Some devices only respond to ping...I use NetPath not just for webservices, but all external devices that connect my network...it builds a better view of my network than any other tool Solarwinds has.
Please, please, please.
Yes please add ping and trace route
cobrien is there a way to do this?
Not today.
It will also be ideal to be able to use UDP Port 161.
I had a Win Win with Port 4880
Before upgrading from SolarWinds Orion v12.0 to v12.1 I need to make sure the Servers were all up to date before a Snapshot was Taken
Unfortunately, this upgrade was delayed due to the recent Global Outbreak of Ransomware in June 2017
Being the ‘Owner’ of the SolarWinds Orion Servers, I was asked check the Antivirus Status and Run an Update if necessary
Not all of the SolarWinds Servers, both Legacy SolarWinds Orion v10.5 and the new SolarWinds Orion v12.0 were up to date and were unable to receive their Antivirus Update form the Antivirus Servers
With the Antivirus Servers IP Address and the Port Number 4880, I was able to provide the NOC and SOC a Screen Shot of the NetPath Services Graph showing the Node that had the Connectivity Issue
Eventually, there was a Systems Guy that took the information that I gave them from NetPath Services Graph and all of the SolarWinds Orion Monitoring Platform Servers are now all up to date with their Antivirus
Wot No Ransomware
I will look forward to your feedback on Port 161
Need this feature, some devices only answer to PING!!!!!!!!!!!!
I'll be brave and cast the lone "nay" vote, per understanding NetPath's intent, via the great explanation from cobrien (see above).
If I want to use ping, I can ping manually or with one of the tools in the Engineer's Toolset.
The same for traceroute.
I love the fact that NetPath, as released currently, does an accurate job displaying and tracking the actual path that an application would take, instead of the path ping and traceroute might take.
The impression I get is that many of us are familiar with ICMP's basics, and with tracert, and we expect NetPath to simply be the graphic display of either. But NetPath is better than either ICMP or traceroute for the simple reasons that ICMP and Traceroute may be denied by firewall rules where an applications port is NOT denied. And ICMP just doesn't transit routers the same way that an application does.
Instead of using ICMP, testing a path via an already-allowed port like TCP 443 or 22 (or whatever port our applications use) lets us test accurately without having to contact intermediary carriers to allow ICMP response, or to allow some other new port to be tracked, or needing some new firewall rule.
Be careful of what you ask for--NetPath was well thought out and well deployed. Adding ICMP as a replacement won't let it be as good a tool as it is today, and it will enable users to dumb it down and receive inaccurate path readings.
If you DO add an option in the future for ICMP, please don't take away the current functionality. ICMP must never replace the present NetPath ability of showing the actual path through routers that an application will take.
It turns out you CAN use port 161 for Netpath flow discovery.
Of course, this doesn't give you the ability to choose UDT or TCP--I assume it's only TCP.
Very wise advice!
It would be nice to have it all in one place without loosing any current functionality. Engineers toolkit is nice but its yet another bit to open.
Can you give us some examples of devices that don't respond to TCP 443 or TCP 22 or any other TCP port, but that DO respond to ICMP?
My thought is that there's nothing I'm aware of (and I'm unaware of LOADS of things!) that you'd want to monitor that operates SOLELY via ICMP. And if a devices uses something BESIDES ICMP, then it probably uses at least one TCP port that NetPath can use. Setting up NetPath to use that port will accomplish whatever anyone would want from a NetPath that can use ICMP.
And the benefit of NOT using ICMP is getting the actual and predicted path of the TCP packet, instead of the varied and inconsistent paths that ICMP may take.
If a path / service / device doesn't ONLY use ICMP, then simply set up NetPath to use whatever TCP ports it CAN use, and you'll get the information you need.
Now, everyone dump on me for my ignorance, and tell me which devices and services and applications ONLY use ICMP. I submit that they all probably also use at least one TCP port, and if so, then NetPath has validity exactly as it's built.
When I saw this I thought it was a reasonable request, however I will also be casting a nay vote. As you mentioned, icmp is blocked at firewalls since it can be used in DOS and DDOS attacks. I allow ICMP in through the firewall to and from specific sources because it is inherit in the applications nature to first ping to see if there is a device then to proceed with it task, like a vulnerability scanner. The only time consuming part is to be able to determine what TCP port a destination has open and listening that will respond to polls from NetPath Services. It takes a lot of trial and error, creating and deleting when I have looked to create this helpful NetPaths.
I understand that ICMP isn't the intended function and using a specific port is how it is supposed to work but what's wrong with giving the option? I don't think anyone is saying to change the feature to ONLY use ICMP but the "nay" responses are almost worded as such (even though I don't think they mean it that way). The questions keeps getting asked of "Why?" but I would turn it around and say "Why not?". Again, choice isn't a bad thing and most people will still use NetPath with it's intended function but sometimes we just want a pretty traceroute. Even a little notice saying that actual data, TCP, etc. won't necessarily follow the same path could be added just so the user/admin is aware.
Yeah I don't understand how anyone would cast a nay vote. It just doesn't make any logical sense. Information is information and can be useful in situations we aren't even aware of yet. There is current situation I have where I suspect ICMP might be de-prioritized by a provider in Uruguay, the only way to verify that in my case is to compare a port 179 Net Path to an ICMP one. If port 179 has no loss but ICMP does at the same hop, that clues me in that ICMP is indeed being de-prioritized. Information is information is information. To say nay on an additional and very useful feature is self limiting to say the least.
I also need this feature, as the endpoint I'm monitoring only supports responding via ICMP. As it stands, I have to monitor as red "down" with limited value as observing the path always in down state.
Upvoted
