9.1 Route Reflectors
9.1.4 Naming conventions and rules of operation
The IBGP peers of a RR fall under two categories, clients and nonclients; a RR and its clients form a cluster. All peers of the RR that are not part of the cluster are nonclients, and must be fully meshed in accordance with normal IBGP rules. Clients should not peer with internal speakers outside their associated cluster.

The RR function is configured only on the RR; all clients and nonclients are normal BGP peers that have no notion of the RR. Clients are considered part of the cluster only because the RR lists them as clients.

Any RR that receives multiple routes for the same destination will pick the best path based on the usual BGP decision process and propagates it inside the AS based on the following rules of operation:

  • If the route is received from a nonclient peer, reflect to clients only.
  • If the route is received from a client peer, reflect to all nonclient peers and also to client peers, except the originator of the route.
  • If the route is received from an EBGP peer, reflect to all client and nonclient peers.

Configuration Example: Route Reflectors

In the figure, RTA, RTB, and RTC form a single cluster, with RTC being the RR. Clients of a RR are configured using the neighbor route-reflector-client command. RTD is also the RR for its clients RTE and RTF; RTG is a RR in a third cluster. Note RTD, RTC, and RTG are fully meshed, but the routers within the clusters are not.

Note: Click on topology to view command outputs.

When a route is received by a RR, it will do the following, depending on the peer type:

  1. Route from a nonclient peer: reflect to all the clients within the cluster.
  2. Route from a client peer: reflect to all the nonclient peers and also to the client peers.
  3. Route from an EBGP peer: send the update to all client and nonclient peers.