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>
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.
When peering with an EVPN device from other vendor, FRR acting as route
reflector is not able to read nor transmit the label value.
Actually, EVPN AD routes completely ignore the label value in the code,
whereas in some functionalities like evpn-vpws, it is authorised to
carry and propagate label value.
Fix this by handling the label value.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When staticd receives a `ZAPI_SRV6_SID_RELEASED` notification from SRv6
SID Manager, it tries to unset the validity flag of `sid`. But since
the `sid` variable is NULL, we get a NULL pointer dereference.
```
=================================================================
==13815==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000060 (pc 0xc14b813d9eac bp 0xffffcb135a40 sp 0xffffcb135a40 T0)
==13815==The signal is caused by a READ memory access.
==13815==Hint: address points to the zero page.
#0 0xc14b813d9eac in static_zebra_srv6_sid_notify staticd/static_zebra.c:1172
#1 0xe44e7aa2c194 in zclient_read lib/zclient.c:4746
#2 0xe44e7a9b69d8 in event_call lib/event.c:1984
#3 0xe44e7a85ac28 in frr_run lib/libfrr.c:1246
#4 0xc14b813ccf98 in main staticd/static_main.c:193
#5 0xe44e7a4773f8 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
#6 0xe44e7a4774c8 in __libc_start_main_impl ../csu/libc-start.c:392
#7 0xc14b813cc92c in _start (/usr/lib/frr/staticd+0x1c92c)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV staticd/static_zebra.c:1172 in static_zebra_srv6_sid_notify
==13815==ABORTING
```
This commit fixes the problem by doing a SID lookup first. If the SID
can't be found, we log an error and return. If the SID is found, we go
ahead and unset the validity flag.
Donald Sharp [Fri, 31 Jan 2025 23:53:30 +0000 (18:53 -0500)]
bgpd: With suppress-fib-pending ensure withdrawal is sent
When you have suppress-fib-pending turned on it is possible
to end up in a situation where the prefix is not withdrawn
from downstream peers.
Here is the timing that I believe is happening:
a) have 2 paths to a peer.
b) receive a withdrawal from 1 path, set BGP_NODE_FIB_INSTALL_PENDING
and send the route install to zebra.
c) receive a withdrawal from the other path.
d) At this point we have a dest->flags set BGP_NODE_FIB_INSTALL_PENDING
old_select the path_info going away, new_select is NULL
e) A bit further down we call group_announce_route() which calls
the code to see if we should advertise the path. It sees the
BGP_NODE_FIB_INSTALL_PENDING flag and says, nope.
f) the route is sent to zebra to withdraw, which unsets the
BGP_NODE_FIB_INSTALL_PENDING.
g) This function winds up and deletes the path_info. Dest now
has no path infos.
h) BGP receives the route install(from step b) and unsets the
BGP_NODE_FIB_INSTALL_PENDING flag
i) BGP receives the route removed from zebra (from step f) and
unsets the flag again.
We know if there is no new_select, let's go ahead and just
unset the PENDING flag to allow the withdrawal to go out
at the time when the second withdrawal is received.
Donald Sharp [Fri, 31 Jan 2025 17:38:20 +0000 (12:38 -0500)]
zebra: Ensure dplane does not send work back to master at wrong time
When looping through the dplane providers, the worklist was
being populated with items from the last provider and then
the event system was checked to see if we should stop processing.
If the event system says `yes` then the dplane code would stop
and send the worklist to the master zebra pthread for collection.
This obviously skipped the next dplane provider on the list
which is double plus not good.
Donald Sharp [Fri, 31 Jan 2025 17:12:17 +0000 (12:12 -0500)]
zebra: Limit mutex for obuf to when we access obuf
The mutex that wraps access to the output buffer
is being held for the entire time the data is
being generated to send down the pipe. Since
the generation has absolutely nothing to do
with the obuf, let's limit the mutex holding some.
Donald Sharp [Thu, 30 Jan 2025 14:53:09 +0000 (09:53 -0500)]
tests: Show that asic offload works in the fpm testing
The fpm_testing_topo1 didn't turn on the fpm_listener
sending the routes back to zebra to set the asic offload.
Modify the test to tell the fpm_listener to set the offloaded
flag and reflect the route back to the dplane_fpm_nl.c code.
Also modify zebra to expect a response to the underlying fpm listener.
Donald Sharp [Thu, 30 Jan 2025 14:02:44 +0000 (09:02 -0500)]
zebra: fpm_listener allow continued operation
In fpm_listener, when a error is detected it would
stop listening and not recover. Modify the code
to close the socket and allow the connection to
recover.
Donald Sharp [Thu, 30 Jan 2025 13:57:57 +0000 (08:57 -0500)]
zebra: Fix pass back of data from dplane through fpm pipe
A recent code change 29122bc9b8d5317f6f486f9fe61a92a854948cc5
changed the passing of data up the fpm from passing the
tableid and vrf to the sonic expected tableid contains
the vrfid. This violates the assumptions in the code
that the netlink message passes up the tableid as the
tableid. Additionally this code change did not modify
the rib_find_rn_from_ctx to actually properly decode
what could be passed up. Let's just fix this and let
Sonic carry the patch as appropriate for themselves
since they are not the only users of dplane_fpm_nl.c
Mark Stapp [Fri, 31 Jan 2025 18:13:48 +0000 (13:13 -0500)]
libs: return from change_caps if no caps
When called without caps/privs, just return from "change_caps"
instead of exiting - it's possible that a process may not need
privs, but a lib (for example) may use the api.
Donald Sharp [Fri, 31 Jan 2025 17:38:20 +0000 (12:38 -0500)]
zebra: Ensure dplane does not send work back to master at wrong time
When looping through the dplane providers, the worklist was
being populated with items from the last provider and then
the event system was checked to see if we should stop processing.
If the event system says `yes` then the dplane code would stop
and send the worklist to the master zebra pthread for collection.
This obviously skipped the next dplane provider on the list
which is double plus not good.
David Lamparter [Wed, 22 Jan 2025 10:19:04 +0000 (11:19 +0100)]
lib: guard against padding garbage in ZAPI read
When reading in a nexthop from ZAPI, only set the fields that actually
have meaning. While it shouldn't happen to begin with, we can otherwise
carry padding garbage into the unused leftover union bytes.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
David Lamparter [Wed, 22 Jan 2025 10:17:21 +0000 (11:17 +0100)]
zebra: guard against junk in nexthop->rmap_src
rmap_src wasn't initialized, so for IPv4 the unused 12 bytes would
contain whatever junk is on the stack on function entry. Also move
the IPv4 parse before the IPv6 parse so if it's successful we can be
sure the other bytes haven't been touched.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
David Lamparter [Wed, 22 Jan 2025 10:13:21 +0000 (11:13 +0100)]
bgpd: don't reuse nexthop variable in loop/switch
While the loop is currently exited in all cases after using nexthop, it
is a footgun to have "nh" around to be reused in another iteration of
the loop. This would leave nexthop with partial data from the previous
use. Make it local where needed instead.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Nobuhiro MIKI [Wed, 29 Jan 2025 04:31:53 +0000 (04:31 +0000)]
tools: Fix frr-reload for ebgp-multihop TTL reconfiguration.
In ebgp-multihop, there is a difference in reload behavior when TTL is
unspecified (meaning default 255) and when 255 is explicitly specified.
For example, when reloading with 'neighbor <neighbor> ebgp-multihop
255' in the config, the following difference is created. This commit
fixes that.
Lines To Delete
===============
router bgp 65001
no neighbor 10.0.0.4 ebgp-multihop
exit
Donald Sharp [Mon, 27 Jan 2025 15:34:31 +0000 (10:34 -0500)]
tests: Add a test that shows the v6 recursive nexthop problem
Currently FRR does not handle v6 recurisive resolution properly
when the route being recursed through changes and the most
significant bits of the route are not changed.
David Lamparter [Tue, 28 Jan 2025 15:37:52 +0000 (16:37 +0100)]
lib: fix use after free in `clear event cpu`
Freeing any item here means freeing someone's `event->hist`, leaving a
dangling pointer there. Which will immediately be written to because
we're executing in a CLI function under the `vty_read` event, whose
`event->hist` is then updated.
Deallocating `event->hist` anywhere other than shutting down the whole
event loop is a bad idea to begin with, just zero out the stats instead.
Fixes: FRRouting/frr#16419 Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Donatas Abraitis [Tue, 28 Jan 2025 15:11:58 +0000 (17:11 +0200)]
bgpd: Do not ignore auto generated VRF instances when deleting
When VRF instance is going to be deleted inside bgp_vrf_disable(), it uses
a helper method that skips auto created VRF instances and that leads to STALE
issue.
When creating a VNI for a particular VRF vrfX with e.g. `advertise-all-vni`,
auto VRF instance is created, and then we do `router bgp ASN vrf vrfX`.
But when we do a reload bgp_vrf_disable() is called, and we miss previously
created auto instance.
David Lamparter [Mon, 27 Jan 2025 17:18:24 +0000 (18:18 +0100)]
staticd: fix botched staticd YANG for dst-src
The staticd YANG conversion completely f*cked up dst-src routes.
Stupidly enough, the correct thing is much simpler as seen by the amount
of deletes in this commit.
This does, unfortunately, involve a rather annoying YANG edge case with
what should reasonably be an optional leaf as part of a list key, which
is not possible. It uses `::/0` as unconditional filler instead, since
that is semantically correct.
The `test_yang_mgmt` topotest needed to be adjusted after this to add
`src-prefix='::/0'`.
projects / matthieu / frr.git / log