RouterOS bridge mysteries explained

Thx a lot for this answer, I have to put in sketch to make me understand it well

By the way
What means

If the “bridge” port is in pure trunk mode,

It means that ingress-filtering is set to yes and frame-types is set to admit-only-vlan-tagged on that port.

But, when we have hardware with “separate chip” we need connect them via external short patchcord to get full hardware speed.
Example is like with 2011/3011/4011/ and CCR2004. With a 1100AHx4 we need 2 connections. That politics kill us count of port we can use and this is real “mysteries” too.

Additional “mysteries” are when people see that Bridge have VLAN tab, each bridge port have VLAN tab, each wlan have own VLAN entry, Switch menu … and by adding differ config to each chip.. and mix stuff with say “real hardware acc you get when you connect 2 ports of differ hw chip” and we buy 4011 and we have -2 ports… .

No one good toturial on youtube, and I constance add on MikroTik YT channel a comment:

Please do a new series of videos about vlans. Each episode should start of selecting devices to method, theory about that method, example configuration for Access/Tagged/Hybrid and Trunk - those on one device only, and how use those vlans on /ip/address to reach them, how use that method with bonding and Q&Q. I hope you can stop this series on 6 episodes bcs I know at least 6 way of creating vlans and each should be shorter then 1h. I hope you clear all stuff about VLAN on MikroTik by that videos, I wait for that video series. Remember, Hybrid port are for wifi AccessPoint very very important.

I hope the documentation or proper video will be on this topic.

Does MTCSWE answer on all of that “mysteries” ? NO because only one short Module3 is about VLANs who should be only this topic take 2-3days .

For me the VLANs are the most hard stuff to learn. And I watch videos from 2013 from tiktube… and this topic have not proper documentation and path to learn like HowTo/Video material.
This is like puzzle topic.

PS. yes, I wrote this post under the influence of emotions

That’s not a bridge mystery, it’s a switch mystery … possibly due to the fact that only a handful of devices are affected and some more complex logic would be needed to properly configure switchX-CPU interconnect to pass all the necessary VLANs. Plus it always involves CPU … by using direct cable connection one is actually adding another interconnect, this time switch1-switch2 … which is missing from hardware layout of those devices.

I guess MT still wants us to forget about switch menus and switch to using bridge menus exclusively (hence no decent tutorials for switch chip configuration) … which we all gladly would if all switch chips could HW offload bridge configuration, so it’s to Mikrotik again.

MT documentation on VLANs and bridge configuration is indeed confusing … for all people not fully grasping the bridge mysteries explained in this topic. After that things become clear it’s easeier to follow documentation … but would be even more clear if settings for different bridge personalities were spread into different categories (i.e. CPU-facing port settings under /interface/bridge/port, although the fact bridge port is created automatically would confuse people being used to use “add” everywhere, while in this case one would have to use “set”). Not an easy task of making thins easy for everybody.

Pun intended ? :laughing:

No, but did get out nicely. Definitiely better than

I guess MT still wants us to forget about switch menus and bridge to using bridge menus exclusively …

:laughing:

I must say i agree 100% with SiB and many others. The Mikrotik documentation is, well, plain awful.
I’m sorry but that’s a fact. For about two years i struggle again and again and again in finding my way around those “help-pages”.
It’s painful and annoying at the same time. No new look and no new Css will ever make up for the lack of quality. Quality in conception and language. The reader always misses a clear perspective on the underlying topics. The text often crates confusion instead of conclusion and clarity. When do i use switching, when do i use bridging. On which devices with what chip under which circumstances. What do i do when wireless is added to the equation. Can i still use vlan switching then? And if not, how do i meet the topic of reducing cpu-load and security. It’s a nightmare.

A documentation should be concise, logically organized and make as sure as humanly possible, that nothing can be misunderstood. But in Mikrotik documentation, we find slang, tons of grammar-mistakes, insinuation and sarcasm. Well, that’s not helpful. Much too often it is an all confusing soup of too many uncertainties and poorly organized cross-references. And don’t get me started on the mikrotik video series. Unfortunately not better at all. Striving to match video formats familiar from other vendors, they fail as unfortunate as the textual counterpart. No visual polishing is ever going to improve the lack of quality in concept. It should be obvious the according company teams (sometimes i wonder if they even exist) that there will probably be a reason, why one finds thousands and thousands of people on youtube and other forums, who try to do this job:
explain how to achieve what on mikrotik.

The company should really finally hire an agency that actually knows what it’s doing to accomplish this basic task. A usable manual transports all necessary information in a suitable manner, language, system and style. I can’t count how many times these frustrating situations made me regret ever having bought a Mikrotik product. And i say this knowing that the product itself is a great deal. There’s just a an ever pressing need for a proper explanation on how to use it.

Obviously opinions here. Not to be an apologist… But Mikroitk manual is more a reference manual. A well-thought out “user guide”, that’s certainly missing (but certainly explainers in docs, beyond YouTube, then a few years). And if we look at cost-per-packet/unit/etc, you’re kinda getting a discount because they don’t have an elaborate product lifecycle - so I try not to get frustrated over sloppiness in non-engineering things, clearly not their strength. Totally agree that certainly MT could better explain “why” you might one approach over another. They do gloss over when you’d want to use the switch chip config vs bridge - but since the switch chips have different features, it perhaps not a clear cut answer.

