Route Reflector
To ensure connectivity between IBGP peers, you need to establish full-mesh connections between IBGP peers. If there are n devices in an AS, n(n-1)/2 IBGP connections need to be established. When there are a large number of devices, many network resources and CPU resources are consumed. A route reflector (RR) can be used between IBGP peers to solve this problem.
Roles in RR
As shown in Figure 1, the following roles are involved in RR scenarios in an AS.
Route reflector (RR)
A BGP device that can reflect the routes learned from an IBGP peer to other IBGP peers. An RR is similar to a designated router (DR) on an OSPF network.
Client
An IBGP device whose routes are reflected by the RR to other IBGP devices. In an AS, clients need to connect only to the RR directly.
Non-client
An IBGP device that is neither an RR nor a client. In an AS, a non-client must establish full-mesh connections with the RR and all the other non-clients.
Originator
A device that originates routes in an AS. The Originator_ID attribute helps eliminate routing loops in a cluster.
Cluster
A set of the RR and clients. The Cluster_List attribute helps eliminate routing loops between clusters.
RR Principles
Clients in a cluster need to exchange routing information only with the RR in the same cluster. Therefore, clients need to establish IBGP connections only with the RR. This reduces the number of IBGP connections in the cluster. As shown in Figure 1, in AS 65000, Cluster1 is comprised of an RR and three clients. The number of IBGP connections in AS 65000 is then reduced from 10 to 4, which simplifies the device configuration and reduces the loads on the network and CPU.
The RR allows a BGP device to advertise the BGP routes learned from an IBGP peer to other IBGP peers, and uses the Cluster_List and Originator_ID attributes to eliminate routing loops. The RR advertises routes to IBGP peers based on the following rules:
The RR advertises the routes learned from a non-client to all the clients.
The RR advertises the routes learned from a client to all the other clients and all the non-clients.
The RR advertises the routes learned from an EBGP peer to all the clients and non-clients.
Cluster_List Attribute
An RR and its clients form a cluster, which is identified by a unique cluster ID in an AS. To prevent routing loops between clusters, an RR uses the Cluster_List attribute to record the cluster IDs of all the clusters that a route passes through based on the following rules:
When a route is reflected by an RR for the first time, the RR adds the local cluster ID to the top of the cluster list. If there is no cluster list, the RR creates a Cluster_List attribute.
When receiving an updated route, the RR checks the cluster list of the route. If the cluster list contains the local cluster ID, the RR discards the route. If the cluster list does not contain the local cluster ID, the RR adds the local cluster ID to the cluster list and then reflects the route.
Originator_ID Attribute
An originator ID identifies the originator of a route and is generated by an RR to prevent routing loops in a cluster. Its value is the same as a router ID.
When a route is reflected by an RR for the first time, the RR adds the Originator_ID attribute to this route. The Originator_ID attribute identifies the originator of the route. If the route contains the Originator_ID attribute, the RR retains this Originator_ID attribute.
When a device receives a route, the device compares the originator ID of the route with the local router ID. If they are the same, the device discards the route.
Backup RR
To ensure network reliability and prevent single-point failures, a cluster requires redundant RRs. An RR allows a BGP device to advertise the routes received from an IBGP peer to other IBGP peers. Therefore, routing loops may occur between RRs in the same cluster. To prevent this, all the RRs in the cluster must use the same cluster ID.
As shown in Figure 2, RR1 and RR2 reside in the same cluster and have the same cluster ID configured.
When Client1 receives an updated route from an EBGP peer, Client1 advertises this route to RR1 and RR2 using IBGP.
After RR1 and RR2 receive this route, they add the local cluster ID to the top of the cluster list of the route and then reflect the route to other clients (Client2 and Client3) and to each other.
After RR1 and RR2 receive the reflected route from each other, they check the cluster list of the route, finding that the cluster list contains their local cluster IDs. RR1 and RR2 discard this route to prevent routing loops.
RRs of Multiple Clusters in an AS
If there are multiple clusters in an AS, RRs of the clusters establish IBGP peer relationships. When RRs reside at different network layers, an RR at the lower network layer can be configured as a client to implement hierarchical RR. When RRs reside at the same network layer, RRs of different clusters can establish full-mesh connections to implement flat RR.
Hierarchical RR
In practice, hierarchical RR is often used. As shown in Figure 3, the ISP provides Internet routes to AS 100. AS 100 is divided into two clusters, Cluster1 and Cluster2. Four devices in Cluster1 are core routers and use a backup RR to ensure reliability.
Flat RR
As shown in Figure 4, the backbone network is divided into multiple clusters. RRs of the clusters are non-clients and establish full-mesh connections with each other. Although each client only establishes an IBGP connection with its RR, all the RRs and clients can receive all routing information.