Revision as of 21:16, 17 November 2010

>== Explanation of MTU Path Discovery ==

For sending bulk data, the Internet generally works better when using larger packets. Each packet implies a routing decision, when sending a 1 megabyte file, this can either mean around 700 packets when using packets that are as large as possible, or 4000 if using the smallest default.

However, not all parts of the Internet support full 1460 bytes of payload per packet. It is therefore necessary to try and find the largest packet that will 'fit', in order to optimize a connection.

This process is called 'Path MTU Discovery', where MTU stands for 'Maximum Transfer Unit.'

When a router encounters a packet that's too big too send in one piece, AND it has been flagged with the "Don't Fragment" bit, it returns an ICMP message stating that it was forced to drop a packet because of this. The sending host acts on this hint by sending smaller packets, and by iterating it can find the optimum packet size for a connection over a certain path.

This used to work well until the Internet was discovered by hooligans who do their best to disrupt communications. This in turn lead administrators to either block or shape ICMP traffic in a misguided attempt to improve security or robustness of their Internet service.

What has happened now is that Path MTU Discovery is working less and less well and fails for certain routes, which leads to strange TCP/IP sessions which die after a while.

Setting MTU Manually by Route

When you encounter sites that suffer from this problem, you can disable Path MTU discovery by setting it manually.

When having problems connecting to an IRC server, make sure outgoing masqueraded traffic started with the lower mtu of the outside link while keeping local ethernet traffic with a normal mtu (for things like nfs traffic). In the example below 192.168.0.1 is the gateway address.

 ip route add default via 192.168.0.1 mtu 296

If only a certain subnet is problematic, PMTU Discovery can be overridden by setting a specific route.

 ip route add 195.96.96.0/24 via 192.168.0.1 mtu 1000

Circumvention MTU Path Discovery Using MSS Clamping

This is useful for ADSL subscribers using PPPoE. I recently upgraded from my old CAP router to a new DMT router also forcing me to embrace PPPoE. There were problems immediately.

Besides MTU, there is yet another way to set the maximum packet size, the so called Maximum Segment Size. This is a field in the TCP Options part of a SYN packet.

Recent Linux kernels, and a few PPPoE drivers (notably, the excellent Roaring Penguin one), feature the possibility to 'clamp the MSS'.

The good thing about this is that by setting the MSS value, you are telling the remote side unequivocally 'do not ever try to send me packets bigger than this value'. No ICMP traffic is needed to get this to work.

There is a pitfall to this, however, and it will be explained... someday.

Doing this requires iptables-1.2.1a and Linux 2.4.3 or higher. This solution is only modern 2.4.x kernel users connected via ANY type of Internet connection. This solution allows for changes to be done ONLY on the MASQ server itself and not on all of the internal MASQ clients. It is useful for users connected to the Internet via a PPPoE DSL or Cablemodem connections when the PPPoE is handled by the CPE and not the Linux firewall.

PPPoE users may note some ISPs and WWW sites filter critical ICMP packets like MTU Path Discovery. Because of this, many users might find more Internet sites work but others hang or work poorly. Fortunately, recent IPTABLES have added PMTU Clamping support which should help you. If your using IPTABLES and think you're hitting this issue, try adding the following line to the end of your rc.firewall-iptables rules. This will calculate proper MSS for your link.

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

Although the above is recommended, another approach is to set the MSS of passing SYN packets to 128. Use this if you have VoIP with tiny packets, and huge http packets which are causing chopping in your voice calls.

 iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 128

Use one or the other.

sources:

• Linux Advanced Routing & Traffic Control HOWTO
• http://howtos.linux.com/howtos/Adv-Routing-HOWTO/index.shtml

Linux IP Masquerade HOWTO

• http://www.linux.org/docs/ldp/howto/IP-Masquerade-HOWTO/index.html

______________________________________________________________________________

• Sat Jul 30 08:58:43 CDT 2005