RouterOS bridge mysteries explained

sindy · Sun Mar 21, 2021 7:51 pm

This topic is a reaction to the countless cases of confusion regarding why the bridge “itself” must be listed among tagged or untagged ports of a VLAN in some cases, why the VLAN interfaces must be attached to the “bridge” rather than to its member ports etc. The fact that both “interface” and “port” have multiple meanings in the networking vernacular contributes to that confusion.

This topic does not deal with the details of the “new” way of handling multiple VLANs on a single bridge; for that, a great topic by @pcunite exists.

So, let’s start from a picture of a hardware setup:

router_and_switch_hw.png

Here, everything is clear – there’s a switch to take care about the L2 forwarding and VLAN filtering, and to one of the physical Ethernet ports of that switch, a router is connected using one of its own physical Ethernet ports.

We can tell the switch which VLANs are permitted on each port or, in another words, which ports are members of each VLAN. Some flavor of the Spanning Tree Protocol may run on the switch to prevent L2 loops caused by wrong wiring. And on advanced models, some filters may control forwarding of frames from the ingress port to the egress one(s).

On the router, we can assign an IP address directly to the physical interface; if we want the router to have accesss to multiple VLANs, we could use as many physical interfaces as needed and connect each of them to an access port to that VLAN on the switch, but a better approach is to connect the physical interface of the router to a trunk port of the switch and attach a virtual VLAN interface to the physical one for each VLAN. The virtual VLAN interface picks frames tagged with the right VLAN ID from those that ingress through the physical interface, untags them, and forwards them to the routing engine. In the egress direction, the frames the routing engine sends via this interface get tagged with the right VLAN ID and egress via the physical interface.

We can use a slightly more abstract diagram to represent the same arrangement:

router_and_switch_schematic.png

This diagram may still represent the topology shown on the first picture, only the perspective is slightly different. The abstraction allows us to forget about the hardware nature of the functional components and concentrate on their functionality alone. Even if we implement most of it in pure software, the roles of the functional components do not change, i.e. there is still the router whose one interface is connected to one port of the switch, the switch itself, and the other ports of the switch.

Now the software module called “bridge” in RouterOS implements three of the elements above: the switch-facing interface of the router, the router-facing port of the switch, and the switch itself.
The drawing below illustrates that:

router_and_switch_schematic_bridge.png

So far pretty clear, isn’t it?

And now the confusing points.

Since, when you add a “bridge”,

all the three elements (interface of a router, port of a switch, and the switch itself) are created,
the relationship among the three is a fixed one,
none of the elements has got any configuration parameter that would overlap with a configuration parameter of the remaining two,

the configuration parameters for all the three elements have been grouped on a single row of the /interface bridge table.

In particular:

parameters bearing the same names as those on the /interface bridge port rows, such as pvid or ingress-filtering, are parameters of the router-facing port of the virtual switch
parameters bearing the same names as those on the /interface ethernet rows, such as mtu or arp-timeout, are parameters of the switch-facing interface of the router
parameters that don’t fit to any of the two groups above are mostly parameters of the virtual switch; an exception are the admin-mac and auto-mac parameters, which are also parameters of the switch-facing interface of the router.

The name item is common for all the three elements. So when specifying the membership of the router-facing port of the switch in VLANs, the same name is used to identify the virtual switch and to identify the router-facing port:
/interface bridge vlan
add bridge=bridge-row-name vlan-ids=10,… tagged=bridge-row-name,…

In the bridge filter, the relationship of the frame to the router-facing port of the switch determines the chain to be used: input handles frames that egress from the virtual switch through that port, output handles frames that ingress to the virtual switch through that port, and forward handles frames that bypass that port.

SiB · Sun Mar 21, 2021 10:15 pm

I hope you add information about creating VLANs by new way... and how live with General vlan id:1 and others as Trunk.
For now I use always this howto: https://mbum.pl/archive/vlan-po-nowemu.pdf (Presentation from Ihor Hreskiv at Mikrotik Beer User Meating at Poland 2019, mbum.pl)
Pages: 34 - 50

I can take picture from that PDF and create a Photo-story here. I hope you can do that way edition of your post - this will be greate have it in English.

----------

BTW, It's always good to setup with every bridge a Admin. Mac Address.

----------

Now, the first bridge have a HARDWARE ACCELERATE feature, means we should use one bridge and on it use many vlans

sindy · Sun Mar 21, 2021 10:25 pm

I hope you add information about creating VLANs by new way...

What is missing in this topic about the subject of "VLANs the new way" that I should repeat it here?

SiB · Sun Mar 21, 2021 10:44 pm

This thread should be as first post of your "Using RouterOS to VLAN your network".
In my opinion people not use that grate vlan article because they must go into .rsc file and LEARN / ANALYZE that all stuff.
Here the Photo Story with description for easy examples to reproduce will be great.

History point...
Creating vlans at every ether port and assigning all of them to one dedicate bridge-vlan100 and repeat for every vlan is like ros5 doing.
Next people try learn Switch menu for HW acceleration.
Next are this new way when we use one Bridge with VLAN tab.
Who know, we will have next generation of doing vlans in ros7 or maybe few of them, who know.

anav · Mon Mar 22, 2021 1:53 am

Ahh you mean at the beginning of pcunites thread!!!

Zacharias · Fri Nov 12, 2021 8:36 pm

@sindy,

To my understanding, what you describe as the switch-facing interface of the router, and the router-facing port of the switch is actually what enables the switch to communicate with the CPU of the Device (Management Access, Layer 3 Services and more ), the communication line of the switch with the Routing Block ( Switch - > CPU Port ).

So the Bridge consists of the Switching Block and the Switch-CPU Port.
Am i missing something ?

sindy · Fri Nov 12, 2021 9:04 pm

It's unfortunately not that simple. The internal Ethernet link between the physical switch chip and the CPU is not a 100 % functional equivalent of the link between the router-facing port of the virtual switch and the virtual-switch-facing port of the router. VLAN frames from wireless and L2-tunnel interfaces can flow to and from the virtual switch even if the router-facing port of the virtual switch is not a member one of the respective VLAN. But the /interface vlan attached to the virtual-switch-facing interface of the router can only send/receive traffic to/from the virtual switch if the respective VLAN is allowed on the router-facing port of the virtual switch.

Zacharias · Sat Nov 13, 2021 1:08 pm

Yes, but how can you not include the CPU Port in the Bridge Entity ?

Amm0 · Sat Nov 13, 2021 9:47 pm

Yes, but how can you not include the CPU Port in the Bridge Entity ?

I think that gist of @sindy's description while it's convenient to think of the "bridge" as being the L2 access to "CPU port", like it for "/ethernet switch". And, this simplifying assumption likely works in most cases – e.g. you probably need to add the bridge as a VLAN port in Bridge VLANs if you're doing L3 stuff too. But that's not exactly true in all cases. And, it's also a counter-intuitive configuration: treating the bridge as a port in the VLAN tab, while a lot of times necessary, isn't natural esp. if you think of "classic" access port/truck terms.

So the "router side" and "bridging side" way of describing "under the covers" of the "new VLAN method" is actually a helpful way if you're trying to understand the "why you need to add the bridge as port". @pcunite VLAN manifesto describes the various options, some good practices, and mechanics, BUT not the why.

And @SiB is also right, some pictures next to packet traces/"L2 frames breakouts" is awful helpful way of presenting it. While the Vinn diagram shows the multi-faceted roles, it doesn't actually help understanding the relationships.

