Under an ERB design, where should a tenant's IRB interface be placed for correct multitenancy?
Select an answer to reveal the explanation.
Short Explanation
IRB is the tenant's front desk—it has to sit inside that tenant's routing instance. Park it in inet.0 or a shared junk drawer and the gateway starts answering for the wrong agency. ERB still means the leaf does routing, but routing for the right VRF.
Full Explanation
Under an ERB design, a tenant's IRB interface should be placed in that tenant's routing instance or VRF so gateway functions stay in the correct L3 context. The anycast or distributed gateway for Parks must live in the Parks table; otherwise ARP and routed east-west land in the wrong civic context and isolation breaks at the gateway attachment point.
Placing the IRB only in the underlay loft instance used for iBGP to spines mixes overlay gatewaying with underlay control. Putting IRBs in inet.0 on every leaf regardless of tenant ownership collapses multitenancy. A shared nonforwarding instance that holds all agencies together fails both forwarding and isolation goals.
Exam caveat: ERB + multitenancy ⇒ IRB membership in the tenant instance is a classic binding question.
Operational check: show IRB unit assignment under the correct routing-instance, ping the gateway from a tenant host, and confirm ARP/route lookups occur in that tenant table only after convergence. Validate anycast IRB consistency across ERB leaves for that tenant only, and ensure no IRB unit remains attached under master by mistake. Retain before-and-after show commands in the change ticket so the municipal NOC can prove the isolation or steering outcome without relying on memory.