FRRouting release 7.3.1

Maintenance/bugfix release.

Signed-off-by: David Lamparter <equinox@opensourcerouting.org>

Merge pull request #6353 from ton31337/fix/communities_bgpd_crash_7.3

bgpd: Check to ensure community attributes exist before freeing them

Community attributes might have been removed by an inbound route map, so we
should check to ensure they still exist before trying to free them.
This fixes a segfault described in issue #6345.

Signed-off-by: Josh Cox <josh.cox@pureport.com>

Merge pull request #6338 from ton31337/fix/FALSE_TRUE_7.3

bgpd: [7.3] bools use `true/false` not `TRUE/FALSE`

bgpd: bools use `true/false` not `TRUE/FALSE`

Who knows where these values were coming from.

Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>

Merge pull request #6336 from sworleys/No-NHG-Install-With-VRFns_7.3

[7.3] zebra: force off kernel NHG install with netns VRFs

zebra: force off kernel NHG install with netns VRFs

Force off kernel NHG install with netns-based VRFs for
now. There is not really a good solution for allowing
kernel nexthop groups in namespaced based vrfs.

Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
(cherry picked from commit d982012a0e7e77814b25381f634b64034d80c1ad)

Merge pull request #6315 from ton31337/fix/access-list_deletion_7.3

lib: [7.3] Delete the entire access-list only if there are no more entries

lib: Delete the entire access-list only if there are no more entries

When you enter the access-list with the same sequence number but with a
different prefix AND access-list has only a single entry, then the entry
is deleted and the whole access-list is deleted.

That means that "replace entry" never be re-inserted.

With fix:
```
~# vtysh -c 'c' -c 'access-list 1 seq 10 permit 127.0.0.10/32'
~# vtysh -c 'sh run' | grep access-list
access-list 1 seq 10 permit 127.0.0.10/32
~# vtysh -c 'c' -c 'access-list 1 seq 10 permit 127.0.0.20/32'
~# vtysh -c 'sh run' | grep access-list
access-list 1 seq 10 permit 127.0.0.20/32
~# vtysh -c 'c' -c 'access-list 1 seq 11 permit 127.0.0.11/32'
~# vtysh -c 'sh run' | grep access-list
access-list 1 seq 10 permit 127.0.0.20/32
access-list 1 seq 11 permit 127.0.0.11/32
~# vtysh -c 'c' -c 'no access-list 1 seq 10 permit 127.0.0.20/32'
~# vtysh -c 'sh run' | grep access-list
access-list 1 seq 11 permit 127.0.0.11/32
~#
```

Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>

lib: Convert access_list_empty to bool

Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>

Merge pull request #6312 from donaldsharp/revert_73

[7.3]Revert "vtysh: fix searching commands in parent nodes"

Revert "vtysh: fix searching commands in parent nodes"

This reverts commit d741915ecdcf8930ccb3bd23eec1da2f0d000483.

This is because it breaks this behavior:

router ospf6
  <commands>
!
int enp39s0
  <more commands>
!

This is a very legal set of commands and completely destroys the
ability to do this.

Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>

Merge pull request #6288 from ton31337/fix/allow_nhlen_32_with_empty_global_7.3

bgpd: [7.3] Do not discard an UPDATE if the global nexthop is set to ::

Merge pull request #6287 from ton31337/fix/show_bgp_hostname_7.3

bgpd: [7.3] Show hostname in `show [ip] bgp ...` only if nexthop is connected

tests: Check if the right next-hop is shown (bgp_show_ip_bgp_fqdn)

Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>

Merge pull request #6283 from opensourcerouting/7.3/gcc-10

[7.3] backport gcc 10 fixes

bgpd: Do not discard an UPDATE if the global nexthop is set to ::

When we receive an UPDATE with MP_NEXTHOP len as 32 bytes, we shouldn't
check if the global (1st) nexthop is unspecified.

Peering between bird and FRRouting we receive from Bird something like:
```
rcvd UPDATE w/ attr: , origin i, mp_nexthop ::(fe80::a00:27ff:fe09:f8a3)
```
The link-local (2nd) nexthop is valid and validated later in the code.

Before it was marked:
```
IPv6 unicast -- DENIED due to: martian or self next-hop;
```

After it's a valid prefix:
```
spine1-debian-9# show bgp
BGP table version is 0, local router ID is 2.2.2.2, vrf id 0
Default local pref 100, local AS 65002
Status codes:  s suppressed, d damped, h history, * valid, > best, = multipath,
               i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes:  i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
   2a02:4780::/64   fe80::a00:27ff:fe09:f8a3
                                                           0 65001 i

Displayed  1 routes and 1 total paths
```

Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>

bgpd: Add a sanitify check for bgp_nexthop_cache against NULL

In real world sometimes happens that bgp_nexthop_cache is NULL. Avoid
segfaulting when using `show [ip] bgp ...` CLI commands.

Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>

bgpd: Show hostname in `show [ip] bgp ...` only if nexthop is connected

The problem is when using kinda such topologies:
(192.168.1.1/32) r1 <-- eBGP --> r2 <-- iBGP --> r3

Looking at r3's nexthop for 192.168.1.1/32 we have it as r2, but really
it MUST be r1.

Checking if the nexthop is connected solves the problem even for cases
when route-reflectors are used.

Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>

vrrpd: fix build on Fedora Rawhide

Fixes the following linker errors:
make[1]: Entering directory '/home/ruben/src/frr'
  CCLD     vrrpd/vrrpd
