MTU最適化計算機|Ethernet・PPPoE・VPN・ジャンボフレームの推奨パケットサイズ
MTU(Maximum Transmission Unit)を通信種別・カプセル化オーバーヘッドから自動計算。Ethernet 1500・PPPoE 1492・IPsec VPN 1400・OpenVPN 1400・WireGuard 1420・ジャンボフレーム 9000までプリセット対応。MSS(Maximum Segment Size)推奨値、ping による実測手順、断片化トラブルの原因究明まで、RFC 791/1191/8201 に基づいて解説。ネットワークエンジニア・SIer・自宅ルーター運用者の現場実務に対応した信頼性設計。
MTU最適化ツール
MTUとMSSの基本式
MTU(Maximum Transmission Unit)
MTU = IPパケット(ヘッダ+ペイロード)の最大 byte 数
MTUは「ネットワークインタフェースが1回の送信で運べるIPパケットの最大サイズ」です。Ethernet標準は1500 byte、PPPoEは1492 byte(PPPヘッダ8byte差引)。物理レイヤ・データリンクレイヤの制約で決まり、送信側と受信側で異なる場合は経路上で最小のMTUに合わせる必要があります。
MSS(Maximum Segment Size)
MSS = MTU − IPヘッダ − TCPヘッダ
IPv4 の場合:MSS = MTU − 20 − 20 = MTU − 40
IPv6 の場合:MSS = MTU − 40 − 20 = MTU − 60
MSSはTCPコネクション確立時(3-wayハンドシェイクのSYN)にネゴシエートされる最大セグメントサイズ。Ethernet(MTU 1500)ならMSS 1460、PPPoE(MTU 1492)ならMSS 1452になります。TCP通信のスループット最適化はMSS正確設定が要点です。
断片化(Fragmentation)
MTUを超えるIPパケットは経路のルーターでフラグメント分割されます(IPv4)。分割はCPU負荷とパケット再送リスクを増やすため避けるべき事象で、IPv6では中間ルーターの断片化が廃止され、送信元が事前にMTUを把握する仕組み(PMTUD)に一本化されています。
通信種別ごとの標準MTU
| 通信種別 | MTU (byte) | MSS(v4) | 備考・オーバーヘッド |
|---|---|---|---|
| Ethernet(IEEE 802.3) | 1500 | 1460 | 標準・LAN共通 |
| Wi-Fi(IEEE 802.11) | 1500 | 1460 | Ethernet互換 |
| PPPoE(フレッツ光) | 1492 | 1452 | PPPoEヘッダ8byte |
| PPPoA(ADSL) | 1500 | 1460 | ATMセル化オーバーヘッド別途 |
| IPoE(v6プラス等) | 1500 | 1460 | PPPoEなし・生Ethernet |
| IPv6 生Ethernet | 1500 | 1440 | IPv6ヘッダ40byte |
| IPsec VPN(トンネル) | 1400前後 | 1360 | ESPヘッダ+暗号化パディング |
| OpenVPN(UDP) | 1400 | 1360 | OpenVPN独自ヘッダ |
| WireGuard | 1420 | 1380 | 32byte固定オーバーヘッド |
| GRE トンネル | 1476 | 1436 | GREヘッダ24byte |
| L2TP/IPsec | 1400前後 | 1360 | L2TP+IPsec重複 |
| MPLS | 1500-1508 | 1460 | MPLSラベル1個4byte |
| ジャンボフレーム | 9000 | 8960 | 10GbE以上のDC・iSCSI |
| スーパージャンボ | 9216 | 9176 | Ciscoベンダ実装 |
| モバイル(LTE/5G) | 1400前後 | 1360 | APN・キャリア依存 |
| 衛星通信(GEO) | 1500 | 1460 | 遅延大・TCPウィンドウ最適化 |
| PPP over ATM(古ADSL) | 576 | 536 | IPv4最小推奨 |
プロトコルヘッダの内訳
MTU計算の要点はカプセル化で追加されるヘッダの累積を正確に把握することです。主要オーバーヘッド:
| プロトコル/ヘッダ | サイズ (byte) | 用途 |
|---|---|---|
| Ethernet II ヘッダ+FCS | 18 | 宛先/送信元MAC+タイプ+CRC |
| Ethernet プリアンブル+IFG | 20 | 物理層(MTU計算外) |
| VLAN タグ(802.1Q) | +4 | VLAN識別 |
| IPv4 ヘッダ | 20 | オプションなし |
| IPv6 ヘッダ | 40 | 拡張ヘッダ別途 |
| TCP ヘッダ | 20 | オプション最大40 |
| UDP ヘッダ | 8 | — |
| PPPoE ヘッダ | 8 | フレッツ光 |
| GRE ヘッダ | 4-24 | トンネル基本+オプション |
| IPsec ESP(トンネル) | 50-80 | ESPヘッダ+IV+パディング+HMAC |
| WireGuard | 32 | 固定 |
| OpenVPN(UDP) | 29-93 | 設定次第で変動 |
| VXLAN | 50 | Ethernet over UDP |
| MPLS ラベル | 4/label | 多段時は累積 |
パスMTU探索(PMTUD)の仕組み
PMTUD(Path MTU Discovery)は経路上の最小MTU(パスMTU)を送信元が自動発見する仕組み(RFC 1191/8201)。
IPv4 の PMTUD
IPフラグメント不可(DF: Don't Fragment)ビットを立てて送信し、経路ルーターが「Fragmentation Needed(ICMP Type 3 Code 4)」で返答すると、送信元はそのMTUに合わせて再送します。ICMPが遮断されている環境(ファイアウォール設定ミス)ではPMTUDが機能せず、ブラックホール現象(接続はできるが大きなパケットだけ通らない)が発生します。
IPv6 の PMTUD
IPv6では中間ルーターが断片化しないためPMTUDが必須。ICMPv6「Packet Too Big」で通知(RFC 8201)。最小MTUは1280 byteに拡張され、これを下回るリンクでは動作しません。
TCP MSS Clamping
PMTUDが機能しない環境ではMSS Clamping(MSS書換え)で対応。ルーターがSYNパケットのMSSオプションを強制的に書き換える手法で、フレッツ光のPPPoE越しやIPsec VPNゲートウェイで広く使われています。設定値はMTU−40を基本とします。
ping/tracepathでのMTU実測
実際のパスMTUは以下のコマンドで測定できます。
Windows: ping -f -l
ping -f -l 1472 [対象ホスト]
-fでDFビットセット、-lでペイロードサイズ指定。「Packet needs to be fragmented but DF set.」が出たらサイズを下げて再試行。成功する最大値+ICMPヘッダ8+IPヘッダ20が経路MTU。1472成功なら1472+28=1500 byteが有効MTU。
Linux/Mac: ping -M do -s
ping -M do -s 1472 [対象ホスト]
Linuxでは-M doでDFビットセット、-sでペイロードサイズ指定。
tracepath (Linux)
tracepath [対象ホスト]
経路ホップごとにMTU変化を自動記録するコマンド。PMTUDのブラックホール検出に便利。
Windows PowerShell: Test-NetConnection -InformationLevel Detailed
PowerShellベースでリンクMTU情報を取得可能。ネットワークインタフェースの詳細診断に利用します。
現場での応用
🏠 家庭ルーター運用
フレッツ光PPPoEでMTU 1454(NTT東西の推奨値)、IPoE(v6プラス等)で1500が標準。ルーター管理画面で明示設定するとブラックホール回避と速度向上の両立が可能。Amazon等のショッピングサイトが特定サイズで開けない現象はMTU不一致が原因のことが多い。
🏢 IPsec/WireGuard VPN
本社-拠点間のIPsec VPNではペイロード1400 byteが実務推奨値。ESPヘッダ・IV・HMACのオーバーヘッドが50-80 byteあり、フラグメント発生でトンネル効率が急落します。SSL-VPNやWireGuardでも同様の考慮が必要。
💾 iSCSI/NFS(データセンター)
ストレージネットワークではジャンボフレーム(9000)採用が一般的。SANスイッチ・ホスト側NIC・ストレージコントローラの全てを9000に統一しないと逆に断片化で性能低下。10GbE・25GbE・100GbE環境の標準構成。
☁️ クラウド VPC/VNet
AWS VPC はVPC内 9001 byte・VPCピアリング1500・Transit Gateway 8500・VPN 1436。Azure VNetは基本1500だがAccelerated NetworkingでMTUが変動します。マルチクラウド構成では最小値を選ぶのが安全策。
📱 モバイル通信・APN
キャリアAPNごとにMTUが1400-1500の間で変動。5G SA・NSA・LTEで異なり、テザリング先端末が1500想定だと断片化発生。プロファイル設定でMTU 1400前後にすると安定するケースが多い。
🔒 SD-WAN / SASE
OverlayトンネルではベースMTUからGRE(24)+IPsec(50-80)を差引した実効MTUを設計。SD-WANゲートウェイ製品は自動MTU検知機能を持ちますが、事前設計値との整合性確認が本番前検証で必須です。
よくある間違い・注意点
- ICMP を全遮断してしまう — セキュリティのつもりでICMP全遮断するとPMTUDが機能せず「特定サイズだけ通らないブラックホール」が発生。Type 3 Code 4(Fragmentation Needed)は必ず通す設定が必要です。
- MSS を MTU と混同して設定 — MSS は MTU から IP+TCP ヘッダを差し引いた値(IPv4なら-40)。ルーターのTCP MSS Clamping設定でMTUの値をそのまま入れると通信不能に陥ります。
- ジャンボフレーム未統一 — 経路上の1機器でも1500 byteのままだと断片化またはドロップが発生。エンドツーエンドで9000統一が原則で、SANスイッチ・ホスト・ストレージの全設定確認が必要です。
- ping の -l サイズを MTU そのものと勘違い — ping -l 1500 はペイロード1500 byteの意で、実際のパケットは1500+8(ICMP)+20(IP)=1528 byte。正しい実測は -l 1472 で1500 MTU確認。
- PPPoE でMTU 1500 のまま運用 — PPPoEオーバーヘッド8 byteで実効1492のはずが、PC側1500設定でPPPoEルーターが断片化。フレッツ光ではPCまたはルーターのWAN側MTUを1454(NTT推奨)に設定します。
- VPN で断片化を許容してしまう — フラグメント再組立てはVPNゲートウェイのCPU負荷を数倍に増やします。ペイロード1400への統一とMSS Clampingで断片化ゼロを目指すのが実務標準。
関連する規格・RFC
- RFC 791 ― Internet Protocol(IPv4基本仕様)。IPフラグメンテーションの基本規則。
- RFC 793 ― Transmission Control Protocol(TCP)。MSSオプション定義。
- RFC 1191 ― Path MTU Discovery(IPv4向けPMTUD)。
- RFC 2460 / RFC 8200 ― Internet Protocol Version 6(IPv6)。中間ルーター断片化廃止。
- RFC 8201 ― Path MTU Discovery for IP version 6(IPv6向けPMTUD)。
- RFC 2516 ― A Method for Transmitting PPP Over Ethernet (PPPoE)。オーバーヘッド8byte。
- RFC 4301-4303 ― IPsec Architecture / ESP / AH。トンネル暗号化オーバーヘッド。
- IEEE 802.3 ― Ethernet標準。1500 byteペイロード上限、ジャンボフレームは9000-9216推奨。
- IEEE 802.11 ― Wireless LAN(Wi-Fi)。Ethernet互換MTU。
参考文献・公的資料
公式RFC・キャリア技術資料・OSベンダーマニュアルは以下を参照してください。
- IETF RFC Editor ― RFC 791/1191/8201/2460/8200など、TCP/IP・PMTUD・IPv6の公式規格の一次資料。
- JPNIC(日本ネットワークインフォメーションセンター) ― 日本のIPアドレス・技術文書。IPoE/IPv6普及活動の情報。
- NTT東日本 フレッツ光 ― PPPoE 1454 / IPoE 1500の推奨MTU値と接続手順マニュアル。
- NTT西日本 フレッツ光 ― 西日本エリアのMTU/MSS推奨値。
- Microsoft Learn: Windows Server MSS/MTU ― Windows での MTU/MSS 設定と診断コマンドの公式解説。
- Cisco: PMTUD と IP フラグメンテーション ― GRE/IPsec環境でのPMTUD・MSS Clamping設定例。
- AWS VPC ジャンボフレーム ― VPC内9001・VPCピアリング1500など環境別MTU仕様。
- Azure ネットワーク パフォーマンス チューニング ― Azure VNet MTU/MSS ガイド。
- WireGuard 公式プロトコル ― 32 byte 固定オーバーヘッドの規格仕様。
- OpenVPN Reference Manual ― --tun-mtu, --mssfix, --fragmentなどMTU関連パラメータ。
よくある質問(FAQ)
MTUを最適化するとどれくらい速くなる?
断片化が発生している環境では最大30-50%の実効スループット向上が期待できます。適切なMTU設定なら断片化ゼロで、CPU・回線とも効率化。逆に既に最適化されている環境ではMTU変更で目立った速度向上は望めません。まずping -f -l で断片化発生の有無を確認してから調整してください。
フレッツ光でPPPoEのMTUは?
NTT東西の推奨値はPPPoEで1454 byte、MSS 1414。PPPoEヘッダ8+PPPoE制御6=14 byteを1500 Ethernetから差し引いた実効値です。ルーターのWAN側MTU設定を1454にすることで、YouTube/Netflix/Amazonでの表示不良やSSHタイムアウトなどの現象を防げます。IPoE(v6プラス、transix等)ではMTU 1500のままで問題ありません。
MSSとMTUの違いは?
MSSはTCPペイロード最大サイズ、MTUはIPパケット最大サイズ。MSS = MTU − 40(IPv4) または MTU − 60(IPv6)の関係。3-wayハンドシェイクのSYNパケットでネゴシエートされ、TCPスループット最適化の主要パラメータになります。UDP通信ではMSSの概念は使いません。
ジャンボフレーム(9000)の効果は?
10GbE以上のバックボーンやSAN(iSCSI/NFS)でCPU負荷削減・スループット向上効果があります。1パケットあたりのオーバーヘッド割合が減り、大量データ転送で顕著。ただしエンドツーエンドで9000統一が絶対条件で、経路上の1機器でも1500のままだと逆に断片化で性能低下します。
VPNトンネルのMTUはなぜ小さい?
IPsec ESPで50-80 byte、OpenVPNで29-93 byte、WireGuardで32 byteのオーバーヘッドが追加されるため。ペイロード1400 byteが実務推奨値。トンネル外側MTUが1500なら暗号化+ヘッダで超過し、断片化またはドロップが発生します。VPN設定側で1400への統一とMSS Clampingが必須。
PMTUD(パスMTU探索)とは?
送信元が経路上の最小MTUを自動発見する仕組み(RFC 1191/8201)。DFビットセットで送信し、ICMP「Fragmentation Needed」で経路のMTU情報を得ます。ICMPが遮断されるとPMTUDが動作せずブラックホール現象が発生するため、Type 3 Code 4は必ず許可設定が必要。
MSS Clampingとは?
ルーター/ファイアウォールがSYNパケットのMSSオプションを強制書換えする手法。PMTUDが動作しない環境の代替策として広く使われています。フレッツ光のPPPoEルーター、IPsec VPNゲートウェイ、SD-WAN機器の必須機能。設定値はMTU−40が基本です。
Windowsでの MTU 確認・変更方法は?
確認: netsh interface ipv4 show subinterfaces。変更: netsh interface ipv4 set subinterface "接続名" mtu=1454 store=persistent。実測は ping -f -l 1472 8.8.8.8 等で成功する最大値を探索します。管理者権限で実行が必要です。
LinuxでのMTU確認・変更方法は?
確認: ip link show。変更: sudo ip link set dev eth0 mtu 1454。永続化は/etc/network/interfacesまたはNetworkManagerの設定ファイル編集で対応。断片化テストはping -M do -s 1472で実施します。
クラウド(AWS/Azure)のMTUは?
AWS VPC内 9001 byte・VPCピアリング 1500・Transit Gateway 8500・Direct Connect 1500(1522までジャンボ)。Azure VNetは基本1500・Accelerated Networkingで拡張。マルチクラウド設計時は経路上の最小値に合わせるのが安全策で、8500程度に統一する事例が多いです。
Wi-FiのMTUは有線と違う?
IEEE 802.11のMTUは1500 byteでEthernetと同じですが、暗号化(WPA2/WPA3)による無線フレーム内オーバーヘッドは物理層で処理されるためIPレイヤのMTUは変わりません。Wi-Fiルーター内蔵ONUがPPPoEを終端する場合はWAN側で1454になります。
MTUを小さくしすぎるとどうなる?
MTUを不必要に小さく(例: 576 byte)すると、同じデータ転送に多数のパケットが必要になり、ヘッダオーバーヘッド率が急上昇してスループット低下・CPU負荷増加を招きます。TCP再送・ウィンドウサイズの効率も落ちるため、経路が許す最大値を採用するのが原則。