こんにちは！NOC（ネットワークオペレーションセンター）で日々、張り詰めた空気の中インフラの番人をしているシニアエンジニアです。数え切れないほどの通信障害や、夜中の緊急アラート対応をくぐり抜けてきました。
ネットワークの世界に飛び込んだばかりの頃は、見えないパケットの動きや、聞き慣れない専門用語の壁にぶつかって途方に暮れてしまいますよね。「一歩ずつ理解していきましょう！」ということで、今回は現場のトラブルシューティングでめちゃくちゃお世話になる「pingを使ったMTU（Maximum Transmission Unit）パス探索とDFフラグの制御」について、身近な例えを交えながらたっぷり解説していきますね。
—
1. そもそもMTUってなに？ 郵便配達に例えてみよう
ネットワークでデータをやり取りするとき、一度に送れる荷物の大きさには制限があります。この「1回で送れる荷物の最大の大きさ（重さやサイズ）」のことを、ネットワークの世界では MTU（Maximum Transmission Unit） と呼んでいます。
想像してみてください。あなたは今、ダンボール箱に荷物を詰めて、遠くの友達に送ろうとしています。
もし、運送会社（ネットワークの経路）のルールで「1箱あたり最大1,500グラムまで」と決まっていたとします。そこにあなたが「2,000グラム」のパンパンに詰まった巨大なダンボール箱を出したらどうなるでしょう？
窓口の係員さんはこう言うはずです。
「お客さん、この箱は大きすぎてうちのトラックに入らないので、2つにパッカーンと分割して送りますね」
これが、ネットワークでいう「パケットの断片化（フラグメンテーション）」です。
分割された荷物は、宛先のコンピュータに届いたあとで、元の1つの大きな箱に組み立て直されます。
分割が引き起こす「現場の悲劇」
一見、親切に分割して運んでくれるなら問題ないように思えますよね。でも、データ通信の世界では、この「途中での分割」はできるだけ避けたいのです。
なぜなら、
1. ルーターという交通整理役の機械が、わざわざ荷物をカッターで切り分けて包み直す作業（CPU負荷）が発生する。
2. 分割された荷物のうち、1つでも途中で紛失（パケットロス）すると、「全部の断片が揃わなかったから、最初から送り直して！」となり、通信全体のスピードがガクッと落ちてしまう。
私たちNOCのエンジニアが夜中に「通信が急に重くなったぞ」と調査すると、大抵この「途中での無駄な分割」が悪さをしていることが多いんです。
—
2. 「これ以上小さく分解するな！」を伝えるDFフラグ
「じゃあ、途中で勝手に分割されないようにするにはどうすればいいの？」という疑問が湧きますよね。
ここで登場するのが、IPヘッダー（荷物に貼り付ける送り状のようなもの）に書き込む「DF（Don’t Fragment＝分割禁止）フラグ」です。日本語にするなら、ダンボール箱の横に大きく書く「【取扱注意・絶対に分解するな！】」という赤字のスタンプのようなものです。
このDFフラグを「ピタッ」と立てて（有効にして）荷物を送り出すと、ネットワークの途中でサイズオーバーの壁にぶぶつかったとき、ルーターは次のような冷酷な判断を下します。
「おっ、この荷物には『絶対に分解するな（DF）』って書いてあるぞ。でも、この先の道路（回線）は狭くて通せない……。しかたない、荷物を壊して（破棄して）、送り主に『大きすぎます！』って手紙を突き返そう！」
この「大きすぎて通れなかったよ」と教えてくれるエラーメッセージの名前を、ICMP Destination Unreachable (Fragmentation Needed) と呼びます。現場では親しみを込めて「Fragmentation Needed（断片化が必要だが拒否された）」と呼ぶことが多いですね。
—
3. pingとDFフラグで「通れる限界のサイズ」を探る
さて、ここからが本番です。
「今、目の前の通信経路は、一体どこまでの大きさの荷物なら分割なし（DFフラグ付き）で通してくれるんだろう？」
これを調べるために、おなじみの ping コマンドを使います。
通常、ping は相手の生存確認に使われますが、実は「送る荷物のサイズを指定する機能」と「DFフラグを立てる機能」を持っています。
OSによってコマンドの書き方が少し違うので、実務でよく使う代表的なものを載せておきますね。
Windowsの場合
Windowsの ping では、-f オプションでDFフラグを立て、-l オプションでサイズを指定します。
# サイズ1472バイトのパケットに「分割禁止(DF)」のスタンプを押して送信する
ping 8.8.8.8 -f -l 1472macOS / Linuxの場合
MacやLinuxでは、-M do というオプションで「DFフラグを立てて、大きすぎたら破棄しろ（do not fragment）」と指示します。また、指定するサイズは「Windowsのサイズ ＋ 28バイト（IPヘッダーとICMPヘッダーの分）」になるのが少しややこしいポイントです。
# サイズ1500バイト（IPヘッダー等を含む総サイズ）でDFフラグを立てて送信する
ping -c 3 -M do -s 1472 8.8.8.8—
4. 実践！ 現場でのMTUパス探索シミュレーション
では、実際に私たちの頭の中で、あるいは手元の端末でこの探索を行ってみましょう。
ターゲットのサーバーに向かって、徐々にサイズを大きくしながら ping を打っていくイメージです。
ステップ1：余裕のサイズで送ってみる
ping 192.168.1.1 -f -l 1300結果: パケットの往復に成功しました。（スムーズに通過！）
ステップ2：もっと大きくしてみる
ping 192.168.1.1 -f -l 1472結果: パケットの往復に成功しました。（まだいける！）
ステップ3：限界を超えてみる
ping 192.168.1.1 -f -l 1473結果:
パケットを送信する必要がありますが、DF が設定されています。（または fragmentation needed and DF set）
おっ、ここでエラーが出ましたね！
「1473バイトだと、途中のルーターを通れなくて弾き返された」ということです。
最後に計算をしよう
今、弾き返されたデータ本体のサイズが 1473バイト でした。
ここに、ネットワークの基本ルールである「IPヘッダー（20バイト）」と「ICMPヘッダー（8バイト）」の合計 28バイト を足し算します。
1473バイト (データ) + 28バイト (ヘッダー) = 1501バイト
つまり、この経路の最大MTU（パスMTU）は 1501バイト……ではなく、一般的なイーサネットの規格に合わせて切り上げると 1500バイト であることが綺麗に導き出せました！
—
5. まとめとシニアエンジニアからのアドバイス
いかがでしたでしょうか？
「MTUパス探索」や「DFフラグ」という言葉を聞くと、なんだか分厚い教科書を開きたくなりますが、要するに「途中でバラバラに壊されない最大の荷物の大きさを、失敗を恐れずにテストしながら見つけ出すテクニック」なんです。
実務の現場では、VPNトンネル（IPsecやGREなど）を張った途端に「なぜか特定のWebサイトだけが表示されない」「大きなファイルのアップロードだけ途中で止まる」というトラブルに非常によく遭遇します。これらは大抵、トンネルのオーバーヘッド（追加のヘッダー）のせいで、本来のMTU1500バイトでは荷物が大きすぎて途中で路頭に迷っていることが原因です。
そんな時、今回紹介した ping によるDFフラグ制御を使ったパス探索を知っていれば、「あ、ここでパケットサイズが詰まっているな」と瞬時に当たりをつけられるようになります。
ネットワークのトラブルシューティングは、見えないパケットの挙動を自分の頭の中でいかにリアルに想像できるかが勝負です。ぜひ、ご自身のPCのコマンドプロンプトやターミナルを開いて、身近なサーバー宛てに試してみてくださいね。
それでは、また次回のNOC技術コラムでお会いしましょう！
コメント