Netwatch icmp incoherent status

RouterOS General
1

I have enabled Netwatch icmp using this command on routerOS 7.8:

/tool netwatch add disabled=no host=10.100.24.24 interval=2h10m10s type=icmp

the ip 10.100.24.24 is online, I can ping it with success:

[admin@ServerMK-03] /tool> ping 10.100.24.24
  SEQ HOST                                     SIZE TTL TIME       STATUS                                                                      
    0 10.100.24.24                               56  64 72ms305us 
    1 10.100.24.24                               56  64 72ms550us 
    2 10.100.24.24                               56  64 72ms739us 
    3 10.100.24.24                               56  64 72ms717us 
    4 10.100.24.24                               56  64 72ms490us 
    sent=5 received=5 packet-loss=0% min-rtt=72ms305us avg-rtt=72ms560us max-rtt=72ms739us

but sometimes I got the netwatch status ‘down’ and the strange (for my understanding) situation in image1 (with response count = 10, but status = down)
image1.png
image2.png
I’m missing something obvious?

LP

Secondary WAN and failover setup hap ax2 (7.16) for a beginner
Netwatch icmp problem
2

Perhaps because the last check is too long ago? Why is your check interval more than two hours?

3

Or the default values for the ICMP check are getting applied. And one of the RTT check is exceeding a “hidden” default. Didn’t test but one idea.

e.g.

ICMP probe options
packet-interval (Default: 50ms) The time between ICMP-request packet send
packet-count (Default: 10) Total count of ICMP packets to send out within a single test
packet-size (Default: 54 (IPv4) or 54 (IPv6)) The total size of the IP ICMP packet
thr-rtt-max (Default: 1s) Fail threshold for rtt-max (a value above thr-max is a probe fail)
thr-rtt-avg (Default: 100ms) Fail threshold for rtt-avg
thr-rtt-stdev (Default: 250ms) Fail threshold for rtt-stdev
thr-rtt-jitter (Default: 1s) Fail threshold for rtt-jitter
thr-loss-percent (Default: 85.0%) Fail threshold for loss-percent
thr-loss-count (Default: 4294967295(max)) Fail threshold for loss-count

AND, at 154ms for rtt-avg … that bigger than the 100ms default. So it should fail – although initially confusing. You can use simple ping check if you don’t care :wink: