MTU path discovery and IPSec
cproctor at epik.net
cproctor at epik.net
Wed Dec 3 16:59:53 UTC 2003
The problem is described pretty clearly at
http://www.cisco.com/warp/public/105/56.html. The issue I have
experienced is that fragmentation can lead to performance impacts that are
unacceptable.
I wish we could start a clue campaign informing people why ICMP should not
be summarily dumped at the firewall.
Chris Proctor
EPIK Communications
> -----Original Message-----
> From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu]
> Sent: Wednesday, December 03, 2003 11:39 AM
> To: jgraun at comcast.net
> Cc: nanog at merit.edu
> Subject: Re: MTU path discovery and IPSec
>
> On Wed, 03 Dec 2003 16:05:39 GMT, jgraun at comcast.net said:
>
> > 1) I assume MTU path discovery has to been in enabled on
> each router in the path in order for it work correctly?!
>
> Actually, no. All that's required is that:
>
> a) The router handle the case of a too-large packet with the
> DF bit set by
> sending back an ICMP 'Dest Unreachable - Frag Needed' packet.
> I've never
> actually encountered a router that didn't get this part
> right. (Has anybody ever
> seen a router botch this, *other* than a config error covered
> in (b) below?)
>
> b) said ICMP makes it back to the originating machine. This
> is where all the
> operational breakage I've ever seen on PMTU Discovery comes
> from. And in almost
> all cases, one of two things is at fault. Either some
> bonehead firewall admin
> is "blocking all ICMP for security" (fixable by reconfiguring
> the firewall to
> let ICMP Frag Needed error messages through), or some
> bonehead network provider
> numbered their point-to-points from 1918 space and the ICMP
> gets ingress/egress
> filtered (this one is usually not fixable except with a baseball bat).
>
>
More information about the NANOG
mailing list