Learn Understand first, then practice while the concept is still fresh.

M32 - Network Diagnostics

Troubleshoot network problems layer by layer using connectivity tests, route tracing, DNS checks, and port inspection.

Networking

Network Diagnostics

Troubleshoot network problems layer by layer using connectivity tests, route tracing, DNS checks, and port inspection.

45 min INTERMEDIATE BOTH Curriculum-reviewed
Prerequisites
Module M28 - Network Model: How Networks Work Module M30 - Network Config: CLI Module M31 - DNS Deep Dive
What you should be able to do after this
  • Use a layered troubleshooting sequence instead of random command jumping.
  • Separate basic reachability, route problems, DNS problems, and port problems.
  • Explain what each tool is proving and what it is not proving.

Why This Matters

Good network diagnosis is mostly about order.

If you jump between random tools, you waste time. If you move layer by layer, the failure usually reveals itself much faster.

1. Start With Reachability

Use a simple connectivity test first.

Basic Reachability on Windows

ping 127.0.0.1 ping 8.8.8.8

Basic Reachability on Linux

ping -c 2 127.0.0.1 ping -c 2 8.8.8.8

This helps separate local stack issues from broader reachability issues.

2. Then Ask About the Path

If reachability is inconsistent or missing, route-tracing tools can show where the path seems to break.

Trace the Path on Windows

tracert google.com

Trace the Path on Linux

traceroute google.com

These tools are about path visibility, not application success.

3. Separate DNS From Raw Connectivity

If raw IP reachability works but hostnames fail, DNS becomes the focus.

That is why ping 8.8.8.8 and ping google.com are not identical tests.

One asks about raw connectivity. The other also depends on name resolution first.

Important Distinction

A failed hostname test can point to DNS even when the route and the remote network path are fine.

4. Check Whether the Service Is Actually Listening

Even when the network path is fine, the target application may not be listening on the expected port.

Inspect Listening State on Windows

netstat -ano

Inspect Listening State on Linux

sudo ss -tulpn

That step answers a different question: is the program waiting for network traffic at all?

A Better Troubleshooting Order

  1. confirm local network state
  2. test reachability
  3. inspect the route when needed
  4. check DNS separately
  5. inspect whether the service is listening

That order prevents a lot of confusion.

What to Ignore for Now

  • packet capture tools
  • deep BGP or routing-protocol analysis
  • advanced firewall-state debugging

The goal here is clean first-pass diagnosis.

Before You Move On

You are ready for the firewall lesson when you can:

  1. explain a layered diagnostic sequence
  2. separate route problems from DNS problems
  3. explain why a listening-port check is its own step

Next, we look at how firewalls fit into this troubleshooting picture.