Proxmox “puerto del bridge sin enlace”: Solución rápida para cables, switches y controladores

Qué significa realmente “bridge port has no carrier”

En Proxmox, la red de tus VMs suele montarse sobre un bridge de Linux como vmbr0. Ese bridge tiene uno o varios puertos (normalmente una NIC física como enp3s0 o un bond como bond0). La advertencia aparece cuando el puerto informa sin enlace—la forma de Linux de decir “link está abajo”.

El carrier no es “puedo hacer ping al gateway”. Carrier es la señal física o a nivel PHY: la interfaz no puede negociar enlace con lo que hay en el otro extremo. Si es un puerto de cobre, suele ser cable/switch. Si es fibra/DAC, suele ser compatibilidad del SFP, polaridad de fibra o la configuración del puerto del switch. Si es un bond, puede ser mismatch de LACP. Si es un driver, puede ser problemas de firmware/controlador, gestión de energía o que la NIC esté en un estado raro.

Una advertencia del bridge suele ser el mensajero al que disparan. El bridge suele estar bien. El problema es el puerto. Tu trabajo: averiguar por qué el puerto perdió el enlace, no por qué Proxmox se quejó.

Exactamente una cita, porque encaja en este trabajo: “La esperanza no es una estrategia.” — Vince Lombardi

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

Primero: demuestra si es realmente enlace (L1) o algo superior

1. Comprueba el estado del enlace desde el host (ip link, ethtool). Si dice NO-CARRIER o Link detected: no, trátalo como L1 hasta que se demuestre lo contrario.
2. Revisa los LEDs y el estado del puerto del switch. Un LED muerto es una pista: significa que puedes dejar de discutir sobre VLANs.
3. Intercambia el elemento conocido bueno: cable/DAC/SFP o mueve a un puerto del switch que sepas que funciona. Hazlo pronto. Es más rápido que intentar ser ingenioso.

Segundo: si el carrier está arriba, persigue problemas L2/LACP/VLAN

1. Verifica pertenencia al bridge (bridge link). Asegúrate de que la interfaz correcta esté esclavizada al bridge.
2. Verifica que el modo VLAN coincida con el switch (VLAN nativa vs etiquetada, trunks). Un mismatch de trunk no suele mostrar “sin carrier”, pero sí “todo está muerto” y la gente se confunde.
3. Si hay bonding, confirma el estado de LACP (cat /proc/net/bonding/bond0) y la agregación en el switch.

Tercero: si el enlace hace flapping o negocia mal, sospecha del driver/firmware/EEE

1. Busca eventos de flapping en journalctl y dmesg.
2. Identifica el driver y el firmware (ethtool -i, lspci -nnk).
3. Desactiva elementos problemáticos conocidos para diagnóstico (EEE en cobre, offloads en casos raros, ASPM). Prueba. Revierte si no ayuda.

Chiste #1: La forma más rápida de solucionar un enlace es asumir que es el cable—porque casi siempre lo es, hasta la vez que resulta ser el SFP que “tomaste prestado” del cajón.

Datos interesantes y contexto histórico (te ayudarán a diagnosticar más rápido)

