[lkml]   [1998]   [Dec]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Generic neighbour manipulatoin
    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

    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,


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:45    [W:0.024 / U:56.124 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site