【入門編】 pingにおけるパケットサイズ(Payload)の調整とMTU・断片化(Fragmentation)の検証 – トラブルシューティング＆ネットワーク運用監視実践ガイド

皆さん、こんにちは！NOC（ネットワークオペレーションセンター）で日々、張り巡らせたケーブルとパケットの奔流に向き合っているシニアエンジニアです。数え切れないほどの障害現場を乗り越えてきましたが、夜中に突然「ある特定サイトだけ繋がらない！」「大きなデータを送ると途中でプツッと切れる！」という連絡を受けると、今でもアドレナリンがグッと湧き上がってきます。

ネットワークの世界は、目に見えないだけに難しく感じてしまいますよね。「一歩ずつ理解していきましょう！」ということで、今回はインフラエンジニアなら誰もが必ずお世話になる ping コマンド、そしてその奥にある「パケットサイズ」と「MTU（最大伝送単位）」の切っても切れない関係について、現場の生きた知見を交えながら分かりやすく紐解いていきたいと思います。

—

1. 巨大な荷物を送るとき、なぜ「切っちゃダメ！」と叫ぶのか？

いきなりですが、インターネットの世界を「郵便配達」に例えてみましょう。

私たちが普段使っているパソコンやサーバーは、データを小さなダンボール箱（パケット）に詰めて相手に送っています。このダンボール箱には、一度に運べる最大の大きさ（サイズ）が決まっています。これがネットワークの世界でいう MTU（Maximum Transmission Unit） です。一般的なインターネットの道（イーサネット）では、この制限がだいたい 1500バイト に設定されています。

ここで想像してみてください。
「2000バイト ある超特大の荷物」を、制限が 1500バイト の道に無理やり流そうとしたらどうなるでしょうか？

通常の優しい郵便屋さん（ルーター）なら、「おや、この荷物は大きすぎるから、中身を2つに分割して、それぞれ別の箱に詰め替えて届けよう」と親切に作業してくれます。これがネットワークの世界でいう「断片化（フラグメンテーション）」です。

しかし、現場のシニアエンジニアとして声を大にして言いたいのですが、この「荷物の詰め替え作業」は、ルーターにとってものすごく重労働なのです。ルーターがパケットを細かく切り刻んでいる間に、処理が追いつかなくなったり、宛先で上手に元通りに組み立てられなくて荷物（パケット）が迷子になったりするトラブルが後を絶ちません。

だからこそ、最近のセキュアでモダンなネットワークでは、発信元にあらかじめ「いいか、この荷物は絶対に途中で切断（断片化）するなよ！」という厳命のハンコを押させて送ることが一般的です。これが、今回主役となる DFフラグ（Don’t Fragment：断片化禁止フラグ） です。

—

2. 現場で大活躍！ping で経路の限界サイズを暴く

「自分のサーバーから宛先まで、途中で断片化されずに通る最大のパケットサイズはいくつだろう？」
これを調べるために、私たちはよく ping コマンドの力を借ります。

Linux環境であれば、ping コマンドに -M do（DFフラグを立てる＝断片化禁止）と -s（送信パケットのサイズ指定）のオプションを組み合わせて実行します。

実際に、GoogleのパブリックDNS（8.8.8.8）に向けて、少しずつサイズを変えながらテストしてみましょう。

# 【検証1】標準的なサイズ（1400バイト）でパケットを飛ばしてみる
# -M do: 途中で断片化することを禁止（DFフラグON）
# -s 1400: ペイロード（中身のデータ）のサイズを1400バイトに指定
ping -c 3 -M do -s 1400 8.8.8.8

このコマンドを実行すると、次のような応答が返ってくるはずです。

PING 8.8.8.8 (8.8.8.8) 1400(1428) bytes of data.
1408 bytes from 8.8.8.8: icmp_seq=1 ttl=116 time=12.5 ms
1408 bytes from 8.8.8.8: icmp_seq=2 ttl=116 time=11.8 ms
1408 bytes from 8.8.8.8: icmp_seq=3 ttl=116 time=11.9 ms

