Constant delete / add route after upgrade to 1.6.3

[Ondrej Zajicek]

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."