V7.21.2 [stable] is released!

Announcements
103

What I hate most is when parameter names are changed or structured in different levels than before, the existing config is reworked and the new export shows the new names and values, but the new version does not accept the old structure (and convert it just like it does with existing config).

Because that means that a config that was made for an older version, to be used in netinstall or for a cut/paste config solution, suddenly no longer works. And indeed, there is usually no warning for that in the release notes.

104

The process that does this could also just mark all previous firewall rules as disabled=yes with additions to the comments stating something like “FWRESET: en/dis/abled previously” and then the admin could rework his/her old rules into the mix without completely losing them.

105

For all persons with stranges behaviors : igmp-snooping is enabled or not on your setup ?

107

This is because of this, check if you have duplicated tables called main, i had same for some reason, so at the end no routes are created

  • route - prevent creating routing tables with the same name;
109

Version 7.21.3 has been released:

110

It depends…

On networks that have services that depends on Multicast…
Most common example is TV Multicast. Or Industrial automation networks that depends also on multicast.

Yes! Its recommended to use it.
Specially if you will gonna use IGMP+PIM+OSPF to make L2 Multicast become L3 Multicast, and at the other side, OSPF+PIM+IGMP.

But on scenarios without services that depends on multicast.
In MY point of view, don’t need that…

P.S.: A good example that IGMP is needed:
Enterprise networks with high quality needs on WIFI.
That thing on Apple devices that you do CommandKey+C and you can do CommandKey+V on other devices that will work. That depends directly on Multicast and IGMP.
Some Trading Softwares also depends on Multicast.

111

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

  1. Netwatch logs DOWN events even when the host is reachable.
    Manual ping from two different terminals shows zero packet loss.

  2. Netwatch logs UP events immediately after, creating flapping, even though the link never actually went down.

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

  4. The problem persists even with very conservative settings:• Interval: 10s
    • Timeout: 2s
    • Packet Count: 5
    • Packet Interval: 1s
    • Early Detection disabled

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

  1. Confirm whether this is a known issue in 7.21.2
  2. Investigate the Netwatch ICMP engine behavior
  3. Check timing, packet scheduling, and PPPoE interaction
  4. 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.

112

Of course nothing "resolving" the issue, but with your script you are probably only "plain" pinging, so what happens in netwatch using "simple" (as opposed to "ICMP")?

113

Don’t use netwatch for failover… you can use recursive routing with ping check of several destinations, that is much more reliable and does not require config changes that may result in problems when the router is rebooted in another config than usual.

Aside from that, I run 7.22beta on a router with PPPoE where I use netwatch for monitoring (not failover) and I do not observe this issue.

Edit: well, I use “simple” ping, not “ICMP”.

114

How do you do failover with multi wan IPv6 and public prefixes without netwatch? I came to the conclusion that toggling the advertise flag on lan IPv6 addresses with netwatch is probably the best solution.

115

You mention the "Thr. Loss Percent", but if any of the threshold value are exceeded, you'll get a failure. What sometime confuses folks is their are default values for all of the threshold values. So while you may not be exceeding the loss%, you maybe on latency etc. I don't track netwatches default values, but they very well could have changed from when you first set this up (although I'd say they made them less strict over time, but IDK).

Basically it's probably not netwatch being "broken". More its check values you didn't set explictly (so default thresholds are used)

116

I use NAT to translate IPv6 addresses when the advertised prefix on the LAN is down on the WAN side. Just 2 NAT rules that act only when the outgoing interface does not match the local address.

117

The ICMP probe (actually its settings) is a deeep rabbit hole, and it is under- and mis- documented, JFYI:
Netwatch UP threshold

Netwatch ICMP settings

118

Interesting idea, but I imagine this may cause trouble with dynamically assigned prefixes when the lease expires? I guess you would need to advertise an ULA prefix in parallel to maintain some kind of ipv6 connectivity during longer outages.

I think I'll stay on netwach instead, but thanks for sharing.

119

Well, in my config the two IPv6 prefixes assigned by the two ISPs are static, and I advertise them on the local networks (on some networks I advertise both, on other networks I advertise only one of the two).

I have the usual multi-route-table setup to have policy routing by source address, so traffic gets routed to the correct ISP, but when that ISP is down the fallback route sends it to the other ISP and then the NAT rules intervene to translate the source address (I use a “netmap”).

When your IPv6 addresses are not static, that complicates things, but as you said it would probably be better to have a ULA prefix instead of a dynamically changing address anyway.