Coexistence of multiple babel daemons on the same host
Hi Babelers, I've just come across a reason I'd want to run babel with both bird and babeld on the same node and have them become neighbours. The details are tedious -- my usual disclamer applies ;) This got me to think about something I'd observed in the past and been meaning to write about though: when I accidentally had both babeld and bird running on a node it would casuse severe route flapping and consequently packet loss. I wonder if we can do better here? Maybe by warning about this situation in the logs, shutting down both sides or just turning this into a supported use-case? :)
From what I gather by a quick skimming of the relevant details in RFC8966 this could work by assigning each daemon a unique LL address so each gets it's own entry in the neighbour table, right?
Thanks, --Daniel
I've just come across a reason I'd want to run babel with both bird and babeld on the same node and have them become neighbours.
I hope you know what you're doing. The simplest solution would be to run each daemon in a different container. If you don't want to use containers, you'll want to use separate routing tables for the two daemons, and then set up the correct routing rules. First configure the routing rule: ip rule add lookup 42 then run babeld in table 42: import-table 42 export-table 42
From what I gather by a quick skimming of the relevant details in RFC8966 this could work by assigning each daemon a unique LL address so each gets it's own entry in the neighbour table, right?
No, there's no relation between the link-local address and the routing table. -- Juliusz
Hi Juliusz, On Sun, Mar 31, 2024 at 04:35:28PM +0200, Juliusz Chroboczek wrote:
I've just come across a reason I'd want to run babel with both bird and babeld on the same node and have them become neighbours.
I hope you know what you're doing.
I sure hope so too, haha. No it's really quite benign. Just working around BIRD still not being quite as featureful as I need to run my network but babeld's non-atomic route replacement interacting badly with BIRD's proto/radv. See below.
The simplest solution would be to run each daemon in a different container.
Yeah, I am always trying to avoid that to keep things simple and manageable for me. Keep in mind my reason for even raising this on the MLs and not just shooting patches is that I think the current UX is broken. I don't want "accidentally running two babel daemons" to cause a network outage like it did for me.
If you don't want to use containers, you'll want to use separate routing tables for the two daemons, and then set up the correct routing rules. First configure the routing rule:
I just want to import routes into bird for use with radv "trigger". These aren't going to get exported anywhere at all so no need for multiple routing tables in the kernel and all that. I do appreciate you taking the time to write down how to do it however :)
From what I gather by a quick skimming of the relevant details in RFC8966 this could work by assigning each daemon a unique LL address so each gets it's own entry in the neighbour table, right?
No, there's no relation between the link-local address and the routing table.
*neighbour table*. I think the crux of the issue I was seeing is that both daemons will use eg. fe80::1 to source their babel hellos and since the neighbour table is indexed by this address whoever sees both of these announcements will experience "fighting" over who gets to own that entry or something? I'm not actually sure, should have probably kept some pcaps from when this was going on. Let me know if this makes no sense to you and I'll try to recreate the circumstances. After some careful reading of the BIRD code I've actually found I can set the LL saddr it uses using `protocol device { interface "eth0" { preferred fe80::1234; }; }` so I think I can actually get this working without code changes. I'm labbing that now. Thanks, --Daniel
Just working around [...] babeld's non-atomic route replacement interacting badly with BIRD's proto/radv.
I guess we could revive atomic updates in babeld, perhaps the buggy kernels it didn't work with are no longer relevant.
*neighbour table*. I think the crux of the issue I was seeing is that both daemons will use eg. fe80::1 to source their babel hellos
Oh, you're running both babeld and BIRD on the same interface? I assumed you were running them on different interfaces. I'm really not sure if it can be made to work. -- Juliusz
On Sun, Mar 31, 2024 at 11:34:43AM +0200, Daniel Gröber wrote:
Hi Babelers,
I've just come across a reason I'd want to run babel with both bird and babeld on the same node and have them become neighbours. The details are tedious -- my usual disclamer applies ;)
If you want to have both bird and babeld on the same node and have them neighbors, you could create veth pair, assign bird to one end and babeld on the other end. You probably should use different routing tables for each (as Juliusz Chroboczek noted) and they should use different set of interfaces. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
participants (3)
-
Daniel Gröber -
Juliusz Chroboczek -
Ondrej Zajicek