Skip to main content

Static and dynamic IP address configurations: DHCP deployment

Configure a DHCP server and scope to provide dynamic IP address configurations to your network subnet.
Image
Static and dynamic IP address configurations: DHCP deployment
Image by Dirk Schulz from Pixabay

In my Static and dynamic IP address configurations for DHCP article, I discussed the pros and cons of static versus dynamic IP address allocation. Typically, sysadmins will manually configure servers and network devices (routers, switches, firewalls, etc.) with static IP address configurations. These addresses don’t change (unless the administrator changes them), which is important for making services easy to find on the network.

With dynamic IP configurations, client devices lease an IP configuration from a Dynamic Host Configuration Protocol (DHCP) server. This server is configured with a pool of available IPs and other settings. Clients contact the server and temporarily borrow an IP address configuration.

In this article, I demonstrate how to configure DHCP on a Linux server.

[ You might also like: Using systemd features to secure services ]

Manage the DHCP service

First, install the DHCP service on your selected Linux box. This box should have a static IP address. DHCP is a very lightweight service, so feel free to co-locate other services such as name resolution on the same device.

# yum -y install dhcp-server

Note: By using the -y option, yum will automatically install any dependencies necessary.

Configure a DHCP scope

Next, edit the DHCP configuration file to set the scope. However, before this step, you should make certain you understand the addressing scheme in your network segment. In my courses, I recommend establishing the entire range of addresses, then identifying the static IPs within the range. Next, determine the remaining IPs that are available for DHCP clients to lease. The following information details this process.

How many static IP addresses?

Figure out how many servers, routers, switches, printers, and other network devices will require static IP addresses. Add some additional addresses to this group to account for network growth (it seems like we’re always deploying more print devices).

What are the static and dynamic IP address ranges?

Set the range of static IPs in a distinct group. I like to use the front of the available address range. For example, in a simple Class C network of 192.168.2.0/24, I might set aside 192.168.2.1 through 192.168.2.50 for static IPs. If that’s true, you may assume I have about 30 devices that merit static IP addresses, and I have left about twenty addresses to grow into. Therefore, the available address space for DHCP is 192.168.2.51 through 192.168.2.254 (remember, 192.168.2.255 is the subnet broadcast address).

This screenshot from the part one article is a reminder:

Image
spreadsheet tracking IP addresses, MAC addresses, hostnames, etc
Figure 1: A spreadsheet can be used to track relevant static IP address information.

Note: Some administrators include the static IPs in the scope and then manually mark them as excluded or unavailable to the DHCP service for leasing. I’m not a fan of this approach. I prefer that the DHCP not even be aware of the addresses that are statically assigned.

What is the router’s IP address?

Document the router’s IP address because this will be the default gateway value. Administrators tend to choose either the first or the last address in the static range. In my case, I’d configure the router’s IP address as 192.168.2.1/24, so the default gateway value in DHCP is 192.168.2.1.

Where are the name servers?

Name resolution is a critical network service. You should configure clients for at least two DNS name servers for fault tolerance. When set manually, this configuration is in the /etc/resolv.conf file.

Note that the DNS name servers don’t have to be on the same subnet as the DNS clients.

Lease duration

In the next section, I’ll go over the lease generation process whereby clients receive their IP address configurations. For now, suffice it to say that the IP address configuration is temporary. Two values are configured on the DHCP server to govern this lease time:

default-lease-time - How long the lease is valid before renewal attempts begin.

max-lease-time - The point at which the IP address configuration is no longer valid and the client is no longer considered a lease-holder.

Configure the DHCP server

Now that you understand the IP address assignments in the subnet, you can configure the DHCP scope. The scope is the range of available IP addresses, as well as options such as default gateway. There is good documentation here.

Create the DHCP scope

Begin by editing the dhcp.conf configuration file (you’ll need root privileges to do so). I prefer Vim:

# vim /etc/dhcp/dhcp.conf

Next, add the values you identified in the previous section. Here is a subnet declaration (scope):

subnet 192.168.2.0 netmask 255.255.255.0 {
  range 192.168.2.50 192.168.2.254;
  option domain-name-servers ns01.internal.test.net;
  option domain-name "internal.test.net";
  option routers 192.168.2.1;
  option broadcast-address 192.168.2.255;
  default-lease-time 1800;
  max-lease-time 7200;
}

Remember, that spelling counts and typos can cause you a lot of trouble. Check your entries carefully. A mistake in this file can prevent many workstations from having valid network identities.

Reserved IP addresses

