Fully meshed connections need to be established between IBGP peers to ensure the connectivity between IBGP peers. If there are n routers in an AS, n x (n-1)/2 IBGP connections need to be established. When there are a lot of IBGP peers, network resources and CPU resources are greatly consumed. Route reflection can solve the problem.
In an AS shown in Figure 1, one router functions as a Route Reflector (RR), with some other routers as its clients. The clients establish IBGP connections with the RR. The RR and its clients form a cluster. The RR reflects routes among clients, and BGP connections do not need to be established between the clients.
A BGP peer that functions as neither an RR nor a client is called a non-client. A non-client must establish fully meshed connections with the RR and all the other non-clients.
After receiving routes from peers, an RR selects the optimal route based on BGP route selection rules and advertises the optimal route to other peers based on the following rules:
If the optimal route is from a non-client IBGP peer, the RR advertises the route to all clients.
If the optimal route is from a client, the RR advertises the route to all non-clients and clients.
If the optimal route is from an EBGP peer, the RR advertises the route to all clients and non-clients.
An RR is easy to configure because it only needs to be configured on the router that needs to function as an RR, and clients do not need to know whether they are clients.
On some networks, if fully meshed connections have already been established among clients of an RR, they can exchange routing information directly. In this case, route reflection among the clients through the RR is unnecessary and occupies bandwidth. For example, on the NetEngine 8000 F, route reflection through the RR can be disabled, but the routes between clients and non-clients can still be reflected. By default, route reflection between clients through the RR is enabled.
On the NetEngine 8000 F, an RR can change various attributes of BGP routes, such as the AS_Path, MED, Local_Pref, and community attributes.
Originator_ID and Cluster_List are used to detect and prevent routing loops.
The Originator_ID attribute is four bytes long and is generated by an RR. It carries the router ID of the route originator in the local AS.
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 is used to identify the router that originates the route. If a route already carries the Originator_ID attribute, the RR does not create a new one.
After receiving the route, a BGP speaker checks whether the Originator_ID is the same as its router ID. If Originator_ID is the same as its router ID, the BGP speaker discards this route.
To prevent routing loops between ASs, a BGP router uses the AS_Path attribute to record the ASs through which a route passes. Routes with the local AS number are discarded by the router. To prevent routing loops within an AS, IBGP peers do not advertise routes learned from the local AS.
With RR, IBGP peers can advertise routes learned from the local AS to each other. However, the Cluster_List attribute must be deployed to prevent routing loops within the AS.
An RR and its clients form a cluster. In an AS, each RR is uniquely identified by a Cluster_ID.
To prevent routing loops, the RR uses the Cluster_List attribute to record the Cluster_IDs of all RRs through which a route passes.
Similar to an AS_Path, which records all the ASs through which a route passes, a Cluster_List is composed of a series of Cluster_IDs and records all RRs through which a route passes. The Cluster_List is generated by the RR.
Before an RR reflects a route between its clients or between its clients and non-clients, the RR adds the local Cluster_ID to the head of the Cluster_List. If a route does not carry any Cluster_List, the RR creates one for the route.
After the RR receives an updated route, it checks the Cluster_List of the route. If the RR finds that its cluster ID is included in the Cluster_List, the RR discards the route. If its cluster ID is not included in the Cluster_List, the RR adds its cluster ID to the Cluster_List and then reflects the route.
To enhance network reliability and prevent single points of failure, more than one route reflector needs to be configured in a cluster. The route reflectors in the same cluster must share the same Cluster_ID to prevent routing loops. Therefore, the same Cluster_ID must be configured for all RRs in the same cluster.
With backup RRs, clients can receive multiple routes to the same destination from different RRs. The clients then apply BGP route selection rules to choose the optimal route.
On the network shown in Figure 2, RR1 and RR2 are in the same cluster. RR1 and RR2 establish an IBGP connection so that each RR is a non-client of the other RR.
If Client 1 receives an updated route from an external peer, Client 1 advertises the route to RR1 and RR2 through IBGP.
After receiving the updated route, RR1 adds the local Cluster_ID to the top of the Cluster_List of the route and then reflects the route to other clients (Client 1, Client 2, and Client 3) and the non-client (RR2).
After receiving the reflected route, RR2 checks the Cluster_List and finds that its Cluster_ID is contained in the Cluster_List. In this case, it discards the updated route and does not reflect it to its clients.
If RR1 and RR2 are configured with different Cluster_IDs, each RR receives both the routes from its clients and the updated routes reflected by the other RR. Therefore, configuring the same Cluster_ID for RR1 and RR2 reduces the number of routes that each RR receives and memory consumption.
The application of Cluster_List prevents routing loops among RRs in the same AS.
Multiple clusters may exist in an AS. RRs are IBGP peers of each other. An RR can be configured as a client or non-client of another RR. Therefore, the relationship between clusters in an AS can be configured flexibly.
For example, a backbone network is divided into multiple reflection clusters. Each RR has other RRs configured as its non-clients, and these RRs are fully meshed. Each client establishes IBGP connections only to the RR in the same cluster. In this manner, all BGP peers in the AS can receive reflected routes. Figure 3 shows the networking.
Hierarchical reflectors are usually deployed if RRs need to be deployed. On the network shown in Figure 4, the ISP provides Internet routes for AS 100. Two EBGP connections are established between the ISP and AS 100. AS 100 is divided into two clusters. The four routers in Cluster 1 are core routers.
Two Level-1 RRs (RR-1s) are deployed in Cluster 1, which ensures the reliability of the core layer of AS 100. The other two routers in the core layer are clients of RR-1s.
One Level-2 RR (RR-2) is deployed in Cluster 2. RR-2 is a client of RR-1.