tcp mss adjust calculation for GRE tunnel over DSL line

hasmurizal · ‎11-11-2009

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?

Collin Clark · ‎11-11-2009

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.

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.

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

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

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.

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.

hasmurizal · ‎11-11-2009

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?

Collin Clark · ‎11-11-2009

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.

hasmurizal · ‎11-11-2009

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.

hasmurizal · ‎11-11-2009

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)