Tomas L. Byrnes wrote:
> As far as who Iljitsch is, everyone misspeaks from time to time. Even
> those of us who have been at this for nearly 3 decades.
I was simply LOLing at the fact that you found it necessary to give him
a link to the NetHeaven article is all. ;-)
--
Nathan Anderson
First
Iljitsch van Beijnum wrote:
> The problem is in the direction from M$ to you, so you can't fix that
> from your end. I wonder if they've installed SP3 on their servers...
Ah, you are right. I re-read the section on black-hole detection in
http://technet.microsoft.com/en-us/library/bb878081.aspx
Tomas L. Byrnes wrote:
> Some Edumacation on the topic is here:
You do know who it is that you are responding to, right? :)
http://www.oreillynet.com/pub/au/970
--
Nathan Anderson
First Step Internet, LLC
[EMAIL PROTECTED]
___
NANOG mailing list
NAN
Tomas L. Byrnes wrote:
> The remedy you have below is NOT the only one, and is, in fact, a
> non-sequitur in this case.
How so? Iljitsch is suggesting that ICMP blockers originate packets
without DF set if they are going to block the ICMP messages that PMTUD
needs in order to work in the firs
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 ac
[EMAIL PROTECTED] 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 rou
Here is a brief update on the situation:
I have been in contact with someone at Microsoft's service operations
center, who has confirmed for me that MS does in fact block _all_ ICMP
at the edge of their network, that they are aware that this will in fact
break PMTUD, and that they have no curre
Iljitsch van Beijnum wrote:
> No. This would add significant delay because you'd have to give the
> other side enough time to respond to the large packet (also sending a
> large packet on something like GPRS/EDGE is a waste of bandwidth and
> battery power) while if there is ICMP filtering, the
Tomas L. Byrnes wrote:
> Interestingly, Windows XP, Sp3, released today, describes changes in
> PMTUD behavior.
>
> Black Hole Router detection is now on by default:
As I pointed out in my post earlier today timestamped at 2:29PM, I was
using an XP SP3 host to perform my tests with, and it made
All,
A member of Microsoft's GNS network escalations team saw my postings on
NANOG about this issue and took offense at my use of this forum to raise
this issue with them, and criticized me as being unprofessional and
lacking in business acumen.
Therefore, I would like to publicly apologize fo
Nathan Anderson/FSR wrote:
[...]
> connections to that one host? Maybe even send out an MTU - 40 ICMP
:s/40/sized. Brain fart.
--
Nathan Anderson
First Step Internet, LLC
[EMAIL PROTECTED]
___
NANOG mailing list
NANOG@nanog.org
h
Iljitsch van Beijnum wrote:
> A more common approach is to rewrite the MSS option in all TCP SYNs
[snip]
Yeah, we do this now, but the software that we have been using for PPPoE
termination as well as for a huge portion of our clients (MikroTik
RouterOS) doesn't do it correctly in my estimat
Brandon Butterworth wrote:
> I used to see it a lot when hosting on windows was popular and people
> realised they needed a firewall or decided to add a load balancer
> but broke PMTUD by leaving it enabled on the servers.
Yeah, but this is Microsoft's OWN server farm we are talking about here,
see it, I'm happy to post it.)
Thanks,
--
Nathan Anderson
First Step Internet, LLC
[EMAIL PROTECTED]
Original Message
Subject: Microsoft/MSN/Live!/Hotmail behind blackhole router?
Date: Thu, 01 May 2008 19:00:46 -0700
From: Nathan Anderson/FSR <[EMAIL PROTECTED]>
To:
14 matches
Mail list logo
