VXLANからMPLS IP VPNへ：VNIはMPLSラベルではない

どちらの技術もパケットの前に識別子を置くため、VNIをMPLSラベルに対応付け、二つのネットワークを結合すればよいという結論は明白に見えます。しかしその対応付けは、識別子の意味が異なり、生成するコントロールプレーンも異なるため、サポートされた操作としては存在しません。VNIはオーバーレイ内のVXLANセグメントを識別し、MPLSラベルはラベルスイッチパスに沿った転送処理を識別します。ドメインを結合することはルーティングの判断であり、数値の変換ではありません。

神話：どちらもラベルを使うから対応付けよう

表面上の類似は現実であり、同時に誤解を招きます。VXLANはヘッダーに24ビットのVNIを運び、MPLSはラベルのスタックを運ぶため、境界装置で一方の値を他方に書き換えられるように見えます。

この発想を崩すのは、値の周辺にあるすべてです。VNIはEVPNコントロールプレーンとアンダーレイのトンネル端点が解決します。ラベルはMPLS転送プレーンがパスに沿って割り当てます。どちらの側にも、相手側の識別子を自分のものとして受け入れる手順は定義されていません。

各側が実際に転送するもの

ファブリック側では、境界装置がVXLANトンネルを終端し、VNIをテナントのVRFに対応付け、パケットを通常のIPとしてルーティングします。プロバイダー側では、PEが顧客ルートをVRFに受け入れ、MPLSラベルのスタックを付与し、IP VPN越しに転送します。

この受け渡しは、顧客エッジがプロバイダーエッジとIPルートを交換し、各ドメインが自らのカプセル化を持つ、RFC 4364でよく理解されたモデルです。パケットがPEに届く頃にはVNIは消えており、まさにそれがこのモデルが機能する理由です。

コントロールプレーンが統合されない理由

EVPN Type 5はオーバーレイのネクストホップを伴うIPプレフィックスルートを運び、VPN-IPv4の広告は別のアドレスファミリーに属します。両側で同じに見えるルートターゲットは、一方のファミリーを他方に変換せず、境界を越えたネクストホップも解決しません。

統合ゲートウェイが両方の役割を果たせるのは、プラットフォームが必要なカプセル化とルートファミリー間のインターワーキングを実装している場合だけです。この能力は、正確なハードウェアとリリースについて検証する必要があり、製品ファミリー名から推測してはいけません。

この境界では、さらに二つの前提が崩れます。MPLS IP VPNが提供するのはルーテッド到達性であり、Ethernetセグメントではないため、ブロードキャストを延伸するには代わりに対応するレイヤー2サービスが必要です。また、どちらのカプセル化もバイトを消費するため、実効MTUはどちらのアンダーレイが示すよりも小さくなります。

ルーテッドハンドオフか統合ゲートウェイを選ぶ

テナントがIP到達性を必要とし、プロバイダーがすでにCE向けサービスを提供している場合は、ルーテッドハンドオフを選びます。所有関係が明確になります：ファブリックがVXLANとEVPNを、プロバイダーがMPLSとVPNを、境界がVRFとインターフェースの対応付けを持ちます。単一リンクで足りると仮定せず、接続規模、アドレッシング、フェイルオーバーをプロバイダーと計画してください。

統合ゲートウェイを選ぶのは、運用するプラットフォームが両方の役割をサポートし、インターワーキングを試験できる場合だけです。装置削減は現実の利点ですが、二つのコントロールプレーンが一致しなければならない唯一の場所が一つの装置になるという運用リスクも現実です。

テナントごとに記録するもの

接続、受け入れたプレフィックスと広告したプレフィックス、ネクストホップの解決方法、境界またはプロバイダーリンクの障害後に期待される挙動を、テナント固有の記録として残します。両方のカプセル化境界と戻り経路のMTU予算も含めてください、順方向が動くだけではほとんど何も証明できないからです。

その記録こそが、ルーティングとカプセル化の前提が同じだと装わずに、二つの管理ドメインをつなぐものです。後になってVNIを単にラベルにできるのかと誰かが尋ねたとき、文書は議論ではなく設計で答えます。