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

enero 7, 2026 • febrero 3, 2026 • Lectura: 28 min • Views: 5

¿Te fue útil?

Son las 02:13. Reinicias una máquina Debian 13 tras una actualización rutinaria del kernel. Vuelve a arrancar—más o menos. SSH no responde, el monitor se pone en rojo y la consola muestra la luz de enlace perfecta en la NIC que aparentemente “no existe”.

No hay nada más humillante que perder un host porque la tarjeta de red decidió que quería un nuevo apodo. Este caso trata de recuperar ese host y luego asegurarse de que no vuelva a suceder—ni a través de reinicios, actualizaciones del kernel, intercambio de NICs, reordenamientos PCIe ni la mala memoria de tu yo futuro.

Lo que realmente se rompió: cambió el nombre, no la red

Cuando la “red se rompió” tras un reinicio en Debian 13, la realidad más común es aburrida: la NIC sigue funcionando, el enlace está activo, el controlador cargado, DHCP bien… pero tu configuración apunta a eth0 y el kernel ahora la llama enp2s0 (o enp5s0f1, o ens192, o algo igualmente poco romántico).

Esa discrepancia basta para:

Impedir que ifupdown levante la interfaz porque “dispositivo no encontrado”.
Romper la configuración IP estática en /etc/network/interfaces.
Romper conexiones de NetworkManager vinculadas a un nombre de dispositivo.
Romper bonds y bridges que referencian interfaces miembros por nombre.
Romper subinterfaces VLAN (p. ej., bond0.123 o enp2s0.10).
Confundir el monitoreo y las reglas de firewall si dependen de nombres de interfaz.

Los nombres de interfaz son identificadores en las configuraciones. Si el identificador cambia, tu configuración se convierte en un poema sobre una NIC que antes estaba ahí.

Conclusión principal: no “arreglas la red” editando aleatoriamente cada configuración para coincidir con el nuevo nombre. Arreglas la política de nombres para que los nombres sean estables, y luego haces que tus configuraciones dependan de esa política.

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

Primero: ¿el kernel ve la NIC y está el enlace arriba?

Comprueba: ip -br link y dmesg para la asociación del controlador.
Si la NIC falta por completo, estás depurando hardware/controlador/firmware, no el naming.
Si está presente pero no configurada, la discrepancia de nombres es probable.

Segundo: ¿cambió el nombre de la interfaz y la configuración referencia el antiguo?

Compara: ip -br addr vs /etc/network/interfaces o perfiles de NetworkManager.
Busca: “Cannot find device” o “unknown interface” en los logs.

Tercero: ¿qué está definiendo el nombre (systemd/udev, BIOS/firmware, hipervisor)?

Comprueba: udevadm test-builtin net_id y networkctl status.
Decide si: fijar con .link, coincidir por MAC, coincidir por ruta PCI, o desactivar el naming predecible.

Si sigues ese orden, evitas el modo de fallo clásico: pasar una hora “arreglando DHCP” cuando el nombre de la NIC simplemente cambió.

Datos interesantes e historia: por qué Linux nombra las NIC así

eth0 tampoco era estable. Los nombres antiguos dependían del orden de sondeo; añadir una NIC podía intercambiar eth0/eth1 entre reinicios.
Los nombres predecibles se hicieron comunes alrededor de systemd v197. El objetivo: nombres estables basados en la topología de hardware en lugar del orden de descubrimiento.
Los patrones comunes en realidad codifican la ubicación. enp2s0 significa aproximadamente “Ethernet, bus PCI 2, ranura 0”. Eso es útil—hasta que el firmware cambia la numeración.
Hay múltiples “esquemas” de nombres. systemd puede usar índice onboard, índice de slot, ruta, MAC o una mezcla según lo que exponga la plataforma.
Los hipervisores adoran intervenir. En máquinas virtuales, tu “topología de hardware” puede cambiar tras una migración, un cambio de NIC virtual o distinta presentación del bus virtual.
Las reglas udev solían ser el enfoque principal. Muchas guías antiguas muestran reglas udev personalizadas; los archivos .link de systemd son ahora el mecanismo más limpio y soportado.
Las direcciones MAC son estables hasta que no lo son. Algunas plataformas virtuales generan MAC nuevas al clonar, o los administradores “las cambian rápido” y lo olvidan.
Los renombres pueden activarse por cambios en initramfs. Si el initramfs incluye reglas o controladores distintos, la decisión de nombrado puede hacerse antes o de forma diferente.

Una idea para llevar en una nota adhesiva de una voz de confiabilidad operativa: paraphrased idea — John Allspaw, sobre fiabilidad operativa y aprendizaje de incidentes.

Tareas prácticas: comandos, qué significa la salida y la decisión que tomas

No necesitas cien comandos. Necesitas la docena correcta, usada en el orden correcto, con una decisión adjunta a cada uno. Aquí hay dieciséis que consistentemente pagan la renta.

