netdev - Re: Using a bridge for DSA and non-DSA devices

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 5 Dec 2022 21:08:38 +0100
From:   Christian Eggers <ceggers@...i.de>
To:     Vladimir Oltean <olteanv@...il.com>
CC:     <netdev@...r.kernel.org>
Subject: Re: Using a bridge for DSA and non-DSA devices

Hi Vladimir,

On Monday, 5 December 2022, 20:08:05 CET, Vladimir Oltean wrote:
> Hi Christian,
> 
> In the model that the DSA core tries to impose, software bridging is
> possible, as long as you understand the physical constraints (throughput
> will be limited by the link speed of the CPU ports), and as long as the
> switch doesn't use DSA_TAG_PROTO_NONE (a remnant of the past).

my hope was that a "combined" mode would be possible where traffic
between the DSA slave ports is forwarded in hardware and only other
traffic requires CPU intervention. Our embedded device uses the
KSZ9563 3-port switch with two DSA slave ports. The intention is
that the customer can daisy chain multiple of our devices without
the need for extra Ethernet switches. For reasonable performance,
forwarding shall be done in hardware, especially as the external
port a 1 GBit Ethernet whilst the CPU port is only 100 MBit/s.

Beside the Ethernet interfaces I would like to add further connectivity
options (like USB gadget, WiFi, Bluetooth, ...). I consider these
interfaces as "secondary" in terms of performance and I think that
forwarding will not be an use case here. Currently, each secondary
interface has its own subnet (no bridging), but for every interface I add,
I have to "invent" new IP ranges which eventually collide with other
networks of the customers.

I already took the "lets use IP4LL" joker on one interface but I
learned today, that I cannot do this for further ones
(at least not without bridging). To make things even worse, we decided
to always configure IP4LL as a secondary address on the Ethernet
interfaces (NetworkManager just gained support for this). That's
why I estimate whether it makes sense to put all external interfaces
below a common bridge with only one IP address at all (or one pair
of DHCP+IP4LL).

> 
> Unfortunately the results might depend on which switch driver you use
> for this, since some driver cooperation is needed for smooth sailing,
> and we don't see perfect uniformity. See the
> ds->assisted_learning_on_cpu_port flag for some more details.

Thanks for the pointer, unfortunately this hasn't been implemented
yet for the KSZ switches.

> Did you already try to experiment with software bridging and faced any
> issues?

No, I didn't. But just to make it clear: Will the DSA framework
change to "pure software" switching as soon I add the first non-DSA
slave to an exisiting DSA bridge?

regards
Christian