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
