[74793] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: I-D on operational MTU/fragmentation issues in tunneling

daemon@ATHENA.MIT.EDU (Sabri Berisha)
Thu Oct 14 11:33:44 2004

Date: Thu, 14 Oct 2004 17:33:24 +0200
From: Sabri Berisha <sabri@cluecentral.net>
To: Pekka Savola <pekkas@netcore.fi>
Cc: nanog@nanog.org
In-Reply-To: <Pine.LNX.4.44.0410111104020.30360-100000@netcore.fi>
Errors-To: owner-nanog-outgoing@merit.edu


On Mon, Oct 11, 2004 at 11:12:55AM +0300, Pekka Savola wrote:

Hi Pekka and others,

> Please send comments to me by the end of this week, either on- of
> off-list, as you deem appropriate.

With the risk of stating the obvious I would say that normally, PMTUD
should do the trick. Afterall, there is no real difference between the
lower MTU of a tunnel and the lower MTU of any other link. With this in
mind, the real problem can be found on networks and hosts that block
ICMP-host-unreachables (or simply all ICMP traffic for "security"
reasons). Taking this one step further, one might realise that we (as
networking community) are looking for a technical solution to compensate
for the lack of knowledge of the end-user administrators or webmasters.

In my work I have been using tunnels quite a lot, and have delt with a
lot if issues regarding PMTUD problems. For end-users behind a tunnel,
the best solution is usually to turn PMTUD off completely, such as 

[root@bofh root]# sysctl -w net.inet.tcp.path_mtu_discovery=0
net.inet.tcp.path_mtu_discovery: 1 -> 0

on a FreeBSD box. I agree that this is far less efficient than it should
be, but that's always the flipside of the tunnel-coin. Another option
would be to simply strip the DF bit on your tunnel entrance point, but
that would be rather undesirable.. 

-- 
Sabri Berisha, SAB666-RIPE              - I route, therefore you are
http://www.cluecentral.net              - http://www.virt-ix.net

home help back first fref pref prev next nref lref last post