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.

Improve this question
13
  • 2
    They will retry, but seriously - just keep your DHCP server online.
    – EEAA
    Oct 28, 2015 at 3: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, 2015 at 4:09
  • @EEAA I am worried about initial power up.
    – Moby Disk
    Oct 28, 2015 at 4:37
  • which network stack are these clients using?
    – Jim B
    Oct 28, 2015 at 4: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, 2015 at 19:59

4 Answers 4

Reset to default
8

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.

Improve this answer
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.

Improve this answer
5
  • 1
    I need to know non-windows client behavior. :-( Updated question to clarify.
    – Moby Disk
    Oct 28, 2015 at 4: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, 2015 at 4: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, 2015 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, 2015 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, 2015 at 18:52
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.

Improve this answer
9
  • 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, 2015 at 4: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, 2015 at 4: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, 2015 at 4: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, 2015 at 5: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 i.imgur.com/IRldz5s.png
    – Neil
    Oct 28, 2015 at 5:19
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?

Improve this answer
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, 2015 at 14:30
  • 2
    Technically illegal? Under what legislation / standards?
    – BlueCompute
    Oct 28, 2015 at 14:39

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .