Moving Beyond Ping for Troubleshooting Connectivity

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.

The Canonical Weekend - Paul Smith

 

A former boss of mine had a well-rehearsed response for any employee who complained they had too much work. There are twenty-one 8-hr workdays in a week, he would say; three in each of the seven 24-hour days. If you are only using five out of those twenty-one, you are clearly just lazy.

Although the 40-hour workweek would be a dream come true for many (unless you happen to live in Luxembourg) , there are few among us who could ever envision working the 168 hours suggested by this guy. The average full time US worker puts in 41.5 hours, making us a nation of slackers by my old boss’s standards. The hardest workers are found in Colombia, where the average work week is nearly 50 hours, still less than a 30% utilization of available time. 

Troubleshooting At The Physical Level

I thought it would be a good idea to start a series using the NetworkDataPedia’s theme of ‘knowing your network. 

Let’s start at layer 1 or the hardware layer.

Unfortunately, there is so much that can go wrong at this layer that I cant possibly cover it in one article.  I see a lot "you have a network connection and life will seem fine" attitude. This is unfortunate because if the problems would cause an complete outage, you would be forced to address it instead of ignoring it.

I find that many physical level issues are grouped into a few categories:

Installation and Support

FREE WIRESHARK CLASS - Lecture 5 - Hands on stuff

 To celebrate my 10th year on youtube and to thank all those who watch, like, share and subscribe i wanted to give you a gift. 2 years ago i created a Wireshark class for Udemy which was very popular.

FREE WIRESHARK CLASS - Lecture 4 - Navigation

 To celebrate my 10th year on youtube and to thank all those who watch, like, share and subscribe i wanted to give you a gift. 2 years ago i created a Wireshark class for Udemy which was very popular.