NPM - NetPath

Hi to all you Thwackers out there.
I am trying to understand NetPath specifically how to setup probes.

Can I setup a probe on a Cisco router at a site which will then show me the path to say google.com?
Or as I suspect I need to put the probe on a windows machine at the site which will then show me the path to google.com?

If the probe needs to be on a windows machine does NetPath have any impact on it's performance?

I support a Local borough council with quite a few schools and when they report issues I can see in NPM the router and WAN interfaces but sometimes we need more information to troubleshoot issues. We have a WAN provider but no visibility of their network and no real understanding of where or how the traffic travels through our network which makes troubleshooting difficult.

We are looking at purchasing NTA which will help in seeing the types of traffic across the WAN but I would really to get us a better understanding of how and where the traffic routes across..

Find more posts tagged with

poller

npm

nta

Accepted answers

All comments

jm_sysadmin

Today Netpath needs to run from a windows machine with the Agent, but you have one already, your Orion Server.
SolarWinds Orion agent requirements

It self limits how many probes you can assign a server based on the resources (CPU and Ram) the server has, but I have not seen performance impact from running a Netpath probe. It might vary based on the complexity of the paths that get mapped.

mestasew

To share my experience, my attempt to create a secondary probe failed- I concluded netpath only works from the Orion itself.

I would say the impact on the performance would be minimal since it uses icmp packets to trace route and delay statics. There is real time path monitoring that might impact the performance. Mostly once the network topology and delays info gathered , it can be disabled or removed to avoid load and negative effect on performance.

jm_sysadmin

I currently run Netpaths from all 6 of my polling engines (3 active and 3 on my passive HA nodes) and 2 non-Orion windows servers. Additional probes shouldn't be an issue.

mestasew

Now I was able to use my standby HA as probe. thanks for clarifying and sharing.

what do you think about the port option? I am not clear if we used known port like 161 or 22 , netpath will test reachability via that port.

neomatrix1217

Take a look at this KB below as what port see below basically any open TCP Port.

A service is the destination to which you are mapping. It represents an application, and SolarWinds recommends deploying a service for the most important applications that your users rely on. This can be any TCP-based network service, such as salesforce.com, Microsoft Exchange, Office365, or a file server.

NetPath requirements for NPM (solarwinds.com)

xtraspecialj

To be able to run network tests originating on something like a Cisco router or switch, you'd have to use something like IPSLA. Cisco's IOS doesn't really allow third party apps/agents to be installed on it, does it? I've never heard of something like that at least. But like I said, you could use SolarWinds VNQM product that is able to setup and monitor IPSLA tests from/to cisco devices.

cnorborg

Can you set up a probe on a Cisco router? No

Yes, you would need to put the probe on a windows machine at the site.

Yes, it does have an impact on performance, but a single probe won't have a significant impact. I think each windows box can have about 20 probes on it. The way Netpath works is it sends out 100 probes for each step in the path, by incrementing the TTL of the packet, and see's who responds. So, if the packet goes 25 hops, there will be 2500 probes sent out! You can't adjust how many probes it does, but you can change how often it probes, with the default being 10 minutes. If you want to reduce the impact on the system, and don't care how up to date the info is, reduce the frequency that it does the probes.

NTA will give you great insight as to what traffic is going where. Once enabled for a box, you'll be able to see what traffic is going where, such as source IP, dest IP, type of traffic, QoS markings, what interface it transits across, etc. etc. Much better than knowing raw bytes transiting an interface.