VLAN Design for Campus Networks: From Access to Core

Individual VLAN configuration is straightforward — the hard part is deciding which VLANs to create, where they should exist, and how they should be numbered before you type a single command. A poor VLAN design creates sprawling STP domains, oversized broadcast domains, confusing IP schemes, and troubleshooting nightmares that compound with every new switch you add. A good design scales cleanly, keeps failure domains small, and makes the network self-documenting.

This article distills VLAN design principles for campus networks — from a single-building office to a multi-building campus — using the PingLabz Switching Lab as the starting point and scaling it up.

Principle 1: Local VLANs, Not End-to-End VLANs

The single most important VLAN design decision is whether VLANs span the entire campus (end-to-end) or are contained to a specific location (local).

End-to-end VLANs stretch a single VLAN across every access switch in every building. A user in Building A VLAN 10 is in the same broadcast domain as a user in Building C VLAN 10. This was the design pattern in the 1990s and early 2000s, driven by the need for mobile users to keep their IP address when moving between buildings.

Local VLANs confine each VLAN to a single distribution block (one building or one floor). Building A has VLAN 10 (10.10.10.0/24) and Building B has VLAN 110 (10.10.110.0/24) — different VLANs, different subnets, each locally contained.

Local VLANs won, and for good reason:

• Smaller STP domains. End-to-end VLANs mean STP runs across the entire campus for each VLAN. A single misconfigured port in Building C can take down VLAN 10 in Building A. Local VLANs keep STP contained to one distribution block.
• Smaller broadcast domains. A broadcast in a local VLAN stays within one building. End-to-end VLANs broadcast everywhere.
• Simpler troubleshooting. If VLAN 10 has a problem, you know it is in Building A. With end-to-end VLANs, you are searching the entire campus.
• Easier scaling. Adding a new building means adding new VLANs with new subnets. No risk of breaking existing VLANs.

The objection — "users need the same IP when they move" — is solved by DHCP. Modern networks assign IPs dynamically, and applications use DNS names, not static IPs. If you genuinely need IP mobility (rare), use protocols like LISP or VXLAN, not stretched VLANs.

[DIAGRAM: Left side shows "End-to-End VLANs" — VLAN 10 spanning three buildings with one massive STP domain. Right side shows "Local VLANs" — VLAN 10 in Building A, VLAN 110 in Building B, VLAN 210 in Building C, each with independent STP domains. Routing between buildings at the core layer.]

Principle 2: Size Your Subnets to Your VLANs

Each VLAN maps to one IP subnet. Subnet size directly affects broadcast domain size, DHCP scope management, and IP address utilization.

Guidelines for subnet sizing:

Avoid /16 or /22 VLANs for user traffic. A /22 puts 1,022 devices in one broadcast domain — every ARP request hits all 1,022 devices, ARP tables grow large, and a single misbehaving device (broadcast storm, malware scanning) affects everyone.

If a floor has more than 254 users, split it into two VLANs (e.g., VLAN 10 for the east wing, VLAN 11 for the west wing) rather than expanding to a /23.

Principle 3: VLAN Numbering Convention

A consistent numbering scheme makes the network self-documenting. When you see VLAN 210 in a show vlan output, you should immediately know what it is.

Recommended scheme:

The pattern: building prefix + function. Building A uses the 1x–5x range, Building B uses 11x–15x, Building C uses 21x–25x. Voice is always x40, management is always x30, guest is always x50. Anyone looking at a VLAN number can decode the building and function without checking documentation.

Name your VLANs descriptively too:

CORE-SW1(config)# vlan 110
CORE-SW1(config-vlan)# name Users-BldgB-Floor1

Principle 4: Management VLAN Strategy

The management VLAN carries SSH, SNMP, syslog, and NTP traffic to and from switch SVIs. It requires special treatment:

Separate from data VLANs. Never use VLAN 1 or a user VLAN for management. A broadcast storm in the user VLAN should not lock you out of the switch.

One management VLAN per distribution block. Building A switches use VLAN 30 (10.10.30.0/24), Building B switches use VLAN 130 (10.10.130.0/24). This keeps management traffic local and provides clear IP-to-location mapping.

ACL-protected. Only your NOC subnet should be able to SSH to management SVIs. Apply an ACL to the VTY lines:

ACC-SW1(config)# ip access-list standard MGMT-ACCESS
ACC-SW1(config-std-nacl)# permit 10.10.30.0 0.0.0.255
ACC-SW1(config-std-nacl)# permit 10.10.130.0 0.0.0.255
ACC-SW1(config-std-nacl)# deny any log
ACC-SW1(config-std-nacl)# exit
ACC-SW1(config)# line vty 0 15
ACC-SW1(config-line)# access-class MGMT-ACCESS in

Principle 5: Voice VLAN Strategy

Every building with IP phones needs a voice VLAN. The voice VLAN should:

