What exactly is the MTU/MRU issue, what it is caused by and how to fix it?

In cases of hanging, freezing, slow, unresponsive internet connections the cause is usually unreasonably identified as "MTU/MRU issue" with several hastily proposed "magic cures" (usually invalid or inapplicable for the situation) like commands involving iptables or ifconfig, and other "clamp MTU to TSS" spells.

What I want to know is what exactly the MTU/MRU issue is, why it affects the connection speed and latency, and how it is cured (known and modern methods), since I'd like to knowledgeably approach the resolution to the issue, not magically.

Solution 1:

This is a bit of a complicated Question, so I'll start with the basics. Forgive me if you know all this already.

MTU is the Maximum Transmission Unit, the largest packet of data that a computer interface will send. For Ethernet the default is 1500 Bytes. Ethernet frames typically are allowed to be up to 1522-1542 (depends on what you count) and the extra space is 'reserved' for header information.

Various connections may have different capabilities. It's pretty common to run across a link on the Internet that has an MTU that's slightly smaller than 1500. This is usually due to the link employing extra header information or using a medium other than 'standard' Ethernet (most of the Internet actually runs on ATM/SoNet connections). Normally traffic that encounters such a link is simply broken into multiple pieces and sent along.

Because this is common, and was at the time IP was invented, part of the ICMP protocol's responsibility was to communicate any problems with MTUs. If a packet for any reason couldn't be broken and forwarded, ICMP is used to communicate the problem back to the sending computer. The sending computer takes appropriate action, breaking the information into smaller chunks and everyone is happy. This whole process is handled behind the scenes. In a properly functioning network it is never necessary to muck with MTU settings.

The qualifier on that last sentence is the kicker. There are three common reasons the automated process breaks down:

1. Broken Implementation - The software at some point just plain doesn't work as it should. There's no laws saying people have to follow the relevant standard of the Internet and there are companies who break the standards, usually to be cheap.
2. Administratively disabled implementation - It happens that people with good intentions break software because they don't actually know what they're doing. I've personally seen people block ICMP because they think it's only used for ICMP.0.0 packets (echo, most people know this by the ping utility).
3. Other reasons completely outside this 'normal' process. Mostly commonly this means the connection is so lossy that only shorter packets make it through the connection reliably (or without a massive number of retries). Some early DSL and CableModems had issues like this. And before that, dial-up commonly had problems like this when using very poor quality phone lines and aggressive line codings.

So, why is is common: Lazy technicians/companies. It's almost universally 'easier' to handicap the connection with a tiny MTU than to fix one of the problems outlined above. As stated above nobody should every have to mess with MTU these days (the one exception I can think of being enabling Jumbo frames, but that's really not what we're discussing here). The correct cure in any case is to figure out the underlying problem and fix that; classic case of treat the sickness not the symptom.

How does MTU affect a connection? Chopping the data into tiny pieces means each piece will have a better chance of getting to the destination, especially across highly unreliable connections. Being smaller pieces however, there's more overhead per the data transmitted. This means the effective connection speed is decreased; substantially if the MTU is really small. Latency may be affected, though I would expect it to be minor, because of the extra processing and overhead of the header and fragmentation/reassembly process.

Update: - Regarding --clamp-mss-to-pmtu
Personally I've never mucked about with MTU; I admit I'm a bit of a perfectionist and when presented with ugly hacks like this I always find the root of the problem and have been able to correct it. To that end the iptables option --clamp-mss-to-pmtu is unfamiliar to me. Apparently it is extremely common, and likely very unwarranted in most situations, to use this hack. It is still a hack to compensate for one of the above problems. I quote from the Linux manpage for iptables(8):

This target is used to overcome criminally braindead ISPs or servers which block 'ICMP Fragmentation Needed' or 'ICMPv6 Packet Too Big' packets.

The relatively harsh language of the manpage should be an indication as to how much contempt is garnered by ISPs and Networks who do not follow the RFCs (and make no effort to try or compensate).

Speaking to the use of UDP in VPNs, this used to be most common to minimize the overhead of the VPN and allow the existing endpoints to manage the session information. There's no way for the VPN to know how the session should be handled, so that task is really best left to the applications that know.

Many modern VPN tunneling protocols are built on either lower levels (with even less overhead), such as GRE and L2TP; or tunneled at higher levels (usually for compatibility with restrictive firewalls or other reasons), such as SSTP or SSH. These will gradually replace UDP as a transport mechanism.

Update 2: - Diagnosing MTU/ICMP Problems
So you think you've got a MTU/ICMP issue and want to be sure. There are two basic steps to this process. The directions are for a Linux or BSD box, but can be adapted to just about any OS.

1. Pick an ICMP Ping target (eg Google.com, Yahoo.com, Facebook.com, etc). Try pinging them with the following command: ping -c 2 -s 1472 -D google.com.
   • This should succeed. If it does not succeed, it it should return "packet needs to be fragmented". If either of these are true, stop, your connection works just fine.
   • If this does not return anything, or gives a "timeout" message then you have a problem.
2. For broken connections only: run traceroute -F google.com 1472. This will tell you which hop is broken. Note: it's pretty common for CPE to not respond to traceroute requests, so don't be alarmed if the first hop doesn't respond.
   • Whichever is the last hop to respond is the last one that is working correctly for you.
   • If none of them respond it's your CPE or DSL line (figuring out which can be a bit tricky, but it's almost never CPE if it's modern). Note: If your connection works fine, traceroute will complete successfully.

On a side note: What ISP uses PPTP these days?! That's a blast from the antiquated and useless past. They should at least be using PPPoE; but simply authorizing the modem by MAC and Segment would be so much easier (easier for both the ISP and Customer).