IP映像伝送のパケット断片化事故を防ぐ完全ガイド
深夜1時、翌朝の生放送に向けた4Kマルチカメラ中継のセットアップで、8台のカメラのうち3台だけが数十秒おきに一瞬コマ落ちする現象が出た。ケーブルを疑い、SFPトランシーバーを入れ替え、NICのファームウェアまで更新した。原因はどこにも見つからなかった――正確には、原因は「見えない場所」にあった。前日、転送速度を上げる目的でメディアサーバーのNICにジャンボフレームを設定していたのだが、その先にあるコアスイッチのトランクポートは初期設定の1500バイトのままだったのだ。
MTU(Maximum Transmission Unit)とは、1回のイーサネットフレームで運べるデータの上限のことだ。標準は1500バイト、これにイーサネットヘッダー14バイトとFCS(誤り検出符号)4バイトを足した1518バイトが、IEEE 802.3が定める標準フレームの上限になる。VLANタグ(IEEE 802.1Q)を1本付ければ1522バイトまで膨らむ。これに対して「ジャンボフレーム」と呼ばれる設定は、ペイロードを9000バイトまで拡張する。ただし9000という数値にIEEEの公式な規格は存在しない。1990年代後半、Internet2と米連邦政府系ネットワークの合同技術チームが実務上の合意値として採用し、それが業界標準として広まったものだ。SMPTE ST 2110-10は、この違いを数値で明確に規定している。標準UDPペイロードの上限は1460バイト(IPヘッダー20バイト+UDPヘッダー8バイト+RTPヘッダー12バイト、合計40バイトを1500バイトから差し引いた値)。ジャンボフレーム対応網向けの拡張ペイロードは8960バイト(同じ40バイトを9000バイトから差し引いた値)と定義されている(出典:SMPTE ST 2110-10:2017、Wes Simpson「SMPTE ST 2110-10: A Base to Build On」TV Technology、2017年11月15日)。
MTU設計のミスマッチは、二つの拠点間で郵便物の規格が違う状態に似ている。片方の郵便局は最大30センチの封筒までしか受け付けないのに、もう片方は50センチの封筒を平気で送り出す。届いた郵便物は、途中の窓口で強制的に切り分けられるか、あるいは規格外として黙って処分される。イーサネットの世界でこの「切り分け」に当たるのがIPフラグメンテーション(分割)であり、「黙って処分」に当たるのが、ジャンボフレーム非対応のスイッチが1518バイトを超えるフレームを警告なく破棄する挙動だ。どちらも、映像が動くその瞬間まで気づかれない。
対処法は存在する。ネットワーク内の全機器のMTU値を経路単位で揃え、フラグメンテーションが発生しない設計に落とし込む手法だ。特別な機材は要らない。必要なのは、NIC・スイッチ・ファイアウォール・VPNトンネルという4種類の機器それぞれについて、設定値を横断的に確認するという発想の転換だけだ。
この記事で手に入るのは次の4つだ。
- ジャンボフレームを導入すべき経路と、標準MTUのままにすべき経路を切り分ける判断基準
- スイッチ・NIC・ファイアウォール・VPNトンネルの設定値を一覧化して検証する具体的な手順
- フラグメンテーションが発生しているかどうかを、本番前に数値で確認する測定方法
- 拠点間中継やクラウド編集など、複数経路が混在する構成への設計の広げ方
標準フレームの上限は1518バイト(IEEE 802.3)、ST 2110の標準UDPペイロードは1460バイト。この2つの数字を知らないまま「とりあえずジャンボフレームを有効にする」と、経路の途中に1台でも1500バイトのままの機器が残っていれば、そこで静かに事故が起きる。その事故を未然に潰す具体的な手順を、このあと書く。
コメント