Find the first boundary that fails instead of guessing a device
Segmentation creates intentional boundaries. A client reaching a service in another VLAN may depend on endpoint placement, access-port state, VLAN existence, trunk carriage, DHCP configuration, a local gateway, inter-VLAN routing, firewall policy, destination-side routing, and the application itself. The fastest diagnosis preserves every checkpoint already proven and asks which next artifact can separate the remaining causes.
Core reasoning: Source requirement → intended segment → local attachment/IP → gateway → required Layer 2 carriage → route → policy → destination/return path → service → positive and negative verification.
Write the intended flow as a dependency map
For a Staff client in VLAN 20 reaching an application in VLAN 40, write down source IP/prefix/VLAN, source gateway, destination IP/prefix/VLAN, the switches/trunks the source VLAN must cross, routing boundary, security boundary, destination gateway, and exact service such as TCP/443. This turns “the server won't open” into a path that can be tested.
| Boundary | Expected state | Useful evidence | Dangerous overclaim |
|---|---|---|---|
| Access | Port/SSID maps to intended VLAN | Port VLAN, SSID mapping, client IP | “Link is up, so placement is correct.” |
| Trunk | Required VLAN exists and is carried | Allowed/active VLANs, working VLAN controls | “Other VLANs work, so every VLAN works.” |
| Gateway | Correct local L3 boundary is reachable | IP/mask/gateway, ARP, gateway state | “The SVI is configured, so it is operational.” |
| Routing | Both sides have usable paths | Exact destination route/next hop, reverse route | “A route exists, so routing is correct.” |
| Policy | Required exact flow permitted | Rule order, logs/counters, zones | “An allow rule exists, so it must match.” |
| Service | Destination listens and responds | Port/listener/application evidence | “Ping works, so HTTPS works.” |
Swipe horizontally to see the full table.
Wrong VLAN membership can masquerade as DHCP, gateway, routing, or policy failure
If VLAN 20 should use 10.20.0.0/24 but the endpoint receives 10.30.0.55/24, first ask why its logical attachment disagrees with design. The switch access port may be assigned to VLAN 30, a wireless SSID may map to the wrong VLAN, or an unintended DHCP source may be reachable.
Do not “repair” the symptom by statically assigning a VLAN 20 address to an endpoint still attached to VLAN 30. That can create an address that looks correct while Layer 2 placement remains wrong. Compare port/SSID mapping and the actual lease with a healthy peer.
The subnet mask determines whether the client ARPs locally or sends to its gateway
For every destination, a host first decides whether it believes that destination is local. A wrong prefix can therefore produce a segmented-LAN failure that looks like routing trouble. If the client incorrectly considers a remote address local, it may ARP for that destination instead of sending the frame to its gateway.
Illustrative source Client: 10.20.0.25 Correct /24: 10.20.0.0–10.20.0.255 is local Destination: 10.40.0.50 → remote → send toward gateway If the mask is incorrectly broad enough to classify 10.40.0.50 as local, the client can attempt local resolution instead of using the router.
ARP evidence is meaningful only for the local next hop. A router does not ARP through arbitrary routed networks.
Same-VLAN success plus gateway failure sharply narrows the boundary
If a client exchanges traffic with same-VLAN peers but cannot reach its configured gateway, local switching is at least partly working. Inspect the client's gateway value, ARP behavior, gateway/SVI state, and the Layer 2 path to that gateway. If every client in the VLAN fails at the gateway while other VLAN gateways work, focus on dependencies unique to that VLAN.
An SVI can be configured in the running configuration yet not be operational. Platform behavior varies, so distinguish configured state from operational state and active VLAN conditions.
Working VLANs are controls for the physical link—but not proof for the missing VLAN
Suppose VLANs 10 and 20 cross an inter-switch link, but VLAN 30 does not. Those working VLANs show that the physical link can forward some traffic. They do not prove VLAN 30 exists on both switches, is allowed on the trunk, is active, or has consistent tagging/native expectations.
If every VLAN fails across the same link, broaden toward physical state, trunk operational state, shutdown, power, or upstream failure.
Deepen this mechanism with VLANs Explained and VLAN Mismatch Symptoms.
The lease itself is a topology clue
No lease, APIPA, an address from the wrong subnet, a missing gateway option, or an unexpected DHCP server each tells a different story. A client in the wrong VLAN can receive a perfectly valid lease—for the wrong segment. A remote DHCP server may also require relay behavior at the routing boundary.
| Observed lease state | What it suggests | Next discriminating evidence |
|---|---|---|
| 169.254.x.x | Expected IPv4 configuration was not obtained | VLAN, DHCP exchange, relay, server/scope availability |
| Valid address from wrong subnet | Wrong placement or unintended DHCP path/source | Port/SSID VLAN + DHCP server/lease source |
| Correct address, wrong gateway | Bad DHCP option or manual configuration | Lease options vs healthy peer/design |
| Old clients work; new clients fail | New lease acquisition problem | Scope capacity, server/relay/exchange |
Follow source learning through the intended Layer 2 path
If a client's MAC is learned on its expected access port and then on the expected upstream trunk, that is evidence that source frames are reaching those switching points. An unexpected port or VLAN suggests wrong attachment, cabling, topology, or assignment. Rapid movement between ports can indicate a loop or unstable topology, but one MAC move after legitimate topology change is not enough to declare a loop.
MAC tables answer Layer 2 forwarding questions. They do not prove the client has the right gateway, a router has the right route, or a firewall permits the application.
See MAC Address Table Explained and Network Loop & Broadcast Storm.
Same-VLAN works but remote VLAN fails: advance to the Layer 3 boundary
If two hosts inside VLAN 20 communicate, but VLAN 20 cannot reach any other subnet, do not keep troubleshooting basic switching between those two hosts. Verify the clients' default gateway, VLAN 20 gateway state, and routing/policy beyond it. If VLAN 20 reaches VLAN 30 but not VLAN 40, destination specificity points toward the route or policy for VLAN 40 rather than a universal gateway failure.
For the exact failed destination, inspect the route selected by longest-prefix match and its next hop. A default route can coexist with a wrong more-specific route.
A request arriving at the server proves much of the forward path
If application or packet evidence shows the server received the request, the source-side access VLAN, gateway, much of the forward routing, and the path into the destination have already succeeded for that request. The next question is why the response did not return.
Inspect the server's local IP/prefix/default gateway, reverse route, destination-side policy, stateful-firewall behavior, and any asymmetric path. Do not restart at the source access port unless new evidence contradicts the proven forward path.
Test the exact flow against rule order and intended segmentation
Represent the failed transaction precisely: source IP/network, destination IP, protocol, destination service/port, security zones, and connection state. On a first-match policy system, an early broad deny can shadow a later narrow allow. An allow rule existing somewhere in the configuration does not prove it handles the test flow.
Use Firewall Rules Explained for rule-order reasoning and Port Blocked Troubleshooting for exact service failures.
A deny can be correct network behavior
A guest client being unable to reach a management VLAN is not automatically a fault. If policy explicitly prohibits that path and logs show the exact guest-to-management flow being denied, the network is enforcing segmentation correctly. Troubleshooting must compare observed behavior with the requirement before changing controls.
This is why “make it ping” is not a sufficient repair goal. A segmented LAN is supposed to allow some paths and deny others.
Reachability to the host does not prove the required application is available
A server can answer ICMP while TCP/443 has no listener. It can listen on 443 while a host firewall denies the source subnet. It can complete TCP while the application returns an error. Once network path and policy are proven, inspect listener state, host policy, and application evidence rather than continuing to alter VLANs or routes.
Match verification to the original requirement: if the requirement is HTTPS, verify HTTPS or the relevant TCP service—not merely ping.
Know exactly what each artifact can and cannot prove
ARP
Useful for local next-hop resolution. Repeated ARP for a remote destination can expose a wrong local-subnet assumption.
MAC table
Shows where source MACs are learned at Layer 2. It does not prove routing or application health.
Route table
Shows control-plane path selection. A route's presence alone does not prove successful forwarding end-to-end.
Firewall log
A matching deny is strong policy evidence. No log is ambiguous if logging/path assumptions are uncertain.
Server log
A recorded request proves arrival at that service point. Missing response still requires reverse-path/service reasoning.
Ping
Tests the specific ICMP reachability attempted. It does not prove TCP/443, DNS, or application correctness.
VLAN 30 works locally on both switches but cannot cross one uplink
VLAN 30 hosts on Switch A communicate with one another; VLAN 30 hosts on Switch B do the same. VLANs 10 and 20 cross the A–B trunk successfully. VLAN 30 hosts cannot reach peers across the trunk. This combination preserves endpoint access, VLAN 30 local switching, and the trunk's physical ability to forward other VLANs.
The high-value next evidence is VLAN 30 presence/allowed-active state on both sides of that trunk. Replacing the cable is poorly matched to the VLAN-specific scope.
Client receives an address from the wrong subnet
A workstation intended for VLAN 20 receives 10.30.0.55/24 with a VLAN 30 gateway. The lease is internally consistent, so DHCP is not simply “down.” Compare the access-port VLAN and a healthy VLAN 20 peer. The port is found assigned to VLAN 30.
The correct repair is to restore intended placement and obtain a fresh lease. Statically assigning a 10.20.0.x address while the port remains in VLAN 30 would conceal the cause and create a Layer 2/Layer 3 mismatch.
The HTTPS allow exists—but an earlier rule shadows it
Staff VLAN users reach the application server's subnet but TCP/443 times out. A firewall deny counter/log increments for the exact test flow. The configuration contains a narrow HTTPS allow later in the policy, but a broader Staff-to-Server deny appears first.
Rule-order evidence identifies the first failed dependency. Correct the policy narrowly according to the intended requirement, then verify HTTPS succeeds and a prohibited comparison service remains denied.
The server records the request, but the client never receives the response
The server application log records the client's request at the test timestamp. That is powerful forward-path evidence. Inspection shows the server has an incorrect default gateway after a manual configuration change, so responses cannot follow the intended return path.
After correcting the server gateway, repeat the exact application transaction and verify the response returns. There is no justification for changing the source trunk or firewall if those earlier checkpoints remain proven.
Successful segmentation can look like failure to the wrong expectation
A guest user reports that an internal administration page is “down.” Guest Internet access works, the administration page works from the staff VLAN, and firewall logs show the guest flow matching the documented deny. No network repair is required. The correct conclusion is that the requested path violates segmentation policy.
This counterexample matters because good troubleshooting does not assume every failed connection should become permitted.
A repair must restore the intended path without destroying the boundary
Moving a guest into a trusted VLAN, disabling inter-VLAN filtering, permitting every VLAN on every trunk, or adding an any-to-any firewall rule can make a symptom disappear while making the network less correct. A segmented-LAN fix should be as narrow as the evidence and requirement allow.
Prove the repaired dependency and the segmentation guardrail
| Repair | Positive test | Negative/control test | Mechanism evidence |
|---|---|---|---|
| Access VLAN | Endpoint joins intended subnet and reaches intended gateway | Unintended segment is no longer assigned | Port/SSID mapping + fresh IP state |
| Trunk VLAN | Affected VLAN crosses required link | Other VLANs remain correct; unauthorized VLANs not added | Allowed/active state + traffic test |
| DHCP | Fresh client receives complete intended lease | Other scopes remain correct | Lease/server/relay evidence |
| Route | Required remote subnet follows intended path | Unrelated prefixes retain expected paths | Exact route/next hop + reachability |
| Firewall | Required exact application flow succeeds | Prohibited flow remains denied | Rule/log/counter + transaction |
| Return path | Response reaches original client | Other destination routing remains intact | Reverse route/gateway + transaction |
Record proof at each boundary
- Write source IP/prefix/VLAN and destination IP/prefix/VLAN.
- State the exact required protocol/service and whether policy should allow it.
- Confirm source placement and actual IP/gateway state.
- Mark source gateway reachability as proven, failed, or untested.
- Confirm the required VLAN exists across each necessary Layer 2 link.
- Inspect the exact destination route and next hop.
- Identify the matching firewall rule/log for the exact flow.
- Use destination evidence to determine whether the request arrived.
- Check the response/return path when forward arrival is proven.
- After correction, repeat the original transaction and a prohibited control.
Explain where the packet stopped, what evidence proves it, and what remains unknown
Observation: VLANs 10 and 20 cross an inter-switch link, but VLAN 30 does not; VLAN 30 works locally on both switches. Bounded inference: the link can forward traffic and VLAN 30 endpoints can switch locally, so a total physical-link failure and universal VLAN 30 failure are inconsistent with the evidence. Next discriminating artifact: inspect VLAN 30 existence and trunk allowed/active state on both sides. Correction: restore only the intended VLAN 30 carriage if the configuration is wrong. Verification: prove VLAN 30 crosses the link, existing VLANs remain healthy, and no unauthorized VLAN was introduced.
This form is stronger than “check the switch” because every claim has an evidence boundary and every change has a verification target.
24 segmented-LAN troubleshooting flashcards
Practice VLAN placement, trunks, DHCP, gateway reasoning, ARP/MAC evidence, routing, policy, return paths, service boundaries, and verification.