So far in this chapter, we talked about creating a layout for your network. In this section, we'll put that plan in action. Here, we'll set up a DHCP server on either a Debian or CentOS machine, and configure it to serve IPv4 addresses to our network. So, let's get started!

First, decide on which distribution will run your DHCP server. It doesn't matter if you choose Debian, CentOS, or a derivative. The configuration is the same on each, with the main difference being the name of the package that you'll need to install and the daemon to start up. With Debian, you'll install the isc-dhcp-server package, and you'll install dhcp for CentOS. Debian will enable the DHCP daemon (isc-dhcp-server) for you, but it won't start up because we haven't configured it yet. CentOS will not attempt to start or enable its DHCP daemon (dhcpd).

For both Debian and CentOS, the configuration file we'll need to edit is located at /etc/dhcp/dhcpd.conf. In order to set up our DHCP server, we'll need to edit this file and then start or restart the daemon. Go ahead and open this file with your favorite text editor. If you installed your DHCP server on Debian, you'll notice you're provided with a default /etc/dhcp/dhcpd.conf file that contains a fair amount of example configuration. CentOS, on the other hand, pretty much gives you a blank file to work with. For our purposes, we'll create some configuration from scratch. You can either remove or back up the default configuration file in the case of Debian.

What follows is an example configuration /etc/dhcp/dhcpd.conf file for DHCP. In this example, we're using the same network as identified earlier while demonstrating the ipcalc utility (10.10.96.0/22). This network gives us several subnets to use, but you don't have to go ahead with this scheme; feel free to adjust accordingly to fit your environment.

default-lease-time 86400;
max-lease-time 86400;
option subnet-mask 255.255.252.0;
option broadcast-address 10.10.99.255;
option domain-name "local.lan";
authoritative;
subnet 10.10.96.0 netmask 255.255.252.0 {
    range 10.10.99.100 10.10.99.254;
    option routers 10.10.96.1;
    option domain-name-servers 10.10.96.1;
}

So, let's go through this configuration line by line.

First, we have the following two lines:

default-lease-time 86400;
max-lease-time 86400;

Here, we're identifying how long we would like a DHCP lease to last for. In practice, when a node requests an IP address, its client will be given a lease along with the IP address. This means that the IP address is only valid for a particular period of time. Here, we're setting a lease time of 86400, which means our lease time is one day since this is referenced in seconds. We have this number listed twice, in the default and maximum lease times. The default-lease-time is given to any client if it doesn't specify a particular amount of time it is requesting the hold onto the IP address for. The max-lease-time means that if the client requests to hold onto the IP address for longer than this period, it won't be allowed to do so. We're basically setting the default and the maximum lease time to the same number. If we wanted to, we could have also included min-lease-time to enforce a minimum lease time in case a client asks for less.

Consider the following two lines:

option subnet-mask 255.255.252.0;
option broadcast-address 10.10.99.255;

With this section, we're setting the subnet mask that will be given to clients as well as the broadcast address. As you probably already know, the subnet mask identifies the network that each connecting node will be a part of. When clients check their IP info after being provided an address, the subnet mask we identify will be shown. The broadcast address is an address on which all nodes within this subnet would be able to receive packets.

Consider the following two lines:

option domain-name "local.lan";
authoritative;

Here, we're appending the domain name of local.lan to the hostnames of each node that connect to our DHCP server. This step isn't required by any means, but can be useful if normalizing domain names within your network. We also include authoritative in our configuration to establish that our DHCP server is the primary one for this subnet.

Consider the following lines:

subnet 10.10.96.0 netmask 255.255.252.0 {
    range 10.10.99.1 10.10.99.254;
    option routers 10.10.96.1;
    option domain-name-servers 10.10.96.1;
}

Finally, we have a very important block of code at the end. Here, we identify the network address for our subnet, its subnet mask, the range of IP addresses we're issuing, the default gateway, and our DNS server. In this example, we're starting our first DHCP-issued address at 10.10.99.100 and ending our pool at 10.10.99.254. If you recall the output of ipcalc earlier, you'd notice that the first address in this subnet begins at 10.10.96.1. Instead of starting our pool there, we're starting our pool much later. For the sake of reference, we used the 10.10.96.0/22 network, which gives us the following subnets:

