Started getting a down indication on an icmp ping to a remote subnet.
Confirmed the node was not down.
Pinged directly from the machine that hosts the probe.
Pinged with packets of varying sizes.
Pinged at different rates.
No failed pings.
Tried multiple times rechecking/pausing/unpausing etc.
The sensor did eventually clear itself after about 15 minutes.
This did not coincide with any outage or know network disruption.
The prtg system is running on a server 08 64 r2 instance under vmware with about half it's 4 gig ram free, cpu load never goes above 10% - there is plenty of bandwidth.
An occasional false positive isn't the end of the world - prtg is just an indicator after all - any actions should be predicated on an inspection after receiving the alert.
Still, I am wondering why a simple ping would fail like that.
Article Comments
I have this same issue that has continually gotten worse! We can ping successfully outside of PRTG from the server running PRTG. BUT PRTG app reports down false-positives for numerous PING sensors. I have tried increasing the PING timeout from 2sec to 5sec and the problem still happens in PRTG.
We are very frustrated with PRTG support for no phone or remote session support.
Mar, 2014 - Permalink
If you are having issues with your ping sensors failing, then it could also be that the probe is overloaded. We are taking a look at the logs that you sent over with the developers currently and will try to answer you as quickly as we can.
Mar, 2014 - Permalink
Hi PRTG
I am having the same issue for my sensor. When the remote PRTG server always have a ping error while the local does not have this issue. Can you suggest a solution? Thank You
Feb, 2022 - Permalink
Hello there,
PRTG uses the Windows API to query the ICMP scans. If these does not work, I highly recommend to log on the Remote Probe Host and try to ping the exact same device which is configured in PRTG from CMD.
This needs to work in order to also send the ICMP requests via our PRTG Network Monitor.
One more thing which you can confirm is the correct "Outgoing Interface". Log on the Remote Probe machine again and open the PRTG Administrator Tool to confirm that the probe is using the interface connected to the remote endpoint / network.
Kind regards,
Felix Saure, Tech Support Team
Feb, 2022 - Permalink
The first thing that I would do to make sure that this isn't just one freak packet getting lost would be to change this to perform a multiple ping and increase the timeout and scanning interval.
If you are still having issues, it could be that the probe is not handling the request correctly which could simply be that it needs to be restarted. If that does not handle the problem, I would check with Wireshark whether the pings are being sent and received by the probe.
If that all looks like normal traffic, I would try recreating the sensor and device if needed.
Nov, 2013 - Permalink