DSA Mini-tutorial still marked as Work In Progress
f.fainelli at gmail.com
Wed Sep 7 16:49:18 PDT 2022
On 9/7/2022 3:17 PM, David Lang wrote:
> with DSA, do you HAVE to go through the cpu interface and kernel to
> bridge different ports on the switch? or can you still do vlan routing
> inside the switch?
DSA offloads the bridge to the switch hardware, so if the hardware
switch can do its job and forward frames in hardware from port A to port
B, it will do it. DSA has little significance here, the same constraints
apply/applied to swconfig as well.
> for the Scale conference, I've done a lot of work using the switch for
> passing vlan tagged traffic on to other systems while only sending some
> of it to the CPU (the CPU would be a very significant bottleneck if I
> tried to send everything though it)
> David Lang
> On Wed, 7 Sep 2022, Jo-Philipp Wich 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
>> bridge VLAN filtering became conflated into one concept while they're
>> different pieces; one can do bridge VLAN filtering without DSA and one
>> 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
>> 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
>> For example simple common use cases like:
>> - Making each switch port it's own independent interface with own subnet
>> - Break out one switch port to turn it into some kind of restricted
>> IoT or
>> guest network access port
>> - 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
>> out of the br-lan bridge and either be put into another bridge or
>> 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
>> - Bridge device "br-lan" containing "lan1 lan2 lan3"
>> - VLAN filtering enabled
>> - Bridge VLAN #10 containing lan1 as tagged, lan2 as tagged, lan3 as
>> - VLAN device br-lan.10 on top of br-lan
>> In the former case you would put your IP address settings onto the
>> "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
>> out any bridge-VLAN related information into a separate advanced VLAN
>> Another conceptual issue I see is that people came to expect a dedicated
>> "switch" configuration ui which is something that does not really work
>> 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,
>> that the former semi opague swconfig switch configuration entity was
>> into a bunch of ethernet devices inside a bridge...
>> ~ Jo
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
More information about the openwrt-devel