bgpd: Make sure network/aggregate-address commands lay down under labeled safi
unicast and labeled-unicast share the same table, but configuration should
be visible for both independently. Without this fix it confuses a bit
because when you enter `network 10.0.0.0/24` under labeled-unicast it's
written in unicast family block.
Donatas Abraitis [Mon, 25 May 2020 14:22:37 +0000 (17:22 +0300)]
bgpd: Use IPv6 LL address as nexthop if global was set to ::/LL
This happens between Bird and FRR. Maybe others as well, dunno.
Bird sends ::(fe80::1588) and we have a nexthop as :: which is inaccessible:
```
BGP routing table entry for fdff:b87d:f5b0::/48
Paths: (1 available, no best path)
Not advertised to any peer 4242421588424242254742424226014242423605
:: (inaccessible) from fe80::1588 (172.20.16.140)
(fe80::1588) (used)
Origin IGP, invalid, external
Last update: Mon May 25 14:27:02 2020
```
Quentin Young [Sun, 31 May 2020 08:10:33 +0000 (04:10 -0400)]
alpine: update packages
Alpine builds have been failing for some time as a consequence of only
installing python 2 development packages when we have build scripts that
require python 3.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
David Lamparter [Mon, 11 May 2020 19:37:08 +0000 (21:37 +0200)]
build: use configfile mode in init script
This only applies for split-config; the init script would create an
empty config file with default permissions.
Reported-by: Robert Scheck <robert@fedoraproject.org> Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
(cherry picked from commit 5c9063771195bb51a8cc1c64f9924e53a0602817)
Josh Cox [Tue, 5 May 2020 17:09:14 +0000 (13:09 -0400)]
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.
Stephen Worley [Fri, 1 May 2020 16:34:43 +0000 (12:34 -0400)]
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.
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.
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
Ruben Kerkhof [Sat, 7 Mar 2020 22:38:14 +0000 (23:38 +0100)]
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
Ruben Kerkhof [Sat, 7 Mar 2020 22:51:34 +0000 (23:51 +0100)]
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
Ruben Kerkhof [Sat, 7 Mar 2020 22:19:13 +0000 (23:19 +0100)]
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
Tomas Korbar [Thu, 20 Feb 2020 06:37:55 +0000 (07:37 +0100)]
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
Ruben Kerkhof [Sun, 8 Mar 2020 14:34:40 +0000 (15:34 +0100)]
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
Don Slice [Thu, 2 Apr 2020 20:17:33 +0000 (20:17 +0000)]
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.
Stephen Worley [Mon, 6 Jan 2020 18:33:45 +0000 (13:33 -0500)]
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
```
Stephen Worley [Mon, 6 Jan 2020 17:58:41 +0000 (12:58 -0500)]
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)
```
Stephen Worley [Tue, 28 Jan 2020 20:20:18 +0000 (15:20 -0500)]
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.
Stephen Worley [Tue, 28 Jan 2020 19:33:10 +0000 (14:33 -0500)]
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.
Stephen Worley [Tue, 28 Jan 2020 00:36:01 +0000 (19:36 -0500)]
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.
David Lamparter [Thu, 2 Apr 2020 19:16:04 +0000 (21:16 +0200)]
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)
Stephen Worley [Wed, 1 Apr 2020 19:31:40 +0000 (15:31 -0400)]
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
Martin Winter [Fri, 20 Mar 2020 22:50:29 +0000 (23:50 +0100)]
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>
Donald Sharp [Tue, 11 Feb 2020 00:25:52 +0000 (19:25 -0500)]
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
Martin Winter [Fri, 14 Feb 2020 14:03:09 +0000 (15:03 +0100)]
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>
Donald Sharp [Mon, 13 Jan 2020 21:11:46 +0000 (16:11 -0500)]
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>
Donald Sharp [Mon, 13 Jan 2020 21:00:33 +0000 (16:00 -0500)]
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>
Donald Sharp [Thu, 6 Feb 2020 02:02:25 +0000 (21:02 -0500)]
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>
Chirag Shah [Wed, 22 Jan 2020 20:22:27 +0000 (12:22 -0800)]
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>
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>
projects / mirror / frr.git / log