Message-ID: <02874ECE860811409154E81DA85FBB5882AD0E1A@ORSMSX115.amr.corp.intel.com>
Date:   Thu, 26 Oct 2017 20:27:13 +0000
From:   "Keller, Jacob E" <jacob.e.keller@...el.com>
To:     "vyasevic@...hat.com" <vyasevic@...hat.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
CC:     "Malek, Patryk" <patryk.malek@...el.com>
Subject: RE: removing bridge in vlan_filtering mode requests delete of
 attached ports main MAC address

> -----Original Message-----
> From: Vlad Yasevich [mailto:vyasevic@...hat.com]
> Sent: Thursday, October 26, 2017 3:22 AM
> To: Keller, Jacob E <jacob.e.keller@...el.com>; netdev@...r.kernel.org
> Cc: Malek, Patryk <patryk.malek@...el.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@...r.kernel.org
> >> Cc: Malek, Patryk <patryk.malek@...el.com>; 'Vlad Yasevich'
> >> <vyasevic@...hat.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
> 

So this does prevent us from removing the port's address. However, if I add two devices to the bridge, then after removing the bridge, each device now keeps both permanent addresses in their list, which isn't what we want is it?

Do we even want to assign the local fdb addresses to every port?

Obviously, I don't fully understand this code, so I think I'm missing something here.

Regards,
Jake

> > Thanks,
> > Jake
> >
> >>
> >> Regards,
> >> Jake

Powered by blists - more mailing lists