Between two municipal DCs the metro path is plain IP, while tenant traffic uses VXLAN overlays signaled by EVPN. What does this reinforce about EVPN-VXLAN DCI?
Select an answer to reveal the explanation.
Short Explanation
The WAN can just be IP roads between border VTEPs—the overlay still rides VXLAN on top. EVPN handles the smart signaling; the underlay just has to reach those VTEP addresses. No need to turn the metro into one giant L2 LAN for DCI to work.
Full Explanation
Between two municipal DCs, a plain IP metro path with tenant traffic in EVPN-signaled VXLAN overlays reinforces that EVPN-VXLAN DCI rides an IP interconnect; the underlay only needs VTEP reachability between borders. Borders exchange EVPN routes and encapsulate VXLAN over ordinary IP transport—there is no requirement that the WAN itself be an Ethernet LAN. Claiming the interconnect must be a Layer-2 metro E-LAN or else VXLAN DCI cannot function invents a false underlay constraint and often pushes cities toward brittle stretched VLANs. VXLAN overlays do not require MPLS labels on every WAN hop in addition to UDP; VXLAN is UDP/IP encapsulation and can traverse IP-routed metros without MPLS. Plain IP underlays do not forbid EVPN sessions or force only static tunnels; BGP EVPN commonly runs between borders over IP reachability. Exam caveat: underlay = IP reachability to remote VTEPs; overlay = EVPN + VXLAN—do not demand L2 WAN or MPLS as mandatory for EVPN-VXLAN DCI. Operational check: traceroute and ping between municipal border VTEP addresses across the IP metro, confirm EVPN sessions up, then capture UDP 4789 for a tenant flow; if VTEP ping fails, fix underlay before blaming EVPN configuration.