MTU問題が引き起こすネットワークトラブル
style=”color:#334155;margin:0 0 1.5rem;font-size:18px;line-height:1.8;”>ネットワークトラブルの調査をしていると、通信はできているのに「なぜか遅い」「パケットロスが発生する」というケースに遭遇することがあります。回線帯域にも余裕があり、CPU使用率も問題ない。それでも通信品質が悪い場合、原因として疑われるのがMTU(Maximum Transmission Unit)です。MTUの設定が適切でない場合、パケットのフラグメントが発生し、通信効率が大きく低下します。特にIPsecやGREトンネルを使ったVPN環境では、MTU問題が通信品質に直接影響するにもかかわらず、見落とされやすいポイントです。
この記事では、MTUの基本概念・フラグメント発生の仕組み・調査コマンド・環境別の対策まで、実務目線で体系的に解説します。
【実例】IPsec環境でMTU問題が発生したケース style=”color:#166534;margin:0 0 0.8rem;font-size:18px;line-height:1.8;”>拠点間でIPsecトンネルを構築したとき、pingやHTTPの軽い通信は問題ないのに、ファイル転送だけが異常に遅いという問題が発生しました。帯域・ルーティング・ACLを確認しても問題なし。
最終的にMTU問題が原因でした。IPsecヘッダが追加されることで実効MTUが1500より小さくなっており、大きなパケットがフラグメントされていました。トンネルインターフェースのMTUを1400に変更したところ、転送速度が正常に戻りました。「なんで大きいファイルだけ遅いのか」という症状はMTUを疑うサインです。

