Netwatch is the simplest tool in RouterOS: it pings an address at a fixed interval and keeps track of whether the answer comes back. When that state changes it runs a piece of script. One line when the host goes down, one line when it returns.
Where it sits
In advanced mode, in the part called High availability (VRRP, Netwatch), below the VRRP table. The part is off by default and has no wizard step.
The fields
- Host
- The address you watch. Pick something that actually tells you anything: your provider's gateway, a public resolver, or the device at the far end of a tunnel. An address that drops out regularly for innocent reasons only produces noise.
- Interval
- How often it pings, every 30 seconds by default. Shorter reacts faster and costs more; shorter also makes it more likely that a single lost packet fires an action.
- Script on down
- What happens the moment the host stops answering. One line of RouterOS script, for example
/log warning "WAN down". - Script on up
- What happens when it answers again. Usually the counterpart of the previous one: a log line, a notification, or undoing whatever you switched on at down.
What the configurator writes
One /tool netwatch entry per row, with your host, your interval, timeout=1s, type=icmp, and your down and up scripts if you filled them in. The timeout and the type are fixed: the tool always writes an ICMP check. RouterOS 7 also has checks on a TCP port or an HTTP response, but you add those on the device yourself.
The script fields are a single line. If you need more than that, put the content in a script of its own under Services and tools and call it here with /system script run name. That also reads better later than a two hundred character line.
What it is good for
- Recording that something happened. A
/log warningon down and on up gives you two timestamps afterwards. If you send your log to a syslog server they end up there as well. See System and time. - Sending an e-mail. With e-mail configured under Services and tools you can call
/tool e-mail sendon down. Mind the trap: mail over the line that has just gone down does not arrive. This works for watching something inside your network, not for your own internet connection. - Switching something over. Enabling or disabling a route, a rule or an interface. It works, and it is also how people get into trouble: a script that changes your configuration on a false alarm does so at four in the morning as well.
What not to use it for
Failover between two internet lines. It looks like the obvious application, but RouterOS has better means. Under Multiple uplinks you set route distances and a gateway check, and the routing table handles it itself, faster and without scripts that can get stuck. Netwatch is at most the addition that writes it to the log.
Rebooting the router when something stops responding. That is what the watchdog in the System part is for: you give it an address and RouterOS reboots itself when that stays unreachable for too long. One setting instead of a script. See System and time.
Where a proper monitoring system is the better answer
Netwatch is a switch, not monitoring. The limits are not subtle:
- There is no history. You see the current state and whatever you logged yourself. No graph of last month, no availability figure.
- There is no alerting. No escalation, no on-call rota, no confirmation that someone is looking at it.
- The router cannot report itself. If the device is down, netwatch is down with it. A device that is silent is silent in exactly the same way as a device with nothing wrong.
- It only looks at reachability. A line that answers but drops 40 percent of packets is fine as far as netwatch is concerned.
As soon as you manage more than a couple of devices, the watching belongs outside the router. The configurator helps with two things under Services and tools: SNMP, so a monitoring system can read the router and you do get graphs and history, and NetFlow if you want to see what is passing through. And in the System part you point logging at a syslog server, so your messages land somewhere that survives a reboot.
The sensible division of labour is usually this: the monitoring system watches your network from the outside, and netwatch does the one small trick inside the router that can only be done there.
Checking
/tool netwatch printshows the status per host and when it last changed.- A script that does not seem to run is usually a permissions problem or a typo. Test the line by hand in the terminal first.
- If netwatch sees a host as down while you can ping it yourself, check that ICMP to that address is not being dropped somewhere in your own firewall.
If your down script uses a feature device-mode can block, such as fetch or e-mail, that script silently does nothing. Check with /system/device-mode/print.
Further reading: Services and tools, VRRP and Troubleshooting.