]> git.puffer.fish Git - matthieu/frr.git/commit
bgpd: Suppress redundant L3VNI delete processing
authorRajasekar Raja <rajasekarr@nvidia.com>
Tue, 26 Nov 2024 20:02:53 +0000 (12:02 -0800)
committerRajasekar Raja <rajasekarr@nvidia.com>
Mon, 9 Dec 2024 16:46:16 +0000 (08:46 -0800)
commitbd32706c704175872f5af23715639990775820eb
tree052589a82a3f9f7b3e989224e88e2d2402479210
parent0f2cb2731053a678c85115abda008dc1d012e591
bgpd: Suppress redundant L3VNI delete processing

Consider a master bridge interface (br_l3vni) having a slave vxlan99
mapped to vlans used by 3 L3VNIs.

During ifdown br_l3vni interface, the function
zebra_vxlan_process_l3vni_oper_down() where zebra sends ZAPI to bgp for
a delete L3VNI is sent twice.
 1) if_down -> zebra_vxlan_svi_down()
 2) VXLAN is unlinked from the bridge i.e. vxlan99
    zebra_if_dplane_ifp_handling() --> zebra_vxlan_if_update_vni()
    (since ZEBRA_VXLIF_MASTER_CHANGE flag is set)

During ifup br_l3vni interface, the function
zebra_vxlan_process_l3vni_oper_down() is invoked because of access-vlan
change - process oper down, associate with new svi_if and then process
oper up again

The problem here is that the redundant ZAPI message of L3VNI delete
results in BGP doing a inline Global table walk for remote route
installation when the L3VNI is already removed/deleted. Bigger the
scale, more wastage is the CPU utilization.

Given the triggers for bridge flap is not a common scenario, idea is to
simply return from BGP if the L3VNI is already set to 0 i.e.
if the L3VNI is already deleted, do nothing and return.

NOTE/TBD: An ideal fix is to make zebra not send the second L3VNI delete
ZAPI message. However it is a much involved and a day-1 code to handle
corner cases.

Ticket :#3864372

Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.com>
bgpd/bgp_evpn.c