BGP Additional Paths

Hello Rodrigo

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.

I hope this has been helpful!

Laz

1 Like

Interesting. thanks!!!

1 Like


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?

R5#show run | sec bgp
router bgp 5
 bgp router-id 5.5.5.5
 bgp log-neighbor-changes
 neighbor 2.2.2.2 remote-as 5
 neighbor 2.2.2.2 update-source Loopback0
 neighbor 192.168.56.2 remote-as 6
 !
 address-family ipv4
  neighbor 2.2.2.2 activate
  neighbor 2.2.2.2 next-hop-self
  neighbor 2.2.2.2 additional-paths receive
  neighbor 192.168.56.2 activate
  neighbor 192.168.56.2 route-map PRIMARY_LINK in
 exit-address-family
R5#show rou
R5#show route-m
R5#show route-map
route-map PRIMARY_LINK, permit, sequence 10
  Match clauses:
  Set clauses:
    local-preference 110
  Policy routing matches: 0 packets, 0 bytes
R5#

Reagrds
Unni

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)?

Hello Unni

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.

I hope this has been helpful!

Laz

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?

1 Like

Hello Unni

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.

I hope this has been helpful!

Laz

Hi,

Are there any lessons about address-family usage?, I’m not confident with this topic.

Thanks

Hello Giovanni

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 :stuck_out_tongue:).

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!

I hope this has been helpful!

Laz

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 ?

Hello Kien

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.

I hope this has been helpful!

Laz

Having the configs at the end of the lesson would definitely help.

For MED oscillation, I found this article easier to read than the RFC (it’s based on the RFC, but in a more digestible form): https://rule11.tech/bgp-persistent-oscillation/

For “group-best” it’s similar to “bgp deterministic-med” but for add paths :slight_smile:

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.

Hello Chris

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.

Laz

Hi Guys,

Just to quote:

"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?

Hello Joseph

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.

I hope this has been helpful!

Laz

1 Like

Excellent, 100% thanks man

1 Like

Hello Rene,

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.

Thanks

Hello Arivudainambi

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.

I hope this has been helpful!

Laz