On Thu, Dec 21, 2023 at 10:35:45AM -0600, Chris Adams wrote:
> Once upon a time, Beniamino Galvani <bgalvani@xxxxxxxxxx> 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
Attachment:
signature.asc
Description: PGP signature
-- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
