You’re correct. Changed the scenario and made R1 the RR. Thanks for the advice. Now about those multicast lessons… lol
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
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?
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.
Your lectures are great. Also can you prepare some lecture RR redundancy where we have two or more RR operating in the same AS
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?
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!
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 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.
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.
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 18.104.22.168 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.
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.
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?
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.
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 22.214.171.124 remote-as 1234 neighbor 126.96.36.199 remote-as 1234 maximum-paths ibgp 64
Leaf2#sh run | sec bgp router bgp 1234 bgp log-neighbor-changes neighbor 188.8.131.52 remote-as 1234 neighbor 184.108.40.206 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 220.127.116.11 remote-as 1234 neighbor 18.104.22.168 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 22.214.171.124 peer-group S1_L1_L2_L3 neighbor 126.96.36.199 peer-group S1_L1_L2_L3 neighbor 188.8.131.52 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 184.108.40.206 peer-group S2_L1_L2_L3 neighbor 220.127.116.11 peer-group S2_L1_L2_L3 neighbor 18.104.22.168 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 22.214.171.124 0 100 0 i *>i 126.96.36.199 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 188.8.131.52, 00:31:39 [200/0] via 184.108.40.206, 00:31:39
19 posts were merged into an existing topic: BGP Route Reflector
I have one doubt,please clarify.
The IBGP peering between two RR’s will be considered as non-client peering ?