BGP route reflectors, used as an alternate method to full-mesh IBGP, help in scaling. A BGP route reflector cluster is used to provide redundancy in a BGP RR design: the route reflectors and their clients together create a cluster (Cluster = BGP RR + BGP RR Clients).
In this article, I will first explain what a route reflector is and why it is used, then focus on route reflector clusters, the cluster-ID and cluster list attributes, route reflector design and redundancy rules, and finally compare route reflectors with BGP confederation.
I am explaining this topic in deep detail in our specialized BGP Zero to Hero course.
What Is a BGP Route Reflector?
A BGP route reflector (RR) is a network routing component for BGP, defined in RFC 4456. It offers an alternative to the logical full-mesh requirement of the Internal Border Gateway Protocol (IBGP).
There are two BGP methods: EBGP and IBGP. In EBGP, a BGP neighborship is created between two routers that have different BGP Autonomous System numbers. In IBGP, the neighborship is created between routers that have the same BGP Autonomous System number. A route reflector is only used in IBGP.
The requirement with IBGP is that every BGP speaker has to be in a logical full mesh: every BGP router needs to have a direct IBGP neighborship with all the other BGP routers in one particular BGP Autonomous System.
Figure 1 - IBGP Full Mesh
The route reflector is the exception to this rule. If you place a BGP route reflector, the IBGP routers set up a BGP neighborship with only the route reflectors. A route reflector is not a special device; it is a regular router, physical or virtual, that runs BGP code.
Figure 2 - BGP Route Reflector Topology
As you can see in the topology above, the route reflector is a central node that all the other BGP routers in the network build an IBGP neighborship with. Routers that have a BGP session to the route reflector are called route reflector clients.
Did you notice what changed between Figure 1 and Figure 2? The topology changed from full mesh to hub-and-spoke. So we can say that a BGP route reflector changes the logical BGP topology of the network from full mesh to hub-and-spoke.
Why Is a BGP Route Reflector Used?
Almost every Service Provider network uses BGP route reflectors, and the main reason is scaling. When you don't need an IBGP neighborship to each and every BGP router in the network, you have fewer BGP sessions, which means fewer connections to troubleshoot and maintain. Configuration on the devices is greatly reduced too.
In Figure 2, each RR client has only one BGP session. Without a route reflector in that topology, since there are six routers, each router would have five IBGP sessions.
Reducing the number of BGP sessions also reduces CPU and memory usage on the routers, which can otherwise escalate quickly as the network grows. In addition, route reflectors centralize route management: network administrators can implement routing policies directly on the RR to influence routing decisions across the network, which simplifies management and keeps routing policies consistent.
What Is a BGP Route Reflector Cluster?
A BGP route reflector cluster is the route reflector and all of its clients. If you have an RR and its RR clients, you have a BGP cluster. This is a very important and less-known definition, and it is the foundation of route reflector redundancy design, which we will cover next.
What Is the BGP Route Reflector Cluster-ID?
The Route Reflector Cluster-ID is a four-byte BGP attribute, and, by default, it is taken from the route reflector's BGP router ID. If two routers share the same BGP cluster-ID, they belong to the same cluster.
Before reflecting a route, the route reflector appends its cluster-ID to the cluster list. If the route originated from the route reflector itself, then the route reflector does not create a cluster list. If the route is sent to an EBGP peer, the RR removes the cluster list information. If the route is received from an EBGP peer, the RR does not create a cluster list attribute.
Why Is the BGP Route Reflector Cluster List Used?
The RR cluster list is used for loop prevention, and it is used only by the route reflectors. Route reflector clients do not use the cluster list attribute, so they do not know which cluster they belong to.
If an RR receives a route from an IBGP neighbor that carries the same cluster-ID, the route is discarded. This behavior is exactly what drives the same-or-different cluster-ID design decision below.
Same or Different Cluster-ID on Redundant Route Reflectors?
If there are two route reflectors, are the same or different cluster-IDs better on the route reflectors? Let's start with the basic topology.
Figure 3 - Route reflectors use the same cluster-ID
In the diagram shown above in Figure 3, R1 and R2 are the route reflectors, and R3 and R4 are the RR clients. Both route reflectors use the same cluster-ID. Green lines depict physical connections; red lines show IBGP connections.
Assume that both route reflectors use cluster-ID 1.1.1.1, which is R1's router ID. R1 and R2 receive routes from R4, and R1 and R2 receive routes from R3. Both R1 and R2, as route reflectors, append 1.1.1.1 as the cluster-ID attribute in the routes they send to each other. However, since they use the same cluster-ID, they discard each other's routes.
That's why, if the RRs use the same cluster-ID, the RR clients have to connect to both RRs.
In this topology, the routes behind R4 are learned by R1 only from the direct R1-R4 IBGP session (R1 rejects them from R2). Of course, the IGP path goes through R1-R2-R4, since there is no physical path between R1 and R4.
If the physical link between R2 and R4 goes down, both IBGP sessions between R1-R4 and R2-R4 go down as well. Thus, the networks behind R4 cannot be learned. Since the routes cannot be learned from R2 (same cluster-ID), if the physical link is up but the IBGP session between R1 and R4 goes down, the networks behind R4 will not be reachable either. But if you have the BGP neighborship between loopbacks and the physical topology is redundant, the chance of the IBGP session going down is very small.
Note: Having redundant physical links is a common network design best practice. That's why the topology below is a more realistic one.
What if we add a physical link between R1-R4 and R2-R3?
Figure 4 - Route reflectors use the same cluster-ID; physical cross-connections are added between the RRs and the RR clients
In Figure 4, physical cross-connections are added between R1-R4 and R2-R3. We are still using the same BGP cluster-ID on the route reflectors.
Thus, when R2 reflects R4's routes to R1, R1 will discard those routes. In addition, R1 will learn R4's routes through its direct IBGP peering with R4. In this case, the IGP path will change to R1-R4 rather than R1-R2-R4.
In a situation in which the R1-R4 physical link fails, the IBGP session will not go down if the IGP converges to the R1-R2-R4 path quicker than the BGP session timeout (by default it does).
Thus, having the same cluster-ID on the RRs saves a lot of memory and CPU resources on the route reflectors, and link failures do not cause IBGP session drops if there is enough redundancy in the network.
If we used different BGP cluster-IDs on R1 and R2, R1 would accept the reflected routes from R2 in addition to the routes from its direct peering with R4. The route reflectors would keep an extra copy of each prefix, which increases memory usage, but having the additional path can provide faster convergence in some failure cases, depending on the topology.
BGP Route Reflector Design and Redundancy Rules
A route reflector is an important node: its failure collapses the BGP topology it serves. Thus, RR redundancy is important, and having more than one route reflector is a must. As a general design rule, I always recommend two — not three or four. What was the motto? Two is the company, three is crowded.
Beyond the number of route reflectors, several design rules and best practices should be observed:
Route reflector candidates should be robust, high-capability routers placed at strategic locations in the network, so that route propagation reaches everywhere with minimal latency. They should have high-availability and redundancy features to prevent a single point of failure, which could lead to large-scale network disruption.
Route reflectors do not need direct physical connections to all of their clients; they only need to be reachable through the network. Build the IBGP sessions between loopback interfaces so that, as long as the IGP finds any path, the BGP sessions stay up during link failures.
Use filters and route policies on the route reflectors to manage and optimize the propagation of routing information to and from the client routers. Since the RR is the central point for route advertisements, this is also where routing policy is implemented consistently.
There can be different services in the network, such as Internet and VPN services. When the route reflector is used for the IP address family, it is called an IP RR; when it is used in an MPLS network for the VPN service, it is called a VPN RR. Should you use the same router for both IP RR and VPN RR functions? It depends. If the deployment is small enough, you can. But always consider the impact of a problem in one service on the other: if there is an attack on the IP RR, it will affect the VPN customers as well. This concept is called fate-sharing.
In large networks, engineers can go beyond a single pair of route reflectors and deploy multiple RR clusters or a hierarchy of route reflectors within the autonomous system. Clustered and layered RRs help distribute the load and improve fault tolerance. As the network grows and evolves, the RR setup should be monitored and adjusted continuously.
One design trade-off to keep in mind: a route reflector selects only one best path for a destination and advertises only that path to its clients. This saves memory and CPU on the clients, but it hides the other available paths, which in some topologies can cause suboptimal routing and slower convergence. Techniques such as BGP Add-Path or unique RD per PE per VRF in MPLS VPN networks can be used when clients need to receive more than one path.
BGP Route Reflector vs Confederation
RR vs Confederation is one of the first things network engineers want to understand when they learn these two Internal BGP scalability mechanisms.
With BGP confederation, the BGP topology is divided into smaller parts, and each part is called a sub-autonomous system. There is only one global autonomous system that represents the network to the outside world; when this network has an EBGP connection with another BGP network, the global autonomous system number is used. Inside, each sub-autonomous system has its own number, and IBGP rules still apply inside every sub-AS.
Figure 5 - BGP Confederation
Scalability
Both of these techniques are used in Internal BGP for scalability purposes, but they work differently. The BGP route reflector changes the full-mesh IBGP topology to hub-and-spoke. BGP confederation divides the autonomous system into sub-ASes, but inside every sub-AS, IBGP rules are applied — so full-mesh IBGP or a route reflector is still required inside each sub-autonomous system.
This is why the route reflector is considered more scalable compared to confederation: inside a sub-AS, full-mesh IBGP might still be used, and if an RR is deployed inside the sub-AS, the configuration complexity increases. In fact, confederation is not exactly an alternative to the route reflector; the real alternative to a route reflector is full-mesh IBGP.
Loop Prevention
The BGP route reflector uses two BGP attributes to prevent routing loops: Originator-ID and Cluster List. With Originator-ID, if a BGP router sees its own router ID in the Originator-ID attribute of an update, it does not accept the update. With the cluster list, as the route passes through the route reflectors, each RR adds its cluster-ID into the cluster list; if an update arrives carrying the receiver's own cluster-ID, the update is not accepted, and the routing loop is prevented.
BGP confederation, on the other hand, records the sub-AS numbers in the AS path as the route travels between sub-autonomous systems, and a router rejects an update that already contains its own sub-AS number.
IGP Usage
A BGP route reflector is used in a single BGP AS, and inside a single BGP AS, usually a single IGP is used. This is not a hard rule — in theory, there can be multiple IGP protocols in different parts of the network — but in practice, single-AS and single-IGP designs are much more common in real-life networks.
BGP confederation is almost always the opposite. Confederation is seen in real life mostly because of mergers and acquisitions. The companies involved might be using different IGP protocols before the merger, and they usually continue to use them afterward, because their network engineers are familiar with those protocols operationally and design-wise. Forcing everyone onto a common IGP rarely makes sense in that situation.
Conclusion
Orhan Ergun recommends the same BGP cluster-ID for route reflector redundancy if there is a resource issue on the route reflectors. If there is no resource problem, having a different cluster-ID provides faster convergence in some cases, depending on the topology. Otherwise, the route reflectors would keep an extra copy of each prefix, which wouldn't be advertised to the route reflector clients anyway.
To gain a deeper understanding of Service Provider networks, you can check our Service Provider Networks Design and Architecture Perspective book.
