This is my first forum post, that I am making in genuinely trying to get MikroTik to see pain points of most MikroTik users, especially SOHO/Home users and even professional network engineers too.

Every vendor in the network world has their own flavours and implementation for configuration abstraction front-end for exposing the UI/UX to the human operator, whether it's CLI or some JSON over APIs.

There's the ugly Cisco CLI, there's the tactical CLI from Juniper JunOS & VyOS, and there's the modern-day DevOps/Linux-y friendly CLI/API from Nokia SR-Linux.

MikroTik is obviously a unique network vendor in both the type of hardware they sell and produce and support in the last 20+ years. And due to this large portfolio of devices, it's understandable why MikroTik has excessive tech debt in their software stack that prevents and overnight migration to JSON-like CLI like JunOS or DevOps styled SR-Linux.

The challenge however is that there are too many ways to configure different hardware models from MikroTik, especially on layer 2, 2.5 and 3 (VLANs, bridge, VPLS to bridge or no bridge etc), this leads to confusion as evident on this forum itself, every day, every month every year, we see even professional network engineers struggling with MikroTik's bridge/VLAN configuration or many other aspects of configuration in general, like BGP on RouterOS v7, it's simply not readable-friendly through the CLI, with the “.” weird syntax.

I'm well familiar with Linux Netfilter framework, Linux bridge VLAN-aware and worked with Cumulus Linux as well, but never have I seen so much confusion as MikroTik's implementation.

Of course, I'm known on this forum to be a bit of an asshole, but this time I decided to look at this issue with an open mind — The reality that I have to accept is that, the abstraction model for RouterOS configuration is too heavy with tech debt, leading to issues for users, even those who are experienced network engineers and have worked in the industry for 20 years+. While I personally managed to avoid bridge/VLAN debacles by following the official docs, it doesn't mean it's a great experience, it's way too much inconsistency and lack of resilience across hardware upgrades etc:
https://help.mikrotik.com/docs/display/ ... +switching

This is probably because MikroTik supports almost ALL of their hardware, leading to excessive tech debt that impacts their modern hardware products, I think it may be time for MikroTik to potentially consider ending such excessive long-term software support in favour of avoiding tech debt OR have two different versions of RouterOS, RouterOS Legacy for older hardware with the old config abstraction model, RouterOS Modern for newer Marvell hardware with proper 2024-grade CLI/API abstraction models like other vendors.

You can also look at VyOS, which is open-source, yet it doesn't have config abstraction tech debt/complexity that leads to excessive confusion or misconfig for users.

It's also unclear if MikroTik is using switchdev, or some NIC offloading with Linux bridge VLAN-aware implementation on some models, or purely Marvell SDK on Marvell chips? Lack of in-depth CCIE-level documentation on RouterOS is also another pain point.

It's probably easier for MikroTik to implement something like SR-Linux, considering both SR-Linux and RouterOS are both Linux kernel underlay for the control and management plane:
https://learn.srlinux.dev/blog/2024/vlans-on-sr-linux/

@normis/@MikroTik management, would it be possible for you guys to some day remove legacy RouterOS CLI/Abstraction model and do something new? One where configuration of bridge VLANs/VLANs in general etc are easy just like Juniper, Cisco, Nokia etc? On other vendors, misconfig doesn't lead to performance issues (issue unknowingly routing/bridging traffic through CPU).

Side Note: MikroTik uses Linux Kernel for RouterOS, it would be nice if they contributed back to the upstream Kernel (patches/fixes etc) like Nokia does, even better, let's move away from legacy bridge/VLAN implementation CPU-only products/paths and implement DPDK for maximum line-rate performance, let's move away from legacy iptables of MikroTik RouterOS and move to XDP for packet filtering, let's move to nftables for IPv4/IPv6 NAT and NPTv6.

It would be nice if MikroTik is open-source for certain components like Nokia, the community could help patch things faster, improve things faster, along with root access/shell login for RouterOS:
https://github.com/nokia/srlinux-yang-models

Some latest examples of the issue with abstraction complexity:
viewtopic.php?t=203326
viewtopic.php?t=204009
viewtopic.php?t=203981
viewtopic.php?t=143510
viewtopic.php?t=183336
viewtopic.php?t=204083

(slightly off-topic)

Not going to contribute a lot in the context of this post.
But I do get your point even though I nowhere have the same experience as you have with other vendors. So it may be interesting to follow where this leads to.
I certainly would like to see more from you with this style.

Nice way to start a discussion !

Yeah, but it looks like nobody cares. They must love the abstraction complexity of tech-debt ridden RouterOS.

Heck, can't even get MPLS/VPLS to work on the ASICs on CCR2k models, it's still CPU-only in 2024.

MikroTik lacks software engineering expertise, it's clear as day based on the facts we all know and the bugs and the lack of features (MPLS on hardware etc).

Why they never scaled up and take VC money like Juniper is beyond me. Look up founded date/year of Juniper and MikroTik, both started in the same era, one's rich, one's broke…

Lacking software engineering expertise. I certainly would agree.

Too much legacy hardware? Indeed.