/usr/bin/ld: vrrpd/libvrrp.a(vrrp.o):/home/ruben/src/frr/vrrpd/vrrp_debug.h:33: multiple definition of `vrrp_dbg_sock'; vrrpd/vrrp_main.o:/home/ruben/src/frr/vrrpd/vrrp_debug.h:33: first defined here
/usr/bin/ld: vrrpd/libvrrp.a(vrrp.o):/home/ruben/src/frr/vrrpd/vrrp_debug.h:31: multiple definition of `vrrp_dbg_pkt'; vrrpd/vrrp_main.o:/home/ruben/src/frr/vrrpd/vrrp_debug.h:31: first defined here
/usr/bin/ld: vrrpd/libvrrp.a(vrrp.o):/home/ruben/src/frr/vrrpd/vrrp_debug.h:32: multiple definition of `vrrp_dbg_proto'; vrrpd/vrrp_main.o:/home/ruben/src/frr/vrrpd/vrrp_debug.h:32: first defined here
/usr/bin/ld: vrrpd/libvrrp.a(vrrp.o):/home/ruben/src/frr/vrrpd/vrrp_debug.h:34: multiple definition of `vrrp_dbg_zebra'; vrrpd/vrrp_main.o:/home/ruben/src/frr/vrrpd/vrrp_debug.h:34: first defined here
/usr/bin/ld: vrrpd/libvrrp.a(vrrp.o):/home/ruben/src/frr/vrrpd/vrrp_debug.h:29: multiple definition of `vrrp_dbg_auto'; vrrpd/vrrp_main.o:/home/ruben/src/frr/vrrpd/vrrp_debug.h:29: first defined here
/usr/bin/ld: vrrpd/libvrrp.a(vrrp.o):/home/ruben/src/frr/vrrpd/vrrp_debug.h:30: multiple definition of `vrrp_dbg_ndisc'; vrrpd/vrrp_main.o:/home/ruben/src/frr/vrrpd/vrrp_debug.h:30: first defined here
/usr/bin/ld: vrrpd/libvrrp.a(vrrp.o):/home/ruben/src/frr/vrrpd/vrrp_debug.h:28: multiple definition of `vrrp_dbg_arp'; vrrpd/vrrp_main.o:/home/ruben/src/frr/vrrpd/vrrp_debug.h:28: first defined here
/usr/bin/ld: vrrpd/libvrrp.a(vrrp_arp.o):/home/ruben/src/frr/vrrpd/vrrp_debug.h:28: multiple definition of `vrrp_dbg_arp'; vrrpd/vrrp_main.o:/home/ruben/src/frr/vrrpd/vrrp_debug.h:28: first defined here
/usr/bin/ld: vrrpd/libvrrp.a(vrrp_arp.o):/home/ruben/src/frr/vrrpd/vrrp_debug.h:33: multiple definition of `vrrp_dbg_sock'; vrrpd/vrrp_main.o:/home/ruben/src/frr/vrrpd/vrrp_debug.h:33: first defined here
/usr/bin/ld: vrrpd/libvrrp.a(vrrp_arp.o):/home/ruben/src/frr/vrrpd/vrrp_debug.h:34: multiple definition of `vrrp_dbg_zebra'; vrrpd/vrrp_main.o:/home/ruben/src/frr/vrrpd/vrrp_debug.h:34: first defined here
/usr/bin/ld: vrrpd/libvrrp.a(vrrp_arp.o):/home/ruben/src/frr/vrrpd/vrrp_debug.h:32: multiple definition of `vrrp_dbg_proto'; vrrpd/vrrp_main.o:/home/ruben/src/frr/vrrpd/vrrp_debug.h:32: first defined here
/usr/bin/ld: vrrpd/libvrrp.a(vrrp_arp.o):/home/ruben/src/frr/vrrpd/vrrp_debug.h:31: multiple definition of `vrrp_dbg_pkt'; vrrpd/vrrp_main.o:/home/ruben/src/frr/vrrpd/vrrp_debug.h:31: first defined here
/usr/bin/ld: vrrpd/libvrrp.a(vrrp_arp.o):/home/ruben/src/frr/vrrpd/vrrp_debug.h:30: multiple definition of `vrrp_dbg_ndisc'; vrrpd/vrrp_main.o:/home/ruben/src/frr/vrrpd/vrrp_debug.h:30: first defined here
/usr/bin/ld: vrrpd/libvrrp.a(vrrp_arp.o):/home/ruben/src/frr/vrrpd/vrrp_debug.h:29: multiple definition of `vrrp_dbg_auto'; vrrpd/vrrp_main.o:/home/ruben/src/frr/vrrpd/vrrp_debug.h:29: first defined here
/usr/bin/ld: vrrpd/libvrrp.a(vrrp_debug.o):/home/ruben/src/frr/vrrpd/vrrp_debug.h:32: multiple definition of `vrrp_dbg_proto'; vrrpd/vrrp_main.o:/home/ruben/src/frr/vrrpd/vrrp_debug.h:32: first defined here
/usr/bin/ld: vrrpd/libvrrp.a(vrrp_debug.o):/home/ruben/src/frr/vrrpd/vrrp_debug.h:29: multiple definition of `vrrp_dbg_auto'; vrrpd/vrrp_main.o:/home/ruben/src/frr/vrrpd/vrrp_debug.h:29: first defined here
/usr/bin/ld: vrrpd/libvrrp.a(vrrp_debug.o):/home/ruben/src/frr/vrrpd/vrrp_debug.h:31: multiple definition of `vrrp_dbg_pkt'; vrrpd/vrrp_main.o:/home/ruben/src/frr/vrrpd/vrrp_debug.h:31: first defined here
/usr/bin/ld: vrrpd/libvrrp.a(vrrp_debug.o):/home/ruben/src/frr/vrrpd/vrrp_debug.h:33: multiple definition of `vrrp_dbg_sock'; vrrpd/vrrp_main.o:/home/ruben/src/frr/vrrpd/vrrp_debug.h:33: first defined here
/usr/bin/ld: vrrpd/libvrrp.a(vrrp_debug.o):/home/ruben/src/frr/vrrpd/vrrp_debug.h:30: multiple definition of `vrrp_dbg_ndisc'; vrrpd/vrrp_main.o:/home/ruben/src/frr/vrrpd/vrrp_debug.h:30: first defined here
/usr/bin/ld: vrrpd/libvrrp.a(vrrp_debug.o):/home/ruben/src/frr/vrrpd/vrrp_debug.h:28: multiple definition of `vrrp_dbg_arp'; vrrpd/vrrp_main.o:/home/ruben/src/frr/vrrpd/vrrp_debug.h:28: first defined here
/usr/bin/ld: vrrpd/libvrrp.a(vrrp_debug.o):/home/ruben/src/frr/vrrpd/vrrp_debug.h:34: multiple definition of `vrrp_dbg_zebra'; vrrpd/vrrp_main.o:/home/ruben/src/frr/vrrpd/vrrp_debug.h:34: first defined here
/usr/bin/ld: vrrpd/libvrrp.a(vrrp_ndisc.o):/home/ruben/src/frr/vrrpd/vrrp_debug.h:30: multiple definition of `vrrp_dbg_ndisc'; vrrpd/vrrp_main.o:/home/ruben/src/frr/vrrpd/vrrp_debug.h:30: first defined here
/usr/bin/ld: vrrpd/libvrrp.a(vrrp_ndisc.o):/home/ruben/src/frr/vrrpd/vrrp_debug.h:31: multiple definition of `vrrp_dbg_pkt'; vrrpd/vrrp_main.o:/home/ruben/src/frr/vrrpd/vrrp_debug.h:31: first defined here
/usr/bin/ld: vrrpd/libvrrp.a(vrrp_ndisc.o):/home/ruben/src/frr/vrrpd/vrrp_debug.h:33: multiple definition of `vrrp_dbg_sock'; vrrpd/vrrp_main.o:/home/ruben/src/frr/vrrpd/vrrp_debug.h:33: first defined here
/usr/bin/ld: vrrpd/libvrrp.a(vrrp_ndisc.o):/home/ruben/src/frr/vrrpd/vrrp_debug.h:34: multiple definition of `vrrp_dbg_zebra'; vrrpd/vrrp_main.o:/home/ruben/src/frr/vrrpd/vrrp_debug.h:34: first defined here
/usr/bin/ld: vrrpd/libvrrp.a(vrrp_ndisc.o):/home/ruben/src/frr/vrrpd/vrrp_debug.h:32: multiple definition of `vrrp_dbg_proto'; vrrpd/vrrp_main.o:/home/ruben/src/frr/vrrpd/vrrp_debug.h:32: first defined here
/usr/bin/ld: vrrpd/libvrrp.a(vrrp_ndisc.o):/home/ruben/src/frr/vrrpd/vrrp_debug.h:29: multiple definition of `vrrp_dbg_auto'; vrrpd/vrrp_main.o:/home/ruben/src/frr/vrrpd/vrrp_debug.h:29: first defined here
/usr/bin/ld: vrrpd/libvrrp.a(vrrp_ndisc.o):/home/ruben/src/frr/vrrpd/vrrp_debug.h:28: multiple definition of `vrrp_dbg_arp'; vrrpd/vrrp_main.o:/home/ruben/src/frr/vrrpd/vrrp_debug.h:28: first defined here
/usr/bin/ld: vrrpd/libvrrp.a(vrrp_packet.o):/home/ruben/src/frr/vrrpd/vrrp_debug.h:34: multiple definition of `vrrp_dbg_zebra'; vrrpd/vrrp_main.o:/home/ruben/src/frr/vrrpd/vrrp_debug.h:34: first defined here
/usr/bin/ld: vrrpd/libvrrp.a(vrrp_packet.o):/home/ruben/src/frr/vrrpd/vrrp_debug.h:33: multiple definition of `vrrp_dbg_sock'; vrrpd/vrrp_main.o:/home/ruben/src/frr/vrrpd/vrrp_debug.h:33: first defined here
/usr/bin/ld: vrrpd/libvrrp.a(vrrp_packet.o):/home/ruben/src/frr/vrrpd/vrrp_debug.h:32: multiple definition of `vrrp_dbg_proto'; vrrpd/vrrp_main.o:/home/ruben/src/frr/vrrpd/vrrp_debug.h:32: first defined here
/usr/bin/ld: vrrpd/libvrrp.a(vrrp_packet.o):/home/ruben/src/frr/vrrpd/vrrp_debug.h:31: multiple definition of `vrrp_dbg_pkt'; vrrpd/vrrp_main.o:/home/ruben/src/frr/vrrpd/vrrp_debug.h:31: first defined here
/usr/bin/ld: vrrpd/libvrrp.a(vrrp_packet.o):/home/ruben/src/frr/vrrpd/vrrp_debug.h:30: multiple definition of `vrrp_dbg_ndisc'; vrrpd/vrrp_main.o:/home/ruben/src/frr/vrrpd/vrrp_debug.h:30: first defined here
/usr/bin/ld: vrrpd/libvrrp.a(vrrp_packet.o):/home/ruben/src/frr/vrrpd/vrrp_debug.h:29: multiple definition of `vrrp_dbg_auto'; vrrpd/vrrp_main.o:/home/ruben/src/frr/vrrpd/vrrp_debug.h:29: first defined here
/usr/bin/ld: vrrpd/libvrrp.a(vrrp_packet.o):/home/ruben/src/frr/vrrpd/vrrp_debug.h:28: multiple definition of `vrrp_dbg_arp'; vrrpd/vrrp_main.o:/home/ruben/src/frr/vrrpd/vrrp_debug.h:28: first defined here
/usr/bin/ld: vrrpd/libvrrp.a(vrrp_vty.o):/home/ruben/src/frr/vrrpd/vrrp_debug.h:34: multiple definition of `vrrp_dbg_zebra'; vrrpd/vrrp_main.o:/home/ruben/src/frr/vrrpd/vrrp_debug.h:34: first defined here
/usr/bin/ld: vrrpd/libvrrp.a(vrrp_vty.o):/home/ruben/src/frr/vrrpd/vrrp_debug.h:33: multiple definition of `vrrp_dbg_sock'; vrrpd/vrrp_main.o:/home/ruben/src/frr/vrrpd/vrrp_debug.h:33: first defined here
/usr/bin/ld: vrrpd/libvrrp.a(vrrp_vty.o):/home/ruben/src/frr/vrrpd/vrrp_debug.h:32: multiple definition of `vrrp_dbg_proto'; vrrpd/vrrp_main.o:/home/ruben/src/frr/vrrpd/vrrp_debug.h:32: first defined here
/usr/bin/ld: vrrpd/libvrrp.a(vrrp_vty.o):/home/ruben/src/frr/vrrpd/vrrp_debug.h:31: multiple definition of `vrrp_dbg_pkt'; vrrpd/vrrp_main.o:/home/ruben/src/frr/vrrpd/vrrp_debug.h:31: first defined here
/usr/bin/ld: vrrpd/libvrrp.a(vrrp_vty.o):/home/ruben/src/frr/vrrpd/vrrp_debug.h:30: multiple definition of `vrrp_dbg_ndisc'; vrrpd/vrrp_main.o:/home/ruben/src/frr/vrrpd/vrrp_debug.h:30: first defined here
/usr/bin/ld: vrrpd/libvrrp.a(vrrp_vty.o):/home/ruben/src/frr/vrrpd/vrrp_debug.h:29: multiple definition of `vrrp_dbg_auto'; vrrpd/vrrp_main.o:/home/ruben/src/frr/vrrpd/vrrp_debug.h:29: first defined here
/usr/bin/ld: vrrpd/libvrrp.a(vrrp_vty.o):/home/ruben/src/frr/vrrpd/vrrp_debug.h:28: multiple definition of `vrrp_dbg_arp'; vrrpd/vrrp_main.o:/home/ruben/src/frr/vrrpd/vrrp_debug.h:28: first defined here
/usr/bin/ld: vrrpd/libvrrp.a(vrrp_zebra.o):/home/ruben/src/frr/vrrpd/vrrp_debug.h:34: multiple definition of `vrrp_dbg_zebra'; vrrpd/vrrp_main.o:/home/ruben/src/frr/vrrpd/vrrp_debug.h:34: first defined here
/usr/bin/ld: vrrpd/libvrrp.a(vrrp_zebra.o):/home/ruben/src/frr/vrrpd/vrrp_debug.h:33: multiple definition of `vrrp_dbg_sock'; vrrpd/vrrp_main.o:/home/ruben/src/frr/vrrpd/vrrp_debug.h:33: first defined here
/usr/bin/ld: vrrpd/libvrrp.a(vrrp_zebra.o):/home/ruben/src/frr/vrrpd/vrrp_debug.h:32: multiple definition of `vrrp_dbg_proto'; vrrpd/vrrp_main.o:/home/ruben/src/frr/vrrpd/vrrp_debug.h:32: first defined here
/usr/bin/ld: vrrpd/libvrrp.a(vrrp_zebra.o):/home/ruben/src/frr/vrrpd/vrrp_debug.h:31: multiple definition of `vrrp_dbg_pkt'; vrrpd/vrrp_main.o:/home/ruben/src/frr/vrrpd/vrrp_debug.h:31: first defined here
/usr/bin/ld: vrrpd/libvrrp.a(vrrp_zebra.o):/home/ruben/src/frr/vrrpd/vrrp_debug.h:30: multiple definition of `vrrp_dbg_ndisc'; vrrpd/vrrp_main.o:/home/ruben/src/frr/vrrpd/vrrp_debug.h:30: first defined here
/usr/bin/ld: vrrpd/libvrrp.a(vrrp_zebra.o):/home/ruben/src/frr/vrrpd/vrrp_debug.h:29: multiple definition of `vrrp_dbg_auto'; vrrpd/vrrp_main.o:/home/ruben/src/frr/vrrpd/vrrp_debug.h:29: first defined here
/usr/bin/ld: vrrpd/libvrrp.a(vrrp_zebra.o):/home/ruben/src/frr/vrrpd/vrrp_debug.h:28: multiple definition of `vrrp_dbg_arp'; vrrpd/vrrp_main.o:/home/ruben/src/frr/vrrpd/vrrp_debug.h:28: first defined here
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:6639: vrrpd/vrrpd] Error 1
make[1]: Leaving directory '/home/ruben/src/frr'
make: *** [Makefile:4525: all] Error 2

Signed-off-by: Ruben Kerkhof <ruben@rubenkerkhof.com>
(cherry picked from commit 744f2650c4e7b6dd5075c31dc8e1638269a6f601)

babeld: GCC complaining about no return in non-void function

The babel_main_loop function did not have a return for
a non-void function.  For some reason gcc is starting to complain
about this now.

Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
(cherry picked from commit be04d1487f975e4044c2c07089722dab7f5afbff)

babeld: fix build on Fedora Rawhide

Fixes the following linker errors:
/usr/bin/ld: babeld/libbabel.a(babel_interface.o):/home/ruben/src/frr/babeld/util.h:125: multiple definition of `v4prefix'; babeld/babel_main.o:/home/ruben/src/frr/babeld/util.h:125: first defined here
/usr/bin/ld: babeld/libbabel.a(babel_zebra.o):/home/ruben/src/frr/babeld/util.h:125: multiple definition of `v4prefix'; babeld/babel_main.o:/home/ruben/src/frr/babeld/util.h:125: first defined here
/usr/bin/ld: babeld/libbabel.a(babeld.o):/home/ruben/src/frr/babeld/util.h:125: multiple definition of `v4prefix'; babeld/babel_main.o:/home/ruben/src/frr/babeld/util.h:125: first defined here
/usr/bin/ld: babeld/libbabel.a(kernel.o):/home/ruben/src/frr/babeld/util.h:125: multiple definition of `v4prefix'; babeld/babel_main.o:/home/ruben/src/frr/babeld/util.h:125: first defined here
/usr/bin/ld: babeld/libbabel.a(message.o):/home/ruben/src/frr/babeld/util.h:125: multiple definition of `v4prefix'; babeld/babel_main.o:/home/ruben/src/frr/babeld/util.h:125: first defined here
/usr/bin/ld: babeld/libbabel.a(neighbour.o):/home/ruben/src/frr/babeld/util.h:125: multiple definition of `v4prefix'; babeld/babel_main.o:/home/ruben/src/frr/babeld/util.h:125: first defined here
/usr/bin/ld: babeld/libbabel.a(net.o):/home/ruben/src/frr/babeld/util.h:125: multiple definition of `v4prefix'; babeld/babel_main.o:/home/ruben/src/frr/babeld/util.h:125: first defined here
/usr/bin/ld: babeld/libbabel.a(resend.o):/home/ruben/src/frr/babeld/util.h:125: multiple definition of `v4prefix'; babeld/babel_main.o:/home/ruben/src/frr/babeld/util.h:125: first defined here
/usr/bin/ld: babeld/libbabel.a(route.o):/home/ruben/src/frr/babeld/util.h:125: multiple definition of `v4prefix'; babeld/babel_main.o:/home/ruben/src/frr/babeld/util.h:125: first defined here
/usr/bin/ld: babeld/libbabel.a(source.o):/home/ruben/src/frr/babeld/util.h:125: multiple definition of `v4prefix'; babeld/babel_main.o:/home/ruben/src/frr/babeld/util.h:125: first defined here
/usr/bin/ld: babeld/libbabel.a(util.o):/home/ruben/src/frr/babeld/util.h:125: multiple definition of `v4prefix'; babeld/babel_main.o:/home/ruben/src/frr/babeld/util.h:125: first defined here
/usr/bin/ld: babeld/libbabel.a(xroute.o):/home/ruben/src/frr/babeld/util.h:125: multiple definition of `v4prefix'; babeld/babel_main.o:/home/ruben/src/frr/babeld/util.h:125: first defined here
/usr/bin/ld: babeld/libbabel.a(babel_filter.o):/home/ruben/src/frr/babeld/util.h:125: multiple definition of `v4prefix'; babeld/babel_main.o:/home/ruben/src/frr/babeld/util.h:125: first defined here
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:6015: babeld/babeld] Error 1

