Quick Summary
- MTU (Maximum Transmission Unit) is the largest packet size a network link can carry -- typically 1500 bytes on Ethernet
- If a packet is too large for any link along its path, it gets dropped -- causing downloads to stall while small pings succeed
- Path MTU Discovery (PMTUD) automatically finds the smallest MTU on the path, but it breaks when ICMP is blocked
What is MTU?
Every network link has a maximum packet size it can carry in a single frame. This limit is called the Maximum Transmission Unit (MTU). On standard Ethernet, the MTU is 1500 bytes. This means the largest IP packet you can send without fragmentation is 1500 bytes -- including the IP header (20 bytes) and the TCP header (20 bytes), leaving 1460 bytes of actual data payload.
Think of MTU like the width of a tunnel. A compact car (small packet) drives through easily. A wide truck (large packet) gets stuck. If there is even one narrow tunnel along your entire route, every wide truck must either be split into smaller pieces (fragmentation) or turned back with a "too wide" sign (ICMP "Packet Too Big" message). This is exactly what happens to your data on the internet.
The default MTU of 1500 bytes dates back to early Ethernet standards from the 1980s. It was a compromise between efficiency (larger packets have less overhead per byte of data) and reliability (smaller packets are less likely to be corrupted in transit). Today, most local networks still use 1500, but tunnels, VPNs, and certain ISP links often have lower MTUs because they add extra headers that eat into the available space.
Interactive: Packet Size vs. Bottleneck MTU
Use the slider to change the packet size, then click "Send Packet" to see what happens when it hits a link with a lower MTU.
Why "Ping Works But Downloads Fail"
This is one of the most common and confusing network symptoms. The reason is simple: ping packets are small. A typical ping sends 64 bytes of data (plus headers). That tiny packet fits through any link, even one with a very low MTU. But when you download a file, TCP sends packets at the full MSS (Maximum Segment Size), which is usually 1460 bytes of payload inside a 1500-byte IP packet. If there is a bottleneck link with an MTU of, say, 1280 bytes, those large packets cannot fit through.
Normally, the router at the bottleneck would send back an ICMP "Packet Too Big" message telling the sender to reduce its packet size. This is called Path MTU Discovery (PMTUD). But here is where it gets tricky: many firewalls and routers are misconfigured to block all ICMP traffic, thinking it is a security risk. When they block ICMP "Packet Too Big" messages, the sender never learns about the smaller MTU. It keeps sending large packets, they keep getting dropped, and the connection stalls -- creating a "black hole" where the TCP connection is established (small SYN packets pass fine) but data transfer hangs.
Path MTU Discovery: How It Works
Set the Don't Fragment Bit
The sending host sets the DF (Don't Fragment) flag on its IP packets. This tells every router along the path: "do not break this packet into pieces. If it does not fit, drop it and tell me." Modern TCP connections always set the DF bit because IP fragmentation causes severe performance problems and security risks.
Bottleneck Router Responds
When a router encounters a packet with the DF bit set that exceeds the outgoing link's MTU, it drops the packet and sends an ICMP Type 3, Code 4 message ("Fragmentation Needed and DF Set") back to the sender. This message includes the MTU of the bottleneck link, telling the sender exactly how large its packets can be.
Sender Reduces Packet Size
Upon receiving the ICMP message, the sender adjusts its MSS (Maximum Segment Size) for that connection to fit within the reported MTU. Subsequent packets are smaller, fitting through the bottleneck link. The connection proceeds at the reduced packet size. This adjustment is cached so future connections to the same destination start with the correct size.
PMTUD Black Hole
If the ICMP "Packet Too Big" message is blocked by a firewall or never reaches the sender, PMTUD fails silently. The sender keeps retransmitting the too-large packet, never reducing its size. The connection hangs. This is called a PMTUD black hole and it is the root cause of the "ping works, downloads fail" symptom. Some modern operating systems implement PLPMTUD (Packetization Layer PMTUD) which probes with different sizes to work around blocked ICMP.
Where MTU Problems Happen
Certain network configurations are notorious for causing MTU issues. Here are the most common culprits:
VPN Tunnels
VPNs wrap your original packet inside a new IP packet with additional headers. IPsec adds 50-70 bytes of overhead, reducing the effective MTU from 1500 to around 1400-1450. If the tunnel endpoint does not adjust the MTU or MSS, large packets get dropped silently.
PPPoE Connections
Many DSL and fiber connections use PPPoE, which adds an 8-byte header. This reduces the link MTU from 1500 to 1492. It is a small difference, but it is enough to break PMTUD when ICMP is blocked. Many ISPs configure MSS clamping on their routers to prevent this.
Cloud / Container Overlays
Cloud networks like AWS VPCs, GRE tunnels, and VXLAN overlays all add encapsulation headers. VXLAN adds 50 bytes, reducing MTU to 1450. Kubernetes pod-to-pod traffic through overlay networks frequently hits MTU issues if the CNI plugin is not configured properly.
Diagnosing MTU Problems
When you suspect an MTU issue, the first diagnostic step is to send pings of increasing size with the DF bit set.
On Linux, you can run ping -M do -s 1472 destination (1472 + 28 bytes of ICMP/IP headers = 1500). If
this succeeds, increase the size. If it fails, reduce it. The largest size that succeeds reveals the path MTU. On
Windows, the equivalent command is ping -f -l 1472 destination. On macOS, use ping -D -s 1472
destination.
Another powerful tool is tracepath on Linux, which automatically discovers the path MTU by sending
UDP packets of varying sizes. Unlike traceroute, tracepath was specifically designed for PMTUD diagnostics. It reports
the MTU at each hop, making it easy to identify exactly where the bottleneck is.
Fixing MTU Issues
The best fix depends on the situation. MSS clamping is the most reliable solution: the router at the
bottleneck rewrites the TCP MSS option in SYN packets to match the link MTU, so the sender never tries to send packets
that are too large. On Linux, this is done with iptables: iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST
SYN -j TCPMSS --clamp-mss-to-pmtu. This fixes the problem transparently without requiring any changes on the
endpoints.
Alternatively, you can manually set the MTU on the interface. On Linux: ip link set dev eth0
mtu 1400. This forces the host to use smaller packets on all connections through that interface. The downside is
reduced efficiency on paths that could support the full 1500-byte MTU. For VPN tunnels, the tunnel software should
automatically handle MTU adjustment, but you may need to configure it explicitly if it does not.
Finally, never block ICMP indiscriminately. ICMP Type 3 Code 4 ("Fragmentation Needed") messages are essential for PMTUD. Blocking them causes black holes. If you must restrict ICMP for security, always allow Type 3 (Destination Unreachable) messages, especially Code 4. Many security guides from the early 2000s recommended blocking all ICMP, but modern best practice recognizes this as harmful.
Common MTU Mistakes
Blocking All ICMP
Firewalls that drop all ICMP traffic break Path MTU Discovery. Always allow ICMP Type 3 Code 4 messages through your firewall. This single misconfiguration causes more mysterious connection problems than almost any other.
Ignoring Tunnel Overhead
Setting up a VPN or GRE tunnel without reducing the MTU or enabling MSS clamping. The tunnel adds headers, but the endpoints still try to send 1500-byte packets. This works in testing with small payloads but fails under real load.
Setting MTU Too Low
Over-correcting by setting MTU to a very small value (like 576). While this avoids all fragmentation issues, it dramatically increases overhead. Each packet carries proportionally more headers and fewer data bytes, reducing throughput by 10-40%.
Frequently asked questions about MTU and path MTU discovery
What is MTU?
MTU (Maximum Transmission Unit) is the largest IP packet a link can carry in a single frame. Standard Ethernet has an MTU of 1500 bytes. Tunnels, PPPoE, and overlay networks have a smaller effective MTU because they add encapsulation headers.
Why does ping work but downloads fail?
Ping uses tiny packets (typically 64 bytes) that fit through any link. TCP downloads use full-MSS packets near 1500 bytes. If a bottleneck link has a smaller MTU and the ICMP "Packet Too Big" messages are blocked, those large packets are dropped silently — the connection establishes but never makes progress.
How does Path MTU Discovery work?
The sender sets the Don't Fragment bit on every packet. When a router can't forward a too-large packet, it drops it and returns ICMP Type 3 Code 4 (Fragmentation Needed) with the next-hop MTU. The sender shrinks its packets to that size. When the ICMP message is blocked, PMTUD silently fails — a PMTUD black hole.
What is MSS clamping?
MSS clamping is a workaround where a router rewrites the TCP MSS option in SYN packets to match the link MTU. This forces both endpoints to negotiate a smaller segment size, so they never send packets that won't fit. It is the most reliable fix for MTU black holes on VPN and PPPoE links.
Should I block ICMP at my firewall?
No, not all of it. Blocking ICMP Type 3 Code 4 (Fragmentation Needed) breaks Path MTU Discovery and causes silent failures. If you must filter ICMP, always allow Type 3 messages. The old advice to "block all ICMP" is widely cited and widely wrong.
Try the MTU black-hole lab
You just learned why ping works but downloads fail. Now reproduce the bug: trace small and full-size packets across a 1280-byte bottleneck, see path MTU discovery fail because a firewall drops "fragmentation needed", then fix it by allowing that ICMP message. MSS clamping is not modelled in the lab, so that fix stays in the explanation above.
Launch the MTU lab →