The Babel routing protocol. Babel is a routing protocol designed for wireless and wired networks. Babel is a distance-vector routing protocol. Babel converges quickly compared to other distance-vector routing protocols. Babel does NOT support BFD, at least not using FRRouting. Babel uses multiple metrics, to calculate the path to a route. Babel could be used in wired networks but always having in mind that it was designed primarily for wireless networks. In this netlab it is shown how to setup a basic babel wired topology. It is using a FRR 8.2.2 running on a alpine linux appliance. See Building 64bit alpine linux GNS3 FRRouting appliance. This netlab is running using the Graphical Network Simulator - GNS3.

Topology

This netlab is using a triangle design. It is using IPv6 only.

Triangle network topology and addressing:

            lo                                          lo
    2001:db8:1111::/128                         2001:db8:2222::/128
        +-------+                                   +-------+
        |       | eth0                         eth0 |       |
        |  FRR1 |-----------------------------------|  FRR2 |
        |       |                                   |       |
        +-------+                                   +-------+
       eth2 |                                           | eth1
            |                                           |
            |                                           |
            |                                           |
            |                                           |
            |                                           |
            |                 +-------+                 |
            |                 |       |                 |
            +-----------------|  FRR3 |-----------------+
                         eth2 |       | eth1
                              +-------+
                                  lo
                          2001:db8:3333::/128

This netlab uses wired connections to cover the basic information about the Babel routing protocol, and its current implementation status in FRRouting.

Router configuration

The router configurations for FRR1, FRR2 and FRR3 according to the depicted upper network sketch:

• Configure loopback address
• Enable babel routing process
• Enable babel routing on physical interfaces
• Advertise the loopback address

One note regarding the used redistribuite ipv6 connected configuration command in this netlab.

Before using redistribute ipv6 connected command in a routing context, verify connected routes first. Each connected route on the router will be advertised by this router. It is a catchall method , or joker route kind of adding local router, as a personal note, not a good approach of adding routes into routing. Everything connected will be added to the routing area. To verify which and how many networks will be put into the babel routing, use the sh ipv6 route connected command:

Looking at the output, only the lo interface will be put into the Babel routing domain. IPv6 Link Local LL addressing on the eth0 and eth2 interfaces, will not be put into the Babel routing domain. Using the redistribute connected is currently the only working approach of putting IPv6 networks into the Babel routing domain. This is what happens when you try to be careful and add interfaces into routing domain using the best practice approach:

FRR1# conf t
FRR1(config)# router babel
FRR1(config-router)# network
IF_OR_ADDR  Interface or address
FRR1(config-router)# network 1.1.1.1
% [BABELD] Unknown command: network 1.1.1.1
FRR1(config-router)# network 2001:db8:1111::
% [BABELD] Unknown command: network 2001:db8:1111::
FRR1(config-router)# network 2001:db8:1111::/128
% [BABELD] Unknown command: network 2001:db8:1111::/128
FRR1(config-router)# network 2001:db8:1111::/64
% [BABELD] Unknown command: network 2001:db8:1111::/64
FRR1(config-router)#

Putting IP addressing does not work using the network command. Adding networks works only by the interface name lo eth0. The network command enables the babel routing protocol on a particular interface. Routers from neighborships on dedicated interfaces, these dedicated interfaces, where neighbors are awaited need to be configured with the network <IF> command.

Babel passive interface adding, where no Babel neighborship will be formed, like the interface lo interface works now only using the redistribute connected router command.

FRR1

conf t
!
! Configure int lo address:
!
interface lo
 ipv6 address 2001:db8:1111::/128
exit
!
! Enable the routing process:
!
router babel
 !
 ! Enable routing on physical interfaces:
 !
 network eth0
 network eth1
 network eth2
 !
 ! Advertise loopback address:
 !
 redistribute ipv6 connected
exit
!
end

FRR2

conf t
!
interface lo
 ipv6 address 2001:db8:2222::/128
exit
!
router babel
 network eth0
 network eth1
 network eth2
 redistribute ipv6 connected
exit
!
end

FRR3

conf t
!
interface lo
 ipv6 address 2001:db8:3333::/128
exit
!
router babel
 network eth0
 network eth1
 network eth2
 redistribute ipv6 connected
exit
!
end

show commands

show babel neighbor

After finished the configuration on all topology routers. Verify if the routers form neighborships on directly connected links:

The show babel neighbor output shows the metrics and cost on the interface:

• interface eth2
• reachability ffff (best?)
• recive cost 256
• transmit cost 256
• round trip time 0
• round trip time cost 0

show babel interface

