Network Virtualization and Multitenancy
Domain 5 is about keeping tenants apart while letting them share one physical fabric, and about mapping the two address spaces correctly: MAC-VRFs (bridge domains, L2 VNIs) and IP-VRFs (routing instances, L3 VNIs).
Isolation mechanics
Each tenant gets a unique VNI and a unique route target. Import and export are separate: vrf-import pulls routes in, vrf-export pushes them out, so an asymmetric policy creates one-way reachability that looks like a routing bug. Overlapping 10.0.0.0/24 across tenants is fine because each lives in its own VRF table with its own L3 VNI; it is only a problem if the RTs collide.
Shared services
A hub VRF (firewall, DHCP, DNS) imports every tenant RT and exports a services RT that tenants import. That gives controlled any-to-any without leaking tenant-to-tenant routes.
Worked example
Tenant A uses 10.0.0.0/24 with VNI 10010 and RT target:65000:10010; Tenant B uses the same prefix with VNI 10020 and target:65000:10020. On the leaf, two routing instances each hold one IRB, and show route table TENANT-A.inet.0 shows only Tenant A's prefix. If you accidentally give both instances the same vrf-target, each table suddenly holds two paths for 10.0.0.0/24 and hosts intermittently land on the wrong tenant - a classic silent leak.
Traps
Same RT for two tenants, same VNI for two bridge domains, forgetting the export half of vrf-target, leaving DHCP relay unconfigured so broadcast DHCP dies at the leaf, and forgetting that a VLAN-to-VNI mapping must be consistent on every leaf that carries the tenant.