Babel on a wireless mesh
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... 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.) Thanks for pointers and hints. Bernd PS: Yes, I'm not even sure if I need to "tune" anything or not. Or what to expect. But I would like to "get the picture".
Bernd Naumann <bernd@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 :) 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) - Source-specific routing for IPv6 - 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 ;)
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). 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. -Toke
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@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
As Toke said, OSPFv3 is a fine protocol. OSPFv2 was already pretty good, and the designers of OSPFv3 fixed the two significant flaws in OSPFv2. But of course I'd be delighted if you could experiment with Babel.
routes). I'm simplifying wildly here, and I'm sure Juliusz will jump in and point out all the ways this simplification is wrong :)
It's a good summary. I cannot at the same time claim that Babel is simple and object to simple explanations :-)
I'm not quiet sure I get the filtering part. Could you give me an example please?
What it means that Babel, just like BGP, can drop routes arbitrarily at any point of the network, while OSPF and IS-IS can only drop routes at area boundaries. Suppose that you have the following topology: B / \ / \ Internet --- A C \ / \ / D Suppose further that, for some reason, you don't want to carry C's traffic to the Internet through D (say, because D is a battery operated node). However, you want C to be able to reach D directly, so dropping the C-D link is not an option. You want the following behaviour: * C to A follows C-B-A * C to D follows C-D With OSPF, you have two solutions: 1. you increase the cost of the link D-A; 2. you put D in a separate area, so you can filter at the area border. Solution 1 is tricky and error-prone (you need to increase the cost of the link D-A, but not too much, otherwise traffic from D to A risks going through D-C-B-A). Solution 2 works fine (OSPF can do arbitrary filtering at area boundaries), but it involves planning (where to put the area boundaries) and a good understanding of the constraints on OSPF areas. With Babel or BGP, you just write a single filtering rule at C that drops the forbidden route C-D-A, and you're done. No tricky tweaking of metrics, no areas, just a single filtering rule. This cuts both ways, of course. OSPF imposes discipline: you need to carefully think about your network's structure, so you can have a uniform policy within each area. BGP and Babel allow fairly arbitrary routing policies, so it's easy to hack around issues with no understanding of the network topology: we give you powerful tools, and if you cut yourself, you're on your own. My feeling is that OSPF is well-suited to managed networks with a single central authority, while BGP and Babel are more adapted to chaotic networks with no central administration. While I certainly wouldn't want to use OSPF in a community mesh network, it'd be my first choice in a large, stable network where all links are fast and all nodes are powerful.
And yes IPv4 NLRI via IPv6 NH is just such a great achievement.
Yeah, I like it too :-)
I have to admit: I think I need to re-read this chapter in my version of "IPv6 essentials"...
I'm certainly biased, but I rather like the introduction to https://arxiv.org/pdf/1403.0445.pdf
Does it start with using multicast and later/after it knows about its neighbors, it switches automatically to unicast? Or how does it work?
Babel (the protocol) is carefully designed so that the implementation can choose whether to send routing data over multicast or unicast. By default, both babeld and BIRD use primarily multicast, but occasionally use unicast to solve emergency situations ("I'm about to loose a route, probably due to packet loss"). Babeld has a mode where it uses multicast for discovery only and user unicast for all other communication, as you suggest, but I don't think that Toke has implemented it in BIRD yet. (Babeld was used to design the Babel protocol, and we experimented with a lot of features, many of which turned out to be useless, and which we've been busy removing over the last years. Toke had the benefit of our experience, so he could implement just the features that have been proven to be useful. In addition, Toke is a better programmer than I am, so the result is a much cleaner implementation, and one that is slowly getting to feature parity with babeld. I recommend using BIRD in production in preference to babeld, since the code is so much better; however, I intend to keep maintaining babeld for the foreseeable future.)
Maybe I should just set it up and see "how it feels".
Please? -- Juliusz
participants (3)
-
Bernd Naumann -
Juliusz Chroboczek -
Toke Høiland-Jørgensen