Step 2 — Establish a Theory of Probable Cause (and Question the Obvious)

With the facts gathered in Step 1, develop the most plausible explanation for the problem. Start with the simple, obvious possibilities and progressively work toward more complex theories as evidence dictates.

Start with Fast Wins

• Power and cabling: Is the device on? Are fans spinning and LEDs lit? Are cables firmly seated in the correct ports?
• Link status: Check NIC and switch port lights along with speed/duplex settings. Mismatches or amber LEDs point to physical-layer issues.
• IP basics: Use ipconfig/ifconfig to verify addressing, the default gateway, and DNS servers. APIPA addresses (169.254.x.x) signal DHCP trouble.
• Wireless checks: Confirm the SSID, signal strength, security settings, and whether the client is stuck behind a captive portal.
• Scope: Determine if the issue impacts a single user, an entire VLAN, a site, or the organization. Scope directs which OSI layers deserve attention.

Exam Tip: If a host can ping IP addresses but not hostnames, suspect DNS. If the host can reach the gateway but not the Internet, look at routing, ACLs, or NAT.

Build and Rank Theories

1. List hypotheses in order from most common or easiest to test to the least likely.
2. Validate with minimal disruption—swap a cable, reboot a service, or review logs before making large changes.
3. Change one variable at a time so you know exactly which action altered the outcome.

Gather Evidence

• Use your senses. Burning smells imply overheating components; clicking or grinding often indicates a failing hard drive; silence from a fan can signal power issues.
• Reproduce the issue. Note exact error messages, timing patterns, and whether the symptom appears under specific loads.
• Review telemetry. Dive into logs, syslog/SIEM, SNMP traps, or monitoring dashboards to align hard data with the user’s account.

Choose an OSI Strategy

• Top-down (Application → Physical): Effective when a single application is misbehaving. Tools include browser developer tools, nslookup, and tracert.
• Bottom-up (Physical → Application): Best when nothing works. Inspect cabling, link lights, and Layer 1/2 connectivity before moving upward.
• Divide and conquer: Start in the middle—Layer 3. If you can ping the default gateway, Layer 1 and 2 are likely healthy; if not, focus on physical and data-link layers.

Tools That Confirm or Refute Theories

• Connectivity: ping, traceroute, arp -a.
• Name resolution: nslookup, dig.
• Interface health: netstat, ethtool, nmcli, switchport counters.
• Packet analysis: Wireshark or tcpdump for verifying handshakes, DNS responses, or resets.
• External validation: Outage trackers, ISP health dashboards, and vendor status pages.

Common Symptom Paths

| Symptom | Likely Cause | | --- | --- | | 169.254.x.x address | DHCP failure or misconfigured scope | | Can reach gateway but not Internet | Upstream routing, ACL, or ISP outage | | Hostnames fail, IPs succeed | DNS issue | | Heavy CRC/FCS errors on one port | Faulty cable, EMI, or speed/duplex mismatch | | Only one VLAN fails | Incorrect VLAN tagging, DHCP helper, or ACL |

---

Memory Trick

OOPS: Obvious checks → OSI strategy → Probable cause list → Single-change testing.

Rapid Review

1. A workstation receives 169.254.x.x. What is your leading theory?
2. You can ping the gateway but not 8.8.8.8. Which layers do you inspect next?
3. Pings succeed, DNS queries fail. What’s the likely culprit?
4. A switch port shows thousands of CRC errors. What should you try first?
5. Only VLAN 20 hosts miss DHCP leases. Where do you focus?

Answers: 1) DHCP issue. 2) Routing/NAT/ISP. 3) DNS. 4) Replace cable or correct duplex. 5) VLAN tagging or DHCP relay for VLAN 20.