Network Diagnostics

Networking path · Step 13Available

Turn a vague report into a reproducible troubleshooting path from local link and addressing through DNS, transport, and application response.

Difficulty: Intermediate
Time: 60 min
Practice: Layered diagnosis
Assessment: Knowledge check

Before you start

Who is this for?

For learners and aspiring administrators who want to narrow down errors reproducibly instead of guessing.

Prerequisites

IPv4 and default gateway
Basic DNS, port, and router concepts

What you'll be able to do

Structure diagnosis from local to remote
Interpret ping and traceroute correctly
Test DNS, ports, and throughput separately
Document evidence and the next test

Practical outcome

You can derive a documented fault area and next test from a report such as ‘the Internet is not working’.

Good diagnosis starts with a question: What works, what fails, since when, for whom, and what changed? Then test one layer at a time from the local system toward the remote service.

1. Capture local state

Windows:

Get-NetAdapter
Get-NetIPConfiguration
Get-NetRoute
Get-DnsClientServerAddress

Linux:

ip link
ip address
ip route
resolvectl status

Check link state, address, prefix, gateway, and DNS separately. An address in 169.254.0.0/16 often means the client did not receive a DHCP lease; do not jump to DNS or Internet testing yet.

2. Test reachability in order

Ping loopback, the local interface, the gateway, a permitted IP destination, and finally the same destination by name. Use a small, repeatable count. ICMP filtering can produce no reply even when a host is available, so a failed ping is evidence about that test—not proof of a complete outage.

3. Understand the route

Windows:

Get-NetRoute -AddressFamily IPv4
tracert example.test

Linux:

ip route get 203.0.113.10
traceroute -n 203.0.113.10

Traceroute varies TTL or hop limit and observes responses from routers. Asterisks can mean filtering or rate limiting. A slow intermediate hop matters most when the delay continues at later hops; return paths can differ from forward paths.

4. Test DNS independently

dig example.test A
dig @1.1.1.1 example.test A

Compare the configured resolver with an explicitly chosen test resolver only when the test is authorised and appropriate. Record the response code, answer, TTL, and resolver. If a connection by IP works but the name fails, investigate DNS and local name configuration.

5. Test the service, not only the host

Test-NetConnection example.test -Port 443

curl --verbose https://example.test/
ss -lntup

Separate four questions: Is the host reachable? Is the port reachable? Is the expected process listening? Does the application response succeed? A TCP handshake says nothing about authentication or application logic.

6. Observe packets carefully

tcpdump and Wireshark can show ARP/Neighbor Discovery, DNS, TCP handshakes, retransmissions, TLS, and application traffic. Capture the smallest useful interface, time range, and filter. Packet captures may contain credentials or personal data; protect and delete them according to your lab policy.

7. Measure throughput deliberately

Use iperf3 only between systems you own or are authorised to test:

# authorised test server
iperf3 --server
# authorised client
iperf3 --client 192.0.2.10 --parallel 2 --time 10

TCP measures useful throughput under the selected conditions. UDP can reveal jitter and loss but needs an intentional rate and interpretation. Test both directions when wireless, QoS, or routing may be asymmetric.

Diagnosis matrix

Observation	Likely area	Next test
No link or no address	Local link, VLAN, DHCP	Adapter, switch/AP, lease path
Gateway unreachable	Addressing or local network	Prefix, neighbor cache, VLAN
IP works, name fails	DNS	Resolver, record, cache
Host works, port fails	Service or firewall	Listener, policy, route
Port works, application fails	TLS, authentication, app	Verbose client output and logs
Intermittent loss	Link, path, or load	Longer measurement and counters

Common mistakes

Changing several settings before recording the original state.
Treating a failed ping as proof that a host is offline.
Testing DNS before the client has a valid route.
Interpreting a traceroute star as a broken router without checking later hops.
Capturing too broadly or too long.

What you should be able to do now

You should be able to move from local link to service response, interpret each test within its limits, and document a diagnosis with starting state, command, result, and next action.

Related: IPv6 Fundamentals adds the IPv6-specific address, route, and Neighbor Discovery checks.