メインコンテンツまでスキップ

4. VXLAN

VXLAN (仮想拡張可能ローカルエリアネットワーク, Virtual eXtensible Local Area Network) は、マルチテナント環境においてVMが存在する場合のレイヤ2およびレイヤ3データセンターネットワークインフラストラクチャの上記の要件に対処します。既存のネットワークインフラストラクチャ上で動作し、レイヤ2ネットワークを「拡張」する手段を提供します。つまり、VXLANはレイヤ3ネットワーク上のレイヤ2オーバーレイスキームです。各オーバーレイはVXLANセグメント (VXLAN Segment) と呼ばれます。同じVXLANセグメント内のVMのみが相互に通信できます。各VXLANセグメントは、「VXLANネットワーク識別子 (VXLAN Network Identifier, VNI)」と呼ばれる24ビットのセグメントIDによって識別されます。これにより、同じ管理ドメイン内で最大16MのVXLANセグメントが共存できます。

VNIは、個々のVMから発信される内部MACフレームの範囲を識別します。したがって、セグメント間で重複するMACアドレスを持つことができますが、トラフィックはVNIを使用して分離されるため、トラフィックが「交差」することはありません。VNIは、VMから発信される内部MACフレームをカプセル化する外部ヘッダー内にあります。以下のセクションでは、「VXLANセグメント」という用語は「VXLANオーバーレイネットワーク」という用語と互換的に使用されます。

このカプセル化により、VXLANはレイヤ3ネットワークの上にレイヤ2ネットワークをオーバーレイするトンネリングスキームとも呼ばれます。トンネルはステートレスであるため、各フレームは一連のルールに従ってカプセル化されます。以下のセクションで説明するトンネルのエンドポイント (VXLANトンネルエンドポイント, VXLAN Tunnel End Point または VTEP) は、VMをホストするサーバー上のハイパーバイザー内に配置されています。したがって、VNIおよびVXLAN関連のトンネル/外部ヘッダーカプセル化はVTEPのみが知っており、VMはそれを見ることはありません (図1を参照)。VTEPは物理スイッチまたは物理サーバー上にも存在でき、ソフトウェアまたはハードウェアで実装できることに注意してください。VTEPが物理スイッチである1つのユースケースは、VXLANデプロイメントシナリオに関するセクション6で説明されています。

以下のセクションでは、1つのタイプの制御スキーム、すなわちデータプレーン学習 (Data Plane Learning) を使用したVXLAN環境での典型的なトラフィックフローシナリオについて説明します。ここでは、VMのMACからVTEPのIPアドレスへの関連付けは、送信元アドレス学習を介して発見されます。マルチキャスト (Multicast) は、未知の宛先、ブロードキャスト、およびマルチキャストフレームを伝送するために使用されます。

学習ベースの制御プレーンに加えて、VTEP IPからVM MACへのマッピング情報の配布には他のスキームも可能です。オプションには、個々のVTEPによる中央権限/ディレクトリベースのルックアップ、中央権限によるこのマッピング情報のVTEPへの配布などが含まれる可能性があります。これらはそれぞれプッシュ (Push) およびプル (Pull) モデルとして特徴付けられることがあります。このドキュメントでは、VXLANの制御プレーンとしてデータプレーン学習スキームに焦点を当てます。

4.1. Unicast VM-to-VM Communication (ユニキャストVM間通信)

VXLANオーバーレイネットワーク内のVMを考えます。このVMはVXLANを認識していません。異なるホスト上のVMと通信するために、通常どおりターゲット宛てのMACフレームを送信します。物理ホスト上のVTEPは、このVMが関連付けられているVNIを検索します。次に、宛先MACが同じセグメント上にあるかどうか、および宛先MACアドレスからリモートVTEPへのマッピングが存在するかどうかを判断します。存在する場合、外部MAC、外部IPヘッダー、およびVXLANヘッダーで構成される外部ヘッダー (フレーム形式についてはセクション5の図1を参照) が元のMACフレームの前に追加されます。カプセル化されたパケットはリモートVTEPに転送されます。受信すると、リモートVTEPはVNIの有効性と、そのVNI上に内部宛先MACアドレスと一致するMACアドレスを使用するVMが存在するかどうかを確認します。存在する場合、パケットはカプセル化ヘッダーを削除され、宛先VMに渡されます。宛先VMは、VNIについて、またはフレームがVXLANカプセル化で転送されたことを知ることはありません。

パケットを宛先VMに転送することに加えて、リモートVTEPは内部送信元MACから外部送信元IPアドレスへのマッピングを学習します。このマッピングをテーブルに保存することで、宛先VMが応答パケットを送信するときに、応答パケットの「未知の宛先」フラッディングを行う必要がなくなります。

