こんにちは！ネットワークの深淵を愛するインフラエンジニアの皆さん、そしてこれからネットワークの世界へ足を踏み入れる初学者の皆さん。日々のインフラ構築や運用、本当にお疲れ様です。
私たちが普段何気なく使っているインターネットや社内ネットワーク。YouTubeの動画がサクサク見られたり、大きなファイルを一瞬でダウンロードできたりするのは、目に見えないところで膨大なデータが「小包」のように綺麗に小さく分割され、目的地へと駆け抜けているからです。
しかし、現場のネットワークエンジニアを長年悩ませ続ける「ある悪夢」が存在します。それが今回取り上げる「MTUミスマッチとDFビット（フラグメンテーション）の罠」です。
「通信がなぜか途中で止まる」「Webサイトのログイン画面だけが真っ白になって進まない」――そんな泥臭いトラブルに直面したとき、この仕組みを知っているかどうかでエンジニアとしての生存率が大きく変わります。難解なパケットの構造はちょっと横に置いて、まずは身近な「郵便配達」の世界から一歩ずつ紐解いていきましょう！
—
1. 荷物と道路の制限：MTU（Maximum Transmission Unit）の基本
ネットワークでデータをやり取りするとき、データはそのままの巨大なかたまりで流れるわけではありません。必ず「パケット」という一定の大きさに切り分けられます。
この「1回に運べる荷物の最大の大きさ（重さ・サイズ）」のことを、ネットワークの世界では MTU（Maximum Transmission Unit） と呼びます。標準的なイーサネット（Ethernet）の道路では、このMTUのサイズは基本1,500バイトに設定されています。これは「1500バイトを超える大きな荷物は、この道路を通しちゃダメですよ」という、いわば道路の高さ制限のようなものです。
郵便配達に例えてみ軽やかにイメージしよう
想像してみてください。あなたは巨大な荷物を送ろうとしています。
もし郵便局（送信元）から宛先（宛先サーバー）までの間に、ずっと高さ制限1,500メートルのトンネル（L2スイッチやルーター）しかなければ、1,500メートル以下の荷物はスイスイ通過できますよね。
ところが、途中の経路に「高さ制限が1,400メートルしかない古い吊り橋（狭いMTUのネットワーク機器）」がこっそり混ざっていたらどうなるでしょうか？
当然、1,500メートルの荷物はその吊り橋をそのまま渡ることができません。この「道路ごとに運べる最大の大きさが違う（ミスマッチが起きる）」という状態こそが、すべてのドラマの始まりなのです。
—
2. 許されざるオーバーサイズ：フラグメンテーションとDFビットの衝突
途中の経路で自分の荷物よりも小さな制限（低いMTU）に出会ったとき、ルーターたちは通常、次のような親切（あるいは余計なお世話？）な行動に出ます。
「おや、この荷物は大きすぎてこの先の橋を渡れないな……よし、この荷物を包丁で真っ二つに切って、2つに分けてから向こう側に送ろう！」
この、途中で荷物を分割する作業を フラグメンテーション（断片化） と呼びます。分割された荷物は、宛先のコンピュータに届いたあとで、パズルのように元の1つの荷物に組み立て直されます。
でも、現場では「フラグメンテーション悪者説」が常識です
「途中で勝手に分割してくれるなら、親切でいいじゃない！」と思いますよね。しかし、ネットワークの現場では、フラグメンテーションはなるべく避けたい御法度とされています。なぜなら、ルーターという機器は「ただ猛スピードで荷物を右から左へ流す」特急仕分け人であり、わざわざ荷物を包丁で切ったり貼ったりする高度な工作作業をやらせると、もの凄いCPU負荷がかかってネットワーク全体のパフォーマンスがガクッと落ちてしまうからです。
ここに登場するのが「DFビット」という頑固な意思表示
そこで現代のネットワーク通信（特にTCPなど）では、荷物の伝票にこうスタンプを押して発送します。
「DF（Don’t Fragment = 分割するな！）ビット：ON」
この「DFビット」が立った荷物を受け取ったルーターは、次のように頭を抱えます。
- ルーター心の声：「うわ、この荷物、先の橋（MTU）より大きくて通せない……。でも、送り主から『絶対に包丁で切るな（DF=1）』って厳命されているぞ。勝手に切ったら怒られる！」
結果として、このルーターはどうするか？
優しく分割するのを諦め、その荷物を冷酷にゴミ箱へポイッと捨ててしまいます（パケット破棄）。これが、MTUミスマッチによる通信不良の正体です。
—
3. 「おっと、大きすぎますよ！」ルーターからの悲鳴：ICMPとPMTUD
荷物を捨てられた送信元のパソコンは、このままだと「荷物が届いたのかな？」と永遠に返事を待ち続けてしまいます。これでは困るので、意地悪をした途中のルーターは、送信元に向けてこんなお手紙を送り返してあげます。
- ルーター：「あー、さっき送ってくれた荷物、うちの先の橋（MTU 1400）より大きかったから捨てちゃったよ！ 次はもっと小さく（1400以下で）して送ってね！」
このお叱りのお手紙こそが、ネットワークの診断でよく見る ICMP Destination Unreachable (Type 3, Code 4: Fragmentation Needed and DF Set) です。
このお手紙を受け取った送信元のパソコンは、「なるほど、この先のルートは1,400が限界なんだな」と学習します。そして、次に送る荷物のサイズを自ら小さく調整して再挑戦します。この仕組みを PMTUD（Path MTU Discovery：経路MTU探索） と呼びます。
—
4. 現場の落とし穴：「ブラックホールルーター問題」
「おっ、ICMPのお手紙を貰えば自動でサイズを小さくできるなら安心だね！」……そう思ったそこのあなた、実はここに大きな落とし穴があります。
世の中のセキュリティ設定（ファイアウォールのポリシーなど）の中には、「セキュリティ対策として、ルーターからのICMPメッセージ（お叱りのお手紙）はすべて一律でブロック（破棄）するぞ！」という厳しい環境がゴロゴロ存在します。
こうなるとどうなるでしょうか？
1. 送信元の荷物は途中のルーターで捨てられる。
2. ルーターは「大きすぎますよ」とお手紙（ICMP）を送る。
3. しかし、そのお手紙は途中のファイアウォールに没収されて、送信元には絶対に届かない。
4. 送信元は「お手紙が来ないから、きっと荷物は無事に届いたんだな」と思い込み、再び同じ巨大な荷物を送り続けて、また捨てられる。
通信が完全にフリーズ（ブラックホール化）してしまうこの現象こそ、インフラエンジニアを夜な夜な悩ませる「PMTUDブラックホール問題」です。VPNトンネル（IPsecやGREなど、ヘッダーの分だけ余計にパケットが大きくなる技術）を導入した直後に、なぜか特定のWebサイトだけが見られなくなるトラブルの多くは、これが原因で発生します。
—
5. 実務での対策：ネットワーク構築・設定のアプローチ
では、この厄介なMTUミスマッチやDFビットの問題に、現場のエンジニアはどのように立ち向かえばよいのでしょうか？ 実務で即座に使える設定やアプローチを見ていきましょう。
アプローチA：ルーターやL3スイッチでの「MSSクランプ」設定（一番お手軽で確実）
VPNやPPPoE回線などを経由する場合、通常のイーサネットMTU（1500）からカプセル化ヘッダーの分だけ利用できるサイズが小さくなります。ルーターの入り口で、TCPの最大セグメントサイズ（MSS）を強制的に書き換えることで、そもそも大きすぎるパケットが生成されるのを防ぐのが最もポピュラーな対策です。
CiscoルーターやCisco Catalyst（L3スイッチ）での設定例を見てみましょう。
# インターフェースコンフィギュレーションモードに入ります
interface GigabitEthernet0/0
ip address 192.168.1.1 255.255.255.0
# TCPセグメントの最大サイズ（MSS）を、PMTUDに頼らず強制的に1360バイトに制限します
# （PPPoEや各種VPNトンネルを考慮した安全な値の例です）
ip tcp adjust-mss 1360- 日本語解説:
ip tcp adjust-mss コマンドは、TCPの三方向ハンドシェイク（SYNパケット）が通過する際に、その中にある「私、これだけのサイズを受け取れます」というMSSの値をルーターが勝手に書き換えて小さくしてくれる魔術のような設定です。これにより、送信元は最初から小さなパケットしか作らなくなるため、途中でDFビットに阻まれて破棄される悲劇を根本から防ぐことができます。
アプローチB：ホストOS側でのMTU固定・確認（Linuxの例）
サーバー自身や仮想マシン（VM）のネットワークインターフェースで、適切なMTUが正しく設定されているか確認・変更することも重要です。
# 現在のインターフェース（例: eth0）のMTUと状態を確認する
ip link show eth0
# 一時的にMTUを1400に変更する（実務では永続化設定が必要です）
sudo ip link set dev eth0 mtu 1400
# 実際にDFビットを立てた状態で、パケットが通る限界の大きさをテストする（pingコマンドの例）
# -M do は「DFビットを立てろ」、-s はペイロードサイズを指定します
ping -M do -s 1372 8.8.8.8- 日本語解説:
Linuxの ping コマンドに -M do オプションを付与すると、まさに今回解説した「DFビットを立てた状態」でテストパケットを飛ばすことができます。もし指定したサイズが途中のMTUを超えていて、かつICMPが返ってこないブラックホール環境であれば、ping は「message too long」のまま沈黙します。これを利用して、経路の限界値を実測するトラブルシューティング手法は現場の必須テクニックです。
—
まとめ：見えないパケットの息づかいを感じよう
今回は、MTUミスマッチとDFビット、そしてフラグメンテーションが引き起こすネットワークのドラマを、郵便配達に例えながら紐解いてきました。
- MTU は道路の高さ制限。
- フラグメンテーション は途中の荷物の分割（できれば避けたい）。
- DFビット は「分割するな！」という頑なな意志。
- PMTUDとICMP は、ルーターからのお叱りのお手紙。
- これらが噛み合わないと、通信はブラックホールへ吸い込まれていく。
ネットワークのトラブルシューティングは、目の前に見えないパケットたちの「心の声」や「すれ違い」を、残されたログや挙動からいかにリアルに想像できるかが勝負の分かれ道です。
「あ、今の症状はもしかしてMTUミスマッチによるDFパケットの破棄じゃないか？」――そうピンと閃いた瞬間から、あなたの中のネットワークエンジニアとしての血が、より一層熱くたぎり始めるはずです。
それでは、また次回の深淵なるプロトコルの世界でお会いしましょう！ 安全で快適なネットワークライフを！
コメント