No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search


To have a better experience, please upgrade your IE browser.


Configuration Guide - IP Unicast Routing

CloudEngine 12800 and 12800E V200R002C50

This document describes the configurations of IP Unicast Routing, including IP Routing, Static Route, RIP, RIPng, OSPF, OSPFv3, IPv4 IS-IS, IPv6 IS-IS, BGP, Routing Policy, and PBR.

Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
Route Reflector

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 9-3, the following roles are involved in RR scenarios in an AS.

Figure 9-3 Networking diagram of the RR

  • 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 of which routes are reflected by the RR to other IBGP devices. In an AS, clients only need to directly connect to the RR.

  • 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 only need to exchange routing information with the RR in the same cluster. Therefore, clients only need to establish IBGP connections with the RR. This reduces the number of IBGP connections in the cluster. As shown in Figure 9-3, 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.

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

Backup RR

To ensure network reliability and prevent single points of failures, redundant RRs are required in a cluster. 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 solve this problem, all the RRs in the cluster must use the same cluster ID.

Figure 9-4 Backup RR

As shown in Figure 9-4, 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

There may be 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

Figure 9-5 Hierarchical RR

In practice, hierarchical RR is often used. As shown in Figure 9-5, 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

Figure 9-6 Flat RR

As shown in Figure 9-6, 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.

Updated: 2019-03-21

Document ID: EDOC1000166601

Views: 276485

Downloads: 161

Average rating:
This Document Applies to these Products

Related Version

Related Documents

Previous Next