Proxmox « bridge port has no carrier » : dépannage rapide pour câble, switch et pilote

Ce que signifie réellement « bridge port has no carrier »

Dans Proxmox, le réseau de vos VM repose généralement sur un bridge Linux comme vmbr0. Ce bridge a un ou plusieurs ports (généralement une NIC physique comme enp3s0 ou un bond comme bond0). L’erreur apparaît lorsque le port signale no carrier — la façon dont Linux dit « le lien est down ».

Carrier n’est pas « je peux pinguer la passerelle ». Carrier est le signal physique ou au niveau PHY : l’interface ne peut pas négocier de lien avec ce qui est à l’autre bout. Si c’est un port cuivre, c’est habituellement le câble/le switch. Si c’est de la fibre/DAC, c’est la compatibilité du module SFP, la polarité de la fibre, ou la configuration du port du switch. Si c’est un bond, cela peut être un mismatch LACP. Si c’est un pilote, cela peut être des problèmes de firmware/driver, gestion d’énergie, ou une NIC dans un état étrange.

Un avertissement sur le bridge est souvent le messager qui se fait tirer dessus. Le bridge est bien. Le port est le problème. Votre mission : découvrir pourquoi le port a perdu le carrier, pas pourquoi Proxmox s’en est plaint.

Une citation exacte, parce qu’elle s’applique à ce travail : « L’espoir n’est pas une stratégie. » — Vince Lombardi

Feuille de route de diagnostic rapide (premier/deuxième/troisième)

Premier : Prouvez s’il s’agit vraiment d’un lien (L1) ou de quelque chose de supérieur

1. Vérifiez l’état du lien depuis l’hôte (ip link, ethtool). S’il indique NO-CARRIER ou Link detected: no, traitez‑le comme L1 jusqu’à preuve du contraire.
2. Vérifiez les LEDs et le statut du port du switch. Une LED éteinte est un cadeau : cela veut dire que vous pouvez arrêter de débattre des VLANs.
3. Remplacez l’élément connu‑bon : câble/DAC/SFP ou déplacez vers un port de switch connu‑bon. Faites‑le tôt. C’est plus rapide que d’être trop malin.

Second : Si le carrier est présent, chassez les problèmes L2/LACP/VLAN

1. Vérifiez l’appartenance au bridge (bridge link). Assurez‑vous que la bonne interface est esclave du bridge.
2. Vérifiez que le mode VLAN correspond au switch (VLAN natif vs tagué, trunks). Un mismatch de trunk n’affiche pas habituellement « no carrier », mais il donne souvent l’impression que « tout est mort » et les gens se trompent.
3. Si bonding, confirmez l’état LACP (cat /proc/net/bonding/bond0) et l’agrégation côté switch.

Troisième : Si le lien clignote ou négocie mal, suspectez pilote/firmware/EEE

1. Recherchez des événements de link flap dans journalctl et dmesg.
2. Identifiez le pilote et le firmware (ethtool -i, lspci -nnk).
3. Désactivez les éléments connus problématiques pour le diagnostic (EEE sur cuivre, offloads dans de rares cas, ASPM). Testez. Rétablissez si ça n’aide pas.

Blague #1 : La manière la plus rapide de dépanner un lien est de supposer que c’est le câble — parce que c’est presque toujours le câble, jusqu’à la fois où c’est le SFP que vous aviez « emprunté » d’un tiroir.

Faits et contexte historique utiles (vous diagnostiquerez plus vite)

