Lesson 3: Read IP, Route, DNS, and Connectivity Evidence

A terminal makes troubleshooting look authoritative.

Black background. Technical output. Numbers everywhere.

That does not mean the interpretation is correct.

Commands are useful because each one gives you a narrow view of system state. Your job is to connect that view to the network architecture without claiming more than it proves.

All output in this lesson is supplied or simulated. Do not probe the school network.

Interface configuration tells you what the endpoint believes

Windows-style example:

IPv4 Address . . . . . . : 192.168.40.25
Subnet Mask  . . . . . . : 255.255.255.0
Default Gateway . . . .  : 192.168.40.1
DNS Server . . . . . . . : 192.168.40.10

This supports the claim that the operating system currently represents those values on the interface.

It does not prove the gateway is reachable, DNS is reachable, the address is unique, the switch path is healthy, or the internet works.

Configuration is state, not end-to-end proof.

System process animation

Packet to service: prove each boundary

Use a layered test path from link through the application response.

RestartPreviousPlay sequenceNext

1. 1LinkConfirm the interface before higher-layer tests.
2. 2Local configVerify address, prefix, gateway, and DNS.
3. 3Local subnetProve local delivery independently of routing.
4. 4GatewayTest the routed boundary.
5. 5Remote IPSeparate reachability from DNS.
6. 6DNSResolve the hostname independently.
7. 7ServiceTest port and application response.

Technician question: Which test proves reachability but not application health?

Compare expected and observed state

Expected:

network: 192.168.40.0/24
gateway: 192.168.40.1
DHCP: enabled

Observed:

IPv4: 169.254.33.18/16
gateway: none

Strong claim:

The client does not have the expected DHCP-provided IPv4 configuration and is using a link-local/APIPA address.

Weak claim:

The DHCP server is definitely dead.

The failure could instead be client DHCP state, VLAN placement, AP uplink, relay or path behavior, or scope/service state.

The output narrows the problem. It does not name the guilty component automatically.

ping tests reachability to one target under one test

ping 192.168.40.1
Reply from 192.168.40.1: time=1ms

Supported claim:

The endpoint received a reply from the configured gateway under this test.

Unsupported leap:

The internet is working.

The gateway responding does not prove the remote path, DNS, transport, or application.

Now compare:

Request timed out.

The expected reply was not observed.

Why remains open.

Possible explanations include path failure, target down, filtering, wrong address, local configuration problems, or ignored responses.

Timeout is evidence. It is not root cause.

Use a ladder of targets

Instead of one random ping, test increasing scope when the scenario supports it:

local interface / loopback concept
        ↓
same-subnet known-good target
        ↓
default gateway
        ↓
remote documentation IP

Suppose the same-subnet printer, gateway, and remote documentation IP all reply.

You have proven more of the path than one isolated gateway test.

Still not proven: DNS, HTTPS, authentication, or application health.

Climb only as high as the evidence allows.

tracert and traceroute show responding points along a routed path

Supplied example:

1  192.168.40.1       1 ms
2  198.51.100.1      11 ms
3  * * *
4  203.0.113.20      27 ms

Is hop 3 definitely dead?

No.

A router may forward traffic while not responding to the particular traceroute probe. Filtering, rate limiting, or implementation behavior can create * entries.

The final responding destination proves the path continued beyond hop 3.

Read the sequence, not one dramatic symbol.

Latency is different from reachability

Compare:

Gateway reply: 1 ms
Remote hop:    18 ms
Service host:  220 ms

The path returns replies, but the response time has changed.

High latency is a degradation problem, not the same thing as total connectivity loss.

That distinction matters for real-time traffic.

nslookup asks DNS a question

nslookup portal.training.test
Server: 192.168.40.10
Address: 192.168.40.10

Name: portal.training.test
Address: 192.0.2.40

Supported claim:

The queried DNS path returned the represented answer mapping the name to 192.0.2.40.

Not proven:

• the web service works;
• the answer is correct for the intended application;
• TCP/443 is reachable;
• the user is authorized.

DNS success is DNS evidence.

Compare direct IP and name-based behavior

Case:

ping 192.0.2.40: replies
nslookup portal.training.test: fails

That comparison supports the idea that the IP path works while the required name-resolution path does not.

Now DNS becomes a justified focus.

Route tables explain intended next hops

A route table may contain:

destination      gateway          interface
192.168.40.0/24  on-link          192.168.40.25
default          192.168.40.1     192.168.40.25

This tells you how the endpoint intends to reach local and default destinations.

A wrong route can break one class of destination while leaving another healthy.

Ask:

For this destination, which route should win and where should the packet go next?

Logs show state transitions a snapshot can miss

Supplied switch evidence:

14:01:02 port 8 link up
14:01:19 port 8 link down
14:01:24 port 8 link up
14:01:41 port 8 link down

That pattern is port flapping.

A single snapshot might show the port up and miss the instability.

The log adds time to the evidence.

Possible boundaries include cable or connector, NIC, switch port, physical movement, and power instability.

DNS is not a strong first suspect for a link repeatedly changing state.

Worked evidence chain

Start with:

user report: "portal will not load"

Then inspect:

IP config: valid
same-subnet target: reachable
gateway: reachable
remote portal IP: reachable
DNS lookup: correct
TCP endpoint 443: responds
application: returns authentication error

Where is the failure now?

Not the cable. Not DHCP. Not DNS. Not basic remote reachability.

The evidence has climbed into the application or authentication layer.

That is what layered troubleshooting is supposed to do.

Annotate command evidence

For each supplied command or output, record:

question being asked
raw observation
what the result supports
what the result does not prove
next useful test

Use at least ipconfig or ip, ping, traceroute or tracert, nslookup, route or interface output, and one supplied log.

Before you move on

A screenshot of terminal output is not troubleshooting documentation by itself.

The important part is the sentence underneath it:

This output supports ______ because ______, but it does not yet prove ______.

Next we apply that discipline to the full A+ network symptom set, including cases where connectivity exists but performance or stability is degraded.