|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: PMTU and Broken Servers
Thus spake "Stephen J. Wilcox" <[email protected]> > You mean theres routers which get a large packet and silently drop it rather > than return an icmp? > > Curious as to know which vendors? (read fundementally broken!) Well, most core routers rate-limit the ICMP messages they generate, so any given packet may not result in a Needs-Fragmentation error. If the result is consistent, however, you're likely dealing with an ACL or broken loadbalancer as Leo describes: > > On Thu, 8 May 2003, Leo Bicknell wrote: However, there > > > are still a number of web servers for popular sites that behave > > > just like the firewall was still filtering Can't Fragments. The > > > theory is that the servers are behind a firewall/load balancer that > > > is filtering them on the server side -- but I find it slightly > > > (emphasis on the slightly) that someone would turn on PMTU discovery, > > > and then filter it out right in front of the boxes where they turned > > > it on. Also, it seems to me most DSL users are behind PPPoE links > > > with lower MTU, and should get hit by the same problem. The problem here is that the Needs-Frag error comes back as an ICMP, and many load balancers don't bother looking inside at the offending packet to determine which server to forward the error to. Why do these people use PMTUD? It's on by default, and you have to muck with the registry (or the unix equivalent) to disable it, at which point you're better off enabling PMTU Black Hole Detection. Hopefully BHD will also be default someday. Most network folk have found it's easier to provide 1500 MTU than to educate all of the server operators and end users as to what's going wrong with PMTU. This is also, IMHO, the only significant reason jumbo frames aren't in widespread use -- we have no reliable means of coping with networks that remain at 1500 MTU. S
|