Where are the examples of the ROS complexity?

I looked at the VyOS docs. Their config management is very interesting in terms of features like versioning.

But VyOS seems to be a full blown Linux OS. Why do we compare with embedded device OS like ROS?

A fair comparison would be OpenWrt. But their CLI and config management is crap TBH. And the luci webui isnt much better. Too sluggish.

From the very little I know of this OS and from the view point of a non-professional/casual user there are surely issues well before the "technical debt" or "abstraction complexity".

The documentation is scarce and extremely incomplete, the little that exists is poorly written and in some cases confuses more than helps.

The impression is that the help pages are written casually by people that either cannot or don't like to explain the way the commands work or how they should be used (and why).

There is an almost complete lack of "sane", "complete" examples, everything is fragmented and scattered throughout the Mikrotik site, most of what you can learn (as a newbie) comes from the forum (where the info is also scattered, but at least with some patience, lots of search, countless side deviations, it can usually be found).

At the level of the home/soho networking is not (should not be) brain surgery or rocket science, there can be what 3/5/10 types or common setups, it shouldn't be too difficult to provide a complete commented template for each one of those cases, reproducible in (say) CHR/gns3, tested and verified.

But, looking at the more complex setups/questions on the forum, asked by people that (seemingly) do have a networking experience before and besides Mikrotik's ways of doing things and at the replies by experienced people in both general networking and specific Mikrotik OS it seems like there is often no "canonical", "documented" solutions, but rather this or that "trick" coming from own personal experience or extrapolated from this (or that) MUM presentation.

