Subject: Re: dsa/mv88e6xxx: leaking packets on MV88E6341 switch

From: Tobias Waldekranz <[email-masked]>
Date: Tue, 01 Dec 2020 13:29:54 +0100

On Tue, Dec 01, 2020 at 09:49, Peter Vollmer <[email-masked]> wrote:
> On Thu, Nov 26, 2020 at 10:41:44PM +0100, Tobias Waldekranz wrote:
>> On Wed, Nov 25, 2020 at 15:09, Peter Vollmer <[email-masked]> wrote:
>> > - pinging from client0 (connected to lan0 ) to the bridge IP, the ping
>> > requests (only the requests) are also seen on client1 connected to
>> > lan1
>> 
>> This is the expected behavior of the current implementation I am
>> afraid. It stems from the fact that the CPU responds to the echo request
>> (or to any other request for that matter) with a FROM_CPU. This means
>> that no learning takes place, and the SA of br0 will thus never reach
>> the switch's FDB. So while client0 knows the MAC of br0, the switch
>> (very counter-intuitively) does not.
>> 
>> The result is that the unicast echo request sent by client0 is flooded
>> as unknown unicast by the switch. This way it reaches the CPU but also,
>> as you have discovered, all other ports that allow unknown unicast to
>> egress.
>> 
>
> Thanks for this explanation. Would there be a way to inject the br0 MAC
> into the switch FDB using 'bridge fdb' or some other tool as a
> workaround ?

Unfortunately not. DSA will only attempt to offload FDB entries on user
ports to the ATU at the moment. Vladimir has started work on a series
that would also offload addresses from "foreign" ports:

https://lore.kernel.org/netdev/[email-masked]/

His work could possibly be extended to include addresses added to the
bridge itself.

> And is this behaviour the same with all other DSA capable
> switches (or at least the mv88e6xxx ones)?  Will this change eventually 

For mv88e6xxx, yes. These devices will never perform learning on
FROM_CPU frames.

> after the implementation is complete ?

I sure hope so. There are multiple ways forward here. Vladimirs approach
with adding dynamically learned addresses as static entries is one way.

I would like to do some work to optimize multicast forwarding
performance that would also, as a side-effect, solve this
problem. Because it would mean that we would start sending FORWARD
frames from the CPU for bridged traffic, and thus the switch would be
able to learn the location of the source address.