does someone of you know about any tool/script to convert exported MikroTik configurations (*.cfg.rsc) between different MikroTik devices?
For example, I have a device with 5 ETH ports and want to migrate to another device with 8 ETH ports and, therefore, being able to re-map the ports used in my configuration.
Doing this manually would be possible, but is a really boring task with a high chance to forget something.
I am aware, that - nevertheless - the new configuration should be copied line by line to the new device and not simply be imported. But this would be fine if you have not to think about each of the configuration lines. However, if the tool could handle it in a way that a simple restore of the *.cfg.rsc would be possible, that’s even better
I have never seen it…
You are right, migration of config in MikroTik routers is a bit of a problem.
It is not possible to do it using .backup files, but the backup restore procedure does not check that and happily messes up the device.
And the load of .rsc files also is problematic. The import command stops whenever it encounters some minor problem.
It would be so much better when there was at least an option to “continue on errors”.
To avoid issues with re-mapping of ports I at least put the ports in a bridge with appropriate functional name. Can be a separate bridge (e.g. bridge-internet which then contains only the port towards internet) or in some cases I used the modern vlan-filtering bridge with a vlan per function.
It is then much easier to migrate config to another device where another port mapping is more optimal, as one only has to reconfigure the bridge port memberships and not all the other config tied to an interface (dhcp, firewall, etc etc). Of course “interface lists” also helps with that.
For one particular case, where I have a CCR2004 in production and a CCR1009 as standby, I wrote a Perl script that reads the CCR2004 export and makes the changes required to import it on the CCR1009, which I use after config changes on the 2004 so that the 1009 is always correctly configured to take over.
It would likely be much more difficult to make a “generic” version of that, because there is so much you have to watch out for.
Too funny, I think its pure genius that I can export a config file and put any of the script file directly into the command prompt of another router and insert exactly the same code. So effing convenient…
Yes pe1chi, dont exaggerate the problem. Changes are not that different and its not that hard or time consuming… What next the router needs to hold your member so you can take a whiz with no hands???
While, yes, in a lot of cases, :import works with an :export, or with minimal “search-and-replace” in a text editor.
Whether it’s “hard” or “easy” really depends on device differences and topology differences… But there are MANY “gotchas” that require a rather deep understanding of RouterOS if you don’t want problems…
OP ask if there is a tool to help… that does sounds pretty reasonable. And Mikrotik doesn’t have anything “built-in” that help with some reasonable “cloning”. There may be other commercial tools to help… I don’t use, but there is https://unimus.net/ , that offers some of what you’re looking for. There may be something else akin to what your looking for in Mikrotik’s list of ISVs too: https://mikrotik.com/mfm/software
What I do to “help” with this problem is treat config like any other script… e.g. the config script is essentially dozens of :globals at top, with a bunch of :if/:for statements around items from defconf/:export – so I do the “thinking once” & then make some changes to few variable, and then load that variant config on a new router. This gets reproducibility and less error-prone over the long term. Now this is inefficient if your only needs are only a handful of routers… but at some scale, without SOME tools, config management is awfully tedious.
Hint: use the “/export show-sensitive terse” command (especially the “terse” parameter) when you want easier handling in a text editor or script.
I don’t use it because my Perl script first performs the equivalent action on “non-terse” exports, but it can save some work.
Also, always make sure you either do a config-reset with the prepared script as import, or you connect to the reset router via MAC address and paste the script in there. But first confirm that the router is really empty by typing /export in the command window. Sometimes there is a dhcp-client that you first want to delete.
Anything of the “add” form (vs “set”) will usually cause problems when it is already present in the config and also in the script.
At least try to use the same RouterOS version on source and destination router. There are unfortunate changes between versions that the router itself handles when upgrading, but the export/import method will not handle them.
E.g. now in 7.12rc1 they changed the parameter “address” of /tool/e-mail to “server”, causing my import to fail again. So in my script I needed to add a new “regexp change”.
Of course when your source router is v6 and your destination router is v7, you will have major hurdles ahead. You either need to upgrade the old router from v6 to v7 (which you may not want to do) or you need to have a temporary CHR installed to v6 where you load the old config, upgrade that to v7 and then export again to obtain the config for the new router.
It would be very convenient when MikroTik made the “crossfig” tool used inside the router to convert v6 to v7 available e.g. on the website (paste your v6 export and obtain a converted v7 export for the same router).
There are also other snags. E.g. on a router with 2 WiFi bands, it varies per model if wlan1 is 2 GHz and wlan2 is 5 GHz or the reverse. That means that you may have to change all references to wlan1 into wlan2 and vice-versa.
Another snag is the user list. The users on the router are not exported, but the user groups are. So when you use multiple users, you need to manually transfer them from the old to the new router, or when you already have them and select to use “keep users” you will need to remove the /user group section from your export before you import it. Because otherwise it will conflict with the already existing user group. This really should be fixed: users should be exported with their encrypted password and be able to re-import them in an empty router keeping the password. So the “keep users” option can be skipped.
And of course there is also other data that is not in /export files: the certificates, ssh keys, etc. That also really should be fixed.
Everything is the same, find and comp… line by line