要約

  • Route Target Constraints は PE の import 関心を相手別の開示状態に変える。RT Membership NLRI は経路の保有側へ進み、合致する VPN 到達性は反対方向へ戻る。
  • 参加、離脱、移行の完了には AFI 1/SAFI 132、正確な membership、上限付き同期、VPN Adj-RIB-Out の差分、独立した安全ポリシー、VRF・ラベル・FIB・パケットの証拠が必要である。

開通手順を終えた直後を考える。受信 PE には新しい VRF があり、import RT は設計書どおりだ。送信元 PE の VPN RIB には対象プレフィックスがあり、途中の BGP セッションもすべて Established を示す。ところが受信側には何もない。

この場合、探すべき最初の欠落は VPN 経路そのものとは限らない。受信 PE が必要な RT Membership NLRI をまだ起点としていないか、RR がその方向を保持していない可能性がある。RR は、その相手が対象経路を必要としていると判断できず、VPN Adj-RIB-Out から経路を除外する。

RFC 4684 の RTC、すなわち RT-Constrain は、この選択的配布を定義する。全 PE に大量の VPN 経路を送り、各 PE が不要分を捨てる方式に対し、受信者が関心を広告し、RR が相手別の出力フィルターを組み立て、合致分だけを返す。

membership が疎であるほど、メモリー、更新、処理量の削減は大きい。同時に、運用上の問いも変わる。送信元の経路が有効であることと、ある受信者に開示されるべきことは別の証明になる。

Route Target は候補資格を与えるだけ

RFC 4364 では、Route Distinguisher と Route Target は別物である。RD は重複し得る VPN プレフィックスを BGP 上で一意にする。RT は extended community であり、VRF の export と import の関係を制御する。

経路の RT が VRF の import RT の一つと一致すると、その経路は VRF に取り込まれる候補になる。まだインストールされたわけではない。BGP 選択、ローカルポリシー、PE/CE 処理、next hop とラベルの再帰解決、RIB と FIB のプログラミングが残る。

RTC membership も顧客の身元や契約を表さない。上流が不要な NLRI を開示しないための配布関心である。membership は VRF を作らず、VPN 経路を検証せず、パケット配送も証明しない。

従って「VPN 経路がない」には異なる境界がある。送信元が起点化していない、RR が保持していない、RTC 関心がない、反射で必要な membership path が失われた、派生フィルターが古い、受信後に import や選択で落ちる、ラベルや next hop が解決しない、FIB の先でパケットが失敗する、といった境界だ。

正しい調査は、期待した状態が最初に消える場所を特定する。総経路数だけでは、その位置を示せない。

関心の向きと経路の向きは逆になる

RFC 4684 の中心は、Route Target membership から作る逆向きの配布グラフである。受信ネットワークは、特定の RT への関心を VPN 経路の保有・配布側へ伝える。その情報から相手別フィルターができ、合致する経路が受信者へ戻る。

これは遠隔装置への命令ではない。membership 自体が BGP の到達性オブジェクトであり、選択、ポリシー、route reflection の影響を受ける。関心を広告した装置と、最終的に経路を開示する装置の間の各段階を確認する必要がある。

membership NLRI は RFC 4760 の MP_REACH_NLRI または MP_UNREACH_NLRI で運ばれ、AFI 1、SAFI 132 を使う。default を除くキーには 4 オクテットの origin AS と 8 オクテットの Route Target が入り、32～96 ビットのプレフィックスとして表される。短いプレフィックスは広い関心を表せるが、状態と開示範囲も広げる。

長さ 0 の RT membership は default membership route である。その相手関係で関連 VPN 広告を広く受け取る意思を示す。IP の default route、default VRF、全顧客を表す識別子、全経路をインストールする指示ではない。

RR の役割や RTC 非対応装置との混在によって dense な受信が必要な場合はある。しかし default membership は選択性と拡張性を消費する。どの neighbor と family に認めるか、独立フィルターが何を残すかを明文化すべきである。

Capability は交換面を示すが、購読内容は示さない

両者が BGP OPEN で AFI 1/SAFI 132 を合意すれば、RTC family を交換できる。これは必要条件だが、特定 membership の存在、選択、フィルター反映を証明しない。設定に rtfilter や family route-target があっても同じである。

証拠は層ごとに残す。両方向の capability、正確な MP_REACH/MP_UNREACH、peer の RTC RIB、選択済みと代替の membership path、適用ポリシー、VPN family ごとの派生 Adj-RIB-Out フィルターである。

Cisco の Route Target Constraint 解説 は、VRF import RT から rtfilter 更新を生成し、RR が受信フィルターを使う実装例を示す。Juniper の family route-target も、PE が必要な RT を知らせ、RR が一致する経路だけを送る流れを説明する。

