Network troubleshooting: a proven method, the essential commands and 12 real fault scenarios

"The internet is not working" is the most common sentence an IT person hears. Good troubleshooters don't guess or randomly restart things: they follow a method, gather facts with a few key commands, narrow down the layer where the fault lives, fix it, and document it. This skill is what employers test in interviews and what makes you valuable at a helpdesk, an ISP NOC or as a freelance technician.

The 7-step method

1. Identify the problem: gather information, question users, find symptoms, ask what changed, reproduce it.
2. Establish a theory of probable cause: start with the obvious; consider multiple causes.
3. Test the theory: if confirmed, plan the fix; if not, form a new theory or escalate.
4. Plan the fix, considering impact (don't reboot the core switch at 10 a.m. on payday).
5. Implement the solution or escalate.
6. Verify full functionality, and add preventive measures.
7. Document findings, actions and outcome.

Questions to ask first

• Who is affected? One user, one department, everyone?
• What exactly fails? All websites, one system, email only, printing?
• When did it start? Is it constant or intermittent?
• What changed? New device, software update, cable moved, power outage, new router, ISP work?
• Where? Wired or Wi-Fi? Which floor/branch?

"Everyone on the second floor since this morning" points to a switch or VLAN; "only my laptop" points to the device.

Approaches

The essential commands

ipconfig / ip: what are my settings?

ipconfig /all            # Windows: IP, mask, gateway, DNS, DHCP server, MAC, lease
ip a ; ip r              # Linux: addresses and routes

Look for: a valid IP in the right subnet, a gateway, DNS servers. 169.254.x.x = DHCP failed. Media disconnected = layer 1.

ping: can I reach it?

ping 127.0.0.1           # my own TCP/IP stack works
ping 192.168.1.1         # my gateway (LAN works)
ping 8.8.8.8             # the internet by IP (routing/ISP works)
ping google.com          # name resolution works
ping -t 192.168.1.1      # Windows: continuous (Ctrl+C to stop); Linux pings continuously by default

Results: Reply (good; check the time in ms), Request timed out (no reply: down, blocked by firewall, or no route back), Destination host unreachable (a router or your PC has no path), Could not find host (DNS).

Note: many servers and firewalls block ping, so "no reply" doesn't always mean "down".

tracert / traceroute: where does it stop?

tracert google.com        # Windows
traceroute google.com     # Linux/macOS
pathping google.com       # Windows: path + loss per hop
mtr google.com            # Linux: live traceroute with loss statistics

Each line is a router (hop). Asterisks * * * at one hop may just be a router that doesn't reply; asterisks from some hop onward to the end show where traffic stops. Sudden big jumps in time show slow links (e.g. an international hop).

nslookup / dig: does DNS work?

nslookup google.com
nslookup google.com 1.1.1.1     # compare with another resolver
dig google.com +short

arp, netstat/ss, and others

arp -a                       # IP-to-MAC table: is the gateway's MAC present?
netstat -ano                 # Windows connections and PIDs
ss -tulpn                    # Linux listening ports
Test-NetConnection server -Port 443    # Windows: is a TCP port reachable?
nc -zv server 443            # Linux/macOS port test
ipconfig /release ; ipconfig /renew    # get a new DHCP lease
ipconfig /flushdns           # clear DNS cache
netsh winsock reset          # Windows: reset network stack (then reboot)

A quick diagnostic sequence

1. ipconfig /all       → valid IP? gateway? DNS?
2. ping gateway        → LAN OK?
3. ping 8.8.8.8        → internet routing OK?
4. nslookup google.com → DNS OK?
5. tracert 8.8.8.8     → where does it stop?

# Interpret the quick diagnostic results like a technician
def diagnose(has_ip, ip_is_apipa, gw_ping, internet_ping, dns_ok):
    if not has_ip: return "Layer 1/2: cable, Wi-Fi or adapter problem"
    if ip_is_apipa: return "DHCP failed: check cable/VLAN/DHCP server"
    if not gw_ping: return "Can't reach gateway: local network, wrong subnet or switch/VLAN issue"
    if not internet_ping: return "Gateway OK but no internet: router WAN, NAT, default route or ISP"
    if not dns_ok: return "Internet by IP works: DNS problem"
    return "Network OK: check the application, browser, proxy or the remote server"

print(diagnose(True, True, False, False, False))
print(diagnose(True, False, True, False, False))
print(diagnose(True, False, True, True, False))
print(diagnose(True, False, True, True, True))

12 real scenarios

Documentation and escalation

Record every incident: date, users affected, symptoms, tests run (with results), root cause, fix, time to resolve. A ticketing system or even a shared spreadsheet works. Good documentation:

• Speeds up the next similar fault
• Reveals patterns (the same switch failing monthly)
• Protects you (proof of what was done)

Escalate when the fault is outside your access or skill (ISP line, core equipment, security incident), with your test results attached: "Branch line down since 9:05; router WAN shows no carrier; power and cables checked; ISP ticket needed".

Summary

• Follow a method: identify, theorise, test, plan, implement, verify, document.
• Ask who/what/when/what changed/where before touching anything.
• Use bottom-up, top-down or divide-and-conquer (start with ping).
• Core commands: ipconfig/ip, ping, tracert/traceroute, nslookup/dig, arp, netstat/ss, Test-NetConnection.
• Recognise common faults: APIPA, missing gateway, DNS failure, rogue DHCP, IP conflicts, loops, saturation; document and escalate with evidence.