Five VLAN Mistakes That Break a Working Network (And the Commands That Find Them)

The VLAN worked on Friday. Monday morning the third floor couldn’t print, the cameras went dark, and nobody had touched a cable all weekend.

That’s the shape of nearly every VLAN failure worth writing about. Not a network that never worked. A network that ran fine for months until one port, one trunk, or one newly racked switch quietly changed the rules underneath it.

You’ve probably read a dozen pages explaining what a VLAN is. Broadcast domains, 802.1Q tags, access versus trunk, the same diagram every time. Almost none of them tell you what breaks, what the breakage looks like from a terminal, or how to prove which mistake you’ve actually got.

So that’s what this is. Five VLAN mistakes, ranked by how much time they cost people. For each one you get the symptom you’ll really see, the command that confirms it, and the fix. No guessing.

The Fast Answer: Five VLAN Mistakes at a Glance

Notice the pattern. Four of the five are trunk problems. The trunk is where they stop being a switch feature and start being a design that spans hardware, and it’s where the design falls over.

New to switching and want the ground floor first? Our free CompTIA Network+ course covers VLANs, tagging and trunking from zero, live, with an instructor you can interrupt.

VLAN Mistake 1: Leaving Everything on VLAN 1

Out of the box, every port on a Cisco switch sits in VLAN 1. Plug in and it works. That’s the trap.

Nothing breaks on the left, which is exactly why it survives for years.

VLAN 1 can’t be deleted. It’s also where a lot of Layer 2 control traffic lives by default, and on many switches it carries the management interface too. Leave it as your working segment and you’ve built a flat network with a management plane sitting in the same broadcast domain as the guest laptop in reception.

NSA’s Network Infrastructure Security Guide is blunt about the risk: “If mitigation steps are not taken, the default VLAN may span the entire network, and place trusted devices at a higher security risk of exploitation by untrusted devices that gain access.”

Their recommendation is to move all management and operational traffic off the default VLAN, and to disallow it on every trunk and access port that doesn’t need it, disconnected and shut ports included.

The symptom

There isn’t one. That’s what makes this the worst of the five.

Nothing breaks. No log message, no dropped ping, no ticket. The network runs happily on VLAN 1 for two years, and then someone plugs a compromised laptop into an unused wall port and reaches your switch management address on the first try.

The command

Switch# show vlan brief

VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
1    default                          active    Gi1/0/1, Gi1/0/2, Gi1/0/3
                                                Gi1/0/4, Gi1/0/5, Gi1/0/6
10   STAFF                            active    Gi1/0/11, Gi1/0/12
20   VOICE                            active    Gi1/0/13

Count the ports parked in VLAN 1. If that list is long, you have work to do.

The fix

Build a real access VLAN for users, a separate one for management, and a dead one for everything unused:

Switch(config)# vlan 998
Switch(config-vlan)# name UNUSED-NATIVE
Switch(config-vlan)# shutdown
Switch(config)# vlan 999
Switch(config-vlan)# name UNUSED-DISABLED
Switch(config-vlan)# shutdown
Switch(config)# interface range Gi1/0/1 - 6
Switch(config-if-range)# switchport mode access
Switch(config-if-range)# switchport access vlan 10

Then take VLAN 1 off the trunks:

Switch(config)# interface Gi1/0/24
Switch(config-if)# switchport trunk allowed vlan 10,20,30

Every unused port gets shut down and dropped into VLAN 999. Takes an afternoon. Worth it.

VLAN Mistake 2: A Native VLAN Mismatch on the Trunk

This one hurts because it half works.

Run show interfaces trunk on both switches and compare one column.

On an 802.1Q trunk, tagged frames carry a VLAN ID. Untagged frames don’t, so the switch drops them into the native VLAN for that port. Both ends have to agree on which one that is. When they disagree, untagged traffic leaving one switch in VLAN 99 arrives at the other and gets filed under VLAN 1.

Traffic leaks across a boundary that was supposed to hold. And spanning tree loses its grip, because VLAN 1 BPDUs travel untagged and the two switches no longer agree on where those BPDUs belong.

Picture Dana, halfway through an office move. Both closets tested clean on the bench. The trunk between them goes live at 07:00 on a Monday and guest devices start pulling internal addresses at random.

One line different on each switch. Half a day to find it.

The symptom

Cisco switches usually tell you, through CDP, and the message is easy to scroll past:

%CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on
GigabitEthernet1/0/24 (99), with Switch2 GigabitEthernet1/0/24 (1).

If spanning tree catches it, the port goes into a PVID inconsistent state and stops forwarding for the affected VLANs. That reads to users as “some things work, some don’t”. If STP is disabled or filtered on that link, you get the other outcome instead. A loop.

The command

Switch# show interfaces trunk

