A tenant routing instance on a municipal leaf must advertise and learn overlay routes for its VNI. What binding is required?
Select an answer to reveal the explanation.
Short Explanation
The tenant instance is the agency office; EVPN/VNI association is the intercom that publishes who lives there. Without that binding, the instance is a lonely room that never talks overlay. Do not shove tenant routes into OSPF underlay area 0 as a shortcut.
Full Explanation
A tenant routing instance on a municipal leaf must advertise and learn overlay routes for its VNI by associating the tenant routing instance with the correct EVPN/VNI service so overlay routes import and export properly. Without that binding, the instance is an empty filing cabinet disconnected from the fabric’s EVPN control plane for that tenant, and civic workloads will not learn remote MAC/IP or Type-5 state as intended.
Exporting the tenant instance only into the underlay OSPF area 0 database pushes tenant routes into the wrong plane and does not establish overlay EVPN service membership. Disabling EVPN on that leaf and relying on static VXLAN flood lists alone abandons the scalable control plane the design assumes. Mapping the tenant instance exclusively to the management Ethernet VRF mixes OOB management with tenant overlay routing.
Exam caveat: tenant instance ↔ EVPN/VNI service association is a frequent “why isn’t my Type-2/Type-5 showing up” root cause.
Operational check: verify routing-instance to EVPN/VNI configuration, confirm import/export RTs, and check that tenant EVPN routes appear in the correct instance table on peer leaves. If remote Type-2/Type-5 are missing, first diff the EVPN service binding and RTs before blaming underlay ECMP or MTU.