[190706] in North American Network Operators' Group

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

Re: MTU

daemon@ATHENA.MIT.EDU (Saad Abdullah)
Fri Jul 22 11:19:48 2016

X-Original-To: nanog@nanog.org
In-Reply-To: <CAOOLXZigQiwG-aRhne-R96gbBciSBpn6E6HYA6Xi94rcigmR1Q@mail.gmail.com>
From: Saad Abdullah <saad17621@gmail.com>
Date: Sat, 23 Jul 2016 00:48:08 +1000
To: nanog@nanog.org
Errors-To: nanog-bounces@nanog.org

Worth reading this on choosing MTU on transit link.

http://blog.apnic.net/2014/12/15/ip-mtu-and-tcp-mss-missmatch-an-evil-for-network-performance/

-Sad



>>
>> On Fri, Jul 22, 2016 at 10:01 PM, Baldur Norddahl <
>> baldur.norddahl@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.
>>>
>>> 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
>>>
>>
>>
>

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