Full mesh network topologies are a vital aspect of resilient networks. However, iBGP routers do not advertise routes learned from iBGP neighbors. BGP Route Reflectors solve this problem and enable full-mesh topology within an AS and route propagation across an AS. Additionally, Route Reflectors simplify network configuration from an iBGP neighborship perspective and improve scalability.
To help you get started with BGP Route Reflectors, let’s take a closer look at how they work and provide a walkthrough of a BGP Route Reflector configuration so you can get hands-on with it.
Border Gateway Protocol (BGP) is the engine that keeps the whole internet running. Internet Service Providers (ISPs) and large enterprises use BGP to interconnect Autonomous Systems (AS) and route traffic within an AS.
BGP comes in two flavors: internal BGP (iBGP) and external BGP (eBGP). iBGP connects routers within an AS, while External BGP (eBGP) connects routers in different Autonomous Systems.
To understand BGP Route Reflector, it’s important to understand how iBGP advertises network paths to neighbors.
eBGP uses the AS_PATH attribute to avoid routing loops. The router will discard the route if it sees its own AS number on the list. iBGP, on the other hand, is used entirely within the AS and requires a different approach. iBGP uses the split-horizon rule, which means that if a BGP router receives a route from iBGP peering, it does not advertise that route to other iBGP peers.
Because of how iBGP route advertisement works, administrators need to work around it to ensure full connectivity. The three options for doing that are as follows:
- Full Mesh Topology - Full mesh topology requires every router to establish peering with every other router. The formula for this is N(N-1)/2. For example, having 10 routers will result in 10(10-1)/2 = 45 peerings. This topology can quickly get out of hand if we deal with larger networks.
- Route Reflector - A Route Reflector is a designated router that will reflect routes learned from other iBGP peers. All routers form a peering relationship only with the Route Reflector. In our case of 10 routers, this will result in only nine peerings instead of 45, as compared to the full mesh topology.
- BGP Confederation - BGP confederation is an alternative method that reduces the number of peerings required, although it is sometimes used in conjunction with Route Reflectors. A confederation employs nested autonomous systems into the original AS and is also advertised as a single AS to external peers. The nested autonomous systems are also forming eBPG peerings between themselves and thus avoid using Route Reflectors.
Standard Route Reflector topology
A Route Reflector simplifies an iBGP network when it comes to route propagation. However, it also creates a single point of failure. If the Route Reflector crashes, the entire network will be affected.
Clustering Route Reflectors is a standard solution to that problem. In a cluster configuration, each Route Reflector has a Cluster-ID (a four-byte string that can be manually configured or taken from the Router ID). Some cluster configurations give each Route Reflector the same Cluster-ID, while others assign a unique ID to each one.
BGP route reflector and the types of iBGP routers
The broad categories of iBGP routers are Route Reflectors, Route Reflector clients, and Route Reflector non-clients.
There are a few rules that BGP Route Reflectors obey when it comes to route propagation:
- Routes learned from Route Reflector clients are advertised to other RR clients and RR non-clients.
- Routes received from RR non-clients are advertised to RR clients only.
- Routes learned from eBGP neighbors are reflected to RR clients and RR non-clients.
- Only the best routes are reflected if there are multiple possible routes.
- The Route Reflector cannot change any attributes, including the next-hop address.
Avoiding routing loops with Route Reflector
iBGP networks with Route Reflectors use the optional non-transitive BGP attributes Originator ID and Cluster-ID to avoid routing loops.
The Originator ID is the actual Router ID that originated the route. It helps with loop prevention when the router sees its Originator ID in the list and discards the route.
The Cluster-ID is the Router ID of the Route Reflector. A Route Reflector discards a route if it comes from its Cluster-ID.
With Route Reflectors, the path selection process is following the standard BGP attributes as normally before evaluating Originator ID and Cluster-ID.
- A route without Originator ID is preferred over a reflected route with Originator ID.
- Routes with shorter Cluster lists are preferred over routes with longer Cluster lists.
Additional BGP attributes might come into play if there is a tie between the above criteria.
How to configure a BGP Route Reflector
For this walkthrough, let’s use a simple configuration with three routers and a single Route Reflector in the middle.
To create this configuration, start with the following commands.
As shown in the snippet above,only the configuration on the Route Reflector is different. We specify R1 and R3 as our RR clients in this case.
Next, run these commands to configure a loopback address on R1 to prove that we can advertise it to R3 through our Route Reflector.
The “show” command below shows that the Route Reflector received a route from an RR client. We can further check if R3 knows about the 184.108.40.206 loopback address.
Finally, the commands below demonstrate that R3 has learned about the loopback address, and the interesting fields to note are the “Originator” and “Cluster list” t.
The Route Reflector has introduced the Originator to cope with loops in the network as we are bypassing the split-horizon rule now. In our example, this is the IP address of R1. An iBGP router will not accept a route if it contains its own Originator IP address.
The other ‘Cluster list’ field is simply the Router ID of the Route Reflector. A single cluster refers to the Route Reflector and all of its clients.
BGP Route Reflectors reduce the number of peerings required for full-mesh connectivity in iBGP networks. Now that you understand BGP Route Reflectors, you can use them to streamline iBGP topology and improve network resilience.
Key takeaways to remember are:
- BGP Route Reflectors simplify route propagation in iBGP networks.
- Route Reflector clusters eliminate single points of failure.
- Using Originator ID and Cluster-ID can mitigate routing loops.
This BGP monitoring guide provides network administrators and engineers with the technical and informational background necessary to successfully and responsibly monitor BGP in their own networks.
Learn about the six states of the BGP protocol and follow instructions with examples to learn how to configure BGP correctly.
Learn the benefits and best practices for implementing BGP multipath along with step by step configuration examples.
Learn how the BGP protocol chooses the best route for forwarding traffic, understand its use cases, and follow configuration instructions along with examples.
Learn BGP hijacking in depth, including how BGP advertisements work, how bad actors perform hijacks, and how you can detect and prevent BGP route hijacking.
Understand the unintentional causes and the repercussions of BGP resets and learn the best practices for safely executing them.
Learn the top tips, and tricks to assist you in quickly diagnosing and fixing BGP session issues using features ranging from ACLs to multihop TTL.
Understand how the BGP local preference attribute determines the preferred outbound path from the local AS by following examples and instructions.
Learn how a BGP tunnel broker is used to provide IPv6 connectivity to a network that exists in a region of the Internet that supports only IPv4.
Follow a detailed explanation of the BGP MED attributes and follow examples and instructions for correctly configuring it in your environment.