Command-Line Triage and Ping

Build a Repeatable Command-Line Baseline

The CCST Networking exam (Cisco exam 100-150, 50 minutes, a question count Cisco says varies by exam form, no publicly published passing score, delivered through Pearson VUE/Certiport for around $125 USD) lists "run basic diagnostic commands and interpret results" under its diagnosing objectives. The load-bearing word is interpret. A command never repairs a network by itself; it produces evidence. Before you type anything, pin down five facts: the symptom, the affected user or device, the expected destination, the connection type (Wi-Fi, wired, VPN), and the scope (one user, one room, one site, everyone).

Then answer one question per command, in order:

1. Does this host even have an IP address? (ipconfig / ip addr)
2. Can it reach its own loopback (is the TCP/IP stack alive)?
3. Can it reach the default gateway (local LAN intact)?
4. Can it reach a known good external IP (routing out works)?
5. Can it resolve names (DNS works)?

What Ping Actually Proves

ping sends ICMP (Internet Control Message Protocol) Echo Request messages and waits for Echo Reply messages. A reply confirms only that packets reached the target and came back. It does not prove the website, file share, mail server, or login service is healthy. A server can answer ping while its web service is stopped; conversely a firewall may drop ICMP while permitting HTTPS, so ping fails even though the site loads in a browser. Treat ping as a Layer 3 reachability probe, nothing more.

Work from the inside out so each failure pinpoints a layer:

Reading the Output

Watch the message text, not just "failed." Request timed out means no reply arrived before the timeout (silent drop or filtering). Destination host unreachable means a device on the path actively reports it cannot deliver, often a missing route or down next hop. Ping request could not find host or Unknown host is a name-resolution error pointing at DNS or a typo, not at IP routing. Round-trip time and the Lost = N packet-loss line hint at latency and reliability, but a single four-packet test is not a real performance benchmark.

The split test is the most exam-relevant skill: if ping 8.8.8.8 succeeds but ping example.com returns a name error, IP connectivity is fine and DNS is broken; if a hostname resolves to an address but replies still fail, DNS works while reachability is blocked. If both fail, drop back to the address, gateway, link state, VLAN/SSID, and upstream checks.

Worked Scenario

A user reports the company intranet is "down." You ping the gateway 192.168.10.1 and get four <1 ms replies, so the LAN is healthy. You ping 8.8.8.8 and get replies, so routing out works. You ping intranet.company.example and get could not find host, so DNS resolution is the failure, not the network. You have moved from a vague outage to a specific resolver problem in three commands. Had the gateway ping failed instead, you would never have bothered testing DNS, you would have checked the cable, the Wi-Fi association, the switch port, and the client's address first, because nothing off-subnet can work until the gateway is reachable.

Useful Ping Options

Platform options matter when you need more than four packets or a different size. On Windows, ping -t host runs continuously until Ctrl+C, useful for watching an intermittent drop, ping -n 20 host sends 20 packets, and ping -l 1400 host sets payload size to probe for MTU or fragmentation issues. On Linux/macOS, ping runs continuously by default (use -c 20 to limit count) and -s sets the packet size. A continuous ping with a few timeouts scattered among replies points to intermittent loss, often a flapping link, wireless interference, or an overloaded path, rather than a hard outage.

Common Traps

• Reading a successful ping as "the application works." It only confirms ICMP reachability for that path, not that a web, mail, file, or login service is up.
• Assuming a timeout means the destination is dead; ICMP is frequently filtered by design at servers and firewalls.
• Forgetting that some hosts disable loopback responses or rate-limit ICMP, so a slow or missing reply is not always a fault.
• Pinging only a hostname and never an IP, which leaves you unable to tell a DNS failure from a routing failure.
• Flooding internal systems or running tests outside policy. Run a small, clear set, record the results, and escalate with context. A note like From user laptop on Wi-Fi, ping 192.168.10.1 at 09:14 = Request timed out x4; wired desktop on same VLAN reached gateway <1 ms is far stronger than ping failed, because it already isolates the problem to that laptop's wireless path rather than the gateway.