Feature request: static routes to not directly connected gateways

[Alexander Demenshin]

On 2014-10-22 22:22, Ondrej Zajicek wrote:

> This works, but the route must have special 'recursive' nexthop.

It seems that there are some issues with this option.

First of all, for interface-recursive route:

> protocol static {
>     route 192.168.90.0/24 via "br0";
>     route 192.168.91.0/24 recursive 192.168.90.10;
> }

On my system (CentOS 7, bird 1.4.5, kernel 3.17.0) this produces no 
route to 192.168.91.0/24,
as route to 192.168.90.0/24 lacks "scope link" and kernel hates this. 
Bird does:

2014-10-23 03:47:04 <TRACE> static1 > added [best] 192.168.90.0/24 dev 
br0
2014-10-23 03:47:04 <TRACE> kernel1 < added 192.168.90.0/24 dev br0
... this works so far but without "scope link", and then it fails:
2014-10-23 03:47:04 <TRACE> static1 > updated 192.168.91.0/24 via 
192.168.90.10 on br0
2014-10-23 03:47:04 <TRACE> kernel1 < replaced 192.168.91.0/24 via 
192.168.90.10 on br0
2014-10-23 03:47:04 <WARN> Netlink: No such process
2014-10-23 03:47:04 <TRACE> static1 > updated [best] 192.168.91.0/24 via 
192.168.90.10 on br0

At this point, there is no route in kernel, but Bird shows this:

# birdc show route
BIRD 1.4.5 ready.
192.168.90.0/24    dev br0 [static1 03:47:03] * (1000)
192.168.91.0/24    via 192.168.90.10 on br0 [static1 03:47:03] ! (1000)

I guess that "!" means something like "not installed" but 
nevertheless...

After manually adding a route, like:

# ip ro add 192.168.90.0/24 dev br0

everything works as expected (as it has "scope link" by default).

Second issue - if there is a default route somewhere, it will be used
when looking for recursive route. On the one hand, this is expected
behavior, on the other hand, it would be nice to have an option
to disable it or otherwise limit recursion level.

Third issue - if recursive gateway is not available, it installs the 
route
as "unreachable", which may (or may not) be a problem depending on 
routing
policy - I prefer to fall through remaining policies, for instance, 
instead
of rejecting, so again, it would be nice to control this somehow.

Fourth issue - Bird does not detect when its own route is deleted, but 
it will
remain active in Bird while it is not active in kernel (this is common 
issue
for all kernel routes installed by Bird).

And finally, this case:

> protocol static {
>     route 192.168.90.0/24 via 192.168.81.1;
>     route 192.168.91.0/24 recursive 192.168.90.10;
> }

This does not work as expected, as it install the following route:

192.168.91.0/24 via 192.168.1.254 dev br0  proto bird

(192.168.1.254 is my default gateway).

It is logical to expect, that, since 192.168.81.0/24 is routed to 
interface:

192.168.81.0/24 dev br0  scope link

then it should use 192.168.81.1 instead of default gateway (again, this 
is
recursion related issue and the fact that non-direct scope link routes 
are
not taken into account).

If 192.168.81.0/24 is a directly connected (which is not always the 
case),
then it will work, of course.

Though, there is another problem... Assuming that 192.168.81.0/24
is directly connected, and if it is removed from the interface,
then route will change to the default gateway (if there is one).

I am not sure if all those issues are bugs or I simply overlook 
something,
but they make "recursive" option a bit useless - though it still could 
be
used for interface based routes (with some care).

If needed, I'll provide all debug logs produced by this research, though
it is easy to reproduce.

Thank you for patience reading so long post :)

--
Best regards,
Alexander.