I’ve got tagged VLANs functioning up to a managed switch fine but what I am interested in is at least understanding if this second goal is not possible. I would like to set the vacant ports on the RB4011 to untagged on one of the VLANs, that is to add tag to ingress and strip on egress. I know there are plentiful discussions but they span pre-6.41 and RB4011 switch type so I am wondering if this is workable with all of the VLANs on the bridge. When I attempt to set the ingress/egress under the switch menu I get an error that it is not supported. I have tried creating a bridge for the VLAN and individuals interfaces but everything I have tried ends up in one of two results. No traffic at all or the default (for now) 192.168.88.0 network. Thank you for any insight!
Mikrotik have not implemented hardware VLAN support for the switch chip used in the RB4011. You should be using a single VLAN-aware bridge, in which case you just have to set the PVID for the bridge port interface. Posting the output of /export hide-sensitive usually helps.
Thank you tdw! This makes sense, I would be okay with just having the PVID changed to interact with another VLAN (besides VID1) but when I change this, it still communicates on the “default-default” 192.168.88.0 network.
On switch chips which support it, Mikrotik makes use of proprietary tags allowing the switch to indicate to the CPU through which port the frame got in and allowing the CPU to indicate to the switch chip through which port to send the frame out. This allows to bypass the switch chip forwarding and let the bridge do the job. On switch chips which do not support these proprietary tags, Mikrotik misuses the regular 802.1Q tags for this purpose, so as many VLAN IDs as there are external ports on the chip are occupied for this purpose. This makes it impossible to make the VLAN handling capabilities of the switch available to the user in the /interface ethernet switch configuration tree, because for trunk ports, there would be no way how the CPU could learn or indicate the port.
As far as I know, this affects the 4011 and hEX Gr3.
When implementing your concept using bridges:
with “bridge-per-VLAN” approach, just create another bridge, and make all unused ports its members.
with the “one-bridge-for-all-VLANs” approach, which requires vlan-filtering=yes on that bridge, you can use the /interface bridge vlan to define which VLANs are permitted on which ports of a bridge (by reverse mapping - you list the tagged and untagged ports per VLAN ID or VLAN ID list), and a matching setting of pvid in /interface bridge port rows. So here, to make the unused ports access ones to VLAN X, you list the unused ports in the untagged field of an /interface bridge vlan row with vlan-ids=X, and set the pvid in /interface bridge port rows for these interfaces to X.
Thank you Sindy! When I attempt to follow, creating a new bridge and assigning member ports, I do not get any traffic. If I enable vlan-filtering on the original bridge, it kills traffic for all VLANs (I only bring this up because it may help home in on the issue!). One interesting thing about creating another bridge and assigning members and then enabling vlan-filtering is that the “Current Tagged” and “Current Untagged” columns for the VLANs on the new bridge populate dynamically but then traffic does not flow. I know I am missing something but I practically tore my hair out scouring for info
Post your current configuration (see my automatic signature regarding anonymisation). I become nervous when you mention “vlan-filtering=no” as well as “multiple vlans” that get killed on the original bridge.
A bridge has two roles - one like a switch between member ports, the other an interface for traffic to the CPU. You haven’t included the interface-like role in the bridge VLAN configuration.
If you are creating VLAN interfaces for all CPU traffic leave the PVID on the bridge itself unchanged (i.e. 1), similarly on tagged-only trunk ports.
Note frame-types has no effect unless ingress-filtering is set, you can also omit /interface bridge vlan untagged entries (untagged=), these will be generated automatically from the /interface bridge port PVID entries (pvid=)
Assuming you want ether2,3,6-10 & sfpplus1 to carry VLAN24 untagged, ether4 to carry VLAN99 untagged, and ether5 to carry VLANs 24,31,32,43,59,99 tagged then the following - although this doesn’t include all of the ingress filtering settings
If I need to change some ports PVID later, will the untagged entries follow automatically?
If I define a “management” interface in /interface vlan, will it also be automatically added to tagged entries? (so, could I omit both untagged and tagged on this code line you mentioned?)
Yes, changing the pvid= settings in /interface bridge port will add matching dynamic untagged entries to /interface bridge vlan. Otherwise you have to remember to update both when changing the PVID on an interface. Note that by default Winbox only shows the ‘Current Tagged’ and ‘Current Untagged’ columns under Bridge > VLANs, it is worthwhile enabling the ‘Tagged’ and possibly ‘Untagged’ columns too as inactive interfaces do not appear in the ‘Current …’ entries.
If I define a “management” interface in /interface vlan, will it also be automatically added to > tagged > entries? (so, could I omit both untagged and tagged on this code line you mentioned?)
No, tagged membership of the ‘switch’ bridge role has to stated explicitly in /interface bridge vlan
This is glorious! It clicked in my head when you added the bridge to tagged VLANs! Everything is working from all RB switchports and the managed switchports with the following:
This setting adds extra port security … it will discard any tagged packets on ingress which othereise might get delivered somewhere.
Settings in /interface bridge vlan largely define behaviour on egress and don’t necessarily reflect behaviour on ingress.
Another setting from the same category is ingress-filtering which, when set to yes, actually links the ingress filtering to egress filtering.
