EVPN-MPLS All-Active Multihoming with MAC Mobility
An EVPN-MPLS network has six leaf PE routers and two spine P routers. A customer access switch is dual-homed to PE1 and PE2 with an ESI and all-active multihoming; BUM traffic is replicated across the ESI. A virtual machine moves from a server behind PE3 to a server behind PE4. Shortly after the move, PE3 reports a duplicate MAC and continues to advertise the old MAC, so traffic to the VM is black-holed for about 30 seconds. The DF election on the ESI is configured per-VLAN, and one VLAN's DF is PE1 while another VLAN's DF is PE2. The provider also needs to extend this EVPN domain to a remote data center running EVPN-VXLAN; the remote DC uses a different ASN and a different VTEP address family.
1. The ESI has per-VLAN DF election, with PE1 DF for VLAN 10 and PE2 DF for VLAN 20. Is that the cause of the 30-second black hole? Explain what DF election controls in all-active multihoming and what else must be true for unicast forwarding.
Read the worked answer
No. DF election controls which PE forwards broadcast, unknown unicast, and multicast (BUM) traffic for a given VLAN on an ESI; it does not control unicast. Per-VLAN DF is a valid design: PE1 can be DF for VLAN 10 and PE2 for VLAN 20, so BUM traffic for each VLAN is sourced by one PE. That can be asymmetric but is not a black hole.
For all-active unicast, every PE attached to the ESI must be allowed to forward traffic for locally learned MACs, and remote PEs must use aliasing so they can send to the CE through any PE in the ESI. The CE must hash flows across the two links; if it sends all traffic on one link, the other PE is standby in practice. Check show evpn ethernet-segment, show evpn instance, and show evpn mac-table on both PEs. The 30-second black hole aligns with MAC mobility/withdrawal, not DF election. If the DF were incorrectly configured as single-active, then only one PE would forward and the other would drop, but that would be persistent, not 30 seconds.
2. PE3 reports a duplicate MAC and keeps advertising the old location after the VM moves. Explain the EVPN MAC mobility sequence-number process, why PE3 might not withdraw, and what you would check and change.
Read the worked answer
EVPN MAC mobility uses a sequence number in the MAC advertisement. When the VM moves, the new PE advertises the MAC with a higher sequence number; the old PE should withdraw or update its route after seeing the higher number. Duplicate MAC detection occurs when two PEs advertise the same MAC with the same sequence number, or when the old PE keeps the MAC without a higher sequence. Common causes: the old PE still has the MAC in its local table because the VM's old port is up, the MAC is static, or mac-mobility is configured without sequence numbers. On a VXLAN DCI, the sequence number may be lost if the border re-originates the route.
Check show evpn mac-table, show evpn mac-table duplicates, show evpn instance extensive, and show ethernet-switching table on the CE side. Enable mac-mobility { sequence-number } on the EVPN instance, clear the duplicate state with clear evpn duplicate-mac-detection, and ensure the old access port is down. If the MAC is static, remove the static configuration or use static-mac with the correct ESI. For the DCI, preserve the MAC mobility sequence number across the border, or terminate the EVPN domain and re-originate at Layer 3.
3. The provider must extend this EVPN domain to a remote EVPN-VXLAN data center with a different ASN. Recommend a DCI design and state what must be preserved or terminated at the border.
Read the worked answer
Prefer a Layer 3 DCI gateway: a border PE with an IRB and EVPN Type 5 routes, eBGP between the two ASNs, and route-target filtering. This avoids stretching a single Layer 2 domain across data centers, keeps ESI multihoming local to each DC, and limits MAC scaling and failure propagation. If Layer 2 extension is a hard requirement, use a border PE that terminates EVPN-MPLS and originates EVPN-VXLAN (or vice versa) with a 1:1 VNI-to-label mapping, import/export RTs, and a MAC-VRF per VNI. In that case, do not extend the ESI across the DCI; multihoming is per DC. Preserve the EVPN route types (Type 2 for MAC/IP, Type 5 for prefix), the VNI/label mapping, and the MTU. Verify with show evpn instance, show route table bgp.evpn.0, and end-to-end ping with different frame sizes. A different ASN is normal for eBGP DCI; use local-as only if the border must appear in the remote AS.