/etc/sysconfig/network-scripts/ or nmcli, ensure the service is enabled, and check physical link status using standard diagnostic tools before attempting to restart the network stack.
Understanding Configuration Changes Between RHEL Versions
Administrators migrating from older versions of Red Hat Enterprise Linux may encounter unexpected behavior when upgrading to RHEL 8.6. One significant change involves the handling of network interfaces and the default network management stack. In previous iterations, such as RHEL 8.4, the traditional network service was more prominently used for static configurations, while DHCP requests were handled by distinct daemon processes with predictable interface naming conventions.
In RHEL 8.6, NetworkManager is the primary controller for all networking tasks. It enforces strict consistency between the kernel interface name (seen via ip link) and the connection profile stored in its database. If a profile exists for an interface that no longer has that name due to driver updates or hardware changes, the DHCP client will not initiate a request because it believes the interface is inactive or unmanaged. This discrepancy is the root cause of many "address not obtained" errors in updated systems.
Verifying Interface Names and Status
The first step in troubleshooting is to identify which physical ports are actually active and recognized by the operating system. Legacy commands like ifconfig may still be available but are deprecated and can sometimes hide critical details about the carrier state or MTU settings.
- Open a terminal session with root privileges.
- Run the command
ip addr showto list all interfaces and their assigned IP addresses. - Look for interfaces with a state of
UP. Note the interface name (e.g.,eth0,ens192, orenp3s0).
If the interface shows a state of DOWN or lacks a MAC address, the issue may be physical. Check the cable connections and switch port indicators. If the interface is listed but shows no IP address, proceed to check the NetworkManager status.
Checking NetworkManager Service State
Since NetworkManager controls DHCP in RHEL 8.6, ensuring the service is running and enabled is crucial. A stopped or disabled service will prevent any automatic configuration.
systemctl status NetworkManager
systemctl is-enabled NetworkManagerIf the service is inactive, start it immediately:
sudo systemctl start NetworkManager
sudo systemctl enable NetworkManagerAfter starting the service, wait a few seconds for it to initialize, then check the journal logs for specific errors related to DHCP discovery packets.
Inspecting Connection Profiles
Even if the service is running, the specific connection profile for your interface might be misconfigured. Use nmcli to inspect the current profiles.
nmcli connection showIdentify the profile associated with your interface. Look for the following attributes:
- TYPE: Should be
802-3-ethernetfor wired connections. - CONNECTION.AUTOCONNECT: Must be set to
yes. - IPV4.METHOD: Must be set to
autofor DHCP.
If the method is set to manual or disabled, update it using the following command, replacing profile-name with the actual name found in the previous step:
nmcli connection modify profile-name ipv4.method autoOnce modified, reactivate the connection to trigger a new DHCP request:
nmcli connection up profile-nameAnalyzing Logs for DHCP Failures
If the above steps do not resolve the issue, examine the system logs for detailed error messages. The journalctl utility provides access to real-time logging data from NetworkManager and dhclient.
journalctl -u NetworkManager -fLook for entries containing "DHCP" or "NCKit". Common errors include "No DHCP offers received" or "Connection timed out". These messages indicate that the server is unreachable or the client is not broadcasting correctly. In such cases, verify that the VLAN tagging or firewall rules on the RHEL host are not blocking UDP ports 67 and 68.
For deeper insights into packet loss, consider reviewing our guide on Understanding DHCP and How It Works with Direct Ethernet Link for Hosts to ensure your network segment supports broadcast traffic appropriately.
Restoring Default Configuration
As a last resort, you can delete the existing problematic profile and allow NetworkManager to recreate it automatically upon reconnection. This removes any corrupted settings.
nmcli connection delete profile-name
nmcli device connect interface-nameThis forces NetworkManager to generate a fresh configuration based on the current hardware state. Ensure that any custom DNS or route settings required by your environment are reapplied after this process.
Frequently Asked Questions
Why did my interface name change after updating to RHEL 8.6?
RHEL 8 introduced consistent naming schemes based on firmware, topology, and slot index rather than arbitrary assignments. When drivers are updated or hardware is swapped, the kernel may assign a new name. You must update your connection profile to match the new name to restore connectivity.
Can I use the old network-scripts directory in RHEL 8.6?
While the files may still exist, they are largely ignored by default in favor of NetworkManager's internal database. Manually editing files in /etc/sysconfig/network-scripts/ without using nmtui or nmcli can lead to synchronization issues where the GUI and CLI show different states.
What should I do if DHCP times out repeatedly?
A timeout usually indicates a physical layer issue or a blocked broadcast. Verify the cable integrity, check for switch port security features like Port Security or BPDU filtering, and ensure that no local firewall rule is dropping UDP port 67 traffic.
How do I verify if the DHCP client is actually running?
You can check for active dhclient processes using ps aux | grep dhclient. However, in modern RHEL, NetworkManager manages the lease internally. Checking the lease file at /run/NetworkManager/dhclient-*.lease confirms if a valid lease has been acquired.
Is there a way to force a quick renew of the IP address?
Yes, you can release and renew the lease manually using nmcli connection down profile-name followed immediately by nmcli connection up profile-name. This simulates a full disconnect and reconnect cycle, forcing a fresh DHCP discovery.