Here is a example config that I use for Failover no scripting needed. This is being used in production. Currently it uses Static IPs for GW.

You must adjust all gateway= and in-interface= for your config

This assumes you don't have any routing or other mangle rules to mark connections and routing marks

After adjusting for you network copy then paste in Mikrotik terminal

Randy Newman
--------

## http://http://wiki.mikrotik.com/wiki/Ad ... _Scripting
## Adapted from the above
## change gateway= to correct gw IPs
## and in-interface= in mangle rules

/ip route

## Need IP addresses to test this is in the USA
## Changed to less used sites but always up.
## If you change these you need to change all the same IPs below
# b.resolvers.Level3.net
add dst-address=4.2.2.2 gateway=192.168.10.1 scope=10
# c.resolvers.Level3.net
add dst-address=4.2.2.3 gateway=192.168.202.1 scope=10
# google-public-dns-a.google.com
add dst-address=8.8.4.4 gateway=192.168.10.1 scope=10
# dns1.rcsntx.sbcglobal.net
add dst-address=151.164.1.8 gateway=192.168.202.1 scope=10


## Now we create rules ISP1 routing mark:
add distance=1 gateway=4.2.2.2 routing-mark=to_ISP1 check-gateway=ping
add distance=2 gateway=8.8.4.4 routing-mark=to_ISP1 check-gateway=ping

## Create rules for ISP2 routing mark:
add distance=1 gateway=4.2.2.3 routing-mark=to_ISP2 check-gateway=ping
add distance=2 gateway=151.164.1.8 routing-mark=to_ISP2 check-gateway=ping

## Create destinations to "virtual" ISP1 hops to use in further routes
add dst-address=10.8.8.1 gateway=4.2.2.2 scope=10 target-scope=10 check-gateway=ping
add dst-address=10.8.8.1 gateway=8.8.4.4 scope=10 target-scope=10 check-gateway=ping

## Create destinations to "virtual" ISP2 hops to use in further routes
add dst-address=10.4.4.1 gateway=4.2.2.3 scope=10 target-scope=10 check-gateway=ping
add dst-address=10.4.4.1 gateway=151.164.1.8 scope=10 target-scope=10 check-gateway=ping

## add default routes
add distance=2 gateway=10.8.8.1 routing-mark=to_ISP1
add distance=1 gateway=10.4.4.1 routing-mark=to_ISP2

## add default routes no routing marks distance 1 for router
add distance=2 gateway=10.8.8.1
add distance=1 gateway=10.4.4.1

## Add blackhole for routeros bug if interface goes down not
## sure if still needed with current version of RouterOS
add dst-address=4.2.2.2 type=blackhole distance=20
add dst-address=4.2.2.3 type=blackhole distance=20
add dst-address=8.8.4.4 type=blackhole distance=20
add dst-address=151.164.1.8 type=blackhole distance=20


## make sure to set in-interface= to correct interface names
/ip firewall mangle

add action=mark-connection chain=input comment="mark ISP1_conn" disabled=no \
in-interface=ether1-gw-att new-connection-mark=ISP1_conn passthrough=yes

## This must be output chain
add action=mark-routing chain=output comment="mark routing isp1_conn" \
connection-mark=ISP1_conn disabled=no new-routing-mark=to_ISP1 passthrough=no

add action=mark-routing chain=prerouting comment="mark routing to_ISP1" \
connection-mark=ISP1_conn disabled=no in-interface=ether5-LAN \
new-routing-mark=to_ISP1 passthrough=yes

add action=mark-connection chain=input comment="mark ISP2_conn" disabled=no \
in-interface=ether2-gw-tw new-connection-mark=ISP2_conn passthrough=yes

## This must be output chain
add action=mark-routing chain=output comment="mark routing isp2_conn" \
connection-mark=ISP2_conn disabled=no new-routing-mark=to_ISP2 passthrough=no

add action=mark-routing chain=prerouting comment="mark routing to_ISP2" \
connection-mark=ISP2_conn disabled=no in-interface=ether5-LAN \
new-routing-mark=to_ISP2 passthrough=yes

