dhclient Removed in RHEL 10: Use NetworkManager for DHCP

RHEL 10 no longer provides dhclient or the dhcp-client package. NetworkManager’s built-in DHCP client is the supported replacement, so DHCP is configured and controlled through NetworkManager profiles and nmcli instead of a standalone dhclient command.

RHEL 8 and RHEL 9 already used NetworkManager’s internal client by default. RHEL 9 still allowed dhcp=dhclient; that option is gone in RHEL 10. No extra DHCP client package is required. This page is about the client that receives a lease on the host, not about serving leases to other machines.

dhclient Replacement on RHEL 10: Quick Answer

NetworkManager stores interface settings in a connection profile. After you identify the profile attached to your interface, set it to DHCP:

nmcli connection show

The DEVICE column is the network interface, such as enp0s8. The NAME column is the NetworkManager connection profile. They can have the same name, as they do in this lab, but they do not have to. Your profile might be named something like Wired connection 1 even when the interface is enp0s8.

Set IPv4 to DHCP on that profile (replace the name with yours):

sudo nmcli connection modify "<profile>" ipv4.method auto

Activate the profile:

sudo nmcli connection up "<profile>"

Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/9)

The D-Bus path is internal NetworkManager information; you do not need it for this task. If this profile carries your current SSH connection, reactivating it can briefly interrupt network access. Use console access or a separate test interface when changing a remote system.

Confirm the address and DHCP options on the device:

nmcli -f IP4,DHCP4 device show <interface>

dhclient cannot be installed from supported RHEL 10 repositories. There is no new standalone replacement command. NetworkManager’s internal DHCP implementation owns DHCP now, and you do not need to install anything else for that role.

Do not confuse the removed DHCP client with the removed ISC DHCP server:

Kea does not replace dhclient. For a DHCP server build-out, see Configure Kea DHCP server.

Why Is dhclient Missing in RHEL 10?

On a fresh RHEL 10 system the binary is not there. Confirm with command -v:

command -v dhclient

No path prints, and the shell exit status is non-zero. Calling the command by name produces the error people usually search for:

dhclient

bash: dhclient: command not found

That message alone does not prove the package was removed from the distro. Check the RPM database next:

rpm -q dhcp-client

package dhcp-client is not installed

The package is absent, not merely missing from $PATH. Red Hat removed dhcp-client because the ISC DHCP client is no longer maintained upstream. NetworkManager already shipped an internal DHCP client and used it by default in earlier RHEL releases, so the external dhclient helper was retired rather than replaced with another standalone client package.

Can I Install dhclient on RHEL 10?

Try a normal repository install with dnf:

sudo dnf install dhcp-client

Updating Subscription Management repositories.
Last metadata expiration check: 0:31:11 ago on Mon 21 Sep 2026 06:21:39 PM IST.
No match for argument: dhcp-client
Error: Unable to find a match: dhcp-client

Supported RHEL 10 repositories do not ship dhcp-client. Do not pull an old RHEL 9 dhcp-client RPM into RHEL 10 to restore the old workflow. Use NetworkManager’s internal DHCP client instead. You do not need to install a replacement package for this role.

What Replaces dhclient in RHEL 10?

NetworkManager owns the connection lifecycle and runs an internal DHCP client in-process. There is no separate dhclient binary to start, stop, or pass interface names to.

  ┌─────────────┐      ┌──────────────────────────┐      ┌──────────┐
  │ DHCP server │ ───► │ NetworkManager           │ ───► │ enp0s8   │
  │ (lease)     │      │ internal DHCP client     │      │ (iface)  │
  └─────────────┘      └──────────────────────────┘      └──────────┘

The DHCP server still supplies the lease; the difference is that NetworkManager now performs the DHCP client work itself.

The old model looked like this:

  ┌─────────────┐      ┌──────────┐      ┌──────────┐
  │ DHCP server │ ───► │ dhclient │ ───► │ enp0s8   │
  └─────────────┘      └──────────┘      └──────────┘

Previously, NetworkManager could delegate DHCP to the external dhclient process. RHEL 10 removes that option, so NetworkManager handles DHCP internally.

