Donald Sharp [Wed, 8 May 2024 16:52:12 +0000 (12:52 -0400)]
zebra: Ensure multipath encodes vxlan right for fpm usage
The fpm code path for the dplane_fpm_nl module was improperly
encoding the multipath nexthop data for vxlan type routes.
Move this into the embedded nexthop encoding where it belongs.
This change makes it so that the usage of `-M dplane_fpm_nl`
is now producing the same netlink messages that `-M fpm`
produces when using vxlan based nexthops.
Direct leak of 592 byte(s) in 2 object(s) allocated from:
#0 0xfeb98b28a4b4 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0xfeb98ae572f8 in qcalloc lib/memory.c:105
#2 0xfeb98ae76138 in srv6_locator_chunk_alloc lib/srv6.c:138
#3 0xb7f3c8508fa0 in ensure_vrf_tovpn_sid_per_vrf bgpd/bgp_mplsvpn.c:831
#4 0xb7f3c8509494 in ensure_vrf_tovpn_sid bgpd/bgp_mplsvpn.c:866
#5 0xb7f3c85028a8 in vpn_leak_postchange bgpd/bgp_mplsvpn.h:289
#6 0xb7f3c851a7c0 in vpn_leak_postchange_all bgpd/bgp_mplsvpn.c:3769
#7 0xb7f3c86f6ef0 in bgp_zebra_process_srv6_locator_chunk bgpd/bgp_zebra.c:3378
#8 0xfeb98afa6e14 in zclient_read lib/zclient.c:4608
#9 0xfeb98af3d684 in event_call lib/event.c:2011
#10 0xfeb98ae2788c in frr_run lib/libfrr.c:1217
#11 0xb7f3c83cbf0c in main bgpd/bgp_main.c:545
#12 0xfeb98a8973f8 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
#13 0xfeb98a8974c8 in __libc_start_main_impl ../csu/libc-start.c:392
#14 0xb7f3c83c832c in _start (/usr/lib/frr/bgpd+0x2d832c)
Direct leak of 32 byte(s) in 2 object(s) allocated from:
#0 0xfeb98b28a4b4 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0xfeb98ae572f8 in qcalloc lib/memory.c:105
#2 0xb7f3c8508fd8 in ensure_vrf_tovpn_sid_per_vrf bgpd/bgp_mplsvpn.c:832
#3 0xb7f3c8509494 in ensure_vrf_tovpn_sid bgpd/bgp_mplsvpn.c:866
#4 0xb7f3c85028a8 in vpn_leak_postchange bgpd/bgp_mplsvpn.h:289
#5 0xb7f3c851a7c0 in vpn_leak_postchange_all bgpd/bgp_mplsvpn.c:3769
#6 0xb7f3c86f6ef0 in bgp_zebra_process_srv6_locator_chunk bgpd/bgp_zebra.c:3378
#7 0xfeb98afa6e14 in zclient_read lib/zclient.c:4608
#8 0xfeb98af3d684 in event_call lib/event.c:2011
#9 0xfeb98ae2788c in frr_run lib/libfrr.c:1217
#10 0xb7f3c83cbf0c in main bgpd/bgp_main.c:545
#11 0xfeb98a8973f8 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
#12 0xfeb98a8974c8 in __libc_start_main_impl ../csu/libc-start.c:392
#13 0xb7f3c83c832c in _start (/usr/lib/frr/bgpd+0x2d832c)
Direct leak of 32 byte(s) in 2 object(s) allocated from:
#0 0xfeb98b28a4b4 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0xfeb98ae572f8 in qcalloc lib/memory.c:105
#2 0xb7f3c8506520 in vpn_leak_zebra_vrf_sid_update_per_vrf bgpd/bgp_mplsvpn.c:439
#3 0xb7f3c85068d8 in vpn_leak_zebra_vrf_sid_update bgpd/bgp_mplsvpn.c:459
#4 0xb7f3c86f6aec in bgp_ifp_create bgpd/bgp_zebra.c:3345
#5 0xfeb98adfd3f8 in hook_call_if_real lib/if.c:48
#6 0xfeb98adfe750 in if_new_via_zapi lib/if.c:181
#7 0xfeb98af98084 in zclient_interface_add lib/zclient.c:2592
#8 0xfeb98afa6d24 in zclient_read lib/zclient.c:4606
#9 0xfeb98af3d684 in event_call lib/event.c:2011
#10 0xfeb98ae2788c in frr_run lib/libfrr.c:1217
#11 0xb7f3c83cbf0c in main bgpd/bgp_main.c:545
#12 0xfeb98a8973f8 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
#13 0xfeb98a8974c8 in __libc_start_main_impl ../csu/libc-start.c:392
#14 0xb7f3c83c832c in _start (/usr/lib/frr/bgpd+0x2d832c)
SUMMARY: AddressSanitizer: 656 byte(s) leaked in 6 allocation(s).
David Lamparter [Wed, 8 May 2024 19:47:14 +0000 (21:47 +0200)]
build: make clang-format ignore DEFUN/DEFPY
This makes clang-format not wreck all our hand-formatted DEFUN/DEFPY
statements. We apparently missed this option when we originally looked
at setting up the .clang-format control file...
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
David Lamparter [Mon, 12 Dec 2022 16:50:59 +0000 (17:50 +0100)]
pimd: fix order of operations for evaluating join
join_desired looks at whether up->channel_oil is empty. up->channel_oil
is updated from pim_forward_stop(), calling pim_channel_del_oif(). But
that was being called *after* updating join_desired, so join_desired saw
a non-empty OIL. Pull up the pim_forward_stop() call to before updating
join_desired.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
David Lamparter [Mon, 17 Apr 2023 09:47:08 +0000 (11:47 +0200)]
pimd: fix null register before aging out reg-stop
It looks like the code was trying to do this with the null_register
parameter on pim_upstream_start_register_stop_timer(), but that didn't
quite work right. Restructure a bit to get it right.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Christian Hopps [Tue, 7 May 2024 02:40:27 +0000 (02:40 +0000)]
mgmtd: some cleanup from original RPC commit
- Fix memleak on multiple errstr returns (multiple clients) Allow the
- multiple clients to all return results and merge them (as with other
operations like get tree).
Christian Hopps [Tue, 7 May 2024 02:37:52 +0000 (02:37 +0000)]
mgmtd: rpc and action handling both should use rpc map.
The previous idea of using config xpath registrations for actions b/c
the config is the subject of the action is sub-optimal. It splits
handling of YANG "actions" (Action and RPCs) between 2 different
registartion maps for the same category of functionality.
Loïc Sang [Mon, 6 May 2024 15:30:01 +0000 (17:30 +0200)]
if: fix same connected address
Using the same address with a different prefix length is not supported.
If we configure two identical addresses with different
netmasks 192.168.1.1/30 and then 192.168.1.1/29. Zebra sends
'192.168.1.1' with a prefix length of 29. However, the function
'zebra_interface_address_read()' reads '192.168.1.1/30' because the
prefix length is not checked.
Alexander Rose [Thu, 11 Apr 2024 11:07:33 +0000 (13:07 +0200)]
ospf6d: Redistribute metric for AS-external route
When ospf6d originates an AS-external route that has been read from a kernel
routing table, then the metric of that route was ignored until now.
If a routemap is configured, then this metric will be redistributed from
now on.
Using metric increment and decrement in routemaps is supported by ospf6d now.
Signed-off-by: Alexander Rose <alexander.rose@secunet.com>
When BGP receives an SRV6_LOCATOR_ADD message from zebra, it calls the
`bgp_zebra_process_srv6_locator_add()` function to process the message.
`bgp_zebra_process_srv6_locator_add()` decodes the message first, and
then if the pointer to the default BGP instance is NULL (i.e. the
default BGP instance is not configured yet), it returns early without
doing anything and without using the decoded message information.
This commit fixes the order of the operations executed by
`bgp_zebra_process_srv6_locator_add()`. We first ensure that the default
BGP instance is ready and we return early if it is not. Then, we decode
the message and do something with the information contained in it.
Chirag Shah [Fri, 2 Feb 2024 20:11:58 +0000 (12:11 -0800)]
bgpd: [GR] fix mode change vtysh return code
When a bgp neighbor graceful-restart config mode change
is applied, after accepting the config if it does not
take effect instead of throwing vtysh error code,
return the success to vtysh and warn the user.
The debug log is already present at critical code point
where GR failure is seen during config apply.
Chirag Shah [Fri, 3 May 2024 03:58:50 +0000 (20:58 -0700)]
zebra: fix EVPN svd based remote nh neigh del
In the context of SVD (Single VxLAN Device) for L3VNI,
the remote VTEP's nexthop is programmed neighbor entry against
SVD along with neighbor entry against SVI.
However, when L3VNI is removed or the VRF is disabled, all SVI
based remote nexthop neighbors are uninstalled and deleted.
The SVD based neigh entries remains in Zebra and the Kernel.
Subsequently, when reconfiguring L3VNI and relearning the same nexthop,
the neighbor entry is not programmed is because it is not removed
from Zebra SVD neighbor hash table, leading to the failure to
reprogram the entry.
With this fix, the SVD nexthop neigh entry is uninstalled
and deleted from Zebra and Kernel.
borderleaf:# ip neigh show 2.2.2.2
2.2.2.2 dev vlan2560_l3 lladdr 00:01:00:00:1d:09 extern_learn NOARP proto zebra
2.2.2.2 dev vxlan99 lladdr 00:01:00:00:1d:09 extern_learn NOARP proto zebra
With the fix:
Zebra log shows both enties SVD (vxlan99) and SVI (vlan2560_l3)
neighbor entries are deleted.
2024/05/03 18:41:33.527125 ZEBRA: [NH6N7-54CD1] Tx RTM_DELNEIGH family
ipv4 IF vxlan99(16) Neigh 2.2.2.2 MAC null flags 0x10 state 0x0
ext_flags 0x0
2024/05/03 18:41:33.527128 ZEBRA: [NH6N7-54CD1] Tx RTM_DELNEIGH family
ipv4 IF vlan2560_l3(18) Neigh 2.2.2.2 MAC null flags 0x10 state 0x0
ext_flags 0x0
Chirag Shah [Fri, 22 Mar 2024 20:25:18 +0000 (13:25 -0700)]
zebra: bridge flap handle vlan membership update
Upon bridge flap, the associated SVD case,
VLAN membership is not updated correctly.
When SVI comes up, the VNI could not associate
with it as bridge VLAN membership was not updated.
David Lamparter [Tue, 30 Apr 2024 11:51:38 +0000 (13:51 +0200)]
build: get rid of "unrecognized … anon-tag"
GCC only errors out on unrecognized _positive_ `-Wsomething` flags,
negative ones it ignores... but then prints a "note" about whenever an
unrelated(!) warning/error occurs. This is both annoying and confusing,
since we now get a lot of:
```
cc1: note: unrecognized command-line option ‘-Wno-microsoft-anon-tag’ may have been intended to silence earlier diagnostics
```
Fix by checking for the positive flag in `AC_C_FLAG` instead, which will
error out, and therefore `-Wno-microsoft-anon-tag` won't be added for
GCC. (It only exists on clang.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Martin Buck [Mon, 22 Apr 2024 11:01:22 +0000 (13:01 +0200)]
tests: Modify inter-area ECMP topotest to also test redundant ABRs
So far, this test only convered redundant paths to one ABR, now it checks
redundant paths to redundant ABRs, covering both cases. Useful as a
regression test for #15777.
Signed-off-by: Martin Buck <mb-tmp-tvguho.pbz@gromit.dyndns.org>
Martin Buck [Mon, 22 Apr 2024 15:13:23 +0000 (17:13 +0200)]
ospf6d: Fix nexthop computation for inter-area multi-ABR ECMP
Pre-b74e965, we always merged nexthops of old (existing) and new (newly
generated, based on a LSA update) routes, making it impossible to remove
individual nexthops from a route. b74e965 replaced this by copying nexthops
from the new route to the old route. This works as long as the old and new
route are derived from the same LSA (e.g. multiple ECMP paths to the same
ABR). However, in case of multiple parallel ABRs, each of them originates a
LSA and the nexthops derived from them need to be combined to get the proper
route nexthops. So instead of trying to incrementally update the route
nexthops based on the old and new route nexthops, always recompute the route
nexthops by merging all of its path nexthops (which we're already updating
based on the LSA being processed).
Fixes #15777.
Signed-off-by: Martin Buck <mb-tmp-tvguho.pbz@gromit.dyndns.org>
David Lamparter [Thu, 2 May 2024 09:00:17 +0000 (11:00 +0200)]
build: hppa is weird
hppa (yes, HP PA-RISC) apparently creates relocations that refer to
".init+0x12345" for everything, referencing way past the end of the
.init section. While this is only fallback code hit when XREF_SETUP()
is missing (i.e. the FRRouting.XREF ELF note is absent), try to make it
work anyway.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
David Lamparter [Thu, 2 May 2024 08:57:31 +0000 (10:57 +0200)]
build: warn/fail on missing `XREF_SETUP()`
While clippy tries really, really hard to work under adverse conditions,
and this catches missing XREF_SETUP() on almost all CPU architectures,
this doesn't quite work on hppa. So, make it a warning on *all*
platforms (or error for --enable-dev-build) in order to catch it before
shipping off to Debian's buildd and blowing up there...
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
David Lamparter [Thu, 2 May 2024 08:55:11 +0000 (10:55 +0200)]
*: add XREF_SETUP() to libraries and utilites
This is theoretically not needed if neither DEFUNs nor zlog_* calls are
used, except I'm about to turn it into a build error to catch the cases
where it _is_ necessary. Which is libmgmt_be_nb.la in this case, where
it causes build failures on hppa.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
David Lamparter [Tue, 30 Apr 2024 12:13:22 +0000 (14:13 +0200)]
tools/gcc-plugins: warn for `suseconds_t` format
The plugin was already catching attempts to print `time_t` without
casting it first (there is no valid printf specifier without a cast),
but `__suseconds64_t` needs the same treatment. (Probably
`__suseconds_t` too, if it exists, which I'm not sure it does - but that
doesn't matter, the plugin ignores non-existing types.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
David Lamparter [Tue, 30 Apr 2024 12:18:03 +0000 (14:18 +0200)]
lib: fix `time_t` print without cast
The gcc plugin wasn't warning about printing `suseconds_t` (which is
`time_t`, but in `struct timeval`.) It needs to be printed with a cast,
just like `time_t`. Luckily there is only one such usage.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
David Lamparter [Thu, 2 May 2024 20:07:24 +0000 (22:07 +0200)]
build: exclude deprecated decls from -Werror
Other parts of the system can change (e.g. libc-ares), making things
deprecated, and then our build fails for no reason inside FRR. This
shouldn't be an error.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
With the commit `605df8d4`, all real things are moved into dplane.
So the operations mentioned in this comment have nothing to do with
this function `netlink_link_change()`.
Donald Sharp [Tue, 30 Apr 2024 14:53:48 +0000 (10:53 -0400)]
zebra: Ensure proper decoding of netlink message
As part of the kernel netlink functionality, it is
possible that a bit of nested attributes can be
passed up. This attribute has a type value which
is stored in the lower 8 bits and in the upper 8
bits are a couple control flags that can be used.
FRR can parse this data and then just throw away
the value unless we mask off the upper 8 bits.
Let's ensure that it can be properly parsed.
projects / matthieu / frr.git / log