Similarly to recently fixed 'show ip[v6] prefix-list ...' - PR#15750,
json output is not valid for 'show ip[v6] access-list ... json' commands,
as it goes through all the running daemons and for each one it calls
'filter_show' creating a new json object. To aggreagate the output
and create a valid json that can later be parsed, the commands were
moved to vtysh and formatted accordingly
Philippe Guibert [Mon, 13 May 2024 15:42:30 +0000 (17:42 +0200)]
bgpd: fix colored nexthops resolution
When the SR-TE service is off, colored BGP routes are not
selected if it is recursively resolved over routes that are
colored only.
Actually, a BGP nexthop context includes the color attribute;
when an update from ZEBRA is received, there is no color, and
the colored BGP nexthop contexts are parsed, only if there
is a non colored BGP nexthop context. The actual setup shows
this may not be the case every time.
Fix this by parsing all the colored BGP nexthop contexts.
Fixes: b8210849b8ac ("bgpd: Make bgp ready to remove distinction between 2 nh tracking types") Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
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 Schweizer [Tue, 30 Apr 2024 08:15:40 +0000 (11:15 +0300)]
doc: user doc for route-flap dampening commands
Changes update the user documentation to include a description of the
now available commands to enable/disable route-flap dampening for peers
and peer groups.
Signed-off-by: David Schweizer <dschweizer@opensourcerouting.org> Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
bgpd: Pass the right reuse_list when handling it via bgp_reuse_timer thread
This fixes the crash:
```
==14759== Invalid read of size 8
==14759== at 0x31032B: bgp_reuselist_del (bgp_damp.c:51)
==14759== by 0x310392: bgp_damp_info_unclaim (bgp_damp.c:69)
==14759== by 0x310CD6: bgp_damp_info_free (bgp_damp.c:387)
==14759== by 0x311016: bgp_reuse_timer (bgp_damp.c:230)
==14759== by 0x4F227CC: thread_call (thread.c:2008)
==14759== by 0x4EDB7D7: frr_run (libfrr.c:1216)
==14759== by 0x1EF748: main (bgp_main.c:525)
==14759== Address 0x48 is not stack'd, malloc'd or (recently) free'd
==14759==
==14759==
==14759== Process terminating with default action of signal 11 (SIGSEGV)
==14759== at 0x59CC7F5: raise (raise.c:46)
==14759== by 0x4F10CEB: core_handler (sigevent.c:261)
==14759== by 0x59CC97F: ??? (in /lib/x86_64-linux-gnu/libpthread-2.27.so)
==14759== by 0x31032A: bgp_reuselist_del (bgp_damp.c:51)
==14759== by 0x310392: bgp_damp_info_unclaim (bgp_damp.c:69)
==14759== by 0x310CD6: bgp_damp_info_free (bgp_damp.c:387)
==14759== by 0x311016: bgp_reuse_timer (bgp_damp.c:230)
==14759== by 0x4F227CC: thread_call (thread.c:2008)
==14759== by 0x4EDB7D7: frr_run (libfrr.c:1216)
==14759== by 0x1EF748: main (bgp_main.c:525)
```
Igor Ryzhov [Wed, 28 Jul 2021 22:17:50 +0000 (01:17 +0300)]
bgpd: fix incorrect usage of slist in dampening
Current code is a complete misuse of SLIST structure. Instead of just
adding a SLIST_ENTRY to struct bgp_damp_info, it allocates a separate
structure to be a node in the list.
Igor Ryzhov [Thu, 29 Jul 2021 11:42:16 +0000 (14:42 +0300)]
bgpd: fix missing list add in dampening
One more crash in dampening code...
When bgp_damp_withdraw is called, if there's already a BDI structure,
bgp_damp_info_claim is called to re-assign the bdi->config in case it
was changed. The problem is that bgp_damp_info_claim actually removes
the BDI from the reuse list of the old config and never adds it to the
reuse list of the new config. We must do this to prevent the crash
because all the code assumes that BDI is always in some list.
bgpd: clear ip bgp dampening was not triggering the route calculation for the prefix
Description:
clear ip bgp dampening was not triggering the route
calculation for the prefix, Due to this prefix are not install in
RIB(Zebra) and not adv to neighbor
Problem Description/Summary :
clear ip bgp dampening was not triggering the route
calculation for the prefix, Due to this prefix are not install in
RIB(Zebra) and not adv to neighbor
Fix: When clear ip bgp dampening, route are put for route-calculation as
that it is install in the Zebra and adv to neighbor.
projects / mirror / frr.git / log