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.

It's not that we don't care it's just that I doubt that Mikrotik will change something here.

In another topic I proposed to them to create RouterOS lite for SOHO devices as there is really no need for BGP, MPLS etc. All of this advanced routing functions that will never be used in such devices. So leave just basic functions that could be useful in such device.

Also if they want to expand to such market then much better GUI is needed (for eg look at Ubiquiti, TP-Link etc.)

And I agree with you, Mikrotik have too much older device that they supports, to much different hardware they need to adapt ROS to.

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.

Where are the examples of the ROS complexity?

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.

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

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.

I agree, using 32bit software in 2024 is kinda ridiculous.

Funny thing today, regarding normal home user and Mikrotik configuration.

I installed ax2 at my parents house about a year ago and brother wanted to change SSID and password from default provided by Mikrotik.

He opened winbox, clicked few times around GUI and said that he don't want to mess with that. Then he asked me why Mikrotik don't have normal home router. He was shocked when i told him ax2 is normal home router. He just said that is not normal router.

He was expecting "normal" wireless settings. SSID, encryption, password, channel. He did find quickset but as i created 2 vlans and some other stuff i told him not to touch that because there is a possibility that router stop working.

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.

As someone said this, Mikrotik is not plug and play it's more like plug n pray

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)

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

With that I agree, if you are network administrator you know what are you doing (probably) and it's easier for them to understand what to do if they are working with ROS for the first time for but what in case of the home users ?

You must admit that ROS is not by any means home user friendly.

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.

For eg. in Croatia I've never seen ISP to give out Mikrotik devices for home users, business customers yes but home users gets some router that was the cheapest for ISP, you get instructions on how to change your password, SSIDs and you get your credentials to access your router. (of course not admin access)

Here your SSID and password is your problem, not ISP problem. What is with customer that buy Mikrotik in store ? Feature rich device and then home app that looks great but have limited functionality ?

What would I consider is to 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, if yes then open VLAN wizard where VLAN ID, IP, do you want for VLAN to be accessible from other VLANs if there is any and ports that user want's to use and then device create routes, FW rules, ip pool, dhcp server etc.

- Add BTH to quick set, don't let users wander around ROS to turn on this feature.

- Maybe consider adding some CAPsMAN wizard ?

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

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

Yea... in that case they will provide you with SIM card if possible and tell you that you can buy your own router. You get Huawei from them if you are lucky...

Regarding Quickset, i can't say it's complicated but will break stuff if you mess with quick set and then you go and mess with config.

For eg. Local network:

-ditch netmask, dhcp and nat option, there are great chances that home user will not know what that is, and you need that by default and netmask leave as /24.

When user wants to change subnet, when they input their wanted IP address quickset should do all necessary task behind the scene. (I would add notification if they want to use IP address that is not in private address range) Don't know what does now as I don't ever use quickset.

It's not possible to create VLAN setup as you have for DHCP server ?

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

@darknate: Resources: Engineering Management ( besides the academics of maths, physics, statistics-probability, electrical, programming, chemistry, drawing, thermodynamics etc...)
All old text books circa 1980s LOL
PRODUCTION/OPERATIONS MANAGEMENT: Concepts Structure & Analysis --> Richard J Tersine 1980
ENGINEERING ECONOMICS --> James L. Rigg 1977
Management ( and accompanying Study Guide & Workbook ) --> James F. Stoner 1978
Information Systems: Theory and Practice -->: John G Burch Jr, Felix R. Strater, Gary Grudnitski 1979
Maintenance Replacement and Reliability --> AKS Jardine 1973
Measurement Systems: Application and Design --> Ernest O. Doebelin 1975
INDUSTRIAL ENGINEERING HANDBOOK: Third Edition H.B Maynard 1971
INTRODUCTION TO OPERATIONS RESEARCH: Third Edition Hillier and Lieberman 1980
HUMAN FACTORS IN ENGINEERING DESIGN: Fifth Edition Ernest J. McCormick, Mark S Sanders 1982
RELIABILITY IN ENGINEERING DESIGN --> KC Kapur, LR Lamberson 1977

All old text books circa 1980s LOL

At which time Latvia was still part of Soviet Union. So those western (US in particular) books were probably banned ... or at least ignored because Soviet communism did things differently.

So it might be that all of these concepts are somehow unknown to MT management.

Funny that, today I was watching one of my favourite youtube distractions, losing my self in the world of "Bald & Bankrupt" .
Today I learned about Tajikistan! Good thing they left the USSR otherwise Voldemort would have pulled all the able bodied men to fight in Ukraine.
https://www.youtube.com/watch?v=fBBiFhhY2to

At which time Latvia was still part of Soviet Union. So those western (US in particular) books were probably banned ... or at least ignored because Soviet communism did things differently.

So it might be that all of these concepts are somehow unknown to MT management.

Many industry folks (outside Latvia) are of the opinion that MikroTik operates using Soviet economic/business model and that's their major bottleneck. The facts and timeline of Latvia<>USSR seems to indicate that MikroTik never adapted 21st century business model nor engineering management.

@darknate: Resources: Engineering Management ( besides the academics of maths, physics, statistics-probability, electrical, programming, chemistry, drawing, thermodynamics etc...)
All old text books circa 1980s LOL
PRODUCTION/OPERATIONS MANAGEMENT: Concepts Structure & Analysis --> Richard J Tersine 1980
ENGINEERING ECONOMICS --> James L. Rigg 1977
Management ( and accompanying Study Guide & Workbook ) --> James F. Stoner 1978
Information Systems: Theory and Practice -->: John G Burch Jr, Felix R. Strater, Gary Grudnitski 1979
Maintenance Replacement and Reliability --> AKS Jardine 1973
Measurement Systems: Application and Design --> Ernest O. Doebelin 1975
INDUSTRIAL ENGINEERING HANDBOOK: Third Edition H.B Maynard 1971
INTRODUCTION TO OPERATIONS RESEARCH: Third Edition Hillier and Lieberman 1980
HUMAN FACTORS IN ENGINEERING DESIGN: Fifth Edition Ernest J. McCormick, Mark S Sanders 1982
RELIABILITY IN ENGINEERING DESIGN --> KC Kapur, LR Lamberson 1977

Any 2020-2024 edition of these books? I'm sure the authors have updated some of them. 2024 tech business is vastly different to what it was in 1980.

Many industry folks (outside Latvia) are of the opinion that MikroTik operates using Soviet economic/business model ...

It's often very hard to get rid of some mental petterns if they are given (or enforced) to a few generations in a row.

One of them is "USA are the greatest in known Universe in all aspects" mentality, deeply engraved in majority of US population.

It's often very hard to get rid of some mental petterns if they are given (or enforced) to a few generations in a row.

One of them is "USA are the greatest in known Universe in all aspects" mentality, deeply engraved in majority of US population.

Unfortunately, that's the reality of humanity as a whole.

USA is great for getting paid, with the right plan. $10k for NAT configuration on a MikroTik lol. Stupid American enterprises are good cash cows, because they'll pay $$$$ for something as simple as BGP route filter configuration. Idiots could do it for free if they Googled, but nope.

Certainly Mikrotik has a curious business strategy from this silicon valley denizen POV. I kinda view Mikrotik more as a redhat that made the choice to fund itself by selling low-margin hardware, over a high-margin services. It's a choice.

On this front and to @DarkNate points on "config complexity". Why is UBNT the clear winner in high-volume, low-cost router/AP market in the US? My guess: it's more plug-and-play - not better hardware or more reliable – just some UI for beginners. In US/elsewhere, labor sometimes a much higher cost than hardware, so if it takes 3-5X as long to configure Mikrotik over UBNT/etc for similar setup, that makes Mikrotik a tougher sell.

But on the enterprise/DC side discussion of "configuration abstraction complexity", be curious to know if @DarkNate is looking for Mikrotik hardware to run something like Cumulus/etc and dump RouterOS? Or, is issue that RouterOS cannot be configured using standard protocols like NETCONF/etc and/or lack of routing protocols (EGIRP, EVPN etc) the BIGGER problem?

Certainly Mikrotik has a curious business strategy from this silicon valley denizen POV. I kinda view Mikrotik more as a redhat that made the choice to fund itself by selling low-margin hardware, over a high-margin services. It's a choice.

On this front and to @DarkNate points on “config complexity”. Why is UBNT the clear winner in high-volume, low-cost router/AP market in the US? My guess: it's more plug-and-play - not better hardware or more reliable – just some UI for beginners. In US/elsewhere, labor sometimes a much higher cost than hardware, so if it takes 3-5X as long to configure Mikrotik over UBNT/etc for similar setup, that makes Mikrotik a tougher sell.

