Junos L2VPN：顧客の接続契約を先に正しく決める

pseudowire に触れる前に、顧客のフレームを一つ PE の中まで追いかけ、どこに着地すべきかを見る。物理ポートはそれを論理ユニットに分類し、そのユニットがカプセル化を担い、ユニットはサービスに結合されている。三つの別々の判断、三つの別々の誤り方。シグナリング障害としてエスカレーションされる事例の多くは、実はそのサービスのために誰も設定していないユニットに分類されたフレームだ。だから接続から始めて外へ向かう。

フレームの契約を書き留める

設定を選ぶ前に契約を記録する。タグなし、サービス用タグ一つ、スタックのいずれかであり、顧客が送る MTU と各方向で期待するタグの扱いも加える。これらはローカルの好みではなく交渉で決まる性質だからだ。ユニット番号は識別子にすぎず、インターフェースがどのフレームを受け入れるかは何も語らない。

これはチケットのコメントではなくサービスノートに書く。半年後にこれをデバッグする人はノートを読む。チケットは読まない。

カプセル化を契約に合わせる

単一タグのサービスは通常 VLAN 回路のカプセル化を使う。たとえば vlan-ccc であり、タグなしのフレームには素の Ethernet 回路形式が、スタックには二つのタグを理解する拡張形式が要る。ユニット単位のサービスカプセル化に対応したプラットフォームでは、一つの物理インターフェースが複数を同時に収容できる。便利であると同時に、フレームが誤ったユニットに入る経路でもある。プラットフォームのガイドが family ccc を求める場合は、ルーティングインターフェースに後付けするのではなく、接続全体の一部として設定する。カプセル化ガイド は、どの接続種別がどの要件を課すかを一覧にしている。

念のためという理由で、すべてのインターフェースに family 文を足してはいけない。一つの回路を動かす設定が、次の回路に顧客が決して送らないフレームを受け入れさせることがある。

接続を正しいサービスに結合する

BGP でシグナリングするレイヤー2 VPN、LDP でシグナリングする回路、その他の対応サービスは、それぞれ独自のインターフェース結合とシグナリングの設定を持ち、互換ではない。一方の接続方式をもう一方のシグナリングと混ぜると、ピアを報告するだけでフレームを運ばない回路になる。

近い側だけでなく遠い側と突き合わせて比べる：ピアアドレス、サービス識別子、カプセル化の合意、control word の期待、サイズの予算だ。MPLS の下位層が完全に健全でも、接続が欠けていたり別の場所に分類されていたりする。だから下位層だけを見る試験はここでは何も証明しない。

状態ではなくフレームで確認する

顧客がトラフィックを送っている間にローカルインターフェースのカウンタを読み、次にサービスの状態を読み、そのうえで到着するフレームが合意したフレームそのものか、タグまで含めて確かめる。修理された接続はそのフレームを届ける。状態の変化だけでは何の証拠にもならない。

取得が許可されている場所では、フレームを両方向で見る。タグの非対称は状態表示では見落としやすく、取得では明らかだ。その非対称は、片方向だけ通って逆方向で失敗するという苦情も説明する。

そして書き留める

サービスノートに四つの値を記録する。契約、カプセル化、ユニット、サービス結合だ。新しい技術者に必要なのはこの四つであり、設定レビューが明示することはほとんどない。

半年後に回路が壊れたとき、そのノートが十五分で直るか、動いている設定から設計全体を導き直すかの差になる。最後に確認した日付も添えれば、ノートがどれだけ古いかも分かる。