I apologize this question. I know it's been gone over many times. But, my confusion persists.

If I have a simple vlan setup such as a hEX (i.e., with WAN on ether1) and an AP (e.g., Netmetal).

The hEX has vlan32 for management and connectivity to the AP; and vlan2 for wifi-guest (coming in from AP).

This is a totally simplified/stripped down version, just so I can ask the question (at the end of the post).


On the hEX:


On the AP:

My question is:

On the AP, vlan32 is tagged for both bridge and ether1.

But, vlan2 is tagged only for ether1.

Is this correct? Either yes or no, why?

Does the answer to this lie with the question of whether vlan2 frames need to be processed by the CPU, which is accomplished by tagging bridge? But, because the AP is not acting as a router, the CPU is not necessary?

First off all you are doing it wrong, in HEX there's a different way to configure VLAN what you are doing is for CRS3XX

Try this
https://www.youtube.com/watch?v=Rj9aPoyZOPo

What VLAN1 ?? Don't mention VLAN1 here or we will strip your forum rank...

So only VLAN that is used as management VLAN should be tagged for bridge and in interface/vlan you should create mgmt vlan interface.

Other vlans should be tagged only for trunk port, in your case ether1, and untagged for desired wireless interfaces.

What VLAN1 ?? Don't mention VLAN1 here or we will strip your forum rank...

So only VLAN that is used as management VLAN should be tagged for bridge and in interface/vlan you should create mgmt vlan interface.

Other vlans should be tagged only for trunk port, in your case ether1, and untagged for desired wireless interfaces.

It was a typo. Please allow me this one innocent typographic error. You can't possibly suggest that a guru would actually mean to write vlan1!

So only VLAN that is used as management VLAN should be tagged for bridge and in interface/vlan you should create mgmt vlan interface.

Other vlans should be tagged only for trunk port, in your case ether1, and untagged for desired wireless interfaces.

Thank you for the confirmation.

Why should only the VLAN used as management be tagged for bridge? Is it the CPU connection?

First off all you are doing it wrong, in HEX there's a different way to configure VLAN what you are doing is for CRS3XX

Try this
https://www.youtube.com/watch?v=Rj9aPoyZOPo

No if he is using the RB750Gr3 with RouterOS 7 then what the OP does is the correct way (but ingress-filtering should be set to the default value of yes). Your video is out of date because the hEX supports hardware offload with Bridge VLAN Filtering since RouterOS 7 and the old method of using the switch menu is no longer suitable.

First off all you are doing it wrong, in HEX there's a different way to configure VLAN what you are doing is for CRS3XX

Try this
https://www.youtube.com/watch?v=Rj9aPoyZOPo

I got about 10 minutes into it and could not follow along, I believe because of the differences between the ROS version he's using (6.4x) and what I'm using (7.17.2). Specifically, creating VLANs within the SWITCH configuration.

My guess would be that the bridge vlan creation process has replaced the switch vlan creation process.

Is this correct? Either yes or no, why?

Does the answer to this lie with the question of whether vlan2 frames need to be processed by the CPU, which is accomplished by tagging bridge? But, because the AP is not acting as a router, the CPU is not necessary?

Each VLAN only needs to pass through the bridge (the port) if the routing part of the code needs access to that VLAN. Therefore, as you have correctly concluded, since there is no address on the cAP that would be associated to VLAN ID 2 by any means, there is no reason to allow VLAN 2 to pass through bridge (the port).

Newer versions of RouterOS (7.16+) do this for you automatically. If you create an /interface/vlan with vid=N and attach it to bridge (the IP interface), RouterOS automatically adds a row into /interface/bridge/vlan with vlan-ids=N and puts bridge (the port) to the tagged list on that row; if you set the pvid to N and frame-types to admit-all or admit-only-untagged-and-priority-tagged on an /interface/bridge row, RouterOS also automatically adds a row to /interface/bridge/vlan with vlan-ids=N and puts bridge (the port) to the untagged list on that row.

Is this correct? Either yes or no, why?

Does the answer to this lie with the question of whether vlan2 frames need to be processed by the CPU, which is accomplished by tagging bridge? But, because the AP is not acting as a router, the CPU is not necessary?

Each VLAN only needs to pass through the bridge (the port) if the routing part of the code needs access to that VLAN. Therefore, as you have correctly concluded, since there is no address on the cAP that would be associated to VLAN ID 2 by any means, there is no reason to allow VLAN 2 to pass through bridge (the port).