But on the enterprise/DC side discussion of “configuration abstraction complexity”, be curious to know if @DarkNate is looking for Mikrotik hardware to run something like Cumulus/etc and dump RouterOS? Or, is issue that RouterOS cannot be configured using standard protocols like NETCONF/etc and/or lack of routing protocols (EGIRP, EVPN etc) the BIGGER problem?

Redhat doesn't have a Soviet business model. It's a fine line difference between “low-margin” business and “Soviet margin” business. Don't insult Redhat by clubbing it with MikroTik.

Ubnt isn't exactly “clear winner” in the sense you might think, it's a clear winner for normies, yes. But not for professional SP, DC and enterprise networks that needs things like MPLS/VPLS, BGP etc. Ubnt really targets wannabe fake-network engineers playing engineer in their home lab with some shiny RGB switch from Ubnt. It's actually an insult to MikroTik to club it together with Ubnt.

Configuration abstraction complexity stems from the simple fact that MikroTik never built their own custom data-plane, they relied on Linux kernel data-plane all these years instead of userspace dataplane using DPDK/VPP (or XDP) for CPU forwarding to begin with. If they had built their own custom dataplane, they would've not only been able to push high throughput over CPU, but also simplify configuration options to match exactly how they envisioned it to look like in the source code.

Even though, now they have hardware dataplane with Marvell ASICs (clearly really good ASICs for the price), MikroTik failed to just drop the abstraction of the Linux kernel based configuration paradigm and still used it even for the ASICs which isn't required, but it is in the case of MirkoTik as RouterOS v7 still uses Kernel dataplane for CPU. So in order to achieve consistency in config (to whatever ends), they stuck with Linux kernel abstraction.

Speaking of software dataplanes with DPDK/VPP, 100Gbps with full tables on arm64-CPU-only forwarding is possible. I can't site sources for this as this project wasn't public.

Speaking of software dataplanes with DPDK/VPP, 100Gbps with full tables on arm64-CPU-only forwarding is possible. I can't site sources for this as this project wasn't public.

Can you tell us something about the hardware? ARM64 varies between, say a Raspberry Pi and a 192-core Ampere One I'm guessing it's more like the latter...

Can you tell us something about the hardware? ARM64 varies between, say a Raspberry Pi and a 192-core Ampere One I'm guessing it's more like the latter...

I'll try to ask my source again for the hardware product page, but I may not be able to reach them. But it wasn't Ampere, it was a Single Board Computer in fact with few cores arm64 CPU, similar to a high-powered Banana Pi. RAM was 8 GB if I recall correctly. It had 2×100G SFP cages. This was 2–3 years ago.

I've seen what VPP/DPDK achieves on x86 machines and it's really impressive. I have not had the possibility to see results on the ARM architecture.

I'll try to ask my source again for the hardware product page, but I may not be able to reach them. But it wasn't Ampere, it was a Single Board Computer in fact with few cores arm64 CPU, similar to a high-powered Banana Pi. RAM was 8 GB if I recall correctly. It had 2×100G SFP cages. This was 2–3 years ago.

That would be impressive indeed...

Configuration abstraction complexity stems from the simple fact that MikroTik never built their own custom data-plane, they relied on Linux kernel data-plane all these years instead ...

Well, Mikrotik obviously doesn't have in-house development resources to go for custom anything large scale. They did go down this path with their custom wireless drivers (which worked fine for a while) and we all saw where it ended (they are using chipset vendor's drivers now which is fine for most users but sorely lack some functionality upon which some WISPs rely). So perhaps it's better for MT to stick to stock linux kernel data-plane in the long run and simply pass the high-performance market.

Well, Mikrotik obviously doesn't have in-house development resources to go for custom anything large scale. They did go down this path with their custom wireless drivers (which worked fine for a while) and we all saw where it ended (they are using chipset vendor's drivers now which is fine for most users but sorely lack some functionality upon which some WISPs rely). So perhaps it's better for MT to stick to stock linux kernel data-plane in the long run and simply pass the high-performance market.

To be fair, and without sharing too much non-public information and risk getting myself identified for said information.

It takes only about 3 network software engineers full-time employees to build a complete NOS using DPDK/VPP + Linux kernel for control plane and packages (DHCP, BGP etc).

For building the DPDK/VPP dataplane alone stack itself, that's an average of only 1 full-time network software engineer on the payroll.

Average cost per engineer is around $200k per year. If this is Latvia, then I'm sure they can manage with $180k per year per engineer with incentives like medical insurance, gym/home office budget etc. Total cost per employee, probably, $185k per year or something.

But is MikroTik interested in hiring international engineers? I don't know. But there's many talented network software engineers, out there where quality > quantity.

I've seen what VPP/DPDK achieves on x86 machines and it's really impressive. I have not had the possibility to see results on the ARM architecture.

Yeah, but VPP/DPDK is a pure user-space solution (appliance) typically used by the telco industry so it's unlikely to be integrated into the MT product line (IMO)

As someone said this, Mikrotik is not plug and play it's more like plug n pray

jeezzzz LFMAO

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

Untill it meets DDdoS world... and its software routing crashes... whilst other vendors are using hardware based routing, firewall etc....which makes a hughe difference in the end compared to software rounting systems...... i guess we have to accept the fact of the RoS limitations... its good for small ISPs up to 1000 clients.. once u get past that..unfortunatelly you have to start looking into other vendors options in the market if you want to grow pacefully with quality like huawei,juniper,cisco ASRxxxx... Thunder A10 and other players emerging..

Untill it meets DDdoS world... and its software routing crashes... whilst other vendors are using hardware based routing, firewall etc....which makes a hughe difference in the end compared to software rounting systems...... i guess we have to accept the fact of the RoS limitations... its good for small ISPs up to 1000 clients.. once u get past that..unfortunatelly you have to start looking into other vendors options in the market if you want to grow pacefully with quality like huawei,juniper,cisco ASRxxxx... Thunder A10 and other players emerging..

Other “vendors” as in DDoS scrubbing companies do not use Huawei, Cisco, Juniper, Nokia, Arista for DDoS mitigation/filtering/re-routing/scrubbing.

They use XDP with x64 Intel or AMD CPU-only boxes.

Example:
https://blog.cloudflare.com/l4drop-xdp- ... itigations

Yeah, that's a pretty neat example of how powerful the XDP/eBPF combo is.

Can be improved by AI.............. Will have to be as soon the DDOS attach will be AI run.

And defended by AI - the ultmate AI war! Skynet will become reality in the near future!

I don't get the "why can't just mikrotik do x86 stuff like anyone else with fancy linux dataplane thing" complaints. If Mikrotik doesn't suits your needs, stick with x86-boxes with Linux then. Serious traffic should be done in hardware anyways.

Huawei, Cisco, Juniper and Nokia all makes their own sillicon and builds functionality around that.

I agree that RouterOS sometimes is over-flexible. It allows users to do something the wrong way and mess stuff up. Other vendors forces the users to do it a certain way only. And Mikrotik sometimes has a schizophrenic approach when adding new products and software features. DLNA, Kid-control and BGP & MPLS-VPN in the same box... Then certain common usual features that you find almost everywhere just doesn't exist and just seems to be ignored. Mikrotik can't really make up it's mind what target audience it should have.

As for configuration. Yes. I also wish that switching logic was better. Yes, it's fiddly to remove/change stuff. I also wish that there was a "commit" mode. Personally I find YANG a bit overrated.

This has been touched on a bit in this thread, I'd like to continue on this topic as I think it's an area where the fastest improvements can be made.
This would be the documentation.

I'd suggest the following.

1. Cleanup old documentation -ie delete it
wiki.mikrotik.com and mikrotik.com/download/pdf/MT_Manual.pdf are a couple of examples that really need to go.

2. For help.mikrotik.com allow users to contribute to the documentation.
I'd definitely not advocate for the wild west where everyone can change anything. It would need some form of control, but then you could have potentially hundreds of editors making a multitude of improvements that we all know are needed.

I don't get the "why can't just mikrotik do x86 stuff like anyone else with fancy linux dataplane thing" complaints. If Mikrotik doesn't suits your needs, stick with x86-boxes with Linux then. Serious traffic should be done in hardware anyways.

Huawei, Cisco, Juniper and Nokia all makes their own sillicon and builds functionality around that.

I agree that RouterOS sometimes is over-flexible. It allows users to do something the wrong way and mess stuff up. Other vendors forces the users to do it a certain way only. And Mikrotik sometimes has a schizophrenic approach when adding new products and software features. DLNA, Kid-control and BGP & MPLS-VPN in the same box... Then certain common usual features that you find almost everywhere just doesn't exist and just seems to be ignored. Mikrotik can't really make up it's mind what target audience it should have.

