[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/ 
>> live.com
>> 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 mailing list