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.

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.

Good ideas but, in my humble opinion, this post would fit better on the beta forum. I fear these good advices will be lost in a few months if this post remains on the general forum.

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.

A billion 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.

A billion times

+ 1 billion

time is money, and i have wasted a lot of money doing "find/replace" on Mikrotik configs....

I would also like to suggest the addition of:

Configuration Versioning
Configuration's on RouterOS would have "version numbers", each time the configuration is committed it saves it as a new "version"

Commit functionality
All config changes made in WinBox/CLI will appear, but will not be active until they have been "committed". Using the commit command, or winbox button will apply the changes to the router, and save the updated configuration with an incremented "version".

Rollback Functionality
By having versioned configurations, you would be able to rollback to any version.

commit confirmed
This would effectively replace safemode. When you "commit" the configuration with the "confirmed" option, the router would make the changes active but after a defined period of time without a "confirm" command being entered revert to the previous configuration version.

Basically, take the best parts of JunOS's config system, and put them in to RouterOS !!

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.

Oh I forgot to mention, yet again:

Add VTI support to IPSEC
The third most popular request on http://wiki.mikrotik.com/wiki/MikroTik_ ... e_Requests

Add NHTB support to IPSEC
related to the above, basically allows point-to-multipoint IPSEC tunnels...

And a layer 2 protection mechanism like PPPoE Option 82 http://forum.mikrotik.com/viewtopic.php?f=2&t=42698

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.

And another million here.

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.
Than, CPE's work with different AP's which means different SSID's or AP mac addresses and different ´connect-to´ rules.
And what about the names of the unit? In mass deployment operator would like to see which CPE belongs to what client so some naming has to be done in the system ID, radio ID and dhcp-cl ID.
All variables that connot be copied because they ID a single unit.

Now all these options can be left as default, and change these later, and have all the other settings copied.
Well, that already is available.
Most config's are already in default state by MT so all you need to make is a simple script doing the rest.
I have a .txt file with an installation script for CPE's.
Only the items that need to be changed are in that script, it is about 60 lines long.
I even fill in the varialbes if I know them in advance, like unit ID, SSID, freq. etc.
Each time I make a new CPE ready I just edit the sript (on some 6-12 items depening need) and copy it into the terminal, reboot, wait.... and done.... CPE ready for use..... how simple life can be!

It takes me 5 mins to prepare a new CPE and most of the time is spend on waiting the reboot after the new software update, and after the firmware update, and after the rebot needed to upload new settings.
With a little switch connected to my PC I can do 2 or 3 at the time....

So I don't see the billion demand for copy config...

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.

another million.

And add to the wish list:

• variables that can hold more than 4096 characters.
  output of fetch into a variable

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.

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 ...
You yourself are already stating "are unique to the location." How do you now to expect a copy system that knows all this?

Copying an router? Well, if the board is gone there is hardly anything to copy isn't it?
If the interfaces are gone, well in that case a copy won't work since the interface carry their unique mac addresses so you still need to manually arrange settings.
And if you are still able to copy, why not have the script of that routerboard saved (and edited each time after edits) as a file in that routerboard? All you need to do is download it in your ´to be copied´ board and boot the new board. Change the mac addresses in the process and you're done.

All routerboards come with a default MT-installation. If that doesn't suit you why not install your default when the boards come in? Once this has to be done anyway?

You explain to me how others can do a copy if almost every unit in each network has different settings to always give the need to adjust them manually.

another million.

And add to the wish list:

• variables that can hold more than 4096 characters.
  output of fetch into a variable

re-introducing LUA to v6 might be a suitable option to assist with this.

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.

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.

Besides, MAC addresses are not configuration, unless you explicitly change the MAC address of an interface. Your configuration should not deal with MAC addresses by default. The configuration that can be exported should contain only the statements necessary to configure any similar device with the same parameters.

Most other vendors have an exportable configuration

Like MT has.
Basically what you guys are asking for is a "copy" button in winbox that performs the "export" command in terminal and save the output as a file in the router. (Which is already possible with some extra scripting.)
All configs are copied in a second and cut and paste into another router will do the rest.

Now it depends on the unique variables that each router has, how much work you should have done or still have to do to make new router almost identical as the first one.
I can 't see any program able to predict these.... but tell me if they can, I'll stop eating fortune cookies...

I honestly don't know how else to explain this.

Maybe a simple example would work.

I can take a Cisco router that is running in production, and issue the command "show running-config". I can then copy that output into my clipboard. I take a second router that is the same make, model and software version, and has the same interfaces, and paste it in. I can then unplug router number one, plug in router number two, and it'll just work just like the first router did.

