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