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.\n\nMTU 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.

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.\n\nLayer considerations:\n\nMTU 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.

Each network technology specifies its own MTU based on historical, technical, and economic factors. Understanding these values and their origins helps predict fragmentation scenarios.

Why 1500 bytes became the standard:\n\nWhen Ethernet was developed at Xerox PARC in the 1970s, engineers faced competing constraints:\n\n1. Efficiency — Larger frames have better payload-to-overhead ratio\n2. Collision recovery — On shared coax, larger frames mean longer recovery from collisions\n3. Buffer memory — RAM was expensive; larger frames require more buffer space\n4. Latency fairness — Larger frames delay other traffic longer\n\nThe 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.\n\nJumbo frames (9000 bytes):\n\nData centers often enable jumbo frames for significant performance benefits:\n- 6× higher efficiency for bulk transfers\n- Reduced CPU interrupt load\n- Lower latency for large transfers\n\nHowever, jumbo frames require end-to-end support and are NOT internet-compatible.

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.\n\nHow PMTUD Works:

PMTUD Algorithm Step-by-Step:\n\n1. Send with DF flag set — Host sends packets with the Don't Fragment (DF) flag, starting with interface MTU\n\n2. Router encounters MTU limit — If packet exceeds outgoing interface MTU, router cannot fragment due to DF\n\n3. ICMP response sent — Router sends ICMP Type 3, Code 4 (Fragmentation Needed and DF Set) with next-hop MTU\n\n4. Host updates cache — Source records the reduced MTU in its routing/PMTU cache\n\n5. Retry with smaller packets — Host retransmits using the discovered MTU\n\n6. Iterative discovery — Process repeats until packet reaches destination (path may have multiple reduced MTU points)

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:\n\n- TCP connection establishes successfully (SYN/SYN-ACK/ACK are small)\n- Small HTTP requests work (GET requests, small responses)\n- Large transfers hang (file downloads, large web pages)\n- SSH works but SCP hangs\n- Ping succeeds but application fails\n\nWhy TCP is particularly affected:\n\nTCP uses MSS (Maximum Segment Size) which depends on PMTU. If PMTUD fails:\n- TCP sends segments at interface MTU size\n- Segments are dropped at bottleneck link\n- TCP retransmits at same size (no ICMP feedback)\n- Connection times out after multiple retries

Given PMTUD's fragility, various alternatives and workarounds have been developed:

Tunneling protocols wrap packets in additional headers, reducing effective MTU. Understanding this overhead is critical for VPN design and troubleshooting.

Calculating tunnel MTU:\n\nTunnel effective MTU = Underlying MTU - Tunnel overhead\n\nExample: IPsec VPN over DSL:\n- Base MTU (DSL/PPPoE): 1492 bytes\n- IPsec ESP overhead: 60 bytes (typical)\n- Effective MTU: 1492 - 60 = 1432 bytes\n- TCP MSS: 1432 - 40 = 1392 bytes\n\nNested tunnels compound the problem:\n\n- Original Ethernet: 1500 bytes MTU\n- VPN tunnel: 1500 - 60 = 1440 bytes\n- Inner GRE tunnel: 1440 - 24 = 1416 bytes\n- Final TCP MSS: 1416 - 40 = 1376 bytes\n\nEach tunnel layer consumes overhead that cannot carry user payload.

Systematic MTU diagnosis requires understanding what tools are available and how to interpret their output.

Mastering MTU concepts enables you to design robust networks and quickly diagnose connectivity issues. Let's consolidate the key principles:

What's Next:\n\nWith 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.