Feature Request: Optional ability to restore without keeping MAC addresses
Mikrotik backup and restore do work pretty well for restoring a backup on the same device that originally created the backup.
however -
When a restore is performed on a different router that did not originally create the backup , the interface MAC addresses on the 2’nd router are changed to now be the original MAC addresses from the router that created the backup.
There are times this re-write of MAC address may be desired or not desired.
My problem with this re-write of MAC address when restoring a Mikrotik :
As in ISP , we use hundreds/thousands of identically configured Mikrotik routers.
When we configure a new Mikrotik CPE , we restore a master configuration on the 2’nd Mikrotik - then must perform a /interface ethernet reset-mac-address
for each interface.
Then after the MAC address resets, the new Mikrotik CPE router is ready to be installed and added to our customer ISP network(s).
This process is time consuming and subject to a technician forgetting to reset a MAC address ( which can create network problems ).
Also , a backup ( or updated backup configuration ) can’t be restored to a 2’nd remote customer located Mikrotik CPE router. When the remote router reboots after a restore , the MAC address are changed and the remote Mikrotik CPE router is no longer communicating - which now will require an on-site technician to correct the issue. (( note - all networks must have unique MAC addresses for every device on that network ))
I request a feature to Mikrotik to update/modify the Mikrotik restore function to have a new option to not restore interface MAC addresses when a restore is performed.
IMO :
This new feature in the Mikrotik restore function should default to re-write interface MAC addresses ( normal restore ).
When restoring , a new optional selection to not restore interface MAC addresses.
*** This requested feature would also allow the ability to bulk update newer master configurations to all of my remote located customer Mikrotik CPE routers.
As a (W)ISP I do everything you wrote about, without the slightest need to restore .backup files from other devices, but using only configuration scripts.
Is there a really valid reason why you have to use the .backup file instead of using the .rsc ???
One could automate it, true. But, really, why not just make a checkbox (or CLI parameter) saying "keep the device MAC"? I mean, You - as a "BIG GREAT ISP"® - can do wonders. What about us, small users/medium business technicians? Yes, we could do the same. But... why? Just let us export the backup from (say) RB5009 DEAD to RB5009 NEW. So much easier...
Great, if you then explain to me how you export the backup from a dead device without extract nand/flash and put elsewhere, etc.
And if she’s dead, who cares if the new has that old MACs… (in fact, it could sometimes be an advantage…)
Because it’s easier than managing .backup
It doesn’t matter how big the company is.
If the machine makes .backups for… backup…
it’s worth making the .rsc that imported into a “blank” device does not duplicate the mac-addresses at all.
If the device is different MODEL, no matter what happens, it remains different model, both the .backup and the .rsc would still have problems.
Re: … As a (W)ISP I do everything you wrote about, without the slightest need to restore .backup files from other devices, but using only configuration scripts.
Is there a really valid reason why you have to use the .backup file instead of using the .rsc ??? …
OK - here might be a good reason :
You have multiple remote customers
Those remote customers may have slightly different configurations ( but they all pretty much do the same thing )
Some of those remote customers may have different parts of the updates already configured.
Your new master configuration has ; new users , changed passwords , updated configurations and changes.
You need to make a rather large .rsc file to cover all possible remote customer configurations - so you might have to write/modify your .rsc to function with some programming functions to be able to work properly on customer routers that do not have identical configurations. You might also have multiple files and scripts you are wanting to also upload to those remote customers.
Configuring a do-everything .rsc can easily be beyond the capability of most Mikrotik network admins.
However , if the restore had an option to not re-write MAC addresses , then just about anybody could make a backup and use that backup to make a clone router ( possibly replacing a router , possibly making a dozen clone routers. A restore with an option to not restore MACs , should save time because you don’t have to worry about .rsc files and testing them first.
As general matter, tend agree with @rextended that with some config-based approach (netinstall/branding/run-after-reset) to the problem. But at same time… .backup does get you an exact copy, not merely just the equivalent config. At end of day, both approach have some pro-and-cons & require you develop some system around it.
I do think some “reset-mac-address=yes” on /system/backup/load is not a bad idea. For a [W]ISP/OEM/etc, whether you want to “unwind” a backup (mac-address), or “config from empty”…both require some DIY scheme…so more pick-your-poison situation if you ask me. If one went down the .backup approach, a small feature-ite to reset MACs on restore avoids one step in generalizing restored backup.
IMO, where both scheme fall down is if you want to “upgrade hardware” on an existing working router. If you had certificates, backup does get you “closer” to a working config… but potentially duplicate MAC is one problem in using .backup for “migration”. The issue is there likely more “restore EXCEPT” cases than just MAC address, like ac → ax devices.
They’ve been promising a “new controller” for a while, so perhaps there be some positive changes in config management there… or at least that been my hope. It is pretty tedious to maintain ANY approach to provisioning new routers today, so easy to see where the “without keeping MAC address” on restore be some incremental improvement.
You DO keep backups of Your production devices, don't You - oh holly and mighty?
You know, those pesky things we do, while things are working, in order to use when, well, they stop working?
You likely know this, but just in case & for the benefit of everyone else, instead of having to issue separate commands “for each interface”, you can shortcut this into a single command:
/interface/ethernet/reset-mac-address [find]
Knocks out all MAC resets for all ethernet interfaces in one blow.
You mean those things that usually fail to restore or cannot be found anymore when needed, as they strictly follow Murphy’s Law?
Seriously, the current backup system (I would call it an imaging system as the effect of restoring the backup is a “clone”) seems to me a good/handy solution for two use cases: #1 a device configuration becomes corrupted and you reset, netinstall and then restore the backup on the same device #2 a device fails and you want to quickly replicate its configuration to a second, spare, identical one you have already available
The request by North Idaho Tom Jones would make it suitable also to: #3 configure a number of identical devices in the shop before physically installing them in different locations #4 remotely netinstall/restore the same devices to that configuration
For these use cases (several devices with exactly the same configuration) it would also be much more practical to have a single “master” backup that “fits 'em all” as opposed to several individual devices backups (that could also applied mistakenly to the “wrong” device)
The (smart) workaround by NathanA:
/interface/ethernet/reset-mac-address [find]
will work for #3 (though the risk for the installing technician to forget the step is a possibility), but still #4 seems like not easily doable.
I don’t think that an optional parameter like “-YESIWANTTORESETMACS” would be difficult to implement by the good Mikrotik guys, and won’t create any kind of issue to people that don’t need or don’t want to use it, so the proposal makes a lot of sense to me.
My devices all do a backup in .rsc format on a centralized server at night, at an almost-random time (so as not to do them all at the same time)
And in the morning a very simple "diff" compares all the latest backups with the "master" version reporting the slightest change (except the first line). So every day I have an ultra-detailed report of every single comma changed everywhere.
this mean that the device for some reason is offline at the time of backup
Only in /srv/ftp/*******/master/CPE/: *******.rsc
this mean that "someone" on the device has disable the ipv6 assigned automatically from a pool
add disabled=yes eui-64=yes from-pool=dhcpv6-pool interface=bri-lan
As I had already proposed in the "controller" I would expect the same things done by the "controller"...
Ok, you can (must…) have multiple .rsc for each customer, like you have multiple .backup for each custimer…
My .rsc script ignore what is already updated
This is already covered from previous, but about users, I do not use at all .rsc
The configured device load system users from a remote server, so when the device go online automatically update users and passwords.
As I said before, each customer has identical configurations, meaning the customer’s CPE,
instead for each distinct company, each one has its own .rsc obviously, without mixing things together, as should be done with .backup files anyway
The main problem with .backup files is that if there is an error in the various databases where the configuration is,
or “surprises” left by the migration from one version to another (you can read hundreds of cases on the forum) they carry the defects of one device to the next, without the possibility of correcting them.
Instead, restoring a .rsc after netinstall without default config, or sometimes simply a reset with no-default cleans up often the mess.
Ok, I could have said "import the backup from...", but, really? Occam razor and all? While debating backups, and how to better the backup software, why one would think that someone was asking to extract the flash from it? Isn't it far more reasonably to assume the backup file?
And, Yes, it's still a pet peeve of mine. We should be able tom use backup from one device into another, as long they were the same model. And no, export isn't good enough - some things aren´t exported.
-- EDIT --
Yes, I know we can do a mac reset. But official guidelines are (were, last I checked) not to do this. It would be nice to get this finally wrapped up.
The only other non-Ethernet hardware interface type I can think of that RouterOS supports and which also uses MAC addresses would be WiFi interfaces.
I was going to note that ‘reset-mac-address’ does not exist for WiFi interfaces (you can ‘/interface/wireless/reset-configuration’ but that wipes EVERYTHING, not just MAC), and that even if it did the existence of VAPs just complicates the whole issue. But! It appears that MT finally added ‘reset-mac-address’ to both the legacy ‘wireless’ and new ‘wifi-qcom’ packages/drivers, in 7.17:
*) wifi - added option to reset MAC address (CLI only);
*) wireless - added option to reset MAC address (CLI only);
Though it is nice that they finally added this, the fact that VAPs exist of course still do not make this a completely straightforward problem to solve, since a VAP naturally does not have a native/“burned-in” MAC that you can “fall back” to. Now, if you create a new VAP from scratch, then by default ROS will take the MAC of the master interface and +2 the first octet; every additional VAP made after that will take the MAC of the previous VAP and +1 the last octet. But you can also choose to come up with your own completely different MAC at the time of VAP creation. If you ask ROS to reset the MAC of a VAP, how does it know what your intentions are about how you would want it to be numbered?
It looks like MikroTik took the easy way out, and just decided to throw an error if you try to execute ‘reset-mac-address’ on a non-physical WiFi interface:
[admin@MikroTik] > /interface/wireless/reset-mac-address wlan3-vap
failure: not supported
This will probably stop a script dead in its tracks, if one indiscriminately executes ‘reset-mac-address’ on all interfaces that are listed under /interface/wireless and at least one VAP exists in there. But if a binary .backup includes VAPs, you won’t have a good time if you don’t change their MAC addresses…multiple identical BSSIDs are going to cause problems for WiFi clients. And there is no way I have found, aside from deleting the VAPs and recreating them from scratch, to cause RouterOS to re-compute a new MAC for a VAP while taking into account the MACs of both the master interface as well as any other VAPs that exist.
There is a similar problem with all other virtual Ether-like interface types that exist within RouterOS, such veth, EoIP, VPLS, virtual-ethernet/vif (if on MIPS or PPC), and so on. There is no underlying hardware that can be referenced if one were to hypothetically ask RouterOS to “reset the MAC”. If you create one without specifying a MAC at the time of creation, RouterOS generates a random one. But the value it generates gets statically saved within the running config: it will be saved to .backups, it will show up in .rsc '/export’s, etc. And you can never ask it to re-generate a new one…‘reset-mac-address’ doesn’t exist as a command for these, and trying to do something like ‘set mac-address=“”’ just results in an error of “invalid value of mac-address, mac address required”, requiring you to actually generate and specify one of your own if you actually want to change it, again making the easiest solution to blow the existing virtual interface away and re-create from scratch. (If one wanted to get creative, rather than coming up with a proper randomizer script that can generate valid MACs, I suppose you could script something up that creates a temp/throwaway EoIP interface, copies the MAC generated from that to a variable, deletes the EoIP interface, then assigns that MAC to the virtual interface of your choice.)
Some kind of thoughtful solution to the problem of re-generating new MACs on virtual Ether-like interfaces needs to be solved within ROS first…asking for this to exist during restore of a backup when it can’t even be done easily on a running system is jumping the gun a bit (though it would be nice if the problem was addressed in both places).
As things stand, I would tend to agree that .backup files are not the proper way to do cookie-cutter router programming/config. Configure up a router to act as your template, /export that config, then edit the export by hand one time to strip out any references to static MAC addresses. Import that .rsc on the routers you want to stamp out, rather than restoring a .backup. Problem solved.
.rsc vs .backup ; Both have their advantages and disadvantages and neither as of today is KISS ( Keep It Simple Stupid ).
With .rsc , you have an added layer of complexity which may require editing your .rsc files ( and have a full understanding of all the configurations lines in the .rsc file ) when creating a file to be used to make identical clones of the original router. Also , when importing a .rsc file into an off-site router to update it’s config , there is a possibility your .rsc file may be missing something important which could result in loosing connectivity to the remote device being updated.
IMO , The ability to restore a .backup with a optional feature to keep-or-loose MAC addresses appears to be much closer to KISS, and would be much easier to understand and be used by most admins.
Also , what I propose re MAC the address option during a restore could be used on another already configured router ( with other users & passwords & wireless configurations & routes & … & … ) and quickly make it an identical clone. With .rcs import files , the .rsc import file could be very complex and not every possible existing configuration accounted for in the modified .rsc file - which could result in problems.
This is generally solved by only importing .rsc on routers that have had their config completely wiped first, and NO default config on them (so, “/system/reset-configuration no-defaults=yes”).
.backups are a nice feature, but it seems clear that MT specifically intends for them to be actual backups (hence the name), not as a means of making cookie-cutter config templates. Part of the problem with .backups is that they really only restore cleanly in the event that you are restoring them to the EXACT same model of device that the backup was made on, otherwise the config from any interfaces is completely lost or mis-applied to the target router anyway. So people who don’t understand that limitation are still going to encounter problems. And the only work-around to that problem, if you use lots of different RB models, is to make multiple different .backup files, one per model. Which then increases the work-load needed to maintain them dramatically…every time you want to update the config or make a change that would apply to all models of RB that you deploy, you would have to re-generate a bunch of new .backups for ALL models. So .backup files can’t be turned into a true “KISS” approach to config templating simply by adding the proposed “MAC wipe” feature. This other problem with mapping old interfaces to new ones would also need to be solved as well…and is a much more difficult problem to solve, with no really clear and obvious simple solution to it.
There are so many OTHER places where MAC addresses are used,
like ethernet interfaces, bridges, wifi/wireless (also station-bridge-clone-mac),
eoip-tunnel and eoipv6-tunnel, virtual ethernet, virtual wifi/wireless, wireless60G, cap interfaces, ovpn-server
and surely others that I forgot.
Backup is backup. Period.
The correct way to make a template is to do it with .rsc
