BGP Route Reflector

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. Let me show you an example picture:

IBGP 6 routers full mesh

Above we have a network with 6 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:

IBGP Route Reflector Example

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:

IBGP Route Reflector Route Update

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:

  1. A route learned from an EBGP neighbor can be forwarded to another EBGP neighbor, a client and non-client.
  2. A route learned from a client can be forwarded to another EBGP neighbor, client and non-client.
  3. 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.

Configuration

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

AS 123 IBGP 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, 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

So what do we see here? Let me explain…

We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You've Ever Spent on Your Cisco Career!
  • Full Access to our 657 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

541 Sign Ups in the last 30 days

satisfaction-guaranteed
100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Tags:


Forum Replies

  1. Rene,

    If this has been answered by other members I apologize but following your example, the RR works as configured as R3 does learn about the 1.1.1.1/32 prefix but its not being installed in the routing table because it can not reach the next hop address of 192.168.12.1. To resolve this I added the next-hop-self command on R1 and reset the BGP peerings. That still did not resolve this.

    My question is once a RR is configured should all the clients update their next hop to the RR or should the originator of the prefix have the next-hop-self configuration?

    R3#sh 
    ... Continue reading in our forum

  2. Hi Michael,

    In this example R1 originates the prefix so the next hop is 192.168.12.1.

    R2 will reflect this prefix to R3 but it doesn’t change the next hop. Using next-hop self on R1 won’t help here since 192.168.12.1 is already the next hop IP address.

    The route reflector will reduce the number of iBGP peerings but that’s it :slight_smile:

    About your question, let’s imagine that R1 learns 1.1.1.1/32 from an eBGP router. In this case, it would be better to make R1 the RR and use “next hop self” for all other iBGP routers. That would ensure that all iBGP neighbors learn the pr

    ... Continue reading in our forum

  3. Udaya,
    In the case of a router’s being a route reflector client of multiple route reflectors, the client will accept routes from all reflectors. In other words, all learned routes will be present in the BGP topology table. As far as which routes are selected as best routes, and installed in the routing table, the client will use the standard (and complex!) BGP best path selection algorithm.

  4. I need a bit of help, I can’t seem to get this working on Real Equip or GNS3

    I have the following setup; http://imgur.com/a/ZLqCl

    But R1 still cannot ping the 192.168.0.1 address assigned on loopback 0 on R3. I’ve got some outputs below, let me know if you need more :slight_smile: Hope someone can help me figure what i’ve done wrong

    R1 - http://paste.ubuntu.com/23460781/ http://paste.ubuntu.com/23460783/
    R2 - http://paste.ubuntu.com/23460788/ http://paste.ubuntu.com/23460789/
    R3 - http://paste.ubuntu.com/23460791/ http://paste.ubuntu.com/23460793/

    What I can see is R1 is sho

    ... Continue reading in our forum

  5. Hey Ryan,
    The issue you are having is that while R1 knows about the BGP route to R3, it is not installing it into the routing table. You can verify this by going on to R1 and issuing a “show ip bgp” and look for the 192.168.0.0 route (it will be missing the “>” symbol).

    The reason R1 is not installing the route is due to BGP behaving differently than other routing protocols. BGP really isn’t a true routing protocol in the way that OSPF or EIGRP are. BGP is more of an application that tells you WHERE to go to get to a network, but it does not tell HOW to get

    ... Continue reading in our forum

65 more replies! Ask a question or join the discussion by visiting our Community Forum