Advanced Routing Failover without Scripting

RouterOS Useful user articles
101

Thanks =)

I’m a bit out of networking/ISP for a couple of years already, but still doing my best to support the community :smiley:

102

This FailOver was public at MikroTik WIKI, now it’s moved/re-write here: https://help.mikrotik.com/docs/display/ROS/Failover#heading-SetupOverview

103

Great, now I know they reworked my article without even mentioning me… That’s a bit depressing :slight_smile:

104

Plagiarism much…

105

@SiB

106

Greetings, friends I have a load balancing of 2 ISPs configured in (Policy Based Routing) with FAILOVER, and it works very well,
If I manually disconnect the interface of each ISP, the FAILOVER sends the ip addresses of the fallen isp to the other isp and the entire LAN network works fine,
and when I manually reconnect the interface the failover returns the ip addresses to each ISP and everything is normal,
But days ago the ISP 2 had problems delivering a dynamic IP address and the problem was in the central, the modem was working but it had no internet and
The failover did not work, I have ISP 2 connected from the modem to a router and from the router to my RB and thus I have a fixed IP (static),
Is there any way to ping 8.8.8.8 on ISP 2 and when that ping fails, the failover can be activated and what happened days ago will not happen again?
The ISP’s failover is already pinging the router’s gateway, which is 192.168.0.1, and since the router was on but had no internet,
That’s where the failover didn’t work because the ping was working fine. I don’t know if you understand me.
Thanks for your help.

/ip address
add address=192.168.9.1/24 interface=“ETHER 4” network=192.168.9.0
add address=192.168.6.3/24 interface=“ETHER 1” network=192.168.6.0
add address=192.168.1.2/24 interface=“ETHER 2” network=192.168.1.0

/interface list
add name=WAN
/interface list member
add interface=“ETHER 1” list=WAN
add interface=“ETHER 2” list=WAN

/ip firewall nat
add action=masquerade chain=srcnat out-interface-list=WAN

/ip firewall address-list
add address=192.168.9.46 list=ISP 2
add address=192.168.9.56 list=ISP 2
add address=192.168.9.60 list=ISP 2
add address=192.168.9.78 list=ISP 1
add address=192.168.9.85 list=ISP 2
add address=192.168.9.21 list=ISP 1
add address=192.168.9.22 list=ISP 1

/ip firewall mangle
add action=mark-routing chain=prerouting comment=“TO ISP 1”
new-routing-mark=ISP 1 passthrough=no src-address-list=ISP 1
add action=mark-routing chain=prerouting comment=“TO ISP 2”
new-routing-mark=ISP 2 passthrough=no src-address-list=ISP 2

/ip route
add check-gateway=ping distance=1 gateway=192.168.6.1 routing-mark=ISP 1
add check-gateway=ping distance=2 gateway=192.168.1.1 routing-mark=ISP 1
add check-gateway=ping distance=1 gateway=192.168.1.1 routing-mark=ISP 2
add check-gateway=ping distance=2 gateway=192.168.6.1 routing-mark=ISP 2

This is my load balancing configuration, is there a way to ping DNS 8.8.8.8 from ETHER 2 so that when ISP2 doesn’t work the failover works?

According to this thread this could be the solution to my problem:
/ip route
add dst-address=8.8.8.8 scope=10 gateway=192.168.6.1
add dst-address=8.8.4.4 scope=10 gateway=192.168.0.1

add distance=1 gateway=8.8.8.8 routing-mark=ISP 1 check-gateway=ping
add distance=2 gateway=8.8.4.4 routing-mark=ISP 1 check-gateway=ping

add distance=1 gateway=8.8.4.4 routing-mark=ISP 2 check-gateway=ping
add distance=2 gateway=8.8.8.8 routing-mark=ISP 2 check-gateway=ping

107

Try using “ISP 1” and “ISP 2”

Nice to see you back…so soon.

108

Greetings matter, I tried to do it with the scripts that you told me by disabling the interface, but it did not work for me, I think that with the use of recursive ways I can achieve that the failover is done and everything works well, later I will tell you how it went.

109

Taking advantage of the fact that we are at Christmas, how do I copy this and keep it this way, copy the configuration that I have and it didn’t come out like that.
Tank you.

