bgpd: fix do not skip paths with same nexthop

bgpd: fix do not skip paths with same nexthop

Under a setup where two BGP prefixes are available from multiple sources,
if one of the two prefixes is recursive over the other BGP prefix, then
it will not be considered as multipath. The below output shows the two
prefixes 192.0.2.24/32 and 192.0.2.21/32. The 192.0.2.[5,6,8] are the
known IP addresses visible from the IGP.

> # show bgp ipv4 192.0.2.24/32
> *>i 192.0.2.24/32    192.0.2.21               0    100      0 i
> * i                  192.0.2.21               0    100      0 i
> * i                  192.0.2.21               0    100      0 i
> # show bgp ipv4 192.0.2.21/32
>  *>i 192.0.2.21/32    192.0.2.5                0    100      0 i
>  *=i                  192.0.2.6                0    100      0 i
>  *=i                  192.0.2.8                0    100      0 i

The bgp best selection algorithm refuses to consider the paths to
'192.0.2.24/32' as multipath, whereas the BGP paths which use the
BGP peer as nexthop are considered multipath.

> ... has the same nexthop as the bestpath, skip it ...

Previously, this condition has been added to prevent ZEBRA from
installing routes with same nexthop:

>     Here you can see the two paths with nexthop 210.2.2.2
>     superm-redxp-05# show ip route 2.23.24.192/28
>     Routing entry for 2.23.24.192/28
>       Known via "bgp", distance 20, metric 0, best
>       Last update 00:32:12 ago
>       * 210.2.2.2, via swp3
>       * 210.2.0.2, via swp1
>       * 210.2.1.2, via swp2
>       * 210.2.2.2, via swp3
> [..]

But today, ZEBRA knows how to handle it. When receiving incoming routes,
nexthop groups are used. At creation, duplicated nexthops are
identified, and will not be installed. The below output illustrate the
duplicate paths to 172.16.0.200 received by an other peer.

> r1# show ip route 172.18.1.100 nexthop-group
> Routing entry for 172.18.1.100/32
>   Known via "bgp", distance 200, metric 0, best
>   Last update 00:03:03 ago
>   Nexthop Group ID: 75757580
>     172.16.0.200 (recursive), weight 1
>   *   172.31.0.3, via r1-eth1, label 16055, weight 1
>   *   172.31.2.4, via r1-eth2, label 16055, weight 1
>   *   172.31.0.3, via r1-eth1, label 16006, weight 1
>   *   172.31.2.4, via r1-eth2, label 16006, weight 1
>   *   172.31.8.7, via r1-eth4, label 16008, weight 1
>     172.16.0.200 (duplicate nexthop removed) (recursive), weight 1
>       172.31.0.3, via r1-eth1 (duplicate nexthop removed), label 16055, weight 1
>       172.31.2.4, via r1-eth2 (duplicate nexthop removed), label 16055, weight 1
>       172.31.0.3, via r1-eth1 (duplicate nexthop removed), label 16006, weight 1
>       172.31.2.4, via r1-eth2 (duplicate nexthop removed), label 16006, weight 1
>       172.31.8.7, via r1-eth4 (duplicate nexthop removed), label 16008, weight 1

Fix this by proposing to let ZEBRA handle this duplicate decision.

Fixes: 7dc9d4e4e360 ("bgp may add multiple path entries with the same nexthop")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>