• “Carrier detect” es más antiguo que tu hipervisor: el término viene de las primeras señales de red y módems—Linux mantuvo el lenguaje porque encaja bien con el estado PHY del enlace.
• Los bridges de Linux son nativos del kernel, no una “cosa de Proxmox”: Proxmox los configura, pero la lógica y la telemetría son de las herramientas estándar de Linux (iproute2, bridge, ethtool).
• La auto-negociación ha sido fuente recurrente de problemas desde Fast Ethernet: negociaciones desajustadas pueden causar flaps, velocidad/duplex erróneo o “link arriba pero inútil”.
• Energy Efficient Ethernet (EEE) fue diseñado para ahorrar energía: en algunas combinaciones de NIC+switch, ahorra energía y también tu tiempo de actividad—por accidente, y no para bien.
• Los módulos SFP tienen “códigos” y comprobaciones de compatibilidad: muchos proveedores prefieren sus ópticas; algunas NICs y switches son exigentes, y el modo de fallo suele ser un “no link” limpio.
• Los cables DAC no son solo cables de cobre: incluyen identificación y tienen restricciones de longitud/calidad; un DAC barato puede negociar a 1G pero fallar a 10G.
• LACP (802.3ad) no es “configurar y olvidar”: un lado en LAG estático y el otro en LACP puede producir conectividad parcial, agujeros negros o carrier intermitente según la implementación.
• Nombres de interfaz predecibles (enpXsY): systemd/udev redujo la “ruleta eth0”, pero también provocó que la gente lea mal identidades de NIC y conecte el puerto equivocado.
• STP y seguridad de puertos existen para prevenir bucles: el switch puede cerrar o bloquear un puerto tras eventos topológicos; el host ve enlace, pero el tráfico muere—diferente de no-carrier, pero a menudo se confunde durante incidentes.

Tareas prácticas: comandos, salidas y decisiones

Estas son las tareas que ejecuto en producción cuando Proxmox reporta bridge port has no carrier. Cada una incluye: el comando, un ejemplo de salida real, qué significa y qué decisión tomar.

Task 1: Confirmar qué interfaz está realmente “sin enlace”

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

Significado: enp3s0 está abajo y vmbr0 hereda eso. Un bridge sin un uplink activo es básicamente un aparcamiento sin salida.

Decisión: Deja de mirar la configuración de VMs. Estás en territorio de NIC del host / switch / cable.

Task 2: Comprobar carrier y parámetros negociados con ethtool

cr0x@server:~$ ethtool enp3s0
Settings for enp3s0:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Supported pause frame use: Symmetric Receive-only
        Supports auto-negotiation: Yes
        Advertised link modes:  1000baseT/Full
        Advertised auto-negotiation: Yes
        Speed: Unknown!
        Duplex: Unknown! (255)
        Auto-negotiation: on
        Link detected: no

Significado: La NIC no detecta los pulsos de enlace. Esto no es un problema de VLAN.

Decisión: Revisa la capa física: cable, patch panel, puerto del switch, transceptor.

Task 3: Confirmar que el bridge está configurado como crees

cr0x@server:~$ cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto enp3s0
iface enp3s0 inet manual

auto vmbr0
iface vmbr0 inet static
        address 10.20.30.11/24
        gateway 10.20.30.1
        bridge-ports enp3s0
        bridge-stp off
        bridge-fd 0

Significado: vmbr0 está respaldado por enp3s0. Si enp3s0 está muerto, todo en vmbr0 está muerto.

Decisión: Verifica el cable físico conectado al puerto de NIC que corresponde a enp3s0. No asumas que la etiqueta es correcta.

Task 4: Identificar la NIC y el driver cargado

cr0x@server:~$ lspci -nnk | sed -n '/Ethernet controller/,+4p'
03:00.0 Ethernet controller [0200]: Intel Corporation I210 Gigabit Network Connection [8086:1533] (rev 03)
        Subsystem: Intel Corporation Ethernet Server Adapter I210-T1 [8086:0001]
        Kernel driver in use: igb
        Kernel modules: igb

Significado: Ahora sabes con qué silicio estás tratando. Esto importa para fallos conocidos del driver y herramientas de firmware.

Decisión: Si sospechas del driver, puedes buscar por ID de dispositivo/driver y validar firmware y parámetros del módulo.

Task 5: Comprobar versiones de driver y firmware desde ethtool

cr0x@server:~$ ethtool -i enp3s0
driver: igb
version: 6.1.0-27-pve
firmware-version: 3.25, 0x80000d4b
expansion-rom-version:
bus-info: 0000:03:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: yes