I don't need to edit the output, or do anything else to it. It just works. That is possible because the "show running-config" command only shows the commands entered that aren't the default in that software version. If I don't change the MAC address of an interface administratively, the router defaults to using the burned in one. I didn't configure it to do differently, so the configuration export doesn't contain any reference to MAC addresses. If I changed the MAC administratively then it'll reflect that in the exported configuration.

This works perfectly fine. There's no magic, or predicting any values. It isn't like Cisco are the only ones that do this they're just an an example. In fact, all other vendors can do this. Mikrotik stands out as one of very, very few vendors that can't do this.

How is this useful? It enables me to use my NMS to just download configs at night, and when I need to replace a router due to hardware failure, I can just paste the last known state in and can rely on that working. I don't have to figure out what to edit, I don't have to guess whether the router is going to work, I don't have to train other people on which parts to edit - things just work.

That, however, is just the basic feature. If you want most vendors can do versioning. I can go into a router before maintenance (be it planned or emergency), and can tell it to save its config. I can then work on it. If I need to go back to how things were before the maintenance I just tell it to roll back. I don't need to reboot it for that, or reset it to factory defaults to import the previous export. I don't need to manually undo changes, or restore a binary file (that would only work on that router). To take this even further, most changes are first tried out in a lab. With other vendors I can download the config from a production router and just apply it to a bench router of the same make, model, version, and inventory. This router now is exactly the same as the production router, they are completely interchangable. I can then make my changes, and at the end tell it to generate a delta between the two configuration versions. I can then, during maintenance windows, apply that delta to the production router and be confident that what I'm going to do will just work, since it worked in the lab on a perfect clone. I can also document just that delta in the change management system.

Even if you don't need that, it's clearly useful to many people, so I'm not sure why you're arguing against it. It's clearly possible as a feature, or all other vendors wouldn't have it as a feature. In fact, it's downright trivial to implement in RouterOS. Settings are obviously kept in a database, or we wouldn't be referring to items in lists by number, or get pointers returned when using "find" to return items. Add a column to the database that marks whether or not a setting it at default. Add a parameter to "export" that only prints settings that are not at the default. Boom, done. Or, rather, make that how "export" works because printing device and hardware specific default values like MAC addresses in a config is stupid and backwards. Require a parameter for "export" to show those settings because they are useless 99.9% of the time.

I thoroughly enjoyed reading the above post, and I wholeheartedly agree.

Me too.

Thank you fewi for your crystal clear explanation.

fewi's post explains it pretty well. Hopefully Mikrotik implement it!

Dual-Stack Lite
DHCP Option 82
Carrier Ethernet (Y,1731, 802.3AG)
MPLS-TP ???

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.

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.....

I also worked with UBNT and their options for the same is so much worse. I can only copy amongst units that share same network settings. All other variables I can only edit after I put it on the unit... takes me about 15 min each unit to prepare one.... (and every setting the need to ´accept´ followed by the need to reboot....pffff.)
I can only do this with a browser. What a pain ... (Telnet? I still found no one that can tell me the commands they use.... ) And than to think they have only 50% of the same editable options as MT.
Tried same once on a netgear router. The new one ended in the waste bin thereafter..... crashed beyond economic repair (new is cheaper..).

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.)
But 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.

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...

DHCP Option 82

already here for years, usable only with RADIUS =)

Dual-Stack Lite
DHCP Option 82
Carrier Ethernet (Y,1731, 802.3AG)
MPLS-TP ???

DS Lite will get my vote, DHCP option 82, well, see Chupaka's post.
The rest, well, Carrier Ethernet is so much outside the scope of MikroTik equipment, not mentioning MPLS-TP, MPLS-T and all those derivatives are not even formally sanctioned by the ITU yet...

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.

.. so it's just like a Cisco config then?
Only problem is as we all know and has already been mentioned, there's sections that CANT be copied from one device to another without breaking things.

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.....

The dude handles this fine IMHO, thou it could do with an option to check and do firmware upgrades too.

*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...

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.

The issue is that many of us are managing 100+ devices which we need config management/duplication/drop in backups for and it shouldn't take someone who's been using MikroTik for over a year just to work out how to do so.

But 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.

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 here

there's sections that CANT be copied from one device to another without breaking things.

sorry for the offtop, any example?.. thanks

sorry for the offtop, any example?.. thanks

Several posts above yours have already covered this…

sorry for the offtop, any example?.. thanks

Several posts above yours have already covered this…

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...

Unless you don't mind cloning your MAC addresses over other hardware…then simply running that command is fine.

Most of us enjoy unique MAC's in our network though.

so, if you remove "mac-address=bla-bla-bla" from /export - all the rest is fine?.. just want to know...

