As most know, /ip/route supports a “check-gateway” parameter, but’s it limited to the next-hop today. The “recursive routes” technique extends this to any host... BUT it’s awfully complex and still limited to check-gateway’s simplistic/fixed ping algorithm.

But with the expanded netwatch options in V7.6, it be very handy have a new option like check-gateway=netwatch in /ip/route. The idea is there be additional parameter, say netwatch-hosts= that would match a specific host(s) monitored in /tool/netwatch. /ip/routes then follow the up/down stuff for the “linked” netwatch.

This allow for way more sophistication in what’s considered a “failed route”, and the syntax be WAY simpler to enable good route failover. Using netwatch also allow a DNS name to be used as the monitored hosts – that’s not possible in a route table. Now I use the recursive routing in most of our configs but it’s non-trivial to get right and the resulting config equally confusing to understand/explain. Frankly it’s plain awkward to specify the monitored hosts in the route table – but that’s required when using recursive routes.

If any MikroTik support staff are seeing this suggestion, it would be good to have something baked into RouterOS to handle link failure. Don't need to do it in routes, but baked it into netwatch perhaps.

Yeah I'm a bit indifferent myself on approaches. But I wouldn't even know where to start to write your "How to MultiWAN", since there is no simple path through it.

I'm just thinking they have a "check-gateway=ping" setting, so if instead of doing the ping itself, it just lookup the current /tool/netwatch state. e.g. a particular netwatch's up/down state, at time of /ip/route's polling of it, determine route state of.



And Netwatch let you do stuff like fail on latency/jitter – thing you might want to in a "multi WAN" environment as latency may be more important than "pingabilty".



My issue with recursive routing's is the "monitored host" cannot actually be the thing you want to actually monitor – since that's the canary for a particular route's liveness. So some de-coupling of "the things you care are up" (/tool/netwatch) and the "route they take" (/ip/route) should be possible, but isn't – without scripting...
And, while an “on up" or "on down” script can find the route to enable/disable, you need to always keep the route-id in sync. And scripting can be fragile e.g. generally really useful, but no guarantees script valid today will be valid after some update. If a backup doesn't get emailed, no great. But or something critical like route failover at a far away remote site, it be disastrous if the "failover script" broke after an upgrade. Plus you're still left explaining, "when you update a route, don't forget to change the route-id in the netwatch scripts...).

The fun of the router being off line and thus cant inform you its off line LOL.
Too bad IP cloud doesnt have a built in functionality to send you an SMS, hey your internet is down LOL.

Too bad IP cloud doesnt have a built in functionality to send you an SMS, hey your internet is down LOL.

Well issue is I don't want to be "notified it's down", I want it to be "NOT down" in the first place.

Complexity is an enemy of reliability.

HAHA which means 2xHA aka high availability

You need
2 powerful routers (preferably with redundant power supplies)
2 truly independent ISP providers

All of the above on UPS with a backup generator for main power!

WAY before you work about up or down messages...........

Well, I use VRRP in some configs, with recursive routing. e.g. if you have two Mikrtok LTE devices, on different carriers, VRRP is pretty useful technique. This feature would allow more sophistication with LTE since the netwatch jitter useful to select routing with multiple LTE choices – that is, if you didn't have to worry so much about a liveness check.

I assure you the VRRP part isn't the hard part. In fact, VRRP would be on my list of "under utilized features". But it make the routing table quite the mess with recursive routes + VRRP – doubles the interfaces to do stuff with.

All the per-packet and per-connection methods in multi-wan doesn't matter... if it send to an interface that doesn't have internet on it. Why I focus on the "check-gateway" in the Multi-WAN discussions.

Basically LTE goes down more than any Mikrotik hardware fails.

2 powerful routers (preferably with redundant power supplies)

Sure, but for under US$500, two RB5009, using VRRP, gets you pretty far for HA.
Those allow AC and DC, so use both, on both if you perfer.
Plus, even with only one ISP, a router upgrade (or failed config) avoids down-time & keeps any screaming gamers far away.

Anyway, different topic.

But if any ISP goes down in this scheme...that's the weak point IMO.

Basically LTE goes down more than any Mikrotik hardware fails.

Yeah, that is our experience as well.

Btw, OT regading MNOs and HA. In rural areas it's not uncommon that some operators co-locate. In case the backhaul breaks down or there is power outage that linger too long there is unfortunately no advantage using different operators simultaneously since they all will cease to function. Thus if possible different base stations should be used for maximum redundancy but on the countryside this is unfortunately not an option.

Most of the problems we've encountered so far related to the MNO are (as usual) due to failed software updates in the base station and backhaul issues. However, the vast majority of problems we have to deal with on daily basis is on the CPE side.