Re: MSS on router, why?
- From: briggs@xxxxxxxxxxxxxxxxx
- Date: 19 Mar 2007 09:21:38 -0500
In article <1174146544.678412.289050@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>, prashant.goud@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.
.
- Follow-Ups:
- Re: MSS on router, why?
- From: Chris Mason
- Re: MSS on router, why?
- References:
- MSS on router, why?
- From: christian maier
- Re: MSS on router, why?
- From: prashant . goud
- MSS on router, why?
- Prev by Date: Re: frame-relay multilink
- Next by Date: Need help with adtran if possible.
- Previous by thread: Re: MSS on router, why?
- Next by thread: Re: MSS on router, why?
- Index(es):
Relevant Pages
|
