This, a million times.It is still not possible to extract the full configuration of one device and import it into a new device. The built in backup system is device specific, and heavy editing of an configuration export is necessary to make it importable on another device.
A billion timesThis, a million times.It is still not possible to extract the full configuration of one device and import it into a new device. The built in backup system is device specific, and heavy editing of an configuration export is necessary to make it importable on another device.
+ 1 billionA billion timesThis, a million times.It is still not possible to extract the full configuration of one device and import it into a new device. The built in backup system is device specific, and heavy editing of an configuration export is necessary to make it importable on another device.
This, a million times.It is still not possible to extract the full configuration of one device and import it into a new device. The built in backup system is device specific, and heavy editing of an configuration export is necessary to make it importable on another device.
Well, still I don't see the issue. 200 or 20.000. The more units you have the bigger the change some variables are different ...Not to be mean, but you've said elsewhere you have 200 customers.
We run 200+ routers, 2000+ switches with over 40,000 interfaces, and 4,000 APs. Our deployment and management procedures are likely very different from yours.
Setting aside connect list on APs for a moment (we don't use Mikrotik for APs at all), it's completely common for all other product we use to allow you to copy and paste a text configuration from one router to another to clone it. For router interfaces MAC addresses are irrelevant (unless you do some crazy manual ARP stuff that doesn't scale beyond a couple of nodes). When a router fails and I need to deploy a replacement I don't want to have to spend time mucking around figuring out which parts of the configuration I should delete in a text editor, and I don't want to have to rely on a connection back to the configuration repository to find the initial deployment script for that site (which likely wasn't updated anyway last time tier one made a change, and yes I will find them and chew them out for it, but that doesn't help me at that moment). I want to console into the failed router, issue "/export generic=yes", copy/paste that AS IS into a new router, replug some cables, and be up and running. Partly because I may be thousands of miles away, talking on the phone to the only warm body that could be found at this time of night, who unfortunately only has minimal training.
Setting up a CPE with a cookie cutter approach is different from setting up a router with network interfaces that are configured according to general network policy, but are unique to the location. Sure, you might have to change some connect lists on the other side after the swap, but this would still get you 99% of the way there.
re-introducing LUA to v6 might be a suitable option to assist with this.another million.
And add to the wish list:
- variables that can hold more than 4096 characters.
output of fetch into a variable
Have you ever worked any other types of gear besides MT? Most other vendors have an exportable configuration, and that feature is simply a life saver, and makes a lot of difference in any large network, where you can use tools like RANCID to backup your router configuration and have it ready to be imported into a new device in a matter of seconds.I don't see how MT could make a config copy feature to your wishes..
Each interface has its unique mac address and since the mac address comes in respect in several settings all these have to be done manually anyway.
Like MT has.Most other vendors have an exportable configuration
already here for years, usable only with RADIUS =)DHCP Option 82
DS Lite will get my vote, DHCP option 82, well, see Chupaka's post.Dual-Stack Lite
DHCP Option 82
Carrier Ethernet (Y,1731, 802.3AG)
MPLS-TP ???
.. so it's just like a Cisco config then?fewi, and supporters;
What you showed in your examples I can do for 95% with MT.
In fact, all my important routers send me either a daily or weekly backup that I can use to set-up a new one in case of hardware failure. Basically it cost me 2 mins to prepare a new router.
As a bonus I get a .txt file that is easy to read and to edit without the need to upload it or to have a special editor program.
The dude handles this fine IMHO, thou it could do with an option to check and do firmware upgrades too.I have a script for setting up CPE's. Last week I made 10 units in about just over an hour ready for deployment in different AP networks. This preparation also means upgrade of the OS and firmware so yeah, most time is spend in waiting for the reboots.... I used that to read my morning paper in doing this.....
You're preaching to the choir here, we all already know exactly how the MT backup works as we've been using it for years, what people like Eising, Fewi, I and others are trying to do is make workable suggestions that would make things easier and comparable to other vendors.. come up with a new solution that makes more sense, one that MikroTik can investigate implementing.*snipped*
So, what you guys want is already possible for the most, but with some extra functionality on top.
I am not saying other vendors can't do better, there always will be some that can. Or that MT cannot try to improve things, they always can. (They get enough ´feed´ from my end too.)
*snip*
I am happy with it, and probably a lot of more users, even some many times bigger than me. If you're not, enjoy all the other benefits of MT above others....
And maybe one day your wishes will be fulfilled by MT. Who knows! They obviously read this...
This thread is for suggestions, so it's natural to assume that people would be putting in ideas for better ways of doing things. Obviously we're all using MikroTik otherwise we wouldn't be hereBut in this tread it looks like MT has a poor way of copying and saving configs. Which I tried to show you guys it is not as bad as you present it.
sorry for the offtop, any example?.. thanksthere's sections that CANT be copied from one device to another without breaking things.
Several posts above yours have already covered this…sorry for the offtop, any example?.. thanks
there were mentioned some problem with MAC addresses, but, for example, /interface ethernet export, should work on any router with the same number of ethernet ports - that's why I wonder...Several posts above yours have already covered this…sorry for the offtop, any example?.. thanks
you can't run "remove [find]" because that fails saying you cannot remove default items
well, one may use "remove [find default=no]" and "remove [dynamic=no]" correspondingly..."remove [find]" in firewall filters removes all the dynamic rules
I agree, we all have our points and lets hope MT peeps over our shoulder and pick some suggestions to improve ros wherever possible.Edit: kinda done arguing about it.
I'd very much like better config management. I'm aware of the workarounds and tricks, and am indeed making do. However, I'd rather spend my time on other things.
Last post on the matter.
Is it better to quote oneself or edit?another million.
And add to the wish list:
- variables that can hold more than 4096 characters.
output of fetch into a variable
on big ciscos (as well as big junipers, alcatels, ericssons and what not) this happens because they have two supervisor modules that are essentially computers that program the chips (ASICs, FPGAs) to do the actual forwarding.on big Ciscos, you can upgrade firmware without single packet loss =) any chance to enable 'kexec' kernel feature (at least for x86) for quick reboot without rebooting the hardware?
Hello,
When v4 was released I did a post about things I would like for v5. Now v5 is out and finally reaching stability, I would like to share my thoughts about the direction I believe RouterOS should go.
CLI cleanup
The CLI has remained somewhat unchanged the last couple of major releases. Having only been working with RouterOS since the early 3.x releases, I can't make any generalisations, but in my view, there hasn't been any major changes to the CLI. Obviously new things have been added, such as a complete revamp of most build in systems, notably complete rework of SNMP, SSH and ping.
However, basic issues still exist that I find a bit frustrating, and there is one major feature I would like to emphasise:
It is still not possible to extract the full configuration of one device and import it into a new device. The built in backup system is device specific, and heavy editing of an configuration export is necessary to make it importable on another device.
A rewrite of the configuration system to allow a direct export that can be used as a real backup is in my opinion the most basic and useful change that can be done for v6.
Furthermore, it would be really great to see some sort of transactional configuration model implemented, as seen on Juniper routers. To be able to roll back entire configuration steps and see changes done would be a really handy feature.
More standards
It would be beneficial if RouterOS dropped their current support for CDP and switched to LLDP. LLDP is the open standard alternative to CDP, and as such a much better protocol to implement, as it would integrate much better in a mixed vendor environment.
Remote Flashfig
A remote FlashFig would be really handy. I am here thinking of a system that allows you to send out unconfigured devices and let them fetch their configuration automatically at first boot. This would ease mass deployment.
LUA!
What the heck happened to LUA? You tried to implement LUA in the early v4 betas, but after that it was apparently completely dropped. Will you try again?
Control plane and forwarding plane separation
Now that multi-core processors are becoming widespread, it would be beneficial for the stability of RouterOS powered device if you could split control plane and forwarding plane to different CPU cores, so if something drags the control plane down forwarding would still function.
These are my first thoughts for v6.
Let me know if there is anything you need clarified.
VRRP?+1 for
Implement High-Availability
Allow Mikrotik routers to be put into an active-passive "cluster" where configuration is automatically synchronized between cluster members, IP addresses/MPLS/VPLS/BGP/OSPF/PPP are only active on the active unit. A device failure is detected by interface status, loss of ping, or loss of heartbeat and the passive unit will take over as master. See Fortinet's implementation for ideas, it is the best I have seen.
is VERY VERY VERY important
an hardware with all port bypassed and support for HA can breake the market!!
Yes VRRP is great thing and thank you mikrotik guys that it is included in routerOS, but we need more, like sync firewall, nat, dhcp leases etc. (without scripting )VRRP?+1 for
Implement High-Availability
Allow Mikrotik routers to be put into an active-passive "cluster" where configuration is automatically synchronized between cluster members, IP addresses/MPLS/VPLS/BGP/OSPF/PPP are only active on the active unit. A device failure is detected by interface status, loss of ping, or loss of heartbeat and the passive unit will take over as master. See Fortinet's implementation for ideas, it is the best I have seen.
is VERY VERY VERY important
an hardware with all port bypassed and support for HA can breake the market!!