• « Carrier detect » est plus ancien que votre hyperviseur : le terme vient des premiers réseaux et signaux modem — Linux a gardé le vocabulaire parce qu’il correspond bien à l’état PHY du lien.
• Les bridges Linux sont natifs au noyau, pas une « chose Proxmox » : Proxmox les configure, mais la logique et la télémétrie sont les outils Linux standards (iproute2, bridge, ethtool).
• L’auto‑négociation est une source récurrente de douleur depuis Fast Ethernet : une négociation mismatched peut provoquer des flaps, de mauvaises vitesses/duplex, ou un « lien up mais inutile ».
• Energy Efficient Ethernet (EEE) a été conçu pour économiser de l’énergie : sur certaines combinaisons NIC+switch, il économise aussi votre disponibilité (par accident, et pas en bien).
• Les modules SFP ont des « codes » et des vérifications de compatibilité : beaucoup de fournisseurs appliquent des préférences à leurs optiques ; certaines NIC et switches sont pointilleux, et le mode de défaillance est souvent un « pas de lien » net.
• Les câbles DAC ne sont pas de simples câbles cuivre : ils intègrent de l’identification et ont des contraintes de longueur/qualité ; un DAC bon marché peut négocier à 1G mais échouer à 10G.
• LACP (802.3ad) n’est pas « configuré et oublié » : un côté en LAG statique et l’autre en LACP peut produire une connectivité partielle, du blackholing, ou un carrier intermittent selon l’implémentation.
• Nommage d’interface prévisible (enpXsY) : systemd/udev a réduit la roulette « eth0 », mais cela a aussi fait que des humains lisent mal les identifiants NIC et branchent le mauvais port.
• STP et sécurité de port existent pour éviter les boucles : le switch peut fermer ou bloquer un port après des événements topologiques ; l’hôte voit le lien, mais le trafic meurt — différent du no‑carrier, mais souvent confondu pendant les incidents.

Tâches pratiques : commandes, sorties et décisions

Voici les tâches que j’exécute en production quand Proxmox signale bridge port has no carrier. Chacune inclut : la commande, un exemple de sortie réelle, ce que cela signifie, et la décision à prendre.

Task 1: Confirm which interface is actually “no carrier”

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>

Signification : enp3s0 est down et vmbr0 en hérite. Un bridge sans uplink actif est essentiellement un parking sans route de sortie.

Décision : Arrêtez d’examiner la config des VM. Vous êtes en territoire NIC hôte / switch / câble.

Task 2: Check carrier and negotiated parameters with 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

Signification : La NIC ne voit pas les impulsions de lien. Ce n’est pas un problème de VLAN.

Décision : Vérifiez la couche physique : câble, baie de brassage, port du switch, transceiver.

Task 3: Confirm the bridge is configured how you think it is

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

Signification : vmbr0 est adossé à enp3s0. Si enp3s0 est mort, tout sur vmbr0 est mort.

Décision : Vérifiez le câble physique branché sur le port NIC correspondant à enp3s0. Ne supposez pas que le marquage soit correct.

Task 4: Identify the NIC and the loaded driver

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

Signification : Vous savez maintenant quel silicium vous avez en face. Cela compte pour les quirks connus du pilote et les outils de firmware.

Décision : Si vous suspectez un problème de pilote, vous pouvez rechercher en interne par ID de périphérique/driver, et valider le firmware et les paramètres du module.

Task 5: Check driver and firmware versions from 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

Signification : Confirme le noyau/driver et le firmware de la NIC. Si vous voyez des flaps après une mise à jour du noyau, c’est ici que vous commencez à corréler.

Décision : Si le firmware est ancien ou disparate entre hôtes, planifiez une mise à jour ; pour l’instant continuez le diagnostic L1.

Task 6: Look for link flap messages in the 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

Signification : Le lien oscille. C’est généralement un câble défectueux, un port défectueux, des optiques/DAC marginaux, ou un comportement EEE — pas un problème de configuration du bridge.

Décision : Remplacez d’abord câble/DAC. Si ça persiste, changez de port switch. Si ça persiste encore, désactivez EEE et vérifiez le firmware NIC.

Task 7: Verify bridge port state and whether it’s actually enslaved

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

Signification : Le port fait partie de vmbr0, mais state disabled car il n’y a pas de carrier.

Décision : Arrêtez de bidouiller les timers STP du bridge. Réparez le carrier du port.

Task 8: Check switch-side symptoms indirectly with LLDP (if available)

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

Signification : Aucun voisin LLDP. C’est cohérent avec pas de carrier, ou LLDP non installé, ou le switch qui ne parle pas LLDP.

