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 <j...@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@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
--
Florian
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
