EVPN-VXLAN Stretch vs. Route: Placing a Shared Services Segment
A data center has two pods, each with its own CX 10000 leaf pair and EVPN-VXLAN overlay, connected via border/spine layer. A shared services VLAN hosts DNS, NTP, and a jump host that every workload in both pods must reach. Option A stretches the VLAN across both pods as an L2 EVPN segment. Option B keeps the segment local to pod A and advertises it as an L3 anycast gateway subnet reachable from pod B. The team reports that with Option A, ARP/ND and broadcast traffic between pods is heavy and a single misbehaving host in pod B caused broadcast storms that reached pod A. Change windows are tight and the team wants the lowest-risk option.
1. Which option should be chosen and why? Address the storm symptom directly.
Read the worked answer
Choose Option B (L3 anycast gateway, no L2 stretch) for shared services.
Reasoning:
- Shared services (DNS/NTP/jump) are client-server, not L2-adjacent; they do not need broadcast domain adjacency across pods.
- Option A stretches a failure and broadcast domain: the pod-B storm reaching pod-A is the classic L2-stretch blast radius. Fixing it means adding storm control and tuning, which is ongoing operational risk.
- Option B confines broadcasts to pod A, gives clean fault isolation, and lets each pod's border route to the service subnet. Anycast gateway on the CX 10000 provides local first-hop for pod-A hosts; pod-B hosts route via the border.
Caveats to verify:
- Return path symmetry for stateful inspection of shared-services traffic.
- DNS/NTP clients must tolerate L3 reachability (they do).
- If a service truly requires L2 (e.g., legacy broadcast discovery), isolate that one service rather than stretching the whole VLAN.
Default to L3 for shared services; stretch L2 only for a documented L2 requirement.
2. If the business insists on Option A, what controls would you require before go-live?
Read the worked answer
If L2 stretch is mandated, treat it as a risk-managed exception:
- Storm control on every leaf port and the EVPN segment (broadcast/multicast/unknown-unicast thresholds) so a pod-B host cannot flood pod-A.
- BUM containment: verify ingress replication or multicast underlay scoping; keep the segment's VTEP membership minimal.
- ARP/ND suppression enabled to cut broadcast/unknown-unicast flooding across the overlay.
- Loop protection: ensure no unintended L2 path between pods outside EVPN; STP is not the tool across a VXLAN overlay.
- Monitoring: per-segment broadcast rate alarms and a documented rollback to Option B.
- Change plan: stage in a maintenance window with a canary host in pod B before broad cutover.
Document that Option A remains the higher-risk design and that Option B is the target state.