[190713] in North American Network Operators' Group
Re: MTU
daemon@ATHENA.MIT.EDU (=?utf-8?Q?=C5=81ukasz_Bromirski?=)
Fri Jul 22 14:35:21 2016
X-Original-To: nanog@nanog.org
From: =?utf-8?Q?=C5=81ukasz_Bromirski?= <lukasz@bromirski.net>
Date: Fri, 22 Jul 2016 20:35:14 +0200
In-Reply-To: <520e997e-9c83-3d1c-b99b-b818e3ea3b16@Janoszka.pl>
To: Grzegorz Janoszka <Grzegorz@Janoszka.pl>, nanog@nanog.org
Errors-To: nanog-bounces@nanog.org
> On 22 Jul 2016, at 19:37, Grzegorz Janoszka <Grzegorz@Janoszka.pl> wrote:
>=20
>> On 2016-07-22 15:57, William Herrin wrote:
>> On a link containing only routers, you can safely increase the MTU to
>> any mutually agreed value with these caveats:
>=20
> What I noticed a few years ago was that BGP convergence time was faster wi=
th higher MTU.
> Full BGP table load took twice less time on MTU 9192 than on 1500.
> Of course BGP has to be allowed to use higher MTU.
Quite obvious thing - BGP by default on Cisco and Juniper will use up to max=
allowed 4k message per packet, which for typical unicast IPv4/v6 helps to p=
ack all attributes with prefix. This not only improves (lowers) CPU load on=
sending side but also on the receiving end and helps with routing convergen=
ce.
There was a draft to use up to 9k for BGP messaging, but I belive it's burie=
d somewhere on the outside of town called "our current version RFC".
--=20
=C5=81ukasz Bromirski=