On my VirtualBox lab I keep SSH on NAT (enp0s3) and run DHCP cycle tests on host-only enp0s8, so nmcli connection down never drops the management session — the same NAT plus host-only layout as SSH into a VirtualBox VM.

Replace Common dhclient Commands on RHEL 10

There is no perfect one-to-one map from dhclient flags to nmcli. NetworkManager owns the full connection lifecycle, so you work with profiles instead of invoking a standalone DHCP client.

Deactivating a NetworkManager connection is not an exact replacement for dhclient -r. It stops using the DHCP-configured connection, but the DHCP protocol behavior is not necessarily identical.

Do not treat nmcli device reapply as the generic replacement for dhclient -r && dhclient. reapply updates the active device from connection settings you already changed; it is not documented as a general way to force a new DHCP transaction. Prefer deactivate/reactivate when you intentionally need a fresh negotiation.

Configure DHCP with nmcli

List profiles and pick the one bound to your interface:

nmcli connection show

NAME             UUID                                  TYPE      DEVICE
enp0s3           e5c9e04d-e7ac-3c7e-a7c7-1809bba0b686  ethernet  enp0s3
enp0s8           3c55dd51-6081-41cc-9d23-5e5752edd166  ethernet  enp0s8
Internal-LAN     5674a787-accc-3200-9f56-177cd5c693f3  ethernet  --
lo               4e3479b0-7a52-4f47-affd-ec14e8e31045  loopback  lo

The DEVICE column is the interface. The NAME column is the connection profile. On my host the active profile for the test NIC is also named enp0s8 (Internal-LAN is an unused spare). Set IPv4 to automatic (DHCP):

sudo nmcli connection modify enp0s8 ipv4.method auto

Bring the connection up so the setting takes effect:

sudo nmcli connection up enp0s8

Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/9)

successfully activated means NetworkManager applied the profile and completed IPv4 setup for that device. For a permanent static address instead of DHCP, use the static IP Rocky Linux guide rather than this replacement workflow.

Force a New DHCP Request with NetworkManager

NetworkManager automatically renews active leases while the connection stays up. You normally do not run a manual renew command the way you did with dhclient.

If you need to force a new DHCP transaction immediately, deactivate and reactivate the connection. This restarts the NetworkManager connection and triggers a fresh DHCP negotiation. It is not a direct semantic equivalent of a DHCP lease renewal operation.

This interrupts connectivity on that interface, so do not run it against the NIC that carries your only SSH session.

Deactivate the test profile:

sudo nmcli connection down enp0s8

Connection 'enp0s8' successfully deactivated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/7)

successfully deactivated means that profile is down and NetworkManager is no longer holding the previous DHCP configuration on that connection. Activate it again:

sudo nmcli connection up enp0s8

Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/9)

The profile is active again. Watch the DHCP negotiation in the NetworkManager journal (from another console if you ran the cycle live):

sudo journalctl -u NetworkManager --since '1 min ago' --no-pager | grep -iE 'dhcp4 \(enp0s8\)'

Sep 21 18:53:23 vm1.lab.example NetworkManager[26772]: <info>  [1789997003.4006] dhcp4 (enp0s8): canceled DHCP transaction
Sep 21 18:53:23 vm1.lab.example NetworkManager[26772]: <info>  [1789997003.4007] dhcp4 (enp0s8): activation: beginning transaction (timeout in 45 seconds)
Sep 21 18:53:23 vm1.lab.example NetworkManager[26772]: <info>  [1789997003.4007] dhcp4 (enp0s8): state changed no lease
Sep 21 18:53:24 vm1.lab.example NetworkManager[26772]: <info>  [1789997004.7697] dhcp4 (enp0s8): activation: beginning transaction (timeout in 45 seconds)
Sep 21 18:53:24 vm1.lab.example NetworkManager[26772]: <info>  [1789997004.7844] dhcp4 (enp0s8): state changed new lease, address=192.168.56.116, acd pending
Sep 21 18:53:24 vm1.lab.example NetworkManager[26772]: <info>  [1789997004.9774] dhcp4 (enp0s8): state changed new lease, address=192.168.56.116