Significado: Confirma kernel/driver y firmware de la NIC. Si ves flaps tras una actualización del kernel, aquí empiezas a correlacionar.

Decisión: Si el firmware está antiguo o desparejo entre hosts, programa una actualización de mantenimiento; por ahora sigue diagnosticando L1.

Task 6: Buscar mensajes de flapping en el journal

cr0x@server:~$ journalctl -k -b | grep -E 'enp3s0|igb|link up|link down' | tail -n 20
igb 0000:03:00.0 enp3s0: NIC Link is Down
igb 0000:03:00.0 enp3s0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
igb 0000:03:00.0 enp3s0: NIC Link is Down
igb 0000:03:00.0 enp3s0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX

Significado: El enlace está haciendo flapping. Suele ser cable malo, puerto defectuoso, óptica/DAC marginal o rarezas de EEE—no un problema de configuración del bridge.

Decisión: Cambia cable/DAC primero. Si persiste, cambia de puerto en el switch. Si persiste, desactiva EEE y revisa firmware de la NIC.

Task 7: Verificar el estado del puerto del bridge y si está realmente esclavizado

cr0x@server:~$ bridge link
2: enp3s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 master vmbr0 state disabled priority 32 cost 100

Significado: El puerto forma parte de vmbr0, pero state disabled porque no hay carrier.

Decisión: Deja de tocar timers STP del bridge. Arregla el carrier del puerto.

Task 8: Comprobar síntomas en el switch indirectamente con LLDP (si está disponible)

cr0x@server:~$ lldpctl 2>/dev/null | sed -n '1,30p'
-------------------------------------------------------------------------------
LLDP neighbors:
-------------------------------------------------------------------------------

Significado: No hay vecinos LLDP. Eso concuerda con no carrier, o LLDP no corriendo, o el switch que no habla LLDP.

Decisión: Si esperas LLDP y no obtienes nada, te empuja hacia L1. Si obtienes vecinos, puedes identificar el switch/puerto exacto rápidamente.

Task 9: Comprobar si NetworkManager/systemd está peleando con ifupdown

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

Significado: Bien. Proxmox suele usar ifupdown2; no quieres que NetworkManager “ayude”.

Decisión: Si está activo, considera deshabilitarlo en una ventana de mantenimiento, porque pilas de red en conflicto crean problemas fantasma.

Task 10: Bajar/subir la interfaz limpiamente (poke controlado)

cr0x@server:~$ ifdown enp3s0 && ifup enp3s0
ifdown: interface enp3s0 not configured

Significado: En muchos hosts Proxmox, la interfaz física es “manual” y está controlada por el bridge; ifdown puede no aplicarse. No te asustes.

Decisión: Reinicia el bridge en su lugar (con cuidado) o usa ip link para alternar, pero solo si tienes acceso fuera de banda.

Task 11: Alternar el estado del enlace y comprobar si vuelve el carrier

cr0x@server:~$ ip link set dev enp3s0 down
cr0x@server:~$ ip link set dev enp3s0 up
cr0x@server:~$ ip -br link show enp3s0
enp3s0           DOWN           3c:fd:fe:aa:bb:cc <BROADCAST,MULTICAST>

Significado: Si permanece abajo sin carrier, esto no es un fallo de software transitorio.

Decisión: Ve a lo físico. Cambia cable/DAC. Revisa la configuración y estado del puerto del switch.

Task 12: Si es fibra/DAC, lee la EEPROM del módulo (cuando esté soportado)

cr0x@server:~$ ethtool -m enp3s0 | sed -n '1,25p'
Identifier                                : 0x03 (SFP)
Extended identifier                       : 0x04 (GBIC/SFP defined by 2-wire interface ID)
Connector                                 : 0x21 (Copper pigtail)
Transceiver codes                         : 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
Vendor name                               : GENERIC
Vendor PN                                 : DAC-10G-1M
Vendor rev                                : A
Vendor SN                                 : ABC123456789

