BGP Redundant Route-Reflectors

In this post we will look at the various ways to configure redundant route reflectors in the network.

As shown in the diagram, R1 and R2 are the route-reflectors, R3 and R4 are the RR-Clients & R5 and R6 are the non-clients. All the routers have IGP reachability to each other. I have used their loopback interfaces to establish IBGP neighborship. 

We have advertised the loopback IP (172.16.X.0/24) from each router into BGP (X=router's number).

The BGP configs on R1 and R2

The route-reflectors will propagate prefixes based on these conditions

• If a route is received from an EBGP peer, reflect to all client and nonclient peers.
• If a route is received from a client peer, reflect to all nonclient peers and also to client peers.
• If a route is received from nonclient peer, reflect to clients only but not to the other non-client peers.

Let's look at the output on R3 which is one of the clients 

We can see that R3 receives all the loopback prefixes advertised by clients and non-clients from route reflectors R1 and R2. Both R1 and R2 has different cluster-id which is inherited from their local router-id.It chooses the best path based on the lowest neighbour id.

Let's look at various configuration scenarios now..

1) Route Reflectors with different cluster-id configured as each other's RR-Clients:

At the moment R1 treats R2 as client and vice-versa so R1 receives all the prefixes from it's IBGP neighbours and also from the route-reflector R2.

The above output shows that R1 receives the prefix 172.16.4.0/24 from R2 and from R4.

Let's assume that R4 lose connectivity to R1 and R5 lose connectivity to R2. 

We can see that R1 still receives the loopback of R4 via the R2.

Similarly, R3 still receives the loopback of R4 via R1

The reachability between R5 and R4 has not been affected.

So in this scenario there will not be any impact on client to client communication or client to non-client communication.

2) Route Reflectors with different cluster-id NOT configured as each other's RR-Clients:

Now let's change the configuration and stop R1 being the route-reflector client of R2 and vice versa. 

Both R1 and R2 now pass on the updates received from R3 and R4 to each other (clients to non-clients) however they don't pass the updates received from R5 and R6 to each other (non-clients to non-clients).

So if R4 lose connectivity to R1 and R5 lose connectivity to R2. 

We can see that R1 still receives the prefix 172.16.4.0/24 from R2 however R2 stops received the prefix 172.16.5.0/24. 

So in this scenario, the connectivity between client and non-client will not work but the connectivity between client to client will remain unaffected.

3) Route Reflectors with same cluster-id:

We will now change R2's cluster-id and change it 172.16.1.1 so both R1 and R2 will have the same cluster-id.

Looking at R1's BGP table

We can see that it only receives prefixes from it's IBGP neighbours. 

If we debug the BGP update then we can see that it rejects all the updates received from R2 because it has the same cluster-id.

We will see what happens if R4 lose connectivity to R1 and R5 lose connectivity to R2. 

We can see that R1 can't see the prefix 172.16.4.0/24 and R2 can't see the prefix 172.16.5.0/24 so the client to non-client communication will not work. 

What if R3 lose connectivity to R2...

R2 now can't see the prefix 172.16.3.0/24 from R3 which means that client to client communication will not work as well.

From the above experiments it looks like the best option is to configure both route-reflectors with different cluster-id and also configure them as each other's clients. However the drawback of this option is that each RR server has to maintain twice the amount of routes in it's BGP table which will consume extra memory. If your topology consists of hundreds of thousand of routes then this may not be the best option. 

The point is that there is no right or wrong method, it all depends on the design of your network and the functionality you want to achieve.