EMZETT.Troubleshooting (Networking)
In short: Systematically narrowing down and identifying the cause of a network problem — usually layer by layer, following the OSI model.
In more detail: A typical approach: first check the physical connection (cable/Wi-Fi, layer 1), then test reachability (ping, layer 3), then port availability (port, layer 4), then the actual application. Tools such as traceroute, nslookup or Wireshark help assign the error to a particular layer instead of guessing aimlessly.
In Depth
A systematic diagnostic sequence, layer by layer:
1. Physical (layer 1): cable plugged in? link LED on? Wi-Fi signal present?
2. Data link (layer 2): arp -a (does the device know its neighbours?)
3. Network (layer 3): ping <target> (is the target reachable at all?)
4. Transport (layer 4): telnet <target> <port> (is the port open?)
5. Application (layer 7): curl -v <url> (does the application answer correctly?)
The trick of this approach: as soon as a step fails, you immediately know at which level the problem lies, instead of testing all sorts of things at random. traceroute/tracert additionally shows every single router hop on the way to the target and makes visible WHERE exactly a connection stalls. nslookup/dig specifically checks whether there’s a DNS problem (does the name resolve correctly at all?) before you look deeper into the connection itself. Finally, Wireshark lets you capture the complete data traffic and inspect every single packet in detail when the simpler tools don’t give a clear answer.
Typical failure patterns and their causes
Experience shows that certain symptoms point to certain layers: no link light on the network adapter or completely missing Wi-Fi networks almost always point to layer 1 (cable/hardware). “Destination host unreachable” in a ping points to a routing problem (layer 3) — either there’s no route to the target, or a router along the way discards the packet. “Connection refused” means that the target device is reachable but no service is listening on the requested port (layer 4) — unlike a timeout, which often points to a firewall silently dropping the request instead of actively rejecting it.
Top-down versus bottom-up
The order shown above (from layer 1 upwards) is called “bottom-up” diagnosis and is well suited when you know nothing about the likely cause. Experienced engineers often work “top-down” or “divide and conquer”: they start with a test in the middle of the stack (e.g. directly with a ping) and, depending on the result, decide whether to search further down (towards hardware) or further up (towards the application) — which saves time if the symptoms already give you a hunch where the problem probably lies.