you are right
but
i think MikroTik in its roots started with a strange way to do bridging (version 5 etc) and many people started to using it and learned that way
i think in 6.41 MikroTik tryed to correct course with Bridge VLAN filtering with some sucess but had up to some extend still allow old style configurations working.
maybe MikroTik try to do things in a different way to avoid pattent hell
anyway, maybe what we have today is the result and remanents of that history, and that cannot be wiped From overnight
I was lucky, never learned old way of MikroTIk bridging so i embrace Bridge Vlan Filtering without a hassle, for me was a matter of add L3 and go
Yeah, the old VLAN config method on MikroTik was rubbish, but it's not so different from how most people do it on Cisco, JunOS, Arista either as of 2023, so I wouldn't blame MikroTik for it, because this dumb approach predates even the birth of MikroTik. @IPANetEngineer can probably elaborate from his experience with Cisco/Juniper in the early ages of the internet.
The “new” bridge method that MikroTik implemented was based on DSA, which for some reason, only Linux programmers and nerds know about? Most network engineers have no clue this is the main backbone for the bridge config approach or rather VLAN bridge aware approach and in general most Cisco/Juniper affectionados learnt squat on Linux networking to begin with, so they shit on MikroTik without real solid technical arguments:
https://www.kernel.org/doc/Documentatio ... sa/dsa.txt
Cumulus Linux also recommends the same thing as MikroTik:
https://docs.nvidia.com/networking-ethe ... idge-Mode/
The reasons why you would use VLAN-aware mode for bridges are:
Scale: The VLAN-aware mode can support 2000 concurrent VLANs while the traditional mode supports only 200 concurrent VLANs.
Simplicity: VLAN-aware mode has a simpler configuration.
However, what differentiates MikroTik from Cumulus compatible hardware (or other vendors in general)
1. Bridge config is highly hardware dependent, one wrong config on a specific hardware model, and you're done for with offloading:
https://help.mikrotik.com/docs/display/ ... +switching
2. Even if you do the bridge config correctly, if you have a large network with complex topology, you cannot use the bridge so easily on all the downlink ports if your hardware model have weird switch chip and non switch chip combo like those old CCR models or simply more than one switch chip for different set of ports, can't remember the models off the top of my head. So meaning, if your hardware has more than one switch chip or one switch chip for some ports but not the others, it adds complexity to the config. Especially for medium to large scale networks with a variety of topologies, especially unconventional ones.
3. As you already know, on MikroTik hardware offloading depends on proper bridge config, on Cisco/Juniper/Arista, you don't need a bridge config for hardware offloading.
With that being said, I personally prefer bridge config (also called IRB in Juniper/Cisco world) even on those big boys for the simplicity reason mentioned on Cumulus docs. I'm not sure why Cisco and Juniper certifications don't teach this bridge config approach. It simplifies config by a ton and helps achieve what some automation experts would call “unified config”. Some people just love complexity (hello MikroTik?) instead of KISS principle.
So in short, all this complexity MikroTik brought to itself, leads to the reality that only a few MikroTik or Linux specialist can truly do L3 offloading/bridge config correctly with any hardware model and in any network topology setup. Which as we can see from this thread, means 0.1%.
The real solution here for MikroTik, which we both know, isn't going to happen is:
1. MikroTik needs to correct their complexities and/or mistakes using the daemon/CLI/UI/UX. Which means a user only configures a single bridge on a single device, irrelevant of the hardware model and software will handle the correct mapping to ensure 100% native hardware offloading subject to ASIC capabilities.
2. Once the UI/UX/CLI config for bridge is hardware independent, the network topology dependency is simplified and people can then just work better with it.
The newer CCR models like CCR2116-12G-4S+ doesn't have this problem, even hAP ax2 doesn't have this problem, but CCR2004-16G-2S+ for example has this exact same dumb problem like their models from 2010 or something. You can verify this by looking at the block diagrams.
I'm not a hardware engineer, but I am curious as to how Juniper/Cisco achieves hardware offloading even if you use bridge or no bridge, or bridge some ports, and not others? MikroTik if possible, should implement a similar approach, but still push for bridge config like Cumulus did of course, it's still the best way forward.
I will give a real life example of how many ISPs and enterprise dump MikroTik because of “high CPU usage” where the actual reason is the lack of knowledge on proper bridge config for their specific hardware model:
This is a real example of one large scale ISP serving half a million customers with a bunch of CCR1072-1G-8S+, roughly 15k PPPoE customers on each CCR1072-1G-8S+ back in 2020-21.
What these idiots did was:
1. No bridge config, therefore no bridge/L2 fast-forward/fast-path
2. Created QinQ/VLANs using Cisco/Juniper style directly on the physical interfaces
3. Did their best to crap up on the MTU config for their MPLS/VPLS/PPPoE, therefore leading to CPU overhead for packet de-fragmentation and fragmentation
What they should've done:
1. Bridge all downlink ports together, enable bridge/L2 fast-forward/fast-path and then enable VLAN filtering
2. Properly configure L2/L3 MTU on the physical ports, therefore ensuring no crap up on MPLS/VPLS/PPPoE and hence zero CPU overhead for packet de-fragmentation and fragmentation
3. Follow hardware specific bridge config as per MikroTik docs in general.
So long story short, this is how MikroTik loses even loyal customers to other vendors like Edge-Core/Cumulus/IPInfusion(?)/Russian BisonRouter etc.
I don't know how Latvian culture is, but something about MikroTik's approach to the market feels very… “Free for all” type approach, which as we can see, lead them to these various dumb problems over the years. They should increase both hardware/software quality, increase pricing for CCR models etc, increase licensing fees for high-grade switches/routers which therefore will fund high quality software/hardware employees. It's 2023 and RouterOS v7.8 still fails to do BFD, still fails to show BGP prefix count in the UI/UX/CLI.
And oh, maybe launch 400G-2Tbps routers, with say 4M to 16M ASIC route offloading capacity? With “line cards”? MikroTik has potential to be a serious threat to so-called “big vendors”, but they for whatever reason fail to capitalise on that market. I know a lot of companies that would dump big vendors for MikroTik if they sold such products and fix the issues mentioned.