• Mirror the user VLAN scope (per building or per floor).
• Be included in QoS policies end-to-end (access to core).
• Have DHCP scopes that include the call manager (CUCM) address as DHCP Option 150.
• Have the SVI on the core/distribution switch with ip helper-address pointing to the DHCP server.

See Configuring Voice VLANs on Cisco Switches for IP Phones for the port-level configuration.

Principle 6: Guest VLAN Isolation

Guest traffic must be isolated from internal networks. Design requirements:

Separate VLAN per building — VLAN 50 (Building A), VLAN 150 (Building B).

No inter-VLAN routing to internal VLANs. The guest VLAN SVI should only have a route to the internet, not to internal subnets. Use an ACL on the guest SVI:

CORE-SW1(config)# ip access-list extended GUEST-RESTRICT
CORE-SW1(config-ext-nacl)# permit ip 10.10.50.0 0.0.0.255 any
CORE-SW1(config-ext-nacl)# deny ip 10.10.50.0 0.0.0.255 10.0.0.0 0.255.255.255
CORE-SW1(config-ext-nacl)# permit ip any any
CORE-SW1(config-ext-nacl)# exit
CORE-SW1(config)# interface Vlan50
CORE-SW1(config-if)# ip access-group GUEST-RESTRICT in

Alternatively, route guest traffic to a dedicated firewall context or WLC guest anchor. For 802.1X-based guest VLAN assignment, see the 802.1X series.

Principle 7: Keep STP Domains Small

Every VLAN runs its own STP instance (in Rapid PVST+ mode). The more switches a VLAN spans, the larger the STP domain and the greater the impact of a topology change.

Concrete guidance:

• A VLAN should not span more than one distribution block (one pair of distribution switches and their downstream access switches).
• If using Rapid PVST+, limit each VLAN to 20–30 switches maximum. Beyond that, STP convergence times increase and the risk of loops from misconfiguration grows.
• Use MST (Multiple Spanning Tree) if you have many VLANs — it maps multiple VLANs to a single STP instance, reducing STP overhead without requiring per-VLAN tuning.

For STP design and root bridge placement, see the STP series.

Principle 8: The Routed Access Layer

The most modern campus design eliminates VLANs between access and distribution entirely. Instead of Layer 2 trunks between ACC-SW1 and DIST-SW1, you use routed (Layer 3) point-to-point links. VLANs exist only on the access switch — between the access ports and the local SVIs.

Advantages:

• STP is eliminated on uplinks (they are routed, not switched).
• VLAN scope is limited to a single access switch.
• Convergence is handled by OSPF/EIGRP instead of STP — sub-second failover.
• No possibility of Layer 2 loops on uplinks.

Trade-off: Requires Layer 3-capable access switches (Catalyst 9200 with DNA Advantage, or Catalyst 9300). The Catalyst 9200L does not support full Layer 3 routing, so the PingLabz Switching Lab uses the traditional Layer 2 access design.

This is the direction campus networking is heading. If your switch budget allows it, routed access is the preferred design for new deployments.

Sample Design: Three-Building Campus

Expanding the PingLabz Switching Lab to a three-building campus:

Building A (PingLabz Lab)

Building B

Building C

Campus-Wide

Each building has its own distribution switches. The core layer (CORE-SW1 or a pair of core switches) routes between buildings using SVIs or routed links. VLANs never span between buildings — the core routes between them.

How Many VLANs Is Too Many?

There is no hard limit, but practical guidance:

• Under 50 VLANs per switch: No concerns. TCAM, STP instances, and CPU overhead are negligible.
• 50–200 VLANs: Workable but monitor STP convergence times and TCAM utilization. Consider MST to reduce STP instances.
• 200+ VLANs: Review your design. In a campus network, this usually indicates end-to-end VLANs or per-user VLANs — both are anti-patterns. Consider aggregation, routed access, or VXLAN for overlay needs.

The Catalyst 9300 supports up to 4,094 VLANs, but STP does not scale well past a few hundred instances. The TCAM on the 9300 handles thousands of VLANs, but each VLAN consumes entries for the SVI ARP, MAC table, and STP instance state.

Key Takeaways

• Use local VLANs confined to one distribution block — never stretch VLANs across the campus. Local VLANs keep STP domains small and failures contained.
• Size subnets at /24 for user VLANs. If you need more than 254 devices, split into two VLANs rather than expanding the subnet.
• Adopt a consistent VLAN numbering scheme: building prefix + function (10=Users-A, 110=Users-B, 40=Voice-A, 140=Voice-B).
• Isolate management, voice, and guest VLANs from user data VLANs. Apply ACLs to restrict guest traffic.
• For new deployments, consider the routed access layer design — it eliminates STP between access and distribution, confines each VLAN to a single switch, and provides sub-second convergence via routing protocols.

This is the final article in the VLANs & Layer 2 Switching series. For security hardening of the design covered here, see VLAN Security Hardening: Protecting Your Layer 2 Network. For STP design that complements your VLAN architecture, see the STP series.