nanog mailing list archives

RE: MTU path discovery and IPSec


From: cproctor () epik net
Date: Wed, 3 Dec 2003 11:59:53 -0500


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).




Current thread: