11-11-2009 07:37 AM
hi guys,
need your advice on this one, as i search on cisco.com and netpro but unable to find the exact info that i required.
First, can anyone confirm the following calculation to find out MSS size.
Mss size = MTU size - encapsulation size - tcp header size
So for normal case;
MSS = 1500 - 48 (48 is the tcp/ip header)
so MSS = 1452
Thus in my case GRE tunnel over DSL connection;
MSS = 1492 - 24 - 48 (24 is the GRE encap; 48 is the tcp/ip header)
MSS = 1420
is this correct?
Secondly, where should the ip tcp mss-adjust to be implemented. Is it at the Dialer(DSL) interface or at Tunnel interface?
11-11-2009 08:33 AM
I don't use the math (it doesn't work for me probably b/c I miss something). Here's how I do it-
C:\>ping 10.125.0.250 -f -l 1600
Pinging 10.125.0.250 with 1600 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Ping statistics for 10.125.0.250:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
C:\>ping 10.125.0.250 -f -l 1500
Pinging 10.125.0.250 with 1500 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Ping statistics for 10.125.0.250:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
C:\>ping 10.125.0.250 -f -l 1400
Pinging 10.125.0.250 with 1400 bytes of data:
Reply from 10.125.0.250: bytes=1400 time=19ms TTL=251
Reply from 10.125.0.250: bytes=1400 time=19ms TTL=251
Reply from 10.125.0.250: bytes=1400 time=19ms TTL=251
Reply from 10.125.0.250: bytes=1400 time=19ms TTL=251
Ping statistics for 10.125.0.250:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 19ms, Maximum = 19ms, Average = 19ms
C:\>ping 10.125.0.250 -f -l 1450
Pinging 10.125.0.250 with 1450 bytes of data:
Reply from 10.125.0.250: bytes=1450 time=19ms TTL=251
Reply from 10.125.0.250: bytes=1450 time=20ms TTL=251
Reply from 10.125.0.250: bytes=1450 time=19ms TTL=251
Reply from 10.125.0.250: bytes=1450 time=19ms TTL=251
Ping statistics for 10.125.0.250:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 19ms, Maximum = 20ms, Average = 19ms
C:\>ping 10.125.0.250 -f -l 1475
Pinging 10.125.0.250 with 1475 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Ping statistics for 10.125.0.250:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
C:\>ping 10.125.0.250 -f -l 1470
Pinging 10.125.0.250 with 1470 bytes of data:
Reply from 10.125.0.250: bytes=1470 time=19ms TTL=251
Reply from 10.125.0.250: bytes=1470 time=22ms TTL=251
Reply from 10.125.0.250: bytes=1470 time=20ms TTL=251
Reply from 10.125.0.250: bytes=1470 time=19ms TTL=251
Ping statistics for 10.125.0.250:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 19ms, Maximum = 22ms, Average = 20ms
C:\>
1470 works and has a little bit of extra room. The tcp mss-adjust should be done on the LAN interface.
Hope it helps.
11-11-2009 09:13 AM
Hi collin,
thank you for your response. perhaps i did not explain a little bit more on this. since i'm on the provider side, that is why i cannot test this from the user/LAN side via ping test.
Our customer bring up this matter as one of their application unable to work. This only happens if the router using the backup line (primary serial down). If we were to apply into the LAN interface that it would interfere with other apps. (LAN interface = MTU of 1500)
So that is why i wanted to know on the calculative part rather than trial-and-error type guessing mss size. anybody have ideas on this?
11-11-2009 09:21 AM
You should not change the MTU on your side, it will be on their side only. They can decrease the MTU, but you should not. They can test using my example above. I understand you're trying to help your customer, but by decreasing the MTU in your network you may break other customers. Your one customer should reduce their MTU to fit inside your network MTU. If you reduce your MTU, the customer would have to reduce theirs even more or experience more fragmentation. Their packets with the additional header(s) need to fit in your MTU so you can transfer them without fragmenting them.
11-11-2009 09:39 AM
well, i dont think that changing the MTU size at customer part is doable, since this happen at a particular application (site to HQ via GRE tunnel) and on our MPLS cloud. So we can only see the change to be done on CE router and only to MSS size, not to MTU.If CE main link (leased line/metro-e)is in working state, there are no problem, but only when link is on DSL, only then customer can see the problem.
Any chance you have several test routers to test? From my side i cant since it is a live network.
11-11-2009 10:05 AM
just remember one of the links with respect to tcp mass-adjust
http://www.cisco.com/en/US/tech/tk827/tk369/technologies_tech_note09186a0080093f1f.shtml
if taken example of the given link above; i could conclude that:
if tunnel MTU is 1400 then
MSS = 1400 - 40 -24 (40 is tcp/ip header;24 GRE encap)
MSS = 1336
and this to be place on Tunnel interface (DSL CE router)
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide