Command-Line Tools: ping, traceroute, nslookup, dig, ipconfig, ifconfig, ip, arp, netstat, ss, and route
Key Takeaways
- ping tests reachability with ICMP, but a blocked ping does not always mean the host or service is down.
- traceroute and tracert reveal the path toward a destination and can localize routing or hop-related loss.
- nslookup and dig test DNS resolution, record types, authoritative answers, and resolver behavior.
- ipconfig, ifconfig, and ip show local addressing, interface state, gateways, DNS settings, and lease information.
- arp, netstat, ss, and route inspect neighbor resolution, active connections, listening ports, and routing tables.
Command-Line Troubleshooting Tools
Command-line tools isolate where a problem lives: the local host, name resolution, the default gateway, the routing path, a remote service, or a policy enforcement point. N10-009 objective 5.3 lists these utilities by name, and the exam almost always frames them as "which is the best next tool for this symptom?" Memorize both the Windows and Linux variants, because PBQs may show output from either.
Reachability and Path
| Tool | Common platforms | What it tests |
|---|---|---|
| ping | Windows, Linux, macOS | ICMP echo reachability, round-trip latency, packet loss |
| traceroute | Linux, macOS | Path toward a destination using incrementing TTL (UDP/ICMP) |
| tracert | Windows | Windows path tracing (ICMP echo by default) |
| pathping | Windows | Combines path discovery with per-hop packet-loss statistics |
Ping is useful but limited. A host or firewall may silently drop ICMP while the application still works on TCP 443. Traceroute shows where packets stop, but routers often rate-limit or drop the ICMP Time Exceeded replies, producing rows of asterisks that do not necessarily mean an outage at that hop. Treat these tools as evidence, not absolute proof. On Windows, ping -t runs continuously and ping -l 1500 -f tests MTU/fragmentation; on Linux, ping -c 4 sends four packets.
DNS Tools
| Tool | Best use |
|---|---|
| nslookup | Quick lookup and resolver testing; nslookup host server queries a specific resolver |
| dig | Detailed queries, record types (A, AAAA, MX, TXT, NS, SOA), authoritative answers, TTLs |
| host | Simple, terse hostname lookup on Unix-like systems |
DNS symptoms include reaching an app by IP but not by name, wrong records after a change, split-horizon (internal vs. external) discrepancies, stale answers from a long TTL, and only one resolver returning a bad answer. Worked example: if https://portal.example.com fails but https://203.0.113.50 works, run dig portal.example.com or nslookup portal.example.com before touching any hardware. Use dig +trace to follow delegation from the root, and dig @8.8.8.8 example.com to compare a second resolver.
Interface and Address Tools
| Tool | Platform | Useful output |
|---|---|---|
| ipconfig | Windows | IP, mask, gateway, DNS, basic adapter state |
| ipconfig /all | Windows | Full adapter config including DHCP server and lease times |
| ipconfig /release and /renew | Windows | Release and renew the DHCP lease |
| ifconfig | Older Unix-like | Interface addresses and basic state (deprecated on modern Linux) |
| ip addr | Linux | Interface addresses and status |
| ip link | Linux | Link state, MAC address, MTU |
| ip route | Linux | Routing table and default gateway |
If one workstation cannot connect, confirm it has a valid IP, subnet mask, default gateway, DNS server, and an up link. A 169.254.0.0/16 APIPA (Automatic Private IP Addressing) address on Windows almost always means that host failed to obtain a DHCP lease, pointing to DHCP server reachability, the switch port, or the VLAN, not to a DNS or routing fault.
Neighbor, Socket, and Route Tools
| Tool | What it shows | Scenario |
|---|---|---|
| arp -a | ARP cache | Verify IP-to-MAC resolution on the local subnet |
| ip neigh | Linux neighbor table | Modern Linux equivalent of the ARP cache |
| netstat | Connections, listening ports, routes, stats | Confirm a service is listening or sessions exist (netstat -an) |
| ss | Modern Linux socket statistics | Faster replacement for many netstat uses (ss -tlnp) |
| route print | Windows routing table | Confirm the default route or static routes |
| route / ip route | Unix-like routing | Inspect or modify routes |
When client and server share a subnet, ARP matters: if the default gateway's MAC cannot be resolved, all off-subnet traffic fails. When a service is unreachable, ss -tln or netstat -an shows whether it is listening on the expected port and the right interface (0.0.0.0 vs. 127.0.0.1). A service bound only to 127.0.0.1 (loopback) is reachable locally but not from the network, a subtle finding that explains "the app works on the server but not from clients." On Windows, netstat -ano adds the owning process ID so you can map a listening port to a service; on Linux, ss -tlnp shows the process directly.
Reading the ARP cache with arp -a and comparing the gateway's MAC across two clients can also expose ARP spoofing or a duplicate-IP conflict, where two devices answer for the same address and intermittent connectivity results.
Symptom-to-Tool Matrix
| Symptom | First useful command |
|---|---|
| No IP or wrong gateway | ipconfig /all, ip addr, or ip route |
| Hostname fails but IP works | nslookup or dig |
| Need to see where the path stops | traceroute, tracert, or pathping |
| Verify local neighbor resolution | arp -a or ip neigh |
| See listening TCP ports | netstat -an or ss -tln |
| Inspect the default route | route print or ip route |
Common Traps
- A successful ping to a server does not prove the application port is open.
- A failed ping does not prove the server is down if ICMP is filtered.
- DNS cache can make one client behave differently from another; clear it with
ipconfig /flushdns. - A correct IP with the wrong subnet mask still breaks local communication.
- Multiple default gateways on one host create unpredictable routing.
A user can reach a web application by IP address but not by its hostname. Which tool should be used first?
Match each command-line tool to its common troubleshooting use.
Match each item on the left with the correct item on the right
A Windows workstation has a 169.254.x.x address and cannot reach network services. What is the most likely direction to investigate?