pseudowire エンドポイントで VLAN タグを正規化する：実運用の手順書

pseudowire に触る前に、各カスタマーエッジが受け取るべきフレームを定義します。単純なケースでは、CE A がサービスを区切るタグを 一つ送信し、CE B はタグなしフレームを期待し、その差はプロバイダーエッジで解消されます。タグはローカルポリシーであり顧客の Ethernet 契約の一部ではなく、pseudowire は元のフレームではなく合意したフレームを運びます。設定の前に両方向を書き留めてください。

まずフレーム契約を書く

順方向はタグを 一つ外し、逆方向はそれを戻します。片方だけ書くと、一方向でしか動かない経路を試験して回線を健全と判断してしまいます。

契約は変更チケットに貼れる長さに抑え、どのエッジがタグ付きで送り、どれがタグなしを期待し、どのタグ値がサービスを区切るのかを書きます。

pseudowire のモードを合意する

RFC 4448 は raw と tagged の 二つの pseudowire モードを区別し、サービスを区切るタグの扱いを説明しています。raw モードでも顧客フレームに属するタグは運べるため、違いはタグのサービス上の役割にあり、802.1Q ヘッダーの有無だけではありません。モードを tagged か untagged かと読むことが、この作業の範囲を誤る最も一般的な原因です。必要な操作を決める前に、対向装置とモードを合意してください。

次に実際の pseudowire タイプと対向パラメーターを確認します。ローカル VLAN 接続と遠隔ポート接続にはサポートされたインターワーキング構成が必要で、ローカルの書き換え文が 二つあっても、広告された回線タイプが一致する証明にはなりません。

control word と MTU の想定が異なるなら、どの書き換えでも直せないネゴシエーションの問題です。どちらも設計書ではなく対向装置の稼働設定から確認してください。

ローカルのタグ操作を適用する

Juniper の VLAN CCC 書き換えガイド は、プラットフォーム固有の制約付きで pop、push、swap の操作を記録しています。互換性のあるタグ付きユニットが既に設定済みなら、例示の方向は入力側が input-vlan-map pop、出力側が output-vlan-map push です。これらの行は操作の例示であり、完全なインターフェースや回線の設定ではありません。一つの機器ファミリーの例をどこにでも当てはめるのではなく、正確なプラットフォームとリリースを確認してください。

ユニットがサポートする VLAN とカプセル化の設定が、意図したタグと分類を定義する必要は依然としてあります。誤ったフレームを分類するユニットに書き換え文を置いても、問題は解決せず移動するだけです。

サービスが必要とする内側の顧客タグは保持します。タグが積み重なる場合は、何かを外す前にどの外側タグを操作しているかを確定してください。

タグだけでなくサイズを見積もる

保持するタグ、実際の MPLS スタック、control word をサイズ予算に含めます。RFC 8469 はイーサネット pseudowire に control word を推奨しており、この推奨はプラットフォームが既定で有効にするかどうかに関わらずフレーム予算を変えます。MTU の不一致は警告を抑止して済ませるのではなく整合させてください。抑止された警告は、日付を削られた計画停止です。

片側がタグを追加し、もう片側が control word を追加するだけで以前は正常だったペイロードが壊れるため、同じ予算を両方のプロバイダーエッジで確認します。

数値が合わないなら、ログレベルではなく計画を変えてください。

フレーム単位で受け入れる

受け入れでは、各カスタマー接続点で期待されるフレームを両方向で検査し、そのうえで、承認された試験計画に従い、サービスが実際に必要とするアプリケーションと制御のトラフィックを流してください。ping が証明できることは、タグ付きフレームが無傷で届くことに比べてはるかに少ないからです。入力と出力のフレーム契約を回線の設定と一緒に記録します。次の変更をレビュー可能にするのはこの記録です。

モード、タグ操作、MTU 予算、試験結果を一か所にまとめます。これらは揃って初めて意味を持つので、三つのチケットに分けると次の技術者が同じ制約を再発見することになります。

回線が完了するのは、最初の方向が通ったときではなく、両方向が冒頭に書いた契約と一致したときです。