| Age | Commit message (Collapse) | Author |
|---|
|
Separate zebra's ZAPI server socket handling into two phases:
an early phase that opens the socket, and a later phase that
starts listening for client connections.
Signed-off-by: Mark Stapp <mjs@cisco.com>
(cherry picked from commit 506097a1b96974c261411edd25330ceaf90fa3db)
|
|
```
-A, --asic-offload FRR is interacting with an asic underneath the linux kernel
--v6-with-v4-nexthops Underlying dataplane supports v6 routes with v4 nexthops -s, --nl-bufsize Set netlink receive buffer size
```
Fixes: 1f5611c06d1c243b42279748788f0627793ead9c ("zebra: Allow zebra cli to accept v6 routes with v4 nexthops")
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit 25ae643996d338b8230fb15a9064843fe85de224)
|
|
After the change:
```
$ grep on-rib-process /etc/frr/frr.conf
zebra on-rib-process script script4
$ systemctl restart frr
$ vtysh -c 'show run' | grep on-rib-process
zebra on-rib-process script script4
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
|
|
Move route_unlock_node() after rnh_list_del().
Signed-off-by: Enke Chen <enchen@paloaltonetworks.com>
(cherry picked from commit 5b6ff51b8ae7f8c7348cea4de9543956f32641a7)
|
|
fpm_enqueue_rmac_table expects an fpm_rmac_arg* as its argument.
The issue can be reproduced by dropping the TCP session using:
ss -K dst 127.0.0.1 dport = 2620
I used Fedora 40 and frr 9.1.2 and I got the gdb backtrace:
(gdb) bt
0 0x00007fdd7d6997ea in fpm_enqueue_rmac_table (bucket=0x2134dd0, arg=0x2132b60) at zebra/dplane_fpm_nl.c:1217
1 0x00007fdd7dd1560d in hash_iterate (hash=0x21335f0, func=0x7fdd7d6997a0 <fpm_enqueue_rmac_table>, arg=0x2132b60) at lib/hash.c:252
2 0x00007fdd7dd1560d in hash_iterate (hash=0x1e5bf10, func=func@entry=0x7fdd7d698900 <fpm_enqueue_l3vni_table>,
arg=arg@entry=0x7ffed983bef0) at lib/hash.c:252
3 0x00007fdd7d698b5c in fpm_rmac_send (t=<optimized out>) at zebra/dplane_fpm_nl.c:1262
4 0x00007fdd7dd6ce22 in event_call (thread=thread@entry=0x7ffed983c010) at lib/event.c:1970
5 0x00007fdd7dd20758 in frr_run (master=0x1d27f10) at lib/libfrr.c:1213
6 0x0000000000425588 in main (argc=10, argv=0x7ffed983c2e8) at zebra/main.c:492
Signed-off-by: Igor Zhukov <fsb4000@yandex.ru>
(cherry picked from commit a3877e4444dc3a1253135d3b9479935fc9a966f8)
|
|
Add missing isis and eigrp proto translations.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit f53dde0e5921aafae0a00d993257ea7423b5ee97)
|
|
Report the routes metric in IPFORWARDMETRIC1 and return
-1 for the other metrics as required by the IP-FORWARD-MIB.
inetCidrRouteMetric2 OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"An alternate routing metric for this route. The
semantics of this metric are determined by the routing-
protocol specified in the route's inetCidrRouteProto
value. If this metric is not used, its value should be
set to -1."
DEFVAL { -1 }
::= { inetCidrRouteEntry 13 }
I've included metric2 but it's the same for all of them.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit e41ae0acc1940b568def5018efad3df019023f85)
|
|
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit 659cd66427ac8a6fe705b4a319245b7c88f80c05)
|
|
The snmp walk of the zebra rib was skipping entries
because in_addr_cmp was replaced with a prefix_cmp
which worked slightly differently causing parts
of the zebra rib tree to be skipped.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit ecd9d441b082e3f24139eb96915b18fc17996c08)
|
|
The function zebra_nhg_hash_equal is only used
as a hash function for storage of NHG's and retrieval.
If you have say two nhg's:
31 (25/26)
32 (25/26)
This function would return them as being equal. Which
of course leads to the problem when you attempt to
hash_release 32 but release 31 from the hash. Then later
when you attempt to do hash comparisons 32 has actually
been freed leaving to use after free situations and shit
goes down hill fast.
This hash is only used as part of the hash comparison
function for nexthop group storage. Since this is so
let's always return the 31/32 nhg's are not equal at all.
We possibly have a different problem where we are creating
31 and 32 ( when 31 should have just been used instead of 32 )
but we need to prevent any type of hash release problem at all.
This supercedes any other issue( that should be tracked down
on it's own ). Since you can have use after free situation
that leads to a crash -vs- some possible nexthop group duplication
which is very minor in comparison.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit 5a1b61aeba1b83825e1656a047aab35be0c1db55)
|
|
During internal testing, when the following sequence is followed, two
non default vrfs end up pointing to the same table-id
- Initially vrf201 has table id 1002
- ip link add dev vrf202 type vrf table 1002
- ip link set dev vrf202 up
- ip link set dev <intrerface> master vrf202
This will ideally lead to zebra exit since this is a misconfiguration as
expected.
However if we perform a restart frr.service at this point, we end up
having two vrfs pointing to same table-id and bad things can happen.
This is because in the interface_vrf_change, we incorrectly check for
vrf_lookup_by_id() to evaluate if there is a misconfig. This works well
for a non restart case but not for the startup case.
root@mlx-3700-20:mgmt:/var/log/frr# sudo vtysh -c "sh vrf"
vrf mgmt id 37 table 1001
vrf vrf201 id 46 table 1002
vrf vrf202 id 59 table 1002 >>>>
Fix: in all cases of misconfiguration, exit zebra as expected.
Ticket :#3970414
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.com>
(cherry picked from commit c77e15710d6a3a9be71f41a9ce608f06b2795dfb)
|
|
In case of EVPN MH bond, a member port going in
protodown state due to external reason (one case being linkflap),
frr updates the state correctly but upon manually
clearing external reason trigger FRR to reinstate
protodown without any reason code.
Fix is to ensure if the protodown reason was external
and new state is to have protodown 'off' then do no reinstate
protodown.
Ticket: #3947432
Testing:
switch:#ip link show swp1
4: swp1: <NO-CARRIER,BROADCAST,MULTICAST,SLAVE,UP> mtu 9216 qdisc
pfifo_fast master bond1 state DOWN mode DEFAULT group default qlen
1000
link/ether 1c:34:da:2c:aa:68 brd ff:ff:ff:ff:ff:ff protodown on
protodown_reason <linkflap>
switch:#ip link set swp1 protodown off protodown_reason linkflap off
switch:#ip link show swp1
4: swp1: <NO-CARRIER,BROADCAST,MULTICAST,SLAVE,UP> mtu 9216 qdisc
pfifo_fast master bond1 state DOWN mode DEFAULT group default qlen
1000
link/ether 1c:34:da:2c:aa:68 brd ff:ff:ff:ff:ff:ff
Signed-off-by: Chirag Shah <chirag@nvidia.com>
(cherry picked from commit e4d843b438ae7cbae89ae47af0754fb1db153c6c)
|
|
Currently zebra does not deny the routes if `ip protocol <proto> route-map
FOO`
commmand is configured with reference to an undefined route-map (FOO in
this case).
However, on FRR restart, in zebra_route_map_check() routes get denied
if route-map name is available but the route-map is not defined. This
change was introduced in fd303a4ba14c762550db972317e1e88528768005.
Fix:
When `ip protocol <proto> route-map FOO` CLI is configured with reference to an
undefined route-map FOO, let the processing in ip_protocol_rm_add() and
ip_protocol_rm_del() go through so that zebra can deny the routes instead
of simply returning. This will result in consistent behavior.
Testing Done:
Before fix:
```
spine-1# configure
spine-1(config)# ip protocol bgp route-map rmap7
root@spine-1:mgmt:/var/home/cumulus# vtysh -c "show run" | grep rmap7
ip protocol bgp route-map rmap7
root@spine-1:mgmt:/var/home/cumulus#
spine-1(config)# do show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, A - Babel, D - SHARP, F - PBR, f - OpenFabric,
Z - FRR,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure
C>* 27.0.0.1/32 is directly connected, lo, 02:27:45
B>* 27.0.0.3/32 [20/0] via fe80::202:ff:fe00:21, downlink_1, weight 1, 02:27:35
B>* 27.0.0.4/32 [20/0] via fe80::202:ff:fe00:29, downlink_2, weight 1, 02:27:40
B>* 27.0.0.5/32 [20/0] via fe80::202:ff:fe00:31, downlink_3, weight 1, 02:27:40
B>* 27.0.0.6/32 [20/0] via fe80::202:ff:fe00:39, downlink_4, weight 1, 02:27:40
```
After fix:
```
spine-1(config)# ip protocol bgp route-map route-map67
spine-1(config)# do show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, A - Babel, D - SHARP, F - PBR, f - OpenFabric,
Z - FRR,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure
C>* 27.0.0.1/32 is directly connected, lo, 00:35:03
B 27.0.0.3/32 [20/0] via fe80::202:ff:fe00:21, downlink_1 inactive, weight 1, 00:34:58
B 27.0.0.4/32 [20/0] via fe80::202:ff:fe00:29, downlink_2 inactive, weight 1, 00:34:57
B 27.0.0.5/32 [20/0] via fe80::202:ff:fe00:31, downlink_3 inactive, weight 1, 00:34:57
B 27.0.0.6/32 [20/0] via fe80::202:ff:fe00:39, downlink_4 inactive, weight 1, 00:34:58
spine-1(config)#
root@spine-1:mgmt:/var/home/cumulus# ip route show
root@spine-1:mgmt:/var/home/cumulus#
```
Signed-off-by: Pooja Jagadeesh Doijode <pdoijode@nvidia.com>
(cherry picked from commit 705e8ef78f84dea3af5943a74571f968ad076c8d)
|
|
Configured with "mpls label bind 1.1.1.1/32 explicit-null", the running
configuration is:
```
!
mpls label bind 1.1.1.1/32 IPv4 Explicit Null
!
```
After this commit, the running configuration is:
```
!
mpls label bind 1.1.1.1/32 explicit-null
!
```
And add the support for the "no" form:
```
anlan(config)# mpls label bind 1.1.1.1/32 explicit-null
anlan(config)# no mpls label bind 1.1.1.1/32 explicit-null
```
Signed-off-by: anlan_cs <anlan_cs@tom.com>
(cherry picked from commit 05ad3ccb034c174d2e853e88b826ca0db1e77f45)
|
|
In the context of SVD (Single VxLAN Device) for L3VNI,
the remote VTEP's nexthop is programmed neighbor entry against
SVD along with neighbor entry against SVI.
However, when L3VNI is removed or the VRF is disabled, all SVI
based remote nexthop neighbors are uninstalled and deleted.
The SVD based neigh entries remains in Zebra and the Kernel.
Subsequently, when reconfiguring L3VNI and relearning the same nexthop,
the neighbor entry is not programmed is because it is not removed
from Zebra SVD neighbor hash table, leading to the failure to
reprogram the entry.
With this fix, the SVD nexthop neigh entry is uninstalled
and deleted from Zebra and Kernel.
Ticket: #3729045
Testing:
borderleaf:# ip neigh show 2.2.2.2
2.2.2.2 dev vlan2560_l3 lladdr 00:01:00:00:1d:09 extern_learn NOARP proto zebra
2.2.2.2 dev vxlan99 lladdr 00:01:00:00:1d:09 extern_learn NOARP proto zebra
With the fix:
Zebra log shows both enties SVD (vxlan99) and SVI (vlan2560_l3)
neighbor entries are deleted.
2024/05/03 18:41:33.527125 ZEBRA: [NH6N7-54CD1] Tx RTM_DELNEIGH family
ipv4 IF vxlan99(16) Neigh 2.2.2.2 MAC null flags 0x10 state 0x0
ext_flags 0x0
2024/05/03 18:41:33.527128 ZEBRA: [NH6N7-54CD1] Tx RTM_DELNEIGH family
ipv4 IF vlan2560_l3(18) Neigh 2.2.2.2 MAC null flags 0x10 state 0x0
ext_flags 0x0
borderleaf:# ip neigh show 2.2.2.2
borderleaf:#
Signed-off-by: Chirag Shah <chirag@nvidia.com>
(cherry picked from commit fde6dd7bb9161cf58fdd8ca066cce77bad159c9d)
|
|
In zebra_interface_nhg_reinstall zebra is checking that the
nhg is a singleton and not a blackhole nhg. This was originally
done with checking that the nexthop is a NEXTHOP_TYPE_IFINDEX,
NEXTHOP_TYPE_IPV4_IFINDEX and NEXTHOP_TYPE_IPV6_IFINDEX. This
was excluding NEXTHOP_TYPE_IPV4 and NEXTHOP_TYPE_IPV6. These
were both possible to be received and maintained from the upper
level protocol for when a route is being recursively resolved.
If we have gotten to this point in zebra_interface_nhg_reinstall
the nexthop group has already been installed at least once
and we *know* that it is actually a valid nexthop. What the
test is really trying to do is ensure that we are not reinstalling
a blackhole nexthop group( Which is not possible to even be
here by the way, but safety first! ). So let's change
to test for that instead.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit 29c1ff446e581fc403d155fd1d00b7c944cba56a)
|
|
Null-check the vxlan-vni array info coming into zebra from
the dataplane.
Signed-off-by: Mark Stapp <mjs@cisco.com>
(cherry picked from commit 75ef259b1dd9273478414ea0684243f535ec8f33)
|
|
Whenever a link up change was detected on a macvlan device where
the linked device wasn't visible in the namespace zebra was
running in, the linked zebra interface was NULL. This was already
handled in the event of a link down, but was ommitted from the
upside. Added the same null check to the up-side.
Signed-off-by: Tomi Salminen <tlsalmin@gmail.com>
(cherry picked from commit bdf6a9ba810b58146371e8a0000397d2ae9ea956)
|
|
Split zebra's vrf_terminate() into disable() and delete() stages.
The former enqueues all events for the dplane thread.
Memory freeing is performed in the second stage.
Signed-off-by: Alexander Skorichenko <askorichenko@netgate.com>
(cherry picked from commit 444ce317b2af491b5cdc321286772627a5d4c8ea)
|
|
A macvlan interface can have its underlying link-interface in another
namespace (aka. netns). However, by default, zebra does not know the
interface from the other namespaces. It results in a crash the pointer
to the link interface is NULL.
> 6 0x0000559d77a329d3 in zebra_vxlan_macvlan_up (ifp=0x559d798b8e00) at /root/frr/zebra/zebra_vxlan.c:4676
> 4676 link_zif = link_ifp->info;
> (gdb) list
> 4671 struct interface *link_ifp, *link_if;
> 4672
> 4673 zif = ifp->info;
> 4674 assert(zif);
> 4675 link_ifp = zif->link;
> 4676 link_zif = link_ifp->info;
> 4677 assert(link_zif);
> 4678
> (gdb) p zif->link
> $2 = (struct interface *) 0x0
> (gdb) p zif->link_ifindex
> $3 = 15
Fix the crash by returning when the macvlan link-interface is in another
namespace. No need to go further because any vxlan under the macvlan
interface would not be accessible by zebra.
Link: https://github.com/FRRouting/frr/issues/15370
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
(cherry picked from commit 44e6e3868d7a1488447f2be446dbd7cb5a5559ce)
|
|
This reverts commit e2b180cc902ee92a464c997f0ab6663ac3986266.
|
|
This reverts commit b311787366bae730b58d416251eed45c608df8a3.
|
|
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 7f9c5c7fa2d927033549a806fd9025a9459f22bc)
|
|
Before:
```
status: Removed ReplacingInstalled
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit 162433cb2af7170318ab117ff4ded51f7e020343)
|
|
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 8a574840a4e29d2529fb03cdeeb6a09a11b0bdf5)
|
|
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 466ad88ce12af8d613600717def6a17dc6283ee8)
|
|
Fix a crash because a use-after-free.
> =================================================================
> ==1249835==ERROR: AddressSanitizer: heap-use-after-free on address 0x604000074210 at pc 0x7fa1b42a652c bp 0x7ffc477a2aa0 sp 0x7ffc477a2a98
> READ of size 8 at 0x604000074210 thread T0
> #0 0x7fa1b42a652b in list_delete_all_node git/frr/lib/linklist.c:299:20
> #1 0x7fa1b42a683f in list_delete git/frr/lib/linklist.c:312:2
> #2 0x5ee515 in dplane_ctx_free_internal git/frr/zebra/zebra_dplane.c:858:4
> #3 0x5ee59c in dplane_ctx_free git/frr/zebra/zebra_dplane.c:884:2
> #4 0x5ee544 in dplane_ctx_fini git/frr/zebra/zebra_dplane.c:905:2
> #5 0x7045c0 in rib_process_dplane_results git/frr/zebra/zebra_rib.c:4928:4
> #6 0x7fa1b4434fb2 in event_call git/frr/lib/event.c:1970:2
> #7 0x7fa1b42a0ccf in frr_run git/frr/lib/libfrr.c:1213:3
> #8 0x556808 in main git/frr/zebra/main.c:488:2
> #9 0x7fa1b3d0bd09 in __libc_start_main csu/../csu/libc-start.c:308:16
> #10 0x4453e9 in _start (/usr/lib/frr/zebra+0x4453e9)
>
> 0x604000074210 is located 0 bytes inside of 40-byte region [0x604000074210,0x604000074238)
> freed by thread T0 here:
> #0 0x4bf1dd in free (/usr/lib/frr/zebra+0x4bf1dd)
> #1 0x7fa1b42df0c0 in qfree git/frr/lib/memory.c:130:2
> #2 0x7fa1b42a68ce in list_free_internal git/frr/lib/linklist.c:24:2
> #3 0x7fa1b42a6870 in list_delete git/frr/lib/linklist.c:313:2
> #4 0x5ee515 in dplane_ctx_free_internal git/frr/zebra/zebra_dplane.c:858:4
> #5 0x5ee59c in dplane_ctx_free git/frr/zebra/zebra_dplane.c:884:2
> #6 0x5ee544 in dplane_ctx_fini git/frr/zebra/zebra_dplane.c:905:2
> #7 0x7045c0 in rib_process_dplane_results git/frr/zebra/zebra_rib.c:4928:4
> #8 0x7fa1b4434fb2 in event_call git/frr/lib/event.c:1970:2
> #9 0x7fa1b42a0ccf in frr_run git/frr/lib/libfrr.c:1213:3
> #10 0x556808 in main git/frr/zebra/main.c:488:2
> #11 0x7fa1b3d0bd09 in __libc_start_main csu/../csu/libc-start.c:308:16
>
> previously allocated by thread T0 here:
> #0 0x4bf5d2 in calloc (/usr/lib/frr/zebra+0x4bf5d2)
> #1 0x7fa1b42dee18 in qcalloc git/frr/lib/memory.c:105:27
> #2 0x7fa1b42a3784 in list_new git/frr/lib/linklist.c:18:9
> #3 0x6d165f in pbr_iptable_alloc_intern git/frr/zebra/zebra_pbr.c:1015:29
> #4 0x7fa1b426ad1f in hash_get git/frr/lib/hash.c:147:13
> #5 0x6d15f2 in zebra_pbr_add_iptable git/frr/zebra/zebra_pbr.c:1030:13
> #6 0x5db2a3 in zread_iptable git/frr/zebra/zapi_msg.c:3759:3
> #7 0x5e365d in zserv_handle_commands git/frr/zebra/zapi_msg.c:4039:3
> #8 0x7e09fc in zserv_process_messages git/frr/zebra/zserv.c:520:3
> #9 0x7fa1b4434fb2 in event_call git/frr/lib/event.c:1970:2
> #10 0x7fa1b42a0ccf in frr_run git/frr/lib/libfrr.c:1213:3
> #11 0x556808 in main git/frr/zebra/main.c:488:2
> #12 0x7fa1b3d0bd09 in __libc_start_main csu/../csu/libc-start.c:308:16
Fixes: 1cc380679e ("zebra: Actually free all memory associated ctx->u.iptable.interface_name_list")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
(cherry picked from commit 45140bb9e1efd2e603377809e349b35087d24f7d)
|
|
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 6b23ece88bc061ed6c0bdabf6846e3d981aa757a)
|
|
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 531866c538f5c6717158c8672b7539f797c50555)
|
|
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 a35bb7e2a89097dc90105a75cbd68618fb74451c)
|
|
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 4ac659fcbeb3848ee6caf06676a9ac1543ae62f1)
|
|
Display ptmStatus in correct order in show interface json
output.
Signed-off-by: Sindhu Parvathi Gopinathan's <sgopinathan@nvidia.com>
(cherry picked from commit aa6dab0369b9ab90291f5596f6b23a4c0b226ed0)
|
|
zebra: add xxxCHAIN netlink messages to handler, ignore (backport #14577)
|
|
zebra: add label chunk range in log when label manager request fails (backport #14584)
|
|
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 1cedcf7b15ee72fe859189bf772081a141fb50e6)
|
|
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 69886228326443941a65f87e7ee6fb42323f825b)
|
|
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 a35ba7ba602f87390cc9cbce3f0ceb61977f0949)
|
|
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 620daa36c5a757a96b6d0ed97e350d00b721cc48)
|
|
This reverts commit 1642a68d60cfade4b2fce72aaef58dea700c65c3.
(cherry picked from commit 0dc12c9003a865c7ee829543d40e8c285863abe8)
|
|
zebra: be more careful removing 'installed' flag from nhgs
|
|
zebra: Prevent leaking ctx memory in err condition
|
|
`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>
|
|
lib,*: add vrf id to pbr rule results zapi message
|
|
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>
|
|
zebra: add zclient to iprules key
|
|
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>
|
|
A couple minor fixes
|
