On QFX leaves in a city EVPN-VXLAN fabric, what Junos construct is primarily used to separate tenant Layer 3 tables for multitenancy?
Select an answer to reveal the explanation.
Short Explanation
Routing instances are the Junos apartment doors for tenant L3. Each agency gets its own instance/table instead of everyone crashing in inet.0. Filters help, clusters help HA—but they are not the multitenancy construct the blueprint is pointing at.
Full Explanation
On QFX leaves in a city EVPN-VXLAN fabric, the Junos construct primarily used to separate tenant Layer 3 tables for multitenancy is routing instances that provide per-tenant VRFs and independent routing tables. Each agency gets its own apartment door and map book instead of everyone crashing in inet.0, which is how municipal overlays keep route policy and overlapping space sane.
A single bridge-domain with overlapping IRB addresses for every agency confuses L2 constructs with L3 table separation and invites conflict. Chassis clustering alone without any per-tenant routing context is an HA feature, not multitenancy. Only firewall filter terms in the underlay inet.0 table can filter packets but do not create independent tenant routing tables.
Exam caveat: when the stem asks what separates tenant L3 tables, answer routing instances/VRFs—not HA, not filters-alone, not one bridge-domain.
Operational check: show routing-instance configuration per agency, display independent route tables, and verify a Parks prefix installs only in the Parks instance after EVPN convergence. Confirm EVPN routes for Parks install only under the Parks instance table on multiple leaves, not merely on the leaf where you configured it.