Tarea 1: Listar interfaces rápidamente (y detectar renombres)

cr0x@server:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
enp2s0           DOWN           3c:fd:fe:aa:bb:cc <BROADCAST,MULTICAST>
enp3s0           UP             3c:fd:fe:dd:ee:ff <BROADCAST,MULTICAST,UP,LOWER_UP>

Qué significa: Tienes enp2s0 y enp3s0, no eth0. Una está UP, otra DOWN.

Decisión: Si las configuraciones refieren eth0, estás en territorio de discrepancia de nombres. Identifica qué interfaz debería llevar la IP del servicio.

Tarea 2: Confirmar direcciones y si DHCP/estática se aplicaron

cr0x@server:~$ ip -br addr
lo               UNKNOWN        127.0.0.1/8 ::1/128
enp2s0           DOWN
enp3s0           UP             192.0.2.10/24 fe80::3efd:feff:fedd:eeff/64

Qué significa: enp3s0 tiene una IPv4; enp2s0 no. Es probable que el servicio pertenezca a enp3s0.

Decisión: Si la IP esperada no aparece en ninguna interfaz, la interfaz podría estar arriba pero no configurada por discrepancia de nombre, fallo de VLAN/bond o gateway faltante.

Tarea 3: Comprobar estado de enlace y velocidad negociada (chequeo físico)

cr0x@server:~$ ethtool enp3s0 | sed -n '1,20p'
Settings for enp3s0:
	Supported ports: [ TP ]
	Supported link modes:   1000baseT/Full
	Supported pause frame use: No
	Supports auto-negotiation: Yes
	Advertised link modes:  1000baseT/Full
	Advertised auto-negotiation: Yes
	Speed: 1000Mb/s
	Duplex: Full
	Auto-negotiation: on
	Link detected: yes

Qué significa: El cable y el puerto del switch están bien. Esto no es “la red está caída”.

Decisión: Deja de culpar al switch. Sube por la pila: naming/gestión de servicios.

Tarea 4: Ver qué piensa systemd que se llama la interfaz y por qué

cr0x@server:~$ networkctl status enp3s0
● 2: enp3s0
                 Link File: /usr/lib/systemd/network/99-default.link
              Network File: n/a
                      Type: ether
                     State: routable (configured)
                      Path: pci-0000:03:00.0
                    Driver: e1000e
                HW Address: 3c:fd:fe:dd:ee:ff
                     Address: 192.0.2.10/24
                            fe80::3efd:feff:fedd:eeff/64

Qué significa: systemd aplicó reglas de nombrado por defecto y ve la ruta PCI. Excelente: puedes coincidir por eso.

Decisión: Si quieres estabilidad ante cambios de MAC, coincide por ruta PCI. Si quieres estabilidad ante reordenamientos PCI (VMs), considera coincidir por MAC (con precauciones).

Tarea 5: Identificar los candidatos de “nombre predecible” que udev genera

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

Qué significa: El sistema puede nombrar esta NIC por MAC (enx...), por ruta (enp3s0) o por slot (ens3) según el esquema y las reglas.

Decisión: Elige tu ancla: basado en MAC es muy estable en hardware físico, menos en VMs clonadas. Ruta/slot es estable cuando la topología de hardware es estable.

Tarea 6: Encontrar qué espera tu configuración (ifupdown)

cr0x@server:~$ grep -RIn 'auto\|allow-hotplug\|iface' /etc/network/interfaces /etc/network/interfaces.d
/etc/network/interfaces:3:auto lo
/etc/network/interfaces:5:auto eth0
/etc/network/interfaces:6:iface eth0 inet static

Qué significa: Tu configuración codifica eth0. Debian 13 usa naming predecible, así que eth0 no existe.

Decisión: No renombres eth0 en un solo lugar si hay bonds/bridges/reglas de firewall también. O fijas la interfaz al nombre esperado o actualizas todos los consumidores con intención.

Tarea 7: Revisar logs de servicio por el mensaje honesto de error

cr0x@server:~$ journalctl -u networking -b --no-pager | tail -n 30
ifup: unknown interface eth0
ifup: failed to bring up eth0
networking.service: Failed with result 'exit-code'.

Qué significa: El servicio falla porque el nombre no existe. No es ruteo. No es DNS. No es DHCP.

Decisión: Arregla el naming o la configuración. Reiniciar el servicio 15 veces no inventará un eth0.

Tarea 8: Verificar qué controladores se enlazaron y si hubo renombrado durante el arranque

cr0x@server:~$ dmesg -T | egrep -i 'renamed|link up|eth|enp' | tail -n 25
[Mon Dec 30 02:13:22 2025] e1000e 0000:03:00.0 enp3s0: renamed from eth0
[Mon Dec 30 02:13:22 2025] e1000e 0000:03:00.0 enp3s0: Link is Up 1000 Mbps Full Duplex

