Re: MSS on router, why?
- From: "Chris Mason" <chrismason@xxxxxxxxxxxx>
- Date: 20 Mar 2007 09:28:16 -0700
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
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t4/ft_admss.htm
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.
2. 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.
3. 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.
<g>
4. 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 Mason
On Mar 19, 3:21 pm, bri...@xxxxxxxxxxxxxxxxx wrote:
In article <1174146544.678412.289...@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>, prashant.g...@xxxxxxxxx writes:
On 17 Mar, 07:12, christian maier <christian3...@xxxxxxxx> wrote:
Hello!
What is MSS on a router good for?
Usually the client -> server send their MSS in the SYN packet.
So why do I need ip tcp adjust-mss on a router?
Thanks.
Christian
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.
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.
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.
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.
"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.
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.- Hide quoted text -
- Show quoted text -
.
- References:
- MSS on router, why?
- From: christian maier
- Re: MSS on router, why?
- From: prashant . goud
- Re: MSS on router, why?
- From: briggs
- MSS on router, why?
- Prev by Date: Re: Switch randomly drops connection to port
- Next by Date: Re: Switch randomly drops connection to port
- Previous by thread: Re: MSS on router, why?
- Next by thread: Las mejores Tarifas Internacionales
- Index(es):
Relevant Pages
|
