Lesson 1: Troubleshoot in Layers

A user says:

"The internet doesn't work."

You now know enough networking to hear that sentence for what it is.

A starting point.

Not a diagnosis.

The failure could be no physical link, failed Wi-Fi association, missing DHCP configuration, wrong subnet or gateway, local switching failure, upstream route failure, DNS failure, transport or service failure, authentication failure, application failure, or degraded performance rather than complete loss.

The fastest way to make this harder is to change several network settings before proving which boundary failed.

Build the ladder from the bottom up

A practical endpoint troubleshooting ladder looks like this:

1. interface / physical or radio link
2. local IP configuration
3. same-subnet destination
4. default gateway
5. remote IP path
6. DNS when a name is required
7. transport endpoint
8. application / authentication

This is not a ritual that must always be followed in exactly this order.

If the user reports a specific DNS error and you already have evidence that IP connectivity works, you do not need to pretend you know nothing and start replacing cables.

The point is to preserve what has already been proven.

Diagrams open at a readable shape-aware scale. Zoom or expand when you need more detail.

The last proven-good boundary saves time

Suppose you know:

Wi-Fi associated
IPv4 address valid
same-subnet printer reachable
gateway reachable
remote IP reachable
hostname lookup fails

Where is the last proven-good boundary?

Remote IP reachability.

What is the first failed responsibility?

Name resolution.

That makes a failed Wi-Fi radio, dead NIC, complete switch failure, missing gateway, and total provider outage much weaker theories.

Good troubleshooting is partly knowing what not to touch.

Translate the user report into testable observations

"No internet"

Ask:

• Is the interface linked or associated?
• Does the endpoint have expected IP configuration?
• Can it reach a same-subnet destination?
• Can it reach the gateway?
• Can it reach a remote IP?
• Does DNS resolve the required name?
• Does the actual service respond?

"Wi-Fi keeps dropping"

Ask:

• Does association drop or only the application?
• Does IP configuration disappear?
• Does the AP uplink stay healthy?
• Does signal or interference change?
• Do wired clients have the same problem?
• Does the symptom affect one client or many?

"The network is slow"

Ask:

• Slow from this device only or everywhere?
• Wired and wireless?
• Local transfers or remote services?
• Constant or load-dependent?
• High latency, jitter, packet loss, congestion, or endpoint resource pressure?

"Slow" is a category. Evidence gives it shape.

Baseline before change

Before changing configuration, capture the current state when practical.

Useful baseline evidence may include:

• interface and link state;
• current IP configuration;
• gateway;
• DNS server;
• route table;
• Wi-Fi band, channel, and signal in supplied evidence;
• expected service endpoint;
• what works from another known-good client.

If the change makes things worse, the baseline tells you what changed. If the change appears to fix the problem, it gives you a before-and-after comparison.

One test should challenge one theory

Suppose the client has:

Ethernet link: up
IPv4: 169.254.42.18/16
gateway: none
expected network: DHCP on 192.168.40.0/24

A useful theory:

The endpoint did not obtain expected DHCP configuration.

A useful next test:

Compare DHCP behavior with a known-good client on the same expected network, or inspect the supplied client and DHCP state.

A poor first action:

Replace the router.

The evidence has not shown a router hardware failure. The endpoint does not even have expected local configuration yet.

Stay close to the first failed boundary.

Do not confuse a test with a fix

ping is a test.

nslookup is a test.

A cable tester is a test instrument.

Changing DNS servers, replacing a cable, resetting an adapter, changing a VLAN, or rebooting a router are changes.

Those changes may eventually be justified, but they should follow evidence.

A troubleshooting process that changes the system before measuring it destroys part of the evidence trail.

Worked case: local works, gateway fails

Evidence:

interface: linked
IP: 192.168.40.25/24
same-subnet printer: reachable
same-subnet workstation: reachable
default gateway 192.168.40.1: unreachable

This supports working local interface, local switching, and plausible endpoint addressing for same-subnet traffic.

The investigation moves toward the gateway path, router LAN interface, gateway address, local path to the router, or policy.

Do not replace the NIC while it is successfully communicating with local devices.

Worked case: host reachable, service refused

Evidence:

DNS: resolves
server IP: reachable
TCP connection to expected service endpoint: refused/reset

Basic IP reachability exists.

The failure moves toward listener or service state, configured port, service policy, or application startup.

The network path did not disappear because one service failed.

Build five troubleshooting ladders

For each symptom, identify:

• what you already know;
• last proven-good boundary;
• first failed or unproven boundary;
• smallest useful next test;
• one premature fix to avoid.

Use:

1. no Ethernet link;
2. APIPA address;
3. local printer works but gateway fails;
4. remote IP works but hostname fails;
5. host reachable but expected TCP service is refused.

The sentence you should be able to say

By the end of this lesson, you should be able to state:

Here is the last boundary I proved good. Here is the next boundary I have not proved. This test is intended to distinguish between these two explanations.

That is troubleshooting.

Ten random commands are just activity.

Next we look at the actual network tool set and connect each tool to the question it is capable of answering.