10.10.96.0
10.10.97.0
10.10.98.0
10.10.99.0

If we wanted to, we could set our DHCP range to begin at 10.10.96.1 and end at 10.10.99.254. We would have 1,022 DHCP addresses in that case. However, the reason I didn't do that in my configuration is because the first three networks have been reserved for several purposes. I use the first (10.10.96.0/22) for servers, the next for DHCP reservations, and the third for network appliances. Since the first three subnets are outside the DHCP range, the DHCP server will never offer any of those addresses to clients, so I don't have to worry about a DHCP lease tackling a static address I may have set up. It's a very common practice to ensure that static IP addresses are outside the DHCP range.

To be fair, this configuration is fairly complicated, as I'm showing you how to use multiple subnets with DHCP rather than focusing on just one network. To simplify a bit, if we were setting up a default 24-bit network, our configuration would look like the following (if we were using a 10.10.10.0/24 network):

default-lease-time 86400;
max-lease-time 86400;
option subnet-mask 255.255.255.0;
option broadcast-address 10.10.10.255;
option domain-name "local.lan";
authoritative;
subnet 10.10.10.0 netmask 255.255.255.0 {
    range 10.10.10.10 10.10.10.254;
    option routers 10.10.96.1;
    option domain-name-servers 10.10.96.1;
}

With this configuration, I'm setting the DHCP range to start at 10.10.10.10 and end at 10.10.10.254. This gives me nine IP addresses (10.10.10.1—10.10.10.9) that will never be assigned, so I have room to set up a few static IP addresses.

So, I mentioned static IP addresses a few times here. You probably already know what that means, but it's important to elaborate that static IP addresses are a great idea for servers. These are addresses that are reserved for certain servers or nodes, where you expect them to have the same IP address each time. This is probably a no-brainer if you've ever configured a network before. There's also the concept of a static lease that's important as well. A static lease is also known as a reservation. With a static lease, the IP address is still provided by the DHCP server, and the client still uses DHCP to request an address. The difference is that the client will receive the same address, each and every time it connects.

Setting up static leases is very easy. Reservations can be placed at the end of your /etc/dhcp/dhcpd.conf file. Here's an example to show what the syntax looks like:

host bahamut {
    hardware ethernet 28:B2:BD:05:1E:00;
    fixed-address 10.10.97.4;
}

Here, we have a host named bahamut with a MAC address 28:B2:BD:05:1E:00. The name is arbitrary; it has no actual meaning other than for us to remember which host the reservation is for. It doesn't have to match the hostname of the device that's requesting an IP. The two lines within the block of code simply mean that any time a network card connects to the DHCP server with a MAC address 28:B2:BD:05:1E:00, it needs to be provided an IP address of 10.10.97.4. We can add as many similar code blocks as we'd like for as many static leases we wish to assign.

You might be wondering, when should you use a static IP and when should you use a static lease? In my opinion, use static leases whenever it makes sense and fits the design of your network. With static leases, you only need to check the /etc/dhcp/dhcpd.conf file whenever you'd like to see an overview of all your reservations. In addition, the host will always receive the same IP address, even if you reinstall the OS or boot it from a live install image. There's nothing you need to configure on the host itself for a static lease. Generally, static leases are easier to manage. Of course, your own preferences will supersede this.

Finally, in order for our DHCP server to run properly, it must be started and configured to run at boot. Debian already took care of enabling the daemon, so you would just need to restart it for our configuration to take affect:

# systemctl restart isc-dhcp-server

For CentOS, we need to enable and start the service manually:

# systemctl enable dhcpd
# systemctl start dhcpd

As you can see, configuring a DHCP server on Linux is fairly easy and straightforward. Of course, there are advanced usage scenarios and a plethora of additional options. But for most purposes, a configuration such as the one outlined here should suffice.