PMTU and Broken Servers

Stephen J. Wilcox steve at
Thu May 8 15:03:15 UTC 2003

On Thu, 8 May 2003, Leo Bicknell wrote:

> I've recently had the pleasure of troubleshooting a problem I don't
> normally have to deal with, and the results don't quite make sense
> to me.  I'm hoping someone can enlighten me as to what is going on.
> A diagram:

I had a rant about this a few months back (as many others have done before me), 
its a combination of ICMP filtering and RFC1918 links on the Internet that cause 

> server---internet---fw---tunnelbox1----tunnelbox2----user
> The tunnel between the tunnelboxes is a lower (1480) MTU.  Originally
> the user couldn't access some servers, turns out the firewall was
> filtering ICMP Can't Fragment messages, preventing PMTU from working
> in the server->user direction (tunnelbox1 would generate Can't
> Fragement, firewall would filter).
> That's been corrected.  Going to a server I control I see good PMTU
> in both directions between the server and the user.  However, there
> are still a number of web servers for popular sites that behave
> just like the firewall was still filtering Can't Fragments.  The
> theory is that the servers are behind a firewall/load balancer that
> is filtering them on the server side -- but I find it slightly
> (emphasis on the slightly) that someone would turn on PMTU discovery,
> and then filter it out right in front of the boxes where they turned
> it on.  Also, it seems to me most DSL users are behind PPPoE links
> with lower MTU, and should get hit by the same problem.
> The temporary hack is to have tunnelbox1 clear the DF bit on all
> incoming packets, which just causes the packets to get fragmented
> going down the tunnel.  A minor performance hit, but it works.

Consider this a permanent hack if you want to keep things working on the 
> This is a new problem to me, but I'm sure people have run into it
> before.  Are the servers really that broken (PMTU enabled, ICMP


> Can't Fragement filtered)?  Does the head end box of DSL services
> generally do something to work around this (ie, clear the DF bit)?

I've wondered this too, not sure but they clearly do something, perhaps they 
encapsulate the packets in fragments then recombine without altering the 
original packet?

> Am I just being an idiot and missing something obvious?


More information about the NANOG mailing list