Décision : Si vous attendiez LLDP et n’obtenez rien, cela vous pousse vers L1. Si vous obtenez des voisins, vous pouvez identifier rapidement le switch/port exact.

Task 9: Check if NetworkManager/systemd is fighting ifupdown

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

Signification : Bien. Proxmox utilise typiquement ifupdown2 ; vous ne voulez pas que NetworkManager « aide ».

Décision : S’il est actif, envisagez de le désactiver en fenêtre de maintenance, car les piles réseau qui se font concurrence créent des problèmes fantômes.

Task 10: Bring the interface down/up cleanly (controlled poke)

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

Signification : Sur de nombreux hôtes Proxmox, l’interface physique est « manual » et contrôlée via le bridge ; ifdown peut ne pas s’appliquer. Ne paniquez pas.

Décision : Redémarrez le bridge à la place (avec précaution) ou utilisez ip link pour basculer, mais seulement si vous avez un accès hors bande.

Task 11: Toggle link state and check if carrier returns

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>

Signification : S’il reste down sans carrier, ce n’est pas un hic logiciel transitoire.

Décision : Allez sur le physique. Remplacez câble/DAC. Vérifiez la config et le statut du port du switch.

Task 12: If it’s fiber/DAC, read the module EEPROM (when supported)

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

Signification : Vous pouvez voir quel module/câble vous utilisez. « GENERIC » convient jusqu’au jour où un fournisseur décide que non.

Décision : Si le lien est down et que le module semble suspect (mauvais type, vendeur étrange, mauvaise vitesse), remplacez par une optique/DAC connue‑bonne et supportée.

Task 13: Check bonding state if the bridge port is a 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

Signification : Le bond est lui‑même down parce que tous les esclaves sont down. C’est souvent à l’amont (problème de stack switch, deux ports désactivés, optiques incorrectes) ou une erreur physique partagée.

Décision : Vérifiez que les deux ports switch sont activés et dans le même groupe LACP. Vérifiez aussi le câblage : deux liens morts souvent signifient un même trajet de brassage mal utilisé deux fois.

Task 14: Verify VLAN subinterfaces and bridge VLAN awareness

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

Signification : Le bridge est up et a LOWER_UP ici, donc le carrier existe. (Cette tâche concerne les cas « ce n’est pas carrier, c’est VLAN ».)

Décision : Si les VM ne peuvent toujours pas communiquer, pivotez maintenant vers le taggage VLAN, le trunking et les règles de pare‑feu — car le carrier est bon.

Task 15: Validate reachability to the switch/router once carrier is up

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

Signification : La connectivité L3 de base fonctionne sur l’hôte. Si les VM échouent encore, concentrez‑vous sur les ports du bridge, le taggage VLAN et le pare‑feu des VM.

Décision : Décidez si c’est un problème uniquement hôte (VMs en panne) ou hôte+uplink (hôte en panne aussi). Ce ping trace cette ligne.

Blague #2 : Si vous dépannez un « no carrier » et que vous n’avez pas encore touché un câble, vous essayez essentiellement de SSH dans un grille‑pain débranché.

Câble, switch, pilote : à quoi ressemble chaque mode de défaillance

1) Problèmes câble/DAC/fibre (la majorité peu glamour)

Les défaillances de câble sont ennuyeuses, fréquentes et largement sous‑documentées. Les cordons cuivre de brassage tombent en panne par contrainte, languettes pliées, ou sertissage médiocre. Les câbles DAC lâchent à cause de courbures serrées et d’un blindage bon marché. La fibre échoue à cause de contamination — oui, de la poussière invisible. Dans tous ces cas, Linux rapporte NO-CARRIER et Link detected: no.

Schémas classiques :

• Toujours down : mauvais type de câble, port switch mort, port NIC mort, optique incorrecte, ou port administrativement désactivé.
• Flapping sous charge : câble marginal, comportement EEE, mauvaise terminaison, ou mouvement physique (porte d’armoire, tension du faisceau).
• Négocie à une mauvaise vitesse : mismatch d’auto‑négociation, paires abîmées, ou vitesse forcée sur le switch.

