From: "Keller, Jacob E" <jacob.e.keller@intel.com>
To: "vyasevic@redhat.com" <vyasevic@redhat.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Cc: "Malek, Patryk" <patryk.malek@intel.com>
Subject: RE: removing bridge in vlan_filtering mode requests delete of attached ports main MAC address
Date: Thu, 26 Oct 2017 19:56:31 +0000 [thread overview]
Message-ID: <02874ECE860811409154E81DA85FBB5882AD0DDE@ORSMSX115.amr.corp.intel.com> (raw)
In-Reply-To: <e48172b8-52ec-a9e8-c720-d9da69d8ced7@redhat.com>
> -----Original Message-----
> From: Vlad Yasevich [mailto:vyasevic@redhat.com]
> Sent: Thursday, October 26, 2017 3:22 AM
> To: Keller, Jacob E <jacob.e.keller@intel.com>; netdev@vger.kernel.org
> Cc: Malek, Patryk <patryk.malek@intel.com>
> Subject: Re: removing bridge in vlan_filtering mode requests delete of attached
> ports main MAC address
>
> On 10/20/2017 08:06 PM, Keller, Jacob E wrote:
> >> -----Original Message-----
> >> From: Keller, Jacob E
> >> Sent: Friday, October 20, 2017 10:23 AM
> >> To: 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
> >>
> >> 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?
> >
> > For the record, adding a check to prevent unsync_static from removing
> addresses which are targetting the specific port does work to resolve this specific
> issue, but I'm sure it's not the correct solution as I expect that would cause other
> problems.
> >
>
> Hi Jake
>
> I think adding a !fdb->local should work. local fdb contain the address of assigned
> to
> the ports of the bridge and those shouldn't be directly removed.
>
> If that works, that looks like the right solution.
>
> -vlad
>
I'll give this a shot, and if so, cook up a patch.
Thanks,
Jake
> > Thanks,
> > Jake
> >
> >>
> >> Regards,
> >> Jake
next prev parent reply other threads:[~2017-10-26 19:56 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
-- strict thread matches above, loose matches on Subject: below --
2017-10-20 17:23 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=02874ECE860811409154E81DA85FBB5882AD0DDE@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).