MPLS L3VPN ラボで ping が通らない？確認すべき五つのチェックポイント

顧客ルーターが二台、プロバイダーエッジの筐体が一対、そしてエラーメッセージも出さずに消える ping がある。小規模な MPLS L3VPN ラボでは、障害はほぼ必ず五つのチェックポイントのどれかにあり、それぞれに依存関係が機能しているか欠けているかを示すコマンドがある。間違いは、ping が失敗するたびに BGP を再起動することで、依存関係を順番に試さないことだ。いきなり VRF の設定へ飛び込むと、二台先の未解決のネクストホップから始まった問題に一時間を費やすことになる。

リストは下から上へたどる。合格したチェックポイントは合格のままで、最初の失敗こそがデバッグする価値のある箇所だ。

チェックポイント一：PE 同士が到達できる

各 PE は相手 PE のループバックへの経路を必要とし、その経路は実在する何かを通じて解決されなければならない。通常は内部ゲートウェイプロトコルで到達するが、再帰ルックアップが生きた隣接に着地する限りスタティックルートでも機能する。IOS 系の機器では、show ip route 10.0.0.2 に続けて show ip cef 10.0.0.2 を実行すると、プレフィックスが存在するか、解決済みの隣接を持つかがわかる。隣接を伴わないテーブル上の経路は到達性ではない。

両方向を確認する。非対称な IGP コスト、誤った側のパッシブインターフェース、ループバックをフィルタする分布リストは、いずれも片方向だけを壊し、片方向だけでセッションは落ちる。ループバックに ping が通るのに BGP セッションが Active のままであれば、他に触る前にアップデートソースを見る。

チェックポイント二：ラベルパスが存在する

遠隔ループバックへの IP 経路は、トランスポートがラベルを押し付けることの証明にはならない。LDP 設計では、遠隔ループバックにローカルとリモートのバインディングがあり、出力ラベルが転送テーブルに現れていることを確認する。show mpls ldp bindings 10.0.0.2 32 はラベルの組を示し、show mpls forwarding-table 10.0.0.2 はラインカードが実際に何を挿入するかを示す。二つ目のコマンドが「no label」と表示したり IP へパントしたりするなら、トランスポートは設計が想定するようには VPN トラフィックを運んでいない。

この区別は、MPLS が転送状態を宛先プレフィックスから分離する方法に由来し、それはRFC 3031で説明されているモデルだ。ラボで LDP の代わりに RSVP-TE や BGP 隣接ラベルを使う場合は、その仕組み自体の状態を確認し、LDP がすべてのアンダーレイラベルを配布すると決めつけるのは幽霊バグを追いかけるよくある方法だと知っておく。壊れたラベルパスは通常、後になって存在するが使えない VPN 経路として現れる。

チェックポイント三：VPN 経路が無傷で届いた

セッションの要約ではなく、正確な顧客プレフィックスの VPNv4 または VPNv6 経路を見る。show bgp vpnv4 unicast all 10.10.1.0/24 はルートディスティングイッシャー、遠隔 PE ループバックに設定されたネクストホップ、そしてラベルを示すはずだ。プレフィックスが欠けていれば、発信側 PE のエクスポートポリシーか受信側 PE のインポートポリシーが第一の容疑者で、route target がいつもの犯人だ。

route target の確認は BGP での受信とは別に読む。経路が正しいネクストホップで届いても、import target が一致しなければ VRF に入らないことがある。受信側 PE では show ip route vrf CUSTOMER 10.10.1.0 が意味のあるテストであり、BGP テーブルは経路がコントロールプレーンを越えたことしか証明しない。

チェックポイント四：インターフェースが VRF に入っている

ルートディスティングイッシャーと route target を伴う VRF 定義は、どのインターフェースもその中へ移さない。CE 側のインターフェースには VRF の割り当てが必要で、show ip vrf interfaces か show ip interface brief が正しいインスタンスの下にそれを一覧表示するはずだ。ここはコピーした設定が最もよく間違えるチェックポイントで、VRF ブロックは完全に見えるのにインターフェースはグローバルテーブルに残っている。

次に、PE がローカルの顧客プレフィックスをその VRF に学習したこと、そして CE が接続を通じて戻る経路を持つことを確認する。CE 上のスタティックデフォルトが PE を指していれば、PE の VRF に CE の LAN への経路がある限り、ラボには十分だ。どちらか半分が欠けていれば、ラベルが押される前に ping は失敗する。

チェックポイント五：応答が帰り道を見つける

両者が異なるテーブルを使うため、転送パケットを追跡し、次に戻りパケットを追跡する。入口 PE では、顧客の送信元が VRF 内で遠隔ラベル付きの遠隔プレフィックスに解決されるべきだ。出口 PE では、宛先が同じ VRF 内で CE 側インターフェースに解決されるべきだ。PE 自身から送った ping は証拠にならず、グローバルテーブルや別の送信元アドレスから出ることがあるため、ping vrf CUSTOMER 10.10.2.10 source 10.10.1.1 が実行すべきテストとなる。

ホストのファイアウォール、逆経路フィルタリング、CE のアクセスリストは依然として効く。転送経路が機能して応答が消えるなら、問題は戻り側の経路かフィルターであり、MPLS トランスポートではない。

チェックポイントごとに、最初に失敗した依存関係を記した一行の記録を残す。その記録は「顧客が ping できない」を、到達性、ラベル状態、経路のインポート、インターフェースの所属、戻り経路についての具体的な問いに変え、次のデバッグが同じ五つのコマンドを同じ順序で繰り返すのを防ぐ。