Hi does this works in 6.42.x routeros ?

Anyway is it possible to add additional routing mark using PCC to manage ISP balancing ?
e.g ISP1 2/3 of whole speed and ISP2 1/3 of whole speed ISP3 just for backup

Yes, everything is possible. Look at https://wiki.mikrotik.com/wiki/Advanced ... _Scripting for availability checks, then create default routes with any routing-marks you want.

In your case, you'll have two routing tables (Path1 and Path2, for example) with added routes via ISP3 having low priority.

Hi, I'm having problems with this configuration: https://wiki.mikrotik.com/wiki/Advanced ... _Scripting

My WAN with fixed ip works but with pppoe it stays unchanged. attached capture

Version 6.44.1
Thansk


Spanish
Hola, yo estoy teniendo problemas con esta configuración: https://wiki.mikrotik.com/wiki/Advanced ... _Scripting

Mi WAN con ip fija funciona pero con pppoe se queda inalcancable. adjunto captura

Versión 6.44.1

Gracias

Ah, sorry, you cannot use it this way. It's because routes with interface name as the value of gateway are not used for recursive nexthop lookup...

But with pppoe you may create separate PPP Profile and set "Remote Address" to necessary IP for checking: After that, remove your static route with dst-address=8.8.8.8 - it should appear automagically when pppoe connects.

thank you, it seems to be working correctly

Your definition holy grail would imply dhcp support for wan, this is nothing new.

Overly complex Failover. Simple recursive routes (choose 1 or 2 public DNS) is just as effective, no mangling required.

Mangling is to have external access to both addresses simultaneously. It's not about failover itself, it's about usability

Concur and thus one could be talking about
1. failover where two wans are equally used (mangling required)
2. failover where one WAN is primary and one WAN is secondary

Overly complex Failover. Simple recursive routes (choose 1 or 2 public DNS) is just as effective, no mangling required.

