]> git.proxmox.com Git - mirror_frr.git/commit
zebra: svd and mvab bug fixes
authorsharathr <sharathr@cumulusnetworks.com>
Thu, 23 Sep 2021 07:17:57 +0000 (00:17 -0700)
committerStephen Worley <sworley@nvidia.com>
Mon, 13 Feb 2023 23:12:05 +0000 (18:12 -0500)
commit5c713062201d6953e36af651624e506887a1a5d0
tree52b73da76bd87df0934be208f5a9d8d26b32e1a9
parentee720c5dca5e2d013ba24d824c4760219f79af67
zebra: svd and mvab bug fixes

Ticket: 27303282724075
Reviewed By: CCR-11741, CCR-11746
Testing Done: Unit Test

2730328: At high bridge-vids count, VNI devices are not added in FRR if
FRR restarts after loading e/n/i
The issue is the wrt buffer overflow for netlink_recv_msg.
We have defined the kernel recv message buffer in stack which is of size 32768 (32K).

When the configuration is applied without FRR restart things work fine
because the recv message from kernel is well within the limit of 32K.
However with this configuration, when the FRR was restarted I could see that
some recv messages were crossing the 32K limit and hence weren't processed.
Below error logs were seen when frr was restarted with the confuguration.
2021/08/09 05:59:55 ZEBRA: [EC 4043309092] netlink-cmd (NS 0) error: data remnant size 32768
Fix is to increase the buffer size by another 2K

2724075: evpn mh/SVD - some of the remote neighs/macs aren't installed
in kernel post ifdown/ifup bridge

The issue was specific to SVD. During ifdown/ifup of the bridge,
I could see that the access-bd was not associated with the vni and hence
the remote neighs were not getting programmed in the kernel.
Fix is to reference (or associate) vxlan vni to the access-bd when
the vni is reported up. With this fix, I was able to see the remote
neighs getting programmed to the kernel.

Signed-off-by: Sharath Ramamurthy <sramamurthy@nvidia.com>
zebra/kernel_netlink.h
zebra/zebra_vxlan_if.c