The route entry created when using a ctx to pass route
entry data backup to the master pthread in zebra is
being leaked. Prevent this from happening.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit 7f9c5c7fa2)
Add ability for the connected routes to know
if they are a prefix route or not.
sharpd@eva:/work/home/sharpd/frr1$ ip addr show dev dummy1
13: dummy1: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
link/ether aa:93:ce:ce:3f:62 brd ff:ff:ff:ff:ff:ff
inet 192.168.55.1/24 scope global noprefixroute dummy1
valid_lft forever preferred_lft forever
inet 192.168.56.1/24 scope global dummy1
valid_lft forever preferred_lft forever
inet6 fe80::a893:ceff:fece:3f62/64 scope link
valid_lft forever preferred_lft forever
sharpd@eva:/work/home/sharpd/frr1$ sudo vtysh -c "show int dummy1"
Interface dummy1 is up, line protocol is up
Link ups: 0 last: (never)
Link downs: 0 last: (never)
vrf: default
index 13 metric 0 mtu 1500 speed 0 txqlen 1000
flags: <UP,BROADCAST,RUNNING,NOARP>
Type: Ethernet
HWaddr: aa:93:ce:ce:3f:62
inet 192.168.55.1/24 noprefixroute
inet 192.168.56.1/24
inet6 fe80::a893:ceff:fece:3f62/64
Interface Type Other
Interface Slave Type None
protodown: off
sharpd@eva:/work/home/sharpd/frr1$ sudo vtysh -c "show ip route"
Codes: K - kernel route, C - connected, L - local, S - static,
R - RIP, O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
F - PBR, f - OpenFabric, t - Table-Direct,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure
K>* 0.0.0.0/0 [0/100] via 192.168.119.1, enp13s0, 00:00:08
K>* 169.254.0.0/16 [0/1000] is directly connected, virbr2 linkdown, 00:00:08
L>* 192.168.44.1/32 is directly connected, dummy2, 00:00:08
L>* 192.168.55.1/32 is directly connected, dummy1, 00:00:08
C>* 192.168.56.0/24 is directly connected, dummy1, 00:00:08
L>* 192.168.56.1/32 is directly connected, dummy1, 00:00:08
L>* 192.168.119.205/32 is directly connected, enp13s0, 00:00:08
sharpd@eva:/work/home/sharpd/frr1$ ip route show
default via 192.168.119.1 dev enp13s0 proto dhcp metric 100
169.254.0.0/16 dev virbr2 scope link metric 1000 linkdown
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
192.168.45.0/24 dev virbr2 proto kernel scope link src 192.168.45.1 linkdown
192.168.56.0/24 dev dummy1 proto kernel scope link src 192.168.56.1
192.168.119.0/24 dev enp13s0 proto kernel scope link src 192.168.119.205 metric 100
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
sharpd@eva:/work/home/sharpd/frr1$ ip route show table 255
local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1
local 172.17.0.1 dev docker0 proto kernel scope host src 172.17.0.1
broadcast 172.17.255.255 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
local 192.168.44.1 dev dummy2 proto kernel scope host src 192.168.44.1
broadcast 192.168.44.255 dev dummy2 proto kernel scope link src 192.168.44.1
local 192.168.45.1 dev virbr2 proto kernel scope host src 192.168.45.1
broadcast 192.168.45.255 dev virbr2 proto kernel scope link src 192.168.45.1 linkdown
local 192.168.55.1 dev dummy1 proto kernel scope host src 192.168.55.1
broadcast 192.168.55.255 dev dummy1 proto kernel scope link src 192.168.55.1
local 192.168.56.1 dev dummy1 proto kernel scope host src 192.168.56.1
broadcast 192.168.56.255 dev dummy1 proto kernel scope link src 192.168.56.1
local 192.168.119.205 dev enp13s0 proto kernel scope host src 192.168.119.205
broadcast 192.168.119.255 dev enp13s0 proto kernel scope link src 192.168.119.205
local 192.168.122.1 dev virbr0 proto kernel scope host src 192.168.122.1
broadcast 192.168.122.255 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
Fixes: #14952
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit 8a574840a4)
The linux kernel can send up a flag that tells us that the
connected address is not a PREFIXROUTE. Add the ability
to note this and pass it up from the data plane.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit 466ad88ce1)
The fpm code path in building a ecmp route for evpn has
a bug that caused it to not add the encap attribute to
the netlink message. See #f0f7b285b99dbd971400d33feea007232c0bd4a9
for the single path case being fixed.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit 6b23ece88b)
Fix memory leaks by allocating `json_segs` conditionally on `nexthop->nh_srv6->seg6_segs`.
The previous code allocated memory even when not in use or attached to the JSON tree.
The ASan leak log for reference:
```
Direct leak of 3240 byte(s) in 45 object(s) allocated from:
#0 0x7f6e84a35d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7f6e83de9e6f in json_object_new_array (/lib/x86_64-linux-gnu/libjson-c.so.3+0x3e6f)
#2 0x564dcab5c1a6 in vty_show_ip_route zebra/zebra_vty.c:705
#3 0x564dcab5cc71 in do_show_route_helper zebra/zebra_vty.c:955
#4 0x564dcab5d418 in do_show_ip_route zebra/zebra_vty.c:1039
#5 0x564dcab63ee5 in show_route_magic zebra/zebra_vty.c:1878
#6 0x564dcab63ee5 in show_route zebra/zebra_vty_clippy.c:659
#7 0x7f6e843b6fb1 in cmd_execute_command_real lib/command.c:978
#8 0x7f6e843b7475 in cmd_execute_command lib/command.c:1036
#9 0x7f6e843b78f4 in cmd_execute lib/command.c:1203
#10 0x7f6e844dfe3b in vty_command lib/vty.c:594
#11 0x7f6e844e02e6 in vty_execute lib/vty.c:1357
#12 0x7f6e844e8bb7 in vtysh_read lib/vty.c:2365
#13 0x7f6e844d3b7a in event_call lib/event.c:1965
#14 0x7f6e844172b0 in frr_run lib/libfrr.c:1214
#15 0x564dcaa50e81 in main zebra/main.c:488
#16 0x7f6e837f7c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Indirect leak of 11520 byte(s) in 45 object(s) allocated from:
#0 0x7f6e84a35d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7f6e83de88c0 in array_list_new (/lib/x86_64-linux-gnu/libjson-c.so.3+0x28c0)
Indirect leak of 1080 byte(s) in 45 object(s) allocated from:
#0 0x7f6e84a35d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7f6e83de8897 in array_list_new (/lib/x86_64-linux-gnu/libjson-c.so.3+0x2897)
```
Signed-off-by: Keelan Cannoo <keelan.cannoo@icloud.com>
Signed-off-by: ryndia <dindyalsarvesh@gmail.com>
(cherry picked from commit 531866c538)
Without this patch, static ARP entries remain active even if the interface is
down, but the kernel already removed them.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit a35bb7e2a8)
Currently in the single nexthop case w/ evpn sending
down via the FPM the encap type is not being set
for the nexthop.
This looks like the result of some code reorg for the
nexthop happened but the fpm failed to be accounted for.
Let's just move the encap type encoding to where it
will happen.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit 4ac659fcbe)
Display ptmStatus in correct order in show interface json
output.
Signed-off-by: Sindhu Parvathi Gopinathan's <sgopinathan@nvidia.com>
(cherry picked from commit aa6dab0369)
When the label manager is unable to provide a label chunk to
a routing service, an error message is displayed:
> Oct 11 11:47:27 vsr zebra[163745]: [YMY6E-K9JYD][EC 4043309085] Unable to assign Label Chunk to bgp instance 0
There is missing information on the range that was requested.
Add this information in the log message.
> Oct 11 11:47:27 vsr zebra[163745]: [YMY6E-K9JYD][EC 4043309085] Unable to assign Label Chunk 60 - 60 to bgp instance 0
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
(cherry picked from commit 1cedcf7b15)
This function lm_get_chunk_response() is only called
by label_manager_get_chunk(). Let us move the code of
the function in the caller.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
(cherry picked from commit 6988622832)
When multiple interfaces have addresses in the same network, deleting
one of them may cause the wrong connected route being deleted.
For example:
ip link add veth1 type veth peer veth2
ip link set veth1 up
ip link set veth2 up
ip addr add dev veth1 192.168.0.1/24
ip addr add dev veth2 192.168.0.2/24
ip addr flush dev veth1
Zebra deletes the route of interface veth2 rather than veth1.
Should match nexthop against ere->re_nhe instead of ere->re->nhe.
Signed-off-by: Xiao Liang <shaw.leon@gmail.com>
(cherry picked from commit a35ba7ba60)
We may receive some xxxCHAIN netlink messages, but we ignore
them (currently). Add them to the basic handler callback so
that we don't log errors about them.
Signed-off-by: Mark Stapp <mjs@labn.net>
(cherry picked from commit 620daa36c5)
`ng` was not properly freed, leading to a memory leak.
The commit calls `nexthop_group_delete` to free memory associated with `ng`.
The ASan leak log for reference:
```
***********************************************************************************
Address Sanitizer Error detected in isis_topo1.test_isis_topo1/r5.asan.zebra.24308
=================================================================
==24308==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 32 byte(s) in 1 object(s) allocated from:
#0 0x7f4f47b43d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7f4f4753c0a8 in qcalloc lib/memory.c:105
#2 0x7f4f47559526 in nexthop_group_new lib/nexthop_group.c:270
#3 0x562ded6a39d4 in zebra_add_import_table_entry zebra/redistribute.c:681
#4 0x562ded787c35 in rib_link zebra/zebra_rib.c:3972
#5 0x562ded787c35 in rib_addnode zebra/zebra_rib.c:3993
#6 0x562ded787c35 in process_subq_early_route_add zebra/zebra_rib.c:2860
#7 0x562ded787c35 in process_subq_early_route zebra/zebra_rib.c:3138
#8 0x562ded787c35 in process_subq zebra/zebra_rib.c:3178
#9 0x562ded787c35 in meta_queue_process zebra/zebra_rib.c:3228
#10 0x7f4f475f7118 in work_queue_run lib/workqueue.c:266
#11 0x7f4f475dc7f2 in event_call lib/event.c:1969
#12 0x7f4f4751f347 in frr_run lib/libfrr.c:1213
#13 0x562ded69e818 in main zebra/main.c:486
#14 0x7f4f468ffc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Indirect leak of 152 byte(s) in 1 object(s) allocated from:
#0 0x7f4f47b43d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7f4f4753c0a8 in qcalloc lib/memory.c:105
#2 0x7f4f475510ad in nexthop_new lib/nexthop.c:376
#3 0x7f4f475539c5 in nexthop_dup lib/nexthop.c:914
#4 0x7f4f4755b27a in copy_nexthops lib/nexthop_group.c:444
#5 0x562ded6a3a1c in zebra_add_import_table_entry zebra/redistribute.c:682
#6 0x562ded787c35 in rib_link zebra/zebra_rib.c:3972
#7 0x562ded787c35 in rib_addnode zebra/zebra_rib.c:3993
#8 0x562ded787c35 in process_subq_early_route_add zebra/zebra_rib.c:2860
#9 0x562ded787c35 in process_subq_early_route zebra/zebra_rib.c:3138
#10 0x562ded787c35 in process_subq zebra/zebra_rib.c:3178
#11 0x562ded787c35 in meta_queue_process zebra/zebra_rib.c:3228
#12 0x7f4f475f7118 in work_queue_run lib/workqueue.c:266
#13 0x7f4f475dc7f2 in event_call lib/event.c:1969
#14 0x7f4f4751f347 in frr_run lib/libfrr.c:1213
#15 0x562ded69e818 in main zebra/main.c:486
#16 0x7f4f468ffc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
SUMMARY: AddressSanitizer: 184 byte(s) leaked in 2 allocation(s).
***********************************************************************************
```
Signed-off-by: Keelan Cannoo <keelan.cannoo@icloud.com>
When netlink_link_change() errors out for a new link for
interface without MTU set, the allocated ctx is not freed..
Adding code for correctness
Ticket# 3628313
Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.com>
Currently when one interface changes its VRF, zebra will send these messages to
all daemons in *order*:
1) `ZEBRA_INTERFACE_DELETE` ( notify them delete from old VRF )
2) `ZEBRA_INTERFACE_VRF_UPDATE` ( notify them move from old to new VRF )
3) `ZEBRA_INTERFACE_ADD` ( notify them added into new VRF )
When daemons deal with `VRF_UPDATE`, they use
`zebra_interface_vrf_update_read()->if_lookup_by_name()`
to check the interface exist or not in old VRF. This check will always return
*NULL* because `DELETE` ( deleted from old VRF ) is already done, so can't
find this interface in old VRF.
Send `VRF_UPDATE` is redundant and unuseful. `DELETE` and `ADD` are enough,
they will deal with RB tree, so don't send this `VRF_UPDATE` message when
vrf changes.
Since all daemons have good mechanism to deal with changing vrf, and don't
use this `VRF_UPDATE` mechanism. So, it is safe to completely remove
all the code with `VRF_UPDATE`.
Signed-off-by: anlan_cs <anlan_cs@tom.com>
Include a zclient value in the hash and tree key computations
for iprules in zebra: clients may collide without this.
Signed-off-by: Mark Stapp <mjs@labn.net>
The iprule/pbr rule object has a vrf id, and zebra uses
that internally, but the vrf id isn't returned to clients
who install rules and are waiting for results. Include the
vrf_id sent by the client in the zapi result notification
message; update the existing clients so they decode the id.
Signed-off-by: Mark Stapp <mjs@labn.net>
When interface addresses change, we examine nhgs associated
with the interface in case they need to be reinstalled. As
part of that, we may need to reinstall ecmp nhgs that use the
interface being examined - but not always.
Signed-off-by: Mark Stapp <mjs@labn.net>
In zebra/label_manager.c the releasing of the label chunk is done by
disowning the chunk to the system. The presence of this system label
chunk will cause label assignment to fail for this use case example:
label chunk ospf: 300-320
label chunk system: 510-520
label chunk isis: 1200-1300
Then we try to allocate the chunk 500-530, we get this error:
"Allocation of mpls label chunk [500/530] failed"
The error is raised when the below condition is true:
/* if chunk is used, cannot honor request */
if (lmc->proto != NO_PROTO)
return NULL;
Delete the label chunk instead of disowning it when the label releasing
is done.
Signed-off-by: Farid MIHOUB <farid.mihoub@6wind.com>
Add the new command "show debugging labeltable" to show allocated label
chunks in the label table managed with label_manager.c
Signed-off-by: Farid Mihoub <farid.mihoub@6wind.com>
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Provide skeleton hooks for nexthop segments
Those hooks address seg6 segs stack entries defined in the YANG
model
Signed-off-by: Dmytro Shytyi <dmytro.shytyi@6wind.com>
Append zebra and lib to use muliple SRv6 segs SIDs, and keep one
seg SID for bgpd and sharpd.
Note: bgpd and sharpd compilation relies on the lib and zebra files,
i.e if we separate this: lib or zebra or bgpd or sharpd in different
commits - this will not compile.
Signed-off-by: Dmytro Shytyi <dmytro.shytyi@6wind.com>
When zebra receives a Netlink message containing a seg6local nexthop,
let's use the default values for optional attributes `lcblock_len` and
`lcnode_fn_len`, if they are not specified.
Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
When zebra receives a Netlink message containing a seg6local nexthop,
let's use the default values for optional attributes `lcblock_len` and
`lcnode_fn_len`, if they are not specified.
Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
Extend the `parse_encap_seg6local` function to parse SRv6 flavors
information contained in the Netlink message.
Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
Only attempt to install in netlink iprules that include supported
actions; ignore requests with actions that aren't supported by
netlink.
Signed-off-by: Mark Stapp <mjs@labn.net>
If the kernel sends us bad data then the kind_str
will be NULL and a later strcmp operation will
cause a crash.
As a note: If the kernel is not sending us properly
formated netlink messages then we got bigger problems
than zebra crashing. But at least let's prevent zebra
from crashing.
Reported-by: Iggy Frankovic <iggyfran@amazon.com>
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
