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.