VLAN per Tenant: Design, Limits and When to Add VRFs

A VLAN per tenant gives each occupier, department or customer its own Layer 2 broadcast domain, usually with its own subnet and its own SSID on wireless. It is a sound starting point for shared workspaces, student accommodation, mixed-use developments and multi-occupier campuses. On its own, though, a VLAN only draws the boundary. Isolation is delivered by what you attach to it: a dedicated subnet, a routing domain, firewall policy at the gateway, hardened trunks and regular audits.

This guide is written for IT directors and operations managers who need to separate tenants on shared infrastructure. It covers how the design works, how to plan it, where it stops scaling and how to check that it is not leaking.

TL;DR

• A VLAN per tenant separates broadcast traffic. Add a unique subnet, a gateway with access control and, where isolation matters, a VRF per tenant.
• The 802.1Q VLAN ID field allows 4094 usable VLANs. Plan ID ranges per tenant early, especially across multiple sites.
• Most leaks come from trunk and native VLAN misconfiguration, not from the VLAN concept itself. Restrict allowed VLANs on every trunk.
• Beyond a few thousand segments, or where tenants choose their own VLAN IDs, move to an overlay such as VXLAN.
• Audit the design after every change, and before every new tenant is onboarded.

Table of Contents

• What a VLAN per tenant actually means
• Where a VLAN per tenant fits best
• How to plan the design
• What UK guidance says about shared networks
• Hardening the design against leakage
• Scaling limits of a VLAN per tenant
• Testing and monitoring a tenant design
• Perspective
• Getting the design right with Re-Solution
• FAQ
• Sources

What a VLAN per tenant actually means

In a basic design, each tenant receives one VLAN ID, for example VLAN 100 for tenant A and VLAN 200 for tenant B. Each VLAN maps to its own IP subnet. Ports and SSIDs for that tenant are placed in that VLAN, and a Layer 3 gateway (a switch SVI or a firewall interface) routes between the tenant and the outside world.

The model has three layers:

1. Layer 2 separation. Devices in different VLANs cannot exchange frames directly, so broadcasts and ARP stay inside the tenant.
2. Layer 3 boundary. Traffic between VLANs must pass through a gateway, which is where you apply policy.
3. Policy. Access control lists or firewall rules decide what each tenant can reach: usually the internet and shared services, never another tenant.

A documented multi-tenant example from a firewall configuration guide follows exactly this pattern: a unique VLAN tag and a separate subnet for each tenant, DHCP per tenant, and block rules on each tenant interface that stop inter-tenant traffic while still allowing internet access. The principle applies to any platform, including Cisco Catalyst, Meraki and Cisco-managed firewalls.

If a tenant needs several internal networks, such as staff, guest and IoT, the design becomes a VLAN group per tenant rather than a single VLAN. That is where numbering discipline starts to matter.

Where a VLAN per tenant fits best

The approach suits environments where tenants share physical switching and cabling but must not share a network:

• Shared workspaces and serviced offices. Each member company gets a private network, while meeting rooms and printers sit in shared VLANs.
• Student accommodation and housing. Each flat or block is isolated, with a common management VLAN. Our guide on Wi-Fi surveys for UK student accommodation covers the radio side of the same problem.
• Multi-occupier campuses and business parks. Landlord services (access control, CCTV, building systems) are kept apart from occupier traffic.
• Hospitality. Guest, staff, payment and building-management networks are separated, often per venue or per franchise.
• Logistics and warehousing. Third-party operators in a shared facility each need their own segment.

For building systems that sit alongside tenant networks, read our BMS network segmentation guide. Operational technology and industrial sites have their own rules, covered in OT network segmentation.

How to plan the design

1. Decide the unit of isolation

A tenant may be a company, a floor, a flat or a department. Decide this before allocating anything. Changing the unit later means renumbering VLANs, subnets and firewall policy.

2. Reserve ID and address blocks

Give each tenant a predictable block, for example 20 VLAN IDs per tenant and a /22 of address space. Reserve a separate range for shared services and a separate one for management. Predictable numbering makes audits quicker and reduces the risk of duplicated IDs when sites are merged.

Keep VLAN 1 unused for tenant traffic, and avoid using any tenant VLAN as the native VLAN on trunks.

3. Pair every VLAN with a routing domain

If all tenant VLANs terminate on the same routing table, isolation rests entirely on ACLs. One mistaken rule can connect two tenants. A VRF per tenant gives each its own routing table, so overlapping address ranges are possible and a missing route means no path, rather than relying on a deny rule being present.

