cancel
Showing results for 
Search instead for 
Did you mean: 
Create Post

ability to use ICMP Echo for Netpath services

ability to use ICMP Echo for Netpath services

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.

29 Comments
Level 10

Please, please, please.

Level 8

Yes please add ping and trace route

cobrien​ is there a way to do this?

Level 15

Not today.

Is it contrary to the intent of netpath or just something that's not available? Just curious, if you're able to elaborate.

Level 15

It's contrary to initial intent because as soon as we use ICMP, the performance and even the path may be different than the application receives.  In practice, path is not frequently different but performance is.  It also encourages making paths destined to transit nodes like a router rather than to an endpoint like an app server.  There is plenty of tech to test performance to infrastructure.  NetPath is trying to test performance to applications, then map it back to infrastructure.

All that said, this FR has quite a few votes for such a recently released feature and the Dev team keeps talking to me about ICMP.

What nodes are you guys wanting to add as ICMP nodes?  Why don't they respond to a single TCP port?

cobrien in my case I'm doing netpath directly to our MPLS provider's SIP trunk. They discard all non-stop/non ICMP traffic at the final hop. I can provide screenshots if you want via email. Honestly netpath is new and so everyone's understanding of both the goal and the function are probably still subject to evolve further.

I also have an application that redirects at the final hop (app server) yet netpath isn't catching said redirect at the end. Just unreachable node.

VNQM doesn't do anything to quantify SIP status currently but actually this is used to tell us both if the gateway is up and if the SIP trunk itself is responding as we have to reach the gateway to reach the trunk​.

That being said, netpath is immensely useful and is great even for handling things like NAT mid-path. I'm also VERY appreciative of the JSON handling it behind the scenes.

Level 12

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

Level 7

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.