Fast DHCP

[PlainName]

Sometimes the network has to be shut down, typically when we get a powercut and it's likely to be down for more than half an hour. Not a big issue - everything would survive a sudden power outage, but the servers are on a UPS to allow time for manual shutdown.

However, bringing it back up is a problem because the DHCP server is in a VM. That box, like many backend machines, takes forever plus 10 mins to just power up past POST, and then the VM manager has to get going, and then the VM has to start, etc. Meantime, everything else has booted and asked for an IP then given up and picked some random thing. A large proportion of the power-up sequence is going around to reboot everything once DHCP is running.

What I am looking for are suggestions for a simple means to have a DHCP server come up fast. Requirements are reasonably simple but not simple enough for many possible solutions: a block of static addresses and a (different!) block for DHCP assignments. The ability to have more than one DHCP block depending on stuff like MAC organisation, OS type, etc would be nice but not currently necessary. However, the DHCP server does need the ability to assign static addresses to specific MACs (and there are quite a few - a way to block enter those would be cool).

Finally, the ability to save and restore the config, preferably in a human readable (and potentially writable) form, is pretty much needed.

Any ideas?

[eleguy]

Maybe it is good idea at least to check https://opnsense.org/

[PlainName]

Thanks. I actually run pfSense which is very similar, and the DHCP server isn't really applicable - it is like the feature on a lot of routers in that it is there as an additional feature and not a core product. One particular thing that I forgot to mention, and the xxsense has trouble with, is making a reservation within the dynamic range. Sometimes very useful (to make sure some temporary thing stays where you think it is). As is being able to set an arbitrary range, not just one that fits, say, a subnet class.

The one I use currently is Hanewin, which works very well. Just not before anything else

[madires]

