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. How to Fix it: TURN OFF MTU PATH DISCOVERY on the server ... or less popular, change filtering to allow the required responses in. It is of course possible to fix the MTU for a specific case, but this never will work for everyone on the Internet. Common Scenarios: This will regularly occur with networks using; - Tunnels (L2TP, GRE, IPIP etc) as the tunnels must have lower MTU than the physical path, to allow it to carry the IP header. - ISDN Routers, where the client has an Ethernet, but the ISDN dialled connection is set to 952 or whatever. - Sites behind small links, where the MTU is tuned for the bandwidth available. This does not occur on dial-up connections, as the client may only have an MTU of 512 bytes, but this is internal to the client, and the original MTU negotiation will prevent a path discovery of packets beyond the MTU of the rest of the path. ps. I hope you are all aware of the problem with clients setting IP packets with a TTL of 32 hops, causing certain locations deep inside Europe to be unreachable. Detail on this problem is on www.netgate.net.nz under the "Too Many Hops Issue" Hope this is useful, Arron Scott Telecom NZ Ltd (But only for three more weeks)
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
participants (2)
-
Arron Scott -
Geoff Huston