On Fri, Aug 19, 2022 at 11:51:11AM +0200, netdev@xxxxxxxxxxxxxxxxxxxx wrote:
> On 2022-08-14 16:55, Ido Schimmel wrote:
> > On Fri, Aug 12, 2022 at 02:29:48PM +0200, netdev@xxxxxxxxxxxxxxxxxxxx
> > 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.
