[190704] in North American Network Operators' Group
Re: MTU
daemon@ATHENA.MIT.EDU (Vincent Bernat)
Fri Jul 22 11:13:39 2016
X-Original-To: nanog@nanog.org
From: Vincent Bernat <bernat@luffy.cx>
To: Baldur Norddahl <baldur.norddahl@gmail.com>
Date: Fri, 22 Jul 2016 15:01:50 +0200
In-Reply-To: <CAPkb-7AOoQ4=7cCuqwN96u-q5cBsr6q1aTnQ8sxW83LNqcjb2g@mail.gmail.com>
(Baldur Norddahl's message of "Fri, 22 Jul 2016 14:01:36 +0200")
Cc: nanog@nanog.org
Errors-To: nanog-bounces@nanog.org
=E2=9D=A6 22 juillet 2016 14:01 CEST, Baldur Norddahl <baldur.norddahl@gma=
il.com>=C2=A0:
> Until now we have used the default of 1500 bytes. I now have a project we=
re
> we peer directly with another small ISP. However we need a backup so we
> figured a GRE tunnel on a common IP transit carrier would work. We want to
> avoid the troubles you get by having an effective MTU smaller than 1500
> inside the tunnel, so the IP transit carrier agreed to configure a MTU of
> 9216.
>
> Obviously I only need to increase my MTU by the size of the GRE header. B=
ut
> I am thinking is there any reason not to go all in and ask every peer to =
go
> to whatever max MTU they can support? My own equipment will do MTU of 9600
> bytes.
You should always match the MTU of the remote end. So, if your transit
carrier configured 9126 on its side, you should do the same on
yours. There is no MTU discovery at the L2 layer: if you setup the MTU
of your interface at 9600 and you happen to route a 9500-byte packets,
it will be silently dropped by your transit carrier.
--=20
Test input for validity and plausibility.
- The Elements of Programming Style (Kernighan & Plauger)
