]> CyberLeo.Net >> Repos - FreeBSD/stable/10.git/commit
MFC r306577 r306652 306830
authorvangyzen <vangyzen@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f>
Wed, 30 Nov 2016 22:20:23 +0000 (22:20 +0000)
committervangyzen <vangyzen@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f>
Wed, 30 Nov 2016 22:20:23 +0000 (22:20 +0000)
commit56c6da38b49fc0da56e1ab8898c05be5ad06dad9
tree4eec1aed20764cb246ce808d6e1a08af843faef6
parent9d3970a679de8116f17fe486791e041afacbede2
MFC r306577 r306652 306830

Add GARP retransmit capability

A single gratuitous ARP (GARP) is always transmitted when an IPv4
address is added to an interface, and that is usually sufficient.
However, in some circumstances, such as when a shared address is
passed between cluster nodes, this single GARP may occasionally be
dropped or lost.  This can lead to neighbors on the network link
working with a stale ARP cache and sending packets destined for
that address to the node that previously owned the address, which
may not respond.

To avoid this situation, GARP retransmissions can be enabled by setting
the net.link.ether.inet.garp_rexmit_count sysctl to a value greater
than zero.  The setting represents the maximum number of retransmissions.
The interval between retransmissions is calculated using an exponential
backoff algorithm, doubling each time, so the retransmission intervals
are: {1, 2, 4, 8, 16, ...} (seconds).

Due to the exponential backoff algorithm used for the interval
between GARP retransmissions, the maximum number of retransmissions
is limited to 16 for sanity.  This limit corresponds to a maximum
interval between retransmissions of 2^16 seconds ~= 18 hours.
Increasing this limit is possible, but sending out GARPs spaced
days apart would be of little use.

Update arp(4) to document the net.link.ether.inet.garp_rexmit_count sysctl.

Submitted by: dab
Relnotes: yes
Sponsored by: Dell EMC

git-svn-id: svn://svn.freebsd.org/base/stable/10@309340 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
sys/netinet/if_ether.c
sys/netinet/in.c
sys/netinet/in_var.h
usr.sbin/arp/arp.4