Port        Mode         Encapsulation  Status        Native vlan
Gi1/0/24    on           802.1q         trunking      99

Run it on both switches and compare the Native vlan column. That’s the whole test.

To catch the spanning tree side of it:

Switch# show spanning-tree inconsistentports

The fix

Set the same native VLAN on both ends, and make it one no access port uses:

Switch(config)# interface Gi1/0/24
Switch(config-if)# switchport trunk native vlan 500

NSA goes a step further and recommends giving trunk ports a unique native VLAN assigned only to trunks, which as they put it “will prevent an adversary from jumping between active VLANs by intentionally tagging traffic that would otherwise be untagged.”

Want the spanning tree half of this properly? Our guide to per-VLAN spanning tree explains why the BPDU behaviour matters here, and MSTP covers what changes when you map many VLANs to a few instances.

VLAN Mistake 3: Letting Ports Negotiate Their Own VLAN Trunks

A switch port can work out for itself whether to be an access port or a trunk. Cisco calls the mechanism DTP. It’s convenient and it’s a hole.

Route A needs the port to negotiate. Route B works even when it won’t.

Here’s the deal. A port left in dynamic auto or dynamic desirable will form a trunk with anything that asks nicely. Plug a laptop running the right software into that port and it can ask.

Once the trunk comes up, every VLAN allowed on it is reachable from a wall socket. That’s switch spoofing, and it’s one of the two routes into VLAN hopping.

NSA’s position: “NSA recommends disabling dynamic trunking as it is not necessary for an interface port to dynamically configure itself.”

The second route is double tagging, and it’s sneakier. The attacker stacks two 802.1Q tags in one frame. The first switch strips the outer tag and forwards the frame with the inner tag still attached, landing it in a VLAN the outer tag never named. That one works even when the attacker’s port isn’t a trunk, which is exactly why the native VLAN fix from mistake 2 matters so much.

The symptom

A port that should be an access port shows up as a trunk. Or a device reaches VLANs it has no business seeing.

The command

Switch# show interfaces Gi1/0/5 switchport

Name: Gi1/0/5
Switchport: Enabled
Administrative Mode: dynamic auto
Operational Mode: static access
Administrative Trunking Encapsulation: dot1q
Access Mode VLAN: 10 (STAFF)
Trunking Native Mode VLAN: 1 (default)

Two lines matter. Administrative Mode: dynamic auto means the port is still willing to negotiate. Operational Mode tells you what it settled on today, which can change tomorrow.

The fix

Be explicit about every port. No exceptions:

Switch(config)# interface range Gi1/0/1 - 20
Switch(config-if-range)# switchport mode access
Switch(config-if-range)# switchport access vlan 10

Setting switchport mode access shuts DTP down on that port. For ports that genuinely are trunks, pin them and stop them negotiating:

Switch(config)# interface Gi1/0/24
Switch(config-if)# switchport mode trunk
Switch(config-if)# switchport nonegotiate

Two commands. Both routes into VLAN hopping closed.

Ready to configure this on real gear instead of reading about it? Our live CCNA course runs VLANs, trunking and inter-VLAN routing on physical switches with unlimited lab time and an instructor in the session. Ask the awkward question the moment it occurs to you.

VLAN Mistake 4: Replacing the Allowed VLAN List Instead of Adding to It

This is the one that breaks a working network, and it’s a single missing word.

One word. The command that destroys the config looks exactly like the one that extends it.

You’ve got a trunk carrying VLANs 10, 20 and 30. Marketing needs VLAN 40. You type what looks obvious:

Switch(config-if)# switchport trunk allowed vlan 40

VLAN 40 now works. VLANs 10, 20 and 30 are gone.

That command doesn’t append. It sets the list to exactly what you typed. Everything you didn’t type just lost its path across the trunk. The keyword you needed was add:

Switch(config-if)# switchport trunk allowed vlan add 40

One word. Honestly, this is the mistake we see most often in our live labs, and it’s the one people are most surprised by, because the command that destroys the config looks exactly like the command that extends it.

The same failure arrives a second way. You rack a new switch, cable the uplink, configure VLAN 40 on both ends, and it still doesn’t pass. The trunk in the middle, on the switch nobody touched, never had 40 in its allowed list. That list is per-port, and traffic has to survive every hop.

The symptom

One VLAN works end to end. Another doesn’t, and only across a specific path. Devices pull no IP address, because the DHCP broadcast can’t reach the server.

The command

Switch# show interfaces trunk

Port        Vlans allowed on trunk
Gi1/0/24    40

Port        Vlans allowed and active in management domain
Gi1/0/24    40

Port        Vlans in spanning tree forwarding state and not pruned
Gi1/0/24    40

