Feature request: static routes to not directly connected gateways
Hi, It would be nice to be able to use "indirect" gateways, i.e. which are routed via interface but are not part of interface networks, like this: protocol static { route 10.1.1.0/24 via "eth0"; route 10.2.1.0/24 via 10.1.1.1; } Linux supports this, so it would be really useful and opens interesting opportunities, like automatically adding routes once specified gateway becomes reachable after adding an interface-bound route (either outside or inside of Bird). One possible application (from my actual configuration) is routing of specific networks through VPN gateway - the gateway itself is in /30 transfer network (and this could not be changed easily) so I could not make it reachable directly on more than one Bird router simultaneously. Please consider this for next release :) Thank you! -- With best regards, Alexander.
On Wed, Oct 22, 2014 at 08:10:06PM +0200, Alexander Demenshin wrote:
Hi,
It would be nice to be able to use "indirect" gateways, i.e. which are routed via interface but are not part of interface networks, like this:
protocol static { route 10.1.1.0/24 via "eth0"; route 10.2.1.0/24 via 10.1.1.1; }
Hi This works, but the route must have special 'recursive' nexthop. In that case its nexthop is resolved through the table and found route is used for nexthop, combined with the original nexthop in the case where found nexthop is a device: protocol static { route 192.168.90.0/24 via 192.168.81.1; route 192.168.91.0/24 recursive 192.168.90.10; } bird> show route 192.168.81.0/24 dev eth0 [direct1 21:56:40] * (240) 192.168.90.0/24 via 192.168.81.1 on eth0 [static1 21:57:36] * (200) 192.168.91.0/24 via 192.168.81.1 on eth0 [static1 21:56:40] * (200) protocol static { route 192.168.90.0/24 via "eth0"; route 192.168.91.0/24 recursive 192.168.90.10; } bird> show route 192.168.81.0/24 dev eth0 [direct1 21:56:39] * (240) 192.168.90.0/24 dev eth0 [static1 22:00:20] * (200) 192.168.91.0/24 via 192.168.90.10 on eth0 [static1 22:08:54] * (200) -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@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."
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.
participants (2)
-
Alexander Demenshin -
Ondrej Zajicek