What is BGP Route Reflector – Explanation and Discussion (with Cisco Example)

Border Gateway Protocol (BGP) is the protocol of choice for routing on the Internet.  BGP is also often used on the edge of corporate networks and is often the routing protocol of choice for large private enterprise networks. 

BGP needs to be extremely scalable to respond to these requirements.  One of the ways that this vast scalability is ensured is through the use of a BGP route reflector.  In this article, we’ll explain what it is and how it works.

Basic BGP Design

BGP is a path vector routing protocol that uses autonomous systems (AS) to route traffic to its destination. 

Each AS is composed of BGP routers that create BGP peerings or neighbor adjacencies.  BGP peerings between routers that are in the same AS are said to use internal BGP, or iBGP, while those peerings between routers in different ASes are said to use external BGP, or eBGP.

Full mesh iBGP Peerings

One of the requirements for the implementation of BGP within an AS is that iBGP peerings within an AS must be implemented as a full mesh. 

Now this requirement is fine for small ASes that consist of less than ten iBGP routers.  However, as the number of iBGP routers increases, the number of iBGP neighbor adjacencies you must configure increases exponentially.  Specifically, for every N iBGP routers in an AS, you must create N*(N-1)/2 peerings.

To put that into perspective, if you have 12 iBGP routers in an AS, you must create 12*(12-1)/2 peerings, or 66 peerings. 

Unlike OSPF or EIGRP which can automatically detect and create neighbor adjacencies, BGP requires that you manually configure the neighbor adjacencies.  You can immediately see the administrative overhead that such a situation would require.

Large AS Sizes

Keeping in mind that many ASes on private enterprise networks as well as on the Internet at large do consist of dozens or even hundreds of iBGP routers, there must be an alternative to creating a full mesh iBGP topology.  There are two alternatives to a full mesh iBGP topology:

• BGP Route Reflectors
• BGP confederations.

Here is also a comparison between BGP Confederations vs Route Reflectors.

What is a Route Reflector?

BGP route reflector (RR) is a network routing design approach in BGP that is used to bypass the full mesh peering problem described above, which arises in large networks where each router has to maintain an adjacency with every other router.

In this design, a route reflector is designated within an AS. It receives BGP updates from specific iBGP routers called clients and reflects or readvertises these updates to other clients and non-client peers.

This allows for a more scalable solution by reducing the number of necessary peerings and helping to manage the propagation of routing information within the AS.

RR Specifics

Note that the verb “to reflect” and all of its forms in the context of RRs simply refers to the readvertising of routes that it learns. 

Also, note that this behavior of an RR of readvertising a route is an exception to the split horizon rule of iBGP which states that any route received from an iBGP peer should never be readvertised to another iBGP peer.

In addition, it’s important to realize that the Route Reflector itself does not alter any routes, but simply acts as a relay point for routing information.  In this sense, an RR is similar in design to the use of a Designated Router (DR) in OSPF which is deployed on a per-network-segment basis.

RR Peerings and Design

An iBGP router designated as an RR can have three types of peerings:

• eBGP neighbor – An RR can have an eBGP peering with a router that belongs to another AS
• iBGP client neighbor – An iBGP peering can be configured to an iBGP client neighbor. An iBGP client neighbor is an iBGP router that the RR will reflect or re-advertise routes to.
• iBGP non-client neighbor – This is an iBGP peering to another iBGP router. This is a regular iBGP peering where no route reflecting is involved.

Now you may have realized that the use of an RR seems to create a single point of failure. If the RR in the AS goes down, all the reflected routes are lost.  For this reason, it is possible to have two or more RRs within an AS delivering redundancy in the design.

RR Route Forwarding Rules

In order to share routes in a way that avoids creating routing loops, RRs must adhere to specific rules that determine which learned routes can be readvertised, and to what type of peer they can be readvertised.  These rules are stated below:

