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>
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.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
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>
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:
!
router isis 10
fast-reroute lfa tiebreaker lowest-backup-metric index 100 level-1
exit
!
Signed-off-by: baozhen-H3C <bao.zhen@h3c.com>
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.
tor-11# show bgp vrf blue ipv4 unicast route-leak json
{
"vrf":"blue",
"afiSafi":"ipv4Unicast",
"importFromVrfs":[
"purple"
],
"importRts":"10.10.3.11:6",
"exportToVrfs":[
"purple"
],
"routeDistinguisher":"(null)", <<<<<
"exportRts":"10.10.3.11:10"
}
Signed-off-by: Chirag Shah <chirag@nvidia.com>
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
Signed-off-by: Chirag Shah <chirag@nvidia.com>
Add a new test case that re-add the deleted SIDs and verifies that all
SIDs are added back to the RIB.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
Add a new test case that deletes a SID and verifies that only this
SID has been removed from the RIB.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
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.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
Add a topotest to verify the newly introduced CLI to support
steering of IPv4 traffic over an SRv6 SID list.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
staticd already has a CLI to steer IPv6 traffic over a given SRv6 SID
list:
```
vrf vrf10
ipv6 route 2001:db8:1:1::/64 sr0 segments fcbb:bbbb:1:2:3:fe00::
```
This PR extends the existing CLI `ip route` to support steering of IPv4
traffic over an SRv6 SID list.
```
vrf vrf10
ip route 10.0.0.0/24 sr0 segments fcbb:bbbb:1:2:3:fe00::
```
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
staticd already has a CLI to steer IPv6 traffic over a given SRv6 SID
list:
```
ipv6 route 2001:db8:1:1::/64 sr0 segments fcbb:bbbb:1:2:3:fe00::
```
This PR extends the existing CLI `ip route` to support steering of IPv4
traffic over an SRv6 SID list.
```
ip route 10.0.0.0/24 sr0 segments fcbb:bbbb:1:2:3:fe00::
```
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
staticd already has a CLI to steer IPv6 traffic over a given SRv6 SID
list:
```
vrf vrf10
ipv6 route 2001:db8:1:1::/64 sr0 segments fcbb:bbbb:1:2:3:fe00::
```
This PR extends the existing CLI `ip route` to support steering of IPv4
traffic over an SRv6 SID list.
```
vrf vrf10
ip route 10.0.0.0/24 sr0 segments fcbb:bbbb:1:2:3:fe00::
```
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
staticd already has a CLI to steer IPv6 traffic over a given SRv6 SID
list:
```
ipv6 route 2001:db8:1:1::/64 sr0 segments fcbb:bbbb:1:2:3:fe00::
```
This PR extends the existing CLI `ip route` to support steering of IPv4
traffic over an SRv6 SID list.
```
ip route 10.0.0.0/24 sr0 segments fcbb:bbbb:1:2:3:fe00::
```
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
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>
Just to make it simpler for compiling with a different default value.
No change to its default value.
Signed-off-by: Enke Chen <enchen@paloaltonetworks.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.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
Just to make it simpler for compiling with a different default value.
No change to its default value.
Signed-off-by: Enke Chen <enchen@paloaltonetworks.com>