Anything linux with Kea DHCP (https://www.isc.org/kea/) plus Stork (web UI for Kea, https://www.isc.org/stork/).

[PlainName]

Interesting, thanks. That's certainly not limited in any way

I think it kind of defeats the purpose, though. It would need a new VM with linux just to run that, and of course that VM is going to be slow to boot.... An alternative, and possibly more what I had in mind, is to try running it on a RPi. A quick google suggests that might be difficult, particularly for someone essentially new to the Pi (and Linux).

[wraper]

An alternative, and possibly more what I had in mind, is to try running it on a RPi.

If you're going to buy hardware, you could use almost any cheap router for that, will be cheaper than RPi and needs no tinkering.

[PlainName]

Cheap routers don't have the feature set, which is one reason I'm not already using the decent router already on the network.

[indeterminate]

Run OpenWrt on the router
https://openwrt.org/docs/guide-user/base-system/dhcp
you can get prebuilt images for a huge range of cheep routers.

[PlainName]

OpenWRT doesn't seem to be particularly user friendly: to see leases, awk is apparently a useful tool. I really don't want to be messing about with CLIs. A typical thing I might do currently is shove something on the network then pop into the GUI display of dynamic leases to see where it is. Click it, say make this so-and-so static (and delete this address), ok, done. Does OpenWRT allow similar simple operation?

[ejeffrey]

The easiest thing would be to run the DHCP server on a different machine that boots faster or has a much longer lasting UPS.  A raspberry pi or something can run as complicated of a DHCP configuration as you want and is low enough power you can have very long backup times.

Assuming that's just not practical, are you using a managed / smart network switch?  If you power cycle or reboot the network switch all of the directly attached devices should see the link cycle and retry DHCP.  You could have a bootup script on your DHCP server that reboots the switch after the DHCP server is running.

[grumpydoc]

Delegate your DHCP to a small, fast booting mini-PC running Linux and a full featured DHCP server - I'd favour Fedora Server but whatever fits in your environment.

I use a PC Engines APU3D4 but any SFF or mini PC should do.

[PlainName]

The easiest thing would be to run the DHCP server on a different machine that boots faster or has a much longer lasting UPS.  A raspberry pi or something can run as complicated of a DHCP configuration as you want and is low enough power you can have very long backup times.

Yes, that's a solution (if the Pi could run an acceptable server). I could imagine powering just that from a small UPS (or current equivalent), although being able to come up quickly would be nice.

are you using a managed / smart network switch?  If you power cycle or reboot the network switch all of the directly attached devices should see the link cycle and retry DHCP.

Yep, but unfortunately a lot of stuff is on WiFi. I do have to reboot the access points (even though they are static IP - they're this mesh thing which thinks for itself when there is lack of authority), but even doing that doesn't clear up some devices.

[PlainName]

fast booting mini-PC running Linux and a full featured DHCP server

Got some PC Engines kit and even pukka mini-PCs, but Linux doesn't seem to be particularly fast booting. Still, that's beginning to look like the only reasonable alternative.

Part of my problem is that it's not a problem for a long time. We don't often get powercuts so between times it doesn't seem to be that important. When it does happen, though, I remember the previous tediousness and figure I really should do something about it... 

[ejeffrey]

The easiest thing would be to run the DHCP server on a different machine that boots faster or has a much longer lasting UPS.  A raspberry pi or something can run as complicated of a DHCP configuration as you want and is low enough power you can have very long backup times.

Yes, that's a solution (if the Pi could run an acceptable server). I could imagine powering just that from a small UPS (or current equivalent), although being able to come up quickly would be nice.

The Pi can definitely run an acceptable DHCP server, and it should boot up in about 30 seconds.  It will also be able to run for hours on a UPS or a DC battery bank.  You shouldn't tolerate a computer that takes 10 minutes to boot in 2025.

Yep, but unfortunately a lot of stuff is on WiFi. I do have to reboot the access points (even though they are static IP - they're this mesh thing which thinks for itself when there is lack of authority), but even doing that doesn't clear up some devices.

Maybe leave the wifi access points off for a bit longer or make sure that they are all off at the same time?  If the device thinks it's just a bit of radio fade or that it's roaming between access points it may not renew the lease.  But if the wifi is off for ~30 seconds, it should trigger re-association for most devices.  If you had a way that the access points would not enable their radios until the DHCP server was active that would be even better.

[ejeffrey]

Part of my problem is that it's not a problem for a long time. We don't often get powercuts so between times it doesn't seem to be that important. When it does happen, though, I remember the previous tediousness and figure I really should do something about it... 

I would think seriously about this.  If it takes you 10 minutes of rebooting a few times a year, it may not be worth solving, even if it is annoying.

[PlainName]

Maybe leave the wifi access points off for a bit longer or make sure that they are all off at the same time?

Not possible. OK, strictly it is, but having to go round turning them off before power comes back, then turning them on once the server it is up, it actually more hassle than just waiting for the server than then recycling the AP power. ISTR they are best booted in a specific order too, the primary needing to be up before the others get going.

[PlainName]

Part of my problem is that it's not a problem for a long time. We don't often get powercuts so between times it doesn't seem to be that important. When it does happen, though, I remember the previous tediousness and figure I really should do something about it... 

I would think seriously about this.  If it takes you 10 minutes of rebooting a few times a year, it may not be worth solving, even if it is annoying.

Yes, I've been a long time coming here

But this thread has been useful even if a solution doesn't pop up. I mean to look seriously at kea DHCP and see if I should switch to that.

[ejeffrey]

Maybe leave the wifi access points off for a bit longer or make sure that they are all off at the same time?

Not possible. OK, strictly it is, but having to go round turning them off before power comes back, then turning them on once the server it is up, it actually more hassle than just waiting for the server than then recycling the AP power. ISTR they are best booted in a specific order too, the primary needing to be up before the others get going.

Yeah, all my APs are wired and on POE.  So if I reboot the main switch it pretty much works for all wired and wireless clients.

[BradC]

I have a Pi set up for secondary DNS and DHCP for precisely this reason. Doesn't matter what is happening with the main server, everything can still get an address and resolve.

As with everything, this was prompted by an "event". I have a managed PDU and IP KVM. The server had a hardware issue and got stuck in a boot loop. I couldn't get access to the PDU or KVM because I had no record of their static IPs and had to manually configure the network on my laptop because DHCP was down.

I ended up using nmap to scan the management network to find the devices and get into them that way, but next step was to set up a secondary for DHCP & DNS.

It wasn't hard to configure, but I have a few years under my belt with the old ISC DHCP server, BIND and the RPi.

[brucehoult]

The easiest thing would be to run the DHCP server on a different machine that boots faster or has a much longer lasting UPS.  A raspberry pi or something can run as complicated of a DHCP configuration as you want and is low enough power you can have very long backup times.

Yes, that's a solution (if the Pi could run an acceptable server).

How could a machine with four 2.4 GHz cores and up to 16 GB RAM possibly NOT run any complexity of software you need?

You can probably find/make something in the Arm / RISC-V / N100 space with a cut-down kernel that boots in 10 seconds if not 5.


I'd bet a $5 Milk-V Duo would do the job just fine. That's a single core 1 GHz CPU with 64 MB RAM. Mine boots to the point of being able to SSH into it in 25 seconds, though it's already responding to pings by 15 seconds.

And, drawing 0.5W of power (100mA), you can run it off an airline-legal 100Wh USB power bank for more than a week, which would make boot time actually irrelevant anyway. Even a massively powerful Raspberry Pi 5 uses only 2.5W at idle, so it'd run of fthe same pocketable power bank for nearly two days.

[Monkeh]

I think it kind of defeats the purpose, though. It would need a new VM with linux just to run that, and of course that VM is going to be slow to boot....

So don't use a slow VM host to run it, use a dedicated machine which doesn't take 30 seconds to run through the firmware. A Pi 5 with a real SSD instead of a silly SD card should be able to be up and running in under 20 seconds. There's nothing inherently slow about booting Linux, and indeed once hardware issues are eliminated, it can be done in just a second or two.

Thanks. I actually run pfSense which is very similar, and the DHCP server isn't really applicable - it is like the feature on a lot of routers in that it is there as an additional feature and not a core product. One particular thing that I forgot to mention, and the xxsense has trouble with, is making a reservation within the dynamic range. Sometimes very useful (to make sure some temporary thing stays where you think it is). As is being able to set an arbitrary range, not just one that fits, say, a subnet class.

OPNsense is quite well fleshed out for DHCP capability, including setting any dynamic range you want and static leases within that range - however, because of how the server operates, a static lease within the pool can be handed out to a dynamic client if it's not taken by the static one. I don't know if that behaviour is different with Kea.

I switched to OPNsense from pfSense because of these sorts of limitations. It's far more flexible.

[mwb1100]

The dnsmasq program can act as a DHCP server (also a DNS or TFTP server, but those can be disabled if all you want is DHCP).  AFAIK there is not Windows port, so you'd probably have to this on a Linux machine.  I imagine an RPi or similar running Linux would have no problem.

dnsmasq should support the following from your list of requirements:

  - static addresses based on MAC address: there can be a simple text file specifying the MAC-->static IP configuration

  - DHCP blocks specified by MAC organization: using the --dhcp-mac=set:<tag>,<MAC address> configuration a "tag" can be assigned based on the MAC organization (since wildcards are permitted in the <MAC address> part of the option).  The tag can be used to match a specified address pool.

I don't know whether or not it can support using the OS Type to map to specific address pools.

I also don't know what is meant by the requirement "a block of static addresses "

However, I'm unaware of a GUI to configure dnsmasq.  The configuration is done by command line option and/or configuration file(s).

Going though the config options initially might be daunting (there are a lot of them), but I think once initially done that it would be straightforward to do any reconfiguration you want.

In comparison though, my brief look at the Kea DHCP server documentation left my head spinning.

[brucehoult]

Here is a GUI for managing DHCP (and many other services) on Linux / Unix hosts:

https://webmin.com/docs/modules/dhcp-server/

[Monkeh]

Here is a GUI for managing DHCP (and many other services) on Linux / Unix hosts:

https://webmin.com/docs/modules/dhcp-server/

webmin's still going? Jeez. Haven't looked at that in a decade or more.

[PlainName]

... however, because of how the server operates, a static lease within the pool can be handed out to a dynamic client if it's not taken by the static one.

Yes, exactly. If the client would just stay up and connected I wouldn't need the feature!

/quote]
I switched to OPNsense from pfSense because of these sorts of limitations. It's far more flexible.
[/quote]

Same limitation on this, AFAICS.