> ## Content Index > Fetch the complete content index at: https://www.pinglabz.com/llms.txt > Use this file to discover other available public pages before exploring further. # VLAN Design for Campus Networks: From Access to Core - URL: https://www.pinglabz.com/vlan-design-campus-network/ - Published: 2026-04-01T06:31:22.000Z - Updated: 2026-07-04T23:21:44.000Z - Description: A good VLAN design scales cleanly, keeps STP domains small, and makes troubleshooting obvious. Here is how to plan VLANs for a multi-building campus network. - Author: Jaime - Tags: VLAN, #Import 2026-08-01 19:54 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. For where this topic sits in the wider picture, see the [VLAN complete guide](https://www.pinglabz.com/vlans-layer-2-switching/). 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:** User/data Recommended Size/24 (254 hosts) Rationale Covers a typical floor or department. ARP and DHCP traffic stays manageable. Server Recommended Size/24 or /25 Rationale Servers are fewer and more predictable. Smaller subnets reduce blast radius. Management Recommended Size/24 per building Rationale One management VLAN per distribution block. Switches and APs only. Voice Recommended Size/24 per building Rationale Mirrors the user VLAN scope. One phone per desk = similar device count. Guest Recommended Size/24 or /23 Rationale Depends on guest density. Conference rooms and lobbies drive the count. 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:** 10–19 PurposeBuilding A user VLANs Example 10=Users-A, 11=Users-A-East 20–29 Purpose Building A server/infra VLANs Example20=Servers-A 30–39 PurposeBuilding A management Example30=Mgmt-A 40–49 PurposeBuilding A voice Example40=Voice-A 50–59 PurposeBuilding A guest Example50=Guest-A 99 Purpose Native VLAN (all buildings) Example99=Native 110–159 Purpose Building B (same pattern) Example 110=Users-B, 140=Voice-B 210–259 PurposeBuilding C Example 210=Users-C, 240=Voice-C 900–999 PurposeSpecial purpose Example999=Parking 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](https://www.pinglabz.com/voice-vlan-cisco-configuration/) 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](https://www.pinglabz.com/tag/802-1x/). ## 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](https://www.pinglabz.com/tag/spanning-tree-protocol/). ## 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) Users-BldgA VLAN10 Subnet10.10.10.0/24 PurposeUser workstations Servers-BldgA VLAN20 Subnet10.10.20.0/24 PurposeServer farm Mgmt-BldgA VLAN30 Subnet10.10.30.0/24 PurposeSwitch/AP management Voice-BldgA VLAN40 Subnet10.10.40.0/24 PurposeIP phones Guest-BldgA VLAN50 Subnet10.10.50.0/24 PurposeGuest Wi-Fi/wired ### Building B Users-BldgB VLAN110 Subnet10.10.110.0/24 PurposeUser workstations Mgmt-BldgB VLAN130 Subnet10.10.130.0/24 PurposeSwitch/AP management Voice-BldgB VLAN140 Subnet10.10.140.0/24 PurposeIP phones Guest-BldgB VLAN150 Subnet10.10.150.0/24 PurposeGuest Wi-Fi/wired ### Building C Users-BldgC VLAN210 Subnet10.10.210.0/24 PurposeUser workstations Mgmt-BldgC VLAN230 Subnet10.10.230.0/24 PurposeSwitch/AP management Voice-BldgC VLAN240 Subnet10.10.240.0/24 PurposeIP phones Guest-BldgC VLAN250 Subnet10.10.250.0/24 PurposeGuest Wi-Fi/wired ### Campus-Wide Native VLAN99 SubnetN/A Purpose Trunk native VLAN (no IP) Parking VLAN999 SubnetN/A PurposeUnused ports (no IP) 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](https://www.pinglabz.com/vlan-security-best-practices/). For STP design that complements your VLAN architecture, see the [STP series](https://www.pinglabz.com/tag/spanning-tree-protocol/). Build this yourself, on real gear The PingLabz lab library: 74 hands-on labs on real Cisco IOS XE in Cisco Modeling Labs. Seven are free, no card required. [Browse the labs](https://www.pinglabz.com/labs/)