前提知識
スパイン・リーフ（Spine and Leaf）とは何か？
昔ながらのオフィスネットワーク（3層階層型：コア、ディストリビューション、アクセス）の古いやり方から脱却するために生まれた「配線・接続のトポロジ（形）の名称」。
特徴：
- リーフ（Leaf = 葉っぱ）スイッチ
- 役割： サーバーやストレージ、あるいは外部ネットワークとの接続口（末端）になるスイッチ。木にたとえると「葉っぱ」の位置にある。
- 特徴： すべての物理サーバーは、このリーフスイッチにぶら下がる。「リーフスイッチ同士は、直接は繋がらない」というルールがある。必ずすべてのリーフスイッチは、すべてのスパインスイッチと網の目のように接続される（これをClosトポロジと呼ぶ）。
- スパイン（Spine = 背骨）スイッチ
- 役割： リーフスイッチ同士を相互に接続するための、中心となる背骨（コア）のスイッチ。木にたとえると「幹や背骨」にあたる部分。
- 特徴： 「スパインスイッチ同士は、直接は繋がらない」というルールがある。
メリット：
- どこからどこへ通信しても、ホップ数（経由する機器の数）が常に一定
- どのサーバーのVM Aから、別のラックにいるVM Bへ通信する場合でも、必ず「Leaf → Spine → Leaf」の「常に2ホップ（最短）」で通信できる。これにより、ネットワークの遅延（レイテンシ）が均一になり、予測しやすくなる。
- 圧倒的な拡張性と耐障害性
- スパインやリーフを増やしたいときは、足りなくなったらポンと新しいスイッチを追加して配線するだけでスケールアウトできる。どれか1台のスパインスイッチが壊れても、他のスパインを通っていけるため通信が途絶えない。
SDNの全貌
どうやってアンダーレイを作り、その上でどうやってOpenFlowとコントローラーが動いて疎通に至るのかの全貌を見ていこう！
ステップ1：まずは「アンダーレイ」で最低限のIP通信を可能にする
最初に行うのは物理的な結線と、アンダーレイ（物理ネットワーク）の構築。
- 何をするのか：
- SpineスイッチとLeafスイッチ、そして物理サーバーの間で、通常のIPルーティング（OSPFやBGPなどのルーティングプロトコル）を設定。
- なぜこれが必要か：
- 「SDNコントローラーと、各スイッチ（や仮想スイッチ）がIPパケットで通信できるようにするため」の土管を作る。
- コントローラーはネットワーク全体の頭脳だが、物理的なスイッチやサーバーに指示を送るためには、まず「コントローラーから各機器へIPパケットが届く状態（疎通）」になっていなければならない
- ここで重要なポイント：
- このアンダーレイ（OSPF等）によって、「コントローラーとスイッチ間が話せるようになる」だけであり、まだ「仮想マシン（VM）同士が通信するための複雑なポリシーやルーティング」は一切決まっていない。
ステップ2：コントローラーとOpenFlowスイッチの接続（握手）
アンダーレイでIPが通るようになったら、次に行うのがOpenFlowのセッション確立。
- 接続の確立：
- 各OpenFlowスイッチ（Spine/Leaf/仮想スイッチ）は、起動すると「自分の頭脳はどこにいるか」という設定（コントローラーのIPアドレス）を持っている。
- スイッチはアンダーレイのIP網を使って、SDNコントローラーに対して「おーい、つながったよ（OpenFlow接続の要求）」と話しかけに行く。
- これで、コントローラーがすべてのスイッチをリモート操作できる「専用のコントロール線（OpenFlow制御チャネル）」が完成する。
ステップ3：いよいよ本番！「仮想マシン（VM）同士が通信する（疎通）」までの具体的なパケットのフロー
１．アンダーレイ
２．コントローラとセッション確立
ここからがOpenFlowの真骨頂。「VM AからVM Bへ初めてパケットを送るとき、裏で何が起きているのか」を追っていこう！
- 最初のパケット（Packet-In）の発生
- VM A（例: 左下の物理サーバー内）が、通信相手であるVM B（右下の物理サーバー内）宛てにパケットを送信。
- パケットは、まず物理サーバー内の仮想スイッチ（OpenFlow vSwitch）に届く。
- フローテーブルに「一致するルールがない！」
- 仮想スイッチは自分の「フローテーブル（転送ルール一覧）」を確認するが、まだこの通信のルールは登録されてない（初期状態はからっぽ）。
- 仮想スイッチは自分の「フローテーブル（転送ルール一覧）」を確認するが、まだこの通信のルールは登録されてない（初期状態はからっぽ）。
- コントローラーへ助けを求める（Packet-Inメッセージ）
- ルールを知らない物理サーバ内の仮想スイッチは、どうしていいか分からないため、そのパケットそのもの（あるいはヘッダ情報）を、OpenFlowプロトコルに乗せてSDNコントローラーへ丸投げする。「ねぇ、この宛先宛のパケットが来たんだけど、どこに投げたらいい？」と聞きに行く（これを Packet-In と呼ぶ）。
Q.なんでどうしたらいいかわからないの？アンダーレイのテーブルに従えばいいじゃん？
A.初期状態ではvm-Bがどの物理サーバに格納されているかまではわからない。
分かっているのは、vm-BのプライベートIPアドレスだけ。
- ルールを知らない物理サーバ内の仮想スイッチは、どうしていいか分からないため、そのパケットそのもの（あるいはヘッダ情報）を、OpenFlowプロトコルに乗せてSDNコントローラーへ丸投げする。「ねぇ、この宛先宛のパケットが来たんだけど、どこに投げたらいい？」と聞きに行く（これを Packet-In と呼ぶ）。
- 頭脳（コントローラー）が経路とポリシーを計算
- コントローラーは、ネットワーク全体のトポロジを把握している。「あ、VM Bは右下のあのサーバーのあのポートにいるな。この通信はセキュリティ的に許可されているな」ということを計算する。
Q.どうやってコントローラーはVM Bがどの物理サーバ内にあるのかを知るの？
A.上位システムからの事前登録。データセンターでは、OpenStackやVMwareなどの仮想化管理システム（オーケストレーター）が裏で動いています。「VM Bをこのサーバー上で起動したよ」というイベントが起きると、その情報が上位システムからSDNコントローラーに事前に連携・登録される。
- コントローラーは、ネットワーク全体のトポロジを把握している。「あ、VM Bは右下のあのサーバーのあのポートにいるな。この通信はセキュリティ的に許可されているな」ということを計算する。
- スイッチへルールを書き込む（Flow-Modメッセージ）
- コントローラーは、通信経路上にあるすべてのスイッチ（送信元の仮想スイッチ、途中のLeaf/Spineスイッチ、宛先の仮想スイッチ）に対して、「こういう宛先のパケットが来たら、このポートから出しなさい、あるいはこういう書き換えをしなさい」という具体的なルール（フローエントリ）を一斉に指示（Flow-Mod）して書き込む。
- コントローラーは、通信経路上にあるすべてのスイッチ（送信元の仮想スイッチ、途中のLeaf/Spineスイッチ、宛先の仮想スイッチ）に対して、「こういう宛先のパケットが来たら、このポートから出しなさい、あるいはこういう書き換えをしなさい」という具体的なルール（フローエントリ）を一斉に指示（Flow-Mod）して書き込む。
- 2回目以降のパケットは超高速でスイスイ通る
- ルールを書き込まれたスイッチたちは、次からはコントローラーに聞くことなく、自分たちのハードウェア処理（ASIC）で爆速でパケットを転送する。
以上👆３ステップがSDN/OpenFlowの全貌である。
