I’ve been meanign to setup a backup DHCP service on my home network for a while. I doubt the primary node will fail since a server class way overpowered workstation, however when bad storms like the ones over the past few weeks pass through I do like to turn it off. I’ve also ran into problems while upgrading Arkhal, my primary node, because I can’t troubleshoot without configuring a network. Enter my old Respberry Pi B 2.0 which I’ll be using for network stuff.

The node is already up to date, running Raspbian’s version of Jesse. I installed isc-dhcp-server so now I just need to configure it. I keep my configuration in git repository so in theory it should be relatively simple to deploy. First step is to get the repository cloned into the correct place. The version of dhcpd which installed looks for the configuration at /etc/dhcp/dhcpd.conf. Verifying in on Arkhal this is the correct file. I should really get a continous delivery pipeline setup for this, so that willb e the next steps. Needed to installl git in order to clone the repository :doh:. I wonder what the man-db process does…it seems to take a while; I’m assuming it updates the man indexes. Checkout was fairly painless.

The DHCP service is named dhcpcd5 annoyingly. The file name also means systemd really doesn’t like it. Easy enought to boot, however I’m sure that will get me more than the frist time. Nope; that was the DHCP client configuration file. The service is a SysV service named isc-dhcp-server.service.

The service doesn’t log to the systemd journal, whcih I’ve just kind of assumed with all boot scripts which haven’t updated from SysV yet. Well, a simple update script is in place to pull and restart the service. Now to test the service. Well, that was a sad failure. The service isn’t properly responding at all. Unfortunately this is really annoying there isn’t a decent DHCP test client out there :-/. The best answer I found produces some decent output but requries you use nmap. An example of the output:

[gremlin@kal]~:> sudo nmap -sU -p 67 --script=dhcp-discover 172.16.10.50

Starting Nmap 7.12 ( https://nmap.org ) at 2017-01-22 16:45 PST
Nmap scan report for 172.16.10.50
Host is up (0.00038s latency).
PORT   STATE SERVICE
67/udp open  dhcps
| dhcp-discover:
|   DHCP Message Type: DHCPACK
|   Server Identifier: 172.16.10.40
|   Subnet Mask: 255.255.255.0
|   Router: 172.16.10.1
|   Domain Name Server: 172.16.10.40, 8.8.8.8
|_  Domain Name: workshop.meschbach.net
MAC Address: B8:27:EB:14:EF:57 (Raspberry Pi Foundation)

Hmm, the server identifier is a little off. Interestingly, after trying to track down why nmap was either picking up the wrong identifier or from the correct specific host it seems to renew leases without a problem. So onto to configuring the fail over! Or at least trying to configure the fail over. According to the ISC’s documentation the process should be as simple as adding a few stanzs and a shared secret. Let’s see how this works out.

DHCP failover

Alrighty, time to configure the DHCP failover. They seem fairly searious about the times being in sync. For my own sanity I also should change the board from UTC to pacific time so I don’t have to continue with the conversion. Should be a trivial dpkg-reconfigure using sudo dpkg-reconfigure tzdata. I really wish they had SF instead of LA for the choice of regions. Time drift between the two devices is fairly small so I’ll probably be okay.

Reading through teh ISC’s documentation they require two different stanzas to inform the service if it’s the leader or follower. I wonder if the configuration file supports conditioanls or if I’ll have to resort to using the C preprocessor. Looks like conditionals are supported although very strange they look. use-host-decl-names appears to be an awesome option to reduce the repetition of declaring the host name and value. Anyway, C preprocessor it is for now. Maybe in the future I’ll look into it.

Perhaps the C preprocessor isn’t so great. Being a configuration file they use the # symbol to denote comments. Hmm, apparently there are include statements in the DHCP configuration. There is a question regarding include paths. Maybe I’ll just concatenate the files for each host and installation.

Following the tutorial it says I need to generate the shared secrets for the peers. dnssec-keygen is a utility which is apart of the BIND 9 family of tools. Bummer I need to install it but meh, time to move forward with the project. From my understanding MD5 is broken and it’s probably best to use SHA128 and above. By default this produces several files. If you open one it will contian the key in a Base64 encoding, this is the key which needs to be copied in from my understanding. And I hit a bug with the key I generated. Unable to create tsec structure for omapi_key. I feel back to the example method of generating a key which produced the following errror: /etc/dhcp/dhcpd.conf line 7: invalid statement in peer declaration. It’s within the peering block on the max-response-delay line. max-response-delay is the time the primary should be out of communciation before the secondary assumes failover mode. This is stated as requried. Turns out I had a character encoding issue when I copied and pasted from the examples. Not so fun times.

Next up to resolve: service fails. It complains I’m not using the failover peer in the correct places. Easy enough, I had to place the failover in each pool declaration. I’ve got a number of static hosts…so I’m hoping they aren’t going to get multiple repsonses. Not that DHCP is a particularly high bandwidth protocol anyway. Well that mountain has been climbed! It should work. I’ll have to await real validation when I’m more awake and others in my household arne’t trying to use the network (or I feel more inclined to kick them off :smile: ).