Network troubleshooting commands: the right tool for the symptom

ping: is this host reachable at Layer 3

ping sends ICMP echo requests and waits for replies. It tests whether one host can reach another at the network layer. If ping works, Layer 1, 2, and 3 are healthy between you and the target. If ping fails, the problem lives somewhere below the application.

C:\> ping 192.168.1.1

Pinging 192.168.1.1 with 32 bytes of data:
Reply from 192.168.1.1: bytes=32 time<1ms TTL=64
Reply from 192.168.1.1: bytes=32 time<1ms TTL=64
Reply from 192.168.1.1: bytes=32 time<1ms TTL=64
Reply from 192.168.1.1: bytes=32 time<1ms TTL=64

Ping statistics for 192.168.1.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss)

What to look for in the output: reply count (loss tells you about congestion or a flaky link), round-trip time (latency hints at congestion or distance), and TTL (decrements at each hop, so a TTL of 64 means zero hops, you are talking to your local default gateway). "Request timed out" means no reply came back. "Destination host unreachable" means a router along the way had no route to your target.

tracert and traceroute: where in the path does it break

When ping fails, traceroute shows you which hop fails. It sends packets with increasing TTL values, so each router along the path is forced to send back a "TTL exceeded" message. That gives you the address of every router between you and the destination, in order.

On Windows the command is tracert. On Linux and macOS it is traceroute. Same idea, slightly different output format. On Windows the default uses ICMP. On Linux it uses UDP by default. Some networks block one or the other. If you get asterisks instead of times, ICMP or UDP is being filtered.

nslookup and dig: is DNS resolving correctly

When a user says "I cannot reach the website but I can ping its IP," DNS is your suspect. nslookup queries DNS directly so you can see whether a name resolves and to what address. dig is the more powerful Linux and macOS equivalent.

C:\> nslookup mail.example.com

Server:  dc01.example.local
Address: 192.168.1.10

Non-authoritative answer:
Name:    mail.example.com
Address: 203.0.113.42

Read this top down. "Server" is which DNS server answered you. "Non-authoritative answer" means the answer came from a cache, not the authoritative server. If the IP is wrong, your DNS server is stale or has been poisoned. If you get "server can't find," the name does not exist or your DNS server cannot reach an authoritative server.

ipconfig, ip a, and ifconfig: what does my own machine think

Half of troubleshooting is checking your own machine first. ipconfig on Windows, ip a (the modern replacement for ifconfig) on Linux, and ifconfig on macOS show your interface's IP, mask, default gateway, and DNS server.

On Windows, ipconfig /all gives you the full picture including MAC address and DHCP lease info. ipconfig /release and ipconfig /renew drop and reacquire a DHCP lease, which is the single most useful one-line fix for "my IP looks weird." If you see 169.254.x.x, that is APIPA, which means the machine could not reach a DHCP server.

netstat and arp: who is connected, who is talking

netstat -an shows open TCP and UDP connections plus listening ports. Useful when you suspect a port is blocked, a service is not listening, or something unexpected is connecting outbound. On Linux, ss -tuln has replaced netstat for most uses but the older command still works.

arp -a shows the ARP cache, the mapping between IP addresses and MAC addresses on your local subnet. If two machines have the same IP, you see ARP table flapping. If a Layer 2 attacker is poisoning ARP, the same IP maps to a MAC you do not expect. The arp table is also where you confirm "yes, my machine knows the MAC of the gateway" when Layer 2 troubleshooting.

route, pathping, and the OS-specific tools

route print on Windows and ip route on Linux show the routing table. Useful when a static route is missing, a metric is wrong, or VPN routing has hijacked traffic you did not expect.

pathping is a Windows-only hybrid of ping and tracert that gives you per-hop statistics over a longer sample window. Slower than tracert but it tells you which hop is actually losing packets, not just which hop is sometimes slow. On Linux, mtr is the equivalent.

Walking a real ticket: the file share is unreachable

A remote user at a logistics firm in the south suburbs cannot reach the file share at fileserver.corp.local. Walk it.

1. Run ipconfig /all. Confirm the user has a real IP (not APIPA), a default gateway, and the corporate DNS server (not 8.8.8.8).
2. Run ping fileserver.corp.local. If the name resolves but ping fails, DNS is fine and the problem is routing or a firewall.
3. If DNS fails, run nslookup fileserver.corp.local. Confirm which server answered and what address it returned. If you get "server can't find," the user's VPN tunnel did not bring up the corporate DNS server.
4. Run tracert fileserver.corp.local. See where the path dies. If it dies at the user's gateway, their internet is the problem. If it dies at the VPN concentrator, the VPN is the problem.
5. Run netstat -an | findstr 445. See whether the user has an existing SMB connection to the file server. If they do but cannot mount, the problem is authentication or share permissions.

Each step takes about thirty seconds. By the end you know exactly which layer broke and exactly which team to hand the ticket to.

What this looks like in our platform

The Study Mode deck for objective 5.3 covers every command in this post plus the less common ones (iperf, tcpdump, Wireshark capture filters). The Help Desk Simulator has tickets where you have to run the right command at the right time and read the output. The Net+ track page shows where troubleshooting tools fit in the broader domain.

The pattern across operating systems

Windows, Linux, and macOS all have a tool for every job in this list. The names differ. The output differs slightly. The mental model does not. Reach for the tool that tests the layer you suspect, read the output for the failure signature, and let the answer point you to the next test. The command is a means to the end, not the end itself.

About the authors

Nick Miller

Founder and Lead Author

IT Service Center Manager and former CTE / IT teacher. Owner of Revtek IT Solutions. Writes everything that ships under his name and reviews every line of Revy-assisted drafting before publish.

LinkedIn ↗

R

Revy

Study buddy · AI co-author

Revy helps draft and structure these posts. Every piece is reviewed, edited, and fact-checked by Nick before publish. We disclose this here because it is the right thing to do. See the AI Policy for the full stance.