staticd: Failed to register nexthop after networking restart
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 3c05d53bf8defc36acdfe6e78064e068d60c649f. 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
```
Louis Scalbert [Wed, 12 Feb 2025 11:50:42 +0000 (12:50 +0100)]
bgpd: fix incorrect json in bgp_show_table_rd
In bgp_show_table_rd(), the is_last argument is determined using the
expression "next == NULL" to check if the RD table is the last one. This
helps ensure proper JSON formatting.
However, if next is not NULL but is no longer associated with a BGP
table, the JSON output becomes malformed.
Updates the condition to also verify the existence of the next bgp_dest
table.
Fixes: 1ae44dfcba ("bgpd: unify 'show bgp' with RD with normal unicast bgp show") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Donald Sharp [Thu, 6 Feb 2025 23:40:30 +0000 (18:40 -0500)]
zebra: Allow fpm_listener to continue to try to read
Currently when the fpm_listener attempts to read say X
bytes it may only get Y( which is less than X ). In this
case we should assume that the dplane_fpm_nl code is just
being slow, as that we know it is possible for it to send
a partial fpm message. Let's just loosen the constraints
a bit and allow data to flow.
David Lamparter [Tue, 11 Feb 2025 10:58:15 +0000 (11:58 +0100)]
lib: `thread` -> `event` in formatting
Make it consistent and call it `event` when formatting something to
display. Much less confusing for some user seeing it too, since threads
aren't involved.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
David Lamparter [Tue, 11 Feb 2025 11:07:00 +0000 (12:07 +0100)]
bfdd: use lower lateness warning for TX timers
FRR's event loop prints a warning if a timer is executed more than some
given threshold late, default being 4s. Set a more appropriate
threshold for BFD TX timers (half TX interval).
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
David Lamparter [Tue, 11 Feb 2025 10:55:19 +0000 (11:55 +0100)]
lib: improve late timer warnings
Refactor the "timer getting executed too late" warning:
- warning threshold is now adjustable
- check is performed when event actually executes, rather than when it's
thrown on ready list
- ignore_late_timer replaced with threshold = 0
- system load averages printed in log message
- warning ratelimited to once per 10s rather than once per poll()
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Philippe Guibert [Mon, 10 Feb 2025 15:15:44 +0000 (16:15 +0100)]
nhrpd: fix dont consider incomplete L2 entry
Sometimes, NHRP receives L2 information on a cache entry with the
0.0.0.0 IP address. NHRP considers it as valid and updates the binding
with the new IP address.
> Feb 09 20:09:54 aws-sin-vpn01 nhrpd[2695]: [QQ0NK-1H449] Netlink: new-neigh 10.2.114.238 dev dmvpn1 lladdr 162.251.180.10 nud 0x2 cache used 0 type 4
> Feb 09 20:10:35 aws-sin-vpn01 nhrpd[2695]: [QQ0NK-1H449] Netlink: new-neigh 10.2.114.238 dev dmvpn1 lladdr 162.251.180.10 nud 0x4 cache used 1 type 4
> Feb 09 20:10:48 aws-sin-vpn01 nhrpd[2695]: [QQ0NK-1H449] Netlink: del-neigh 10.2.114.238 dev dmvpn1 lladdr 162.251.180.10 nud 0x4 cache used 1 type 4
> Feb 09 20:10:49 aws-sin-vpn01 nhrpd[2695]: [QQ0NK-1H449] Netlink: who-has 10.2.114.238 dev dmvpn1 lladdr (unspec) nud 0x1 cache used 1 type 4
> Feb 09 20:10:49 aws-sin-vpn01 nhrpd[2695]: [QVXNM-NVHEQ] Netlink: update binding for 10.2.114.238 dev dmvpn1 from c 162.251.180.10 peer.vc.nbma 162.251.180.10 to lladdr (unspec)
> Feb 09 20:10:49 aws-sin-vpn01 nhrpd[2695]: [QQ0NK-1H449] Netlink: new-neigh 10.2.114.238 dev dmvpn1 lladdr 0.0.0.0 nud 0x2 cache used 1 type 4
> Feb 09 20:11:30 aws-sin-vpn01 nhrpd[2695]: [QQ0NK-1H449] Netlink: new-neigh 10.2.114.238 dev dmvpn1 lladdr 0.0.0.0 nud 0x4 cache used 1 type 4
Actually, the 0.0.0.0 IP addressed mentiones in the 'who-has' message is
wrong because the nud state value means that value is incomplete and
should not be handled as a valid entry. Instead of considering it, fix
this by by invalidating the current binding. This step is necessary in
order to permit NHRP to trigger resolution requests again.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
bgpd: fix bmp loc-rib peer up message should use correct AS number
The transmitted AS value in te tx open message of the peer up loc-rib
message is set to 0. Actually, it should reflect the AS value of the
current BGP instance.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
bgpd: fix loc-rib open message should use router-id
When forging BMP open message, the BGP router-id of tx open message of
the BMP LOC-RIB peer up message is always set to 0.0.0.0, whatever the
configured value of 'bgp router-id'.
Actually, when forging a peer up LOC-RIB message, the BGP router-id
value should be taken from the main BGP instance, and not from the peer
bgp identifier. Fix this by refreshing the router-id whenever a peer up
loc-rib message should be sent.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Chirag Shah [Tue, 11 Feb 2025 02:56:15 +0000 (18:56 -0800)]
bgpd: fix bgp vrf instance creation from implicit
In bgp route leak, when import vrf x is executed,
it creates bgp instance as hidden with asn value as unspecified.
When router bgp x is configured ensure the correct as,
asnotation is applied otherwise running config shows asn value as 0.
This can lead to frr-reload failure when any FRR config change.
Fix:
Move asn and asnotiation, as_pretty value in common done section,
so when bgp_create gets existing instance but before returning
update asn and required fields in common section.
In bgp_create(): when returning for hidden at least update asn
and required when bgp instance created implicitly due to vrf leak.
if (hidden) {
bgp = bgp_old;
goto peer_init; <<<
}
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:
David Lamparter [Fri, 7 Feb 2025 12:22:25 +0000 (13:22 +0100)]
lib: crash handlers must be allowed on threads
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>
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.
Donald Sharp [Wed, 5 Feb 2025 13:42:00 +0000 (08:42 -0500)]
bfdd: Use pass by reference instead of pass by value for a struct
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.
Donald Sharp [Tue, 4 Feb 2025 20:00:12 +0000 (15:00 -0500)]
zebra: Stop leaking labels when receiving nexthops from kernel
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.
Donald Sharp [Tue, 4 Feb 2025 15:56:59 +0000 (10:56 -0500)]
bgpd: Fix up memory leak in processing eoiu marker
Memory is being leaked when processing the eoiu marker.
BGP is creating a dummy dest to contain the data but
it was never freed. As well as the eoiu info was
not being freed either.
bgpd: add L2 attr community support as per RFC8214
The L2 attribute extended community can not be decoded when using L2VPN
EVPN as a route reflector. Decode the extended community and dump the
detailed information about flags and MTU information.
> rt4# show bgp l2vpn evpn
> BGP table version is 1, local router ID is 4.4.4.4
> Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
> Origin codes: i - IGP, e - EGP, ? - incomplete
> EVPN type-1 prefix: [1]:[EthTag]:[ESI]:[IPlen]:[VTEP-IP]:[Frag-id]
> EVPN type-2 prefix: [2]:[EthTag]:[MAClen]:[MAC]:[IPlen]:[IP]
> EVPN type-3 prefix: [3]:[EthTag]:[IPlen]:[OrigIP]
> EVPN type-4 prefix: [4]:[ESI]:[IPlen]:[OrigIP]
> EVPN type-5 prefix: [5]:[EthTag]:[IPlen]:[IP]
>
> Network Next Hop Metric LocPrf Weight Path
> Route Distinguisher: 1.1.1.1:100
> *>i[1]:[12]:[00:00:00:00:00:00:00:00:00:00]:[32]:[0.0.0.0]:[0]
> 1.1.1.1 100 0 i
> RT:65500:100 L2: P flag:N, B Flag N, C word N, MTU 0
> Route Distinguisher: 5.5.5.5:100
> *>i[1]:[10]:[00:00:00:00:00:00:00:00:00:00]:[32]:[0.0.0.0]:[0]
> 5.5.5.5 100 0 i
> RT:65500:100 L2: P flag:N, B Flag N, C word N, MTU 0
>
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Louis Scalbert [Tue, 5 Nov 2024 16:13:38 +0000 (17:13 +0100)]
tests: bgp_vpnv4_route_leak_basic add del static prefix
In bgp_vpnv4_route_leak_basic, remove and add back the static prefix
172.16.3.0/24 on VRF DONNA. Before the previous fixes, the 172.16.3.0/24
prefix re-appeared when it was added back in the VPN table but it was
marked as invalid.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Louis Scalbert [Thu, 14 Nov 2024 10:28:24 +0000 (11:28 +0100)]
tests: fix no vrf1 in bgp_bmp r2
The bgp_bmp test is failing because r2 lacks the vrf1 VRF, which
prevents it from exporting VPN prefixes from the configured vrf1 BGP
instance. Previous versions allowed the export of static BGP prefixes
from a non-existent VRF, so the test passed under those conditions.
Louis Scalbert [Tue, 5 Nov 2024 14:53:43 +0000 (15:53 +0100)]
bgpd: recheck leak nexthop validity
When leak_update() rechecks an existing path, it considers nothing to
update if the attributes and labels are not changed. However, it does
not take into account the nexthop validity.
Perform a leak update if the nexthop validity has changed.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
b29332 [Thu, 15 Aug 2024 08:20:19 +0000 (16:20 +0800)]
isisd: 'tiebreaker' command line funtionality is inconsistent with its implementation
The command fast-reroute lfa tiebreaker [downstream | lowest-backup-metric | node-protecting] index (1-255) [level-1 | level-2] will overwrite configurations with the same index but different types. This is because the index is set as the key in frr-isisd.yang. However, the lfa_tiebreaker_cmp function uses a tuple (index, type) as the key. Therefore, the yang file should be modified to stay in sync with the business logic.
Test Scenario:
On RouterA, first configure fast-reroute lfa tiebreaker downstream index 100 level-1, then configure fast-reroute lfa tiebreaker lowest-backup-metric index 100 level-1, and check the configuration:
Chirag Shah [Mon, 3 Feb 2025 20:00:41 +0000 (12:00 -0800)]
bgpd: fix route-distinguisher in vrf leak json cmd
For auto configured value RD value comes as NULL,
switching back to original change will ensure to cover
for both auto and user configured RD value in JSON.
Chirag Shah [Fri, 31 Jan 2025 01:26:46 +0000 (17:26 -0800)]
zebra: evpn svd hash avoid double free
Upon zebra shutdown hash_clean_and_free is called
where user free function is passed,
The free function should not call hash_release
which lead to double free of hash bucket.
Fix:
The fix is to avoid calling hash_release from
free function if its called from hash_clean_and_free
path.
10 0x00007f0422b7df1f in free () from /lib/x86_64-linux-gnu/libc.so.6
11 0x00007f0422edd779 in qfree (mt=0x7f0423047ca0 <MTYPE_HASH_BUCKET>,
ptr=0x55fc8bc81980) at ../lib/memory.c:130
12 0x00007f0422eb97e2 in hash_clean (hash=0x55fc8b979a60,
free_func=0x55fc8a529478 <svd_nh_del_terminate>) at
../lib/hash.c:290
13 0x00007f0422eb98a1 in hash_clean_and_free (hash=0x55fc8a675920
<svd_nh_table>, free_func=0x55fc8a529478 <svd_nh_del_terminate>) at
../lib/hash.c:305
14 0x000055fc8a5323a5 in zebra_vxlan_terminate () at
../zebra/zebra_vxlan.c:6099
15 0x000055fc8a4c9227 in zebra_router_terminate () at
../zebra/zebra_router.c:276
16 0x000055fc8a4413b3 in zebra_finalize (dummy=0x7fffb881c1d0) at
../zebra/main.c:269
17 0x00007f0422f44387 in event_call (thread=0x7fffb881c1d0) at
../lib/event.c:2011
18 0x00007f0422ecb6fa in frr_run (master=0x55fc8b733cb0) at
../lib/libfrr.c:1243
19 0x000055fc8a441987 in main (argc=14, argv=0x7fffb881c4a8) at
../zebra/main.c:584
When a user wants to delete a specific SRv6 SID, he executes the
`no sid X:X::X:X/M` command.
However, by mistake, in addition to deleting the SID requested by the
user, this command also removes all other SIDs.
This happens because `no sid X:X::X:X/M` triggers a destroy operation
on the wrong xpath `frr-staticd:staticd/segment-routing/srv6`.
This commit fixes the issue by replacing the wrong xpath
`frr-staticd:staticd/segment-routing/srv6` with the correct xpath
`frr-staticd:staticd/segment-routing/srv6/static-sids/sid[sid='%s']`.
This ensures that the `no sid X:X::X:X/M` command only deletes the SID
that was requested by the user.
projects / mirror / frr.git / log