static default route not always pushed to kernel (2.0.4)

[Ondrej Zajicek]

On Mon, Apr 29, 2019 at 12:14:56PM +0000, Kenth Eriksson wrote:
> Hi!
> 
> There are cases where bird does not push a static default route to the
> kernel. One way to see this is as follows;
> 
> Next remove both static routes, configure, add one of them back again
> and both are shown.
> 
> bird> show route for 0.0.0.0
> Table master4:
> 0.0.0.0/0            unicast [static1 14:13:16.762] * (255)
> 	via 10.210.137.1 on eth1
>                      unicast [kernel1 13:46:07.958] (215)
> 	via 10.210.137.1 on eth1

Hi

Yes, BIRD on Linux intentionally avoids replacing any existing non-BIRD
(alien) routes in kernel tables.

The reason is: Consider route A from BIRD and alien route B, both for the
same network. A is preferred in BIRD and therefore pushed to kernel,
where it replaces route B. Therefore, route B is overwritten and
disappears. Then route A is for some reason removed, but route B no
longer exists, so it cannot be restored and we end with no route.

There are two ways how to fix that: one way is that kernel would remember
all alien routes it learned, even when they were replaced by BIRD route.
This would solve the problem above, but has other issues (e.g. the
original source of alien route may want update or remove it, but it is
no longer in kernel table).

The approach we use is that we expect to have dedicated kernel metric
value (by default 32) that is not used by alien routes (as kernel table
keeps multiple routes with different kernel metric). This works well
with IPv6, where default kernel metric used by alien routes is higher
(256 or 1024) but in IPv4 the default kernel metric is 0 (most preferred),
so we cannot override such routes without replacing them. The answer is
to create alien routes with higher kernel metric (easy when created with
'ip' tool, perhaps harder in other cases). It would be great if there
existed sysctl option for default IPv4 route metric.

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