On Mon, Sep 23, 2024 at 05:48:53PM +0200, Philipp Kern wrote: > > > > I like ifupdown. It's simple and just works. > > > > > > I find this quite funny, given a recent discussion about IPv6 dad > > > issues with ifupdown on #debian-admin. > > > > The "discussion" was about ifup@eth0 being in a failed state on a > > particular server due to a DAD failure and someone having to manually > > intervene. > > I find my ghost being invoked here. > > > Chris, what behaviour do you expect here? Below I'm going to assume what > > you're getting at is that we should continue to retry DAD. > > > > To me going to a stable failure state seems desirable. Continuing to re-try > > for IPs could cause instability in the face of legitimate address > > conflicts: when the owning machine reboots the conflicting machine would > > now win the IP due to continous retrying. The change in owner would cause > > disruption to services entirely unrelated to the machine that was just > > rebooted. > > DAD did not fail, it timed out after 60 sleeps of 0.1, aka 6s. The kernel > subsequently succeeded to configure the network. The script in question was > added in response to [1] and [2] to have a pause during boot to give the > kernel time to resolve the situation before continuing the bootup. So it > left the race around because there's not that much it can do better as a > script-based setup without much state.
I'm not familiar with the discussion on #debian-admin, so the details may be different, but I can point to a specific use case where we want DAD/SLAAC failure handled without marking the interface as failed. The cloud team wanted to produce working images that would support both IPv4-only and dualstack environments transparently, without knowing the type of environment in advance or requiring admin intervention. [1] We ended up coming up with something that worked, but it would have been nice if ifupdown could have handled this more gracefully. [2] We have since transitioned to systemd-networkd and netplan; bullseye is the last generation of cloud images to use ifupdown. Although the above issue certainly contributed to this decision, the primary driver for the netplan change was the cloud-init integration. noah 1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804396#17 2. https://salsa.debian.org/cloud-team/debian-cloud-images/-/tree/master/config_space/bullseye/files/etc/network
