This article explains what causes odd number of BGP add-path routes on cRPD

cRPD learns three copies of 110.1.1.1/32 route from each of the 3 upstream routers. All attributes are the same, except Tunnel end points and PNHs (9 copies of the route in total). Expectation is that cRPD will then advertise all copies to downstream router. However cRPD advertises 7 copies to downstream router. 4 out of 7 copies have absolutely identical attributes, i.e. only 3 out of 7 routes actually have something unique (PNH, TEP). We expect to see either 3 to be advertised instead of odd number.

cRPD receives 9 copies of the same route from 3 upstream routers:

[edit]
root@crpd1# run show route 110.1.1.1                                               
inet.0: 23 destinations, 43 routes (23 active, 6 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
 
110.1.1.1/32       *[BGP/170] 00:07:47, localpref 100, from 100.2.2.2
                      AS path: 65002 65022 I, validation-state: unverified
                    >  to 60.1.1.2 via ens33
                    >  to 60.1.1.2 via ens33
                    >  to 60.1.1.2 via ens33
                    [BGP/170] 00:07:47, localpref 100, from 100.2.2.2
                      AS path: 65002 65022 I, validation-state: unverified
                    >  to 60.1.1.2 via ens33
                    [BGP/170] 00:07:47, localpref 100, from 100.2.2.2
                      AS path: 65002 65022 I, validation-state: unverified
                    >  to 60.1.1.2 via ens33
                    [BGP/170] 00:07:48, localpref 100, from 100.3.3.3
                      AS path: 65003 65033 I, validation-state: unverified
                    >  to 60.1.1.2 via ens33
                    [BGP/170] 00:07:49, localpref 100, from 100.3.3.3
                      AS path: 65003 65033 I, validation-state: unverified
                    >  to 60.1.1.2 via ens33
                    [BGP/170] 00:07:48, localpref 100, from 100.3.3.3
                      AS path: 65003 65033 I, validation-state: unverified
                    >  to 60.1.1.2 via ens33
                    [BGP/170] 00:07:45, localpref 100, from 100.4.4.4
                      AS path: 65004 65044 I, validation-state: unverified
                    >  to 60.1.1.2 via ens33
                    [BGP/170] 00:07:45, localpref 100, from 100.4.4.4
                      AS path: 65004 65044 I, validation-state: unverified
                    >  to 60.1.1.2 via ens33
                    [BGP/170] 00:07:46, localpref 100, from 100.4.4.4
                      AS path: 65004 65044 I, validation-state: unverified
                    >  to 60.1.1.2 via ens33
  

However, cRPD advertises odd number of routes to downstream node:

[edit]
root@crpd1# run show route advertising-protocol bgp 90.1.1.2 110.1.1.1   
 
inet.0: 23 destinations, 43 routes (23 active, 6 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
  110.1.1.1/32            XX.XX.102.62                100        65003 65033 I
*                         XX.XX.102.60                100        65002 65022 I
                          XX.XX.102.61                100        65002 65022 I
                          XX.XX.102.61                100        65004 65044 I

This is cause by symptoms of known software bug, tracking via PR1747724, in which the IPIP tunnel-attribute is stored in such a way that the 'route' nexthops ends up being unique and causes the selection of duplicate paths to be advertised through BGP Add-Path.