Signed-off-by: Ruben Kerkhof <ruben@rubenkerkhof.com>
(cherry picked from commit b0ba81f81f5fff158e756ef52c91f8c6179872e6)

bgpd: remove unused variable

This fixes a linking issue on Fedora Rawhide:
/usr/bin/ld: bgpd/libbgp.a(bgp_flowspec.o):/home/ruben/src/frr/./bgpd/bgp_attr_evpn.h:37: multiple definition of `eth_tag_id'; bgpd/bgp_btoa-bgp_btoa.o:/home/ruben/src/frr/./bgpd/bgp_attr_evpn.h:37: first defined here
collect2: error: ld returned 1 exit status

Signed-off-by: Ruben Kerkhof <ruben@rubenkerkhof.com>
(cherry picked from commit 01feb0907f6e7f72fbd973dba1ea69489f11a9c7)

pimd: Make frr able to be built by gcc 10

- Add extern modifier to some declarations in header file and move
qpim_all_pim_routers_addr definition to pimd/pimd.c

`GCC now defaults to -fno-common. As a result, global variable accesses
are more efficient on various targets. In C, global variables with
multiple tentative definitions now result in linker errors.`
Taken from https://gcc.gnu.org/gcc-10/changes.html

Signed-off-by: Tomas Korbar <tkorbar@redhat.com>
(cherry picked from commit 403242d214b6cb919ed08f2149d7bee77a060947)

ldpd: remove multiple definitions of thread_master

This fixes the last issue compiling FRR with GCC 10 on Fedora Rawhide.

Signed-off-by: Ruben Kerkhof <ruben@rubenkerkhof.com>
(cherry picked from commit f3faea7fe3bf5f73991effe56290346e3f43728e)

ldpd: fix another linking issue with GCC-10

Signed-off-by: Ruben Kerkhof <ruben@rubenkerkhof.com>
(cherry picked from commit 54ca644b6e20416587484011f8e649eeddf2cb15)

tests: fix build with GCC 10

Signed-off-by: Ruben Kerkhof <ruben@rubenkerkhof.com>
(cherry picked from commit 9635de6e9b8cbc35f5ec62d4d1dc8b6c72df8c45)

ldpd: Fix linking error on Fedora Rawhide with GCC 10

GCC 10 switched to -fno-common by default, see
https://gcc.gnu.org/gcc-10/porting_to.html#common for details.

Fixes:
  CCLD     ldpd/ldpd
/usr/bin/ld: ldpd/libldp.a(adjacency.o):/home/ruben/src/frr/ldpd/ldpe.h:294: multiple definition of `pkt_ptr'; ldpd/ldpd.o:/home/ruben/src/frr/ldpd/ldpe.h:294: first defined here

Signed-off-by: Ruben Kerkhof <ruben@rubenkerkhof.com>
(cherry picked from commit 56b7d7252f13f3c90c824287b2441f13e2b0defe)

Merge pull request #6148 from opensourcerouting/ldpd-broken-lsps-7.3

[7.3] ldpd: don't drop packets coming through a broken LSP

Merge pull request #6223 from dslicenc/ospf6d-brouter-loop-73

[7.3]ospf6d: stop looping thru same Inter-Area Router LSAs

ospf6d: stop looping thru same Inter-Area Router LSAs

Processing loop uncovered when there are multiple ABRs also
acting as ASBRs into the same area in ospf6.  The problem
was that when looking thru the list of Inter-area router
entries, if the current entry being processed matched, it
still merged next-hops and re-initiated the process.  In
this fix, if the route/path matches and the next-hops also
match, there is no need to re-initiate the examine process.

Ticket: CM-28900
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>

ldpd: don't drop packets coming through a broken LSP

When the Independent Control mode is in use (the default one),
each LDP speaker allocates labels independently, which can lead to
broken LSPs when the LDP and IGP domains are not congruent.

What we were doing in this case was to drop all packets coming
through a broken LSP, which causes drastic side effects in the
network like loss of IP connectivity between routers.

We can however do a best-effort attempt to avoid packet loss by
popping the top-level label of the incoming packets and forwarding
them normally to their nexthops. This will be enough to guarantee
that labeled IP packets will reach their final destination. The
broken LSPs will still be unsuitable to tunnel labeled traffic, like
VPN packets, but in this case there's nothing we can do about it.

Cisco's IOS does something similar, called the "Untagged/No Label"
operation, which removes the entire label stack and forward the
packet unlabeled. We don't have such functionality available in the
Linux kernel, but this shouldn't make any difference for practical
purposes.

