[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200420133111.GL785713@lunn.ch>
Date: Mon, 20 Apr 2020 15:31:11 +0200
From: Andrew Lunn <andrew@...n.ch>
To: DENG Qingfang <dqfext@...il.com>
Cc: netdev <netdev@...r.kernel.org>,
Vivien Didelot <vivien.didelot@...il.com>,
Florian Fainelli <f.fainelli@...il.com>,
Roopa Prabhu <roopa@...ulusnetworks.com>,
bridge@...ts.linux-foundation.org,
Nikolay Aleksandrov <nikolay@...ulusnetworks.com>,
Jakub Kicinski <kuba@...nel.org>,
"David S . Miller" <davem@...emloft.net>,
René van Dorst <opensource@...rst.com>
Subject: Re: [RFC PATCH net-next] net: bridge: fix client roaming from DSA
user port
> When a client moves from a hardware port (e.g. sw0p1) to a software port (wlan0)
> or another hardware port that belongs to a different switch (sw1p1),
> that MAC entry
> in sw0's MAC table should be deleted, or replaced with the CPU port as
> destination,
> by DSA. Otherwise the client is unable to talk to other hosts on sw0 because sw0
> still thinks the client is on sw0p1.
The MAC address needs to move, no argument there. But what are the
mechanisms which cause this. Is learning sufficient, or does DSA need
to take an active role?
Forget about DSA for the moment. How does this work for two normal
bridges? Is the flow of unicast packets sufficient? Does it requires a
broadcast packet from the device after it moves?
Andrew
Powered by blists - more mailing lists