Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Ticket: 2730328, 2724075 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>
- Loading branch information