As for configuration. Yes. I also wish that switching logic was better. Yes, it's fiddly to remove/change stuff. I also wish that there was a "commit" mode. Personally I find YANG a bit overrated.

Huawei, Cisco, Juniper and Nokia all use Broadcom with the occasional dump of their own ASICs, stop spreading fake information.

"Flexible" isn't the problem, relying on Linux Netfilter framework for data plane is.

Even PURE Linux OSes like those used at Cloudflare for DDoS mitigation and filtering, do not use Linux data plane, they ues DPDK/VPP or XDP.

1. Cleanup old documentation -ie delete it
wiki.mikrotik.com and mikrotik.com/download/pdf/MT_Manual.pdf are a couple of examples that really need to go.

I don't agree with that!
It is already bad enough that most MikroTik documentation is not linked a version history of RouterOS.
When you are running 6.49.15, there is really no way to get documentation that pertains to that version.
wiki.mikrotik.com is the closest that you can get. It should NOT be deleted for at least several years.

It would be best when the versions of the help.mikrotik.com system (yes, the pages are in a versioning system) would somehow be linked to the RouterOS version, so you could e.g. retrieve documentation as it is for version 7.12 and that does not include features for higher versions.
When that is really not possible (for me that would be a total disqualification of the Atlassian system!), at least each feature introduced should have a "first available in 7.xx" note.

It is already bad enough that most MikroTik documentation is not linked a version history of RouterOS.

Thats good, nice constructive post.
What are your though on having community members updating the manuals?

"old" wiki is still very useful

Is the old wiki good for you because it contains information specific to the ROS6?

"old" wiki is still very useful

Is the old wiki good for you because it contains information specific to the ROS6?

Yes, and because it is more complete and easier to read/follow than the new one.

We are, this way or another, forced to use both documentation systems. The old wiki may be more readable (this is subjective of course) and describes v6 (for those still using it). The new help is a must when using new features of v7. Most contents is the same in both (but can be presented differently).

The problem with both documentation branches is something complained about quite a few times: docs (in either branch) don't clearly indicate ROS versions to which description applies. It should be fairly easy to add this metadata to descriptions of new features or to (radical) changes. I can understand it's a bit harder to do the same when a feature gets removed, but even this is not impossible to do.

The comparison to Cisco/Juniper/Huawei/etc is not really relevant. May as well go pick on TPLink and ask why they aren't 'Carrier Grade'.
I don't think most people would ever bother to try and make the comparison because clearly TPLink is almost entirely residential focused with a few soho grade business products

MikroTik sits in its own market segment that bleeds over to residential as well as up to 'lite' carrier grade where it absolutely can and is used in ISP's, DC's and enterprise
That's a big problem with the 'perception' of MikroTik, as its so wide reaching that it can be viewed as viable as well as falling short in just about every segment. Too complex for the basic home user, yet too many missing features, bugs and half baked implementations for industry recognized carrier use. So of course if you have eyes for the higher end enterprise market you're going to critique a lot of things that don't fall into that world. But at the same time you could just as easily go and badger the Cisco/Juniper/Huawei community over their lackluster offerings for the WISP market..... or not, because clearly thats not their sole focus

So if we had to have a polarizing choice and MikroTik focused entirely on shifting towards higher end gear, entirely industry compliant and accepted practices etc and essentially become yet another large player like Cisco, whilst abandoning the smaller market in favor of large corporate profits. Or stay where they are in a very exclusive market segment that serves an enormous amount of use cases at very very good prices with a very broad feature set. Which do you honestly prefer? Cause i'd absolutely take the latter. We don't need more players in the high end market, you can already go there and get what you want if you so desire

Does MikroTik and RouterOS have room for improvement? yep, heaps. I wouldn't shed a single tear if they ripped out the entire bridging/VLAN concept and rewrote that.
But lets look at it from another perspective, where are the real competitors to MikroTik? Oh there aren't any? So lets not forget what they have managed to do. If MikroTik disappeared overnight it would leave an enormous hole in the market that cannot be covered by any other player in the market space. Running an ISP on Ubiquiti or Draytek routers? Yeah i'm sure you possibly could and it would be truly awful
Trying to build a sizeable SOHO base on Cisco/Juniper? Yeah no
MikroTik covers both very well (of course not perfect) and much more to either end of the spectrum, and allows anyone to scale from entry level to the point where money doesn't really become an obstacle anymore (at which point great, start rolling out Juniper or any other high end player if you so wish). All the whilst NOT requiring CCNP/CCIE level staff to operate (of course sound networking principles go a very long way). No other vendor does that and is severely lacking otherwise

@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

1000000% agree with your point and statements. I've personally been also voicing my opinion to MikroTik support channel, hopefully it gets directed to appropriate team.

Even if they released a "Professional" line-up of hardware at a different price point. There are markets/verticals that will sustain higher cost. However, they also need to improve their routerOS quality. If they refuse to do such, allow us to flash ONIE .

MikroTik hardware is solid, I've not had RMA's or failures. Software is always the issue, bugs or quirks [vlan bridging, cpu method]. etc.

I can go on. But @DarkNate has great points.

Ofcourse, we know our market and will deploy MikroTik hardware for specific customer or environment. Otherwise, we are Cisco/Juniper/HPE.. Or Meraki. etc.

I feel MikroTik is at a point they need to better split their hardware into categories. Cheap SMB/SOHO product line-up that can better utilize their new mobile MikroTik Home App. This would create a big market. Then egular home/SOHO users can create their basic configs and be happy using an app-driven router [TP-Link, Eeero, etc].

The Cloud Core, or "Professional" series, will have the hardware and higher cost associated to be used by true "professionals" in the networking field.

Lastly, The mention of containerizing certain MikroTik add-ons would be the next logical and best move. Containerize CAPsMAN, UserManager, DNS manager? Or even if they add-on suricata...

There are already SMB/SOHO/Consumer level products by MikroTik that are priced accordingly. However - they are purchased by professionals. When an average end-user purchases one due to the attractive price point and product availability - it will put a bad taste due to complexity.

I've come late to this discussion but can relate to everything that's been said here. I really *want* Mikrotik to thrive because their hardware really is neat and RouterOS is wonderful (as a one-time assembly programmer) but I've had a word with myself recently and told myself to stop implementing it. I work primarily in the SOHO market and Unifi is just easier. I can stick a Unifi network in and forget about it. Occasional update via web of firmware. 99% of my clients don't need anything more than firewall/router with DHCP server and guest LAN.

I've tried, I've cajoled but that's the wrong attitude. When clients can buy a new Unfi AP, supply their existing cloud account details and then simply plug it into PoE on the switch, RouterOS can just not complete. Why should they pay me an hours work?

Which leads me to believe that Mikrotik does not want the SOHO market - which is fine as it's their bat and their ball. But that's a crying shame.

So yes, it's not hardware as such (some weird choices though like hAP ax lite without 5GHz) but the software - it's just too complex.

Id be very much against a split segment model
One of the best parts of MikroTik is NOT artificially gimping functionality and having a (mostly) uniform OS across the board regardless of what piece of hardware you pick up. Aside from a few things (like wireguard not on MIPS chipsets) you can use any of their hardware to do anything

Waking up one day to find you can't do an EoIP tunnel unless you change hardware or upgrade to a subscription licence or some other utter BS would be horrible

I'm all for improvement where it's viable improvement - some hardware definitely needs improvement, PoE capability sucks - I just don't understand the mentality of "well just make it more like TP-Link/Cisco" when TP-Link/Cisco already exists. Why? Just go over to that side and use their products

I feel MikroTik has put themselves into a corner with the current market and times. Times changing. Reliable hardware, very powerful - but complicated. Especially complicated when the vlan bridge method changed to be more CPU bound [all vlan bridge], instead of relying on switch chip [specfic models].

Old saying "can have good and cheap, but not both".

Issue is the lower priced hardware that is attractive to SOHO and residential consumers, who want easy. Well, MikroTik can be complex.

If MIkroTik takes time to work on UI/UX - perhaps a new "WebFig" -- this would ease the cost of entry for home users or people looking to join team MikroTik... Otherwise, the hAP type products 'home access points - given their low cost and home users attracted..... force App or CLI config - not both. IE: Home user can simply use MikroTik Home App to configure and be satisfied. If this is what they aim for -they need to do better job of marketing or including QR codes in packaging for those devices aimed at residential and home users.

And then for the rest of us as network professionals, advanced users / power users -- we toss the manual and full flex on the MikroTik available features.

