Constant delete / add route after upgrade to 1.6.3

[Xavier Trilla]

Hi Ondrej,

Thanks for your reply, know I see why it's done this way. But Im wondering, could that lead to packed loss or the remove/add is fast enough? I mean, we just push to the kernel the best paths, so in this scenario a destination could be without a destination for a brief period of time, or the update is fast enough to not even affect a high traffic connection? 

The alternative I'm seeing is publishing all routes to kernel with weights, but that's something I would like to avoid (I don't want to publish several million routes to the kernel :/ )

Thanks!

Saludos Cordiales,
Xavier Trilla P.
Clouding.io

¿Un Servidor Cloud con SSDs, redundado
y disponible en menos de 30 segundos?

¡Pruébalo ahora en Clouding.io!

-----Mensaje original-----
De: Ondrej Zajicek <santiago at crfreenet.org> 
Enviado el: miércoles, 9 de mayo de 2018 15:48
Para: Xavier Trilla <xavier.trilla at clouding.io>
CC: Maria Jan Matějka <jan.matejka at nic.cz>; bird-users at network.cz
Asunto: Re: Constant delete / add route after upgrade to 1.6.3

On Tue, May 08, 2018 at 08:29:06PM +0000, Xavier Trilla wrote:
> Hi Maria,
> 
> For what I'm seeing, looks like every time birds gets a route update via BGP the route is replaced, I enabled debug in kernel protocol and I'm seeing this:
> 
> 2018-05-08 22:20:32 <TRACE> icewall_01_BGP > added [best] 
> 80.84.147.0/24 via 172.17.0.1 on vlan10
> 2018-05-08 22:20:32 <TRACE> icewall_01_BGP < rejected by protocol 
> 80.84.147.0/24 via 172.17.0.1 on vlan10
> 2018-05-08 22:20:32 <TRACE> kernel1 < replaced 80.84.147.0/24 via 
> 172.17.0.1 on vlan10
> 2018-05-08 22:20:32 <TRACE> icewall_01_BGP > added [best] 
> 78.40.178.0/24 via 172.17.0.1 on vlan10
> 2018-05-08 22:20:32 <TRACE> icewall_01_BGP < rejected by protocol 
> 78.40.178.0/24 via 172.17.0.1 on vlan10
> 2018-05-08 22:20:32 <TRACE> kernel1 < replaced 78.40.178.0/24 via 
> 172.17.0.1 on vlan10
> 2018-05-08 22:20:32 <TRACE> icewall_01_BGP > added [best] 
> 64.17.246.0/23 via 172.17.0.1 on vlan10
> 2018-05-08 22:20:32 <TRACE> icewall_01_BGP < rejected by protocol 
> 64.17.246.0/23 via 172.17.0.1 on vlan10
> 2018-05-08 22:20:32 <TRACE> kernel1 < replaced 64.17.246.0/23 via 
> 172.17.0.1 on vlan10
> 
> 
> But does it make sense? I mean, deleting and reading the route to replace it when a route update is received doesn't seem to make much sense considering the gateway does not change.

Hi

It is true that we send a route to the kernel if there is any change in the route, even if the change is irrelevant for the kernel itself. They may be export filters in kernel that are dependent on any route attributes so it is hard to predict whether the change is relevant or not.

> Also, I guess removing and adding the route again could lead to some packet loss.

We could use replace netlink operation instead of remove/add, but that has some other problems (like insufficient protection against overwriting alien routes).

> Maybe bird needs to keep some information in the route in order to keep sync and that's why it needs to replace it? Or there is anything I'm missing...

We could keep that information but that essentialy means double memory footprint for simple setups.

--
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."