From: Timo Teras <timo.teras@iki•fi>
To: David Miller <davem@davemloft•net>
Cc: netdev@vger•kernel.org
Subject: Re: probe netlink app in NUD_PROBE
Date: Wed, 26 Feb 2014 08:28:14 +0200 [thread overview]
Message-ID: <20140226082814.00289828@vostro> (raw)
In-Reply-To: <20140225.181844.1715731388552960836.davem@davemloft.net>
On Tue, 25 Feb 2014 18:18:44 -0500 (EST)
David Miller <davem@davemloft•net> wrote:
> From: Timo Teras <timo.teras@iki•fi>
> Date: Sat, 22 Feb 2014 10:44:19 +0200
>
> > When a stale or delayed neigh entry is being re-validated the entry
> > goes to NUD_PROBE state. At the moment only unicast probes are sent.
> > This is basically because neigh_max_probes() limits the probe
> > amount so.
> >
> > Now, opennhrp intentionally configures UCAST_PROBES and
> > MCAST_PROBES to zero and APP_PROBES to something meaningful. The
> > idea is that opennhrp replaces arp completely with NHRP implemented
> > in userland.
> >
> > Due to this it seems there is a very small time window, when the
> > NUD_PROBE times out and the neighbour entry gets invalidated, and
> > packets get lost.
> >
> > To remedy this, I would like to have these NUD_PROBE validations
> > sent via netlink too.
> >
> > First choice is to change to just use both unicast and application
> > probes:
>
> So basically, the generic and protocol-specific neighbour code work
> together to implement a cascading priority based probing scheme using
> a per-neigh counter and three limits.
>
> It seems that neigh->probes is zero when we enter the probing state.
>
> On each solicit we increment neigh->probes.
>
> Then we have this very funny logic in the protocol specific
> implementations of solicit:
>
> probes = atomic_read(&neigh->probes);
>
> probes -= UCAST_PROBES;
> if (probes < 0) {
> send unicast probe;
> } else {
> probes -= APP_PROBES;
> if (probes < 0) {
> trigger application based probe via netlink
> } else {
> send multicast probe;
> }
> }
>
> As an example, for ipv4 arp, UCAST_PROBES defaults to 3 and APP_PROBES
> defaults (as you say) to zero.
Right, the idea is that on NUD_INVALID it does sequence of:
UCAST_PROBES protocol specific unicasts
APP_PROBE netlink requeusts
MCAST_PROBES protocol specific multicasts
And in NUD_PROBE currently only the unicast probes.
> If neigh_max_probes() evaluates to UCAST_PROBES, we'll do 3 unicast
> probes then fail the neigh, for example.
>
> I took a look at iproute2's arpd, and I suggest you take a gander
> over there as well.
>
> If given the '-a N' option it will set app_probes to N and send it's
> own ARP requests out in certain situations.
>
> It might depend upon the current behavior of neigh_max_probes().
In fact, it seems that the arpd is expecting to get app probe in
NUD_PROBE. There's code like:
if (ndm->ndm_state&NUD_PROBE) {
/* If we get this, kernel still has some valid
* address, but unicast probing failed and host
* is either dead or changed its mac address.
* Kernel is going to initiate broadcast resolution.
* OK, we invalidate our information as well.
*/
if (dbdat.data && !IS_NEG(dbdat.data))
stats.app_neg++;
dbase->del(dbase, &dbkey, 0);
On the other hand opennhrp, needs the NUD_PROBE app queries to confirm
the existing entries, as opennhrp intentionally turns UCAST_PROBES to
zero.
So I'll submit the first variant soon, where app probes are added to be
done for NUD_PROBE.
- Timo
next prev parent reply other threads:[~2014-02-26 6:27 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-22 8:44 probe netlink app in NUD_PROBE Timo Teras
2014-02-25 23:18 ` David Miller
2014-02-26 6:28 ` Timo Teras [this message]
2014-02-26 9:43 ` [PATCH net-next] neigh: probe application via netlink " Timo Teräs
2014-02-26 20:47 ` David Miller
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=20140226082814.00289828@vostro \
--to=timo.teras@iki$(echo .)fi \
--cc=davem@davemloft$(echo .)net \
--cc=netdev@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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