[157452] in North American Network Operators' Group
Re: IP tunnel MTU
daemon@ATHENA.MIT.EDU (Dobbins, Roland)
Mon Oct 22 21:49:51 2012
From: "Dobbins, Roland" <rdobbins@arbor.net>
To: NANOG list <nanog@nanog.org>
Date: Tue, 23 Oct 2012 01:49:21 +0000
In-Reply-To: <E1829B60731D1740BB7A0626B4FAF0A65E0DF5CC68@XCH-NW-01V.nw.nos.boeing.com>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Oct 23, 2012, at 5:24 AM, Templin, Fred L wrote:
> Since tunnels always reduce the effective MTU seen by data packets due to=
the encapsulation overhead, the only two ways to accommodate
> the tunnel MTU is either through the use of path MTU discovery or through=
fragmentation and reassembly.
Actually, you can set your tunnel MTU manually.
For example, the typical MTU folks set for a GRE tunnel is 1476.
This isn't a new issue; it's been around ever since tunneling technologies =
have been around, and tons have been written on this topic. Look at your v=
arious router/switch vendor Web sites, archives of this list and others, et=
c.
So, it's been known about, dealt with, and documented for a long time. In =
terms of doing something about it, the answer there is a) to allow the requ=
isite ICMP for PMTU-D to work to/through any networks within your span of a=
dministrative control and b) adjusting your own tunnel MTUs to appropriate =
values based upon experimentation.
Enterprise endpoint networks are notorious for blocking *all* ICMP (as well=
as TCP/53 DNS) at their edges due to 'security' misinformation propagated =
by Confused Information Systems Security Professionals and their ilk. Be s=
ure that your own network policies aren't part of the problem affecting you=
r userbase, as well as anyone else with a need to communicate with properti=
es on your network via tunnels.
-----------------------------------------------------------------------
Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>
Luck is the residue of opportunity and design.
-- John Milton
