In the process of setting up an automated deployment processes within my lab, I stumbled into the need to send DHCP requests to both my existing DHCP server as well as a Windows Deployment Services (WDS) server I was standing up.
There are several widely discussed options for this:
- Place the DHCP client and both servers on the same subnet.
- Place the DHCP service and the WDS service on the same system/IP address.
- Add DHCP options to the client scopes to point to the PXE server and appropriate boot image.
- Add both servers to the list of DHCP relays/IP helpers.
While the first two options are probably the easiest to implement, implementing either of those options would require changes to the existing environment. The client subnet I was interested in using was already distinct from the subnet on which the servers existed in (to better match the lab to production environments). As implementing an automated deployment process was a new experience for me, I was not interested in moving my reliable DHCP services onto a machine I might decide at any time to delete and start over with.
The third option is an interesting one from the perspective of what gets posted online. There is a large amount of material online recommending this approach and many administrators have implemented some variation of this technique. There is also discussion of possible shortfalls of this approach in the mixed BIOS vs EFI, 32-bit vs 64-bit, Windows vs Linux environments common today. You want to PXE Boot? Don’t use DHCP Options on the Microsoft Configuration Manager blog provides a summary of both the approach and possible complications. Giving this a lab environment, I didn’t want to restrict myself to a subset of system configurations.
For some, the fourth and final option of adding both addresses to the list of DHCP relays may have been the obvious choice. This option was a bit more complicated in my case as the lab router only supports a single target for DHCP relay. Perhaps there is a way to overcome this by manually editing configuration files, but such modifications rarely prove maintainable long term. Another option might be to use layer 3 functionality on another network device (such as a switch) to achieve this. Just as I was not interested in moving my existing DHCP services, I was not looking to reconfigure my lab switch.
Based on these constraints I decided to stand up a small (1vCPU, 512MB ram) VM running Debian within the client subnet to provide DHCP relay services. ISC’s DHCP Relay Agent is built for this very purpose and is packaged within Debian’s apt repositories as isc-dhcp-relay. Once installed the relevant configuration file to modify is /etc/default/isc-dhcp-relay. There are three configuration options in this file servers, interfaces, and options. For this configuration it was only necessary to populate the serversoption with the IP addresses of the existing DHCP server and the WDS server, delimited by a space. Once configured and the isc-dhcp-relay service restarted, requests can be received by both services and each can respond appropriately.
Hopefully this summary can help in other lab environments lacking or having only limited parallels to full featured enterprise networking dhcp relay capabilities.
