Sign in Subscribe
Network+

Basic Tools for Troubleshooting Network Services

This post introduces two foundational troubleshooting network tools, ping and traceroute, explaining how each works and when to use them. Using a practical analogy and real CLI output, readers learn how to systematically diagnose network connectivity issues step by step. It is aimed at Network+ lea

Jay Whale

• 3 min read
Basic Tools for Troubleshooting Network Services

When something stops working on a network, your first job is figuring out where the problem lives. Is it your device? The next hop router? Something three networks away? Fortunately, you do not need fancy software to start answering those questions. A handful of built-in command-line tools can tell you an enormous amount about what is happening on a network, and two of the most important are ping and traceroute.

Think of It Like Troubleshooting a Road Trip

Before diving into commands, here is a useful analogy. Imagine you are driving from your house to a friend's place across town. If you never arrive, there are several possible explanations: your car would not start, a road is closed near your house, or there is construction somewhere in the middle. Network diagnosis works the same way. You need tools that help you test each segment of the journey, not just shout into the void and wonder why no one answered.

The ping Command

The ping command is your simplest connectivity test. It sends an ICMP Echo Request to a target host and waits for an ICMP Echo Reply. If you get replies back, you know the host is reachable and the round-trip path is functional. If you do not, you have a starting point for further investigation.

Here is what a basic ping looks like on a Windows or Linux machine:

ping 8.8.8.8

PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=118 time=12.4 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=118 time=11.9 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=118 time=12.1 ms

--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 11.9/12.1/12.4/0.2 ms

Here is what to look for in that output:

  • Packet loss: Anything above 0% warrants investigation. High loss usually points to congestion or a failing link.
  • Round-trip time (RTT): The time= value shows how long each round trip took in milliseconds. Consistently high or wildly variable RTT can indicate network congestion or routing issues.
  • TTL: The Time to Live value tells you roughly how many hops the packet traveled. Each router decrements TTL by one.

If ping to a remote host fails, try pinging your default gateway first. If that works, the problem is further along. If it fails, the issue is closer to home, possibly your own network interface or local switch.

The traceroute Command

Where ping tests whether you can reach a destination, traceroute (called tracert on Windows) shows you the exact path your traffic takes to get there, hop by hop. It works by sending packets with incrementally increasing TTL values. Each router that decrements TTL to zero sends back an ICMP Time Exceeded message, revealing its identity.

traceroute 8.8.8.8

traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  192.168.1.1 (192.168.1.1)    1.2 ms   1.1 ms   1.0 ms
 2  10.20.0.1 (10.20.0.1)        8.4 ms   8.2 ms   8.3 ms
 3  72.14.215.165                10.1 ms  10.0 ms  10.3 ms
 4  8.8.8.8                      12.4 ms  11.9 ms  12.1 ms

Reading the output is straightforward. Each numbered line is a hop. The three time values represent three separate probe packets, giving you a sense of consistency. If you see asterisks (* * *) at a particular hop, that device is either blocking ICMP or not responding, which is not always a problem. If latency spikes dramatically at a specific hop and stays high for every hop after, that hop is likely where congestion or a routing issue exists.

Using Both Tools Together

In real network diagnosis, you rarely use just one tool. A solid troubleshooting workflow looks like this:

  1. Ping your own loopback address (127.0.0.1) to confirm your network stack is functional.
  2. Ping your default gateway to confirm local connectivity.
  3. Ping a known external host by IP to confirm internet routing.
  4. Ping an external hostname (like google.com) to confirm DNS resolution.
  5. Run traceroute if a ping fails to narrow down which hop is the problem.

This methodical approach keeps your troubleshooting network tools focused and prevents you from jumping to conclusions before you have actual data.

What's Next

Now that you have the fundamentals of ping and traceroute in your toolkit, the next step is learning about additional built-in tools like nslookup and ipconfig / ifconfig. These commands help you dig into DNS resolution problems and interface-level configuration issues, which are common culprits when basic connectivity looks fine but services still will not load.

🔧
If you find yourself running ping and traceroute repeatedly to keep tabs on network health, a dedicated monitoring tool like PRTG Network Monitor can automate that process and alert you the moment latency or packet loss crosses a threshold — no manual checks required. PRTG Network Monitor, SolarWinds Network Performance Monitor and ManageEngine OpManager.

Tools and resources for this topic