Qué significa: El kernel inicialmente la llamó eth0, luego udev/systemd la renombró a enp3s0.

Decisión: Si quieres mantener eth0, puedes—pero hazlo explícita y consistentemente. De lo contrario, migra configuraciones al nombre predecible.

Tarea 9: Confirmar la política de nombrado por defecto en la línea de comandos del kernel

cr0x@server:~$ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-6.12.0 root=/dev/mapper/vg0-root ro quiet

Qué significa: No estás sobrescribiendo el nombrado con net.ifnames=0 o biosdevname=0.

Decisión: Si necesitas el instrumento contundente (desactivar naming predecible), aquí es donde aparecería una vez configurado.

Tarea 10: Mostrar MAC, ubicación PCI y mapeo de interfaces en una sola pasada

cr0x@server:~$ for i in /sys/class/net/en*; do n=$(basename "$i"); printf "%s " "$n"; cat "$i/address"; readlink -f "$i/device"; done
enp2s0 3c:fd:fe:aa:bb:cc
/sys/devices/pci0000:00/0000:00:1c.0/0000:02:00.0
enp3s0 3c:fd:fe:dd:ee:ff
/sys/devices/pci0000:00/0000:00:1c.4/0000:03:00.0

Qué significa: Puedes coincidir una NIC por MAC (address) o por ruta del dispositivo (.../0000:03:00.0).

Decisión: Elige criterios de coincidencia para tu regla de naming estable. Servidores físicos: la ruta PCI suele ser estable. VMs: la MAC puede ser más estable que la ranura PCI (depende del hipervisor).

Tarea 11: Detectar si NetworkManager gestiona dispositivos y perfiles

cr0x@server:~$ systemctl is-active NetworkManager
inactive

Qué significa: NetworkManager no está en juego; probablemente ifupdown/systemd-networkd lo estén.

Decisión: No arregles al gestor equivocado. Si NetworkManager está activo, inspeccionarías perfiles; si no, enfócate en ifupdown o systemd-networkd.

Tarea 12: Si NetworkManager está activo, comprobar si los perfiles se vinculan por nombre de dispositivo

cr0x@server:~$ nmcli -f NAME,UUID,DEVICE con show
Wired connection 1  2a0b1c1d-8a9b-4c1f-9a62-2c4f2f0b7e1a  --

Qué significa: El perfil existe pero no está conectado a ningún dispositivo (DEVICE es --).

Decisión: O vuelves a vincular el perfil al nuevo nombre de interfaz, o quitas la dependencia del nombre configurando la coincidencia por MAC en el perfil.

Tarea 13: Si usas systemd-networkd, comprobar estado de unidades y coincidencia de configuración

cr0x@server:~$ systemctl is-active systemd-networkd
active

Qué significa: systemd-networkd está en ejecución. Bien: puedes coincidir en archivos .network por MAC/Path/Name y evitar nombres frágiles.

Decisión: Decide si arreglas el nombrado (.link) o coincides las interfaces en .network por propiedades estables (a menudo mejor).

Tarea 14: Validar dependencias VLAN/bond/bridge (daños colaterales comunes)

cr0x@server:~$ ip -d link show | egrep -A2 'bond|bridge|vlan'
5: bond0: <NO-CARRIER,BROADCAST,MULTICAST,MASTER,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
    link/ether 3c:fd:fe:dd:ee:ff brd ff:ff:ff:ff:ff:ff
7: br0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
    link/ether 3c:fd:fe:dd:ee:ff brd ff:ff:ff:ff:ff:ff

Qué significa: Dispositivos de nivel superior existen pero no tienen carrier. Eso suele ser porque la interfaz esclava no se ensabló (nombre equivocado) o nunca subió.

Decisión: Arregla primero el naming de la interfaz base, luego reevalúa la creación de bond/bridge. No depures LACP antes de confirmar que las esclavas existen.

Tarea 15: Comprobar reglas de firewall que dependan de nombres de interfaz

cr0x@server:~$ nft list ruleset | grep -n 'iifname\|oifname' | head
42:		iifname "eth0" accept
88:		oifname "eth0" masquerade

Qué significa: Tu firewall literalmente espera eth0. Encajará y bloqueará tráfico en enp3s0.

Decisión: O actualizas reglas al nombre estable que vas a mantener, o filtras por dirección/subred/mark en lugar de nombre de interfaz cuando sea factible.

Tarea 16: Asegurarte de no haber creado “dos verdades” por configuraciones obsoletas

cr0x@server:~$ ls -1 /etc/systemd/network /etc/network/interfaces.d 2>/dev/null
/etc/network/interfaces.d:
eth0.cfg

/etc/systemd/network:
10-wan.network

