A network configuration is a dependency chain, not a collection of isolated values
A configuration field can be syntactically valid and still be operationally wrong. Strong analysis asks whether the endpoint address, prefix, gateway, VLAN, DHCP scope, switchport, route, DNS resolver, firewall policy, and application all describe the same intended path.
The best AP-style answer identifies the first demonstrated contradiction, explains the symptom it predicts, and names the next artifact that could falsify the hypothesis.
Use SCOPE → ADDRESS → SEGMENT → PATH → POLICY → SERVICE → VERIFY
1. Scope
One host, one VLAN, one application, or everyone?
2. Address
Does IP/prefix define the intended local subnet?
3. Segment
Does access VLAN, DHCP scope, and gateway agree?
4. Path
Do forward and return routes exist?
5. Policy
Do ACL/firewall rules permit the exact flow?
6. Service
Does DNS resolve correctly and is the application listening?
7. Verify
Repeat the original failed test and preserve a control.
What each configuration field can prove—and what it cannot
| Artifact / field | Useful evidence | Does not prove | Strong next comparison |
|---|---|---|---|
| IP + prefix | Host's calculated local subnet | Gateway exists or VLAN is correct | Gateway and intended subnet |
| Default gateway | Configured next hop for remote traffic | Gateway is reachable or routing onward works | Subnet math + neighbor/reachability |
| Access VLAN | Intended Layer 2 segmentation at that port | DHCP actually came from matching scope | Lease, relay, VLAN documentation |
| DHCP lease | What addressing client received | Why that scope was selected | Relay/helper and server logs |
| Route table | Known forwarding choices | Return path or firewall permission | Opposite-side route + policy |
| Firewall allow | Shown policy permits matching flow | Route, listener, DNS, or return traffic | Path and service state |
| DNS result | Name-to-address answer from a resolver | Target service is reachable | IP test, route, port/service |
Swipe horizontally to inspect the complete evidence matrix.
Client and default gateway are in different /25 subnets
Contradiction found
The gateway is not an ordinary on-link gateway for the client's calculated subnet. The evidence supports an IP/prefix/gateway mismatch, but it does not tell you which field is wrong relative to the intended design.
One bit of configuration can completely change Case 1
| Client | Gateway | Result | Why |
|---|---|---|---|
| 10.60.12.130/25 | 10.60.12.1 | Mismatch | Different /25 blocks |
| 10.60.12.130/24 | 10.60.12.1 | Gateway is local | Both are in 10.60.12.0/24 |
| 10.60.12.130/25 | 10.60.12.129 | Gateway is local | Both are in 10.60.12.128/25 |
Swipe horizontally to compare the changed facts.
The switchport says VLAN 40, but the lease looks like VLAN 50
The client lease matches the documented VLAN 50 subnet, creating a contradiction with the access-port configuration. Do not jump directly to “change the port to VLAN 50.” Possible explanations include wrong port assignment, wrong DHCP relay/scope selection, rogue DHCP, stale documentation, or a different actual path than assumed.
Two interfaces, two default gateways, one ambiguous outbound decision
Multiple defaults can produce unexpected or asymmetric outbound behavior depending on the host's route metrics and policy. The configuration is not diagnosed by deleting a gateway blindly. First inspect the host route table, determine the intended default egress, and identify which remote networks should instead use specific routes.
VLAN 30 exists at both ends but is omitted from the uplink
This predicts a selective failure: VLANs 10 and 20 can cross the shown trunk, while VLAN 30 cannot. If DHCP or the gateway for VLAN 30 is reached across this uplink, VLAN 30 clients may fail those dependencies even though other VLANs work.
Compare this pattern with VLAN Mismatch Symptoms.
A forward route and firewall allow are necessary evidence—not complete proof
The shown route covers the destination and the shown firewall rule appears to cover the source, destination, protocol, and port. But return routing and server listener state are unresolved.
Public websites work, but an internal-only name fails
This pattern sharply narrows the problem. General IP connectivity exists, and the internal service is reachable by address. The unresolved dependency is name resolution for the internal namespace. Compare the configured resolver with the organization's intended internal DNS service and query the internal record directly.
A wrong mask can make a remote host look local
The address itself can be correct while the prefix is wrong. The resulting symptom is especially valuable: the host may attempt local delivery for a destination that peers correctly send to the gateway.
Correct VLAN, wrong DHCP options
The lease address matches VLAN 40, but the supplied gateway is outside the client's /24. This is different from receiving an entirely wrong scope. Inspect the DHCP option configuration for the correct scope rather than changing the access VLAN.
A route exists, but a more specific route changes the path
“There is a route to 10.90.0.0/16” is incomplete analysis. Longest-prefix match means a more specific route can override the broader path for the destination.
An allow rule can look right but miss the actual flow
The destination and port match, but the source does not fall within 10.20.0.0/16. The existence of an “allow 443” rule therefore does not prove this client's flow is allowed.
Network path succeeds, but the service is not listening
The failure has moved beyond basic routing and firewall reachability. A refusal plus no listener supports an application/service-state problem. Reconfiguring DNS or the client gateway would ignore the strongest evidence.
Packets arrive at the server, but replies leave the wrong way
The forward path is proven far enough to reach the server. The missing or incorrect return path can create asymmetric failure. The strongest next correction belongs in routing—not in the client's DNS settings.
Use the failure pattern to decide what to compare first
| Observed symptom | Strong early comparison | Why | Weak first move |
|---|---|---|---|
| One client gets wrong subnet | Port VLAN ↔ DHCP lease/scope | Host-specific segmentation or scope selection | Change core default route |
| Entire VLAN fails gateway/DHCP | VLAN existence ↔ trunk allowance ↔ SVI | Shared VLAN path dependency | Reinstall one client NIC |
| IP works, hostname fails | DNS resolver ↔ required namespace | Layer 3 path already has a successful control | Change subnet mask |
| Forward packet reaches server, no reply | Server return route ↔ client prefix | Forward path is already demonstrated | Change client access VLAN |
| Only TCP/443 fails | Exact firewall flow ↔ listener | Protocol/port-specific symptom | Replace DHCP scope |
| Remote destination treated as local | Host prefix ↔ intended subnet | Wrong locality calculation | Change DNS server |
Swipe horizontally to inspect the troubleshooting matrix.
Practice separating observation, conclusion, and next evidence
Lab A
Observation: the configured gateway is outside 192.168.70.0/24. Supported conclusion: the ordinary gateway relationship is inconsistent. Unresolved: which configuration field is wrong. Next evidence: intended subnet documentation or a working peer.
Lab B
The working peer weakens a total VLAN-30 infrastructure outage. Investigate the problem port/client path, DHCP source, and whether the shown port is actually the one serving the client.
Lab C
The firewall log is the strongest direct evidence for the shown flow. Do not repair DNS merely because the application is accessed by name.
Eight reasoning mistakes to eliminate
- Assuming a valid-looking IP must be correct for the intended VLAN.
- Assuming the gateway is local because its first three octets look similar.
- Changing a switchport merely because the lease matches another VLAN.
- Treating a forward route as proof of a return route.
- Treating an allow rule as proof the exact flow matches it.
- Blaming DNS when direct IP connectivity also fails.
- Repairing the command output instead of the configuration source it revealed.
- Choosing a fix before stating what evidence would falsify the diagnosis.
Write every configuration-analysis answer in five parts
Observation
Quote or calculate the exact contradiction.
Supported conclusion
State only what the evidence establishes.
Unresolved question
Name what remains unknown.
Next evidence
Choose the artifact that can separate competing causes.
Verification
Repeat the original failed task after correction.
24 network-configuration analysis flashcards
These cards emphasize contradictions, evidence limits, troubleshooting controls, and AP exam-transfer reasoning—not memorized definitions.