Your First Lab: Ping, Traceroute, and Reading Output
Enterprise Network Engineer · Module 1: Networking Fundamentals
Lesson 4 of 8
Prerequisites: What Is a Network, Really?, How Computers Talk: Packets, Frames, and Addresses, IP Addresses and Subnets Without Tears
What you'll be able to do: send the two classic test messages, read their output like a technician, and answer "is it down, is it slow, or is it me?"
Stand at one end of a long hallway and shout "are you there?" If someone shouts back, you learn two things: they're awake, and how long the echo took. Shout every second and you learn a third: whether they answer every time.
Now walk the hallway knocking on every door, writing down who answers. When the replies stop, you know how far you got — and the last door that answered tells you where the silence starts.
That is the entire toolkit for the most common question in networking: is it down, is it slow, or is it me? Two tiny test messages, sendable from any computer with no permission needed — and the replies map exactly where things break. Every professional troubleshooter starts here, every time, before touching anything else.
Three neighbors ran these tests this morning. One of them has no network problem at all.
Here's the puzzle.
Scenario. Three neighbors knock on your door on the same Saturday. Ana's video calls keep freezing. Ben's new security camera never came online. Carla's laptop "can't reach the internet" since Thursday. Each of them ran the hallway-shout tests and saved the output. You're the neighborhood tech — diagnose all three before lunch.
Given artifacts. The three saved outputs (hover the path diagram for a reminder of the route each test took).
── Output A (Carla's laptop → video site 203.0.113.45) ──
$ ping -c 4 203.0.113.45
PING 203.0.113.45 (203.0.113.45): 56 data bytes
64 bytes from 203.0.113.45: icmp_seq=0 ttl=52 time=11.8 ms
64 bytes from 203.0.113.45: icmp_seq=1 ttl=52 time=12.4 ms
64 bytes from 203.0.113.45: icmp_seq=2 ttl=52 time=11.2 ms
64 bytes from 203.0.113.45: icmp_seq=3 ttl=52 time=12.0 ms
--- 203.0.113.45 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss── Output B (Ana's laptop → video site 203.0.113.45) ──
$ traceroute 203.0.113.45
1 192.168.1.1 (home box) 1.2 ms 0.9 ms 1.1 ms
2 10.20.0.1 (street cabinet) 8.4 ms 9.1 ms 8.8 ms
3 72.14.200.9 312 ms 298 ms *
4 72.14.200.10 14.2 ms 13.9 ms 14.5 ms
5 203.0.113.45 (video site) 15.1 ms 14.8 ms 15.3 ms── Output C (Ben's laptop → camera cloud 198.51.100.23) ──
$ ping -c 2 198.51.100.23
PING 198.51.100.23 (198.51.100.23): 56 data bytes
--- 198.51.100.23 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss
$ traceroute 198.51.100.23
1 192.168.1.1 (home box) 1.1 ms 0.8 ms 1.0 ms
2 * * *
3 * * *
From 10.20.0.1: Destination unreachableYour task: for each output (A, B, C), give the diagnosis — the far end is down, the path is slow, or the trouble is on your own side — in ≤2 sentences, and quote the single line of output that proves it.
Workspace: analyze-and-answer — three text fields, one per output, in the shape "Output A: ___ because '___'." Nothing is graded.
Hint 1 — where to look
Don't read every line — in each output, find the line where the pattern breaks: the first number that looks nothing like its neighbors. One output has no break at all, and that's a diagnosis too.Hint 2 — what to compare
Compare hop 1 across all three outputs. In which output does even hop 1 — your own home box — look sick? Trouble that never leaves the house is a different diagnosis from trouble past it.Hint 3 — the mechanism
A slow middle hop with fast hops after it means one tired device, not a slow path — the later replies overtook it, which a truly congested road wouldn't allow. And * * * plus "Destination unreachable" means your messages died past your home box: your side is innocent, something beyond it gave up.Commitment ritual: below the workspace sits a checkbox — "I've attempted this challenge and thought it through." Checking it (with or without typing an answer) reveals the worked answer in S7. Nothing is graded; the checkbox is a promise to yourself that you struggled first. (Honor system for now — real progress tracking arrives with accounts.)
Checking the box reveals the worked answer in S7 below. Returning learners stay unlocked.
The hallway shout: echo request and reply
Ping (a tool that sends "are you there?" messages and times the replies) is the simplest diagnostic in existence. It sends an echo request (a short "are you there?" message, sent as ICMP — Internet Control Message Protocol, the network's built-in control language, separate from your apps' traffic) and waits for the echo reply ("I'm here!"). Four requests, four replies, and you know the far end is alive and how long the round trip takes.
The beauty is its honesty: ping doesn't ask the far program anything — it asks the far machine. If ping works but your app doesn't, the network is innocent and the app is guilty. That single distinction solves an enormous fraction of "the internet is broken" complaints.
Why this matters for the challenge: Outputs A and C are ping outputs. The summary line at the bottom ("4 transmitted, 4 received, 0% loss") is the whole verdict in one sentence.
What the reply tells you: loss, latency, and the countdown
Three numbers tell the story. Packet loss (replies that never came back — a little loss on a busy path is normal; 100% is a statement) measures reliability. Latency — the RTT, or round-trip time, in milliseconds — measures speed: how long the echo took. And jitter (how much the times wobble between replies — steady 12 ms is healthier than swinging 10–300 ms) measures steadiness, which is what video calls actually need.
Every reply also carries a TTL (time to live — a countdown stamped on each message; every device on the way subtracts one, and at zero the message is thrown away so lost messages can't loop forever). You'll see it as ttl=52 in ping output. Mostly it's trivia at this level — but the next tool weaponizes it.
Why this matters for the challenge: Output A's verdict lives in its loss (0%) and its times (steady ~12 ms). Output C's verdict lives in its loss (100%).
Knocking on every door: traceroute
Traceroute (a tool that maps the path to a destination, one device at a time) is ping's big sibling, and its trick is gloriously sneaky: it sends messages with tiny TTLs on purpose. TTL=1 dies at the first device, which reports back "I killed your message" — revealing itself as hop 1. TTL=2 survives one device and dies at the second — hop 2. And so on, knocking on every door down the hallway.
Each hop line shows the hop number, the device's name or address, and three round-trip times (three knocks per door, so one fluke doesn't fool you). When a device stays silent you see ** *** (no reply to that knock — the device didn't answer, which is not the same as being dead; many devices ignore knocks while happily forwarding real traffic).
Why this matters for the challenge: Output B is a traceroute. The story isn't in any single line — it's in the shape of the times down the column, which we'll dissect in the worked answer.
Reading like a tech: down, slow, or me
Three verdicts cover nearly everything, and each has a signature:
- Down: 100% loss, or traceroute's knocks dying at some hop with "destination unreachable." The question is always where — hop 1 healthy means it's past your house.
- Slow: replies come back but late or wobbly — high latency, high jitter, partial loss. Video freezes; pages limp along.
- Me: ping and traceroute look clean, yet the app misbehaves. The road is fine; the car is the problem — your device, your wifi radio, the app itself.
One caveat for the road: path asymmetry (the reply may take a different road home than the request took out there). So a slow reply proves some road is slow, not necessarily the one you knocked on. Techs remember this when the map and the symptoms disagree.
Why this matters for the challenge: A, B, and C are one of each — down, slow, and me, in some order. The signatures above are your sorting hat.
- Step 1 of 5: The laptop shouts "are you there?" (blue dot) — an echo request leaves for the server.
- Step 2 of 5: The timer starts. The request crosses the wire; every device subtracts one from its TTL countdown.
- Step 3 of 5: The server shouts back "I'm here!" (green dot) — the echo reply. Timer stops: 12 ms. That's one ping.
- Step 4 of 5: Traceroute's trick: send with TTL=1, so the message dies at the very first device — which reports back, revealing hop 1.
- Step 5 of 5: Raise the TTL to 2, then 3, knocking on each door in turn — the replies draw the map of the whole path.
The hallway shout, on the wire — ICMP echo request and reply
green = healthy/expected · red = problem packet(s) · amber = noteworthy, not faulty · untinted = context
| No | Time | Source | Destination | Protocol | Length | Info |
|---|---|---|---|---|---|---|
| 1 | 0.000 | 192.168.1.10 | 203.0.113.45 | ICMP | 74 | Echo request — 'are you there?' |
| 2 | 0.012 | 203.0.113.45 | 192.168.1.10 | ICMP | 74 | Echo reply — 'I'm here!' |
| 3 | 5.000 | 192.168.1.10 | 198.51.100.23 | ICMP | 74 | Echo request — no reply follows |
| 4 | 5.031 | 10.20.0.1 | 192.168.1.10 | ICMP | 78 | Destination unreachable — the network gives up |
Step 1 of 5 · packets 1, 2: The whole conversation in two packets: a question and its answer. Check the pair first in any capture — request, then the mirror-image reply.
Step 2 of 5 · packets 1: Open packet 1: the Type field says 8, which means 'echo request' — the hallway shout, written in the network's own control language.
Step 3 of 5 · packets 2: Packet 2 answers with Type 0 — 'echo reply.' Same sequence number as the request, so the laptop can match them up. This is what a healthy ping looks like on the wire.
Step 4 of 5 · packets 4: A different story: no reply came, so a device on the way gives up and sends Type 3 — 'destination unreachable.' This is the red packet: the network itself telling you it failed.
Step 5 of 5 · packets 3: And the quiet case: a request with no reply and no error either. Silence alone isn't proof of death — remember the * * * rule — but silence plus an unreachable message is a verdict.
| No | Time | Source | Destination | Protocol | Length | Info |
|---|---|---|---|---|---|---|
| 1 | 0.000 | 192.168.1.10 | 203.0.113.45 | ICMP | 74 | Echo request — 'are you there?' |
| 2 | 0.012 | 203.0.113.45 | 192.168.1.10 | ICMP | 74 | Echo reply — 'I'm here!' |
| 3 | 5.000 | 192.168.1.10 | 198.51.100.23 | ICMP | 74 | Echo request — no reply follows |
| 4 | 5.031 | 10.20.0.1 | 192.168.1.10 | ICMP | 78 | Destination unreachable — the network gives up |
Fixture: hand-authored to show a healthy echo exchange plus the 'destination unreachable' message; no production data
🔒 Revealed after the commitment ritual in S2 — attempt the challenge first. (Honor system: the page hides this until you check the box.)
Output A — me (Carla's trouble is on her own side). The proof is the summary line: "4 packets transmitted, 4 received, 0% packet loss" — plus four replies all landing at ~12 ms with no wobble. The road to the video site is healthy. So the network is innocent, and Carla's "can't reach the internet" lives in her laptop or its apps — the browser, the wifi radio, something on her side of the wire.
Output B — slow (one tired device, path otherwise fine). Hop 3 answers at 312 ms, 298 ms, then — while hops 4 and 5 answer crisply at ~14–15 ms. The proof is in those later lines: "4 72.14.200.10 14.2 ms 13.9 ms 14.5 ms" and "5 203.0.113.45 15.1 ms 14.8 ms 15.3 ms". If the road itself were congested, the far hops would be slow too — instead the later replies overtook* hop 3. One device is struggling to answer knocks (very common: busy devices deprioritize replying), but it's still forwarding real traffic fine. Ana's freezing video is that device's fault, not "the internet being slow."
Output C — down (past Ben's house). Hop 1 — the home box — answers at ~1 ms: "1 192.168.1.1 (home box) 1.1 ms 0.8 ms 1.0 ms". Then silence ( ), then the verdict: "From 10.20.0.1: Destination unreachable"*. Messages leave Ben's house cleanly and die at the street cabinet. Ben's gear is innocent; the camera's cloud address (or the road to it) is down.
Wrong turns, named: "Output B means the whole internet is slow" — hops 4 and 5 disprove it; judge a path by its far hops, not its worst middle one. "Output C means Ben's wifi is broken" — hop 1 answering in ~1 ms disproves it; his house is fine, the failure is past it. "Output A means Carla is imagining things" — never dismiss the user; "me" still means a real problem, just one that lives in her device rather than the network.
The exact answer: A = your own side (0% loss, steady 12 ms — the network is healthy) · B = slow (hop 3 at ~300 ms, hops 4–5 fast — one tired device) · C = down (hop 1 fine, then stars and "Destination unreachable" from 10.20.0.1).
Verify it worked: run ping -c 4 192.168.1.1 — your own home box — right now. Expected: 0% packet loss, replies around 1 ms, the same "hop 1 is healthy" pattern from outputs B and C. If you can point at that summary line and say "my side is innocent," you've internalized the method techs use on every call.
Check yourself — nothing here is graded. Wrong answers are the useful ones; each explains why.
Question 1. Ping reports: 10 transmitted, 6 received, 40% packet loss, times swinging 15–400 ms. Video calls stutter, but web pages eventually load. What's the diagnosis?
Question 2. Traceroute shows hops 1–3 answering in under 5 ms, then hops 4–9 all '* * *', and ping to the far server gets 100% loss. What's the diagnosis?
Question 3. Every ping to everywhere fails — even pinging 192.168.1.1, your own home box, shows 100% loss. What's the diagnosis?
Question 4. A traceroute hop shows '* * *' but later hops answer quickly. What does the '* * *' most likely mean?
- Ping asks "are you there?" and the reply's loss and timing tell you healthy, slow, or silent.
- Traceroute knocks on every door by expiring messages one hop at a time — each line is one device's answer.
- Judge a path by its far hops: a slow middle hop with fast hops after it is one tired device, not a slow path.
*means "no answer," not "dead" — silence from a device that still forwards traffic is normal.- Always test hop 1 first: if your own box answers cleanly, the trouble is past your house, not in it.
Next: How a Switch Learns: The MAC Table — you've learned to shout down the hallway and map every door; next you'll meet the quiet device that's been delivering your messages all along, and watch it memorize where every computer lives. Heads-up: Module 1 was the free taste — this is the first paid lesson, where the track gets hands-on with real device behavior.