Understanding Bridge VLAN filtering UI and untagged ports

[Dante]

I'm trying to understand Bridge VLAN filtering UI in Luci on OpenWrt 24.10.0 with DSA. I'm not deeply familiar with VLANs, but as far as I understand, a port can't be untagged (or native using other vendor's terminology) on multiple VLAN IDs simultaneously without setting the PVID. However it seems Luci doesn't prevent me from marking a port as untagged on multiple VLANs.

So, does this configuration makes sense? And if not, perhaps the UI should not let the user save this change?

Edit: clarified the bit about PVID.

[_bernd]

Yes a port can only be untagged for a single vlan. But a chainsaw is also intended to cut wood but nobody prevents you from cutting of your foot too

[Dante]

Thanks. I thought of making a PR to give users a warning in this situation, but wanted to check my assumptions first. I'll wait for more people to chime in.

[psherman]

IIRC, LuCI does enforce the limit of one untagged VLAN per physical port for devices that use swconfig (not DSA). I'd have to go back and test to be sure that this is true. However, the same logic should ideally be applied to DSA... so that may be worth a PR.

That said, there is an additional nuance and consideration:

• OpenWrt DSA bridge-vlan syntax has 3 options that are considered valid:
  • Tagged (:t)
  • Untagged (:u)
  • Untagged + PVID (:u*).
  • Keep in mind that the * (for PVID) really sets the ingress status (i.e. to what VLAN should untagged traffic be assigned as it enters the port), while the t or u affect the egress.
• Notice that it is possible to have a port that is marked as untagged, but not PVID.
  • There is some precedence for this concept -- some managed switches do this, too, but in order for a network to be considered active on the port as untagged, you must also set the PVID.
  • Some switches simply give you the choice of tagged, untagged, or excluded/not-a-member. The PVID is thus implied with any untagged VLAN, and the software/firmware validates that no more than one network is assigned to a port as untagged.
  • OpenWrt seems to work differently in this regard, though, in that you can actually have multiple VLANs set for untagged egress, even though only one can be set for untagged ingress.
    • this situation is odd and not typically useful, but there was a thread (I can't find it now) where I asked why anyone would ever do this... the answer was a unique, and rather quirky method to perform port isolation with devices on the same subnet using hardware that wasn't designed with port isolation in mind.

So... with that in mind, having multiple VLANs set as untagged on a port may not actually be invalid at the OpenWrt DSA level, although it certainly shouldn't be used under any normal circumstances.

In that thread I referenced, I also remember asking what the difference was between the three ways one could theoretically specify untagged:

config bridge-vlan
   option device 'br-lan'
   option vlan '10'
   list ports 'lan1:u*'

where the above is explicitly specifying untagged + PVID; vs.

   list ports 'lan1:u'

where we specify untagged but not PVID; vs

   list ports 'lan1'

where nothing is specified...

AFAIK (and this would require verification), all three should result in the same effect if only a single VLAN is assigned to a port (as untagged). However, IMO, the ports should always be specified exactly to avoid any ambiguity.... so an untagged VLAN on a port should be untagged + PVID (:u*).

Meanwhile, I'm not sure what data validation currently exists for bridge-VLANs both in LuCI and in UCI syntax...

• In addition to unspecified, :u, :u* and :t, I think the system will actually allow :t* (tagged egress, untagged PVID for ingress), which is not valid or any practical use case that I am aware of.
• The system clearly does not prevent the use of unspecified or :u on multiple VLANs on a given port.
• I don't know if it validates that only one PVID * is specified on a port.

In other words... it's complicated... lol

EDIT: I say all of this based on significant experience with VLANs on both DSA and swconfig for OpenWrt. I almost always directly edit the config files, and I rarely use LuCI or UCI CLI methods to make the changes..

[Dante]

@psherman

IIRC, LuCI does enforce the limit of one untagged VLAN per physical port for devices that use swconfig (not DSA).

You're correct: this is what's happening on a device with swconfig with 23.05.5:

---

@psherman

his situation is odd and not typically useful, but there was a thread (I can't find it now) where I asked why anyone would ever do this... the answer was a unique, and rather quirky method to perform port isolation with devices on the same subnet using hardware that wasn't designed with port isolation in mind.

I guess this is the thread you were referring to:

Asymmetric VLAN is it possible?

[avlan11] I was trying to set up asymmetric vlan on my router ,but it seems impossible. Is there any way to create asymmetric vlan on openwrt ?

With the actual scenario fleshed out here:

DSA and PVID usage examples

After some frustration in trying to figure out what exactly PVID means in relation to vlans and trunk usage in openwrt. Thanx to jow in pointing out what it actually means , So I decided to poke further and find a use case where it can actually apply it in openwrt . I decided to replicate and test a basic concept from cisco of Private vlans . Having multiple layer 2 domains with restrictions on who they can talk to. And now the ability to create multiple untagged vlans on a port without …

Another, more arcane example from Microtik forums:

...traffic passes through dumb switch without any tags and reaches untagged to router at port where switch is connected. Then, if MAC address is found in bridge/host table, traffic gets tagged according to MAC->VID mapping and goes with tag through MT bridge. The return traffic gets untagged and in dumb switch acts like all devices in same L2 but with different subnets.

I did that in the past when I had to modernize an old network full of dumb switches. So while I was waiting for HQ approving proper equipment, purchase and delivery process, I did setup router to tag devices per their MAC, so there could be printer and PC in different VLAN connected to same dumb switch. For dumb switch and devices it looks like you have just router and throw multiple IPs to the bridge - so technically there's multiple subnets, but on switch level anyone can communicate as no VLAN exists.

---

@psherman

I don't know if it validates that only one PVID * is specified on a port.

At least LuCi on 24.10.0 allows only one PVID per port to be set.

---

Wiki DSA examples, explicitly show multiple untagged VLANs on the same port: both with and without PVID:

@psherman

I think the system will actually allow :t* (tagged egress, untagged PVID for ingress), which is not valid or any practical use case that I am aware of.

There’s also a t:* example. The confusing bit is that the implicit PVID assignment is somewhat asymmetric:

• if all interfaces are untagged and no PVID is specified, the first one (based on alphanumeric sort order, creation date or order in the UI?) gets a PVID, hence all untagged ingress is now on PVID;
• if all interfaces are tagged and no PVID is specified, untagged ingress is discarded, i.e. no PVID is assigned automatically.

Unfortunately, these examples are not flashed out and it’s unclear when they would be useful.

---

@psherman

so that may be worth a PR.

It seems that everything is working as expected, but having multiple untagged VLANs can have unintended consequences when not thought through. There could be a warning, like the warning when changing some networking settings that might result in a lock out.

The remaining unclear part from the original scenario of multiple VLANs marked untagged for a port, but no explicit PVID set, is which port will be PVID on that specific OpenWrt device, as VLANs can be added and named in different order. Perhaps this is the part that should give a warning, e.g Port Y has no explicit PVID specified, so VLAN X on port Y will be PVID. Or UI could just mark a VLAN that is PVID for a port in that scenario.

Edit: and thank you for the extended reply. It's always a pleasure reading your posts.

[_bernd]

@Dante

when they would be useful

My totally biased opinion: they are not.
there should never be a reason to fiddle with pvid.
Just use tagged vlans, and untagged on access ports. And if you need to, then single untagged and multiple tagged (like server).

But being creative with pvid? No.
I would consider the network architect and architecture broken.