VRF で消えた経路：ローカル、VPNv4、転送テーブルのどれか
VRF に無い、VPNv4 に無い、CEF に未インストールというのは三つの別の障害です。ルートターゲットを編集する前に、テーブルを順番に読んでください。
顧客はルートターゲット変更後にプレフィックスが消えたと言うが、最初に送ってくるスクリーンショットはたいてい間違ったテーブルだ。三つの異なるテーブルは、プレフィックスが VRF の内側に存在するか、VPNv4 経路として広告されインポートされたか、転送エントリが実際にインストールされたかという三つの異なる問いに答える。順序を外して読むと、自信に満ちた誤った結論が出る。本手順はローカルのプレフィックスとリモートのプレフィックスを一つずつ三つのテーブルに順番に通し、最後にそれを始めた RT 変更のロールバック計画で締める。
プレフィックスと、それが属するテーブルを名指しする
何かを入力する前に、プレフィックスを二つ書き留める。一つは顧客サイトにローカルなもので、接続インターフェースや CE 広告から学習する。もう一つはリモートで、プロバイダーのバックボーンを越えて届くはずのものだ。両者は同じ VRF に別の道から入り、片方の障害はもう片方について何も語らない。
| Table | Question it answers | Command |
|---|---|---|
show ip vrf CUST-A | Which RTs are attached for import and export | Read the RT lists before anything else |
show ip route vrf CUST-A | Is the prefix present in this VRF at all | Local and imported routes both appear |
show ip bgp vpnv4 all | Was the NLRI advertised and retained | Keyed by route distinguisher |
show ip cef vrf CUST-A | Was a forwarding entry installed | Proves a usable path, not just a BGP entry |
二つの識別子の区別を保つこと。この種のチケットの混乱の大半はそこから来る。ルート識別子は VPNv4 の NLRI の一部であり、そうでなければ同一の顧客プレフィックスをバックボーン全体で一意にするために存在する。ルートターゲットは属性として運ばれる拡張コミュニティであり、インポートとエクスポートのポリシーはこれに照合する。それは識別子の別名ではないし、顧客のパケットに載ることもない。
ステップ 1：プレフィックスが VRF にあることを証明する
まずローカルの見え方、次にインポートを司る RT を見る。ローカルのプレフィックスがここに無ければ、上流の何も原因にはならない：
show ip route vrf CUST-A 172.21.4.0 255.255.255.0
show ip route vrf CUST-A | include 172.21.4.0
show ip vrf CUST-A接続済みやスタティックとして見えるプレフィックスはローカルで学習されたものであり、その存在はエクスポートされたかどうかを何も語らない。これがこの作業で最も多い誤読で、健全な VRF テーブルはローカル学習についての証拠にすぎない。エクスポート側は別の問いであり、隣接の見え方と付与されたエクスポートターゲットがそれに答える。
ここにいるうちに VRF の RT 一覧を確認する。意図したインポートターゲットが一覧に無ければ、下流のすべては無意味だ。あればあるで、リモート PE がエクスポートするものと違っていれば、パケットキャプチャを一つも開かずに障害を突き止めたことになる。
ステップ 2：VPNv4 テーブルとそのターゲットを読む
VPNv4 テーブルは、コントロールプレーンが実際に何を交換したかを示す。正しい識別子の下でリモートのプレフィックスを探し、次にそれに付いたコミュニティを見る：
show ip bgp vpnv4 all 10.60.9.0/24
show ip bgp vpnv4 all | include 10.60.9.0
show ip bgp vpnv4 vrf CUST-A neighbors 192.0.2.17 advertised-routes正しいルートターゲットを持ちながらローカルにインストールされていないエントリは、到達性ではなくインポートポリシーか経路選択を指す。VPNv4 テーブルにまったく現れないエントリは上流を指し、起点の PE がエクスポートしていないか、セッションがアドレスファミリーを運んでいない。
変更の最中に人を惑わせる第三の場合はある。一部のプラットフォームはルートターゲットのメンバーシップ情報を使って、どの VPN 経路を要求し保持するかを制限するので、あるフィルタ済みの見え方にリモート NLRI が無いことは広告がどこにも無い証拠にならない。経路が全体として撤回されたと結論する前に、フィルタしていないテーブルと隣接の広告経路を確認する。
ステップ 3：何かがインストールされラベル付けされたことを確かめる
BGP エントリは決定であって経路ではない。転送テーブルは、パケットに行き先があるかどうかを教える：
show ip cef vrf CUST-A 10.60.9.0/24
show mpls forwarding-table vrf CUST-A | include 10.60.9.0
show ip bgp vpnv4 vrf CUST-A隣接が解決し送信ラベルがある CEF エントリは、データプレーンのトラフィックが動くはずだという意味であり、残る症状はアプリケーションか VRF 内のフィルタリングに属する。次ホップが未解決の CEF エントリは、BGP が健全に見えてもラベルの経路が不完全だという意味であり、BGP テーブルのスクリーンショットが変更レビューを誤らせたのはまさにこの場合だ。
ローカル PE が課すラベルと、リモート PE が受け取るはずのラベルを比べる。二つの見え方の不一致はラベルの割り当てかセッションの問題であり、ルートターゲットを何度編集しても直らない。
宣言した範囲で RT 変更を戻す
障害がルートターゲットの編集から始まったなら、一つの意図的な手順として取り消し、どの範囲を変えるのかを言う。インポートターゲットを外すと、その VRF の内側で適格性が撤回される。バックボーンから VPNv4 広告が消えるわけではなく、一部のプラットフォームでは経路がテーブルに保持されたままになる。これは別の結果であり、利用者に見える影響はどちらを指すかで変わる。
configure terminal
vrf definition CUST-A
address-family ipv4
no route-target import 65000:410
end
clear ip bgp vpnv4 vrf CUST-A soft inセッションがすでにプレフィックスを保持しているなら内向きのソフト再構成で足りるが、業務時間中にプロバイダー向けセッションをハードリセットするのは他の誰かが決めることだ。Junos では同等の確認が VRF ごとのテーブルと VPN テーブルを直接読み、ロールバックはコマンド単位の取り消しではなく commit 時の戻しになるので、始める前に構成の差分を取っておく。
始めたのと同じ三つのコマンドを同じ順序で終え、その出力を時刻付きで記録する。RT が誤りで今は正しいと言うチケットは再利用できないが、プレフィックスが VRF にあり、VPNv4 にあり、CEF にインストールされていることを示すものは次の人が突き合わせられる証拠になる。最初の二つしか変わっていないなら、変更は終わっていない。