Network Virtualization and Multitenancy
Isolation needs to exist in both planes
Multitenancy starts with VRFs. Each tenant gets its own VRF (and usually its own VNI), so overlapping address space is fine - 10.0.0.0/24 can exist in three tenants because the VRF, not the prefix, is the identity. In EVPN designs each VRF maps to an L3 VNI and each tenant VLAN maps to an L2 VNI. Route distinguishers must be unique per VRF per VTEP; route targets define which VRFs import which routes, so a missing or asymmetric RT is the classic cause of a cross-tenant leak or a black hole.
Design patterns
- Per-tenant VRF plus L3VNI, with a shared or dedicated border leaf for external connectivity.
- Deliberate route leaking between VRFs for shared services (DNS, DHCP, NTP) using explicit import/export targets - never through the default VRF.
- Overlay edge: firewalls or load balancers attached as a service VRF/VLAN, or a border leaf that also faces the WAN.
- Management and out-of-band traffic in their own VRF, never inside a tenant VRF.
Traps
- Assuming a VLAN number isolates tenants; isolation comes from VNI/VRF separation.
- Reusing a route distinguisher across VRFs, which breaks uniqueness and can silently overwrite routes.
- Leaking a default route into tenant VRFs and calling it shared services.
- Forgetting DHCP relay and DNS per VRF, so tenants get addresses but no name resolution.
- Stretching a tenant's Layer 2 across sites without an EVPN control plane.
Rule of thumb
Say it out loud: one tenant = one VRF + one L3VNI + a set of L2 VNIs + a unique RD + explicit RTs. If any element is shared with another tenant, isolation depends on policy rather than architecture.