BGP Route Reflector – Network Professional Member Site

Route reflectors (RR) are one method to eliminate the full-mesh of IBGP peers in your network. The other method is BGP confederations.

The route reflector allows all IBGP speakers within your autonomous network to learn about the available routes without introducing loops. Let me show you an example picture:

Above, we have a network with six IBGP routers. Using the full mesh formula, we can calculate the number of IBGP peerings:

N(N-1)/2

So that will be:

6(6-1=5) / 2 = 15 IBGP peerings.

When we use a route reflector, our network could look like this:

We still have six routers, but each router only has an IBGP peering with the route reflector on top. When one of those IBGP routes advertises a route to the route reflector, it will be “reflected” to all other IBGP routers:

This simplifies our IBGP configuration a lot, but there’s also a downside. What if the route reflector crashes? It’s a single point of failure when it comes to IBGP peerings. Of course, there’s a solution to this: we can have multiple route reflectors in our network. I’ll give you some examples later.

The route reflector can have three types of peerings:

EBGP neighbor
IBGP client neighbor
IBGP non-client neighbor

When configuring a route reflector, you must tell the router whether the other IBGP router is a client or non-client. A client is an IBGP router to which the route reflector will “reflect” routes. The non-client is just a regular IBGP neighbor.

Rules

When a route reflector forwards a route, there are a couple of rules:

A route learned from a non-RR client is advertised to RR clients but not to non-RR clients.
A route learned from an RR client is advertised to both RR clients and non-RR clients. Even the RR client that advertised the route will receive a copy and discard it because it sees itself as the originator.
A route learned from an EBGP neighbor is advertised to both RR clients and non-RR clients.

Here are three illustrations to see these rules in action.

Rule 1

Rule 2

Rule 3

Now you have an idea of what the route reflector is about, let’s take a look at some configurations.

Configuration

We’ll use a simple example, 3 IBGP routers with a single route reflector:

In this example, we have 3 IBGP routers. With normal IBGP rules, when R2 receives a route from R1, it will not be forwarded to R3 (IBGP split horizon). We will configure R2 as the route reflector to get around this. Let’s configure R1 and R3 first:

R1(config)#router bgp 123
R1(config-router)#neighbor 192.168.12.2 remote-as 123

R3(config)#router bgp 123
R3(config-router)#neighbor 192.168.23.2 remote-as 123

The configuration of R1 and R3 is exactly the same as a normal IBGP peering. Only the configuration on the route reflector is special:

R2(config)#router bgp 123
R2(config-router)#neighbor 192.168.12.1 remote-as 123
R2(config-router)#neighbor 192.168.12.1 route-reflector-client

R2(config-router)#neighbor 192.168.23.3 remote-as 123
R2(config-router)#neighbor 192.168.23.3 route-reflector-client

Here’s the magic…when we configure the route reflector, we have to specify its clients. In this case, R1 and R3. In my topology, I have added a loopback interface on R1. Let’s advertise that in BGP to see what it looks like on R2 and R3:

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

That’s all we have to configure. Let’s use some show commands to verify our work.

Verification

First, we’ll look at R2 and see if it learned anything:

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)
    192.168.12.1 from 192.168.12.1 (1.1.1.1)
      Origin IGP, metric 0, localpref 100, valid, internal, best

R2 shows us that this route was received from a route reflector client. Did it advertise anything to R3? Let’s find out:

R2#show ip bgp neighbors 192.168.23.3 advertised-routes
BGP table version is 2, local router ID is 192.168.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       192.168.12.1             0    100      0 i

So what do we see here? Let me explain…

Excellent, the 1.1.1.1/32 route was advertised to R3. Let’s see what R3 thinks of this:

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
    192.168.12.1 (inaccessible) from 192.168.23.2 (192.168.23.2)
      Origin IGP, metric 0, localpref 100, valid, internal
      Originator: 1.1.1.1, Cluster list: 192.168.23.2

R3 has learned about this route from R2, and there are two important new fields that you can see here:

Originator
Cluster List

R2 added this information, but for what reason?

The IBGP split horizon rule was created to prevent loops. Since our route reflector violates this rule, we have to think of a new rule for loop prevention. That’s where these two items are used for:

The originator ID is set by the route reflector, you can see that this is the IP address of R1. When an IBGP router receives a route with its own originator ID, it will not accept the route. Just like with OSPF or EIGRP, it’s important that each BGP router has a unique router ID.

The other thing called the Cluster list is the router ID of the route reflector. When we talk about a cluster, we refer to a route reflector and its clients. Let me give you an example of a larger topology with multiple route reflectors:

This topology has three route reflectors, each serving 2 IBGP neighbors. Between the route reflectors, we still have to configure full mesh IBGP. It’s possible that a route loops between these route reflectors, so when a route reflector sees its own cluster-ID, it will drop the route

Rules

Rule 1

Rule 2

Rule 3

Configuration

Verification

Unit 1: Introduction to BGP

Unit 2: BGP Neighbor Adjacency

Unit 3: BGP Attributes

Unit 4: BGP Communities

Unit 5: BGP Filtering

Unit 6: Advanced BGP Features

Unit 7: BGP Convergence