Thus spake "Lasher, Donn" <[EMAIL PROTECTED]>
PMTU Black Hole Detection works well in my experience, but unfortunately
MS doesn't turn it on by default, which is where all of the L2VPN with
<1500
MTU issues come from; turn BHD on and the problems just go away... (And,
as others have noted, there's better PMTUD algorithms that are designed to
work _with_ black holes, but IME they're not really needed)
I wish I'd had your experience. PMTU _can_ work well, but on the internet
as
a whole, far too many ignorant paranoid admins block PMTU, mostly by
accident, causing all sorts of unpleasantness.
You can't block PMTUD per se, just the ICMP messages that dumber
implementations rely on. And, as I noted, MS's implementation is dumb by
default, which leads to the problems we're all familiar with. "PMTU Black
Hole Detection" is appropriately named; one registry change* and a reboot is
all you need to solve the problem. Of course, that's non-trivial to
implement when there's hundreds of millions of boxes with the wrong
setting...
Clearing DF only takes you so far. Unless both ends are aware, and respond
apppropriately to the squeeze in the middle, you're back to square one.
Smarter implementations still set DF. The difference is that when they get
neither an ACK nor an ICMP, they try progressively smaller sizes until they
do get a response of some kind. They make a note of what works and continue
on with that, with the occasional larger probe in case the problem was
transient.
In fact, one could consider Lorier's "mtud" to be roughly the same idea;
it's only needed because the stack's own PMTUD code is typically bypassed
for on-subnet destinations and/or not as smart as it should be.
S
* HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\
Parameters\EnablePMTUBHDetect=1
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov