Bug 194879

Summary:	arp_notify does not send grace ARP on ip address add
Product:	Networking	Reporter:	George Shuklin (george.shuklin)
Component:	IPV4	Assignee:	Stephen Hemminger (stephen)
Status:	RESOLVED WILL_NOT_FIX
Severity:	low	CC:	evg
Priority:	P1
Hardware:	All
OS:	Linux
Kernel Version:	4.11	Subsystem:
Regression:	No	Bisected commit-id:

Description George Shuklin 2017-03-14 11:02:21 UTC

When net.ipv4.conf.ethX.arp_notify=1 it sends grace ARP when interface changes it mac address or become up. This is good.

But it does not send grace ARP when interface getting new address (ip address add). This is bad.

If operator set net.ipv4.conf.ethX.arp_notify to 1, he really wants to have ARP probes to be send to help routers/switches and minimize unknown unicast traffic in the network. If arp_notify works in some cases and does not work in others, it cause chaos and misunderstanding.

Example of inconsistency:

sysct net.ipv4.conf.eth0 arp_notify=1
ip addr add 10.0.0.1/24 dev eth0
ip link set up dev eth0  [arp notify send]
ip addr add 10.0.0.2/24 dev eth0 [arp does not sent]
ip link set down dev eth0
ip link set up dev eth0 [arp notify send for both 10.0.0.1 and 10.0.0.2].

Suggestion: change arp_notify=1 behavior to 'send arp notify (grace ARP) on every IPv4 address change on interface of interest'.

Comment 1 George Shuklin 2017-03-14 11:03:50 UTC

Here example of userspace bug which could be prevented if this fix applied: https://bugs.launchpad.net/neutron/+bug/1672433

Comment 2 Stephen Hemminger 2017-03-14 15:33:48 UTC

Linux kernel does uses a weak binding between addresses and interfaces, plus there are other sysctl's controlling arp behavior. A patch to change current behavior when value is 1 is unlikely to be accepted. You might get a patch accepted that adds a third state (value = 2) but it would be complex since with weak host model it is not easy to do.