My point is more I think you have the wrong target here. From user POV, the tricky thing in the bridge is you may (and generally must) have to add the bridge as a member of VLAN. The “may” part is what’s explained here. Largely it’s because the “bridge as bridge-port” thing is largely a stand-in for all of the network service Mikrotik could provide (e.g. that need the CPU), and that include the Layer3 parts of VLAN interfaces. Again, I think @sindy does good work here is trying to unwind the nuances of that. But from user POV, it just one more item to do.

Again I’m not some apologist here. Mikrotik largely models the “linux way” of networking - that’s kinda by design. So in mainline Linux, they have the same “vlan-filtering” switch, imagine it’s kernel primitive – so Mikrotik’s wrapper in bridge is largely UI around the linux features for bridging (with more tweaks to work all types of interface/drivers they support). FWIW, here is what how RedHat describe it all: https://developers.redhat.com/blog/2017/09/14/vlan-filter-support-on-bridge# (see also intro: https://developers.redhat.com/articles/2022/04/06/introduction-linux-bridging-commands-and-features#bridging_with_netfilter )
which while formatted/profread better, actually has less info than Mikrotik.




Should Mikrotik add more help, both in docs and UI, even more over what linux does? Absolutely. But I wouldn’t characterize the bridge as “broken”, just both misunderstood and finicky.

Hi to all, I think I start some of OffTopic here from #44, sorry to all for hijack topic. Maybe some admin can move it to other thread.

I have dream that MikroTik in product page in Documentation tab, add info to that “VLAN x,y,z” documentation can be assigned to selected model. This will solve many problems.
Maybe we as community can do that “matrix” of RB & method who can be used, but I know that 90% of ppl say this is done, just check your soc and read proper documentation, but this is not that easy in reality.
Of course we have this @pcunity post who give some answers, but they not select method per used device, means they not work on all platforms.

I track many of YT videos on this topic and latest time YT: The Network Berg do some video about few ways of doing vlans 1, 2 and YT: KalTek show perfect way of using RB4011 in 1, 2 and he do a command matrix for 3 group of RBs, here: https://i.imgur.com/6e1pvaB.png but he ignore 1GbE to get success :(, he use one switch soc and ignore 2 others.

Common, repeat problem what I see from past 10years:

  • no real configuration matrix of RB → method x,y,z
  • How x unit with wireless can assign differ SSID into vlans configured by method x,y,z
  • We use method x,y,z and how setup a new Hybrid port for new e.g. AccessPoint (his pvid1 as mgmt, next vlans as trunk) or new server (his pvid1 as IPMI, next vlans as trunk), etc.
  • How use method x,y,z on unit who have few hardware switch soc (like RB1100/4011 etc) with inter hw soc patchcord and without it by local switch menu (e.g. CRS125)
  • We can use separed incomming Trunks into each hw switch soc to solve problems, witch the same vlans..
  • How in Method x,y,z add a 4cable bonding0 with main stacked core switch
  • VLANs are to complex, I call to you to solve this for me…

If we can select our RB and documentation answer on above topics then I can say, YES WE HAVE ALL ANSWERs and SOLUTION to that VLAN MYSTERIES.
I really hope that MikroTik do something with that “old” topic because they create that new Jira Documentation page, I hope they plan it well.
BR
Marcin (SiB) Przysowa

Mikrotik posted in another thread, http://forum.mikrotik.com/t/dhcp-vs-vlans/163884/18 which confirms some details here and highlight potential changes coming:

We had a discussion about dynamically adding the bridge interface (CPU) as a VLAN member when this kind of configuration is detected, and even adding the bridge as a tagged VLAN member when you create a routable VLAN interface on the bridge, but I cannot provide any release date for this feature.

Just use this to decide on which VLAN configuration to use for what model, no confusion whatsoever.

https://help.mikrotik.com/docs/display/ROS/Basic+VLAN+switching

can you tell us when to use Bridge Interface as Logical Interface in other settings like Firewall?

The first of those two cases - when you have untagged traffic to/from the CPU-port.

thx

By “bypass” do you mean the frames that never ingress router via the switch-facing interface of the router, but are sent directly to other port of the switch. Does it also imply no (un)tagging, i.e. packet is sent without its VLAN-priority (and thus ingress priority) implicitly stripped?

Yes. I’d rather say they do not egress via the router-facing interface of the virtual switch, but that’s the other side of the same thing.


It doesn’t. The virtual swich tags and untags frames on ingress and egress if vlan-filtering is enabled, depending on the relationship of a given port to a given VLAN - access (untagged) member, trunk (tagged) member, or non-member. “Inside” the virtual switch, all frames are tagged in this case. If vlan-filtering is disabled, no tagging or untagging is performed as the frames pass through the switch.

If “hardware accelerated bridging” is enabled, i.e. if the switch chip is used to forward the frames between physical Ethernet interfaces, the behavior regarding tagging and untagging depends on a particular device model - some switch chips can perform tagging and untagging in hardware in accord with the bridge settings, some can do it but vlan-filtering must be disabled on the bridge, some cannot do it at all. But hardwae accelerated frames bypass the CPU completely, so even the bridge filter cannot affect them.

The bridge filter is currently not very useful when handling tagged frames, i.e. when vlan-filtering is enabled on the bridge, as matching on IP headers and L4 headers is not possible for them.

Don’t “use-ip-firewall” and “use-ip-firewall-for-vlan” resolve this?

No. These are intended to allow traffic prioritization using queues (aka QoS) also for bridged traffic, but it causes a lot of headache if used along with NAT, so only enable these items if you exactly know what you need them for.

No as in “won’t work in principle” or as in “will work, but with many caveats”?