Posted inNetworking

VLAN Configuration Basics: What I Learned Getting Paged at 2 AM

Networking tutorial - IT technology blog
Networking tutorial - IT technology blog

The 2 AM Phone Call That Changed How I Think About VLANs

Three years ago, I got paged because “the office can’t reach the servers.” Not a single person. The entire 60-person office. I rolled out of bed, VPN’d in, and spent 45 minutes chasing a ghost — only to find that someone had plugged a laptop into the wrong switch port and collapsed the entire network segment.

The root cause wasn’t a cable or a bad NIC. It was a missing VLAN configuration on one trunk port. That night cost us $4,000 in SLA penalties and gave me a permanent appreciation for doing VLANs right the first time.

Whether something is currently broken or you’re trying to avoid that exact scenario — this guide is for you.

What’s Actually Happening When Your Network “Breaks”

Most network incidents that get blamed on “the switch” are actually VLAN misconfigurations. Before we get into commands, you need to understand what VLANs are doing at the frame level — because when you understand the problem, the fix becomes obvious.

A VLAN (Virtual Local Area Network) segments your physical network into isolated broadcast domains. Devices in VLAN 10 cannot talk to devices in VLAN 20 unless traffic routes through a Layer 3 device. That’s not a bug — that’s the security model.

Every switch port operates in one of two modes:

  • Access port — belongs to exactly one VLAN, strips VLAN tags before forwarding to the end device. Your workstations, printers, and IoT devices connect here.
  • Trunk port — carries multiple VLANs tagged with 802.1Q headers. Switch-to-switch links and switch-to-router links use this.

The incident I described? Someone had added a new VLAN to the switch but forgot to allow it on the trunk port between the access layer and distribution layer. Traffic from the new VLAN had nowhere to go.

Root Cause Analysis: Why VLAN Configs Fail in Production

After years of on-call rotations, I’ve catalogued the VLAN failures I see repeatedly:

  1. Trunk port missing a VLAN — you add VLAN 30 to one switch but forget to allow it on the uplink trunk. Traffic blackholed.
  2. Native VLAN mismatch — Switch A has native VLAN 1, Switch B has native VLAN 99. Untagged traffic gets misassigned. You end up with weird intermittent connectivity that’s incredibly hard to trace.
  3. STP topology changes — adding a new VLAN without verifying Spanning Tree Priority causes unexpected root bridge elections.
  4. Inter-VLAN routing not configured — VLANs exist but there’s no Layer 3 path between them. Users can ping within their VLAN but nothing else.
  5. VLAN not in the VLAN database — you assigned a port to VLAN 50 but VLAN 50 was never created. The port goes into an inactive state.

Almost every VLAN incident maps to one of these five. Once you’ve seen them all, you stop guessing and go straight to the checklist.

Solutions Compared: Cisco IOS vs. Open vSwitch vs. Linux Bridge

The commands look different depending on your platform — but the underlying logic doesn’t change. Here’s how it shakes out across the three environments I use most.

Option 1: Cisco IOS (Catalyst switches)

The most common enterprise scenario. Creating a VLAN and assigning a port is straightforward:

# Create VLANs in the VLAN database
switch# configure terminal
switch(config)# vlan 10
switch(config-vlan)# name OFFICE
switch(config-vlan)# vlan 20
switch(config-vlan)# name SERVERS
switch(config-vlan)# exit

# Configure an access port (e.g., Gi0/1 for a workstation)
switch(config)# interface GigabitEthernet0/1
switch(config-if)# switchport mode access
switch(config-if)# switchport access vlan 10
switch(config-if)# spanning-tree portfast
switch(config-if)# exit

# Configure a trunk port (e.g., Gi0/24 uplink)
switch(config)# interface GigabitEthernet0/24
switch(config-if)# switchport mode trunk
switch(config-if)# switchport trunk encapsulation dot1q
switch(config-if)# switchport trunk allowed vlan 10,20
switch(config-if)# switchport trunk native vlan 999
switch(config-if)# exit

# Save config
switch# write memory

The native vlan 999 line is deliberate — I always set native VLAN to an unused VLAN. Leaving it as VLAN 1 is a well-known security risk (VLAN hopping attacks exploit native VLAN 1).

Option 2: Open vSwitch (virtualization/SDN environments)

Running KVM, OpenStack, or any SDN-based infrastructure? Open vSwitch handles VLANs differently:

# Create a bridge
ovs-vsctl add-br br0

# Add a physical interface as a trunk
ovs-vsctl add-port br0 eth0

# Add a VM interface as an access port for VLAN 10
ovs-vsctl add-port br0 vnet0 tag=10

# Add a trunk port allowing VLANs 10 and 20
ovs-vsctl add-port br0 eth1 trunks=10,20

# Verify
ovs-vsctl show
ovs-ofctl show br0

