How to set up MikroTik failover with recursive routes

Why traditional failover fails on MikroTik

When configuring two internet connections on a router, the ideal scenario is that if the primary provider goes down, traffic automatically switches to the backup link. However, the basic method of simply checking the local modem often fools the administrator. If the physical cable between your MikroTik and the ISP modem remains plugged in, the router assumes the internet is active, even if the provider has lost connection to the rest of the world. To solve this hidden flaw, we need to look beyond the local network and understand how traffic behaves in the wild. If you manage multiple cables and want to understand how to bond connections for higher capacity when everything works, check out our guide on how to set up LACP link aggregation for better network speed in local environments.

What recursive static routes are in practice

In practice, a recursive route is a smart network engineering trick where the router discovers the path to a final destination through an intermediate IP located deep in the internet, such as Google's public DNS (8.8.8.8) or Cloudflare's (1.1.1.1). Instead of pointing the route solely to the local ISP gateway, you instruct MikroTik to search for that external IP using the specific gateway of that provider. If the primary carrier loses connection to the global network, the external address stops responding, and MikroTik immediately realizes that the route has expired, allowing the backup route to take over. This resilience principle is similar to what we discuss when analyzing why the default gateway fails and how to diagnose with ping in corporate networks.

Step-by-step route configuration on MikroTik

To bring this architecture to life, we need to create routes with different weights and scopes. Let's assume your primary ISP (Link A) uses gateway 192.168.1.1 and the backup ISP (Link B) uses gateway 192.168.2.1. The first step is to pin the external monitoring IP tied to the primary gateway using the following command.

/ip route add dst-address=8.8.8.8 gateway=192.168.1.1 scope=10

Next, we create the default route that will use this monitored destination. This route will remain active only as long as the IP 8.8.8.8 can be reached through that specific gateway.

/ip route add dst-address=0.0.0.0/0 gateway=8.8.8.8 distance=1

To ensure the backup takes over when the worst happens, we add the secondary route with a higher distance value, indicating lower priority for the router.

/ip route add dst-address=0.0.0.0/0 gateway=192.168.2.1 distance=2

Active monitoring with the Netwatch utility

Although recursive routes handle most traffic scenarios, adding Netwatch to the ecosystem brings an extra layer of automation and visual alerts. Netwatch is a native RouterOS tool that sends periodic pings to a specific IP address and executes custom commands depending on whether the destination is responding or not. This is extremely useful not only for changing routes, but also for logging the exact moment of an outage or triggering additional notification scripts.

To configure Netwatch to monitor the primary link, access the tool and define the test address with a safe interval to prevent false positives caused by momentary micro-outages.

/tool netwatch add host=8.8.8.8 interval=10s timeout=3s up-script=":log info \"Primary Link UP\"" down-script=":log warning \"Primary Link DOWN\""

Essential precautions and common configuration pitfalls

A classic mistake made by beginner administrators is choosing a monitoring IP that suffers from frequent instability or ICMP blocks from smaller ISPs. Always prefer highly stable and globally distributed corporate addresses. Another critical point is adjusting Netwatch timeout and interval settings so it doesn't flap wildly between links if the primary provider experiences intermittent packet loss.

Maintaining network infrastructure stability requires practical tests simulating physical failures. Unplugging the primary ISP cable during a controlled schedule is the only way to ensure the transition to backup actually occurs without leaving active connections hanging. To explore these architectural concepts further in production, see our related technical analysis on How to test IGBT transistors on board with a multimeter.

Final thoughts on network resilience

Implementing recursive routes and monitoring tools in MikroTik turns a vulnerable connection into a highly reliable setup for demanding homes and small businesses. Well-planned automation removes the reliance on human intervention during critical power outages or fiber cuts. With a solid failover foundation configured, your network gains the robustness needed to operate continuously and without unpleasant surprises.