City fabric engineers map each agency to a Junos routing instance used as a tenant VRF on EVPN-VXLAN leaves. Which instance approach best matches common DC tenant separation at describe depth?
Select an answer to reveal the explanation.
Short Explanation
Pick the instance type that actually gives each agency its own routing brain—virtual-router/VRF-style patterns—not cosmetic renames on the master instance. If everything still lands in inet.0, you renamed the hallway signs but kept one hallway.
Full Explanation
City fabric engineers who map each agency to a Junos routing instance used as a tenant VRF on EVPN-VXLAN leaves should use appropriate routing-instance types such as virtual-router or VRF patterns for each agency tenant. At describe depth, the point is a real per-tenant forwarding/routing context—not a cosmetic rename of the master instance—so each civic department keeps an independent table.
Putting every agency in forwarding-only instances with no routing table at all fails tenants that must route and exchange overlay routes. Reusing the default master instance for all agencies and renaming interfaces only collapses isolation into one table. Configuring one nonforwarding routing instance and attaching every IRB to inet.0 likewise keeps forwarding in the shared default context.
Exam caveat: know that tenant separation needs an instance type that actually provides a tenant routing table aligned to the EVPN/VRF service model.
Operational check: confirm each agency uses a suitable routing-instance type with its own table, IRBs attached to that instance, and EVPN service association—not merely renamed units in master. Cross-check that automation templates stamp the same instance type and tenant ID on every leaf that hosts that agency.