13.4.9 Route Reflection

Route reflection is a means of reducing the number of internal peers in an AS. In BGP4, routing information distributed by one internal peer is not redistributed to any other internal peers. Therefore, internal peers must be logically fully meshed with each BGP speaker within the AS. Route reflection relaxes this restriction and reduces the number of internal peers in the AS by allowing redistribution of received routing information to other internal peers.

<Structure of this section>

(1) Route Reflection Concepts and Flow of Route Information

In route reflection, a route reflector (RR) and its clients constitute a cluster. A cluster can contain more than one RR. The other BGP speakers in the AS are referred to as non-clients.

On receiving an UPDATE message from a client in the cluster, the RR distributes the message to all clients (including the source client) in the cluster, and to all non-clients. Upon receiving an UPDATE message from a non-client, the RR distributes the message to all clients in the cluster. This eliminates the need for internal peer relationships from client to non-client, or among the clients in a cluster.

Routing information distributed from external peers and member AS peers, or to external peers and member AS peers, is handled in the usual manner.

(2) When placing one route reflector in a cluster

The following figure shows an example of route reflection with one RR in the cluster.

Figure 13-23: Example of placing a route reflector in a cluster

Router 1 (route reflector) and Routers 2 and 3 (clients) form a cluster. Router 4 (route reflector) and Routers 5 and 6 (clients) form another cluster. Routing information advertised from Router 2 to Router 1 is distributed to the clients (Routers 2 and 3) and all non-clients (Router 4). Routing information advertised from Router 1 to Router 4 is distributed to all clients (Routers 5 and 6).

(3) Placing multiple route reflectors in a cluster

A cluster can have more than one RR. This prevents the route reflection functionality from stopping if an RR fails.

Each RR forms an internal peer relationship with clients and non-clients. As described in Figure 13-23: Example of placing a route reflector in a cluster, each route reflector redistributes routing information reported by a client or non-client. In this way, if one RR fails, the routing information can be redistributed by the other RR. When there are multiple RRs in a cluster, the same cluster ID must be set for each RR, using the bgp cluster-id configuration command.

The following figure shows an example of a redundant RR configuration.

Figure 13-24: Example of a redundant configuration for a route reflector

The cluster contains two RRs (Routers 1 and 2). Each of which has internal peer relationships with clients (Routers 3 and 4) and with non-clients (Routers 5 and 6). For example, routing information reported from client Router 3 will be redistributed by the RRs (Routers 1 and 2) to clients (Routers 3 and 4) and non-clients (Routers 5 and 6). Should one RR fail, the routing information will be reported by the other RR. BGP speakers that do not belong to the cluster (Routers 5 and 6) can also be present in the AS.