From: Guyler, Rik (rguyler@shp-dayton.org)
Date: Thu May 26 2005 - 12:20:11 GMT-3
I think you hit the nail on the head. Clearly the DF bit error message is
telling and is further supported that a 1250-byte packet gets through. If
you support all of the in-between boxes then you can check them for MTU on
the interfaces. Otherwise, you can probably set the Mtu on the client down
to a smaller value as a workaround.
Another but possibly more painful option is to force fragmentation, which
ignores the DF bit value. Usually the DF bit is set for a reason so this is
not always wise but it could be worth a try...
Rik
-----Original Message-----
From: Peter P [mailto:nobody@groupstudy.com]
Sent: Thursday, May 26, 2005 10:03 AM
To: cisco@groupstudy.com
Subject: MTU issues? [7:99709]
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.
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 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 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
This archive was generated by hypermail 2.1.4 : Fri Jun 03 2005 - 10:12:02 GMT-3