MTU不一致で起きるパケットロスの見抜き方（Linux編）

通信はできている。 しかし、特定の通信だけ失敗する、レスポンスが極端に遅い。

このような症状の原因として非常に多いのが MTU（Maximum Transmission Unit）の不一致です。

本記事では、 Linux上でMTU不一致によるパケットロスを見抜く具体的な方法を、 切り分け手順として解説します。

結論：MTU不一致は「pingで見抜ける」

MTU不一致は、

• 通常の ping は通る
• 大きなパケットだけ失敗する

という特徴があります。

そのため、 DF（フラグメント禁止）指定の ping が有効です。

MTU不一致が起きる仕組み

通信経路のどこかに

• MTUが小さい機器
• ICMPが遮断されている機器

が存在すると、

• フラグメント不可
• 通知が返らない

結果として、 パケットが破棄され続ける状態になります。

確認① インターフェースのMTU確認

ip link show

全ての通信経路で MTUが揃っているかを確認します。

確認② DF指定pingによる確認

IPv4の場合

ping -M do -s 1472 対象ホスト

1472 + 28byte = 1500（Ethernet MTU）

判断ポイント

• 通る → MTUは問題ない可能性が高い
• 通らない → 経路上でMTU不一致

サイズを下げての切り分け

ping -M do -s 1400 対象ホスト
ping -M do -s 1300 対象ホスト

通るサイズ／通らないサイズの境界を確認します。

確認③ 仮想環境・トンネルの存在

以下の環境ではMTU不一致が起きやすくなります。

• VPN
• VXLAN
• GRE
• クラウドLB

オーバーヘッドを考慮し、 MTUを意図的に下げる必要があります。

パケットロスとして見える理由

MTU不一致では、

• ping loss
• TCP再送

として現れます。

CPUやメモリ負荷には現れにくいため、 原因に辿り着きにくいのが特徴です。

どうなれば「解決」と判断できるか

• DF指定pingが安定して通る
• TCP再送が発生しない
• アプリ通信が安定

これらを満たせば、 MTU不一致による問題は解消したと判断できます。

よくある誤解

• MTUはデフォルトで問題ない
• pingが通るから問題ない

MTUは 経路全体で揃って初めて意味を持ちます。

まとめ

MTU不一致は、

• 通信できるのに遅い
• 特定通信だけ失敗

という症状を引き起こします。

Linuxでは DF指定pingを使うことで、 原因を明確に切り分けることができます。