Look at Unifi -- hits a price point and the UI/UX is easy enough for 90% of folks for that given market vertical.

Or they will just keep producing products/hardware for certain price points and targets environments. They could see as the current software as "is what it is".

I just feel if they had a 'hAP, Professional, and then Cloud Core" type line-up it would be better organized.

Could lock down their mobile app to specific product model SKU's.

Id be very much against a split segment model
One of the best parts of MikroTik is NOT artificially gimping functionality and having a (mostly) uniform OS across the board regardless of what piece of hardware you pick up. Aside from a few things (like wireguard not on MIPS chipsets) you can use any of their hardware to do anything

Waking up one day to find you can't do an EoIP tunnel unless you change hardware or upgrade to a subscription licence or some other utter BS would be horrible

I'm all for improvement where it's viable improvement - some hardware definitely needs improvement, PoE capability sucks - I just don't understand the mentality of "well just make it more like TP-Link/Cisco" when TP-Link/Cisco already exists. Why? Just go over to that side and use their products

Its a tough spot they put themselves into. Like they're confused for market segment. hAP products for price directly complete with SOHO / residential TP-Link, Belkin, Cisco, etc etc... So consumers purchase due to price and end up returning due to complexity. They have the Home App available -- but its not provided in box documentation or a QR code. etc etc.

Or we leave the "affordable and powerful" to the network professionals and stay away from SOHO/Consumer level. Why then create a MikroTik Home app for ease of config -- trying to reach perhaps the wrong customers / end-user. This is where I feel they're confused.

I want to recommend MikroTik to friends/family--- but cant due to complexity for them. I'd be the throat they choke to configure - or perhaps I recommend so I just handle it and get paid an hour of time.

It's all about marketing and outreach. If they market saying hey -- our affordable lower cost devices 'hAPs' -- just use the Home App for basic end-users. But if you're experienced in networking or already #Team MikroTik -- no need to use app. Rely on Winbox or WebFig.

Then full circle, WebFig sucks. So some folks immediately nope and go back to other vendor.

Especially complicated when the vlan bridge method changed to be more CPU bound [all vlan bridge], instead of relying on switch chip [specfic models].

Wait, what????.... Old switch menu is horrible. Bridge menu isn't the best and it does not automatically handle certain capabilities in hardware across all models despite them supporting it (and this still needing to do it in switch menu)
However it is SUBSTANTIALLY better and easier than the old switch menu. Configuring CRS1xx/2xx are an absolute nightmare, exponentially more complicated to do very basic switching. If you want to go back to that method you're insane

I want to recommend MikroTik to friends/family--- but cant due to complexity for them.

But why? Do you have shares in the company or are a distributor and benefit from the number of units shifted? Residential market is amply serviced by other vendors. We don't install mikrotik anywhere a customer wants access to it precisely for the reasons you stated, we provide them when it's a managed device and they don't touch it

Especially complicated when the vlan bridge method changed to be more CPU bound [all vlan bridge], instead of relying on switch chip [specfic models].

Wait, what????.... Old switch menu is horrible. Bridge menu isn't the best and it does not automatically handle certain capabilities in hardware across all models despite them supporting it (and this still needing to do it in switch menu)
However it is SUBSTANTIALLY better and easier than the old switch menu. Configuring CRS1xx/2xx are an absolute nightmare, exponentially more complicated to do very basic switching. If you want to go back to that method you're insane

I want to recommend MikroTik to friends/family--- but cant due to complexity for them.

But why? Do you have shares in the company or are a distributor and benefit from the number of units shifted? Residential market is amply serviced by other vendors. We don't install mikrotik anywhere a customer wants access to it precisely for the reasons you stated, we provide them when it's a managed device and they don't touch it

I agree. The old vlan method or switch menu was a nightmare. When first migrating to the new bridge vlan method, it was confusion. But now it makes sense - but takes experience. For outsiders who are use to iOS access/trunk type setup; its difficult.

The same here, we provide when it's a managed router provided by us under our services. Then this convo take take a different turn as far as RoMon and how awesome it is.

So many awesome MIkroTik only features, but yet - other aspects that are almost perfect. I guess we all cant have it all, or perhaps we're all so passionate and we want the best products and features from MikroTik; all about setting expectations.

Don't tell us that VLAN configuration is done differently in RouterOS than by everyone else! That simply is NOT true!

Across the board there are different ways of handling VLANs, broadly speaking:
- the VLAN-centered method where you configure a VLAN and specify which ports should be tagged and untagged members
- the port-centered method where (besides that you configure the VLAN anyway) you specify for each port which VLANs are present on that port, tagged or untagged.

And then there are the systems where you need, for each untagged port, to tell the system twice how it is to work: what VLAN the incoming untagged packets should go to, and of what VLAN(s) the port is an untagged member.
It may seem that it is like that for RouterOS, but that is not really true: when you set the VLAN for incoming untagged traffic on a port, the port is automatically added as an untagged member of that VLAN. That is not true for some other manufacturers! E.g. I have a Netgear switch where you NEED to set it two times, or it will not work.

What method is better? It depends. Sometimes it is more convenient to have everything neatly available under the VLANs, sometimes it is better to have it by port. But I surely would suggest to move the "bridge port pvid" setting to the bridge vlan setting. I cannot imagine a situation where you would usefully have a port as an untagged member of multiple VLANs, which is a flexibility that this config provides. Most other manufacturers do not even allow such a configuration.

I cannot imagine a situation where you would usefully have a port as an untagged member of multiple VLANs, which is a flexibility that this config provides. Most other manufacturers do not even allow such a configuration.

I can't even imagine how such a config would work in practice. Destination IP or MAC-based VLANs or something like that?
As a networker who cut his teeth on Cisco IOS, I'm #TeamPort myself

I cannot imagine a situation where you would usefully have a port as an untagged member of multiple VLANs, which is a flexibility that this config provides. Most other manufacturers do not even allow such a configuration.

I can't even imagine how such a config would work in practice. Destination IP or MAC-based VLANs or something like that?
As a networker who cut his teeth on Cisco IOS, I'm #TeamPort myself

Well, what you would get would be similar to what you get when you connect a Windows PC to a hybrid port: the traffic towards the device would be the merged traffic of all configured VLANs, and the traffic from the device would all go to one specific VLAN (the PVID).
How that is useful, I do not know. How it causes big and mysterious problems, I unfortunately know all too well!
(I cannot understand that Microsoft still has not fixed this design error in 2024)

(I cannot understand that Microsoft still has not fixed this design error in 2024)

I can. The current Windows network stack (L1-L4) has, due to historical reasons, a numerous serious flaws and limitations. Addressing these issues would require a complete rewrite of the entire stack from scratch which whould be practically impossible due to extensive legacy dependencies.

Well, at least they could have integrated some filter so that VLAN information is not silently dropped when the network card driver does not have a VLAN configuration interface.
It was never a good idea to put that layer in the network card driver and the manufacturer-specific config section, but I can understand that this is no longer easily fixable.
But they should so something that the traffic is not silently merged, especially now that we have IPv6 SLAAC (another stupid design, but not made by Microsoft AFAIK).

I cannot imagine a situation where you would usefully have a port as an untagged member of multiple VLANs, which is a flexibility that this config provides. Most other manufacturers do not even allow such a configuration.

I can't even imagine how such a config would work in practice. Destination IP or MAC-based VLANs or something like that?
As a networker who cut his teeth on Cisco IOS, I'm #TeamPort myself

D-link has it (well, slightly different) and even advertises it as "asymmetric VLAN". The use case: a bit weird way of raw firewall rules without firewall. Or very convoluted way of bridge port horizon. E.g.

• device1: port 1 has ingress PVID 100 and for egress it's untagged member of VLANs 200 and 300
• device2: port 2 has ingress PVID set to 200 and for egress it's untagged member of VLAN 100
• device3: port 3 has ingress PVID set to 300 and for egress it's untagged for VLAN 100 and 400
• device4: port 4 has ingress PVID set to 400 and for egress it's untagged for VLAN 300

So device3, connected to port 3 can send packets to device1 connected to port 1 but can not send traffic to device2 connected to port 2. Likewise device2 can send traffic to device1 but not device3. Device3 can send traffic to device4 and device1 and can receive traffic from these two (but not device2). And device4 can send traffic to device3 and receive traffic from device3 (but not other devices). And all of that enforced by switch chip.
In this example device1 might be main router, device2 a guest AP, device3 "home PC" and device4 a NAS

The difference between ROS and above described D-link is that in ROS ingress PVID is always also available for egress (untagged) while in D-link it's possible to have completely distinct values. But it's possible to construct similar functionality, perhaps it's necessary to make it even more convoluted with more VLAN IDs used.

