VPNv4 にコアでの MPLS は必要か？必ずしもそうではない

BGP VPNv4 が交渉するのはルート配布のコンテキストであり、転送パスではない。インポート、ネクストホップ解決、実行できるカプセル化を分けて考える。

二台のルーター間で VPNv4 アドレスファミリーを有効にしても、ルート配布のコンテキストができるだけで、それ以上ではない。転送パスはインストールされず、顧客パケットを遠端のエンドポイントまで運ぶカプセル化がどれかも分からない。この二つの事実を分ければ、「コアに MPLS が必要か」という問いは、プラットフォームが対応するデータプレーンについての、より狭く答えられる問いになる。

アドレスファミリーが実際に交渉するもの

マルチプロトコル BGP は、AFI 1 と SAFI 128 の下で VPNv4 ネットワーク層の到達可能性情報を運び、各エントリはルート識別子をプレフィックスとラベルに組み合わせる。セッションが交渉するのは、両者がその情報を符号化・復号できることだ。交渉しないのはデータプレーンである。この段落以降はすべて転送の話であり、そのどれもセッションの確立では決まらない。

したがって、成功したセッションは制御プレーンの能力の証拠であり、転送の証拠ではない。ルーターは数千の VPNv4 エントリを保持しながらすべての顧客パケットを破棄でき、二つの障害クラスが最初から混同されるのはそのためだ。

NLRI のラベルに注目してほしい。これは VRF 内のプレフィックスに結び付いたサービスラベルであり、パケットが出口エンドポイントに到達した後は転送の役割を持つ。通過する装置がそれを読むかどうかは、別の設計判断である。

受信、インポート、転送は三つのステップ

ルートを受信すること、それを使う許可を得ること、それで転送できることは、装置の異なる部分が担う。BGP は聞いたものを保存し、インポートポリシーとルートターゲットの一致がどの VRF が検討できるかを決め、その後で転送プレーンが広告されたネクストホップを実際にワイヤへ送れるものへ解決しなければならない。

Step in the chainWhat has to be trueHow it fails quietly
NLRI exchangeBoth speakers negotiate the VPNv4 capabilitySession stays up while the family is never activated
Import eligibilityA route target on the received route matches the VRF import policyThe route exists in the table but never enters the VRF
Next-hop resolutionThe advertised next hop resolves to a usable tunnel or label pathBest path is selected, then marked unreachable or unusable
EncapsulationThe egress endpoint can decapsulate what the ingress producedPackets arrive and are discarded for a format mismatch

最も驚くべき障害が住むのは、この中間ステップである。ルートが BGP テーブルに存在し、有効で、最良でさえあっても、ルートターゲットがインポートリストに一致しないため VRF のルートテーブルは空のままでいられる。プロトコルエラーは起きていないので、何もそれを記録しない。

最後のステップでプラットフォーム対応が見えてくる。アンダーレイで到達可能なネクストホップが、自動的に VPN サービス輸送として解決できるとは限らず、装置が特定のトンネル種別、特定のラベル操作、あるいはその両方を要求することがある。解決状態を読むほうが、ルート数を読むより情報量が多い。

IP コアは決してスイッチしないスタックを運べる

保つ価値のある区別は、「コアは MPLS を動かしていない」と「サービス内のどこにもラベルが存在しない」の間にある。これは別の主張であり、最初のものだけが通過装置について述べている。RFC 4023 は IP または GRE トンネルによる MPLS の輸送を定義しており、まさにその仕組みが、完全に IP のコアで二番目の主張を可能にする。

customer packet + service label
  encapsulated in GRE, addressed to the egress tunnel endpoint
  forwarded by ordinary IP routers on the outer header
  decapsulated at the endpoint, label still meaningful

通過ルーターは外側の IP 宛先で転送し、顧客プレフィックスもネイティブなラベルスイッチングも必要としない。遠端では外側トンネルが外され、サービスラベルが仕事を再開する。コアは不透明なペイロードを運んだのであり、それこそが IP ネットワークの得意分野である。

この設計が与えないのは、普遍的な保証である。すべてのルーターがすべての VPNv4 ネクストホップを任意の GRE インターフェース経由で解決する証明ではなく、動作しているネイティブ MPLS 設定を削除する理由でもない。これは普遍的な主張への反例であり、実務的な問いはプラットフォームに局所的なままだ。その問いはプロトコルの規則ではなく、プラットフォームの制限として記録しておく。

ボックス上でチェーンを壊れるまでたどる

受信したルートから始め、失敗する最初のステップで止めるなぜなら、前のステップが壊れている間は後のステップを診断できないからだ。典型的な実装では、四つのコマンドでその大部分を網羅できる。

show bgp vpnv4 unicast all summary
show bgp vrf CUSTOMER_A ip route 198.51.100.0/24
show ip route vrf CUSTOMER_A 198.51.100.0
show mpls forwarding-table vrf CUSTOMER_A

それらは四つの独立した確認ではなく、順序として読む。最初のものはファミリーが有効でピアがルートを交換していることを確かめ、二番目はプレフィックスが使えるネクストホップとともに届いたかを示し、三番目はインポート適格性を証明し、四番目は転送プレーンがラベルやトンネルを結び付けたかを示す。

次に、カプセル化に耐える MTU で、ワークロードの経路を両方向に試験する。GRE はヘッダーのバイトを追加し、小さなプローブを通過する経路が、一方向だけフルサイズのパケットで失敗することがあり、それは輸送障害ではなくアプリケーション障害に見える。

二つの運用上の注意でループを閉じる。GRE はカプセル化であり機密性ではないので、信頼できない通過ネットワークには、想定ではなく上にサポートされたセキュリティ構成が必要だ。そして設計レビューの前に、プラットフォームが実際にどのカプセル化をサポートするかを記録しておくべきであり、その一つの答えが IP のみのコアを有効な選択にするか、転送できない計画にするかを決める。

関連記事