Over the past year, NetPath has been put through its paces by many of our customers who have benefitted from its numerous enhancements.
In this blog, we will delve into the top five common questions we heard about NetPath.
1. Why should I use NetPath? Why not Ping or traceroute?
For many of us, as network technicians, PING (Packet InterNet Groper) and traceroute (or tracert) have been our most trusted network troubleshooting tools. They have served well in troubleshooting connectivity issues, but they have their limitations.
Both Ping and traceroute provide the status of the network between two endpoints at a given instant. Even when you run them continuously, they cannot provide directional information; they cannot answer questions such as, “Is the value of latency good enough for my applications to maintain connectivity?” or “If it is bad, how bad is it?” For example, just as I was writing this sentence, I ran a quick ping test from my laptop to CNN.com. The result is attached in the picture below.
Here are some interesting observations:
- The network latency is not constant: the latency in this example varies between 11ms and 75ms.
- There are some packet drops as well (packets #6 and #14 were dropped somewhere along the path)
- More importantly, the very last ping output says it took 75ms for the ICMP request packet to reach the destination and response packet to get back.
The questions still remain: Is a latency of 75ms good enough? Is some higher latency, say 500ms, good enough? Is it a problem that I need to troubleshoot? The answer is it depends. Compared to all the other packets that were sent, that last packet took six times longer to reach the destination [FYI: Latency of 75ms is fine for most Internet applications, including voice/video]. Ping and traceroute lack the following important features necessary for troubleshooting:
- The ability to dynamically identify what values of latency are good and what are not
- For this specific path, what values of latency make sense (alert on specific thresholds)
- The ability to alert the user when the dynamic threshold for latency/RTT is violated
For these reasons and more, NetPath is a very powerful tool and a must-have in every MSP’s toolkit to make network management and troubleshooting easy.
2. How do I monitor a path for connectivity and alert when problems occur?
This is the most common use case for NetPath. NetPath tracks and stores two important metrics: latency, and packet loss. As you can see from the picture below, three latency values are shown: Minimum, Average, and Maximum latency.
Using these three values, the technician can easily figure out the following:
- Minimum value is the lowest/best latency (5ms from this pic) that NetPath measured during the monitoring interval. The value could be since the NetPath was configured OR in the last 30-day period, whichever is smaller.
- Maximum value indicates the highest/worst latency (18ms from this pic) that NetPath measured during the monitoring interval.
- Average value, as it says is the average latency value (10ms from this pic)
- How good/bad the latency has been by looking at the range (min to max value); now the technician can get an idea about the quality of that network segment/path
Packet loss is shown as a percentage. Depending on the types of connection (TCP sessions vs best effort UDP), a low-packet loss may be tolerable. Both these important metrics provide the required data either to troubleshoot the problem itself or to talk to the ISP.
There are a few other interesting pieces of information that can be gleaned from the graphic. In NetPath, hovering the mouse over any of the links (lines) activates a popup window that shows the Transit Likelihood metric. This indicates the percentage of the traffic that transited that link. Any value less than 100% implies that there were other paths through which the traffic flowed. Combining with packet loss and latency, the technician gets a fuller picture of the health of that network segment.
The bottom of the NetPath window shows the histogram of latency and packet loss over time. You can visually understand the behavior of these KPIs over time and help make better decisions. NetPath is truly the ECG for your network.
Bottomline: NetPath saves you time and money by actively monitoring your important resources and shortening your troubleshooting time.
3. How do I check whether Wi-Fi is responsible for the slowdown in application-response time?
We have all heard so many times the refrain, “The network is very slow today.” In reality, this “slowness” can be due to multiple reasons—the end-user’s device, the network (connectivity, latency, packet loss), or the application itself. Either way, it is always the network that gets blamed. In a way, the network is guilty until proven innocent. So, you as the MSP have to prove the network’s innocence or complicity.
With BYOD and Wi-Fi as first hop connectivity becoming ubiquitous, the need to identify, isolate, and resolve Wi-Fi bandwidth problems becomes critical. NetPath can help to figure out whether the Wi-Fi device (AP, WLC) is responsible for the slow network about which your client complained. With NetPath, you can understand latency on a per-hop basis. So solving this problem is very easy—just hover over the corresponding link to get the latency metric. Or, click on the link or the bubble to get to the latency and packet loss histogram. It’s that easy.