How to set up Mikrotik failover with recursive routes

Why traditional failover fails in practice

When setting up two internet connections on a router, the ideal scenario is for the network to automatically switch to the backup link if the primary one drops. However, the basic method of monitoring only the ISP router often fails because the telephone line or fiber cable to the central office can break while the modem light remains green. In practice, this means your router thinks it has internet just because it is talking to the ISP box, leaving your entire local network offline. To solve this intelligence problem, we need to look beyond the first hop and test real connectivity with the internet.

The concept of recursive routes in RouterOS

Recursive routes act like a detective investigating whether the final destination actually responds, instead of trusting only the first intermediary. In the Mikrotik operating system, RouterOS, we tell the router that to reach a public IP address on the internet — such as Google's DNS 8.8.8.8 — it must obligatorily use the primary ISP gateway. If that remote address stops responding to test pings, the router understands that the path has expired and disables that route automatically. Before applying advanced routing rules, it is worth ensuring your basic infrastructure is clean, concepts we also cover when learning how to diagnose packet loss and high latency with mtr to understand the true health of your links.

Step-by-step to configure the primary link with recursive ping

To get our hands dirty, let's configure the primary internet link by forcing recursive checks through a reliable IP address on the internet. Suppose your primary link is on interface ether1 and uses gateway IP 192.168.1.1, while the backup link is on ether2 with gateway 192.168.2.1. The first step is to create a static route to a test IP, such as 8.8.8.8, pointing to the primary gateway, and then create the default route using that same test IP as the check scope. To isolate addressing issues and ensure your internal network does not mix improper traffic during bench tests, maintaining logical organization is vital, much like how to configure VLAN on switch port and isolate network to prevent packet leakage.

Open your Mikrotik terminal or access WinBox and run the commands below to structure the recursive route for the primary link. Make sure to replace the gateway addresses with the actual IPs provided by your internet service providers:

/ip route add dst-address=8.8.8.8 gateway=192.168.1.1 scope=10
/ip route add dst-address=0.0.0.0/0 gateway=8.8.8.8 check-gateway=ping distance=1

Configuring the backup link and return priority

Now we need to configure the second route for the backup link, which will take over traffic if the primary link stops responding to ping tests at address 8.8.8.8. Since we assigned distance equal to 1 for the primary route, the backup link must receive a higher distance value, like 2, making it a secondary option in the routing table. In practice, this means the router will always prefer the shorter and faster path, falling back to the backup only when the primary fails completely. Furthermore, when the primary connection reestablishes and responds to piques again, the router automatically and transparently recovers the primary route for local network users.

Enter the command below to configure the secondary link with a higher distance, ensuring it strictly acts as redundancy:

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

Testing and validating high availability

After applying the settings, the ultimate test consists of simulating a real outage by physically disconnecting the primary link network cable from the Mikrotik's ether1 port. As soon as the cable is removed, the router sends test packets to IP 8.8.8.8 through that gateway, but receiving no response, the check-gateway=ping parameter marks the route as unreachable. Within seconds, the routing table updates and traffic is forwarded through the secondary gateway configured on ether2. This transition occurs without human intervention, ensuring that critical systems and users keep browsing without noticing the interruption at the source. To explore these architectural concepts further in production, see our related technical analysis on How to test a Schottky diode on board with a multimeter.

Final considerations on router redundancy

Implementing recursive routes in Mikrotik turns an ordinary home or corporate infrastructure into a highly resilient environment against carrier failures. Although more complex load balancing and multi-gateway protocols exist, recursive failover solves the vast majority of downtime scenarios with low router CPU consumption. Keeping active monitoring and periodically testing the physical integrity of cables and connectors ensures your network remains shielded against unwanted daily surprises.