[65607] in North American Network Operators' Group
RE: MTU path discovery and IPSec
daemon@ATHENA.MIT.EDU (cproctor@epik.net)
Wed Dec 3 12:17:59 2003
From: cproctor@epik.net
To:
Cc: nanog@merit.edu
Date: Wed, 3 Dec 2003 11:59:53 -0500
Errors-To: owner-nanog-outgoing@merit.edu
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@vt.edu [mailto:Valdis.Kletnieks@vt.edu]
> Sent: Wednesday, December 03, 2003 11:39 AM
> To: jgraun@comcast.net
> Cc: nanog@merit.edu
> Subject: Re: MTU path discovery and IPSec
>
> On Wed, 03 Dec 2003 16:05:39 GMT, jgraun@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).
>
>
