What happens if the DHCP server comes online after the client devices do?

If I have a Windows PC running a DHCP server. I expect it will take on order of minutes a few to boot. My network will have a variety of other devices from various vendors that will boot within seconds.

I have not found a "standard" for DHCP client retries. Will those devices timeout before the Windows DHCP server starts? If so, what is the best way to deal with that?

Clarifications: There are no Windows clients involved. The clients are industrial embedded devices such as cameras, heaters, and robots.

I am not worried about what happens if the DHCP server goes down. These are embedded devices that are all hooked to a single power source. I want to know what to do when the "factory" powers on in the morning.

Solution 1:

OK, I have a couple thoughts:

1. There are as many DHCP stacks as there are stars in the sky. OK, not quite, but you get the idea. Embedded networking stacks are especially known for having non-complete "standards" implementation. As such, it's highly likely that your devices will end up booting before your DHCPd is ready, will APIPA, and won't ever retry DHCP. The only way you can verify this is to check the behavior of each device involved.
2. Power-cycling the switch (as others have recommended) may not even work. I've seen many embedded devices that fire off their DHCP requests once as part of the boot sequence and then never try again, even if the PHY link state on the NIC changes.

Here is my recommended solution:

There are available on the market power-sequencing PDUs. These are typically two or three-stage PDUs with programmable delays. With these, when they're powered on, they'll power up the first stage, wait the specified number of seconds, power up the second stage, etc. You could connect your switch and your server to the first stage, have the PDU wait 5 minutes for the server to complete booting and then power up the second stage which has all of the other devices on it.

Solution 2:

There are three scenarios for a Windows DHCP client that I can think of off the top of my head. I can't speak to non-Windows DHCP clients but I have to assume they operate the same way.

1. A running Windows DHCP client that has an active lease while the DHCP server is unavailable: The DHCP client will continue using it's currently leased ip address. When it reaches the renewal phase (T1) it will attempt to renew it's existing lease. If it fails to communicate with the DHCP server that can renew the existing lease the client will continue attempting to renew it's lease until it reaches the Rebinding phase (T2) where it will attempt to contact any DHCP server. If the T2 timer expires then the client will release it's ip address.

2. A Windows DHCP client with an active leased that is rebooted while the DHCP server is unavailable: The DHCP client will continue using it's currently leased ip address. When it reaches the renewal phase (T1) it will attempt to renew it's existing lease. If it fails to communicate with the DHCP server that can renew the existing lease the client will continue attempting to renew it's lease until it reaches the Rebinding phase (T2) where it will attempt to contact any DHCP server. If the T2 timer expires then the client releases it's ip address. The caveat here is that to my understanding the DHCP client should release it's existing ip address if it fails to contact the DHCP server upon rebooting because it can't confirm that it's allowed to continue using the ip address. This appears not to be the case with Windows clients, which has me a little stumped. At any rate, my tests with Windows clients shows that they do indeed retain their existing leased ip address across reboots when the DHCP server is unavailable.

3. A Windows DHCP client that does not have an existing lease: Of course the DHCP client will not be able to contact a DHCP server and will assign itself an APIPA ip address. As Neil T stated in his answer, a DHCP client that does not have an active lease will attempt to contact a DHCP server roughly every 5 minutes.

Solution 3:

Windows clients usually give the server about 60 seconds (give or take) to get it together. After that they switch to a fallback mode in which the devices check every 5 minutes. If 5 minutes is too long to wait, you could reboot the switch they're connected to. Even a warm boot if the switch has that feature would work.