Qué significa: Potencialmente tienes both ifupdown y systemd-networkd configurados. Eso es receta para “funciona a veces”.

Decisión: Elige un solo stack de red por rol de host. Elimina o desactiva el otro. La gestión mixta no es “flexibilidad”, es combustible para incidentes futuros.

Recuperación inmediata: volver a estar en línea sin empeorar la situación

Cuando estás caído, necesitas dos cosas: restaurar acceso y evitar empeorarlo. El truco es aplicar una solución temporal reversible, y luego implementar el cambio permanente.

Movimiento de recuperación 1: levantar la interfaz correcta manualmente

Si tienes acceso por consola (KVM, serie, consola del hipervisor), a menudo puedes restaurar la conectividad el tiempo suficiente para desplegar la solución real.

cr0x@server:~$ ip link set enp3s0 up
cr0x@server:~$ ip addr add 192.0.2.10/24 dev enp3s0
cr0x@server:~$ ip route add default via 192.0.2.1
cr0x@server:~$ ping -c 2 192.0.2.1
PING 192.0.2.1 (192.0.2.1) 56(84) bytes of data.
64 bytes from 192.0.2.1: icmp_seq=1 ttl=64 time=0.420 ms
64 bytes from 192.0.2.1: icmp_seq=2 ttl=64 time=0.391 ms

Qué significa: Has probado que L1–L3 están bien. Ahora puedes conectar de forma remota (una vez que SSH/rules de firewall lo permitan).

Decisión: Usa esto solo como puente hacia la solución permanente. Las IPs manuales desaparecen al reiniciar; ese es el punto.

Movimiento de recuperación 2: no “arregles” renombrando todo aleatoriamente

Si te tienta buscar y reemplazar eth0 por enp3s0 en todas las configuraciones en pánico, haz una pausa. Funciona hasta el próximo renombrado y no escala en flotas. Tu futuro outage será más rápido, que no es el tipo de “optimización” que nadie quiere.

Broma #1: Los renombres de interfaz son la única crisis de identidad capaz de tumbar un centro de datos sin cambiar un solo cable.

Estrategias de nombres estables que sobreviven reinicios (elige tu veneno)

Hay tres estrategias sensatas. Dos son modernas. Una es una manta de confort legacy que a veces sigue siendo la elección correcta.

Estrategia A (recomendada): Mantener naming predecible, fijarlo con archivos .link de systemd

Esta suele ser la mejor opción en Debian 13. Mantienes el sistema de naming predecible, pero lo sobrescribes para las interfaces que te importan (WAN/LAN/almacenamiento/latido). Puedes coincidir por MAC, por ruta PCI, por controlador o por índice onboard—luego establecer un nombre que controles (como wan0, lan0, stor0).

Por qué sobrevive reinicios: La regla se ejecuta en el descubrimiento del dispositivo. Cada arranque, los mismos criterios de coincidencia producen el mismo nombre.

Dónde falla: si tus criterios de coincidencia no son realmente estables (MAC de VM cambia, firmware altera la exposición de la ruta).

Estrategia B (también buena): No importar el nombre; coincidir en la configuración de red por MAC/path

Si usas systemd-networkd, puedes escribir archivos .network que coincidan por MAC o por ruta y luego configurar IP/gateway sin importar cómo se llame la interfaz. Esto es sorprendentemente resistente.

Por qué sobrevive reinicios: incluso si cambia el nombre, la coincidencia sigue apuntando a la NIC correcta.

Dónde falla: herramientas y políticas (firewalls, monitoreo) a menudo siguen dependiendo de nombres de interfaz. Además, los humanos que depuran a las 03:00 aprecian nombres legibles.

Estrategia C (instrumento contundente): Desactivar naming predecible y volver a `eth0`

Esta es la aproximación “hacer que parezca 2012”. Puede ser correcta en entornos controlados donde software legacy espera eth0, o donde estandarizas sobre automatización antigua.

Por qué sobrevive reinicios: vuelve a la enumeración del kernel. Pero recuerda: el orden de enumeración también puede cambiar.

Dónde falla: añadir/quitar NICs o cambiar controladores puede intercambiar eth0 y eth1. La predictibilidad no está garantizada; solo es familiar.

La forma correcta (generalmente): archivos .link de systemd

Si quieres nombres de interfaz estables y significativos, hazlo con archivos .link en /etc/systemd/network/. Son explícitos, legibles y controlados por ti en lugar de por lo que el hardware decida hoy.

Elige un esquema de nombres que coincida con tu realidad

Servidor físico, NIC permanece en la misma ranura: coincide por ruta PCI (Path=pci-0000:03:00.0) o por MAC.
VMs que se migran: suele convenir coincidir por MAC (si la MAC es estable en tu plataforma), pero cuidado con las clonaciones.
Redes de almacenamiento y clusters HA: considera nombrar por rol (stor0, hb0) para que la gente deje de confundir “puerto izquierdo” y “puerto derecho”.

