netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jay Vosburgh <jv@jvosburgh.net>
To: Hangbin Liu <liuhangbin@gmail.com>
Cc: netdev@vger.kernel.org
Subject: Re: [Question]: should we consider arp missed max during bond_ab_arp_probe()?
Date: Thu, 07 Nov 2024 17:32:29 -0800	[thread overview]
Message-ID: <316685.1731029549@famine> (raw)
In-Reply-To: <ZysdRHul2pWy44Rh@fedora>

Hangbin Liu <liuhangbin@gmail.com> wrote:

>Hi Jay,
>
>Our QE reported that, when there is no active slave during
>bond_ab_arp_probe(), the slaves send the arp probe message one by one. This
>will flap the switch's mac table quickly, sometimes even make the switch stop
>learning mac address. So should we consider the arp missed max during
>bond_ab_arp_probe()? i.e. each slave has more chances to send probe messages
>before switch to another slave. What do you think?

	Well, "quickly" here depends entirely on what the value of
arp_interval is.  It's been quite a while since I looked into the
details of this particular behavior, but at the time I didn't see the
switches I had issue flap warnings.  If memory serves, I usually tested
with arp_interval in the realm of 100ms, with anywhere from 2 to 6
interfaces in the bond.

	What settings are you using for the bond, and what model of
switch exhibits the behavior you describe?

	That said, the intent of the current implementation is to cycle
through the interfaces in the bond relatively quickly when no interfaces
are up, under the theory that such behavior finds an available interface
in the minimum time.

	I'm not necessarily opposed to having each probe "step," so to
speak, perform multiple ARP probe checks.  However, I wonder if this is
a complicated workaround for not wanting to change a configuration
setting on a switch, and it would only make things better by chance
(i.e., that the probes just happen to now take long enough to not run
afoul of the switch's time limit for some flap parameter).

	-J

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

  parent reply	other threads:[~2024-11-08  1:32 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-06  7:39 [Question]: should we consider arp missed max during bond_ab_arp_probe()? Hangbin Liu
2024-11-06  8:34 ` Jiri Pirko
2024-11-06  9:25   ` Hangbin Liu
2024-11-06 14:40     ` Jiri Pirko
2024-11-07  1:21       ` Hangbin Liu
2024-11-07  1:21       ` Jakub Kicinski
2024-11-08  1:32 ` Jay Vosburgh [this message]
2024-11-08  2:51   ` 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=316685.1731029549@famine \
    --to=jv@jvosburgh.net \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).