MTU and Fragmentation: Why Large Pages Hang

MTU problems produce one of the most distinctive symptom patterns in networking: small things work and large things hang. A login page loads, a file download stalls at zero. A terminal session connects and then freezes the moment output gets long. Recognising the pattern is most of the diagnosis.

What MTU Is

The maximum transmission unit is the largest payload a link will carry in a single frame. Standard Ethernet carries 1500 bytes.

A packet that needs to cross a link with a smaller MTU has two possible fates. It can be fragmented into pieces small enough to fit and reassembled at the destination, or it can be dropped with a notification back to the sender. Which one happens depends on whether the packet carries the do-not-fragment flag, and most modern traffic does.

Where the MTU Shrinks

Every encapsulation adds a header, and every header comes out of the payload.

The number is not the point. The point is that a path crossing several links has an effective MTU equal to the smallest one on it, and nothing on the sending machine knows that in advance.

Path MTU Discovery

The mechanism for finding out is Path MTU Discovery. The sender marks packets as do-not-fragment and sends at its local MTU. A router that cannot forward one because it is too large for the next link drops it and sends back an ICMP message saying so, including the size that would fit. The sender reduces accordingly and retries.

This works well, and it depends entirely on that ICMP message arriving.

Why It Breaks

A great many firewalls are configured to block ICMP, either wholesale or by dropping anything not explicitly permitted. The intent is usually to stop the network being scanned.

The effect is that the fragmentation-needed message never reaches the sender. The sender does not learn that its packets are too large. It retransmits the same oversized packet, which is dropped again, and the connection hangs rather than failing.

Because the mechanism fails silently, nothing in the logs on either end says “MTU”. The connection simply stops making progress once packets get large.

This is why blocking all ICMP is a mistake rather than a hardening measure. The fragmentation-needed and packet-too-big messages are load-bearing parts of how the network works, not diagnostics.

Finding the Working MTU

The test is ping with the do-not-fragment flag and an explicit payload size.

Send a large packet with the flag set toward a destination on the far side of the suspect link. If it comes back, that size fits. If it reports that the packet needs fragmenting, it does not. Work downward until packets get through, and the largest successful payload plus the header overhead ping does not count is the working MTU.

Test past the link you suspect, not to it. Pinging the router at the end of your own link tells you nothing about the tunnel beyond it.

Fixing It

There are three places to act, in rough order of preference.

Set the correct MTU on the device that owns the link. A router terminating a PPPoE connection or a VPN tunnel should be configured with the MTU that connection actually supports, so it advertises the right size rather than discovering it per connection.

Allow the necessary ICMP. Permitting the fragmentation-needed and packet-too-big messages through the firewall restores Path MTU Discovery without opening anything meaningful. This is the fix that helps everything behind the firewall rather than one machine.

Use MSS clamping where the equipment supports it. The device rewrites the maximum segment size advertised during connection setup so that both ends agree on a size that fits, without depending on ICMP at all. This is common on routers terminating tunnels and is the pragmatic answer when the far end is not under your control.

Lowering the MTU on individual client machines works and is the least good option, because it has to be repeated on every device and it lowers the MTU for all traffic rather than for the path that needed it.

Where This Shows Up

VPN connections are the most common context, because the tunnel adds headers and the endpoints often sit behind firewalls with restrictive ICMP rules. See multiple VPN connections for the related case of tunnels interacting.

DSL connections using PPPoE are the classic fixed-line case. Nested tunnels, such as a VPN inside another VPN, accumulate overhead and are worth testing explicitly.

What People Get Wrong About This

The first mistake is not recognising the pattern. Small requests succeeding while large transfers hang is nearly diagnostic on its own, and it gets investigated as a bandwidth or DNS problem instead.

The second is blocking all ICMP as a security measure. It disables Path MTU Discovery and produces exactly this failure for everything behind the firewall.

A third is testing with ordinary ping. Without the do-not-fragment flag the packet is simply fragmented and reports success, which tells you nothing.

A fourth is lowering the MTU on one machine until things work and considering it solved. The next device on the network has the same problem.

And the last is confusing this with packet loss. Loss degrades a connection gradually; an MTU problem stops it dead at a specific size while smaller traffic is unaffected. Packet loss against latency covers how the other pattern looks.

Jumbo Frames

Some networks raise the MTU above the standard, typically on storage or backup segments where large transfers dominate. The efficiency gain is real within that segment.

It also means every device on the path must agree. A single switch port or interface left at the standard MTU in a jumbo-frame path produces the same silent stall discussed above, in a network where nobody is expecting an MTU problem.