troubleshooting

Overview

ARP, ICMP, and ping are the building blocks of everyday network troubleshooting. This lesson combines them with the layered method from the OSI module into a practical routine for diagnosing connectivity problems.

Learning objectives

• Combine common tools into a troubleshooting routine.
• Interpret results to localize a fault.
• Know which tool answers which question.

Core concept

Effective troubleshooting means asking targeted questions and using the right tool for each:

• Is the host reachable at all? → ping (IP).
• Where does the path break? → traceroute/tracert (uses ICMP TTL).
• Is name resolution working? → DNS lookup tools (e.g. nslookup, dig).
• What are my own settings (IP, gateway)? → ipconfig/ip addr.
• What local IP↔MAC mappings do I have? → arp -a.

Testing by IP first, then by name cleanly separates network-path problems from DNS problems.

How it works

A logical sequence, layer-aware:

1. Check your own configuration (IP, subnet mask, gateway) — is it valid?
2. ping your gateway — is the local network working?
3. ping a known external IP (e.g. a public address) — is routing to the internet working?
4. ping/resolve an external name — if IP works but name fails, it is a DNS problem.
5. Use traceroute to see where along the path failures begin.

Each step confirms a layer and narrows the fault, exactly as the OSI troubleshooting lesson described.

Practical example

A user cannot load websites. You check: their IP and gateway look valid; ping to the gateway succeeds (local network fine); ping to a public IP succeeds (routing fine); but resolving a site name fails. Conclusion: the network path works and the problem is DNS. You fix the DNS configuration rather than chasing cables — the tools localized the fault to name resolution.

Cybersecurity relevance

The same tools and logic support security analysis: confirming reachability of a target, mapping a network's live hosts and paths, and distinguishing a blocked port from an unreachable host. Interpreting these results correctly is a foundational skill for both defenders and testers.

Common mistakes

• Skipping the "ping by IP vs by name" distinction, missing that the issue is DNS.
• Not checking your own configuration first (a bad IP/gateway breaks everything).
• Random changes instead of a stepwise, layer-by-layer routine.

Key takeaways

• Match the tool to the question: ping (reachability), traceroute (path), DNS tools (name resolution), ipconfig/ip addr (own settings), arp (local mappings).
• Test by IP first, then by name, to separate network-path from DNS problems.
• Work stepwise from your own config → gateway → external IP → external name to localize faults.

Check your understanding

• If ping to an external IP works but ping to a website name fails, what is the likely problem?
• Which tool would you use to find where along the route to a server packets stop getting through?