Path MTU Discovery Issues

Issues with different MTUs on a network path can be extremely hard to debug. Usually they are caused by some router in between not sending ICMP messages if a package is to big (or these messages being filtered on their way back). Typical symptoms are that you can "ping" a host and you can also establish a connection and transfer some data, but sometimes the connection stalls (e.g. a website is not loaded completely).

Luckily, if you have a Linux system somewhere in the path, there is a way to fix this problem, which I discovered in the Linux Advanced Routing & Traffic Control HOWTO.

You can use the following IPTables rules:

iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS  --clamp-mss-to-pmtu # IPv4
ip6tables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS  --clamp-mss-to-pmtu # IPv6

I use -I instead of -A because this rule should be the first rule in the FORWARD chain, so that it is applied to all packets passing through.

If you are experiencing MTU related problems, you might also be interested in some informationen regarding the MTU setting for 6to4 tunnels and OpenVPN virtual private networks. You should try the fixes described there first (if applicable), because using the clamp MSS options is more of a last resort then a best practice.

MTU and MSS Explained

If you wonder why TCP connections work sometimes, even if path MTU discovery is broken, you might be interested in a very interesting article in the ThousandEyes blog. Thanks to the colleague who pointed me to this article!

Find the MTU for a Certain Path

The MTU for a certain path can be found with ping (I found these instructions at http://www.dslreports.com/faq/695):

Windows:

ping -f -l 1472 <target>

Linux:

ping -s 1472 <target>

macOS:

ping -D -s 1472 <target>

Add 28 to the largest number with which the ping is successful. The resulting number is the MTU.

Tags: Network
    

Need help?

If you need help with XWiki you can contact: