MTU

Fri Jul 22 14:53:00 UTC 2016

On Fri 2016-Jul-22 14:01:36 +0200, Baldur Norddahl <baldur.norddahl at gmail.com> 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 
talking about backup over transit and possibly $deity-knows-where paths, 
TBH I might just lean towards pinning your L3 MTU inside the tunnel to 1500 
bytes and configuring IP fragmentation post-encap.  Not pretty, but 
probably fewer chances for WTF moments than trying to push >1500 on a 
transit path.

This *might* be coloured by my past fights with having to force GRE through 
a 1500-byte path and trying to make that transparent to transit traffic, 
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

-- 
Hugo Slabbert       | email, xmpp/jabber: hugo at slabnet.com
pgp key: B178313E   | also on Signal
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20160722/e6707ead/attachment.sig>