I am thinking to have 2 CCR2004, one as a warm spare. I was reading this document using meraki https://www.willette.works/mx-warm-spare/ and i am wondering if something similar could be done. Can we handle crrp messages directly between ccr2004 with a dedicated port for it? or any other similar way to do it?
Not sure if this is the right functionality but VRRP might be one approach.
Basically create a virtual router with inputs from two physical routers.
One drawback is apparently you can lose natted connections… as the traffic came in one physical interface and cannot go out a non-existing physical interface ???
Also dont know how responsive it is in terms of what happens when the primary router goes offline.
Seen this recommended but its 2016.
https://github.com/svlsResearch/ha-mikrotik
Newer version 2019
https://github.com/svlsResearch/ha-mikrotik
For sure you’ll have some broken sessions since none of this is a statefull switchover.
These scripts work without too much impact if your CCR’s are pure ROUTERS. If they perform NAT then you’ll break all sessions that where running on the “active” node when it dies.
Now VRRP are LAN-side redundancy protocols, there might be more at play depending on your setup, you connectivity/routing towards your upstream.
Now depending on the sorts of traffic this probably is not a disaster, merely a small hiccup in most cases.
For example,
if you have a warm spare of everything, but only one cable / fiber / ptp connects your location to the internet,
probably the cable / fiber / ptp is the first to break
well i have 2 fiber links nd a 5G baxkup… They are using different paths also. On that part i am covered i think. But I see where you are going 
the main point there is to get some safety whern you are not in the place to change the hw.
thanks for the links. This seems to fit my need 
i wish such things would be easily implemented
I think I read sometime that there are plans to cover this in version 7.
But then, haven’t we all read how version 7 would be heaven where all problems are solved?
Anyway, it appears that Linux now supports a protocol to synchronize connection tracking state, and they are making it available in RouterOS.
I confirm the synchronisation of connection tracking state was working in 7.1beta something, it just sometimes started consuming lots of CPU and had other issues (stopped working when the master/backup roles changed forth and back or something). I haven’t checked the state of the art in 7.1beta6 yet. It is linked to VRRP there:
/interface/vrrp/add … sync-connection-tracking=yes
The HA approach implemented by nathan1 is great, I admire his determination to work around all the pointless limitations.
Regardless whether you use the HA approach or the plain VRRP one, it makes sense to connect each WAN to another router. The configuration below is necessary for the HA case; for the plain VRRP one you can save one ethernet interface per router as you don’t need the configurations to be identical.
So: ether1 and ether2 are bridged together, and so are ether3 and ether4. IP or PPPoE configuration of each WAN is attached to one of these bridges. ether2s of the routers are connected together, and so are ether4s. The physical LAN cable of WAN A is connected to ether1 at one router, the physical LAN cable of WAN B is connected to ether3 at the other router. ether1,2,3,4 are excluded from the general disabling at the standby router in the HA case; instead of disabling these ports, the IP/PPPoE configurations of both WANs must be disabled on the standby router.
so do i have only the choice of vrp and eventually synchronize the configuration in routeros 6? i am not sure how routeros7 will work, will it add something similar to pfsync?
Do you know if there is a way to synchronize the dhcp leases between the 2 routers?
There are actually three separate things to address:
- providing the routing redundancy itself
- synchronisation of the (static) configuration
- synchronisation of the (dynamic) connection tracking information
Point 1. is provided by both the HA approach implemented by @nathan1 and the VRRP approach, regardless RouterOS version (provided that you test and eventually fine-tune the HA approach with the RouterOS version you want to use, as subtle changes in RouterOS behaviour may have a heavy impact on its functionality). The VRRP approach offers you a possibility to distribute the load among all the routers in a group, but this only matters if you have more than two routers per group, so not your case.
Point 2. is currently only provided by the HA approach, again regardless the RouterOS version. As of writing this, I don’t know any way to parse the configuration export row by row using RouterOS scripting and selectively update it on the other router(s) in the group.
Point 3. is only available in RouterOS 7, and yes, it is similar to pfsync, the firewall state in the “backup” router (in VRRP terms) is synchronized with the one on the “master” router. It is linked to VRRP in terms that VRRP must be configured (with a limitation that preemption-mode must be set to no if you want the connection tracking state to be synchronized), but as @nathan1’s HA implementation does use VRRP as a heartbeat link between the two routers, it should be available there as well.
Synchronisation of DHCP leases is not a big deal as DHCP has an embedded mechanism for this; if the clients behave properly, they ask for the previously assigned address when asking for a new lease, and the Mikrotik DHCP server accepts that requirement unless that address has already been assigned to something else. So there is a risk of clients losing their addresses if a takeover takes place, and some new client asks for an address before the existing clients renew their ones. You can mitigate this to some extent if you use two pools, A and B, whereas the DHCP server of router A will use pool A and pool B will be the next-pool for pool A there; on router B, the DHCP server will use pool B and pool B’s next-pool will be pool A. So new clients requesting an address shortly after the failover should get addresses not conflicting with leases assigned by the previously active router. But this of course only works for the first failover ever.
Hopefully in v7 there will be some capability to make routers in a group update each other’s configuration when something is modified, e.g. you modify it only on the active router in VRRP and that copies the change to the other router(s) using some internal clever use of API…
Without that it would be difficult to market it as a solution (unless they license the work done by nathan1)…
For DHCP there ideally should be some master/slave sync as well, as is available in some DHCP servers already.
Similar issues exist for RADIUS (usermanager) which also does not provide a way to keep a redundant copy, even in the improved v7 usermanager.