ただしコマンド、既定値、表示項目は製品固有である。Cisco の bgp default route-target filter や Juniper の Route Target Filtering の設定が存在しても、RFC 4684 の family が実際に相手と交渉され、期待する membership が届いた証拠にはならない。

RR は一つの通常 best path だけを見てはいけない

複数の PE が同じ AS 内で、同じ {origin AS, Route Target} membership を起点化することがある。通常の iBGP best path 一つだけを使えば、他のクライアントから来た「需要の方向」が消え、RR が必要な相手へ VPN 経路を返せなくなる。

RFC 4684 は、RT プレフィックスの出力フィルターを作る際に、利用可能なすべての iBGP path を考慮するよう求める。また、ローカル起点の membership の広告にも特別な扱いを加える。これは RFC 4456 の route reflection を土台にするが、通常の反射動作だけで RTC の要件が満たされるわけではない。

これは VPN 到達性の ADD-PATH でもない。複数の到達性候補を一つの受信者へ渡すためではなく、どのクライアント方向に需要があるかを失わないための処理である。

したがって「RT プレフィックスが BGP table にある」という確認は不十分だ。起点 PE、RR が保持した各 path、neighbor 別の派生フィルター、そこから生じた VPN Adj-RIB-Out を対応付ける必要がある。

参加と離脱は分散グラフの遷移である

membership の広告または withdraw を受けると、送信者は VPN RIB-OUT を再評価し、旧グラフから新グラフへ移るために必要な最小限の広告・撤回を行う。設定 commit は参加完了ではなく、RT を削除した事実も離脱完了ではない。

参加では、承認済み import 意図、membership 起点化、RR での受信と全 path 処理、peer filter の拡張、VPN Adj-RIB-Out への追加、PE の受信、VRF import、label と next hop、FIB、パケットの順に検証する。

離脱では、他のローカル VRF が同じ RT を必要としていないことを先に確かめる。membership withdraw 後、別の有効 RT でも一致する経路を残し、不要になったものだけを消す。一つの経路が複数 RT を持ち、一つの VRF が複数 RT を import できるため、件数比較だけでは誤りを隠す。

経路 ID と属性の集合を前後で比較し、旧 RR から新 RR への移行では、意図した重複期間と旧グラフ消滅の双方を記録する。

EoR の待機には上限がある

初期交換時に RR が membership 集合の到着を待ってから VPN 広告を始めれば、不要な一時開示を減らせる。RFC 4684 は Graceful Restart がなくても RTC family の End-of-RIB を推奨する。

しかし EoR は無期限の待機許可ではない。VPN 広告を遅らせる場合は上限を置き、RFC は default を 60 秒としている。これは全ネットワーク共通の SLO ではなく、最適化が制御面停止へ変わらないための境界である。実際の timer、EoR 時刻、期限後の動作を記録する。

Route Refresh と RTC update も区別する。RTC は現在の関心を変える。Route Refresh は現在の export state の再広告を求める。RFC 5291 の ORF は ROUTE-REFRESH と共に typed entry を運ぶ別機構である。RFC 7543 の Covering Prefix ORF は、不足する VPN route を得るため RTC membership を起点化させ得るが、通常の RTC に必須ではない。

RTC はセキュリティ境界ではない

RFC 4684 は、RT membership から作る output filter を security purpose に使うものではないと明示する。管理ドメインを越えるなら、VPN NLRI の独立した入出力フィルターと、membership 自体へのポリシーが必要である。

membership は peer から受けた BGP assertion にすぎない。顧客認証でも契約証明でもなく、任意 RT の使用許可、VPN 経路の正当性、データプレーンの制限を与えない。相手が自由に interest を広げ、それを送信者が許可と誤解すれば、情報開示も広がる。

安全統制は RT namespace、peer role、境界での変換、membership input、VPN NLRI output、状態上限、ログ、rollback を別に持つ。RTC はその下で配布を効率化できるが、統制そのものにはならない。

二方向の証拠を一本の鎖にする

RFC 4271 の Adj-RIB-In、Loc-RIB、Adj-RIB-Out の区別を、membership と VPN の二 family に拡張して使う。単一画面を全過程の代理にしない。

受信 PE から始め、承認済み import RT と反映時刻を保存する。RTC capability、membership UPDATE、policy 変換、全関連 iBGP path を追う。RR では membership RIB と peer filter を残す。次に VPN 方向へ移り、source、RR Loc-RIB、対象 Adj-RIB-Out、受信 VPN RIB を比較する。

最後に VRF import、選択、label、next hop、FIB、双方向 packet を確認する。対象 destination は通り、許可外の canary は方針どおり非開示または非到達でなければならない。withdraw、RR migration、software upgrade でも同じ証拠鎖を再現する。

情報源