[104341] in North American Network Operators' Group
Re: [NANOG] Microsoft.com PMTUD black hole?
daemon@ATHENA.MIT.EDU (Nathan Anderson/FSR)
Wed May 7 15:38:38 2008
Date: Wed, 07 May 2008 12:38:32 -0700
From: Nathan Anderson/FSR <nathana@fsr.com>
To: Valdis.Kletnieks@vt.edu
In-Reply-To: <30937.1210187359@turing-police.cc.vt.edu>
Cc: nanog@merit.edu
Errors-To: nanog-bounces@nanog.org
Valdis.Kletnieks@vt.edu wrote:
> The usual case where you get screwed over is when the router trying to toss
> the ICMP FRAG NEEDED is *behind* the ICMP-munching firewall. And in case (2),
> you still can't assume that path MTU == local MTU, because your local MTU is
> likely 1500, and the fragging router often trying to stuff your 1500 byte
> packet down an PPPoE tunnel that's got an MTU of 1492....
Yes, but my point was precisely that one OR the other side (server OR
client) is going to NOT have the ICMP-munching firewall in between
itself and the "RITM" as I have affectionately been calling it (although
it is definitely possible that there are two ICMP-munchers on either
side of the RITM).
And case #2 is exactly what is occurring right now _anyway_: hosts
assume that path MTU == local MTU even if there is already an active
PMTU cache entry from a recent earlier communication with the remote
host. So I don't see how making that assumption _after_ making an
honest attempt at actively determining whether or not it is actually the
case is any more broken than they way things are already being done.
The problem is that, as I realized at the end of the message you quoted,
there are potentially multiple paths between the same two hosts, and the
path that the packet takes in one direction is not guaranteed to be the
same path that the packet takes in the opposite direction.
--
Nathan Anderson
First Step Internet, LLC
nathana@fsr.com
_______________________________________________
NANOG mailing list
NANOG@nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog
