Designing a Route Reflector Lab with Bird 2

Learning route reflector behavior in production BGP topologies is expensive. Especially in spine-leaf, edge or data-center transitions, a small reflection mistake can produce a wide routing impact. A route reflector lab built with Bird 2 is a powerful method to test these behaviors at low cost and to clearly observe the decision logic.

Lab objective

In this guide we will build a simple BGP laboratory composed of three client routers and two route reflector nodes. The aim is not to mimic production scale; it is to validate these behaviors:

• Route reflector cluster structure
• The difference between client and non-client sessions
• Verification of route propagation
• Adjacency and route behavior during failover

You can build the lab on containers or VMs. Bird 2 is lightweight, so it runs comfortably in small test environments.

Topology

The example topology proceeds with the following logic:

1. rr1 and rr2 act as route reflectors.
2. leaf1, leaf2 and edge1 play the client router role.
3. All nodes establish BGP adjacency on the same private lab network.

A simple addressing example:

rr1   10.10.0.11   AS 65000
rr2   10.10.0.12   AS 65000
leaf1 10.10.0.21   AS 65000
leaf2 10.10.0.22   AS 65000
edge1 10.10.0.31   AS 65000

In this example we use iBGP. That is enough to see the route reflector logic.

Bird 2 installation

On a Debian or Ubuntu-based system:

sudo apt update
sudo apt install -y bird2

After the service files are installed, the main configuration is typically located under /etc/bird/bird.conf. In the early stages, generating a separate file for each node makes it more readable.

Sample configuration for a route reflector node

A simple example on rr1:

router id 10.10.0.11;

protocol device {}
protocol direct {}

template bgp RR_CLIENT {
  local as 65000;
  rr client;
  ipv4 {
    import all;
    export all;
  };
}

protocol bgp leaf1 from RR_CLIENT {
  neighbor 10.10.0.21 as 65000;
}

protocol bgp leaf2 from RR_CLIENT {
  neighbor 10.10.0.22 as 65000;
}

protocol bgp edge1 from RR_CLIENT {
  neighbor 10.10.0.31 as 65000;
}

A similar structure can be set up for the second reflector. Running two reflectors matters because it lets you observe how routes behave on a single-node failure.

Client router example

A simple client configuration for leaf1:

router id 10.10.0.21;

protocol device {}
protocol direct {}
protocol static {
  route 192.168.21.0/24 via "lo";
}

template bgp RR_PEER {
  local as 65000;
  ipv4 {
    import all;
    export where source = RTS_STATIC;
  };
}

protocol bgp rr1 from RR_PEER {
  neighbor 10.10.0.11 as 65000;
}

protocol bgp rr2 from RR_PEER {
  neighbor 10.10.0.12 as 65000;
}

This definition lets the client advertise its own static route to the reflectors.

Verification steps

After configuration, run these checks:

sudo birdc show protocols
sudo birdc show route
sudo birdc show route all 192.168.21.0/24

Expected behaviors:

• All BGP sessions should appear Established
• leaf2 and edge1 should learn the prefix originated by leaf1 from the reflectors
• On the reflector node, route origin and next-hop information should be readable

You can then stop the rr1 service and test route continuity through rr2.

Extensions that make the lab valuable

After the basic flow runs, adding the following experiments to the lab is useful:

• Local-pref differences
• Route-map or filter usage
• next hop self behavior
• Non-client distribution with a peer outside the reflector

These experiments deliver far clearer insight than reading documentation when transitioning to production.

Conclusion

A route reflector lab built with Bird 2 makes BGP behavior visible in a small, controllable environment. Especially before enterprise network modernization, data-center segmentation or edge-routing decisions, this kind of lab reduces costly surprises. What matters is not building a perfect lab, but being able to safely observe why a given route decision occurred.