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.
Sull'autore
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.
Ricerca per canale
Automazione
Novità sull'automazione IT di tecnologie, team e ambienti
Intelligenza artificiale
Aggiornamenti sulle piattaforme che consentono alle aziende di eseguire carichi di lavoro IA ovunque
Hybrid cloud open source
Scopri come affrontare il futuro in modo più agile grazie al cloud ibrido
Sicurezza
Le ultime novità sulle nostre soluzioni per ridurre i rischi nelle tecnologie e negli ambienti
Edge computing
Aggiornamenti sulle piattaforme che semplificano l'operatività edge
Infrastruttura
Le ultime novità sulla piattaforma Linux aziendale leader a livello mondiale
Applicazioni
Approfondimenti sulle nostre soluzioni alle sfide applicative più difficili
Serie originali
Raccontiamo le interessanti storie di leader e creatori di tecnologie pensate per le aziende
Prodotti
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Servizi cloud
- Scopri tutti i prodotti
Strumenti
- Formazione e certificazioni
- Il mio account
- Supporto clienti
- Risorse per sviluppatori
- Trova un partner
- Red Hat Ecosystem Catalog
- Calcola il valore delle soluzioni Red Hat
- Documentazione
Prova, acquista, vendi
Comunica
- Contatta l'ufficio vendite
- Contatta l'assistenza clienti
- Contatta un esperto della formazione
- Social media
Informazioni su Red Hat
Red Hat è leader mondiale nella fornitura di soluzioni open source per le aziende, tra cui Linux, Kubernetes, container e soluzioni cloud. Le nostre soluzioni open source, rese sicure per un uso aziendale, consentono di operare su più piattaforme e ambienti, dal datacenter centrale all'edge della rete.
Seleziona la tua lingua
Red Hat legal and privacy links
- Informazioni su Red Hat
- Opportunità di lavoro
- Eventi
- Sedi
- Contattaci
- Blog di Red Hat
- Diversità, equità e inclusione
- Cool Stuff Store
- Red Hat Summit