On Tue, Aug 09, 2016 at 04:51:04PM -0700, Jay Vosburgh wrote: > > This will cause balance-rr to add the slave to the bond if any > device's dev_set_mac_address call fails. > > If a bond of regular Ethernet devices is connected to a static > link aggregation (Etherchannel channel group), a set_mac failure would > result in that slave having a different MAC address than the bond, which > in turn would cause traffic inbound from the switch to that slave to be > dropped (as the destination MAC would not pass the device MAC filters). > > The failure check for the set_mac call serves a legitimate > purpose, and I don't believe we should bypass it without making the > bypass an option that is explicitly enabled for those special cases that > need it. > > E.g., something like the following (which I have not tested); > this would also need documentation and iproute2 updates to go with it. > This would be enabled with "fail_over_mac=keepmac".
Thank you! Tested-by: Jörn Engel <jo...@purestorage.com> Having to set one more parameter is a bit annoying. It would have to be documented in a prominent place and people would still often miss it. So I wonder if we can make the interface a little nicer. Options: - If there are no slaves yet and the first slave added is tun, we trust the users to know what they are doing. Automatically set bond->params.fail_over_mac = BOND_FOM_KEEPMAC Maybe do a printk to inform the user in case of a mistake. - If we get an error and the slave device is tun, do a printk giving the user enough information to find this parameter. I'm leaning towards the former, but you probably know a reason why I am wrong again. Jörn -- For a successful technology, reality must take precedence over public relations, for nature cannot be fooled. -- Richard Feynman