Fixes #6127.

Signed-off-by: Renato Westphal <renato@opensourcerouting.org>

Merge pull request #6151 from sworleys/NHG-Backports_7.3

[7.3] NHG Backports

zebra: add null check before connecting recursive depend

Add a null check in `handle_recursive_depend()` so it
doesn't try to add a NULL pointer to the RB tree.

This was found with clang SA.

Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
(cherry picked from commit a7e1b02d4a6794a5caa475ab6e4bfc30fdc6b31b)

zebra: reset nexthop pointer in zread of nexthops

We were not resetting the nexthop pointer to NULL for each
new read of a nexthop from the zapi route. On the chance we
get a nexthop that does not have a proper type, we will not
create a new nexthop and update that pointer, thus it still
has the last valid one and will create a group with two
pointers to the same nexthop.

Then when it enters any code that iterates the group, it loops
endlessly.

This was found with zapi fuzzing.

```
0x00007f728891f1c3 in jhash2 (k=<optimized out>, length=<optimized out>, initval=12183506) at lib/jhash.c:138
0x00007f728896d92c in nexthop_hash (nexthop=<optimized out>) at lib/nexthop.c:563
0x00007f7288979ece in nexthop_group_hash (nhg=<optimized out>) at lib/nexthop_group.c:394
0x0000000000621036 in zebra_nhg_hash_key (arg=<optimized out>) at zebra/zebra_nhg.c:356
0x00007f72888ec0e1 in hash_get (hash=<optimized out>, data=0x7ffffb94aef0, alloc_func=0x0) at lib/hash.c:138
0x00007f72888ee118 in hash_lookup (hash=0x7f7288de2f10, data=0x7f728908e7fc) at lib/hash.c:183
0x0000000000626613 in zebra_nhg_find (nhe=0x7ffffb94b080, id=0, nhg=0x6020000032d0, nhg_depends=0x0, vrf_id=<optimized out>,
    afi=<optimized out>, type=<optimized out>) at zebra/zebra_nhg.c:541
0x0000000000625f39 in zebra_nhg_rib_find (id=0, nhg=<optimized out>, rt_afi=AFI_IP) at zebra/zebra_nhg.c:1126
0x000000000065f953 in rib_add_multipath (afi=AFI_IP, safi=<optimized out>, p=0x7ffffb94b370, src_p=0x0, re=0x6070000013d0,
    ng=0x7f728908e7fc) at zebra/zebra_rib.c:2616
0x0000000000768f90 in zread_route_add (client=0x61f000000080, hdr=<optimized out>, msg=<optimized out>, zvrf=<optimized out>)
    at zebra/zapi_msg.c:1596
0x000000000077c135 in zserv_handle_commands (client=<optimized out>, msg=0x61b000000780) at zebra/zapi_msg.c:2636
0x0000000000575e1f in main (argc=<optimized out>, argv=<optimized out>) at zebra/main.c:309
```

```
(gdb) p *nhg->nexthop
$4 = {next = 0x5488e0, prev = 0x5488e0, vrf_id = 16843009, ifindex = 16843009, type = NEXTHOP_TYPE_IFINDEX, flags = 8 '\b', {gate = {ipv4 = {s_addr = 0},
      ipv6 = {__in6_u = {__u6_addr8 = '\000' <repeats 15 times>, __u6_addr16 = {0, 0, 0, 0, 0, 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}},
    bh_type = BLACKHOLE_UNSPEC}, src = {ipv4 = {s_addr = 0}, ipv6 = {__in6_u = {__u6_addr8 = '\000' <repeats 15 times>, __u6_addr16 = {0, 0, 0, 0, 0, 0, 0,
          0}, __u6_addr32 = {0, 0, 0, 0}}}}, rmap_src = {ipv4 = {s_addr = 0}, ipv6 = {__in6_u = {__u6_addr8 = '\000' <repeats 15 times>, __u6_addr16 = {0, 0,
          0, 0, 0, 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}}, resolved = 0x0, rparent = 0x0, nh_label_type = ZEBRA_LSP_NONE, nh_label = 0x0, weight = 1 '\001'}
(gdb) quit

```

Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
(cherry picked from commit c8b891b48392e0d29eb7b56942e4df697d4c14fd)

zebra: don't created connected if duplicate depend

Since we are using a UNIQUE RB tree, we need to handle the
case of adding in a duplicate entry into it.

The list API code returns NULL when a successfull add
occurs, so lets pull that handling further up into
the connected handlers. Then, free the allocated
connected struct if it is a duplicate.

This is a pretty unlikely situation to happen.

Also, pull up the RB handling of _del RB API as well.

This was found with the zapi fuzzing code.

```
==1052840==
==1052840== 200 bytes in 5 blocks are definitely lost in loss record 545 of 663
==1052840==    at 0x483BB1A: calloc (vg_replace_malloc.c:762)
==1052840==    by 0x48E1008: qcalloc (memory.c:110)
==1052840==    by 0x44D357: nhg_connected_new (zebra_nhg.c:73)
==1052840==    by 0x44D300: nhg_connected_tree_add_nhe (zebra_nhg.c:123)
==1052840==    by 0x44FBDC: depends_add (zebra_nhg.c:1077)
==1052840==    by 0x44FD62: depends_find_add (zebra_nhg.c:1090)
==1052840==    by 0x44E46D: zebra_nhg_find (zebra_nhg.c:567)
==1052840==    by 0x44E1FE: zebra_nhg_rib_find (zebra_nhg.c:1126)
==1052840==    by 0x45AD3D: rib_add_multipath (zebra_rib.c:2616)
==1052840==    by 0x4977DC: zread_route_add (zapi_msg.c:1596)
==1052840==    by 0x49ABB9: zserv_handle_commands (zapi_msg.c:2636)
==1052840==    by 0x428B11: main (main.c:309)
```

Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
(cherry picked from commit 5bf15faa19288144c214ca48ef26e01512037ef6)

zebra: break if duplicate nexthop found in nhe2grp

If we find that a nexthop is a duplicate, break immediately
rather than continuing to look through the rest of the list.

Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
(cherry picked from commit d43122b58f4bf9cb729c786b990ae254b8dde35b)

zebra: properly set the NEXTHOP_GROUP_VALID flag

Properly set the NEXTHOP_GROUP_VALID flag and use it
as a conditional for installation decisions for individual
nexthop and groups containing it.

We set the NEXTHOP_GROUP_VALID flag it is:

1) A fully resolved active nexthop
or
2) Its a group that contains at least one VALID NHE

Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
(cherry picked from commit 086e4e02f5fe02849ad9a6c17472094c1c1cbd98)

zebra: set valid on re->nhe directly in nexthop_active_update()

We were still doing a lookup on the nhe_id from before we
started referencing re->nhe directly.

Change set flag to just use re->nhe directly here since they
should always be the same at this point in the code anyway.

Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
(cherry picked from commit 715e5c70d564017a8b709599e23bf94884ab9bb9)

zebra: add debug for duplicate NH in dataplane array conversion

When we find a nexthop ID thats a duplicate in the code that converts
NHG rb trees into a flat list of nexthop IDs for the dataplane,
output a debug message.

Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
(cherry picked from commit b1c3f7ef80fb626a15a1043b4c46f53c3fd34826)

zebra: don't add ID to kernel nh_grp if not installed/queued

When we transform the nexthop group rb trees into a flat
array of IDs to send into the dataplane code (zebra_nhg_nhe2grp),
don't put an ID in there that has not been in installed or is
not currently queued to be installed into the dataplane.

