Change address on every DHCP renewal
Change address on every DHCP renewal
Posted Aug 26, 2025 17:52 UTC (Tue) by NYKevin (subscriber, #129325)In reply to: Change address on every DHCP renewal by farnz
Parent article: Linux's missing CRL infrastructure
For devices used by humans (workstations, phones, etc.): Configure this to happen at ~4 AM local time, and very few people will care. In the event that you do need some humans working those hours (e.g. at hospitals), use the next solution instead, or schedule those humans' devices to force a re-discover at a different time (if feasible).
For devices that are serving traffic, or otherwise cannot suffer a total site outage all at once: Spread the DHCPNAKs over several hours during your daily trough (the period when usage is lowest every day), such that you lose no more than one device every few minutes or so. If your error budget does not allow for this, then only flip over a fraction of all devices every day (preferably, split the devices into stable cohorts so that every device is flipped once every few days). If you do not have an error budget, then on paper, your requirements are not compatible with doing this at all (see next item). You should consider whether or not you really intend to provide that level of availability, and for that matter whether you have the necessary resources to do so.
For devices that absolutely, positively must not go down under any circumstances: Obviously, you cannot do this at all, because even the tiniest blip is a catastrophic failure, under this standard of availability. Instead, you should be hardening the network so that it does not go down (e.g. put the router on a UPS, get multiple discontiguous fiber links from separate ASes, etc.). Probably it's also worth the bother of configuring the device with a static address just in case, but that's almost the least important part. You may have noticed that this is extremely expensive. That's the point. "Absolutely must not go down ever" is a very high bar. You are not going to get there by clever configuration of software alone.
Posted Sep 2, 2025 14:13 UTC (Tue)
by vonbrand (subscriber, #4458)
[Link] (1 responses)
Posted Sep 3, 2025 9:05 UTC (Wed)
by farnz (subscriber, #17727)
[Link]
YouTube (and other streaming media platforms) work by stitching together a lot of small (typically 10 seconds or so) clips at the client side, and YouTube is set up so that if you download the first part of a clip, then change network, it's possible to download the rest of that clip with a range request, instead of a full redownload.
It also adapts to network conditions by using lower bitrate clips if requests are either not completing in full, or taking too long (since 10 seconds at 400 kbit/s is less data to transfer than 10 seconds at 2 Mbit/s).
To test properly, you'd need a server side under your control, and you'd be watching for connection drops of something long-lived like an SSH connection. And, of course, the best fix is to not depend on long-lived connections to begin with - you're in the best possible place if connections can drop freely without issue, and you always find systems by mDNS or similar, not IP.
My phone switches seamlessly between WiFi and 5G, even in the middle of e.g. watching YouTube. Haven't tried changing WiFi connection mid-stream, however.
Change address on every DHCP renewal
YouTube is not a good test for seamless switching at the network layer, since it makes many small requests, and copes well with connection drop (by design - YouTube is meant to work even on bad networks).
Change address on every DHCP renewal