As a networker who cut his teeth on Cisco IOS, I'm #TeamPort myself

LOL, #TeamPort, agree I think.... I take you to mean being able to express normal things like "access"/"trunk"/"hybrid" on /interface/bridge/port including what's tagged for trunks WITHOUT having to use convoluted /interface/bridge/vlans stuff. They already do a lot of "dynamic config" in bridge VLAN setting (i.e. PVID becomes untagged) but they same dynamic config isn't possible for trunks from config of a bridge port itself.

But where this all goes south, even if you could declare the trunked vlans directly on bridge port... is needing the stupid "/interface/bridge/vlans add tagged=bridge vlan-id=XXX" to be defined first. That just plain confusing. If there is an associated /interface/vlan that has interface= the bridge, I have NEVER understood why it's NOT AUTOMATICALLY tagged on bridge interface. No complains about having some way to setup some "asymmetric VLAN" / "very convoluted way of bridge port horizon" — but the config scheme should focus on making it easy to setup "trunk port" and "access ports", not force everyone through the convoluted /interface/bridge/vlan stuff....

And I do think @DarkNate's critique goes deeper than just bridged tagging. For routers that support L3HW and HW-QOS the bridge vs switch add even MORE confusing config... e.g. the opaque/complex relationship between /interface/ethernet/switch/port and an corresponding /interface/bridge/port. There are many subtle rules/restriction L2/L3/QoS HW offloading so many ways to have traffic on a "slow path" – just because of the split of responsibilities between /interface/ethernet/swtich/... and /interface/bridge/... when there is just ONE physical port but multiple config locations for it... #TeamPort

I cannot imagine a situation where you would usefully have a port as an untagged member of multiple VLANs, which is a flexibility that this config provides. Most other manufacturers do not even allow such a configuration.

I can't even imagine how such a config would work in practice. Destination IP or MAC-based VLANs or something like that?
As a networker who cut his teeth on Cisco IOS, I'm #TeamPort myself

One use case is where you want port isolation but the switches don't support it. I.e. you are setting up a hotel network, you bought Cisco CBS250 switches and discover they artificially gimp out that functionality because reasons....
You want a simple switched network, but don't want Unit 10 to have any cross talk to Unit 20 so they don't see each other printers, TVs, whatever.
You can create a different VLAN for each port but typically this means with 100 rooms you'll need to make 100 subnets, 100 DHCP server pools, 100 rate limit queues etc etc it's a bloody massive PITA

So instead you can just create and join all of those VLANs as an untagged member with the same subnet on a single bridge of a MikroTik router at the head end and use a horizon value. Set ARP to 'reply only' to avoid massive broadcasts and now you essentially have the same as port isolation with minimal administrative overhead

Holy shit! I was gone for a few days and came back to see people STILL fighting over the Linux switchdev/DSA abstraction bridging, switching and VLANs.

It's not a MikroTik problem, it's a Linux switchdev/DSA problem, which will never be solved because it's embedded deep into Linux Kernel source code.

I've spoken to a few ASIC and NOS programmers and the consensus is, it's time to ditch switchdev/DSA and move to SAI:
https://github.com/opencomputeproject/SAI

But before you get too excited, VLAN config on SAI is not that much different:
https://support.edge-core.com/hc/en-us/ ... AN-Routing

Cisco, Juniper, Nokia, Arista, simply never made use of Linux Kernel for dataplane nor used SAI (until recently I believe), they had official SDK access from Broadcom for developing vertical software to program the ASICs, obviously inside the ASIC, the actual VLAN tag/untag is very different from what it looks like in CLI. MikroTik could've done the same with Marvell ASICs, i.e. use their official SDK access to Marvell to develop a simple, unified IRB/bridge/VLAN configuration paradigm in ROSv7, but they did not, they persisted in using the Linux data plane abstraction even for the ASICs, probably because MikroTik is always CPU + ASIC forwarding and never 100% ASIC forwarding, leading to complexity if they tried the Cisco way.

One use case is where you want port isolation but the switches don't support it.

Port isolation aka Private VLAN is supported in the original Linux bridge codebase, it's also on Tik:
https://help.mikrotik.com/docs/display/ ... tisolation

I've used this feature in ISP use-cases combined with DHCP Snooping on the switch and local-proxy-arp on the BNG.

It's not a MikroTik problem, it's a Linux switchdev/DSA problem, which will never be solved because it's embedded deep into Linux Kernel source code.

So won't all networking solutions based on the Linux kernel have the same issues/limitations?

Well, sort of. It still is the chip that sets the limitations.

Though SAI offers significantly greater flexibility in managing the configuration process from user space (ie ROS) directly to the driver without having to adopt to and pass through the Linux kernel DSA interface structures (which BTW was originally developed in the early 2000s for a Marvell chipset).

Once the chip manufacturers' drivers start to mature, I think we'll see a rapid transition to SAI that will likely benefit all parties.

One use case is where you want port isolation but the switches don't support it.

Port isolation aka Private VLAN is supported in the original Linux bridge codebase, it's also on Tik:
https://help.mikrotik.com/docs/display/ ... tisolation

I've used this feature in ISP use-cases combined with DHCP Snooping on the switch and local-proxy-arp on the BNG.

Sure and it's all well and good to mention best practices, the reality is the real world doesn't always work that way for a multitude of reasons. One such may be that there's 30x PoE switches in place that work perfectly fine yet are basic SOHO units that do support neither private VLAN's nor port isolation but do support VLAN tagging. What I suggested is a perfectly valid solution to work around the problem without needlessly dropping $30,000+ on new switches

The best network engineers aren't the ones that can perfectly follow the recipe of standards, but ones that can work out viable solutions to problems as they are presented. RouterOS does REALLY well in this regard in letting you bend or even break rules where appropriately. Just like a double edged sword it cuts both ways but is an incredibly useful tool

Well, sort of. It still is the chip that sets the limitations.

Though SAI offers significantly greater flexibility in managing the configuration process from user space (ie ROS) directly to the driver without having to adopt to and pass through the Linux kernel DSA interface structures (which BTW was originally developed in the early 2000s for a Marvell chipset).

Once the chip manufacturers' drivers start to mature, I think we'll see a rapid transition to SAI that will likely benefit all parties.

RouterOS is an abstraction layer and can still achieve tasks whilst presented in a totally different way to the user. It does not need to specifically follow any other set standards. And wherever the hardware doesn't support it, it can often be emulated in software. Which is what already happens with the Bridge configuration
I'd just like to see it be rewritten in a more sensible manner (like not having to set VLAN's in so many tabs, and laid out in a grid not drop down lists) and handle the abstraction better. There are still a lot of things that disable HW acceleration needlessly, i.e. enabling VLAN filtering on many of the older devices. Necessitating the use of the Switch menu even just for basic functionality like changing the PVID or port isolation without losing HW acceleration. It absolutely could be extrapolated to handle this automatically behind the scenes and keep the config uniform across many more chipsets. It's bloody annoying having to use a CRS1xx/2xx amongst other 3xx switches, or even substituting in something like a powerbox or HEX PoE as the config is all entirely different across them all unless you don't mind 80mbit/s through the CPU

So won't all networking solutions based on the Linux kernel have the same issues/limitations?

It's not an “issue” in terms of raw networking functionality. But it is an issue in terms of UI/UX and human design elements.

Any software product or hardware product that uses switchdev or just simple Linux CPU for bridging and switching of ethernet frames, will have the same “issue”, yes.

People talk about Ubiquiti “simple VLAN” config, I investigated this claim, by going into the Ubiquiti devices with SSH root access, type ip a command and hit enter, you will see that Ubiquiti is actually WORSE than MikroTik, OpenWRT (official Linux DSA configuration docs) etc. Ubiquiti proactively violates the Linux switchdev/DSA paradigm.

This bridge/VLAN/layer 2 UI/UX problem started with Cisco, just type on Google “Cisco VLAN memes”.

If you want truly “clean” problem-free VLAN/IRB/Layer 2 config, then check Juniper, Nokia SR-Linux and hell even Huawei NetEngine products.

Your best alternative is SONiC (excluding Juniper, Nokia SR-Linux and Huawei).

Well, sort of. It still is the chip that sets the limitations.

Though SAI offers significantly greater flexibility in managing the configuration process from user space (ie ROS) directly to the driver without having to adopt to and pass through the Linux kernel DSA interface structures (which BTW was originally developed in the early 2000s for a Marvell chipset).

Once the chip manufacturers' drivers start to mature, I think we'll see a rapid transition to SAI that will likely benefit all parties.