Nope. Established sessions (like VPN) never return to the primary connection.
This is a recurring problem for Mikrotik that there doesn't exist vetted solutions which either function in the majority of circumstances or have the major issues labeled. Everyone has to reinvent the wheel again as there is no comparison of the pros and cons in solutions. There are only hints, tips and tricks taking you to the next "problem".
Mikrotik products would be immensely more adopted should they have the primary sought after features with turn key examples completely documented, like QoS (PCQ), Failover, Load balancing, Policy based routing, etc with the examples applied to both quickset and full deployment scenarios with multiple wans, lans in different configurations with static ip, dynamic ip, etc (think https://en.wikipedia.org/wiki/Unit_testing ). Mikrotiks most common repeat reply in their forums is "how would that work? it doesn't work because..." of which "none" of them are mentioned in the documentation (wiki) being the initial trigger of people asking it in the forums in the first place.

Overly complex Failover. Simple recursive routes (choose 1 or 2 public DNS) is just as effective, no mangling required.

Nope. Established sessions (like VPN) never return to the primary connection.
This is a recurring problem for Mikrotik that there doesn't exist vetted solutions which either function in the majority of circumstances or have the major issues labeled. Everyone has to reinvent the wheel again as there is no comparison of the pros and cons in solutions. There are only hints, tips and tricks taking you to the next "problem".
Mikrotik products would be immensely more adopted should they have the primary sought after features with turn key examples completely documented, like QoS (PCQ), Failover, Load balancing, Policy based routing, etc with the examples applied to both quickset and full deployment scenarios with multiple wans, lans in different configurations with static ip, dynamic ip, etc (think https://en.wikipedia.org/wiki/Unit_testing ). Mikrotiks most common repeat reply in their forums is "how would that work? it doesn't work because..." of which "none" of them are mentioned in the documentation (wiki) being the initial trigger of people asking it in the forums in the first place.

I really don't care about re-establishing the same connection on failover. That seems pie in the sky thinking.
The old connection is gone caput, dead, I would expect to have to restart all my activity. The idea of failover is minimal disruption to service plus as the admin I dont have to intervene.
Different expectations.

I really don't care about re-establishing the same connection on failover. That seems pie in the sky thinking.
The old connection is gone caput, dead, I would expect to have to restart all my activity. The idea of failover is minimal disruption to service plus as the admin I dont have to intervene.
Different expectations.

Well unless you intervene the new connection wont be restored (used) on the primary until you intervene, because the secondary (failover) hasn't failed, same expectations. Your vpn will be running on the bandwidth, speed, etc capped secondary until the end of times.

...should they have the primary sought after features with turn key examples completely documented, like QoS (PCQ), Failover, Load balancing, Policy based routing, etc with the examples applied to both quickset and full deployment scenarios with multiple wans, lans in different configurations with static ip, dynamic ip, etc (think https://en.wikipedia.org/wiki/Unit_testing ). Mikrotiks most common repeat reply in their forums is "how would that work? it doesn't work because..." of which "none" of them are mentioned in the documentation (wiki) being the initial trigger of people asking it in the forums in the first place.

First, on the forums you can see people who came to ask. You have no evidence on the number of people who found the existing documentation sufficient, nor on the number of people who had a problem but haven't asked on the official forum because they don't trust their English, so they asked on one of the community-run forums in other languages.

Second, to your VPN issue - this is an example of a niche case. In enterprise and ISP networking environments, protocols for dynamic routing (and switching) silently do their job the way they have been designed. In the SOHO environment, there is the NAT issue which cannot be easily overcome. For "normal" protocols including most VPN ones, there is no way to change the address of one of the session endpoints seamlessly - you need to terminate an existing session and establish a new one, as sessions of this kind are not identified by anything more than the two address:port tuples, so if a change of uplink at client side includes a change of the client's IP address from the perspective of the server, there is no way for the server to identify that the packets coming from the new address actually belong to an existing session and to take appropriate measures.

Specifically for VPN, this scenario is currently only addressed by IPsec IKEv2 extension called MOBIKE, where the server can seamlessly adapt to a change of client's IP address because the VPN protocol's own session identifiers can be used to identify incoming traffic as these identifiers are independent on the IP address and port.

So once Mikrotik starts supporting MOBIKE, the approach to uplink redundancy can change in terms that each switchover won't cause a breakdown and re-establishment of an ongoing IPsec session. However, for other VPN types (and other types of sessions) the need to prioritize between the minimization of the number of outages and the data accounting/speed constraints of the backup line always exists, and each user has individual environment and preferences leading to different changeback strategies.

So as a RouterOS product manager, you have two options:

• to ask your team to create a software module controlling the changeover and changeback for any underlying protocol (VPNs and others) choosing from the two common strategies to handle disruptive switchovers, which are "use of one of the links as a primary one with an automatic changeback to it after a configurable guard time expires since the primary link has become available again" and "switch over to the redundant link only if the currently used one becomes unavailable", and have to address a lot of integration issues with the other functionalities.
• let the users themselves script solutions tailored to their needs, including strategies for more than two uplinks etc.

Even the first approach leaves a group of users who won't find the available functionality sufficient for their needs, and another group of users for whom it would be sufficient but they don't understand how to use it, so the effort needed to implement it may be too high as compared to the effect.

Even just documenting a VPN failover solution for every possible combination of factors would require an enormous effort while the actual audience is very limited. And looking at the forum users' questions, many of them have problems to read the existing documentation and properly adapt the information to their particular situation, and even to find an existing forum topic dealing exactly with their particular situation So my private preference is that the Mikrotik documentation squad concentrates on the quality of the documentation in its existing structure, not on top-to-bottom descriptions of scenarios actually used by three people in the world.

As Chupaka states to route traffic correctly with multiple WAN and respond to items on the correct WAN interface you have to use mange rules to mark packets to go over/back interface.

Mikrotik has a PCC example you can use. It doesn't do failover but you can adapt the recursive route way and use PCC and queues to do it.
https://wiki.mikrotik.com/wiki/Manual:PCC

Randy