VLAN and filtering on non-CRS3xx devices

If I have read post/threads like Bridge http://forum.mikrotik.com/t/bridge-vlan-filtering/120657/8 and wiki pages like https://wiki.mikrotik.com/wiki/Manual:Interface/Bridge#Bridge_Hardware_Offloading and https://wiki.mikrotik.com/wiki/Manual:Basic_VLAN_switching#Other_devices_with_built-in_switch_chip.

So if understood/read this correctly, I can get VLAN filtering on non-CRS3xx devices like my RB3011, either by

  1. Using /interface bridge vlan and loosing hardware offload, or
  2. By using /interface ethernet switch

But if I use the second (Switch menu) method, I loose STP (in general, or just RSTP?), since this is implemented in the bridge code?

And as of now, MikroTik does not seem to have any plans on getting HW offload to work with Bridge menu on other models than CRS3xx?
:question:

I personally think that peoples angst, about vlan filtering affect on CPU as something evils is too broad brush an approach.
For most home owners the ease and convenience of vlan setups as per
http://forum.mikrotik.com/t/using-routeros-to-vlan-your-network/126489/1

Is a great way to go.
I am sure for enterprise scenarios the throughput (CPU load) is critical but thats not everybody.
Caveat that is just an opinion from a non IT trained layperson with no MT credentials.
I prefer keep it simple!

… But still I wonder if my understanding is correct? :slight_smile:
(I’m already running bridge based VLAN, but using the pre 6.41 way, one bridge per VLAN, thinking to update that to the new way. But thought maybe some performance comparison would be interesting. I don’t have CPU issues at all on RB3011.) :smiley:

You don’t run bridge based VLAN. In ROS, bridge is “kind of a switch”. In pre-6.41 times bridge was a “dumb switch” and passed traffic around without regard to VLAN tags, only cared about dst-mac-address. In post-6.41 times bridge (if vlan-filtering is set to yes) became “smart switch” which knows about VLAN tags.

So what you do virtually have is a number of dumb switches, each spanning single VLAN. If you have VLANs configured in /interface ethernet switch, then most of those “dumb switches” (per-VLAN bridges) don’t do much as switch chip does the bulk of work (unless you have some wlan interface part of that bridge in which case the bridge does shuffle traffic to/from wlan interface. Same goes to all other non-ethernet interfaces that might be members of such bridge) [case 1a].
On the other hand, if you don’t have anything in /interface ethernet switch, but instead you have VLAN interfaces defined on each individual ethernet interface (and bridging those vlan interfaces), then all of the traffic already passes device’s CPU [case 1b].

In the new way with bridge being “smart switch”, all of traffic will pass through bridge (that’s device’s CPU). [case 2]

I don’t think there’s a big difference between cases [case 1b] and [case 2] CPU-load wise … but you might want to test.

Back to my main question: Is this understanding correct:

And:

I’ve no idea about STP, but

More or less yes. While the /interface bridge vlan covers all sorts of interfaces (ethernet, wireless, PtP, IPsec, …), the /interface ethernet switch obviously only covers ethernet ports run by switch chips. Any you can’t really mix the two approaches, so if you want to join a non-ethernet interface to a VLAN-infested bridge, you will quite likely have to use the former approach (wireless interfaces are notable exceptions, they have their own VLAN configuration parameters).

Yes, your understanding is correct. Switch chips of other than CRS models do not support any flavor of STP in their hardware, which means that use of any kind of STP is mutually exclusive with hardware forwarding using these chips. I still believe it would be possible to break this spell on switch chips which support rules and independent per-VLAN learning, as it would be possible to use the rules to forward STP BPDUs to the CPU and the CPU could in turn dynamically modify the VLAN port membership maps of the switch chip (effectively enabling and disabling forwarding of a set of VLANs through individual ports as MSTP does), but it is probably too much effort to spend for too little outcome for the R&D.

Thank you! :smiley:

I dare to correct you a bit:

  1. /interface bridge vlan applies only to bridge ports, and bridge ports can be only L2 interfaces, which means Ethernet, wireless, EoIP, and outside the VLAN context, also BCP L2 tunnels using all kinds of PPP-based connections. BCP L2 tunnels are currently (last tested with 6.44.x) not compatible with vlan-filtering=yes. IPSec is out of question, it is pure L3, like all the PPP tunnels without BCP.
  2. you can mix bridge and switch chip forwarding, this is exactly what the “bridge with hardware acceleration” does. Technically it works like two switches interconnected together - frames which can take the short path within the same switch chip do take it, and all frames between devices connected to different chips take the path through the interconnect. Of course, handling this “fusion” architecture at STP would be more of a challenge but still doable.

This is why I would like to clone Sindy’s brain and then somehow figure out how to siphon the knowledge into mine directly.
I just get giddy when MKX is schooled. :wink:

No one knows everything, and sometimes you don’t realize all dependencies when writing something. I felt it necessary to comment not in order to school Metod but not to leave misleading information without comment on a place where it might be trusted by some innocent soul.

Check how many times @Sebastia or @Sob have to “school” me.

Everyone has their niche area of interest or expertise! Its always fun seeing what pretzel configurations you all come up with!!