Significado: Puedes ver qué módulo/cable estás usando. “GENERIC” está bien hasta que un vendor del switch decide que no.

Decisión: Si el enlace está abajo y el módulo parece sospechoso (tipo equivocado, vendor raro, velocidad incorrecta), cámbialo por una óptica/DAC conocida y soportada.

Task 13: Comprobar estado del bonding si el puerto del bridge es un bond

cr0x@server:~$ cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)

Bonding Mode: IEEE 802.3ad Dynamic link aggregation
MII Status: down
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0

802.3ad info
LACP rate: fast
Aggregator selection policy (ad_select): stable

Slave Interface: enp3s0
MII Status: down
Slave queue ID: 0

Slave Interface: enp4s0
MII Status: down
Slave queue ID: 0

Significado: El bond en sí está abajo porque todas las esclavas están abajo. Eso suele ser corriente arriba (problema del switch, ambos puertos deshabilitados, óptica equivocada) o un error físico compartido.

Decisión: Verifica que ambos puertos del switch estén habilitados y en el mismo grupo LACP. También verifica el cableado: dos enlaces caídos a menudo significan un mismo recorrido de patch panel mal usado dos veces.

Task 14: Verificar subinterfaces VLAN y la conciencia VLAN del bridge

cr0x@server:~$ ip -d link show vmbr0 | sed -n '1,12p'
7: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 3c:fd:fe:aa:bb:cc brd ff:ff:ff:ff:ff:ff
    bridge forward_delay 0 hello_time 2 max_age 20 ageing_time 300 stp_state 0 priority 32768 vlan_filtering 0

Significado: El bridge está arriba y tiene LOWER_UP aquí, por lo que existe carrier. (Esta tarea es para los casos de “no es carrier, es VLAN”.)

Decisión: Si las VMs siguen sin comunicarse, ahora pivota a etiquetado VLAN, trunking y reglas de firewall—porque el carrier está bien.

Task 15: Validar alcanzabilidad hacia el switch/router una vez que el carrier esté arriba

cr0x@server:~$ ping -c 3 -I vmbr0 10.20.30.1
PING 10.20.30.1 (10.20.30.1) from 10.20.30.11 vmbr0: 56(84) bytes of data.
64 bytes from 10.20.30.1: icmp_seq=1 ttl=64 time=0.322 ms
64 bytes from 10.20.30.1: icmp_seq=2 ttl=64 time=0.289 ms
64 bytes from 10.20.30.1: icmp_seq=3 ttl=64 time=0.301 ms

--- 10.20.30.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2036ms

Significado: La conectividad L3 básica funciona en el host. Si las VMs siguen fallando, céntrate en los puertos del bridge, el etiquetado VLAN y el firewall de las VMs.

Decisión: Decide si esto es un problema solo del host (VMs rotas) o del host+uplink (host roto también). Este ping marca esa línea.

Chiste #2: Si estás solucionando “no carrier” y aún no has tocado un cable, básicamente estás intentando SSH a una tostadora desenchufada.

Cable, switch, controlador: cómo se manifiesta cada modo de fallo

1) Problemas de cable/DAC/fibra (la mayoría poco glamurosa)

Los fallos de cable son aburridos, frecuentes y muy poco documentados. Los patch cords de cobre fallan por tensión, lengüetas dobladas o crimpeos mediocres. Los cables DAC fallan por radios de curvatura estrictos y blindajes baratos. La fibra falla por contaminación—sí, polvo que no ves. En todos estos, Linux reporta NO-CARRIER y Link detected: no.

Patrones clásicos:

• Siempre abajo: tipo de cable equivocado, puerto del switch muerto, puerto NIC muerto, óptica equivocada o puerto administrativamente deshabilitado.
• Flapping bajo carga: cable marginal, rarezas de EEE, terminación mala o movimiento físico (puerta del rack, tensión en el racimo de cables).
• Negocia a velocidad incorrecta: desajuste de auto-neg, pares malos o velocidad forzada en el switch.

Qué hacer: intercambia el elemento físico primero. Usa un cable/DAC/óptica conocido bueno de una bolsa etiquetada “funciona”. Si tu bolsa no está etiquetada, felicidades: tienes una bolsa de misterios.

2) Problemas del puerto del switch (configuración, seguridad y “ayuda” silenciosa)

Los switches pueden matar la conectividad de formas que parecen fallos físicos. Algunos son honestos (admin shutdown). Otros son “protectores” (port security, err-disable, BPDU guard). Y otros simplemente están mal configurados (velocidad/duplex fijado).

Distingue:

• Sin carrier normalmente significa que el puerto del switch no está transmitiendo pulsos de enlace (deshabilitado, fallado, transceptor equivocado, óptica incompatible).
• Carrier arriba pero tráfico muerto suele significar mismatch de VLAN, bloqueo STP, seguridad de puertos o ajustes incorrectos de LACP/static.

No adivines. Obtén el estado del puerto del switch del equipo de red o accede tú mismo. Si no puedes, usa LLDP e historial de enlace en el host para inferir qué sucede.

3) Driver/firmware/BIOS/gestión de energía (los casos “ayer funcionaba”)

Cuando un host Proxmox está estable meses y luego empieza a perder carrier después de una actualización del kernel, sueles estar ante:

• Regresión del driver para un modelo específico de NIC.
• Desajuste de firmware (especialmente con NICs de servidor que dependen de comportamientos NVM/firmware).
• Funciones de gestión de energía: ASPM, estados C profundos, EEE.
• Problemas PCIe: riser defectuoso, ranura marginal, ajustes BIOS.

La clave es la correlación: ¿los logs muestran flaps a la misma hora cada día (políticas de energía)? ¿Empezó después de actualizar pve-kernel? ¿Moviste cables y “arregló” accidentalmente por un rato? Tu evidencia debe ser cronológica, no emocional.

Tres microhistorias corporativas (cómo duele esto en la vida real)

Microhistoria #1: El outage causado por una suposición equivocada

Una empresa mediana gestionaba un clúster Proxmox para servicios internos: runners de CI, almacenamiento de artefactos, algunas bases de datos y el habitual montón de VMs “temporales” que se volvieron permanentes. Tras una limpieza rutinaria del rack, un nodo empezó a gritar: bridge port has no carrier. El ingeniero on‑call supuso que era un problema de etiquetado VLAN porque recientemente habían introducido bridges con conciencia VLAN.

Pasaron una hora mirando /etc/network/interfaces, alternando filtrado VLAN y recargando la pila de red. El enlace siguió abajo. La suposición “nueva característica VLAN igual a nuevo problema VLAN” era reconfortante y errónea.

Finalmente alguien fue al rack. El cable uplink se había movido del NIC del nodo al puerto IPMI por un contratista bienintencionado que vio dos jacks RJ45 idénticos y eligió el caos. El host no tenía carrier porque literalmente no estaba conectado a la red que debía.

La solución tardó 30 segundos: devolver el cable. El postmortem tardó más pero importó: etiquetaron los puertos, documentaron qué NIC física mapea a qué nombre enp* y activaron LLDP en switches y hosts para que la pregunta “¿en qué puerto estoy?” tuviera respuesta sin ir al rack.

Microhistoria #2: La optimización que salió mal

Otra organización quiso reducir consumo y calor en un clúster denso. Alguien activó EEE agresivamente en los switches de acceso y también retocó estados de energía en BIOS. No tocaron la red de Proxmox, por eso el incidente fue tan confuso: nodos aleatorios perdían carrier por segundos y luego se recuperaban.

