Hot Diggety! Doug Hughes was rumored to have written: > > Unless the firewall is actively blocking ICMP, I wouldn't worry too > much about MTU. The Path MTU discovery should take care of all of > that.
Well, the catch is, *any* point between sender and recipient host that blocks the certain ICMP messages required to make PMTUD (Path MTU Discovery) work will cause PMTUD to fail and may result in interesting effects. Years ago, I debugged a very strange and very non-obvious NNTP feeding issue after a peer complained we weren't sending them a robust amount of data. I finally broke out a packet sniffer and eventually figured out what was going on. An intermediate host was blocking the ICMP messages in question but in such a way that it essentially silently failed, causing packets to be effectively blackholed. This was partially due to the sending host having a non-Ethernet MTU as it was on a FDDI ring (4470 bytes or some such?). The sending host, not aware of the lower MTU, kept trying to stuff a 4470 byte packet into a 1500 byte hole. That isn't a recipe for success. Voila! Packet gets dropped on the floor -- instant blackholing. Small-enough packets made it through, just not the larger ones. Hence the peer's complaint of a lower-than-expected amount of data coming through. I've also seen PMTUD fail when you run into certain tunnelling or VPN situations -- basically a non-standard (Ethernet-wise) MTU due to tunnel/VPN header overhead -- and overaggressive ICMP filtering. That report was also interesting: "I can browse eBay but I keep losing auctions because when it comes to snipe time, I can't usually fully load the page." Some five hours later, with IOS tweaks, it worked again. Mainly to lower the MTU on the VPN interface by the extra bytes it needed. As a result of such fun debugging, I tell folks to generally leave ICMP unfiltered unless they know *exactly* what they're doing. :-) (Or at least, to just filter out *specific* ICMP messages they don't want such as echo or ttl-exceeded, but leave the rest untouched.) -Dan _______________________________________________ Tech mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
