MPLSの疑似回線ではMTUの「三十バイト追加」ルールが崩れる

MPLSのためにいくつ足せばよいかと技術者に尋ねると、たいてい三十という数字が自信たっぷりに返ってくる。その数字が間違っているというより、根拠から切り離されている。何を起点に数えるのか、プロバイダーのエッジが実際に何を送るのかに完全に依存する。Ethernet疑似回線では前提が見える形になり、書き出した瞬間に算術が言い伝えに取って代わる。

一つの名前の下で三つの異なるものが測られている。顧客のIPパケット、疑似回線を越えて運ばれるEthernetフレーム、そしてプロバイダー自身の外側リンクのフレーミングだ。これらを混ぜた予算は、どのデバイスフィールドも期待しない値を生む。

すべての前提を明示した一つの計算例

顧客の1500バイトのIPパケット、顧客FCSなしで疑似回線を越えて運ばれる通常のEthernetヘッダー、保持されないVLANタグ、二つのエントリのラベルスタック、四バイトの制御ワードを取る。運ばれるEthernetヘッダーが14を加え、保持されたタグは何も加えず、二つのラベルエントリは各エントリが4バイトなので8を加え、制御ワードが4を加える。これでMPLSカプセル化パケットは1526バイトになる。

結果を注意深く読む。これはプロバイダーリンクの外側EthernetヘッダーとそのFCSを除外しており、MTUという名のどのフィールドにも入力する定数ではなく一例である。二つのラベルも前提だ。実際のスタックはトランスポートラベル、サービスラベル、時にはそれ以上を運ぶことがあり、各エントリは同じ4バイトを要する。

疑似回線を実際に越えるもの

RFC 4448はEthernetフレームがMPLS内部をどう移動するかを定義しており、その通常モデルでは顧客のプリアンブルとFCSが入口で取り除かれ出口で再生成される。だから上の予算にFCSは現れない。VLANの扱いはサービスモードによる。顧客タグを保持するモードはそのバイトを加算し、マッピングするモードは加算しない。追加の保持や追加のカプセル化はその上に数える必要がある。

制御ワードは使われるたびに算術の一部になる。RFC 8469はEthernet疑似回線にこれを推奨しているので、任意だと書いた古い文書は、あなたの経路がそれを省いている証拠にはならない。図から推測せず、実際のサービスモードをプロバイダーに確認すること。

数値を正しいフィールドと比較する

次に、必要なカプセル化サイズを関係する各リンクの隣に、そして設定する上限のベンダー定義の隣に置く。IPパケットを表すフィールドもあれば、フレームや別のカプセル化境界を表すフィールドもある。二つの数値は同じに見えても異なる容量を表すことがあり、適合して見える設定が本番でドロップを生むのはそのためだ。

無関係なプラットフォーム間で値をコピーするのが危険なのも同じ理由だ。フィールド名こそが仕様であり、別のベンダーのコンソールで覚えた十進数ではない。

pingのペイロードはMTU値ではない

IPv4のpingペイロードはIP MTUではない。IPヘッダーとICMPヘッダーもバイトを消費するので、成功するペイロードサイズは回線上のはるかに大きいパケットに対応する。あるサイズで通るプローブは、別のVLANモードやより深いラベルスタックを使うサービスについては何も語らない。テストが測るのは一つの経路、一つのサイズ、一つのペイロード形状であり、サービスはその三つすべてを変えうる。

さらに悪いことに、実際のトラフィックが決して使わない経路とサイズをプローブが試したために、大きなフレームが失敗する一方でpingは成功することがある。到達性に関する一つのデータ点として扱い、レイヤー2サービスの仕様として扱わないこと。

フレームが収まらないとき

大きすぎるフレームを運べず、対応するフラグメンテーションや再組み立ての仕組みがない場合、それらは破棄され、通常は両端に明確なエラーも出ない。するとアプリケーションは一括転送でタイムアウトを示す一方、対話的なセッションは健全なままで、人々はバイト数を数える代わりにファイアウォールやルートを見に行く。

実際の予算をプロバイダーと確定する。サービスモード、タグの扱い、ラベルの深さ、制御ワード、そしてデバイスが適用する正確な上限だ。前提を数値の隣に書き残すこと。さもなければ次の技術者が三十バイトのルールと謎を引き継ぐ。