Those new lease lines replace the verbose dhclient -v transcript most admins used before. For broader restart patterns (nmcli networking, systemctl restart NetworkManager), see restart networking on RHEL.

View DHCP Lease, Gateway, and DNS

Use NetworkManager’s device view for address, gateway, DNS, and the important DHCP options:

nmcli -f IP4,DHCP4 device show enp0s3

Sample output (trimmed):

IP4.ADDRESS[1]:                         10.0.2.15/24
IP4.GATEWAY:                            10.0.2.2
IP4.DNS[1]:                             192.168.0.1
IP4.DOMAIN[1]:                          lab.example
DHCP4.OPTION[2]:                        dhcp_lease_time = 86400
DHCP4.OPTION[3]:                        dhcp_server_identifier = 10.0.2.2
DHCP4.OPTION[5]:                        domain_name_servers = 192.168.0.1
DHCP4.OPTION[6]:                        expiry = 1790083399
DHCP4.OPTION[7]:                        ip_address = 10.0.2.15
DHCP4.OPTION[21]:                       routers = 10.0.2.2
DHCP4.OPTION[27]:                       subnet_mask = 255.255.255.0

I used enp0s3 here because VirtualBox NAT supplies a gateway and DNS. The host-only enp0s8 lease on my lab returns an address without a gateway, which is normal for that DHCP server.

Useful companion checks:

ip -4 route

default via 10.0.2.2 dev enp0s3 proto dhcp src 10.0.2.15 metric 100
10.0.2.0/24 dev enp0s3 proto kernel scope link src 10.0.2.15 metric 100
192.168.56.0/24 dev enp0s8 proto kernel scope link src 192.168.56.116 metric 101

The default route came from DHCP on enp0s3. DNS that NetworkManager wrote for the resolver is in /etc/resolv.conf:

cat /etc/resolv.conf

# Generated by NetworkManager
search lab.example
nameserver 192.168.0.1

The Generated by NetworkManager header means NetworkManager manages this file. In this example, the DNS information came through the active connection and its DHCP options. Lease state under /var/lib/NetworkManager/ is private to NetworkManager. Prefer nmcli and the journal over digging in those files for day-to-day checks.

Confirm DHCP Works Without a dhclient Process

Prove there is no dhclient process while the interface already has a DHCP address.

pgrep -a dhclient

pgrep prints nothing when no matching process exists. NetworkManager should be active:

systemctl is-active NetworkManager

active

active means the daemon that owns DHCP on RHEL 10 is running. Confirm the test profile uses DHCP (ipv4.method auto):

nmcli -g ipv4.method connection show enp0s8

auto

auto is NetworkManager’s DHCP setting for IPv4. Read the address and DHCP options it learned for the device:

nmcli -f GENERAL.STATE,IP4.ADDRESS,DHCP4 device show enp0s8

Sample output (trimmed):

GENERAL.STATE:                          100 (connected)
IP4.ADDRESS[1]:                         192.168.56.116/24
DHCP4.OPTION[2]:                        dhcp_lease_time = 600
DHCP4.OPTION[3]:                        dhcp_server_identifier = 192.168.56.100
DHCP4.OPTION[5]:                        ip_address = 192.168.56.116
DHCP4.OPTION[23]:                       subnet_mask = 255.255.255.0

The interface is connected, and the DHCP4.OPTION fields confirm NetworkManager obtained this address through DHCP. No dhclient process is involved.

Cross-check with ip:

ip -4 addr show enp0s8

3: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    altname enx080027c44f20
    inet 192.168.56.116/24 brd 192.168.56.255 scope global dynamic noprefixroute enp0s8
       valid_lft 598sec preferred_lft 598sec

The dynamic flag is consistent with a dynamically assigned address. The DHCP4.OPTION fields above specifically confirm that NetworkManager obtained this address through DHCP.

Check Which DHCP Client NetworkManager Actually Uses

Print the effective NetworkManager configuration:

NetworkManager --print-config

# NetworkManager configuration: /etc/NetworkManager/NetworkManager.conf, /usr/lib/NetworkManager/conf.d/{00-server.conf,99-nvme-nbft-no-ignore-carrier.conf}, /run/NetworkManager/conf.d/15-carrier-timeout.conf

