I have been trying to come up with a way to have 2 core routers synced in case the main one should fail.
I am not looking for failover, but rather a clone of the main router that is updated daily or more often that can be manually switched into place if the main router fails.
This way, even if I am not available to re-program a backup unit someone in the office can simply swap the hardware and the system is 99% back.
Here is what I am thinking might be possible and I am looking for input on if this is possible or not.
Assuming I have 2 routers with identical hardware, I would set the main unit to run a daily export using the new COMPACT parameter allowing only non defaults and no macs to be exported to disk.
On the backup router, I would create a script to fetch the backup from the main router and then execute a sys reset with a run-after-reset that opens the backup file.
Obviously the fetch and reset script would have to exist on both routers since this is a “clone” so to prevent the scripts from running on the main router, I would create some kind of “if mac-address=xx-xx-xx-xx-xx” statement so it only executes on the backup router. Likewise the backup/export command could be set to only execute on the main router.
Final issue is how to allow the backup router to fetch from the main router if all the IPs and routes are the same… so, I would need another script that would change the IP of one of the ports (used only for backup to something different to allow it to reach the main router without conflict.
So there it is, do you think this is a reasonable solution? Are there issues I am not seeing? Is there a better way?
Then, you already have both pieces of hardware in place, and a failure wouldn’t require anybody to change anything out (at the moment of failure anyway). Using this method, the routers would be mostly identical. The only different would be their IP/VRRP configuration: http://wiki.mikrotik.com/wiki/VRRP-examples#Configuration
You could still do the compact export on the main router, fetch the script and do /system reset run-after-reset on the second router. Then have a startup scheduled script on the second router to change IP/VRRP soon after new config is applied. The only thing that bugs me with this method is that the second router will have duplicate IP settings as the main router for a few seconds during this process. Could this cause brief network issues? I don’t know. Ideally, you would want to change IP/VRRP settings in the script before applying it to the new router to avoid this. I can think of a couple ways to do this:
Use a PC/server on the network that downloads the script from the main router, does a find/replace for these settings. The PC could also save a copy of the previous script. Compare new and old scripts. If scripts are the same, don’t upload new version to second router. Second router would have schedule that checks for export file and if it exists, do /system reset-config. Then have another script that runs on startup that waits 30 seconds (or however much time sufficient to run new config) and then deletes the config file. An advantage would be that the second router isn’t unnecessarily re-configured and rebooted if config hasn’t changed. A downside would be another dedicated device in the mix.
On the main router, you could export only the settings from sections that you know would change (ex. /ip firewall filter export compact), creating a number of separate files. The second router would then download each of these, reset its settings for each section (ex. /ip firewall filter remove [find]), and then execute the new script. This method could be useful if there are only a few sections that will have changes, and you can specifically target them. If there is the possibility of many sections with changes, you would have to manually configure export/import of each, and this could be tedious and not very flexible if you need to add/remove sections, or RouterOS introduces new features down the road that you want to include.