How to recover from the misuse of backup and restore?

RouterOS Beginner Basics
1

I discovered recently that using backup and restore to copy router configurations between devices is not a good idea. It works, but having twin devices in a subnet that differ only in identity name causes issues.

I recently had reason to expand wireless access points. I used backup and restore to copy the configuration from one mANTBox ax 15s to another. I changed the identity on the copy and proceeded with the installation.

I had worked so hard on perfecting the mANTBox configuration that I wanted the same on a second device. My journey in MikroTik started last year. I have moved a company network from a single residential router to a company network separated by VLANs over a fibre backbone using MikroTik routers and switches. The MikroTik knowledge shared by members in this community made it possible.

If you recall in network theory, there are some values that must be unique in a network if it is to function properly. Two in my example are MAC address and IP address. The backup command copies over to the second device MAC addresses without change.

What happened in my case is that both devices tried to secure the same IP address from the DHCP server. Their existence in the network was short-lived. They kept appearing and disappearing in the DHCP server leases. DHCP screen showed two devices sharing one IP momentarily. Then they both were gone.

The backup and restore is ideal for moving configurations. The backup carries all the tweaks that perfect the installation. Unfortunately, it doesn’t work. Now for the fix.

I discovered through these two commands interface details that are causing me issues.

/interface print detail

/interface bridge print detail

I then completed this set of commands to re-align the MAC address with the values provided on the equipment label.

/interface bridge set bridge auto-mac=yes

reboot

/interface ethernet set sfp1 mac-address=XX:XX:XX:XX:XX:XX

/interface wifi set wifi1_2G configuration.mode=ap mac-address=XX:XX:XX:XX:XX:XY

/interface wifi set wifi2_5G configuration.mode=ap mac-address=XX:XX:XX:XX:XX:XZ

/interface wifi set wifi1_2G mac-address=XX:XX:XX:XX:XX:XY

/interface wifi set wifi2_5G mac-address=XX:XX:XX:XX:XX:XZ

/interface ethernet set ether1 mac-address=XX:XX:XX:XX:XX:XW

/interface bridge set defconf admin-mac=XX:XX:XX:XX:XX:XW auto-mac=no

What am I missing?

I started over and tried the import file-name but not all the configuration imports worked error-free. I also tried starting over and building the device from scratch. So much learning occurred during this first configuration, I worry I will miss some.

What is the community's advice? Will my plan work?

2

The correct solution is to take a working .rsc config export and modify it down to the bare minimum commands needed to setup the next one. Usually you can omit mac-address and it'll use the existing one etc. Of course all IP's need to be different as well if statically set.

Over the course of years, I have a few rsc's that are basically made to be run on-top-of a barebones config to get it up-to-scratch for my network.

Backup and restore is really only for recovering an exact device.

3

Generally the binary backup/restore is not meant for this. However it does work - sort of. If you decide to use it, only do so between the exact same devices in terms of hardware and the same software version.

People then generally have a small script to set up what should be different between devices. For interfaces, the reset-mac-address command restores the factory mac.

Unfortunately export/import is also not exactly what you want. As you have seen, in many cases it does not apply cleanly. (Take care to only attempt it on a device with no configuration, not on one with a default. The reset-configuration command with "no default" and "run after reset" helps here.)

The cleanest way is to write a script that sets everything up, but only what you want. Unfortunately, this requires a bit of work. The script generated by export helps a lot though.

4

Indeed it is really sad that after over 25 years of development, RouterOS still does not offer a mechanism to clone a configuration to a different hardware device.

Not only to setup a different device with similar parameters as another one you have in the same network, but also to transfer working configuration from one device to another when you have bought a newer, faster device (e.g. a new router).

There should be functions to "export configuration without hardware specifics" (e.g. MAC addresses), and easier ways to import a config onto another device (e.g. skipping config not valid on the import device, like LED settings etc).

As it is, it requires detailed knowledge of the config commands and manual work like cut/paste in terminal sessions.

5

Thanks for the posts so far. I was expecting for someone to chastise me for the newbie mistake. I'm in the lab trying your recommendation to see how that fares out.

I haven't heard a cease and desist on such a move. I just realize the device serial number is another value I will need to change. That one doesn't seem to play into networking.

6

In most situations you need only two commands:

/interface ethernet reset-mac-address [ find ]
/interface wifi reset-mac-address [ find ]

If you have statically set ip addresses (not via dhcp), those have to be updated.

The device serial number is not user configurable and it's stored separately from the config. You might want to update the system name, however.

You might want to reboot after doing this.

7

good, but use { } because when the mac you use is changed, you loss the connection and the operation can be incomplete

{
/interface
ethernet reset-mac-address [find]
wifi reset-mac-address [find]
}

An not all RouterOS v7 versions support reset-mac-address of the wifi. Only the lasts. (v6 not)

