VLAN tutorial - Understanding menu "/interface bridge vlan"

moveik · Sat Feb 25, 2023 9:00 pm

There is the thread "Using RouterOS to VLAN your network":
viewtopic.php?f=13&t=143620

In that there, there is the post of "Router-Switch-AP (all in one)":
viewtopic.php?f=13&t=143620#p706998

The post has a file attached, "RouterSwitchAP.rsc".
That file has the following code snippet:

# egress behavior, handled automatically

# L3 switching so Bridge must be a tagged member
/interface bridge vlan
set bridge=BR1 tagged=BR1 [find vlan-ids=10]
set bridge=BR1 tagged=BR1 [find vlan-ids=20]
set bridge=BR1 tagged=BR1 [find vlan-ids=99]

I have these questions about it:

1. This is the first (and only) time that the menu "/interface bridge vlan" appears in the file.
Also, in default config - that menu doesn't have any entries (at least in my case).
So, how is it possible that the subcommand "[find ...]" actually finds something?

2. Having the bridge "BR1" as the value to "tagged" means that all packets which leave the bridge "BR1" will have their corresponding VLAN added, as indicated here:
https://help.mikrotik.com/docs/display/ ... eVLANtable
Why do we need to have this applied to the bridge "BR1"?
(I fail to understand the role of the bridge in the field of VLANs...)

mkx · Sat Feb 25, 2023 11:49 pm

1. You are right, probably the code snippet, when applied to default config, does nothing and thus result isn't as intended. On empty config, comnand "add" with similar properties has to be used.

2. Bridge in ROS has two (or more, depends how thoroughly one divides them) personalitues: the switch-like entity which (on L2) connects member ports, and port/interface via which ROS (L3 part of it) communicates with other bridge ports. The config example shown in post is about the later. More about different bridge personalities in this thread.

moveik · Tue Feb 28, 2023 12:23 am

1. You are right, probably the code snippet, when applied to default config, does nothing and thus result isn't as intended. On empty config, comnand "add" with similar properties has to be used.

2. Bridge in ROS has two (or more, depends how thoroughly one divides them) personalitues: the switch-like entity which (on L2) connects member ports, and port/interface via which ROS (L3 part of it) communicates with other bridge ports. The config example shown in post is about the later. More about different bridge personalities in this thread.

Thanks! Your reply was very helpful.

1. I understand, then these are the equivalent commands for empty config:

# egress behavior, handled automatically

# L3 switching so Bridge must be a tagged member
/interface bridge vlan
add bridge=BR1 tagged=BR1 vlan-ids=10
add bridge=BR1 tagged=BR1 vlan-ids=20
add bridge=BR1 tagged=BR1 vlan-ids=99

2. Great tutorial.

I think I understand:

If I execute the following command:

/interface bridge vlan
add bridge=BR1 tagged=BR1 vlan-ids=10

It means that for every packet that leaves through the virtual VLAN interface#10 (and through the "switch-facing interface of the router" towards the "switch"), then the packet will be tagged with a VLAN#10 tag.
The switch would obviously know to which physical port it should send it out, because of the "pvid" attribute that each port of the switch was assigned with.

Is it true?
If that is true, then:

Why do I need a separate commands for each VLAN number?
Why not grouping it all in a single command, like so:

/interface bridge vlan
add bridge=BR1 tagged=BR1 vlan-ids=10,20,99

?

anav · Tue Feb 28, 2023 12:44 am

You dont if there is no difference in the paths of all the tagged vlans..... so yes on one line

mkx · Tue Feb 28, 2023 8:45 am

As @anav noted, it is perfectly fine to group lines per VLAN. There's a gotcha: some VLAN ID can only be referred to in single line. So this construct is not possible:

/interface bridge vlan
add bridge=BR1 tagged=BR1 vlans=10,20,30
add bridge=BR1 tagged=BR1,ether1 vlans=10

this one is fine though:

/interface bridge vlan
add bridge=BR1 tagged=BR1 vlans=20,30
add bridge=BR1 tagged=BR1,ether1 vlans=10

Having VLANs grouped initially brings another drawback. This construct doesn't work:

/interface bridge vlan
add bridge=BR1 tagged=BR1 vlans=10,20,30
# after a few moths one perhaps wants to execute the following line
set [ find where vlans=10 ] tagged=BR1,ether1

moveik · Tue Feb 28, 2023 7:58 pm

You dont if there is no difference in the paths of all the tagged vlans..... so yes on one line

