PMTU and Broken Servers

Leo Bicknell bicknell at
Thu May 8 14:29:48 UTC 2003

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:


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.

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)?
Am I just being an idiot and missing something obvious?

       Leo Bicknell - bicknell at - CCIE 3440
        PGP keys at
Read TMBG List - tmbg-list-request at,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <>

More information about the NANOG mailing list