From: Andrew Lunn <andrew@lunn.ch>
To: DENG Qingfang <dqfext@gmail.com>
Cc: "Florian Fainelli" <f.fainelli@gmail.com>,
"Nikolay Aleksandrov" <nikolay@cumulusnetworks.com>,
netdev <netdev@vger.kernel.org>,
"Roopa Prabhu" <roopa@cumulusnetworks.com>,
bridge@lists.linux-foundation.org,
"David S . Miller" <davem@davemloft.net>,
"René van Dorst" <opensource@vdorst.com>,
"Jakub Kicinski" <kuba@kernel.org>,
"Vivien Didelot" <vivien.didelot@gmail.com>
Subject: Re: [Bridge] [RFC PATCH net-next] net: bridge: fix client roaming from DSA user port
Date: Mon, 20 Apr 2020 15:31:11 +0200 [thread overview]
Message-ID: <20200420133111.GL785713@lunn.ch> (raw)
In-Reply-To: <CALW65jYmcZJoP_i5=bgeWpcibzOmEPne3mHyBngE5bTiOZreDw@mail.gmail.com>
> 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
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Lunn <andrew@lunn.ch>
To: DENG Qingfang <dqfext@gmail.com>
Cc: netdev <netdev@vger.kernel.org>,
"Vivien Didelot" <vivien.didelot@gmail.com>,
"Florian Fainelli" <f.fainelli@gmail.com>,
"Roopa Prabhu" <roopa@cumulusnetworks.com>,
bridge@lists.linux-foundation.org,
"Nikolay Aleksandrov" <nikolay@cumulusnetworks.com>,
"Jakub Kicinski" <kuba@kernel.org>,
"David S . Miller" <davem@davemloft.net>,
"René van Dorst" <opensource@vdorst.com>
Subject: Re: [RFC PATCH net-next] net: bridge: fix client roaming from DSA user port
Date: Mon, 20 Apr 2020 15:31:11 +0200 [thread overview]
Message-ID: <20200420133111.GL785713@lunn.ch> (raw)
In-Reply-To: <CALW65jYmcZJoP_i5=bgeWpcibzOmEPne3mHyBngE5bTiOZreDw@mail.gmail.com>
> 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
next prev parent reply other threads:[~2020-04-20 13:31 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-19 16:19 [RFC PATCH net-next] net: bridge: fix client roaming from DSA user port DENG Qingfang
2020-04-19 16:19 ` [Bridge] " DENG Qingfang
2020-04-19 16:42 ` Andrew Lunn
2020-04-19 16:42 ` Andrew Lunn
2020-04-20 4:03 ` DENG Qingfang
2020-04-20 4:03 ` [Bridge] " DENG Qingfang
2020-04-20 13:31 ` Andrew Lunn [this message]
2020-04-20 13:31 ` Andrew Lunn
2020-04-22 6:01 ` Chuanhong Guo
2020-04-22 6:01 ` [Bridge] " Chuanhong Guo
2020-04-23 21:36 ` Andrew Lunn
2020-04-23 21:36 ` Andrew Lunn
2020-12-18 14:54 ` [Bridge] " Eric Woudstra
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=20200420133111.GL785713@lunn.ch \
--to=andrew@lunn.ch \
--cc=bridge@lists.linux-foundation.org \
--cc=davem@davemloft.net \
--cc=dqfext@gmail.com \
--cc=f.fainelli@gmail.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=nikolay@cumulusnetworks.com \
--cc=opensource@vdorst.com \
--cc=roopa@cumulusnetworks.com \
--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.