This is how large multi-tenant fabrics work. In a VXLAN BGP EVPN fabric, a Layer 3 VNI identifies each tenant and is associated with a unique tenant VRF, while individual Layer 2 VLANs can carry their own Layer 2 VNI for separate segmentation. The same document notes that VLANs have only leaf-switch significance in that model, so the VLAN ID no longer has to match across the estate.

The build order matters. A sensible sequence is: create the tenant VLANs, associate them with the tenant VRF, then create the Layer 3 interfaces and policy.

4. Choose Layer 2 or Layer 3 reach

Most tenants do not need their VLAN stretched across the whole building. Where a VLAN must span several switches, Cisco’s design guidance says VLANs do not need to be connected to every VTEP and should be attached according to security, scale, traffic pattern and application requirements. Extending only where needed keeps broadcast domains small and limits the blast radius of a fault.

5. Build the wireless layer to match

Each tenant SSID maps to the tenant VLAN. More SSIDs mean more management overhead on the air, so use them sparingly and consider identity-based assignment, where one SSID places users into the right VLAN after authentication. A wireless site survey before deployment shows how many networks the space can support without hurting capacity.

What UK guidance says about shared networks

For shared offices, the UK Government Digital Service has published guidance on sharing workplace wireless. It asks for wifi networks to be separated, using separate VLANs at the access point or separation at a central point, with separate IP addressing, routing and access controls for each network, and with wifi clients isolated from one another.

The same page sets two points that apply well beyond government. Security measures must prevent access to other VLANs, including through dynamic trunking. And VLANs should not be spanned between shared and non-shared switches unless detailed agreements exist to share a spanning tree instance safely and contain the effect of a broadcast storm.

The guidance also recommends, for shared buildings, a single wifi infrastructure managed by an integrated controller, with different organisational needs met through multiple VLANs and SSIDs. The reasoning is radio efficiency: one controller can manage spectrum across the space, whereas separate systems need pre-surveying, agreed frequency bands and power levels and manual radio settings. The guidance dates from 2016, so treat it as a design principle and check it against your own risk assessment.

Hardening the design against leakage

VLAN separation fails in predictable places. These are the controls to build in from the start.

A native VLAN mismatch deserves particular attention because it is quiet. Untagged traffic can land in the wrong VLAN with no visible fault, so a device may appear in a different tenant’s address range or log mismatch warnings on the switch. Matching native VLANs at both ends, listing allowed VLANs explicitly and auditing regularly closes most of this exposure.

Where a tenant needs isolation between its own devices, as in student rooms or hotel bedrooms, private VLANs add port-level separation inside one subnet. Cisco’s own definition of the feature is documented in RFC 5517 on private VLANs, which also restates the 802.1Q limit of 4094 usable VLAN IDs.

Scaling limits of a VLAN per tenant

The VLAN ID is a 12-bit field. That gives a theoretical maximum of 4094 usable VLANs, because IDs 0 and 4095 are reserved. In a single office or campus that is rarely the constraint. The practical limits arrive sooner:

• Multiple VLANs per tenant. A tenant with staff, guest, voice, IoT and printer networks uses five IDs, so 800 tenants would exhaust the space. The IETF notes in its VXLAN draft that multiple VLANs per tenant make the 4094 ceiling worse for multi-tenant data centres.
• Duplicate IDs. The same draft points out that when tenants assign their own MAC addresses and VLAN IDs independently, duplication on the physical network becomes possible. In a managed building, the landlord or provider must therefore control ID allocation.
• Spanning tree and broadcast scope. Large Layer 2 domains carry more risk. Keep tenant VLANs as local as the use case allows.
• Operational load. Each VLAN is another object to configure on every trunk, document and audit.

Overlay networks remove the numeric ceiling. Cisco’s deployment guide for VXLAN fabrics states that VXLAN allows up to 16 million unique network identifiers compared with the 4094 of traditional VLANs. The same guide describes Q-in-Q tagging, in which a customer tag and a provider tag let a provider carry several customers’ VLANs over a shared backbone while keeping them isolated.

The OpenStack security guide gives a useful rule of thumb: if a deployment intends to support more than 4094 tenants, VLAN is probably not the right option, and L2 tunnelling such as VXLAN suits environments with many Layer 2 networks or limited VLAN ID availability.

When VLANs are enough, and when to go further