The problem with SONiC and SAI is how fragile the “open source” aspect is for the dataplane, Broadcom calls all the shots and only gives them a firmware blob. It's not open like original DSA/switchdev of Marvell.

If you want TRUE open-source networking, start by getting rid of Broadcom in an anti-competitive lawsuit across the globe.

Sure and it's all well and good to mention best practices, the reality is the real world doesn't always work that way for a multitude of reasons. One such may be that there's 30x PoE switches in place that work perfectly fine yet are basic SOHO units that do support neither private VLAN's nor port isolation but do support VLAN tagging. What I suggested is a perfectly valid solution to work around the problem without needlessly dropping $30,000+ on new switches

I smell an enterprise guy right here from 1995, who's still doing layer 2 access networks and switch daisy chains. No sir, where I come from, we've moved SP, DC and enterprise (offices or campus etc) to 10000% layer 3 routed networks all the way to each access switch in the office room or floors etc. The layer 2 doesn't span. For layer 2 adjacency of Wi-Fi, EVPN + MPLS or VXLAN is used, some Cisco fanboys prefer using LISP, both solutions are 10000% superior to layer 2 spanning AND it REMOVES the need for port isolation because everything is Layer 3 up-to access switch with local-proxy-arp + DHCP Snooping enabled on the access port, for additional security, we enable client isolation on the Wi-Fi APs to block “switching” of clients in the same broadcast domain.

RouterOS is an abstraction layer and can still achieve tasks whilst presented in a totally different way to the user. It does not need to specifically follow any other set standards. And wherever the hardware doesn't support it, it can often be emulated in software. Which is what already happens with the Bridge configuration
I'd just like to see it be rewritten in a more sensible manner (like not having to set VLAN's in so many tabs, and laid out in a grid not drop down lists) and handle the abstraction better. There are still a lot of things that disable HW acceleration needlessly, i.e. enabling VLAN filtering on many of the older devices. Necessitating the use of the Switch menu even just for basic functionality like changing the PVID or port isolation without losing HW acceleration. It absolutely could be extrapolated to handle this automatically behind the scenes and keep the config uniform across many more chipsets. It's bloody annoying having to use a CRS1xx/2xx amongst other 3xx switches, or even substituting in something like a powerbox or HEX PoE as the config is all entirely different across them all unless you don't mind 80mbit/s through the CPU

You're making this a complex explanation. It's called UI/UX design and programming. That's what MikroTik (and the Linux kernel netdev contributors) need to fix.

Remember, it's often “nerds” making software for nerds, not many nerds know how to make software for non-nerds and that's why UI/UX design experts (like those at Apple) make millions of dollars each year in total comp, because so many few of them are alive in the world.

... start by getting rid of Broadcom in an anti-competitive lawsuit across the globe.

I bet the entire WVM sphere (absolutely no pun intended ) would totally agree with that as well..

You're making this a complex explanation. It's called UI/UX design and programming. That's what MikroTik (and the Linux kernel netdev contributors) need to fix.

Remember, it's often “nerds” making software for nerds, not many nerds know how to make software for non-nerds and that's why UI/UX design experts (like those at Apple) make millions of dollars each year in total comp, because so many few of them are alive in the world.

Couldn't agree more, though I think MT is actually pretty decent compared to pure Linux firewalls/routers like OpenWrt, pfSense/OPNSense and similar systems.

Couldn't agree more, though I think MT is actually pretty decent compared to pure Linux firewalls/routers like OpenWrt, pfSense/OPNSense and similar systems.

Yes, MikroTik abstraction is better than vanilla Linux kernel dataplane config (Debian, Ubuntu, OpenWRT-ish although OpenWRT is also abstracted itself).

*Sense are *BSD based. BSD is dead in the networking world of professionals. Juniper dumped BSD in favour of Linux for the control plane in JunOS Evolved (which is now in process of replacing JunOS).

I couldn't even get simple GREv6 working on FreeBSD a few months ago. *BSD is generally a security-oriented platform, but it lacked 2000+ programmers that build networking software, which is what Linux netdev community has. I would say FreeBSD is 10–15 years behind Linux network stack.

Just look at Apple macOS pf implementation vs Ubuntu nftables.

Allthough macOS PF is pretty okay, the standard interface (i.e., Apple > Settings > Network > Firewall) is pretty much a disaster and pfctl is too cumbersome IMO. I wouldn't cope without Litle Snitch (or LuLu).

Although macOS PF is pretty okay

Nah, it's terrible and doesn't even function like *BSD real pf stack or in today's world, eBPF.

Yeah, it's a pity the extended version of BPF hasn't been introduced as standard in macOS. It might be because Apple doesn't sell "network-related" hardware, IDK. And since macOS extensions (kext) are moving away from the kernel, third-party versions of eBPF will probably disappear.

I smell an enterprise guy right here from 1995, who's still doing layer 2 access networks and switch daisy chains. No sir, where I come from, we've moved SP, DC and enterprise (offices or campus etc) to 10000% layer 3 routed networks all the way to each access switch in the office room or floors etc. The layer 2 doesn't span. For layer 2 adjacency of Wi-Fi, EVPN + MPLS or VXLAN is used, some Cisco fanboys prefer using LISP, both solutions are 10000% superior to layer 2 spanning AND it REMOVES the need for port isolation because everything is Layer 3 up-to access switch with local-proxy-arp + DHCP Snooping enabled on the access port, for additional security, we enable client isolation on the Wi-Fi APs to block “switching” of clients in the same broadcast domain.

See this here is the problem with this thread in general. If you get to work solely with companies that just throw money around willy nilly on high end gear and needlessly replace infrastructure for little to no practical benefit (which makes me think why are you even bothering with the MikroTik forums) then thats great for you but ironically worthless in many other segments.
Your focus aligns better with the Cisco/Juniper space (which is already served just fine), not so much the broader MikroTik demographic. A lot of what you say has merit but its a bit like trying to sell Ferrari's, great if you're in Hollywood, not so great in South Africa where a Toyota is far better suited

See this here is the problem with this thread in general. If you get to work solely with companies that just throw money around willy nilly on high end gear and needlessly replace infrastructure for little to no practical benefit (which makes me think why are you even bothering with the MikroTik forums) then thats great for you but ironically worthless in many other segments.
Your focus aligns better with the Cisco/Juniper space (which is already served just fine), not so much the broader MikroTik demographic. A lot of what you say has merit but its a bit like trying to sell Ferrari's, great if you're in Hollywood, not so great in South Africa where a Toyota is far better suited

You're missing the points and issue with MikroTik completely. Re-read this thread one more time. It has nothing to do with $30k routers or switches.

MikroTik layer 3 based networks costs about $400 or whatever per router or CRS etc. You don't need more than $2k for a small enterprise to be 100% layer 3 with VXLAN (or MPLS + VPLS) on MikroTik.

I've worked with rich companies that buy Junipers like it's a sandwich, and I've worked with poor companies that can barely afford a god-damn CCR2216.

In addition, unlike “Cisco engineers” or “Juniper engineer”, I'm a network engineer, I'm vendor-neutral, i.e. MikroTik is one of the vendors I work with, I hate Cisco, I like Juniper, want to play with SR-Linux of Nokia, I dislike Arista for being a Cisco-fake and Huawei is fairly decent.

You're missing the points and issue with MikroTik completely. Re-read this thread one more time. It has nothing to do with $30k routers or switches.

And yet you completely missed what I wrote. Maybe try re-reading my post
The purpose was to illustrate a simple use case with MikroTik of
1) not needlessly spending a lot of extra money on gear to provide functionality that isn't needed and has no tangible benefit in that particular use case
2) massively simplifying the configuration and deployment

You keep preaching #2, its the entire basis of this thread right? Simplify and unify configuration. Yet are more than happy to not comprehend and disregard what others say by then mentioning a substantially more complex setup that suits a completely different market segment
MikroTik are actually fantastic at point #1 which is a big reason why they are so widespread. Are they perfect? Hell no, but bang for buck absolutely phenomenal and as already mentioned, they allow you to bend/break rules and 'best practices' where appropriate. Exactly like the scenario I mentioned.
They're the Leatherman of networking, perfect? nope, but you can do almost everything to accomplish a certain outcome. Not always as well as a dedicated tool, yet that is their network segment

Yet are more than happy to not comprehend and disregard what others say by then mentioning a substantially more complex setup that suits a completely different market segment

Isn't this the basis of many threads? Love the hardware (mostly), love the power of RouterOS (but not without it's annoyances) and recognise there are multiple use cases that fall broadly into SOHO and the rest. The rest is usually supported by trained IT professionals so the complexity is accepted, sometimes grudgingly. Although it's up against CISCO, Juniper etc which is a tough battle to win.

