BGP redundant Route Reflector

[shelley_wang]

Topology of AS 10:

R1------------------------R4 (RR)

|                                   |

R2 (RR)-----------------R5

R1 advertises BGP route 168.1.0.0 to R2 and R4. R5 learns IBGP route 168.1.0.0 from RR R2 and RR R4 in 2 different clusters. R5 chooses the best path which is reflected by R2.

R5#sh ip bgp 168.1.0.0

BGP routing table entry for 168.1.0.0/16, version 4

Paths: (2 available, best #2, table Default-IP-Routing-Table)

Not advertised to any peer

Local

   1.1.1.1 (metric 21) from 4.4.4.4 (4.4.4.4)

     Origin IGP, metric 0, localpref 100, valid, internal

     Originator: 1.1.1.1, Cluster list: 4.4.4.4

Local

   1.1.1.1 (metric 21) from 2.2.2.2 (2.2.2.2)

     Origin IGP, metric 0, localpref 100, valid, internal, best

     Originator: 1.1.1.1, Cluster list: 2.2.2.2

If I change the configuration to make R2 and R4 have same cluster ID, R2 becomes primary RR, and R4 becomes the redundant RR. Still R5 chooses the best path which is reflected by R2.

What is the advantage of the 2^nd configuration of making R4 the redundant RR?

[Giuseppe Larosa]

Hello Jingyi,

when both RR are members of the same cluster they do not exchange routes coming from route-reflector clients assuming all clients have valid iBGP sessions with both.

When RR are in different cluster they exchange NLRI of their own clients even if most or all of them are in common.

This second design pays in terms of unnecessary routing information exchanged by the RR, but provides protection from the case where a client X  has lost iBGP connection to RR1 and a client Y has lost connection to RR2. With this second design this particular fault scenario is covered and services between clientX and client Y are still operational (think of an MPLS L3 VPN for example)

Hope to help

Giuseppe

[shelley_wang]

Hi Guiseppe,

It is surprising to hear that both RRs in different cluster is a better design than both RRs in same cluster (Redundant RR).

Would you please draw diagrams of both designs for more clarifications?

thx,

Jingyi