What are The Tubes? They are an experimental overlay network for doing, uh, sysadmin LARP? Some public information about the setup can be seen over at https://pvpn.reclaim.technology/. Anyways, as the overlay network grows, we want to make the network more mesh-like instead of star-like. And that means we need a routing protocol.
After considering BGP and OSPF, I found some information about the Babel routing protocol. It promised to be simpler to set up, capable of handling optimal routing in a mesh network, and even has specialized metrics such as RTT-based metrics designed for use on overlay networks like the Tubes.
Here’s a public duplicate of the Tubes-internal document on setting up the Wireguard link and Babel configuration for this usage. This configuration as it stands is not well tested – it’s probably going to change as we bring on more links and find issues!
Babel Routing for the Tubes
The instructions below assume you are using wg-quick style Wireguard configuration, and babeld as your Babel routing daemon. Other tools may be used, but you will have to translate the configuration examples for it.
Configuring a Wireguard link for Babel routing
Wireguard links that will be running Babel routing need some configuration changes to allow the Babel protocol to run over them. Here’s an example configuration for a Wireguard link in wg-quick format.
[Interface] # Leave the PrivateKey, ListenPort # options unchanged from the normal configuration # Assign an IPv6 link local address on the tunnel so multicast works # This address must be distinct from the remote side! Consider using your # participant number for the address. Address = fe80::XX/64 # Also configure your router's local addresses on this interface Address = 10.42.N.1, fd70:feed:cafe:XX00::1 # Disable automatically adding routes for AllowedIPs. That's Babel's job Table = off # An interface used for Babel MUST only have one peer [Peer] # Leave the PublicKey, PresharedKey, Endpoint, PersistentKeepalive # options unchanged from the normal configuration # Since we're doing mesh routing, allow all Tubes IPv4 & IPv6 addresses AllowedIPs = 10.42.0.0/16, fd70:feed:cafe::/48 # The Babel protocol uses IPv6 link-local unicast and multicast addresses AllowedIPs = fe80::/64, ff02::1:6/128
When this Wireguard link is running, there should be no IPv4 routes shown in
ip route with
dev wgN. There should be one IPv6 route shown with
ip -6 route on the Wireguard device, for the link local range:
fe80::/64 dev wgN proto kernel metric 256 pref medium
The babeld configuration file is usually located at
# Set default options that will apply to all wireguard interfaces # Tunnel mode enables timestamps and RTT metrics default type tunnel # An optimization for point-to-point or wired links default split-horizon true # Override this to false on a specific interface if the remote node is # close enough to have wifi interference on routed subnets. default faraway true # Prefer using unicast messages over the tunnel default unicast true # For each Wireguard interface that will be running babel, add an interface line: interface wgN # To protect against misconfigured remote Babel nodes, reject prefixes # in the wrong subnet, or with the wrong prefix length. in ip fd70:feed:cafe::/48 le 64 ge 56 allow in ip fd70:feed:cafe::/56 eq 128 allow in ip 10.42.0.0/16 eq 24 allow in ip 10.42.0.0/24 eq 32 allow in deny # Advertise locally configured routes in the Tubes ranges redistribute ip fd70:feed:cafe::/48 le 64 ge 56 allow redistribute ip fd70:feed:cafe::/56 eq 128 allow # If you are redistributing subnets on behalf of wireguard-connected # peers who aren't using babel, increase the metrics for those subnets #redistribute ip 10.42.1.0/24 eq 24 metric 256 redistribute ip 10.42.0.0/16 eq 24 allow redistribute ip 10.42.0.0/24 eq 32 allow redistribute local ip 10.42.0.0/24 eq 32 allow redistribute local deny
If you send the running babeld process
SIGUSR1, it will print out the list of known routes to the log. Please use this to verify that it has imported the correct local routes – marked
(exported) – before linking to another node.
If Babel is not exporting your subnet address, there’s a couple possible reasons:
If you have a route for the subnet address, but the output of the
ip route (or
ip -6 route) command does not include a
proto keyword, then it’s probably
proto boot, and is excluded by default in babel. You can add the appropriate IPv4 or v6 lines to the
redistribute section of the babel config to include that route:
redistribute ip 10.42.0.0/16 proto 3 eq 24 allow redistribute ip fd70:feed:cafe::/48 proto 3 le 64 ge 56 allow
Alternately, maybe you don’t have a single route configured covering the entire subnet – for example, if you are assigning individual addresses in a VPN concentrator, or are using smaller subnet sizes. In this case, consider adding local “unreachable” routes that cover your entire subnet for babeld to pick up:
ip route add unreachable 10.42.N.0/24 ip -6 route add unreachable fd70:feed:cafe:XX00::/56
Disabling transit traffic
If you want to use babel to automatically receive routes, but do not want to allow traffic to different systems to transit through your system, you can configure that by using
out filters in the babel config:
# Allow announcing routes for your own local subnets out ip 10.42.N.0/24 allow out ip fd70:feed:cafe:XX00::/56 allow # Don't announce routes to anything else out deny