Newer versions of RouterOS (7.16+) do this for you automatically. If you create an /interface/vlan with vid=N and attach it to bridge (the IP interface), RouterOS automatically adds a row into /interface/bridge/vlan with vlan-ids=N and puts bridge (the port) to the tagged list on that row; if you set the pvid to N and frame-types to admit-all or admit-only-untagged-and-priority-tagged on an /interface/bridge row, RouterOS also automatically adds a row to /interface/bridge/vlan with vlan-ids=N and puts bridge (the port) to the untagged list on that row.

That's a wonderful explanation -- thank you

Could you please "address on the cAP" might there be to require the bridge port to be tagged? Are you referring to an IP address associated with vlan2?

When you refer to newer versions of ROS doing this automatically you state that creating a vlan using /interface/vlan and attaching that vlan to the bridge (I assume you mean /interface/bridge/vlan), automatically creates a vlan table row that includes tagged=bridge. Did I get that correct? If so, then if vlan2 had an IP address associated with it, then adding vlan2 to /interface/bridge/vlan would add the parameter tagged=bridge, correct?

I tried it and it didn't work (I'm sure I'm doing something incorrectly).

I added:

/interface vlan
add interface=ether1 name=vlan999 vlan-id=999

Then I added:

/interface bridge vlan
add bridge=bridge vlan-ids=999

And it did not automatically add vlan999 as tagged on the bridge.

I then I removed /interface/bridge/vlan 999

Then I added:

/interface bridge port
add bridge=bridge interface=ether1 pvid=999

This totally locked me out of the router.

Luckily, I have ether5 as OffBridge.

As soon as you make any interface (in your case, ether1) a member port of a bridge, you must not use that interface directly for any other purpose - you must not attach /interface/vlan or an IP address/DHCP client to it, you must not make it a member port of any other bridge, you must not make it a member port of a bonding interface, I don't know what else I've forgotten, otherwise a lot of surprises awaits you.

So move the /interface/vlan with vlan-id=999 from ether1 to bridge and all should start working the intended way.

Could you please "address on the cAP" might there be to require the bridge port to be tagged? Are you referring to an IP address associated with vlan2?

I am. I just have detailed both possible ways how to do that.

if vlan2 had an IP address associated with it, then adding vlan2 to /interface/bridge/vlan would add the parameter tagged=bridge, correct?

Not adding vlan2 to /interface/bridge/vlan (that's what will happen automatically), but adding an /interface/vlan with interface=bridge vlan-id=2 (that's what you have to do manually if you want to let the router code access VLAN 2).


What I forgot to write was that since the rows in /interface/bridge/vlan are added dynamically, they are not shown in the export.

Will read what you wrote 100 more times and attempt to learn.

Thanks (as always)!

all should start working the intended way.

(that is, if the actual intention was to make ether1 an access port to VLAN 999, despite having no IP configuration attached to VLAN 999).

Okay, just tested.

Added:
And (as you indicated), the entry in /interface/bridge/vlan shows vlan 999 as tagged on bridge:
But, export (as you state) does not show vlan 999:
As far as what I am trying to accomplish: I might call it "The Impossible:" I am trying to learn how to set up VLANs.

Now I need to go back to figuring what exactly how, when, why, and where to use:
because I suspect it is rare that the automatically created entry (where the vlan is tagged to the bridge with no other parameters) is sufficient.

With 7.16+, an /interface/bridge/vlan row is dynamically created for a particular VLAN ID and bridge:

• whenever an interface is made a member port of that bridge and its pvid is set to that VLAN ID (in this case, the interface name is put to the untagged list on that row)
• whenever an /interface/vlan with that VLAN ID is attached to that bridge (in this case, the bridge is put to the tagged list on that row)

So the only situation where you have to add the row manually is when you want to allow that VLAN to pass tagged through some other ports of the bridge.

So the only situation where you have to add the row manually is when you want to allow that VLAN to pass tagged through some other ports of the bridge.

Isn't this case (requiring the VLAN to pass tagged through ports other than the bridge) a common situation?

It is indeed, does it make the description misleading in any way?

It is indeed, does it make the description misleading in any way?

I'm not sure what description you are referring to but nothing you wrote in this thread is at all misleading.

You are wonderfully precise and detailed.

My only comment would be that your responses are so complete and accurate that they are challenging to understanding for those at the other extreme of understanding these things.