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
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
Statistics: Posted by DarkNate — Thu Feb 01, 2024 9:28 pm