Current code implementation does not have a "no" form of handling for
the following commands under segment-routing srv6
- no formats
- no locators
- no prefix <> under locator XYZ
Fix the handling of segment-routing srv6 locators and formats commands
- Ignore "no formats" and "no locators" command
- replace "no prefix" under locator XYZ as "no locator XYZ" as prefix
is a mandatory property of locator
Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.com>
Adding a `-N` pathspace option to the generate_support_bundle.py
to support FRR running in a non-default namespace with a prefix
on the config/socket options.
The same pathspace will be prepended to the output log files (if
specified)
Signed-off-by: Martin Winter <mwinter@opensourcerouting.org>
The 'acceptedPrefixCounter' is available in 'show bgp neighbor json', but
there is no equivalent when using the non json output. Add it.
> # show bgp neighbor
> [..]
> Community attribute sent to this neighbor(all)
> 0 accepted prefixes, 1 sent prefixes
Fixes: 856ca177c4 ("Added json formating support to show-...-neighbors-... bgp commands.")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The existing iteration callback only allows for a daemon to return a
pointer to objects that must already exist and must continue to exists
indefinitely.
To allow the daemon to return allocated iterator objects and for locking
it's container structures we need a callback to tell the daemon when FRR
is done using the returned value, so the daemon can free it (or unlock
etc)
That's what list_entry_done() is for.
Signed-off-by: Christian Hopps <chopps@labn.net>
This fix add tests to verify routes/path are getting
deleted properly, when the advertising neighbor is shutdown
Signed-off-by: Soumya Roy <souroy@nvidia.com>
Issue:
In a scaled setup, (where number of nets > BGP_CLEARING_BATCH_MAX_DESTS
for walk_batch_table_helper), when peer is shutdown, it is seen some
of the paths are not deleted, which are received from that peer.
Fix:
This is due to, in clear_batch_rib_helper, once walk_batch_table_helper
returns after BGP_CLEARING_BATCH_MAX_DESTS is reached, we just break
from inner loop for the afi/safi for loops. So during walk for next
afi/safi that 'ret' state is overwritten with new state. Also the
resume context is overwritten. This causes to lose the start point
for next walk, some nets are skipped forever. So they are not marked
for deletion anymore. To fix this, we immediately return from current
run. This will have resume state to be stored correctly, and next walk
will start from there.
Testing:
32 ecmp paths were received from the shutdown peer
Before fix:
show bgp ipv6 2052:52:1:167::/64
BGP routing table entry for 2052:52:1:167::/64, version 495
Paths: (246 available, best #127, table default)
Not advertised to any peer
<snip>
4200165500 4200165002
2021:21:51:101::2(spine-5) from spine-5(2021:21:51:101::2) (6.0.0.17)
(fe80::202:ff:fe00:55) (prefer-global)
Origin incomplete, valid, external, multipath
Last update: Fri Apr 4 17:25:05 2025
4200165500 4200165002
2021:21:11:116::2(spine-1) from spine-1(2021:21:11:116::2) (0.0.0.0)
(fe80::202:ff:fe00:3d) (prefer-global)<<<<path not deleted
Origin incomplete, valid, external
Last update: Fri Apr 4 17:25:05 2025
4200165500 4200165002
2021:21:11:115::2(spine-1) from spine-1(2021:21:11:115::2) (0.0.0.0)
(fe80::202:ff:fe00:3d) (prefer-global)<<<<path not deleted
Origin incomplete, valid, external
Last update: Fri Apr 4 17:25:05 2025
<snip>
32 paths are supposed to be withdrawn:
root@leaf-1:mgmt:# vtysh -c "show bgp ipv6 2052:52:1:167::/64" | grep "prefer-global" | wc -l
256
root@leaf-1:mgmt# vtysh -c "show bgp ipv6 2052:52:1:167::/64" | grep "prefer-global" | wc -l
246<<should be 224, but showing 246, which is wrong
After fix:
32 paths are supposed to be withdrawn:
root@leaf-1:mgmt:# vtysh -c "show bgp ipv6 2052:52:1:167::/64" | grep "prefer-global" | wc -l
256
root@leaf-1:mgmt:# vtysh -c "show bgp ipv6 2052:52:1:167::/64" | grep "prefer-global" | wc -l
224<<<shows correctly
Signed-off-by: Soumya Roy <souroy@nvidia.com>
Indirect leak of 56 byte(s) in 1 object(s) allocated from:
0 0x7fdaf6cb83b7 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:77
1 0x7fdaf683a480 in qcalloc lib/memory.c:106
2 0x7fdaf68dd706 in route_table_init_with_delegate lib/table.c:38
3 0x5649b22c05b0 in bgp_table_init bgpd/bgp_table.c:139
4 0x5649b2273da0 in bgp_static_set bgpd/bgp_route.c:7779
5 0x5649b21eba58 in vpnv4_network bgpd/bgp_mplsvpn.c:3244
6 0x7fdaf67b6d61 in cmd_execute_command_real lib/command.c:1003
7 0x7fdaf67b7080 in cmd_execute_command lib/command.c:1062
8 0x7fdaf67b75ac in cmd_execute lib/command.c:1228
9 0x7fdaf68ffb20 in vty_command lib/vty.c:626
10 0x7fdaf6900073 in vty_execute lib/vty.c:1389
11 0x7fdaf6903e24 in vtysh_read lib/vty.c:2408
12 0x7fdaf68f0222 in event_call lib/event.c:2019
13 0x7fdaf681b3c6 in frr_run lib/libfrr.c:1247
14 0x5649b211c903 in main bgpd/bgp_main.c:565
15 0x7fdaf630c249 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
Table was being created but never deleted. Let's delete it.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Having just completed a code audit during RCA, the fact that we have 2
different argument orders for the related datastore copying functions
was unnecessary and super confusing.
Fix this code-maintenance/comprehension mistake and move the newer mgmtd
copy routines to use the same arg order as the pre-existing underlying
northbound copy functions (i.e., use `copy(dst, src)`)
Signed-off-by: Christian Hopps <chopps@labn.net>
Clean up compiler warnings; convert a linklist macro
to an inline to resolve one; clean up a side-effect in isisd.
Signed-off-by: Mark Stapp <mjs@cisco.com>
The `_once` loop variable will result in a `-Wshadow` warning when that
is turned on. Use `__COUNTER__` to give these variables distinct names,
like is already done with `_mtx_`.
(and because I touched it, clang-format wants it reformatted... ohwell.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
This commit fixes two types of problems:
a) Avoidance of cleaning up memory when a instance is
hidden, thus causing it never to be freed on shutdown
b) In some instances bgp_create is called 2 times
for some code. We are double allocating memory
and dropping it on the second allocation.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
