[190702] in North American Network Operators' Group
Re: MTU
daemon@ATHENA.MIT.EDU (Hugo Slabbert)
Fri Jul 22 10:53:04 2016
X-Original-To: nanog@nanog.org
Date: Fri, 22 Jul 2016 07:53:00 -0700
From: Hugo Slabbert <hugo@slabnet.com>
To: Baldur Norddahl <baldur.norddahl@gmail.com>
In-Reply-To: <CAPkb-7AOoQ4=7cCuqwN96u-q5cBsr6q1aTnQ8sxW83LNqcjb2g@mail.gmail.com>
Cc: nanog@nanog.org
Errors-To: nanog-bounces@nanog.org
--W/nzBZO5zC0uMSeA
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri 2016-Jul-22 14:01:36 +0200, Baldur Norddahl <baldur.norddahl@gmail.c=
om> wrote:
>Hi
>
>What is best practice regarding choosing MTU on transit links?
>
>Until now we have used the default of 1500 bytes. I now have a project were
>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. But
>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.
If you're just doing this for the GRE overhead and given that you're=20
talking about backup over transit and possibly $deity-knows-where paths,=20
TBH I might just lean towards pinning your L3 MTU inside the tunnel to 1500=
=20
bytes and configuring IP fragmentation post-encap. Not pretty, but=20
probably fewer chances for WTF moments than trying to push >1500 on a=20
transit path.
This *might* be coloured by my past fights with having to force GRE through=
=20
a 1500-byte path and trying to make that transparent to transit traffic,=20
but there you have it...
>On the other hand, none of my customers will see any actual difference
>because they are end users with CPE equipment that expects a 1500 byte MTU.
>Trying to deliver jumbo frames to the end users is probably going to end
>badly.
>
>Regards,
>
>Baldur
--=20
Hugo Slabbert | email, xmpp/jabber: hugo@slabnet.com
pgp key: B178313E | also on Signal
--W/nzBZO5zC0uMSeA
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBCgAGBQJXkjNMAAoJEFsnhBAb2KmARVEP/2RiCr0qV+cKE/FtIVIR/frU
fjo4/zQlJ2Gb0IZ3UUGPI9CGxNS+98yOUjL+9ngb4heCYsfmPYfpVOghHDi6TB++
72b13W7CqSwl3mc3UP9EiKynFFkf3m31ymdiw5JKGdqJAf1PYaJ2RJN7yL4BGaVP
15cEG1FJpS/+nErtWlVNOi/W/qzEdmO3J64JhRmt010VkKB0MYUWS0mWcG1Q+1+I
oA9JLoi88NANc3hPXsjWB4m26v2dokxzDrHcUvGvLUF1iuRLGPgfaSsskEIoVvuw
00Xy7IRgIuSn947TfKhiP6v4w8sAz7iVcNMzpPv1Ii2ATMmxKUpKXbHW/OuVCa6l
w+k6MabM6mbMcy1iVaBXk1nZFBNyFUAK3E32ZJTLSQ092McdAj8+2sb7iypRp5vr
9q+wr56Lhibe8WFtmROjWDStZi/wn5HTwPUBMvkLfFNAVeD2NyxHw6dMAv3Z+wk4
Kls1ptwOtA/LH8TjWeCQ6P+O7uCqVIBWYXohUB85yHEdZpCIPPKrNqpdnFtQTGRY
Tn2dw7VjQYx5gVGYnreIAgMel6pk8xsBiauP8Cb+qUXiXjFb0Z9WRZVP/5oE83Vk
cMsPHlPezKoS21qwyfsYxAlgstJsCzT7mq7mT/BZ90Kv/ClMO05ecpcT40dYg+MT
cbKSIOtk4PO7qbRZwfgi
=bUp3
-----END PGP SIGNATURE-----
--W/nzBZO5zC0uMSeA--
