Levantar y asegurar persistencia de la interfaz de red en RHEL 10 (guía técnica con nmcli)

En entornos RHEL 10 es común encontrar incidencias donde, tras un reinicio, la interfaz queda sin dirección IP o en estados como disconnected / unmanaged. Esto suele deberse a una asociación incorrecta entre el perfil de conexión de NetworkManager y el dispositivo físico/virtual, a autoconnect deshabilitado, o a que el servicio NetworkManager no está gestionando el device.

Objetivo: validar la interfaz (p. ej. ens160), corregir la vinculación del perfil, habilitar DHCP (IPv4), desactivar IPv6 si no aplica, y garantizar conectividad y persistencia tras reinicio mediante connection.autoconnect y el arranque automático de NetworkManager.

Antes de empezar (muy importante)

En Linux hay dos conceptos distintos:

• Device (dispositivo): la interfaz real del sistema, ej. ens160, enp0s3, eth0.
• Connection (perfil): una configuración guardada en NetworkManager, ej. Wired connection 1, ens160, etc.

A veces el perfil NO se llama igual que el device, y ahí se rompe todo si modificas “ens160” cuando tu conexión real se llama distinto. Por eso primero identificamos ambos.

1) Ver interfaces reales (kernel)

ip link

Qué estás buscando:

• El nombre real de la interfaz (ej. ens160).
• Su estado: UP / DOWN.
• Que exista (si no aparece, el problema puede ser del hypervisor/driver).

2) Ver dispositivos que conoce NetworkManager

nmcli device

Cómo interpretar:

• connected : ya hay una conexión activa.
• disconnected : el device existe pero no está conectado.
• unavailable : suele ser cable virtual desconectado, NIC deshabilitada, etc.
• unmanaged : NetworkManager NO está controlando esa interfaz (hay que corregirlo).

3) Ver perfiles de conexión (NetworkManager)

nmcli connection show

Qué estás buscando:

• El NAME de la conexión que corresponde a tu device.
• En la columna DEVICE (si aparece) verás a cuál interfaz está amarrada.

Tip útil (más claro):

nmcli -f NAME,DEVICE,STATE connection show

4) Asegurar que la interfaz existe (ejemplo: ens160)

ip link show ens160

Si no existe, no es un tema de nmcli: es el hypervisor (VMware), el adaptador, el driver, o la NIC deshabilitada.

5) Amarrar el perfil al device correcto (clave cuando “se desasocia”)

sudo nmcli connection modify ens160 connection.interface-name ens160

¿Qué hace esto?

Le dice a NetworkManager:
“Este perfil de conexión debe aplicarse a esta interfaz exacta (ens160)”.

Esto evita que el perfil se quede “volando” o que intente engancharse a otra NIC.

Si tu conexión NO se llama ens160, primero detecta el nombre real con:

nmcli connection show

y usa ese NAME en los comandos.

6) Configurar IPv4 en automático (DHCP)

sudo nmcli connection modify ens160 ipv4.method auto

¿Qué significa?

• auto = pide IP por DHCP al router/red.
• Ideal para VMs y redes corporativas comunes.

7) Ignorar IPv6 (si no lo usas)

sudo nmcli connection modify ens160 ipv6.method ignore

¿Por qué hacerlo?

• Si tu red no usa IPv6, ignorarlo evita delays raros o configuraciones mezcladas.
• Si sí usas IPv6, mejor déjalo en auto.

8) Bajar y subir la conexión para aplicar cambios

sudo nmcli connection down ens160
sudo nmcli connection up ens160

¿Qué logra?

• Reinicia el perfil de red sin reiniciar el servidor.
• Fuerza a pedir IP de nuevo y aplicar parámetros.

9) Verificación obligatoria: ¿ya tienes IP?

ip a show ens160

Debes ver algo como:

• inet X.X.X.X/.. (IPv4 asignada)
• estado UP

10) Confirmar el nombre exacto del perfil (por si te equivocaste)

nmcli connection show

Si ves que el perfil se llama “Wired connection 1”, entonces todo lo anterior debió ejecutarse con ese nombre, no con ens160.

Ejemplo:

sudo nmcli connection modify "Wired connection 1" ipv4.method auto

11) Habilitar autoconnect (CLAVE para que sobreviva reinicios)

sudo nmcli connection modify ens160 connection.autoconnect yes

¿Qué hace?

• Le dice a NetworkManager: “Conéctate solo al arrancar”.

12) Asegurar que NetworkManager gestione el device (si salía unmanaged)

sudo nmcli device set ens160 managed yes

¿Cuándo se usa?

• Cuando nmcli device muestra unmanaged.
• Sin esto, aunque el perfil esté bien, NM lo ignora.

13) Habilitar NetworkManager al arranque y reiniciarlo

sudo systemctl enable NetworkManager
sudo systemctl restart NetworkManager

¿Qué logra?

• enable → que el servicio inicie siempre al boot.
• restart → aplica todo de inmediato.

14) Verificar que quedó persistente (autoconnect)

nmcli connection show ens160 | grep autoconnect

Debes ver algo como connection.autoconnect: yes.

15) Prueba final (la importante)

Reinicia:

reboot

Cuando regrese:

ip a
ip route
ping -c 3 8.8.8.8
ping -c 3 google.com

Cómo interpretar:

• ping 8.8.8.8 funciona = hay red (ruta/ICMP ok).
• ping google.com funciona = DNS ok.
• Si 8.8.8.8 falla = problema de red/ruta/gateway/hypervisor.
• Si 8.8.8.8 funciona pero google.com falla = problema de DNS.

Extra: mini sección “si algo falla”

Si sigue sin dar IP, revisa esto rápido:

Estado del device:

nmcli device

Logs de NetworkManager (muy reveladores):

journalctl -u NetworkManager -b --no-pager | tail -200

Ver si tu conexión está activa:

nmcli connection show --active