I have two interfaces that I use for internet access, one through a provider and one through a 4G module. The first interface has an exit route with priority 1 and the other has priority 2. How can I make an effective ping through the interface with priority 2 to an external IP (Example: 8.8.8.
without giving me a timeout or unreachable IP? Or in case I have changed the priority to 3 of the first route to redirect traffic to the route through the 4G interface, how can I verify that that route, which now has priority 3, already has access to 8.8.8.8? I cannot use the “Check-gateway” option because there are other IPs that my provider accesses before going out to Internet, that is, the fact that the ping gateway does not mean that it has internet, that is why I need to verify directly with a external ip like 8.8.8.8
I think you are describing what Is usually called “recursive routing”.
Check this post for more details:
http://forum.mikrotik.com/t/advanced-routing-failover-without-scripting/136599/1
Once you confirm this Is the desired result, we’ll talk of the details.
If - more generally - you are looking for automatic failover there are (IMHO) simpler methods using netwatch.
What type of ISP connection is the primary…
Recursive allows one to verify www connectivity
General format:
/ip route
add checkgateway=ping distance=1 dst-address=0.0.0.0/0 gateway=1.1.1.1 routing-table=main scope=10 target-scope=12
add checkgateway=ping distance=2 dst-address=0.0.0.0/0 gateway=9.9.9.9 routing-table=main scope=10 target-scope=12
add distance=1 dst-address=1.1.1.1/32 gateway=ISP1-gatewayIP routing-table=main scope=10 target-scope=11
add distance=2 dst-address=1.1.1.1/32 gateway=ISP2-gatewayIP routing-table=main scope=10 target-scope=11
The complexity comes in for the gateway IP settings. If static, one is laughing, if dynamic it depends on ISP functionality.
My cable provider automatically updates my routes, my bell fiber does not so I need additional script to do so.
netwatch my indeed be easier.
First of all, I want to thank you for responding so quickly. Now I explain to you what I have and what I want to implement in my equipment.
I have 2 main routes, are these:
0 As 0.0.0.0/0 Gateway: 192.168.7.1 Distance: 1 Routing-Table: main
1 s 0.0.0.0/0 Gateway: LTE Distance: 2 Routing-Table: main
Route 0 goes out through an ISP, but I cannot establish a “Chek Gateway” because that gateway connects to another one, and that other one is the one that has the exit, therefore, that gateway may be working (192.168.7.1 ) and I don’t have a connection because the ones behind that are not working.
How could I know if the internet is working through it? Well, doing a ping for example, or a traceroute. So, in that case, I must route everything to exit via route 1, which exits through an LTE module, but only when route 0 (ISP) fails. So, what I did was a script to check the internet connection by pinging 8.8.8.8 and depending on that, change the priority to the route, example:
If there is no internet, route 0 (ISP) will have priority 3 and route 1 (LTE) will have priority 2, thus everything would go through route 1 (LTE) which has a higher priority.
But with this I have a problem, because when everything goes out through route 1 (LTE), I cannot do ping or traceroute through route 0 (ISP) because it gives me an error, so, the temporary solution, which I don’t like because it leaves me a few seconds without internet every so often, is to change the priority of the route again from 0 to 1, do ping, if it fails, change it again to priority 3. I am not allowed to ping or traceroute through a specific interface or route because I fails at the moment After doing it, it always gives me a timeout even if I already have a connection.
I had never ventured into these networking topics, since I dedicate myself to programming and my knowledge of networks can be said to be basic, nor had I previously worked with RouterOS, so I greatly appreciate your help and explanation on these topics. Thank you very much for having responded to me.
This is my script:
:local target 8.8.8.8
:local routeComment “MainRoute”
Returns the distance of the main route to 1 to test connectivity
/ip route set [find comment=$routeComment] distance=1
:log info “Restoring primary route priority to test connectivity.”
Wait a few seconds for the route change to take effect
:delay 3s
Ping the destination to verify connectivity
:local pingResult [/ping address=$target count=3 interval=1s]
:log info “Ping result to $target: $pingResult successful packets.”
Check if the ping was successful
:if ($pingResult > 0) do={
If the ping is successful, keep the main path distance at 1
:log info “Connection successful on main route. Keeping distance at 1.”
} else={
If ping fails, set the primary route priority to 3
/ip route set [find comment=$routeComment] distance=3
:log warning “Connection failure on main route. Changing distance to 3.”
}
Well, the actual idea behind both recursive routing and netwatch checking is to use a “remote” (and likely reliable) DNS server (such as 8.8.8.8, 8.8.4.4.4, 9.9.9.9, 1.1.1.1, etc.) to check the connection to the internet by pinging it.
This is done through a “narrow” additional route (a /32 one) to the chosen DNS server.
A recursive set is made of TWO routes, the narrow one telling the router what the next hop (let’s call “next hop” the “gateway=” setting) to reach the DNS server ( I will use two, 1.1.1.1/32 and 9.9.9.9 for the example) is and a wide 0.0.0.0/0 route with a check-gateway for the same 1.1.1.1 and 9.9.9.9, simplified (anav’s example has only 1.1.1.1) :
.
set#1 (checked address 1.1.1.1 with distance=1 and next hop set to ISP1):
Route#1 distance=1 dst-address=1.1.1.1/32 gateway=ISP1-gatewayIP
Route#2 check-gateway=ping distance=1 dst-address=0.0.0.0/0 gateway=1.1.1.1
set#2 (checked address 9.9.9.9 with distance=2 and next hop set to ISP2)
Route#3 distance=2 dst-address=9.9.9.9/32 gateway=ISP2-gatewayIP
Route#4 check-gateway=ping distance=2 dst-address=0.0.0.0/0 gateway=9.9.9.9
When BOTH ISP1 AND ISP2 are working:
Route#1 is active as it is the ONLY route leading to 1.1.1.1
Route#2 is active because has the lowest distance among the routes leading to 0.0.0.0
Route#3 is active as it is the ONLY route leading to 9.9.9.9
Route#4 is NOT active as there is Route#2 leading to the same 0.0.0.0 but with a lower distance
IF you switch off (or disconnect LAN side) your ISP1 router:
Route#1 becomes NOT active as the ISP1 router is not reachable
Route#2 becomes NOT active as the 1.1.1.1 is not reachable
Route#3 is still active
Route#4 becomes active because it is the ONLY route to 0.0.0.0 (actually the one with the smaller distance among active routes)
IF you disconnect your ISP1 router from the fibre/dsl/whatever: (thus simulating an interruption anywhere between your ISP router and 1.1.1.1):
Route#1 is active as it is the ONLY route leading to 1.1.1.1
Route#2 becomes NOT active as the 1.1.1.1 is not reachable
Route#3 is still active
Route#4 becomes active because it is the ONLY route to 0.0.0.0 (actually the one with the smaller distance among active routes)
As soon as 1.1.1.1 becomes reachable again Route#2 (or Routes#1 and #2) will be active again.
More detailed explanation (including scope and target scope) here:
http://forum.mikrotik.com/t/trying-to-understand-this-config-mikrotik-automatic-isp-fail-over-without-scripts-or-route-marking/177349/1
Hope that this way it is easier to understand the general idea, but have a look at this:
http://forum.mikrotik.com/t/simpler-failover-for-two-gateways-i-found-working/169108/1
in the even more simplified version here:
http://forum.mikrotik.com/t/simpler-failover-for-two-gateways-i-found-working/169108/1
it is as simple as it can be.
In plain english, the recursive checks if you can actually reach the WWW.
We have to go through the closest hop as that is what we know. what in between is immaterial.
The key is can the route reach the www, if not switch to WAN2 etc…
I wanted to take a moment to thank both of you for your insightful explanations regarding recursive routes. I truly appreciate the time you took to clarify the concept, and I can say that I’ve learned a lot about how these routes function thanks to your responses.
That said, after evaluating the situation in my specific setup, it turns out that implementing recursive routes is not a feasible solution for me. The issue lies in the complexity of my ISP’s infrastructure, which involves several intermediate hops. For instance, my primary gateway (192.168.7.1) connects to another MikroTik device (10.1.1.1), which in turn depends on yet another device controlled by my ISP’s upstream provider. As a result, if there’s any issue beyond the 10.1.1.1 hop (e.g., at my ISP’s upstream), the route to destinations like 8.8.8.8 becomes unreachable, even if the closer gateways themselves are still operational. This behavior causes recursive routes to fail in this context.
Given this limitation, we opted for a different approach that works reliably with my setup:
I created a specific route for traffic to 8.8.8.8 via my ISP’s primary gateway (192.168.7.1).
A script runs periodically (every 20-30 seconds) to send a ping to 8.8.8.8.
If the ping fails consistently (e.g., after 3 attempts), the script disables the default route (0.0.0.0/0) for the ISP and allows all traffic to fall back to the LTE connection.
When the pings to 8.8.8.8 succeed again, the script restores the ISP’s default route.
This solution allows me to dynamically manage failover in a way that’s both simple and effective for my specific environment.
Once again, thank you for your assistance and for helping me better understand routing concepts. Your support was incredibly helpful, and I’m glad to be part of such a knowledgeable community.
Best regards
Well, what do you think netwatch is supposed to do? 
https://help.mikrotik.com/docs/spaces/ROS/pages/8323208/Netwatch
Using the (newish) ICMP mode (as opposed to “simple” ping) it allows for “fine-tuning” the failover triggering, and it has a few other modes too, besides ping:
Type of the probe:
- icmp - (ping-style) series of ICMP request-response with statistics
- tcp-conn - test TCP connection (3-way handshake) to a server specified by IP and port
- http-get - do an HTTP Get request and test for a range of correct replies
- https-get - do an HTTP Get request and test for a range of correct replies
- dns - do a specified DNS query for domain name
- simple - simplified ICMP probe, with fewer options than “ICMP” type, used for backward compatibility with the older Netwatch version
Yes @jaclaz, you are absolutely right 
, sometimes when trying to look for more complicated solutions one does not realize that they already have the means for these checks, I did not understand the issue of routes very well until I started talking to you, before I tried to use it and it gave me an error, now I imagine it doesn’t because I already have a route defined for 8.8.8.8 through the interface connected to my ISP. Once again thank you very much for responding and teaching me a little more about mikrotiks and their configurations.
Only for the record and JFYI, there is a way out for cases where the narrow route becomes invalid/inactive (for one reason or the other), which is to add a second narrow route as blackhole, but with a higher distance, is that your case?.
See, as an example:
http://forum.mikrotik.com/t/port-based-routing-to-2-identical-ip/180504/1