MTUとは何か
あわせて読みたい関連記事
- MTUとMSSの確認方法|ping -f -lコマンド・Cisco show interfaces・ip tcp adjust-mss設定
- GREトンネルとは?仕組みと設定方法|MTU問題の対処法
- Cisco show interfacesの見方|エラーカウンタの意味と対処法
- SFPモジュールのSRとLRの違い|リンクアップするのに通信できないトラブル
- PCがネットワークに繋がらない原因と対処法
- ポート番号一覧|TCP/UDPの違い
MTUとは?基本概念をわかりやすく解説
style=”color:#334155;margin:0 0 1.5rem;font-size:18px;line-height:1.8;”>MTU(Maximum Transmission Unit)は、ネットワークインターフェースが一度に送信できるパケットサイズの最大値を指します。一般的なEthernetでは1500バイトがデフォルト値として広く使われています。MTUはネットワーク層(L3)の概念ですが、実際には物理的な伝送媒体やプロトコルの制約を反映したものです。Ethernetフレームの最大サイズが1518バイト(ヘッダ+ペイロード)に対して、IPパケットとして運べる最大値が1500バイトになります。
| 環境・プロトコル | 一般的なMTU値 | ヘッダオーバーヘッド | 備考 |
|---|---|---|---|
| Ethernet(通常) | 1500 bytes | なし | 最も一般的な値 |
| PPPoE | 1492 bytes | PPPoEヘッダ 8 bytes | フレッツ光など家庭・拠点回線で多い |
| IPsec(ESP/AES) | 1380〜1422 bytes | ESP/IPヘッダ等 数十〜100 bytes程度 | 暗号化方式・NAT-T有無で変動 |
| GREトンネル | 1476 bytes | GREヘッダ 24 bytes(IP20+GRE4) | IPsecと組み合わせるとさらに減少 |
| VXLANなどオーバーレイ | 1450 bytes前後 | VXLANヘッダ 50 bytes | クラウド・DC間接続で注意が必要 |
フラグメントとは何か・なぜ問題になるのか
MTUより大きなパケットを送信しようとすると、ルータや機器がパケットを分割します。この処理をフラグメント(fragmentation)と呼びます。
フラグメント発生の例
2000バイトのパケットをMTU 1500の回線で送信する場合、以下のように分割されます。
送信データ :2000 bytes
MTU :1500 bytes
分割後:
Fragment 1 :1500 bytes(IPヘッダ + データ)
Fragment 2 : 500 bytes(IPヘッダ + 残りデータ)
受信側で再構築して元の2000バイトに戻すフラグメントが引き起こす問題
DF(Don’t Fragment)ビットとPMTUD
TCPパケットにはDFビット(Don’t Fragment)が設定されており、「このパケットは分割しないで」という指示を持っています。経路上でMTUを超えた場合、ルータはパケットを破棄してICMPエラー(Type 3 Code 4:フラグメント必要)を返します。
この仕組みを使って経路上の最小MTUを自動検出するのがPMTUD(Path MTU Discovery)です。しかし、途中のFWがICMPをブロックしているとPMTUDが機能せず、通信が突然途絶えることがあります。これを「PMTUD ブラックホール」と呼びます。
MTUの確認方法
Windows
netsh interface ipv4 show subinterfaces
Bytes In Bytes Out Discards Errors MTU Interface
-------- --------- -------- ------ ---------- ---------------
... 1500 イーサネット
... 1500 Wi-FiMTU列を確認します。
Linux
ip link show
2: eth0: mtu 1500 qdisc ...
# または ifconfig
ifconfig eth0 | grep mtu
eth0: flags=... mtu 1500 mtu 1500の部分を確認します。
Cisco IOS
show interfaces GigabitEthernet0/0
GigabitEthernet0/0 is up, line protocol is up
Hardware is ..., address is ...
MTU 1500 bytes, BW 1000000 Kbit/sec, ...MTU 1500 bytesの行を確認します。
FortiGate
get system interface physical
== [ wan1 ]
name: wan1 mode: static ip: xx.xx.xx.xx/xx
mtu: 1500 mtu-override: disableMTU問題の調査方法(pingコマンド)
MTU問題はpingコマンドで調査できます。DFビットを立てた状態でサイズを変えながらpingを打ち、どのサイズで失敗するかを確認します。
Windows
ping -f -l 1472 8.8.8.8| オプション | 意味 |
|---|---|
| -f | DFビットを立てる(フラグメント禁止) |
| -l 1472 | 送信データサイズを1472バイトに指定 ※ 1472 = 1500(MTU)− 20(IPヘッダ)− 8(ICMPヘッダ)= 1472 |
MTUが小さい場合(フラグメントが発生する場合):
Packet needs to be fragmented but DF set.
(フラグメントが必要ですが、DFビットが設定されています)Linux
# DFビットを立てて1472バイトを送信
ping -M do -s 1472 8.8.8.8
# MTUが小さい場合の出力例
ping: local error: message too long, mtu=1400最適なMTUサイズを二分探索で探す手順
経路上の実際のMTUがいくつかを調べるには、サイズを変えながらpingを打ち二分探索的に絞り込みます。
ping -f -l 1472 を試す → 失敗なら問題ありping -f -l 1400 → 成功なら MTUは1400〜1472の間ping -f -l 1436 → 成否を確認。成功なら上限を狭めるMTU問題が発生しやすいケースと原因
| 環境 | 問題の原因 | 症状 |
|---|---|---|
| IPsec VPN | ESPヘッダ追加で実効MTUが低下 | 小さいファイルは通るが大きいファイルが遅い・失敗する |
| GREトンネル | GREヘッダ追加(24 bytes)でMTU1476相当に | 通信が断続的に遅い |
| PPPoE回線 | PPPoEヘッダ 8 bytes でMTU1492に | Webサイトが部分的に表示される・HTTPS通信が不安定 |
| クラウド接続(VPC) | オーバーレイネットワークでMTUが低下 | クラウド間通信で断続的な通信障害 |
| ICMPブロック環境 | PMTUDが機能せずDFパケットが破棄 | pingは通るのにWebやSSH接続が途切れる |
MTU問題の対策
対策1:インターフェースのMTUを調整する
トンネルインターフェースのMTUを、経路上で問題のないサイズに下げることでフラグメントを防ぎます。
! Cisco IOS:インターフェースのMTUを変更
Router(config)# interface Tunnel0
Router(config-if)# ip mtu 1400
! Linux:インターフェースのMTUを変更(一時的)
ip link set eth0 mtu 1400
! Linux:永続化(NetworkManager環境の場合)
nmcli connection modify "eth0" 802-3-ethernet.mtu 1400対策2:MSSのクランプ設定(最も推奨)
MSS(Maximum Segment Size)はTCPのペイロードサイズの最大値です。TCP SYNパケットで交換されます。ルータでMSSを強制的に調整する(クランプする)ことで、フラグメントを防ぎつつUDPは影響なく通す方法です。MTUを直接変更できない場合でも使えるため、実務では最もよく使われる対策です。
! Cisco IOS:MSSクランプ設定
Router(config)# interface GigabitEthernet0/0
Router(config-if)# ip tcp adjust-mss 1360
! インターフェースの両側に設定するのが確実
Router(config)# interface Tunnel0
Router(config-if)# ip tcp adjust-mss 1360| 環境 | 推奨MSS値 | 計算根拠 |
|---|---|---|
| PPPoE環境 | 1452 | 1492(PPPoE MTU)− 40(TCP/IPヘッダ) |
| IPsecトンネル(AES/SHA) | 1360〜1380 | 実効MTU(1400前後)− 40(TCP/IPヘッダ) |
| GRE over IPsec | 1300前後 | GREとIPsecの両方のオーバーヘッドを考慮 |
対策3:ICMPのType 3を許可する
PMTUDが正常に機能するよう、ファイアウォールでICMP Type 3(Destination Unreachable)を許可します。特にCode 4(フラグメント必要)のメッセージが届かないとPMTUDブラックホールが発生します。
! Cisco IOS:ICMP Type 3を許可するACL例
ip access-list extended ALLOW_ICMP_UNREACH
permit icmp any any unreachable
permit icmp any any packet-too-bigMTU問題は意外と見落とされる
ネットワークトラブルの調査ではルーティング・VLAN・ACLなどに目が行きがちです。しかしMTUが原因のケースも多く存在します。特に以下の症状が出ているときはMTUを疑う価値があります。
まとめ
MTU問題は「通信はできているのに遅い」という症状で現れるため、見落とされやすいトラブルです。特にVPN環境やPPPoE回線では必ず考慮すべき項目です。
- 一般的なEthernetのMTUは1500 bytes。トンネル通信ではヘッダ追加で実効MTUが低下する
- フラグメントが発生するとCPU増加・再送増加・ファイアウォール問題が起きる
- 調査は
ping -f -l 1472(Windows)でDFビットを立てたpingを使う - 対策はMSSクランプ(ip tcp adjust-mss)が最も推奨。MTUを直接変更できない場合でも有効
- ICMPのType 3をブロックするとPMTUDが機能せず「PMTUDブラックホール」になる
- 「大きいファイルだけ遅い」「VPN経由だけ遅い」症状が出たらMTUを疑う
ネットワークトラブルでルーティングやACLを確認しても原因が見つからない場合、MTUの確認を忘れずに加えてください。見落としがちなポイントですが、正しく対処すれば通信品質が劇的に改善することがあります。



