In 9461953914 and
8ebcc02328, transmission of PIM register and
register stop messages was changed to use a separate socket. However, that
socket is not bound to a possible VRF, so the messages were sent in the
default VRF instead. Call vrf_bind() once after socket creation and when the
VRF is ready to ensure transmission in the correct VRF. vrf_bind() handles
the non-VRF case (i.e. VRF_DEFAULT) automatically, so it may be called
unconditionally.
Signed-off-by: Martin Buck <mb-tmp-tvguho.pbz@gromit.dyndns.org>
As part of the upstream master commit (f3575f61c7 bgpd: Sort the
bgp_path_inf) the snippet of the code for dmed check condition
left out, which leads to an issue of selecting incorrect bestpath.
As an example:
During the bestpath selection local route looses to another path due
to dmed condition being hit.
The snippet of the logs:
2025/02/20 03:06:20.131441 BGP: [JW7VP-K1YVV]
[2]:[0]:[48]:[00:92:00:00:00:10](VRF default): Comparing path
27.0.0.7 flags Valid with path Static announcement flags Selected Valid Attr Changed Unsorted
2025/02/20 03:06:20.131445 BGP: [SYTDR-QV6X9] [2]:[0]:[48]:[00:92:00:00:00:10]: path 27.0.0.7 loses to path Static announcement as ES 03:44:38:39:ff:ff:02:00:00:01 is same and local
2025/02/20 03:06:20.131452 BGP: [JW7VP-K1YVV] [2]:[0]:[48]:[00:92:00:00:00:10](VRF default): Comparing path 27.0.0.8 flags Valid with path Static announcement flags Selected Valid Attr Changed Unsorted
2025/02/20 03:06:20.131456 BGP: [SYTDR-QV6X9] [2]:[0]:[48]:[00:92:00:00:00:10]: path 27.0.0.8 loses to path Static announcement as ES 03:44:38:39:ff:ff:02:00:00:01 is same and local
2025/02/20 03:06:20.131458 BGP: [WEWEC-8SE72] [2]:[0]:[48]:[00:92:00:00:00:10](VRF default): path Static announcement is the bestpath from AS 0 <<<< static is best
2025/02/20 03:06:20.131463 BGP: [Z3A78-GM3G5] bgp_best_selection: [2]:[0]:[48]:[00:92:00:00:00:10](VRF default) pi 27.0.0.7 dmed
2025/02/20 03:06:20.131467 BGP: [Z3A78-GM3G5] bgp_best_selection: [2]:[0]:[48]:[00:92:00:00:00:10](VRF default) pi 27.0.0.8 dmed
2025/02/20 03:06:20.131471 BGP: [N6CTF-2RSKS] [2]:[0]:[48]:[00:92:00:00:00:10](VRF default): After path selection, newbest is path 27.0.0.7 oldbest was Static announce
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
I was pointed at yet another crash in the orf code. I think it
stems from basicaly the same problem as the last one. Let's just
make sure that the orf_plist is handled appropriately.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The previous version incorrectly spelled the command as `ip split-horizon`. The correct command is `ip rip split-horizon`, as indicated in the code at line 675 of rip_cli.c.
Signed-off-by: Shbinging <bingshui@smail.nju.edu.cn>
Add the option of printing logs in logfmt format.
Additional machine readable information can be printed via the `extra`
argument.
Example:
```python
log.debug("exit context"), extra={"line": line, "ctx_keys": ctx_keys})
log.error(f"Failed to execute command {' '.join(cmd)}", extra={"cmd": cmd})
```
Signed-off-by: Giovanni Tataranni <g.tataranni@gmail.com>
The `srv6_encap_src_addr` runs a vtysh command to configure the SRv6
encapsulation source address and then immediately invokes an iproute2
command to verify that zebra has set this address in the kernel. There
is no wait between the two operations and the verification is attempted
only once. If the topotest does not find the expected address it fails
immediately.
The problem is that when topotest is run on a heavyily loaded system,
it can take some time for zebra to set the address in the kernel.
In this case, when the topotest checks the kernel address right after
running the vtysh command, it doesn't find the expected address because
zebra hasn't set it yet.
This commit gives zebra some time to configure the address. It keeps to
check that the address is the expected one for about 1 minute. If after
1 minute the address is not the expected one then the test fails.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
The `srv6_encap_src_addr` topotest uses a waiting time that is too
small. For this reason during startup it prints a warning:
```
2025-02-16 09:23:47,704 WARNING: topo: Waiting time is too small (count=10, wait=1), using default values (count=20, wait=3)
```
This commit increases the waiting time to fix the warning.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
The `srv6_encap_src_addr` topotest tries to load bgpd.conf file that
does not exist, which produces the following warning:
```
2025-02-16 09:23:35,151 WARNING: topo: missing config 'r1' for '/media/frr/tests/topotests/srv6_encap_src_addr/r1/bgpd.conf' creating empty file '/etc/frr/bgpd.conf'
```
Since this topotest doesn't actually use bgpd, there's no point in
loading the config file.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
The `srv6_encap_src_addr` topotest tries to load sharpd.conf file that
does not exist, which produces the following warning:
```
2025-02-16 09:23:35,151 WARNING: topo: missing config 'r1' for '/media/frr/tests/topotests/srv6_encap_src_addr/r1/sharpd.conf' creating empty file '/etc/frr/sharpd.conf'
```
Since this topotest doesn't actually use sharpd, there's no point in
loading the config file.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
When SRv6 is enabled and an SRv6 locator is specified in the IS-IS
configuration, IS-IS 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/14 21:41:20 ISIS: [HR66R-TWQYD][EC 100663302] srv6_manager_get_locator: invalid zclient socket
````
As a result, IS-IS is unable to obtain the locator information,
preventing SRv6 from working.
This commit fixes the issue by ensuring IS-IS requests SRv6 locator
information once the connection with zebra is successfully established.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
This commit adds a function that iterates over all IS-IS areas and asks
the SRv6 Manager for information about the configured locators.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
Problem:
After networking restart, staticd unregistered the nexthop
but failed to register the nexthop again, which caused the
nexthop to remain inactive in zebra for static route.
Fix:
Call to static_zebra_nht_register() from static_install_path() was
removed in 3c05d53bf8. Adding it back
so that staticd can register the nexthop for static routes.
Testing:
After networking restart trigger on h1:
Before fix:
```
h1# show ipv6 route vrf vrf1012
Codes: K - kernel route, C - connected, L - local, S - static,
R - RIPng, O - OSPFv3, I - IS-IS, B - BGP, N - NHRP,
T - Table, A - Babel, D - SHARP, F - PBR, f - OpenFabric,
t - Table-Direct, Z - FRR,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure
VRF vrf1012:
S ::/0 [1/0] via 2003:7:2::1, swp1.2 inactive, weight 1, 00:00:39
K>* ::/0 [255/8192] unreachable (ICMP unreachable) (vrf default), 00:00:39
L * 2000:9:12::3/128 is directly connected, vrf1012, 00:00:39
C>* 2000:9:12::3/128 is directly connected, vrf1012, 00:00:39
C>* 2003:7:2::/125 is directly connected, swp1.2, 00:00:37
L>* 2003:7:2::3/128 is directly connected, swp1.2, 00:00:37
C>* fe80::/64 is directly connected, swp1.2, 00:00:37
h1#
```
After fix:
```
h1# show ipv6 route vrf vrf1012
Codes: K - kernel route, C - connected, L - local, S - static,
R - RIPng, O - OSPFv3, I - IS-IS, B - BGP, N - NHRP,
T - Table, A - Babel, D - SHARP, F - PBR, f - OpenFabric,
t - Table-Direct, Z - FRR,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure
VRF vrf1012:
S>* ::/0 [1/0] via 2003:7:2::1, swp1.2, weight 1, 00:00:15
K * ::/0 [255/8192] unreachable (ICMP unreachable) (vrf default), 00:00:17
L * 2000:9:12::3/128 is directly connected, vrf1012, 00:00:17
C>* 2000:9:12::3/128 is directly connected, vrf1012, 00:00:17
C>* 2003:7:2::/125 is directly connected, swp1.2, 00:00:15
L>* 2003:7:2::3/128 is directly connected, swp1.2, 00:00:15
```
Signed-off-by: Pooja Jagadeesh Doijode <pdoijode@nvidia.com>
Previously the code was only calling the child destroy callbacks if the target
deleted node was a non-presence container. We now add a flag to the callback
structure to instruct northbound to perform the rescursive delete for code that
wishes for this to happen.
- Fix wrong relative path lookup in keychain destroy callback
Signed-off-by: Christian Hopps <chopps@labn.net>
This adds 2 commands, one that should just straight up SEGV, another
that should trip an ASAN warning for an use-after-free.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Some codepoints can not be read by interoperating with CISCO.
This is because PSP/USP flavor are used by default, and the display of
the isis output has to be adapted.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Update user documentation to reflect behavior of config command
'allow-reserved-ranges' after changes enable use of ipv4 class E
addresses by default.
Signed-off-by: David Schweizer <dschweizer@opensourcerouting.org>
Changes allow ipv4 class E addresses and prefixes in the 240.0.0.0/4
range to be configured on interfaces, imported from the kernel routing
table and redistributed as connected routes in zebra by default.
Changes also fix routes with class E prefixes in kernel routing table
getting rejected by zebra during early daemon startup.
Drivin this change in default behavior are cloud providers (with
customers still using obsolete ipv4 protocol, i.e. Azure, AWS) running
out of ip space and abusing class E for addressing instances (announced
via BGP) over tunneling connections back to customers on premise
infrastructure.
Signed-off-by: David Schweizer <dschweizer@opensourcerouting.org>
We are very very rarely seeing this crash:
0 0x7f36ba48e389 in prefix_list_apply_ext lib/plist.c:789
1 0x55eff3fa4126 in subgroup_announce_check bgpd/bgp_route.c:2334
2 0x55eff3fa858e in subgroup_process_announce_selected bgpd/bgp_route.c:3440
3 0x55eff4016488 in subgroup_announce_table bgpd/bgp_updgrp_adv.c:808
4 0x55eff401664e in subgroup_announce_route bgpd/bgp_updgrp_adv.c:861
5 0x55eff40111df in peer_af_announce_route bgpd/bgp_updgrp.c:2223
6 0x55eff3f884cb in bgp_announce_route_timer_expired bgpd/bgp_route.c:5892
7 0x7f36ba4ec239 in event_call lib/event.c:2019
8 0x7f36ba41a22a in frr_run lib/libfrr.c:1295
9 0x55eff3e668b7 in main bgpd/bgp_main.c:557
10 0x7f36b9e2d249 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
11 0x7f36b9e2d304 in __libc_start_main_impl ../csu/libc-start.c:360
12 0x55eff3e64a30 in _start (/home/ci/cibuild.1407/frr-source/bgpd/.libs/bgpd+0x2fda30)
0x608000037038 is located 24 bytes inside of 88-byte region [0x608000037020,0x608000037078)
freed by thread T0 here:
0 0x7f36ba8b76a8 in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:52
1 0x7f36ba439bd7 in qfree lib/memory.c:131
2 0x7f36ba48d3a3 in prefix_list_free lib/plist.c:156
3 0x7f36ba48d3a3 in prefix_list_delete lib/plist.c:247
4 0x7f36ba48fbef in prefix_bgp_orf_remove_all lib/plist.c:1516
5 0x55eff3f679c4 in bgp_route_refresh_receive bgpd/bgp_packet.c:2841
6 0x55eff3f70bab in bgp_process_packet bgpd/bgp_packet.c:4069
7 0x7f36ba4ec239 in event_call lib/event.c:2019
8 0x7f36ba41a22a in frr_run lib/libfrr.c:1295
9 0x55eff3e668b7 in main bgpd/bgp_main.c:557
10 0x7f36b9e2d249 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
previously allocated by thread T0 here:
0 0x7f36ba8b83b7 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:77
1 0x7f36ba4392e4 in qcalloc lib/memory.c:106
2 0x7f36ba48d0de in prefix_list_new lib/plist.c:150
3 0x7f36ba48d0de in prefix_list_insert lib/plist.c:186
4 0x7f36ba48d0de in prefix_list_get lib/plist.c:204
5 0x7f36ba48f9df in prefix_bgp_orf_set lib/plist.c:1479
6 0x55eff3f67ba6 in bgp_route_refresh_receive bgpd/bgp_packet.c:2920
7 0x55eff3f70bab in bgp_process_packet bgpd/bgp_packet.c:4069
8 0x7f36ba4ec239 in event_call lib/event.c:2019
9 0x7f36ba41a22a in frr_run lib/libfrr.c:1295
10 0x55eff3e668b7 in main bgpd/bgp_main.c:557
11 0x7f36b9e2d249 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
Let's just stop trying to save the pointer around in the peer->orf_plist
data structure. There are other design problems but at least lets
stop the crash from possibly happening.
Fixes: #18138
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
