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?
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.
Do you know if there is a way to synchronize the dhcp leases between the 2 routers?
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.