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>

0 files changed, 0 insertions, 0 deletions