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>
Implement a callback function for memory cleanup of sharp_nh_tracker.
Specifically, set `sharp_nh_tracker_free` as the deletion function for the `sg.nhs` list.
This ensures proper cleanup of resources when elements are removed.
The ASan leak log for reference:
```
***********************************************************************************
Address Sanitizer Error detected in zebra_nht_resolution.test_verify_nh_resolution/r1.asan.sharpd.32320
=================================================================
==32320==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 64 byte(s) in 1 object(s) allocated from:
#0 0x7f4ee812ad28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7f4ee7b291cc in qcalloc lib/memory.c:105
#2 0x5582be672011 in sharp_nh_tracker_get sharpd/sharp_nht.c:36
#3 0x5582be680b42 in watch_nexthop_v4_magic sharpd/sharp_vty.c:139
#4 0x5582be680b42 in watch_nexthop_v4 sharpd/sharp_vty_clippy.c:192
#5 0x7f4ee7aac0b1 in cmd_execute_command_real lib/command.c:978
#6 0x7f4ee7aac575 in cmd_execute_command lib/command.c:1036
#7 0x7f4ee7aac9f4 in cmd_execute lib/command.c:1203
#8 0x7f4ee7bd50bb in vty_command lib/vty.c:594
#9 0x7f4ee7bd5566 in vty_execute lib/vty.c:1357
#10 0x7f4ee7bdde37 in vtysh_read lib/vty.c:2365
#11 0x7f4ee7bc8dfa in event_call lib/event.c:1965
#12 0x7f4ee7b0c3bf in frr_run lib/libfrr.c:1214
#13 0x5582be671252 in main sharpd/sharp_main.c:188
#14 0x7f4ee6f1bc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
SUMMARY: AddressSanitizer: 64 byte(s) leaked in 1 allocation(s).
***********************************************************************************
```
Signed-off-by: Keelan Cannoo <keelan.cannoo@icloud.com>
At this point add abilty for the encode/decode of the
resilience down ZAPI to zebra. Just hookup sharpd
at this point in time.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
This patch just introduces the callback mechanism for the
resilient nexthop changes so that upper level daemons
can take advantage of the change. This does nothing
at this point but just call some code.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Back when I put this together in 2015, ISO C11 was still reasonably new
and we couldn't require it just yet. Without ISO C11, there is no
"good" way (only bad hacks) to require a semicolon after a macro that
ends with a function definition. And if you added one anyway, you'd get
"spurious semicolon" warnings on some compilers...
With C11, `_Static_assert()` at the end of a macro will make it so that
the semicolon is properly required, consumed, and not warned about.
Consistently requiring semicolons after "file-level" macros matches
Linux kernel coding style and helps some editors against mis-syntax'ing
these macros.
Signed-off-by: David Lamparter <equinox@diac24.net>
If you have two nexthop groups named
one
oneone
then the sharp daemon will treat them as the same nexthop
group. This is because we are doign this:
static int sharp_nhg_compare_func(const struct sharp_nhg *a,
const struct sharp_nhg *b)
{
return strncmp(a->name, b->name, strlen(a->name));
}
The strlen should be the size of the array of name.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Add the zapi code for encoding/decoding of backup nexthops for when
we are ready for it, but disable it for now so that we revert
to the old way with them.
When zebra gets a proto-NHG with a backup in it, we early fail and
tell the upper level proto. In this case sharpd. Sharpd then reverts
to the old way of installation with the route.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Implement handling of NHG notifications in sharpd so that
the routes don't attempt to use an NHG ID that did not
successfully get created. If it does not get installed, we
fall back to traditional zapi messaging.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Add a command `set installable` that allows configured nexthop
groups to be treated as separate/installable objects in the RIB.
A callback needs to be implemented per daemon to handle installing
the NHG into the rib via zapi when this command is set. This
patch includes the implementation for sharpd.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
We were incrementing in the output the ID value when we
shouldnt be. The value the NHG is assigned is before its
incremented.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Modify the sharpd program to have the ability to pass down
a NHG and then operate on it for route installation.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
