The Command-Line Toolkit

The Command-Line Toolkit

What you'll learn

• State precisely what ping proves — and the two things it can never prove
• Read ping's reply messages as diagnostic evidence, and adjust its behavior with switches on Windows and Linux
• Trace a path with tracert/traceroute and watch it live with mtr
• Inspect your machine's neighbor cache, connection list, configuration and routing table with the current commands on both operating systems
• Test a specific service — not just a host — with PowerShell's Test-NetConnection

This lesson builds on Chapter 10 of Dr. Tahseen Al-Doori's Network Essentials, the book's tour of the command-line utilities every technician carries. Almost everything in that chapter transfers to 2026 intact — these tools are among the most durable software in computing — with a handful of replacements and one small correction we will make along the way.

ping: the question "are you there?"

The name is honest about its origins: ping is borrowed from sonar. A submarine sends a sharp sound pulse into dark water and listens. If an echo returns, something solid is out there — and the round-trip time says how far away. Your computer's ping does exactly this with an ICMP echo request (you placed ICMP at the network layer in Module 2 — protocol number 1, riding directly inside IP). The target answers with an echo reply; ping prints the round-trip time and the reply's TTL. Four facts arrive in one line: the target exists, it is powered and running a network stack, a path exists in both directions, and the trip took this long.

Now the discipline: what ping does not prove. A reply tells you the machine answered — not that the program you need is running on it. Picture phoning a hotel to reach the spa desk: reception answers, which proves the building has power and a working phone line — but the spa may still be closed for the day. Servers work the same way: the operating system answers pings, while the web service, the print service or the database on that same machine may be stopped, misconfigured or firewalled. Programs are reached through ports (Module 5), and ping never knocks on a port — it only rings the building. Keep this distinction sharp; a tool for testing the spa desk directly arrives at the end of this lesson.

The second thing ping cannot prove is a negative. No reply does not reliably mean "host down," because ICMP is the most-filtered protocol on the Internet: host firewalls drop echo requests by default (Windows has shipped that way for two decades), and many routers rate-limit or ignore them. A dead ping to a machine that serves web pages perfectly is an everyday sight. Professional reading: a reply is strong evidence of life; silence is weak evidence of death.

Adjusting the question. Ping's switches tune how it asks — and here is a trap worth an honest warning: Windows and Linux use some of the same letters for different jobs (on Linux, -t sets the TTL and -w is a total deadline in seconds). Check the built-in help on the machine in front of you (ping /? or man ping) before copying a switch across systems.

The continuous form is the classic cable-wiggle test, straight from the book's teaching: start ping -t against the gateway, then move the suspect cable, connector or laptop — a burst of timeouts synchronized with your hand is a physical-layer confession.

Reading the answers. Each failure message is evidence pointing at a different layer:

That third row rewards a close look: when the "unreachable" verdict comes from your own IP address, no packet ever left your machine — the failure is local. When it comes from a router's address, your packet traveled and died out there. Same words, opposite diagnoses.

Tracing the path: tracert, traceroute and mtr

