ability to use ICMP Echo for Netpath services

Upvoted

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.

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 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.

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.

cobrien​ exactly, but doing per-hop metrics leading up to the sip gateway was what I wanted to do with netpath. (original goal: actually poll the sip gateway obviously)

Bummer.  ICMP + RUM seem like the best bet then.  And polling the entities that are allowed to partake in that SIP conversation for any metrics they store.

cobrien , the vendor only allows specific IP's which I can't put a netpath probe on to hit their SIP ports. Anything else, ICMP only.

My expectation is for any TCP port to work, including those that use encryption.  443 works, for instance.  You tried 5061 and it did not work?

I think having netpath log into things is probably in the same boat as having netpath do ICMP. We're still asking it to do something it's not designed to do in both instances. In one, sometimes we don't have a choice. If I have a path from A -> B that *only* includes ICMP (read: SIP trunk), I don't have an option of "Another port".  In the other scenario of asking to authenticate via a particular port we do have choices (see: SAM, WPM in some instances) .