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

On Tue, Jan 21, 2025 at 04:32:30PM -0800, Jay Vosburgh wrote:
> Hangbin Liu <liuhangbin@gmail.com> wrote:
> >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.

Ah, yes. I need to read carefully.

> 
> >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.

Thanks for your explanation.
> 
> 	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.

OK, I will try add a warning for this issue.

Thanks
Hangbin

      reply	other threads:[~2025-01-22  1:50 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
2025-01-22  1:50   ` Hangbin Liu [this message]

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=Z5BO57CBUEL6gRUX@fedora \
    --to=liuhangbin@gmail.com \
    --cc=jv@jvosburgh.net \
    --cc=liali@redhat.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.