Path MTU Discovery (PMTUD)
The scenario (Why you care)
Path MTU Discovery problems show up as a very specific kind of “it sometimes works, sometimes hangs.” Small things succeed: short pings, simple logins, tiny API calls. But as soon as a user tries to load a large web page, start a VPN, or transfer a bigger file, the session stalls halfway with no obvious error.
From the application side this feels like random slowness or timeouts. From the network side, what is really happening is that packets large enough to exceed a smaller MTU somewhere on the path are being dropped, while smaller packets still pass. PMTUD is the mechanism meant to avoid this, and when it fails you get a pattern that is easy to mislabel as “flaky internet” or “the server is slow” unless you know what to look for in captures.
This topic focuses on the IPv4 case with DF (Don’t Fragment) traffic and ICMP “fragmentation needed” messages, but the same ideas help you reason about tunnels, VPNs, and firewalls that interfere with path MTU discovery.
What “good” looks like (Success pattern)
- What you see
- Large flows start slowly but then run smoothly. In captures you may see one or two ICMP “fragmentation needed” messages early on, followed by a reduction in packet size from the sender. After that, no more ICMP errors and the transfer completes without unusual retransmissions.
- Why it happens
- The sender initially sends packets sized for its local interface MTU (for example 1500 bytes). A smaller MTU exists somewhere downstream (for example 1400 bytes over a tunnel). A router on that path sends an ICMP message describing the smaller MTU. The sender lowers its path MTU estimate and continues with smaller segments, avoiding further drops.
- Key clue
- You see a small burst of ICMP “fragmentation needed” paired with a step change in TCP segment sizes, and after that point retransmissions drop and throughput becomes stable.
What goes wrong (Failure pattern)
- What you see
- Connections that move only small amounts of data succeed, but larger transfers stall or time out. In packets, you see repeated TCP retransmissions for larger segments, no corresponding ACKs, and often no ICMP “fragmentation needed” messages at all. From the sender’s perspective, the path looks like random loss.
- Likely causes
- Common causes include: firewalls blocking ICMP “fragmentation needed”, middleboxes that drop oversized DF packets without sending errors, tunnel MTUs that are smaller than the endpoints assume, or asymmetric paths where ICMP is generated but never makes it back to the original sender.
- Key clue
- The pattern “small pings OK, large pings fail” or “TLS handshake completes but large HTTP responses stall” combined with repeated retransmissions for the same large sequence numbers is a strong PMTUD failure signature.
Signals & decision table
Use this table when you’re not sure whether you are looking at a generic loss problem or a specific path MTU issue. Check which signal best matches your capture and follow the suggested next step.
| Signal you see | What it suggests | What to check next | Related field/protocol |
|---|---|---|---|
| Small pings succeed, large pings time out | Likely path MTU problem on the route | Compare ping sizes with observed TCP segment sizes; look for ICMP “fragmentation needed” | IPv4 DF bit, ICMP Type 3 Code 4 |
| ICMP “fragmentation needed” present, then segment size shrinks | PMTUD working as designed | Verify the new segment size fits the reported MTU; confirm transfer completes without further errors | IPv4 header, ICMP error payload |
| Repeated TCP retransmits of large segments, no ICMP errors | PMTUD blocked or broken (ICMP filtered) | Capture closer to the suspected bottleneck; test with DF cleared or smaller MSS | TCP MSS option, IPv4 Flags/Fragment Offset |
| VPN or tunnel traffic stalls, plain traffic works | Encapsulation overhead reduced effective MTU | Compare MTU on tunnel vs underlay; inspect outer/inner packet sizes in captures | Encapsulating protocol + inner IPv4 |
| One direction fine, reverse direction stalls for large data | Asymmetric path MTU or ICMP filtering | Capture in both directions; check which side never sees ICMP or ACKs for large packets | IPv4 routing, ICMP return path |
How it looks in Wireshark
Display filter example:
icmp.type == 3 && icmp.code == 4- When PMTUD is working, you see one or more ICMP “fragmentation needed” messages referencing the original IP header and the next-hop MTU, followed by smaller TCP segments from the sender.
- When PMTUD is broken, you typically see large TCP segments being retransmitted without any matching ICMP errors, and the receiver never acknowledges those bytes.
- On tunneled or VPN links, you may see the outer packet being too large for a hop even when the inner IP packet looks reasonable; the ICMP error will reference the outer header.
Quick read tip: Line up the sequence numbers of the retransmitted TCP segments with any ICMP “fragmentation needed” messages. If you never see ICMP and only the large segments suffer, you are almost certainly looking at a PMTUD or MTU configuration issue, not generic congestion loss.
Fast triage checklist
- Reproduce the problem with a simple test (for example: increasing-size ping or a controlled file transfer) so you can capture a clean example.
- In the capture, identify the first point where traffic stalls and note the size of the packets involved (IP total length and TCP segment size).
- Apply an ICMP filter and look for Type 3 Code 4 messages around that time. If present, note the reported MTU and whether the sender adapts.
- If no ICMP appears, capture closer to intermediate hops or firewalls, or temporarily clear DF / lower MSS to see if a smaller packet size restores connectivity.
- Once you’ve confirmed an MTU-related root cause, decide whether the permanent fix belongs in routing (path choice), device configuration (MTU settings, tunnel parameters), or security policy (allowing critical ICMP types).
Common pitfalls
Assuming “packet loss” always means congestion
It is tempting to treat any retransmission-heavy trace as a bandwidth or congestion problem. In PMTUD failures, the loss is very size-specific: only packets above a certain size disappear. If you don’t check packet sizes, you can waste time tuning TCP, QoS, or server settings when the real fix is to adjust MTU or allow ICMP.
Misreading ICMP as “noise” or “attack”
Some environments aggressively drop ICMP because it “looks scary.” For PMTUD, ICMP is part of the control plane that keeps large traffic working. Blocking all ICMP may remove useful attack vectors, but it also removes the mechanism that tells senders to slow down their packet size. The right approach is usually to allow well-defined ICMP types and codes rather than blocking the protocol entirely.
Forgetting about tunnels and overlays
When MTU seems “correct everywhere” but PMTUD symptoms persist, an overlay is often hiding in the middle: GRE, IPsec, VXLAN, or a provider-managed tunnel. Each adds headers and reduces the effective MTU. If you only look at endpoint MTUs, you can miss the real bottleneck where the encapsulated packets are actually dropped.