A more detailed discussion of the problem is at http://users.worldgate.ca/~marcs/mtu/ and the recommendation there is "FIX YOUR FILTERS!" (my emphasis) (Actually the issue of using the interface MTU as the path MTU for non-local connections is also broken - I recall RFC 1122 (host requirements) saying that the host is to use the lesser of 576 and the first-hop MTU as the Path MTU for any destination that is not on the same subnet as the host. Why some idiot implementor decided to ignore this and opt for interface MTU beats me - its just asking for problems!) At 03:38 PM 5/16/00, Arron Scott wrote:
Hi all,
As this is a discussion forum for Network Operations people in NZ, I thought I would raise a little problem that I regularly see around the network. I am not pointing this at anyone in NZ in specific, it's just FYI. Hopefully most of you will already know about this.
The problem: Clients can ping Web Servers running MTU Path Discovery but cannot HTTP.
Why: At HTTP connect time, MTU is negotiated as the lowest set on the interfaces between server and client, for both using Internet this would be 1500 bytes.
After that the server attempts to do MTU Path Discovery, by sending the largest agreed packet marked "DO NOT FRAGMENT". If there is a circuit somewhere along the path that is smaller than that packet size, the router is expected to drop the packet, and return ICMP Unreachables, with the "COULD NOT FRAGMENT" message attached. The server should then try a smaller packet.
Unfortunately it is common for sites to filter the ICMP Unreachables, which the server never sees, and it spends it's life resending MTU Discovery Packets forever.
--------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog