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
next prev parent 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.