I am not very experienced with mikrotk and I have got the following problem.
I have got mikrotik RB450G.
If I restore backup of the same model (RB450G) to my present router, I noticed that very strange for me effect. Let say that we have bridge1 which included ether1 to 4 and ether5 is used as WAN interface. To the router connections are to ether1 (LAN) and rther5 (WAN). I see the traffic goes through interfaces ether1 and ether5 in Interface window.
Next, I restore backup from another router from the same model (RB450G).
When the router restarted, I saw that the traffic goes through ether2 and ether4. I unplugged the Ethernet patch cable from port 1 and connected it to port 2. In interface window, I see that the traffic goes through ether5 interface.
If I reset the configuration, and next remove the default one and next I set the configuration through terminal window (paste the already exported commands /export compact file=xxxxxxxxxx/), on Interface windows, the traffic correspond with the connected Ethernet patch cable to the ports.
Can you explain me the behavior and recommend how I can restore backup configuration properly without such effects? This will happen when I got backup of a device (RB450G), change the device with another one and restore the backup from the first device to the new one.
There is not AFAIK a proper, automated, mechanism to “clone” the configuration of a device to another one, even if it is the exact same model.
The backup is intended to be restored ONLY on the SAME device.
The possible approaches are:
(as you are doing now) remove configuration and copy and paste a saved export in one which has in some cases (slow device, complex configuration, whatever) issues as the “import” of the pasted data “chokes” the device
do a “reasoned” copy and paste of snippets (sections) of copied data from an export, this may create the issue that since the export is in alphabetical order (and not in a “logical” order) one has to be very careful when complex configurations are involved, as it is possible that access to the device depends on something that is “later” in the export and pasting the first part sets something that prevent access breaks the connection with terminal/Winbox
Indeed. The “help” text is quite confusing, it talks about “cloning a router configuration” but that suggest that you can use that to generate similarly configured devices, and that is not possible with “backup”.
The “can then be re-applied on the same device” has to be read literally: you can apply it to THE SAME BOX.
NOT to another device of the same type.
So indeed you have to use “export” and “cut/paste”. What jaclaz writes is not correct, you CAN apply the exported config in the same order as it was exported.
However, you usually cannot paste an entire export file into a router, because there will be default or previous config, and pasting the export will ADD to that, leading to invalid config and/or errors due to duplicate items.
The closest you can get is do a reset configuration without defaults, then connect to the router via MAC address and paste the config there. Even then there will be some items that are auto-generate, e.g. the “configuration without defaults” still tends to have a DHCP client on port 1, which you have to remove later when you do not need it.
You can type /export on the empty router (connected via MAC) and you will see what has been automatically inserted and what you have to remove later.
Well, anecdotally, jaclaz managed to lock himself out at least once by doing that, if I recall correctly it was due to a conflict between the assignment of ethernet interfaces to LAN or WAN interface-list (which is in the early part of an export) and the mac server winbox while experimenting with VRF’s. Of course it is possible that either the pre-existing or the applied configuration was botched beyond the imaginable, still it happened, and since then I started paying attention to what I copy and paste, and in which order I do that, maybe it is excessive, cannot say. But the configurations I was testing with were - when compared to many of the ones I see posted on the board - very simple, so I adopted a better be safe then sorry approach.
MT Docs, first line: The RouterOS backup feature allows cloning a router configuration in binary format, which can then be re-applied on the same device. https://help.mikrotik.com/docs/display/ROS/Backup
Many thanks, to all of you, makin notes on that problem.
This is just the first time is face this problem and I was quite surprised at the beginning.
I understand that pasting commands as script in terminal windows is my only option.
The problem I face that at some point, pasting the configuration in terminal windows make router to restart at some point and my observation are that different parts of program are loaded. I am not aware, which part of configuration make the restart. I suppose that this is bridge configuration and adding the ports to it.
Next time I paste the configuration, it is OK, but the rules in firewall are doubled!
So obviously it is long try and test business.
As my friend point today, restoring mikrotik configuration on another device, it is not for untrained users!
You can NOT paste the configuration a second time!
Each item of the configuration has to be pasted exactly once.
When you somehow need to interrupt the process, you need to restart exactly at the correct point.
Well, I have reconfigured entire routers this way and never encountered “router restart”.
More likely you lost the connection and had to re-connect (and logon), but the router was running as before.
But yes, it is a tedious process that requires experience and patience.
It would be helpful when MikroTik did something to improve this situation.
As it is now, “upgrade to a different model keeping configuration” and “rollout of several routers with similar configuration” are quite difficult on MikroTik routers compared to some other makes.
It is possible to rename router’s interfaces and some (perverse) admins rename them to names which resemble original names exactly … effectively reordering interfaces. You can check if this is the case by checking output of /interface/ethernet/export (the stuff in the “main” branch, not in sub-branches such as …/ethernet/switch/) …
If it’s remotely like this, then you’re looking at result of twisted mind:
/interface ethernet
set [ find default-name=ether1 ] name=ether2
set [ find default-name=ether2 ] name=ether3
set [ find default-name=ether3 ] name=ether4
set [ find default-name=ether4 ] name=ether5
set [ find default-name=ether5 ] name=ether1
Actually you’re still stuck because set uses construct “[ find default-name=… ]” and default-name doesn’t change.
But if code was run from “default” state, then it would fail even the first time … because only one interface can have certain name and running first line (which renames ether1 to ether2) would result in having two interfaces with same name (ether2). It is possible to create a script which would actually run (one interface would have to be renamed twice, first time to some random garbage “to make space” and second time to final name), but the end export wouldn’t include that construct and would look just like I showed in my previous post.
Actually that happens “all by itself” when you restore a backup on a different device…
Apparently there is some internal device identifier that may get remapped to a different actual interface when the corresponding physical interface does not exist.
