1. Route Reflector
Created By Ahmed Raafat

2. What is Route Reflector (RR)?
 Route reflectors (RR) are one method to get rid of 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.

3.  Above we have a network with 6 IBGP routers. Using the full mesh formula we
can calculate the number of IBGP peering: N(N-1)/2
 So that will be: 6(6-1)/2= 15 IBGP peering.

4.  When we use a route reflector our network could look like this:

5.  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 peering. Of
course there’s a solution to this,
we can have multiple route
reflectors in our network.

6.  The route reflector can have three types of peering:
 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.

7. Configuration

8.  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

9.  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

10.  Here’s the magic.. When we configure the route reflector we have to specify
its clients. In this case, R1 and R3. In the 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

11. Verification

12.  First we’ll look at R2, 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 (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
i1.1.1.1/32 192.168.12.1 0 100 0 i