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)
Glad to hear that you like it. I’ll add some of these tutorials, don’t worry
Thanks Rene, I’ll be waiting for that.
I also want to thank you for BGP tutorials. Its very nicely and simply written.
For redundancy when we have 2 RR in the same cluster, how do we peer them ?
client-to-client or simple iBGP peers ?
In “R3#show ip bgp 188.8.131.52” 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 184.108.40.206 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?
Typically we use regular IBGP between the RRs.
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…
Is a RR of Cluster A is seen as a non-client from the RR of Cluster B ?
>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?
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.
>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.
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, 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:
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.
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 220.127.116.11/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 18.104.22.168 BGP routing table entry for 22.214.171.124/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: 126.96.36.199, 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 188.8.131.52 mask 255.255.255.255 neighbor 192.168.12.2 remote-as 123 neighbor 192.168.12.2 next-hop-self
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 184.108.40.206/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.