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:
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.
- The client broadcasts a DHCPDiscover message on the subnet, which the DHCP server hears.
- The DHCP server broadcasts a DHCPOffer on the subnet, which the client hears.
- The client broadcasts a DHCPRequest message, formally requesting the use of the IP address configuration.
- 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.
About the author
Damon Garn owns Cogspinner Coaction, LLC, a technical writing, editing, and IT project company based in Colorado Springs, CO. Damon authored many CompTIA Official Instructor and Student Guides (Linux+, Cloud+, Cloud Essentials+, Server+) and developed a broad library of interactive, scored labs. He regularly contributes to Enable Sysadmin, SearchNetworking, and CompTIA article repositories. Damon has 20 years of experience as a technical trainer covering Linux, Windows Server, and security content. He is a former sysadmin for US Figure Skating. He lives in Colorado Springs with his family and is a writer, musician, and amateur genealogist.
Browse by channel
Automation
The latest on IT automation for tech, teams, and environments
Artificial intelligence
Updates on the platforms that free customers to run AI workloads anywhere
Open hybrid cloud
Explore how we build a more flexible future with hybrid cloud
Security
The latest on how we reduce risks across environments and technologies
Edge computing
Updates on the platforms that simplify operations at the edge
Infrastructure
The latest on the world’s leading enterprise Linux platform
Applications
Inside our solutions to the toughest application challenges
Original shows
Entertaining stories from the makers and leaders in enterprise tech
Products
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Cloud services
- See all products
Tools
- Training and certification
- My account
- Customer support
- Developer resources
- Find a partner
- Red Hat Ecosystem Catalog
- Red Hat value calculator
- Documentation
Try, buy, & sell
Communicate
About Red Hat
We’re the world’s leading provider of enterprise open source solutions—including Linux, cloud, container, and Kubernetes. We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.
Select a language
Red Hat legal and privacy links
- About Red Hat
- Jobs
- Events
- Locations
- Contact Red Hat
- Red Hat Blog
- Diversity, equity, and inclusion
- Cool Stuff Store
- Red Hat Summit