Donald Sharp [Sun, 23 Mar 2025 21:48:02 +0000 (17:48 -0400)]
tests: high_ecmp creates 2 update groups
The high_ecmp test was creating 2 update groups, where
513 of the neighbors are in 1 and the remaining is in
another. They should just all be in 1 update group.
Modify the test creation such that interfaces r1-eth514
and r2-eth514 have v4 and v6 addresses.
Signed-off-by: Donald Sharp <donaldsharp72@gmail.com>
Donald Sharp [Fri, 21 Mar 2025 22:08:25 +0000 (18:08 -0400)]
tests: Change up start order of bmp tests
Currently the tests appear to do this:
a) Start the neighbors
b) Start the bmp server connection
c) Look for the neighbors up
d) Look for the neighbor up messages in the bmp log
This is not great from a testing perspective in that
even though we started a) first it may not happen
until after b) happens. Or even worse if it is
partially up ( 1 of the 2 peers ) then the dump
will have the neighbor connecting after parts
of the table. This doesn't work too well because
the SEQ number is something that is kept and compared
to to make sure only new data is being looked at.
Let's modify the startup configuration to start
the bmp server first and then have a delayopen
on the bgp neighbor statements so that the bmp
peering can come up first.
Soumya Roy [Fri, 14 Mar 2025 22:01:51 +0000 (22:01 +0000)]
zebra: reduce memory usage by streams when redistributing routes
This commit undo 8c9b007a0c7efb2e9afc2eac936ba9dd971c6707
stream lib has been modified to expand the stream if needed
Now for zapi route encode, we use expandable stream
Soumya Roy [Fri, 14 Mar 2025 21:56:48 +0000 (21:56 +0000)]
zebra: zebra crash for zapi stream
Issue:
If static route is created with a BGP route as nexthop, which
recursively resolves over 512 ECMP v6 nexthops, zapi nexthop encode
fails, as there is not enough memory allocated for stream. This causes
assert/core dump in zebra. Right now we allocate fixed memory
of ZEBRA_MAX_PACKET_SIZ size.
Fix:
1)Dynamically calculate required memory size for the stream
2)try to optimize memory usage
Testing:
No crash happens anymore with the fix
zebra: zebra crash for zapi stream
Issue:
If static route is created with a BGP route as nexthop, which
recursively resolves over 512 ECMP v6 nexthops, zapi nexthop encode
fails, as there is not enough memory allocated for stream. This causes
assert/core dump in zebra. Right now we allocate fixed memory
of ZEBRA_MAX_PACKET_SIZ size.
Fix:
1)Dynamically calculate required memory size for the stream
2)try to optimize memory usage
Testing:
No crash happens anymore with the fix
r1#
r1# sharp install routes 2100:cafe:: nexthop 2001:db8::1 1000
r1#
Soumya Roy [Fri, 14 Mar 2025 21:44:39 +0000 (21:44 +0000)]
lib: Add support for stream buffer to expand
Issue:
Currently, during encode time, if required memory is
more than available space in stream buffer, stream buffer
can't be expanded. This fix introduces new apis to support
stream buffer expansion.
Testing:
Tested with zebra nexthop encoding with 512 nexthops, which triggers
this new code changes, it works fine. Without fix, for same trigger
it asserts.
Tuetuopay [Mon, 17 Mar 2025 14:08:15 +0000 (15:08 +0100)]
bgpd: fix evpn attributes being dropped on input
All assignments of the EVPN attributes (ESI and Gateway IP) are gated
behind the peer being set up for inbound soft-reconfiguration.
There are no actual reasons for this limitation, so let's perform the
EVPN attribute assignment no matter what when soft reconfiguration is
not enabled.
Fixes: 6e076ba5231 ("bgpd: Fix for ain->attr corruption during path update") Signed-off-by: Tuetuopay <tuetuopay@me.com>
Donald Sharp [Wed, 19 Mar 2025 20:50:11 +0000 (16:50 -0400)]
bgpd: Fix leaked memory when showing some bgp routes
The two memory leaks:
==387155== 744 (48 direct, 696 indirect) bytes in 1 blocks are definitely lost in loss record 222 of 262
==387155== at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==387155== by 0x4C1B982: json_object_new_object (in /usr/lib/x86_64-linux-gnu/libjson-c.so.5.1.0)
==387155== by 0x2E4146: peer_adj_routes (bgp_route.c:15245)
==387155== by 0x2E4F1A: show_ip_bgp_instance_neighbor_advertised_route_magic (bgp_route.c:15549)
==387155== by 0x2B982B: show_ip_bgp_instance_neighbor_advertised_route (bgp_route_clippy.c:722)
==387155== by 0x4915E6F: cmd_execute_command_real (command.c:1003)
==387155== by 0x4915FE8: cmd_execute_command (command.c:1062)
==387155== by 0x4916598: cmd_execute (command.c:1228)
==387155== by 0x49EB858: vty_command (vty.c:626)
==387155== by 0x49ED77C: vty_execute (vty.c:1389)
==387155== by 0x49EFFA7: vtysh_read (vty.c:2408)
==387155== by 0x49E4156: event_call (event.c:2019)
==387155== by 0x4958ABD: frr_run (libfrr.c:1247)
==387155== by 0x206A68: main (bgp_main.c:557)
==387155==
==387155== 2,976 (192 direct, 2,784 indirect) bytes in 4 blocks are definitely lost in loss record 240 of 262
==387155== at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==387155== by 0x4C1B982: json_object_new_object (in /usr/lib/x86_64-linux-gnu/libjson-c.so.5.1.0)
==387155== by 0x2E45CA: peer_adj_routes (bgp_route.c:15325)
==387155== by 0x2E4F1A: show_ip_bgp_instance_neighbor_advertised_route_magic (bgp_route.c:15549)
==387155== by 0x2B982B: show_ip_bgp_instance_neighbor_advertised_route (bgp_route_clippy.c:722)
==387155== by 0x4915E6F: cmd_execute_command_real (command.c:1003)
==387155== by 0x4915FE8: cmd_execute_command (command.c:1062)
==387155== by 0x4916598: cmd_execute (command.c:1228)
==387155== by 0x49EB858: vty_command (vty.c:626)
==387155== by 0x49ED77C: vty_execute (vty.c:1389)
==387155== by 0x49EFFA7: vtysh_read (vty.c:2408)
==387155== by 0x49E4156: event_call (event.c:2019)
==387155== by 0x4958ABD: frr_run (libfrr.c:1247)
==387155== by 0x206A68: main (bgp_main.c:557)
For the 1st one, if the operator issues a advertised-routes command, the
json_ar variable was never being freed.
For the 2nd one, if the operator issued a command where the
output_count_per_rd is 0, we need to free the json_routes value.
Donald Sharp [Wed, 19 Mar 2025 19:20:31 +0000 (15:20 -0400)]
tests: Ensure that the daemon has connected to zebra
On daemon startup, ensure that the daemon is there and
connected to zebra. There are some exceptions,
pathd is srte. pim6d and pimd are the same at the
moment and finally smnptrapd.
This should help the startup of using a unified
config in the topotests.
Donald Sharp [Wed, 19 Mar 2025 16:22:04 +0000 (12:22 -0400)]
zebra: Allow fpm_listener to reject all routes
Now usage of `-r -f` with fpm_listener now causes all
routes to be rejected.
r1# sharp install routes 10.0.0.0 nexthop 192.168.44.5 5
r1# show ip route
Codes: K - kernel route, C - connected, L - local, S - static,
R - RIP, O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
F - PBR, f - OpenFabric, t - Table-Direct,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure
IPv4 unicast VRF default:
D>o 10.0.0.0/32 [150/0] via 192.168.44.5, r1-eth0, weight 1, 00:00:02
D>o 10.0.0.1/32 [150/0] via 192.168.44.5, r1-eth0, weight 1, 00:00:02
D>o 10.0.0.2/32 [150/0] via 192.168.44.5, r1-eth0, weight 1, 00:00:02
D>o 10.0.0.3/32 [150/0] via 192.168.44.5, r1-eth0, weight 1, 00:00:02
D>o 10.0.0.4/32 [150/0] via 192.168.44.5, r1-eth0, weight 1, 00:00:02
C>* 192.168.44.0/24 is directly connected, r1-eth0, weight 1, 00:00:37
L>* 192.168.44.1/32 is directly connected, r1-eth0, weight 1, 00:00:37
r1#
Nathan Bahr [Wed, 19 Mar 2025 16:07:37 +0000 (16:07 +0000)]
lib: Create VRF if needed
When creating a control plane protocol through NB, create the vrf
if needed instead of only looking up and asserting if it doesn't
exist yet.
Fixes 18429.
Martin Winter [Wed, 19 Mar 2025 12:40:53 +0000 (13:40 +0100)]
redhat: Make sure zeromq is always disabled
Fix issue where zeromq is getting enabled if build system has the libs
installed. For RPMs, we want it always based on intended config options.
(and currently the zeromq is not part of the packages)
Signed-off-by: Martin Winter <mwinter@opensourcerouting.org>
Martin Winter [Wed, 19 Mar 2025 06:21:37 +0000 (07:21 +0100)]
redhat: Make docs and rpki optional for RPM package build
Adding options to disable docs and rpki during the build. By
default they are always built. RPKI sub-package will not be built
(and not available) if built without the RPKI support.
Signed-off-by: Martin Winter <mwinter@opensourcerouting.org>
Rajasekar Raja [Tue, 11 Mar 2025 19:15:32 +0000 (12:15 -0700)]
zebra: Fix reinstalling nexthops in NHGs upon interface flaps
Trigger:
Imagine a route utilizing an NHG with six nexthops (Intf swp1-swp6).
If interfaces swp1-swp4 flaps, the NHG remains the same but now only
references two nexthops (swp5-6) instead of all six. This behavior
occurs due to how NHGs with recursive nexthops are managed within Zebra.
In the scenario below, NHG 370 has all six nexthops installed in the
kernel. However, Zebra maintains a list of recursive NHGs that NHG 370
references i.e., Depends: (371), (372), (373) which are not directly
installed in the kernel.
- When an interface comes up, its nexthop and corresponding dependents
are installed.
- These dependents (counterparts to 371-373) are non-recursive and
are installed as well.
- However, when attempting to install the recursive ones in
zebra_nhg_install_kernel(), they resolve to the already installed
counterparts, resulting in a NO-OP.
Fixing this by iterating all dependents of the recursively resolved
NHGs and reinstalling them.
Trigger: Flap swp1 to swp4
Before Fix:
root@leaf-11:mgmt:/var/home/cumulus# ip route show | grep 6.0.0.5
6.0.0.5 nhid 370 proto bgp metric 20
ip -d next show
id 337 via 2000:1:0:1:0:f:0:9 dev swp6 scope link proto zebra
id 339 via 2000:1:0:1:0:e:0:9 dev swp5 scope link proto zebra
id 341 via 2000:1:0:1:0:8:0:8 dev swp4 scope link proto zebra
id 343 via 2000:1:0:1:0:7:0:8 dev swp3 scope link proto zebra
id 346 via 2000:1:0:1:0:1:0:7 dev swp2 scope link proto zebra
id 348 via 2000:1:0:1::7 dev swp1 scope link proto zebra
id 370 group 346/348/341/343/337/339 scope global proto zebra
After Trigger:
root@leaf-11:mgmt:/var/home/cumulus# ip route show | grep 6.0.0.5
6.0.0.5 nhid 370 proto bgp metric 20
root@leaf-11:mgmt:/var/home/cumulus# ip -d next show
id 337 via 2000:1:0:1:0:f:0:9 dev swp6 scope link proto zebra
id 339 via 2000:1:0:1:0:e:0:9 dev swp5 scope link proto zebra
id 370 group 337/339 scope global proto zebra
After Fix:
root@leaf-11:mgmt:/var/home/cumulus# ip route show | grep 6.0.0.5
6.0.0.5 nhid 432 proto bgp metric 20
ip -d next show
id 432 group 395/397/400/402/405/407 scope global proto zebra
After Trigger
root@leaf-11:mgmt:/var/home/cumulus# ip route show | grep 6.0.0.5
6.0.0.5 nhid 432 proto bgp metric 20
root@leaf-11:mgmt:/var/home/cumulus# ip -d next show
id 432 group 395/397/400/402/405/407 scope global proto zebra
Ticket :#
Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.com> Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Loïc Sang [Tue, 18 Mar 2025 16:39:03 +0000 (17:39 +0100)]
bgpd: fix "delete in progress" flag on default instance
Since 4d0e7a4 ("bgpd: VRF-Lite fix default BGP delete"), upon deletion
of the default instance, it is marked as hidden and the "deletion
in progress" flag is set. When the instance is restored, some routes
are not installed due to the presence of this flag.
Tuetuopay [Fri, 14 Mar 2025 19:21:53 +0000 (20:21 +0100)]
tests: add route-map evpn set gateway-ip topotest
This test does not actually look at the route since the gateway-ip is
not exposed in vtysh output. However, this ensures such a route-map does
not crash bgpd.
Shbinging [Tue, 18 Mar 2025 02:35:16 +0000 (10:35 +0800)]
babled: set wired/wireless internal only when wired/wireless status changes
As stated in doc, interface's attributes such noninterfering/interfering are reset when the wired/wireless status of an interface is changed. If wired/wireless status is not changed, such as wired->wired, we should not reset internal attributes.
Donatas Abraitis [Thu, 27 Feb 2025 14:08:21 +0000 (16:08 +0200)]
bgpd: Do not keep stale paths in Adj-RIB-Out if not addpath aware
```
munet> r1 shi vtysh -c 'show ip bgp update advertised-routes'
update group 1, subgroup 1
BGP table version is 5, local router ID is 192.168.137.1
Status codes: s suppressed, d damped, h history, u unsorted, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0/24 192.168.137.201 10 0 65200 65444 i
*> 10.0.0.0/24 192.168.137.100 10 0 65100 65444 65444 i
*> 10.65.10.0/24 192.168.137.100 0 10 0 65100 i
*> 10.200.2.0/24 192.168.137.202 0 10 0 65200 i
```
Announce one more 10.0.0.0/24 via 65200 and we have TWO paths 10.0.0.0/24 in adj-rib-out:
```
munet> r1 shi vtysh -c 'show ip bgp update advertised-routes'
update group 1, subgroup 1
BGP table version is 6, local router ID is 192.168.137.1
Status codes: s suppressed, d damped, h history, u unsorted, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0/24 192.168.137.201 10 0 65200 65444 i
*> 10.0.0.0/24 192.168.137.100 10 0 65100 65444 65444 i
*> 10.0.0.0/24 192.168.137.201 10 0 65200 65444 i
*> 10.65.10.0/24 192.168.137.100 0 10 0 65100 i
*> 10.200.2.0/24 192.168.137.202 0 10 0 65200 i
```
Stop announcing 10.0.0.0/24 via 65200 and we still have TWO paths for 10.0.0.0/24...
```
munet> r1 shi vtysh -c 'show ip bgp update advertised-routes'
update group 1, subgroup 1
BGP table version is 7, local router ID is 192.168.137.1
Status codes: s suppressed, d damped, h history, u unsorted, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0/24 192.168.137.201 10 0 65200 65444 i
*> 10.0.0.0/24 192.168.137.100 10 0 65100 65444 65444 i
*> 10.0.0.0/24 192.168.137.201 10 0 65200 65444 i
*> 10.65.10.0/24 192.168.137.100 0 10 0 65100 i
*> 10.200.2.0/24 192.168.137.202 0 10 0 65200 i
```
Why do we need to keep old paths in adj-rib-out if we don't have e.g. AddPaths enabled?
Shouldn't it be like here? (only one 10.0.0.0/24 in adj-rib-out for this update-group instead of multiple (stale from previous announcements))
```
munet> r1 shi vtysh -c 'show ip bgp update advertised-routes'
update group 1, subgroup 1
BGP table version is 6, local router ID is 192.168.137.1
Status codes: s suppressed, d damped, h history, u unsorted, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0/24 192.168.137.201 10 0 65200 65444 i
*> 10.0.0.0/24 192.168.137.201 10 0 65200 65444 i
*> 10.65.10.0/24 192.168.137.100 0 10 0 65100 i
*> 10.200.2.0/24 192.168.137.202 0 10 0 65200 i
```
Tuetuopay [Fri, 14 Mar 2025 19:21:46 +0000 (20:21 +0100)]
bgpd: fix `set evpn gateway-ip ipv[46]` route-map
The `route_set_evpn_gateway_ip` function copies `gw_ip->ip.addr` in the
route's gateway ip. In a nutshell, this skips the `ipa_type` field,
writing the actual IP in the IP type. This later rightfully trips
asserts about unknown IP types.
The following route-map...
```
route-map test permit 10
set evpn gateway-ip ipv4 1.1.1.1
```
...will make the following gateway IP in the route:
Dmytro Shytyi [Mon, 10 Mar 2025 13:59:34 +0000 (14:59 +0100)]
bgpd: align peer_unconfigure with gracefull-restart
When configured Graceful-Restart, skipping unconfig notification,
similarly as it is done in 95098d9611e79d43b578400bb76dc7a76aa8cab9
("bgpd: Do not send Deconfig/Shutdown message when restarting")
bgpd: fix radv interface disabled when bgp instance removed
If a peer uses radv for an interface, and bgp instance is removed,
then the radv service is not disabled on the interface.
Fix this by doing the same at BGP unconfiguration. Like it has been
done when a peer is unconfigured, call the radv unregistration before
deleting the peer.
Fixes: b3a3290e2303 ("bgpd: turn off RAs when numbered peers are deleted") Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com> Signed-off-by: Dmytro Shytyi <dmytro.shytyi@6wind.com>
echken [Mon, 17 Mar 2025 03:43:19 +0000 (03:43 +0000)]
fix(vrrp): display vrrp version by default
Make the VRRP version information always visible in the running
configuration output, regardless of whether it's the default value
(version 3) or not.
When using frr-reload.py to apply configuration changes, VRRP instances
were being unnecessarily reinitialized even when no actual configuration
changes were made. This occurred because:
The cli_show_vrrp function in vrrpd/vrrp_vty.c does not display the VRRP
version in the show running-config output when it's the default value
(version 3).
Configuration files often explicitly specify vrrp X version 3 even
though it's the default.
When frr-reload.py compares the explicit configuration with the running
configuration, it detects a difference and generates commands to remove
and recreate the VRRP instance.
This patch modifies the cli_show_vrrp function to unconditionally
display the VRRP version, regardless of whether it's the default value
or the show_defaults parameter is set. By making the version information
explicit in all cases, we ensure consistent configuration comparison in
frr-reload.py, preventing unnecessary VRRP reinitialization and
associated network disruptions.
Christian Hopps [Sat, 15 Mar 2025 04:09:29 +0000 (04:09 +0000)]
tests: deal with configure overridden timestamp prec in unit test
Previously if you configured a different timestamp precision then
`make check` would fail as the non-default config is generated and
fails test_cli config file comparison.
Donald Sharp [Fri, 14 Mar 2025 18:50:59 +0000 (14:50 -0400)]
bgpd: Remove unnecessary stream_new/stream_copies in bgp_open_make
The call into bgp_open_capability can return that it wrote more
than BGP_OPEN_NON_EXT_OPT_LEN bytes, in that case the open
part needs to be written again with ext_opt_params set to
true to allow extended parameters to be written thus keeping
the len < 255 bytes. The code to do this was first creating
a new stream and then copying into it the stream, trying
to call bgp_open_capability() and if it succeeded recopying
the tmp stream back onto the original.
Let's change this around such that we save the current spot
in the stream of where we are writing and if the change does
not work reset the pointer and try again with the correct
parameter. This removes the stream and multiple copies and
eventual free of the temporary stream.
Acee Lindem [Fri, 14 Mar 2025 16:02:28 +0000 (16:02 +0000)]
ospf6d: Disable and delete OSPFv3 areas that no longer have interfaces or configuration.
This fix will delete an OSPFv3 area when all the interfaces and
configuration (ranges, NSSA ranges, stub area, NSSA area, filter-list,
import-list and export-list) have been removed. The changes provides
a general solution to https://github.com/FRRouting/frr/issues/18324.
Manpreet Kaur [Thu, 13 Mar 2025 11:14:24 +0000 (04:14 -0700)]
bgpd: Fixed crash upon bgp network import-check command
BT:
```
3 <signal handler called>
4 0x00005616837546fc in bgp_static_update (bgp=bgp@entry=0x5616865eac50, p=0x561686639e40,
bgp_static=0x561686639f50, afi=afi@entry=AFI_IP6, safi=safi@entry=SAFI_UNICAST) at ../bgpd/bgp_route.c:7232
5 0x0000561683754ad0 in bgp_static_add (bgp=0x5616865eac50) at ../bgpd/bgp_table.h:413
6 0x0000561683785e2e in no_bgp_network_import_check (self=<optimized out>, vty=0x5616865e04c0,
argc=<optimized out>, argv=<optimized out>) at ../bgpd/bgp_vty.c:4609
7 0x00007fdbcc294820 in cmd_execute_command_real (vline=vline@entry=0x561686663000,
```
The program encountered a SEG FAULT when attempting to access pi->extra->vrfleak->bgp_orig because
pi->extra->vrfleak was NULL.
```
(gdb) p pi->extra->vrfleak
$1 = (struct bgp_path_info_extra_vrfleak *) 0x0
(gdb) p pi->extra->vrfleak->bgp_orig
Cannot access memory at address 0x8
```
Added NOT NULL check on pi->extra->vrfleak before accessing pi->extra->vrfleak->bgp_orig
to prevent the segmentation fault.
Donald Sharp [Thu, 13 Mar 2025 19:19:02 +0000 (15:19 -0400)]
bgpd: Show bgp <afi> <safi> shouldn't display peers in groups
The command `show bgp <afi> <safi>` has this output:
r1# show bgp ipv4 uni 10.0.0.0
BGP routing table entry for 10.0.0.0/32, version 1
Paths: (1 available, best #1, table default)
Advertised to non peer-group peers:
r1-eth0 r1-eth1 r1-eth2 r1-eth3
....
It specifically states `Advertised to non peer-group peers:` yet
the code is not filtering those out.
Gabriel Goller [Thu, 13 Mar 2025 11:11:34 +0000 (12:11 +0100)]
isisd: fix bit flag collision in options field
Resolve conflict between F_ISIS_UNIT_TEST and ISIS_OPT_DUMMY_AS_LOOPBACK
which were both using the same bit value (0x01). This collision caused
unit test mode to be unintentionally enabled when DUMMY_AS_LOOPBACK was set.
Signed-off-by: Gabriel Goller <g.goller@proxmox.com>
This commit is being reverted because of several issues:
a) tcpdump -i <any interface that bgp happens to use>
This command causes bgp to dump it's entire table to all
of it's peers again. This is a huge problem in any type
of scaled environment *and* it is not unusual to have an
operator do this.
b) This commit appears to be attempting to solve the problem
with route leaking across vrf's using labels( or somesuch ).
Unfortunately we have absolutely no topotests that show the
behavior. I am also unable to get any type of how to reproduce
the problem being solved by the commit. I do know, though,
that the problem really stems from the fact that bgp has
decided to cheat and not create bnc's for route leaking.
Thus when a nexthop changes, bgp is not being notified.
This commit was being used as a hammer to solve the problem.
While I do agree backing out a bug fix for some operator
is less then ideal, I believe that since I cannot get the
operator to tell me the problem it solved and the fact
that sending large amounts of updates with just a simple
tcpdump command ( actually 2 one for tcpdump start and
one for finishing ) is more detrimental in my eyes at
this point in time. Additionally the solution used
is the wrong one for the problem.
Donald Sharp [Wed, 12 Mar 2025 12:30:43 +0000 (08:30 -0400)]
staticd: Install known nexthops upon connection with zebra
CI tests are showing cases where staticd is connecting to
zebra after config is read in and the nexthops are never
being registered w/ zebra:
2025/03/11 15:39:44 STATIC: [T83RR-8SM5G] staticd 10.4-dev starting: vty@2616
2025/03/11 15:39:45 STATIC: [GH3PB-C7X4Y] Static Route to 13.13.13.13/32 not installed currently because dependent config not fully available
2025/03/11 15:39:45 STATIC: [RHJK1-M5FAR] static_zebra_nht_register: Failure to send nexthop 1.1.1.2/32 for 11.11.11.11/32 to zebra
2025/03/11 15:39:45 STATIC: [M7Q4P-46WDR] vty[14]@> enable
Zebra shows connection time as:
2025/03/11 15:39:45.933343 ZEBRA: [V98V0-MTWPF] client 5 says hello and bids fair to announce only static routes vrf=0
As a result staticd never installs the route because it has no nexthop
tracking to say that the route could be installed.
Modify staticd on startup to go through it's nexthops and dump them to
zebra to allow the staticd state machine to get to work.
Session flapping isn't tested which led to queuing / order issues
in the past. This adds a second path between R1 and R2, after that
both paths are flapped and the presence of the routerMac is checked
Signed-off-by: Christopher Dziomba <christopher.dziomba@telekom.de>
Issue:
Not freeing the neighbor n within the same function can lead to
memory leak.
zebra_neigh_del_all() -> zebra_neigh_del() re lookup and free
Fix: not accessing n after its freed.
Directly free the neighbor entry (n) when its interface index matches
ifp->ifindex.
This fixes:
ERROR: AddressSanitizer: heap-use-after-free on address 0x6070001052e8 at pc 0x7f6bf7d09ddb bp 0x7ffd3366a000 sp 0x7ffd33669ff0
READ of size 8 at 0x6070001052e8 thread T0
#0 0x7f6bf7d09dda in _rb_next lib/openbsd-tree.c:455
#1 0x55f95a307261 in zebra_neigh_rb_head_RB_NEXT zebra/zebra_neigh.h:34
#2 0x55f95a3082e9 in zebra_neigh_del_all zebra/zebra_neigh.c:162
#3 0x55f95a121ee7 in zebra_interface_down_update zebra/redistribute.c:571
#4 0x55f95a0f819d in if_down zebra/interface.c:1017
#5 0x55f95a0fe168 in zebra_if_dplane_ifp_handling zebra/interface.c:2102
#6 0x55f95a0ff10c in zebra_if_dplane_result zebra/interface.c:2241
#7 0x55f95a27ce9c in rib_process_dplane_results zebra/zebra_rib.c:5015
#8 0x7f6bf7da3ad9 in event_call lib/event.c:1984
#9 0x7f6bf7c62141 in frr_run lib/libfrr.c:1246
#10 0x55f95a11ca7f in main zebra/main.c:543
#11 0x7f6bf7029d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
#12 0x7f6bf7029e3f in __libc_start_main_impl ../csu/libc-start.c:392
#13 0x55f95a0dd0b4 in _start (/usr/lib/frr/zebra+0x1a80b4)
projects / matthieu / frr.git / log