rmatejka ✭✭✭✭

What about tracetcp? Same behavior? In either case, it may be easier to open a ticked with support so we can try to get the necessary traces to better determine what's going on. Rick

It is definitely needed - even listed in the requirements: NetPath requirements

Laurin, Try clicking the connections - you should see additional statistics:

Is there any way to check the log so the Sonicwall to verify that it is not dropping the traffic?

OK but what about inbound rules? NetPath as well as TraceTCP require ICMP Type 11 responses.

What about inbound traffic on the Sonicwall - anything that would prevent ICMP responses from coming back? Or anything that would drop packets that it considers have "suspicious" TTLs?

Best option is to open a ticket with support so we can work more closely with you to diagnose the problem. Rick

Laurin, OK the node is in a warning state because of the ingress an egress connections so you need to select those to see what is listed as the cause - most likely packet loss since I see that showing up on the node already. If you find that you are getting a false-positive, you may want to adjust the packet loss & latency…

Your welcome, glad I could help. Rick

As sum_giais mentioned above, NetPath does not use ICMP like traceroute but instead tries to mimic application-level traffic to get a better picture of how real traffic is behaving. Do you have any other devices downstream that could be restricting the traffic? Rick

Sure: LICENSE PLUGINS * * * * * Rick

Is there a separate setting in your firewall for ICMP traffic? In order for NetPath or tracetcp to work, the polling machine needs to be able to receive the ICMP type 11 - Time Exceeded message.

It exports the data necessary to rebuild the graph on this end. But a screenshot may suffice.

Well it is also possible that it's simply due to drift in the polling start time and how we display the completed runs on the timeline. In some cases, it may be that there were no complete runs during that period since the start time was off by a few minutes. Maybe lanli.fsm​ can provide a better explanation when he gets a…

For NetPath functionality, the eval is identical to the release version in all ways. Since you are on eval, please verify the license has not expired as that will cause this exact behavior. Also when you are adding the new services, are they on a remote agent or the local "default" poller?

Also please confirm that you are on the release version of NPM and not an alpha release. Thanks, Rick

If possible can you export the graph and upload it here?

NetPath does not use ICMP because of the accuracy issues. It uses TCP in a manner that is similar to the way an actual application would respond. Rick Matejka

Can you see what TraceTCP shows? tracetcp Rick

NetPath_50014 is unrelated to BGP. That has to do with NTA data and appeas to be a bug. WOudl you please open up a trouble ticket? Thanks, Rick

Greg, Unfortunately this will require more analysis. Can you enter a ticket with support so we can look into the issue in more detail? Thanks, Rick

That could be an indication that your probing interval is too short. If you add ?debug to the end of the URL and then click the TESTS tab at the bottom of the page, the Ratio column provides an indication of how many paths are being discovered. If it is below say 90%, try making the Polling Interval longer to allow more…

One of the other NetPath developers has seen this issue as well . His suggestion is to run route delete 0.0.0.0. More details: Most articles talk about Bonjour service causing this and beside removal of route, they suggest to remove service. One guide here: Illustrated guide http://www.petenetlive.com/KB/Article/0000332…

Well the wording may be a bit misleading. I have 23 paths currently and mine says (23 of 20 paths assigned). I just added a 24th :-)

The polling interval change is only done for the default google service that is auto-created. After 24 hours, the polling interval is reduced to 12 hours. If this is an evaluation version, can you verify that your license is still valid? Also are you using a remote agent or the local agent? Admin > Agent Settings > Manage…

Unfortunately then it seems something on your internal network is blocking or altering the probes. I know some firewalls can be configured to block certain TTL values. Rick

Thanks, I'll see that we get that added as a feature request. For now you can see if any of the data in the debug screen could be used. Just as ?debug to the end of the url and see the bottom of the page below the timeline. You should be able to copy/paste the data into an email. Rick

Thanks, never can be too secure :-) OK how many timeout hops in the node between the endpoint and the first VRF? Thanks, Rick

We are currently looking into the packet loss issues that are occurring within certain environments. Rick Matejka

Yes unfortunately proxies effectively prevent probing of the actual path.