Re: Generic neighbour manipulatoin

Andi Kleen (ak@muc.de)
Mon, 7 Dec 1998 17:38:55 +0100


In muc.lists.linux-kernel, you wrote:
>I'm sorry if this sounds a bit stupid, but I am trying to find out how the
>variables found in /proc/sys/net/neigh effect generic neighbour
>manipulation. There does not seem to be any documentation referencing to
>them. Can someone help me out to identifying what all this stuff means
>exactly?

Generally, these sysctls use IPv6 terminology, so it helps to read
RFC1970 about IPv6 neighbour discovery. 2.1 uses a lot of the IPv6
algorithms for IPv4 too. A lot of the variables here are straight
taken from RFC1970.

These variables are shared between IPv4 and IPv6 and configure both
IPv4 ARP and IPv6 neighbour discovery.

All times are in jiffies (1/100 second on the i386). This is considered
a bug.

>net/ipv4/neigh/[device, default]/locktime

An ARP/neighbour entry is only replaced with a new one if the old is at
least locktime old. This prevents ARP cache thrashing.

>net/ipv4/neigh/[device, default]/proxy_delay

Maximum time (real time is random [0..proxytime]) before answering
to an arp request for which we have an proxy arp entry. This is used
to prevent network flooding in some cases.

>net/ipv4/neigh/[device, default]/anycast_delay

Not yet implemented (Linux IPv6 has no anycast support yet).

>net/ipv4/neigh/[device, default]/proxy_qlen

Maximum queue length of the delayed proxy arp timer (see proxy_delay)

>net/ipv4/neigh/[device, default]/unres_qlen

Maximum queue length for an pending arp request - how many packets are
accepted from other layers while the arp address is still resolved.

>net/ipv4/neigh/[device, default]/gc_stale_time

How often to check for stale ARP entries. After an ARP entry is stale
it will be resolved again (useful when an IP address migrates to another
machine). When ucast_solicit is >0 it first tries to send an ARP packet
directly to the known host, when that fails and mcast_solicit is >0 an
ARP request is broadcasted.

>net/ipv4/neigh/[device, default]/delay_first_probe_time

How long to wait until a probe is sent on a stale neighbour entry (see above)

>net/ipv4/neigh/[device, default]/base_reachable_time

Base delay for the reachability checking algorithm - see RFC1970/7.3

>net/ipv4/neigh/[device, default]/retrans_time

How long to wait until an ARP request is retransmitted when there is no answer.

>net/ipv4/neigh/[device, default]/app_solicit

How many requests to send to the user level arp daemon (CONFIG_ARPD).
0 to turn off.

>net/ipv4/neigh/[device, default]/ucast_solicit

Number of unicast probes. See above.
>net/ipv4/neigh/[device, default]/mcast_solicit

Number of multicast/broadcast probes. See above.

If mcast_solicit and ucast_solicit are both 0 no ARP is done.

I hope this helps,

-Andi

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/