DSA Mini-tutorial still marked as Work In Progress

[Florian Fainelli]

On 9/7/2022 3:00 PM, Sebastian Moeller wrote:
> Hi Jo,
> 
> I was under the impression* that bridge-vlan filtering is something that can be relegated to the switch hardware, while creating a bridge between VLAN interfaces happens in software. Is that wrong?

It is incorrect. DSA offloads the bridge to the switch hardware whether 
you have VLAN filtering or not.

When the bridge is not VLAN aware (vlan_filtering=0) what it means is 
that the Linux bridge, and the underlying switch MUST accept both VLAN 
and non-VLAN tagged frames.

If you do want VLAN tagged frames in that bridge, then you are supposed 
to terminate VLAN traffic by creating upper VLAN devices such as 
lan1.10, lan2.10 etc. but the switching between lan1.10 and lan2.10 
still happens in hardware because those VLAN devices are offloaded into 
the switch hardware.

When vlan_filtering=1 is set, the hardware is configured to only accept 
untagged PVID frames as well as whichever VLAN tagged frames you have 
configured.

For instance, if you configured your bridge this way with: lan1, lan2, 
lan3 and lan4 part of br-lan with vlan_filtering=1, each switch port 
will be programmed to be in the bridge's default_pvid (1, unless 
changed), and if you sent a VLAN tagged frame with VLAN ID 2 towards any 
of those ports, and assuming the switch hardware is capable of it, that 
VLAN ID 2 frame creates an egress VID violation and is discarded. If not 
discarded in hardware it would be discarded in software.

Hope this helps.

> 
> Regards
> 	Sebastian
> 
> 
> *) Not sure where I got that impression from
> 
> 
>> On Sep 7, 2022, at 23:48, Jo-Philipp Wich <jo at mein.io> wrote:
>>
>> Hi Rich,
>>
>> that tutorial is good ground work imho. One thing I repeatedly noticed (not in
>> the document, but in forum and irc chatter) is that over the time, DSA and
>> bridge VLAN filtering became conflated into one concept while they're actually
>> different pieces; one can do bridge VLAN filtering without DSA and one can
>> utilize DSA without doing bridge VLAN filtering.
>>
>> Bluntly speaking, DSA is the thing that gives you one Linux network device per
>> switch port and bridge VLAN filtering is the stuff that allows you declaring
>> swconfig-esque VLAN port groups on top of an arbitrary bridge interface.
>>
>> I think this is something we should try to better convey in the documentation.
>>
>> For example simple common use cases like:
>>
>> - Making each switch port it's own independent interface with own subnet
>>
>> or
>>
>> - Break out one switch port to turn it into some kind of restricted IoT or
>>    guest network access port
>>
>> or
>>
>> - Bridge each ethernet port to another SSID
>>
>> don't require bridge VLAN filtering or touching VLANs in general at all (in
>> contrast to former swconfig). The per-port net devices just have to be taken
>> out of the br-lan bridge and either be put into another bridge or configured
>> as independent network devices.
>>
>> Bridge VLAN filtering on the other hand is only actually needed if you want to
>> deal with VLAN tagged traffic inside the bridge. And even then there's
>> sometimes alternative ways, for example the following two scenarios should be
>> functionally equivalent:
>>
>> - Bridge device "br-vlan10" containing "lan1.10 lan2.10 lan3.10"
>>   - VLAN filtering disabled
>>
>> vs.
>>
>> - Bridge device "br-lan" containing "lan1 lan2 lan3"
>>   - VLAN filtering enabled
>>   - Bridge VLAN #10 containing lan1 as tagged, lan2 as tagged, lan3 as tagged
>> - VLAN device br-lan.10 on top of br-lan
>>
>>
>> In the former case you would put your IP address settings onto the dedicated
>> "br-vlan10" bridge device while in the latter case you would configure the IP
>> addressing on the "br-lan.10" subinterface of the "br-lan" bridge.
>>
>> So maybe it makes sense to focus on the "with DSA, your switch just becomes a
>> linux bridge over a bunch of netdevs" aspect in the mini tutorial and break
>> out any bridge-VLAN related information into a separate advanced VLAN tutorial.
>>
>> Another conceptual issue I see is that people came to expect a dedicated
>> "switch" configuration ui which is something that does not really work with
>> DSA devices anymore since there is no dedicated switch hardware entity to
>> interact with anymore (DSA takes care of completely abstracting this away from
>> the user point of view) and that bridge-vlans just happen to be a
>> configuration detail of a bridge, and that there happens to be a bridge
>> "br-lan" by default, but a system could have multiple bridges, or none at all.
>>
>> So we should also explain why there is no central "switch configuration"
>> anymore and that this does not translate into a loss of functionality, but
>> that the former semi opague swconfig switch configuration entity was dissolved
>> into a bunch of ethernet devices inside a bridge...
>>
>>
>>
>> ~ Jo
>>
>> _______________________________________________
>> openwrt-devel mailing list
>> openwrt-devel at lists.openwrt.org
>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> 
> 
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

-- 
Florian