• A route learned by an RR from a non-client neighbor is reflected to client neighbors but not to other non-client neighbors.
• A route learned by an RR from a client neighbor is reflected to both client neighbors and non-client neighbors.
• A route learned by an RR from an eBGP neighbor is reflected to both client neighbors and non-client neighbors.

Configuration Example of RR on Cisco Routers

Now we’ll see a configuration example of Route Reflector on Cisco router devices.

Let’s take a look at this topology of three iBGP peers. 

Under normal iBGP rules, we would have to configure three iBGP peerings, one for each pair of routers.  Remember, iBGP routers don’t need to be directly connected, so R1 and R3 can be configured to become iBGP peers.

In our scenario however, we will make R2 our RR, and create client peerings between R1 and R2, and between R2 and R3.  We will see how R1 will advertise the 1.1.1.1/32 network to the RR, and the RR will readvertise that route to R3.

Let’s begin with our basic BGP configuration on R1 and R3:

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

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

Note that from the point of view of these routers, the iBGP configuration is configured normally.  No specialized configuration is necessary.  Now let’s configure the RR which is our R2 router:

R2(config)#router bgp 100
R2(config-router)#neighbor 10.10.12.1 remote-as 100
R2(config-router)#neighbor 10.10.12.1 route-reflector-client
R2(config-router)#neighbor 10.10.23.3 remote-as 100
R2(config-router)#neighbor 10.10.23.3 route-reflector-client

The RR clients are identified within the configuration of the RR.  Note the route-reflector-client keyword that is used in the neighbor command.

Now let’s advertise via iBGP the network on loopback 0 of R1:

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

Testing the Results

Now we’re all set.  Let’s see how routes are shared between the iBGP peers.  Let’s start by taking a look at what the RR learned from R1:

R2#show ip bgp 1.1.1.1

BGP routing table entry for 1.1.1.1/32, version 2
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x820
  Advertised to update-groups:
        1
  Local, (Received from a RR-client)
    10.10.12.1 from 10.10.12.1 (1.1.1.1)
      Origin IGP, metric 0, localpref 100, valid, internal, best

We can see that this route was received from an RR client (bold red text).  Now R2, as an RR should have relayed this route to R3.  Let’s take a look at what routes R2 has advertised.  We can do this using the advertised-routes keyword with the show ip bgp neighbors command.:

R2#show ip bgp neighbors 10.10.23.3 advertised-routes

BGP table version is 2, local router ID is 10.10.23.2
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
              r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete

   Network          Next Hop            Metric LocPrf Weight Path

*>i1.1.1.1/32       10.10.12.1               0    100      0 i

We can see that R2 has advertised the 1.1.1.1/32 network to R3 with R1 as the next hop.  Let’s now take a look at what information R3 has received:

R3#show ip bgp 1.1.1.1

BGP routing table entry for 1.1.1.1/32, version 0
Paths: (1 available, no best path)
  Not advertised to any peer
  Local
    10.10.12.1 (inaccessible) from 10.10.23.2 (10.10.23.2)
      Origin IGP, metric 0, localpref 100, valid, internal
      Originator: 1.1.1.1, Cluster list: 10.10.23.2

The 1.1.1.1/32 route exists as a routing entry in R3’s BGP table, so the RR has done its job.  Just a note here, if we were to try to ping 1.1.1.1 from R3, the ping would fail. 

This is because we have not configured routing within our AS, which is a prerequisite for the operation of iBGP within an AS.  

This is why the 10.10.12.1 next hop indicated in the above output is considered inaccessible, due to the fact that there is no available route to this next hop address.

However, the purpose of this exercise was to see how RRs share iBGP routes between client neighbors, and we have been successful in this.

Conclusion

This piece serves as a fundamental primer on RRs, outlining their function, operational principles, and initial configuration guidelines.  

Nevertheless, a comprehensive understanding of RRs goes beyond the scope of this article, encompassing more complex elements like cluster lists, originator ID markers, and the establishment of redundant RRs.  

Even so, I trust that this article has effectively paved the way for your further exploration into the world of RRs, providing a stepping stone to a deeper comprehension of their nature and functionality.