送信元VMによる送信前に宛先VMのMACアドレスを決定する方法は、セクション4.2で説明されている内容を除いて、非VXLAN環境と同じように実行されます。ブロードキャストフレームが使用されますが、セクション4.2で詳述されているように、マルチキャストパケット内にカプセル化されます。

4.2. Broadcast Communication and Mapping to Multicast (ブロードキャスト通信とマルチキャストへのマッピング)

送信元ホスト上のVMがIPを使用して宛先VMと通信しようとする場合を考えます。両方が同じサブネット上にあると仮定すると、VMはアドレス解決プロトコル (Address Resolution Protocol, ARP) ブロードキャストフレームを送信します。非VXLAN環境では、このフレームはそのVLANを伝送するすべてのスイッチでMACブロードキャストを使用して送信されます。

VXLANでは、VXLAN VNIを含むヘッダーがIPヘッダーおよびUDPヘッダーとともにパケットの先頭に挿入されます。ただし、このブロードキャストパケットは、そのVXLANオーバーレイネットワークが実現されるIPマルチキャストグループに送信されます。

これを実現するには、VXLAN VNIと使用するIPマルチキャストグループとの間のマッピングが必要です。このマッピングは管理レイヤーで行われ、管理チャネルを通じて個々のVTEPに提供されます。このマッピングを使用して、VTEPは上流のスイッチ/ルーターにIGMPメンバーシップレポートを提供して、必要に応じてVXLAN関連のIPマルチキャストグループに参加/脱退できます。これにより、特定のマルチキャストアドレスを使用するメンバーがこのホスト上で利用可能かどうかに基づいて、特定のマルチキャストトラフィックアドレスのリーフノードのプルーニングが可能になります ([RFC4541] を参照)。さらに、プロトコル独立マルチキャスト - スパースモード (Protocol Independent Multicast - Sparse Mode, PIM-SM [RFC4601] を参照) などのマルチキャストルーティングプロトコルを使用すると、レイヤ3ネットワーク内で効率的なマルチキャストツリーが提供されます。

VTEPは (*,G) 結合を使用します。これは、VXLANトンネルソースのセットが不明であり、VMが異なるホスト間で起動/停止するため、頻繁に変更される可能性があるため必要です。ここで付記すると、各VTEPはマルチキャストパケットの送信元と宛先の両方として機能できるため、双方向PIM (Bidirectional PIM, BIDIR-PIM -- [RFC5015] を参照) のようなプロトコルがより効率的です。

宛先VMは、IPユニキャストを使用して標準ARP応答を送信します。このフレームは、IPユニキャストVXLANカプセル化を使用して、発信元VMを接続するVTEPにカプセル化されます。これは、ARP応答の宛先MACからVXLANトンネルエンドポイントIPへのマッピングが、ARP要求を通じて以前に学習されたため可能です。

マルチキャストフレームおよび「未知のMAC宛先」フレームも、ブロードキャストフレームと同様にマルチキャストツリーを使用して送信されることに注意してください。

4.3. Physical Infrastructure Requirements (物理インフラストラクチャ要件)

ネットワークインフラストラクチャ内でIPマルチキャストが使用される場合、ネットワーク内の個々のレイヤ3 IPルーター/スイッチでPIM-SMのようなマルチキャストルーティングプロトコルを使用できます。これは、マルチキャストフレームを受信するように要求したホストにのみ送信されるように、効率的なマルチキャスト転送ツリーを構築するために使用されます。

同様に、送信元VMと宛先VMを接続する実際のネットワークがレイヤ3ネットワークである必要はありません。VXLANはレイヤ2ネットワーク上でも動作できます。いずれの場合でも、IGMPスヌーピングを使用してレイヤ2ネットワーク内で効率的なマルチキャストレプリケーションを実現できます。

VTEPはVXLANパケットをフラグメント化してはなりません (MUST NOT)。中間ルーターは、より大きなフレームサイズのためにカプセル化されたVXLANパケットをフラグメント化する可能性があります。宛先VTEPは、このようなVXLANフラグメントを静かに破棄してもかまいません (MAY)。フラグメント化せずにエンドツーエンドのトラフィック配信を確保するために、カプセル化による大きなフレームサイズに対応する値に物理ネットワークインフラストラクチャ全体のMTU (最大転送ユニット, Maximum Transmission Unit) を設定することが推奨されます (RECOMMENDED)。パスMTU発見 ([RFC1191] および [RFC1981] を参照) などの他の技術も、この要件に対処するために使用してもかまいません (MAY)。