Netpath result different from traceroute

ecurrie1483

Hi Folks, I'm just a newbie to Solarwinds in general and have been starting to setup various components.

One of which is Netpath.

When using it though I am finding the results from it differ in terms of response times compared to traceroute - why would this be ?

i.e.  If I do a traceroute from server 1 to the end device

Server 1

- <1ms

Device 1

- <1ms

Device 2

- <1ms

Device 3

- <1ms

Device 4

- <1ms

Device 5

- 3ms

End point

If I look at NetPath the last hop from Device 5 to the end point shows 195ms

What one is showing the correct response time ?

rschroeder

Let's first be sure you're comparing apples to apples.  Your NetPath data will be sourced from one of your SolarWinds pollers.  Your traceroute data is probably coming from your laptop or PC--unless you've taken care to run the traceroute from the actual SolarWinds server that's hosting the NetPath setup for that destination.  If you're sourcing from two different computers, your hops could easily be different up to the point where the data leaves for the Internet, or where it hits your WAN service provider's network.

NetPath, when properly configured, and when passing through routers and firewalls that are correctly configured to allow all NetPath's ports through them, gives you real data about every hop.  Especially if you are using routing protocols like BGP--it can show you data about every Service Provider's hops, as well as latency between hops that you might not be able to even see with tracert.

Use this link to verify you have the right firewall ports open for NetPath to work.  And also to determine the resource you should allocate for it.

NetPath requirements - SolarWinds Worldwide, LLC. Help and Support

NetPath also gives you historical information about latency changes and routing changes.  Hops can change without anyone notifying you, and even on the occasions when the hop COUNT remains the same, latency between service providers may change dramatically.  Troubleshooting that with traditional tracert is inconvenient at best, and impossible at worst.

I had to install a small VPN router INSIDE another corporation's network, behind their firewall, to allow a remote set of staff to access my company's data.  This was inconvenient in that it required the remote corporation's firewall team to allow me to tunnel my VPN in through their firewall to my local firewall inside their building.  But it worked.

Later, when my team inside that remote corporation's building began experiencing network slowness and even complete loss of service, I was at a loss to discover the problem with the resources I had available--traceroute and version 11 NPM with the comparable versions of NCM and NTA.

But right around that time NetPath was released, and when I pointed it at my remote VPN router I could suddenly see the interaction of all the ISPs and their routers and my equipment.  I could click on any given provider and see all their BGP hops inside their service ring, and discover where they touched the next provider's network.

And right in that graphic was the combined latency from each provider, and the latency between each provider.  Down below I could track the connectivity by date and time period through them all.

Opening up "yellow" sections in the bottom timeline it was easy to see the problem.  If my home site is "Site A", and my remote VPN router inside that other corporation is "Site F", I had ISP's and intermediary Service Providers B, C, D, and E.  And between 10 a.m. and 4 p.m. the latency at the point where Provider C's network joined Provider D's network jumped from 40 ms to 250 ms and higher.

Opening up NetPath's views of each of those providers' internal BGP hops enabled me to drill into the data, see which routers were the problem, and then alert my ISP to the issue.  I shared with them the NetPath timeline and the NetPath graphics showing all the hops & latency, and I highlighted where the latency got so high my remote users' apps were failing. 

My ISP reached out to Providers C and D and shared my NetPath data with them.  The problem was quickly showing to be Provider D was oversubscribing their pipe to Provider C--by a factor of three!.  And due to the contract between them there was no correction provisioned--users were expected to accept loss of service during peak hours based on the low fees they were paying.

Unacceptable!  It was easy to arrange path changes that bypassed Provider D's link to Provider C, and just that quickly my users were back in business.

The sad parts:

• I'd had no way to see and prove and track the problem granularly enough to get a direction for remediation--until I got NetPath installed and configured.
• Provider D was not interested in keeping the business from Provider C.
• None of the providers had any monitoring going that alerted them to the problem, nor did they have a method of informing customers of the cause and impact.

Yes, NetPath will show you more than Traceroute--because it's designed to.  It'll show you:

• Physical hops
• Changes in hops
• Changes in latency
• Details inside ISP and intermediary providers' networks
• Timelines of normal traffic, problem traffic, and outages
• Hops, their changes, and latency changes over historical periods, depending on how you set it up and how much space you allocate to storing that data.

My earlier write-up of this could be one reason why fun toys like these show up on occasion:

Here's a helpful link comparing NetPath and Traceroute:  https://www.networkmanagementsoftware.com/solarwinds-netpath-vs-traceroute-the-power-of-visualizing-networks/

I'm very happy with NetPath!