When ping says "no" to a distant target, the next question is where along the road the failure lives. tracert (Windows) and traceroute (Linux/macOS) answer it with a genuinely elegant trick: they send probes with deliberately tiny TTL values — first 1, then 2, then 3. Remember from Module 2 that every router decrements TTL and discards the packet at zero, sending back an ICMP "time exceeded" notice. So the TTL-1 probe dies at the first router, which thereby introduces itself; the TTL-2 probe dies at the second; hop by hop, the whole path signs the guest book. Where the introductions stop, the trouble begins — everything before the silence is working, which is isolation (next lessons' theme) performed automatically.

Useful switches: tracert -d (Windows) and traceroute -n (Linux) skip reverse-DNS lookups of each hop, making the trace dramatically faster; -h (Windows) / -m (Linux) caps the hop count; -6 forces IPv6. Two honest cautions. First, tracert rides on ICMP too — a hop showing * * * may simply be a router that refuses to answer probes while forwarding real traffic flawlessly; if later hops answer, the silent hop is fine. Second, paths can differ by direction; your trace shows the outbound road only.

mtr ("my traceroute", Linux/macOS; Windows ports exist) fuses both tools: it traces the path, then pings every hop continuously, showing live per-hop loss and latency statistics. For intermittent trouble — "the video call stutters every few minutes" — a few minutes of mtr -n <target> beats a hundred single pings, because the hop where loss begins stands out in a column.

Neighbors and conversations: arp, ip neigh, netstat and ss

Two more lists live inside your machine, and you have met both.

The ARP cache (Module 4) maps neighbor IP addresses to MAC addresses. arp -a (Windows) or ip neigh (Linux) prints it. Its diagnostic use: after you ping your gateway, the gateway's MAC must appear in this cache — if it does not, address resolution itself is failing and your problem lives at layer 2, not beyond. Entries age out after minutes of silence, which is why a neighbor you have not talked to recently is legitimately absent.

netstat ("network statistics") lists your machine's active conversations and listening ports. netstat -ano on Windows shows every connection and listener with the owning process ID; netstat -e prints interface counters — and one book-era reading still worth knowing: a healthy client sends overwhelmingly unicast traffic, so counters showing broadcast traffic rivaling unicast hint at a noisy or troubled LAN. On Linux, netstat is legacy: the replacement is ss (ss -tunp — TCP and UDP conversations, numeric, with programs), which you drilled in Module 5's ports lesson. Same questions, faster answers.

A historical cousin deserves its farewell note: nbtstat inspected NetBIOS names — Windows's pre-DNS naming world, where machines announced names like ACCOUNTS-PC and WINS servers kept the directory. That world is retired: modern Windows networks resolve names through DNS (plus local multicast discovery), Microsoft has deprecated the WINS/NetBIOS machinery, and new networks should not deploy it. You may still meet nbtstat in older exam material and in corners of aging networks — recognize it, date it (legacy — still worth knowing it existed), and move on.

Configuration, names and routes: ipconfig, ip, nslookup, dig, route

ipconfig is Windows's configuration reporter, your companion since Module 4. The family: ipconfig (summary), /all (everything: MAC, DHCP server, lease times, DNS servers), /release and /renew (give back / re-request the DHCP lease — the pair you captured live in Module 5's DHCP lab, with /release6 and /renew6 for IPv6), /displaydns (the local resolver cache), /flushdns (empty it — the classic first move when a name resolves to a stale answer), and /registerdns (re-register this machine's own name and refresh its lease in one stroke).

One kind correction as we pass: the book's chapter slips in one line and names IPCONFIG as the UNIX version of the command — an easy confusion, since the names are nearly twins. The classic UNIX/Linux counterpart was actually ifconfig ("interface configuration"), and even that is now itself a legacy tool: current Linux systems use the ip command suite — ip addr for configuration, ip route for the routing table, ip neigh for the neighbor cache (current; macOS still ships ifconfig). One habit to carry: on Linux, if a guide reaches for ifconfig or netstat, mentally translate to ip and ss.

Remember also what ipconfig cannot do — a distinction the book presses because certification exams press it: ipconfig reports settings; it does not test connectivity. A machine can display a perfectly formed address whose lease outlived the cable being unplugged. Configuration is a claim; ping is a test.

nslookup and dig interrogate DNS directly — your Module 5 skills, recapped as diagnostic instruments. nslookup example.com asks your configured resolver and prints, in its first lines, which server it is asking — gold when the question is "is DNS itself broken, or just slow?", because that header appears even when the query times out and no answer ever comes. If an answer follows, that server answered; if DNS request timed out follows, the header has just named the resolver you depend on and cannot reach. Interactive mode (nslookup, then commands like server 1.1.1.1 or set type=MX) lets you re-ask the same question of a different server, instantly separating "my resolver is sick" from "the record is wrong everywhere." dig (Linux/macOS) answers the same questions with more detail and cleaner scripting: dig example.com MX +short.

route print (Windows) / ip route (Linux) shows the table you learned to read in Module 4's gateway lesson — look for the 0.0.0.0/0 "anywhere else" line naming your gateway. Its place in the kit: when ping says destination host unreachable from your own address, this table is the accused. The route add / route delete forms modify it; adding static routes is an administrator's move you will not need in this course, but knowing the table is editable explains how machines end up with broken custom routes.

The modern addition: Test-NetConnection

Windows PowerShell contributes the newest tool in the kit, and it closes the loop this lesson opened: Test-NetConnection (alias tnc) tests a service, not just a host.

Test-NetConnection example.com -Port 443

One command resolves the name and attempts a real TCP connection to port 443: TcpTestSucceeded : True means the spa desk itself picked up, not just reception. Note what -Port does to the cmdlet — it switches into TCP-test mode and stops pinging altogether, so no PingSucceeded line appears. Run Test-NetConnection example.com on its own when you want the ICMP result; the two commands together are ring-reception-then-knock-on-the-door, in that order. When ping is filtered (that caveat again), the TCP test still tells the truth, because real services must accept real connections. Linux has no single equivalent; the working idioms are curl -sI https://example.com | head -1 for web services (expect an HTTP/… status line) or nc -vz <host> <port> where netcat is installed.

From the textbook to 2026

The remarkable fact about Chapter 10 is how little has changed: ping, traceroute, arp, nslookup and the routing table work today precisely as taught in 2007 — this toolkit is the stable bedrock of the trade. The changes are substitutions at the edges: on Linux, the iproute2 suite's ip and ss are the present tense of ifconfig and netstat (both legacy — still worth recognizing); nbtstat and the whole NetBIOS/WINS naming world moved from "Windows-only tool" to retired history as DNS became the only directory that matters; dig joined nslookup as the resolver-side workhorse; and PowerShell's Test-NetConnection added the service-level test the classic kit always lacked. One book slip — IPCONFIG credited as the UNIX version — corrected above, kindly: the right lineage is ifconfig, now succeeded by ip.

Lab: The Twelve-Step Diagnostic Relay

The kit only becomes yours through your fingers. This relay runs every tool against your own connection in a deliberate order — the same escalation you will use on real faults for the rest of your career: inside the machine → across the LAN → out the gateway → up to names and services. Every step lists both command forms; run the one matching your OS (or both, if you have both). Nothing here changes any setting except step 12's cache flush, which is harmless.

Objective. Verify your own connectivity layer by layer, touching all ten tools, and annotate what each step proves.

Setup. Any Windows or Linux computer on a working network, with a terminal (Command Prompt or PowerShell on Windows — step 11 needs PowerShell; any shell on Linux). Have paper or a text file open: the deliverable is your annotated relay sheet — one line per step: command, key output, what it proved.

Steps.

1. Read your configuration. ipconfig /all · ip addr (then ip route for the gateway). Record: your IPv4 address, mask, default gateway, DNS server(s), MAC. Expected: a private address (likely 192.168.… or 10.…). Proves: configuration exists. Red flag: an address starting 169.254. means DHCP failed and Windows self-assigned — stop and fix DHCP first (renew in step 2's position: ipconfig /renew).
2. Ping the loopback. ping 127.0.0.1 (Linux: add -c 4 here and in every ping step). Expected: instant replies, ~0 ms. Proves: the TCP/IP stack itself is installed and sane. This never touches the network card.
3. Ping your own address (from step 1). Expected: instant replies. Proves: your adapter and driver work.
4. Inspect the neighbor cache — before. arp -a · ip neigh. Expected: a short list; the gateway may or may not appear yet. Note whether it does.
5. Ping the default gateway (address from step 1). Expected: replies in ~1–10 ms. Proves: physical layer, switching, and your addressing all work to the edge of your LAN. If it fails but the Internet works (test later steps anyway): your gateway filters ICMP — annotate, don't panic.
6. Inspect the neighbor cache — after. arp -a · ip neigh. Expected: the gateway's MAC address now present (Linux: state REACHABLE). Proves: ARP resolution works; you just watched the cache learn.
7. Ping a public address by number: ping 1.1.1.1. Expected: replies, tens of ms. Proves: routing and NAT carry you beyond the LAN — with DNS deliberately not involved yet.
8. Ping the same world by name: ping example.com. Expected: the name resolves to an address, then replies. Proves: name resolution works end to end. If step 7 succeeded and this fails, you have isolated a pure DNS problem — the relay's most instructive possible outcome.
9. Interrogate DNS directly. nslookup example.com · dig example.com +short (run nslookup on either OS if dig is absent). Expected: nslookup's header names the server it queried — compare it with step 1's DNS entry. Proves: which resolver you actually depend on.
10. Trace the road out: tracert -d 1.1.1.1 · traceroute -n 1.1.1.1 (or mtr -n 1.1.1.1 for the live version; press q to quit). Expected: hop 1 is your gateway from step 1; a handful of hops follow; * * * rows mid-path are routers declining to introduce themselves, not failures. Proves: the path, hop by hop — and that hop 1 confirms your routing table in practice.
11. Test a service, not a host. PowerShell: Test-NetConnection example.com -Port 443 · Linux: curl -sI https://example.com | head -1. Expected: TcpTestSucceeded : True · an HTTP/… line. Proves: an actual program answered on an actual port — the distinction this lesson opened with, demonstrated.
12. Read, then clear, the resolver cache. ipconfig /displaydns (spot example.com from step 8), then ipconfig /flushdns · Linux with systemd: resolvectl statistics, then resolvectl flush-caches. Expected: "Successfully flushed…" · counters reset. Proves: you know where stale name answers hide, and how to evict them.

Expected result. Twelve annotated lines; every step green (or a consciously annotated exception such as an ICMP-filtering gateway at step 5).

Verify. Cover the command column of your sheet and re-derive it from the annotation alone: "prove the stack is installed" → you should produce ping 127.0.0.1 without looking. The relay is learned when the questions generate the commands.

Questions.

1. Steps 2 and 3 both ping addresses belonging to your own machine. Why keep both — what can step 3 catch that step 2 cannot?
2. A colleague's relay: steps 1–7 pass, step 8 fails. Steps 9's nslookup times out. Name the failed component and the evidence chain.
3. In step 10, hops 4–6 show * * * but hops 7–12 answer normally. Is the path broken? Explain like a professional.
4. Why does the relay ping 1.1.1.1 before pinging example.com, and not the other way around?

(Answers: 1 — step 2 exercises only the software stack via the loopback; step 3 additionally exercises the real adapter and driver — a dead NIC passes step 2 and fails step 3. 2 — DNS resolution: connectivity by number is proven through step 7, the by-name ping fails, and the direct resolver query also fails — the resolver itself is unreachable or down. 3 — no: those routers simply decline to answer probes; hops beyond them responding proves traffic flows through them fine. 4 — testing by number first removes DNS from the experiment, so each step adds exactly one new suspect; reversed, a failed name-ping would leave two suspects tangled together.)

If it goes wrong.

• Step 1 shows 169.254.x.x. Your machine never reached a DHCP server: check the cable/Wi-Fi association, then ipconfig /renew · sudo dhclient -v (or toggle the interface).
• Step 5 fails on a network that otherwise works. Gateway filters ICMP — very common on corporate gear. Confirm with steps 7 and 11: if the world is reachable, annotate and continue.
• Steps 7–8 both fail; 1–6 pass. Your LAN is healthy but the way out is not: gateway device, ISP link or upstream. Rerun step 10 toward 1.1.1.1 and note where introductions stop.
• dig/mtr not found on Linux. Install (sudo apt install dnsutils mtr on Debian/Ubuntu) or substitute nslookup/traceroute — the relay is about questions, not spellings.
• PowerShell blocked at step 11. The curl form works on modern Windows too: curl.exe -sI https://example.com.

Reset/cleanup. Nothing to undo — the only state changed was a DNS cache that rebuilds itself with use. Keep the relay sheet: it is the seed of the personal runbook you will build for the rest of this module.

Check yourself

1. A user reports "the Internet is down." Ping to the company web server's name fails with Ping request could not find host. What single fact does this message already establish, and which tool do you reach for next?
2. ping 192.168.1.44 returns Destination host unreachable reported from 192.168.1.23 — the technician's own address. Ping to the gateway succeeds. Where does the fault live, and which cache would you inspect?
3. A monitoring alert says a branch office is unreachable. tracert toward it answers normally for 5 hops and then shows * * * forever, never reaching the destination. A second tracert to a different site shares the first 4 hops and completes. What have you learned, in isolation terms?
4. A server answers ping in 2 ms, yet customers report the website down. Name the tool and exact command that tests the real question, and say what result confirms the outage.
5. On a borrowed Linux laptop you type ping -t 10.0.0.1 expecting an endless ping, and it exits after a few probes with odd output. What happened, and what habit prevents it?
6. During the relay, step 7 (ping 1.1.1.1) fails but step 5 (gateway) passes. A teammate says "must be DNS." Refute them with one sentence of evidence.

Answers

1. The name never resolved — no probe was sent, so this is a DNS symptom, not connectivity. Next: nslookup (or dig) to interrogate the resolver directly.
2. On the local LAN, at layer 2/3 between the technician's machine and .44: the machine itself found no way to deliver — most often ARP got no answer (host off, wrong subnet). Inspect the ARP cache (arp -a / ip neigh) for a missing or incomplete entry for .44.
3. The first 4 shared hops work (proven by the second trace); the branch path dies after hop 5. The fault is isolated to the segment beyond hop 5 on the branch route — likely the branch link or its provider, not your LAN or core.
4. Test-NetConnection <server> -Port 443 (or curl -sI https://<server>). TcpTestSucceeded : False (or no HTTP status line) while ping succeeds confirms: host up, service down.
5. On Linux -t sets the TTL, not "ping forever" — the flag letters differ across systems. Habit: check ping /? or man ping on the machine in front of you before reusing a switch.
6. DNS cannot be the culprit because 1.1.1.1 is a raw address — no name was ever resolved; the failure sits in routing/NAT beyond the gateway.

Key terms

• ICMP echo request / echo reply — the packet pair behind ping; ICMP is protocol 1, the network layer's messenger (Module 2).
• Round-trip time (RTT) — the milliseconds between request sent and reply received; ping's per-line measurement.
• ICMP filtering — firewalls and routers dropping or rate-limiting ICMP; the reason silence is weak evidence of death.
• tracert / traceroute — path discovery by expiring TTLs: each router in turn kills a probe and introduces itself.
• mtr — live traceroute + per-hop loss/latency statistics; the intermittent-problem instrument.
• ARP cache — the IP→MAC neighbor table (arp -a / ip neigh); ages out after idle minutes.
• netstat / ss — connection and listener listing; ss is the current Linux form (netstat legacy).
• nbtstat / WINS / NetBIOS names — Windows's pre-DNS naming system and its inspector (retired; recognize in old material).
• ipconfig family — /all, /release, /renew, /displaydns, /flushdns, /registerdns; reports and refreshes configuration — never tests connectivity.
• ifconfig → ip — the UNIX/Linux lineage: ifconfig (legacy) succeeded by the iproute2 ip suite (current).
• nslookup / dig — direct DNS interrogation; both name the server being queried (even on a timeout), and can be pointed at a different one.
• Test-NetConnection — PowerShell's service-level test: resolve + ping + real TCP connection to a named port.

Summary

• Every tool answers one question; the professional skill is picking the question before the command.
• Ping proves a host answers — never that a service runs (ports are the spa desk, ping only rings reception), and silence is weak evidence because ICMP is routinely filtered.
• Ping's messages localize faults: unreachable-from-your-own-address means the packet never left; unreachable-from-a-router means it died mid-path; could-not-find-host means DNS, not connectivity.
• tracert/traceroute turn the TTL hop budget into a searchlight, making every router introduce itself; mtr adds continuous per-hop statistics.
• arp/ip neigh expose layer-2 resolution; ss (and netstat -ano on Windows) expose live conversations and listeners; nbtstat belongs to the retired NetBIOS/WINS era.
• ipconfig reports, ping tests — configuration is a claim, not a proof; on Linux, ip and ss are the present tense of ifconfig and netstat.
• Test-NetConnection (or curl) asks the modern question the classic kit could not: is the service itself accepting connections?
• The twelve-step relay — stack → adapter → LAN → gateway → world by number → world by name → service — is the escalation order for real diagnosis.

Next lesson

The command line tells you that something is wrong; the next lesson opens the microscope that shows you what the packets themselves are doing. Wireshark returns — this time with the professional filtering craft this course has been promising since your first capture.

Sources and further study

• Al-Doori, T., Network Essentials, Chapter 10 — the command-line utilities tour this lesson consolidates and modernizes.
• ping(8), Linux manual page — https://man7.org/linux/man-pages/man8/ping.8.html — every Linux switch, authoritatively.
• ipconfig — Microsoft Learn — https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/ipconfig — the full Windows family reference.
• Test-NetConnection — Microsoft Learn — https://learn.microsoft.com/en-us/powershell/module/nettcpip/test-netconnection — parameters and output fields.
• ss(8), Linux manual page — https://man7.org/linux/man-pages/man8/ss.8.html — the modern connection viewer.
• Download: Ports and Protocols Reference (the Module 5 card — keep it beside netstat/ss output to name what you see listening).