Netwatch, IPv4 and interface

RouterOS General
1

Hi,

Could you tell me why the following does not work ?
/tool/netwatch/add host=8.8.8.8%myInterface

Returning the following ?
failure: IPv6 link-local address and interface must both be specified

/ping 8.8.8.8%myInterface does work.
So I don't understand why Netwatch would not allow such a destination.

User manual seems to not allow this, but I can't see why.

Thank you very much !

2

8.8.8.8 is IPv4 IP and as already present on examples, can't be specified the interface on IPv4.
And if the syntax work on another position, do not matter at all.

3

But Is It some kind of impossible thing (for whatever reason) or a missing/forgotten feature?

It would be "logic" and "symmetric" that what works in IPv6 works also in IPv4.

Maybe It could be the object of a feature request?

4

It's not a "what works for ipv6 doesn't work for ipv4" situation. The %interface is only accepted for ipv6 link-local addresses, because that is the only correct form for them. There is no corresponding thing in ipv4.

Rather, the question may be if netwatch should support the "through this interface" feature that ping does. This is valid, but it's more a suggestion for a possible new feature.

5

Yep, reworded, having the possibility to force netwatch to ping through a given interface would be (IMHO) nice.
And It could have practical uses.
Right now we need in a failover setup with recursive a narrow (/32) route, but also for netwatch It Is convenient to use one.
This implies that you need different canary addresses, one for each ISP/connection.
Having the possibility of directing netwatch to go through a given interface might allow to re-use a single canary for all ISP's and get rid of the narrow routes.

6

Support for %interface is a must for IPv6 link-local destinations (fe80:xxxx) because the router most probably has more than one interface.

But for IPv4, it's only useful if:

  • Either the interface is a point-to-point interface (for example PPPoE or WireGuard).
  • Or the address to be reached is part of the connected subnet of that interface (like reaching 192.168.2.5 with 192.168.2.0/24 being the subnet on the interface).
  • Or the gateway attached to that interface implements some sort of Proxy-ARP.

Otherwise, for example if the WAN connection needs something like gateway=192.168.1.254%ether10, then specifying 8.8.8.8%ether10 will not help you reach the destination with :ping if the route with gateway=192.168.1.254 is not currently the active route.

For Netwatch it would be much better if a gateway option is supported instead (you can then use gateway=myInterface too if you want for connected addresses or P2P interfaces).

7

Yes, that would be better (and also easier to the eye) :slightly_smiling_face:

For what it matters (for Netwatch and "normal" interfaces) there could be (in my perverted mind) an automatic (temporary) narrow route created on the fly.

Only thinking aloud :astonished_face: but you have (say) 8.8.8.8 chosen as canary.
In Netwatch you have (say):
Standard Route 0.0.0.0/0 set to 192.168.1.250 with Distance 1 comment=ISP3 disabled (ether3)
Standard Route 0.0.0.0/0 set to 192.168.1.249 with Distance 1 comment=ISP2 disabled (ether2)
Standard Route 0.0.0.0/0 set to 192.168.1.248 with Distance 1 comment=ISP1 enabled (ether1)
No static Narrow routes.

When you have a Netwatch running for host=8.8.8.8%ether1, it is already reachable and nothing happens, when you have one running for host=8.8.8.8%ether2 a temporary route is added 8.8.8.8 set to 192.168.1.249 with Distance 0 is added and immediately removed after netwatch has done the check.