summaryrefslogtreecommitdiff
path: root/lib/command_graph.h
diff options
context:
space:
mode:
authorChirag Shah <chirag@cumulusnetworks.com>2020-07-06 11:13:54 -0700
committerChirag Shah <chirag@cumulusnetworks.com>2020-07-20 20:58:20 -0700
commit92475ca4873fd6ccf1f804e675c912c698c486ce (patch)
tree8694ef2d5934d2d5cb6e87c3b79c5e79ba4615ee /lib/command_graph.h
parentf1ed7d22d6e7fac752841c3cdc2171e96ed8d1b2 (diff)
zebra: vrf disable clean up evpn rmac nxthp cache
In networking restart event, l3vni (vxlan) interface followed by associated vrf interfaces go down/deleted. L3vni (oper) down event (from zebra to bgp) triggers to clean up/un-import evpn routes (one-by-one) from the vrf table, zebra internally removes the route entry from nexthop and RMAC hash. When all the routes references in nexthop and RMAC db removed, both (nexthop/rmac) are suppose to be uninstalled from the bridge fdb and neigh table. While evpn routes removal in progress, a vrf disable event removes l3vni to its vrf association. Subsequent bgp to evpn routes removal does not clean up thus evpn routes reference to nexthop and RMAC remains in zebra hash. bridge fdb and neigh tables are flushed out since networking restart brings down all interfaces which results in flush of fdb and neigh tables. By product is the zebra does not install nexthop and rmac when routes are re-imported into vrf in VNI/VRF up event. The fix is in vrf disable event to flush all l3vni's nexthop and rmac db. Ticket:CM-30338 Reviewed By:CCR-10489 Testing Done: Performed multiple networking restart and checked neigh and bridge fdb tables for respective nexthop and router mac entry programmed. Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
Diffstat (limited to 'lib/command_graph.h')
0 files changed, 0 insertions, 0 deletions