[main]
# plugins=
# rc-manager=auto
# migrate-ifcfg-rh=false
# auth-polkit=true
# dhcp=internal
# iwd-config-path=
no-auto-default=*
ignore-carrier=*
configure-and-quit=no

The commented # dhcp=internal line is the documented default. You do not need to set dhcp=internal unless you previously overrode it.

Search for any leftover dhcp= overrides:

sudo grep -Rni 'dhcp=' /etc/NetworkManager/NetworkManager.conf /etc/NetworkManager/conf.d/

An empty result means no admin drop-in is forcing a non-default DHCP plugin. The dhcp: init message is normally logged when NetworkManager starts. If NetworkManager has not restarted recently, searching the current boot is more reliable than limiting the journal to the last few minutes:

sudo journalctl -u NetworkManager -b --no-pager | grep -i 'dhcp: init'

Sep 21 18:53:18 vm1.lab.example NetworkManager[26772]: <info>  [1789996998.5386] dhcp: init: Using DHCP client 'internal'

NetworkManager --print-config tells you what was configured. The NetworkManager journal tells you which DHCP implementation was actually selected. On a healthy RHEL 10 host both should agree on internal.

What Happens to dhcp=dhclient on RHEL 10?

On RHEL 9 you could still put this in NetworkManager config:

[main]
dhcp=dhclient

That [main] override is obsolete on RHEL 10. I created a temporary drop-in on the lab host to see what happens today:

sudo tee /etc/NetworkManager/conf.d/99-lab-dhcp-dhclient.conf >/dev/null <<'EOF'
[main]
dhcp=dhclient
EOF

Restart NetworkManager so the drop-in is read from a fresh start:

sudo systemctl restart NetworkManager

Check the merged config first:

NetworkManager --print-config | grep -i dhcp

dhcp=dhclient

The merged config still shows the obsolete plugin name. Read the journal next for what NetworkManager actually selected:

sudo journalctl -u NetworkManager --since '30 sec ago' --no-pager | grep -iE 'dhcp: init'

Sep 21 18:53:00 vm1.lab.example NetworkManager[26421]: <warn>  [1789996980.3479] dhcp: init: DHCP client 'dhclient' not available
Sep 21 18:53:00 vm1.lab.example NetworkManager[26421]: <info>  [1789996980.3481] dhcp: init: Using DHCP client 'internal'

On RHEL 10.2 the setting still appears in --print-config, but NetworkManager warns that dhclient is unavailable and falls back to internal. DHCP still works.

That fallback means an upgraded system may keep networking instead of failing outright. It does not make dhcp=dhclient a valid RHEL 10 configuration. The setting is obsolete, it produces a warning, any dhclient-specific configuration under /etc/dhcp is ignored, and Leapp treats this setting as an upgrade inhibitor, so remove it on RHEL 9 before upgrading to RHEL 10.

Delete the drop-in (or remove the dhcp=dhclient line from every file under /etc/NetworkManager/):

sudo rm -f /etc/NetworkManager/conf.d/99-lab-dhcp-dhclient.conf

The drop-in file is gone. Restart again so NetworkManager reloads without it:

sudo systemctl restart NetworkManager

Confirm the effective DHCP setting is back to the commented default:

NetworkManager --print-config | grep -i dhcp

# dhcp=internal

That commented line is the healthy RHEL 10 state. Also review anything under /etc/dhcp. Custom dhclient.conf and related snippets will not drive NetworkManager’s internal client.

Troubleshoot DHCP Without dhclient

Start with a quick map of common symptoms, then use the commands below:

Replace dhclient -v with NetworkManager logging. Start with the journal:

sudo journalctl -fu NetworkManager

This follows the journal and does not exit on its own. Leave it running, then in another terminal reactivate the connection and watch for dhcp4 (…): state changed new lease or timeout messages.

Confirm the profile still asks for DHCP:

nmcli -g ipv4.method connection show enp0s8

auto

If the method is manual, the profile will not request a lease until you set ipv4.method auto again.

Check carrier and device state:

nmcli device status

DEVICE  TYPE      STATE                   CONNECTION
enp0s3  ethernet  connected               enp0s3
enp0s8  ethernet  connected               enp0s8
lo      loopback  connected (externally)  lo