In the default configuration every interface in Babel will be set in the wireless mode using following settings:

• Operating mode wireless
• Split horizon mode Off
• Hello 4 seconds
• Update interval 16 seconds
• RXcost multiplier 256

show ipv6 route babel

Babel routes with Administrative Distance of 100 and 0 metrics. Available via LL interface addressing on both interfaces eth0 and eth2. With a weight of 1, and time since the route has become available in the routing table. Verify using the Administrative Distance on various network operating systems. Administrative Distance, called also route priority or priority is a network operating system specific option. Different implementation will most probably set different default values.

configure commands

babel interface wired

The topology relies on wired connections, per default all interfaces in BABEL are assumed to be in wireless mode. Adjust the configuration in the netlab on directly connected interfaces for FRR1, FRR2 and FRR3 routers to be set to wired mode:

conf t
!
int eth0
 babel wired
int eth1
 babel wired
int eth2
 babel wired
!
end

This configuration step has a impact on the used BABEL metrics. The wired interfaces have lower cost multiplier, so are cheaper to use, wired interfaces more preferred than the wireless from the standpoint of BABEL routing process.

show babel neighbor

Show the babel neighbor connected to the FRR1 router. Notice the neighborship are formed via LL addresses, and the changed rxcost/txcost int the output:

The output shows following metrics and cost for the interface eth2:

• interface eth2
• reachability ffff (best?)
• recive cost 96
• transmit cost 96
• round trip time 0
• round trip time cost 0

show babel interface

Review the babel interface eth0 configuration. Notice the change of Rxcost multiplier from 256 to 96 and the Split horizon option has been set to On:

Wired mode babel default interface settings:

• Operating mode wired
• Split horizon mode On
• Hello 4 seconds
• Update interval 16 seconds
• RXcost multiplier 96

show ipv6 route babel

Show the ipv6 BABEL routes in the routing table. The Administrative Distance is set to 100, note that no metrics are applied on the vtysh output [100/0]. The metrics of the babel route are set to 0. This is something that might be missing in FRR for wired links, either not displayed correctly, or still not working in this babel implementation:

show ipv6 route

Display the whole IPv6 routing table. Notice the lo address is directly connected, indicating which router the output is from 2001:db8:1111::/128 FRR1:

iproute2

The ipv6 routing table shown by the iproute2 utility. Notice the metric of babel is set to 20:

Babel path computation

The metrics are split up in wired and wireless networks. Babel uses different algorithms for different types of networks. It looks the implementation is lacking some of the code to display the metrics properly, at least for the wired FRR implementation part:

• Path Cost Computation
• Recommended strategies for computing a link's cost- Appendix A
• Wired links use k-out-of-j path computation - Appendix A.2.1
• Wireless links use The Expected Transmission Cost algorithm ETX
• Recommended default values of the parameters - Appendix B

bug 10893

Note that using FRR version 8.2.2 setting up a lab BABEL netlab initially works.

After disrupting the link on eth0 interface on router FRR1, the directly connected neighbor FRR2 will not get reachable via that eth0 interface. Further interface flapping on other routers in the network topology renders the netlab unusable. After the restart of the the network toplogy in GNS3 every neighborship is formed up properly again.

• FRR1 full configuration
• FRR2 full configuration
• FRR3 full configuration

bug fix

How the bug was fixed in the code. File babeld/babel_interface.c received

• 1 add and
• 17 deletions

This is the diff of the fix. With following commit message:

babeld: Rehook up interface up events 
When babeld was switched over to the zapi interface up/down callbacks the interface up event was not properly put back in.

Bug has been reported by a debian linux user. Thanks for that bug report.

Summary

Babel implementation lacks the ability to add interfaces or IP addresses into the routing domain. Best approach would be to have syntax like this:

conf t
!
interfaces lo
  router babel
exit
!
int eth0
  router babel
exit
!
router babel
  passive interface lo
end

Instead of putting interfaces into the router babel process. Someone needs to implement this in the babel code. Also all the EIGRP metric like calculation for the routing cost is still lacking. Different algos for different media. However the DUAL algo is calculated from 5 metrics that are taken into account so this might be a longer undertaking. Good to have the RFC's at hand.

Resources

• FRRouting - Official Babel documentation - version 8.2
• FRRouting - Official Release Notes - version 8.2
• FRRouting - Issue 10893
• RFC8966 - The Babel Routing Protocol
• RFC8966 - Route Filtering
• Wikipedia - Babel Protocol
• Wikipedia - Split Horizon
• Administrative Distance on various network operating systems
• Building 64bit alpine linux GNS3 FRRouting appliance