From: Jay Vosburgh <jay.vosburgh@canonical.com>
To: John Valko <jovalko@cisco.com>
Cc: netdev@vger.kernel.org, "Dwight Frye (dfrye)" <dfrye@cisco.com>,
Wally Dixon <wdixon@cisco.com>,
"Leo Lee (lelee2)" <lelee2@cisco.com>,
"Nishant Thakre (nthakre)" <nthakre@cisco.com>,
"Parvez Shaikh (pshaikh)" <pshaikh@cisco.com>
Subject: Re: Bonding MAC failover behavior with VLAN interfaces
Date: Fri, 12 Feb 2016 12:58:44 -0800 [thread overview]
Message-ID: <12288.1455310724@famine> (raw)
In-Reply-To: <56BAA15F.4080609@cisco.com>
John Valko <jovalko@cisco.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@canonical.com
next prev parent reply other threads:[~2016-02-12 20:58 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-10 2:33 Bonding MAC failover behavior with VLAN interfaces John Valko
2016-02-12 20:58 ` Jay Vosburgh [this message]
2016-02-13 23:28 ` John Valko
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=12288.1455310724@famine \
--to=jay.vosburgh@canonical.com \
--cc=dfrye@cisco.com \
--cc=jovalko@cisco.com \
--cc=lelee2@cisco.com \
--cc=netdev@vger.kernel.org \
--cc=nthakre@cisco.com \
--cc=pshaikh@cisco.com \
--cc=wdixon@cisco.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.