If the device shows disconnected, unavailable, or unmanaged, fix that state first. NetworkManager cannot obtain a DHCP lease until it can manage and activate the interface. Also confirm a DHCP server is reachable on that segment (VirtualBox host-only DHCP, lab DHCP, or production scope).

If ordinary journal output is not detailed enough, raise NetworkManager logging for a short debug window. On the tested NetworkManager 1.56 build I used:

sudo nmcli general logging level DEBUG domains DHCP,IP,IP4,IP6

Logging domains can vary between NetworkManager releases, so treat these as the values verified on NetworkManager 1.56. Reproduce the activation, capture journalctl -u NetworkManager, then set logging back:

sudo nmcli general logging level INFO domains DEFAULT

That return to INFO / DEFAULT keeps everyday logs readable after you finish the debug window.

Replace Common dhclient.conf Settings Carefully

If you previously customized dhclient behavior in /etc/dhcp/dhclient.conf, those settings are not automatically transferred to NetworkManager’s internal DHCP client. Do not blindly copy that file into RHEL 10. NetworkManager does not provide a direct equivalent for every ISC dhclient directive.

A few connection properties cover common needs:

Example timeout change:

sudo nmcli connection modify enp0s8 ipv4.dhcp-timeout 30

Activate the profile again so the new timeout applies on the next DHCP transaction. Only migrate settings you still need; leave the rest behind with dhclient.

Fix "Deprecated DHCP plugin configured" During RHEL 9→10 Upgrade

You do not need a full in-place upgrade to understand this check. On RHEL 9, Leapp can stop a RHEL 10 upgrade with:

Risk Factor: high (inhibitor)
Title: Deprecated DHCP plugin configured
Summary: NetworkManager is configured to use the "dhclient" DHCP module. In Red Hat Enterprise Linux 10, this setting will be ignored along with any dhcp-client specific configuration.
Remediation: [hint] Remove "dhcp=dhclient" line from "[main]" section from all configuration files in "/etc/NetworkManager". Review configuration in "/etc/dhcp", which will be ignored.

That report is specifically about dhcp=dhclient in NetworkManager config, not about missing packages on the target system. Remediation before you re-run the preupgrade check:

1. Search /etc/NetworkManager/ (and package drop-ins you manage) for dhcp=dhclient.
2. Remove those lines.
3. Review /etc/dhcp for custom dhclient behavior you still need, then express the equivalent in NetworkManager properties where possible.
4. Restart NetworkManager and confirm NetworkManager --print-config shows the internal default (or no forced dhcp=dhclient).
5. Re-run Leapp / the preupgrade report.

NetworkManager Internal DHCP vs dhclient

Upstream NetworkManager can be built with other DHCP backends, and some generic Linux guides mention dhcpcd. On RHEL 10, Red Hat supports only the NetworkManager-internal DHCP client. Do not treat dhcpcd as the supported RHEL replacement for dhclient.

Summary

On RHEL 10, dhclient is gone because dhcp-client was removed with the unmaintained ISC DHCP client. Packages are not in the supported repositories, so dnf install dhcp-client fails with No match for argument. NetworkManager’s internal DHCP client, already the default on RHEL 8 and 9, is the supported path, and no extra client package is required.

You configure DHCP by setting ipv4.method auto on a NetworkManager profile and activating that profile. NetworkManager renews leases automatically; if you intentionally need a new DHCP negotiation, deactivate and reactivate the connection. Verify the result with nmcli device show or the NetworkManager journal.

Before a RHEL 9→10 upgrade, remove every dhcp=dhclient line under /etc/NetworkManager so Leapp does not stop on Deprecated DHCP plugin configured, and review /etc/dhcp because those client snippets no longer apply. Keep Kea in mind only when you need a DHCP server; it is not a substitute for dhclient on the client host.

References

• The dhcp-client package has been removed — RHEL 10.0 Release Notes
• Networking — Considerations in adopting RHEL 10
• Configuring an Ethernet connection — RHEL 10
• Leapp: Deprecated DHCP plugin configured
• NetworkManager.conf(5)