My thoughts for v6

RouterOS General
1

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.

2

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.

3

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.

4

A billion times

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

6

Oh I forgot to mention, yet again:

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

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

7

And a layer 2 protection mechanism like PPPoE Option 82 http://forum.mikrotik.com/t/feature-request-pppoe-option-82/38611/1

8

And another million here.

9

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… :confused:

10

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.

11

another million.

And add to the wish list:

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

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.

13

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

14

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.

15

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… :smiley:

16

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.

17

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

18

Me too.

19

Thank you fewi for your crystal clear explanation.

20

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