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

On Fri, Aug 19, 2022 at 11:51:11AM +0200, netdev@kapio-technology.com wrote:

On 2022-08-14 16:55, Ido Schimmel wrote:

quoted

On Fri, Aug 12, 2022 at 02:29:48PM +0200, netdev@kapio-technology.com
wrote:

quoted

On 2022-08-11 13:28, Ido Schimmel wrote:

quoted

quoted

quoted

I'm talking about roaming, not forwarding. Let's say you have a locked
entry with MAC X pointing to port Y. Now you get a packet with SMAC X
from port Z which is unlocked. Will the FDB entry roam to port Z? I
think it should, but at least in current implementation it seems that
the "locked" flag will not be reset and having locked entries pointing
to an unlocked port looks like a bug.

I have made the locked entries sticky in the bridge, so that they don't move
to other ports.

Please make sure that this design choice is explained in the commit
message. To be clear, it cannot be "this is how device X happens to
work".

quoted

quoted

quoted

quoted

quoted

In general I have been thinking that the said setup is a network
configuration error as I was arguing in an earlier conversation with
Vladimir. In this setup we must remember that SMAC X becomes DMAC X
in the
return traffic on the open port. But the question arises to me why
MAC X
would be behind the locked port without getting authed while being
behind an
open port too?
In a real life setup, I don't think you would want random hosts
behind a
locked port in the MAB case, but only the hosts you will let
through. Other
hosts should be regarded as intruders.

If we are talking about a station move, then the locked entry will
age out
and MAC X will function normally on the open port after the timeout,
which
was a case that was taken up in earlier discussions.

But I will anyhow do some testing with this 'edge case' (of being
behind
both a locked and an unlocked port) if I may call it so, and see to
that the
offloaded and non-offloaded cases correspond to each other, and will
work
satisfactory.

It would be best to implement these as additional test cases in the
current selftest. Then you can easily test with both veth pairs and
loopbacks and see that the hardware and software data paths behave the
same.

How many loops would be needed to have a selftest with a HUB and a MAC on
both a locked and an unlocked port?

I assume you want a hub to simulate multiple MACs behind the same port.
You don't need a hub for that. You can set the MAC using mausezahn. See
'-a' option:

"
   -a <src-mac|keyword>
       Use specified source MAC address with hexadecimal notation such as 00:00:aa:bb:cc:dd.  By default the interface MAC address will be used. The  keywords  ''rand''
       and  ''own''  refer to a random MAC address (only unicast addresses are created) and the own address, respectively. You can also use the keywords mentioned below
       although broadcast-type source addresses are officially invalid.
"

quoted

quoted

I think it will be good to have a flag to enable the mac-auth/MAB
feature,
and I suggest just calling the flag 'mab', as it is short.

I have now created the flag to enable Mac-Auth/MAB with iproute2:
bridge link set dev DEV macauth on|off

You have 'macauth' here, but 'mab' in the output below. They need to
match. I prefer the latter unless you have a good reason to use
'macauth'.

with the example output from 'bridge -d link show dev DEV' when macauth is
enabled:
1: ethX: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state
forwarding priority 32 cost 19
    hairpin off guard off root_block off fastleave off learning on flood off
mcast_flood on bcast_flood on mcast_router 1 mcast_to_unicast off
neigh_suppress off vlan_tunnel off isolated off locked mab on

The flag itself in the code is called BR_PORT_MACAUTH.

quoted

Fine by me, but I'm not sure everyone agrees.