I85PREP
⌘ K
Nokia VPRN study materials
Nokia VPRN study resources

Anycast gateway MAC causes EVPN MAC flapping between DCGWs

Nokia VPRN · Put your knowledge to work in context.

All case studies

Anycast gateway MAC causes EVPN MAC flapping between DCGWs

Two data-center gateway PEs, DCGW-1 and DCGW-2, connect a VXLAN EVPN leaf-spine fabric to an MPLS WAN. VPRN 500 is stretched across both; the default gateway for VLAN 50 is anycast 10.50.0.1/24 with virtual MAC 00:00:5e:00:01:01 configured identically on both DCGWs, VNI 10500. Each DCGW has a VXLAN tunnel to each of 24 leaves and an MPLS SDP to the other DCGW. The service worked with only DCGW-1 acting as gateway. After the anycast gateway was enabled on DCGW-2, NSP raises MAC-mobility events for the virtual MAC every 60-120 seconds and hosts in VLAN 50 see 3-5 s of loss each time. show service id 500 fdb detail shows the virtual MAC alternating between the local VXLAN SAP and the MPLS SDP on both DCGWs. Neither DCGW has an ESI configured for the virtual MAC; each advertises it as a separately originated EVPN MAC route. The fabric underlay is stable and no leaf or link events are logged.

1. Why does an identical gateway MAC on two VTEPs cause MAC mobility churn, and what does EVPN need in order to treat the two advertisements as one logical attachment?

Read the worked answer

An EVPN MAC route identifies a MAC by next-hop (the VTEP) and by ESI. With no ESI, each DCGW advertises 00:00:5e:00:01:01 from a different VTEP as a single-homed MAC, so remote PEs see the same MAC arriving from two different next-hops.

EVPN's MAC mobility interprets that as the MAC moving between VTEPs: it withdraws the old route, installs the new one, and the sequence repeats as traffic alternates between the two gateways. Each move is a convergence event, which is why the loss is 3-5 s every minute or two and why NSP logs mobility events. The MPLS SDP appearing in the FDB is the same churn seen from the local side.

What EVPN needs is a shared multihoming identity: both DCGWs advertise the virtual MAC with the same ESI and enable AD per-ESI, so receivers understand 'this MAC is multihomed behind these two VTEPs' and install both paths instead of moving it. Implementations also typically require the MAC to be flagged as an anycast-gateway MAC so it is exempt from mobility detection. The virtual MAC is already identical; the missing piece is the multihoming identity.

2. What design change fixes it, and what alternatives exist if the platform or release does not support that construct?

Read the worked answer

Fix: configure the gateway as an EVPN anycast gateway on both DCGWs - same virtual MAC, same VNI and VLAN, same ESI, AD per-ESI enabled so both can be active for the MAC. Confirm the exact knobs for the installed SR OS release (interface-level anycast-gw plus the EVPN-side ESI) in the release documentation rather than assuming a syntax; a wrong ESI can blackhole traffic silently.

Alternatives:

  • Active/standby gateway with VRRP: one virtual MAC owned by the master, and EVPN advertises only the master's VTEP for that MAC. You lose active-active first-hop and gain a VRRP state to monitor, but the duplicate-MAC problem disappears.
  • Unique MAC per DCGW with host routing on the leaves: hosts resolve their local gateway; workable, but you no longer have one anycast IP without VRRP, and default-gateway distribution must be consistent.
  • Single gateway, second DCGW as WAN/MPLS-only backup: simplest and it is what was working, but there is no DC-side first-hop redundancy.

Whichever is chosen, validate in a lab with the same VNI and ESI configuration before touching production, and keep the ESI value in the golden template so a rebuilt DCGW does not come back single-homed.

3. What verification and monitoring would prove the fix and catch a recurrence?

Read the worked answer

Immediate verification:

  • show service id 500 fdb detail on both DCGWs: the virtual MAC should show as local on each and remote via the ESI/peer, not alternating to the MPLS SDP.
  • BGP EVPN MAC routes: both DCGWs advertise the MAC with the same ESI and correct next-hops, with no withdrawal/re-add churn.
  • NSP: mobility events for the virtual MAC drop to zero over at least 30 minutes and through a leaf reboot.
  • Data plane: sustained ping and throughput from VLAN 50 to a WAN destination for several minutes with zero loss, plus a failover test shutting one DCGW's VXLAN to confirm the path stays active.

Monitoring:

  • Alarm on MAC-mobility events above a low threshold per MAC-VRF, so churn is visible before users report loss.
  • Configuration compliance check comparing ESI and anycast-gateway settings between the DCGW pair; a mismatch is a ticket.
  • Keep the ESI/anycast configuration in the golden template and include it in the post-replacement checklist, since this failure only appears when the second gateway is enabled.