Cisco VLAN Config and Verification: Repeatable Workflow

Most VLAN incidents are not caused by a single broken command but by an incomplete verification process that misses mismatches between access ports, trunks and gateways. This article presents a practical, repeatable workflow for configuring and verifying VLANs on Cisco IOS and IOS XE switches: plan VLAN IDs and subnets first, build access ports and trunks explicitly, choose inter-VLAN routing (router-on-a-stick or SVIs), then verify in a fixed order that catches mistakes fast. It is written from real troubleshooting experience and ends with the failure modes seen most often in production.

The reason to write the workflow down is that a VLAN misconfiguration is almost never a syntax error. The switch accepts every command, the interface comes up, and the problem only appears when a specific host tries to reach a specific address. A disciplined order of operations - and a disciplined order of verification - turns that needle-in-a-haystack into a checklist.

Plan First: IDs, Subnets, Trunks and Gateways

Choose stable VLAN IDs and names (USERS, SERVERS, NATIVE, PARKING), assign a clean IP subnet per VLAN even if routing is not needed today, and decide trunk policy up front: a dedicated native VLAN that carries no user traffic (e.g. 99) and an explicit allowed list per trunk.

Write four columns before you touch the CLI: VLAN ID, purpose, subnet with mask, and the single gateway address that will own that subnet. If two engineers independently pick a gateway address for the same VLAN, you have created a phantom second gateway that will work for half the hosts and fail for the rest - and it will not show up in any single command output.

Building VLANs and Access Ports

enable
configure terminal
vlan 10
 name USERS
vlan 30
 name SERVERS
vlan 99
 name NATIVE
vlan 999
 name PARKING
interface range gigabitEthernet 1/0/1 - 12
 switchport mode access
 switchport access vlan 10
 spanning-tree portfast
 spanning-tree bpduguard enable
end
write memory

Explicit switchport mode access prevents DTP from negotiating a trunk by surprise; PortFast and BPDU Guard protect edge ports from rogue switches and loops. On platforms that still run VTP, either put every switch in transparent mode or set the domain mode and password deliberately, because server mode with a mismatched revision number is a classic way to wipe a VLAN database across the whole campus at once.

For IP phones, add a voice VLAN to the same port rather than giving the phone its own cable:

interface range gigabitEthernet 1/0/1 - 12
 switchport voice vlan 20
 spanning-tree portfast
 spanning-tree bpduguard disable

Note the deliberate exception on BPDU Guard: some IP phone and access-point firmware sends BPDUs, so a blanket bpduguard enable on a voice port can shut the port down mid-call. Test with the actual endpoint rather than assuming.

Trunks Done Right

interface gigabitEthernet 1/0/24
 description Uplink-to-Distribution
 switchport trunk encapsulation dot1q
 switchport mode trunk
 switchport trunk native vlan 99
 switchport trunk allowed vlan 10,20,30,99
 spanning-tree guard root

Every line here earns its place. encapsulation dot1q removes negotiation on older platforms that still offer ISL. The explicit native VLAN keeps untagged traffic away from user subnets. The allowed list stops a future VLAN from leaking onto every uplink. spanning-tree guard root refuses superior BPDUs arriving from an unexpected direction, which is what keeps a mis-cabled access switch from becoming your root bridge.

Both ends of a trunk must agree on three things or you get subtle, intermittent breakage: the encapsulation, the native VLAN, and the allowed list. IOS does not warn you about a native VLAN mismatch beyond a syslog message and a CDP error, so make it part of the verification pass below.

Inter-VLAN Routing: SVIs vs Router-on-a-Stick

For a Layer 3 switch, enable routing and create SVIs:

ip routing
interface vlan 10
 description USERS-Gateway
 ip address 192.168.10.1 255.255.255.0
 no shutdown

For labs, router subinterfaces with encapsulation dot1Q tags work the same way. Remember: VLAN configuration and SVI configuration are separate - an SVI stays down if no port in the VLAN is active.

interface gigabitEthernet 0/0.10
 encapsulation dot1Q 10
 ip address 192.168.10.1 255.255.255.0

That "SVI down because no port is up" behaviour catches people constantly: you can configure the gateway, see it in the running config, and still have no reachability because the VLAN has no active member port. show ip interface brief shows the symptom; show vlan shows the cause.

If the routed VLAN also needs DHCP relay, add the helper on the SVI so the broadcast reaches the server - and if DHCP snooping is enabled, remember that the uplink toward the server must be trusted while the access ports stay untrusted, as described in the Cisco DHCP snooping trusted and untrusted port guide.

Verification Workflow

show vlan brief
show interfaces status
show interfaces trunk
show mac address-table vlan 10
show spanning-tree vlan 10
show ip interface brief