However, RouterOS/WinBox/WebFig is a poor fit for SOHO which happens to be the area I work in and is where Mikrotik have lost potential sales to UBNT and others.

This could be solved with different software (inc. a cloud/web centric controller) but it's entirely Mikrotik's choice whether they want to tackle this requirement/market segment. We know that because it's a software issue that it can be solved.

Aside but it's been made horribly messy recently with the move from ROS v6 to ROS v7 and the spaghetti around ARM/ac/ax/wireless/wifi etc. I installed a Unfi Wi-Fi 6 access point recently without realising it was AX until I spotted the 6 on my mobile. I've spent HOURS pouring over the various Wi-Fi settings around AX on my home AX2.

I'm sure we all want Mikrotik to thrive and want the company to succeed but they make it difficult to keep the faith sometimes There are a lot of very knowledgeable people on this board, more so IMO than any other board I've come across in 40 years in IT. I do sometimes feel Mikrotik are missing a trick by not engaging in discussion.

This Unifi fantasy tale like stories - I feel the urge to respond.
To setup a AP with ROS is straight forward and by far no rocket science. I don't talk about bugs that should be fixed. Unifi software has no bugs? sure! Just read about a Unifi AP Firmware release recently that was only 1 day in Early Access and release the next day as stable. People freaked out due to issues.
And on Mikrotik I am not obliged to use a damn controller software, or publish my network to the cloud. The only offline offer from Unifi (besides a Gigabyte blown Controller Java Software) is an Android app, a crippled down thing (Unifi even tells you so) that even does not allow you to configure WPA3 on a U6+ - you need to use the full fledged controller for this setting. Completely insane. And not butter smooth as well: This year I did a initial configuration for an U6+ using the app. Then adopted it via controller and afterwards did a change in the app. result: AP dead. it broadcasted some random string SSIDs suddenly, couldn't connect and a factory reset / forget was needed. But have to admit: provisioning was just a reset button away.
And once you switch from "auto" (which is for max compatibility and disables many features like WPA3, FT, etc) to "manual" you enter the "same atmosphere of problems" you criticize on ROS.

And yet you completely missed what I wrote. Maybe try re-reading my post
The purpose was to illustrate a simple use case with MikroTik of
1) not needlessly spending a lot of extra money on gear to provide functionality that isn't needed and has no tangible benefit in that particular use case
2) massively simplifying the configuration and deployment

You keep preaching #2, its the entire basis of this thread right? Simplify and unify configuration. Yet are more than happy to not comprehend and disregard what others say by then mentioning a substantially more complex setup that suits a completely different market segment
MikroTik are actually fantastic at point #1 which is a big reason why they are so widespread. Are they perfect? Hell no, but bang for buck absolutely phenomenal and as already mentioned, they allow you to bend/break rules and 'best practices' where appropriate. Exactly like the scenario I mentioned.
They're the Leatherman of networking, perfect? nope, but you can do almost everything to accomplish a certain outcome. Not always as well as a dedicated tool, yet that is their network segment

People already agree with me, both in this anonymous forum, and also in the real life global telecom industry. You can disagree, but I got 100 people agreeing with me for every 1 person that disagrees with me.

Again, my point is:
viewtopic.php?p=1076110#p1075843

Example of a person in this forum who agrees with me:
viewtopic.php?p=1076110#p1075856

This Unifi fantasy tale like stories - I feel the urge to respond.
To setup a AP with ROS is straight forward and by far no rocket science. I don't talk about bugs that should be fixed. Unifi software has no bugs? sure! Just read about a Unifi AP Firmware release recently that was only 1 day in Early Access and release the next day as stable. People freaked out due to issues.
And on Mikrotik I am not obliged to use a damn controller software, or publish my network to the cloud. The only offline offer from Unifi (besides a Gigabyte blown Controller Java Software) is an Android app, a crippled down thing (Unifi even tells you so) that even does not allow you to configure WPA3 on a U6+ - you need to use the full fledged controller for this setting. Completely insane. And not butter smooth as well: This year I did a initial configuration for an U6+ using the app. Then adopted it via controller and afterwards did a change in the app. result: AP dead. it broadcasted some random string SSIDs suddenly, couldn't connect and a factory reset / forget was needed. But have to admit: provisioning was just a reset button away.
And once you switch from "auto" (which is for max compatibility and disables many features like WPA3, FT, etc) to "manual" you enter the "same atmosphere of problems" you criticize on ROS.

