BGP multiple Route Reflectors - TCP-IP

This is a discussion on BGP multiple Route Reflectors - TCP-IP ; Hello, I have a question about BGP and Route Reflectors (RR). There is a possibility to have multiple RR in a cluster. To prevent routing loop RRs set the Originator-ID (their router ID) and the Cluster-ID attribute (to know that ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: BGP multiple Route Reflectors

  1. BGP multiple Route Reflectors

    Hello,
    I have a question about BGP and Route Reflectors (RR). There is a
    possibility to have multiple RR in a cluster. To prevent routing loop
    RRs set the Originator-ID (their router ID) and the Cluster-ID
    attribute (to know that they are in the same cluster).

    -When a RR receives a route and the originator-id on that route is its
    own, then the route is dropped (to prevent a loop).
    -When a RR receives a route with the same cluster-id it also drops it
    since that route was already shared with the cluster.

    For instance if RR1 sends out a route to the cluster, all of the
    clients receive the route and accept it, then the RR2 receives the
    route and since the cluster-id is the same as it would use, wouldn't
    the RR2 just drop the route? So my question is how do the two Route
    Reflectors share routes between each other?

    Thank you in advance.


  2. Re: BGP multiple Route Reflectors

    kemot wrote:
    >
    > For instance if RR1 sends out a route to the cluster, all of the
    > clients receive the route and accept it, then the RR2 receives the
    > route and since the cluster-id is the same as it would use, wouldn't
    > the RR2 just drop the route? So my question is how do the two Route
    > Reflectors share routes between each other?


    If multiple route reflectors belong to the same cluster, they
    won't learn *RR-client-routes* from each other. They will
    know the same RR-client-routes only if they keep identical
    RR-client peerings. Result is, within the cluster, all RR-clients
    should peer against all RR-servers. This will yield redundancy
    of RR-server, but not of RR peering. If one RR goes down, the
    cluster remains active. It would not allow, for instance, to
    "shutdown" client peerings against distinct RR servers. Though
    one could shutdown client peerings against a single RR server.

    However, I'm aware that Cisco currently does not recommend
    a such design (multiple RR servers on the same cluster). They
    think a slightly superior approach is to not configure cluster-id
    at all, so that each redundant RR-server lies on its separate
    cluster, and each protected RR-client should peer with
    multiple RR-servers, thus belonging to multiple clusters.
    In the one-RR-per-cluster design, it would be possible to
    "shutdown" any redundant RR-client-server peering, even
    against distinct RR-servers.

    Everton


+ Reply to Thread