Crear un archivo .link que fije un nombre por MAC

cr0x@server:~$ sudo tee /etc/systemd/network/10-wan.link >/dev/null <<'EOF'
[Match]
MACAddress=3c:fd:fe:dd:ee:ff

[Link]
Name=wan0
EOF

Qué significa: Cualquier NIC con esa MAC será renombrada a wan0 temprano en el arranque.

Decisión: Usa coincidencia por MAC cuando confíes en la estabilidad de la MAC. En servidores físicos, normalmente está bien. En VMs clonadas, puedes querer otro criterio.

Crear un archivo .link que fije un nombre por ruta PCI

cr0x@server:~$ sudo tee /etc/systemd/network/10-stor.link >/dev/null <<'EOF'
[Match]
Path=pci-0000:02:00.0

[Link]
Name=stor0
EOF

Qué significa: El dispositivo en esa ruta PCI pasará a llamarse stor0.

Decisión: La coincidencia por ruta es excelente hasta que mueves la tarjeta o el firmware cambia la exposición de la topología. En un chasis que nunca cambia, es sólido como una roca.

Aplicar cambios de forma segura

Renombrar una interfaz en un sistema en vivo puede cortarte la rama si estás sobre él. Planifica el momento.

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

Qué significa: udev recarga reglas y retriggera dispositivos de red. En algunos sistemas el renombrado tendrá efecto; en otros necesitarás un reinicio para una transición limpia.

Decisión: Si es un host remoto y no tienes consola fuera de banda, programa un reinicio de mantenimiento y hazlo con calma.

Verificar el nuevo nombre y actualizar los consumidores de la configuración de red

cr0x@server:~$ ip -br link | grep -E 'wan0|stor0|enp|eth'
wan0             UP             3c:fd:fe:dd:ee:ff <BROADCAST,MULTICAST,UP,LOWER_UP>
stor0            DOWN           3c:fd:fe:aa:bb:cc <BROADCAST,MULTICAST>

Qué significa: El renombrado está funcionando.

Decisión: Ahora actualiza exactamente una vez—tus configs de bond/bridge/VLAN, reglas de firewall y monitoreo para usar wan0/stor0 (o coincide por MAC donde sea posible).

Un detalle que la gente pasa por alto: el nombrado ocurre temprano

Si tu initramfs incluye red e intenta levantar una interfaz por nombre (arranque sin disco, root remoto, iSCSI, algunos setups de root encriptado), tu nombrado debe ser consistente también en esa etapa. Si cambias reglas de nombrado, reconstruye initramfs si tu entorno lo requiere.

cr0x@server:~$ sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.img-6.12.0

Qué significa: Tu initramfs ahora contiene reglas/configs actualizadas (según corresponda).

Decisión: Si te ha pasado que “funciona después del arranque, falla en arranque temprano”, trata al initramfs como parte del sistema, no como una masa mágica.

La forma contundente: desactivar el naming predecible (cuando es aceptable)

Algunas veces heredas automatización que asume eth0. A veces un script de proveedor está pegado a eso. A veces necesitas la vía más rápida para restaurar una flota sin reescribirlo todo en medio del incidente.

Desactivar nombres predecibles es aceptable cuando además aseguras un orden de sondeo estable (o tienes una sola NIC). No es aceptable cuando tienes hosts multi-NIC con bonds y trunks VLAN, a menos que disfrutes de la ruleta.

Establecer parámetros del kernel para desactivar los nombres predecibles

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
Found initrd image: /boot/initrd.img-6.12.0
done

Qué significa: Los futuros arranques pedirán al kernel que mantenga el nombrado tradicional. Dependiendo del entorno, verás eth0 de nuevo.

Decisión: Haz esto solo si toleras cambios por enumeración, o si además fijas el orden por otros medios. De lo contrario, prefierem .link o coincidencia por MAC en la configuración.

Reiniciar y confirmar

cr0x@server:~$ sudo reboot
Connection to server closed by remote host.
Connection to server closed.

cr0x@server:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
eth0             UP             3c:fd:fe:dd:ee:ff <BROADCAST,MULTICAST,UP,LOWER_UP>

Qué significa: El sistema volvió al nombrado legacy.

Decisión: Si tienes más de una NIC, verifica cada mapeo. Si eth0 no es la NIC que crees, detente y arréglalo antes de que el tráfico equivocado vaya al lugar equivocado.

Bonds, VLANs, bridges e hipervisores: donde los renombres hacen más daño

Máquinas con una sola NIC suelen sobrevivir a renombres con algo de molestia. Máquinas multi-NIC pueden quedarse totalmente a oscuras, o peor: parcialmente funcionales de forma que consume horas.

Bonds (LACP/active-backup)

