Debian 13: el nuevo nombre de interfaz rompió la red — nombres estables que resisten reinicios (caso #67)

Cómo se manifiesta cuando falla el nombrado de interfaces

El modo de fallo es brutalmente consistente: el sistema arranca bien, pero tu pila de red está configurada contra un nombre que ya no coincide con un dispositivo real. La unidad está “arriba” pero inalcanzable, o accesible solo en una red de reserva, o accesible únicamente por fuera de banda.

Síntomas típicos en Debian 13

• Host remoto inalcanzable tras reinicio, pero la consola muestra un prompt de inicio de sesión normal.
• Errores de servicio de red como “Cannot find device” o “Unknown interface” provenientes de ifupdown, systemd-networkd o NetworkManager.
• Enlace físicamente arriba (el switch muestra enlace), pero no hay IP configurada.
• Rutas ausentes: la ruta por defecto no está configurada porque la interfaz prevista nunca subió.
• Dispositivos de bonding/VLAN/bridge faltantes: si cambia el nombre de la interfaz base, cualquier interfaz apilada también falla.

Los problemas de nombrado de interfaces son el tipo de bug que te hace dudar de la realidad. Tu archivo de configuración es correcto. El cable está bien. El switch está bien. El servidor está bien. Simplemente está hablando con otro sustantivo.

Broma #1: Los nombres de interfaz “predecibles” son como reglas de firewall “temporales”: predecibles solo si nunca cambias nada.

Datos interesantes y contexto histórico (por qué sigue ocurriendo)

El nombrado de interfaces es uno de esos temas de Linux donde las opciones predeterminadas han cambiado varias veces, y cada cambio fue “para mejor” de una forma que sigue molestando a los operadores.

1. Linux solía usar por defecto eth0, eth1, … según el orden de descubrimiento, lo que puede invertirse cuando los controladores se cargan en distinto orden o cambia el hardware.
2. Systemd introdujo “nombres predecibles de interfaces de red” para evitar la ruleta de eth0, basando nombres en la topología firmware/PCI (por ejemplo, enp3s0).
3. Debian adoptó los nombres predecibles hace años, pero el resultado real depende de tablas del firmware, ajustes de BIOS y si reglas udev o archivos .link anulan los valores predeterminados.
4. Hay múltiples esquemas de nombrado: por ruta PCI (enpXsY), por índice onboard (eno1), por slot (ens1), por MAC (enx...) y por enumeración clásica del kernel (eth0).
5. Imágenes cloud a menudo usan coincidencia por MAC porque la “misma” NIC virtual puede presentar diferentes direcciones PCI según la versión del hypervisor y el tipo de máquina.
6. Las actualizaciones de firmware pueden cambiar la información SMBIOS/ACPI, lo que puede alterar sutilmente el sistema de nombres que systemd considera “predecible”.
7. Initramfs importa: si necesitas red en el arranque temprano (root iSCSI, root NFS, desbloqueo remoto), los cambios de nombre pueden romper antes de que el espacio de usuario tenga oportunidad de recuperarse.
8. Los contenedores complican el diagnóstico: puedes estar viendo eth0 dentro de un namespace mientras el host renombró la NIC real bajo tu automatización.
9. Las NICs en bonding y los bridges amplifican el radio del fallo: un rename puede romper esclavos de bond, subinterfaces VLAN, bridges, reglas de firewall, monitorización y las suposiciones de la gestión de configuración.

Guía de diagnóstico rápido (comprueba primero/segundo/tercero)

Esta es la secuencia “deja de adivinar”. Está optimizada para el caso común: el servidor está arriba, pero la red no se configuró porque cambió el nombre de la NIC.

Primero: confirma que el sistema ve una NIC y cómo se llama ahora

• Ejecuta ip -br link y ip -br addr para listar interfaces y cuáles tienen direcciones.
• Comprueba networkctl list si usas systemd-networkd.
• Busca un “nuevo” enp*/eno*/ens* que tenga la MAC esperada.

Segundo: confirma qué espera tu configuración de red

• ifupdown: grep -R "iface" /etc/network/interfaces*
• systemd-networkd: ls /etc/systemd/network e inspecciona *.network
• NetworkManager: nmcli con show y busca connection.interface-name

Tercero: prueba el mapeo (MAC ↔ nombre de interfaz) y decide el identificador estable

• Usa ip link o udevadm info para mapear MAC y ruta PCI.
• Elige un enfoque: archivos .link de systemd por MAC, coincidencia por ruta PCI, o desactivar naming predecible (rara vez lo mejor), según tu entorno.

Una vez puedas responder “¿cómo se llama la NIC ahora?” y “¿qué espera la configuración?”, lo demás es mecánica.

Tareas prácticas: comandos, salidas y decisiones (12+)

Estos son controles de calidad para producción. Cada uno incluye lo que significa la salida y qué decisión tomar a continuación. Ejecútalos en consola si la máquina está aislada. Si todavía tienes SSH, hazlos de todos modos: los renombres de interfaz tienden a reaparecer en el siguiente reinicio, no durante el incidente actual.

Tarea 1: Lista rápida de interfaces y su estado operativo

cr0x@server:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
enp4s0           DOWN           3c:fd:fe:aa:bb:cc <BROADCAST,MULTICAST>
enp5s0           UP             3c:fd:fe:11:22:33 <BROADCAST,MULTICAST,UP,LOWER_UP>

Significado: enp5s0 tiene carrier y está arriba. enp4s0 existe pero está abajo (o no conectado o administrativamente down).

Decisión: Centra la atención en enp5s0 como tu NIC primaria probable. A continuación, confirma si tiene la IP esperada.

Tarea 2: Comprueba qué interfaces tienen direcciones IP

cr0x@server:~$ ip -br addr
lo               UNKNOWN        127.0.0.1/8 ::1/128
enp4s0           DOWN
enp5s0           UP             192.0.2.10/24 2001:db8:10::10/64

Significado: La red está configurada en enp5s0. Si esperabas que estuviera en enp4s0 o enp3s0, tu configuración está desincronizada.

Decisión: Si sigues offline, el problema podría ser rutas, firewall, VLANs o gateway equivocado—no solo el nombrado. Comprueba el enrutamiento a continuación.

Tarea 3: Valida el enrutamiento (la ruta por defecto suele faltar)

cr0x@server:~$ ip route
default via 192.0.2.1 dev enp5s0
192.0.2.0/24 dev enp5s0 proto kernel scope link src 192.0.2.10

Significado: La ruta por defecto existe a través de enp5s0. Si no ves la línea default, tu configuración de red no se aplicó o DHCP no se ejecutó.

Decisión: Si falta la ruta por defecto, revisa los logs y la configuración del gestor de red (ifupdown/networkd/NM). Si existe, prueba la conectividad (ARP, reachability del gateway).

Tarea 4: Identifica qué nombre espera tu configuración (ifupdown)

cr0x@server:~$ grep -R "iface " /etc/network/interfaces /etc/network/interfaces.d 2>/dev/null
/etc/network/interfaces:iface enp3s0 inet static
/etc/network/interfaces:iface enp3s0 inet6 static

Significado: Tu configuración espera enp3s0, pero el kernel/systemd actualmente expone enp5s0. Ese desajuste por sí solo puede dejarte aislado.

Decisión: O actualizas la configuración al nuevo nombre (rápido pero frágil), o aplicas un nombrado estable para que el nombre esperado vuelva en cada arranque (preferible). No “edites y ya” en flotas salvo que disfrutes rehacer trabajo.

Tarea 5: Para systemd-networkd, lista el estado de link y lo que networkd piensa

cr0x@server:~$ networkctl list
IDX LINK   TYPE     OPERATIONAL SETUP
  1 lo     loopback carrier     unmanaged
  2 enp5s0 ether    routable    configured
  3 enp4s0 ether    no-carrier  unmanaged

Significado: networkd configuró enp5s0. Si la interfaz prevista está “unmanaged”, tus reglas de emparejamiento la pasaron por alto (a menudo debido a un rename).

Decisión: Inspecciona los archivos *.network buscando Name= o MACAddress= en el bloque [Match]. Planea un identificador estable.

Tarea 6: Para NetworkManager, comprueba qué conexión está ligada a qué interfaz

cr0x@server:~$ nmcli -f NAME,DEVICE,TYPE,STATE con show --active
NAME            DEVICE  TYPE      STATE
prod-uplink     enp5s0  ethernet  activated

Significado: Un perfil de conexión llamado prod-uplink está activo en enp5s0. Si nada está activo, NM puede estar esperando un nombre de interfaz específico.

Decisión: Revisa nmcli con show prod-uplink para ver connection.interface-name. Si está configurado con el nombre antiguo, corrígelo o usa nombrado estable.

Tarea 7: Mapear direcciones MAC a nombres de interfaz (el ancla de la cordura)

cr0x@server:~$ ip -br link | awk '{print $1, $3}'
lo 00:00:00:00:00:00
enp4s0 3c:fd:fe:aa:bb:cc
enp5s0 3c:fd:fe:11:22:33

Significado: Ahora puedes emparejar la MAC desde tu inventario/puerto del switch/política de seguridad con el nombre de dispositivo en Linux.

Decisión: Si tu automatización conoce MACs de forma fiable, empareja por MAC (archivo .link de systemd o reglas de match en networkd). Si las MAC cambian (algunas nubes), prefiere otros atributos estables.

Tarea 8: Obtén las pistas ID_NET_NAME_* que systemd/udev calculó

cr0x@server:~$ udevadm test-builtin net_id /sys/class/net/enp5s0 2>/dev/null | grep ID_NET_NAME
ID_NET_NAME_MAC=enx3cfdfe112233
ID_NET_NAME_PATH=enp5s0
ID_NET_NAME_SLOT=ens3

Significado: udev calculó múltiples nombres candidatas estables. Tu nombre actual es enp5s0 (basado en la ruta), pero también tiene una sugerencia por slot ens3 y por MAC enx....

Decisión: Elige cuál es más estable en tu entorno. Los servidores físicos suelen ir bien con nombres por slot o onboard. Las VMs pueden preferir nombres por MAC o coincidencia explícita.

Tarea 9: Ve la ruta PCI y el driver de la NIC (ayuda a explicar renombres)

cr0x@server:~$ lspci -nnk | grep -A3 -i ethernet
03:00.0 Ethernet controller [0200]: Intel Corporation I210 Gigabit Network Connection [8086:1533]
	Subsystem: Intel Corporation Device [8086:0001]
	Kernel driver in use: igb
	Kernel modules: igb

Significado: La dirección PCI 03:00.0 es la NIC uplink. Si el firmware/BIOS cambia el orden de buses o presenta otra topología, los nombres basados en ruta pueden variar.

Decisión: Si la topología PCI suele cambiar (servidores con ajustes de bifurcación, toggles SR-IOV o tarjetas add-in), no confíes solo en enpXsY. Considera nombres por slot o por MAC.

Tarea 10: Confirma si el naming predecible está activo vía cmdline del kernel

cr0x@server:~$ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-6.12.0-1-amd64 root=UUID=8b1d... ro quiet

Significado: No hay net.ifnames=0 ni biosdevname=0 como override. El naming predecible está activo (normal en Debian).

Decisión: No te apresures a desactivar el naming predecible globalmente. Es un último recurso. Prefiere nombrado explícito vía archivos .link o reglas de match.

Tarea 11: Busca logs relacionados con renombrado durante el arranque

cr0x@server:~$ journalctl -b -u systemd-udevd --no-pager | grep -E "renamed|ID_NET_NAME|link_config"
Dec 30 10:12:01 server systemd-udevd[322]: enp3s0: Interface name change detected, renamed to enp5s0

Significado: udev registró explícitamente un rename del antiguo al nuevo. Esta es tu prueba contundente.

Decisión: Implementa nombrado estable para que las referencias de configuración no queden obsoletas otra vez. También busca reglas udev personalizadas o archivos .link que puedan estar en conflicto.

Tarea 12: Comprueba si ya existen archivos .link de systemd que anulen nombres

cr0x@server:~$ ls -1 /etc/systemd/network/*.link 2>/dev/null
/etc/systemd/network/10-uplink.link

Significado: Ya tienes una anulación. Puede estar equivocada, obsoleta o en conflicto con los valores por defecto de la distro.

Decisión: Inspecciónala con cuidado. Si hace match demasiado amplio (por ejemplo, por driver solo), puedes renombrar una NIC equivocada tras cambios de hardware.

Tarea 13: Inspecciona un archivo .link y verifica que solo coincida con la interfaz prevista

cr0x@server:~$ sed -n '1,120p' /etc/systemd/network/10-uplink.link
[Match]
MACAddress=3c:fd:fe:11:22:33

[Link]
Name=uplink0

Significado: Este es el tipo bueno de anulación: coincide con una MAC única y asigna un nombre humano.

Decisión: Si la MAC es correcta, esto sobrevivirá reboots y reordenados de PCI. Si la MAC cambió (clonado de VM, reemplazo de NIC), actualiza el archivo y reconstruye dependencias de arranque temprano si es necesario.

Tarea 14: Aplica cambios de nombrado de forma segura (reiniciar udev y replug no siempre basta)

cr0x@server:~$ sudo udevadm control --reload
cr0x@server:~$ sudo udevadm trigger -c add -s net

Significado: Recarga reglas udev y dispara eventos de dispositivos de red. Los renombres pueden o no aplicarse en vivo; systemd es conservador renombrando interfaces activas.

Decisión: Planea una ventana de reinicio controlada tras implementar nombrado estable. Para sistemas remotos, asegura acceso fuera de banda o una conexión de reserva primero.

Tarea 15: Valida enlace y negociación (porque a veces no es un problema de nombres)

cr0x@server:~$ sudo ethtool enp5s0 | egrep "Link detected|Speed|Duplex"
Speed: 1000Mb/s
Duplex: Full
Link detected: yes

Significado: El enlace físico está bien. Si el enlace está abajo, el renombrado puede ser una cortina de humo y tu “nueva NIC” es la desconectada.

Decisión: Si el enlace está abajo, revisa el puerto del switch/VLAN/parches y valida que estás enlazando la MAC correcta al puerto correcto.

Causas raíz: cómo Debian 13 acaba con un “nuevo” nombre de NIC

Debian 13 no despertó y eligió el caos. Los nombres de interfaz se calculan a partir de la información que el SO recibe del kernel, firmware y reglas udev. Cuando cualquiera de esas entradas cambia, el nombre puede cambiar. Aquí están los desencadenantes comunes que he visto en entornos reales.

1) Cambió la topología PCI (hardware real o “hardware virtual”)

Los nombres basados en ruta como enp5s0 codifican el bus/dispositivo/función PCI. Si cambia la numeración del bus, cambia el nombre. Las razones incluyen actualizaciones de BIOS, alternar SR-IOV, cambiar ajustes de bifurcación PCIe, añadir/quitar tarjetas o incluso mover una NIC a otra ranura.

2) El firmware empezó a reportar índices de slot/onboard de forma distinta

Los nombres como eno1 (onboard) y ens1 (slot) dependen de índices provistos por el firmware. Cuando cambian esas tablas del firmware, el nombre “predecible” de Linux se vuelve predeciblemente distinto.

3) Un nuevo kernel/driver cambió el orden de enumeración

Este es el viejo problema de eth0 con otro disfraz. Incluso con naming predecible activado, hay casos límite donde el sistema recurre a otras heurísticas si la información preferida no está disponible suficientemente temprano.

4) Reglas udev o archivos .link en conflicto

Un equipo añade una regla amplia (“renombra todas las Intel NIC a lan0”), otro equipo añade otra regla amplia, y ahora gana la que se ejecute al final. No es malintencionado; es configuración distribuida.

5) Clonado de VMs y cambios de MAC

El nombrado por MAC es estable solo si la MAC es estable. Clona una VM y regenera MACs, y tus nombres enx... se convierten en nuevos. Cloud-init y herramientas del hypervisor a menudo intentan ayudar, a veces con éxito.

6) Networking en arranque temprano (initramfs) con una vista de nombres distinta

Si el sistema necesita la red en initramfs (desbloqueo remoto, root iSCSI), puedes tener fallos antes de montar el root filesystem. Corregir el nombrado solo en /etc puede no ayudar si initramfs aún espera el nombre antiguo.

Una cita para mantenerte honesto, parafraseando una idea de John Allspaw: La fiabilidad viene de cómo los sistemas realmente se comportan bajo el cambio, no de cómo deseamos que se comporten en los diagramas.

Estrategias de nombres estables que resisten reinicios

Tienes tres enfoques generales. Dos son buenos. Uno es tentador. Elige según el entorno, no según tu estado de ánimo.

Estrategia A (recomendada): archivos .link de systemd nombrando por MAC (u otras propiedades únicas)

Esta es la forma más directa de afirmar: “la interfaz con esta MAC se llama uplink0.” Es explícito, revisable y sobrevive reinicios. En hosts físicos donde las MAC no cambian, es aburrido en el mejor sentido.

Crear un archivo .link:

cr0x@server:~$ sudo tee /etc/systemd/network/10-uplink.link >/dev/null <<'EOF'
[Match]
MACAddress=3c:fd:fe:11:22:33

[Link]
Name=uplink0
EOF

Qué significa: systemd-udevd renombrará la interfaz que coincida con esa MAC a uplink0 durante la inicialización del dispositivo.

Decisión: Usa esto si la MAC es estable y única. No hagas match solo por driver o vendor a menos que busques diversión impredecible.

Luego ajusta tu configuración de red para usar uplink0:

• ifupdown: cambia iface enp3s0 por iface uplink0
• systemd-networkd: [Match] Name=uplink0
• NetworkManager: establece connection.interface-name uplink0 o enlaza por MAC

Estrategia B (a menudo la mejor para systemd-networkd): hacer match en .network por MAC y evitar renombrar

Si no te importa cómo el kernel llama a la interfaz, no la renombres—solo haz match. Esto reduce sorpresas por renombres y evita casos límite donde el renombrado interactúa con otros servicios.

Ejemplo de config networkd haciendo match por MAC:

cr0x@server:~$ sudo tee /etc/systemd/network/10-uplink.network >/dev/null <<'EOF'
[Match]
MACAddress=3c:fd:fe:11:22:33

[Network]
Address=192.0.2.10/24
Gateway=192.0.2.1
DNS=192.0.2.53
EOF

Qué significa: Independientemente de si la interfaz se llama enp5s0 hoy o enp2s0 tras la próxima actualización de BIOS, networkd la configurará.

Decisión: Prefiere esto para flotas donde no necesitas nombres amigables para humanos, solo comportamiento consistente.

Estrategia C (último recurso): desactivar el naming predecible y volver a eth0

Puedes forzar los nombres antiguos con parámetros del kernel. Puede ser útil por compatibilidad en entornos legacy muy controlados, pero es una regresión en la mayoría de flotas modernas. La orden de descubrimiento puede seguir cambiando. Vuelves a jugar a “¿qué NIC es eth0 hoy?”.

Parametros tentadores: añade net.ifnames=0 biosdevname=0 en GRUB.

cr0x@server:~$ sudo sed -i 's/GRUB_CMDLINE_LINUX="/GRUB_CMDLINE_LINUX="net.ifnames=0 biosdevname=0 /' /etc/default/grub
cr0x@server:~$ sudo update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.12.0-1-amd64
done

Qué significa: Indicas al kernel/udev que deje de usar nombres predecibles. Las interfaces probablemente se conviertan en eth0, eth1.

Decisión: Haz esto solo si tienes un entorno controlado y puedes verificar la estabilidad de la enumeración—o si compras tiempo para migrar fuera de configuraciones basadas en nombres.

Qué recomiendo realmente

Para servidores físicos: usa renombrado .link por MAC para obtener nombres significativos como uplink0, storage0, oob0. Te lo agradecerás durante incidentes.

Para VMs y cloud: usa match por MAC en tu gestor de red (o integración con cloud-init) y evita sobreajustar a la topología PCI que el hypervisor puede cambiar.

Broma #2: Si nombras interfaces según su ruta PCI, recuerda que la ruta cambia más rápido que la persona de guardia.

Tres mini-historias corporativas desde el terreno

Mini-historia 1: La caída causada por una suposición equivocada

Tenían una configuración limpia: hosts Debian, un par de NICs, VLANs para front-end y back-end, y una convención bienintencionada de que “el puerto izquierdo siempre es enp3s0.” No estaba documentado, pero se trataba como si fuera una ley de la física.

Luego vino una actualización de firmware desplegada en una tanda de servidores. No cambió drivers. No cambió el SO. Cambió cómo la BIOS describía la topología PCI. Al reiniciar, el “puerto izquierdo” se convirtió en enp4s0. La gestión de configuración seguía escribiendo /etc/network/interfaces para enp3s0.

La mitad de los servidores volvieron sin uplink. La otra mitad volvió “bien”, lo cual es el peor tipo de fallo parcial porque convence a la dirección de que es un caso aislado.

El postmortem encontró la falla real: asumieron que los nombres de interfaz eran lo bastante estables como para tratarlos como etiquetas en los puertos físicos. Pero Linux no mira tus dedos en el panel trasero; mira metadatos del firmware. La solución fue simple: emparejar la configuración de red por MAC y para los humanos renombrar a uplink0 vía .link. Lo difícil fue admitir que la suposición era el bug.

Mini-historia 2: La optimización que salió mal

Otra organización se cansó de los “nombres feos” de interfaz. Querían todo estandarizado: lan0, lan1, stor0. Objetivo razonable. La ejecución fue el problema.

Escribieron una regla udev haciendo match por driver y vendor PCI. Algo como “cualquier NIC Intel se convierte en lan0 salvo que ya exista.” Funcionó en su laboratorio. Funcionó en algunos servidores. Luego un refresh de hardware trajo NICs de doble puerto con el mismo driver. De pronto ambos puertos coincidían con la misma regla.

En el arranque, el “ganador” de lan0 variaba según el timing de enumeración. Su configuración de red se aplicaba a la NIC que agarraba el nombre primero. Algunos servidores arrancaron con redes de front-end y almacenamiento intercambiadas. Eso no es “caído”; es “peligrosamente arriba”.

Revirtieron la regla udev y la reemplazaron por archivos .link de systemd haciendo match por MAC, un archivo por interfaz, versionado en su repo de configuración. Menos ingenioso. Más correcto. También mucho menos emocionante durante auditorías.

Mini-historia 3: La práctica aburrida que salvó el día

Esta casi resulta decepcionante. Un equipo de plataforma tenía un estándar: cada construcción de servidor incluía un mapeo registrado de MACs de NIC a propósito (“uplink”, “storage”, “cluster”), almacenado junto con los datos de provisión del host. Se actualizaba cuando se reemplazaban NICs. Nada heroico. Solo contabilidad aburrida.

Cuando empezaron las actualizaciones a Debian 13, un puñado de hosts regresaron con interfaces renombradas debido a un cambio en ajustes de BIOS en un subconjunto de máquinas. La monitorización disparó: “host inalcanzable.” El on-call usó la consola fuera de banda, ejecutó ip -br link y emparejó inmediatamente las MAC con los roles conocidos.

No adivinaron. No cambiaron cables. No reescribieron configuraciones a ciegas. Aplicaron la solución estándar: regenerar los archivos .link desde el inventario, reiniciar una vez, confirmar rutas y gateway, cerrar incidente.

La lección no es glamorosa: el nombrado estable es mitad solución técnica, mitad higiene operativa. Si no sabes qué MAC es cuál, haces arqueología durante una interrupción.

Errores comunes (síntoma → causa raíz → solución)

1) “Tras reiniciar, SSH está muerto, pero la consola funciona.”

Causa raíz: la configuración de red referencia un nombre de interfaz obsoleto (enp3s0) que ya no existe.

Solución: identifica el nombre actual con ip -br link, luego implementa nombrado estable (systemd .link o match por MAC) y actualiza la configuración de red en consecuencia.

2) “El nombre de la NIC cambió, así que editamos la configuración. Cambió otra vez con la próxima actualización.”

Causa raíz: confiar en nombres basados en topología en un entorno donde la topología PCI no es estable (VMs, cambios de firmware, tarjetas add-in).

Solución: deja de perseguir nombres. Haz match por MAC en tu gestor de red, o renombra por MAC a un nombre de rol.

3) “Bond0 no se arma; los logs muestran que no puede esclavizar la interfaz.”

Causa raíz: cambiaron los nombres de los slaves del bond; la configuración del bond referencia esclavos antiguos.

Solución: haz match de slaves de bond por MAC (donde sea soportado) o aplica nombres estables a los slaves usando .link. Luego actualiza la configuración del bond para usar esos nombres estables.

4) “Interfaz VLAN faltante: enp3s0.100 no existe.”

Causa raíz: la interfaz base se renombró; la subinterfaz VLAN depende del nombre base.

Solución: estabiliza el nombre base (o usa un bridge/bond estable como padre de la VLAN), luego recrea las VLANs.

5) “NetworkManager dice que la conexión está activada, pero está en la NIC equivocada.”

Causa raíz: el perfil de conexión no está ligado a la interfaz o está ligado de forma demasiado laxa; NM escogió otro dispositivo tras el rename.

Solución: establece connection.interface-name o enlaza por MAC en el perfil de conexión; verifica con nmcli.

6) “Creamos una regla udev para renombrar NICs; ahora los nombres a veces se intercambian.”

Causa raíz: criterios de match demasiado amplios (driver/vendor) y orden de renombrado no determinista.

Solución: usa match por MAC por interfaz o por ruta estable; prefiere archivos .link de systemd sobre reglas udev personalizadas salvo que tengas una razón sólida.

7) “La interfaz está nombrada correctamente, pero aún no obtiene IP.”

Causa raíz: arreglaste el nombrado pero olvidaste el gestor: conflicto ifupdown vs networkd vs NetworkManager, o el servicio equivocado está habilitado.

Solución: elige un gestor de red, desactiva los otros y asegúrate de que el correcto tome control del dispositivo.

8) “Todo funcionó hasta que activamos SR-IOV; entonces cambiaron los nombres de interfaz.”

Causa raíz: SR-IOV cambia cómo se exponen las funciones; la dirección PCI y el naming netdev pueden desplazarse.

Solución: usa match por MAC o nombres basados en slot; documenta la activación de SR-IOV como un cambio de riesgo para el nombrado.

Listas de verificación / plan paso a paso

Lista A: Recuperar un host Debian 13 aislado tras un rename de NIC

1. Consigue acceso por consola (IPMI/iDRAC/ILO, consola del hypervisor o local).
2. Ejecuta ip -br link y ip -br addr. Identifica el nombre “nuevo” de la interfaz y la MAC.
3. Confirma la MAC esperada desde inventario o seguridad de puerto del switch (si la tienes).
4. Verifica qué gestor de red está a cargo:
   • ifupdown: cat /etc/network/interfaces
   • networkd: networkctl list
   • NetworkManager: nmcli con show --active
5. Aplica una corrección de nombrado estable:
   • Prefiere un archivo .link renombrando por MAC a uplink0, o
   • Haz match por MAC en la configuración del gestor de red (sin renombrar).
6. Actualiza configuraciones dependientes: bonds, bridges, VLANs, reglas de firewall que referencien nombres anteriores.
7. Recarga configuraciones cuando sea seguro; si no, planifica un reinicio.
8. Antes de reiniciar, verifica que aún tienes acceso fuera de banda y un plan de reversión.
9. Reinicia una vez. Confirma:
   • ip -br addr muestra la IP correcta en la interfaz prevista
   • ip route tiene la ruta por defecto
   • El ping al gateway funciona

Lista B: Prevenir esto en una flota (el plan “nunca más”)

1. Elige tu ancla de estabilidad según el entorno:
   • Físico: naming por MAC o por slot; evita path-based cuando el firmware tiene mucho cambio.
   • VM/cloud: match por MAC (a menudo), o identificadores estables específicos del proveedor si las MAC se reciclan.
2. Estandariza nombres de rol de interfaz: uplink0, storage0, cluster0. Evita la nostalgia de “eth0”.
3. Almacena mapeos MAC↔rol en tus datos de provisión. Mantenlos actualizados cuando se reemplacen NICs.
4. Despliega archivos .link de systemd (o reglas de match del gestor) vía gestión de configuración.
5. Añade un paso CI/validación: si los nombres de interfaz en la configuración no existen en la clase de host, falla el build/deploy.
6. Durante cambios de BIOS/firmware, trata “el nombrado de interfaces puede cambiar” como un riesgo real y prueba un host canario de extremo a extremo.
7. Mantén requisito de acceso fuera de banda para cualquier host que pueda dejarse aislado (especialmente almacenamiento, hypervisors, routers).

Lista C: Después de arreglar el nombrado, verifica que no rompiste el resto de la pila de red

1. Enlace: ethtool uplink0 muestra Link detected: yes.
2. Direcciones: ip -br addr muestra las IPv4/IPv6 esperadas.
3. Rutas: ip route tiene la ruta por defecto en la interfaz prevista.
4. ARP/vecinos: ip neigh show dev uplink0 tiene una entrada de gateway alcanzable tras ping.
5. DNS: resolvectl status (o revisa /etc/resolv.conf) coincide con lo esperado.
6. Firewalls: si usas reglas ligadas a nombres de interfaz, confirma que referencian el nombre estable nuevo.
7. Dependencias: bonds/bridges/VLANs están arriba (ip -d link te será útil).

Preguntas frecuentes

1) ¿Por qué Debian 13 renombró mi interfaz si no cambié nada?

Algo cambió. Puede ser tablas de firmware, numeración de buses PCI, comportamiento de un kernel/driver o evaluación de reglas udev/systemd. “No cambié nada” suele significar “no cambié nada intencionalmente”. Revisa journalctl en busca de eventos de renombrado y compara la topología PCI con lspci.

2) ¿Debo desactivar los nombres predecibles de interfaz de red?

No como primer paso. Desactivarlos puede reintroducir problemas por orden de enumeración. Usa archivos .link de systemd o match por MAC en su lugar. Desactívalos solo cuando la compatibilidad lo exija y puedas validar la estabilidad.

3) ¿Es siempre seguro hacer match por MAC?

En servidores físicos, por lo general sí. En VMs clonadas, a veces no. Si las direcciones MAC cambian por clonado, redeploy o comportamiento del proveedor, necesitas automatización que actualice los mapeos—o usar otro selector estable.

4) ¿Qué es mejor: renombrar vía .link o hacer match por MAC en networkd?

Renombrar te da nombres estables y legibles por humanos y ayuda con reglas de firewall y dashboards. Hacer match por MAC evita casos límite de renombrado y mantiene el nombre elegido por el kernel. Si tienes muchas herramientas que referencian nombres de interfaz, renombra a nombres de rol. Si solo quieres que la red se configure correctamente, hacer match por MAC es más limpio.

5) ¿Un archivo .link producirá efecto inmediato?

A veces, pero no lo cuentes. Renombrar interfaces activas está restringido intencionalmente. En la práctica implementas el archivo, recargas udev y planificas un reinicio para estar seguro.

6) ¿Cómo interactúa esto con bonds y bridges?

Esos dispositivos suelen referenciar nombres de esclavos. Si cambian los nombres de esclavos, los bonds no se arman; si cambia el nombre del bond, bridges y VLANs fallan. Estabiliza primero las interfaces físicas de menor nivel y luego reconstruye la pila hacia arriba.

7) ¿Y initramfs y la red en arranque temprano?

Si dependes de la red en initramfs (desbloqueo remoto, root iSCSI), asegúrate de que el nombrado/match esté disponible también en initramfs. Si no, la máquina puede fallar antes de llegar al userspace normal. Normalmente eso implica actualizar initramfs tras tu cambio de nombrado.

8) Usamos reglas de firewall ligadas a nombres de interfaz. ¿Qué debemos hacer?

Deja de ligar reglas a nombres volátiles. O renombra interfaces a nombres de rol estables (uplink0) o aplica firewalling a zonas/direcciones/marcas según proceda. Si debes usar nombres, hazlos estables vía .link.

9) ¿Puedo elegir un nombre como eth0 vía .link?

Puedes, pero probablemente no deberías. Los nombres basados en rol son más claros durante incidentes y evitan confusión con expectativas legacy. Si necesitas eth0 por una app antigua, renombra deliberadamente y documéntalo.

10) ¿Cuál es la solución más rápida y segura durante una interrupción?

Empareja la NIC correcta por MAC y levanta la red con el gestor que ya usas. Si tu configuración está basada en nombres, una edición rápida al nuevo nombre restaura la conectividad—luego aplica una solución de nombrado estable para no repetir el incidente en el próximo reinicio.

Conclusión: próximos pasos que puedes hacer hoy

Si Debian 13 renombró tu interfaz y rompió la red, la lección no es “Debian es inestable”. La lección es “los nombres de interfaz son datos derivados”. Los datos derivados cambian cuando cambian las entradas.

Haz esto a continuación:

1. Elige una estrategia de identidad estable: coincidencia por MAC en la mayoría de casos; nombres por slot donde el firmware es fiable; evita basarte en la ruta en topologías inestables.
2. Implementa la estabilidad explícitamente: archivos .link de systemd para renombrar a nombres de rol, o match por MAC en tu gestor de red.
3. Arregla la cadena de dependencias: bonds, VLANs, bridges, reglas de firewall, comprobaciones de monitorización—todo lo que referencie el nombre antiguo.
4. Documenta el mapeo: MAC ↔ rol ↔ puerto del switch. No es glamoroso, pero acelera la resolución de incidentes.
5. Reinicia una vez en tus términos: verifica enlace, IP, rutas y alcance. Luego sigue con el resto de tu día.

Las fallas de red causadas por renombrados de interfaz son prevenibles. El truco es tratar el nombrado como configuración, no como una sorpresa del descubrimiento.