El patrón fue malo: ocurría más en periodos de bajo tráfico, lo que hizo a la gente culpar a “monitoring” o “ventanas de backup” en lugar de la capa física. Los logs mostraban ciclos link down/up. Los logs del switch no estaban evidentemente alterados. Las VMs a veces quedaban fenceadas porque los heartbeats de corosync no soportaban siestas inesperadas.

El verdadero culpable fue una combinación: ciertas NICs de esa generación no convivían bien con las transiciones EEE de ese modelo de switch. La “optimización” hizo que el PHY negociara estados de energía que parecían desconexiones intermitentes.

Lo arreglaron desactivando EEE en los puertos usados por los nodos Proxmox (no en todos) y revirtiendo los estados de energía más agresivos. El consumo subió un poco. El uptime subió dramáticamente. Todos fingieron que así había sido el plan desde el principio.

Microhistoria #3: La práctica tediosa pero correcta que salvó el día

Un equipo de servicios financieros tenía una práctica que parecía tediosa: cada vez que parcheaban o movían un cable, ejecutaban un script rápido de “validación de enlace” en el host y capturaban la salida antes/después en el ticket. Incluía ip -br link, ethtool y búsquedas en journalctl para eventos de enlace.

Durante un mantenimiento, se reemplazó un switch top-of-rack. Un nodo Proxmox arrancó con “no carrier” en un miembro del bond. El equipo de red insistía en que el puerto estaba configurado correctamente. El equipo de servidores decía que la NIC estaba bien. El ticket tenía el estado previo mostrando ambos enlaces del bond estables a 10G durante meses, más la info EEPROM exacta del transceptor.

Esa evidencia acotó el problema rápido: el nuevo switch tenía una política de ópticas distinta y no le gustaba el DAC “GENERIC” en ese puerto. Cambiaron el DAC por uno soportado. El enlace vino arriba al instante. Sin tormenta de culpas ni cambios VLAN fantasmas.

La práctica no era glamorosa. No requería una herramienta nueva. Simplemente obligaba al equipo a capturar la línea base “conocida buena”. Cuando ocurrió el incidente, no estaban depurando a oscuras—comparaban la realidad con una instantánea guardada de la realidad.

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

Estos son los reincidentes que veo en entornos Proxmox—especialmente tras trabajos en el rack, cambios de switch, actualizaciones de kernel o “refactors” menores.

1) Síntoma: “bridge port has no carrier” tras mover un host

• Causa raíz: Cable en puerto NIC equivocado (o en IPMI), mapeo de patch panel incorrecto o puerto del switch equivocado.
• Solución: Usa ethtool -P (MAC permanente), LLDP si está disponible, y verifica físicamente la ruta del cable. Etiqueta ambos extremos. Si puedes, estandariza: la NIC más a la izquierda siempre es uplink A, etc.

2) Síntoma: Enlace hace flapping cada pocos minutos

• Causa raíz: Cable de cobre marginal, keystone jack defectuoso, violación del radio de curvatura del DAC o interacción con EEE.
• Solución: Reemplaza el segmento físico primero. Si persiste, desactiva EEE en NIC y/o puerto del switch para diagnóstico. Revisa logs para frecuencia y correlación del flap.

3) Síntoma: Bond aparece abajo aunque un cable esté conectado

• Causa raíz: Mismatch de LACP (el switch espera LACP pero el host está en active-backup, o viceversa), o ambas esclavas cableadas al mismo puerto del switch por error de patch.
• Solución: Revisa /proc/net/bonding/bond0 en el host y la configuración del port-channel en el switch. Confirma que cada esclava va al puerto físico del switch previsto.

4) Síntoma: Enlace arriba, pero Proxmox sigue mostrando advertencia intermitente

• Causa raíz: El bridge incluye una interfaz sin uso que está abajo; Proxmox la reporta. O un segundo puerto en un bond está desenchufado.
• Solución: Elimina puertos no usados del bridge/bond, o conéctalos correctamente. No mantengas miembros “para expansión futura” en la config de producción si te gustan las falsas alertas.

