BGP – Route-reflector Resilience Design

There are 2 major forms of route-reflector clustering:

1. Two or more RRs in the same cluster

2. Client is a member of multiple clusters

Let’s take a look at how it works in these 2 cases.  Assuming I have 2 RRs, RR1 and RR2 and 2 route reflector client C1 and C2. 

- RR1 has a peer session with RR2

- C1 has 2 peer sessions one to RR1 another to RR2

- C2 has 2 peer sessions one to RR1 another to RR2

Case 1 – Same Cluster, When everything is fine

- C1 gets an update from somewhere and advertise to RR-1 and RR-2

- Both RRs will advertise the update to C2

- RRs will send update to each other, but since the same cluster-id in the update message and it is identical to its own, it will discard the update

Case 2 – Same Cluster, C1-RR2 and C2-RR1 links down

- C1 gets update and advertises to RR1

- C1 can’t advertise to RR2 as the link is down

- RR1 can’t advertise to RR2 as the cluster-id is the same

- As a result C2 can’t get the update (50% of the routers in the cluster)

Case 3 – Different Cluster, When everything is fine

- C1 gets update and advertises to RR1 and RR2

- RR1 will advertise to RR2 and it will process it as the cluster-ids are different, and vice versa

- C2 gets the update

Case 4 – Different Cluster, C1-RR2 and C2-RR1 links down

- C1 gets update and advertise to RR1

- RR1 advertises to RR2 and it is accepted, as cluster-ids are different

- C2 will gets the update

- Therefore it provides better redundancy

If you want to know more on different forms of RR redundancy design, here is a good presentation on this topic:

http://www.ripe.net/ripe/meetings/ripe-42/presentations/ripe42-eof-bgp/index.html