MTUサイズ不一致による断続的な通信障害の原因と解決法

「特定の通信だけ遅い」「大きなファイル転送が途中で止まる」「VPNだけ不安定」などの症状がある場合、原因としてよく挙げられるのが MTU（最大転送単位）不一致 です。

本記事では、現場で MTU 問題を確実に切り分けられるように、原因 → 確認 → コマンド例 → 対処方法 を整理して解説します。

■ MTUサイズ不一致が原因で起きる主な症状

• Ping は通るが、大きなデータ通信だけ遅い／止まる
• VPN（IPsec, SSL-VPN）が断続的に切れる
• Webサイトの一部だけ読み込めない
• トンネル経由の通信だけ不安定
• Path MTU Discovery が失敗し ICMP Fragmentation Needed が返らない

特に、ファイアウォールや VPN 装置で ICMP を遮断しているケースでは、不一致による断続的な障害が非常に起こりやすくなります。

■ MTU不一致が発生する典型的なケース

• VPN トンネル内でのオーバーヘッド（IPsec 40～60byte など）
• クラウド（AWS/Azure/GCP）側の MTU がデフォルト 9001/1500
• PPPoE 経路が混在（MTU 1492）
• 一部の L3 スイッチだけ MTU を変更している
• ルータ間で Jumbo Frame を使っているのに経路途中が未対応

■ MTU不一致の確認手順

① 通常の ping が通るか確認

ping 192.168.1.1

これは大抵通るため MTU問題の判定には不十分 です。

② MTUサイズを指定したパケットで確認（Do not Fragment）

※Cisco 機器

ping 192.168.1.1 size 1472 df-bit

1472 + 28 = 1500 となり、1500byte 経路を確認できます。

【失敗した例】

Sending 1472, DF bit set
Packet needs to be fragmented but DF set.

→ MTU 不一致が発生している証拠です。

③ ネットワーク機器側の MTU を確認

show interface GigabitEthernet1/0/1

【MTU不一致の例】

GigabitEthernet1/0/1
  MTU 1500 bytes, BW 1000000 Kbit
GigabitEthernet1/0/2
  MTU 9000 bytes, BW 1000000 Kbit

→ 1500 と 9000 が混在しているため、途中で破棄される可能性があります。

■ MTU不一致の原因を特定するための追加確認コマンド

Path MTU Discovery の失敗確認（Linux）

tracepath 8.8.8.8

【PMTUD失敗の例】

1?: [LOCALHOST] pmtu 1500
2?: no reply
3?: no reply

→ 経路途中で Fragmentation Needed を返せない機器がある。

VPN での MTU 確認

show vpn flow
show ipsec sa

→ 一部の装置では「フラグメント発生」「ドロップ」などのカウンタが増えているのを確認できます。

■ MTU問題の解決方法

① 経路で共通の MTU に統一する

interface GigabitEthernet1/0/1
  mtu 1500

特に、クラウド接続や VPN 時は 1500 が無難 です。

② VPNのオーバーヘッドを考慮して MTU を小さくする

例：IPsec VPN の場合 1400 前後が推奨されることが多い

interface Tunnel0
  ip mtu 1400
  ip tcp adjust-mss 1360

③ TCP MSS を調整する（最も確実）

MTU ではなく MSS を調整して断続的な切断を防ぐ方法。

interface Tunnel0
  ip tcp adjust-mss 1360

※MSS = MTU – 40（TCP/IP ヘッダ）

④ ファイアウォールで ICMP Fragmentation Needed を許可する

PMTUD が機能するように ICMP type 3 code 4 を許可します。

permit icmp any any packet-too-big

■ 実例：MTU不一致による障害と復旧プロセス

【現場の状況】

• VPN経由だけ通信が断続的に切れる
• 大容量ファイル転送が必ず途中で失敗
• 通常 ping は通る

【切り分け】

ping 10.0.0.1 size 1472 df-bit
Packet needs to be fragmented but DF set.

→ MTU 1500 では通らないことが判明。

【対処】

interface Tunnel0
  ip mtu 1400
  ip tcp adjust-mss 1360

【復旧結果】

ping 10.0.0.1 size 1372 df-bit
!!!!  (success)

→ 大容量転送も安定し、通信障害は解消。

■ まとめ

• MTU不一致は「断続的」「特定の大容量通信だけ不安定」などの特徴を持つ
• df-bit ping（Do not Fragment）で確認するのが最も有効
• VPN では特に発生しやすいので MTU/MSS 調整が必須
• ICMP packet-too-big を遮断すると PMTUD が失敗し問題が悪化する

MTU問題は現場で非常に多いトラブルの1つですが、確認ポイントを押さえると確実に切り分け可能です。