Netwatch false DOWN/UP events on RouterOS 7.21.2 (PPPoE links)
Hello everyone,
I would like to report a set of anomalies I am experiencing with Netwatch after upgrading to RouterOS 7.21.2. These issues are reproducible and occur even on clean configurations.
Summary of the problem
After updating to RouterOS 7.21.2, Netwatch began generating false DOWN and UP events, even though the monitored hosts are fully reachable and stable when tested manually via terminal using continuous ping.
This behavior did not occur on previous versions (7.19 / 7.20.x).
Environment
• RouterOS: 7.21.2
• Interfaces: PPPoE clients
• Monitoring type: ICMP
• Hosts tested:• Public IPs (8.8.8.8, 1.1.1.1)
• PPPoE gateway addresses
• Packet loss: 0% when tested manually via /ping
• CPU usage: low
• No firewall rules affecting ICMP
Symptoms
-
Netwatch logs DOWN events even when the host is reachable.
Manual ping from two different terminals shows zero packet loss. -
Netwatch logs UP events immediately after, creating flapping, even though the link never actually went down.
-
The issue occurs regardless of Netwatch configuration:• Packet Interval (0.1s → 1s)
• Packet Count (3 → 5)
• Timeout (1s → 3s)
• Early Success/Failure Detection ON/OFF
• Thr. Loss Percent adjustments
• Different hosts (public DNS, PPPoE gateway, etc.) -
The problem persists even with very conservative settings:• Interval: 10s
• Timeout: 2s
• Packet Count: 5
• Packet Interval: 1s
• Early Detection disabled -
The issue affects only Netwatch.
The standard /ping tool works perfectly and does not show any loss or jitter.
Additional observations
• The issue seems more noticeable on PPPoE interfaces.
• It appears that Netwatch’s internal ICMP engine behaves differently from the normal /ping tool.
• During PPPoE IPCP renegotiation, Netwatch may briefly stop sending probes, even though the link remains operational.
• Some users have reported similar behavior on 7.21.x, suggesting a regression in Netwatch’s timing or ICMP handling.
Impact
This behavior causes:
• False failover triggers
• Incorrect routing changes
• Unnecessary logs and alerts
• Instability in multi‑WAN environments
Because of this, Netwatch becomes unreliable for link monitoring on 7.21.2.
Temporary workaround
I replaced Netwatch with a custom script + scheduler using the standard /ping tool, which works reliably and does not produce false positives.
However, this is only a workaround — Netwatch should not behave this way.
Request
Could MikroTik please:
- Confirm whether this is a known issue in 7.21.2
- Investigate the Netwatch ICMP engine behavior
- Check timing, packet scheduling, and PPPoE interaction
- Provide guidance or a fix in an upcoming release
Netwatch is widely used for failover and link monitoring, so this regression has a significant operational impact.
Thank you.