Otherwise, if some of the nexthops fail to install, we will
still try to create a group with them and then the entire group
will fail.

Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
(cherry picked from commit 1866b3afc259c565f42a9aab262ede27c142eea4)

zebra: handle NHG in NHG dataplane group conversion

We were not properly handling the case of a NHG inside of
another NHG when converting the rb tree of a multilevel NHG
into a flat list of IDs. When constructing, we call the function
zebra_nhg_nhe2grp_internal() recursively so that the rare
case of a group within a group is handled such that its
singleton nexthops are appended to the grp array of IDs
we send to the dataplane code.

Ex)

1:
-> 2:
-> 3
-> 4
->5:
->6

becomes this:

1:
->3
->4
->6

when its sent to the dataplane code for final kernel installation.

Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
(cherry picked from commit 497ff5792f6a27702bf4ee33b79e1a80ffcf0a09)

Merge pull request #6142 from opensourcerouting/7.3/defaults-fix-bools

[7.3] bgpd, ospfd, ospf6d: long is not bool :(

Merge pull request #6140 from sworleys/NHG-Fix-Dup-Leak_7.3

[7.3] zebra: free unhashable (dup) NHEs via ID table cleanup

bgpd, ospfd, ospf6d: long is not bool :(

... Oops ...

(for context, the defaults code originally didn't have a dedicated
"bool" variant and just used long for bools...  I derp'd this when
adding bool as a separate case :( )

Reported-by: Donald Sharp <sharpd@cumulusnetworks.com>
Signed-off-by: David Lamparter <equinox@diac24.net>
(cherry picked from commit 4c1458b595282bff6a6e0b20767bb5cb655d0b4c)

zebra: free unhashable (dup) NHEs via ID table cleanup

Free unhashable (duplicate NHEs from the kernel) via ID table
cleanup. Since the NHE ID hash table contains extra entries,
that's the one we need to be calling zebra_nhg_hash_free()
on, otherwise we will never free the unhashable NHEs.

This was found via a memleak:

==1478713== HEAP SUMMARY:
==1478713==     in use at exit: 10,267 bytes in 46 blocks
==1478713==   total heap usage: 76,810 allocs, 76,764 frees, 3,901,237 bytes allocated
==1478713==
==1478713== 208 (88 direct, 120 indirect) bytes in 1 blocks are definitely lost in loss record 35 of 41
==1478713==    at 0x483BB1A: calloc (vg_replace_malloc.c:762)
==1478713==    by 0x48E35E8: qcalloc (memory.c:110)
==1478713==    by 0x451CCB: zebra_nhg_alloc (zebra_nhg.c:369)
==1478713==    by 0x453DE3: zebra_nhg_copy (zebra_nhg.c:379)
==1478713==    by 0x452670: nhg_ctx_process_new (zebra_nhg.c:1143)
==1478713==    by 0x4523A8: nhg_ctx_process (zebra_nhg.c:1234)
==1478713==    by 0x452A2D: zebra_nhg_kernel_find (zebra_nhg.c:1294)
==1478713==    by 0x4326E0: netlink_nexthop_change (rt_netlink.c:2433)
==1478713==    by 0x427320: netlink_parse_info (kernel_netlink.c:945)
==1478713==    by 0x432DAD: netlink_nexthop_read (rt_netlink.c:2488)
==1478713==    by 0x41B600: interface_list (if_netlink.c:1486)
==1478713==    by 0x457275: zebra_ns_enable (zebra_ns.c:127)

Repro with:
ip next add id 1 blackhole
ip next add id 2 blackhole

valgrind /usr/lib/frr/zebra

Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
(cherry picked from commit c25c3ea57a3dcd3b36d86ba76dd34961bcb662f0)

Merge pull request #6136 from sworleys/NHG-Fix-Src_7.3

[7.3] zebra: determine src with nexthop objects as well

zebra: determine src when using nexthop objects

Determine src based on nexthop data even when we are using
kernel nexthop objects.

Before, we were entirely skipping this step and just sending the
nexthop ID, ignoring src determination.

Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
(cherry picked from commit d8bfd8dc9a899f841967257a6b5f30910fdc17c8)

zebra: abstract route src determiniation into func

Abstraction the route src determination from a nexthop in the
netlink code into a function for both singlepath and mutlipath
to call.

Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
(cherry picked from commit 762288f50f5fa29512864fcc7814be83e1b58ff4)

Merge pull request #6098 from opensourcerouting/73_topo-fixes

Topotest fixes

tests: fix check for nhid in ipv6 table output

Check based on actual output instead of assuming output based
on kernel version

Signed-off-by: Martin Winter <mwinter@opensourcerouting.org>

tests: Make topotest working on different locale

"sort" as used in all-protocol-startup used sort which causes
different sort order based on locale settings. Specify the
correct one to make output matching our expected result

Signed-off-by: Martin Winter <mwinter@opensourcerouting.org>

Merge pull request #6063 from donaldsharp/73_want_a_yump

yang: Partially revert code to restore functionality

yang: Partially revert code to restore functionality

Partially revert code from commit:
f22b9250853229c93617ffdad139a4762f5f7348

since this broke passive-interface, network and offset-list
commands in rip and ripng

Fixes: #6001
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>

Merge pull request #5980 from donaldsharp/backport_no_nhg_kernel_73

zebra: [7.3] add config to disable use of kernel nexthops

zebra: add config to disable use of kernel nexthops

Add a config that disables use of kernel-level nexthop ids.
Currently, zebra always uses nexthop ids if the kernel supports
them.

Signed-off-by: Mark Stapp <mjs@voltanet.io>

Merge pull request #5888 from ton31337/fix/do_not_show_failed_if_shutdown_7.3

bgpd: [7.3] `show bgp summary failed` backports

bgpd: Format properly `show bgp summary failed`

Before:
```
Neighbor        EstdCnt DropCnt ResetTime Reason
192.168.0.1           0       0    never  Waiting for peer OPEN
```

After:
```
Neighbor        EstdCnt DropCnt ResetTime Reason
192.168.0.1           0       0     never Waiting for peer OPEN
```

Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>

bgpd: Show the real reason why the peer is failed

If the peer was shutdown locally, it doesn't show up as admin. shutdown.
Instead it's treated as "Waiting for peer OPEN".

The same applies to when the peer reaches maximum-prefix count.

Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>

bgpd: Update failed reason to distinguish some NHT scenarios

Current failed reasons for bgp when you have a peer that
is not online yet is `Waiting for NHT`, even if NHT has
succeeded.  Add some code to differentiate this.

eva# show bgp ipv4 uni summ failed
BGP router identifier 192.168.201.135, local AS number 3923 vrf-id 0
BGP table version 0
RIB entries 0, using 0 bytes of memory
Peers 2, using 43 KiB of memory
Neighbor        EstdCnt DropCnt ResetTime Reason
192.168.44.1          0       0    never  Waiting for NHT
192.168.201.139       0       0    never  Waiting for Open to Succeed
Total number of neighbors 2
eva#

eva# show bgp nexthop
Current BGP nexthop cache:
 192.168.44.1 invalid, peer 192.168.44.1
  Must be Connected
  Last update: Mon Feb 10 19:05:19 2020

 192.168.201.139 valid [IGP metric 0], #paths 0, peer 192.168.201.139

So 192.168.201.139 is a peer for a connected route that has not been
created on .139, while 44.1 nexthop tracking has not succeeded yet.

Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>

Merge pull request #5832 from mjstapp/fix_rtadv_stubs_7_3

[7.3] zebra: Fix rtadv stubs

zebra: fix missing route-advert stubs

Stubs are used when frr is built without route-advert
support; a couple of apis were missing, causing builds to fail.

Signed-off-by: Mark Stapp <mjs@voltanet.io>

FRRouting Release 7.3

BGPd
   EVPN PIP Support
   Route Aggregation code speed ups
   BGP Vector I/O speed ups
   New CLI: `set distance XXX`
   New CLI: `aggregate-address A.B.C.D/M route-map WORD`
   New CLI: `bgp reject-as-sets`
   New CLI: `advertise pip ...`
   New CLI: `match evpn rd ASN:NN_OR_IP-ADDRESS:NN`
   New CLI: `show bgp l2vpn evpn community|large-community X`
   New CLI: `show bgp l2vpn evpn A.B.C.D`
   Auto-completion for clear bgp command
   Add ability to set tcp socket buffer size
OSPFd
   Partial MPLS TE support
PBRd
   New CLI: `set vrf unchanged|NAME`
BFDd
   VRF Support
   New CLI: 'show bfd peers brief'
   New CLI: 'clear bfd peer ...'
PIMd
   Significant Speedups in accessing Internal Data for higher scale
   Support for joining any-source Multicast
   Updated CLI: 'show ip pim upstream-join-desired'
   New CLI: 'show ip pim channel'
   Debug Cleanup
   MLAG experimental support
VRRPd
   VRF Support
   Northbound Conversion- NHRPd
vtysh
   New CLI: `banner motd line LINE...`
yangx
   New CLI: `show yang operational-data XPATH`
   New CLI: `debug northbound`
Zebra
   Nexthop Group support
   New CLI: 'debug zebra nexthop [detail]'
   New CLI: 'show router-id'
   MLAG experimental support
watchfrr
   Additional status messages of system state to systemd
   New CLI: `watchfrr ignore DAEMON`
Others
   As always all daemons have received too many bug fixes to fully list
   There has been a significant focus on increasing test coverage
Change in Behavior:
   ISISd
      All areas created default automatically to level-1-2
   Zebra
      Nexthop Group Installation in Kernel is turned on by default
      if the kernel supports-    New CLI: 'show nexthop-group rib [singleton]'
   Man Pages
      Renamed to frr-* to remove collision with other packages

Signed-off-by: Martin Winter <mwinter@opensourcerouting.org>

Merge pull request #5782 from donaldsharp/bgp_73

[7.3]bgpd: Remove prefix pointer creation

Merge pull request #5784 from donaldsharp/dc_73

[7.3] Double commit of nexthop cli changes to get this in.

doc: Update doc to reflect changes in `show nexthop-group rib` command

Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>

zebra: nexthop groups vrf's are only a function of namespaces

Nexthop groups as a whole do not make sense to have a vrf'ness
As that you can have a arbitrary number of nexthops that point
to separate vrf's.

Modify the code to make this distinction, by clearly delineating
the line between the nhg and the nexthop a bit better.
Nexthop groups having a vrf_id only make sense if you are using
network namespaces to represent them.

Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>

zebra: Modify 'show nexthop-group rib ip|ipv6'

The zebra implementation of nexthop groups has
two types of nexthops groups currently.  Singleton
objects which have afi's and combined nexthop groups
that do not.  Specifically call this out in the code
to make this distinction.

Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>

bgpd: Remove prefix pointer creation

The creation of a prefix pointer is unnecessary.  Save the
prefix as part of the actual data structure.  This will
reduce the data needed by 8 bytes per nexthop stored.

Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>

Merge pull request #5769 from Spantik/bugs

OSPF: Multi instance broken

OSPF: Multi instance broken

Multi instance ospf support was broken due to PR #4564.
Adding fix back and extra checks to support multi instance
OSPF.

Fixes issues #5343 & #5741

Signed-off-by: Santosh P K <sapk@vmware.com>

Merge pull request #5735 from chiragshah6/73_evpn

[7.3] bgpd: fix evpn route json memory leaks

Merge pull request #5736 from opensourcerouting/move_rpm_to_python3_73

[7.3] Move rpm to python3

bgpd: fix memory leak in evpn json outpus II

Two of the evpn show commands with json option has memory leak.
1) show bgp l2vpn evpn route vni all json
2) show bgp l2vpn evpn route esi json

Before fix:
----------
Executed 'show bgp l2vpn evpn route vni all json' multiple times
used ordinary blocks continue to increase.

Note at the time of show command capture there were 22 evpn routes
in vni evpn route table.

Memory statistics for bgpd:
System allocator statistics:
  Total heap allocated:  9152 KiB
  Holding block headers: 0 bytes
  Used small blocks:     0 bytes
  Used ordinary blocks:  7300 KiB
  Free small blocks:     1760 bytes
  Free ordinary blocks:  1852 KiB
  Ordinary blocks:       880
  Small blocks:          51
  Holding blocks:        0

Ticket:CM-27920
Reviewed By:
Testing Done:

After fix:
---------
Executed 'show bgp l2vpn evpn route vni all json' multiple times
Used ordinary blocks remains low.

Memory statistics for bgpd:
System allocator statistics:
  Total heap allocated:  8356 KiB
  Holding block headers: 0 bytes
  Used small blocks:     0 bytes
  Used ordinary blocks:  6492 KiB
  Free small blocks:     1840 bytes
  Free ordinary blocks:  1864 KiB
  Ordinary blocks:       939
  Small blocks:          52
  Holding blocks:        0

Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>

bgpd: fix memory leak in evpn json outputs

Found memory leak in json output of evpn's route
commands.

After executing 'show bgp l2vpn evpn route type prefix json'
and 'show bgp l2vpn evpn route type macip json' few times
(6 times) with more than 600 routes in total seeing
memory footprint for bgpd continue to grow.

Memory statistics for bgpd:
System allocator statistics:
  Total heap allocated:  12 MiB
  Holding block headers: 0 bytes
  Used small blocks:     0 bytes
  Used ordinary blocks:  8390 KiB
  Free small blocks:     1760 bytes
  Free ordinary blocks:  3762 KiB
  Ordinary blocks:       1161
  Small blocks:          51
  Holding blocks:        0

Ticket:CM-27920
Testing Done:

After fix:
excute few times,
'show bgp l2vpn evpn route type prefix json'
and 'show bgp l2vpn evpn route type macip json'
commands where used ordinary blocks (uordblks) is
in steady state.

Memory statistics for bgpd:
System allocator statistics:
  Total heap allocated:  9968 KiB
  Holding block headers: 0 bytes
  Used small blocks:     0 bytes
  Used ordinary blocks:  6486 KiB
  Free small blocks:     1984 bytes
  Free ordinary blocks:  3482 KiB
  Ordinary blocks:       1110
  Small blocks:          54
  Holding blocks:        0

Memory statistics for bgpd:
System allocator statistics:
  Total heap allocated:  10100 KiB
  Holding block headers: 0 bytes
  Used small blocks:     0 bytes
  Used ordinary blocks:  6488 KiB
  Free small blocks:     1984 bytes
  Free ordinary blocks:  3612 KiB
  Ordinary blocks:       1113
  Small blocks:          54
  Holding blocks:        0

Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>

doc: Update RedHat packaging description to use Python 3

Signed-off-by: Martin Winter <mwinter@opensourcerouting.org>

redhat: Update frr.spec.in to move all systems to Python3 except CentOS 6

Signed-off-by: Martin Winter <mwinter@opensourcerouting.org>

tools: Update generate_support_bundle.py to support Python 3

Signed-off-by: Martin Winter <mwinter@opensourcerouting.org>

Merge pull request #5730 from opensourcerouting/73_fix_centos6

lib: Fix missing __be16 typedef on CentOS6

lib: Fix missing __be16 typedef on CentOS6

Need to include linux/types.h on older Linux

Signed-off-by: Martin Winter <mwinter@opensourcerouting.org>

Merge pull request #5723 from donaldsharp/73_onlink_loss

73 onlink loss

doc: Update ospf unnumbered documentation

Update the ospf unnumbered documentation to reflect how
to get it working under linux.

Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>

tests: Test ospf unnumbered behavior and ensure that it works

Recent commit: 0eb97b860dc94329cf9add9f8f3d3a2c7f539568

Broke onlink behavior and as a result ospf unnumbered failed
to work.  This commit adds a small test to create 2 ospf routers,
connect them through ospf unlinked behavior and then ensure
that the routes are installed into the kernel as expected.

Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>

zebra: Re-add onlink flag due to loss in earlier commit

commit: 0eb97b860dc94329cf9add9f8f3d3a2c7f539568

Removed this chunk of code in zebra:
-       if (ifp)
-               if (connected_is_unnumbered(ifp))
-                       SET_FLAG(nexthop->flags, NEXTHOP_FLAG_ONLINK);

Effectively if we had a NEXTHOP_TYPE_IPV4_IFINDEX we would
auto set the onlink flag.  This commit dropped it for some reason.

Add it back in an intelligent manner.

Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>

Merge pull request #5720 from mjstapp/fix_nh_debug_show_7_3

zebra: [7.3] include zebra nexthop debug in show run

zebra: include zebra nexthop debug in show run

[7.3 version] Add show output for 'debug zebra nexthop [detail]'
category.

Signed-off-by: Mark Stapp <mjs@voltanet.io>

Merge pull request #5708 from donaldsharp/nexthop_encoding_73

[7.3]lib: Fix nexthop encoding

lib: Fix nexthop encoding

Commit
68a02e06e5f103048d947262c08c569056f74d1c broke nexthop encoding
for nexthop tracking.

This code combined the different types of nexthop encoding
being done in the zapi protocol.  What was missed that
resolved nexthops of type NEXTHOP_TYPE_IPV4|6 have an ifindex
value that was not being reported.  This commit ensures
that we always send this data( even if it is 0).

The following test commit will ensure that this stays working
as is expected by an upper level protocol.

Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>

Merge pull request #5690 from ton31337/fix/addpath_adj_out_look_compare_id_7.3

bgpd: [7.3] add addpath ID to adj_out tree sort

Merge pull request #5688 from sworleys/dev-7.3-NHG-Fixes

[7.3] NHG Crash/Resolution Fixes

bgpd: add addpath ID to adj_out tree sort

When withdrawing addpaths, adj_lookup was called to find the path that
needed to be withdrawn. It would lookup in the RB tree based on subgroup
pointer alone, often find the path with the wrong addpath ID, and return
null.  Only the path highest in the tree sent to the subgroup could be
found, thus withdrawn.

Adding the addpath ID to the sort criteria for the RB tree allows us to
simplify the logic for adj_lookup, and address this problem. We are able
to remove the logic around non-addpath subgroups because the addpath ID
is consistently 0 for non-addpath adj_outs, so special logic to skip
matching the addpath ID isn't required.  (As a side note, addpath will
also never use ID 0, so there won't be any ambiguity when looking at the
structure content.)

Signed-off-by: Mitchell Skiba <mskiba@amazon.com>

zebra: can't improve efficiency for recursive depends

cb86eba3ab3d82f540bdb9ed5f65d361ca301ea8 was causing zebra to crash
when handling a nexthop group that had a nexthop which was recursively resolved.

Steps to recreate:

!
nexthop-group red
 nexthop 1.1.1.1
 nexthop 1.1.1.2
!

sharp install routes 8.8.8.1 nexthop-group red 1

=========================================
==11898== Invalid write of size 8
==11898==    at 0x48E53B4: _nexthop_add_sorted (nexthop_group.c:254)
==11898==    by 0x48E5336: nexthop_group_add_sorted (nexthop_group.c:296)
==11898==    by 0x453593: handle_recursive_depend (zebra_nhg.c:481)
==11898==    by 0x451CA8: zebra_nhg_find (zebra_nhg.c:572)
==11898==    by 0x4530FB: zebra_nhg_find_nexthop (zebra_nhg.c:597)
==11898==    by 0x4536B4: depends_find (zebra_nhg.c:1065)
==11898==    by 0x453526: depends_find_add (zebra_nhg.c:1087)
==11898==    by 0x451C4D: zebra_nhg_find (zebra_nhg.c:567)
==11898==    by 0x4519DE: zebra_nhg_rib_find (zebra_nhg.c:1126)
==11898==    by 0x452268: nexthop_active_update (zebra_nhg.c:1729)
==11898==    by 0x461517: rib_process (zebra_rib.c:1049)
==11898==    by 0x4610C8: process_subq_route (zebra_rib.c:1967)
==11898==  Address 0x0 is not stack'd, malloc'd or (recently) free'd