As @anav noted, it is perfectly fine to group lines per VLAN. There's a gotcha: some VLAN ID can only be referred to in single line. So this construct is not possible:
Code: Select all
/interface bridge vlan
add bridge=BR1 tagged=BR1 vlans=10,20,30
add bridge=BR1 tagged=BR1,ether1 vlans=10
this one is fine though:
Code: Select all
/interface bridge vlan
add bridge=BR1 tagged=BR1 vlans=20,30
add bridge=BR1 tagged=BR1,ether1 vlans=10
Having VLANs grouped initially brings another drawback. This construct doesn't work:
Code: Select all
/interface bridge vlan
add bridge=BR1 tagged=BR1 vlans=10,20,30
# after a few moths one perhaps wants to execute the following line
set [ find where vlans=10 ] tagged=BR1,ether1

I understand.
So it is mainly a programming convenience.

For the scenario of "Router-Switch-AP (all in one)" (as written in this comment):

Why would we need to have these "/interface bridge vlan" commands:

# egress behavior, handled automatically

# L3 switching so Bridge must be a tagged member
/interface bridge vlan
add bridge=BR1 tagged=BR1 vlan-ids=10
add bridge=BR1 tagged=BR1 vlan-ids=20
add bridge=BR1 tagged=BR1 vlan-ids=99

?
As I noted earlier, these commands add tagging of the VLAN id to the packets which leave the bridge.

Specifically for the scenario of "Router-Switch-AP (all in one)", we don't need the packets which leave our device to have VLAN tagging.
Their VLAN tagging is redundant, because only the clients will read it (and do nothing with it).

mkx · Tue Feb 28, 2023 10:17 pm

As I noted earlier, these commands add tagging of the VLAN id to the packets which leave the bridge.

No, these commands don't add or remove tags. These commands say that frames, tagged with VIDs configured, can pass tagged from bridge (the switch like entity) to bridge interface. The other member ports of those VLANs are wifi interfaces and ether ports, all of them are access (untagged) ports (bridge does tag frames on ingress on those ports due to PVID setting and does strip header on egress due to untagged membership). Since AP/router/switch combo is supposed to transparrently pass traffic between some groups of ports (e.g. green or blue), it has to have bridge configured and in this case VLAN functionality ensures that traffic from different port groups doesn't mix on bridge (the switch like entity). The fact that VLANs are all internal to the device may cause some confusion ... Bridge interface being configured as trunk (all tagged) port makes possible for CPU to receive packets neatly marked (with VLAN tag) ...

pcunite · Thu Mar 02, 2023 1:18 am

I updated the examples on February 17th. You must have just missed the fixes for this exact sort of situation. As you've discovered, firmware updates have changed the [find] construct and can cause configuration issues. Basically [find] would do nothing at times depending on what had been done previous. Please uses the new configuration examples which work with v6 and v7.

moveik · Fri Mar 03, 2023 7:01 pm

As I noted earlier, these commands add tagging of the VLAN id to the packets which leave the bridge.
No, these commands don't add or remove tags. These commands say that frames, tagged with VIDs configured, can pass tagged from bridge (the switch like entity) to bridge interface.

Then I got confused.
I will point out the parts which got me confused:

According to the specs, I understand that the attributes "tagged" or "untagged" do add or remove the VLAN-ID tag from the packets.
This is written in the Bridge VLAN table page - quote:

tagged (interfaces; Default: none) Interface list with a VLAN tag adding action in egress. This setting accepts comma-separated values. e.g. tagged=ether1,ether2.
untagged (interfaces; Default: none) Interface list with a VLAN tag removing action in egress. This setting accepts comma-separated values. e.g. untagged=ether3,ether4

And it is also written in the Bridge VLAN Table #Background section - quote:

Tagged/Untagged - Under /interface bridge vlan menu, you can specify an entry that contains tagged and untagged ports. In general, tagged ports should be your trunk ports and untagged ports should be your access ports. By specifying a tagged port the bridge will always set a VLAN tag for packets that are being sent out through this port (egress). By specifying an untagged port the bridge will always remove the VLAN tag from egress packets.

...

PVID - The Port VLAN ID is used for access ports to tag all ingress traffic with a specific VLAN ID. A dynamic entry is added in the bridge VLAN table for every PVID used, the port is automatically added as an untagged port.

On the other hand, in the same page we have this:

VLAN-ids - Under /interface bridge vlan menu, you can specify an entry in which certain VLANs are allowed on specific ports. The VLAN ID is checked on egress ports. If the packet contains a VLAN ID that does not exist in the bridge VLAN table for the egress port, then the packet is dropped before it gets sent out.

So, some parts say that VLAN ID is being added, while other parts say that VLAN ID is being checked.
Not sure which is true, but now I understand that I need to list all the existing VLAN IDs via the "/interface bridge vlan" menu to define the "bridge" as a trunk (which, consequently, would allow the bridge to process packets with those corresponding VLAN IDs).

... (bridge does tag frames on ingress on those ports due to PVID setting and does strip header on egress due to untagged membership).

Apologies for my continued confusion though doesn't that contradict the previous sentences that you wrote?
If bridge strip header on egress due to "untagged" membership, wouldn't it be equivalent to say that bridge adds VLAN ID tag on ingress due to "tagged" membership?