Que faire : remplacez d’abord l’élément physique. Utilisez un câble/DAC/optique connu‑bon provenant d’un sac marqué « works ». Si votre sac n’est pas étiqueté, félicitations : vous avez un sac de mystères.

2) Problèmes de port switch (config, sécurité et « aides » silencieuses)

Les switches peuvent tuer la connectivité de manières qui ressemblent à une défaillance physique. Certains sont honnêtes (shutdown admin). D’autres sont « protecteurs » (port security, err‑disable, BPDU guard). Et certains sont simplement mal configurés (vitesse/duplex codé en dur).

Distinguez :

• Pas de carrier signifie généralement que le port du switch n’émet pas d’impulsions de lien (désactivé, défaillant, mauvais transceiver, optique incompatible).
• Carrier up mais trafic mort signifie souvent mismatch VLAN, blocage STP, port security, ou mauvais réglages LACP/static.

Ne devinez pas. Obtenez le statut du port du switch auprès de l’équipe réseau ou depuis votre propre accès. Si vous ne pouvez pas, utilisez LLDP et l’historique de lien sur l’hôte pour inférer ce qui se passe.

3) Pilote/firmware/BIOS/gestion d’alimentation (les cas « ça marchait hier »)

Quand un hôte Proxmox est stable pendant des mois puis commence à perdre le carrier après une mise à jour du noyau, vous regardez souvent :

• Régression du pilote pour un modèle NIC spécifique.
• Mismatch de firmware (surtout avec des NIC serveur dépendant du NVM/firmware).
• Fonctions de gestion d’énergie : ASPM, états C profonds, EEE.
• Problèmes PCIe : riser défectueux, slot marginal, paramètres BIOS.

L’essentiel est la corrélation : les logs montrent‑ils des flaps à la même heure chaque jour (politiques d’alimentation) ? Est‑ce apparu après la mise à jour de pve-kernel ? Avez‑vous déplacé des câbles et « réparé » accidentellement temporairement ? Vos preuves doivent être chronologiques, pas émotionnelles.

Trois micro‑histoires en entreprise (comment ça mord dans la vraie vie)

Mini‑histoire #1 : L’incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne exploita un cluster Proxmox pour des services internes : runners CI, stockage d’artefacts, quelques bases de données, et la pile habituelle de VM « temporaires » devenues permanentes. Après un nettoyage de baie, un nœud se mit à hurler : bridge port has no carrier. L’ingénieur de garde supposa que c’était un problème de taggage VLAN car ils avaient récemment introduit des bridges VLAN‑aware.

Ils passèrent une heure à scruter /etc/network/interfaces, basculer le filtrage VLAN et recharger le réseau. Le lien resta down. L’hypothèse « nouvelle fonctionnalité VLAN = nouveau problème VLAN » était réconfortante et fausse.

Finalement, quelqu’un alla au rack. Le câble uplink avait été déplacé du NIC du nœud vers le port IPMI par un entrepreneur de bonne volonté qui avait vu deux prises RJ45 identiques et choisi le chaos. L’hôte n’avait pas de carrier car il n’était littéralement pas connecté au réseau attendu.

La réparation prit 30 secondes : remettre le câble. Le post‑mortem prit plus de temps mais fut utile : ils ont étiqueté les ports, documenté la correspondance physique enp*, et ajouté LLDP sur switches et hôtes pour que la question « sur quel port suis‑je ? » soit répondable sans monter au rack.

Mini‑histoire #2 : L’optimisation qui s’est retournée contre eux

Une autre équipe voulut réduire la consommation et la chaleur dans un cluster dense. Quelqu’un activa EEE de façon agressive sur les switches d’accès et changea aussi des états d’alimentation BIOS. Ils ne touchèrent pas au réseau Proxmox du tout, ce qui rendit l’incident d’autant plus déroutant : des nœuds perdaient aléatoirement le carrier pendant quelques secondes, puis récupéraient.

Le schéma était vicieux : cela se produisait plus souvent en période de faible trafic, ce qui fit blâmer le monitoring ou les fenêtres de sauvegarde plutôt que la couche physique. Les logs montraient des cycles link down/up. Les logs du switch n’étaient pas manifestement furieux. Les VM perdaient parfois le quorum car les heartbeats corosync n’aimaient pas ces siestes surprises.

