Networking › Module 5 › Lesson 2
Network Troubleshooting Steps
A layered checklist from physical link to application
Opening
Order is a tool — guessing is not
A ticket that says "the internet is down" is a symptom, not a layer. Random clicks — reboot the router, disable the firewall, change DNS to a meme IP — waste time and sometimes punch holes you did not mean to punch. Structured troubleshooting walks the stack the way packets do: is the link up? Is there an IP? Is there a gateway? Does a name resolve? Does the application (and TLS) complete? Carry Topic 2: ping fail ≠ host down. ICMP is one protocol. This checklist is for YOUR connection — VM, WSL, or a machine you administer — not a sweep of the café LAN.
1. Why the order matches the path
If the cable is unplugged or the Wi-Fi association is gone, no IP trick will help. If the NIC is UP but has no address, the gateway ping is meaningless. If you have an address but no default route, public HTTPS cannot start. If routing works by IP but names fail, you will blame "the site" when DNS is the fault. If DNS works but TCP/443 times out or the certificate is wrong, the application/TLS layer is where you stop. OSI-aligned, bottom-up: 1) Link (L1/L2): ip link — state UP or DOWN, carrier, the iface you think you are using. 2) Address (L3 host): ip addr — inet CIDR on a non-lo iface, not only 127.0.0.1. 3) Route (L3 path): ip route — default via <gateway> dev <iface>. 4) Local stack: ping 127.0.0.1 — if this fails, stop accusing the ISP. 5) First hop: ping the gateway from ip route (YOUR gateway). 6) Name: getent hosts example.com or nslookup — does this host get an A/AAAA? 7) App/TLS: curl -I https://… — headers and status, not a port scan of strangers. Skip a rung and you mis-diagnose. Ping 8.8.8.8 before checking link-up is how people "prove the internet is dead" while their Wi-Fi is simply off. curl a site before checking DNS is how people file a "server down" ticket that is actually a broken resolver.
2. Ping is ICMP — then DNS — then the app
ping 127.0.0.1 proves this kernel can send and receive ICMP to itself. ping <your-gateway> proves L2/L3 to the first hop on a network you own. No reply from the gateway: cable, AP, wrong VLAN, local firewall dropping ICMP, or a down router — not yet "the whole internet." A public IP ping (only if you choose a destination you are allowed to test, such as a well-known anycast you already use) can still fail while HTTPS works: many networks drop ICMP. Topic 2 again: silence is not a tombstone. getent hosts name asks the system resolver (NSS → DNS, files, etc.). nslookup/dig talk to a DNS server more directly. If ping to an IP works (or curl by IP works) but the name fails, you isolated DNS. If the name resolves but curl -I hangs, you isolated TCP/TLS/app or a filter on 443 — not "DNS is broken." curl -I fetches response headers (HTTP status, server headers) without downloading a body. Connection refused vs timeout vs TLS error vs HTTP 503 are different stories. You will reuse this exact command set in the next lab on your own connection.
3. Wrong vs right: skip the stack and reboot everything
Worked failure mode — treating "down" as one blob. Stay on your VM/WSL/home link. Do not nmap the office floor to "find who is broken."
Wrong
You ping a public IP first, get no reply, declare the internet dead, and disable the host firewall. You never ran ip link, never noticed Wi-Fi was DOWN, never pinged 127.0.0.1. Or you nslookup a neighbor's hostname and port-scan their printer "as a connectivity test." That is not troubleshooting; that is unauthorized probing.
Right
Link → address → route → loopback ping → gateway ping → name lookup → curl -I. Write pass/fail at each rung. Interpret ping as ICMP only. If DNS fails, do not rebuild TLS. If loopback fails, do not blame the ISP. Own machine, own gateway, names you already use.
4. Practical: the commands the lab will reuse
Run the full ladder on your own VM or WSL. Replace the example hostname with a site you already visit. Read the gateway IP from ip route — do not guess 192.168.1.1 if your LAN is 10.0.2.0/24. Do not add -b broadcast pings or CIDR sweeps.
Command guide
Layered checks — YOUR VM / WSL / own gateway only
1) Link
Command — copy this
ip link
Expect: lo UP; your NIC (eth0/ens33/wlan0/…) UP, not DOWN
2) Address
Command — copy this
ip addr
Non-lo inet …/CIDR present? If only 127.0.0.1, you are not on a LAN yet.
3) Route
Command — copy this
ip route
default via <GW> dev <IFACE> → that <GW> is YOUR gateway
4) Local stack (always in scope)
Command — copy this
ping -c 4 127.0.0.1
5) First hop — YOUR gateway from ip route, not a guessed .1
Optional command
ping -c 3 <GW>
6) DNS (a name you already use — not a sweep)
Command — copy this
getent hosts example.com command -v nslookup >/dev/null && nslookup example.com || true
7) App / TLS headers (HTTPS you are allowed to use)
Command — copy this
curl -I --connect-timeout 10 https://example.com
NEVER: ping/nmap a /24, café LAN, or school lab you do not own NEVER: disable the firewall because one ping failed
Optional command
ping fail ≠ down. Order matters.
Mission: walk the ladder once on your own link
On your VM or WSL, run ip link, ip addr, ip route, ping -c 4 127.0.0.1, ping -c 3 of YOUR gateway, then getent hosts or nslookup for a hostname you already use, then curl -I to that site. Write one pass/fail line per step. If a later step fails, do not skip recording which earlier step still worked. No LAN scans. Do not disable firewalls.
Stuck? Ask Cyberlium AI Mentor
If gateway ping fails but loopback works, ask Cyberlium AI Mentor for a hint — not a scan of nearby hosts. Try: "Hint only: ping 127.0.0.1 works, ip route has a default via, ping to that via times out — what layers should I still consider besides 'internet down'?"
You have an OSI-aligned order: link, IP, gateway, DNS, application/TLS — and you will not treat ICMP silence as a death certificate. Next — Lab — Diagnose a Broken Connection — you run this ladder on your own path, isolate which rung fails, and write the evidence to a notes file.
Knowledge Check
APPLY: ping 8.8.8.8 works from a laptop, but getent hosts and curl -I to a normal HTTPS site fail with "Could not resolve host." Which rung is broken, and what should you not do?
Multiple choice
Knowledge Check
APPLY: ping 127.0.0.1 fails on a Linux VM, and the user has not yet run ip link. Best next statement?
Multiple choice
Knowledge Check
APPLY: True or False: The ethical default for this checklist is your own iface, your own gateway, names you already use, and curl -I — not nmap of the LAN to "see who else is down."
True or False