5) Síntoma: Tras actualización del kernel, la NIC deja de obtener carrier al arrancar

• Causa raíz: Regresión de driver o interacción con firmware; ocasionalmente cambios en comportamiento de ASPM/gestión de energía PCIe.
• Solución: Confirma versiones de driver/firmware, revisa dmesg por errores y prueba arrancar con un kernel anterior si está disponible. Planea una actualización de firmware y considera fijar un kernel conocido bueno hasta resolverlo.

6) Síntoma: Puerto SFP no muestra carrier solo con ciertas ópticas

• Causa raíz: Compatibilidad de óptica/DAC, tipo equivocado (SR vs LR), velocidad incorrecta (módulo 1G en puerto 10G) o comportamiento de vendor.
• Solución: Lee la info del módulo con ethtool -m, cambia a una óptica conocida soportada y verifica que el puerto del switch soporte la velocidad prevista.

7) Síntoma: “No carrier” solo después de reboot, se arregla al reseat del cable

• Causa raíz: Conector físico desgastado, la pestaña no calza o un transceptor que no inicializa fiable.
• Solución: Reemplaza el patch cable o el transceptor. “Reseat para arreglar” es un síntoma, no una solución.

Listas de verificación / plan paso a paso

Checklist A: Llegar de la alerta a la causa raíz en 10 minutos

1. Confirma la interfaz exacta: ip -br link. Identifica qué puerto está DOWN/NO-CARRIER.
2. Confirma carrier con ethtool: ethtool enpXsY. Si Link detected: no, trátalo como L1.
3. Revisa pertenencia al bridge: bridge link. Asegúrate de que sea el puerto/bond esperado.
4. Revisa logs para flap vs caída total: journalctl -k -b grep link up/down.
5. Intercambia el elemento físico más simple: cable/DAC/óptica.
6. Mueve a otro puerto del switch: elimina rápidamente un puerto defectuoso o en estado err-disable.
7. Si hay bonding: revisa /proc/net/bonding/bond0 y compara con la config LACP del switch.
8. Si sigue muerto: identifica driver/firmware (ethtool -i, lspci -nnk) y considera actualización de firmware o rollback de kernel.

Checklist B: Antes de tocar la red de producción

1. Tener acceso fuera de banda (IPMI/iKVM). Si no lo tienes, tu “rebote rápido” es un movimiento que limita tu carrera.
2. Capturar estado: ip a, ip r, bridge link, ethtool, y las últimas 200 líneas del log del kernel.
3. Saber cómo es el estado “bueno”: velocidad, duplex, vecino LLDP esperado y qué puerto del switch debería encenderse.
4. Hacer un cambio a la vez. La red no es una máquina tragaperras.

Checklist C: Endurecimiento para que esto no te despierte otra vez

1. Etiquetar puertos NIC en el chasis y en tu CMDB/tickets. Mapea enp* a puertos físicos.
2. Habilitar LLDP en tu entorno si es posible (host + switch). Es verdad barata.
3. Estandarizar ópticas/DAC. Mezclar transceptores es cómo se crían fallos intermitentes.
4. Mantener firmware razonablemente actualizado en NICs, especialmente adaptadores Intel/Broadcom de servidor.
5. Alertar sobre flaps de enlace, no solo sobre enlace caído. Los flaps son la alarma de humo; el link-down es el incendio.
6. Documentar perfiles de puertos del switch para uplinks de hipervisores (LACP, trunk VLAN, MTU). La repetibilidad vence a las heroicidades.

Preguntas frecuentes

1) ¿“no carrier” siempre significa un cable malo?

No, pero trátalo así primero. “No carrier” significa que el PHY no ve enlace. Cable/DAC/óptica y estado del puerto del switch son las causas comunes. Drivers y firmware son menos comunes pero reales.

2) ¿Una mala configuración de VLAN puede causar “bridge port has no carrier”?

