Re: MTU issues ?

cyberpete · ‎05-26-2005

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 172.16.1.254 -f -l 1500

Pinging 172.16.1.254

Packet needs to be fragmented but DF set.

Ping statistics for 172.16.1.254:

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 172.16.1.254 -f -l 1250

Pinging 172.16.1.254

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

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

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

Ping statistics for 172.16.1.254:

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

Peter@it-123.co.uk

Richard Burts · ‎05-26-2005

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.

HTH

Rick

HTH

Rick

barisal · ‎05-26-2005

Hi;

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.

Baris.

rlcarr · ‎05-26-2005

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,

~Ron

wkumari · ‎05-26-2005

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...

steveo123 · ‎05-26-2005

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.

Steve'o

johansens · ‎06-05-2005

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:

http://www.cisco.com/en/US/tech/tk827/tk369/technologies_tech_note09186a0080093f1f.shtml

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

http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d6979.shtml

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

http://support.microsoft.com/default.aspx?scid=kb;en-us;898060