As far as R2 is concerned, it has both paths in its routing table, but advertises only one of them. However, R2 will not immediately converge if R4 goes down. The neighbor adjacency will have to be torn down which requires timers to expire before the specific next hop is considered dead. Once that happens, then BGP will reconverge placing 5.5.5.5 as the next hop for that particular route.
If the additional paths feature is not enabled, BGP must reconverge in order for R2 to realize that it must route packets via R5, which will not be immediate, but will take some time.
Hello Rene/Team,
Here the above i tried to configure the bgp additional path on RR(R2) to reflect the same towards clients . But when i was configured the LP on R5 to make it as primary link for inside traffic ,the prefix (6.6.6.6) via 5.5.5.5 is only showing in bgp table of RR(R2).Even though the local prefernce has configured 110 for R5(5.5.5.5) the other path should be there in R2 right?
Rene the question is LP will share within the AS right still the other route needs to show in bgp table of RR right ? Later u will reflect the best path only to client neighbors is agreed but still my question is why that 6.6.6.6/32 vai 4.4.4.4 (R4) is not in bgp table of R2(RR)?
Without the Local Preference configuration on R5, you have R5 advertising its route to 6.6.6.6 via R6 directly, and R4 advertising its route to 6.6.6.6 via R6 directly. In this case, you also have R2 configured to receive and include additional paths. So when it receives the info from both R5 and R4, it places both in the BGP table.
When you created the local preference configuration on R5, both R4 and R5 have a BGP best path to 6.6.6.6 via R5.
So R5 tells R2 to reach 6.6.6.6 via itself, and R4 tells R2 to reach 6.6.6.6 via R5. So R2 receives only the path via R5 as a route to 6.6.6.6. It never receives the alternative in order to consider it and place it as an additional path.
Even though R4 has both paths to 6.6.6.6 in its BGP table, its best path (and thus the one it advertises) is still via 5.5.5.5. R4 is not configured to send additional paths. In such a case R2 never receives the additional path in any advertisement, so it is not added.
But still would like to point out here whatever routing information received from EBGP peer (R6) in our case will be send across towards Route reflector via client right? So R4 and R5 are clients with respect to RR (R2) right? So in that sense the 6.6.6.6/32 via R5 (LP has configured) and 6.6.6.6/32 via R4 should supposed to be there in bgp table of R2 right? And still confusing the concept, how LP value will share across the local AS 5 domain based on this topologyâŚBut still that should be there in BGP table then it will reflect to other clients which includes R4 also right?
Iâve gone in and labbed this one up again to get a clearer picture of what is going on. Now having all the additional paths configured as in the lab, but without the application of Local Pref, we find the following:
There is a single entry in the BGP table in R4 for a destination of 6.6.6.6 as seen below:
R4#show ip bgp
Network Next Hop Metric LocPrf Weight Path
*> 6.6.6.6/32 192.168.46.6 0 0 6 i
R5 however has two paths, one via eBGP and one via iBGP. You can see that it is the one via eBGP (the directly connected one) that is considered best:
R5#show ip bgp
Network Next Hop Metric LocPrf Weight Path
* i 6.6.6.6/32 4.4.4.4 0 100 0 6 i
*> 192.168.56.6 0 0 6 i
Now from this information, R2, the route reflector, has two paths to 6.6.6.6, the best one via R4 and the additional path via R5.
R2#show ip bgp
Network Next Hop Metric LocPrf Weight Path
* ia 6.6.6.6/32 5.5.5.5 0 100 0 6 i
*>i 4.4.4.4 0 100 0 6 i
These two are learned from the best path in R4 and the best path in R5. Now if you apply LP as you state in your post, then the result is that the best path in R5 will be via R6 directly, and the best path in R4 will be via R5 as shown:
R4#show ip bgp
Network Next Hop Metric LocPrf Weight Path
*>i 6.6.6.6/32 5.5.5.5 0 400 0 6 i
* 192.168.46.6 0 0 6 i
and
R5#show ip bgp
Network Next Hop Metric LocPrf Weight Path
*> 6.6.6.6/32 192.168.56.6 0 0 6 i
Remember that both R4 and R5 share only the best path with the route reflector. R4 advertises that the best path is via R5, and R5 advertises that it is the best path. So there is only one path that is being advertised to 6.6.6.6 by both routers. Therefore, R2 will only receive that one single path, and it will never learn of the path via R4â>R6, since that is never advertised:
R2#show ip bgp
Network Next Hop Metric LocPrf Weight Path
*>i 6.6.6.6/32 5.5.5.5 0 400 0 6 i
Notice in the BGP table that the local pref has a value of 400. This is the value that I configured to differentiate the path via R5 rather than R4. R5 is sending this value along with its iBGP updates to the route reflector. But remember, because R4 and R5 are not configured to share additional paths, it is only their best path (the one configured with the higher LP) that is being advertised. In this topology, only R2 is configured to share additional paths, if it itself is informed of these paths. In this case, it is not, so it has no additional path to include in its table.
Address families are used in various aspects of Cisco device configuration. There is no one lesson that describes them, as they are applied in a wide range of areas. However, we may include a lesson in the near future that addresses this topic (pun intended ).
In the meantime, take a look at this post that may answer most of your questions.
If you require further clarification, please feel free to ask!
Hi team!
I wanna ask something :
So when the R2-RR advertise two path to R3. Seem R3 automatic change the next hop to 5.5.5.5
This thing is make me confusing, so could you explain why R3 is automatic change the next hop to R5 while any attribute of R4 and R5 is the same but R4 has route-id lower than R5 ?
This is an excellent question. If we simply look at the BGP attributes and path selection criteria, and go through them one at a time, you will see that R3 chooses 5.5.5.5 as the next hop based on the âShortest IGP path to BGP next hopâ attribute. According to the following lesson, this is attribute number 8.
This comes before router ID as an attribute, so you can see here that R3 chooses the next hop BGP peer which is closest based on the metric of the IGP, which in this case is OSPF. R5 is closer than R4 as per the OSPF metric, and this is why it is chosen.
For âgroup-bestâ itâs similar to âbgp deterministic-medâ but for add paths
Instead of âbgp addtionial-path installâ which puts the secondary path as a backup, you couldâve used âmaximum-path ibgp 2â which would make both routes active/active. Itâs worth clarifying this in the lesson IMO.
Rene is working on this to have the initial configs at the beginning of each lesson, and the final configs at the end. Many of the newer lessons already have this, but some of the older ones need to be updated.
Also, thanks for sharing the link, it will be useful to some readers.
Thanks for your feedback, it is always invaluable to maintain the quality of the content.
"For the additional path selection, there are three options:
Best N: this is the best path and the second best path(s). The second best path(s) is chosen by eliminating the (next) best path and then selecting the next best path."
So is this supposed to mean it picks the 3rd Best Path?
The Best N option actually has two sub-options: Best 2 or Best 3. Cisco documentation puts it this way:
best 2 or best 3 (best 2 means the bestpath and 2nd best path; the 2nd best path is the one computed by eliminating best-path from the best-computation algorithm. Similarly, best 3 means the bestpath, 2nd best path, and 3rd best path; the 3rd best path is the one computed by eliminating bestpath and 2nd best path from the best-computation algorithm.)
In other words, the first best path is identified and stored. Letâs call it Path A. The second best path is determined by first removing Path A from the calculation, and reevaluating the best path.
The result is the second-best path, which we will call Path B. If best 3 is is bein used, then this process is repeated by first removing Path A and Path B from the process, and calculating the best path from whatever remains, to get the third best path.
So to answer your original question, the best N policy where N=2 will determine the two best paths while if N=3, it will determine the three best paths.
In your topology, if we need to install a backup path on R4 for 6.6.6.6/32 what is the correct way?
In this case, one route is received from EBGP and one from the RR.
In the scenario that you are describing, R4 will have information about the 6.6.6.6/32 prefix from eBGP, via R6, and from iBGP via R2. In such a case, by default, the eBGP route is considered to be the preferred route. But the comparison here has nothing to do with the BGP attributes, but with the Administrative Distance. Varying routing protocols have different administrative distances, such as:
0 connected interface
1 static route
20 eBGP
90 EIGRP
110 OSPF
200 iBGP
As you can see, iBGP has a much larger AD than eBGP, so by default, eBGP routes will be installed in the routing table over iBGP. So there is no BGP-specific âbackupâ mechanism that you can apply in such a case, such as additional paths, or multipath.
If you want to manipulate the routing in this case, you will have to adjust the AD. In general, this is not a good idea to do, especially in a topology like this one. It can result in an unstable topology. However, there is one particular case where this is applied by design, and that has to do with BGP backdoor routes, where this configuration changes the AD of the eBGP learned routes for a very specific purpose.
Take a look at this post as well which further describes the reasoning behind it:
Keep in mind that this should only be applied in very specific circumstances in order to achieve something specific. In general, eBGP should always win out over iBGP learned routes.
In the topology mentioned in BGP additional paths section, R4 and R5 routers has IBGP peering.
R4 has eBGP peering to R6 and
R5 has eBGP peering to R6.
R4 and R5 has eBGP best path to R6 loopback 6.6.6.6 in the BGP table.
R5 has additional iBGP route(not best) to 6.6.6.6. But R4 has not had iBGP route. Why? Is this due to iBGP split Horizon rule.
R4#show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 6.6.6.6/32 192.168.46.6 0 0 6 i
R5#show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
> 6.6.6.6/32 192.168.56.6 0 0 6 i
i 4.4.4.4 0 100 0 6 i
My understanding on iBGP split horizon rule is the route learned from iBGP peer do not advertise to the another iBGP neighbor .
Dear @ReneMolenaar - Did you get a chance to check this.
The difference you see is due to the way in which BGP determines the best path. In this particular scenario, we have a route reflector which is R2. You can see in the BGP table of R2 that there are two paths to R6 learned using iBGP, one via R4 and one via R5. It chooses the one via R4 as the best path. Why? Based on the BGP attributes, it is the router ID that is the tie breaker. The path with the lowest BGP neighbor router ID is chosen, which is 4.4.4.4 on R4.
So R2 as a route reflector, will advertise to all other iBGP routers in the AS, only the path via 4.4.4.4 to reach 6.6.6.6. You can see that the BGP tables of both R1 and R3 only have this next hop for the 6.6.6.6 destination. The route via R5 is not advertised.
Now R4 will not learn of this path from the RR, since R4 itself initially advertised this path. But R4 will have this entry in the BGP table simply because it is an eBGP peer with R6 from which it learned the route. R4 will not have the path via R5 simply because the route reflector R2 did not advertise this path. (For more info on route reflectors, take a look at this lesson.)
Now R5 will have learned of the path to 6.6.6.6 via R4 from the route reflector R2, just like all other iBGP routers in the AS, and will thus have the iBGP-learned path in its BGP table. However, it also has learned of a path to 6.6.6.6 via its eBGP peering. And that is why we see both paths in the BGP table in R5.
).