1. Overview
BGP uses the AS_Path attribute to prevent routing loops between ASs. However, the AS_Path attribute of routes changes only if the routes are transmitted between EBGP peers and remain unchanged if the routes are transmitted between IBGP peers. That is why the attribute cannot be used to prevent routing loops within an AS. To prevent routing loops within an AS, BGP defines an IBGP split-horizon rule that each BGP router does not transmit the BGP routes learned from an IBGP peer to other IBGP peers. According to the rule, BGP routers in an AS must establish fully meshed peer relationships to obtain complete BGP route updates. This practice has very low scalability and burdens network devices. To improve scalability in this case, you can deploy the route reflector (RR) or confederation solution. The confederation solution requires that all routers in each confederation support the confederation mechanism, whereas the RR solution only requires that the RR support the RR mechanism. In addition, the RR solution is easier to implement and is a good choice for large networks with redundant and hierarchical network architectures. If you want to use various EBGP mechanisms to manage large-scale ASs, the confederation solution is a better choice.
On the network shown in the preceding figure, due to the IBGP split-horizon rule, R4 does not advertise the route updates received from its IBGP peer R3 to another IBGP peer R5. In this case, R5 cannot learn the route updates unless an IBGP connection is set up between R3 and R5.
To address this problem, you can configure an RR and specify clients for it so that the RR reflects the routes received from a client to other IBGP peers. In this example, R4 is configured as an RR, with R3 as its client. In this case, R3 and R4 form a cluster.
A cluster, which consists of RRs (if more than one RR with the same Cluster_ID is configured) and clients, can be viewed as a logical unit. Within the cluster, relevant configurations are performed only on the RRs, with the clients unaware of the cluster. Note that RRs advertise or reflect only optimal routes that they know. To maintain a consistent BGP topology, RRs do not modify the Next_Hop, AS_Path, Local_Pref, or MED attribute when reflecting routes. In addition, RRs use the Originator_ID and Cluster_List attributes to prevent routing loops.
2. Route Reflection Rules
The route reflection rules are as follows:
· If a route is learned from a non-client IBGP peer, the route has reflected all clients.
· If a route is learned from a client, the route is reflected to other clients and all non-client IBGP peers. (Route reflection between clients through an RR can be disabled on Huawei devices.)
· If a route is learned from an EBGP peer, the route is sent to all clients and non-client IBGP peers.
Pay attention to the keywords marked in red. The following examples show the differences between reflecting and sending:
