An engineer configures the municipal interconnect overlay but sources VXLAN from the wrong VTEP address on the DCI-facing device. What is the likely result?
Select an answer to reveal the explanation.
Short Explanation
VXLAN cares which address you claim as the tunnel endpoint—like putting the wrong return address on every package. If the DCI device sources from the wrong VTEP, remote borders will not line up with what EVPN advertised. Fix the VTEP identity on the interconnect overlay.
Full Explanation
If an engineer configures the municipal interconnect overlay but sources VXLAN from the wrong VTEP address on the DCI-facing device, remote borders expect the configured VTEP and a wrong source breaks consistent VXLAN encapsulation and reachability for the DCI overlay. EVPN next-hops and VXLAN tunnel endpoints must agree; a mismatched source means remote sites send to an address that does not own the overlay or drop frames that fail reverse-path expectations. EVPN will not rewrite the source VTEP automatically based on the remote site’s RD—RDs uniquify routes, they do not fix encapsulation sources. Any interface IP on the box is not equally valid as a VTEP source for all overlays; VTEP addressing must match the advertised EVPN next-hop and underlay reachability plan. Wrong VTEP sources are not limited to LLDP side effects; they directly impact UDP 4789 paths and tenant connectivity. Exam caveat: VTEP source consistency is a first-class DCI correctness requirement—RD myths and “any IP works” are traps. Operational check: compare the EVPN next-hop/VTEP advertised by the municipal border with the actual VXLAN source used in encapsulation, ping that address from the remote border, correct the VTEP/loopback binding, and retest tenant flows with a capture showing the expected outer IPs.