Filter babel routes on a per-neighbor or per-interface basis
Hi, is there any possibility to filter incoming babel routes on a per-neighbor or per-interface basis? As far as I can tell, the babel implementation in bird has its own route selection algorithm and only sends a single route to the bird table. This seems to make it impossible to add additional route filters (for example: adding extra penalty to specific routes received on a specific babel interface), because with regular filters only the already pre-selected route in the bird table is changed. Also, this makes it impossible to use ECMP with babel. Would it be possible to send all feasible babel routes to the bird table? Best regards, Fabian
Fabian Bläse <fabian@blaese.de> writes:
Hi,
is there any possibility to filter incoming babel routes on a per-neighbor or per-interface basis?
As far as I can tell, the babel implementation in bird has its own route selection algorithm and only sends a single route to the bird table. This seems to make it impossible to add additional route filters (for example: adding extra penalty to specific routes received on a specific babel interface), because with regular filters only the already pre-selected route in the bird table is changed.
You are right, this is not currently possible. Babeld does have this capability, so maybe adding an equivalent filter type to Bird which can drop or modify updates before they are handed over to babel's route selection logic would be useful.
Also, this makes it impossible to use ECMP with babel.
Babel (the protocol) does not support ECMP. This is deliberate - see this message for details: https://mailarchive.ietf.org/arch/msg/babel/i4tqsRIL3DS9e22GJ0QuoMef-P0/
Would it be possible to send all feasible babel routes to the bird table?
I don't think this would be the right approach; rather, there should be a filtering step before routes are input into the babel route selection, as mentioned above. And possibly adding an output filter so routes can be modified on a per-interface basis would make sense as well? -Toke
On 22.07.21 20:17, Toke Høiland-Jørgensen wrote:
Babel (the protocol) does not support ECMP. This is deliberate - see this message for details: https://mailarchive.ietf.org/arch/msg/babel/i4tqsRIL3DS9e22GJ0QuoMef-P0/
Ok, thanks for the clarification. I haven't had side effects in mind. I naively assumed, that all feasible routes are usable.
Would it be possible to send all feasible babel routes to the bird table?
I don't think this would be the right approach; rather, there should be a filtering step before routes are input into the babel route selection, as mentioned above. And possibly adding an output filter so routes can be modified on a per-interface basis would make sense as well?
This would make things a bit less intuitive. But as the route selection isn't done in the main table anyway, adding a filtering step before babel route selection probably is the cleanest solution. My suggestion is quite hacky indeed. Best regards, Fabian
On Thu, Jul 22, 2021 at 08:17:54PM +0200, Toke Høiland-Jørgensen wrote:
Would it be possible to send all feasible babel routes to the bird table?
I don't think this would be the right approach; rather, there should be a filtering step before routes are input into the babel route selection, as mentioned above. And possibly adding an output filter so routes can be modified on a per-interface basis would make sense as well?
Hi I think that (optionally) pushing all feasible routes to the BIRD table seems like an interesting idea. It would be relatively easy (by using the same mechanism that is here for BGP ADD-PATH). Babel already requires importing the selected route back in order to announce it to peers, so it would be possible to move best route selection completely to the BIRD table (by moving some logic from babel_select_route() to babel_rte_better()). It also has some unortodox applications, like using different feasible routes for different routing tables with rule-based routing. But disadvantage is that it would require having two distinct modes of operation (the current one and this new one). Adding import (and perhaps export) per-interface filters is also an interesting idea. I thought about it in the past in context of RIP, but one obstacle is that the filtering code assumes it runs on struct rte, so you would need to convert it back and forth between struct rte and struct babel_route. The advantage is that it would integrate easily into current mode of operation. Seems to me that these two approaches are not exclusive and try to solve slightly different use cases.
Also, this makes it impossible to use ECMP with babel.
Babel (the protocol) does not support ECMP. This is deliberate - see this message for details: https://mailarchive.ietf.org/arch/msg/babel/i4tqsRIL3DS9e22GJ0QuoMef-P0/
Some notes to ECMP: First, it is kind of unrelated to whether we send multiple routes to the main table. On the contrary, ECMP in BIRD in general works that protocol merges feasible routes to one route with ECMP next hop and such route is propagated to the main table. So sending multiple non-merged routes to the main table is problematic for ECMP (it is done by BGP, where we do not have 'internal BGP table'). Second, i do not think there is a strong reason to not support ECMP in Babel. It is true that for ad-hoc wifi networks it is probably not that advantageous, but Babel has also support for running on traditional wired networks (fixed rxcost, k-out-of-j selection for failure detection) and there ECMP makes full sense. -- 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."
participants (3)
-
Fabian Bläse -
Ondrej Zajicek -
Toke Høiland-Jørgensen