For multiple sites, a consistent numbering scheme is the main discipline. Our note on multi-site VPN design explains how tenant segments are carried between locations, and network solutions explained gives the wider picture of how access, wireless and WAN layers fit together.

Testing and monitoring a tenant design

A design that looks correct on a diagram can still leak. Build verification into delivery and operations.

1. Before go-live: from a test device in each tenant VLAN, confirm that it receives an address from the correct subnet, reaches only permitted services and cannot ping or scan another tenant’s range or the management VLAN.
2. Trunk review: export the configuration of every trunk and compare allowed VLAN lists and native VLANs at both ends.
3. Logging: forward switch logs to a central system and alert on native VLAN mismatch messages, unexpected MAC address moves and DHCP snooping violations.
4. Change control: every new tenant follows the same template, so the build is repeatable and reviewable.
5. Periodic audit: review VLAN, VRF and policy configuration on a schedule, and after any significant change to switching or firewalls.

Our network audit checklist sets out how to evidence each finding, and the firewall audit checklist covers the rules that sit at the tenant gateway. Where tenants handle card data, the PCI network segmentation guide explains what assessors expect to see.

Perspective

Across 35 years of working with Cisco infrastructure, we have seen that tenant separation rarely fails because the technology cannot do it. It fails because the design was never written down.

Our view is simple. Treat the VLAN as the first layer, not the whole answer. Give every tenant its own address block, its own routing context where the risk justifies it, and a gateway policy that denies by default. Then carry that discipline into operations: fixed numbering, explicit trunk lists, and an audit after every change.

For multi-site and multi-occupier estates, we favour cloud-managed Cisco networking with a consistent template for every tenant, because it makes the design repeatable and visible. A managed service or Network as a Service model then keeps that template enforced over time, rather than leaving it to drift as people come and go.

Jacob

Getting the design right with Re-Solution

Re-Solution designs, audits and runs Cisco networks for education, manufacturing, logistics, hospitality, shared workspaces and property developers. If you are planning a tenant-separated network, or you inherited one and want to know whether it is isolated, a network audit reviews VLANs, trunks and policy against what you intended to build. We can then run the result for you through our managed services, or deliver it as a subscription through Network as a Service.

To discuss a specific building or campus, get in touch with our team.

FAQ

Is a VLAN per tenant secure enough on its own?

A VLAN separates tenants at Layer 2, but security comes from the controls around it. You need a dedicated subnet, default-deny policy at the gateway, hardened trunks with explicit allowed VLAN lists and no dynamic trunking. For stricter separation, add a VRF per tenant.

How many tenants can a VLAN design support?

The 802.1Q standard allows 4094 usable VLAN IDs, and each tenant often needs more than one. Most single buildings and campuses stay well within that. Estates with hundreds of tenants, or with tenants that set their own IDs, are better served by an overlay such as VXLAN.

Should each tenant have its own SSID?

Often yes for a small number of tenants, with each SSID mapped to the tenant VLAN. Many SSIDs add airtime overhead, so for larger buildings consider identity-based VLAN assignment, where users authenticate on a common SSID and are placed into their tenant segment.

What is the difference between a VLAN and a VRF?

A VLAN is a Layer 2 broadcast domain. A VRF is a separate Layer 3 routing table. Used together, each tenant has its own broadcast domain and its own routes, so tenants can reuse address ranges and cannot reach each other without a deliberate, controlled path.

How often should a tenant network be audited?

Audit before onboarding a new tenant, after any change to switching, trunks or firewall rules, and on a regular schedule agreed with your security or compliance owner. Regular audits are the main way to catch native VLAN mismatches and stray allowed-VLAN entries.

Sources

• Cisco Programmable Fabric with VXLAN BGP EVPN: multi-tenancy
• Cisco Nexus 9000 VXLAN BGP EVPN design and implementation guide
• Cisco Q-in-VNI over VXLAN fabric deployment guide
• GOV.UK: Sharing workplace wireless networks
• IETF draft-ietf-nvo3-rfc7348bis-06
• RFC 5517: Cisco Systems’ Private VLANs
• OpenStack Security Guide: Networking services
• pfSense network recipes: multi-tenant VLAN isolation

Recommended

• Validation First IoT VLAN Checklist for Network Engineers (35 Years)
• Network Architects: Standards Backed Multisite VPN Design
• SD-Access Design: A Planning Guide for UK Network Teams
• Cisco SD-WAN Design: Three Decisions Before Rollout