Ubiquiti is absolutely horseshit. MikroTik should learn from VyOS developers (who are by the way, real network programmers in 2024 who embraced VPP/DPDK stack), learn some product management approaches of Juniper, Nokia SR-Linux dev team, and… Hire global talent, not just limit itself to a small pool of engineers inside Latvia (literally a tiny stretch of land that's smaller than some private properties in larger countries).

You're way off base!

It's in no way not fair to compare an embedded NOS like MT/ROS to VyOS, which is a full-fledged Debian Linux solution primarily for x86_64 boxes or virtual NOSes that at a minimum requires 2 GB of storage and 512 MB of RAM. ROS should be compared with NOS built on embedded systems such as VxWorks, QNX, FreeRTOS, or NOS solutions like OpenWrt, Tomato, etc. The other players you mentioned belong to a completely different division as well.

And BTW, VyOS is still a standard Linux distribution NOS, which, like any other Linux distribution, can implement applications using the DPDK libraries. DPDK appliances typically require 10-12 GB of memory at cold boot but more demanding apps, when warmed up, usually require several times more, i.e. +64 GB for mid- to high-end systems [EDIT: which btw are the most common configurations on the market]

So please get the facts straight and stop wh*ng about things that are not comparable.

Ubiquiti is absolutely horseshit. MikroTik should learn from VyOS developers

Are you trying to get banned with all these unprofessional tirades?

Bad language aside, UBNT's EdgeRouter series were based on a fork of VyOS. (Source) If VyOS is the fount of networking wisdom…? The mind boggles attempting to string the logic together here.

a small pool of engineers inside Latvia (literally a tiny stretch of land that's smaller than some private properties in larger countries).

Larry Ellison — one of the major tech billionaires — is famous for owning nearly all of Lanai, at 364 km², with an estimated population of around 3400.

Latvia is 177× larger, with ~540× the population. It's roughly the size of West Virginia on both measures.

You're not helping your case by using "literally" in a comparison that's 2 orders of magnitude off the observable facts. It makes us ask what other facts you've distorted in an attempt to make your case.

You're way off base!

It's in no way not fair to compare an embedded NOS like MT/ROS to VyOS, which is a full-fledged Debian Linux solution primarily for x86_64 boxes or virtual NOSes that at a minimum requires 2 GB of storage and 512 MB of RAM. ROS should be compared with NOS built on embedded systems such as VxWorks, QNX, FreeRTOS, or NOS solutions like OpenWrt, Tomato, etc. The other players you mentioned belong to a completely different division as well.

And BTW, VyOS is still a standard Linux distribution NOS, which, like any other Linux distribution, can implement applications using the DPDK libraries. DPDK appliances typically require 10-12 GB of memory at cold boot but more demanding apps, when warmed up, usually require several times more, i.e. +64 GB for mid- to high-end systems [EDIT: which btw are the most common configurations on the market]

So please get the facts straight and stop wh*ng about things that are not comparable.

@Larsa, when I say VyOS, I specifically only cared about the dataplane options (DPDK 100GB code is not the only option), which would be perfect for MikroTik embedded ROS (on modern arm64 hardware).

MikroTik FastPath/Track is already a precursor version of modern-day XDP/eBPF data plane. The latter runs on tiny Pis as well with limited storage.

It appears, users on this forum, do not really talk to/learn from REAL network programmers in the industry. So I rest my case.

Are you trying to get banned with all these unprofessional tirades?

Don't know what you mean. I talk the same “unprofessional tirades” at work, with clients, with boss/managers/owners/C-suites, peers etc. No problems making $$$$ or developing solutions or buying solutions.

If you want to ban me, then ban me and make it permanent this time. I already asked Normis last year to delete this account of mine, but he refused.

Bad language aside, UBNT's EdgeRouter series were based on a fork of VyOS. (Source) If VyOS is the fount of networking wisdom…? The mind boggles attempting to string the logic together here.

Larry Ellison — one of the major tech billionaires — is famous for owning nearly all of Lanai, at 364 km², with an estimated population of around 3400.

Latvia is 177× larger, with ~540× the population. It's roughly the size of West Virginia on both measures.

You're not helping your case by using "literally" in a comparison that's 2 orders of magnitude off the observable facts. It makes us ask what other facts you've distorted in an attempt to make your case.

EdgeRouter is forked from Vyatta, not VyOS. Please stop with the fake news.

The landmass? Was figure of speech, are you really saying Latvia's population density has global-level number of talent density? You must be dreaming and never worked at global capacity like I have.

@Larsa, when I say VyOS, I specifically only cared about the dataplane options (DPDK 100GB code is not the only option), which would be perfect for MikroTik embedded ROS (on modern arm64 hardware).

DPDK in an MT embedded system using a standard SoC? You're joking, right? BTW, it's not 100GB of code we're talking about here, but hugepages for buffer sizes, queue depths, etc..

DPDK in an MT embedded system using a standard SoC? You're joking, right? BTW, it's not 100GB of code we're talking about here, but hugepages for buffer sizes, queue depths, etc..

I just said "not the only option", AKA it MEANS, DPDK is NOT the only option.

But you've been going on about how MikroTik should look into DPDK. What are you trying to say? That MikroTik should develop DPDK high end appliances, or did I miss something like an alternative to DPDK? Similarly, any other options out there will need a ton of memory to work their best, which is exactly what DPDK is all about.

But you've been going on about how MikroTik should look into DPDK. What are you trying to say? That MikroTik should develop DPDK high end appliances, or did I miss something like an alternative to DPDK?

RouterOS CHR/bare-metal — DPDK/VPP
RouterOS embedded — XDP/eBPF

EdgeRouter is forked from Vyatta, not VyOS. Please stop with the fake news.

Don't VyOS and EdgeRouter have the same legacy root of Vyatta so it's reasonable to compare EdgeRouter and VyOS, albeit the fork seems to have been a long time ago.

@Darknate - you even admitted you were a pain in your original post. Maybe remind yourself of that. For the record, I tend to agree with your original post although I'd disagree on UniFi been useless. I've got more happy UniFi customers than Mikrotik.

When Mikrotik started it was have been unthinkable to run routing on Linux at large scale. Different world for a while. And we seem back to talking ASIC again...

I hate Ccisco [...]
I dislike Arista for being a Cisco-fake

That explains a lot. My take on Mikrotik history is that someone had the idea to put a Cisco IOS face over Linux sysctl. Then, double-down by creating their own scripting language to rival Cisco TCL's complexity. So yeah if you "hate" Cisco IOS config, the yeah RouterOS config be a real disappointment.

If Mikrotik wanted to rid the world of cisco, would/should have continued that and supported EIGRP. Shipped likely sailed, but it's stuff like that keeps folks locked into cisco etc IMO. So not sure some new nifty eBPF architecture with modern data plane actually help too many of current Mikrotik users. If starting from scratch, perhaps that kinda of architecture is what you'd do. But Mikrotik isn't starting from scratch and they have existing customers to appease.

RouterOS CHR/bare-metal — DPDK/VPP

DPDK is a set of user-space libraries that normally won't fit into an embedded system. I don't see the point of using ROS to develop a bare-metal DPDK appliance for a tailor-made solution on a market Mikrotik doesn't operate within (i.e. way out of their league).

RouterOS embedded — XDP/eBPF

While XDP/eBPF is very capable performance-wise, it is still a Linux Kernel extension and cannot be compared to a tailor-made user-space application based on the DPDK libraries.

That explains a lot. My take on Mikrotik history is that someone had the idea to put a Cisco IOS face over Linux sysctl. Then, double-down by creating their own scripting language to rival Cisco TCL's complexity. So yeah if you "hate" Cisco IOS config, the yeah RouterOS config be a real disappointment.

If Mikrotik wanted to rid the world of cisco, would/should have continued that and supported EIGRP. Shipped likely sailed, but it's stuff like that keeps folks locked into cisco etc IMO. So not sure some new nifty eBPF architecture with modern data plane actually help too many of current Mikrotik users. If starting from scratch, perhaps that kinda of architecture is what you'd do. But Mikrotik isn't starting from scratch and they have existing customers to appease.

Well, RouterOS v8 could be “from scratch” maybe Rust-based or Zig-based or something. Max performance, memory safety built-in, supports modern day programming features and frameworks etc.

For RouterOS v7, the only option is XDP/eBPF data-plane. Forget DPDK/VPP probably.

DPDK is a set of user-space libraries that normally won't fit into an embedded system. I don't see the point of using ROS to develop a bare-metal DPDK appliance for a tailor-made solution on a market Mikrotik doesn't operate within (i.e. way out of their league).

While XDP/eBPF is very capable performance-wise, it is still a Linux Kernel extension and cannot be compared to a tailor-made user-space application based on the DPDK libraries.

Do you not understand what DPDK/VPP is? There is no "appliance", it's 100% software-only using CPU. MikroTik only needs to delete the code for netfilter framework dataplane and replace with with DPDK/VPP for the dataplane, control and MGMT plane will retain netfilter framework code (ideally augmented with XDP/eBPF instead).

For embedded arm64 hardware, I don't think you understand how powerful XDP/eBPF based data plane is. Again, you guys seem to have never interacted with DPDK/VPP/XDP/eBPF programmers in real life before and have no idea what you're talking about.

RouterOS v8 could be “from scratch” [...] For RouterOS v7, the only option is XDP/eBPF data-plane. Forget DPDK/VPP probably.

Or in RouterOS v7, don't fuck with the data plane. Fix bugs, and there many. Make the AX more centerialized and simple. And add more docs, especially on interop with cisco/etc.

NOW... For RouterOS V8, you're not wrong: XDP/eBPF architecture is pretty nifty. In theory, existing V7 config could be "compiled" to some V8 eBPF runners.

Or in RouterOS v7, don't fuck with the data plane. Fix bugs, and there many. Make the AX more centerialized and simple. And add more docs, especially on interop with cisco/etc.

NOW... For RouterOS V8, you're not wrong: XDP/eBPF architecture is pretty nifty. In theory, existing V7 config could be "compiled" to some V8 eBPF runners.

Probably yeah.

For RouterOS v8, CLI/Config style needs to be overhauled to be streamlined and more futureproofed for their future products as well, I keep referring Nokia SR-Linux for this reason, please review their CLI/open source project.

...Again, you guys seem to have never interacted with DPDK/VPP/XDP/eBPF programmers in real life before and have no idea what you're talking about.

DarkNate ... if you are so annoyed with Miktorik as company and with that forum so be so corteuos and just stop posting.
You are not able to prove that anyone of us has never interacted with "programmers" in the real life and we do not have power to check you have such an experience so it's a lose-lose situation. In terms of duscussion culture you overuse forum rules and you feel allowed to be as you are.

Please DO stop rocking the boat as you think that you know better than others. Noone forces you to do that so it's only your own internal need to be quite rude and you just look for "wording fights".

Once again: PLEASE DO HOLD YOUR HORSES.

Permanent-delete my account. Problem solved. What are you waiting for? Send request to admins to delete this account, permanently.

Moderators are not admins. Not our decision.
Just stop posting ... problem solved permanently.. Fast & simple if only you want.
Even if the account would be deleted you can create a new one and the story would repeat.

Other solution is that we all assume that you are smarter, better, stronger, taller, more handsom so noone could compete you.
With that assumption you can start posting just technical posts and let us draw from the well of wisdom you are,

Agreed?

Agreed?

Well, it is a thread @DarkNate started – not some bitting invective injected into someone else's posting. Kinda different cases IMO.

The back-and-forth over some folk's tone get's annoying too.

Do you not understand what DPDK/VPP is? There is no "appliance", it's 100% software-only using CPU. MikroTik only needs to delete the code for netfilter framework dataplane and replace with with DPDK/VPP for the dataplane, control and MGMT plane will retain netfilter framework code (ideally augmented with XDP/eBPF instead).

I feel pretty comfortable using solutions built with DPDK for now, but thank you for your concern. Just so you know, DPDK appliances are custom-built for specific tasks. And like I've said before, those aren't really meant for embedded systems. Also, there's no real benefit to using ROS/DPDK in a virtual appliance, actually it's the opposite since ROS has been stripped down to run on embedded systems due to space constraints.

For embedded arm64 hardware, I don't think you understand how powerful XDP/eBPF based data plane is. Again, you guys seem to have never interacted with DPDK/VPP/XDP/eBPF programmers in real life before and have no idea what you're talking about.

Let's get the facts straight, shall we? ;- )

eBPF is a flexible kernel extension using JIT compilation that allows you to run arbitrary small programs instead of static LKMs. XDP is a hook/trigger on top of the NIC driver just before SKB that can be used by any kernel service but has been primarily optimized for use with BPF.

Both have been around for approx 8-10 years.