The city enables VXLAN on access devices that cannot speak EVPN while the leaf standard expects EVPN signaling. What problem does that create?
Select an answer to reveal the explanation.
Short Explanation
Turning on VXLAN UDP is not the same as speaking EVPN. If the city’s standard is EVPN and the box only does flood-and-learn or static tunnels, you have a capability mismatch, not a self-upgrading miracle. Plan for the control plane the platform actually supports—or change the platform.
Full Explanation
When the city enables VXLAN on access devices that cannot speak EVPN while the leaf standard expects EVPN signaling, a capability mismatch appears: those devices cannot participate in the EVPN MAC/IP control plane and must use another supported model such as static or multicast flood-and-learn, or be replaced or redeployed to meet the standard. VXLAN data-plane encapsulation and EVPN control-plane participation are related but distinct capabilities.
It is not true that any VXLAN-capable chipset always speaks every control plane automatically. Devices without EVPN will not originate Type-2 routes using LLDP as a substitute protocol. Non-EVPN VTEPs do not automatically upgrade their control plane when they see UDP port 4789 on the wire.
Exam caveat: qualify platforms for the chosen control plane—EVPN versus flood-and-learn or static—before municipal rollout to avoid mixed learning models and operational blind spots.
Operational check: inventory VTEP control-plane capabilities, move non-EVPN devices onto an approved alternate model or refresh them, and verify EVPN leaves consistently import MAC/IP only from peers that actually speak EVPN.
In civic fabric operations, retain the correct idea—A capability mismatch appears: those devices cannot participate in the EVPN MAC/IP control plane and must use another supported model (such as static/multicast flood-and-learn) or be replaced/redeployed to meet the standard—and reject distractors that confuse layers or tools. Specifically, do not treat “No problem—any VXLAN-capable chipset always speaks every control plane automatically.” as valid, do not accept “Devices without EVPN will originate Type-2 routes using LLDP as a substitute protocol.” as a substitute design, and do not operationalize “Non-EVPN VTEPs automatically upgrade their control plane when they see UDP port 4789.” in production runbooks. Re-validate after changes with show commands for sessions, routes, VTEP reachability, and a simple tenant traffic test appropriate to the VNI under review.