Los bonds dependen de los nombres de esclavos. Si la esclava no existe, el bond se levanta sin miembros y muestra NO-CARRIER.

Síntoma típico: el dispositivo bond existe, pero no fluye tráfico. Verás una interfaz bond con estado DOWN aunque la NIC física tenga enlace.

Bridges (común en virtualización)

Los bridges dependen de ensblar el uplink correcto. Si el nombre del uplink cambió, la red de tu VM puede seguir apareciendo como arriba (el bridge existe), pero aislada.

De aquí viene el “funciona en el host pero no en las VMs”.

Subinterfaces VLAN

Si tienes enp3s0.100 y la base pasa a wan0, la interfaz VLAN debería pasar a wan0.100 si la defines así. Si codificaste el nombre base antiguo, las VLANs no aparecerán.

Hipervisores y hardware virtual “estable”

En el mundo VM, “ruta PCI estable” suele ser una mentira para dormir. Migraciones, actualizaciones de versión y cambiar el modelo de NIC virtual pueden desplazar la presentación bus/slot. A veces la VM sigue viendo la misma MAC, a veces no.

Broma #2: Una migración de hipervisor es solo un “cambio de hardware” vestido con traje e insistiendo en que es un “evento en vivo”.

Tres mini-historias corporativas desde las trincheras

Mini-historia 1: El incidente causado por una suposición equivocada (“eth0 siempre es la primaria”)

Una compañía mediana tenía una flota mixta: algunos servidores Debian antiguos con eth0/eth1 y otros más nuevos con nombres predecibles. Un equipo mantenía un script de aprovisionamiento que hacía una cosa muy eficientemente: asumía que eth0 era la interfaz pública y escribía reglas de firewall en consecuencia.

En Debian 13, un nuevo lote de hosts arrancó como enp1s0 y enp2s0. El script seguía escribiendo reglas nftables para eth0. El servicio de red subió enp1s0 sin problemas, pero el firewall bloqueó felizmente el SSH entrante porque la regla de permitir nunca coincidió.

El fallo fue sutil: los hosts podían salir (el agente de monitoreo llamaba a casa, las actualizaciones funcionaban), pero la gestión entrante estaba muerta. La gente culpó a grupos de seguridad, al balanceador y al DNS. Nadie culpó al nombre de la interfaz porque las luces de enlace estaban encendidas y “la red está arriba”.

La solución no fue reemplazar eth0 por enp1s0 en el script. La solución fue dejar de depender de nombres de interfaz para la política. Cambiaron las reglas de firewall para coincidir por subredes de origen y estado de conexión, y fijaron nombres de interfaz con .link solo donde el rol operativo lo exigía.

Después de eso, el mismo script funcionó en ambos esquemas de nombres. El outage terminó y la empresa aprendió una lección clásica de SRE: las suposiciones son invisibles hasta que fallan de forma ruidosa.

Mini-historia 2: La optimización que se volvió en contra (fijar por MAC… luego clonar VMs)

Otra organización estandarizó nombres de interfaz usando .link por MAC. Quedó ordenado: wan0, lan0, stor0. A la gente le encantó. Los gráficos de monitoreo quedaron más limpios. La documentación dejó de usar “el puerto izquierdo” como término técnico.

Luego desplegaron una plantilla de VM para un nuevo servicio. La plantilla incluía los archivos .link que coincidían con las MAC de la VM plantilla. En producción, los clones recibieron MAC nuevas—como deberían—pero las reglas .link no coincidían con nada. Así que los nombres volvieron a los valores predecibles por defecto.

Ahora tenían dos mundos: pruebas con la plantilla decían wan0, producción decía ens192. Su automatización de despliegue referenciaba wan0. Algunos hosts arrancaron sin IP. Otros sí arrancaron porque otro componente coincidió por client ID DHCP, creando un éxito parcial accidental que alargó el incidente.

La solución fue dejar de meter identidad específica del host en plantillas. Pasaron a coincidir por ruta PCI dentro de la VM solo cuando el hipervisor la mantenía estable, y de lo contrario coincidían en archivos .network por MAC pero generaban la coincidencia MAC en el momento del aprovisionamiento (no en la imagen dorada).

La optimización—“hacer nombres bonitos en todas partes”—se volvió en contra porque introdujo identidad en un artefacto que debía ser genérico. Buenas intenciones, resultado clásico.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día (fuera de banda + comprobaciones previas)

Un equipo de servicios financieros tenía una costumbre que parecía excesivamente cautelosa: cada cambio que afectara la red requería (1) acceso por consola fuera de banda verificado, y (2) un script previo que comparara nombres de interfaz configurados con las interfaces reales.

Cuando actualizaron un nodo de cluster a Debian 13, el nombre de la NIC cambió porque el modelo de hardware virtual subyacente cambió en la actualización del hipervisor realizada la semana anterior. El script previo lo marcó inmediatamente: “Configured interface bond slaves not present.” Abortó el cambio antes del reinicio.

