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 6 IBGP routers. Using the full mesh formula we can calculate the number of IBGP peerings:
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 6 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 type of peerings:
- EBGP neighbor
- IBGP client neighbor
- IBGP non-client neighbor
When you configure a route reflector you have to tell the router whether the other IBGP router is a client or non-client. A client is an IBGP router that the route reflector will “reflect” routes to, the non-client is just a regular IBGP neighbor.
When a route reflector forwards a route, there are a couple of rules:
- A route learned from an EBGP neighbor can be forwarded to another EBGP neighbor, a client and non-client.
- A route learned from a client can be forwarded to another EBGP neighbor, client and non-client.
- A route learned from a non-client can be forwarded to another EBGP neighbor and client, but not to a non-client.
The third rule makes sense, this is our normal IBGP split horizon behavior.
Now you have an idea what the route reflector is about, let’s take a look at some configurations.
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 22.214.171.124 mask 255.255.255.255
That’s all we have to configure. Let’s use some show commands to verify our work.
First we’ll look at R2, see if it learned anything:
R2#show ip bgp 126.96.36.199 BGP routing table entry for 188.8.131.52/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 (192.168.12.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 *>i184.108.40.206/32 192.168.12.1 0 100 0 i
So what do we see here? Let me explain…