If this FAQ didn't solve your problem, please feel free to ask on the Babel-users mailing list.
You may browse the archives on Alioth, at Gmane using HTTP, at Gmane using NNTP, and at mail-archive.com.
Send your bug reports to the Babel-users mailing list (no subscription required) or submit them to the babeld bug tracker.
Send your improvements to the Babel-users mailing list. Both patches and git pull requests are welcome.
Babel is a routing protocol that is designed to be efficient and robust on both normal wired networks (say, a bunch of Ethernets connected together) and on wireless networks. It is therefore particularly suitable for building hybrid networks — networks that are composed of both wired andn wireless links.
The reference implementation of Babel is called babeld. There are other implementations of Babel, listed on the Babel page.
Babel-Z is an extension to the Babel protocol that is able to take radio interference into account when choosing routes. This is believed to be useful if your mesh is running on multiple radio frequencies (e.g. with multiple radios in the 2.4 and 5 GHz bands), but no formal evaluation of Babel-Z has been done yet.
The Babel-Z protocol extensions are described in Diversity Routing for the Babel Routing Protocol. You may also want to have a look at some information about Babel-Z.
The Babel-Z protocol is supported by the babeld binary — please see
diversity parameter in the manual page (or, equivalently,
Babel-RTT is an extension to the Babel protocol that is able to automatically compute link latency and include it in its metric computation. This is particularly useful in overlay networks (networks built of tunnels), where a single hop can span much of the known universe.
The Babel-RTT protocol is supported by the babeld binary — please
max-rtt-pentalty parameter in the manual page.
Babel-S is an extension to the Babel protocol that enables source-specific routing. It is described in detail in source-specific Routing for the Babel Routing Protocol and the Source-Specific Routing paper.
Babel-S supported by the babeld binary. Please see
src-prefix filtering option in the manual page.
All variants of Babel interoperate — you may run Babel-Z, Babel-RTT, Babel-S and plain Babel in the same network.
AHCP is a protocol that is able to distribute IP addresses in a mesh network, just like DHCP distributes IP addresses in a wired network. AHCP is routing-protocol agnostic: it can work with Babel, with OLSR, etc.
The sample implementation of AHCP is called ahcpd.
We are currently looking at replacing AHCP with a modified subset of HNCP.
The babeld reference implementation and the FRR implementation are derived from the same code, and support double-stack operation. At this time, we recommend babeld, which has received more testing.
The Bird implementation is a clean reimplementation from scratch, but it currently only support IPv6. It is worth a try if you are not running IPv4.
Using the redistribute directive in the configuration file. For example,
redistribute ip 22.214.171.124/24
redistribute if eth0
By default, routes with protocol boot, such as the ones installed by DHCP, are ignored. In order to redistribute such routes, you need to specify the protocol explicitly:
redistribute if eth0 proto 3
A stub router is a router that has only one Babel interface, and that only installs default routes. For various reasons, OSPF and EIGRP have specific configuration options for stub routers, which Babel doesn't need.
The most efficient way is to configure the upstream router of your
stub router to not announce any non-default routes. Suppose that A is
your stub router, and that router B speaks to it over an
eth1; then on B say something like:
out if eth1 ip 0.0.0.0/0 ge 1 deny
out if eth1 ip ::/0 ge 1 deny
If you cannot reconfigure the upstream router B (for example because the link is shared with non-stub routers), you can discard the extraneous routes on A itself:
in ip 0.0.0.0/0 ge 1 deny
in ip ::/0 ge 1 deny
If you are very short on space, sbabeld is a stub-only implementation of Babel.
interface tun42 max-rtt-penalty 197
You need to do that on both sides of the tunnel.
Network monitors Tcpdump groks Babel starting with version 4.2.1. Wireshark has support since version 1.6.0.
Monitoring interface You can ask babeld to dump its
internal tables. With the standalone daemon, send a
signal to the daemon to get it to dump its tables to the log file.
Alternatively, run babeld with the flag "
33123", and run
telnet ::1 33123.
The babeld daemon automatically detects wired interfaces, and makes a number of optimisations that are not correct for wireless interfaces. Your firewall rules probably broke the assumptions that make these optimisations correct on wired links.
You may disable these optimisations by running babeld with
-w flag, or by saying something like
Please upgrade to 1.4.0 or later, which recognises BATMAN interfaces automatically.
Babeld version 1.5.0 and later has explicit support for tunnels, but it is not enabled by default. You will want to say something like:
interface tun-42 max-rtt-penalty 128
You need to do that on both sides of the tunnel.
If everything else fails, you can manually tweak babeld's metrics
by using filtering rules. For example, the following will cause
babeld to deprecate the link towards the host with link-local
in neigh fe80::dead:beef metric 512
If you want to forbid this link altogether, say:
in neigh fe80::dead:beef deny
In order to avoid all routes that go through a given interface, say:
in if wlan1 metric 512
Back to the Babel page.