MSS on router, why?

Christian,

My understanding is as below :

This is be sure that TCP packets with improper MSS is not dropped on a router configured for PPPoE.

It helps to get around the problem when path MTU doesn't work between server and the client. By default, modern servers disable fragmentation and try to use path MTU discovery, but sometimes the system administrators block the ICMP notifications from client (to protect server from ICMP DoS attack). So both hosts send packets with MSS equal to their MTU. When a large packet reaches a device (like router) interface with smaller MTU, the packet is dropped, since by default fragmentation is disabled.

"tcp adjust-mss" feature enables the configuration of the MSS for transient TCP packets when PPPoE is being used in the network. PPPoE truncates the Ethernet MTU 1492, and if the effective MTU on the hosts is not changed, the router in between the host and the server can terminate the TCP sessions. The ip tcp adjust-mss command specifies the MSS value on the intermediate router of the SYN packets to avoid truncation.

HTH Prashant

That is one of the scenarios where TCP ADJUST-MSS may be used. Physical links with MTU restrictions, GRE tunnels, IPSEC tunnels may also be a problem. Any router-to-router link that imposes an MTU limitation smaller than 1500 bytes [or smaller than the client/server's MTU] can trigger PMTU discovery problems.

As you know, it is the packet size itself that is the problem. Not an "improper MSS" carried within the packet.

In case the OP does not understand path MTU discovery...

What happens is that the client (or server) sends a full sized packet. Typically the client and server will be on Ethernet LANs with 1500 byte MTU. So they will send 1500 byte IP packets containing

1460 byte TCP segments.

With PMTU discovery enabled (the default), these packets will go out with the "DF" (Don't Fragment) bit set. This instructs all intervening routers not to try to fragment the packet. If a router needs to forward the packet over a link with an MTU less than 1500 bytes, that router is supposed to drop the packet and send an ICMP "fragmentation needed but DF set" datagram back to the sender.

In normal circumstances, the sender gets the "fragmentation needed" datagram, adjusts the MSS for the connection and retransmits a smaller packet (the "fragmentation needed" datagram tells the sender how much smaller he needs to go to get past the problematic hop). This exercise repeats until the sender discovers a packet size that is small enough to make it all the way to the receiver without fragmentation.

If the router doesn't send this "fragmentation needed" datagram or if some over-zealous firewall administrators on the path are blocking ICMP or if various other problems arise, this datagram may not make it back to the sender. The sender will keep retransmitting his 1500 byte packet and the router will keep dropping the retransmissions.

I had trouble following this paragraph.

The "tcp adjust-mss x" feature alters the TCP packets that are exchanged when a connection between client and server is set up. The client is told that the server's MSS is x-40. And the server is told that the client's MSS is x-40. (Without reviewing the documentation carefully, I think I recall that you specify adjust-mss in MTU units rather than in MSS units).

Both ends end up sending IP packets that are no more than x bytes in size because the intervening router has spoofed the connection negotiation dialogue and told each end that the other end has smaller than normal MSS restrictions.

The router administrator chooses x to be an MTU size that can go end to end from client to server without requiring fragmentation, thus eliminating any situation in which a PMTU discovery failure could arise.

There are various ways to attack MTU/PMTU problems.

A. Fix the PMTUD problem. Get the "fragmentation needed" datagram back to the sender. If possible, this is the ideal solution. But it may not be possible.

B. Enable fragmentation/reassembly over the encapsulated link (GRE, IPSEC, PPPoE or whatever). This is often not possible. And the resulting fragmentation is undesireable.

C. Enable fragmentation without reassembly. An IP policy route-map can, for instance, clear the DF bit. This may or may not be possible or may be possible in only one direction. The resulting fragmentation is still undesireable. And overzealous firewall administrators may be blocking IP fragments as well as ICMP.

D. Change the MTU and/or MSS on the client or server. I hesitate to even mention this possibility, but it can work.

F. Use adjust-mss. This has the philosophical disadvantage of having the router meddling in a layer it's not supposed to touch. But it works very nicely. I recommend it.

bri

I'm glad I wasn't the only one having some difficulty understanding what Prashant was trying to say here. Despite his (assuming that Prashant is a masculine name) saying it was his "understanding", in fact the confusion arises from what I assume is the standard Cisco text used to describe this parameter as can be found in the "Usage Guidelines" for "TCP MSS Adjustment" on page

I wouldn't be surprised if Pradesh has heard an explanation from a Cisco teacher who was obliged to cover the topic but had only the confused official description to guide him/her and didn't have the background to work out what the official text should have said.

There's actually no evidence that the OP has taken the trouble to Google a bit for the explanation of what the "tcp mss-adjust" parameter does or his query post would have had more focus. A comment to Christian "Google is your friend" - even if, in that case, despite claims to the contrary, understanding could not have been complete.

Thank you for the clarifying the topic to my satisfaction anyhow.

Four very small quibbles:

1. When you use an abbreviation, you should introduce it at the first opportunity together with what is abbreviated. Thus you should have said Path MTU (PMTU) Discovery properly to explain what PMTU means.

1. PMTU Discovery is covered by an RFC so, if you are playing the role of a teacher, it's best to offer your students a chance to read up further. The RFC is 1191 - although I'm never sure whether or not there may have been a more recent RFC for a topic. RFC 1191 is dated

1990 and is referenced in a qualifying RFC, 2923, dated 2000. RFC 2923 is listed as still being useful in an RFC, 4614, dated 2006, so maybe these references are still the valid ones.

1. The proper way to describe the ICMP packet which is supposed to be returned by a router which cannot forward the IP packet which is too large is ICMP type "Destination Unreachable" with a code "fragmentation needed and DF set". Actually your "but" in place of the "and" makes more sense but it's not what Mr Postel wrote in RFC 792.

2. Because ICMP was defined before Path MTU Discovery (1981 and 1990 respectively) and returning the maximum MTU size for the appropriate interface to exit the router was *not* foreseen as a good idea when ICMP/"Destination Unreachable"/"fragmentation needed and DF set" was designed, there exists the possibility that a router may *not* - as you claimed - provide this information so useful to the Path MTU Discovery mechanism[1]. Thus RFC 1191 provides a handy table of the next lower MTU to try based on likely limitations (Table 7-1: Common MTUs in the Internet).

[1] It may be argued with some conviction that any router worth its salt today would know to respect the RFC 1191 enhancement of ICMP/"Destination Unreachable"/"fragmentation needed and DF set".

A fifth point - not a quibble - is that it's important to know about ICMP that, since the only way to describe a problem is to use an ICMP packet sent back to the originator of a packet, if, for whatever reason including short-lived congestion, an ICMP packet needs to be discarded, that's it. In other words, a mechanism which relies on ICMP packets needs to be robust in other ways.

Chris Mas> > > > >> Hello!