Ops sees EVPN Type-2 MAC/IP routes on a city leaf but still claims the VXLAN MAC control plane is OSPF. Which correction is accurate?
Select an answer to reveal the explanation.
Short Explanation
Two phone books, two jobs: OSPF (or underlay BGP) gets packets to leaf loopbacks, and EVPN hands out the MAC/IP bindings for the overlay. An EVPN Type-2 is not an OSPF LSA with a costume on. If you see Type-2 routes, you are looking at the overlay control plane doing its real work.
Full Explanation
When ops sees EVPN Type-2 MAC/IP routes on a city leaf but still claims the VXLAN MAC control plane is OSPF, correct the model: OSPF or another underlay IGP/BGP provides VTEP IP reachability across the leaf-spine fabric, while EVPN is the overlay control plane that distributes MAC/IP bindings for VXLAN. Both layers must be healthy for end-to-end tenant connectivity; they solve different problems.
OSPF Type-2 LSAs are not identical to EVPN Type-2 routes and do not replace MP-BGP for MAC/IP distribution. Seeing EVPN Type-2 does not prove OSPF has been disabled or that the underlay no longer needs IP routing to VTEP loopbacks. VXLAN in EVPN fabrics does use a MAC/IP control plane; static ARP entries on spines are not the only valid learning model.
Exam caveat: underlay routes VTEP IPs; EVPN routes tenant MAC/IPs—do not equate OSPF LSA type numbers with EVPN route type numbers.
Operational check: show the underlay route to a remote VTEP loopback and separately show EVPN Type-2 for a tenant MAC; fail each layer in a lab window and observe which distinct symptom class appears for civic workloads.
In civic fabric operations, retain the correct idea—OSPF (or another underlay IGP/BGP) provides VTEP IP reachability, while EVPN is the overlay control plane that distributes MAC/IP bindings for VXLAN—and reject distractors that confuse layers or tools. Specifically, do not treat “OSPF Type-2 LSAs are identical to EVPN Type-2 routes and replace MP-BGP entirely.” as valid, do not accept “Seeing EVPN Type-2 proves OSPF has been disabled and the underlay no longer needs IP routing.” as a substitute design, and do not operationalize “VXLAN never uses a MAC control plane; only static ARP entries on spines are valid.” 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.