Rene.
You’re correct. Changed the scenario and made R1 the RR. Thanks for the advice. Now about those multicast lessons… 
lol
HI Michael,
Good to hear you got it working I hope that I can start working on the multicast lessons in a few weeks…to be continued 
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 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
Hi Rene, for some reason R3 didn’t list 1.1.1.1 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.
Hi Marty,
The route reflector will not change the next hop for any prefixes learned through iBGP, not even when you use “next hop self”. It only does this for eBGP prefixes.
To make sure you can resolve next hops for internal neighbors, you should still use an IGP.
Rene
Hi Rene,
Can you please cover more about cluster list (id) when having more then one RR? What is best practice as far as cluster id when having two RR?
Thanks,
Nav
Hi Nav,
I’ll add this to my list. There are some differences when you use one or more cluster IDs when you have two or more route reflectors.
Rene
Using the “neighbor x.x.x.x next-hop-self all” command on RR will solve the iBGP next-hop problems when using RRs.
Below is the config i Labed and it just worked:
----
Leaf1#sh run | sec bgp
router bgp 1234
bgp log-neighbor-changes
network 10.1.1.0 mask 255.255.255.0
neighbor 11.11.11.2 remote-as 1234
neighbor 21.21.21.2 remote-as 1234
maximum-paths ibgp 64
Leaf2#sh run | sec bgp
router bgp 1234
bgp log-neighbor-changes
neighbor 12.12.12.2 remote-as 1234
neighbor 22.22.22.2 remote-as 1234
maximum-paths ibgp 64
Leaf3#sh run | sec bgp
router bgp 1234
bgp log-neighbor-changes
network 10.2.2.0 mask 255.255.255.0
neighbor 13.13.13.2 remote-as 1234
neighbor 23.23.23.2 remote-as 1234
maximum-paths ibgp 64 #ECMP
Spine1#sh run | sec bgp
router bgp 1234
bgp log-neighbor-changes
neighbor S1_L1_L2_L3 peer-group
neighbor S1_L1_L2_L3 remote-as 1234
neighbor S1_L1_L2_L3 route-reflector-client
neighbor S1_L1_L2_L3 next-hop-self all
neighbor 11.11.11.1 peer-group S1_L1_L2_L3
neighbor 12.12.12.1 peer-group S1_L1_L2_L3
neighbor 13.13.13.1 peer-group S1_L1_L2_L3
Spine2#sh run | sec bgp
router bgp 1234
bgp log-neighbor-changes
neighbor S2_L1_L2_L3 peer-group
neighbor S2_L1_L2_L3 remote-as 1234
neighbor S2_L1_L2_L3 route-reflector-client
neighbor S2_L1_L2_L3 next-hop-self all
neighbor 21.21.21.1 peer-group S2_L1_L2_L3
neighbor 22.22.22.1 peer-group S2_L1_L2_L3
neighbor 23.23.23.1 peer-group S2_L1_L2_L3
Leaf1 : BGP and route table:
Network Next Hop Metric LocPrf Weight Path
*> 10.1.1.0/24 0.0.0.0 0 32768 i
*mi 10.2.2.0/24 21.21.21.2 0 100 0 i
*>i 11.11.11.2 0 100 0 i
10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
B 10.2.2.0/24 [200/0] via 21.21.21.2, 00:31:39
[200/0] via 11.11.11.2, 00:31:39
1 Like
Hi Rene,
I have one doubt,please clarify.
The IBGP peering between two RR’s will be considered as non-client peering ?
Please confirm
Pradeep