From: netdev@kapio-technology.com
To: Ido Schimmel <idosch@nvidia.com>
Cc: Vladimir Oltean <olteanv@gmail.com>,
davem@davemloft.net, kuba@kernel.org, netdev@vger.kernel.org,
Andrew Lunn <andrew@lunn.ch>,
Vivien Didelot <vivien.didelot@gmail.com>,
Florian Fainelli <f.fainelli@gmail.com>,
Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>, Jiri Pirko <jiri@resnulli.us>,
Ivan Vecera <ivecera@redhat.com>, Roopa Prabhu <roopa@nvidia.com>,
Nikolay Aleksandrov <razor@blackwall.org>,
Shuah Khan <shuah@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
linux-kernel@vger.kernel.org, bridge@lists.linux-foundation.org,
linux-kselftest@vger.kernel.org
Subject: Re: [PATCH v4 net-next 3/6] drivers: net: dsa: add locked fdb entry flag to drivers
Date: Fri, 19 Aug 2022 11:51:11 +0200 [thread overview]
Message-ID: <34dd1318a878494e7ab595f8727c7d7d@kapio-technology.com> (raw)
In-Reply-To: <YvkM7UJ0SX+jkts2@shredder>
On 2022-08-14 16:55, Ido Schimmel wrote:
> On Fri, Aug 12, 2022 at 02:29:48PM +0200, netdev@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.
>> > > >
>> > >
>>
>> 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 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
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.
WARNING: multiple messages have this Message-ID (diff)
From: netdev@kapio-technology.com
To: Ido Schimmel <idosch@nvidia.com>
Cc: Ivan Vecera <ivecera@redhat.com>, Andrew Lunn <andrew@lunn.ch>,
Florian Fainelli <f.fainelli@gmail.com>,
Jiri Pirko <jiri@resnulli.us>,
Daniel Borkmann <daniel@iogearbox.net>,
netdev@vger.kernel.org, Nikolay Aleksandrov <razor@blackwall.org>,
bridge@lists.linux-foundation.org, linux-kernel@vger.kernel.org,
Vivien Didelot <vivien.didelot@gmail.com>,
Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>,
linux-kselftest@vger.kernel.org, Roopa Prabhu <roopa@nvidia.com>,
kuba@kernel.org, Vladimir Oltean <olteanv@gmail.com>,
Shuah Khan <shuah@kernel.org>,
davem@davemloft.net
Subject: Re: [Bridge] [PATCH v4 net-next 3/6] drivers: net: dsa: add locked fdb entry flag to drivers
Date: Fri, 19 Aug 2022 11:51:11 +0200 [thread overview]
Message-ID: <34dd1318a878494e7ab595f8727c7d7d@kapio-technology.com> (raw)
In-Reply-To: <YvkM7UJ0SX+jkts2@shredder>
On 2022-08-14 16:55, Ido Schimmel wrote:
> On Fri, Aug 12, 2022 at 02:29:48PM +0200, netdev@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.
>> > > >
>> > >
>>
>> 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 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
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.
next prev parent reply other threads:[~2022-08-19 12:19 UTC|newest]
Thread overview: 84+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-12 12:29 [PATCH v4 net-next 3/6] drivers: net: dsa: add locked fdb entry flag to drivers netdev
2022-08-12 12:29 ` [Bridge] " netdev
2022-08-14 14:55 ` Ido Schimmel
2022-08-14 14:55 ` [Bridge] " Ido Schimmel
2022-08-19 9:51 ` netdev [this message]
2022-08-19 9:51 ` netdev
2022-08-21 7:08 ` Ido Schimmel
2022-08-21 7:08 ` [Bridge] " Ido Schimmel
2022-08-21 13:43 ` netdev
2022-08-21 13:43 ` [Bridge] " netdev
2022-08-22 5:40 ` Ido Schimmel
2022-08-22 5:40 ` [Bridge] " Ido Schimmel
2022-08-22 7:49 ` netdev
2022-08-22 7:49 ` [Bridge] " netdev
2022-08-23 6:48 ` Ido Schimmel
2022-08-23 6:48 ` [Bridge] " Ido Schimmel
2022-08-23 7:13 ` netdev
2022-08-23 7:13 ` [Bridge] " netdev
2022-08-23 7:24 ` Ido Schimmel
2022-08-23 7:24 ` [Bridge] " Ido Schimmel
2022-08-23 7:37 ` netdev
2022-08-23 7:37 ` [Bridge] " netdev
2022-08-23 12:36 ` Ido Schimmel
2022-08-23 12:36 ` [Bridge] " Ido Schimmel
2022-08-24 7:07 ` netdev
2022-08-24 7:07 ` [Bridge] " netdev
2022-08-23 11:41 ` netdev
2022-08-23 11:41 ` [Bridge] " netdev
2022-08-25 9:36 ` Ido Schimmel
2022-08-25 9:36 ` [Bridge] " Ido Schimmel
2022-08-25 10:28 ` netdev
2022-08-25 10:28 ` [Bridge] " netdev
2022-08-25 15:14 ` netdev
2022-08-25 15:14 ` [Bridge] " netdev
2022-08-24 20:29 ` netdev
2022-08-24 20:29 ` [Bridge] " netdev
2022-08-25 9:23 ` Ido Schimmel
2022-08-25 9:23 ` [Bridge] " Ido Schimmel
2022-08-25 10:27 ` netdev
2022-08-25 10:27 ` [Bridge] " netdev
2022-08-25 11:58 ` Ido Schimmel
2022-08-25 11:58 ` [Bridge] " Ido Schimmel
2022-08-25 13:41 ` netdev
2022-08-25 13:41 ` [Bridge] " netdev
-- strict thread matches above, loose matches on Subject: below --
2022-07-07 15:29 [PATCH v4 net-next 0/6] Extend locked port feature with FDB locked flag (MAC-Auth/MAB) Hans Schultz
2022-07-07 15:29 ` [PATCH v4 net-next 3/6] drivers: net: dsa: add locked fdb entry flag to drivers Hans Schultz
2022-07-08 7:12 ` kernel test robot
2022-07-08 8:49 ` Vladimir Oltean
2022-07-08 9:06 ` netdev
2022-07-08 9:15 ` Vladimir Oltean
2022-07-08 9:27 ` netdev
2022-07-08 9:50 ` netdev
2022-07-08 11:56 ` Vladimir Oltean
2022-07-08 12:34 ` netdev
2022-07-10 8:35 ` Ido Schimmel
2022-07-13 7:09 ` netdev
2022-07-13 12:39 ` Ido Schimmel
2022-07-17 12:21 ` netdev
2022-07-17 12:57 ` Vladimir Oltean
2022-07-17 13:09 ` netdev
2022-07-17 13:59 ` Vladimir Oltean
2022-07-17 14:57 ` netdev
2022-07-17 15:08 ` Vladimir Oltean
2022-07-17 16:10 ` netdev
2022-07-21 11:54 ` Vladimir Oltean
2022-07-17 15:20 ` Ido Schimmel
2022-07-17 15:53 ` netdev
2022-07-21 11:59 ` Vladimir Oltean
2022-07-21 13:27 ` Ido Schimmel
2022-07-21 14:20 ` Vladimir Oltean
2022-07-24 11:10 ` Ido Schimmel
2022-08-01 11:57 ` netdev
2022-08-01 13:14 ` netdev
2022-08-02 12:54 ` netdev
2022-08-01 15:33 ` netdev
2022-08-09 9:20 ` Ido Schimmel
2022-08-09 20:00 ` netdev
2022-08-10 7:21 ` Ido Schimmel
2022-08-10 8:40 ` netdev
2022-08-11 11:28 ` Ido Schimmel
2022-08-12 15:33 ` netdev
2022-08-16 7:51 ` netdev
2022-08-17 6:21 ` Ido Schimmel
2022-07-21 11:51 ` Vladimir Oltean
2022-07-08 20:39 ` kernel test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=34dd1318a878494e7ab595f8727c7d7d@kapio-technology.com \
--to=netdev@kapio-technology.com \
--cc=andrew@lunn.ch \
--cc=bridge@lists.linux-foundation.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=f.fainelli@gmail.com \
--cc=idosch@nvidia.com \
--cc=ivecera@redhat.com \
--cc=jiri@resnulli.us \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=pabeni@redhat.com \
--cc=razor@blackwall.org \
--cc=roopa@nvidia.com \
--cc=shuah@kernel.org \
--cc=vivien.didelot@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.