Weekend Lab Work: DHCP Servers

I’m going through a process of refreshing the lab and looking at efficiencies and configuration options. One of the first steps is reviewing my DHCP setup for assigning IP addresses and automating the boot process.

Currently we have two lab environments. I host one at home, using Raspberry Pi devices and a Scale Computing NUC cluster. The Scale HE150 (more details here), provides local virtual machines for edge environments. It’s aimed at the type of configuration that could be used in branch offices to deliver virtual desktops or application virtual machines.

The Raspberry Pi cluster is simply a bunch of Raspberry Pi devices of varying genres, from the original to the latest Pi 4. The Pi is a great device for using as a desktop or running small workloads. This includes learning platforms like Kubernetes.

Main Lab

The main lab environment is much more expansive. It’s based off multiple Dell R610 servers, fibre channel storage and Gigabit networking. Currently this runs a vSphere cluster, plus another Scale Computing cluster environment that uses hard drives. I’m writing about automating the Scale Cluster in this separate series of blog posts. Both the home machines (BRK1) and the main lab (BRK2) are linked by VPN.

DHCP Requirements

The DHCP requirements for both environments are pretty straightforward. There’s a reserved set of IP addresses for fixed devices and a variable range for dynamically built VMs. In both configurations, I want the ability to PXE boot (or WDS for Windows servers). IP address ranges are:

BRK1 (home) – 172.16.10.0/24
BRK2 (lab) – 172.17.0.0/16

The BRK2 lab address range is historical and not easy to change, as I’d need to visit the co-lo to make change and that’s not possible at the moment. DHCP and DNS servers are at the .1 address on both networks. Physical routers are at the .254 address on both networks.

BRK1 DHCP

Here’s the DHCP configuration for BRK1.

#
# Brookend Lab (BRK1) DHCP definitions
#
#
authoritative;
allow booting;
allow bootp;
allow client-updates;
ddns-updates on;
option option-128 code 128 = string;
option option-129 code 129 = text;
shared-network "BRK1" {
#
# 10 subnet - used for Scale Cluster VMs and RPis
# cluster nodes are 172.16.10.251,2,3
#
class "scale-cluster" {
    match if substring (hardware,1,3) = 7c:4c:58;
    log(info, "SC01 cluster VM");
}
class "rpi-devices" {
    match if substring (hardware,1,3) = b8:27:eb;
    log(info, "Raspberry Pi Device");
}
class "rpi4-devices" {
    match if substring (hardware,1,3) = dc:a6:32;
    log(info, "Raspberry Pi 4 Device");
}
subnet 172.16.10.0 netmask 255.255.255.0 {
        option routers 172.16.10.254;
        option broadcast-address 172.16.10.255;
	option domain-name-servers 172.16.10.1;
        option domain-search "brk1.brookendlab.com";
	option domain-name "brk1.brookendlab.com";
        default-lease-time 3600;
        max-lease-time 3600;
	next-server 172.16.10.10;
	filename "/pxelinux.0";
    pool {
        range 172.16.10.30 172.16.10.199;
        allow members of "scale-cluster";
	ddns-domainname "brk1.brookendlab.com";
    }
    pool {
	range 172.16.10.200 172.16.10.249;
        allow members of "rpi-devices";
	allow members of "rpi4-devices";
    }
}

Without describing every line, I’ll highlight a few options. First the RPi and Scale VMs are assigned separate ranges for administrative purposes. This is achieved by a filter on the MAC ID. Each DHCP request triggers a syslog entry, which was helpful during debugging the configuration. The PXE boot server (172.16.10.10) is a QNAP device that runs both TFTP and FTP. It also stores all the Linux boot images.

BRK2 DHCP

The main lab is configured slightly differently. Most of the basic parameters are the same as BRK1, however there are three separate VLANs defined in this environment; VLAN0 as the default for VMs, VLAN11 for VMs PXE booted and VLAN12 for WDS VMs. This configuration was separated like this because WDS seemed to want to take over on every automated boot, so I separated them by VLAN.

#
# Brookend Lab (BRK2) DHCP definitions
#  
#
authoritative;
allow booting;
allow bootp;
allow client-updates;
ddns-updates on;
option option-128 code 128 = string;
option option-129 code 129 = text;
#
# 172.17.0 subnet - default subnet
#
shared-network "VLAN0" {
subnet 172.17.0.0 netmask 255.255.255.0 {

        range 172.17.0.150 172.17.0.250;
        option domain-name-servers 172.17.0.1;
        option domain-name "brk2.brookendlab.com";
        option broadcast-address 172.17.0.255;
        option routers 172.17.0.254;
        default-lease-time 3600;
        max-lease-time 3600;
        }
}
#
# 172.17.11.0 subnet - VMs built via PXE
#
shared-network "VLAN11" {
subnet 172.17.11.0 netmask 255.255.255.0 {

	range 172.17.11.150 172.17.11.250;
        option domain-name-servers 172.17.11.1;
        option domain-name "brk2.brookendlab.com";
        option broadcast-address 172.17.11.255;
        default-lease-time 3600;
        max-lease-time 3600;
	next-server 172.17.11.1;
	filename "/pxelinux.0";
        }
}
#
# 172.17.12.0 subnet - VMs build via WDS
#
shared-network "VLAN12" {
subnet 172.17.12.0 netmask 255.255.255.0 {

        range 172.17.12.150 172.17.12.250;
        option domain-name-servers 172.17.12.1;
        option domain-name "brk2.brookendlab.com";
        option broadcast-address 172.17.12.255;
        option routers 172.17.12.254;
        default-lease-time 3600;
        max-lease-time 3600;
        }
}

The Architect’s View

These configurations are pretty basic and keep things simple. You can see that both lab environments are on separate DNS subnets. I’ll cover this in another post that will look at spanning DNS between both locations. All of the configuration data will be available on Github over time.

Note: I’m no expert at running infrastructure, so any comments or feedback are gladly welcome!