Option 3: Linux kernel bridge (simple servers/containers)

For Linux servers that need to participate in VLANs without a full SDN stack:

# Load the 8021q module if not already loaded
modprobe 8021q
echo "8021q" >> /etc/modules

# Create a VLAN interface on eth0 for VLAN 10
ip link add link eth0 name eth0.10 type vlan id 10
ip link set eth0.10 up
ip addr add 192.168.10.100/24 dev eth0.10

# Create a bridge and attach the VLAN interface
ip link add name br-vlan10 type bridge
ip link set eth0.10 master br-vlan10
ip link set br-vlan10 up

# Persist with /etc/network/interfaces (Debian/Ubuntu)
cat >> /etc/network/interfaces << 'EOF'
auto eth0.10
iface eth0.10 inet manual
  vlan-raw-device eth0

auto br-vlan10
iface br-vlan10 inet static
  bridge_ports eth0.10
  address 192.168.10.100
  netmask 255.255.255.0
EOF

The Best Approach: Inter-VLAN Routing with Router-on-a-Stick

VLANs isolate traffic — but users still need to cross segment boundaries. Workstations in VLAN 10 need to reach servers in VLAN 20. Without a Layer 3 switch, the cleanest solution is router-on-a-stick: one trunk link between your switch and router, with sub-interfaces handling each VLAN.

I’ve run this setup in production with 15+ VLANs on a single uplink. It holds up well under heavy traffic and the config stays easy to audit.

# On Cisco router — configure sub-interfaces for inter-VLAN routing
router# configure terminal

# VLAN 10 sub-interface
router(config)# interface GigabitEthernet0/0.10
router(config-subif)# encapsulation dot1Q 10
router(config-subif)# ip address 192.168.10.1 255.255.255.0
router(config-subif)# exit

# VLAN 20 sub-interface
router(config)# interface GigabitEthernet0/0.20
router(config-subif)# encapsulation dot1Q 20
router(config-subif)# ip address 192.168.20.1 255.255.255.0
router(config-subif)# exit

# Bring up the physical interface
router(config)# interface GigabitEthernet0/0
router(config-if)# no shutdown
router(config-if)# exit
router# write memory

After this, set the default gateway on your VLAN 10 hosts to 192.168.10.1 and VLAN 20 hosts to 192.168.20.1. Traffic between VLANs now routes through the router’s sub-interfaces.

Verification Commands You Should Memorize

When something breaks at 2 AM, you don’t have time to search the internet. These are the commands I run in order:

# Check VLAN database — is the VLAN actually created?
show vlan brief

# Check trunk status — is the VLAN allowed on the trunk?
show interfaces trunk

# Check a specific interface
show interfaces GigabitEthernet0/24 trunk
show interfaces GigabitEthernet0/1 switchport

# Check MAC address table for a specific VLAN
show mac address-table vlan 10

# Check spanning tree per VLAN
show spanning-tree vlan 10

# For Linux — verify VLAN interfaces
ip link show type vlan
cat /proc/net/vlan/config

# For Open vSwitch — check port config
ovs-vsctl list port
ovs-vsctl get port vnet0 tag

The 5-Minute Pre-Change Checklist

Every time I touch VLAN config in production, I run through this before making changes:

  1. Document current state: show running-config → save to a file
  2. Verify VLAN exists in database before assigning to ports
  3. Check trunk ports and confirm the new VLAN will be allowed
  4. Confirm native VLAN matches on both ends of every trunk
  5. After change: verify with show vlan brief and a ping test

Realistically, this checklist has caught at least a dozen problems before they became overnight pages. Five minutes of verification beats 45 minutes of debugging at 2 AM — ask me how I know.

Quick Troubleshooting Reference

  • Port in inactive/notconnect state → VLAN doesn’t exist in database. Run show vlan brief and create it.
  • Traffic works within VLAN, not between VLANs → No inter-VLAN routing configured, or sub-interfaces missing.
  • Intermittent connectivity between switches → Native VLAN mismatch. Run show interfaces trunk on both switches and compare.
  • New VLAN can’t reach upstream → VLAN not allowed on trunk. Add it with switchport trunk allowed vlan add 30 (not switchport trunk allowed vlan 30 — that replaces the entire allowed list).
  • Can’t ping default gateway → Sub-interface down or wrong encapsulation. Check show interfaces GigabitEthernet0/0.10.

VLANs stop being scary once you internalize two things: the access-vs-trunk model, and the five failure patterns. The syntax varies by vendor and platform. But the logic never changes — tags go on at trunk ports, come off at access ports, and traffic crosses VLAN boundaries only at Layer 3.

Set your native VLAN to something unused, verify your trunks after every change, and keep that checklist close. Your future self — the one getting paged at 2 AM — will thank you.

Share:
Tags: