TCP MSS Clamping – What Is It and Why Do We Need It?
This (not so very) short video explains what TCP MSS clamping is and why we’re almost forced to use it on xDSL (PPPoE) and tunnel interfaces.
TL&DW summary: because Internet-wide Path MTU Discovery rarely works.
More details
- Path MTU discovery was first defined in RFC 1191 (yeah, it’s THAT old and still doesn’t work well);
- You’ll find more PMTUD and fragmentation hands-on details in my Never-Ending Story of IP Fragmentation article;
- Packetization Layer Path MTU Discovery (RFC 4821) is an alternate approach that does not rely on ICMP replies;
- Discovering Path MTU black holes presentation from RIPE65 (video).
Some configuration tips
- TCP MSS clamping can be configured on end hosts or on some routers (on Cisco IOS, use ip tcp adjust-mss interface configuration command).
- The ip tcp adjust-mss functionality on Cisco IOS is bidirectional – MSS option is adjusted in inbound and outbound TCP SYN packets traversing the interface on which ip tcp adjust-mss is configured.
- You should configure ip tcp adjust-mss on interfaces with low MTUs. In other words, MSS value configured on an interface should match MTU value of the same interface minus 40 bytes.
- Configuration examples where ip tcp adjust-mss is configured on Ethernet interface have interesting side effects if the router has more than two interfaces.
(like my $ISP does)
I've never used 'in fast path' as alternative to hardware based forwarding but I like it (cant wait to use it in a team meeting).
Can someone give me a hint to negotiate a PPPoE MTU of >1492 on Cisco IOS. Looks kind of hard to make a Cisco Router ignore the RFC standard MTU...
I heard some Telco's use PPPoE MTU of 1500 (on a Ethernet link of >1510) in stead of 1492 to workaround the MSS clamping...
Oct 15 09:53:10.164: ppp424 PPP LCP: Enter passive mode, state[Stopped]
Oct 15 09:53:10.185: ppp424 LCP: I CONFREQ [Stopped] id 1 len 14
Oct 15 09:53:10.185: ppp424 LCP: MRU 1500 (0x010405DC)
Oct 15 09:53:10.185: ppp424 LCP: MagicNumber 0x2CC6AA92 (0x05062CC6AA92)
Oct 15 09:53:10.185: ppp424 LCP: O CONFREQ [Stopped] id 1 len 18
Oct 15 09:53:10.185: ppp424 LCP: MRU 1492 (0x010405D4)
Oct 15 09:53:10.185: ppp424 LCP: MagicNumber 0x7A4ECDDA (0x05067A4ECDDA)
Oct 15 09:53:10.186: ppp424 LCP: O CONFACK [Stopped] id 1 len 14
Oct 15 09:53:10.186: ppp424 LCP: MRU 1500 (0x010405DC)
Oct 15 09:53:10.186: ppp424 LCP: MagicNumber 0x2CC6AA92 (0x05062CC6AA92)
Oct 15 09:53:10.186: ppp424 LCP: Event[Receive ConfReq+] State[Stopped to ACKsent]
Oct 15 09:53:10.206: ppp424 LCP: I CONFACK [ACKsent] id 1 len 18
Oct 15 09:53:10.206: ppp424 LCP: MRU 1492 (0x010405D4)
Oct 15 09:53:10.206: ppp424 LCP: MagicNumber 0x7A4ECDDA (0x05067A4ECDDA)
Oct 15 09:53:10.206: ppp424 LCP: Event[Receive ConfAck] State[ACKsent to Open]
thanks for the great explanation.
1 question: I usually would prefer setting the "ip tcp adjust-mss" on the LAN Interface of a CE router. Would it also work on the WAN interface when using crypto maps?
To explain: the CE router has a LAN Interface and 2 WAN Interfaces, one pointing to MPLS, one to Internet (for IPSec). I need to set the adjust-mss for only the IPSec Traffic without reducing the value for MPLS traffic. Will it work, if I only set it on the WAN interface pointing to the internet? (IPSec is done with crypto map).
Is it possible to do mss clamping on Juniper MX80?
Thanks,
-Konstantin
where will you need to add the mss clamping on if your client is connecting over a layer 2 vpn tunnel over ipsec?
As James Mickens said: "In a word: Don't".
If you really really think you need L2VPN then make sure the underlying MTU is big enough to support all the extra headers.
1.1.1.1 does DNSSEC if you don't want to trust Google with even more of your data...