BGP Route Reflector

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. 

Understanding BGP

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. 

{{banner-14="/design/banners"}}

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. 

 {{banner-7="/design/banners"}}

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. 

R1(config)#router bgp 100 
R1(config-router)#neighbor 10.1.1.2 remote-as 100

R3(config)#router bgp 100 
R3(config-router)#neighbor 10.2.2.2 remote-as 100

R2-RR(config)#router bgp 100 
R2-RR(config-router)#neighbor 10.1.1.1 remote-as 100 
R2-RR(config-router)#neighbor 10.1.1.1 route-reflector-client 
R2-RR(config-router)#neighbor 10.2.2.3 remote-as 100
R2-RR(config-router)#neighbor 10.2.2.3 route-reflector-client

{{banner-15="/design/banners"}}

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. 

R1(config)#router bgp 100
R1(config-router)#network 5.5.5.5 mask 255.255.255.255

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 1.1.1.1 loopback address.

R2-RR#show ip bgp 5.5.5.5
BGP routing table entry for 5.5.5.5/32, version 2
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     2
  Refresh Epoch 1
  Local, (Received from a RR-client)
    10.1.1.1 from 10.1.1.1 (10.1.1.1)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0
      

R2-RR#show ip bgp neighbors 10.2.2.3 advertised-routes
BGP table version is 2, local router ID is 10.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *>i 5.5.5.5/32       10.1.1.1                 0    100      0 i

Total number of prefixes 1

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.

R3#show ip bgp 5.5.5.5
BGP routing table entry for 5.5.5.5/32, version 0
Paths: (1 available, no best path)
  Not advertised to any peer
  Refresh Epoch 1
  Local
    10.1.1.1 (inaccessible) from 10.2.2.2 (10.2.2.2)
      Origin IGP, metric 0, localpref 100, valid, internal
      Originator: 10.1.1.1, Cluster list: 10.2.2.2
      rx pathid: 0, tx pathid: 0
      

{{banner-sre="/design/banners"}}

Summary

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.