Thread (59 messages) 59 messages, 6 authors, 2022-08-19

Re: [PATCH v4 net-next 3/6] drivers: net: dsa: add locked fdb entry flag to drivers

From: <hidden>
Date: 2022-07-17 16:10:29
Also in: bridge, linux-kselftest, lkml

On 2022-07-17 17:08, Vladimir Oltean wrote:
On Sun, Jul 17, 2022 at 04:57:50PM +0200, netdev@kapio-technology.com 
wrote:
quoted
Maybe I am just trying to understand the problem you are posing, so 
afaics
MAC addresses should be unique and having the same MAC address behind 
a
locked port and a not-locked port seems like a mis-configuration 
regardless
of vlan setup? As the zero-DPV entry only blocks the specific SA MAC 
on a
specific vlan, which is behind a locked port, there shouldn't be any
problem...?

If the host behind a locked port starts sending on another vlan than 
where
it got the first locked entry, another locked entry will occur, as the
locked entries are MAC + vlan.
I don't think it's an invalid configuration, I have a 17-port Marvell
switch which I use as infrastructure to connect my PC with my board 
farm
and to the Internet. I've cropped 4 out of those 17 ports for use in
selftests, effectively now having 2 bridges (br0 used by the selftests
and br-lan for systemd-networkd).

Currently all the traffic sent and received by the selftests is done
through lan1-lan4, but if I wanted to run some bridge locked port tests
with traffic from my PC, what I'd do is I'd connect a (locked) port 
from br0
to a port from br-lan, and my PC would thus gain indirect connectivity 
to the
locked port.

Then I'd send a packet and the switch would create a locked FDB entry
for my PC's MAC address, but that FDB entry would span across the 
entire
MV88E6XXX_FID_BRIDGED, so practically speaking, it would block my PC's
MAC address from doing anything, including accessing the Internet, i.e.
traffic that has nothing at all to do with the locked port in br0.
That isn't quite ok.
Okay, I see the problem you refer to. I think that we have to accept 
some limitations unless you think that just zeroing the specific port 
bit in the DPV would be a better solution, and there wouldn't be caveats 
with that besides having to do a FDB search etc to get the correct DPV 
if I am not too mistaken.

Also trunk ports is a limitation as that is not supported in this 
implementation.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help