Porque fueron aburridos, fueron rápidos. Ajustaron el naming .link a un esquema por rol, actualizaron las configs de bond, reconstruyeron initramfs y programaron un reinicio en una ventana controlada—con acceso fuera de banda confirmado.

El nodo reinició limpio. Sin outage. Sin drama. El informe post-cambio fue casi insultante por su falta de emoción, que es exactamente lo que quieres cuando hay dinero en juego.

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

Síntoma: networking.service falla con “unknown interface eth0”.
Causa raíz: La configuración referencia el nombre legacy; el sistema usa naming predecible.
Solución: Fija el nombre de la interfaz con un archivo .link o actualiza las configuraciones al nuevo nombre estable; no olvides firewall/bonds/VLANs.
Síntoma: La interfaz muestra UP con enlace, pero sin IP tras reinicio.
Causa raíz: Cliente DHCP o config estática ligada a un nombre de interfaz distinto o perfil de NetworkManager no adjunto.
Solución: Re-asocia el perfil (NetworkManager) o coincide por MAC/ruta (systemd-networkd) y asegúrate de que solo un gestor de red posea el dispositivo.
Síntoma: Bond/bridge existe, pero NO-CARRIER y tráfico muerto.
Causa raíz: Esclavos del bond/uplink del bridge referenciados por un nombre antiguo; las esclavas no se ensablaron.
Solución: Arregla primero el naming base; luego verifica el ensablado; después verifica switch/LACP.
Síntoma: El host puede salir pero no puedes SSH; el monitoreo funciona parcialmente.
Causa raíz: Reglas de firewall casadas con iifname "eth0" que ya no existe.
Solución: Actualiza el firewall al nombre estable correcto o rediseña para coincidir por subred/estado; valida el ruleset tras el renombrado.
Síntoma: Funciona hasta reiniciar; tras reiniciar, el nombre cambia otra vez.
Causa raíz: Hiciste un renombrado en tiempo de ejecución o editaste un solo archivo sin definir una política de nombres persistente.
Solución: Crea reglas .link (o desactiva naming predecible intencionalmente) y persiste la elección; reconstruye initramfs si el arranque temprano importa.
Síntoma: El naming “estable” por MAC falla solo en clones/nuevas VMs.
Causa raíz: La imagen golden incluía reglas emparejadas por la MAC de la plantilla.
Solución: Genera archivos .link en el momento del aprovisionamiento, o coincide por otros identificadores estables; mantén las plantillas genéricas.
Síntoma: Dos interfaces intercambian roles tras añadir una nueva NIC.
Causa raíz: Desactivaste el naming predecible y confiaste en el orden de sondeo.
Solución: Vuelve a habilitar naming predecible y fija con .link, o empareja explícitamente en tu config de red por MAC/ruta.
Síntoma: Flaps aleatorios o nombres duplicados tras cambios.
Causa raíz: Reglas en conflicto: múltiples archivos .link coinciden con la misma NIC, o ifupdown y networkd gestionan ambos.
Solución: Asegura coincidencias únicas, controla la prioridad de reglas (orden de archivos) y usa un solo gestor de red por host.

Listas de verificación / plan paso a paso

Paso a paso: arreglar un host roto ahora mismo (NIC única)

Entra por consola (IPMI/iDRAC/consola virtual). No experimentes sobre una sesión SSH moribunda.
Ejecuta ip -br link y ip -br addr. Identifica la NIC que debería tener la IP del servicio.
Revisa journalctl -u networking -b (o logs de networkd/NetworkManager). Confirma que es discrepancia de nombre, no fallo de controlador.
Asigna temporalmente IP/gateway con ip addr add/ip route add si necesitas acceso remoto inmediatamente.
Crea un archivo .link para nombrar la NIC con algo estable (wan0 está bien) usando MAC o ruta.
Actualiza la configuración de red para referenciar wan0 (o coincide por MAC/ruta si usas networkd).
Actualiza reglas de firewall que coincidan por nombres de interfaz.
Reconstruye initramfs si la red en arranque temprano importa en tu entorno.
Reinicia en una ventana controlada y verifica nombre, IP, ruteo y acceso entrante.

Paso a paso: arreglar un host con bond/bridge (multi-NIC)

Identifica NICs físicas y su mapeo MAC/ruta (udevadm test-builtin net_id y /sys/class/net).
Decide nombres estables por rol: wan0, lan0, stor0, no por número de ranura que no recordarás.
Crea un .link por rol con coincidencias únicas (MAC o ruta PCI). Verifica que no haya coincidencias solapadas.
Actualiza definiciones de esclavos del bond y puertos del bridge a los nuevos nombres estables.
Verifica con ip -d link show bond0 que muestra esclavos correctos y que aparece carrier.
Solo entonces verifica LACP o trunking en el switch.
Reinicia una vez, verifica de nuevo y captura salidas “conocidas buenas” para diffs futuros.

