Quick diagnosis: what this problem is really testing
Use ARP, VLAN membership, masks, host firewalls, and switch evidence to diagnose two devices that should communicate locally but cannot. The key is to treat every command result, packet, address, route, VLAN, or timeout as evidence. A useful diagnosis explains both what the evidence proves and what it does not prove.
Why same-subnet failures are special
When two hosts believe they are on the same IPv4 subnet, they normally communicate without sending the packet to the default gateway. The sender uses ARP to learn the destination MAC address, then sends an Ethernet frame directly. That makes a same-subnet failure a powerful clue: start with addressing, ARP, VLAN placement, switching, and host security before blaming an upstream router. In a classroom or exam scenario, write down the observation before the conclusion. Compare the affected device with a known-good device when possible, and make one change at a time. This preserves the chain of evidence and helps you tell a root cause from a side effect.
First prove they really are in the same subnet
Do not trust similar-looking addresses. Compare each host's IP address and subnet mask. 192.168.10.20/24 and 192.168.10.80/24 are local to each other, but a mismatched mask can make one host believe the other is remote. Calculate the network address on both devices. If the hosts disagree about whether the destination is local, their packet-handling decisions will differ. A strong technician also asks about scope: one device, one VLAN, one switch, one site, or every user. Scope can eliminate entire categories of causes before a configuration is touched. Document the expected state and the observed state so the next step is based on a difference you can defend.
Use ARP as the dividing line
Clear or inspect the ARP cache, then attempt communication. If the destination appears with a resolved MAC address, Layer 2 discovery succeeded and you can investigate host firewalls or the application. If the entry stays incomplete or absent, the sender is broadcasting for the destination and not receiving a usable reply. That shifts attention to VLANs, switching, cabling, or the destination host. In a classroom or exam scenario, write down the observation before the conclusion. Compare the affected device with a known-good device when possible, and make one change at a time. This preserves the chain of evidence and helps you tell a root cause from a side effect. See also CLI output practice and find the network misconfiguration.
The wrong-VLAN trap
Two devices can have addresses from the same IP subnet while physically sitting in different VLANs. Their ARP broadcasts do not cross the VLAN boundary, so each device waits for a reply that never arrives. This is why IP addresses alone cannot prove Layer 2 adjacency. Verify the access VLAN on both switch ports and the VLAN carried across any intervening trunks. A strong technician also asks about scope: one device, one VLAN, one switch, one site, or every user. Scope can eliminate entire categories of causes before a configuration is touched. Document the expected state and the observed state so the next step is based on a difference you can defend.
When both hosts can ping the gateway
This symptom is especially useful. If A and B can each ping the same gateway but cannot ping each other, basic links and some switching work. Possible causes include host firewalls that block peer traffic, wireless client isolation, private VLAN behavior, security policies, or unusual switching configuration. The gateway success narrows the search; it does not prove the hosts can exchange frames directly. In a classroom or exam scenario, write down the observation before the conclusion. Compare the affected device with a known-good device when possible, and make one change at a time. This preserves the chain of evidence and helps you tell a root cause from a side effect.
Host firewalls and endpoint isolation
Modern operating systems may classify a network as public and block inbound echo requests or file-sharing traffic. Test more than one protocol when appropriate and inspect the local firewall profile. On managed wireless networks, client isolation may intentionally prevent station-to-station communication even though both clients can reach the internet. A strong technician also asks about scope: one device, one VLAN, one switch, one site, or every user. Scope can eliminate entire categories of causes before a configuration is touched. Document the expected state and the observed state so the next step is based on a difference you can defend.
Switch evidence to collect
Check port status, learned MAC addresses, access VLAN assignments, and whether the expected VLAN exists across the path. A switch that learns each host's MAC on the expected ports gives different evidence from a switch that never learns one endpoint. Avoid changing trunks or VLANs until the observed MAC table and ARP behavior support that direction. In a classroom or exam scenario, write down the observation before the conclusion. Compare the affected device with a known-good device when possible, and make one change at a time. This preserves the chain of evidence and helps you tell a root cause from a side effect. Reinforce this with Wireshark packet-capture practice and network log analysis practice.
Duplicate addresses can create confusing results
A duplicate IP can make communication intermittent or send frames to the wrong MAC address as ARP entries change. If an IP maps to different MAC addresses over time, investigate duplication. This is one reason a single successful ping is not enough evidence to declare the network healthy. A strong technician also asks about scope: one device, one VLAN, one switch, one site, or every user. Scope can eliminate entire categories of causes before a configuration is touched. Document the expected state and the observed state so the next step is based on a difference you can defend.
A clean troubleshooting order
Record both IP configurations, calculate both network addresses, test local loopback and interface state, ping the peer, inspect ARP, verify VLAN and MAC-table evidence, then inspect host security. This order moves from facts on the endpoints toward the shared network and reduces random changes. In a classroom or exam scenario, write down the observation before the conclusion. Compare the affected device with a known-good device when possible, and make one change at a time. This preserves the chain of evidence and helps you tell a root cause from a side effect.
How to explain the diagnosis
A strong explanation connects layers: 'Host A treats B as local, sends ARP broadcasts, but never learns B's MAC. The switch ports are in different VLANs, so the broadcast cannot reach B.' That is more useful than simply saying 'VLAN problem' because it explains why the symptom occurs. A strong technician also asks about scope: one device, one VLAN, one switch, one site, or every user. Scope can eliminate entire categories of causes before a configuration is touched. Document the expected state and the observed state so the next step is based on a difference you can defend.
Evidence ladder: what to check before you change anything
| Evidence | What it can establish | What it cannot establish alone |
|---|---|---|
| IP configuration | Address, prefix/mask, gateway and DNS settings | That the path beyond the local device works |
| Ping | Whether a particular target replies to ICMP echo | That every protocol or application works |
| ARP/MAC evidence | Local Layer 2 discovery and switching clues | End-to-end routing or DNS health |
| Packet capture | Which messages were actually observed | Traffic that the capture point could not see |
Free interactive troubleshooting check
Read the three prompts. Predict the best reasoning move, then reveal the coaching answer.
- Scenario 1: The first test fails. What should you do next?
- Scenario 2: A later-hop or downstream test succeeds. What does that tell you?
- Scenario 3: Only one device is affected. Where should your investigation lean first?
Practice task: build a defensible diagnosis
Create a four-column evidence sheet labeled Observation, What it proves, What it does not prove, and Next test. Use at least five pieces of evidence from this guide. Then explain your diagnosis in 100–150 words without using the phrase “it is probably” unless you name the evidence supporting that probability.
Continue with AP Networking scenario questions, free-response practice, and configuration analysis practice.
Frequently asked questions
Should I memorize a fixed troubleshooting order?
Learn a dependable baseline, but let evidence change the order. A packet capture or command output may immediately rule out several layers.
Is one successful ping enough?
No. It proves a specific exchange succeeded at that moment. It does not prove DNS, TCP ports, applications, or every path is healthy.
What makes an AP Networking explanation strong?
Connect the symptom to a mechanism, cite the evidence, and choose a next test that can distinguish between remaining causes.
Teacher and student extension: compare two competing explanations
Take one failure scenario from this page and write two explanations that could both fit the first symptom. For each explanation, identify one piece of evidence you would expect to see if it were correct and one result that would weaken it. Then choose the single next test that gives you the most useful separation between the two explanations. This is the habit that turns troubleshooting from guessing into diagnosis.
For students, the goal is not to use the most commands. The goal is to ask the smallest number of useful questions. For teachers, this makes an effective five-minute warm-up: give students the symptom first, reveal one artifact at a time, and require them to revise their hypothesis as evidence arrives. A student who changes an answer because new evidence demands it is demonstrating stronger networking reasoning than a student who guessed the final cause immediately.
Finish by drawing the packet path from source to destination. Label the endpoint, local switch or wireless connection, VLAN or subnet boundary, default gateway when required, and any service involved in the failure. Mark where your evidence is direct and where you are still making an inference. That distinction is one of the most transferable troubleshooting skills in the course.