Document the newly added commands to limit the maximum amount of
groups/source to learn.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
For groups we can just look at the length of the list, for sources we
need to count them on a per-interface level.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
The bgp labelpool code is grabbing the vpn policy data structure.
This vpn_policy has a pointer to the bgp data structure. If
a item placed on the bgp label pool workqueue happens to sit
there for the microsecond or so and the operator issues a
`no router bgp...` command that corresponds to the vpn_policy
bgp pointer, when the workqueue is run it will crash because
the bgp pointer is now freed and something else owns it.
Modify the labelpool code to store the vrf id associated
with the request on the workqueue. When you wake up
if the vrf id still has a bgp pointer allow the request
to continue, else drop it.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When SRv6 is enabled and an SRv6 locator is specified in the BGP
configuration, BGP may attempt to request SRv6 locator information from
zebra before the connection is fully established. If this occurs, the
request fails with the following error:
```
2025/02/06 16:37:32 BGP: [HR66R-TWQYD][EC 100663302] srv6_manager_get_locator: invalid zclient socket
````
As a result, BGP is unable to obtain the locator information,
preventing SRv6 VPN from working.
This commit fixes the issue by ensuring BGP requests SRv6 locator
information once the connection with zebra is successfully established.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
The `static_srv6_sids` topotest verifies that staticd correctly
programs the SIDs in the zebra RIB. Currently, the topotest only
validates the programmed behavior and SID attributes.
This commit extends the topotest to also validate the SID structure.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
The `show ipv6 route json` command displays the IPv6 routing table in
JSON format, including SRv6 SIDs. For each SRv6 SID, it provides
behavior and SID attributes. However, it does not include the SID
structure.
This commit adds the SID structure to the SRv6 SID JSON output.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
The SRv6 support in staticd (PR #16894) does not set the correct SID
parameters (block length, node length, function length).
This commit fixes the issue and computes the correct parameters.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
Capability's length is 0 and this is not needed to check if it's multiplied by
X or there is a minimum length for that.
Fixes: db853cc97e ("bgpd: Implement Link-Local Next Hop capability")
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Blocking all signals on non-main threads is not the way to go, at least
the handlers for SIGSEGV, SIGBUS, SIGILL, SIGABRT and SIGFPE need to run
so we get backtraces. Otherwise the process just exits.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
In case interface address is learnt during configuration, make sure to
run DR election when configuring PIM/PIM passive on interface.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Issue:
If there are any changes to the prefix list, we perform a re-lookup to map the correct RP for the group.
Even if the S,G entry is PIM_UPSTREAM_NOTJOINED and in FHR, In the case of IGMPv3, an S,G entry can be
created with no joins. this is not necessary.
https://www.rfc-editor.org/rfc/rfc4601#section-4.5.7 says no op in case of NOTJOINED
Solution:
To solve this issue, Stop RP mapping when the state is NOTJOINED
Ticket: #3496931
Signed-off-by: Rajesh Varatharaj <rvaratharaj@nvidia.com>
Issue:
When there is no traffic for a group, the LHR and RP take the default KAT+Join timer expiry of
a maximum of 480 seconds to clear the S,G . However, in the FHR, we update the state from JOINED
to NOT Joined, downstream state from PPto NOINFO. This restarts the ET timer, causing S,G on FHR to
take more than 10 minutes to age out.
In other words,
Consider a case where (S,G) is in Join state. When the traffic stops and the KAT (210) expires,
the Join expiry timer restarts. At this time, if we receive a prune, the expectation is to set
PPT to 0 (RFC 4601 sec 4.5.2).
When the PPT expires, we move to the noinfo state and restart the expiry timer one more time. We remove the
(S,G) entry only after ~10 minutes when there is no active traffic.
Summary:
KAT Join ET 210 + PP ET 210 + NOINFO ET 210.
Solution:
Delete the ifchannel when in noinfo state, and KAT is not running.
Ticket: #13703
Signed-off-by: Rajesh Varatharaj <rvaratharaj@nvidia.com>
Use a memory allocation specific type for filter names (to help detect memory
leaks) and fix a memory leak when releasing peer memory.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
The seg6local route dumped by 'show ipv6 route' makes think that the USP
flavor is supported, whereas it is not the case. This information is a
context information, and for End, the context information should be
empty.
> # show ipv6 route
> [..]
> I>* fc00:0:4::/128 [115/0] is directly connected, sr0, seg6local End USP, weight 1, 00:49:01
Fix this by suppressing the USP information from the output.
Fixes: e496b42030 ("bgpd: prefix-sid srv6 l3vpn service tlv")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Our infrastructure was complaining about this:
2025/02/05 19:38:42 ISIS: [ZKB8W-3S2Q4][EC 100663330] unneeded 'modify' callback for '/frr-isisd:isis/instance/fast-reroute/level-1/lfa/tiebreaker/type'
2025/02/05 19:38:42 ISIS: [ZKB8W-3S2Q4][EC 100663330] unneeded 'modify' callback for '/frr-isisd:isis/instance/fast-reroute/level-2/lfa/tiebreaker/type'
Seems we don't need it. Let's just remove it.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Coverity is pointing out that bfd_key_delete is
passing by value instead of reference for a very
large structure. Double plus not good.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The function bfd_key_lookup is currently sending by value for
a now very large structure. Let's convert this over to pass
by reference. This is noticed by coverity.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
This leak is happening:
Direct leak of 96 byte(s) in 2 object(s) allocated from:
0 0x7f6922eb83b7 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:77
1 0x7f6922a38ebb in qcalloc lib/memory.c:106
2 0x7f6922a553d6 in nexthop_add_srv6_seg6 lib/nexthop.c:652
3 0x562825e56b38 in parse_nexthop_unicast zebra/rt_netlink.c:589
4 0x562825e58c4a in netlink_route_change_read_unicast_internal zebra/rt_netlink.c:1291
5 0x562825e58eef in netlink_route_change_read_unicast zebra/rt_netlink.c:1321
6 0x562825e64921 in netlink_route_change zebra/rt_netlink.c:1494
7 0x562825e43407 in netlink_information_fetch zebra/kernel_netlink.c:407
8 0x562825e439b5 in netlink_parse_info zebra/kernel_netlink.c:1148
9 0x562825e44060 in kernel_read zebra/kernel_netlink.c:510
10 0x7f6922aeca72 in event_call lib/event.c:1984
11 0x7f6922a19e01 in frr_run lib/libfrr.c:1246
12 0x562825e4b0b9 in main zebra/main.c:543
13 0x7f692250c249 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
Just check to see if it has been allocated. The nexthop is a stack
variable so it's a bit odd.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