110

NOT disabling the interface this because, how do detect then that it is working again.

111

eldoncito2019

Yes, this answer you can read and learn in #1 at this thread. Recursive Route can “LOCK” path to some TARGET via proper ISP. It’s exactly what you want.
.
.

The ISP’s failover is already pinging the router’s gateway, which is 192.168.0.1, and since the router was on but had no internet,
That’s where the failover didn’t work because the ping was working fine. I don’t know if you understand me.

We know, you not read a #1 at this thread.
.
.
Please use this button and next paste your code between tags next time.

.
.

/ip route
add check-gateway=ping distance=1 gateway=192.168.6.1 routing-mark=ISP 1
add check-gateway=ping distance=2 gateway=192.168.1.1 routing-mark=ISP 1
add check-gateway=ping distance=1 gateway=192.168.1.1 routing-mark=ISP 2
add check-gateway=ping distance=2 gateway=192.168.6.1 routing-mark=ISP 2

>
> This is my load balancing configuration, is there a way to ping DNS 8.8.8.8 from ETHER 2 so that when ISP2 doesn't work the failover works?

Yes, this can be done. When you use SPACE char then always you must use " char e.g. variable="some text"
the Check-Gateway can be used ONES, all next are ignored... means you can on one rule use that action for the same gateway.
.
.

> According to this thread this could be the solution to my problem:
>
> ```text
/ip route
add dst-address=8.8.8.8 scope=10 gateway=192.168.6.1
add dst-address=8.8.4.4 scope=10 gateway=192.168.0.1

YES, but…You write ones WAN2 as 192.168.1.1 default gateway, not ..0.1 !
.
.

add distance=1 gateway=8.8.8.8 routing-mark=ISP 1 check-gateway=ping
add distance=2 gateway=8.8.4.4 routing-mark=ISP 1 check-gateway=ping
add distance=1 gateway=8.8.4.4 routing-mark=ISP 2 check-gateway=ping
add distance=2 gateway=8.8.8.8 routing-mark=ISP 2 check-gateway=ping

>

If you replace all =ISP 1 to ="ISP 1" then this should start working.
112 
/ip route
add check-gateway=ping distance=1 gateway=8.8.8.8 routing-mark=ISP 1
add check-gateway=ping distance=2 gateway=8.8.4.4 routing-mark=ISP 1
add check-gateway=ping distance=1 gateway=8.8.4.4 routing-mark=ISP 2
add check-gateway=ping distance=2 gateway=8.8.8.8 routing-mark=ISP 2
add distance=1 dst-address=8.8.4.4/32 gateway=192.168.0.1 scope=10
add distance=1 dst-address=8.8.8.8/32 gateway=192.168.6.1 scope=10

It works perfectly like this.

Thanks to mstter and chupaka.

ELDONCITO2019.

113

Implemented for our 3 WAN-Connections.
Works great! Thanks Chupaka!

But I have to admit, its very weak form Mikrotik to implement such a basic function not more directly.
A “Gateway Check” and a “WAN-Connectivity Check”, where you can specify N IPs behind the Gateway.

No, they implement a “Detect Internet” feature, which works not really (mines never comes on 2 WAN-conns over “LAN”) and is completely desinged around the routing tables. Sometimes Mikrotik is so overly complicated and I dont understand their way of designing features. Why not a clear approach and not a simple feature which doesnt require you to script around…

114

Hi everyone,

I’ve been looking at how to implement a simple failover without any load balancing, so I came across this thread.

I understand the failover part, but I cannot get my head wrapped around this workaround:

As I understand it, the idea is to make 8.8.4.4 available to hosts on the LAN even if the 192.168.33.1 gateway fails, right?
So the IP route rule makes all traffic that comes in from a LAN interface go through the “exit” routing table, which contains the first four routing entries, correct?
And traffic that originates on the router itself will just see the last two routing entries then?

If the above is correct, then I don’t really understand how the additional two rules plus the routing marks make a difference. Could someone walk me through this, please?

Thanks a lot & Cheers,
Toby.

115

Hi again,

aight, of course, half an hour after this post, I think I got it. :slight_smile:

Here’s my working theory:

These two routes in the table exit mostly take care of the failover. Nothing special to see.

These two routes are unnecessary, I think—at least, in my case, everything worked totally as expected without them.
They were what threw me off in the first place—I couldn’t figure out what they would contribute. As it turns out, nothing? :slight_smile:

Again, these routes manage the failover. They’re not in the exit routing table but in the main table
because otherwise the ping checks the router sends out would be unroutable.

And finally, this rule makes all traffic inbound from the interface lan to use the exit routing table for lookups first.

So, to put it all together, here’s my understanding. The thing I didn’t realize and that I believe is crucial to understand this scheme is that the exit routing table is used first, and the main table is only consulted because the next hop that results after going through the exit table is not directly reachable. Since there is no direct route for either 8.8.4.4 or 8.8.8.8 in the exit table, this means that if one of the routes is inactive, then the other route gets pulled (instead of the direct route as found in the main table). Thus, if, say, 8.8.4.4 is not reachable, then the route via 8.8.4.4 is marked inactive, and if a client pings 8.8.4.4, then the only route left in the exit table is the default route to the other gateway, 8.8.8.8. Thus, the nexthop is 8.8.8.8, but that is not reachable, so the router drop out of the exit table into the main table and finds a direct route for 8.8.8.8. Phew Makes sense now. As expected, traffic originating from the router itself is not marked because the /ip route rule entry does not match, and is still routed directly to the interfaces in case of 8.8.4.4 and 8.8.8.8, irrespective of whether those IPs are reachable.

Two more things turned out to be irritating:

  1. The command /ip route rule add interface=lan table=exit does not work (at least not in ROS 6.48 with default config on my devices), because there is no interface called lan. I originally thought that the interface list was meant, but you have to give an interface, not a list. So interface=bridge, for instance`, works well instead.
  2. Given the above routes, the router itself has no connectivity at all except for the direct routes to its gateways and to 8.8.4.4 and 8.8.8.8. If the router itself should be able to, say, contact an NTP server, then additional routes are necessary.