Then test with targeted pings in a ladder: host to gateway (access + gateway), host to same-VLAN host across switches (trunk), host to other-VLAN host (routing). If step 1 fails, do not waste time on step 3.

The order of the show commands is deliberate. show vlan brief proves the VLAN exists and lists its member ports; if a port you expect to be in VLAN 10 is missing, no amount of routing work will help. show interfaces trunk proves the uplink actually carries VLAN 10 in its allowed and active list - a VLAN can be "allowed" but not "active" if it does not exist locally. show mac address-table vlan 10 then proves frames are being learned, which is the difference between a configuration problem and a physical or STP-blocking problem.

Extending the Check for STP and MST

On a network that runs MST, the same verification pass needs one more step: confirm the region name, revision and VLAN-to-instance mapping match on every switch, because a mismatch silently splits the region and changes your topology. The Cisco MST region and VLAN mapping configuration guide shows the exact commands and the verification output to compare across devices.

show spanning-tree mst configuration
show spanning-tree mst 0
show spanning-tree vlan 10 | include Root|Interface|Role

Reading the Ping Ladder: Which Step Failed?

The ping ladder only pays off if you interpret each rung correctly, because the same "request timed out" message means three different things depending on where it happens.

• Host to its own gateway fails. The problem is local: wrong VLAN on the access port, a missing SVI, or the host has the wrong default gateway address. Nothing upstream is involved, so do not start checking trunks.
• Host to a same-VLAN host on another switch fails, but gateway pings work. The access layer is fine and the SVI is fine, so the fault is the trunk: the VLAN is not in the allowed list, the native VLAN does not match, or STP is blocking the path you assumed was forwarding.
• Same-VLAN works, other-VLAN fails. Routing is the suspect: ip routing disabled, a missing SVI for the destination VLAN, or an ACL filtering inter-VLAN traffic. Confirm with show ip route and show ip interface brief.

Running the commands from the switch's own CLI adds one more data point: ping with a source address (ping 192.168.30.10 source vlan 10) tests the data plane from the gateway itself and separates a control-plane problem from a forwarding problem.

Edge Hardening: Port Security and Storm Control

interface range gigabitEthernet 1/0/1 - 12
 switchport port-security
 switchport port-security maximum 3
 switchport port-security violation restrict
 switchport port-security aging time 10
 storm-control broadcast level 2.00
 storm-control action shutdown

Port security limits how many MAC addresses may appear on an access port, which stops someone plugging in a cheap switch and bridging a second device onto the VLAN. restrict drops and logs the offending frames while shutdown takes the port down - the first is right for user ports, the second for lobby or wall ports where any second MAC is unacceptable. Pair it with storm control so a broadcast loop or a failing NIC cannot saturate the access layer before anyone notices. Verify with show port-security interface and show storm-control broadcast.

Common Failure Modes

Access port in wrong VLAN, trunk native VLAN mismatch, VLAN not allowed on trunk, SVI down/down, and router subinterface tag mismatch are the classics. Three invariants prevent most of them: edge ports forced to access with PortFast + BPDU Guard; trunks with explicit allowed lists and a dedicated native VLAN; and a single documented gateway per routed VLAN.

Two more deserve a mention because they waste the most time:

• Duplicate IP on a gateway. Someone configured 192.168.10.1 as a static address on a server as well as on the SVI. Symptom: intermittent reachability that moves between hosts. Find it with show ip arp and an arping from a host.
• Native VLAN mismatch reported but ignored. The syslog line scrolls past during a change window and nobody reads it. Treat any CDP native VLAN mismatch message as a change-stopper.

Save, Document and Roll Back

copy running-config startup-config
show running-config interface gigabitEthernet 1/0/24
archive config
show archive status

Save explicitly - an uncommitted change is lost on reload and, worse, looks like it was never made. Where the platform supports it, enable the configuration archive so each write memory creates a dated revision you can diff and restore. Document the VLAN plan in the same repository as the configs, so the next engineer reads the intent rather than guessing it from the running state.

Scaling the Workflow

Once the manual pass is stable, the same checklist becomes a template: a Jinja2 template that emits the access-port block, the trunk block and the SVI block, and a verification script that runs the show commands and asserts on the output. Automating the checks before automating the changes is the safer order. When the workflow is proven by hand three or four times, coding it into Ansible or a Python script removes the human step that caused the original incident.

Related: Arista EOS configuration cheat sheet and Juniper EX inter-VLAN communication troubleshooting.

原文链接：https://thelinuxcode.com/configuring-and-verifying-vlans-on-cisco-switches-a-practical-repeatable-workflow