This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

NetPath data validation?

NetPath is an awesome powerful tool that gives great insight into where packet loss and latency issues reside. 

There is one kind of big problem with it being a unique tool.  There is no "traditional" network troubleshooting tool (that I'm aware of at least) that can duplicate the data it's showing as there's really nothing like it out there.

Based on the awesome presentation that cobrien​ gave at the Chicago SWUG on NetPath, it's my understanding that ping and traceroute don't take the same path as "normal" data packets and therefore aren't accurate indicators of network traffic.  Also add in the fact that ICMP traffic is normally given a lower priority over data.  NetPath gets around this by simulating "data" traffic to the destination address and on the port that you define.  I trust in NetPath but, the "old-timers" who've been using ping and traceroute for years to troubleshoot are harder to convince.

So, how can I show hard data to prove that what NetPath is showing is accurate?  Is there a more widely accepted network troubleshooting tool? Some magic Cisco IOS command I'm not aware of? Is perhaps NetPath way ahead of the game and we just have to go with it?

  • Hi

    Netpath is a good for visual path to aservice that running on TCP only ..

    Netpath agent is a windows only ...

    Those 2 things (no UDP /open agent) make it much less attractive for me...

    Cisco shop will utilize Netpath with IPSLA.

    Juniper shop RPM + what ever we can get...

    The next generaion is that

    Network telemetry and automation

  • I think the best thing you can do is to have the "old timers" go to http://lab.solarwinds.com and watch "#45 Hacking the Internet with NetPath". Just understanding the multipath nature of the Internet should be enough to make anyone question traceroute's overall value as a troubleshooting tool. If they've ever actually reached someone in a major carrier's NOC and basically been blown off after submitting traceroute data, watching that video will go a long way to explaining why.

    Jay

  • I guess I am an "Old Timer", and I am not yet trusting what I am seeing with NetPath. I used to use a tool called "PathView" from AppNeta that, at least to me, gave much more concrete and actionable information.