summaryrefslogtreecommitdiff
path: root/lib/libfrr.c
diff options
context:
space:
mode:
authorChirag Shah <chirag@cumulusnetworks.com>2020-01-11 21:23:12 -0800
committerChirag Shah <chirag@cumulusnetworks.com>2020-02-07 17:02:39 -0800
commit256f86b655f725933018683045476f0e388cea7e (patch)
tree3bba1db13411c0ed9d34d2d77409a1b636a8860b /lib/libfrr.c
parent5bf7fe566d74c1093e0c032436a657b4f44ad5f6 (diff)
zebra:remote vtep delete handling
The existing behavior is when a remote VTEP is deleted, its associatedneighbor (arp) and MAC entries are removed from zebra database and do not wait for explicit type-2 route withdraw from originating VTEP. Remote type-2 route delete checks if VTEP is present before removing the entry. The behavior works fine when all evpn routes points to the same nexthop as the VTEP IP. In MLAG topology with advertise-pip, self type-2 and type-5 routes are advertised with individual VTEP IP as nexthop ip for the route. When a new VNI is created, it is assigned individual IP as tunnel-ip then it transition to anycast IP (of the MLAG). During the transition, type-3 route (VTEP delete) withdraw is sent for the individual IP. The remote VTEP delete should not trigger to remove evpn routes pointing to VTEP IP. Instead the route will be removed via explicit withdraw. Ticket:CM-27752 Reviewed By:CCR-9722 Testing Done: In evpn with MLAG deployment with advertise-pip and advertise-svi-ip enabled, validated remote vtep delete does not remove self type-2 routes from zebra DB. Upon explicit type-2 withdraw routes are removed. Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
Diffstat (limited to 'lib/libfrr.c')
0 files changed, 0 insertions, 0 deletions