How to fix a network interface losing its IP on CentOS 7 (NetworkManager)

    Environment

    • OS: CentOS 7
    • NetworkManager version: 1.18.x

    Symptom

    A network interface (e.g. eth1) repeatedly loses its static IP address after a reboot or NetworkManager restart. The interface comes up at layer 2 (link UP, carrier on) but has no IP assigned. NetworkManager shows it as disconnected with no connection profile bound to it.

    $ nmcli device status
DEVICE  TYPE      STATE         CONNECTION
eth0    ethernet  connected     eth0
eth1    ethernet  disconnected  --
    $ ip addr show eth1
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ...
    link/ether 00:0c:29:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    (no inet address)

    Meanwhile, other interfaces (e.g. eth0) work correctly every time.

    Root Cause

    Two configuration errors combined to prevent the interface from getting its IP:

    1. ifcfg-rh plugin disabled in NetworkManager

    In /etc/NetworkManager/NetworkManager.conf, the plugins line was commented out:

    [main]
#plugins=ifcfg-rh,ibft

    With this line commented, NetworkManager does not read /etc/sysconfig/network-scripts/ifcfg-* files. Other interfaces may still work if they have a pre-existing NetworkManager connection profile in its internal database. However, any interface that relies solely on its ifcfg-* file will have no profile loaded.

    Without a valid profile, NetworkManager auto-generates a temporary "Wired connection 1" profile with ipv4.method: auto (DHCP), which will either get a random DHCP address or fail silently — never applying the intended static IP.

    2. Invalid BOOTPROTO value in the ifcfg file

    Even after re-enabling the ifcfg-rh plugin, NetworkManager may refuse to load the file. The journal will show:

    ifcfg-rh: loading "/etc/sysconfig/network-scripts/ifcfg-eth1" fails: Unknown BOOTPROTO 'no'

    NetworkManager 1.18.x expects BOOTPROTO=none (not no) for static IP configuration. The value no is accepted by the legacy network service but not by NetworkManager's ifcfg-rh plugin.

    Fix

    Step 1: Enable the ifcfg-rh plugin

    Edit /etc/NetworkManager/NetworkManager.conf and ensure the plugins line is uncommented:

    [main]
plugins=ifcfg-rh,ibft

    Step 2: Fix BOOTPROTO in the ifcfg file

    Edit the corresponding file in /etc/sysconfig/network-scripts/ and change BOOTPROTO=no to BOOTPROTO=none.

    Example corrected ifcfg-eth1:

    TYPE=Ethernet
PROXY_METHOD=none
BROWSER_ONLY=no
BOOTPROTO=none
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=no
IPV6_AUTOCONF=no
IPV6_DEFROUTE=no
IPV6_FAILURE_FATAL=no
IPV6_ADDR_GEN_MODE=stable-privacy
NAME=eth1
UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
DEVICE=eth1
ONBOOT=yes
IPADDR=192.168.1.254
NETMASK=255.255.255.252

    Step 3: Remove any auto-generated profile and reload

    # Delete the auto-generated DHCP profile if it exists
nmcli connection delete 'Wired connection 1'

# Restart NetworkManager
systemctl restart NetworkManager

    Step 4: Verify

    $ nmcli device status
DEVICE  TYPE      STATE      CONNECTION
eth0    ethernet  connected  eth0
eth1    ethernet  connected  eth1

$ ip addr show eth1
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> ...
    inet 192.168.1.254/30 brd 192.168.1.255 scope global noprefixroute eth1

    Diagnostic Commands

    Command Purpose
    ip addr show eth1 Check if the interface has an IP
    nmcli device status See NM state per interface
    nmcli connection show List loaded NM profiles
    cat /etc/NetworkManager/NetworkManager.conf Check if ifcfg-rh plugin is enabled
    cat /etc/sysconfig/network-scripts/ifcfg-* Inspect interface config files
    journalctl -u NetworkManager Read NM logs for load errors
    nmcli connection load /etc/sysconfig/network-scripts/ifcfg-eth1 Attempt manual load to trigger error

    Key Takeaway

    1. Always verify the ifcfg-rh plugin is enabled — if commented out, NM silently ignores all ifcfg files.
    2. Use BOOTPROTO=none, not BOOTPROTO=no — the legacy network service accepts both, but NetworkManager's ifcfg-rh plugin only accepts none.
    3. Check journalctl -u NetworkManager — NM logs the exact reason it rejects a config file, which is the fastest path to diagnosis.
    Published