2

I have an iBGP session between a Juniper router and a Cisco IOS XR router with add-path/additional-path both in send and receive direction enabled. According to show bgp neighbor, the feature is operating properly in both routers. In the IOS XR router there is a 10.2.34.0/24 prefix with next-hop to 172.16.0.33 and 172.16.0.44:

RP/0/RP0/CPU0:RR2#sh bgp ipv4 unicast 10.2.34.0/24 brief
Wed Apr 21 10:55:09.050 UTC

Status codes: s suppressed, d damped, h history, * valid, > best
              i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network            Next Hop            Metric LocPrf Weight Path
* i10.2.34.0/24       172.16.0.33            200    100      0 65002 i
*>i                   172.16.0.44            100    100      0 65002 i
* i                   172.16.0.33            200    100      0 65002 i
* i                   172.16.0.44            100    100      0 65002 i
RP/0/RP0/CPU0:RR2#

However, for some reason, only the best path is advertised to Juniper router:

RP/0/RP0/CPU0:RR2#sh bgp neighbor 172.16.0.11 advertised-routes
Wed Apr 21 10:56:45.760 UTC
Network            Next Hop        From            AS Path
10.1.12.0/24       172.16.0.202    172.16.0.11     65001i
10.2.34.0/24       172.16.0.44     172.16.0.44     65002i
192.168.10.1/32    172.16.0.202    172.16.0.11     65001i
192.168.10.2/32    172.16.0.22     172.16.0.22     65001i
192.168.20.3/32    172.16.0.33     172.16.0.33     65002i
192.168.20.4/32    172.16.0.44     172.16.0.44     65002i

Processed 6 prefixes, 6 paths
RP/0/RP0/CPU0:RR2#

I would expect the IOS XR router to advertise two copies of 10.2.34.0/24 prefix with different path IDs and different next-hop addresses(172.16.0.33 and 172.16.0.44). Detailed information for 10.2.34.0/24 prefix in IOS XR router can be seen below:

  Path #1: Received by speaker 0
  Not advertised to any peer
  65002, (Received from a RR-client)
    172.16.0.33 (metric 20) from 172.16.0.33 (172.16.0.33)
      Origin IGP, metric 200, localpref 100, valid, internal
      Received Path ID 1, Local Path ID 0, version 0
  Path #2: Received by speaker 0
  Advertised IPv4 Unicast paths to update-groups (with more than one peer):
    0.2 0.3
  Advertised IPv4 Unicast paths to peers (in unique update groups):
    172.16.0.201
  65002, (Received from a RR-client)
    172.16.0.44 (metric 20) from 172.16.0.44 (172.16.0.44)
      Origin IGP, metric 100, localpref 100, valid, internal, best, group-best
      Received Path ID 1, Local Path ID 1, version 17

BGP configuration of the IOS XR router can be seen below:

RP/0/RP0/CPU0:RR2#sh run router bgp
Thu Apr 22 08:17:17.814 UTC
router bgp 65000
 address-family ipv4 unicast
  additional-paths receive
  additional-paths send
 !
 neighbor-group iBGP-RR1
  remote-as 65000
  update-source Loopback0
  address-family ipv4 unicast
  !
 !
 neighbor-group iBGP-CLIENTS
  remote-as 65000
  cluster-id 172.16.0.202
  update-source Loopback0
  address-family ipv4 unicast
   route-reflector-client
  !
 !
 neighbor 172.16.0.11
  use neighbor-group iBGP-CLIENTS
 !
 neighbor 172.16.0.22
  use neighbor-group iBGP-CLIENTS
 !
 neighbor 172.16.0.33
  use neighbor-group iBGP-CLIENTS
 !
 neighbor 172.16.0.44
  use neighbor-group iBGP-CLIENTS
 !
 neighbor 172.16.0.201
  use neighbor-group iBGP-RR1
 !
!

RP/0/RP0/CPU0:RR2#

Is there a reason why IOS XR router does not advertise two copies of 10.2.34.0/24 route?

4
  • 1
    The behavior seems correct, and BGP should only advertise the best path (what is in the routing table), even though the BGP table has multiple routes. BGP only advertises prefixes that exist in the routing table. – Ron Maupin Apr 21 at 12:28
  • 2
    Please include the BGP configuration in your question. We can't simply guess what might be wrong. – Ron Trunk Apr 21 at 14:57
  • @RonMaupin At least the way I understand the additional-path feature is that the IOS XR router should advertise at least two copies of the 10.2.34.0/24 prefix with different next hop values(172.16.0.33 & 172.16.0.44) and path IDs. @RonTrunk I added the BGP configuration. – Martin Apr 22 at 9:31
  • It's not that simple as just adding that. There are steps to follow to get that to work, and it only works establishment. – Ron Maupin Apr 22 at 12:23
1

To send or receive additional paths, you must follow the steps Cisco has established, and both sides agree to it:

The BGP Additional Paths feature requires the user to take three general steps:

  1. Specify whether the device can send, receive, or send and receive additional paths. This is done at the address family level or the neighbor level, and is controlled by either the bgp additional-paths {send [receive] | receive} command or the neighbor additional-paths {send [receive] | receive} command, respectively. During session establishment, two BGP neighbors negotiate the Additional Path capabilities (whether they can send and/or receive) between them.

  2. Select a set or sets of candidate paths for advertisement by specifying selection criteria (using the bgp additional-paths select command).

  3. Advertise for a neighbor a set or sets of additional paths from the candidate paths marked (using the neighbor advertise additional-paths command).

To send or receive additional paths, the Additional Path capability must be negotiated. If it isn't negotiated, even if the selection criteria are such that more than the bestpath is marked and the neighbor is configured to advertise the marked paths, the selections would be useless because without the capability negotiated, only the bestpath can be sent.

Configuring BGP to send or receive additional paths triggers negotiation of additional path capability with the device's peers. Neighbors that have negotiated the capability will be grouped together in an update group (if other update group policies allow), and in a separate update group from those peers that have not negotiated the capability. Therefore, additional path capability causes the neighbor's update group membership to be recalculated.

If you do not follow all the steps, and the neighbors do not agree, the you cannot advertise additional paths to the same prefix.

1
  • Yes, configuring a route-policy with set path-selection backup 1 advertise and applying this route-policy with additional-paths selection route-policy <route_policy_name> under the BGP configuration did the trick. – Martin Apr 23 at 10:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.