Re: [NANOG] Microsoft.com PMTUD black hole?
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
I'm not sure what the issue is here. Just about every modern firewall I've used has an option to enable PMTU on interfaces, while blocking all other ICMP. Is MS not running something manufactured in the last 10 years at their perimeter?
-----Original Message----- From: Nathan Anderson/FSR [mailto:nathana@fsr.com] Sent: Wednesday, May 07, 2008 12:39 PM To: Valdis.Kletnieks@vt.edu Cc: nanog@merit.edu Subject: Re: [NANOG] Microsoft.com PMTUD black hole?
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
Tomas L. Byrnes wrote:
I'm not sure what the issue is here.
Just about every modern firewall I've used has an option to enable PMTU on interfaces, while blocking all other ICMP.
Is MS not running something manufactured in the last 10 years at their perimeter?
Not sure, but you actually entered in here to a subthread of the original conversation, this one about other possible ways of dealing with black hole "ICMP-munchers" in a pre-emptive fashion. I had a brainstorm that I thought would be workable, which is what we were discussing here. Apparently, it turns out my idea was no good. ;-) The original discussion about MS blocking ICMP to their own servers, which is the discussion it sounds like you are looking for, is over that-a-way... *points* -- Nathan Anderson First Step Internet, LLC nathana@fsr.com
On 5/7/08, Tomas L. Byrnes <tomb@byrneit.net> wrote:
I'm not sure what the issue is here.
Just about every modern firewall I've used has an option to enable PMTU on interfaces, while blocking all other ICMP.
Is MS not running something manufactured in the last 10 years at their perimeter?
Unless things have changed drastically since we parted ways, it's a simple ACL applied on all edge interfaces. It should be possible for them to modify it to allow the list of ICMP subtypes listed at http://www.cymru.com/Documents/icmp-messages.html It would *certainly* make troubleshooting easier for the poor folks at Microsoft, since one side effect of the edge filter being set that way meant we couldn't traceroute outside the network; the port unreachable messages never made it back, so everything outside the edge routers was all just stars. Of course, that was in a former lifetime, so it's entirely possible and probable things have changed considerably since then. ^_^;; Matt (speaking only for myself, not for my current employer, and most certainly not for my previous employer who I'm still somewhat bitter at, not having gotten any of my hardware back yet...)
participants (3)
-
Matthew Petach -
Nathan Anderson/FSR -
Tomas L. Byrnes