要約

  • RFC 10039のドメインは、テナント通信が途中でテナント空間のIPルックアップを必要とするかどうかで区切られる。AS番号、IGPインスタンス、拠点名から自動的に決まるものではない。
  • 受信したD-PATHにローカルのDOMAIN-IDがあれば返ってきた経路と判定され、D-PATHの長さも最良経路選択に入る。誤ったIDは、実在しないループを作るのと同じ力で正当な経路を消し得る。

二台の冗長ゲートウェイに同じ図面が配られていた。一台は東側ファブリックを一つのドメインとして設定し、もう一台はテナントVRFごとに別のドメインとしていた。どちらの設定も構文上は正しく、BGPセッションも確立している。それでも、返ってきた経路を見たとき、二台は別の世界を照合する。

この不一致は、D-PATHの実装不良ではない。実装に渡した境界定義の不一致である。

RFC 10039は、EVPNとIPVPNを組み合わせてテナントのサブネット間通信を複数ドメインにまたがって提供するための手順を定めた。Interworking PEは一方のドメインから経路を受け、IP-VRFへ取り込み、隣のドメインに合うアドレスファミリーと属性で再生成する。冗長なゲートウェイがあると、IPVPNからEVPNへ移した経路を別のゲートウェイが再びIPVPNへ戻し、制御プレーンのループを作り得る。

D-PATHは経由ドメインの列を残し、ゲートウェイが自分のドメインを見つけたときに戻りを止める。しかし「自分のドメイン」という事実は、装置が学習したものではなく、運用者が設定したものである。

AS境界とドメイン境界は別物である

RFCの定義では、同じテナントに接続する二つのPE間で、途中のルータがテナント空間のIPルックアップを行わずにパケットを渡せるなら、両者は同じドメインに属する。そのルックアップが必要になる場所を、ゲートウェイがつなぐ。

一つのドメインが複数ASにまたがることも、一つのASの中に複数ドメインが存在することもある。IGPやデータセンター、事業部、クラウドリージョンの境界も、そのまま答えにはならない。図面の箱と転送上の境界が一致する場合でも、確認すべきなのは箱の名前ではなく、実際のIPルックアップである。

DOMAIN-IDは6オクテットで、4オクテットのGlobal Administratorと2オクテットのLocal Administratorから成る。前半には公開・プライベートASN、IPv4アドレス、その他の値を使える。人が割り当てやすく、調査しやすい形式だが、ASNらしい表記がASとの同一性を証明するわけではない。アドレスらしい値も、ドメインの権限を認証しない。

必要なのは一貫した割り当てである。各ドメインには一意のDOMAIN-IDが必要で、同じドメインに接続するすべてのゲートウェイPEが同じ値を使わなければならない。二つのドメインをつなぐ一台のゲートウェイには、側ごとに異なる二つのIDがある。さらに、IDは相互接続全体に割り当てることも、テナントIP-VRFごとに割り当てることもできる。VRF間で経路をリークする設計では、どのVRFのローカルIDと比較するかが結果を変える。

設定値が経路を拒否する

D-PATHはオプショナル・トランジティブなBGP Path Attributeで、IANAのBGPパラメータではコード36である。各エントリにはDOMAIN-IDとISF_SAFI_TYPEが入り、EVPN、IPVPN、あるいはローカル起源を表す一部のゼロ値など、どの種類で区間を通ったかを示す。

SAFI種別は運用確認には役立つが、ループ判定の鍵ではない。受信D-PATH内のDOMAIN-IDが、そのIP-VRFに設定されたローカルIDのどれかと一致すれば、SAFI値が何であっても戻り経路として扱われる。種類の変更で検出をすり抜けないための設計だが、ID衝突にも同じ厳しさで反応する。

別ドメインが同じ値を使えば、正当な経路が戻りと誤認される。同一ドメインのゲートウェイが異なる値を使えば、本当の戻りを見逃す。IDのスコープが違えば、片側がVRF単位の現実を見ているのに、もう片側は相互接続全体を見ているという状態になる。

しかもD-PATHは単なるログではない。同じプレフィックスについてEVPNと非EVPNの候補を比較する際、LOCAL_PREFの比較後に最短D-PATHでない候補が除外される。D-PATHを持たない経路は長さゼロとして扱う。この長さは光ファイバー距離、遅延、混雑、費用、信頼性を表さない。設定されたドメイン通過回数である。それでも選択結果を変える。

属性を消すか、限定して引き継ぐか

D-PATHはデフォルトで広告されず、IPVPNとEVPNの経路だけに使う。明示的に有効化した上で、境界ごとに属性伝播の方針を選ぶ。

デフォルトのNo Propagation Modeでは、ゲートウェイが別ドメインへ経路を再生成するときにBGP属性を初期化し、D-PATHを渡さない。遠隔ドメインへ持ち込む状態を減らせる一方、冗長ゲートウェイ間のループは残り得る。ローカルポリシーやRoute Origin Extended Communityは緩和策になっても、すべてを検出する保証にはならない。

Uniform Propagation Modeは、共通して意味を持つ属性だけを限定的に保つ。標準的な集合はAS_PATH、適用可能なD-PATH、iBGPピア向けの一部内部属性であり、それ以外は明示的なimport/exportポリシーなしに渡すべきではない。来歴を観察しやすくなる反面、構文は正しいが意味の不適切な属性や、悪意ある情報が次のドメインの選択へ影響する範囲も広がる。

片方が常に安全なのではない。No Propagationは分離のために来歴を失い、Uniform Propagationは来歴のために検証責任を引き受ける。変更票には、境界ごとのモード、許可属性、例外所有者、切り戻し方法が必要である。

正しい構文は正しい意味を保証しない

壊れた属性への処理は具体的だ。セグメント長が不正、全長が短い、または許可されないAFI/SAFIにD-PATHが付く場合、RFC 7606の下流撤回扱いが適用される。未知のSAFI種別はID比較を妨げないため受理できる。同じUPDATEに複数のD-PATHがあれば、最初以外を捨てて処理を続ける。

これらはエンコード破損を封じ込める仕組みであり、よく形成された誤設定は見抜けない。RFC 10039自身が、DOMAIN-IDの誤りやサポートの不整合によって、誤ったループ検出、トラフィック破棄、最適でない、または一貫しない経路選択が起こり得ると警告する。トランジティブ属性である以上、虚偽のドメイン情報が複数の管理境界を越える可能性もある。

VPNの外へ出さないことも運用証明が要る。準拠PEは、通常のSAFI 1ユニキャストとしてCEへ広告する前にD-PATHを削除しなければならない。アップグレード済みPEは、未対応と判断したピアからD-PATH付きISF経路を受けた場合のローカルポリシーも持つべきだ。しかし、そのピアをどう未対応と判定するかは標準の範囲外である。製品資料ではなく、対象バージョンの実験が必要になる。

境界合意と展開レシート

実装前に作るべき成果物は、テナントと相互接続ごとの「ドメイン境界合意」である。最初に、どのPE間でテナント空間のIPルックアップが不要かを記録する。次に、IDを割り当てる責任者、一意性の範囲、衝突検索、全ゲートウェイ、インターフェースとIP-VRFへの束縛を並べる。ASNやアドレス形式を使うなら、それが表記であって証明ではないことも残す。

展開レシートには、ソフトウェア版と実測した機能、境界ごとの伝播モード、属性allowlist、ローカル起源経路の扱い、観測期間、中止条件、D-PATHに依存しない切り戻し経路を加える。各ホップで同一プレフィックスがどんな属性を持つはずか、実施前に書けなければならない。

試験には負のケースを含める。正当な経路が意図した列を通ること、ローカルIDを注入した経路が戻りとして処理されること、未知SAFIでもID比較が続くこと、不正構造が限定的な撤回になること、旧版ピアの実挙動、CE向けSAFI 1からの属性除去を確認する。

最後に、同じカナリアプレフィックスをAdj-RIB-In、候補集合、選択結果、FIB、実パケットまで追跡する。設定受理はパーサの事実、属性表示は宣言の存在、FIBは装置の判断、パケットはその時点の観測である。これらを分けて結合して初めて、「この境界合意がこの展開で機能した」と言える。

RFC 4271はBGPの基礎、RFC 4364はIPVPN、RFC 7432、RFC 9135、RFC 9136はEVPNの文脈を与える。いずれも特定ベンダーや実網の適合を証明する資料ではない。

出典