After removing the nexthop of a nexthop group, when the nexthop group
is removed, a nhg removal failure happens:
> ubuntu2204(config)# nexthop-group CCC
> ubuntu2204(config-nh-group)# nexthop 192.0.2.211 loop1
> ubuntu2204(config-nh-group)# no nexthop 192.0.2.211 loop1
> [..]
> 2023/12/05 08:59:22 SHARP: [H3QKG-WH8ZV] Removed nhg 179687505
> ubuntu2204(config-nh-group)# exi
> ubuntu2204(config)# no nexthop-group CCC
> [..]
> 2023/12/05 08:59:27 SHARP: [N030J-V0SFN] Failed removal of nhg 179687505
The NHG_DEL message is sent twice at the nexthop deletion, and at the
nexthop-group deletion. Avoid sending it twice.
Fixes: 82beaf6ae5 ("sharpd: fix deleting nhid when suppressing nexthop from nh group")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When no nexthops are in a nexthop group, two successive events are
sent: NHG_DEL and NHG_ADD, but only the NHG_DEL one is necessary.
Fixes this by returning in the nhg_add() function.
Fixes: 82beaf6ae5 ("sharpd: fix deleting nhid when suppressing nexthop from nh group")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
FRR's RPM package requires protobuf-c to be installed on the runtime
system, otherwise it will refuse to be installed.
Signed-off-by: Juan Vidal Allende <juan.vidal1@ibm.com>
There is no support for dumping multiple paths for the same prefix.
The current implementation only takes the first available entry.
Fix this by walking over the list of available paths, ordered by peer.
The nlri index is set gradually for each path.
Signed-off-by: Francois Dumontet <francois.dumontet@6wind.com>
The following message appears after starting pathd:
> root@ubuntu2204:~# vtysh
> 2023/10/31 05:59:10 [K2CCG-5Y7ZJ] Excessive docstring while parsing 'msd (1-32)'
> 2023/10/31 05:59:10 [W7ENN-K2SVA] ----------
> 2023/10/31 05:59:10 [WCW75-6TZPF] PCC maximum SID depth value
> 2023/10/31 05:59:10 [W7ENN-K2SVA] ----------
Remove the excessive doc string in the pcep msd command.
Fixes: d6d2527448 ("pathd: fix 'no msd' command not possible under pcc node")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When monitoring a static route with BFD multi-hop, the source IP can be
either configured or retrieved from NextHop-Tracking (NHT). After
removing a configured source, the source is supposed to be retrieved
from NHT but it remains to the previous value. This is problematic if
the user desires to fix the configuration of a incorrect source IP.
For example, theses two commands results in the incorrect state:
> ip route 10.0.0.0/24 10.1.0.1 bfd multi-hop source 10.2.2.2
> ip route 10.0.0.0/24 10.1.0.1 bfd multi-hop
When removing the source, BFD is unable to find the source from NHT via
bfd_nht_update() were called.
Force zebra to resend the information to BFD by unregistering and
registering again NHT. The (...)/frr-nexthops/nexthop northbound
apply_finish function will trigger a call to static_install_nexthop()
that does a call to static_zebra_nht_register(nh, true);
Fixes: b7ca809d1c ("lib: BFD automatic source selection")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
The ospfd cleanup code is relatively complicated given the need to
appropriately handle the "max-metric router-lsa on-shutdown (5-100)"
command. When that command is configured and an OSPF instance is
unconfigured, the removal of the instance should be deferred to allow
other routers sufficient time to find alternate paths before the
local Router-LSAs are flushed. When ospfd is killed, however, deferred
shutdown shouldn't take place and all instances should be cleared
immediately.
This commit fixes a problem where ospf_deferred_shutdown_finish()
was prematurely exiting the daemon when no instances were left,
inadvertently preventing ospf_terminate() from clearing the ospfd
global variables. Additionally, the commit includes code refactoring
to enhance readability and maintainability.
Fixes#14855.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
* On ospf_terminate(), proceed to clear the ospfd global variables even
when no OSPF instance is configured
* Remove double call to route_map_finish()
* Call ospf_opaque_term() to clear the opaque LSA infrastructure
* Clear the `OspfRI.area_info` and `om->ospf` global lists.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
This is already handled above, no need to do here, because we could have an
overrun situation where len > 64 and we do out-of-bound actions.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
When stopping a VRF, the linked list entries must be
removed too.
Fixes: 98cbbaea91 ("lib: Handle if up/down and vrf enable/disable events")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The nexthop_group_active_nexthop_num_no_recurse() function is no more
used. Let us remove the function call.
Fixes: 148813c22a ("zebra: zebra_nhg check each nexthop for active, not just number")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When allocating big protocol level identifiers, the number range is
big, and when pushing to netlink messages, the first nexthop group
is truncated, whereas the nexthop has been installed on the kernel.
> ubuntu2204(config)# nexthop-group A
> ubuntu2204(config-nh-group)# group 1
> ubuntu2204(config-nh-group)# group 2
> ubuntu2204(config-nh-group)# exi
> ubuntu2204(config)# nexthop-group 1
> ubuntu2204(config-nh-group)# nexthop 192.0.2.130 loop1 enable-proto-nhg-control
> ubuntu2204(config-nh-group)# exi
> ubuntu2204(config)# nexthop-group 2
> ubuntu2204(config-nh-group)# nexthop 192.0.2.131 loop1 enable-proto-nhg-control
> [..]
> 2023/11/24 16:47:40 ZEBRA: [VNMVB-91G3G] _netlink_nexthop_build_group: ID (179687500): group 17968/179687502
> # ip nexthop ls
> id 179687500 group 179687501/179687502 proto 194
Fix this by increasing the buffer size when appending the first number.
Fixes: 8d03bc501b ("zebra: Handle nhg_hash_entry encaps/more debugging")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Add three counters that account for the nhg operations
that are using the zebra API with the NHG_ADD and NHG_DEL
commands.
> # show zebra client
> [..]
> Type Add Update Del
> ==================================================
> IPv4 100 0 0
> IPv6 0 0 0
> Redist:v4 0 0 0
> Redist:v6 0 0 0
> NHG 1 1 1
> VRF 3 0 0
> [..]
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The candidate yang tree should be validated before `nb_config_diff` is
called. `nb_config_diff` ignores all prohibited operations and can
provide an empty change list because of this. For example, if a user
deletes a mandatory node from the candidate datastore and tries to make
a commit, they'll receive the "No changes found to be committed!" error,
because such a change is ignored by `nb_config_diff`. Instead, mgmtd
should tell the user that their candidate datastore is not valid and
can't be commited.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
If there happens to be a entry in the zebra rib
that has a lower admin distance then a newly received
re, zebra would not notify the upper level protocol
about this happening. Imagine a case where there
is a connected route for say a /32 and bgp receives
a route from a peer that is the same route as the
connected. Since BGP has no network statement and
perceives the route as being `good` bgp will install
the route into zebra. Zebra will look at the new
bgp re and correctly identify that the re is not
something that it will use and do nothing. This
change notices this and sends up a BETTER_ADMIN_WON
route notification.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Implement proper memory cleanup for SRv6 functions and locator chunks to prevent potential memory leaks.
The list callback deletion functions have been set.
The ASan leak log for reference:
```
***********************************************************************************
Address Sanitizer Error detected in bgp_srv6l3vpn_to_bgp_vrf.test_bgp_srv6l3vpn_to_bgp_vrf/r2.asan.bgpd.4180
=================================================================
==4180==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 544 byte(s) in 2 object(s) allocated from:
#0 0x7f8d176a0d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7f8d1709f238 in qcalloc lib/memory.c:105
#2 0x55d5dba6ee75 in sid_register bgpd/bgp_mplsvpn.c:591
#3 0x55d5dba6ee75 in alloc_new_sid bgpd/bgp_mplsvpn.c:712
#4 0x55d5dba6f3ce in ensure_vrf_tovpn_sid_per_af bgpd/bgp_mplsvpn.c:758
#5 0x55d5dba6fb94 in ensure_vrf_tovpn_sid bgpd/bgp_mplsvpn.c:849
#6 0x55d5dba7f975 in vpn_leak_postchange bgpd/bgp_mplsvpn.h:299
#7 0x55d5dba7f975 in vpn_leak_postchange_all bgpd/bgp_mplsvpn.c:3704
#8 0x55d5dbbb6c66 in bgp_zebra_process_srv6_locator_chunk bgpd/bgp_zebra.c:3164
#9 0x7f8d1716f08a in zclient_read lib/zclient.c:4459
#10 0x7f8d1713f034 in event_call lib/event.c:1974
#11 0x7f8d1708242b in frr_run lib/libfrr.c:1214
#12 0x55d5db99d19d in main bgpd/bgp_main.c:510
#13 0x7f8d160c5c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Direct leak of 296 byte(s) in 1 object(s) allocated from:
#0 0x7f8d176a0d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7f8d1709f238 in qcalloc lib/memory.c:105
#2 0x7f8d170b1d5f in srv6_locator_chunk_alloc lib/srv6.c:135
#3 0x55d5dbbb6a19 in bgp_zebra_process_srv6_locator_chunk bgpd/bgp_zebra.c:3144
#4 0x7f8d1716f08a in zclient_read lib/zclient.c:4459
#5 0x7f8d1713f034 in event_call lib/event.c:1974
#6 0x7f8d1708242b in frr_run lib/libfrr.c:1214
#7 0x55d5db99d19d in main bgpd/bgp_main.c:510
#8 0x7f8d160c5c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
***********************************************************************************
```
Signed-off-by: Keelan Cannoo <keelan.cannoo@icloud.com>
Configure hash table cleanup with specific free functions for `zrouter.filter_hash`, `zrouter.qdisc_hash`, and `zrouter.class_hash`.
This ensures proper memory cleanup, addressing memory leaks.
The ASan leak log for reference:
```
***********************************************************************************
Address Sanitizer Error detected in tc_basic.test_tc_basic/r1.asan.zebra.15495
=================================================================
==15495==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 176 byte(s) in 1 object(s) allocated from:
#0 0x7fd5660ffd28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7fd565afe238 in qcalloc lib/memory.c:105
#2 0x5564521c6c9e in tc_filter_alloc_intern zebra/zebra_tc.c:389
#3 0x7fd565ac49e8 in hash_get lib/hash.c:147
#4 0x5564521c7c74 in zebra_tc_filter_add zebra/zebra_tc.c:409
#5 0x55645210755a in zread_tc_filter zebra/zapi_msg.c:3428
#6 0x5564521127c1 in zserv_handle_commands zebra/zapi_msg.c:4004
#7 0x5564522208b2 in zserv_process_messages zebra/zserv.c:520
#8 0x7fd565b9e034 in event_call lib/event.c:1974
#9 0x7fd565ae142b in frr_run lib/libfrr.c:1214
#10 0x5564520c14b1 in main zebra/main.c:492
#11 0x7fd564ec2c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Direct leak of 40 byte(s) in 1 object(s) allocated from:
#0 0x7fd5660ffd28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7fd565afe238 in qcalloc lib/memory.c:105
#2 0x5564521c6c6e in tc_class_alloc_intern zebra/zebra_tc.c:239
#3 0x7fd565ac49e8 in hash_get lib/hash.c:147
#4 0x5564521c784f in zebra_tc_class_add zebra/zebra_tc.c:293
#5 0x556452107ce5 in zread_tc_class zebra/zapi_msg.c:3315
#6 0x5564521127c1 in zserv_handle_commands zebra/zapi_msg.c:4004
#7 0x5564522208b2 in zserv_process_messages zebra/zserv.c:520
#8 0x7fd565b9e034 in event_call lib/event.c:1974
#9 0x7fd565ae142b in frr_run lib/libfrr.c:1214
#10 0x5564520c14b1 in main zebra/main.c:492
#11 0x7fd564ec2c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Direct leak of 12 byte(s) in 1 object(s) allocated from:
#0 0x7fd5660ffd28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7fd565afe238 in qcalloc lib/memory.c:105
#2 0x5564521c6c3e in tc_qdisc_alloc_intern zebra/zebra_tc.c:128
#3 0x7fd565ac49e8 in hash_get lib/hash.c:147
#4 0x5564521c753b in zebra_tc_qdisc_install zebra/zebra_tc.c:184
#5 0x556452108203 in zread_tc_qdisc zebra/zapi_msg.c:3286
#6 0x5564521127c1 in zserv_handle_commands zebra/zapi_msg.c:4004
#7 0x5564522208b2 in zserv_process_messages zebra/zserv.c:520
#8 0x7fd565b9e034 in event_call lib/event.c:1974
#9 0x7fd565ae142b in frr_run lib/libfrr.c:1214
#10 0x5564520c14b1 in main zebra/main.c:492
#11 0x7fd564ec2c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
SUMMARY: AddressSanitizer: 228 byte(s) leaked in 3 allocation(s).
***********************************************************************************
```
Signed-off-by: Keelan Cannoo <keelan.cannoo@icloud.com>
Release memory associated with `bgp->confed_peers` in the `bgp_free`
function to ensure proper cleanup. This fix prevents memory leaks related
to `confed_peers`.
The ASan leak log for reference:
```
***********************************************************************************
Address Sanitizer Error detected in bgp_confederation_astype.test_bgp_confederation_astype/r2.asan.bgpd.15045
=================================================================
==15045==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 16 byte(s) in 1 object(s) allocated from:
#0 0x7f5666787b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
#1 0x7f56661867c7 in qrealloc lib/memory.c:112
#2 0x55a3b4736a40 in bgp_confederation_peers_add bgpd/bgpd.c:681
#3 0x55a3b46b3363 in bgp_confederation_peers bgpd/bgp_vty.c:2068
#4 0x7f5666109021 in cmd_execute_command_real lib/command.c:978
#5 0x7f5666109a52 in cmd_execute_command_strict lib/command.c:1087
#6 0x7f5666109ab1 in command_config_read_one_line lib/command.c:1247
#7 0x7f5666109d98 in config_from_file lib/command.c:1300
#8 0x7f566623c6d0 in vty_read_file lib/vty.c:2614
#9 0x7f566623c7fa in vty_read_config lib/vty.c:2860
#10 0x7f56661682e4 in frr_config_read_in lib/libfrr.c:978
#11 0x7f5666226034 in event_call lib/event.c:1974
#12 0x7f566616942b in frr_run lib/libfrr.c:1214
#13 0x55a3b44f319d in main bgpd/bgp_main.c:510
#14 0x7f56651acc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Indirect leak of 6 byte(s) in 1 object(s) allocated from:
#0 0x7f5666720538 in strdup (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x77538)
#1 0x7f5666186898 in qstrdup lib/memory.c:117
#2 0x55a3b4736adb in bgp_confederation_peers_add bgpd/bgpd.c:687
#3 0x55a3b46b3363 in bgp_confederation_peers bgpd/bgp_vty.c:2068
#4 0x7f5666109021 in cmd_execute_command_real lib/command.c:978
#5 0x7f5666109a52 in cmd_execute_command_strict lib/command.c:1087
#6 0x7f5666109ab1 in command_config_read_one_line lib/command.c:1247
#7 0x7f5666109d98 in config_from_file lib/command.c:1300
#8 0x7f566623c6d0 in vty_read_file lib/vty.c:2614
#9 0x7f566623c7fa in vty_read_config lib/vty.c:2860
#10 0x7f56661682e4 in frr_config_read_in lib/libfrr.c:978
#11 0x7f5666226034 in event_call lib/event.c:1974
#12 0x7f566616942b in frr_run lib/libfrr.c:1214
#13 0x55a3b44f319d in main bgpd/bgp_main.c:510
#14 0x7f56651acc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
***********************************************************************************
```
Signed-off-by: Keelan Cannoo <keelan.cannoo@icloud.com>
