Black hole MTU discovery, twenty years on
2026-08-30
The problem has been documented since the 1990s and it still happens in production: a host sends a packet larger than some link can carry, an intermediate router needs to signal this with an ICMP "fragmentation needed" message, a firewall drops that ICMP, and the connection stalls.
The mechanism
Path MTU discovery assumes the network is helpful. When a packet is too large for the next hop and the DF bit is set, the router is supposed to emit ICMP type 3 code 4 carrying the next-hop MTU. The sender then lowers its estimate and retries.
If that ICMP never arrives, the sender keeps retrying at the original size. Small packets get through, large ones vanish. TCP appears to hang: the handshake completes, the first small request goes out, and then nothing.
Why it persists
Blocking ICMP wholesale is a common and understandable policy — it removes a reconnaissance channel and a set of spoofing tricks. The side effect is that it also removes the feedback loop that makes PMTUD work. The two concerns are conflated far more often than they should be.
The workarounds, all imperfect
- Lower the interface MTU to something safe. Works, costs throughput on paths that could have handled more.
- Enable MSS clamping on the router. Effective for TCP, does nothing for UDP unless you clamp there too.
- Probe with a range of sizes at connection setup. Adds latency and is rarely implemented.
Diagnosing it
Send a ping with the DF bit set and a payload just above the suspected limit. If small payloads succeed and large ones fail silently, the path is a black hole. Then check whether the ICMP is arriving at all — often it is being generated and then dropped one hop short of you.
It is a twenty-year-old bug class that keeps getting reintroduced, because each new firewall policy is written by someone who has not seen it before.