Ops incorrectly associates VXLAN with an IRB on a municipal leaf and routed tenant traffic breaks. What configuration caution applies?
Select an answer to reveal the explanation.
Short Explanation
IRB is the doorway between the L2 room and the L3 hallway—hang it on the wrong wall and nobody routes. Tie IRB to the right bridge domain and L3 VNI, don’t just sprinkle VXLAN keywords nearby. Mis-hung doorways are a classic leaf foot-gun.
Full Explanation
If ops incorrectly associates VXLAN with an IRB on a municipal leaf and routed tenant traffic breaks, the configuration caution is that IRB must be integrated correctly with the L2 and L3 VNIs so gateway and overlay routing functions align. Incorrect VXLAN-on-IRB associations can black-hole gateway traffic even when pure L2 VNI bridging still looks partially alive.
IRB must not be banned from every EVPN-VXLAN fabric—inter-subnet overlay needs it. VXLAN should not be applied only on spine loopbacks and never on leaves with hosts; leaves hosting endpoints are where IRB/VXLAN integration matters. Disabling all VNIs and bridging only in the underlay default instance is not the preferred fix.
Exam caveat: repair the IRB binding model; do not abandon multitenant overlay design because one association was wrong.
Operational check: verify IRB is bound to the correct L2 segments and participates with the correct L3 VNI/routing instance; test gateway ICMP and inter-subnet flows after correcting the association. Separate L2-only validation from IRB/L3 validation in the municipal test plan. Peer-review IRB/VXLAN stanzas before change windows that touch gateway leaves. Record the validated outcome in the municipal fabric runbook for the next change window.