Introduce ZEBRA_IF_DUMMY interface flag to identify Linux dummy interfaces [0].
These interfaces behave similarly to loopback interfaces and can be
specially handled by daemons.
[0]: https://github.com/torvalds/linux/blob/master/drivers/net/dummy.c
Signed-off-by: Gabriel Goller <g.goller@proxmox.com>
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>
