All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jay Vosburgh <jv@jvosburgh.net>
To: Hangbin Liu <liuhangbin@gmail.com>
Cc: netdev@vger.kernel.org, Liang Li <liali@redhat.com>
Subject: Re: [Question] Bonding: change bond dev_addr when fail_over_mac=2
Date: Tue, 21 Jan 2025 16:32:30 -0800	[thread overview]
Message-ID: <3990673.1737505950@famine> (raw)
In-Reply-To: <Z49yXz1dx2ZzqhC1@fedora>

Hangbin Liu <liuhangbin@gmail.com> wrote:

>Hi Jay,
>
>Our QE reported that, when setup bonding with fail_over_mac=2. Then release
>the first enslaved device. The bond and other slave's mac address with
>conflicts with the release device. e.g.
>
># modprobe bonding mode=1 miimon=100 max_bonds=1 fail_over_mac=2
># ip link set bond0 up
># ifenslave bond0 eth0 eth1
># ifenslave -d bond0 eth0
>
>Then we can see the bond0 and eth1 both still using eth0's address.
>
>I saw in __bond_release_one() we have 
>
>        if (!all && (!bond->params.fail_over_mac ||
>                     BOND_MODE(bond) != BOND_MODE_ACTIVEBACKUP)) {
>                if (ether_addr_equal_64bits(bond_dev->dev_addr, slave->perm_hwaddr) &&
>                    bond_has_slaves(bond))
>                        slave_warn(bond_dev, slave_dev, "the permanent HWaddr of slave - %pM - is still in use by bond - set the HWaddr of slave to a different address to avoid conflicts\n",
>                                   slave->perm_hwaddr);
>        }

	If I'm reading it right, I don't think the above will trigger
the message for your example, as "!bond->params.fail_over_mac" and
"BOND_MODE(bond) != BOND_MODE_ACTIVEBACKUP" are both false.

>So why not just change the bond_dev->dev_addr to another slave's perm_hwaddr
>instead of keep using the released one?

	That would cause the MAC of the bond itself to change without
user intervention, and the active-backup mode won't change the bond's
MAC except for the case of fail_over_mac=1.  It's not uncommon for the
network to have dependencies on the MAC address itself, e.g., MAC based
permission rules.  There's also an cost associated with changing the
MAC, requiring a gratuitous ARP and some propagation time.

	What you describe is also the behavior for active-backup with
fail_over_mac=0, in that the bond will keep using the MAC gleaned from
the first interface even if that interface is removed from the bond, so
it's not really something specific to fail_over_mac=2.

	I don't think bonding should automatically adopt a new MAC
address in this case, but loosening the logic on the warning message
would be ok.

	-J

---
	-Jay Vosburgh, jv@jvosburgh.net

  reply	other threads:[~2025-01-22  0:32 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-21 10:09 [Question] Bonding: change bond dev_addr when fail_over_mac=2 Hangbin Liu
2025-01-22  0:32 ` Jay Vosburgh [this message]
2025-01-22  1:50   ` Hangbin Liu

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=3990673.1737505950@famine \
    --to=jv@jvosburgh.net \
    --cc=liali@redhat.com \
    --cc=liuhangbin@gmail.com \
    --cc=netdev@vger.kernel.org \
    /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.