Week 09 · lesson
Lesson 3: Read IP, Route, DNS, and Connectivity Evidence
Core path: 42 minutes
Today the commands are not magic spells. Each one answers a narrower question.
All output in this lesson is supplied or simulated. Do not probe the school network.
Interface configuration
Example Windows-style evidence:
IPv4 Address . . . : 192.168.40.25
Subnet Mask . . . : 255.255.255.0
Default Gateway . : 192.168.40.1
Question answered: did the endpoint receive/plausibly have the expected local IPv4 configuration?
Ping
ping 192.168.40.1
A reply supports reachability to that target under that test. A timeout does not identify the root cause by itself.
Traceroute / tracert
Path-hop output can show which routed hops respond along a path. Missing responses can be caused by filtering or device behavior, so do not treat every * as a dead router.
nslookup
nslookup portal.test
Question answered: does the queried DNS path return an answer for the name?
If direct-address communication works while name lookup fails, DNS becomes a stronger boundary.
APIPA comparison
Expected:
192.168.40.25/24
Gateway 192.168.40.1
Observed:
169.254.33.18/16
No gateway
That is strong evidence that expected IPv4 configuration was not obtained. It is not proof the NIC hardware is dead.
Student action
Annotate each simulated command with:
question:
observation:
what it supports:
what it does not prove:
next test:
Use at least ipconfig/ip, ping, traceroute/tracert, and nslookup.
Evidence checkpoint
The output matters only when you connect it to the architecture:
interface → local path → gateway → name/path → service
Screenshots without interpretation are not troubleshooting documentation.
System process animation
Packet to service: prove each boundary
Step through the technician test path from local link and addressing to gateway, name resolution, transport, and the application response.Technician question: Which successful test proves only IP reachability, and which later test finally proves the application service?
Read it. Prove it.