Introduction
When a network problem occurs — a site won't load, a server seems unreachable, or a connection is slow — engineers rely on a small set of command-line tools to isolate where the failure is happening. Each tool probes a different layer or aspect of the network: reachability, path, active connections, or name resolution. Understanding exactly what each tool does mechanically, not just what output it prints, is what turns a guess into a diagnosis.
Cricket analogy: Just as a team analyst checks different data feeds, run rate, field placement, and pitch report, to diagnose why a batting collapse happened, engineers use different tools to isolate which network layer is failing.
Explanation
ping sends ICMP Echo Request packets to a target host and waits for ICMP Echo Reply packets. It measures round-trip time (RTT) and reports packet loss, telling you whether a host is reachable and roughly how much delay exists on the path. traceroute (tracert on Windows) discovers the sequence of routers (hops) between you and a destination. It works by sending packets with an increasing Time-To-Live (TTL) value, starting at 1. Each router that forwards a packet decrements the TTL by one; when TTL reaches 0, the router discards the packet and returns an ICMP 'Time Exceeded' message. By sending packets with TTL 1, 2, 3, and so on, traceroute forces each successive router along the path to reveal itself, building a hop-by-hop map and per-hop latency. netstat and its modern replacement ss display active network connections, listening ports, and socket states (such as ESTABLISHED, LISTEN, TIME_WAIT) by reading kernel connection-tracking tables — useful for confirming a service is actually listening or finding what process owns a connection. nslookup and dig query DNS servers directly, sending DNS protocol requests (typically over UDP port 53) and displaying the resource records returned (A, AAAA, MX, CNAME, etc.), which helps determine whether a problem is a name-resolution failure rather than a connectivity failure.
Cricket analogy: ping is like calling out to a fielder and timing how long the throw-back takes, traceroute is like tracking the ball through each relay throw from boundary to keeper, and dig is like checking the official scorer's name registry.
Example
# Check basic reachability and latency
ping -c 4 example.com
# Trace the hop-by-hop path to a destination
traceroute example.com
# On Windows: tracert example.com
# List listening TCP ports and established connections
ss -tulpn
# Older/legacy equivalent:
netstat -tulpn
# Query DNS records directly
dig example.com A
nslookup example.comAnalysis
A structured troubleshooting flow uses these tools in layers. If ping fails entirely, the problem may be at the network or lower layers (routing, firewall blocking ICMP, or the host being down). If ping succeeds but an application fails, check ss/netstat on the server to confirm the service is actually bound and listening on the expected port. If a hostname-based request fails but an IP-based request succeeds, the issue is DNS, and dig/nslookup will show whether the resolver returns the wrong record, no record, or times out. traceroute is most useful when latency is high or connectivity is inconsistent partway through the path — it shows exactly which hop introduces delay or where packets stop being forwarded, which helps determine whether the problem is inside your network or somewhere upstream with an ISP or destination network.
Cricket analogy: If a bowler can't get the ball to reach the keeper at all, check the pitch itself (ping failing means network layer); if the ball arrives but the keeper drops it, check the keeper's gloves (ss shows if the service is listening).
Key Takeaways
- ping uses ICMP Echo Request/Reply to test reachability and measure round-trip time and packet loss.
- traceroute reveals the path by sending packets with incrementing TTL values and reading the ICMP Time Exceeded replies from each hop.
- netstat/ss inspect kernel socket tables to show listening ports and connection states.
- nslookup/dig send direct DNS queries to check name resolution independently of connectivity.
Practice what you learned
1. What mechanism does traceroute use to discover each router along a path?
2. Which protocol does ping use to test reachability?
3. You suspect a server process isn't actually listening on port 443. Which tool would confirm this directly?
4. A user can reach a site by IP address but not by domain name. What should you check first?
Was this page helpful?
You May Also Like
Network Performance Concepts
Understand how bandwidth, throughput, latency, jitter, and packet loss differ and how they interact to determine real-world network experience.
DNS: The Domain Name System
How DNS translates human-friendly domain names into IP addresses through a distributed hierarchy of resolvers and servers.
Ports and Sockets
Understand port number ranges and how a socket, the pairing of an IP address and port, identifies a network endpoint.
Routing Fundamentals
Understand how routers use routing tables and longest prefix match to forward packets, and the difference between static and dynamic routing.