babeld
babeld copied to clipboard
jech
feature request: add support for specifying interface with glob
In my particular deployment of babeld together with wireguard, to work around the limitation of the wireguard routing model, namely AllowedIPs, I had to create an interface for each peer. Thus for the addition and removal of peers, I can only regenerate the configuration file for babeld then restart it, leaving an annoying time window before the routes converge again. I think it would be nice if support for specifying interface with glob can be added to babeld, especially for the growing deployments of wireguard .
I'd much rather we had babeld support Wireguard out of the box. The plan is the following:
- support a mode of operation where no automatic discovery happens;
- monitor peers discovered by Wireguard, and add them automatically to the neighbours table with the right parameters.
It's number 4 on my todo list, so please don't hold your breath.
Due to the cryptokey routing nature of wireguard, it's bound to be a tough task to integrate any routing daemon with wireguard without efforts from their side. I checked the documents from freifunk and nycmesh, which should be among the largest mesh networks utilizing wireguard, and found no better solution other than creating a separated interface for each peer and set ::/0 and 0/0 as the allowed ips. Despite that this approach takes a whole range of udp ports, it works flawlessly, not needing any changes from routing daemons. Thus, for now, I think it might be easier to implement dynamic interfaces and wait for the required efforts to be poured into wireguard. Still, maybe we can just formalize the local configuration interface of babeld, and let external helpers do the heavy lifting.
Please propose a patch, it's difficult to discuss stuff in a void.
Still, maybe we can just formalize the local configuration interface of babeld, and let external helpers do the heavy lifting.
We already have — see the -G command-line option.
Still, I think that Wireguard is an important piece of infrastructure, and I'd be quite willing to accept ad-hoc support for it in babeld. The best thing would be to disable neighbour discovery in babeld, and use Wireguard to inform us about new neighbours (we'd still be doing link quality estimation, of course). Let me know if you wish to work on that.
For the configuration interface part, forgive me for not clarifying, as all required is a specification for the protocol, especially the response, so that writing interoperable software involves less guesswork. I'll take time to give it a shot.
And for the integration with wireguard, I'm aware of some ongoing works which might be of interest.
- wg-lla an algorithm for mapping wireguard public keys to linklocal addresses (then the list of peers can be directly converted to the list of neighbors)
- Introduce Wireguard support to bird a patch set that enables bird to update allowed ips according to the routing table (there's still room for improvement in terms of performance, and asymmetrical routes won't work)
I'm currently tinkering with wireguard to find a solution for the second part, may not be able to spare effort for the first part though.
+1 to this feature request.
As someone who has a lot of experience using babeld with WireGuard, with the same topology as @NickCao (multiple WireGuard interfaces, each with a single peer), support for specifying interfaces with a glob would be very useful, and negate the need to update the babeld configuration whenever a new interface is added.
As I mentioned in https://github.com/jech/babeld/pull/64#issuecomment-703355405, I don't think the approach in #64 is workable with WireGuard unless deep integration and control of the WireGuard cryptokey routing table was to occur. Even then, there are cases where a separate WireGuard interface per peer (and therefore glob support in babeld) has its advantages I suspect.
Could we use network namespaces and use Wireguard support for netns to have all of WireGuard interfaces added to a single namespace, then add all other wanted interfaces to the namespace, and specify to babeld the network namespace instead of a list of interfaces? Babeld would use all of the interfaces of the namespace. Of course that is a Linux-only feature.
@MisterDA Using a network namespace for the WireGuard interfaces introduces problems of its own, in particular the fact that you then need to bind any services you want accessible to that namespace too, as well as the fact an interface can only live in a single namespace, reducing flexibility. My preference would stick with being able to specify a glob to cover in my case wg*.
My preference would stick with being able to specify a glob to cover in my case wg*.
This might end up being the right solution, but I need to understand why. Here's what I've gathered:
There are two ways of configuring Wireguard, one which works with Babel and one which doesn't. The way that works consists in manually creating one interface for each neighbour. Since all of these interfaces have the same configuration, people want the ability to configure all of them in a single stanza. Thus, they want to use regexps.
There are a few things I'd be grateful if you could clarify:
- what's the other way, and why does it not work?
- why couldn't the interfaces be created automatically rather than manually? For example by having a deamon observe Wireguard and speaking to babeld over the configuration interface?
- why are globs the right solution, rather then having a notion of interface category?
-- Juliusz
Wireguard is a special case. In our installation we use ipsec/vti interfaces. It would be convenient for us to use a glob for the interface name, including for redistribution. For example: interface vti-gw* redistribute if vmbr*
At the moment, when adding the vti interface, we have to update the configuration file and restart babeld. We cannot use the -G option for security reasons.
The -G option can take a Unix domain socket, which obeys the filesystem permissions.
I'd say the glob is the cleanest solution. Integrating wireguard-specific stuff into babeld feels a little bit wrong to me. I love babeld for its simplicity - it just needs network connection that talks IP. It will find its neighbors on its own without the need to specify any remote babeld routers.
I've been syncing interfaces with a custom daemon, and it works pretty well. I believe that a simple shell script can also do the trick. Specifying interfaces with glob or regex truly is a useful feature anyway, but it still leave other use cases like dynamic interface discovery uncovered.
The main reason that people do not want to generate a new config and simply do a restart is that it would disrupt traffics and cause route flapping. If some sort of reload functionality can be implemented, then that will also be a viable solution.