That output is the fingerprint. You expected 10, 20, 30 and 40. You got 40 alone, in all three blocks, which means the list was replaced rather than extended.

Read all three blocks, top to bottom. The first says what you configured. The second says which of those actually exist on this switch. The third says which are really forwarding.

A VLAN that appears in block one and vanishes by block three is being pruned or is missing from the database, and that’s a different bug from a missing allowed entry.

The fix

Switch(config)# interface Gi1/0/24
Switch(config-if)# switchport trunk allowed vlan add 40

Then walk the path. Every trunk between the source and the gateway needs that VLAN allowed. Trace it hop by hop, the way you’d trace a cable.

Running VLANs into virtual machines? The same trap sits one layer down, on the bridge. Our guide to VLANs on a Proxmox host covers the VLAN-aware bridge and the physical switch port that has to agree with it. And if the tag passes but nothing routes, the problem may be the address plan rather than the tag, which is where VLAN vs subnet sorts out which layer you’re actually fighting.

VLAN Mistake 5: Letting VTP Run Your VLAN Database

Save the worst for last.

Higher revision wins, and it doesn’t merge. It replaces.

VTP, the VLAN Trunking Protocol, syncs your VLAN database across switches so you define each one only once. Sounds helpful. In VTP versions 1 and 2 it’s a loaded gun pointed at your entire Layer 2 network.

Every database carries a configuration revision number. When a switch sees an update with a higher revision than its own, it accepts that database wholesale and discards what it had. Cisco’s own guidance says it plainly: “A switch in VTP server or client mode that has a higher configuration revision and matching VTP domain name and password, when configured, can cause other switches to replace their VLAN database.”

Read that again. Not merges. Replaces.

So here’s the outage. An engineer pulls a switch off the shelf, one that spent a year in a lab collecting VLAN changes and a fat revision number. Same VTP domain name. They cable the uplink at 14:00 on a Tuesday.

Within seconds every switch in the domain adopts the lab switch’s stale database, and the production VLANs are gone. Every one of them. From every switch. Because a cable went into a port.

The symptom

VLANs disappear across multiple switches at the same moment. Users on every segment except the native one lose everything. show vlan brief on a switch nobody touched shows entries you’ve never heard of.

The command

Switch# show vtp status

VTP Version capable            : 1 to 3
VTP version running            : 2
VTP Domain Name                : CAMPUS
VTP Operating Mode             : Server
Configuration Revision         : 47
Maximum VLANs supported locally: 1005

Three fields. VTP version running, because version 3 protects the database and versions 1 and 2 do not. VTP Operating Mode, because Server and Client both accept updates. Configuration Revision, because that’s the number that decides who wins.

The fix

For most networks, stop using it:

Switch(config)# vtp mode transparent

Transparent mode means the switch keeps its own VLANs and passes VTP advertisements through without acting on them. You define them per switch. Slightly more typing, and no single cable can wipe the network.

If you’re keeping VTP, run version 3, and follow Cisco’s instruction to reset the configuration revision to 0 on any switch before you connect it to the domain. Before. Not after.

How Do You Find a VLAN Problem in Four Commands?

Most VLAN troubleshooting goes wrong because people start at the symptom and jump straight to a theory. Run these four in order instead. Each one rules out a layer of the problem.

1. Does the VLAN exist here, and which ports are in it?

Switch# show vlan brief

If the VLAN isn’t in the database, nothing downstream will work. Create it first.

2. What does this specific port think it is?

Switch# show interfaces Gi1/0/5 switchport

Access or trunk. Which one it’s in. Whether it’s still negotiating. This catches mistakes 1 and 3.

3. What actually crosses the trunk?

Switch# show interfaces trunk

Native VLAN on both ends, and all three allowed-VLAN blocks. This catches mistakes 2 and 4.

4. Is something else managing your VLAN database?

Switch# show vtp status

This catches mistake 5, and it’s the one people skip. Run it before you rebuild a VLAN by hand, or you’ll watch your rebuild get overwritten.

Add a fifth when spanning tree is behaving oddly:

Switch# show spanning-tree inconsistentports

Four commands, in that order, on each switch along the path. It’s the same discipline as our layered troubleshooting order: prove one layer before you theorise about the next.

The VLAN Hardening Checklist

Everything above, as a list you can work through on a Friday afternoon. The security items follow NSA’s Network Infrastructure Security Guide.

• Move user traffic off VLAN 1 onto purpose-built access VLANs
• Put management traffic on its own VLAN, separate from user data and protocol traffic
• Disallow VLAN 1 on every trunk that doesn’t need it
• Give trunk ports a unique native VLAN used by no access port
• Match the native VLAN on both ends of every trunk
• Set every port explicitly to access or trunk. Never leave one negotiating
• Add switchport nonegotiate to static trunks
• Name your allowed VLAN lists explicitly rather than allowing all
• Use add and remove when editing an allowed VLAN list, never a bare list
• Shut down unused ports and park them in a shutdown VLAN
• Run VTP in transparent mode, or version 3 with the revision reset before connection
• Keep one subnet per VLAN so Layer 2 and Layer 3 boundaries line up