--- 8.8.8.8 ping statistics ---
3 packets transmissions, transmissions, 3 received, %0 packet loss

おっ、無事に全部返ってきましたね！「このサイズなら、途中で誰にも文句を言われずにスイスイ届けられたよ」ということです。

ここで注意してほしいのが、ping コマンドの -s オプションで指定するのは「ICMPヘッダーを含まない純粋なデータ部分（ペイロード）のサイズ」だという点です。実際にネットワークを流れるときは、これにIPヘッダー（通常20バイト）とICMPヘッダー（8バイト）が合計28バイト追加されます。そのため、出力結果の最初に 1400(1428) bytes と親切にトータルサイズが表示されます。

—

3. 「Message too long」に隠された真実

では、今度はわざと限界を突破するような巨大な荷物を送ってみましょう。

# 【検証2】大きすぎるサイズ（1500バイト）を指定してパケットを飛ばしてみる
ping -c 3 -M do -s 1500 8.8.8.8

実行すると、先ほどとは打って変わって、次のような冷たいエラーメッセージが返ってきます。

PING 8.8.8.8 (8.8.8.8) 1500(1528) bytes of data.
ping: local error: message too long, mtu=1500

あるいは、経路上にある古いルーターなどから、次のようなICMPの悲鳴が聞こえてくることもあります。
Frag needed and DF set（断片化が必要だけど、DFフラグが立っているから進めないよ！）

このエラーこそが、トラブルシューティングにおける最大の黄金の手がかりです。
「あ、我が家の出口、あるいは経路のどこかに 1500バイト の壁があるんだな」と、一発で直感することができるのです。

—

4. 実務でよくある「特定のサイトだけ表示されない」怪奇現象の正体

NOCにいると、「会社の回線から、特定のクラウドサービスやストレージにファイルをアップロードしようとすると、なぜか途中でフリーズしてタイムアウトする」という相談を本当によく受けます。

大体の原因は、次のようなケースです。
1. 自社の回線やVPNトンネル（PPPoEやIPsecなど）の仕組み上、途中のMTUが少し削られて 1450バイト や 1300バイト になっている。
2. しかし、サーバー側は「うちは 1500バイト で送る気満々」で大きなデータを送り出す。
3. 経路上にあるルーターが「おっと、この荷物は大きすぎて通せないぞ」と気づく。本来ならルーターが「もっと小さいサイズで送ってね」と優しく教え返してあげる（これを ICMP Destination Unreachable の一種、経路MTU発見通知と呼びます）はずが……。
4. セキュリティ上の理由（ファイアウォールの設定ミスなど）で、その「おせっかいなアドバイス（ICMPパケット）」が途中でブロックされてしまっている！

結果として、発信元のサーバーは相手が受け取っているのかどうかも分からず、ただひたすら巨大なパケットを送り続け、通信が完全にデッドロック（膠着状態）に陥ってしまうわけです。現場ではこれを「黒洞（ブラックホール）MTU問題」と呼んでいます。

もし皆さんの現場で「巨大なファイル転送だけが失敗する」「Webサイトの一部（画像やフォームなど）が読み込み途中で止まる」という現象に直面したら、ぜひ疑ってみてください。

—

5. まとめ：トラブルシューティングの引き出しを増やそう

今回は、ping を使ったパケットサイズの調整と、MTU・断片化の裏側についてお話しました。

ネットワークの荷物（パケット）にはサイズ制限（MTU）がある。
ルーターに負担をかける断片化を防ぐために DFフラグ が使われる。
ping の -M do と -s オプションを組み合わせることで、経路の限界サイズを自分でテストできる。
「message too long」や通信のフリーズに遭遇したら、MTUのミスマッチやICMPのブロックを疑う。

ネットワークのトラブルシューティングは、見えないパケットの動きを頭の中でどれだけリアルに想像できるかが勝負の分かれ道です。「今、自分のパケットがどのルーターで引っかかっているんだろう？」そんな風に想像しながら、ぜひお手元の端末で ping を叩いてみてくださいね。

それでは、次のNOCレポートでお会いしましょう！快適なネットワークライフを！