Route Reflector

Application

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

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.

Cluster_List

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.

Backup RR

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.

Figure 2 Backup RR

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 in an 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.

Figure 3 Multiple clusters in an AS

Hierarchical Reflector

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.

Figure 4 Hierarchical reflector

In Figure 5, all PEs and RRs reside in the same AS, and peer relationships are established between each PE and its RR and between RRs in both VPNv4 and VPN-Target address families; PE1 is a client of the level-1 RR1, and PE2 is a client of the level-1 RR2; RRR is a level-2 RR, with RR1 and RR2 as its clients; RT 1:1 is configured on PE1 and PE2. PE1 receives a VPN route from CE1.

Figure 5 Networking with hierarchical RRs

If no RR cluster ID loop is allowed, after RR1 and RR2 advertise the RT routes learned from PEs to RRR (Level-2 RR), RRR implements route selection. If RRR selects the route learned from RR1, RRR advertises a VPN ORF route to RR1 and RR2. The Cluster_List of the route includes the local cluster ID. As a result, RR1 discards the VPN ORF route. Consequently, RR1 does not have the RT filter of RRR, unable to guide VPNv4 peers to advertise routes. As a result, CE2 fails to learn routes from CE1. To address this problem, run the peer allow-cluster-loop command in the BGP-VPN-Target address family view on RR1. In the command, the peer address is set to the address of RRR. After the command is run, RR1 can receive the RT routes advertised by RRR (Level-2 RR) and can guide VPNv4 peers to advertise routes.