A VLAN problem is really a boundary problem
Students troubleshoot VLANs faster when they stop treating “the VLAN” as one device or one setting. A successful flow can cross several boundaries: endpoint link → access-port VLAN → Layer 2 forwarding → trunk carriage → gateway/SVI → Layer 3 routing → security policy. Your job is to find the first boundary where expected behavior stops being supported by evidence.
Practice choosing the next observation rather than changing several ports at once with the AP Networking Switching, VLANs, and Ethernet Practice Test. The harder questions use selective VLAN failures, security limits, and loop evidence to distinguish an incomplete path from an unrelated DNS symptom.
Classify the failure before changing configuration
Inside one VLAN
Two intended same-VLAN hosts cannot communicate. Start with endpoint link, access VLAN, subnet configuration, MAC learning, and local Layer 2 path.
Across a trunk
Hosts work on the same switch, but the VLAN fails when traffic must cross an uplink. Inspect trunk state, VLAN allowance, VLAN existence, and tagging consistency.
Between VLANs
Same-VLAN traffic works but another subnet fails. Move the investigation toward gateway/SVI state, routing, ACL/firewall policy, and return path.
A repeatable VLAN troubleshooting sequence
Wrong access VLAN: a classic failure signature
The strongest evidence is not merely the failed ping. The MAC table places the endpoint in VLAN 30 while the addressing plan expects VLAN 20. The narrow correction is the access-port assignment—not changing DNS, replacing the router, or adding a route.
The MAC table tells you where the switch actually sees the endpoint
If the endpoint MAC is absent after generating traffic, investigate whether the host is transmitting, the port is operational, or the path is different from your assumed topology. If the MAC appears in the wrong VLAN, investigate access/tagging configuration. If it appears on an unexpected port, your physical/logical map may be wrong.
Review the underlying artifact in MAC Address Table Explained.
One working VLAN is a powerful control
Because VLANs 10 and 30 successfully use the same physical uplink, a complete cable or uplink failure is a weak hypothesis. The difference between working and failing traffic is VLAN 20, and the artifact shows VLAN 20 missing from one side's allowed set.
Native-VLAN mismatch changes the meaning of untagged traffic
On trunk technologies/configurations where a native VLAN is used, untagged frames are associated with that native VLAN. If the two ends disagree, the same untagged frame can be classified into different VLANs at opposite ends. That can produce confusing partial connectivity and control-plane warnings.
DHCP failure on one VLAN does not automatically mean the DHCP server failed
The working VLAN is a control showing the DHCP service is not completely unavailable. For VLAN 20, inspect whether broadcasts reach the gateway/relay function, whether relay configuration is present, whether the routed path reaches the server, and whether an appropriate scope exists.
Continue with the DHCP Troubleshooting Guide.
Same-VLAN success can coexist with a dead Layer 3 gateway
Hosts in one VLAN can switch frames directly without using their default gateway. Therefore, two same-VLAN hosts successfully communicating does not prove that the SVI/router interface is operational.
A route and an allow policy answer different questions
Routing decides where Layer 3 traffic should go. Security policy decides whether the defined flow is permitted. A routing-table entry can be correct while an ACL/firewall intentionally denies TCP/443 from VLAN 20 to VLAN 50.
The route supports reachability in principle; the deny log explains why this specific flow does not pass. “Inter-VLAN routing is broken” is too broad.
Use the symptom pattern to choose the next artifact
| Observed pattern | Stronger hypotheses | Best next evidence | Weak first move |
|---|---|---|---|
| One host fails; peers in same VLAN work | Host link, access VLAN, IP/prefix, endpoint issue | Port config + MAC learning + host config | Rebuild the trunk |
| One VLAN fails across uplink; others work | Allowed VLAN/tagging/VLAN existence | Trunk state on both ends | Replace uplink cable immediately |
| Same-VLAN works; all remote networks fail | Gateway/SVI, routing, policy | Gateway reachability + interface/route state | Change access VLAN |
| DHCP fails only in one remote VLAN | Relay, scope, VLAN path, gateway | Relay config + DHCP transaction evidence | Assume DHCP server is globally down |
| Inter-VLAN ping works; one application port fails | ACL/firewall/service listener | Policy log/counter + port test | Change subnet mask |
Swipe horizontally to see the complete troubleshooting table.
Strong troubleshooting tries to disprove the favorite hypothesis
Hypothesis: trunk is physically down
Falsifier: another VLAN successfully crosses the same uplink. That strongly weakens a total physical-down explanation.
Hypothesis: DHCP server is down
Falsifier: clients in another relayed VLAN receive leases from the same server.
Hypothesis: VLAN routing is absent
Falsifier: the source reaches a host in the destination VLAN on one protocol while only a different port is denied.
Hypothesis: endpoint is in correct VLAN
Falsifier: its source MAC is learned under a different VLAN than the design requires.
One changed fact can completely change the best answer
| Original scenario | Changed fact | How reasoning changes |
|---|---|---|
| VLAN 20 fails across trunk; VLANs 10/30 work | Now all VLANs fail | A shared trunk/physical failure becomes much more plausible. |
| PC MAC learned in wrong VLAN | MAC now learned in intended VLAN | Access placement is supported; move to IP/gateway/path evidence. |
| Same-VLAN peers work, gateway fails | Gateway now responds | Move outward toward routing, policy, destination, or application. |
| DHCP fails only VLAN 20 | Static IP in VLAN 20 reaches remote networks | Basic VLAN/routed path is supported; DHCP-specific dependencies become stronger. |
Swipe horizontally to use the changed-fact table.
Answer VLAN troubleshooting questions in four moves
- State the boundary: “The failure appears VLAN-specific across the trunk.”
- Name the evidence: “Other VLANs cross the same uplink, but VLAN 20 is missing from the allowed set.”
- Choose the narrow action: “Correct VLAN 20 carriage rather than replacing the entire uplink.”
- Verify both sides: “Retest VLAN 20 and confirm the previously working VLANs remain healthy.”
24 VLAN troubleshooting flashcards
These cards emphasize diagnosis, evidence boundaries, failure signatures, and changed-fact reasoning—not just vocabulary.
Continue the troubleshooting chain
Related troubleshooting deep dive
For a narrower evidence-based scenario, use VLAN Access Port vs. Trunk Port Mismatch Troubleshooting. It includes a free interactive reasoning activity and step-by-step diagnostic evidence.