How to distinguish host configuration, VLAN, gateway, routing, ACL, DHCP, and DNS failures from their symptoms.
When a link is healthy but a service is unavailable, separate the local network, the routed path, and the service dependency. The affected population is important evidence: a failure limited to one VLAN, destination, or name usually has a narrower cause than a site-wide outage.
| Symptom | Useful first checks |
|---|---|
| Client has no expected IPv4 configuration | DHCP scope, relay path, VLAN assignment, and client lease state |
| Local-subnet communication works but remote subnet access fails | Default gateway, routing, route return path, and inter-zone policy |
| Direct IP works but a hostname fails | DNS configuration, resolver reachability, and name records |
| One VLAN fails across an uplink | VLAN membership, trunk tagging, and allowed-VLAN configuration |
| One group cannot reach one destination | ACL, firewall policy, route selection, or service-specific access control |
1Host address and prefix
2→ local VLAN and gateway
3→ routed path and return path
4→ DNS resolution
5→ application or service authorization
Test each dependency deliberately. A successful name lookup does not prove an application is available; successful local pings do not prove a route exists; a valid address lease does not prove the default gateway or DNS server is reachable.
1VLAN 30 users can reach a local printer.
2They cannot reach 10.20.40.20.
3They can resolve and use public websites.
This pattern points away from a total local-link or DNS failure. Compare the route and policy path to 10.20.40.20 with a working VLAN or host, then review recent changes affecting that destination.
Start at the endpoint before changing shared infrastructure: capture address, prefix, gateway, DNS configuration, interface state, and the exact test results. See Core Network Services for the addressing, naming, and time dependencies behind these checks.