++
With 5-6 lines of configuration you can see the whole port config and know exactly what it’s supposed to do without having to look in 10 different places.
Why would de CLI need to have anything to do with your automation? The CLI is for human consumption, the automation isn’t.
Nobody’s talking about automation in that particular context. I clearly replied to this comment by quoting it. I think you’re smoking something.
They should have copied Cisco’s way of doing switching (in terms of > UI/UX/CLI)> . Much more intuitive and easier to troubleshoot.
What is wrong with people? MikroTik has a clear, up-to-date, concise documentation piece on basic VLAN configuration for ALL their hardware, how the hell do you get confused with this?
https://help.mikrotik.com/docs/display/ROS/Basic+VLAN+switching
I suppose English comprehension is a challenge for some.
No need to take cheap shots, but concur, just because the vlans are not on one screen for easy manipulation/viewing doesnt mean its impossible.
The logic is there its not magic, just apply it.
Tom, fly me up to your place and I can help with your vlans ( just call it a business expense, like maybe in ski season )… except I do it only on routers, not on switches LOL.
What is wrong with people? MikroTik has a clear, up-to-date, concise documentation piece on basic VLAN configuration for ALL their hardware, how the hell do you get confused with this?
https://help.mikrotik.com/docs/display/ > … +switching
Let me cite you some sentences with warning signs from the same page you mention. And no it has nothing to do with English comprehension.
These are probably no big issue if working every day with MT, you get used to them, but if you do it just occasionally… And you have the different QoS and L3 Offloading stuff, then the Wifi with it´s old an new (Wifiwave2) style configs. Then add Capsman, old and new User Manager, etc.
I don´t want to say that MT should dumb down ROS, but I do think, that even better docs, could help to spend less time scratching your head!
There is room for improvement. MT istself realizes it and brings some great explanatory videos, which you probably don´t need if you have spent some work years on configuring ROS.
On QCA8337 and Atheros8327 switch chips, a default vlan-header=leave-as-is property should be used. The switch chip will determine which ports are access ports by using the default-vlan-id property. The default-vlan-id should only be used on access/hybrid ports to specify which VLAN the untagged ingress traffic is assigned to.
This type of configuration should be used on RouterBOARD series devices, this includes RB4xx, RB9xx, RB2011, RB3011, hAP, hEX, cAP and other devices.
By default, the bridge interface is configured with protocol-mode set to rstp. For some devices, this can disable hardware offloading because specific switch chips do not support this feature. See the Bridge Hardware Offloading section with supported features.
For devices that have multiple switch chips (for example, RB2011, RB3011, RB1100), each switch chip is only able to switch VLAN traffic between ports that are on the same switch chip, VLAN filtering will not work on a hardware level between ports that are on different switch chips, this means you should not add all ports to a single bridge if you are intending to use VLAN filtering using the switch chip, VLANs between switch chips will not get filtered. You can connect a single cable between both switch chips to work around this hardware limitation, another option is to use Bridge VLAN Filtering, but it disables hardware offloading (and lowers the total throughput).
…
@woland: since you picked up a particular part of documentation (a note none the less) as an example of text which should be improved … why don’t you show how it should look like to be more comprehensible? Personally I find the text pretty comprehensible … it might be a bit terse but for person which has good knowledge of VLANs and decent knowledge of how to configure VLANs on ROS device via switch menu I’d say it says everything necessary.
There’s always a problem when something needs to be explained in a way, understandable to readers with limited knowledge on the matter. Then explanation may become overly extensive and thus indigestible for more experienced readers. Ideally documentation should be two-fold: reference manuals and guides “for dummies” (no offense meant). MT has pretty decent reference manuals (yes, some features definitely need improved documentation), but lacks the “for dummies” line of documentation. But then, as a few other posters already noted: I don’t think MT is targeting “dummies” as customer base. Entering SoHo / small WISP market yes, but not targeting Joe Average.
@mkx
No I don´t mean it´s incomprehensible, I mean it´s a lot to process, lot of exceptions. So creating some more recepies and overviews saves time and frustration. Also expands the userbase in the direction of John Does or in the direction of people who generaly don´t want to spend too much time on just configuring VLANs (or an AP, or whatever).
I´m not sure how this is done the best, but I think some better tables or some links from the specific HW documentation to the correct examples could help a lot.
For example: direct users from the HEXs homepage to a simple VLAN config example with HW VLAN Offloading.
I think it would already be helpful to have the specific switch chip with it´s capabilities (and limitations on ROS Version) on the HW Specification page.
Example: HEXs has currently an entry stating it´s Switch Chip is: MT7621A
If I search for MT7621A in the Wiki, there won´t be any hint, that it´s the same as MT7621 and it supports HW VLAN. You find this info only in https://help.mikrotik.com/docs/display/ROS/Switch+Chip+Features#:~:text=Bridge%20HW%20vlan%2Dfiltering%20was%20added%20in%20the%20RouterOS%207.1rc1%20(for%20RTL8367)%20and%207.1rc5%20(for%20MT7621)%20versions.%20The%20switch%20does%20not%20support%C2%A0other%C2%A0ether%2Dtype%C2%A00x88a8%20or%200x9100%20(only%200x8100%20is%20supported)%20and%20no%C2%A0tag%2Dstacking.%20Using%20these%20features%20will%20disable%20HW%20offload.
Example 2:
Trying to find out if L009UiGS-RM supports HW VLAN Filtering?
https://help.mikrotik.com/docs/display/ROS/Bridging+and+Switching#BridgingandSwitching-BridgeVLANFiltering:~:text=[88E6393X%2C%2088E6191X%2C%2088E6190]
The Remark Nr. 3 says:
The HW vlan-filtering and R/M/STP was added in the RouterOS 7.1rc1 (for RTL8367) and 7.1rc5 (for MT7621) versions. The switch does not support other ether-type 0x88a8 or 0x9100 (only 0x8100 is supported) and no tag-stacking. Using these features will disable HW offload.
Since 88E6190 is no RTL8367 or no MT7621, one could get confused, if not reading further down the following:
Currently, CRS3xx, CRS5xx series switches, CCR2116, CCR2216 routers and RTL8367, 88E6393X, 88E6191X, 88E6190, MT7621 and MT7531 switch chips (since RouterOS v7) are capable of using bridge VLAN filtering and hardware offloading at the same time
This info is burried in a lot of noise. That may lead to a lot of confusion.
Yeah, information overload is a pain. 
For Joe Average it should be enough to follow normal bridge VLAN setup practice. Things will get flowing just fine. The matter of performance is secondary and our friend Joe should only start wondering if it sees performance problems. And that’s true for any recent device. AFAIK all new devices with switch chips, launched after first CRS3xx, support HW offload so following basic bridge VLAN setup should yield wirespeed performance. Basic bridge VLAN doesn’t allow for full wirespeed performance on older devices … if our friend Joe wants to star using 5-year old device and drive it to its max, then … sorry my friend, you’ll have to learn a tad more. Or just go for a decently modern device and leave old devices to MT veterans to waste their time on them.
It’s the sheer amount of those foot notes which makes introduction of (HW-offloaded) VLAN-aware bridge so much a good decision. And we really should focus on quality of documentation for decently modern devices, let’s not brag about soon-to-be-EOL device documentation.
And, BTW, I agree that sometimes a rewrite would be in order. Like the noise about switch chips supporting L2 HW offload. Nowdays it would be better to enumerate switch chip models that don’t work with bridge HW offload … this list would interest less users and would likely be even shorter than the (ever lengthening) list of supported switch chips.
I would like to see Mikrotik gain a huge product market share in all Layer-2 ( switches ) and layer-3 ( routing ) markets ( and wireless products ).
I’ve been in the electronics and computer communications industry for almost 50 years now. I’ve seen countless software and hardware products come and go. I’ve also developed and consulted on many new emerging products. Many of those products are now big brand name products that most IT people know - however most of those products are now gone and forgotten things of the past ( because of poor manufacturer/marketing knowledge of what people want to purchase ).
I would like to see new future Mikrotik L2/L3 products change direction and follow the growing popular ONIE x86 open source software/hardware standards.
The benefits of a ( Mikrotik ) WhiteBox ONIE x86 switch/router would be real.
FYI - WhiteBox ONIE x86 systems enjoy the following positive features:
- Growing world-wide popularity x86 ONIE compatible hardware and software.
- Many different x86 ONIE switch/router operating systems natively run on many different switches/router hardware products from many different vendors.
- IT leaders have modern/popular choices for what x86 ONIE router/switch hardware they want to use and which x86 ONIE operating system they want to use.
- If you outgrow a x86 ONIE product ( example , you had a 4-port switch and now need 32 100-Gig ports and some 400-Gig ports ) , you can easily replace the hardware switch and keep your current switch configuration settings.
- If you want to change the x86 ONIE operating system ( example from Windows to Linux or something else ) , you can keep your existing x86 ONIE router/switch and simply replace the operating system.
If Mikrotik were to enter the x86 ONIE software/hardware markets , there could be a sudden demand for Mikrotik products that would make Mikrotik a major player in the IT router/switch industry. There would no longer be any unique Mikrotik forum topics where we discuss things like "How do I make a Mikrotik switch do Vlans - or - How do I configure a Mikrotik router to filter BGP/OSPF/static routes " , because these topics are already well documented and there are many great videos that have been around for many years now.
IMO - There is a huge market that would want to purchase x86 ONIE compatible Mikrotik routers and switches.
IMO - There could be a huge market for x86 compatible Mikrotik ROS/SwOS software products ( if they do it right ).
I love Mikrotik products. I have thousands of them in my server rooms & fiber networks & wireless networks & customer networks. However , I am planning to fork-lift all of my switches in all of my server rooms to x86 ONIE compatible hardware in the near future. Per server room , I need to replace dozens of switches with 2 or 4 larger x86 ONIE switches and support a large combination of 1/10/20/40/100/400 Gig redundant networks.
If Mikrotik were to head down this x86 ONIE industry standards compatible path , I would have a bunch of Mikrotik orders. I’m sure thousands of other IT departments around the world would also take a good look at Mikrotik x86 ONIE products for their long-term goals.
North Idaho Tom Jones
VLANs and switching in general is needlessly complicated. New bridge menu method is ‘ok’ at best but it’s far from optimal. For one I don’t understand why they couldn’t just make it a very simple tag/untag/exclude option for each port in a bridge instead of the way it’s handled. It’s not clear, it’s not efficient. I don’t have as big of a problem with the documentation as I do with the actual bridging/switching implementation
The second major issue is it seems half assed in its implementation. If you want to go slightly beyond just adding VLAN interfaces on a bridge i.e. port isolation well now you’re really up shit creek because you need to work with both the switch menu and the bridge menu if you want to keep hw offload. Now it’s different for multiple different chipsets, Ive found bugs and incorrect information in the documentation on this (posted one not long ago)
Since the bridge menu config (and routeros as a whole) is an abstraction layer anyway, why couldn’t they have just done it sensibly and added yet another abstraction layer under-the-hood that handles the individual switch chip configurations automatically. Everything can then become uniform and consistent and hw offload will be retained in every possible case without having to deep dive into the switch menu config (which is simply awful on the CRS1xx products)
A few days ago I bought a L009 as well, and as a network engineer (Cisco, HP, Pulse Secure, Arista and a lot of other exotics), I too had (and probably will have in the future) a big problem with understanding the Mikrotik way of working. Only thing that comes close to Mikrotik, configuration wise is Compumatica but I won’t bother you with that.
What I am trying to say is that from all the information you can find out there, a lot does not work or is not the way to go anymore. For those who have configured MikroTik in the past it is a lot easier to adapt to a newer way of working and how to implement that in a new product than for those who are completely new to the brand and are only able to rely on there understanding of networking. In my experience so far, the consistency in how to configure different devices is a bit less on a Mikrotik router than a Cisco router but that might be the noob in me.
Just to be clear: I am not trying to offend anyone here but I can relate to the OP even with the poorly chosen ways to express the frustration.
Hopefully I won’t reach that level of frustration
I hope you didnt buy the L009 expecting to use a 1gig ISp provider???
No, I am on a 100M line and was looking for a router and switch replacement to reduce continuous power usage after my 10 year old ubiquiti edgerouter died.
Thank you for sharing. MikroTik has a long history and is jam packed with features on top of features, so understandibly, for new users it is a steep learning curve. One big benefit is that with MikroTik there are tons of learning resources, on youtube, on the web, also the training courses can be very cheap, comparing to other big brands of similar feature set. The downside of course is, you must be willing to learn. If you only need one device for one purpose, you don’t want to invest time and money in learning a whole system, so I can see how it all can be overwhelming.
I had no problem setting up my first Mikrotik in 2016 when they barely had any youtube tutorials and I was only taught basic networking for one semester.
Every time I see IT “”“engineer”“” I remember that old error “We seem to have encountered some issue but our team of trained monkeys is already on it”.
+1 here, 100% agree.
An Professional don’t talk like that!
Look at you how pro you are when you say one time L900 one L9000, when real device is a L009. You just have heard Mikrotik name for 1st time.
As per training Mikrotik allow remote testing through MTCOPS, but this one does not allow you to cheat, that’s is problem you have.
Just contact me and I will open an MTCOPS testing for you free of charge, and if you don’t pass, you will have to post your results here and say a big SORRY to MIKROTIK.
A professional looks to features, not just talking nonsense.
Even that we like Mikrotik Trainers can have our reserves for Mikrotik like we have for all other brands, but one thing is for sure that Mikrotik make difference from others, is the BEST BRAND for “Features/Performance/Cost” if you are searching for this trio to be together in one package.
First of all my apologies. Sometimes you stuck and get out of the mind.
That day was the day.
Instead of spending time with family i stuck there for 15 hours and could not do. With cisco - 15min. With Ruckus - 15min, with linux 30min, With mikrotik 15 hours and no luck.
I believe mikrotik is OK, but some extremely easy things here are loooks imposible.
So once again apologies for this post.
With mikrotik i work for more then 5 years. But had basic needs. Port forward, static IP, another WiFi with SSID, alow ftp, disable some services and etc.. But this time i’ve burned out. i’m sorry about it.
Two years ago i was looking for online courses. But i only found option to fly to Riga and sit there for 3 days. Could not afford it for my self that.