[NANOG] Microsoft.com PMTUD black hole?
Iljitsch van Beijnum
iljitsch at muada.com
Tue May 6 15:26:46 CDT 2008
On 6 mei 2008, at 21:58, Brandon Butterworth wrote:
>> Has anyone else here seen problems with microsoft/msn/hotmail/
>> sites not performing PMTUD correctly?
> 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.
> I've not heard of it for some time so those people got
> a clue or moved to something else (or everyone worked around them)
Many years ago I had occasion to terminate dial-up service over L2TP
from modem pools operated by a service provider who shall remain
nameless to protect the guilty. This service had the unfortunate
tendency to drap all packets larger than 576 bytes. So we needed to
negotiate a 576-byte MTU over PPP.
We then got many complaints from users who dialed in using ISDN
routers (yes this was a while ago) because of broken path MTU
discovery. The behavior that Microsoft exhibits was EXTREMELY common
in those days, and I have no reason to assume it's any less common
today. (I also see it regularly with IPv6.) What I did was clear the
DF bit on packets going out to the L2TP virtual interfaces so the
packets could be fragmented.
A more common approach is to rewrite the MSS option in all TCP SYNs
with a smaller value so there won't be TCP segments large enough to
trigger the problem. AFAIK, all boxes that do PPPoE do this.
All of this even went so far that the IETF came up with RFC 4821,
which will do path MTU discovery by correlating lost packets with
packet sizes to determine the path MTU rather than depend on ICMP
More information about the NANOG