Checklist previa a cambios para upgrades a Debian 13 (haz esto antes del reinicio)

Confirma que el acceso por consola fuera de banda funciona.
Captura ip -br link, ip -br addr y networkctl status.
Inventaría dependencias: reglas nftables, bonds, bridges, VLANs, chequeos de monitoreo.
Asegúrate de no tener gestores en competencia (ifupdown vs networkd vs NetworkManager) a menos que tengas una razón específica.
Si dependes de red en arranque temprano (root remoto, iSCSI, etc.), planifica reconstrucción de initramfs y pruebas de arranque.

Preguntas frecuentes

1) ¿Por qué Debian 13 renombró mi interfaz tras una actualización?

Porque el nombrado se deriva de reglas udev/systemd, que pueden cambiar con actualizaciones, distintos controladores, firmware/BIOS o un cambio de topología (físico o virtual). Tu NIC no “se rompió”; cambió su identificador.

2) ¿Debería simplemente desactivar los nombres predecibles?

Sólo si tienes una buena razón (herramientas legacy, NIC única, hardware controlado) y aceptas que el orden de sondeo aún puede cambiar. Para servidores multi-NIC, prefiere fijar con .link o coincidir por MAC/ruta en configs de networkd.

3) ¿Es coincidir por dirección MAC siempre lo mejor?

No. Servidores físicos: generalmente sí. VMs: sólo si las MAC son estables en tu ciclo de vida. Si clonas o regeneras MACs, las reglas basadas en MAC en plantillas te traicionarán.

4) ¿Cuál es la diferencia entre fijar nombres con `.link` y coincidir en `.network`?

.link controla el nombre de la interfaz en sí. .network coincide interfaces para aplicar ajustes IP. Puedes evitar dependencia del nombre coincidiendo en .network, pero los nombres siguen importando para humanos y otras herramientas.

5) Mi interfaz fue renombrada, pero DHCP sigue funcionando. ¿Por qué fallaron mis servicios?

Porque los servicios suelen depender de nombres de interfaz: reglas de firewall (iifname), políticas de ruteo, dispositivos VLAN, bonds o scripts. DHCP funcionando solo prueba que la NIC obtuvo una dirección, no que el resto del sistema esté de acuerdo con el nombre.

6) ¿Cómo sé qué nombre de interfaz es “correcto” para mi host?

Deja de pensar en “correcto” y empieza a pensar en “estable”. Elige nombres por rol (WAN/LAN/almacenamiento) y vincula esos nombres a identificadores estables (MAC/ruta). Luego haz que las configuraciones referencien esos nombres por rol.

7) ¿Pueden dos archivos `.link` pelearse por la misma NIC?

Sí. Si dos archivos coinciden con el mismo dispositivo, gana el de mayor prioridad (a menudo orden léxico), y tendrás comportamiento inconsistente ante cambios. Mantén las coincidencias específicas y la nomenclatura de archivos intencional.

8) ¿Necesito reconstruir initramfs tras cambiar reglas de nombrado?

A menudo no para arranques típicos de servidor. Pero si usas red en arranque temprano (sin disco, root remoto, iSCSI, algunos setups encriptados), considéralo obligatorio: reconstruye y prueba.

9) ¿Y los contenedores—les afecta?

Los contenedores suelen ver nombres veth y espacios de nombres; el nombrado del uplink del host aún importa para firewalling, ruteo y configuración CNI. Si rompes el uplink del host, tus contenedores fallarán con él.

10) ¿Cuál es el enfoque más seguro a largo plazo para una flota mixta?

Estandariza en nombres por rol vía .link para uplinks importantes, y escribe política de alto nivel (firewall, monitoreo) para que sea resiliente—evita codificar nombres efímeros cuando puedas.

Conclusión: pasos prácticos siguientes

Si Debian 13 “rompió la red”, asume que estás ante una discrepancia de nombre de interfaz hasta que se demuestre lo contrario. Confirma que la NIC existe, confirma enlace, confirma que la configuración referencia un nombre que ya no existe. Luego arréglalo de una vez, correctamente.

Elige una estrategia de naming estable: nombres por rol con .link es la respuesta por defecto y mejor.
Audita dependencias: bonds/bridges/VLANs, reglas de firewall, monitoreo y cualquier script que asuma eth0.
Haz que la solución sobreviva reinicios: persiste la política de nombres, actualiza las configuraciones, reconstruye initramfs si el arranque temprano importa.
Institucionalízalo: añade una comprobación previa que compare los nombres de interfaz configurados con los dispositivos reales antes de reinicios/actualizaciones.

La meta no es ganar el incidente de hoy. La meta es asegurarse de que el próximo reinicio sea aburrido.