Le véritable coupable fut une combinaison : certaines générations de NIC ne s’entendaient pas avec les transitions EEE sur ce modèle de switch. L’« optimisation » fit négocier l’état d’alimentation du PHY d’une manière qui ressemblait à un débranchement intermittent.

Ils corrigèrent en désactivant EEE sur les ports utilisés par les nœuds Proxmox (pas partout), et en revenant sur les réglages d’alimentation les plus agressifs. La consommation augmenta légèrement. La disponibilité augmenta considérablement. Tout le monde fit comme si c’était prévu.

Mini‑histoire #3 : La pratique ennuyeuse mais correcte qui a sauvé la situation

Une équipe de services financiers avait l’habitude apparemment fastidieuse : chaque fois qu’ils patchaient ou bougeaient un câble, ils exécutaient un petit script de « validation de lien » sur l’hôte et capturaient les sorties before/after dans le ticket. Il incluait ip -br link, ethtool, et des greps journalctl pour les événements de lien.

Lors d’une maintenance, un switch top‑of‑rack fut remplacé. Un nœud Proxmox remonta avec « no carrier » sur un membre de bond. L’équipe réseau affirmait que le port était configuré correctement. L’équipe serveur jurait que la NIC allait bien. Le ticket contenait l’état avant montrant les deux liens du bond stables à 10G depuis des mois, plus l’info EEPROM du transceiver exacte.

Cette preuve resserra rapidement l’enquête : le nouveau switch avait une politique d’optiques différente et n’aimait pas le DAC « GENERIC » sur ce port précis. Ils remplacèrent le DAC par un modèle supporté. Le lien remonta instantanément. Pas de tempête de reproches, pas de changements VLAN fantômes.

La pratique n’était pas glamour. Elle ne nécessitait pas un nouvel outil. Elle contraignit simplement l’équipe à capturer la baseline « connue‑bonne ». Quand l’incident survint, ils ne déboguaient pas dans le noir — ils comparaient la réalité à un instantané sauvegardé de la réalité.

Erreurs courantes : symptôme → cause racine → correctif

Voici les récidivistes que je vois dans les environnements Proxmox — surtout après des travaux de baie, changements de switch, mises à jour du noyau, ou refactors « mineurs ».

1) Symptom: « bridge port has no carrier » après déplacement d’un hôte

• Cause racine : Câble sur le mauvais port NIC (ou branché sur IPMI), mauvais mapping panneau de brassage, ou mauvais port switch.
• Correctif : Utilisez ethtool -P (MAC permanente), LLDP si disponible, et vérifiez physiquement le trajet du câble. Étiquetez les deux extrémités. Si possible, standardisez : NIC la plus à gauche = uplink A, etc.

2) Symptom: Link clignote toutes les quelques minutes

• Cause racine : Câble cuivre marginal, prise keystone défectueuse, violation du rayon de courbure DAC, ou interaction EEE.
• Correctif : Remplacez d’abord le segment physique. Si persistant, désactivez EEE sur la NIC et/ou le port switch pour le diagnostic. Vérifiez les logs pour fréquence et corrélation des flaps.

3) Symptom: Bond affiché down bien qu’un câble soit connecté

• Cause racine : Mismatch LACP (le switch attend LACP mais l’hôte est en active‑backup, ou inversement), ou les deux esclaves sont mal patchés sur le même port switch via erreur de brassage.
• Correctif : Vérifiez /proc/net/bonding/bond0 côté hôte et la configuration du port‑channel sur le switch. Confirmez que chaque esclave va au port switch prévu.

4) Symptom: Lien up, mais Proxmox affiche toujours un avertissement intermittant

• Cause racine : Le bridge inclut une interface inutilisée qui est down ; Proxmox la signale. Ou un second port dans un bond est débranché.
• Correctif : Retirez les ports inutilisés du bridge/bond, ou branchez‑les correctement. Ne gardez pas des membres « pour extension future » en config de production sauf si vous aimez les fausses alertes.

5) Symptom: Après une mise à jour du noyau, la NIC ne reçoit plus de carrier au démarrage

• Cause racine : Régression du pilote ou interaction firmware ; parfois comportement ASPM/gestion d’énergie PCIe change.
• Correctif : Confirmez versions driver/firmware, vérifiez dmesg pour erreurs, et testez le boot sur un noyau plus ancien si disponible. Planifiez une mise à jour firmware et envisagez d’épingler un noyau connu‑bon jusqu’à résolution.

6) Symptom: Port SFP sans carrier seulement avec certaines optiques

• Cause racine : Compatibilité optique/DAC, mauvais type (SR vs LR), mauvaise vitesse (module 1G dans port 10G), ou politique vendor lock.
• Correctif : Lisez le module avec ethtool -m, remplacez par une optique connue‑bonne supportée, et vérifiez que le port switch supporte la vitesse voulue.

7) Symptom: « No carrier » seulement après reboot, corrigé en reseatant le câble

• Cause racine : Connecteur physique usé, verrou non enclenché, ou transceiver qui ne s’initialise pas fiablement.
• Correctif : Remplacez le cordon de brassage ou le transceiver. « Reseat pour réparer » est un symptôme, pas une solution.

Listes de contrôle / plan étape par étape

Checklist A: Passer de l’alerte à la cause racine en 10 minutes

1. Confirmez l’interface exacte : ip -br link. Identifiez quel port est DOWN/NO-CARRIER.
2. Confirmez le carrier avec ethtool : ethtool enpXsY. Si Link detected: no, traitez‑le comme L1.
3. Vérifiez l’appartenance au bridge : bridge link. Assurez‑vous que c’est le port/bond attendu.
4. Vérifiez les logs pour flap vs down permanent : journalctl -k -b grep link up/down.
5. Remplacez l’élément physique le plus simple : câble/DAC/optique.
6. Déplacez vers un autre port switch : élimine rapidement un port mauvais ou en err‑disable.
7. Si bondé : vérifiez /proc/net/bonding/bond0 et alignez la config LACP du switch.
8. Si toujours mort : identifiez driver/firmware (ethtool -i, lspci -nnk) et envisagez mise à jour firmware ou rollback noyau.

Checklist B: Avant de toucher au réseau de production

1. Ayez un accès hors bande (IPMI/iKVM). Si vous ne l’avez pas, votre « restart rapide » est un geste risqué pour votre carrière.
2. Capturez l’état : ip a, ip r, bridge link, ethtool, et les 200 dernières lignes du journal noyau.
3. Sachez à quoi ressemble le « bon » : vitesse, duplex, voisin LLDP attendu, et quel port switch devrait s’allumer.
4. Faites un changement à la fois. Le réseau n’est pas une machine à sous.

Checklist C: Durcir pour ne plus être réveillé

1. Étiquetez les ports NIC sur le châssis et dans votre CMDB/tickets. Mappez enp* aux ports physiques.
2. Activez LLDP dans votre environnement si possible (hôte + switch). C’est une vérité peu coûteuse.
3. Standardisez optiques/DAC. Des boîtes mixtes d’transceivers sont la source de pannes intermittentes.
4. Gardez le firmware raisonnablement à jour sur les NIC, surtout Intel/Broadcom pour serveurs.
5. Alertez sur les flaps, pas seulement sur un lien down. Les flaps sont l’alarme incendie ; link‑down est le feu.
6. Documentez les profils de ports switch pour les uplinks d’hyperviseur (LACP, trunk VLAN, MTU). La répétabilité bat le sauvetage héroïque.

FAQ

1) « No carrier » signifie‑t‑il toujours un câble défectueux ?

Non, mais traitez‑le comme tel en premier. « No carrier » signifie que le PHY ne voit pas le lien. Câble/DAC/optique et état du port switch sont les causes courantes. Les pilotes et firmwares sont moins fréquents mais réels.

2) Une mauvaise configuration VLAN peut‑elle provoquer « bridge port has no carrier » ?

