Linux Ethernet Bridging - Aug 2022 - [Bridge] [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 at kapio-technology.com
wrote:
> On 2022-08-14 16:55, Ido Schimmel wrote:
> > On Fri, Aug 12, 2022 at 02:29:48PM +0200, netdev at
kapio-technology.com
> > wrote:
> > > On 2022-08-11 13:28, Ido Schimmel wrote:
> > > 
> > > > > > 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".
> 
> > > > > >
> > > > >
> > > 
> > > 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.
"
> 
> > > 
> > > 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.
> 
> > 
> > Fine by me, but I'm not sure everyone agrees.

On 2022-08-21 09:08, Ido Schimmel wrote:
> On Fri, Aug 19, 2022 at 11:51:11AM +0200, netdev at kapio-technology.com 
> wrote:
>> On 2022-08-14 16:55, Ido Schimmel wrote:
>> > On Fri, Aug 12, 2022 at 02:29:48PM +0200, netdev at
kapio-technology.com
>> > wrote:
>> > > On 2022-08-11 13:28, Ido Schimmel wrote:
>> > >
>> > > > > > 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".
> 
The real issue I think is that the locked entry should mask the MAC 
address involved (as the description I gave for zero-DPV entries and 
actually also storm prevention entries ensure), so that there is no 
forwarding to the address on any port, otherwise it will allow one-way 
traffic to a host that is not trusted. Thus flooding of unknown unicast 
on a locked port should of course be disabled ('flood off'), so that 
there is no way of sending to an unauthorized silent host behind the 
locked port.

The issue with the locked entry appearing on another SW bridge port from 
where it originated, I think is more of a cosmetic bug, though I could 
be mistaken. But adding the sticky flag to locked entries ensures that 
they do not move to another port.

This of course does that instant roaming is not possible, but I think 
that the right approach is to use the ageing out of entries to allow the 
station move/roaming.

The case of unwanted traffic to a MAC behind a locked port with a locked 
entry is what I would regard as more worthy of a selftest. The sticky 
flag I know will ensure that the locked entries do not move to other 
ports, and since it is only in the bridge this can be tested (e.g. using 
'bridge fdb show dev DEV'), I think that the test would be superfluos. 
What do you think of that and my other consideration for a test?

>> 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.
>> 
>> >
>> > Fine by me, but I'm not sure everyone agrees.
I will change it in iproute2 to:
bridge link set dev DEV mab on|off

On 2022-08-21 09:08, Ido Schimmel wrote:
> 
> 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.
> "
> 

Ido, I am not so known to the selftests, so I am wondering why I don't 
see either check_err or check_fail fail, whichever I use, when I think 
they should and then they are not really checking...


         local mac=10:20:30:30:20:10


         $MZ $h1 -t udp -a $mac -b rand
         bridge fdb show dev $swp1 | grep -q "$mac vlan 1 master br0 
locked"
         check_err $? "MAB station move: no locked entry on first 
injection"

         $MZ $h2 -t udp -a $mac -b rand
         bridge fdb show dev $swp1 | grep -q "$mac vlan 1 master br0 
locked"
         check_err $? "MAB station move: locked entry did not move"

What is wrong here?

For a mv88e6xxx test I guess I can make a check to verify that this 
driver is in use?