A VLAN (Virtual Local Area Network) lets you take a single physical switch — or a whole group of switches — and logically divide it into multiple separate broadcast domains, as if they were physically separate networks, without running separate cabling for each department or function.
This article focuses specifically on normal-range VLANs (1–1005) and how to make them span multiple switches, so that, for example, VLAN 10 in Building A behaves as the exact same Layer 2 network as VLAN 10 in Building B.
What Is a VLAN, Conceptually?
Physically, all your devices might be plugged into the same switch (or chain of switches). But logically, a VLAN groups switch ports into separate broadcast domains. Devices in VLAN 10 cannot directly communicate at Layer 2 with devices in VLAN 20, even if they’re plugged into the same physical switch — a router (or Layer 3 switch) is required to pass traffic between VLANs.
Analogy
Think of a large office building with one shared elevator system (the physical switch), but separate secured floors (VLANs) that require a security badge (routing) to move between them. Two people on the same floor can walk to each other’s offices freely (same VLAN = same broadcast domain), but moving to a different floor requires going through security (a router).
VLAN Ranges
| Range | Name | Notes |
|---|---|---|
| 0, 4095 | Reserved | Not usable |
| 1 | Default VLAN | Exists automatically; cannot be deleted or renamed on most switches |
| 2–1001 | Normal range | Stored in vlan.dat, supported on all switches, focus of this article |
| 1002–1005 | Reserved for legacy Token Ring/FDDI | Not typically used |
| 1006–4094 | Extended range | Requires VTP transparent mode on older platforms; supported natively on modern switches |
This article focuses on normal-range VLANs (2–1001), which is what the CCNA exam blueprint specifically references.
Step-by-Step: Configuring VLANs Spanning Multiple Switches
Topology
graph TB
subgraph SW1["Switch 1 - Building A"]
PC1["PC1 - VLAN 10"]
PC2["PC2 - VLAN 20"]
end
subgraph SW2["Switch 2 - Building B"]
PC3["PC3 - VLAN 10"]
PC4["PC4 - VLAN 20"]
end
SW1 ---|"Trunk Link (802.1Q)"| SW2The goal: PC1 (VLAN 10, SW1) should be able to communicate at Layer 2 with PC3 (VLAN 10, SW2), while remaining completely isolated from PC2 and PC4 (VLAN 20), even though all four devices share the same physical trunk link between switches.
Step 1: Create the VLANs on Both Switches
SW1(config)# vlan 10
SW1(config-vlan)# name SALES
SW1(config-vlan)# exit
SW1(config)# vlan 20
SW1(config-vlan)# name ENGINEERING
SW1(config-vlan)# exitSW2(config)# vlan 10
SW2(config-vlan)# name SALES
SW2(config-vlan)# exit
SW2(config)# vlan 20
SW2(config-vlan)# name ENGINEERING
SW2(config-vlan)# exitImportant: VLAN numbers must match across switches for devices to be considered part of the same VLAN — the VLAN name is just a label for humans and doesn’t need to match, but best practice is to keep names consistent too, to avoid confusion.
Step 2: Assign Access Ports to VLANs
On SW1:
SW1(config)# interface GigabitEthernet0/1
SW1(config-if)# switchport mode access
SW1(config-if)# switchport access vlan 10
SW1(config-if)# exit
SW1(config)# interface GigabitEthernet0/2
SW1(config-if)# switchport mode access
SW1(config-if)# switchport access vlan 20On SW2:
SW2(config)# interface GigabitEthernet0/1
SW2(config-if)# switchport mode access
SW2(config-if)# switchport access vlan 10
SW2(config-if)# exit
SW2(config)# interface GigabitEthernet0/2
SW2(config-if)# switchport mode access
SW2(config-if)# switchport access vlan 20Step 3: Configure the Trunk Link Between Switches
This is the crucial step that lets VLANs “span” multiple switches — without a properly configured trunk, VLAN 10 on SW1 and VLAN 10 on SW2 would be entirely isolated islands with no way to communicate.
SW1(config)# interface GigabitEthernet0/24
SW1(config-if)# switchport trunk encapsulation dot1q
SW1(config-if)# switchport mode trunk
SW1(config-if)# switchport trunk allowed vlan 10,20SW2(config)# interface GigabitEthernet0/24
SW2(config-if)# switchport trunk encapsulation dot1q
SW2(config-if)# switchport mode trunk
SW2(config-if)# switchport trunk allowed vlan 10,20(See the dedicated interswitch connectivity article for full trunking details, native VLAN considerations, and DTP behavior.)
How Traffic Actually Flows Across the Trunk
sequenceDiagram
participant PC1 as PC1 (VLAN 10, SW1)
participant SW1
participant SW2
participant PC3 as PC3 (VLAN 10, SW2)
PC1->>SW1: Untagged frame (access port)
SW1->>SW1: Tag frame with VLAN 10 (802.1Q)
SW1->>SW2: Tagged frame sent across trunk
SW2->>SW2: Read VLAN tag, strip it
SW2->>PC3: Untagged frame delivered (access port, VLAN 10)Notice that the 802.1Q tag only exists on the trunk link itself. The end devices (PC1 and PC3) never see or generate tags — tagging is purely a switch-to-switch mechanism.
Verification Commands
show vlan brief
Confirms VLANs exist and shows which access ports belong to each VLAN (trunk ports are not listed here since they carry multiple VLANs):
SW1# show vlan brief
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Gi0/3, Gi0/4, Gi0/5
10 SALES active Gi0/1
20 ENGINEERING active Gi0/2show interfaces switchport
Confirms an individual port’s VLAN assignment and mode:
SW1# show interfaces GigabitEthernet0/1 switchport
Name: Gi0/1
Switchport: Enabled
Administrative Mode: static access
Operational Mode: static access
Access Mode VLAN: 10 (SALES)show interfaces trunk
Confirms VLANs 10 and 20 are actually being carried across the trunk (covered in detail in the interswitch connectivity article):
SW1# show interfaces trunk
Port Mode Encapsulation Status Native vlan
Gi0/24 on 802.1q trunking 1
Port Vlans allowed on trunk
Gi0/24 10,20show mac address-table vlan 10
Confirms which MAC addresses the switch has learned within VLAN 10 specifically — useful for confirming end-to-end Layer 2 connectivity:
SW1# show mac address-table vlan 10
Vlan Mac Address Type Ports
---- ----------- -------- -----
10 aaaa.bbbb.0001 DYNAMIC Gi0/1
10 cccc.dddd.0002 DYNAMIC Gi0/24The second entry (learned via Gi0/24, the trunk port) confirms the switch has learned about a VLAN 10 device on the other switch — proof the VLAN is genuinely spanning across the trunk.
End-to-End Connectivity Test
Ultimately, the simplest verification is a ping test between two devices in the same VLAN on different switches:
C:\Users\PC1> ping 192.168.10.20
Pinging 192.168.10.20 with 32 bytes of data:
Reply from 192.168.10.20: bytes=32 time=1ms TTL=128If PC1 (VLAN 10, SW1, IP 192.168.10.10) can successfully ping PC3 (VLAN 10, SW2, IP 192.168.10.20), and both are on the same subnet, this confirms the VLAN genuinely spans both switches correctly.
Comparison Table: Access Port vs. Trunk Port
| Feature | Access Port | Trunk Port |
|---|---|---|
| Number of VLANs carried | 1 | Multiple (all allowed VLANs) |
| Frame tagging | None (untagged) | 802.1Q tagged (except native VLAN) |
| Typical use | Connects end devices (PCs, printers, phones) | Connects switches, routers, or APs |
| Configuration command | switchport mode access | switchport mode trunk |
| VLAN assignment command | switchport access vlan | switchport trunk allowed vlan |
Common Mistakes When Spanning VLANs
- Forgetting to create the VLAN on the second switch. VLANs are locally significant to each switch’s database unless you use VTP (VLAN Trunking Protocol) to synchronize them — and even then, VTP has version-specific quirks. Many organizations avoid VTP altogether and manually replicate VLAN configuration for tighter control.
- Forgetting to allow the VLAN across the trunk. Even if VLAN 10 exists on both switches, if the trunk’s allowed VLAN list doesn’t include 10, traffic won’t pass.
- Assigning the wrong VLAN to an access port, resulting in a device that can’t reach others in its intended VLAN.
- IP addressing mismatches — remember, VLANs are a Layer 2 concept; you still need consistent Layer 3 subnetting (same subnet on both switches’ VLAN 10 ports) for IP communication to succeed.
Best Practices
- Use a consistent VLAN numbering scheme across your entire organization (e.g., VLAN 10 = Sales everywhere, VLAN 20 = Engineering everywhere) to reduce confusion.
- Document VLAN-to-subnet mappings clearly (e.g., VLAN 10 = 192.168.10.0/24) so Layer 2 and Layer 3 designs stay aligned.
- Avoid VLAN 1 for user traffic. Reserve it as the default/native VLAN only, and place real traffic in explicitly created VLANs.
- Prune unnecessary VLANs from trunks using
switchport trunk allowed vlanto reduce unnecessary broadcast propagation across the network. - Verify both configuration AND live state.
show running-configshows intended configuration;show vlan brief,show interfaces trunk, andshow mac address-tableshow what’s actually happening — always check both.
Troubleshooting Checklist
- Does the VLAN exist on both switches? (
show vlan brief) - Is the access port’s VLAN assignment correct? (
show interfaces switchport) - Is the VLAN included in the trunk’s allowed list on both ends? (
show interfaces trunk) - Is the trunk actually up and trunking (not stuck in access mode)?
- Are the two end devices in the same IP subnet, with correct default gateways?
- Has the switch actually learned the remote device’s MAC address in the correct VLAN? (
show mac address-table vlan)
Summary
Making a VLAN “span” multiple switches requires three coordinated pieces: the VLAN must exist with the same VLAN ID on every switch involved, end devices must be assigned to that VLAN via access ports, and the VLAN must be explicitly permitted across every trunk link connecting the switches. Once all three pieces are in place, devices in the same VLAN — regardless of which physical switch they’re plugged into — behave as if they’re on the same local network segment, and devices in different VLANs remain isolated at Layer 2 even when sharing the same physical infrastructure.
