Junos L2VPN がラベルを表示するのに何も転送しない理由

L2VPN 接続が Up、アタッチメントが up、しかしフレームが一つも通過しないという顧客報告が届きます。ステータスランプは正直であり、フレームは遠端で使える転送状態を持たないサービスに分類されています。BGP でシグナリングされるポイントツーポイント L2VPN では、最初の判断はルート検索ではなくアタッチメントに属します。顧客のフレームは論理インターフェースに到着し、そのインターフェースが接続を、ひいては遠端のサイトを特定します。その後のすべては、ピアが広告した内容から構築されたラベル転送状態です。

フレームはルート検索を行わない

シグナリングが状態を用意し、パケットごとの処理はすでに選択された接続に対するラベル検索です。したがってルートが無い理由を問うのは間違った質問であり、重要な二つの値、すなわちアタッチメントの接続とそれが使うサービスラベルを隠してしまいます。

これは労力の非対称性も説明します。設定レビューは何をインストールすべきだったかを示し、接続ビューは実際に何が導出されたかを示しますが、ラベルブロックの不一致に耐えるのは後者だけです。

二つのラベル、二つの向き

各 PE はローカルにラベルブロックを割り当て、そのベースとサイズを広告し、ピアはオフセットを加えて特定サイトのラベルを導出します。したがって割り当てはローカルに意味を持ち、二つの PE が同じサービスに対して異なるベースと異なるブロックサイズを使えます。何かを変える前に両端から接続を読んでください。ラベル一つ分小さく見積もられたブロックは、決してインストールされない接続とまったく同じに見えます。

show l2vpn connections instance CUST-A extensive

その出力では、内向きラベルはこの PE が割り当ててピアに使うよう伝えたものであり、外向きラベルはこの PE がプッシュするピアの割り当てです。二つを逆に読むのが典型的な誤りで、こちら側には決して現れないはずの値を探しに行くことになります。接続リファレンスには、サイト、ステータス、ブロック情報など、ラベルの隣のフィールドが記載されています。

ラベル検索が証明するもの

内向きの値が分かれば、ローカル検索はコマンド一つです。

show route label 160042

その出力にはネクストホップ付きの l2vpn エントリが表示されるはずで、ラベル操作はフレームが出る前にプッシュ、スワップ、ポップのどれが行われるかを示します。何も表示されなければ、接続が Up と表示されていてもサービス状態はインストールされておらず、不一致はトランスポートではなくシグナリングにあります。

フレームを一つ追う

アタッチメントにプッシュしたパケット一つは、どんな設定レビューよりも多くを決着させます。サービスラベルのルートは遠端の PE へ向かうトランスポート LSPを指すはずで、二つのラベルはピアが報告した値に対応するはずです。トランスポートが健全でサービスラベルが誤っている場合、フレームは正しいルーターに到達してそこで破棄されるため、遠端のカウンターは空に見え、近端のカウンターは忙しく見えます。

アタッチメントのカプセル化、制御ワードの設定、MTU は同時に確認してください（これらはホップごとの動作ではなく、ネゴシエーションされる性質だからです）。

サービスモデルを分けて考える

VPLS は MAC アドレスを学習し、EVPN はエンドポイントを広告しますが、ポイントツーポイント L2VPN はどちらも行わないため、同じ BGP と MPLS のインフラに乗っていてもフレーム選択の手順は互換ではありません。あるモデルのトラブルシューティング手順を別のモデルに持ち込むと、根拠のない自信に満ちた結論が生まれます。

経路が欠けている場合は、両方のピアの接続ステータス、アタッチメント、両方向のラベル、カプセル化、制御ワードの設定、MTU を記録してください。その記録は広告された内容と転送プレーンが実際に行うことを結びつけるものであり、それが唯一重要なつながりであり、次のエンジニアもそれを求めるでしょう。