The rest of the sections I work with (I do not use wireless, MPLS, PPP, bunch of other sections) imports on a clean router after editing interface MAC addresses.

There are other idiosyncrasies, though, that make importing harder than it should be.

For example, if you take the export of "system logging action", there are default items and the items you configure. The export has them as "set" command for default items, and "add" commands for additional items. Since there are add commands, you first have to either reset to factory defaults, or remove the non-default items, or you're going to end up with duplicated entries, which will fail to import because of a duplicate name. OK, that's fine, but you can't run "remove [find]" because that fails saying you cannot remove default items (it errors out on the first one and then does not even delete all non-default items).
Another idiosyncrasy is that "remove [find]" in firewall filters removes all the dynamic rules created by enabling a Hotspot. So if I want to reset a firewall configuration on a router that also runs a Hotspot I either have to manually figure out which rules to remove first, or live with taking down the Hotspot manually and disable and re-enable all Hotspots after the remove and import to recreate those dynamic rules. Yet dynamic rules of course don't show up in exports, and cannot be edited. They shouldn't delete, either then.

So I'd really like just a smarter CLI. Either change the syntax, or make it so that an add for an item that already exists really becomes a set, or a global flag that allows me to tell the router to interpret it that way temporarily. I would like to be able to run the equivalent of "configure replace" in Cisco IOS.

None of those are unsurmountable problems, but the workarounds are not trivial, so it takes way more training than it should.

Here is a stupid one.

Make Traceroute,Telnet and SSH global commands.

So we dont have to /tool for a simple traceroute.

you can't run "remove [find]" because that fails saying you cannot remove default items

"remove [find]" in firewall filters removes all the dynamic rules

well, one may use "remove [find default=no]" and "remove [dynamic=no]" correspondingly...

I know. But that's what I mean by things being too hard, and requiring too much training.

None of these issues are unsolvable problems. I just shouldn't have to solve them at all...

well, any my configs for managed switches start with "reset configuration" line =)

I don't know details about "configure replace", but "/system reset-configuration run-after-reset=new.rsc" sounds similar...

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.

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.

I agree, we all have our points and lets hope MT peeps over our shoulder and pick some suggestions to improve ros wherever possible.

no argue, just wanted to see how deep the problem is. seems like ROS has its a bit own way of config management - we just need to understand it, at least in v5 =)

As Chupaka mentioned "configure replace" in cisco looks the same as "/system reset-configuration run-after-reset=new.rsc"

There were also some good suggestions that we could use to improve configuration import. If you have any other suggestions how to improve config import/export, share the ideas here.

One fairly big difference is that configuration replace doesn't require a reboot, and only applies delta changes while keeping packets forwarding on all interfaces and services not affected by delta changes.

But I am very glad you guys are reading the thread!

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?

another million.

And add to the wish list:

• variables that can hold more than 4096 characters.
  output of fetch into a variable

Is it better to quote oneself or edit?

Anyway, I left off my list: https fetch

I usually setup an openwrt metarouter and use wget for this.

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?

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.

It would, however be interesting to see if you could do hitless linux and then essentially RouterOS upgrades using kexec. At least for the sake of the experiment, I would love to hear more about this.

+1 for plain text config files. We store a lot of data in source control and being able to pull or push router configs to svn or mercurial at each change for a ...drumroll please.....configuration changelog!! would be awesome. This is already an capability we can exploit on cisco with an ssh key and a show run.

I really enjoyed reading this and I share fewi point of view.

I hope that fewi suggestions become true on v6.

Good weekend to everyone.

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.

Many of these things, specifically your items: "Control plane and forwarding plane separation"; "More standards"; "CLI cleanup"; would be answered quite well by adding support for the OpenFlow software-defined networking standard. See my thread: http://forum.mikrotik.com/viewtopic.php ... t=openflow. Let me know what you think.

Furthermore, _any_ kind of scripting language would be nice, as long as it gives me good facilities to work with. I've been thinking about how I could implement a passive-monitoring program that quantifies the quality of a link using a number of metrics (latency, packet-loss, RTT, SnR) and allows me to prioritize or disable paths based on that metric. As far as I can tell, there's no way for me to accomplish this directly on the router. I'll have to write an external program that uses a span port to monitor traffic. I could probably accomplish this with OpenFlow, if it were implemented, but I'll settle for a good scripting language! =)

What I did not like about version 5 were all the instabilities and bugs that happened to me during these versions. Not that such did not happen with v3 for example but it's too much.

Make a "WinBox" for BSD and that's it.

I don't see how I will have to pay for multiple Level 6 licenses for HA configurations when RouterOS is so buggy .

+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!!

+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!!

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!!

VRRP?

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 )

up
any news guys????