7

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.

Moby Disk
  • 186
  • 1
  • 10
  • 2
    They will retry, but seriously - just keep your DHCP server online. – EEAA Oct 28 '15 at 03:48
  • @EEAA sometimes the power goes out for a long time at a branch too small to run a generator but big enough to use a server instead of a router for DHCP. Servers take longer to boot than desktops/laptops, particularly servers that boot up the firwall, router and VPN virtual machines before the Active Directory virtual machine that runs DHCP. – BeowulfNode42 Oct 28 '15 at 04:09
  • @EEAA I am worried about initial power up. – Moby Disk Oct 28 '15 at 04:37
  • which network stack are these clients using? – Jim B Oct 28 '15 at 04:49
  • @Jim B They are all different OSs and vendors. – Moby Disk Oct 28 '15 at 05:07
  • A remote power control (be it hardware, or a managed switch which can be issued a reboot) to the switch in which clients are plugged. Once dhcp is up, reboot or power-cycle that switch. Any client which detects it's lan interface going down and up should get a dhcp lease when it's interface goes up. – Dan Oct 28 '15 at 07:22
  • I'd use a raspberry pi as DHCP server instead of the Windows PC. It runs from a standard 5V USB connector, and with a USB power bank, it should be able to survive a long time of mains outage. – Guntram Blohm Oct 28 '15 at 07:27
  • Software by default does not "give up". If there's a loop `while(not IP address) { send DHCP request; wait 30 seconds for DHCP response; }` then the software will continue to send requests. And which programmer is _not_ going to put in a loop? DHCP packages are occasionally lost or mangled, so you need to a retry capability. And there's really no point in artificially limiting the number of retries. – MSalters Oct 28 '15 at 09:06
  • @GuntramBlohm that would be OK for a personal application, but OPs question would hint at some sort of professional usage, where a raspberry pi simple doesn't have enough horsepower. – James T Oct 28 '15 at 09:06
  • @GuntramBlohm We are considering using something other than Windows for the DHCP server if this turns out to be a problem. – Moby Disk Oct 28 '15 at 14:25
  • So...you power down the entire building every day? I understand this isn't what your question is about, but that's broken. I've worked in manufacturing before. Powering down the manufacturing floor? Great. Powering down your network infrastructure? Not good. – EEAA Oct 28 '15 at 17:10
  • @EEAA It doesn't matter how often we power it down. But when we do, I want to make sure it comes up without people having to wait 5 minutes. Hopefully, they will never power it down because it will be amazingly reliable. :-) All of these components are housed inside a single large device. But that should not matter for the purpose of the question. – Moby Disk Oct 28 '15 at 18:49
  • 1
    @MobyDisk OK, **those** are the kind of details that should have been included in your question. Context matters, especially in very non-standard situations like this. – EEAA Oct 28 '15 at 19:59

4 Answers4

7

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.

EEAA
  • 108,414
  • 18
  • 172
  • 242
5

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.