No típicamente. Los errores de VLAN suelen mantener el enlace arriba pero romper el tráfico. Si ethtool dice Link detected: no, las VLANs no son la causa.

3) Proxmox muestra la advertencia, pero el host aún tiene conectividad. ¿Por qué?

A menudo porque el bridge tiene varios puertos y uno está abajo (p. ej., un miembro del bond desenchufado), o hay una interfaz sin uso aún adjunta. Proxmox reporta el puerto abajo aunque exista otro camino funcional.

4) ¿Cuál es la prueba más rápida de que es un problema del switch?

Mueve el cable a un puerto conocido bueno del switch (con el mismo perfil de configuración). Si el enlace sube inmediatamente, tu puerto original del switch está mal configurado, deshabilitado o defectuoso.

5) ¿Cómo sé si mi SFP/DAC es incompatible?

Léelo con ethtool -m (si está soportado) y compáralo con lo que funciona en otros equipos. Si el mismo host+puerto funciona con otro módulo pero no con este, el módulo es culpable. Si el módulo funciona en otro switch pero no en este, te has topado con política de compatibilidad del vendor.

6) ¿Es seguro rebotar el bridge en un nodo Proxmox?

Solo si tienes acceso fuera de banda y entiendes qué tráfico vas a cortar. Rebotar vmbr0 corta la conectividad para el host y las VMs que lo usan. Úsalo como paso diagnóstico controlado, no por reflejo.

7) Mi bond está en modo LACP; ¿puede ocurrir “no carrier”?

Sí. LACP es L2, pero carrier es L1. Si ambos enlaces físicos están abajo (o las ópticas no se reconocen), el bond baja. Si un enlace está abajo, el bond puede seguir arriba con capacidad reducida y comportamiento de tráfico distinto según hashing.

8) Tras reemplazar un switch, solo algunos hosts Proxmox pierden carrier. ¿Por qué no todos?

NICs y ópticas diferentes se comportan distinto. El switch nuevo puede ser más estricto con el codificado de transceptores, puede usar valores por defecto de velocidad/auto-neg distintos o tener defaults de EEE diferentes. Hardware heterogéneo convierte un “swap simple” en “laboratorio sorpresa”.

9) ¿Puede una NIC estar “UP” en ip link pero aun así no tener carrier?

Sí. UP significa administrativamente habilitada. Carrier es la señal de la capa inferior indicada por LOWER_UP. Puedes tener UP sin LOWER_UP.

10) ¿Y si el switch muestra enlace arriba pero Linux dice no carrier?

Es raro pero puede ocurrir con transceptores defectuosos, negociación rara o una configuración de mirroring/monitoring que engañe a los LEDs. Confía en ethtool y los logs, y valida cambiando ópticas/puertos para desempatar.

Conclusión: pasos siguientes para evitar repeticiones

“Bridge port has no carrier” es un mensaje directo con un subtexto útil: deja de depurar overlays y comienza a depurar el underlay. Si la NIC no ve enlace, tu bridge es inocente y tus VMs son daños colaterales.

Haz esto a continuación, en orden:

1. Ejecuta ip -br link y ethtool para confirmar el verdadero no‑carrier.
2. Cambia el elemento físico (cable/DAC/óptica). Luego prueba otro puerto del switch.
3. Si hace flapping, extrae la línea temporal con journalctl -k y considera interacciones EEE/energía/driver.
4. Una vez restaurado el carrier, valida L2/L3 (estado del bond, etiquetado VLAN, ping al gateway) y solo entonces profundiza en problemas a nivel VM.
5. Finalmente, hazlo aburrido: etiqueta puertos, estandariza ópticas y captura estados antes/después en los tickets de cambio.

La victoria no es solo arreglar el outage de hoy. Es asegurarte de que el próximo “no carrier” tome cinco minutos y un cambio de cable, no un baile interpretativo a medianoche con la configuración del bridge.