BGP Route Reflector

>show ip bgp
BGP table version is 0, local router ID is 10.5.5.5
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

   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

Total number of prefixes 3

>show ip bgp 10.16.16.0
BGP routing table entry for 10.16.16.0/24
Paths: (1 available, no best path)
  Not advertised to any peer
  Local
    10.1.1.1 (inaccessible) from 10.2.2.2 (10.20.20.2)
      Origin IGP, metric 0, localpref 100, valid, internal
      Originator: 10.20.20.2, Cluster list: 10.2.2.2
      Last update: Wed Feb 11 18:18:23 2015

The route is marked as inaccessible (same as in your example) though as we see in “show ip bgp” that there is a route to 10.1.1.0/24, where is the next hop for our route to 10.16.16.0/24.

Hi Nikita,

It says 10.1.1.1 is inaccessible, which is reachable through 10.2.2.2.

What about 10.2.2.0/24? 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

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 10.2.2.0/24 - one learned via bgp, second one - because it’s directly connected. all topology consists of three routers, we are on R3:
10.16.16.0/24—R1—10.1.1.0/24—R2—10.2.2.0/24–R3

So we definitely have the route to 10.2.2.0/24 (it’s connected) and have also route to 10.1.1.0/24 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 10.16.16.0/24 is not in the routing table.

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

Is there anything else in the routing table that is more specific than 10.1.1.0/24?

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.

Rene

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 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
  Refresh Epoch 2
  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
      rx pathid: 0, tx pathid: 0

-

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

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

Rene

1 Like

Rene.
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:

Rene

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?

Thanks,
Sameer

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.

Rene

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

BR
Taslim

Hi Taslim,

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

Rene

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…

Rene

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.

Thanks,
Mario

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.

Rene

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?

Rene