joeqwerty
  • 108,377
  • 6
  • 80
  • 171
  • I need to know non-windows client behavior. :-( Updated question to clarify. – Moby Disk Oct 28 '15 at 04:41
  • I'm assuming that they all operate the same seeing as the DHCP protocol is an "unofficial" standard first laid out in RFC 1531. – joeqwerty Oct 28 '15 at 04:57
  • Unfortunately, an assumption that all devices behave like Windows doesn't help me. Scenario 3 is somewhat relevant to me, but I need to know how non-Windows devices operate. A 5 minute delay would be unacceptable. I need it to be more on order of 5 seconds. – Moby Disk Oct 28 '15 at 14:28
  • 3
    Well you didn't state any of that in your original question. Someone down voted my answer because it doesn't fit your scenario but that doesn't make my answer any less correct. If you had stated the full details of your scenario I wouldn't have even posted my answer as it wouldn't have been relevant to your scenario. Additionally, I don't see why any device would deviate from the "standard" DHCP client behavior, but the only way to know how your devices will behave is to simulate this scenario while running a network traffic capture. – joeqwerty Oct 28 '15 at 15:58
  • Sorry, I thought "My network will have a variety of other devices from various vendors that will boot within seconds" made it clear that these weren't Windows devices. That is also why I added "There are no Windows clients involved" immediately after you answered, and also why I posted a reply to your answer stating it as well. You are correct that I am looking to see if there is "standard" DHCP client behavior. But many people seem to assume that whatever Windows does is the standard, and I don't have that luxury. :-( – Moby Disk Oct 28 '15 at 18:52
2

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.

Neil
  • 842
  • 6
  • 13
  • So the devices will reissue their DHCPDISCOVER if the seitch is rebooted? Is this standard behavior for any DHCP-capable device, or just observed Windows behavior? – Moby Disk Oct 28 '15 at 04:40
  • Well when a swtich goes down, the network link totally goes down, if we're talking about wired nodes. It's the same as unplugging the cable. When it comes back up, the interface should start its initialization routine, part of which is the DHCP process. It can't know if it's on a totally different network now, so it starts from the top in all scenarios. I don't want to guarantee this is true for every device, but it should be the SOP for 99.9% of ethernet enabled devices you come across. – Neil Oct 28 '15 at 04:53
  • If the DHCP clients have an existing lease they do not need to issue a DHCPDISCOVER packet. They already have the ip address of the DHCP server and will communicate directly with the DHCP server via unicast, as opposed to the broadcast of a DHCPDISCOVER packet. – joeqwerty Oct 28 '15 at 04:59
  • @Neil T ok. I can test each device to see if they send DHCP requests when we plug in the cable or if we must reboot them. – Moby Disk Oct 28 '15 at 05:13
  • @joeqwerty If the network cable is unplugged, they will reinitiate the network including a broadcast DHCP message upon plugging it back in. I just tested this to make sure haha. In the image below, I had wireshark running before plugging the cable back in. Once plugged in, you can see the first 8 frames sent out by my interface. My previous DHCP lease was good until 10/28 @ 20:23 https://i.imgur.com/IRldz5s.png – Neil Oct 28 '15 at 05:19
  • @joeqwerty Yeah, if the server goes down that isn't an issue. It's initial power up that is the potential problem. – Moby Disk Oct 28 '15 at 05:23
  • I think we're talking about different things here. It seems maybe I'm not fully understanding the question. A DHCP client losing it's connectivity to the network is not the same as the DHCP server being unavailable to a DHCP client that has connectivity to the network. Those are distinctly different scenarios. So what is your actual scenario? If the clients have an existing lease and they boot up before the DHCP server boots up then those clients should not go through the DORA process. They should maintain their existing DHCP lease. – joeqwerty Oct 28 '15 at 06:14
  • My actual scenario is that all of the devices are connected to a single power source and they all power up at the same time. But since Windows is slower than a solid state embedded microcontroller, the micros will see no DHCP server, give up, possibly do APIPA, then.... not have a real IP address for some long period of time. – Moby Disk Oct 28 '15 at 18:57
  • @joeqwerty, yeah I think that was my fault. I thought you were disagreeing in your first comment that disconnecting and reconnecting the network wouldn't reinitialize the DHCP process. – Neil Nov 05 '15 at 05:35
0

Is there some reason why these clients can't be given a static IP address? While "technically illegal", I've seen places were some devices were assigned addresses in the 192.168.0.0/16 space, with the DHCP servers then configured to start assigning addresses above the assigned ones.

If that's not reasonable, why not set your DHCP leases to two weeks or more?

TMN
  • 181
  • 2
  • The client will not accept static IPs for a variety of reasons too complex to go into here. I can happily set the DHCP licenses to forever, but it is the initial startup that is a concern. – Moby Disk Oct 28 '15 at 14:30
  • 1
    Technically illegal? Under what legislation / standards? – BlueCompute Oct 28 '15 at 14:39