netdev - Re: Bonding MAC failover behavior with VLAN interfaces

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 12 Feb 2016 12:58:44 -0800
From:	Jay Vosburgh <jay.vosburgh@...onical.com>
To:	John Valko <jovalko@...co.com>
cc:	netdev@...r.kernel.org, "Dwight Frye (dfrye)" <dfrye@...co.com>,
	Wally Dixon <wdixon@...co.com>,
	"Leo Lee (lelee2)" <lelee2@...co.com>,
	"Nishant Thakre (nthakre)" <nthakre@...co.com>,
	"Parvez Shaikh (pshaikh)" <pshaikh@...co.com>
Subject: Re: Bonding MAC failover behavior with VLAN interfaces

John Valko <jovalko@...co.com> wrote:

>Hi all,
>
>I have observed the following on CentOS 6 using the
>2.6.32-573.8.1.el6.x86_64 kernel as well as Ubuntu 15.10 with
>4.2.0-25-generic.. I have not yet tried with a vanilla kernel but with the
>large time/distro gap it didn't seem likely to be caused by distro
>changes.

[ ...example of VLAN-over-bond's MAC not changing when bonding
fail_over_mac=active has a failover... ]

>So, herein lies my confusion.  I expect that the VLAN interfaces should
>also pick up the new MAC address, but they don't.  It seems like a bug to
>me, but I don't want to be presumptuous so if in fact this is expected
>behavior, how do you recommend we approach making it switch when the bond
>fails over?  Right now, the MAC must be manually set for each vlan
>interface.
[...]
>I can see it set the mac of the bond to the new active slave MAC, but I
>don't see any indication of looping over vlan interfaces or anything, if
>that is expected... or would it be expected that the 8021q module receives
>an event that should make it change?

	Your observation is correct: the fail_over_mac functionality
does not propagate beyond the bonding master device itself.  The
presumption at the VLAN level is that the underlying device can support
multiple MAC addresses; this same effect (different MACs between VLAN
and its lower device) occurs if the device logically below a VLAN
interface changes its MAC.  This is handled by vlan_sync_address, which
is called via the NETDEV_CHANGEADDR notifier (which happens when the
bonding master changes its MAC due to f_o_m=active).

	The original need for f_o_m=active was IPoIB devices that cannot
change their MAC address.  Those don't support VLANs, either, so
propagation to VLANs was not a consideration.

	In your "real" SR-IOV sitation, is there something that
necessitates the use of fail_over_mac=active (I don't recall that SR-IOV
itself prohibits a VF from changing its MAC address), or is this being
done for other reasons?

	-J

---
	-Jay Vosburgh, jay.vosburgh@...onical.com