Cisco IOS XR not sending multiple copies of a prefix despite that the additional-path feature is enabled

Question

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?

Answer 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.