VXLAN とオーバーレイネットワークの原理

なぜ「L2 を L3 の上に乗せる」必要があるのか

データセンターでは、物理的に離れたサーバー間でも同じL2セグメント（同一サブネット・同一ブロードキャストドメイン）に見せたい場面が頻発します。仮想マシンのライブマイグレーションはIPを保ったまま別ラックへ移したいし、マルチテナント環境ではテナントごとに独立したL2を多数用意したい。ところが素のL2は、スパニングツリーで冗長リンクを止める非効率や、MACテーブルとブロードキャストの規模限界を抱え、巨大ファブリックには向きません。

そこで発想を逆転させます。物理網は ルーティングされたL3（IP）ファブリック として安定に作り、その上に L2セグメントをトンネルとして重ねる。下層の物理網を アンダーレイ、その上に論理的に張るネットワークを オーバーレイ と呼びます。VXLAN（Virtual eXtensible LAN, RFC 7348）は、イーサネットフレームをまるごとIPパケットの中に封入してアンダーレイ上を運ぶ、代表的なオーバーレイ方式です。

VXLAN カプセル化：フレームを UDP で包む

VXLANは、元のイーサネットフレーム（宛先MAC〜ペイロード、ただし元フレームのFCSは除く）を VXLANヘッダ → UDP → 外側IP → 外側イーサネット の順で包み直します。外側から見れば、これは普通のUDPパケットにすぎません。だからアンダーレイのルータやスイッチはVXLANを一切知らなくてよく、IPで配送できればそれで足ります。

[外側イーサネット] 宛先MAC | 送信元MAC | EtherType=0x0800
[外側IP]          送信元IP=送信VTEP | 宛先IP=受信VTEP
[UDP]             送信元ポート=ハッシュ値 | 宛先ポート=4789
[VXLANヘッダ(8B)] フラグ | 予約 | VNI(24bit) | 予約
[内側イーサネット] 元の宛先MAC | 元の送信元MAC | ...（元フレームそのもの）
[内側ペイロード]   ARP/IP/...（テナントの実トラフィック）

ポイントは2つあります。第一に、UDPの 宛先ポートは 4789 固定（IANA割り当て）で、受信側はこれを見てVXLANと判定します。第二に、UDPの 送信元ポートは内側フレームのハッシュから生成 します。これは中継網のECMP（等コストマルチパス）が、送信元/宛先ポートを含む5タプルでフロー分散するのを利用するためで、内側フローごとに別の送信元ポートを振ることで、外側1組のVTEP間でも複数物理経路へ均等に散らせます。

24 ビット VNI：論理ネットワークの桁が変わる

VXLANヘッダの中核が VNI（VXLAN Network Identifier） です。24ビット幅で、これがセグメントの識別子になります。同じVNIに属する内側フレームだけが互いに同じL2セグメントとして扱われ、VNIが違えばL2では完全に分離されます。受信VTEPは脱カプセル化のとき、VNIを見て「このフレームはどのセグメント（どのMACテーブル）に属するか」を決めます。

桁の違いが効きます。802.1QのVLAN IDは12ビットで実用上1〜4094の 約4千個 が上限でした（その内部は /network/vlan-trunking-internals/ を参照）。VXLANのVNIは24ビットなので 2^24 = 16777216、約1677万個 のセグメントを区別できます。クラウドのように数万テナントを収容する基盤では、この4千の壁を超えること自体がVXLANを採用する直接の動機になります。

VTEP：トンネルの出入口

カプセル化と脱カプセル化を実際に行う主体が VTEP（VXLAN Tunnel End Point） です。VTEPはハイパーバイザの仮想スイッチ内のソフトウェア実装でも、物理スイッチのハードウェア実装（ハードウェアVTEP）でもよく、いずれもアンダーレイ上で 自分のIPアドレス を1つ持ちます。送信VTEPは内側フレームを包んで宛先VTEPのIPへ送り、受信VTEPはVNIを見て該当セグメントへ元フレームを取り出します。

