MikroTik field tools · Routing expertise · free · in-browser
The MikroTik forum keeps asking the same failover question. The gateway pings fine, the internet behind it is dead, and failover never fires. That happens because check-gateway=ping only checks the ISP's own gateway, and the gateway is still up. This simulator runs both checks against the same failures, side by side. Pick the upstream failure and watch the basic probe get fooled. The recursive probe, pinned past the gateway with a scope/target-scope pair, catches the dead upstream and pulls the route. Send it to whoever runs the router before the day the backup has to carry the load.
Pick a failure and watch which probe notices — the plain check-gateway ping at the ISP's edge, or the recursive probe out past it.
check-gateway=ping only tests the route's own gateway — the ISP's edge. If the ISP's link to you is fine but their own uplink to the internet is dead, their gateway keeps answering pings and RouterOS has no reason to pull the route. The internet is unreachable and failover never fires, because nothing asked past the gateway.
Add a /32 route to a real internet host through each ISP's gateway, with scope=10 — one anchor per uplink. The anchor does two jobs: it gives the recursive route something to resolve through, and it pins each probe to its own uplink — traffic to that host leaves through the gateway you named, so a reply proves that link, not whichever one happens to be active.
The default route's gateway becomes the probe host address, not the ISP gateway directly, with target-scope set to accept the anchor: target-scope must be at least the anchor's scope for the recursive lookup to resolve. check-gateway=ping goes on this route too — now it's watching the probe host, not the ISP's edge.
Give the primary uplink's recursive default route the lower distance and the backup the higher one. Distance only decides which active route wins when both are up — recursion plus check-gateway is the separate mechanism that decides whether a route counts as active in the first place.
By default RouterOS pings the checked gateway on a fixed interval and marks it unreachable after two missed replies in a row; the route goes inactive, and one good reply resets the count. The same rule governs a recursive route — it just pings the probe host instead of a directly attached gateway.
Pulling the WAN cable only proves the failover a basic check-gateway already catches — a dead link. To prove the recursive setup earns its keep, break the path beyond the gateway instead: make that uplink's probe host stop answering while the gateway itself still replies — the exact case a plain ping check misses. Then judge it with a fresh connection: NAT is decided on a connection's first packet, so a ping that was already running keeps its old translation and can fail even after the route has moved.
If check-gateway only watches the ISP's own gateway and that gateway still answers, RouterOS has no signal that anything is wrong. The route stays active and failover never fires. This is the failure the simulator's upstream scenario plays. The fix is a recursive check that probes a real internet host past the gateway.
Only the address in the route's gateway field — on a basic route, the ISP's own router one hop away — checked by ARP, ICMP ping, or an active BFD session. It never looks past that address; whatever sits behind it is invisible to the check. Recursive failover works by putting a host far out on the internet into that gateway field instead.
A route whose gateway isn't directly connected to the router, so RouterOS resolves it through another route in the table instead — a lookup governed by scope and target-scope. For failover, that means the route being checked can point at a host out on the internet rather than at the ISP's own doorstep.
By default: one ping every 10 seconds, up to 1 second for the reply, and two misses in a row before the gateway is marked unreachable and the route goes inactive — one good reply resets the count. Since RouterOS 7.21 all three values live in /routing/settings and can be tuned; they apply to every check-gateway=ping route, recursive or not. The simulator runs the same two-miss count, sped up so you can watch it.
A route's scope is the value it offers when it acts as someone else's next-hop; its target-scope is the ceiling it sets on which scope values it will accept when resolving its own gateway. A recursive default route only resolves through an anchor if the anchor's scope is at or below that route's target-scope.
Because an unpinned probe host has no route of its own. Traffic to it follows whatever route the router already prefers, so a check meant for the backup link can ride the primary and prove nothing. A /32 anchor per uplink forces each probe down the link it's meant to test. Choose a host that should always be reachable and answers ping; MikroTik's own example uses public DNS resolvers. Don't use that address for anything else, such as the router's own DNS, because the /32 ties it to one uplink and it goes dark whenever that uplink's upstream fails.
They do different jobs. Distance only sets preference between routes that are both active, and the lower one wins. Recursion plus check-gateway decides whether a route counts as active at all.
Yes. As soon as check-gateway gets a reply again — from the gateway, or from the probe host on a recursive route — the route is marked reachable and, carrying the lower distance, becomes active again on its own. No manual switch-back; the simulator's Recovery scenario plays exactly this.
No, that's the correct outcome, and this simulator has a scenario for it: the backup route wasn't carrying anything, so its own check-gateway failure just marks that one standby route inactive. The primary keeps working untouched — there's nothing to reroute because nothing was using the backup path. It's still worth an alert: until the backup is back, the next primary failure has nowhere to go.
This simulator also runs on the routing expertise page. It has a page of its own here so you can send someone a link to the failover alone. Read Routing that stays up when an ISP dies.
Bring me the failover that never firesAlso on the bench: RouterBOARD reset simulator, Visual subnet calculator, Interactive packet-flow diagram, Diffie-Hellman key-exchange visualizer