BGP Route Reflector

Hi Nikita,

It says is inaccessible, which is reachable through

What about I see it in the BGP table but it doesn’t get installed. Do a show ip bgp for this one, see why it doesn’t get installed.

Right now you only have BGP running? no other routing protocols. One of your next hops probably can’t be resolved which is why they can’t be installed in the routing table.


Rene, if you take a close look at the 3rd line of “show ip bgp” you can see there’s a “Network” column omitted.

   Network _________ Next Hop     ___ Metric LocPrf Weight Path
*>i10.1.1.0/24 _____10.2.2.2       ___      0    100      0 i
* i10.2.2.0/24 ______10.2.2.2        ___      0    100      0 i
*> __________________0.0.0.0           ___    0         32768 i
* i10.16.16.0/24 ____10.1.1.1        ___      0    100      0 i

We have here two lines for network - one learned via bgp, second one - because it’s directly connected. all topology consists of three routers, we are on R3:—R1——R2—–R3

So we definitely have the route to (it’s connected) and have also route to learned via BGP and installed in the routing table.
So that is the issue that we have all the info needed but the route to is not in the routing table.

ah my bad, didn’t see that one. So is in the routing table right?

Is there anything else in the routing table that is more specific than

Send me a mail with your configs, i’ll take a look here if you want.

Hi Lionel,

That’s correct. If you are interested, I can create some examples of multiple RRs with redundancy, show you what the configuration is like.



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 prefix but its not being installed in the routing table because it can not reach the next hop address of 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 ip bgp
BGP routing table entry for, version 0
Paths: (1 available, no best path)
  Not advertised to any peer
  Refresh Epoch 2
  Local (inaccessible) from (
      Origin IGP, metric 0, localpref 100, valid, internal
      Originator:, Cluster list:
      rx pathid: 0, tx pathid: 0


R1#sh running-config | section router bgp
router bgp 123
 bgp log-neighbor-changes
 network mask
 neighbor remote-as 123
 neighbor next-hop-self

Hi Michael,

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

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 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 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 prefix and are able to reach it.


1 Like

You’re correct. Changed the scenario and made R1 the RR. Thanks for the advice. Now about those multicast lessons… :slight_smile: lol

HI Michael,

Good to hear you got it working :slight_smile: I hope that I can start working on the multicast lessons in a few weeks…to be continued :wink:


Hi Rene,

In this example, what if we make R1 as a route reflector? How will the configuration be for R2, R3? Will R2,R3 be clients or non clients?


Hi Sameer,

That’s up to you :slight_smile: On the RR you use the neighbor route-reflector-client command to tell which routers are clients or non-clients.


Hi Rene,

Your lectures are great. Also can you prepare some lecture RR redundancy where we have two or more RR operating in the same AS

Thank you


Hi Taslim,

Sounds like a good idea, I’ve added it to the list.


Rene, i copy your diagram above and simulated it. its all the same. R2 is the RR, R1 and R3 have their loopbacks advertised. the ibgp peers are R1–R2 and R2–R3. no ibgp peers on R1–R3. The R1 sees the R3’s loopback as well as R3 sees the R1’s loopback. Its unaccessible. i tried to implement a “Next-hop-self” on R2, both on R1 and R3, but the next hop of R1 and R3 doesnt change at all. any idea how to resolve this?

Hi John,

Do you still have your configs? If so, open a topic on the forum and add them there. I’ll take a look…


yep i still have, i posted it there, under ccnp route. thank you!

Hi Rene,

Great explanation. However, I am starting to notice that you have simple topologies — which, don’t get me wrong, is absolutely great for an intro. However, it would be nice to have some more mid to advanced level topologies for certain topics. Also, I love when you have videos explaining the topics. Makes it more interactive.


Hi Mario,

Thanks for the suggestion, it depends a bit on the topic…in this case I could add some more route reflector scenarios. This week I’m adding a lot of videos, my goal is to have at least one video per lesson.


Hi Rene

First and foremost, a good write up, makes me understand better the concept.

However, i have a question. What if i have ebgp peering to my RR itself, does that qualify as a non-client ?

My topology is ebgp peering to the RR and route receive from ebgp A is not being advertise to ebgp B from the RR.



Hi Muhammad,

RR is only for iBGP clients, not for eBGP. Maybe something else is preventing your router from forwarding the prefix?


Hi Rene, for some reason R3 didn’t list as best route, hence didn’t include it in the routing table. It’s almost like it requires next-hop-self command one the RR. I believe this should not be the case b/se route reflector should be the one to hand the information to the clients without any need of additional instructions.

Please advise.