【入門編】 ping実行時のデータペイロードとMTUサイズ超過・フラグメンテーション – トラブルシューティング&ネットワーク運用監視実践ガイド

ネットワークの「荷物」が弾き返される理由:MTUとDFフラグの深淵へ

ネットワークエンジニアの皆さま、こんにちは。データセンターの冷たい空調音をBGMに、日々パケットの迷宮をさまよっているシニアエンジニアです。

皆さんは、「なぜか特定のサイトだけ繋がらない」「大きなファイルを送ると途中で止まる」といった、いわゆる「MTU(Maximum Transmission Unit)問題」に遭遇したことはありますか?

実は、ネットワークの世界で起きるトラブルの多くは、私たちが送る「パケット」という名の荷物が、配送ルートの制限に引っかかって弾き返されているだけなのです。今日は、このパケットのサイズと、それを制御する「DFフラグ」という魔法のスイッチについて、現場の知見を交えてお話ししましょう。

—

1. 郵便物に例える「パケット」と「MTU」

ネットワークの通信は、郵便配達に例えると非常に分かりやすくなります。

私たちが送るデータは、小さな封筒に入れられて相手に届きます。この封筒のサイズには上限があり、それが MTU です。一般的なイーサネット環境では、この上限は 1500バイト と決まっています。

もし、あなたが 2000バイト の大きな荷物を送ろうとしたらどうなるでしょう?
本来なら、ルーターという名の郵便局が「あ、これ大きすぎるから2つに切り分けて運ぼう!」と気遣ってくれる機能があります。これを「フラグメンテーション(断片化)」と呼びます。

しかし、現代のネットワークでは「そんな切り分け作業はルーターに負荷がかかるからやめてくれ!」というルールが主流になっています。そこで登場するのが DFフラグ です。

—

2. DFフラグ=「絶対に切り分けるな!」という封印

DF とは Don't Fragment の略です。これをパケットに付与すると、ルーターに対して「どんなに大きくても、絶対に荷物を切り分けないで!もし通れないなら、その場でエラーを送り返して!」と命じることになります。

なぜわざわざそんな厳しい制限をかけるのでしょうか? それは、中途半端に切り分けられたデータがパッチワークのように再構築される過程で、パケットが紛失したり、処理が遅延したりするのを防ぐためです。

—

3. pingでパケットの「サイズ」を限界まで攻める

では、実際に自分のネットワークで「どこまでなら荷物が通れるのか」を検証してみましょう。ここで使うのが ping コマンドです。

Windows環境での実行例

Windowsの ping は、指定したサイズに「IPヘッダー(20バイト)」と「ICMPヘッダー(8バイト)」の計28バイトが自動で加算されます。

# -f: DFフラグをセットする(断片化禁止)
# -l: 送信するデータサイズ(ペイロード)を指定
ping 192.168.1.1 -f -l 1472

もし結果に「パケットの断片化が必要ですが、DFが設定されています」と出たら、その経路のMTUを超えています。逆に、無事に「応答」があれば、そのサイズは通れるということです。

Linux/macOS環境での実行例

Linux系では、指定したサイズがそのままパケット全体のサイズとして扱われることが多いです。

# -M do: DFフラグをセットする(do = Don't Fragment)
# -s: パケットサイズを指定
ping -M do -s 1472 192.168.1.1

—

4. 現場で役立つ「パスMTUディスカバリー」の考え方

実務では、いちいち ping を打って手動でサイズを探すのは大変ですよね。そこでネットワーク機器は、「この道、1500バイトじゃ通れないぞ!」というメッセージを送信元に伝える仕組みを持っています。これを「パスMTUディスカバリー(PMTUD)」と呼びます。

現場でトラブルシューティングをする際は、以下の視点を持つことが重要です。

  • ICMPの通過を許可しているか?:PMTUDは「通れなかったよ」というICMPエラーメッセージを使って動作します。ファイアウォールでICMPを全遮断していると、このエラーが届かず、通信が「ブラックホール(何も返ってこない状態)」に陥ります。
  • VPNやトンネリング:VPNなどのカプセル化技術を使うと、元のデータに新しいヘッダーが追加されます。その分、荷物が膨らむので、物理的なMTUよりも小さいサイズに調整(MSSクランプなど)してあげるのが運用の鉄則です。

—

まとめ:ネットワークは「荷造り」が9割

トラブル対応の現場にいると、「回線速度が遅い」と言われて調べたら、MTUの不一致による再送の嵐だった……というケースに何度も出くわします。

「なぜパケットが届かないのか?」と悩んだときは、ぜひこう問いかけてみてください。
「このパケットは、今どのサイズの箱に入っていて、途中のルートはそれを許容しているのか?」と。

ネットワークという巨大な物流網において、適切な荷造り(MTU管理)を行うことこそが、エンジニアとしての腕の見せ所です。まずは手元のPCから ping -f を打って、身近なネットワークの「限界サイズ」を探る遊びから始めてみませんか?

それでは、また次のトラブルシューティングの現場でお会いしましょう!

コメント

タイトルとURLをコピーしました