Re: Pinging a Device Every Second

[Baldur Norddahl <baldur.norddahl () gmail com>]

You could configure BFD to send out a SNMP alert when three packets have
been missed on a 50 ms cycle. Or instantly if the interface charges state
to down. This way you would know that they are down within 150 ms.

BFD is the hardware solution. A Linux box that has to ping 1000 addresses
per second will be very taxed and likely unable to do that in a stable way.
You will have seconds where it fails to do them all followed by seconds
where it attempts to do them more than once. The result is that the
statistics gathered is worthless. If you do something like this, it is much
better to have a less ambitious 1 minute cycle.

Take a look at Smokeping. If you want a graph to show the quality of the
line, Smokeping makes some very good graphs for that.

Regards
Baldur

15. dec. 2018 16.49 skrev "Colton Conor" <colton.conor () gmail com>:

How much compute and network resources does it take for a NMS to:

1. ICMP ping a device every second
2. Record these results.
3. Report an alarm after so many seconds of missed pings.

We are looking for a system to in near real-time monitor if an end
customers router is up or down. SNMP I assume would be too resource
intensive, so ICMP pings seem like the only logical solution.

The question is once a second pings too polling on an NMS and a consumer
grade router? Does it take much network bandwidth and CPU resources from
both the NMS and CPE side?

Lets say this is for a 1,000 customer ISP.