[Babel-users] Coexistence of multiple babel daemons on the same host

[Daniel Gröber]

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