Maximum Transfer Unit (MTU)

mustapha.chaab_2 · ‎04-16-2010

Hi all

I was wandering if anyone came across the same TCP traffic behaviour.
There are about 30 sites in Europe. There are 3000 people working on thoses sites.
All are connected through a cisco router to the MPLS network.
The configuration of all routers is one standard configurations

When ping from PC

C:\>ping www.google.com -l 1500 -f
Pinging www.l.google.com [209.85.229.147] 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 209.85.229.147:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:\>ping www.google.com -l 1400 -f

Pinging www.l.google.com [209.85.229.147] with 1400 bytes of data:
Reply from 209.85.229.147: bytes=64 (sent 1400) time=45ms TTL=47
Reply from 209.85.229.147: bytes=64 (sent 1400) time=53ms TTL=47
Reply from 209.85.229.147: bytes=64 (sent 1400) time=44ms TTL=47
Reply from 209.85.229.147: bytes=64 (sent 1400) time=46ms TTL=47

Ping statistics for 209.85.229.147:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 44ms, Maximum = 53ms, Average = 47ms

Router cisco Cisco IOS Software, 3800 Software (C3845-ADVIPSERVICESK9-M), Version 12.4(15)T6,

Have made a test with ISP they can not ping
lan with df set size 1500,but it is susseful with 1400
before evey think as working fine till l get this error in my router
%C3800_ENVM-3-MFAIL_OFF : There is more than one failure with the Power System
[dec] or this Power System has been turned off.
since than users cannot browse from internet

I have filtered my packet captures on specific TCP conversation and after downloading it into Wireshark
There are some lost packets which are followed by 'TCP previous segment lost packets'
(TCP packet arrives with a sequence number greater than the "next expected sequence number')
however they are never retransmitted. The peer doesn't send either TCP duplicated ACKs requesting retransmission of the lost packets.
I believed that in TCP connection needs to ACK every single packets and lost packet will always be retransmitted.
Could anyone please advise.

andrew.prince · ‎04-17-2010

This can be a common issue - when a TCP handshake takes place, the MSS is negotiated between the 2 hosts. The lowest MSS value wins - once they have the setting ALL DATA in the packets will confirm to this size. However some systems/applications will send this maximum amount AND set the DF (Do not fragment) bit in the TCP header. Now if the packet traverses a device that cannot pass the packet as it's to big - it will drop it, as the packet has instructed the device to no fragment it.

Now to address your output of:-

When ping from PC

C:\>ping www.google.com -l 1500 -f
Pinging www.l.google.com [209.85.229.147] with 1500 bytes of data:
Packet needs to be fragmented but DF set.

You are trying to ping a remote host using 1500 bytes of data, and you are telling any device along the way to not fragment it. The local PC TCP/IP stack will report you need to fragement it. You need to consider overheads, TCP headers, IP headers, Ethernet Frame Headers etc. To find the optimum MTU (Maximum Transmissible Unit) perform you test again, each time you see "Packet needs to be fragmented but DF set" drop the data down 1 point

mustapha.chaab_2 · ‎04-17-2010

Hi Andrew

C:\>ping www.google.com -l 1470 -f

Pinging www.l.google.com [209.85.229.104] with 1470 bytes of data:
Reply from 209.85.229.104: bytes=64 (sent 1470) time=56ms TTL=48
Reply from 209.85.229.104: bytes=64 (sent 1470) time=45ms TTL=48
Reply from 209.85.229.104: bytes=64 (sent 1470) time=47ms TTL=48
Reply from 209.85.229.104: bytes=64 (sent 1470) time=47ms TTL=48

Ping statistics for 209.85.229.104:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 45ms, Maximum = 56ms, Average = 48ms

That`s fine a this point now but, I understand perfectly your explanations. which means

We have to apply it to the interface with this command ip tcp adjust-mss

but samething weird why before has been working fine

without ip tcp adjust-mss and this command is not part of our standard configuration.

There must be an explanation why a router worked and then stopped working without any config change.

when mtu was as default

Regards

andrew.prince · ‎04-17-2010

Before you make config changes - you should perform packet captures to see what MSS is being negotiated, and why the DF is being set. You also need to confirm which device is not passing the large packet, I use mtruroute (search google).

Once you know the device and the MSS - you will then be able to acurately calculate the optimum tcp adjust-mss value.