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.
4. How do I check the performance of dual-homed paths: Internet vs MPLS/Leased line?
Depending on the size of your client’s network and business need, some might opt for a dedicated private WAN using MPLS or leased lines. These private WANs, especially the ones based on MPLS circuits, are very expensive, running into the hundreds of dollars per megabit per month. While these prices are shrinking as Internet connections get cheaper and more reliable, there is still a need for MSPs to evaluate the need for such expensive circuits and eventually justify their removal. NetPath helps you provide that justification.
Using NetPath enables you to analyze a path as a whole or as individual hops and devices. To analyze an entire path, the history panel at the bottom of the NetPath window (see below) provides you all the data needed to make the decision.
For example, you can see how the path has behaved from a latency and packet loss perspective at a granular level (probing interval of 5 mins to 1,440 mins). You can analyze not only for the past hour or past 24 hours, but for an entire 30-day period. Armed with this data, you can understand the reliability of the critical paths and make the right decisions.
5. How do I check the performance of a load-balancer in my network/datacenter?
By creating a network path that traverses a load balancer (LB), you can understand its behavior. By hovering over the multiple links emanating from the LB, and observing the Transit Likelihood’ metric, you can quickly understand the performance and fine tune it if necessary.
These were just the top five questions that we have heard from our customers. NetPath is a highly flexible network path monitoring tool that can deal with a broad range of network path monitoring use cases; if you have specific questions our sales engineers can help you configure NetPath to support your own requirements.
Getting started with NetPath is simple and can be done directly from your RMM/N-central dashboard. NetPath is accessible via the left panel on both N-central and RMM dashboards (see below).
Getting started with NetPath is simple and can be done directly from your RMM/N-central® dashboard. NetPath is accessible via the left panel on both N-central and RMM dashboards. (see the pic below)
Vittal Krishnamurthy is senior product marketing manager, SolarWinds MSP