Rajasekar Raja [Fri, 17 May 2024 19:36:31 +0000 (12:36 -0700)]
bgpd: backpressure - Fix to withdraw evpn type-5 routes immediately
As part of backpressure changes, there is a bug where immediate withdraw
is to be sent for evpn imported type-5 prefix to clear the nh neigh and
RMAC entry.
Fixing this by sending withdraw immediately to keep it inline with the
code today
EasyNetDev [Mon, 13 May 2024 14:30:45 +0000 (17:30 +0300)]
zebra: Update Zebra for DPDK >=22.11 API
* Starting from version DPDK 22.11 we have API changes:
The rte_driver and rte_device objects are now opaque and must be manipulated through added accessors.
We need to update Zebra DPDK sources to DPDK version >=22.11
Christian Hopps [Wed, 15 May 2024 03:36:38 +0000 (23:36 -0400)]
tests: improve the grpc query client and topotest
- Add separate get, get-config, get-state operations to query command, as
well as switching default output to JSON.
- Add an `--xml` to change the output format.
- move printss to logging.debug so output is a machine parseable result.
Mark Stapp [Tue, 14 May 2024 14:28:17 +0000 (10:28 -0400)]
zebra: include route source set by route-map in show output
Include the prefix source address when set by a route-map in
show output for routes, in various formats.
Add some debugs when encoding netlink route messages with
a source address.
Philippe Guibert [Tue, 14 May 2024 09:51:50 +0000 (11:51 +0200)]
bgpd: fix colored routes not installed after a switchover
On a multihomed setup with colored bgp updates, when the primary
PE goes offline, only a small subset of colored bgp routes are
not switching to the secondary pe.
When a switchover happens, due to a remote IP becoming unreachable,
some nexthop tracking down notifications are sent, but those messages
are completely ignored for colored bgp updates.
The original code has been thought for mounting up the SR-TE service,
when IP reachability is ok, but not when services goes offline.
Fix this by extending the down notification mechanism for colored routes
too.
Fixes: 545aeef1d13e ("bgpd: extend the NHT code to understand SR-TE colors") Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
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>
projects / mirror / frr.git / log