It is possible to reserve an IP address for a specific host. This is not the same thing as a statically-assigned IP address. Static IP addresses are configured manually, directly on the client. Reserved IP addresses are leased from the DHCP server, but the given client will always receive the same IP address. The DHCP service identifies the client by MAC address, as seen below.

host fileserver3 {
    hardware ethernet    00:1B:44:11:B7:4A;
    fixed-address        192.168.2.55;
    max-lease-time       84600; 
}

Start the DHCP service

Start and enable the DHCP service. RHEL 7 and 8 rely on systemd to manage services, so you’ll type the following commands:

# systemctl start dhcpd
# systemctl enable dhcpd
# systemctl status dhcpd

See this article I wrote for a summary on successfully deploying services.

Don’t forget to open the DHCP port in the firewall:

# firewall-cmd --add-service=dhcp --permanent
# firewall-cmd --reload

Explore the DORA process

Now that the DHCP server is configured, here is the lease generation process. This is a four-step process, and I like to point out that it is entirely initiated and managed by the client, not the server. DHCP is a very passive network service.

The process is:

  • Discover
  • Offer
  • Request
  • Acknowledge

Which spells the acronym DORA.

  1. The client broadcasts a DHCPDiscover message on the subnet, which the DHCP server hears.
  2. The DHCP server broadcasts a DHCPOffer on the subnet, which the client hears.
  3. The client broadcasts a DHCPRequest message, formally requesting the use of the IP address configuration.
  4. The DHCP server broadcasts a DHCPAck message that confirms the lease.

The lease must be renewed periodically, based on the DHCP Lease Time setting. This is particularly important in today’s networks that often contain many transient devices such as laptops, tablets, and phones. The lease renewal process is steps three and four. Many client devices, especially desktops, will maintain their IP address settings for a very long time, renewing the configuration over and over.

Updating the IP address configuration

You may need to obtain a new IP address configuration with updated settings. This can be an important part of network troubleshooting.

Manually generate a new lease with nmcli

You can manually force the lease generation process by using the nmcli command. You must know the connection name and then down and up the card.

# nmcli con

# nmcli con down id  enp7s0
# nmcli con up id  enp7s0

Manually force lease generation with dhclient

You can also use the dhclient command to generate a new DHCP lease manually. Here are the commands:

dhclient -r to release it

dhclient (no option) to lease a new one

dhclient -r eth0 for specific NIC

Note: use -v for verbose output

Remember, if the client’s IP address is 169.254.x.x, it could not lease an IP address from the DHCP server.

Other DHCP considerations

There are many ways to customize DHCP to suit your needs. This article only covers the most common options. Two settings to keep in mind are lease times and dealing with routers.

Managing lease times

There is a good trick to be aware of. Use short lease durations on networks with many portable devices or virtual machines that come and go quickly from the network. These short leases will allow IP addresses to be recycled regularly. Use longer durations on unchanging networks (such as a subnet containing mostly desktop computers). In theory, the longer durations reduced network traffic by requiring fewer renewals, but on today’s networks, that traffic is inconsequential.

Routers and DHCP

There is one other aspect of DHCP design to consider. The DORA process covered above occurs entirely by broadcast. Routers, as a general rule, are configured to stop broadcasts. That’s just part of what they do. There are three approaches you can take to managing this problem:

  • Place a DHCP server on each subnet (no routers between the DHCP server and its clients).
  • Place a DHCP relay agent on each subnet that sends DHCP lease generation traffic via unicast to the DHCP server on a different subnet.
  • Use RFC 1542-compliant routers, which can be configured to recognize and pass DHCP broadcast traffic.

[ Getting started with containers? Check out this free course. Deploying containerized applications: A technical overview. ]

Wrap up

DHCP is a simple service but an absolutely critical one. Understanding the lease generation process helps with network troubleshooting. Proper planning and tracking are essential to ensuring you don’t permit duplicate IP address problems to enter your network environment.

Check out these related articles on Enable Sysadmin

Topics:   Linux   Linux Administration  
Author’s photo

Damon Garn

Damon Garn runs Cogspinner Coaction, LLC, a technical writing and IT project company based in Colorado Springs, CO. He has been a technical instructor for nearly 20 years, with a focus on Windows Server, Linux, and security. More about me

On Demand: Red Hat Summit 2021 Virtual Experience

Relive our April event with demos, keynotes, and technical sessions from
experts, and sign up to attend breakout sessions June 15–16.

Related Content

OUR BEST CONTENT, DELIVERED TO YOUR INBOX