Loading learning content...
Every network technology has a fundamental constraint: the maximum amount of data it can carry in a single transmission. This limit—the Maximum Transmission Unit (MTU)—is perhaps the most practically significant concept in network engineering, directly affecting performance, reliability, and whether packets successfully traverse the Internet at all.
MTU is not merely a technical specification—it's the bridge between abstract network protocols and physical transmission realities. Understanding MTU deeply transforms you from someone who follows configuration guides to someone who can diagnose mysterious connectivity failures, optimize network performance, and design robust systems.
By the end of this page, you will master MTU from first principles: what it represents physically and logically, how different technologies determine their MTU values, how Path MTU Discovery (PMTUD) works, and practical techniques for diagnosing and resolving MTU-related problems. You'll understand why experienced network engineers often start debugging with 'What's the MTU?'
Maximum Transmission Unit (MTU) is the largest size of a protocol data unit (PDU) that can be transmitted in a single network-layer transaction. But this simple definition masks considerable complexity.
Layer considerations:
MTU operates at the boundary between the network layer and data link layer. It represents the maximum payload the data link layer can carry—which becomes the maximum datagram size for the network layer.
MTU refers to the payload of the data link frame, NOT the total frame size. An Ethernet frame with 1500-byte MTU actually transmits 1518 bytes minimum (1500 payload + 14 header + 4 FCS). With VLan tagging, this becomes 1522 bytes. Don't confuse MTU with maximum frame size.
Each network technology specifies its own MTU based on historical, technical, and economic factors. Understanding these values and their origins helps predict fragmentation scenarios.
| Technology | MTU (bytes) | Technical Rationale |
|---|---|---|
| Ethernet (IEEE 802.3) | 1500 | Balance of efficiency and collision impact on shared coax; became de facto standard |
| Ethernet Jumbo Frames | 9000 | Increased efficiency for server-to-server traffic in data centers; requires end-to-end support |
| IEEE 802.11 (WiFi) | 2304 | Larger to improve efficiency over wireless medium; usually reduced by driver/AP |
| PPPoE (DSL) | 1492 | 1500 minus 8-byte PPPoE header; common source of fragmentation |
| PPP | 1500 | Negotiated; often set to 1500 for compatibility |
| FDDI | 4352 | Higher efficiency for campus backbones |
| Token Ring (4 Mbps) | 4464 | Optimized for token-passing medium |
| Token Ring (16 Mbps) | 17914 | Larger due to faster token rotation |
| ATM AAL5 | 9180 | Segmented into 48-byte cells; large MTU reduces cell overhead |
| SLIP | 1006 | Historical serial link standard |
| IPv4 Minimum | 576 | All IPv4 hosts must accept datagrams of this size |
| IPv6 Minimum | 1280 | Higher minimum reflects modern network capabilities |
| Loopback | 65535 | No physical transmission; only memory limits apply |
Why 1500 bytes became the standard:
When Ethernet was developed at Xerox PARC in the 1970s, engineers faced competing constraints:
The 1500-byte choice optimized the collision-recovery tradeoff for 10 Mbps Ethernet on coaxial cable. Despite modern switched Ethernet having no collision concerns, backward compatibility has preserved 1500 bytes as the standard.
Jumbo frames (9000 bytes):
Data centers often enable jumbo frames for significant performance benefits:
However, jumbo frames require end-to-end support and are NOT internet-compatible.
Enabling jumbo frames on one end of a connection without ensuring end-to-end support causes silent packet loss. Packets larger than downstream MTU may be dropped if DF is set, causing mysterious application failures. Always verify jumbo frame support at EVERY hop before enabling.
Rather than blindly sending large packets and hoping for the best, modern hosts use Path MTU Discovery (RFC 1191 for IPv4, RFC 8201 for IPv6) to determine the optimal packet size for a given destination.
How PMTUD Works:
PMTUD Algorithm Step-by-Step:
Send with DF flag set — Host sends packets with the Don't Fragment (DF) flag, starting with interface MTU
Router encounters MTU limit — If packet exceeds outgoing interface MTU, router cannot fragment due to DF
ICMP response sent — Router sends ICMP Type 3, Code 4 (Fragmentation Needed and DF Set) with next-hop MTU
Host updates cache — Source records the reduced MTU in its routing/PMTU cache
Retry with smaller packets — Host retransmits using the discovered MTU
Iterative discovery — Process repeats until packet reaches destination (path may have multiple reduced MTU points)
PMTUD depends entirely on receiving ICMP 'Fragmentation Needed' messages. Firewalls that block ICMP (a tragically common misconfiguration) break PMTUD. The host sends large packets that are silently dropped—no ICMP, no discovery, no communication. This is the infamous 'PMTU black hole' and one of the most frustrating network debugging scenarios.
When PMTUD fails, the symptoms can be bewildering: connections establish but data transfer hangs, some websites work but others don't, small requests succeed but large responses fail. Understanding failure modes is essential for diagnosis.
Classic symptoms of PMTU black hole:
Why TCP is particularly affected:
TCP uses MSS (Maximum Segment Size) which depends on PMTU. If PMTUD fails:
To test for PMTU black holes: ping -f -l 1472 destination (Windows) or ping -M do -s 1472 destination (Linux). This sends a 1500-byte packet (1472 + 20 IP + 8 ICMP) with DF set. If it hangs while ping -l 100 destination works, you have a PMTU problem.
Given PMTUD's fragility, various alternatives and workarounds have been developed:
ip tcp adjust-mss on Cisco devices.12345678910111213
! Set TCP MSS to 1452 bytes on interface! This forces TCP to use segments that fit in 1492-byte PPPoE MTU! (1452 + 20 IP header + 20 TCP header = 1492 bytes) interface GigabitEthernet0/0 description WAN Interface with PPPoE ip tcp adjust-mss 1452 ! Verify configurationshow ip interface GigabitEthernet0/0 | include tcp ! Alternative: Clamp based on MTUip tcp mss 1452Virtually all ISP customer-premises equipment (CPE) and enterprise routers perform MSS clamping. This transparent fix ensures TCP works even when ICMP is filtered, making it the most reliable PMTU solution in practice.
Tunneling protocols wrap packets in additional headers, reducing effective MTU. Understanding this overhead is critical for VPN design and troubleshooting.
| Tunnel Type | Overhead (bytes) | Effective MTU | Notes |
|---|---|---|---|
| GRE | 24 | 1476 | 4-byte GRE + 20-byte new IP header |
| GRE with Key | 28 | 1472 | Additional 4-byte key field |
| IPsec ESP (AES-128) | ~50-60 | ~1440-1450 | ESP + IV + padding + auth; varies by cipher |
| IPsec ESP + NAT-T | ~60-70 | ~1430-1440 | Additional UDP encapsulation for NAT traversal |
| L2TP/IPsec | ~70-80 | ~1420-1430 | L2TP + PPP + IPsec overhead combined |
| VXLAN | 50 | 1450 | 8 VXLAN + 8 UDP + 20 IP + 14 Ethernet |
| WireGuard | 60 | 1440 | Encrypted outer packet with overhead |
| OpenVPN (UDP) | ~40-60 | ~1440-1460 | Depends on cipher and compression |
| 6to4 | 20 | 1480 | IPv6 inside IPv4 encapsulation |
| Teredo | 48 | 1452 | IPv6 in UDP in IPv4 |
| PPTP | 38 | 1462 | GRE + PPP overhead |
Calculating tunnel MTU:
Tunnel effective MTU = Underlying MTU - Tunnel overhead
Example: IPsec VPN over DSL:
Nested tunnels compound the problem:
Each tunnel layer consumes overhead that cannot carry user payload.
VPNs are the leading cause of fragmentation in modern networks. When users report 'VPN is slow' or 'some sites don't work through VPN', MTU/fragmentation issues should be the first suspect. Proper MSS clamping on VPN concentrators is essential.
Systematic MTU diagnosis requires understanding what tools are available and how to interpret their output.
123456789101112131415161718
# Check interface MTUnetsh interface ipv4 show subinterfaces # Find PMTU to destination (binary search)# Start with 1472 (1500 - 28 for headers)ping -f -l 1472 google.com # If "Packet needs to be fragmented", reduce sizeping -f -l 1400 google.com # Keep adjusting until packets succeed# Final successful size + 28 = Path MTU # Trace route with MTU detectionpathping google.com # Check current route cache (Windows 10+)netsh interface ipv4 show destinationcacheWhen testing MTU with ping, use 1472 bytes (-s 1472 or -l 1472). This plus 20-byte IP header + 8-byte ICMP header = 1500 bytes total—the standard Ethernet MTU. If 1472 fails, the path MTU is less than 1500. Work down in increments of 10-100 to find the actual limit.
Mastering MTU concepts enables you to design robust networks and quickly diagnose connectivity issues. Let's consolidate the key principles:
What's Next:
With MTU fundamentals mastered, we'll examine the specific IPv4 header field that controls fragmentation behavior: the Fragment Offset. Understanding how this field divides packets into reassemblable pieces is essential for deep fragmentation analysis and troubleshooting.
You now possess comprehensive knowledge of MTU—from basic definitions through technology-specific values, PMTUD mechanics, failure modes, and diagnostic procedures. This foundation is essential for the upcoming deep dive into fragmentation mechanics and header fields.