RSVP-TE トンネルは稼働中、しかし顧客の L3VPN に経路がない

転送とサービスは別々の判断です。ラベルスタックを読み、ネクストホップ解決と VRF 接続を切り分けて確認し、最後に実際の顧客フローを一つ試します。

顧客が VPN の停止を報告し、転送チームがトンネルは正常だと報告するとき、両チームとも正しいことがあります。トラフィックエンジニアリングされた LSP と MPLS L3VPN は、一方がラベル付きパケットをコア全体で運び、もう一方がパケットの属するルーティングコンテキストを決めるという、別の問いに答えます。両者が混同されると、それぞれが別の対象を測定しており、どちらの測定も妥当なので、議論は堂々巡りになります。

転送が正常でサービスが停止しているのは平常状態

LSP が確立し、トラフィックを運び、あらゆる監視システムに見えていても、顧客サービスが使えないままであることはあります。この組み合わせに矛盾はないのは、トンネルが、遠隔プレフィックスが存在するか、インポートポリシーがそれを受け入れたか、接続回線がフレームを通しているかについて何の意見も持たないからです。

混乱を通常露呈させる兆候は、PE のループバックからの ping は成功するのに顧客 LAN のホストは何も受け取らない、あるいはその逆という非対称なものです。理論を組み立てる前に、どのアドレスが機能したかを書き留めてください。自分が二つの異なる対象を試していると気づいたら、次の一歩はどちらのグラフが正しいかを論じることではなく、ラベルスタックを読むことです。二つのアドレス、二人の所有者、そして通常は互いに相手が何かを壊したと信じる二人の別人です。

スタックを二つの責務として読む

下のラベルはサービスに属し、上のラベルは経路に属します。RFC 4364 はその順序を簡潔に説明していて、まず VPN 経路のラベルが押し込まれ、次にそのラベル付きパケットが BGP のネクストホップに向けてトンネルされ、そこでトラフィックエンジニアリングのトンネルが自分のラベルを上に載せます。

ObjectDecision it encodesWho owns it
Attachment and VRFWhich customer context receives the arriving packetEdge configuration
VPN route and service labelWhich remote forwarding context handles the destinationBGP VPN signalling
Transport LSP and tunnel labelHow the core carries the packet to the BGP next hopRSVP-TE or another tunnel mechanism

遠端の PE では、サービスのラベルが VRF 検索や接続の判断といった扱いを選びます。そのラベルはコアを通過するだけのラベルに置き換えることはできず、同じインターフェース上の同じスタックに両方が現れる場合でも、両者は交換可能ではありません。

RSVP の成功が証明することとしないこと

RSVP-TE は、リソース予約の有無にかかわらず、明示的にルーティングされた LSP を確立します。これはパケットがコアを通る経路についての具体的で有用な保証であり、それは顧客経路についての表明ではなく、設定されたトンネル名は経路ですらないのです。

RSVP の存在も、エンドツーエンドの性能を約束するものではありません。一つの LSP 上の帯域予約は、接続回線、顧客自身のアクセスライン、遠端でのキューイング動作について何も語りません。それを保証として扱うと、誰も尋ねていない問いに対して自信満々の答えが生まれます。要件が本当に帯域の確約であるなら、それを実際に強制する部品から組み立てる必要があり、LSP はその連鎖の中央にすぎません。

順に確認し、そこで止める

転送から外側へと作業し、最初に失敗した手順で止めてください、後の手順はすべて前の手順が保たれたことを前提としています。まず、LSP が確立していることと、サービスプレフィックスの転送エントリが実際にそれを指していることを確認します。次に、VPN 経路が正しいテーブルに存在し、そのラベルバインディングがあり、インポートポリシーがそれを受け入れたことを確認します。次に、インターフェース、カプセル化、そして該当する場合はその契約に属する VLAN 識別子という接続を確認します。

show mpls lsp
show mpls forwarding-table 10.60.0.0 24
show bgp vpnv4 unicast vrf CUSTOMER 10.60.0.0/24
show ip vrf detail CUSTOMER

コマンド構文はプラットフォームによって異なるので、その四行はスクリプトではなく四つの問いとして扱ってください。重要なのは、それぞれが異なる対象に問い合わせているという点であり、だからこそ障害は特定の所有者を指し示します。

許可された要求を一つ追跡し、良い証拠を残す

ポリシーで許可された実際の顧客要求を一つと、その応答で締めくくってください。エンドツーエンドで機能する一つのフローは、一ページのカウンタ値よりも多くを決着させ、各部分を個別ではなく組み合わせを試します。

後の段階が失敗したときは、転送を再構築するのではなく、成功した LSP の観測を保存してください。動作するトンネルを再構築しても、存在しない遠隔プレフィックス、誤った VRF 接続、宛先アクセスルールを修復することはできず、そもそも転送が健全だと教えてくれた証拠を破壊してしまいます。

関連記事