This topic is to discuss the following lesson:
Hi Rene, all of your BGP Tutorials are so great please make another advanced BGP topics too, such as :
- BGP Peer-Group
- BGP Community
- BGP Local-AS
- BGP Load-Sharing
- BGP Summarization
- etc (if any)
Hi Black,
Glad to hear that you like it. I’ll add some of these tutorials, don’t worry 
Rene
Thanks Rene, I’ll be waiting for that.
Hi Rene,
I also want to thank you for BGP tutorials. Its very nicely and simply written.
Thanks Martin!
Hello,
For redundancy when we have 2 RR in the same cluster, how do we peer them ?
client-to-client or simple iBGP peers ?
Regards
1 Like
Hi Rene!
In “R3#show ip bgp 1.1.1.1” we see this output:
192.168.12.1 (inaccessible) from 192.168.23.2 (192.168.23.2)
My BGP Quagga-based router with same configuration doesn’t make recursive lookup in BGP table and just doesn’t insert the route for 1.1.1.1 in routing table. Though it is in “show ip bgp …” outputs.
Next-hop-self or route-map’s “set” options don’t work with RR.
How could i make this to work?
Hi Lionel,
Typically we use regular IBGP between the RRs.
Rene
Hi Nikita,
What exactly do you see in the BGP table? If you see something in the BGP table but not in the routing table then there is a reason why it can’t be installed. Probably because it can’t reach the next hop or something…
Rene
1 Like
Hello Rene,
Is a RR of Cluster A is seen as a non-client from the RR of Cluster B ?
Regards
>show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
I - ISIS, B - BGP, > - selected route, * - FIB route
B>* 10.1.1.0/24 [200/0] via 10.2.2.2, eth1, 00:00:11
C>* 10.2.2.0/24 is directly connected, eth1
...
>show 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
As you see we have a route to 10.16.16.0/24 in bgp table but not in routing table.
Next hop is 10.1.1.1 and is not in directly connected network. But we have also a route to that network 10.1.1.0/24 learned via BGP. But the router doesn’t make recursive lookup and just doesn’t use this route.
If i have static (or learned with ospf) route to 10.1.1.0/24 - all works great and route to 10.16.16.0/24 is insatlled in routing table.
Please explain why this happens and how can i get route to 10.16.16.0/24 vith bgp only?
Hi Nikita,
If you take a close look you can see there’s no > in front of your 10.16.16.0/24 route so there’s something wrong with it.
Try a show ip bgp 10.16.16.0 to see why it couldn’t be installed, should give you a reason.
Rene
>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
1 Like
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-selfHi 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
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