But even so, duplicates can still exist, such as MAC addresses in the bridge,
additional Wi-Fi virtual interfaces, virtual Ethernet ports, and anything else that has a MAC address...

So using the backup to configure another machine is fundamentally wrong, regardless.

Do an /export and look everywhere a MAC address appears...
It'll be quicker and will eliminate any doubts.

8

You weren't paying attention.

9

The question is (it's common question, not personeal one) why it is assumed that should work?
No one complains that moving a car engine from gas version do disel one (or vice versa) does not work or replacing transmission from manual to automatic does not work too. Why? It's the same model, so it should work without any adjustments.
Direct cloning Windows from computer to computer does not work as is clones GUID and messes the network operations or AD ones or just BitLocker state. No problem, it's accepted as "Windows work that way".
Direct cloning SQL (with pure dumps) data between MS SQL/Oracle/MariaDB/SQLite/Postgress does not work even SQL standard was designed just for that. No worries. "Everyone is aware of this".

So why it is assumed that Mikrotik's backup/restore could be used for "clone" without any changes? Why the "restore" should work behind the scenes and silently rename/re-MAC/reassign missing/old devices to new devices?

10

It does work OK on some other manufacturer's home routers and access points... I guess it isn't impossible. At least. when a plain backup/restore would not work, a simple mechanism to transfer configuration from one device to another could be added, e.g. as parameters to export and import.

11

So it means that on MANY it does not work too :slight_smile:
They are simplified HOME dedicated devices with not to many knobs to be changed so it's possible but RouterOS is one for all. maybe SohoRouterOS could we installed but what for? Mikrotik is not a simple "install&forget_forever" brand. You buy it as it is quite cheap and gives you a lot of guilty pleasures when you bend it to do what you want :slight_smile: :slight_smile:

It's totally different story. +1 to that.

12

But at that point, clearly, it's no longer the same model...

There are obviously tools (/export & co.) to configure another device in the same way,
but if the device isn't identical, it's too much to imagine that for each device,
the internal software must adapt how VLANs are configured, specific switch commands,
FastX optimization, folders on NAND or XOR,
and a thousand other things that would then need to be re-adapted with each new version.

Summary: There's /export, there are scripts and the rest, and they're more than enough.

For those who really work with it, they're enough;
for home geeks, at least they get some training,
because if someone still hasn't understood that backing up to another machine should not be done,
(unless a complete replacement with an identical device is required following a full failure / emerjency replacement),
well, they really don't know how to use own devices to do their job...

P.S. about other brands:
Of the Ux peripheral models I've used so far,
I can take the text backup and load it onto another machine. The MAC addresses aren't duplicated.
From the S/N to the MAC addresses, each one remains unique.

If, however, I take the text backups of the Cx,
and I'm not careful to remove the MAC addresses from the backup,
everything will be duplicated...

13

@BartoszP

Come on, a check box or an option when using restore like "reset mac addresses" would cost what?

14

@jaclaz

Come on :), you know that it is only of begining of the jurney. If "reset-macs", then why not "reasign-interfaces", "ugrade-filters" and so on?

15

In the past, RouterOS actually relied on the hardware ID number.
Often, due to micro-latencies or driver changes, the order would be reversed or mixed,
mixing everything up and ruining the configuration.
In the end, RouterOS team chose to index the devices in the order in which they were acquired,
but to store the MAC address so that the configuration was no longer based on the hardware ID,
but on the MAC addresses.

This made everything more stable on reboot,
but this make the backups unusable on other machines, causing configuration would be lost,
if the same MAC addresses were not reused again.

16

How to recover from the misuse of backup and restore?

Simply:
Apply this script on terminal

{
/interface
ethernet reset-mac-address [find]
wifi reset-mac-address [find]
}

then do one /export file=checkconfig and open the generated text file checkconfig.rsc (is a simply text file),
search all MAC addresses inside not fixed by the script and correct the MACs on the RouterOS config.

Done.

17

In my opinion, there should be an option in /import to ignore commands that do not apply to the device, e.g. those setting LEDs or LCD, or serial ports, etc so that the /import just continues with the next line instead of stopping right there and leave the router half-configured.

Another useful option (could be in /export or /import) would be to skip MAC address setting or to re-generate MAC setting on the target device. E.g. when a bridge has an explicit admin-mac, generate a new one from the first member interface of the bridge on that particular router.

Improvements like that would enable a smoother migration to a newer router with similar features.

18

I used the perfectrestore-script today on two RG750 routers I have awaiting install. The difference in software versions created some issues. hw-offload is supported in 7.20 but not 7.21. I confess the script is slick. Doff my hat to the developer that shared.

19

I will give it a try. I am curious to find what MAC it will change.

20

I made the post, to better understand the hidden gems that maybe you folks that have been around the block may have experienced. I'm focusing my efforts on the /import. Using the output with the restore script gives me some confidence I haven't overlooked anything.