If you look at the releases of new versions they are essentially an endless list of mostly vague one liners describing the change without any logic or order of relevance, either they do have a proper documentation for each change (but they don't publish it) or they don't have it at all, tertium non datur.

Besides calling "stable" what is actually at the most "beta" and calling "beta" what every other software house would call "pre-alpha" (after all what is in a name) the fact that in 1 1/2 month 7.14 beta had 6 releases, smartly called 3/4/6/7/8/9, each one touching almost every aspect of the OS, in many cases fixing new bugs introduced in the previous version the impression I have from the outside is that there is a push for publishing, no matter testing even in simple, basic test cases and an attitude to touch everything at the same time without any apparent priority.

Why they never scaled up and take VC money like Juniper is beyond me. Look up founded date/year of Juniper and MikroTik, both started in the same era, one's rich, one's broke…

One was so rich it sold out to HPE (who will ruin it). The other probably makes decent money for the founder/owner and staff.

The last feature that had some special attention was BTH. The rest is a lots of fixing and fixing of fixings.

But back to topic: I would wish to see a unified way to configure things one way. No more fooling around and reading all the - when they exist - warnings in doc: "if you have switch chip XYZ then DONT DO IT THIS WAY. then beware and set this FOO here and avoid BAZ here". This is a very error prone approach MT had chosen. why does ROS not resolve the caveats behind the curtains magically without having the user to know every aspect of any platform and what is wrong and right depending on just a piece of chipset/hardware.

why does ROS not resolve the caveats behind the curtains magically without having the user to know every aspect of any platform and what is wrong and right depending on just a piece of chipset/hardware.

Because MT obviously lacks a few developers to do something from start to end and not stop half way. They started great by hiding switch peculiarities behind L2 HW offloaded bridge. They are sticking to it for new products, but not all of them received offload (yet). But: they did not come around to do it for all capable older devices either (CRS1xx, CRS2xx, smaller devices with Qualcomm switch chips). And the new bridge is around already for ages. The way I read lack of HW offload on these devices is that they de-facto decided they were EOL but they are not willing to admit it yet.

Where are the examples of the ROS complexity?

I looked at the VyOS docs. Their config management is very interesting in terms of features like versioning.

But VyOS seems to be a full blown Linux OS. Why do we compare with embedded device OS like ROS?

A fair comparison would be OpenWrt. But their CLI and config management is crap TBH. And the luci webui isnt much better. Too sluggish.

Any network engineer who's worked with MikroTik, Cisco, Juniper, Arista, Huawei, Cumulus Linux will know what complexity. This forum itself is full of it. I'm not going to point out the obvious if you can't see it.

RouterOS supports MPLS/VPLS/BGP/OSPF etc, it's on par in terms of functionality with Cisco IOS variants, JunOS, VyOS, Nokia SR-Linux. No engineer would compare RouterOS with consumer-grade OpenWRT. How the hell do you run MPLS on OpenWRT?

+1000 to @jaclaz comments:
viewtopic.php?t=204023#p1053667

One was so rich it sold out to HPE (who will ruin it). The other probably makes decent money for the founder/owner and staff.

Doesn't take away the fact that Juniper hardware + software are carrier-class in the industry, even better than Cisco. Can you call CCR2216 as carrier-class?

Because MT obviously lacks a few developers to do something from start to end and not stop half way. They started great by hiding switch peculiarities behind L2 HW offloaded bridge. They are sticking to it for new products, but not all of them received offload (yet). But: they did not come around to do it for all capable older devices either (CRS1xx, CRS2xx, smaller devices with Qualcomm switch chips). And the new bridge is around already for ages. The way I read lack of HW offload on these devices is that they de-facto decided they were EOL but they are not willing to admit it yet.

If MikroTik cannot afford an end-to-end software engineering team who can handle NOS development from front-end CLI/API to back-end dataplane, then perhaps they should become like Edge Core and sell hardware with ONIE, let us install our own NOS instead.

As I highlighted in OP, VLAN-aware bridge is not the problem, it is easy to configure on Cumulus Linux or any Linux based NOS that uses switchdev/Linux DSA etc.
It is not “easy” on MikroTik even for someone like me who has Linux networking skill set. In fact, there's a lot of things Linux bridge can do, such as per-VLAN STP etc, that MikroTik cannot.

Well, for eg. configuring VLANs. I think that regular users would be much more happier if they had some kind of wizard or something to do that. Take a look at ubiquiti and how they have that solved.

I mean you can't satisfy all users but if Mikrotik is doing a push towards regular home users then I think that GUI needs redesign.

I don't agree on one thing. MikroTik creating “RouterOS Lite” or some crap, this will be dumb down their hardware capabilities, check Cisco, Juniper, Nokia “enterprise” APs etc, they are dumb as hell and can't do crap beyond basic functionality.

But, yes, WebFig/Mobile app overlay abstraction model (like TP-Link?) could be made for "lite” SOHO/End users who can't even differentiate BGP from OSPF, leaving full SP features intact in the core of the OS for SOHO users who create home labs etc and make use of MPLS/BGP etc. I run BGP in my own home as well, static routing is for peasants!

But, yes, WebFig/Mobile app overlay abstraction model (like TP-Link?) could be made for "lite” SOHO/End users who can't even differentiate BGP from OSPF, leaving full SP features intact in the core of the OS for SOHO users who create home labs etc and make use of MPLS/BGP etc. I run BGP in my own home as well, static routing is for peasants!

I am a peasant.

This said, real world anecdata, a few days ago I had the need to work on my laptop at the same time as with a workstation PC (don't ask) in a room where wi-fi is suboptimal, and I have only one ethernet connection (that goes in the PC) and - since I had literally in my hands a spare Ax lite (I was putting it on a shelf) I had the brilliant idea to use it as a dumb switch.
But then I realized that I had not any free mains socket free near the two PC's and had the even more brilliant idea to use it as a repeater for the wifi, placing it near a free socket a few meters away.
After more than one hour fighting with the stupid thing (and failing miserably) I took off the shelf an old TP-Link (TL-WA901N) and in no more than 10 (ten) minutes I had everything working for what was needed[1].
This probably means something.

[1] the quick setup guide is a two page .pdf:
https://static.tp-link.com/2019/201912/ ... QIG_V6.pdf
you setup a password, choose the desired mode (Range Extender in my case) and follow instructions.

We all are peasants when comparing with for eg. @DarkNate.

For someone who isn't into networking Mikrotik was my first real touch with networks and i got used to it so i don't really know how other vendors have GUI sorted. (Juniper, Nokia, Cisco)

But one feature that i would really love to see is PPSK.

I want to have one SSID no 5 of them... I used user manager and radius but problem is that i run out of sessions due to license limitation and it's really unnecessary complication...

The real issue here is MikroTik lacks software engineering expertise, may be financial reasons, may be understaffed, maybe both, maybe more, but they don't seem to care. Who the hell still sells NEW hardware with 32-Bit software in 2024, even? See below:
viewtopic.php?p=1052394#p1052389

Even tiny embedded industrial electronics in 2024, tends to be arm64 with 64-Bit Kernel/Code base, but nope not MikroTik they will innovate the world of networking with 32-Bit OS.

Clear sign here that MikroTik has software engineering issues, not much hardware issues. MikroTik hardware/block diagram etc is actually open and nice IMO.

Probably if RouterOS had been open source,
ForumOS64 would now exist with everything it needed...
Even the useless Dark-Mode...

The real issue here is MikroTik lacks software engineering expertise, may be financial reasons, may be understaffed, maybe both, maybe more, but they don't seem to care.

I take a different view: Mikrotik is what happens when you let engineers run a company. The results are predictable.

They just keep adding features that are mostly done & move onto new shine things before the last thing was actually done. This lack of focus on quality/completeness shows in recent software releases.

I more blame a complete lack of product/program management to "rationalize" the feature set, and incomplete/piss-poor documentation that basically only a reference manual, not a practical guide to anything.
e.g. Have you ever see someone with "Product Manager" as their title in ANY of there videos? Or anyone really... explain their strategy/direction/roadmap in them? If a new feature is released – how anyone test, even internally, if there is no documentation on how it should work is my worry!

But if it's a lack of resources... WTF are they building a multi-platform client? While I'm not in @DarkNate "throw out it all out" camp... I'm not sure the world needs yet another repackaging around same config scheme. And @normis acts as if surprising, or "teasing", customers is a good thing; see winbox icon on a Mac: When you have software quality issue presently – the last thing should be doing is re-inventing the wheel! I'm not sure a Mac/linux native admin app helps when upgrades fails or run into bugs.

The bigger issue is simple stuff is VERY often actually quite a number of steps & even then you could run into some gotcha/bug. Yet no one cares.

Probably if RouterOS had been open source,
ForumOS64 would now exist with everything it needed...
Even the useless Dark-Mode...

If Nokia, a REAL CARRIER-CLASS network vendor, can benefit from open source, so can MikroTik:
https://github.com/nokia?q=srlinux&type ... &sort=name

I take a different view: Mikrotik is what happens when you let engineers run a company. The results are predictable.

They just keep adding features that are mostly done & move onto new shine things before the last thing was actually done. This lack of focus on quality/completeness shows in recent software releases.

I more blame a complete lack of product/program management to "rationalize" the feature set, and incomplete/piss-poor documentation that basically only a reference manual, not a practical guide to anything.
e.g. Have you ever see someone with "Product Manager" as their title in ANY of there videos? Or anyone really... explain their strategy/direction/roadmap in them? If a new feature is released – how anyone test, even internally, if there is no documentation on how it should work is my worry!

Depends, not all engineers are like that, many engineers have good business decision-making skillset, prioritisation skillset and seeing a project from start to end to release for public use. In fact, some of the big multi-million dollar companies I know and worked for, were founded, operated, structured and built by engineers.

However, in MikroTik's situation, it seems this is not the case, and they likely should have a proper management that's not just two engineers who are nerding about the "Next big thing" like storage on a router.

There is a reason there are different engineering disciplines. Engineering Management or Industrial engineering is more geared towards project management, covering forecasting, budgeting, scheduling and statistics, and knowing enough about a wide scope of engineering disciplines to be able to understand risks, complexity, delays etc.....

Probably if RouterOS had been open source,
ForumOS64 would now exist with everything it needed...
Even the useless Dark-Mode...

If Nokia, a REAL CARRIER-CLASS network vendor, can benefit from open source, so can MikroTik:
https://github.com/nokia?q=srlinux&type ... &sort=name

Or, at least START by having some method to allow the V7 RouterBOOT to install (or at least boot) an alternative Linux disto. But I don't think the NIH mentality is going away.

There is a reason there are different engineering disciplines. Engineering Management or Industrial engineering is more geared towards project management, covering forecasting, budgeting, scheduling and statistics, and knowing enough about a wide scope of engineering disciplines to be able to understand risks, complexity, delays etc.....

Off-topic, got any good resources for Engineering Management learning materials?

Industrial engineering is relevant for MikroTik, because they manufacture hardware.

Or, at least START by having some method to allow the V7 RouterBOOT to install (or at least boot) an alternative Linux disto. But I don't think the NIH mentality is going away.

Forget RouterBOOT, they can save up money/R&D efforts and just use ONIE, which is a bootloader.

I wouldn't look at Ubiquiti of all places, for UI/UX inspiration

Off-topic, got any good resources for Engineering Management learning materials?

Industrial engineering is relevant for MikroTik, because they manufacture hardware.

Personal note: consider following an MBA. See if there are universities/schools near you where you can follow it, if possible evening/weekend classes.
Don't go for online course where you basically buy the degree, you will not learn anything from it.
My personal view.

Personal note: consider following an MBA. See if there are universities/schools near you where you can follow it, if possible evening/weekend classes.
Don't go for online course where you basically buy the degree, you will not learn anything from it.
My personal view.

I'm fortunately in a position where papers (certs, degrees etc) have no value to me for prospects in job or businesses opportunities. However, knowledge is key, got any links for free MBA full course materials? Video playlists or something? Specifically for Engineering management related MBA.

e.g. Have you ever see someone with "Product Manager" as their title in ANY of there videos?

I am glad that I haven't seen anyone with the title "product manager" in their videos yet. You often come across such "product managers" in videos from companies like Cambium, Grandstream, and others. In reality, they are pure salespeople and not actual company-internal "product managers". MikroTik, if I understand correctly, avoids this sales layer and relies on distributors. Sure, MikroTik could involve distributors in video production, but they are not local and can't come to their studio.

I would quite like Mikrotik to stick with its current direction. In my opinion, the reality is that these are not suitable devices for people who don't have a good practical grasp of IP, Ethernet, routing, bridging, VLAN and WiFi fundamentals.

Having done enterprise networking since the days when variable length subnet masks were rare, I've seen several generations of network kit and operating systems. I don't think Mikrotik is wildly different. Where it is different from a lot of high grade gear is, it's not expensive whilst still exposing a wide variety of network options, which is great! What it's not similar to is domestic gear!

There are issues of course, and for me the most frustrating thing is wide dispersion of key information, e.g. follow manual A from start to finish, but be aware of a critical fact buried in manual H (but not pointed out in manual A)

... but be aware of a critical fact buried in manual H (but not pointed out in manual A)

Manual H is not really a problem, since the instructions in it are anyway only applicable to devices that have ARM processor (64 and not 32 bit), and PoE output, but only those with redundant power supplies, but not those that are running version 6.79.12, if the factory software was earlier than 6.11.4, and can only be applied on wednesday nights, if there is full moon (this of course only applies to indoor devices).
Thee is anyway a post on the forum about a possible way to workaround the issue until fixed in a next release ( a ticket was opened three years ago and Mikrotik's response was that they will fix it, but unfortunately no ETA).

I am glad that I haven't seen anyone with the title "product manager" in their videos yet. You often come across such "product managers" in videos from companies like Cambium, Grandstream, and others. In reality, they are pure salespeople and not actual company-internal "product managers". MikroTik, if I understand correctly, avoids this sales layer and relies on distributors. Sure, MikroTik could involve distributors in video production, but they are not local and can't come to their studio.

Who even talks about "Cambium, Grandstream, and others"? These are not carrier-class network vendors, nobody cares.

MikroTik sells boxes with ASICs that are advertised for 100Gbps ASIC switching, that's a foot in the door of carrier-class network engineering. And you need product managers, good ones.

I've dealt with Nokia product managers, and they know their shit, they know layer 1 to layer 7.

I would quite like Mikrotik to stick with its current direction. In my opinion, the reality is that these are not suitable devices for people who don't have a good practical grasp of IP, Ethernet, routing, bridging, VLAN and WiFi fundamentals.

Having done enterprise networking since the days when variable length subnet masks were rare, I've seen several generations of network kit and operating systems. I don't think Mikrotik is wildly different. Where it is different from a lot of high grade gear is, it's not expensive whilst still exposing a wide variety of network options, which is great! What it's not similar to is domestic gear!

There are issues of course, and for me the most frustrating thing is wide dispersion of key information, e.g. follow manual A from start to finish, but be aware of a critical fact buried in manual H (but not pointed out in manual A)

MikroTik IS wildly different, I work with MikroTik, Cisco, Juniper, Arista, Huawei, Cumulus Linux in data centre and service provider domain, MPLS/EVPN/VXLAN/eBGP DC designs, all the good stuff.

MikroTik UI/UX is just plain terrible. No streaming telemetry, no gRPC, no OpenConfig, no YAML/JSON-like API input/output, CLI in/out, no root access like Juniper or Nokia SR-Linux.

Enterprise is not carrier-class networking, nor even DC-grade… I bet you never even deployed eBGP driven IPv6-only EVPN anycast gateways in your “enterprise” segments.

Thee is anyway a post on the forum about a possible way to workaround the issue until fixed in a next release ( a ticket was opened three years ago and Mikrotik's response was that they will fix it, but unfortunately no ETA).

Yeah, doesn't take three years to fix serious issues with JTAC… Just saying…

MikroTik sells boxes with ASICs that are advertised for 100Gbps ASIC switching, that's a foot in the door of carrier-class network engineering. And you need product managers, good ones.

@DarkNate
IMO Mikrotik has ZERO interest in CARRIER-CLASS networking ... MikroTik Market is 1.. Third World entrepreneur's 2.. SMB and 3.. SOHO
And in those markets MikroTik's Distributor Business Model has served them from my perspective extremely well

End Of Story

I think mozerd's answer hits the nail on the head.

In addition to Mozerd's astute observations, look at the vision statement at the MT website.......
Thats right, there isn't one!! But you can find About Us.......... which says nothing about anything in particular.

About us

MikroTik is a Latvian company which was founded in 1996 to develop routers and wireless ISP systems. MikroTik now provides hardware and software for Internet connectivity in most of the countries around the world. Our experience in using industry standard PC hardware and complete routing systems allowed us in 1997 to create the RouterOS software system that provides extensive stability, controls, and flexibility for all kinds of data interfaces and routing. In 2002 we decided to make our own hardware, and the RouterBOARD brand was born. Our company is located in Riga, the capital city of Latvia and has more than 280 employees.


A wee bit more on the jobs page.........

About MikroTik

SIA " Mikrotīkls " is a Latvian company founded in 1996 that develops and manufactures MikroTik RouterOS software and RouterBOARD routers. Our products are used by Internet service providers, companies and individual users who need to provide data flow routing, firewall, VPN and other management functions in various computer networks.

Our goal is to provide powerful and easy-to-use network management tools to the widest range of users. MikroTik products are distributed and used all over the world - we have seen MikroTik solutions on Everest and even in the mechanism of the SpaceX Falcon orbital rocket!

More about SIA "Mikrotīkls" company and products: https://mikrotik.com .

We respect our employees and the work environment. The company's office is a modern class A building, which was rebuilt in 2017 especially for the needs of "Mikrotīkla" employees. Also, a new warehouse has been built, equipped according to all modern requirements. We have received several awards both as a TOP employer in Latvia and other prestigious awards as the best producers and exporters. The World Intellectual Property Organization presented "Mikrotīk" with an award for knowledge-based business focused on continuous development.

Enterprise is not carrier-class networking, nor even DC-grade… I bet you never even deployed eBGP driven IPv6-only EVPN anycast gateways in your “enterprise” segments.

You would lose your bet. I didn't say I continued exclusively in the Enterprise domain, did I?

You would lose your bet. I didn't say I continued exclusively in the Enterprise domain, did I?

If you've had SP/DC experience with other vendors, and assuming you worked with software engineers for network programmability or automation, you'd know MikroTik RouterOS is poor software code, horrible API etc.

No streaming telemetry, no gRPC, no OpenConfig, no YAML/JSON-like API input/output, CLI in/out, no root access like Juniper or Nokia SR-Linux.

A very interesting thread, thank you. It is also clearly obvious how different people have different needs and different ideas about our products. We sure can't go in all directions this thread would want us to

So, for all of us, it would be interesting to hear, which directions Mikrotik will go.

[If you've had SP/DC experience with other vendors, and assuming you worked with software engineers for network programmability or automation, you'd know MikroTik RouterOS is poor software code, horrible API etc.]

I agree with you. When performing strategic corporate procurements, I've always weighted software quality, reliability and end-to-end programmatic observability and manageability as higher than performance or cost per port. For these reasons it's unlikely that Mikrotik would get very far in the procurement process. But then I don't think that is their target market. Like you, I think they need a rethink about the management interface/API to be closer to best practice, but I can't see them breaking into the telecoms/corporate core network market as a primary supplier.

Meanwhile, for SoHo requirements these fora are full of posts from people who have used Netgear (or similar products) in the past, then buy a Mikrotik and can't get it to do simple things. The "plug and pray" market is something that I think Mikrotik ought to make a better job of supporting, even if it's just a different overlay.

While I agree with a lot of what's already been said above I think it's something of a testament to Mikrotik and how good their hardware/software can be (within it's limitations) that people are comparing them to the "big name vendors".

But still I can't see large enterprises changing from those big vendors without being able to get someone on a support call within an hour. Likewise I can't those large enterprises who use the big consulting companies like NTT, Accenture, Atos etc recommending Mikrotik for solutions.

Personally I think Mikrotik hardware and software is outstanding for what I use it for but while the "enterprise" segment is tantalisingly close it still might just be as well a million miles away without a big expensive eco system to support those enterprise customers. Can't see that happening anytime soon.

A very interesting thread, thank you. It is also clearly obvious how different people have different needs and different ideas about our products. We sure can't go in all directions this thread would want us to

I think that a large part of the perplexities derive from the different directions that Mikrotik already took, though.

If the idea is to make powerful, high end devices for the high end professionals, it seems like (as reported by some of the posters that are into networking professionally) a number of needed/useful features/protocols/what_nots are missing.

If the idea is to make powerful, cheap devices intended for the mid-level professionals, this evidently worked for some time but now it looks like while the devices remain cheap, they start to look underpowered/unfit for this use.

If the idea is to make powerful, cheap devices for end users, they are currently unmanageable by the intended customers due to the (understandable) underlying complexities that are NOT mitigated in any way, not with a user-friendly UI, not with proper, clear, documentation, not with adequate sets of examples, not with a number of pre-defined quickset scripts covering the most common operations.

I can (obviously) only talk as an end user, my experience with Mikrotik is very small, and - personally - I am happy with the results I managed somehow to obtain, but it has costed me time, tears and blood to get the something I wished to get, and in my specific case (very simple requirements, only a little uncommon, but not as crazy as it seems) I got there using a couple of tricks found after tens of hours of reading and experimenting. Luckily I took the whole stuff as "fun" and "learning", but I doubt that many other people with my same needs would have the same amount of patience and persistence, and I am anyway an empiricist at heart, and the whole matter is interesting.

Judging from the questions asked and issues reported on this forum[1], I could bet (and easily win the money) that more than 50 percent of devices managed by common people (and a not trifling percentage of those managed by professionals) are running in the wild mis-configured, with settings that are in the best cases unneeded or slowing down the devices and in the worst cases dangerously insecure.

If you prefer, would I recommend Mikrotik to a friend? No.

[1] look also at the answers/solutions provided by even the most experienced members, it is rarely a "Ha, you are in this known case, just do this and that to solve your issue, read here <pointer to some Mikrotik official documentation that actually documents specifically the matter> and much more often "Hmmm, you could try this (or that or this other thing), it may work if you are on version x.xx, but not y.yy compare with this <link to a cryptic seemingly unrelated post on the forum, that actually contains part of the solution>.

I will agree that since there is no real effort to improve the 'question quality', its no surprize the 'answer quality' is not optimal.
Overuse of the word powerful in the explanation, flexible would be more apropos.
Recommend to a friend: Not unless they were tinkerers, otherwise the ISP provided router is usually adequate, or a consumer off-the shelf router.
Recommend to family: Yes, but realizing I'm on the hook for all support.

Overuse of the word powerful in the explanation, flexible would be more apropos.

Well, I did mean powerful.

Flexible is the exact opposite of what Mikrotik is, it is rigid in itself, the fact that a few knowledgeable/initiated users (like you) can manage to make it bend to their will (through secret, arcane magic spells) doesn't make it flexible.

https://www.pirelli.com/global/en-ww/li ... ars-52060/

For the longest time I thought the same as you, but over time, it was clear that it was my lack of networking knowledge and Ros Principals that was keeping me from unlocking the flexibility.
There are many ways to skin a cat [ as mkx & rextended would say ] with RoS, and that leads to many ways to solve issues.

A very interesting thread, thank you. It is also clearly obvious how different people have different needs and different ideas about our products. We sure can't go in all directions this thread would want us to

One direction is the easiest:
Enable official ONIE support on MikroTik hardware, at least all models that are new and has Marvell ASIC/PIPE.

Problem solved, we can install our own NOS and not have problems with VXLAN/EVPN offloading to ASIC or even MPLS/SR-MPLS if the ASIC supports it.

This costs you nothing for developing, give us flashing software to flash official ONIE bootloader for MikroTik, that's it, about 3 months worth of coding + testing? Not much time to make this happen, since you have access to RouterBOOT source code and the hardware in your offices. Should be a fairly doable software project for some C/Rust programmers in your company. ONIE version 2023.11 looks like something that could work.

@jaclaz

1. Nobody is asking for a Juniper MX2020 from MikroTik.

2. MikroTik HARDWARE isn't the problem. In last 10 years of MikroTik, 1/10 are hardware issues.

3. MikroTik SOFTWARE is the problem. In last 10 years of MikroTik, 10/10 are software issues.

They can opt for fastest/cheapest solution i.e. enable official ONIE flashing support. OR, they hire more software engineers who can build ROSv8 or whatever to be on-par with Nokia SR-Linux:
1. Open source components and data model
2. Contribute back to upstream Linux kernel
3. Remove Linux dataplane
4. Move to DPDK/VPP or XDP for software dataplane

For the longest time I thought the same as you, but over time, it was clear that it was my lack of networking knowledge and Ros Principals that was keeping me from unlocking the flexibility.
There are many ways to skin a cat [ as mkx & rextended would say ] with RoS, and that leads to many ways to solve issues.

Computer Networking, as an engineering domain, operates under distinct constraints that often limit the number of “systemically optimal” solutions:
1. Protocols and Standards — You cannot act on your own, packet flow is pre-determined by specs.
2. Physics and transport medium — Self explanatory.
3. Complexity and performance trade-offs — Complexity not only in system design, but also config complexity (circa this post), that leads to human layer issues for scale and manageability.
4. Security — There are limited number of ways to ensure maximum security/and or reasonable compromise

Due to these constraints, there are typically only a few ways to design and implement something in networking while achieving optimal performance, security, and reliability within the defined protocol and physical limitations. Networking has many potential solutions, but the constraints guide engineers towards a narrow range of “systemically optimal” choices based on the specific context and requirements.

My rule of thumb personally based on my experience in SP and DC market is, at best I have two systematically optimal options in a given scenario and if I'm lucky I get three.

What's strange about MikroTik as a network vendor is we don't see them in IETF meetings, we don't see them in NANOG, SANOG, UKNOG, NLNOG etc.

Other vendors, small or big, attend these events, especially IETF, since all are interested to mingle, improve, and make business deals, but MikroTik employees are nowhere to be seen. If you search for Normis or MikroTik employees on LinkedIn, good luck finding them. Now search for VyOS, Nvidia Cumulus, Arista etc, and see the difference.

Cisco, Juniper, Arista, Huawei etc have all contributed tons of RFCs to the community, which RFC draft/spec has MikroTik ever contributed to?

normis is my name just as DarkNate is yours

@Darknate
Yes, it is clear that the issue is mainly software, but I would venture a little further, saying that the software is not as bad as it seems, a relevant part of the perceived (and also objectively found) issues seem to me not due to the core of the software but rather at the poor way features are documented causing mis-configurations.

I have a fantastic theory about this.

Some years ago an alien ship landed in Latvia and a semi-god creature gave to a bunch of engineers the capability of making good hardware and almost decent software but, in the tradition of these stories, he wanted something in exchange for this gift, and he took away their capability to write documentation and to communicate with their customers.

No praying is necessary, but if you are administrating a network, you better at least understand networking.

OR, they hire more software engineers who can build ROSv8 or whatever to be on-par with Nokia SR-Linux:

Tasks/decisions/issues like you describe here aren't solved by just throwing lots of software engineering manpower at it. But I think you already knew that (because you already mentioned the term "product managers" and I assume you were talking about the role in a software development cycle). From what we can see from the outside how ROS evolves I can just make a wild guess. But I dont believe that there is someone with a clear "product-vision" nor someone who defines a roadmap of upcoming ROS features. It seems to be mainly driven by customer feedback (bug reports) and maybe some engineers personal goals (e.g. BTH feature that nobody asked for, sure it is nice, but does it address the real painpoints? nope)

It is not, that's why home user can use "MikroTik Home" app, or rely on the ISP to configure their device. Some mobile operators don't even allow access to RouterOS to home users. The strength comes in the feature set the ISP has available, not on user friendliness.

Croatia is one country, there are some more countries. And also, why not? Maybe you should ask the LTE provider to give you Chateau, not Re-Labeled noname brand.

maybe make quickset a little bit more functional, some of the suggestions:
- VLAN manager of some sort, option to use or not to use VLANs

and others complain that quickset is already too complex for home user

maybe make quickset a little bit more functional, some of the suggestions:
- VLAN manager of some sort, option to use or not to use VLANs

and others complain that quickset is already too complex for home user

Well, it is both "too complex" for SOHO. But QuickSet is how I workaround the "configuration abstraction complexity", at least for LTE devices. I view more as a way to have "configuration template" to a custom defconf. But not sure an "improved QuickSet" does not really address @DarkNate's main complaints, as they don't involve setup.

I do think @DarkNate has an excellent point that may be getting lost here & is not a SP problems:
1.

configuration of bridge VLANs/VLANs in general etc are easy just like Juniper, Cisco, Nokia etc? misconfig doesn't lead to performance issues (issue unknowingly routing/bridging traffic through CPU)."

Hit the nail on the head. I know how bridging works... but if was a given a random Mikrotik model, I'd have to re-read many pages to confirm what's possible (and likely still have search the forum because something still may not be clear). And with L3HW becoming more common on devices, this problem gets even more complex on "what optimal".

e.g. not easy to know what feature/config is causing the "H" not to appear in the bridge, or if it's even possible to achieve.


Now on this one...
2.

MikroTik UI/UX is just plain terrible. No streaming telemetry, no gRPC, no OpenConfig, no YAML/JSON-like API input/output, CLI in/out, no root access like Juniper or Nokia SR-Linux.

Not sure the issue here is the protocols themselves... Mikrotik does have a JSON API via REST. But even if config was represented in protobufs used by gRPC, not sure that alone help anything.

Issue is all protocols go back to the same basic "add", "set", "remove" operations on the router. So if you have some file with desired VLAN/subnet/prefix/whatever for you network... you cannot just "apply it" (e.g. add/remove missing ones, leave rest alone, etc.) – it take scripting (and same via REST/API) using same "if exist(...) { set ... } else { add ...}" as CLI. And you run into the lack of "transactions" to be able to "rollback" a change if there was an error. e.g. "Safe Mode" is only a winbox concept.

So easy to see the SP/DC problem since it hard to automate without some "update" primitive that either add a new item, or set an existing item in ONE operation. e.g. you have a CSV/XLS/JSON/YAML list, that may get updated over time, it potential 2-3 different API calls today if you want to make sure all items match what's configured.

But overall I do like the RouterOS database-like model of config (e.g. everything is a table) vs. some file-based config system. And think it's good design that there is no root access – although that does pose problem if things are broken – not sure it help fix anything with RouterOS since there aren't even any posix tools/etc install...

I like all this talk about Nokia, Cisco, Juniper etc.
But, MikroTik is routing the world.
Never forget.

I am still trying to add up the math......

quote: "DarkNate
@jaclaz
1. Nobody is asking for a Juniper MX2020 from MikroTik.
2. MikroTik HARDWARE isn't the problem. In last 10 years of MikroTik, 1/10 are hardware issues.
3. MikroTik SOFTWARE is the problem. In last 10 years of MikroTik, 10/10 are software issues."

What's strange about MikroTik as a network vendor is we don't see them in IETF meetings, we don't see them in NANOG, SANOG, UKNOG, NLNOG etc.

Other vendors, small or big, attend these events, especially IETF, since all are interested to mingle, improve, and make business deals, but MikroTik employees are nowhere to be seen. If you search for Normis or MikroTik employees on LinkedIn, good luck finding them. Now search for VyOS, Nvidia Cumulus, Arista etc, and see the difference.

Cisco, Juniper, Arista, Huawei etc have all contributed tons of RFCs to the community, which RFC draft/spec has MikroTik ever contributed to?

I will be at IETF next month, will you ?

It would be good to meet up.

I will be at IETF next month, will you ?

It would be good to meet up.

No, I live in economies that are far away from most IETF events. But have fun, and maybe try to get MikroTik employees to go there instead. They never participated in the IETF since 1997.

Hi,

For those who are interested, since the issue of including the WAN port in the same bridge is discussed (although I don't know if it is in this topic).

Ask support about vlan configuration on L009 and RB5009:

Support response:

Regards,

It gets even worse and more confusing, see below:
viewtopic.php?t=204440#p1058995

This is exactly why MikroTik needs to overhaul the source code of RouterOS from scratch (perhaps time re-write in Rust?) and fix the configuration implementation logic from the hardware level, upto userspace level. To ensure consistent config and documentation across all modern CCR, CRS and RB hardware with Marvell ASICs.

There's no “consistency” of config on MikroTik. I've seen “less” of config consistency problem on Juniper, and from the looks of things, Nokia SR Linux doesn't have this problem either.

Mikrotik is very good at making hardware and software products for people that do not have access to "Wall Street Funding". Mikrotik will never be Cisco, Juniper or other "Enterprise" Vendors.
Please continue the adventure into networking that is very affordable for the masses.

Thank You