Path MTU Discovery, and the Black Hole
A process built entirely on an error message arriving
Step 1 of 2 — understand the idea. Read this first and the packet trace will confirm what you already expect, instead of teaching you two things at once.
What you'll be able to do
- ▸Describe path MTU discovery as a named process rather than a side effect
- ▸Explain why blocking ICMP produces a connection that works and then stalls
- ▸Recognise the black-hole signature from what succeeds and what does not
Before this lesson — it builds directly on:
A sender knows the MTU of the link it is plugged into and nothing else. The path to a destination may cross a dozen links with different limits, and the smallest one governs.
The old answer was fragmentation: send what you like and let routers cut packets up. It works and it is expensive — the receiver has to reassemble, one lost fragment costs the whole datagram, and routers spend effort per packet.
Path MTU discovery is the modern answer. Refuse fragmentation, listen for the complaint, adjust. It is efficient and it has one weakness: it depends entirely on the complaint arriving.
Watch these fields in the lab: ipv4.totalLength
- 1The sender assumes the path MTU equals its own link's MTU.
- 2It sends packets at that size with the Don't Fragment bit set.
- 3A router that cannot forward one discards it — DF forbids cutting it up.
- 4The router sends back Destination Unreachable, code 4, stating the MTU it could have handled.
- 5The sender lowers its cached path MTU for that destination and retransmits smaller.
- 6Repeat if a later link is smaller still.
- 7Every step after the third depends on an ICMP error being delivered.
✓ Concept check — before you open the packets
These test the idea, not the trace. You should be able to answer them from the explanation above.
Now that you understand the concept, observe how it appears in the packet exchange.
The lab runs a real simulated capture — pause, step, click any packet, and inspect every byte.