VLAN misconfiguration is usually fixed by checking three things in order: the access port's VLAN assignment, the trunk's allowed-VLAN list between switches, and the Layer 3 interface or SVI that routes between VLANs. Correct any mismatch, confirm 802.1Q tagging matches on both link ends, and connectivity returns.
Symptoms
- Devices on the same VLAN cannot ping each other despite correct IP settings
- Hosts in one VLAN cannot reach another VLAN even though routing appears configured
- DHCP fails on a specific port after moving a device to a new switch
- Traffic works locally but breaks the moment it crosses a trunk to another switch
- Voice or guest traffic leaks into the wrong subnet or shows up on the native VLAN
Common Causes
Wrong access VLAN on the switchport
The port is a member of a different VLAN than the host expects, so its frames never reach the correct broadcast domain. Common after cable moves or template copy-paste.
VLAN not allowed on the trunk
Trunk links carry only VLANs listed in the allowed-vlan set. If the VLAN is pruned or was never added, tagged frames are dropped between switches.
Native VLAN mismatch on 802.1Q trunks
Both ends of a trunk must agree on the native (untagged) VLAN. A mismatch causes CDP warnings, STP inconsistencies, and silent traffic leakage between segments.
Missing SVI or router subinterface
Two VLANs cannot talk without a Layer 3 hop. If the SVI is absent, shut down, or has no IP helper for DHCP, inter-VLAN routing fails.
ACL or firewall rule blocking the subnet
An interface ACL, VLAN map, or upstream firewall policy silently discards traffic between VLAN subnets even when Layer 2 and Layer 3 look healthy.
Step-by-Step Fix
- Confirm the client actually landed in the expected VLAN
On the host, run ipconfig /all (Windows) or ip addr (Linux) and compare the assigned subnet against the VLAN plan. A host in 10.20.0.0/24 that should be in 10.30.0.0/24 tells you the switchport, not the client, is wrong. - Read the switchport VLAN membership
Log into the access switch and run show interfaces status and show vlan brief. Verify the port's Access VLAN matches the intended ID and that the VLAN itself exists in the database and is active, not suspended. - Correct the access port assignment
If the VLAN is wrong, reassign it cleanly. In IOS: interface Gi0/5, switchport mode access, switchport access vlan 30. Then save with write memory. Avoid dynamic mode on user ports, it invites negotiation problems. - Inspect the trunk between switches
Run show interfaces trunk on both ends. Confirm the VLAN in question appears under Vlans allowed and active on the trunk. Also check that the native VLAN ID is identical on both sides to prevent 802.1Q mismatches. - Add the VLAN to the trunk allow-list
If the VLAN is missing, extend the allowed list without wiping it: switchport trunk allowed vlan add 30. Using the bare allowed vlan command replaces the list and can drop every other VLAN on the link. - Verify inter-VLAN routing at Layer 3
On the L3 switch or router, run show ip interface brief. Each VLAN needs an SVI (interface vlan 30) in up/up state with an IP in the correct subnet. For DHCP across VLANs, add ip helper-address pointing at the DHCP server. - Rule out ACLs, VLAN maps, and firewalls
Check show access-lists and any VLAN filters on the SVI. Temporarily remove or log-permit a suspected ACL and retest. If routing still fails, trace the path with traceroute to find where packets die. - Document the change and clear stale MAC entries
After fixes, run clear mac address-table dynamic to flush old learning, then retest ping and application traffic. Update your VLAN map, port description, and change ticket so the next engineer sees the correct state.
Common VLAN symptoms mapped to the actual cause and fix
| Symptom | Likely cause | Where to fix |
|---|---|---|
| Host gets wrong IP subnet | Access port on wrong VLAN | switchport access vlan on the edge switch |
| Works locally, fails across switches | VLAN not on trunk allow-list | switchport trunk allowed vlan add on both trunk ends |
| Intermittent STP or CDP warnings | Native VLAN mismatch | Align switchport trunk native vlan on both sides |
| No route between two VLANs | Missing or down SVI | interface vlan X, no shutdown, correct IP |
| DHCP fails only on new VLAN | No relay to DHCP server | ip helper-address on the SVI |
| Ping works, app blocked | ACL or firewall rule | show access-lists, upstream firewall policy |
Prevention
- Use descriptive port descriptions (e.g. VLAN30-FINANCE) so mismatches are visible at a glance
- Standardise trunk allowed-vlan lists per switch role and manage them from a template or NetBox
- Pick a non-default native VLAN and apply it consistently on every trunk in the domain
- Review VLAN and trunk configs during quarterly audits, especially after switch replacements
FAQ
How do I tell if the problem is Layer 2 or Layer 3?
Ping the default gateway from the affected host. If the gateway responds, Layer 2 and the access VLAN are healthy, and the fault lives in routing, ACLs, or a firewall. If the gateway is unreachable, focus on switchport VLAN membership, cabling, and the trunk carrying that VLAN to the L3 device.
Is it safe to use switchport trunk allowed vlan without add?
No. The command without add replaces the entire allowed list with only the VLANs you specify, which can instantly cut traffic for every other VLAN on that trunk. Always use add or remove to modify an existing list, and review the result with show interfaces trunk before leaving the session.
Why do two devices in the same VLAN still fail to reach each other?
Check that both switchports are truly in the same VLAN ID, not just similar names, and that any trunk between their switches carries that VLAN. Also look for port security, protected ports, private VLAN settings, or a host firewall blocking ICMP or the target service.
Need a second pair of eyes on your VLAN design? Contact our network team for a configuration review.