Redistribute neighbor provides a mechanism for IP subnets to span racks without forcing the end hosts to run a routing protocol.
The fundamental premise behind redistribute neighbor is to announce individual host /32 routes in the routed fabric. Other hosts on the fabric can then use this new path to access the hosts in the fabric. If multiple equal-cost paths (ECMP) are available, traffic can load balance across the available paths natively.
The challenge is to accurately compile and update this list of reachable hosts or neighbors. Luckily, existing commonly-deployed protocols are available to solve this problem. Hosts use ARP to resolve MAC addresses when sending to an IPv4 address. A host then builds an ARP cache table of known MAC addresses: IPv4 tuples as they receive or respond to ARP requests.
In the case of a leaf switch, where the default gateway is deployed for hosts within the rack, the ARP cache table contains a list of all hosts that have ARP'd for their default gateway. In many scenarios, this table contains all the layer 3 information that's needed. This is where redistribute neighbor comes in, as it is a mechanism of formatting and syncing this table into the routing protocol.
Redistribute neighbor is distributed as
Target Use Cases and Best Practices
Redistribute neighbor was created with these use cases in mind:
- Virtualized clusters
- Hosts with service IP addresses that migrate between racks
- Hosts that are dual connected to two leaf nodes without using proprietary protocols such as MLAG
- Anycast services needing dynamic advertisement from multiple hosts
Cumulus Networks recommends following these guidelines with redistribute neighbor:
- Use a single logical connection from each host to each leaf.
- A host can connect to one or more leafs. Each leaf advertises the /32 it sees in its neighbor table.
- A host-bound bridge/VLAN should be local to each switch only.
Leaf switches with redistribute neighbor enabled should be directly connected to the hosts.
- IP addressing must be non-overlapping, as the host IPs are directly advertised into the routed fabric.
- Run redistribute neighbor on Linux-based hosts primarily; other host operating systems may work, but Cumulus Networks has not actively tested any at this stage.
How It Works
Redistribute neighbor works as follows:
- The leaf/ToR switches learn about connected hosts when the host sends an ARP request or ARP reply.
- An entry for the host is added to the kernel neighbor table of each leaf switch.
The redistribute neighbor daemon,
rdnbrd, monitors the kernel neighbor table and creates a /32 route for each neighbor entry. This /32 route is created in kernel table 10.
- FRRouting is configured to import routes from kernel table 10.
- A route-map is used to control which routes from table 10 are imported.
- In FRRouting these routes are imported as table routes.
- BGP, OSPF and so forth are then configured to redistribute the table 10 routes.
The following example configuration is based on the reference topology created by Cumulus Networks. Other configurations are possible, based on the use cases outlined above. Here is a diagram of the topology:
Configure the Leaf(s)
The following steps demonstrate how to configure leaf01, but the same steps can be applied to any of the leafs.
Configure the host facing ports, using the same IP address on both host-facing interfaces as well as a /32 prefix. In this case, swp1 and swp2 are configured as they are the ports facing server01 and server02:
The commands produce the following configuration in the
Enable the daemon so it starts at bootup:
Start the daemon:
Define a route-map that matches on the host-facing interfaces:
Import routing table 10 and apply the route-map:
Redistribute the imported table routes in into the appropriate routing protocol.
Save the configuration by committing your changes.
This configuration uses OSPF as the routing protocol.
Configure the Host(s)
There are a few possible host configurations that range in complexity. This document only covers the basic use case: dual-connected Linux hosts with static IP addresses assigned.
Additional host configurations will be covered in future separate knowledge base articles.
Configure a Dual-connected Host
Configure a host with the same /32 IP address on its loopback (lo) and uplinks (in this example, eth1 and eth2). This is done so both leaf switches advertise the same /32 regardless of the interface. Cumulus Linux relies on ECMP to load balance across the interfaces southbound, and an equal cost static route (see the configuration below) for load balancing northbound.
The loopback hosts the primary service IP address(es) and to which you can bind services.
Configure the loopback and physical interfaces. Referring back to the topology diagram, server01 is connected to leaf01 via eth1 and to leaf02 via eth2. You should note:
- The loopback IP is assigned to lo, eth1 and eth2.
- The post-up ARPing is used to force the host to ARP as soon as its interface comes up. This allows the leaf to learn about the host as soon as possible.
ip route replaceis used to install a default route via one or both leaf nodes if both swp1 and swp2 are up.Click here to expand...
Additionally, install and use ifplugd.
ifplugd modifies the behavior of the Linux routing table when an interface undergoes a link transition (carrier up/down). The Linux kernel by default leaves routes up even when the physical interface is unavailable (NO-CARRIER).
After you install
/etc/default/ifplugd as follows, where eth1 and eth2 are the interface names that your host uses to connect to the leaves.
For full instructions on installing
ifplugd on Ubuntu, follow this guide.
TCAM Route Scale
This feature adds each ARP entry as a /32 host route into the routing table of all switches within a summarization domain. Take care to keep the number of hosts minus fabric routes under the TCAM size of the switch. Review the Cumulus Networks datasheets for up to date scalability limits of your chosen hardware platforms. If in doubt, contact Cumulus Networks support or your Cumulus Networks CSE; they will be happy to help.
Possible Uneven Traffic Distribution
Linux uses source L3 addresses only to do load balancing on most older distributions.
Silent Hosts Never Receive Traffic
Freshly provisioned hosts that have never sent traffic may not ARP for their default gateways. The post-up ARPing in
/etc/network/interfaces on the host should take care of this. If the host does not ARP, then
rdnbrd on the leaf cannot learn about the host.
Support for IPv4 Only
This release of redistribute neighbor supports IPv4 only.
VRFs Are not Supported
This release of redistribute neighbor does not support VRFs.
Only 1024 Interfaces Supported
Redistribute neighbor does not work with more than 1024 interfaces. Doing so can cause the
rdnbrd service to crash.
How do I determine if
rdnbrd (the redistribute neighbor daemon) is running?
systemd to check:
How do I change rdnbrd's default configuration?
/etc/rdnbrd.conf file, then run
systemctl restart rdnbrd.service:
What is table 10? Why was table 10 chosen?
The Linux kernel supports multiple routing tables and can utilize 0 through 255 as table IDs. However, tables 0, 253, 254 and 255 are reserved, and 1 is usually the first one utilized. Therefore,
rdnbrd only allows you to specify 2-252. The number 10 was chosen for no particular reason. Feel free to set it to any value between 2-252. You can see all the tables specified here:
How do I determine that the /32 redistribute neighbor routes are being advertised to my neighbor?
For BGP, check the advertised routes to the neighbor.
How do I verify that the kernel routing table is being correctly populated?
Use the following workflow to verify that the kernel routing table is being populated correctly and that routes are being correctly imported/advertised:
Verify that ARP neighbor entries are being populated into the Kernel routing table 10.
If these routes are not being generated, verify the following:
rdnbrddaemon is running
/etc/rdnbrd.confto verify the correct table number is used
Verify that routes are being imported into FRRouting from the kernel routing table 10.
Both the > and * should be present so that table 10 routes are installed as preferred into the routing table. If the routes are not being installed, verify the following:
- The imported distance of the locally imported kernel routes using the
ip import 10 distance Xcommand, where X is not less than the adminstrative distance of the routing protocol. If the distance is too low, routes learned from the protocol may overwrite the locally imported routes.
- The routes are in the kernel routing table.
- The imported distance of the locally imported kernel routes using the
Confirm that routes are in the BGP/OSPF database and are being advertised.