BGP Additional Paths

Dear Rene,
If you want to send addtional-path for your neighbor:

  • First, you have to configure additional-paths send feature to send to your neighbor
  • Second, you chose which additional-paths which you want to advertise to the neighbor
    And your neighbor:
  • First, he has to configure additional-paths receive feature to receive from you
  • Second, he has to configure bgp additional-paths install to add which BGP path into his routing table
    I am right? Thanks

Hello Thejohn

Yes, that is absolutely right!

Laz

hi Rene and staff,
thanks for always replying to my posts

Just a simple question about what happens just behind configuration R1 to R6 before any consideration about additional paths
R4 and R5 learn Net6 (6.6.6.6) via eBGP (next-hop=R6) = OK
R5 has another path to Net6 via R4, but R4 has not the symetric path to Net6 via R5
This is surprising because the topology is symetric

I think the reason is:
R2 as the reflector prefers R4 to go to Net6 (that is the best choice from its perspective)
So, to go to Net6, R2 (the reflector) only advertises the path via R4 to his clients R4 and R5: R5 gets this path (so R5 install a path to Net6 via R4 in its BGP table) and R4 gets also this path from R2, but in this path the next-hop is itself => so this is done
This is why, in R4, there is not a path to Net6 via R5
I just want to know if i am right ??

I will test this in a lab, but i suppose if i shut Gi0/1on R6 (or i shut Gi0/3 on R4) BGP will reconverge via R5 (so in this case, i will find in R4 the route to Net6 via R5)
Thanks

Hello Dominique

That’s what we’re here for! :slight_smile: It’s always a pleasure.

Your explanation is correct. I suggest you try shutting down the ports you mentioned and allow BGP to reconverge. You should get the behaviour that you predicted.

I hope this has been helpful!

Laz

Hello,

When R1 and R3 are configured to receive the additional paths I can see that the “neighbor 2.2.2.2 additional-paths receive” command is under “router bgp 12345” mode. Shouldn’t the command be under “address-family ipv4” mode?

Many thanks,
Stefanita

Hello Staut

In order to keep a consistency across all routers, it would be a good idea to configure this command under the address-family ipv4 mode. However, it would still function with this configuration since IPv4 is being used for both adjacencies and prefixes.

I hope this has been helpful!

Laz

1 Like

Hi Team,

I am still a bit confused on the following…

neighbor neighbor-id additional-paths send/receive
neighbor neighbor-id advertise additional-paths

I understand I need both statements to get this working… but in my mind, i always thought “send”
is “advertise”.

Is there any method to picture or think around this?

Hello Jon

The neighbor neighbor-id additional-paths send/receive command will define if additional paths will be sent and/or recieved with that particular neighbor. In essence, you enable the feature in that particular BGP neighbor adjacency.

The neighbor neighbor-id advertise additional-paths all/best/group-best command indicates which paths will be advertised in that neighbor adjacency. All of them? The best and second best paths? Or the group best paths as defined in the lesson?

So the first command enables the feature between the specific routers, while the second command specifies what kind of paths will be shared.

I hope this has been helpful!

Laz

Hi Team,

Thank you very much for the replies.
This helps to clear up my confusion totally.

1 Like

Can be some dumb questions and sorry I have not labbed this up yet.

  1. Can we use additional path install command for paths received in bgp table from different neighbors? For example, I get 10.0.0.0/8 from Neighbor A and B, can I use this feature to have one of them as backup route?
  2. If we enable maximum-path 2 ibgp on the RR (R2) in this case, won’t it advertise both the paths from R4 and R5 to its clients avoiding all this additional configurations?
  3. It is mentioned that this feature is fro iBGP but for the group best, it is selecting paths from different ASes which is eBGP routes , so is it contradicting , Am I understanding something wrong?

I will give it a read once again, but any explanation will be helpful.

Regards,
Madhu

Hello Madhu

Yes you can. Actually, this is precisely what the feature is used for. This can be seen in the lesson, where R2 as a route reflector learned two paths to 6.6.6.6 (from R4 and R5) and advertised them both to R1. With the appropriate configuration parameters, this resulted in the installation of a backup path in R1 as can be seen in the below output:

Note here that the “additional paths” and “maximum paths” features are slightly different. You can use the maximum paths feature, but it will function a little differently. Specifically, Cisco states that:

The bgp additional-paths install command will install the type of path that is specified in the bgp additional-paths select command. If the bgp additional-paths select command specifies both keyword options (best-external and backup), the system will install a backup path.

The maximum-paths ebgp andmaximum-paths ibgp commands trigger a multipath computation, and multipaths are automatically installed as primary paths.

On the other hand, the bgp additional-paths install command triggers computation of a backup path or best-external path.

This info is retrieved from this Cisco documentation.

You are correct that the specific paths being mentioned in the groups are from other AS’es, so we’re looking at eBGP. However, a Route Reflector that is in AS4 for example, may have routes to AS1, AS2, and AS3 via eBGP. However, these routes are advertised via iBGP to other routers in AS4. All the next hop routers may be in the same AS, thus these routes would be shared using iBGP, even though they are indeed destinations outside of the AS.

I hope this has been helpful!

Laz

Hi Guys
What about the behavior of R2 for the 6.6.6…6/32 destination ? The BGP convergence on R2 will be right away because it has already installed 2 alternatives in its BGP table:?

  • next hop 4.4.4.4 as the best path installed in the RIB
  • next hop 5.5.5.5 in the bgp table but not in the RIB.

Let’s suppose that R4 is dead and only we have 5.5.5.5
R2 doesn’t need BGP additional feature to configure an install 5.5.5.5 as a backup route to improve BgP convergence?

Am I right?

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