Showing results for 
Search instead for 
Did you mean: 

MTU issues ?

I have a local user accessing a server several hops away (an html based client/server application).

This apps fails 75% of the time (we seem to get an HTTP RST RESET on the sniffer). But otherwise things "look" ok - there's no firewall in between - and only some minor layer 3 packet filtering on the intervening cisco routers. Could MTU be part of the problem in the forwarding path - enough to stuff the app?

(I use rfc1918 private addresses below not the real ones for anonymity)

Here I try to send icmp packets to the remote server at 1500 bytes length...

C:\>ping -f -l 1500


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

Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

Approximate round trip times in milli-seconds:

Minimum = 0ms, Maximum = 0ms, Average = 0ms

THEN I try same with byte length at 1250 - and now it doesn't need to break the packets

C:\>ping -f -l 1250


Reply from bytes=1250 time=62ms TTL=122

Reply from bytes=1250 time=32ms TTL=123

Reply from bytes=1250 time=47ms TTL=123

Reply from bytes=1250 time=47ms TTL=123

Ping statistics for

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 32ms, Maximum = 62ms, Average = 47ms

? What can be concluded from this exercise - that somewhere in the path the packets need to be fragmented and this causes enough latency to make the app fail intermittently?

Is the default MTU size set too high ?

Where ? On one of the interveing routers ?

Could this trash the app?

...........thanks for any meaningful input on this

Richard Burts
Hall of Fame Guru

Your exercise certainly demonstrates that somewhere along the path some device is needing to fragment packets that are 1500 bytes long.

The need to fragment could certainly impact the client server application using HTTP. If the data being exchanged is using smaller packets then it works and when it has more data to exchange and uses larger packets it may fail.

Is it possible that there is more than one path between the client and the server, so that some times large packets work and some times large packets fail? (this would certainly explain the intermittent nature of the problem.)

You might experiment with lowering the segment size on the client (which will impact the MTU). Or you might experiment with the ip tcp adjust-mss command on the router interface. Using the adjust-mss command will over-ride the value offered by the end station and result in lower MTU being used.






Besides Rick's suggestion, you can also use "ip tcp header-compression" to get a lower a IP packet size. But this may not help to you, because this helps with a high tcp-header bytes to lower the packet size. You should know the attribute of your application.



Couple of comments:

1. When you ping with the -l 1500, you are telling PING to use a payload of 1500, not an MTU of 1500. Your header alone require an additional 20 bytes. So you are realling asking ping to send a 1520 byte packet. You may also need to account for other "wrappers" in your network (Encryption, GRE, PPP, etc).

2. If you use PING with the -r (record) from your PC (also available on the router in extended mode) you can traceroute your pings to see where they fail.

Happy Routing,



There is a piece of software called Dr TCP that will let you lower the MTU / MSS on your windows box. Try that and see if the problem goes away. If it does the issues is definatly MTU realted...


O.K here is a very quick and easy solution if you dont know how many hops and the mtu settings in between the paths, just enter the following command on the routers global config.

ip tcp path-mtu-discovery

plus adjusting tcp-mms size to 1460 under the ethernet interface would help.



MTU-issues are a recurring problem in many setups where there are VPN or tunneling involved.

Cisco has made a white-paper on this here:

And another on IP fragmentation and PMTUD (more technical and indepth):

Another interesting sidenote is that Windows 2003 w/SP1 (or Hotfix MS05-019) has some issues in this regard:;en-us;898060