MTU, fragmentation, and Path MTU

A link’s Maximum Transmission Unit, or MTU, is the largest IP packet it can carry without link-specific fragmentation. Ethernet’s standard MTU is 1500 bytes. Check your own interfaces:

ip link show eth0
# 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ...

A VPN or tunnel interface on the same machine will show something smaller, like mtu 1420, because the tunnel’s own headers eat into the budget. Different links along one path can have different limits, and the smallest one wins — that smallest value is the path MTU.

Who fragments, and who doesn’t

IPv4 routers may fragment some oversized packets, splitting them into pieces the next link accepts. In IPv6, routers never fragment; the source must send packets that fit, using feedback to choose a suitable size. Modern systems try to discover the path MTU in both versions, because fragmentation is slow and fragile even where it’s allowed.

The discovery mechanism relies on ICMP feedback: a router that can’t forward a too-large packet reports back that a packet is too large for the next link. You can probe a path yourself by sending pings that refuse fragmentation:

ping -c 1 -M do -s 1472 1.1.1.1     # Linux: -M do sets Don't Fragment
# 64 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=10.1 ms

ping -c 1 -M do -s 1473 1.1.1.1
# ping: local error: message too long, mtu=1500

1472 bytes of payload plus 28 bytes of ICMP and IP headers is exactly 1500 — it fits. One byte more fails. On macOS the equivalent is ping -D -s 1472 1.1.1.1. Walk the size down until it succeeds and you’ve measured the path MTU by hand. On a VPN, expect the boundary near 1392 rather than 1472.

The classic failure: PMTUD black holes

Blocking that ICMP feedback can create a path where small messages work but larger transfers stall. This produces one of networking’s most confusing symptoms:

- ping works
- curl of a small page works
- large downloads or uploads hang forever
- git push freezes mid-transfer

Small packets fit everywhere. Large packets get dropped at the narrow link, and the “too big” message never reaches the sender because a firewall somewhere eats ICMP. The sender retransmits the same oversized packet forever.

When that symptom appears, inspect tunnels, VPN overhead, interface MTUs, and ICMP filtering before blaming the application. The ping -M do probe above is your measuring tool: if the working size is well below what your interface MTU suggests, something in the path is narrower than your system believes.