From: Hannes Frederic Sowa <hannes@stressinduktion.org>
To: Salam Noureddine <noureddine@aristanetworks.com>
Cc: "David S. Miller" <davem@davemloft.net>,
Daniel Borkmann <dborkman@redhat.com>,
Willem de Bruijn <willemb@google.com>, Phil Sutter <phil@nwl.cc>,
Eric Dumazet <edumazet@google.com>,
netdev@vger.kernel.org
Subject: Re: Issue with gratuitous arps when new addr is different from cached addr
Date: Thu, 21 Nov 2013 07:23:49 +0100 [thread overview]
Message-ID: <20131121062349.GC4347@order.stressinduktion.org> (raw)
In-Reply-To: <CAO7SqHC4astdejH6wVAyjsVeuh96T8P3ao3bCDNs=opfv5bbUg@mail.gmail.com>
On Wed, Nov 20, 2013 at 10:06:34PM -0800, Salam Noureddine wrote:
> Isn't locktime useful in that case for limiting the rate of garp
> changes to the arp cache?
Yes, as I said, it would be nice to have rate-limiting for those, too.
GARP is used in cluster setups to make the switch-over as fast as possible and
I don't think they accept those lock-down delays, so I guess it would be nice
to forceful override the lladdr if (sip == tip) && ACCEPT_ARP(dev) is true in
every case.
I guess you are not testing with ACCEPT_ARP?
In that case I am not sure what to do.
override = (...timing...) || sip == tip; could work but does relax the
protection of the neigh cache.
In IPv6 we have a flag in the packet if we should overwrite the entry.
I'll have to think about that a bit more. Could well be the case that we need
your proposal, too. But then we would have to validate the change with IPv6,
too and neighbour cache states are really complex.
Greetings,
Hannes
next prev parent reply other threads:[~2013-11-21 6:23 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-21 0:40 Issue with gratuitous arps when new addr is different from cached addr Salam Noureddine
2013-11-21 4:40 ` Hannes Frederic Sowa
2013-11-21 6:06 ` Salam Noureddine
2013-11-21 6:23 ` Hannes Frederic Sowa [this message]
2013-11-21 6:26 ` Hannes Frederic Sowa
2013-11-21 6:33 ` Salam Noureddine
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=20131121062349.GC4347@order.stressinduktion.org \
--to=hannes@stressinduktion.org \
--cc=davem@davemloft.net \
--cc=dborkman@redhat.com \
--cc=edumazet@google.com \
--cc=netdev@vger.kernel.org \
--cc=noureddine@aristanetworks.com \
--cc=phil@nwl.cc \
--cc=willemb@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox