Re: probe netlink app in NUD_PROBE

[David Miller <davem@davemloft.net>]

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.

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