From: "Keller, Jacob E" <jacob.e.keller@intel.com>
To: "netdev@vger.kernel.org" <netdev@vger.kernel.org>
Cc: "Malek, Patryk" <patryk.malek@intel.com>,
Vlad Yasevich <vyasevic@redhat.com>
Subject: removing bridge in vlan_filtering mode requests delete of attached ports main MAC address
Date: Fri, 20 Oct 2017 17:23:22 +0000 [thread overview]
Message-ID: <02874ECE860811409154E81DA85FBB5882ACC90F@ORSMSX115.amr.corp.intel.com> (raw)
Hi,
We've run into an issue with bridges set in vlan_filtering mode. Basically, if we attach a device to a bridge which has enabled vlan_filtering, and then remove the bridge, we end up requesting the driver of the attached device to remove its own MAC HW address.
In i40e, at least, this causes the driver to actually delete such an address and then it will no longer receive any traffic.
To reproduce this:
a) brctl addbr br0
b) brctl addif br0 enp<n>
# enable vlan filtering
c) echo 1 >/sys/class/net/br0/bridge/vlan_filtering
d) brctl delbr br0
Specifically this appears to happen because of how we automatically enter static configuration for routes when vlan_filtering is enabled, and we call br_fdb_unsync_static which will clear all the routes from the fdb table for the device. See commit 2796d0c648c9 ("bridge: Automatically manage port promiscuous mode.", 2014-05-16) for more details.
This happens to include the devices own default address, which results in the bug.
I'm not sure if this is a driver bug, or if it's a bug in the bridging code.
Who would know more about this and what to do about this?
One obvious solution is to hard code the i40e device driver so that it does not actually delete the HW address from the unicast filter list. This could work, but seems to me like its papering over the problem. Is this just a known thing that drivers should be aware of? I don't really know...
An alternative solution would be to possibly ignore any fdb addresses which specifically target that port?
Any ideas?
Regards,
Jake
next reply other threads:[~2017-10-20 17:23 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-20 17:23 Keller, Jacob E [this message]
2017-10-20 18:06 removing bridge in vlan_filtering mode requests delete of attached ports main MAC address Keller, Jacob E
2017-10-26 10:21 ` Vlad Yasevich
2017-10-26 19:56 ` Keller, Jacob E
2017-10-26 20:27 ` Keller, Jacob E
2017-10-26 20:33 ` Keller, Jacob E
2017-10-27 0:21 ` Keller, Jacob E
2017-11-01 0:10 ` Keller, Jacob E
2017-11-01 0:58 ` Toshiaki Makita
2017-11-01 22:25 ` Keller, Jacob E
2017-11-02 9:22 ` Toshiaki Makita
2017-11-02 22:10 ` Keller, Jacob E
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=02874ECE860811409154E81DA85FBB5882ACC90F@ORSMSX115.amr.corp.intel.com \
--to=jacob.e.keller@intel.com \
--cc=netdev@vger.kernel.org \
--cc=patryk.malek@intel.com \
--cc=vyasevic@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).