Bridge interface being configured as trunk (all tagged) port makes possible for CPU to receive packets neatly marked (with VLAN tag) ...

This scenario which you described is equivalent to whatever we configure for the "Router-Switch-AP (all in one)" (as written in this comment) ?
Meaning, we configured BR1 as trunk here (the VLAN IDs 10,20 and 99 are the only VLAN IDs which exist):

/interface bridge vlan
add bridge=BR1 tagged=BR1 vlan-ids=10
add bridge=BR1 tagged=BR1 vlan-ids=20
add bridge=BR1 tagged=BR1 vlan-ids=99

?

I updated the examples on February 17th. You must have just missed the fixes for this exact sort of situation. As you've discovered, firmware updates have changed the [find] construct and can cause configuration issues. Basically [find] would do nothing at times depending on what had been done previous. Please uses the new configuration examples which work with v6 and v7.

Thank you! Highly appreciated.
I noticed that in my v7 I have "/interface wifiwave2" instead of "/interface wireless", not sure why the difference exist.

anav · Fri Mar 03, 2023 8:10 pm

I noticed that in my v7 I have "/interface wifiwave2" instead of "/interface wireless", not sure why the difference exist.

Hahaha, do you really want to go there........lets just say its an experiment where MT is testing the psychology of their users,,,,,,,,,,,,, how many time will they beat their heads against the wall and still buy MT wifi.............

mkx · Fri Mar 03, 2023 10:27 pm

First: it's a bit confusing which bridge personality is meant in which configuration part. Rule of thumb: when property name is "bridge", then it's referring to switch-like personality. When property name is "interface", then it refers to the bridge personality of interface between CPU and switch-like personality. The same is true when property name is "tagged" or "untagged", these also refer to interface personality.

For example:

/interface bridge vlan
add bridge=BR1 tagged=ether1 untagged=BR1 vlan-ids=42

The "bridge=BR1" only defines bridge (switch-like) entity which is being configured. If there were multiple bridges, then seeing this part of config woukd start to make more sense.

The "tagged" property contains a list of bridge ports that are tagged members of said VLAN. Similarly "untagged" property contains a list of bridge ports that are untagged members of said VLAN (in this example bridge interface BR1 is untagged port for VLAN 42).

Next: the two sections (bridge vlan and bridge port) are only loosely coupled (how tight depends on additional settings).

Basically the bridge port is about ingress behavior. Basic point of this section is to add physical (and some types of logical) interfaces to a bridge. But then there are a few properties that define port behaviour for ingress frames:

frame-types: defines what kind of frames can pass port on ingress. If it's set to admit-only-tagged, then untagged frames are dropped on ingress. If it's set to admit-only-untagged-and-priority-tagged, then any VLAN tagged frames will be dropped on ingress. If it's set to admit-any, then none of frames will be dropped on ingress based only on frame types.
if port is set to allow untagged frames on ingress, then those will be tagged with PVID on ingress.
if port is set with ingress-filtering=yes, then port will check the value of VID for ingress frames against contents of VLAN table which is otherwise constructed in bridge vlan configuration section and act according to check result.
This makes one of loose coupling between the two configuration sections.
a side note: every port has PVID set with default value of PVID=1 ... but that's not shown in normal export (it only shows non-default settings). But it's only used if untagged frames are allowed on ingress. And this (default setting) is the reason for discouraging use of VID=1 for tagged teaffic ... because it's only too easy to forget about untagged dedault and then VLAN subnet integrity is compromised.

The bridge vlan section is essentially about egress behaviour:

it contains VLAN table, each configured VID has a list of member ports. A frame can only egress through port which is member of its VLAN.
If port has property ingress-filtering=yes set, then port will only allow frames to pass on ingress if port is member of corresponding VLAN in this config section
each VLAN member port can either be tagged or untagged member. If it's untagged member, then VLAN tag will be stripped on egress. If port is tagged member, then VLAN tag will stay attached on egress.
If port has frame-types set to admit-only-untagged-and-priority-tagged or admit-all in bridge port section, then it will be automatically added as untagged port to the VLAN row with VID equal to PVID seting of port. This is the second loose coupling between the two configuration sections.

Then there's bridge creation/definition under /interface bridge. As the same command creates both bridge personalities, there are two groups of properties, one group applies to switch-like and another group applies to interface towards CPU:

the important property that defines switch-like personality (among a few others) is vlan-filtering
the important properties that define interface between CPU and switch-like (among others) are: admin-mac, ingress-filtering, frame-types, pvid
These apply only to bridge port connecting to CPU, they don't affect other (explicitly configured) ports.

After this, bridge interface has to be explicitly configured under bridge vlan as VLAN member according to how CPU needs to interact with network.

moveik · Sat Mar 04, 2023 5:33 pm

I noticed that in my v7 I have "/interface wifiwave2" instead of "/interface wireless", not sure why the difference exist.
Hahaha, do you really want to go there........lets just say its an experiment where MT is testing the psychology of their users,,,,,,,,,,,,, how many time will they beat their heads against the wall and still buy MT wifi.............

What do you mean?
Actually I am positively impressed from MT wifi, it seems to be good.

First: it's a bit confusing which bridge personality is meant in which configuration part. Rule of thumb: when property name is "bridge", then it's referring to switch-like personality. When property name is "interface", then it refers to the bridge personality of interface between CPU and switch-like personality. The same is true when property name is "tagged" or "untagged", these also refer to interface personality.

For example:
Code: Select all
/interface bridge vlan
add bridge=BR1 tagged=ether1 untagged=BR1 vlan-ids=42
The "bridge=BR1" only defines bridge (switch-like) entity which is being configured. If there were multiple bridges, then seeing this part of config woukd start to make more sense.

The "tagged" property contains a list of bridge ports that are tagged members of said VLAN. Similarly "untagged" property contains a list of bridge ports that are untagged members of said VLAN (in this example bridge interface BR1 is untagged port for VLAN 42).

Next: the two sections (bridge vlan and bridge port) are only loosely coupled (how tight depends on additional settings).

Basically the bridge port is about ingress behavior. Basic point of this section is to add physical (and some types of logical) interfaces to a bridge. But then there are a few properties that define port behaviour for ingress frames:

frame-types: defines what kind of frames can pass port on ingress. If it's set to admit-only-tagged, then untagged frames are dropped on ingress. If it's set to admit-only-untagged-and-priority-tagged, then any VLAN tagged frames will be dropped on ingress. If it's set to admit-any, then none of frames will be dropped on ingress based only on frame types.

if port is set to allow untagged frames on ingress, then those will be tagged with PVID on ingress.

if port is set with ingress-filtering=yes, then port will check the value of VID for ingress frames against contents of VLAN table which is otherwise constructed in bridge vlan configuration section and act according to check result.
This makes one of loose coupling between the two configuration sections.

a side note: every port has PVID set with default value of PVID=1 ... but that's not shown in normal export (it only shows non-default settings). But it's only used if untagged frames are allowed on ingress. And this (default setting) is the reason for discouraging use of VID=1 for tagged teaffic ... because it's only too easy to forget about untagged dedault and then VLAN subnet integrity is compromised.

The bridge vlan section is essentially about egress behaviour:

it contains VLAN table, each configured VID has a list of member ports. A frame can only egress through port which is member of its VLAN.
If port has property ingress-filtering=yes set, then port will only allow frames to pass on ingress if port is member of corresponding VLAN in this config section

each VLAN member port can either be tagged or untagged member. If it's untagged member, then VLAN tag will be stripped on egress. If port is tagged member, then VLAN tag will stay attached on egress.
If port has frame-types set to admit-only-untagged-and-priority-tagged or admit-all in bridge port section, then it will be automatically added as untagged port to the VLAN row with VID equal to PVID seting of port. This is the second loose coupling between the two configuration sections.

Then there's bridge creation/definition under /interface bridge. As the same command creates both bridge personalities, there are two groups of properties, one group applies to switch-like and another group applies to interface towards CPU:

the important property that defines switch-like personality (among a few others) is vlan-filtering

the important properties that define interface between CPU and switch-like (among others) are: admin-mac, ingress-filtering, frame-types, pvid
These apply only to bridge port connecting to CPU, they don't affect other (explicitly configured) ports.

After this, bridge interface has to be explicitly configured under bridge vlan as VLAN member according to how CPU needs to interact with network.

That is a very valuable reply, thank you!
Technically I understand all what you've written.
I think I need a little bit more time and experience until it would be able to actually internalize everything properly.

VLAN tutorial - Understanding menu "/interface bridge vlan"

VLAN tutorial - Understanding menu "/interface bridge vlan"

Re: VLAN tutorial - Understanding menu "/interface bridge vlan"

Re: VLAN tutorial - Understanding menu "/interface bridge vlan"

Re: VLAN tutorial - Understanding menu "/interface bridge vlan"

Re: VLAN tutorial - Understanding menu "/interface bridge vlan"

Re: VLAN tutorial - Understanding menu "/interface bridge vlan"

Re: VLAN tutorial - Understanding menu "/interface bridge vlan"

Re: VLAN tutorial - Understanding menu "/interface bridge vlan"

Re: VLAN tutorial - Understanding menu "/interface bridge vlan"

Re: VLAN tutorial - Understanding menu "/interface bridge vlan"

Re: VLAN tutorial - Understanding menu "/interface bridge vlan"

Re: VLAN tutorial - Understanding menu "/interface bridge vlan"

Who is online