L3 DCI with a Stretched Legacy VLAN
DC1 and DC2 are 15 ms apart and each has a Juniper EVPN-VXLAN fabric with a border leaf pair. The company wants Layer 3 DCI for 400 subnets and one stretched VLAN 200 for a legacy application. VLAN 200 uses VNI 10200 and anycast gateway 10.20.0.1/24 in both DCs. After enabling the stretch, users report intermittent connectivity to the legacy app. show evpn database in DC1 shows MAC 00:11:22:33:44:55 associated with a local server in DC1 and also with a remote server in DC2; the MAC mobility sequence number increments repeatedly. The border leaves advertise EVPN Type-5 routes for all other subnets, and a firewall cluster sits behind the border leaves for inter-DC policy. The security team requires that inter-DC traffic be inspected, but intra-DC traffic should not hairpin through the firewall.
1. Why does stretching VLAN 200 cause duplicate MAC and mobility? What is the correct fix?
Read the worked answer
Stretching VLAN 200 makes MAC 00:11:22:33:44:55 reachable from two different leaves in two different DCs. EVPN treats a MAC as movable, so each new advertisement increments the MAC mobility sequence number; the remote border and leaves keep updating the path. If the two servers are actually different hosts with the same MAC, caused by a cloned VM, copied NIC, or manual assignment, this is a duplicate MAC, not normal mobility. The anycast gateway MAC is intentionally shared; that is not the problem and should be excluded from duplicate detection if the platform supports it.
The intermittent connectivity comes from traffic being steered to one copy and then the other. Confirm with show evpn database extensive for the ESI, sequence number, and last move, and check the servers MAC addresses. The correct fix is to stop stretching VLAN 200 for those hosts and route between subnets with EVPN Type-5; if the stretch must remain, give each host a unique MAC.
2. Design the DCI to meet L3-only requirements and firewall inspection.
Read the worked answer
Use EVPN Type-5 for the 400 subnets and keep VLAN 200 local to DC1. Each DC has a border leaf pair that advertises Type-5 routes for its local subnets into the DCI. Use a per-tenant VRF with explicit route targets; the DCI imports only the intended targets. Inter-DC traffic is routed to the border leaf and then through the firewall cluster using a service VRF or a firewall filter that redirects to the firewall. Intra-DC traffic stays on the distributed anycast gateway and never hairpins through the border.
The firewall is inserted only for routes that need inspection: advertise a more specific Type-5 route or set a community on inter-DC prefixes that the border maps to the firewall next-hop. Verify with show route table bgp.evpn.0 that Type-5 routes carry the expected community and with show route in the tenant VRF that the firewall next-hop is preferred for inter-DC prefixes but not for local ones.
3. If VLAN 200 must remain stretched for six months, what safeguards would you configure?
Read the worked answer
Enable duplicate MAC detection and alerting on both fabrics; set a detection time that is longer than normal mobility but short enough to catch flapping, and do not auto-recover without investigation. Example knobs are duplicate-mac-detection detect-time and recovery-time under switch options, depending on platform. Ensure the two servers have unique MACs; if they cannot, put them in different VLANs and route.
Limit MAC mobility with a dampening policy only as a last resort, because it can hide a real move. Monitor show evpn database for sequence-number increments and log the duplicate MAC. Also document the stretch as temporary and migrate the legacy app to a unique subnet. The goal is to contain the blast radius while the L3 DCI design is completed.