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