Network troubleshooting: layer by layer
You narrow down “it won’t connect” systematically from the physical layer to the application, collecting evidence and finding the root cause each time.
Level 201 · 21 lessons · 18 practice labs
Lessons
Method
- The troubleshooting method: symptom, hypothesis, test
- Bottom-up, top-down, divide and conquer
- Gathering evidence: command output and a timeline
- Short task: write a complete fault ticket
The lower layers
- No link: cable, interface, speed and duplex mismatch
- Wrong IP or mask
- ARP problems and duplicate IPs
- A missing route and the return path
- MTU black hole: small pages load, large ones do not
- Short task: fix a machine that cannot connect
The upper layers
- DNS failures: NXDOMAIN, SERVFAIL, the wrong resolver
- Firewall or service: reject versus drop
- The service is not listening, or listens on the wrong address
- TLS and certificate errors
- Slow but working: latency and loss
- Short task: restore staff access to a web application
Tools
- Capturing packets while troubleshooting: tcpdump at the right point
- Path analysis with mtr and misleading results
- Verifying port reachability with nc and nmap
- Short task: prove that the fault is on the provider’s side
Wrap-up
- Capstone: solve five separate fault reports on a Monday morning
Practice labs
- The printer is visible, the server is not: Diagnose the client with the wrong netmask from ip addr and ip route output, fix it and show it reaching the server on its subnet and the outside network.
- The connection keeps coming and going: Detect the duplicate IP from the changing MAC in the ARP table, find the second device, fix it and prove with arping that only one reply remains.
- Cable in, light on, link crawling: Find the cause of the slow link in the Blue Harbour Cargo warehouse using interface counters, ethtool output and throughput tests, fix the speed/duplex mismatch and report before and after measurements.
- There is no route to the branch: Find the missing branch route on the head-office router with traceroute, add it and show two-way reachability to the branch server.
- Pings go out, no replies come back: Prove with tcpdump at two points that the packet reaches the target but has no return path, fix the return route and show the result.
- mtr shows loss, but the fault is not there: Prove that the loss shown at an intermediate router comes from ICMP rate limiting and that the real fault is an asymmetric return path, fix it and write a short note explaining the misleading output.
- Small pages load, large ones hang: Find the largest path MTU with ping -M do, fix the faulty interface or add MSS clamping and show the large page loading.
- The application is slow in the mornings: Measure with mtr and ping series at which hop latency and loss begin, identify the bottleneck and present the findings in a timestamped table.
- File transfers over the VPN stall halfway: Prove from a packet capture that path MTU discovery breaks because ICMP is blocked, add the needed ICMP permit and MSS setting to the firewall and show the large transfer completing.
- There is internet, but no names resolve: Show with dig and resolvectl that the client uses the wrong resolver, fix the setting and prove names resolve.
- One subdomain returns SERVFAIL: Find the broken delegation with dig +trace, fix the missing or wrong NS and glue records and show the subdomain resolving.
- One address inside, another outside: Find why some Pinecrest Bank staff reach the internal portal through its external address (search order, cache, VPN DNS), fix it and show the right answer from three client types.
- The service is running but nobody can connect: Use ss to see that the service listens only on localhost, fix the listening address and show a connection from another machine with nc.
- Is the connection refused or dropped?: For each of three closed ports, tell with nc, nmap and tcpdump whether the answer comes from the service or the firewall, and open only the one that is needed.
- Some browsers cannot open the application: Use openssl to separately detect the missing intermediate, the name mismatch and the expired certificate on Silverwater Municipality’s web app, fix them and show a clean verification with curl.
- A proper fault ticket from a messy complaint: Write a complete fault ticket with symptom, impact, timeline and first tests from the given user messages, then run the first two tests in the lab and add their results.
- Prove the fault is at the provider: Take simultaneous captures on the inside and outside of the edge router plus mtr measurements, and prepare a timestamped, evidence-backed notice showing the fault is at the provider.
- Five complaints on a Monday morning: Rank five fault tickets opened at once on the Caravan Travel network by impact, find and fix each root cause, then write a one-paragraph closing note for every ticket.
About this course
You narrow down “it won’t connect” systematically from the physical layer to the application, collecting evidence and finding the root cause each time.
What you will learn
- Method
- The lower layers
- The upper layers
- Tools
- Wrap-up
Prerequisites
Finishing the level 101 courses of the same path, or knowing those topics, is enough.
Lab environment
Lessons run in your own Kali Linux terminal in the browser, connected to a private lab network. Nothing to install.
Frequently asked questions
- Is this course right for my level?
- The course is at level 201; it assumes you know the topics of the lower-level courses.
- Is there anything to install?
- No. Every lesson runs in your own lab environment that opens in the browser.
- How do lessons work?
- Each lesson has 8 to 10 steps and a short quiz. Early steps show the command to type, later steps give less help; if two attempts fail, the solution opens.
- Can I try it for free?
- Yes. The first three lessons of every course are free.