I would second this. Additionally, keep in mind that MikroTik is really a behemoth company now that could easily move into the higher strata of equipment and price, but they willingly don’t want to do it. Good example is equipment prices - even if there is no equipment due to shortages, they did not rise prices almost at all and kept it down. IMO that is a real Chad move.
Additionally, their software is extremely powerful and quite open. Sometimes it is hard to do some stuff (or impossible, or complicated), but realistically the level of interaction with the system you will get with MT is better than with other vendors that “pack-in” and hide stuff how their systems work. And some stuff is straight impossible to do with other providers. For example, I use NV2 pseudobridges for industrial machines and it works perfectly in a way that I have local LAN wherever I want without cables. Cambium for example does not have solution for something like that, and they have phenomenally performant equipment.
I don’t agree … and I wrote my reasoning in post #69 above. Configuring switch chip via bridge configuration interface has nothing to do with hardware topology, it’s an UI design decission.
IMO it’s similar to dilemma between using 3D graphic card using GPU-specific ABI versus using (partly? HW-accelerated) OpenGL/DirectX …
If it is purely UI decision, then why there are three different ways to set VLANs depending on underlying hardware? If it was unifying, all hardware should work the same.
(I don’t mind these peculiarities, just making a note for the sake of conversation.)
bridge with vlan-filtering is the unified solution, introduced in ROS 6.42. All newer devices can offload it to HW for some functions and some older devices got HW offload later (Mediatek and Realtek switch chips with ROS v7) while some devices can’t/don’t offload it to HW (my personal pain are Qualcomm switch chips, nowdays used in most but the newest wireless routers by MT)
This is the UI decission I’m talking about as it supersedes the other ways (which I’m mentioning below)
switch-chip specific is the legacy way and was the way to do it prior to 6.42 on devices with switch chips (which supported / exposed VLAN functionality) for switching between wired ports
vlan interfaces combined with per-VLAN bridges is also legacy way and was the only way of dealing with VLANs on devices without switch chip. Obviously this one doesn’t allow for any kind of HW offload.
So if we discard the legacy ways, then there’s only the bridge way which is unified regardless the underlying hardware. The fact that both legacy ways still work does not change this. And if one uses one of legacy ways, he has to have good reasons for it. The third option on my list above is outright ugly and inefficient and IMO there’s no excuse to use it post-6.42.
If I missed a way to set up VLANs in ROS, please remind me about it.
The problem is that I am not sure if it is true or not? (I only have devices for VLAN that are specified under the “new way” of setting VLANs). Take a look here: https://help.mikrotik.com/docs/display/ROS/Basic+VLAN+switching I can see three distinct methods:
CRS3xx, CRS5xx series switches, CCR2116, CCR2216 and RTL8367, 88E6393X, 88E6191X, 88E6190, MT7621 and MT7531 switch chips
Well, in my counting, your options #2 and #3 count as one: configuration is done via switch chip submenu (/interface/ethernet/switch) and there are different “dialects” depending on switch chip capabilities. Sure CRS 1xx/2xx are a bit more capable than AR/QCA and hence have a bit more extensive documentation (separate from the “generic” documentation to avoid too much of confusion).
But anyway, this is legacy way. One can use bridge way but looses much of performance (and even some functionality) … but the “unified bridge way” is possible. Indeed these devices are examples of cases where bridge way might not be the way to go … I guess MT won’t introduce HW offload for these devices, they will rather let them EOL (and support the legacy way until then).
And this is the actual reason (IMO) for bridge with HW offload: to hide HW dependant config from users (CRS1xx/2xx are pretty similar devices so they can share configuration methods, other more modern devices have more differences so configuring them via switch chip interface would become a nightmare for documentalists).
Anyways, it is nice to have unified way to do this. From what I understand, most, if not all of the new devices support the new bridge mode, so that is fine (and preferable) by me.
In the context of bridge nyszeries explanation forget about switch chip (the real, piece of hardware). In this context, there’s only switching functional block, executed by CPU.
Where actual switch chip gets into the picture is L2 HW offload. But this happens transparently to the configuration (and philosophy), explained by @sindy, so it doesn’t change how all functions of bridge are put together.
@sindy I would like to ask a few questions please,
If I understood correctly, there should be two “entities” capable of switching, the switch chip and the switching functional block in the cpu?
Also when you specify a bridge in the tagged or untagged parameter in /interface bridge vlan does that apply for the router-facing port of the switch or the switch-facing interface of the router, or both?
/interface bridge add name=bridge1
/interface bridge port add bridge=bridge1 interface=ether2
/interface bridge port add bridge=bridge1 interface=ether3
/interface bridge port add bridge=bridge1 interface=ether4
/interface vlan add vlan-id=10 interface=bridge1
And after I issued these command it should look like the image below?(excluding switch chip because I still didn’t understand that yet)
I drew the bridge as another seperate “entity” running inside the switch functional block because I think that the switch functional block is always there and is only used when the bridge is created. Is this correct?
In the context of bridge nyszeries explanation forget about switch chip (the real, piece of hardware). In this context, there’s only switching functional block, executed by CPU.
Where actual switch chip gets into the picture is L2 HW offload. But this happens transparently to the configuration (and philosophy), explained by @sindy, so it doesn’t change how all functions of bridge are put together.
Say I have a switch connected to my Router that sends tagged frames with vlan id 10, when my router receives the frames and sends the reply to the switch, does my router tags the frame it about to send to the switch with vlan id 10 or is it the switch’s duty to tag the reply coming from my router?
I intentionally avoid the subject of VLANs in this topic to prevent it from becoming even more complex. So please create a new topic with a copy of the above post and I will respond there.
[/quote]
I intentionally avoid the subject of VLANs in this topic to prevent it from becoming even more complex. So please create a new topic with a copy of the above post and I will respond there.
[/quote]