sindy · Sat Nov 13, 2021 10:31 pm

Yes, but how can you not include the CPU Port in the Bridge Entity ?

Easily. The bridge is a software thing, and so is the router, so both run "inside" the CPU, hence the traffic between the "software switch" facing "software port" of the "software router" and the "software router" facing "software port" of the "software switch" never passes across the CPU port. Think of CCR or CHR where no switch chips exist and bridging is nevertheless possible.

Hardware-wise, the CPU port <-> switch chip port connection is inside the bridge, not between the bridge and the router. A frame coming from the wire first hits the Ethernet port of the switch chip, then it gets sent via the CPU-facing port of the switch chip to the physical-switch-facing port of the CPU, and only then it gets to the "software router" facing "software port" of the "software switch" (or doesn't, if it instead gets forwarded to the "software switch" port to which a wireless interface or an L2 tunnel interface are connected).

Internally, the "hardware accelerated bridging" in fact means that one of the ports of the full-software bridge is the switch-chip-facing port of the CPU, so frames that can be forwarded directly between Ethernet ports of the switch chip don't ever get to the CPU. But the aim of the concept is not to bother the administrator with these under the hood details and let them see it as a single bridge with both physical and virtual ports.

Zacharias · Sun Nov 14, 2021 8:10 pm

Ok @sindy i agree...

the CPU port <-> switch chip port connection is inside the bridge

So it is part of the Bridge Entity...

mkx · Sun Nov 14, 2021 8:40 pm

I don't think it matters how things are implemented to the last detail. Surely implementation is different on devices with switch chip from implementation on devices without switch chip. Only MT developers can tell how exactly are things implemented under the hood.

What matters is conceptual design and that one is same for all devices. Understanding concept is key to using bridge correctly and effectively. And first post of this thread explains concept quite nicely. Even if I personally agree with explanation by @sindy this doesn't mean it's entirely correct. Too bad nobody from Mikrotik chimed in to add any details (or even only to tell that @sindy's explanation is spot on).

Guscht · Sun Jan 02, 2022 10:48 pm

AFAIU the CPU-Port is called the same as the bridge. This is very confusing, MT should have named this "CPU-Port" or something.

Short explanation:
- If the CPU-Port is set untagged, this is the only way to communicate with the Bridge Interface (itself) and services "behind", like DHCP, NTP... In this state "bridge1" is CPU-Port and Interface.

- If the CPU-Port is set tagged, you will need a dedicated VLAN-Interface - bound to the bridge. But you wont be able to connect to the Bridge Interface itself! Services behind are reached through this dedicated VLAN-interface via the CPU-Port (called "bridge1", but this refers to the CPU-Port only - not to the Bridge as dedicated Interface).

Long explanation:

Default settings without any VLAN-Interfaces, the Bridge is CPU-Port and Interface at the same time:

Screenshot 2022-01-02 204430.jpg

Screenshot 2022-01-02 204731.jpg

DHCP will work:

Screenshot 2022-01-02 205738.jpg

Same settings, changing to "tagged only" results in a total connectivity lost:

Screenshot 2022-01-02 204916.jpg

Now, the ingress-setting filters all tagless/untagged traffic, but the Frames get tagless/untagged forwarded to the Bridge-Interface+CPU-Port (as defined in the first picture).

Now we change the VLAN-setting, placing the CPU-Port into tagged state:

Screenshot 2022-01-02 205959.jpg

At this point the connectivity is lost as well!

For my understanding the bridge itself (as Interface AND CPU-Port) can work only untagged.
Why was the connectivity lost? Via the PVID the ingressing frame gets its (internal) tag. Via the VLAN-tab the bridge/CPU-Port is egressed tagged as well... I see no other conclusion, the bridge-interface+CPU-Port works only untagged.

Now, we enable/create a VLAN-Interface, bound to the bridge:

Screenshot 2022-01-02 210612.jpg

And suddenly, in a mysterious way, everything works again:

Screenshot 2022-01-02 210525.jpg

To me, it seems the way you place the bridge/CPU-Port into tagged or untagged state triggers something:

CPU-Port/bridge = untagged -> in this state, the only working settings (in the bridge/VLAN) menu are "admit all" and "admit only untagged...". This refers to the Interface and the CPU-Port.

CPU-Port/bridge = tagged -> in this state, the bridge-interface itself wont work anymore (because the frame to it are tagged). The only working settings are "admit all" and "admit only tagged...". But they refer to the CPU-Port only (as the Bridge-Interface isnt reachable anymore) -> VLAN-Interfaces bound to the bridge.

Screenshot 2022-01-02 211252.jpg

Screenshot 2022-01-02 211332.jpg

And this is very confusing to me and to all I have spoken! I dont understand why MT has created such a "Frankenstein-like" monster as their VLAN-Implentation. I have never seen such a complicated way (and undocumented too) by any other vendor.

Id recommend simply not to deal with the Bridge as dedicated Interface. Simply create VLAN-interfaces, bound them to the bridge and see the "bridge itself" as CPU-Port (under Bridge -> VLAN).

SiB · Mon Jan 03, 2022 3:10 am

AFAIU the CPU-Port is called the same as the bridge. This is very confusing, MT should have named this "CPU-Port" or something.

I think that before v7.20 we will know next generation of "new vlan setup", we should create some versioning for that.
PS. Nice post.

Zacharias · Mon Jan 03, 2022 1:18 pm

Well yes,
If you want to use the Bridge Interface itself and the Bridge CPU port for Management access then you must use untagged Traffic.
If you want to allow only Tagged Traffic to the Bridge Interface then you must create a VLAN Interface and access the CPU Port through that ( and ofcorse the appropriate VLAN configuration is needed ) ...

sindy · Mon Jan 03, 2022 4:00 pm

@Guscht, the "CPU port" is an oversimplification, based on an assumption that CPU is equivalent to the router process and that the bridge process runs somewhere else than on the CPU. If this simplification helps you understand the concept, stick with it, but actually the "port of the virtual switch" and "interface of the virtual router" form up the demarcation line between the bridge process and the router process, which both run at the CPU.

This confusing blending of multiple logical objects into a single one is not an invention of the Mikrotik team - this is how bridge is implemented in Linux kernel and represented in its configuration layer.

What I likely haven't stressed enough in my OP is that the /interface vlan configuration is related to the router part, and the /interface bridge vlan configuration is related to the virtual switch part. So there is nothing surprising on the fact that if a tagless frame carrying an IP packet arrives to an Ethernet port of a virtual switch with pvid=N, it will only reach the router process if either the pvid of the "router-facing port of the virtual switch" is also N, or if an /interface vlan with vlan-id=N is attached to the "bridge-facing port of the router". In the former case, the in-interface as seen by the router will be the "bridge-facing port of the router" itself; in the latter one, it will be that /interface vlan.

What I find annoying is that you cannot set pvid to none to get all VLANs tagged at the respective port, i.e. there must always be some "native vlan" associated to each port (including the "router-facing virtual port of the virtual switch").

Amm0 · Mon Jan 03, 2022 4:53 pm

What I find annoying is that you cannot set pvid to none to get all VLANs tagged at the respective port, i.e. there must always be some "native vlan" associated to each port (including the "router-facing virtual port of the virtual switch").

Yup that's a problem & very cleaver/clean solution. Wish MT did that.

tdw · Mon Jan 03, 2022 6:53 pm

What I find annoying is that you cannot set pvid to none to get all VLANs tagged at the respective port, i.e. there must always be some "native vlan" associated to each port (including the "router-facing virtual port of the virtual switch").

If you set ingress-filtering=yes frame-types=admit-only-vlan-tagged on a port it removes the untagged membership, i.e. the pvid= setting is ignored, making the port tagged-only.

sindy · Mon Jan 03, 2022 7:44 pm

If you set ingress-filtering=yes frame-types=admit-only-vlan-tagged on a port it removes the untagged membership, i.e. the pvid= setting is ignored, making the port tagged-only.

Wow, thank you, it seems I haven't checked the behaviour for a long time... actually, it seems it's even not necessary to activate the ingress-filtering to make the port accept frames tagged with the VID which is set as the pvid of that port, as adding the interface explicitly to the tagged list on /interface bridge vlan row for that VID prevents/supersedes the automatic addition of the port to the untagged list.

[me@myTik] > interface bridge port print detail where interface=ether5
Flags: X - disabled, I - inactive, D - dynamic, H - hw-offload
 0     interface=ether5 bridge=bridge priority=0x80 path-cost=10 internal-path-cost=10 edge=auto point-to-point=auto learn=auto horizon=none hw=no auto-isolate=no restricted-role=no restricted-tcn=no
       pvid=3333 frame-types=admit-all ingress-filtering=no unknown-unicast-flood=yes unknown-multicast-flood=yes broadcast-flood=yes tag-stacking=no bpdu-guard=no trusted=no
       multicast-router=temporary-query fast-leave=no
[me@myTik] > interface bridge vlan print where vlan-ids=3333
Flags: X - disabled, D - dynamic
 #   BRIDGE                                                     VLAN-IDS  CURRENT-TAGGED                                                   CURRENT-UNTAGGED
 0   bridge                                                     3333      bridge
                                                                          ether5

Of course, it does make sense to use ingress-filtering to prevent tagless frames from being accepted on that port (and probably tagged with the VID stated in its pvid).

So it should even be possible to handle the "mysterious" VLAN 1 on the bridge using an /interface vlan, by adding "bridge" (the router-facing port of the virtual switch) to the tagged list on the /interface bridge vlan row with vlan-ids=1.

Zacharias · Mon Jan 03, 2022 9:04 pm

@sindy,
That is documented in the manual.. When frame-type=admit-only-vlan-tagged is used on a port, then the port is not dynamically added as an untagged port for the PVID.

Source:
https://help.mikrotik.com/docs/display/ ... LAN+Table

pcunite · Mon Jan 03, 2022 11:26 pm

May I join this discussion as to why? From the very beginning, and even now, the bridge, bridge port is confusing. It will always be confusing because it is an insufficient abstraction for the people who use it. This is why @sindy can not make it any clearer. No one more capable and patient than him could be hired to do so, and yet, it is as murky as would be dark waters in the south pacific rim from falling volcanic ash.

Abstraction
Abstractions are very important in the software industry. Generally speaking, programmers create them (implemented from specifications created by software architects which maybe the same person). Then technical writers try to explain them. Marketers then try to sell them. If the abstractions are too close to the hardware, another layer of abstraction is created to make it more sensible, easier to reason about. In programming code, these abstractions are another class (object) that manages the inputs and outputs of the lower (closer to hardware) object. There maybe several. There maybe ten before anyone outside the company sees the final layer.

These layers mean something to different groups based on their needs and use cases. Consider the following: an ethernet frame gets assembled from a nic driver on a PC. A switch, reading in the series of electrical or optical impulses stores the bits in a buffer, a software object identifies the object as a frame, another object responsible for modifying frames inserts a VLAN tag, and so on. This abstraction is well below the needs of people who write programs for your computer. This abstraction is unnecessary and a distraction for them. So, another layer they use allows them to read into a memory buffer, and output file or screen data in a loop. They don't need such verbose access to the wire.

How all these physical things get abstracted by programmers is something that may never be exposed to the network admin. In fact, a final abstraction, often termed the API, is what most generally gets exposed to customers and end uers. And that abstraction is what is the most important thing to MikroTik product administrators, forum commenters, explainers, and apologists. You and me. We care about the RouterOS API (syntax and Winbox).

The Missing Abstraction:
While at first I was thinking it was RouterOS's fault, and indeed it could be a missed opportunity, the real issue, the real blame, the real source of confusion is the missing abstraction that we don't have. Point your fingers at what does not yet exist! Therein lies the blame. Do not blame what we have, blame what we lack.

RouterOS, I theorize, is closely tied to Linux. It is a layer upon Linux and this layer is itself tied to the RouterOS syntax and how that relates to Winbox. Did you catch that? That is a line of dependencies. RouterOS, I suspect, is not an abstraction over a multi-vendor routing, switching, VLAN, whatever concept. Instead, it is a layer over Linux. This layer is tied to the way their GUI (Winbox) works which tries to be like RouterOS text syntax, which in turn tries to simplify the underlying Linux commands.

MikroTik could have created a syntax and GUI in isolation. However, they may not have separation of concerns in-house. The code is too intertwined. A point could be made that MikroTik should have started with an API concept, then separately picked a syntax, and then a vendor (Linux), to make the switching concept physically become a reality. But that is unfair. They've made a great product and we love it. As with all things, there is always something to improve. Looking back one can see more clearly. Maybe they should consider a new end user API. Start with the API, and work backwards from there, in fact. That would clear up all this confusion. But that is a business case for them and not for us to decide.

Conclusion:
So, step away from the MikroTik documentation, my own comments, and all the writing about MikroTik's implementation for a moment. What is a switch and a router doing, conceptually speaking, when operating under the VLAN standard? When you have that diagrammed, demonstrated, understood, and explained, then you can show others how RouterOS API chose to implement this.

But here's the deal. You may never be able to explain, however, why RouterOS does it this way. The RouterOS abstraction maybe based on a model that is not reflective of where their customer's operate. It may not be where you and I actually live. What if RouterOS, the one that we know, is actually for programmers and not network admins? You and I fellow forum co-patriots, we are the ones who are assembling networks. RouterOS may have not been for us. It may have been for the programmers that designed it. They understood it. It made sense to them.

We have become the missing abstraction. We make RouterOS work with network concepts. This means the bridge port, lacking MikroTik's explanation, is whatever @sindy says it is.

bpwl · Tue Jan 04, 2022 12:14 am

I hope you add information about creating VLANs by new way... and how live with General vlan id:1 and others as Trunk.
For now I use always this howto: https://mbum.pl/archive/vlan-po-nowemu.pdf (Presentation from Ihor Hreskiv at Mikrotik Beer User Meating at Poland 2019, mbum.pl)
Pages: 34 - 50

I can take picture from that PDF and create a Photo-story here. I hope you can do that way edition of your post - this will be greate have it in English.

Deepl translation: if it helps

Sob · Sat Jan 08, 2022 8:10 pm

This confusing blending of multiple logical objects into a single one is not an invention of the Mikrotik team - this is how bridge is implemented in Linux kernel and represented in its configuration layer.

Maybe the right choice was to not expose the bridge itself as port. I hope that I didn't miss something, but you don't really need it, do you? Instead of using bridge as untagged port for VLAN X, you can add VLAN interface for VLAN X and use that. But now that it's there and people already use it, it would be problematic to get rid of it.

What I don't like much about current UI for bridge VLAN filtering is that it's spread over different places. If I want some port as untagged access port for VLAN X, its PVID is defined on port, but then the rest of VLAN X is defined elsewhere. And I can even add conflicting config, saying that the port is untagged in completely different VLAN Y. I didn't test what it does and if there's perhaps some use for that, but it can be quite confusing.

Or the fact that I can define VLAN membership for ports that are not even part of the bridge, that can be confusing too. It makes sense when there's support for dynamic interface lists. But it doesn't make the simple config with static ports easier. If it wasn't for dynamic interface lists, I'd prefer interface like this:

vlan-config.png

It would automatically list all member ports of bridge, and it would be immediatelly clear what belongs where. And if it would be linked with ports' PVID, so that changes could be done from one place, it would be much easier to understand. And more efficient too, rather than adding ports to VLAN one by one. But I don't know how to include handling of interface lists in this.

Another way how to make it easier could be built-in hints. Similar to how IPSec warns you about weak secret. So if I have VLAN interface for VLAN X on top of bridge, but bridge is not listed as tagged for VLAN X, there could be a warning about that. Or other way around, if bridge is listed as tagged for VLAN X, but there's no inteface for VLAN X, there could be warning too. I'm sure it would help many people.

Amm0 · Sat Jan 08, 2022 11:46 pm

What I don't like much about current UI for bridge VLAN filtering is that it's spread over different places. If I want some port as untagged access port for VLAN X, its PVID is defined on port, but then the rest of VLAN X is defined elsewhere. And I can even add conflicting config, saying that the port is untagged in completely different VLAN Y. I didn't test what it does and if there's perhaps some use for that, but it can be quite confusing.

Yup that's much closer to the UI I'd expect – great mockup, seem Mikrotik-ish.

IMO the best UI for VLAN management is a grid (like Netonix, older UBNT ToughSwitch & NOT like Netgear which is only marginally better than MT's brigde VLAN) – but a "grid" is pretty far from "winbox" style:

Maybe the axises filped and some grid of checkmarks? All I know is the drop-down is horrible way to do this. I generally use the CLI for stuff, but use winbox a fair share too. But I don't even bother with winbox for Bridge VLANs – it's confusing since you need a few windows open if you want confirm the PVID in an interface etc. But the CLI isn't for everyone, and it's VLAN configuration there isn't that much better BUT you can at least see the PVID of the ports you're working with on the same screen...

Another thing that I do think it would help here is if Mikrotik enabled vlan-filtering=yes in the default config, or at least in one of the QuickSet that create a bridge – in nearly all VLAN cases, you'd want to use - but applying later is where the trouble starts... Plus, some default config with vlan-filtering enabled more easily allowed applying the pcunite's "VLAN'ing you network" kinda scenarios be really helpful. I mean QuickSet does have a checkbox for "Enable VPN", so "Enable VLAN Filtering" doesn't seem that far a stretch.

Idea being while Sob's mock-up seem pretty good & reasonable... but getting to where you can use the "Sob VLAN UI" is also not that easy...

Sob · Sun Jan 09, 2022 12:18 am

Problem with grid (which I otherwise like too) is space. It's ok for switch with fixed ports 1-X. But number of ports in RouterOS is theoretically unlimited (you can add e.g. loads of EoIP interfaces). Configurable and possibly long interface names don't help either. It's not that it couldn't be used, but if you end up having to scroll both horizontally and vertically, it's not going to be great experience. And switching axes won't help with this.

It also has the same problem as my idea, what to do with ports added using interface lists? One way would be listing all current ports that bridge already has, and additionally allow to add others, same way as it's currenly done for all tagged and untagged, that could work.

Amm0 · Sun Jan 09, 2022 1:45 am

Problem with grid (which I otherwise like too) is space. It's ok for switch with fixed ports 1-X. But number of ports in RouterOS is theoretically unlimited (you can add e.g. loads of EoIP interfaces).

Oh no, you're idea certainly more realistic, I like it. I posted a grid based on Cunningham's Law. And, even the current UI can run out of vertical space, but yeah dynamic interface & interface lists do make a tricky problem.

But Sob does have a point here: you kinda have to get through enable vlan-filtering, then getting through two-step setup to tag a new VLAN first to even grok the mysteries discussed here. But, some of these mysteries are created by the UI itself...

Perhaps a new "frame-type" on a Bridge>Port like "use as access port"? This would means it doesn't need to be handle by Bridge>VLANs. But if you wanted a "hybrid" port, you use the existing "allow untagged and priority only" options – those would show up in Sob-like UI. A new "frame-type" wouldn't break existing config, and remove clutter in Bridge>VLAN. e.g. the current drop-downs in Bridge>VLANs would have "less stuff" since these new "access port" are explicitly declared on the bridge port itself, nothing is needed Bridge>VLAN tab. The bridges dynamic assignment half covers this today, but you still always see "access ports" when trying to configure hybird/trunk ports.

None of this make the hybrid/"two faced" bridge interface/port easier, but do the think UI makes the whole topic even more difficult to explain.

Guscht · Wed Feb 16, 2022 12:27 am

@Guscht, the "CPU port" is an oversimplification, based on an assumption that CPU is equivalent to the router process and that the bridge process runs somewhere else than on the CPU. If this simplification helps you understand the concept, stick with it, but actually the "port of the virtual switch" and "interface of the virtual router" form up the demarcation line between the bridge process and the router process, which both run at the CPU.

Hi sindy, late answer... Of course, both things run on the CPU. I borrowed the wording "CPU-Port" from the Switch-Menu, because this is the exact behaviour what the "virtual switch port facing the virtual router interface" does. It will become only a bit more simpler if you can think "it will go to the CPU where the other processes run".

One BIG probelm is, that MT allows you so many invalid configurations. Where is documented, that the Bridge-[itself]-Interface works only with untagged frames? If this is somewhere written (I never found it), why is it not in big, red letters? Its a very(!!) important thing and will result in a lot frustration if you are not a "switching philosopher" with passion

I read issues related to this every week on MT forums, groups.

Why do they not implement a warning/dialogue box if anyone tries to do that? I work with a lot other network-vendors and they all warn you about such things. MT says: FCK you, no help, our devices are cheap - you have to trial-and-error and learn it the hard way...

This toxic mix of poorly written documentations, poorly GUI-design and the way they allow invalid configs, makes it so hard. To be honest, no one of my colleagues is able to configure a ROS device in regards of VLAN. Not in the real world, not in a production enviroment.

And we speak only about the (simple) BRIDGE. MT has this incredible complexity in regards of their SWITCH-CHIPS. Like: this CRS allow this with this menu, this CRS allows this but with a totally different GUI because it contains another switch-chip, this works only from ROSvX.XX. Here we implement a GUI without functions. Here you need to create BRIDGE and add the ports for the SWITCH to function... And they let you mix the settings from the SWITCH and BRIDGE menu and dont tell you what takes precedence.

tdw · Wed Feb 16, 2022 6:22 pm

Where is documented, that the Bridge-[itself]-Interface works only with untagged frames? If this is somewhere written (I never found it), why is it not in big, red letters?

It isn't because it does not. Just as with any physical interface the other CPU processes are expecting untagged IP packets, for tagged traffic you need an /interface vlan to remove the VLAN tag in the 'parent interface to CPU process' direction and add it in the other.

Take a simple example - a single physical ethernet port, ether5, providing the 192.168.1.0/24 subnet untagged plus 192.168.2.0/24 subnet tagged with VLAN ID 2:
/interface vlan
add interface=ether5 name=vlan2-ether5 vlan-id=2
/ip address
add address=192.168.1.1/24 interface=ether5
add address=192.168.2.1/24 interface=vlan2-ether5

If at some point you may wish have more than one port providing access the equivalent bridge with a single port as a member is:
/interface bridge
add name=mybridge pvid=1 vlan-filtering=yes
/interface bridge port
add bridge=mybridge ingress-filtering=yes interface=ether5 pvid=1
/interface bridge vlan
add bridge=mybridge untagged=mybridge,ether5 pvid=1
add bridge=mybridge tagged=mybridge,ether5 vlan-ids=2
/interface vlan
add interface=mybridge name=vlan2-mybridge vlan-id=2
/ip address
add address=192.168.1.1/24 interface=mybridge
add address=192.168.2.1/24 interface=vlan2-mybridge

The parent, subinterface and port members are highlighted by colour; default / dynamically created items are in italics and can be omitted.

Yes, the documentation is not concise, and it would be really helpful if the UI showed warnings for any /interface bridge vlan entries where the tagged= and untagged= lists do not have matching /interface bridge port entries.

Zacharias · Wed Feb 16, 2022 6:39 pm

and it would be really helpful if the UI showed warnings

That would be helpful for any configuration ...

mkx · Thu Feb 17, 2022 10:20 am

Where is documented, that the Bridge-[itself]-Interface works only with untagged frames?
It isn't because it does not. Just as with any physical interface the other CPU processes are expecting untagged IP packets,...

Actually it's not L2 ports (physical ports, bridge port) that would "hate" tagged frames. Rather it's L3 interfaces (IP stack) that doesn't handle VLAN headers.

Note the difference between port and interface ... ROS distinguishes between the two as well.
The mental twist being that e.g. ether1 can be either port (member of bridge, either tagged, untagged or hybrid) or interface (carrying IP address or being anchor for VLAN interface) and one has to be careful to note which it is.
A basic error is to use same entity in both roles at the same time (e.g. making ether1 both member of bridge and attaching IP address directly to it). ROS doesn't flag it as error and things kind of work, but not 100%.

PackElend · Sun Dec 04, 2022 9:44 pm

could you explain it like this as well?

any interface logical or physical has to have an IP to allow >=L3 services on it.
As the bridge interface ( “new” way of handling multiple VLANs ) must not have an IP, so you don't use it anywhere, except handling L2 things for devices/ports connected to it

anav · Sun Dec 04, 2022 10:04 pm

So PackElend how do you distinguish the common use of bridge where there are no vlans and ports are attached to it and the IP address is assigned to the bridge.
Is it not an interface in this scenario?

anav · Sun Dec 04, 2022 10:06 pm

Yes, the documentation is not concise, and it would be really helpful if the UI showed warnings for any /interface bridge vlan entries where the tagged= and untagged= lists do not have matching /interface bridge port entries.

Hence, I always recommend fully documenting the untagged ports on /interface bridge vlans so as to enable clear cross-checking with /interface bridge ports.

sindy · Sun Dec 04, 2022 10:12 pm

any interface logical or physical has to have an IP to allow >=L3 services on it.
As the bridge interface ( “new” way of handling multiple VLANs ) must not have an IP, so you don't use it anywhere, except handling L2 things for devices/ports connected to it

Sorry, I did not understand what you are asking.

In any case, "new" handling of multiple VLANs is just an add-on to the basic concept of the bridge, it doesn't change it. Second, did you mean "a physical/virtual interface that has been made a member port of the bridge must not have an IP"? Because that's the correct description of the requirement.

PackElend · Sun Dec 04, 2022 10:47 pm

sorry not all got pasted

when do you use the bridge interface at all?
Only for “new” way of handling multiple VLANs or in any other configuration as well?
I guess only first and the reason could be explained by:
any interface virtual or physical has to have an IP to allow >=L3 services on it.
As the bridge interface ( “new” way of handling multiple VLANs ) must not have an IP, so you don't use it anywhere, except handling L2 things for devices/ports connected to it

sindy · Sun Dec 04, 2022 11:23 pm

You use a bridge interface whenever you want to connect multiple devices to the same IP subnet. Whether you use VLANs or not is a separate thing. You can use a dedicated bridge for each (V)LAN, you can use multiple bridges with multiple VLANs on each, or a single bridge for all your VLANs - it's up to your actual needs. But the bridge still forwards frames between its ports up to their MAC addresses only, and if the Mikrotik device on which this bridge exists wants to talk IP to the external devices connected to the bridge, you have to attach an IP address to the appropriate interface of the router - to the bridge-facing interface of the router directly or to the /interface vlan attached to it, depending on the rest of the configuration.

So again in different words - the interface of the router that is "connected" to the matching port of the virtual switch must have an IP address if you want that the router had access to devices in the same (V)LAN which is configured as an access one on that port of the virtual switch. If vlan-filtering is off, what came in tagged stays tagged on egress and what came in tagless stays tagged on egress; if vlan-filtering is on, you can tag frames on ingress and untag them on ingress. But that has nothing to do with attaching or not attaching IP addresses to interfaces.

Mon Dec 05, 2022 12:28 am

topic´s name is beautiful

PackElend · Mon Dec 05, 2022 8:36 am

.... the bridge still forwards frames between its ports up to their MAC addresses only, and if the Mikrotik device on which this bridge exists wants to talk IP to the external devices connected to the bridge, you have to attach an IP address to the appropriate interface of the router...

...the interface of the router that is "connected" to the matching port of the virtual switch must have an IP address if you want that the router had access to devices in the same (V)LAN ....

thanks for the detailed answer

So Bridge does L2, being a mature L2-Switch, that is clear to me. If you active use IP-Firewall, it includes some L3 things.
but if you use (multiple) VLAN(s) in the same Bridge, the VLAN Interfaces are the door to L3?

but bridge-facing interface is the Bridge CPU port, if you don't work with VLANs, so you put an IP on etc. on "bridge-... ", so it become the door to L3?

 > interface/print
 Flags: D - DYNAMIC; R - RUNNING; S - SLAVE
 Columns: NAME, TYPE, ACTUAL-MTU, L2MTU, MAX-L2MTU, MAC-ADDRESS
 #     NAME                           TYPE    ACTUAL-MTU  L2MTU  MAX-L2MTU  MAC-ADDRESS      
 0  R  combo1                         ether         1500   1580      10222  08:....
39  R  bridge-...                   bridge        1500   1580             08:55:31:31:24:88
....

mkx · Mon Dec 05, 2022 3:03 pm

Conceptually: physical port (e.g. ether1) is a port. When you add L3 configuration (e.g. IP address) to it, it becomes interface. If you want to work with tagged frames, coming in and leaving out of, you have to create appropriate VLAN ports, anchored to physical port. Adding IP addresses to those VLAN ports makes them VLAN interfaces (VLAN ports can be used as bridge ports when creating per-VLAN bridge in a pre-6.42 fashion).

Likewise: bridge (named e.g. bridge1) comes with CPU-facing port, named bridge1. If you add IP address to it, it becomes interface named bridge1 (and IP stack works with this interface, not with bridge member ports. I.e. in-interface is then bridge1 or out-interface is bridge1 ... not some member port). So the same as with individual physical ports, if you want to work with VLANs, you have to create some VLAN ports and anchor them to port bridge1.
When doing VLANs with bridge, it's necessary to configure the virtual switch ... so you configure VLAN membership (and PVID) for all member ports, including CPU-facing port named bridge1.
So as you can see, port bridge1 is treated the same as other explicitly configured bridge ports (ether ports, SFP ports, wifi ports) except for implicit creation. Naming around ROS is slightly inconsistent (most ports are found under /interface ... ethernet or wireless or ...), but never the less they are ports prior to receiving L3 configuration.

sindy · Mon Dec 05, 2022 4:30 pm

but if you use (multiple) VLAN(s) in the same Bridge, the VLAN Interfaces are the door to L3?

but bridge-facing interface is the Bridge CPU port, if you don't work with VLANs, so you put an IP on etc. on "bridge-... ", so it become the door to L3?

The items under /interface vlan are "featured pipes" whose one end ("tagged") is attached to a carrier (underlying) interface/port, and the other end ("tagless") behaves like an interface/port itself.

So when you attach an IP address to the tagless end, it becomes an IP interface.

When an IP stack sends a packet via an L2-capable interface, that packet gets encapsulated into a tagless ethernet frame (leaving wireless aside to simplify things). If the interface is the tagless end of the /interface vlan pipe, the frame gets an 802.1Q VLAN header as it passes through the pipe, so at the tagged end of the pipe, it is now a VLAN frame.

In the opposite direction, the pipes are "picky" - they only forward VLAN frames whose VID matches the one the pipe is configured to use, and untag them as they deliver them to their tagless end. They ignore frames with other VIDs.

You can attach the /interface vlan to an L2-capable interface directly, and you can also attach an IP address to it, but only if that L2-capable interface is not a member port of a bridge or a member link of a bond (exceptions exist but making use of them has side effects and causes incompatibility with less punky devices than Mikrotik is). At this step, we still think about the interface to which the IP address and/or /interface vlan pipes are attached as about the switch-facing interface of the router.

The next step is to see what happens to the frame as it enters the bridge via the router-facing port of the bridge. And here the difference between vlan-filtering=no and vlan-fltering=yes comes into play. With no, the bridge behaves like a "non-managed" (dumb) switch - it only cares about MAC addresses and nothing else. So if a frame came in tagless through one port, it will stay tagless on the bridge and as it egresses via another port(s). With yes, the bridge behaves like a "managed switch", so each of its ports can be an "access", "trunk", or "hybrid" one, depending on the settings. An access port only accepts tagless frames on ingress, tags them with the configured VID, and ignores tagged ones; a trunk port only accepts tagged frames (and may only accept those that bear the permitted VIDs), and a hybrid port is a combination of both behaviours. "Inside" the bridge, all frames are tagged, but if a tagless frame comes in through to a port with a certain pvid and egresses via another port with the same pvid, it will be tagless also at egress, as it gets tagged on ingress, passes through the bridge tagged, and then gets untagged on egress.

The router-facing port of the bridge behaves exactly the same like any other port of that bridge. So if you attach an IP address "to the bridge itself" (in fact, to the bridge-facing interface of the router), it will end up being reachable via the VLAN which is configured as pvid "on the bridge itself" (in fact, the router-facing port of the bridge). If the "bridge" port is in pure trunk mode, such an address will not be reachable at all. If you attach an IP address to an /interface vlan that is attached to the bridge-facing interface of the router, that address will be reachable via the corresponding VLAN if that VLAN is permitted also on the "router-facing port of the bridge" (which means that the router-facing port of the bridge is listed in the tagged list for that VLAN under /interface bridge vlan).

PackElend · Mon Dec 05, 2022 4:38 pm

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

PackElend · Mon Dec 05, 2022 4:44 pm

By the way
What means

If the "bridge" port is in pure trunk mode,

sindy · Mon Dec 05, 2022 4:55 pm

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.

SiB · Tue Dec 06, 2022 4:28 am

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

mkx · Tue Dec 06, 2022 10:05 am

But, when we have hardware with "separate chip" we need connect them via external short patchcord to get full hardware speed.

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.

Tue Dec 06, 2022 11:54 am

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

Pun intended ?

mkx · Tue Dec 06, 2022 2:30 pm

I guess MT still wants us to forget about switch menus and switch to using bridge menus exclusively ...
Pun intended ?

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 ...

janFfm · Wed Dec 07, 2022 11:39 pm

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.

Amm0 · Thu Dec 08, 2022 12:42 am

I must say i agree 100% with SiB and many others. The Mikrotik documentation is, well, plain aweful.
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".

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 ... -on-bridge# (see also intro: https://developers.redhat.com/articles/ ... _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.

SiB · Thu Dec 08, 2022 4:09 pm

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

Amm0 · Sat Feb 11, 2023 6:01 pm

Mikrotik posted in another thread, viewtopic.php?p=980168#p980440, 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.

DarkNate · Sat Feb 11, 2023 9:33 pm

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

https://help.mikrotik.com/docs/display/ ... +switching

PackElend · Sat May 27, 2023 6:52 pm

If the CPU-Port is set untagged, this is the only way to communicate with the Bridge Interface (itself) and services "behind", like DHCP, NTP... In this state "bridge1" is CPU-Port and Interface.

If the CPU-Port is set tagged, you will need a dedicated VLAN-Interface - bound to the bridge. But you wont be able to connect to the Bridge Interface itself! Services behind are reached through this dedicated VLAN-interface via the CPU-Port (called "bridge1", but this refers to the CPU-Port only - not to the Bridge as dedicated Interface).

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

tdw · Sat May 27, 2023 7:24 pm

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

PackElend · Sun May 28, 2023 9:00 pm

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

thx

Kentzo · Thu Jun 01, 2023 8:36 pm

In the bridge filter, the relationship of the frame to the router-facing port of the switch determines the chain to be used: input handles frames that egress from the virtual switch through that port, output handles frames that ingress to the virtual switch through that port, and forward handles frames that bypass that port.

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?

sindy · Thu Jun 01, 2023 9:40 pm

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.

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.

Does it also imply no (un)tagging, i.e. packet is sent without its VLAN-priority (and thus ingress priority) implicitly stripped?

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.

Kentzo · Fri Jun 02, 2023 1:04 am

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?

sindy · Fri Jun 02, 2023 8:02 pm

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.

Kentzo · Fri Jun 02, 2023 8:37 pm

No.

No as in "won't work in principle" or as in "will work, but with many caveats"?

sindy · Fri Jun 02, 2023 8:50 pm

No as in "enabling use-ip-firewall in bridge settings will not change the fact that you cannot match on ports, IP protocol etc. in bridge filter if the ethernet protocol field (mac-protocol) is different from IPv4 or IPv6":

[me@myTik] > system/resource/print
                   uptime: 1w4d21h5m46s
                  version: 7.9 (stable)
                         ...
        architecture-name: x86_64
               board-name: CHR
                 platform: MikroTik
[me@myTik] > interface/bridge/filter/add chain=forward mac-protocol=vlan vlan-encap=ip src-address=10.0.0.3/24 action=log
failure: ip matchers are valid only when mac-protocol is set to ip

tdw · Fri Jun 02, 2023 10:01 pm

You can match IP traffic with mac-protocol=ip on a VLAN-aware bridge but you can't select a specific VLAN as well. When VLAN-aware bridges were introduced Mikrotik should have separated the filter functionality so you can apply both a VLAN and another filter, rather than the limited either/or situation that exists.

Certainly on 6.48.7 the following works as expected:
/interface bridge
add admin-mac=D6:CA:6D:xx:xx:xx auto-mac=no ingress-filtering=yes name=bridge priority=0x4000 vlan-filtering=yes
...
/interface bridge filter
add action=log chain=forward mac-protocol=ip src-address=192.168.44.0/24

sindy · Fri Jun 02, 2023 11:41 pm

I'm not sure I've understood you well - I've tested on 7.9 and the rule only counts if I remove the mac-protocol=ip src-address=192.168.229.1/32 conditions:

[me@myTik] > interface/bridge/filter/print
Flags: X - disabled, I - invalid, D - dynamic
 0   chain=output action=log out-interface=vxlan1 mac-protocol=ip src-address=192.168.229.1/32
[me@myTik] > tool/sniffer/quick interface=vxlan1
Columns: INTERFACE, TIME, NUM, DIR, SRC-MAC, DST-MAC, VLAN, SRC-ADDRESS, DST-ADDRESS, PROTOCOL, SIZE, CPU
INTERFACE  TIME   NUM  DIR  SRC-MAC            DST-MAC            VLAN  SRC-ADDRESS    DST-ADDRESS    PROTOCOL  SIZE  CPU
vxlan1     0.018    1  ->   76:B0:78:7B:D9:E8  8A:E1:E7:99:D4:E8  2222  192.168.229.2  192.168.229.1  ip:icmp     74    0
vxlan1     0.019    2  <-   8A:E1:E7:99:D4:E8  76:B0:78:7B:D9:E8  2222  192.168.229.1  192.168.229.2  ip:icmp     74    0
vxlan1     1.02     3  ->   76:B0:78:7B:D9:E8  8A:E1:E7:99:D4:E8  2222  192.168.229.2  192.168.229.1  ip:icmp     74    0
vxlan1     1.021    4  <-   8A:E1:E7:99:D4:E8  76:B0:78:7B:D9:E8  2222  192.168.229.1  192.168.229.2  ip:icmp     74    0

PackElend · Sun Jun 04, 2023 2:12 pm

In the bridge filter, the relationship of the frame to the router-facing port of the switch determines the chain to be used: input handles frames that egress from the virtual switch through that port, output handles frames that ingress to the virtual switch through that port, and forward handles frames that bypass that port.
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?

everyone has his own preferred wording, which makes it sometimes challenging to grasp the entire concept being explained.
For that purpose I started making some drawings, they may help here as well (may watch Understanding Packet Flow in RouterOS v6 - YouTube first)

all flow options
hardware switching, dedicated switch chip, hardware offloaded switch (Flow of Hardware Offloaded Packet
From one port to another port, according to
Code: Select all
```
/interface/bridge/vlan
```
still only on L2 but target (or source) port is connected to CPU not switch chip, so VLAN has to be allowed to flow through Bridge CPU Port, frames "bypass" the router (only if you set IP Firewall etc. to yes).
frames leave Bridge, in this case for inter-VLAN routing. To do so it has to leave the bridge through "Bridge Input", via the Bridge CPU Port (so VLAN has to be allowed on it again).
Bridge input is a process that takes place when a packet is destined for the bridge interface. Most commonly this happens when you need to reach some services that are running on the bridge interface (e.g. a DHCP server) or you need to route traffic to other networks
from Packet Flow in RouterOS - RouterOS - MikroTik Documentation

I hope that all that is said and shown in the image is correct, conformation/feedback is welcome.
I'm still searching for a better option than only using plain images to visualise it.

The full story is here: Packet flow from VLAN Host to www how often routing decision is made - Administrator

Amm0 · Sun Jun 04, 2023 3:42 pm

You can match IP traffic with mac-protocol=ip on a VLAN-aware bridge but you can't select a specific VLAN as well. When VLAN-aware bridges were introduced Mikrotik should have separated the filter functionality so you can apply both a VLAN and another filter, rather than the limited either/or situation that exists.

Well, as @sindy describes, the bridge interface is a "two faced". And the packet flow diagrams show a decapsulation step, so from the vlan-enabled=yes bridge's POV, VLAN tagged traffic is in an input or output and can be matched by vlan-id=XX and mac-protocol=vlan (e.g. NOT =ip). Once traffic is forward it is necessarily untagged at that point for the router-side since it only deal with Layer3, so has to be matched with mac-protocol=ip in the bridge filter. And if "use IP firewall" is enabled, than these packets go directly to regular IPv4/IPv6 firewall, which understandably has no idea about vlan-id/port from the bridge as the traffic is fro the vlan interface as that point.

Agreed confusing, but still logical...since you do want some separation between Layer2 and Layer3 things. And RouterOS is somewhat constrained how Linux kernel & hw drivers handle these things – e.g. Linux is similarly confusing when it comes to a software bridge.

sindy · Sun Jun 04, 2023 4:35 pm

Once traffic is forward it is necessarily untagged at that point for the router-side since it only deal with Layer3, so has to be matched with mac-protocol=ip in the bridge filter.

I have to disagree here. input, output, and forward in the context of the bridge filter are all L2 operations, so even during forward (between any two ports of the virtual switch other than the router-facing one), the VLAN tags remain in place.

And if "use IP firewall" is enabled, than these packets go directly to regular IPv4/IPv6 firewall, which understandably has no idea about vlan-id/port from the bridge as the traffic is fro the vlan interface as that point.

Yes, this is indeed where things stop being logical, because use-ip-firewall=yes forces even L2-forwarded frames through layers of the packet processing stack that normally only handle the L3 packets. The whole purpose is to allow QoS handling of L2-forwarded frames using queues. And the list of the associated side effects is quite big - most notably, NAT behaves strangely.

Amm0 · Sun Jun 04, 2023 5:41 pm

@sindy, I could have said that better...your right L2 forward also goes through filter. I was more trying to make the point that things are easier if you do Layer2 filtering in bridge & do IP/Layer3 filtering in /ip[v6]/firewall. Once you want to violate the L2/L3 separation in bridge filter, your stuck reading the packet flow diagrams and hardware switch specs (and re-reading this post a few times

)

DarkNate · Mon Jun 05, 2023 9:01 am

Although I understand how to configure bridges correctly to ensure:
1. Zero performance problems
2. FastPath/FastForward
3. Hardware offloading
4. CPU usage close to 0% for inter-VLAN switching/routing

Can someone explain why MikroTik is the ONLY networking vendor that requires a bridge to accomplish the above? I've never seen this on Juniper, Arista, Huawei, or even Cumulus Linux (though yes, you can use a bridge or something called an IRB on those vendors).

mkx · Mon Jun 05, 2023 11:31 am

I guess that MT tried to hide switch chip peculiarities and unify configuration interface across the hardware portfolio. And my opinion is that this is a really good move.

Whether the UI for configuring bridge is pleasant, self-descritptive, intuitive ... it's debatable and largely subjective, so let's not go there.

DarkNate · Mon Jun 05, 2023 12:31 pm

I guess that MT tried to hide switch chip peculiarities and unify configuration interface across the hardware portfolio. And my opinion is that this is a really good move.

Whether the UI for configuring bridge is pleasant, self-descritptive, intuitive ... it's debatable and largely subjective, so let's not go there.

I mean, all network vendors use different chips with different peculiarities. But NOBODY requires this weird bridge thing. Which itself is not unified across hardware.

It's easy for me, sure. But thousands of MikroTik customers still configure in Cisco style and then assumes MikroTik is underperforming because no HW/Off. Or FastX features without bridge.

9/10 I've never seen people correctly configuring the bridge. Even those with MikroTik certifications.

mkx · Mon Jun 05, 2023 12:53 pm

I'm pretty sure I'd have helluva hard time configuring anything from cisco. So why does everybody assume that a monkey could configure MT while for Cisco a CCNA grade is needed?

Let's accept the reality (which is that in MT we've got the bridge thingy) and move on ...

mkx · Mon Jun 05, 2023 12:55 pm

But NOBODY requires this weird bridge thing. Which itself is not unified across hardware.

Which ROS-driven hardware doesn't support bridge thing? And if you're about to bring up HW offload: which recent HW, where switching/bridging performance actually matters, doesn't have HW offload available?

DarkNate · Mon Jun 05, 2023 2:43 pm

Which ROS-driven hardware doesn't support bridge thing? And if you're about to bring up HW offload: which recent HW, where switching/bridging performance actually matters, doesn't have HW offload available?

Not sure what universe you live in, but bridge config is NOT unified across hardware models on Tik. Different models require different config, need proof? Read this:
https://help.mikrotik.com/docs/display/ ... +switching

Don't know about "CCNA" requirement. I never got certs, no problem working with multi-vendors including MikroTik, but MikroTik's configuration philosophy is just broken, at least it could've been something like Juniper or FRR.

To be clear, I loathe Cisco configuration as well. Trashy shit.

mkx · Mon Jun 05, 2023 2:56 pm

Well, I asked about "recent HW". Mikrotik introduced VLAN to bridge in 6.42 ... when was it released? Somewhere around 2019? Dunno. Since then, new devices got HW offload and some old ones as well. The very old ones did not and I guess they never will, even though MT didn'tnEOL them it's obvious MT is working on replacing them with newer hardware.

And, besides, as I wrote: if you put HW offload aside, all devices capable of running RIS 6.42 or later will have unified bridge. And that's my point.

We can discuss the bridge concept back and forth (which is done in this very thread), you may loathe it ... but when one wraps their head around it, it's logical. And as I wrote: I don't see it gone away anytime soon.

tdw · Mon Jun 05, 2023 3:33 pm

I'm not sure I've understood you well - I've tested on 7.9 and the rule only counts if I remove the mac-protocol=ip src-address=192.168.229.1/32 conditions:

Initially I thought it might be something which got broken going from v6 to v7, but I've tried 7.9.2 on a SMIPS device (not recommend, it's sloooow).

So:
/interface bridge
add admin-mac=CC:2D:E0:xx:xx:xx auto-mac=no name=bridge vlan-filtering=yes
/interface bridge filter
add action=log chain=input ip-protocol=icmp mac-protocol=ip
/interface bridge port
add bridge=bridge interface=ether2
add bridge=bridge interface=ether3
add bridge=bridge interface=ether4
add bridge=bridge interface=pwr-line1
add bridge=bridge interface=wlan1
/ip dhcp-client
add interface=bridge
Then pinging the assigned IP does cause the filter rule count to increment. Maybe architecture related?

atomicduck · Wed Aug 09, 2023 10:33 pm

I hope you add information about creating VLANs by new way... and how live with General vlan id:1 and others as Trunk.
For now I use always this howto: https://mbum.pl/archive/vlan-po-nowemu.pdf (Presentation from Ihor Hreskiv at Mikrotik Beer User Meating at Poland 2019, mbum.pl)
Pages: 34 - 50

I can take picture from that PDF and create a Photo-story here. I hope you can do that way edition of your post - this will be greate have it in English.

I translated the file online, can you put it somewhere permanent?

https://we.tl/t-mwYP7pQNZc

I tried uploading, but it didn't work. I get exclamation sign.

bpwl · Thu Aug 10, 2023 10:40 pm

Translated PDF document is OK! Can be downloaded via that WeTransfer link (for a few days), but uploading such a 4MB PDF file as attachment seems not possible.

atomicduck · Fri Aug 11, 2023 1:59 pm

Would it work that I make images out from it, and post it one by one on the forum? This is rather usable presentation. Would do it.

anav · Fri Aug 11, 2023 5:09 pm

That is probably a good idea, take images, to jpegs which will reduce the doc in size and then maybe try to pdf it. ( open word doc and insert images )???

emunt6 · Sat Aug 12, 2023 1:41 am

Although I understand how to configure bridges correctly to ensure:
1. Zero performance problems
2. FastPath/FastForward
3. Hardware offloading
4. CPU usage close to 0% for inter-VLAN switching/routing

Can someone explain why MikroTik is the ONLY networking vendor that requires a bridge to accomplish the above? I've never seen this on Juniper, Arista, Huawei, or even Cumulus Linux (though yes, you can use a bridge or something called an IRB on those vendors).

The only reason:
MT has using cheap consumer chips which has "slow shared bus" to the physical ports ( eth1, eth2, eth3, ... ) and all the processing is done by the limited CPU. Other "large" vendors, they using ASIC chips for packet processing.

The difference in short:
"You trying to play a 3D game without a Graphics-card"
vs.
"You playing a game with a Graphics-card"

atomicduck · Mon Aug 14, 2023 12:22 am

The only reason:
MT has using cheap consumer chips which has "slow shared bus" to the physical ports ( eth1, eth2, eth3, ... ) and all the processing is done by the limited CPU. Other "large" vendors, they using ASIC chips for packet processing.

The difference in short:
"You trying to play a 3D game without a Graphics-card"
vs.
"You playing a game with a Graphics-card"

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.

mkx · Mon Aug 14, 2023 11:02 am

The only reason:
MT has using cheap consumer chips which has "slow shared bus" to the physical ports ( eth1, eth2, eth3, ... ) and all the processing is done by the limited CPU. Other "large" vendors, they using ASIC chips for packet processing.
I would second this.

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 ...

atomicduck · Mon Aug 14, 2023 11:20 am

I would second this.
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.)

mkx · Mon Aug 14, 2023 11:57 am

If it is purely UI decision, then why there are three different ways to set VLANs depending on underlying hardware?

If we're thinking of same 3 ways, then:

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.

atomicduck · Mon Aug 14, 2023 12:06 pm

If it is purely UI decision, then why there are three different ways to set VLANs depending on underlying hardware?

If we're thinking of same 3 ways, then:

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.

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/ ... +switching I can see three distinct methods:

1. CRS3xx, CRS5xx series switches, CCR2116, CCR2216 and RTL8367, 88E6393X, 88E6191X, 88E6190, MT7621 and MT7531 switch chips
2. CRS1xx/CRS2xx series switches
3. Other devices with a built-in switch chip

mkx · Mon Aug 14, 2023 12:32 pm

I can see three distinct methods:

1. CRS3xx, CRS5xx series switches, CCR2116, CCR2216 and RTL8367, 88E6393X, 88E6191X, 88E6190, MT7621 and MT7531 switch chips
2. CRS1xx/CRS2xx series switches
3. Other devices with a built-in switch chip

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).

atomicduck · Mon Aug 21, 2023 1:29 pm

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.

Who is online