Babel on a wireless mesh

[Bernd Naumann]

On 12.01.23 23:52, Toke Høiland-Jørgensen wrote:

Hey Toke!
Thanks for the quick reply.
This gives me some keywords for a goods nights tale :)

> Bernd Naumann <bernd at kr217.de> writes:
> 
>> Hey *,
>>
>> Because Babel popped up on the list, I want to use the opportunity to
>> drop a few questions I had over the last days...
>>
>> On my small home-network I currently use OSPFv3 for IPv4 and IPv6 to
>> announce routes from Laptops and PCs, and the Router. (There are some
>> "dumb APs", too in the network but routing happens only on "the router"
>> and like I mentioned, PCs and Laptops. Some wired, some wireless only,
>> some both.)
>> Given the fact that both protocols, OSPFv3 and Babel, are using
>> multicast; would I "gain anything" switching to Babel? Right now I'm
>> only using OSPFv3 because I'm familiar with...
> 
> Well, if OSPF is working to your satisfaction I'm not sure you'll "gain"
> anything, really. Babel is certainly capable of doing what you describe,
> I use it myself for similar stuff. The main "philosophical" difference
> between OSPF and Babel is that Babel is a distance vector protocol,
> while OSPF is a link-state protocol. Basically, this means that in OSPF
> every node has a full view of the network and runs the same algorithm to
> agree on the right path. Whereas in Babel, packets are routed "towards
> the best path" and every node doesn't need to have the full same view of
> the network (which allows nodes to do things like filter and aggregate
> routes). I'm simplifying wildly here, and I'm sure Juliusz will jump in
> and point out all the ways this simplification is wrong :)
> 

I'm not quiet sure I get the filtering part. Could you give me an
example please? (On my local network I more or less trust each peer and
only apply export filters, and just import everything on a protocol...)

> In addition, there are a couple of neat features in Babel:
> 
> - The ability to route v4 and v6 traffic using a single instance of the
>   protocol (all Babel routing packets are v6, but they carry information
>   about v4 routes as well).
> 
> - The ability to route v4 packets over v6 nexthops, so nodes internally
>   in the network don't need v4 addresses (not in Bird yet, though, see:
>   https://bird.network.cz/pipermail/bird-users/2023-January/016502.html)
> 

That's right, I followed somehow the progress. That was one of the
reasons I started to think about to introduce Babel at home. I also have
started to consider to setup a MP-BGP RR at home just because its so
easy with bird :) at least in such a small scale setup I did not run
into any issues yet. And yes IPv4 NLRI via IPv6 NH is just such a great
achievement. Praise the lord :D

Site note: The only "issue" I see right now with it / Have not yet found
a fulfilling answer: Many NOS treat 192.0.0.8/32 just as bogus or reject
it because of RPF, and just "ignore" its special meaning. (For those who
are not aware of it, see i.e.
https://www.rfc-editor.org/rfc/rfc7600.html#section-4.8
192.0.0.8/32 is assigned as IPv4 dummy address, so an IPv6 Only node is
able to send IPv4 ICMP packets if needed.
I tried to dig in the kernel source and only got that far that the whole
192.0.0.0/24 is treated "special" but current implementation as far as I
could understand it, is unaware of /32 assignments and their functions
or special meaning. But maybe that's another topic...)

> - Source-specific routing for IPv6

I have to admit: I think I need to re-read this chapter in my version of
"IPv6 essentials"...

> 
> - An RTT extension that lets you pick the lowest-RTT path instead of the
>   least-hop one (not in Bird yet either, but I have an implementation
>   that I'm planning to submit soonish).
> 
> As for which will serve your needs best, well, on a "small home network"
> you'll probably be fine with either one. I personally like the
> simplicity of Babel (3.5k LoC vs 9k for OSPF), but I'm also hopelessly
> biased since I wrote the Babel implementation ;)

:D No rejects on that. Maybe I should just set it up and see "how it
feels". A good sales talk, sometimes, stimulates the appetite.

> 
>> And what really puzzles me, and I don't find "useful" answers:
>> If I run a multicast based routing protocol on jittery wireless links,
>> do I need to "tune" multicast options for the wireless radio? And if so,
>> what options; to what value; based on what? (Regarding the multicast
>> radio options of the access points, I'm running OpenWrt.)
> 
> Tuning shouldn't generally be needed. In Babel you'd want to set the
> wireless interfaces to the (surprise!) "wireless" interface type, which
> makes the protocol employ a link quality estimation algorithm that's
> more suitable to wireless links (which tend to degrade rather than just
> turn off completely).

Yeah, right now, I'm only setting the OSPF Cost and think this sucks :/
And yes, that's one of the issues I think I encounter from time to time,
that a Laptop just disappears from the network. (I somehow knew Babel is
(let me call it) link quality aware, but haven't looked into it yet.)
Sadly, OLSRv2 seams not active any longer which is/was really promising.
I was briefly exposed to it, a few years ago.

I also would like to limit myself on using only bird, and not cluing
multiple daemons together, even it is a common use-case.

> 
> You're right that multicast traffic has different characteristics than
> unicast in Wireless, but if you're "just" trying to pick which of two
> links is better, their relative multicast performance are a decent
> predictor of their relative unicast performance as well. So in practice
> it works OK. One problem with using multicast, though, is that this has
> more overhead than using unicast on wireless links. For this reason,
> Babel has a mode that switches most of the traffic to being unicast;
> however, that's not in Bird yet.
> 

Does it start with using multicast and later/after it knows about its
neighbors, it switches automatically to unicast? Or how does it work?

> -Toke

Thanks again for your detailed response! Good night then!
Bernd