Pas typiquement. Les erreurs VLAN gardent généralement le lien up mais cassent le trafic. Si ethtool indique Link detected: no, les VLANs ne sont pas le coupable.

3) Proxmox affiche l’avertissement, mais l’hôte a encore de la connectivité. Pourquoi ?

Souvent parce que le bridge a plusieurs ports et qu’un seul est down (ex. un membre de bond débranché), ou il y a une interface inutilisée toujours attachée. Proxmox signale le port down même si un autre chemin fonctionne.

4) Quelle est la preuve la plus rapide que c’est côté switch ?

Déplacez le câble vers un port switch connu‑bon (avec le même profil de config). Si le lien remonte immédiatement, votre port switch d’origine est mal configuré, désactivé ou défectueux.

5) Comment savoir si mon SFP/DAC est incompatible ?

Lisez‑le avec ethtool -m (si supporté) et comparez avec ce qui marche ailleurs. Si le même hôte+port fonctionne avec un autre module mais pas celui‑ci, le module est coupable. Si le module marche sur un autre switch mais pas sur celui‑ci, vous avez rencontré une politique de compatibilité vendor.

6) Est‑il sûr de redémarrer le bridge sur un nœud Proxmox ?

Seulement si vous avez un accès hors bande et comprenez quel trafic vous allez couper. Faire remonter vmbr0 coupe la connectivité de l’hôte et des VM qui l’utilisent. Utilisez‑le comme étape de diagnostic contrôlée, pas comme réflexe.

7) Mon bond est en mode LACP ; « no carrier » peut‑il encore arriver ?

Oui. LACP est L2, mais carrier est L1. Si les deux liens physiques sont down (ou les optiques non reconnues), le bond tombe. Si un lien est down, le bond peut rester up mais avec capacité réduite et comportement de trafic différent selon le hashing.

8) Après remplacement d’un switch, seuls certains hôtes Proxmox perdent le carrier. Pourquoi pas tous ?

Les NIC et optiques distincts se comportent différemment. Le nouveau switch peut être plus strict sur le codage des transceivers, avoir des réglages d’auto‑négociation différents, ou des valeurs EEE par défaut autres. Le matériel hétérogène transforme un « swap simple » en « labo surprise ».

9) Une NIC peut‑elle être « up » dans ip link mais quand même sans carrier ?

Oui. UP signifie que l’interface est administrativement activée. Carrier est le signal de la couche inférieure indiqué par LOWER_UP. Vous pouvez avoir UP sans LOWER_UP.

10) Et si le switch montre le lien up mais Linux dit no carrier ?

C’est peu courant mais possible avec des transceivers défectueux, une négociation bizarre, ou une configuration de port en mirroring/monitoring qui induit en erreur les LEDs. Faites confiance à ethtool et aux logs, puis validez en échangeant optiques/ports pour trancher.

Conclusion : étapes suivantes pour éviter les répétitions

« Bridge port has no carrier » est un message brutal avec un sous‑texte utile : arrêtez de déboguer les couches supérieures et commencez par l’underlay. Si la NIC ne voit pas le lien, votre bridge est innocent et vos VM sont des dommages collatéraux.

Faites ceci ensuite, dans l’ordre :

1. Exécutez ip -br link et ethtool pour confirmer le vrai no‑carrier.
2. Remplacez l’élément physique (câble/DAC/optique). Puis essayez un autre port switch.
3. Si ça clignote, fouillez journalctl -k pour la timeline et considérez EEE/gestion d’énergie/interaction pilote.
4. Une fois le carrier restauré, validez L2/L3 (état du bond, taggage VLAN, ping de la passerelle) puis seulement ensuite creusez les problèmes au niveau VM.
5. Enfin, rendez‑le ennuyeux : étiquetez les ports, standardisez les optiques, et capturez les baselines before/after dans les tickets de changement.

La victoire n’est pas seulement de réparer la panne d’aujourd’hui. C’est de faire en sorte que le prochain « no carrier » prenne cinq minutes et un changement de câble, pas une danse interprétative de minuit avec les paramètres de bridge.