https://mum.mikrotik.com/presentations/ ... 545769.pdf

I was interested on this presentation because it shows how to use VLANs but with the emphasis on using the switch CHIP and thus using hardware offloading.
(vice using the more CPU intensive method of vlan bridge filtering).

The advantage of the authors method is clear (efficient use of hardware in the router and performance). However what are the drawbacks that this method must have otherwise vlan bridge filtering would go the way of the dodo bird?????

It's been discussed recently: viewtopic.php?f=2&t=150172

Life is a circle LOL. So there is no downside and I am an idiot for using bridge vlan filtering when I could be doing via switch chip

Configuring switch chip using Switch menu is actually the old thing. I found it somehow unintuitive. But it's also true that it's very long time since I tried to use it, and I don't know if anything changed since then. I thought that bridge VLAN filtering would make Switch menu obsolete, i.e. that any config possibly supported by device's switch chip would be applied automatically. But it looks like it didn't happen (based on what I read, I currenly don't have any device with modern switch chip to test with).

Sadly what @Sob writes is true: MT devs stopped at implementing HW offload for CRS3xx, other devices with capable switch chips didn't get that treatment.

The positive thing about bridge vlan-filtering is unified configuration on any RB device. When doing stuff on switch chip, one has to study particularities and set things up accordingly. Meaning that config is even less portable than it normally is. Those particularities include feature-set supported (number of VLANs, support for hybrid ports, support for VLAN in general, ...) and concrete commands used to set things up. In addition to that, there are devices which feature (on paper) decent switch chip, but it may be buggy without ETA on fixing it (Atheros8327 in RBD52G) ... probably that's out of MT devs hands ... and bugs in ROS are easier to fix (most of the time).

So I'd say that most of users (@anav included ) should be using the bridge vlan-filtering because it is, as @Sob wrote, easier to understand (that's relative, some don't get the concept after years of looking at it ) and the same for all devices. Only when this approach becomes a bottleneck, one should switch over to using switch-chip based VLANs.

... I currenly don't have any device with modern switch chip to test with).

Sadly modern SOHO-class RB devices seem to contain crippled switch chips (RB4011 has RTL8367, RB750Gr3 has MT7621) which don't have any VLAN support what so ever. Seems like MT is trying to create some gap between RB and CRS (even low-end) devices. Which in SOHO segment is a pity (RB951G makes a wonderful gigabit ethernet switch, a bit pricey though).

Sadly modern SOHO-class RB devices seem to contain crippled switch chips (RB4011 has RTL8367, RB750Gr3 has MT7621) which don't have any VLAN support what so ever. Seems like MT is trying to create some gap between RB and CRS (even low-end) devices. Which in SOHO segment is a pity (RB951G makes a wonderful gigabit ethernet switch, a bit pricey though).

The Realtek and MediaTek switch chips are fully-featured devices and include VLAN support - the issue here is the Mikrotik approach to network architecture which stems from originally using Atheros switch chips.

Looking at Winbox and seeing ether1-5 interfaces you are fooled into thinking that the CPU has five ethernet interfaces, each connected to the corresponding physical port. In reality the CPU has one or two ethernet interfaces wired to a switch chip (either within a single system-on-chip package or separate CPU and switch chips), which in turn is wired to the physical ports. Network traffic is always passing through the switch chip irrespective of if you are using the interfaces individually or in a bridge (with or without VLAN filtering).

Atheros implement a proprietary extension to the data flowing between the CPU and switch which specifies which physical port the traffic is associated with so the driver can multiplex/demultiplex the traffic to the logical interfaces. Not having this in the other manufacturers chips you have to resort to using VLANs to handle this multiplexing/demuliplexing which would impose restrictions - making five VLAN IDs reserved, no VLAN trunks. Internally Mikrotik will be using VLANs to perform this multiplexing/demuliplexing with the Realtek and MediaTek switch chips, and don't provide any user access to VLAN functionality.

If you look at OpenWrt you get a better idea of how the hardware is arranged, e.g. https://openwrt.org/toh/mikrotik/mikrotik_rb750gr3

Sadly modern SOHO-class RB devices seem to contain crippled switch chips ...

Internally Mikrotik will be using VLANs to perform this multiplexing/demuliplexing with the Realtek and MediaTek switch chips, and don't provide any user access to VLAN functionality.

Thanks for the explanation and link to openWRT page. So it turns out that switch chips are not crippled, it's MT abusing their functionality and thus crippling them.
Now it's getting clear why sometimes things behave weirdly if IP address is bound to slave port instead of bridge ... and HW offload is active: in such cases ROS actually doesn't know exact bridge port handling the traffic (because all ports use same PVID so that switch chip can do the switching between ports) and gets confused ... if address is bound to bridge (as it should be), then things are clear.

Okay mkx, thanks for muddying the waters with that last post. Not smart enough to really make sense of your wisdom. I have the RB450Gx4. Would that unit be capable of using the switch chip approach and retain HW offloading advantage without any serious drawbacks? Concur that sticking to vlan bridge filtering which I kinda can implement is probably less dangerous for me.

Specs say that RB450Gx4 uses IPQ4019 SoC which in turn is supposed to have AR8327 switch chip embedded. If it's true what @tdw writes about Atheros' proprietary extension (and I believe he's right) and if that embedded switch chip really is complete AR8327 (I've mild doubts about that, my RBD52G using very similar SoC behaves slightly different than RB951G which uses discrete AR8327 - read: RBD52G features a bug which is not present in RB951G), then it seems to be safe to use full HW accelerated ethernet switching without side effects.

If you try it, have a pack of Aspirins handy to battle potential headaches