|
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:
-
Route from a nonclient peer: reflect to all the clients within the
cluster.
-
Route from a client peer: reflect to all the nonclient peers and also to
the client peers.
-
Route from an EBGP peer: send the update to all client and nonclient
peers.
|
|