VLAN failures become much easier when you separate placement, carriage, gateway, and policy
A VLAN symptom can originate at several different boundaries. The endpoint may be placed in the wrong access VLAN, the VLAN may be omitted from a trunk, untagged traffic may land differently on each side, the Layer 3 gateway may be missing, DHCP relay or scope may be incomplete, or routing/policy may block traffic after the VLAN itself is working. The strongest diagnosis identifies the first boundary whose evidence no longer matches the intended design.
Use the clue to choose the next artifact
| Observed clue | Strongest boundary | Next evidence | Important limit |
|---|---|---|---|
| Endpoint gets wrong subnet | Wrong access VLAN / scope candidate | Port VLAN, MAC/VLAN table, DHCP scope | Placement and DHCP can independently confirm each other |
| One VLAN fails across trunk | VLAN omitted/inconsistent | Allowed list, VLAN existence, tagging | Working VLAN is a strong physical-path control |
| All VLANs fail across trunk | Shared trunk/link problem | Operational state, physical link, trunk mode | Do not start with one VLAN |
| Local same-VLAN works, remote VLAN fails | Gateway/routing/policy | SVI, route, firewall | Layer 2 VLAN may already be healthy |
| MAC learned in unexpected VLAN | Access/tagging mismatch | MAC table with VLAN context | Direct Layer 2 placement evidence |
| Voice works, attached PC wrong network | Voice/data VLAN role mismatch | Voice and data VLAN config | One physical port can carry two logical roles |
| Native mismatch | Untagged VLAN inconsistency | Both trunk endpoints | Tagged VLANs may still work |
| DHCP fails only in new VLAN | Relay/scope/trunk/gateway path | VLAN, SVI, helper, scope | VLAN creation alone does not provide DHCP |
| Guest reaches Staff unexpectedly | Segmentation/policy failure | Placement + inter-VLAN rules | Connectivity can be a security defect |
| Port link down | Layer 1/admin state | Interface operational status | Fix lower layer before VLAN |
Swipe horizontally to see the VLAN evidence matrix.
Endpoint gets an address from the wrong subnet
The client received a coherent lease, just from the wrong network. That means DHCP itself completed with some scope. The first question is whether the endpoint was placed into Guest VLAN 70 or whether VLAN 30 selected the wrong DHCP scope.
A wrong subnet can be caused before DHCP ever makes a mistake
If the endpoint enters the wrong VLAN, the DHCP server may correctly assign an address for that VLAN. That is why “wrong IP” is not automatically a DHCP-server fault. Determine where the endpoint is actually placed before changing scope configuration.
One VLAN fails across a trunk while another works
The working VLAN proves the physical inter-switch path is alive. The failure is specific to VLAN 20's logical carriage. Inspect allowed VLANs, VLAN existence, tagging consistency, and trunk mode.
A healthy neighboring VLAN eliminates several shared causes
If VLAN 10 crosses the same cable and trunk, a completely dead cable or dead trunk is inconsistent with the evidence. The failure boundary moves toward VLAN 20-specific configuration.
All VLANs fail across the same trunk
If previously healthy VLANs all stop crossing one inter-switch link, widen scope. Inspect physical link, trunk operational mode, interface admin state, negotiation, port-channel state if applicable, and any shared uplink failure before editing individual VLAN lists.
Same-VLAN peers communicate, but another VLAN is unreachable
This is classic evidence that Layer 2 may be healthy. If hosts within VLAN 40 communicate locally but cannot reach VLAN 50, move to the Layer 3 boundary: default gateway, SVI/router interface, routes, firewall policy, and return path.
MAC learned in an unexpected VLAN
This is direct Layer 2 placement evidence. Check the access VLAN, dynamic VLAN assignment, authentication role, phone/PC voice-data logic, or upstream tagging that could put the endpoint into VLAN 70.
Phone works, attached PC lands in the wrong network
An access switch port can support separate voice and data VLAN roles. A phone may tag voice traffic while the attached PC sends untagged data. The phone can therefore work perfectly even when the data VLAN is wrong.
Native VLAN mismatch affects untagged traffic while tagged VLANs still work
The trunk is not completely broken. Untagged frames are simply being associated with different VLANs on each side. Compare both endpoints before changing access ports elsewhere.
Do not confuse native/untagged behavior with all trunk traffic
A native mismatch can coexist with fully functional tagged VLANs. That makes “trunk works” an incomplete statement. The correct question is whether each relevant VLAN—including any untagged/native traffic—is interpreted consistently at both ends.
DHCP fails only in a newly created VLAN
Creating a VLAN does not automatically create an SVI, trunk allowance, DHCP relay, scope, or firewall permission. New-VLAN failures are therefore best treated as a dependency checklist.
Guest reaches Staff unexpectedly
This is not a success condition if the design requires segmentation. The endpoint may be in the wrong VLAN, inter-VLAN routing may be too permissive, or firewall policy may contain an overly broad allow.
Connectivity itself is the failure signature.
Positive and negative tests are both required
After a segmentation correction, confirm required Guest access such as Internet connectivity still works while prohibited Guest-to-Staff flows remain denied. A fix that blocks everything may remove the security symptom while breaking the intended service.
Port link down is not primarily a VLAN problem
If the interface is down/down or administratively down, solve that lower-layer condition first. VLAN configuration cannot carry frames across a port that is not operational.
Access port is configured for the wrong VLAN
This is a high-confidence case because the access-port configuration and DHCP result independently point to the same placement error.
VLAN exists on one switch but not the next
A trunk can be configured to allow VLAN 50, yet the downstream switch may not have VLAN 50 defined or active according to platform behavior. The path can therefore fail even when the allowed list looks correct.
The VLAN reaches the core, but the gateway/SVI is down
Layer 2 placement and carriage can be correct while inter-VLAN and remote access fail because the Layer 3 gateway is not operational.
The gateway is up, but inter-VLAN policy blocks the path
This is expected segmentation behavior, not a fault. Troubleshooting always compares observed behavior with the requirement.
VLAN pruning or allowed-list asymmetry breaks only part of the topology
In multi-switch paths, a VLAN may be present on the first trunk but disappear on a later trunk. Build a path map from endpoint to gateway and verify VLAN presence at every hop instead of assuming one correct trunk proves the whole path.
Trace the VLAN hop by hop
A lease can reveal the VLAN the broadcast actually entered
If each VLAN has a distinct DHCP scope, the subnet a client receives becomes independent evidence about where its broadcast was processed. This is especially useful when combined with access-port or MAC-table evidence.
SSID-to-VLAN mapping creates the same placement problem without an access port
Wireless clients can be placed into VLANs through SSID configuration, authentication roles, dynamic policies, or controller settings. A wireless client receiving the Guest subnet while connected to Staff SSID should be analyzed as a VLAN-placement problem before assuming DHCP itself is broken.
Authentication can change VLAN placement after the physical port or SSID is known
In some designs, an authentication result assigns a VLAN dynamically. Two users on the same physical interface or SSID can therefore land in different VLANs. When placement seems inconsistent, correlate authentication role, assigned VLAN, and MAC-table/DHCP evidence.
“The VLAN exists” is not enough
A defined VLAN can still fail because no access ports use it, it is missing from a trunk, its gateway is down, DHCP relay is missing, or policy blocks the desired flow. Configuration presence is not the same as end-to-end operational state.
Find the first point where the VLAN path diverges
| Observed sequence | Stronger interpretation |
|---|---|
| Link down before VLAN tests | Layer 1/admin state first |
| MAC learned in wrong VLAN | Access/dynamic placement mismatch |
| Correct VLAN locally, disappears at trunk | Trunk allowance/existence/tagging |
| VLAN reaches gateway, remote VLAN fails | Routing or firewall/policy |
| New VLAN reaches gateway, no DHCP | Relay/scope/service path |
| Guest reaches prohibited resource | Segmentation/policy defect |
Swipe horizontally to see the failure sequence.
Wrong subnet plus wrong MAC/VLAN placement
Only VLAN 20 fails between switches
The working VLAN proves the shared cable and inter-switch link. Add or correct VLAN 20 according to the intended design, then verify VLAN 10 still works.
All VLANs fail after an uplink change
Start with the shared uplink state, not three separate VLAN edits.
New VLAN gets no lease but reaches the gateway
Because the gateway is reachable, access VLAN and trunk carriage are substantially proven.
Guest unexpectedly reaches Staff after a firewall change
The fix is not to move the client to another VLAN if placement is correct. Restore least-privilege inter-VLAN policy.
Verify the original failure and a known-good control after each change
If you add VLAN 20 to a trunk, test VLAN 20 and confirm VLAN 10 still works. If you correct Guest segmentation, verify Guest retains required Internet access while Staff resources remain blocked. If you repair DHCP in a new VLAN, confirm the lease comes from the correct scope and the gateway is reachable.
Strong VLAN answers name the exact boundary
Instead of saying “VLAN problem,” say: “VLAN 20 works locally but is absent from the trunk allowed list, while VLAN 10 crosses the same uplink successfully. The physical path is known-good; VLAN 20 trunk carriage is the first failed boundary.”
24 VLAN Failure Signatures digital flashcards
Practice wrong access VLANs, trunk failures, native VLAN mismatches, MAC/VLAN evidence, DHCP clues, SVI/gateway state, voice/data VLAN roles, segmentation, and verification.