BGP multiple Route Reflectors
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.
Re: BGP multiple Route Reflectors
> 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?[/color]
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.