Print it. Walk your switches against it once a quarter.

So Are VLANs Still Worth the Trouble?

Fair question, given the list above.

Yes, and the reason is that the alternative is worse. A flat network gives an attacker who reaches one device a clear path to every other device on the same switch. VLANs are still the cheapest way to draw a Layer 2 boundary without buying more hardware.

What’s fair to say is that VLANs aren’t security on their own. They separate broadcast domains. They don’t inspect traffic, they don’t authenticate anything, and a misconfigured trunk undoes the whole thing in one command. That’s the honest reading of the disadvantages: the technology is sound, and it fails through configuration far more often than through design.

Which is the argument for the checklist, not against VLANs.

Common VLAN Mistakes: Your Questions Answered

What are common VLAN mistakes?

The five that cost the most time are leaving user and management traffic on VLAN 1, a native VLAN mismatch between the two ends of a trunk, leaving ports free to negotiate their own trunk status, replacing an allowed VLAN list when you meant to add to it, and letting VTP versions 1 or 2 overwrite the VLAN database. Four of the five are trunk problems.

Why is VLAN 1 bad?

VLAN 1 is the default on every port, it can’t be deleted, and it carries Layer 2 control traffic and often the switch management interface. Leaving it in use means the default VLAN can span your whole network, putting trusted devices in the same broadcast domain as untrusted ones. NSA recommends moving management and operational traffic to non-default VLANs and disallowing VLAN 1 on trunks and access ports that don’t need it.

What are the disadvantages of VLAN?

VLANs add configuration overhead that has to stay consistent across every switch, they separate broadcast domains rather than inspecting traffic, and they give no protection at all when misconfigured. A single wrong native VLAN or allowed-VLAN list can quietly remove the isolation you thought you had. Troubleshooting is also harder, because traffic paths are logical and no longer match the cabling.

What are three techniques to mitigate VLAN attacks?

Three that cover the main routes in. First, set every access port explicitly with switchport mode access so DTP can’t negotiate a trunk, and add switchport nonegotiate to real trunks. Second, give trunks a dedicated native VLAN that no access port uses, which closes the double-tagging path. Third, restrict each trunk to the specific VLANs it needs instead of allowing all. Shutting unused ports into a disabled VLAN is a good fourth.

What are the best practices for VLAN numbering?

Reserve VLAN 1 and don’t use it. Keep separate ranges for separate purposes, for example user VLANs in one block, voice in another, management in its own. Pick a scheme that maps to your subnets one-to-one so VLAN 20 always pairs with the same address range. Put unused and native trunk VLANs in high numbers you’ll never confuse with production, such as 500, 998 and 999. Remember that VLANs 1002 to 1005 are reserved on Cisco switches, and that the extended range above 1005 needs a capable platform.

The Bottom Line

VLAN failures are rarely mysterious. They’re four or five specific mistakes, repeated everywhere, and each one leaves a fingerprint you can read from a terminal in under a minute.

What to take away:

• Nothing should be sitting in VLAN 1, and nothing should be negotiating its own trunk
• Native VLAN has to match on both ends, and shouldn’t be one any user port uses
• switchport trunk allowed vlan 40 replaces your list. add 40 extends it
• Check show vtp status before you rebuild a single VLAN by hand
• Four commands, in order, on every switch along the path

The engineers who fix these fast aren’t the ones who memorised the theory. They’re the ones who’ve watched the network break and know which command to reach for.

Want to build that reflex on real switches? Our live CCNA course puts you in front of physical gear with an instructor in the session, and every class gets its own group where you can ask questions between sessions. If you’re aiming at the job rather than the certificate, the Network Engineer programme takes the same material further into design and operations. Pair either one with the CCNA study workbook from SMEnode Labs for drills.

Test yourself first if you’d rather: try our CCNA practice test and the subnetting practice questions. If the trunk questions trip you up, you know where to start.

Sources

• NSA, Network Infrastructure Security Guide, Cybersecurity Technical Report. Guidance on the default VLAN, native trunking VLAN, dynamic trunking and unused ports. Quotations verified against version 1.0 (PP-22-0266, March 2022); the current release is the October 2023 update. nsa.gov
• Cisco, Configure VTP on Catalyst Switches. Configuration revision behaviour and the transparent-mode recommendation. cisco.com
• Cisco, VLAN Configuration Guide, Configure VTP. VTP version 3 protection of the VLAN database. cisco.com