3 Replies Latest reply: Mar 30, 2012 12:20 AM by sg4rb0sss RSS

    Intra-cluster Design


      Hi Guys


      If you have a RR and a bunch of clients hanging off it, then want to add another RR within the cluster to improve redundancy, it's suggested that the way you configure this is by manually configuring the cluster ID.  The idea is to stop the RR's from sending updates to each other (Configuring manual cluster ID's allows RR's to recognise updates from different RRs within the cluster).  It also provides loop detection, but I'm focusing on route updates between RR's here.   However, according to Brian from the INE group, he states that RR <--> RR connections are typically non-clients (so I assume he means they are connected via iBGP).  In which case, by defaut, iBGP neighbors do not advertise routes to other iBGP neighbors.  So why does manual configuration of the cluster ID make RR's recognise routes from each other?


      I think I must have misunderstood something here.  Can anyone help me understand?




        • 1. Re: Intra-cluster Design
          Bradford Chatterjee (CCIEx2/CCDE)

          Recall that routes received by a route reflector from a route reflector client are advertised to all clients and all iBGP peers because the client is assumed not to have a full mesh to the iBGP network. In a route reflector cluster you will have route reflectors that have a normal iBGP relationship and they will both have the same clients, so they will receive iBGP updates from the client and from the other RR.


          There are also cases where you may have RRs that are clients of other RRs for scalability reasons (this would be a very deep network). In this case you would also need the cluster ID for loop prevention as the RRs are reflecting the same routes many times and it's important to recognize when the routes are being reflected in loops - as will certainly happen.

          • 2. Re: Intra-cluster Design

            Hi Stephen.


              If you configure the RR peering with the router reflector client, RR will send updates to each other. This is a ibgp peering, but the rr client configuration overrides the dont advertise to ibgp.


               Under ebgp, the as path is used to detect loops. But for ibgp, the as path remains the same under the same AS. So bgp needs other way to detect routing loops.


               If you dont need the RR to exchange prefix, because these are not redundants under your topology, ther is no loops, then dont need to configure RR as rr clients each other, dont need peering between them, and dont need the cluster id.

               But both RR have to be connected to every bgp router in your network. And if a RR lost its connection to a peer, will not learn its prefix through any other ibgp peer.


               Under a redundant topology, or where one RR have some peers, and other RR other peers, you will need the cluster id, and RR should be rr clients each other.


               Think you have a triangle, 3 RR with different ibgp peers, each RR have to be rr client of the others RR, if not all peers will not have the same bgp table.

               If a path between two RR goes down, then they could use the other RR as a backup path.

               In this case there is a RR loop, the way to detect this is the cluster id. If not every ibgp route will be propagated from rr1 to rr2 to rr3 to rr1 to rr2 ....because they are rr clients. The cluster id breaks this loop, because when a prefix have the same router's cluster id, then routers checks if the received prefix has been originated by the router itself. This way detects the loop.


               So under a redundant topology and a rr loop, you will need the cluster id and RR should be rr clients. If you dont have a redundant topology, you dont need.


               Without cluster id there is no way to detect routing loops under ibgp, and this should be configured manually because in large scenarios you could have several rr "farms" and have several cluster id, confederations, etc.




            • 3. Re: Intra-cluster Design

              Hey Guys,


              Thanks for that guys.


              @Bradford.  So because RR's reflect RR client routes to iBGP neighbors (in our case, the other RR), a loop can form. Gotcha!  Thanks very much.