On Thu, Dec 21, 2023 at 10:35:45AM -0600, Chris Adams wrote:
Once upon a time, Beniamino Galvani bgalvani@redhat.com said:
network-scripts do [1]:
/sbin/arping -c 2 -w ${ARPING_WAIT:-3} -D -I ${REALDEVICE} ${ipaddr[$idx]}
which waits 2 seconds by default.
Ahh, sorry, that's what I get for depending on memory. :)
In the original RFC, the duration of the ACD process is between 4 and 7 seconds (depending on randomization), which is clearly too long on modern hardware.
Definitely agree.
In the Fedora change proposal, the default ACD interval in NM is set to up to 3 seconds and is subject to the same randomization; in practice it would be between ~1.7 and 3 seconds. Perhaps that's still too much, and we can safely decrease it to e.g. 1 second max to reduce the activation delay.
Yeah, I think sending 2-3 requests separated by maybe 0.2 seconds, and waiting another 0.2 seconds for a reply (so a total of 0.8 seconds) is sufficient for modern networks.
Right, by setting a maximum duration of e.g. 0.8 seconds, we get 3 probes spaced between 90ms and 270ms and a final wait time of 180ms, according to the algorithm from RFC 5227.
A number of DHCP servers do a ping before issue as well (although there's no good way for a DHCP client to tell), so it's just adding to the amount of time before the network becomes usable.
DAD/ACD is a good thing, I'd just like to see the impact minimized. The time taken at boot is not a big deal (as users have to log in and start applications and such), but the time taken on resume from sleep is more noticable (open the notebook lid, unlock, then... wait).
Thinking about servers... this would happen before network-online.target is triggered, right? Any services that try to bind to configured IPs or the like need to still work.
The short answer is: enabling ACD will not affect services that bind to configured IPs, because ACD is done before the connection becomes activated, which is a pre-requisite for network-online.target.
In practice, it's a bit more complex than that. network-online.target is emitted after all NM connections succeed. The meaning of "success" depends on properties "ipv4.may-fail" and "ipv6.may-fail" of the connection profile. Normally they are both set to "yes" and this means that just one of IPv4 and IPv6 is enough to reach the activated state.
If the connection has static IPv4 addresses and "auto" IPv6 (i.e. SLAAC plus optionally DHCPv6), before enabling ACD it was guaranteed that IPv4 addresses were added before reaching network-online. After enabling ACD, both IPv4 ACD and IPv6 SLAAC are started in parallel and the first that completes will make the connection succeed. However, in practice IPv6 also requires DAD and the timeout is longer than the IPv4 ACD timeout; so, services that bind to static IPv4 addresses can still rely on the addresses being present after network-online.target is reached.
Of course, in case of services that bind IPv4 to addresses, the best solution is to set "ipv4.may-fail=no" (or for IPv6 addresses, "ipv6.may-fail=no") in the connection profile. That is required when using "auto" methods, in order to avoid the situation where the connection succeeds after the "other" address family completes.
Beniamino