Moving Beyond Ping for Troubleshooting Connectivity

In the following weeks, our sponsor NetAlly will be sharing some tips that will help you troubleshoot your network faster. This first tip shows us how to move beyond a basic ping when connectivity is a problem.

------

Ask any network pro about which command line tool they use the most – likely ping is near the top of the list, which makes sense. Ping has stood the test of time as a quick way to validate the network path between two endpoints.

But what if it fails? What can we do next?

When a ping is successful, we quickly can validate for at least that moment, we have a working path to the target station, routing is working, and basic connectivity is established. However, it is possible to have a successful ping even when underlying layer one and two issues are there - as these problems may not impact every single frame that traverses them.

Ping response times can also provide some level of understanding of latency across a network.

However, when a ping fails, there can be a host of reasons why. It could be that routing between the endpoints had a temporary failure, a link went offline (perhaps due to an intermittent cabling fault), or that ICMP was blocked by an infrastructure device or by the end station.

So before jumping to conclusions and assuming that the network is having a problem when we see a failed result, there are some additional steps we can take to get more information:

1. Try to validate the connection using a TCP connection

For example, if a web server cannot be pinged, try connecting to it using TCP port 443. This would help to determine if ICMP is being blocked along the path somewhere. This can be done using the telnet tool from most operating systems. However, rather than using the default TCP port of 23, we can use telnet to test connections to a defined port – like 80 (HTTP) or 443 (HTTPS).

2. TraceRoute to the target device/service

If possible, use a non-ICMP trace route tool to validate the network along the way, in case the network is blocking echo requests or other ICMP messages. The MacOS and Linux traceroute tools do this natively, using UDP to test the path. Windows systems use ICMP natively for this tool, so consider this if a device is blocking this protocol and the test fails.

3. Graph ping response times to watch for trends

This can help to determine if a drift in latency is due to intermittent network congestion at certain periods of the day. Taking a persistent ping measurement throughout the day and graphing the results can help watch for latency drifts, which can impact application performance.

Telnet and TraceRoute can be run natively from most operating systems. However graphing ping response times usually requires a little help from another tool.

One way to do it is with the Ping/TCP tool in the EtherScope nXG from NetAlly. This feature allows us to validate the network connection with a ping, check connectivity to a port with the TCP tool, and graph the results over time so we can see trends and drifts. After running these tests, the EtherScope can upload the test to Link-Live for reporting and documentation, which saves the time in creating our own local report.

So, let’s move beyond using just a basic ping to testing TCP connectivity, traceroute, and response time graphing. Together, these help us to more quickly diagnose performance and connectivity issues on the network.

Click here to learn more about the persistent ping feature of the EtherScope nXG.