What's the difference between bridge containing lan1.2 and explicit VLAN filtering?

From the doc, it seems there are two way to create VLANs (with the new DSA subsystem):

  1. Create a bridge device that connects interfaces like lan1, lan2.3, lan3.4 to implicitly create connected VLANs and regular interfaces.
  2. Create a bridge device that connect regular interfaces like lan1 and lan2, then explicitly create VLAN filtering with tag, untagged and unparticipating VLAN IDs.

I wonder if the two are equivalent? If so, how to convert between the two? For example, what's the VLAN filtering's equivalent of a bridge connecting lan1, lan2.3, lan3.4?

My intuition says it's something like this

VLAN ID lan1 lan 2 lan3
3 u t -
4 u - t

But the doc says you can have only one untagged VLAN ID for a regular interface, so that must be wrong.

I would really appreciate it if someone could shed some light.

It seems you would need support for VLAN mapping (VLAN translation) if you want to connect VLAN 3 on lan2 with VLAN 4 on lan3. Why do you need to do that anyway?

example PVID

1 Like

As @anomeome has already linked, PVID might be the thing that you are missing.

The 802.1q spec allows the following on any port:

  • zero or one untagged network
    AND
  • zero, one, or many tagged networks.

There are various ways of implementing the untagged network assignments, but it is important to remember that only one untagged network can be active on a port at any given time. So, for switches or firmware environments that allow you to assign multiple networks as untagged on the same port, there will also be means of selecting which one is actually active on that port, and that is the PVID setting.

I like to make silly analogies: Imagine that you have several pairs of shoes for different weather. You've got them all near your front door, and you can only wear one pair when you leave the house (let's assume you can't bring any with you). All of the shoes are available to be chosen as your pair for the day (all 'untagged'), but only the one you select for the day is the active pair (PVID). The others are simply ignored/inactive.

That won't be a problem in this case since a bridge without vlan filtering can only process traffic with a single vlan id (or untagged traffic) on each port.

I think the problem is if you bridge ports with different tags then you can't convert it to a bridge with vlan filtering containing the untagged ports. Because it would require vlan mapping/translation. In this case between vlan 3 and vlan 4.

The example actually only serves to help me understand the difference between the two ways of setting up VLANs, I didn't realize using two or more VLAN IDs in a single bridge could actually make things complicated, sorry about the confusion.

In my case it's actually between a (x86) router and an AP:

Router

br-home: eth0.1 eth1
br-guest: eth0.2 eth2
br-office: eth0.3 eth3

AP

br-home: lan1.1 lan2
br-guest: lan1.2 lan3
br-office: lan1.3 lan4

where router's port1 and AP's port1 are connected with a wire.

@anomeome and @psherman's explanation are helpful, since I didn't really understand PVIDs.

But I'm still not absolutely sure if the dot notation and VLAN filtering are equivalent.

Did you get an answer to what the difference was? I'm looking at vlans currently and have seen several ways of setting them up. It still seems to work when using the simple dot notation on a bridge, but I don't know in what way that's different to specifying vlan filtering and then mapping to each of those separately. Plus then the naming scheme prepends the bridge where you created it (e.g. br-lan.x) but x might be nothing to do with 'lan', if for example you're setting up separate networks e.g. guest etc. Honestly just seems confusing to me.

Everything in one bridge is more certain to set up hardware switching properly, especially if there is an Ethernet trunk port involved handling more than one network by using tags. This used to be the only way that it would work at all, but I don't know maybe the configuration parsing has improved to the point that it can set up hardware switching among multiple bridges.

For dsa, this is certainly true. But for devices still using swconfig, multiple bridges do appear to work just fine.

@VintageRain - I think a new thread would make sense to help you with your specific config. I can move your initial question above into a new thread, or you could create a new one. Let me know what you’d like to do.