GENEVE と NVGRE：オーバーレイカプセル化の比較

VXLAN の固定ヘッダが抱える限界

VXLAN（/network/vxlan-overlay/）は、イーサネットフレームをUDPで包んでL3ファブリック上に論理L2を重ねる、オーバーレイの定番です。しかしそのヘッダは8バイト固定で、中身は実質24ビットのVNI（VXLAN Network Identifier）だけ。残りはフラグと予約領域で、カプセル化の途中で「VNI以外の情報」を運ぶ余地がありません。

これが問題になるのは、論理ネットワークの識別だけでは足りなくなる現代のSDN環境です。たとえば「このパケットはどのファイアウォール規則を通過済みか」「どのテナントのどのセキュリティグループに属するか」「パケットの色付け（QoSメタデータ）はどうか」といった情報を、トンネルの入口で付与し出口で読み取りたい。VXLANにはその器がなく、ベンダーは予約ビットを独自解釈で使うしかありませんでした。結果として方言が乱立し、相互運用が崩れます。

GENEVE：可変長 TLV でメタデータを運ぶ

GENEVE（Generic Network Virtualization Encapsulation, RFC 8926）は、この拡張性の問題を正面から解いた設計です。外側の封入順は 外側イーサネット → 外側IP → UDP → GENEVEヘッダ → 内側フレーム でVXLANと同型ですが、UDP宛先ポートは 6081（IANA割り当て）で、GENEVEヘッダの後半に 可変長のオプション領域 を持つ点が決定的に違います。

[外側イーサネット] 宛先MAC | 送信元MAC | EtherType
[外側IP]          送信元IP=送信トンネル端 | 宛先IP=受信トンネル端
[UDP]             送信元ポート=ハッシュ値 | 宛先ポート=6081
[GENEVEヘッダ(8B+可変)]
   Ver(2bit) | Opt Len(6bit) | O | C | 予約
   Protocol Type(16bit, 例 0x6558=Ethernet)
   VNI(24bit) | 予約(8bit)
   --- 可変長オプション(TLV列, Opt Len×4バイト) ---
   [Opt Class | Type | Length | Variable Data] を必要な数だけ並べる
[内側フレーム]    Protocol Typeで示した中身（イーサ/IP/...）

ヘッダの要点は3つです。第一に Protocol Type で内側ペイロードの種類を明示するため、L2フレームに限らずIPパケットなど任意の中身を運べます（VXLANは内側が常にイーサネット前提）。第二に Opt Len が示す長さだけ TLV（Type-Length-Value）形式のオプション が並び、各TLVは Option Class（ベンダーや用途の名前空間）と Type、長さ、データから成ります。第三に Cビット（Critical） が「このTLVを理解できない機器は破棄せよ」を示し、未知の拡張を安全に扱う規約を与えます。

NVGRE：GRE を土台にした別系統

NVGRE（Network Virtualization using GRE, RFC 7637）は、まったく別の出自を持つオーバーレイです。UDPで包むVXLAN/GENEVEと違い、GRE（Generic Routing Encapsulation） を土台にします。GREヘッダの Key フィールドを24ビットの VSID（Virtual Subnet ID）と8ビットの FlowID に分割 して流用するのが特徴です。

[外側イーサネット]
[外側IP]          Protocol=47 (GRE)
[GREヘッダ]        K=1(Key存在) | Protocol Type=0x6558(Ethernet)
                  Key = VSID(24bit) | FlowID(8bit)
[内側フレーム]    元のイーサネットフレーム

NVGREの設計上の弱点は2つあります。ひとつは 拡張領域が無い こと。GREのKeyは固定32ビットで、GENEVEのようなTLVを足せません。もうひとつは L4ポートが存在しない ことです。GREは外側IPのプロトコル番号47で直接運ばれるため、UDP/TCPの送信元/宛先ポートがありません。中継網のECMP（/network/ecmp-flow-hashing/）は通常5タプル（IPとポート）でフローを分散しますが、ポートが無いNVGREでは外側IPの2タプルしか散らす材料がなく、同一VTEP間の全トラフィックが1経路に集中 しがちです。NVGREはこれを補うためKey内に8ビットのFlowIDを置き、中継機器がそれをハッシュ材料に使えるよう規定しましたが、対応する機器が限られ普及の足かせになりました。

三方式の構造比較

セグメント数はどれも24ビットで同等（2^24、約1677万）です。差が出るのは 拡張性・ペイロードの自由度・経路分散 の3点で、いずれもGENEVEが優位、NVGREが不利という構図になります。NVGREはGRE資産との親和性を狙いましたが、ポート不在によるECMPの不利が実務で重く、現在は新規採用がほぼ途絶えています。

SDN コントローラとの連携

GENEVEが新規採用の主流になった最大の理由は、SDNコントローラとの親和性 です。Open vSwitch系のOVNや、VMware NSXといったコントローラは、トンネル端（VTEPに相当）にフローテーブルを配り、データプレーンの振る舞いを集中制御します。このとき「パケットに付随する論理メタデータ」をトンネルをまたいで運べるかどうかが、機能の幅を直接左右します。

GENEVEのTLVは、まさにこのメタデータの受け皿です。たとえばOVNは、論理ポートの識別子や、入口で評価済みのACL状態などをGENEVEオプションに載せ、出口側がそれを読んでパイプラインの続きを実行します。これにより 「分散したスイッチ群を、あたかも1台の論理スイッチのように」 振る舞わせられます。VXLANやNVGREのように識別子しか運べないと、こうしたメタデータは別の手段（パケット外の制御チャネルや、IPヘッダの一部流用）で補うしかなく、設計が歪みます。

まとめ

GENEVEとNVGREは、VXLANの「固定ヘッダで識別子しか運べない」限界に対する2つの異なる回答です。GENEVE（RFC 8926, UDP 6081）は、可変長TLVのオプション領域とProtocol Typeを備え、任意のペイロードと将来拡張可能なメタデータをトンネル越しに運べる「拡張可能な封筒」です。NVGRE（RFC 7637）はGREを土台にKeyの24ビットをVSIDに流用しますが、拡張領域が無く、L4ポートが無いためECMPの経路分散に弱く、普及は伸び悩みました。セグメント数はどれも24ビットで横並びで、本質的な差は 拡張性・ペイロードの自由度・経路分散 にあります。SDNコントローラがメタデータをデータプレーンへ注入する受け皿としてTLVが効くため、OVNやNSXを含む新規設計ではGENEVEが事実上の標準です。「識別子だけならVXLAN、拡張するならGENEVE、GRE資産前提の特殊解がNVGRE」——この三分法で捉えれば、オーバーレイ方式の選択は一本の筋で読み解けます。