When configuring route reflectors (RRs) in iBGP, the configuration necessary to make this BGP feature work takes place primarily on the device that will play the role of the RR. As shown in the lesson, the configuration of the iBGP peers is the same as always. So if you were to have a Cisco RR, and a Juniper or Palo Alto iBGP client, the only thing you would have to configure on that client is to specify the RR as the BGP neighbor. No other configuration is required.
For more information about using multiple cluster IDs, take a look at this post:
For multiple RRs, take a look at this post:
RRs are used to share BGP routing information more efficiently than having a full mesh topology. Whether you use an RR or not should not affect the ultamate routing patterns of the data plane.
Im not sure if this has been asked already but Im having problems re-advertising route.
R2 has learnāt the route completelym fine from R2 however it cannot pass it on.
Looking at R1, I can see that it has learnt the route from BGP but it has not installed it in the routing table. Please see the below (Iāve excluded part of the show output that we donāt need):
R3#show ip bgp
Network Next Hop Metric LocPrf Weight Path
* i 1.1.1.1/32 192.168.12.1 0 100 0 1 i
R3#show 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 1
1
192.168.12.1 (inaccessible) from 192.168.23.2 (192.168.12.2)
Origin IGP, metric 0, localpref 100, valid, internal
rx pathid: 0, tx pathid: 0
Please can you advise on the above? Iāve got a different router images and tried this on a few of these but they get the same results.
Iām not completely clear on which router can see which prefixes, and what you were expecting to see. However, keep the following in mind:
iBGP does not advertise prefixes from one iBGP neighbor to another iBGP neighbor. This is called the iBGP split-horizon rule. So in a topology like the one in the lesson, if you have a peering between R1 and R2 and a peering between R2 and R3, R2 will not advertise to R3 anything it learns from R1. There are two solutions to this:
Create a full mesh of iBGP peerings within the AS. This is actually a requirement for iBGP.
Alternatively, you can make use of a route reflector, which avoids the full mesh iBGP peering requirement. This is useful for VERY large ASes.
Thus, as shown in the lesson, the prefix 1.1.1.1/32 does appear in the BGP table of R3.
Now how do you get that into the routing table of R3? Well, one of the prerequisites is to ensure that the next hop IP is in the routing table of the local router. The next-hop IP that appears in the BGP table of R3 for the 1.1.1.1/32 prefix is 192.168.12.1, which is the IP address of Fa0/0 of R1. This next-hop IP address is correct because the specific prefix was learned from R1. However, in the lesson, we havenāt configured any other routing. So R3 has no route to 192.168.12.1, therefore it does not put it in the routing table.
Remember, the purpose of this lesson is to examine how the BGP table is affected by the use of an RR. In a production network, routing between all routers within the AS must be established, typically using an IGP.
Would you be able to please explain more regarding the Originator and Cluster List ID?? Also Iāve noticed that my Originator ID is different from the one shown in the example as it used the loopback address 1.1.1.1 instead the physical address 192.168.12.1. Is this a normal occurrence or it supposed to match the IP address in the example??
According to RFC4456 which describes BGP Route Reflectors, the Originator ID is created by the route reflector itself. It will carry the BGP Identifier of the originator of the route in the local AS. In your particular case, the originator is indeed R1, and based on the method of choosing the BGP identifier or BGP router ID of R1, it should indeed be the loopback addressā¦
I will let Rene know to take a look at the lesson and see if any changes are necessary to ensure that the correct router ID is displayed.
There is no how the three (3) RRs on the topology below to exchange routes received between them to their router-reflector-clients? instead of making for example R3 a router-reflector-client of RR3 in case i want to see route from R5 and R6?
My quaetion is: I have 3 RR, each RR has 3 RR clients with diferent netwoks, all are in the same ASN. How can I make the 3 RR exchange route so that all the RR client can talk?
Thanks for the clarification! The full mesh iBGP adjacencies that we would normally have to have within an AS are no longer necessary when we use RRs. However, all the RRs within the AS must still adhere to this rule. So, by ensuring that the RRs are configured with full-mesh iBGP adjacencies, we ensure that all routes shared by the clients with their RRs will be correctly shared with other RRs within the AS.
Youāll have to give us some more information about your topology and your configurations in order for us to help. However, you can start by examining the following:
Is each RR successfully installing the BGP routes obtained from its clients within its own BGP table?
Are the RRs successfully peered with each other as BGP neighbors?
Are the RRs successfully exchanging their own routes with each other?
Does one RR have the routes of the clients of the other RRs in their BGP table?
In other words, try to find out where in the route exchange the update is failing. Let us know some more information, as well as any additional info from your troubleshooting and weāll be happy to help you further.
When implementing MPLS L3VPNs, there are cases where you may have some remote customer sites in locations where the same service provider cannot serve both sites. The result is that the backbone network that interconnects the sites, has more than one AS, thus some sort of mechanism must be established to allow inter-AS communication to take place without disrupting the VPN.
There are three ways to do this, and they are called Options A, B and C:
Option A: Back-to-Back VRFs
Option B: MP-eBGP for VPNv4
Option C: Multihop MP-eBGP between RR + Labels
Because these topics are outside of the scope of current Cisco certifications at all levels, so a lesson on these is not found on the site. However, Cisco has some good content that may help you out. Iām adding a few links below:
The āinaccessibleā indicates that the next hop IP, which for that specific prefix is 192.168.12.1 on R1, is not reachable from R3.
Typically, within an AS, you must ensure that you have routing configured between all iBGP routers. In order to do so, you must employ either an IGP like OSPF or EIGRP or static routing.
For the purposes of this lab, however, this was not necessary. We are only examining how BGP advertises networks using an RR. If you configure routing such that all routers can reach each other within the AS then that āinaccessibleā indicator will disappear.
It is interesting here, however, that because we are using an RR, R3 is still able to learn about the routes advertised by R1, even though we donāt have routing within the AS configured. This is one of the advantages of the RR, which relays routes learned via iBGP to other iBGP routers.
Remember, however, that in a production network, even when you use RRs, it is necessary to ensure that routing is configured between all routers within the AS. Otherwise, you will have āinaccessibilityā problems as you have correctly stated.
instead of making for example R3 a router-reflector-client of RR3 in case i want to see route from R5 and R6?