Zebra crashes because we weren't handling the case of the depend nexthop
being recursive.

For this case, we cannot make the function more efficient. A nexthop
could resolve to a group of any size, thus we need allocs/frees.

To solve this and retain the goal of the original patch, we separate out the
two cases so it will still be more efficient if the nexthop is not recursive.

Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
(cherry picked from commit 0fff714efa1959f48c8e1d88e88968d15c1ffe78)

zebra: just set nexthop member in handle_recursive_depend()

With recent changes to the lib nexthop_group
APIs (e1f3a8eb193267da195088cc515b598ae5a92a12), we are making
new assumptions that this should be adding a single nexthop
to a group, not a list of nexthops.

This broke the case of a recursive nexthop resolving to a group:

```
D>  2.2.2.1/32 [150/0] via 1.1.1.1 (recursive), 00:00:09
  *                      via 1.1.1.1, dummy1 onlink, 00:00:09
                       via 1.1.1.2 (recursive), 00:00:09
  *                      via 1.1.1.2, dummy2 onlink, 00:00:09
D>  3.3.3.1/32 [150/0] via 2.2.2.1 (recursive), 00:00:04
  *                      via 1.1.1.1, dummy1 onlink, 00:00:04
K * 10.0.0.0/8 [0/1] via 172.27.227.148, tun0, 00:00:21
```

This group can instead just directly point to the nh that was passed.
Its only being used for a lookup (the memory gets copied and used
elsewhere if the nexthop is not found).

Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
(cherry picked from commit 1d049aba721bb05ecf2f8b5978d96863330093b6)

Merge pull request #5684 from opensourcerouting/7.3/manpage-rename

[7.3] doc: manpage rename

ospfclient: don't install man page

... we're not installing ospfclient (it's a demo/example program), so
installing the man page is quite useless.

Signed-off-by: David Lamparter <equinox@diac24.net>

doc: rename man pages to frr-*

The vrrpd one conflicts with the standalone vrrpd package; also we're
installing daemons to /usr/lib/frr on some systems so they're not on
PATH.

Signed-off-by: David Lamparter <equinox@diac24.net>

Merge pull request #5683 from donaldsharp/bfd_msg_7.3

[7.3]zebra: bfd message handling cleanup foo

zebra: bfd message handling cleanup foo

Previous patches introduced various issues:
- Removal of stream_free() to fix double free caused memleak
- Patch for memleak was incomplete

This should fix it hopefully.

Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>

Merge pull request #5663 from donaldsharp/nhg_topotests_fixes

Nhg topotests fixes

Merge pull request #5662 from qlyoung/fix-ptm-bfd-deregister-memleak

zebra: fix bfd deregister message memleak