VTEPが解くべき本質的な問題は 「ある宛先MACが、どのVTEPの背後にいるか」 です。これはL2スイッチが「あるMACがどのポートの先にいるか」を学習するのと同型の問題で（/network/ethernet-switching-internals/ のMAC学習と同じ構図）、VXLANではポートの代わりに リモートVTEPのIP を学ぶことになります。内側MAC → リモートVTEPのIP という対応表をどう作るか、ここがVXLANの設計上の分かれ道です。

VTEP が保持する対応表（概念）
  VNI 5000:
    内側MAC aa:bb:cc:00:00:01 → ローカル（自分の配下）
    内側MAC aa:bb:cc:00:00:02 → リモートVTEP 10.0.0.7
    内側MAC aa:bb:cc:00:00:03 → リモートVTEP 10.0.0.9

フラッディングによる学習：BUM トラフィックの問題

宛先MACの位置がまだ分からないとき、L2は伝統的に フラッディング で解決します。VXLANでも初期方式（データプレーン学習）はこれを踏襲し、宛先不明ユニキャスト・ブロードキャスト・マルチキャスト（頭文字から BUMトラフィック と総称）を、同じVNIに属する全VTEPへ届けます。受信側は元フレームの送信元MACと、外側IPの送信元（リモートVTEP）を結びつけて学習します。

問題は「全VTEPへどう届けるか」です。代表的に2方式あります。

マルチキャストはVNIごとにグループを割り当て、ブロードキャストの届く範囲をグループで再現します（マルチキャストの基礎は /network/multicast-broadcast/）。一方ヘッドエンドレプリケーションはVTEP側で全宛先へコピーを撒くため、台数が増えるほど送信負荷が膨らみます。どちらにせよ フラッディングに依存する限り、規模拡大とともにムダな複製トラフィックが増える のが根本課題です。

EVPN：コントロールプレーンで MAC を配る

この課題を断ち切るのが EVPN（Ethernet VPN） です。発想は単純で、「MACの位置を当て推量のフラッディングで学ぶのをやめ、各VTEPが知っている MAC ↔ 自分のIP を MP-BGP で能動的に広告し合う」。つまりデータプレーン学習（フラッディング）を、コントロールプレーン学習（ルーティングプロトコルでの配布）に置き換えます。

EVPNではVTEPがBGPピアとなり、配下で学習した内側MAC（必要に応じてIPも）を Type 2 ルート（MAC/IP Advertisement） としてBGPで広告します。受信したVTEPは 内側MAC → 広告元VTEPのIP を表に直接書き込めるので、宛先不明ユニキャストのフラッディングが原理的に不要になります。ブロードキャスト/マルチキャスト用の配送グループも Type 3 ルート（Inclusive Multicast） で明示的にメンバを把握でき、BUMの扱いも制御プレーン主導になります。

まとめ

VXLANは、イーサネットフレームをUDP(4789)で包んでL3ファブリックの上に運ぶ「L2 over L3」のオーバーレイです。物理網はIPで安定に作り、その上に論理L2を重ねることで、配線に縛られず広域に同一セグメントを延ばせます。セグメントは24ビットのVNIで識別し、約1677万個という802.1Qを桁違いに超える論理ネットワークを収容できます。トンネルの出入口であるVTEPが封入と取り出しを担い、その中心課題は 内側MAC → リモートVTEPのIP をどう学ぶかにあります。初期方式はBUMトラフィックのフラッディングに頼りましたが、規模とともに無駄が増える。これを断つのがEVPNで、MAC到達情報をMP-BGPのルートとして配り、フラッディングなしの高速・大規模なL2延伸を実現します。「物理はL3で固め、論理L2はカプセル化で重ね、到達情報はBGPで配る」——この三段で捉えれば、現代データセンターのオーバーレイは一本の筋で読み解けます。