In particular, I had assumed that the mitigation does not kill the router connectivity, but it actually does, doesn’t it?

Is my working theory accurate? If not, where did I take a wrong turn?

THX & Cheers,
Toby.

116

Yep, generally that’s how it works. If you need the router connectivity - you should either create a rule for its traffic to go to ‘exit’ table, or add default route(s) to ‘main’ table.

117

Hi,

Cool, THX. So then for the record this is my minimal working example that does failover with high-availability for the external “canary” host for traffic that comes from the bridge interface (the canary host being 1.1.1.1, the primary gateway being 192.168.1.254, the secondary gateway being 192.168.2.254):

/ip route
add check-gateway=ping comment="Primary virtual route (HA)" distance=1 gateway=1.1.1.1 routing-mark=HA
add comment="Secondary route (HA)" distance=2 gateway=192.168.2.254 routing-mark=HA

add check-gateway=ping comment="Primary virtual route (main)" distance=1 gateway=1.1.1.1
add comment="Primary route (main)" distance=1 dst-address=1.1.1.1/32 gateway=192.168.1.254 scope=10
add comment="Secondary route (main)" distance=2 gateway=192.168.2.254

/ip route rule
add interface=bridge table=HA

No load balancing, and the secondary route is not checked because it is a fallback route only.

Cheers,
Toby.

118

You want just simple recursive failover without load balancing? You only need two rules in the main routing table with “default route” disabled in the WAN client (PPPoE etc), like this:

add check-gateway=ping comment="Default Route for ISP1 (Recursive 1)" distance=1 gateway=8.8.8.8
add check-gateway=ping comment="Default Route for ISP2 (Recursive 1)" distance=2 gateway=1.1.1.1

#Then create a separate route for each of the "gateway" themselves, in my case using the PPP profile hack
119

Hi,

Well. This has the problem that the “canary” hosts (8.8.8.8 and 1.1.1.1 in the example) are not reachable for clients if the corresponding gateway goes down. That’s the entire reason for the shenanigans with multiple routing tables. If you can live with that effect, then yes, obviously, things can be simpler.

Cheers,
Toby.

120

Hi again,

also… A different question here…

I just realized I don’t understand this hack. How do you “copy” a PPPoE profile?

Cheers,
Toby.