Pannes causées par un mauvais câble : comment un seul fil paralyse un datacenter

Ce que « mauvais câble » signifie vraiment

« Mauvais câble » est rarement une seule chose. C’est une famille de décalages entre ce que le port attend et ce que le fil est réellement. Parfois le lien ne monte pas. C’est le jour facile. Les jours difficiles sont quand le lien monte, négocie quelque chose de « suffisamment proche », puis tombe en charge, à la chaleur ou avec le temps.

Principales catégories de pannes dues à un mauvais câble

• Mauvais connecteur physique : LC vs SC sur la fibre ; MPO mal épinglé ; RJ45 mais mauvais câblage (T568A vs T568B n’est généralement pas fatal, mais des panneaux mixtes peuvent l’être).
• Mauvaise compatibilité de support : brancher un DAC cuivre sur des ports qui attendent de l’optique (ou l’inverse). Ou utiliser de l’AOC alors qu’un émetteur+fibre était supposé.
• Mauvais caractéristiques électriques : mauvaise section, mauvaise catégorie (Cat5 vs Cat6A), blindage inadapté, longueur incorrecte pour la vitesse, incompatibilité de classe PoE.
• Mauvais budget optique : mauvais type de fibre (OM3 vs OS2), mauvais transceiver (SR vs LR), trop de liaisons/pérdition, connecteurs sales, ou rayon de courbure violé qui « fonctionne à moitié ».
• Mauvaise polarité / brochage : Tx/Rx croisés, méthode de polarité MPO inversée, mauvaise orientation de breakout, câble rollover utilisé là où un câble droit est requis.
• Standards et particularités fournisseurs : transceivers codés par le fournisseur, EEPROM des DAC, listes de transceivers « supportés », et cas limites d’auto-négociation.
• Erreur topologique déguisée en problème de câble : patcher deux ports de switch au mauvais endroit, créer une boucle ; croiser des fabrics de stockage ; déplacer un uplink vers un port d’accès.
• Erreurs de câblage électrique : mauvais type C13/C19, mauvaise phase/ligne du PDU, intensité nominale incorrecte, ou une rallonge qui transforme une armoire en radiateur.

Deux principes à retenir :

1. Un voyant de lien n’est pas une preuve de correction. Il signifie seulement qu’un sous-ensemble de la couche physique pense que tout va bien.
2. « Ça marchait la dernière fois » n’est pas une spécification. La qualité et la compatibilité des câbles ne sont pas transitives entre fournisseurs, versions de firmware et températures ambiantes.

Faits intéressants et un peu d’histoire

Six à dix petites vérités qui expliquent pourquoi le câblage humilie encore les personnes brillantes :

1. L’Ethernet précoce utilisait des « vampire taps » sur le câble coaxial épais. Un mauvais tap pouvait mettre hors service tout le segment car c’était littéralement un bus partagé.
2. Le câble crossover était normal pour connecter des appareils similaires (switch-to-switch, host-to-host). Auto-MDI/MDIX a réduit cette douleur, mais pas pour toutes les vitesses et PHY.
3. 10GBase-T avait la réputation de chauffer dans les premières implémentations. Le choix du câblage et du PHY impactait la consommation, puis la fiabilité dans des designs ToR denses.
4. La polarité de la fibre est une tragédie récurrente : la fibre duplex semble simple jusqu’à l’arrivée des panneaux, cassettes et trunks MPO. « A-to-B » et « Méthode B » ne sont pas des histoires du soir.
5. Les transceivers codés par les fournisseurs sont un modèle commercial, pas une loi de la nature. Beaucoup d’optiques sont physiquement correctes mais bloquées par des contrôles firmware. Les équipes Ops en subissent les conséquences.
6. InfiniBand et Ethernet partagent des connecteurs sur certaines générations (QSFP), ce qui a conduit à des incidents réels « ça rentre, donc ça doit marcher ».
7. Le multipathing stockage existe parce que les câbles tombent en panne. L’architecture suppose que vous perdrez un chemin—souvent à cause d’un humain avec une échelle.
8. Les câbles patch ont des classes de performance. Un « Cat6 » ramassé dans un tiroir peut ne pas satisfaire les exigences Cat6 d’un canal, surtout lorsqu’il est bundle et chaud.
9. Petit rayon de courbure, grosses conséquences : les courbures serrées sur la fibre peuvent introduire des pertes par macrobending. Parfois c’est intermittent quand la température change la géométrie.

Une citation qui devrait être scotchée sur chaque porte d’armoire (idée paraphrasée) :

John Gall (idée paraphrasée) : Les systèmes complexes qui fonctionnent tendent à évoluer à partir de systèmes plus simples qui fonctionnaient.

Appliqué au câblage : si vous n’arrivez pas à garder correct un modèle de patching simple, vous n’êtes pas prêt pour un modèle ingénieux.

Comment un fil paralyse un datacenter : modes de défaillance réels

1) Le spécial « lien up, trafic down »

Le port affiche UP. LACP dit que vous êtes dans un bundle. Mais le trafic chute, les retransmissions explosent, la latence monte, et le graphe applicatif ressemble à une lame de scie.

Causes classiques :

• Mauvaise catégorie cuivre ou mauvaise terminaison entraînant de nombreuses erreurs CRC/FCS en charge.
• Optiques proches de la limite de budget : ça marche la nuit, ça échoue à midi quand la salle se réchauffe et que les flux d’air changent.
• DAC/AOC en compatibilité limite : EEPROM qui rapporte des paramètres acceptables, mais l’intégrité du signal n’est pas stable à la vitesse négociée.
• Mauvaise auto-négociation : un côté forcé speed/duplex, l’autre auto-négocie ; certaines plateformes « montent » le lien mais fonctionnent mal.

2) Polarité et brochage : le tueur silencieux

La fibre duplex a un sens d’émission et de réception. Inversez-les et rien ne marche — sauf si le panneau ou la cassette « réarrange » à nouveau, auquel cas ça marche jusqu’à ce que quelqu’un rebranche un côté.

Les câbles breakout ajoutent une couche : un QSFP-to-4xSFP est directionnel. Utilisez le mauvais bout au mauvais équipement, et vous aurez un comportement partiel étrange : certaines lanes up, d’autres down, et beaucoup de confusion confiante.

Blague #1 (courte, pertinente) : Une mauvaise polarité fibre, c’est comme un panneau sens unique illisible — tout le monde continue de conduire et personne n’arrive.

3) Boucles : quand le mauvais patch devient un amplificateur de broadcasts

Si vous voulez voir la peur, créez une boucle de niveau 2 dans un réseau qui ne l’attendait pas. Les symptômes sont spectaculaires : CPU des switches qui explose, tables MAC qui battent des ailes, tempêtes de broadcasts, et interfaces de management injoignables quand vous en avez besoin.

Oui, STP existe. Non, il ne vous sauvera pas s’il est désactivé, mal configuré ou trop lent par rapport au rythme auquel votre erreur fait fondre le planeur de contrôle. Et si la boucle touche votre réseau OOB, votre voie de secours est aussi en feu.

4) Cross-connect du fabric de stockage : le multipath devient multi-douleur

Dans les SAN et autres fabrics de stockage, « mauvais câble » signifie souvent « mauvais fabric ». Deux fabrics indépendants existent pour qu’un puisse tomber sans impact. Croisez-les et vous n’obtenez pas de redondance — vous obtenez une défaillance corrélée, des états de chemins confus, et parfois une panne qui ressemble à un bug du contrôleur de stockage.

En iSCSI, un problème similaire survient lorsque VLANs ou subnets sont croisés, ou quand un port hôte est branché sur le mauvais VLAN. Multipathd continue ses tentatives. Vos E/S deviennent une loterie de latence.

5) Câblage électrique : la panne qui sent le plastique

Les équipes réseau et stockage traitent parfois l’alimentation comme « problème Facilities » jusqu’à ce qu’un mauvais cordon apparaisse. Un cordon C13 dans un monde C19 ne rentre pas ; c’est bien. Les dangereux sont ceux qui rentrent mais sont sous-dimensionnés : cordons de section fine, longueur inadaptée (enroulés derrière des racks), ou mauvais équilibrage de phases PDU.

Les erreurs d’alimentation ne déclenchent pas toujours les disjoncteurs immédiatement. Elles peuvent créer des brownouts qui réinitialisent les appareils, corrompent des caches, ou provoquent des flaps de lien qui ressemblent à des problèmes réseau. L’alimentation est la dépendance partagée originelle. Elle se fiche de votre diagramme de redondance.

6) Plan de gestion : à un câble de rendre les ops aveugles

La gestion out-of-band est censée être le canot de sauvetage. Branchez-la mal une fois — déplacez un uplink de management vers un port d’accès dans le mauvais VLAN, ou patcher des iDRACs dans le réseau de production par accident — et vous comprendrez à quel point vous dépendez d’IPMI, BMCs, serveurs de console et power cycling.

Quand l’OOB tombe, le rayon d’impact s’élargit parce que votre capacité de diagnostic rétrécit.

7) « Optiques supportées » et le veto du firmware

Une panne étonnamment courante : le câble est physiquement correct, mais le transceiver est rejeté après un reboot ou une mise à jour de firmware. Les ports restent sombres. L’astre de nuit découvre que « ça marchait hier » inclut « avant que le switch ne redémarre. »

Ce n’est pas un problème de câble au sens physique, mais c’en est un au sens opérationnel. La dépendance est « bon numéro de pièce », pas « bonne longueur d’onde ».

Mode d’emploi pour diagnostic rapide (premier/deuxième/troisième)

Voici le playbook à exécuter lorsque les graphes deviennent rouges et que quelqu’un dit : « Ça a commencé après un petit changement de câblage. » Vous chassez le goulot rapidement, pas en prouvant un théorème.

Premier : établir le rayon d’impact en trois questions

1. Est-ce un hôte, un rack, un fabric ou un service ? Si c’est un rack, suspectez l’alimentation, les uplinks ToR, ou un panneau de brassage partagé.
2. Est-ce le plan de contrôle, le plan de données, ou les deux ? Si les switches sont joignables mais le trafic mort, suspectez un mauvais VLAN/trunk, LACP, ou erreurs optiques/PHY. Si les switches sont injoignables aussi, suspectez des boucles, l’alimentation, ou des erreurs OOB.
3. Quelque chose a-t-il redémarré ? Un redémarrage transforme « transceiver tiers toléré » en « transceiver tiers rejeté ».

Deuxième : vérifier la vérité physique + liaison, pas les impressions

1. Recherchez les flaps de lien, les erreurs CRC/FCS, et les décalages speed/duplex.
2. Confirmez le type de transceiver, les niveaux DOM, et l’état des lanes pour les breakouts QSFP.
3. Vérifiez l’état du partenaire LACP et du bundle. Un mauvais câble peut atterrir sur le mauvais port de switch et rester allumé.

Troisième : prouver la topologie et le cheminement (réseau + stockage)

1. Confirmez les voisins LLDP pour les ports suspects. S’il indique que vous êtes connecté au mauvais appareil, croyez-le.
2. Vérifiez l’appartenance VLAN/trunk et le mode de port aux deux extrémités. Un mauvais câble signifie souvent « mauvais port ».
3. Sur le stockage, vérifiez l’état multipath et le groupement des chemins. Si tous les chemins passent par un seul fabric, votre « redondance » est fictive.

Si vous ne retenez qu’une chose : une panne due à un mauvais câble se diagnostique le plus vite en combinant compteurs d’interface + découverte des voisins + vérifications de redondance des chemins.

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

Ce sont des tâches réelles à exécuter pendant un incident ou pour une validation de câblage. Chaque item inclut : la commande, une sortie d’exemple, ce que cela signifie, et la décision à prendre.

Task 1: See if the link is actually flapping

cr0x@server:~$ sudo journalctl -k --since "30 min ago" | egrep -i "link is|NIC Link|renamed|bond|mlx|ixgbe" | tail -n 20
Jan 22 12:11:03 server kernel: ixgbe 0000:3b:00.0 eth2: NIC Link is Up 10 Gbps, Flow Control: RX/TX
Jan 22 12:14:19 server kernel: ixgbe 0000:3b:00.0 eth2: NIC Link is Down
Jan 22 12:14:23 server kernel: ixgbe 0000:3b:00.0 eth2: NIC Link is Up 10 Gbps, Flow Control: RX/TX

Signification de la sortie : L’interface rebondit. C’est souvent physique (câble, optique, port), parfois lié à l’alimentation ou à un mauvais câblage LACP.

Décision : Traitez comme physique jusqu’à preuve du contraire. Passez aux compteurs et diagnostics transceiver ; si les flaps correspondent à une fenêtre de maintenance, suspectez un patch récent.

Task 2: Check interface counters for CRC/FCS errors

cr0x@server:~$ ip -s link show dev eth2
3: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 3c:fd:fe:12:34:56 brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast
      987654321 1234567  0      12       0       0
    TX:  bytes packets errors dropped carrier collsns
      876543210 1122334  0      0       0       0

Signification de la sortie : Des drops sans erreurs peuvent indiquer de la congestion, un débordement de ring, ou des problèmes en amont. Les erreurs CRC seraient plus nettement physiques, mais les drops restent importants.

Décision : Si les drops augmentent avec la charge, vérifiez les stats du driver NIC et les compteurs du switch ; considérez câble défectueux, mauvaise catégorie, ou mismatch duplex/autoneg.

Task 3: Get detailed NIC stats (ethtool)

cr0x@server:~$ sudo ethtool -S eth2 | egrep -i "crc|fcs|symbol|align|drops|miss|errors" | head -n 20
     rx_crc_errors: 1842
     rx_length_errors: 0
     rx_errors: 1842
     tx_errors: 0
     rx_dropped: 12

Signification de la sortie : Les erreurs CRC sont presque toujours couche 1/2 : câblage, optiques, assise du transceiver, EMI, ou port défectueux.

Décision : Cessez les débats. Remplacez d’abord le câble patch (connu bon), puis échangez les optiques, puis déplacez le port. Si c’est du cuivre, validez la catégorie et la longueur ; si c’est de la fibre, nettoyez les connecteurs.

Task 4: Confirm speed/duplex and autonegotiation

cr0x@server:~$ sudo ethtool eth2 | egrep -i "Speed|Duplex|Auto-negotiation|Link detected"
	Speed: 10000Mb/s
	Duplex: Full
	Auto-negotiation: on
	Link detected: yes

Signification de la sortie : La NIC pense être en 10G full duplex avec autoneg activé. Si le côté switch est forcé, vous pouvez toujours obtenir « link detected » et une mauvaise journée.

Décision : Vérifiez que la configuration du switch correspond. Si vous ne pouvez pas, forcez temporairement les deux côtés de manière cohérente pendant la mitigation (puis annulez et documentez).

Task 5: Check transceiver and DOM (optical power)

cr0x@server:~$ sudo ethtool -m eth2 | egrep -i "Identifier|Connector|Vendor|Part|Type|Wavelength|RX Power|TX Power" | head -n 25
Identifier                                : 0x03 (SFP)
Connector                                 : 0x07 (LC)
Vendor name                               : FINISAR CORP.
Vendor PN                                 : FTLX8571D3BCL
Transceiver type                          : 10G Ethernet: 10G Base-SR
Laser wavelength                          : 850.00 nm
TX Power                                  : -2.1 dBm
RX Power                                  : -10.9 dBm

Signification de la sortie : Des optiques SR à 850nm impliquent une fibre multimode (OM3/OM4). Une RX proche de la limite (très faible) suggère connecteurs sales, mauvais type de fibre, perte excessive, ou courbure.

Décision : Si RX est faible, nettoyez les deux extrémités et inspectez le routage pour courbures serrées. Confirmez que le patch est OM3/OM4 et non OS2 singlemode avec adaptateurs aléatoires.

Task 6: Verify LLDP neighbor (are you plugged into what you think you’re plugged into?)

cr0x@server:~$ sudo lldpctl eth2
-------------------------------------------------------------------------------
LLDP neighbors:
-------------------------------------------------------------------------------
Interface:    eth2, via: LLDP, RID: 1, Time: 0 day, 00:00:21
  Chassis:
    ChassisID:    mac 7c:fe:90:aa:bb:cc
    SysName:      tor-a17
  Port:
    PortID:       ifname Ethernet1/17
    PortDescr:    server-rack12-uplink
-------------------------------------------------------------------------------

Signification de la sortie : Vous êtes connecté à tor-a17 sur un port spécifique. Si vous attendiez tor-b ou un autre port, le câble est au mauvais endroit.

Décision : Si le voisin est incorrect, arrêtez et tracez/étiquetez physiquement avant de faire des changements de config. Réparez le patch ; ne « corrigez » pas en reconfigurant le mauvais port.

Task 7: Validate bond/LACP state (Linux)

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: up
Active Aggregator Info:
        Aggregator ID: 2
        Number of ports: 2
Slave Interface: eth2
MII Status: up
Actor Churn State: churned
Partner Churn State: churned
Slave Interface: eth3
MII Status: up
Actor Churn State: stable
Partner Churn State: stable

Signification de la sortie : Un esclave est « churned », ce qui signifie que LACP renégocie sans cesse — souvent parce que l’autre extrémité n’est pas configurée de façon cohérente, ou que le câble est patché vers un switch/port-channel incorrect.

Décision : Vérifiez si eth2 et eth3 aboutissent sur la paire MLAG correcte et les membres du port-channel corrects. Un mauvais câble peut diviser un bond sur des switches non pairés et causer des pertes intermittentes.

Task 8: Spot a duplex mismatch or autoneg mismatch via counters

cr0x@server:~$ sudo ethtool -S eth2 | egrep -i "late_collision|excessive_collision|carrier|jabber" | head -n 20
     tx_carrier_errors: 0
     tx_late_collisions: 0
     tx_excessive_collisions: 0

Signification de la sortie : Sur les liens full-duplex modernes vous devriez voir zéro collision. Si vous voyez des collisions sur quelque chose qui « ne devrait pas » en avoir, suspectez une mauvaise négociation de configuration ou un convertisseur média intermédiaire étrange.

Décision : Si des compteurs liés aux collisions augmentent, arrêtez et alignez speed/duplex sur les deux extrémités. Confirmez aussi que vous n’avez pas inséré un appareil intermédiaire incorrect (media converter, ancien switch).

Task 9: Detect a broadcast storm/loop from a host viewpoint

cr0x@server:~$ sudo tcpdump -nni eth2 -c 20 ether multicast
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:20:01.120001 ARP, Request who-has 10.20.0.1 tell 10.20.15.44, length 28
12:20:01.120054 ARP, Request who-has 10.20.0.1 tell 10.20.15.44, length 28
12:20:01.120102 ARP, Request who-has 10.20.0.1 tell 10.20.15.44, length 28
12:20:01.120150 ARP, Request who-has 10.20.0.1 tell 10.20.15.44, length 28

Signification de la sortie : Des broadcasts identiques répétés en succession rapide peuvent indiquer une boucle ou un domaine L2 très instable. Ce n’est pas une preuve, mais une forte odeur.

Décision : Escaladez à l’équipe réseau pour vérifier STP/loop guard et fermer les ports suspects. Entre-temps, isolez l’hôte en débranchant un lien (si bondé) pour réduire le rayon d’impact.

Task 10: Confirm routing and ARP sanity (is this actually a cabling issue?)

cr0x@server:~$ ip route get 10.20.0.1
10.20.0.1 dev eth2 src 10.20.15.44 uid 0
    cache

Signification de la sortie : L’OS croit que la passerelle est directement joignable via eth2. Si cela a changé après un patch, vous pourriez être sur le mauvais VLAN/subnet.

Décision : Si la route pointe vers une interface inattendue, vérifiez le tagging VLAN, le mode du switchport, et si le câble est dans un port configuré pour un réseau différent.

Task 11: Check iSCSI sessions (storage pathing)

cr0x@server:~$ sudo iscsiadm -m session
tcp: [1] 10.30.1.10:3260,1 iqn.2020-01.example:target.a (non-flash)
tcp: [2] 10.30.2.10:3260,1 iqn.2020-01.example:target.b (non-flash)

Signification de la sortie : Deux sessions suggèrent une redondance à travers subnets/fabrics. Si vous n’en voyez qu’une après un changement de câblage, vous avez probablement perdu un chemin.

Décision : Identifiez quelle NIC/VLAN correspond à la session manquante, puis vérifiez le câblage et la config du switch pour ce fabric. N’acceptez pas « c’est OK » avec du stockage à chemin unique.

Task 12: Inspect multipath health (SCSI multipath)

cr0x@server:~$ sudo multipath -ll | head -n 40
mpatha (36001405a6b3f2c9b3e1d2f9b7a8c1234) dm-2 EXAMPLE,Array
size=2.0T features='1 queue_if_no_path' hwhandler='0' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| `- 2:0:0:1 sdb 8:16 active ready running
`-+- policy='service-time 0' prio=10 status=enabled
  `- 3:0:0:1 sdc 8:32 active ready running

Signification de la sortie : Deux chemins existent, l’un préféré. Si un chemin indique failed ou disparaît, vous avez peut-être un câble branché sur le mauvais switch ou le mauvais fabric.

Décision : Si un chemin est down, traitez-le comme un incident même si l’appli semble « OK ». Vous êtes à un mauvais câble d’une panne.

Task 13: Detect NVMe/TCP connectivity issues (if applicable)

cr0x@server:~$ sudo nvme list-subsys
nvme-subsys0 - NQN=nqn.2014-08.org.nvmexpress:uuid:11111111-2222-3333-4444-555555555555
\
 +- nvme0 tcp traddr=10.40.1.20 trsvcid=4420 live
 +- nvme1 tcp traddr=10.40.2.20 trsvcid=4420 live

Signification de la sortie : Deux chemins NVMe/TCP live. Si un disparaît après un patch, vous avez probablement croisé des VLANs ou branché la mauvaise NIC au mauvais ToR.

Décision : Validez la séparation réseau pour les fabrics de stockage ; confirmez LLDP voisin sur les NIC de stockage ; rétablissez le dual-path avant de déclarer résolu.

Task 14: Verify ZFS pool health (symptom of path loss)

cr0x@server:~$ sudo zpool status -x
pool 'tank' is healthy

Signification de la sortie : Aucun défaut de niveau pool évident. Mais un ZFS sain ne signifie pas que vos chemins sous-jacents sont redondants ; cela signifie seulement qu’il n’a pas détecté de défaillance de vdev.

Décision : Si un chemin de stockage est suspect, validez aussi multipath et les liens HBA. Ne confondez pas « pas mort » avec « sûr ».

Task 15: Identify the physical PCI device and driver (helps map to the right cable)

cr0x@server:~$ sudo ethtool -i eth2
driver: ixgbe
version: 5.15.0
firmware-version: 0x800003e5
bus-info: 0000:3b:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no

Signification de la sortie : Vous pouvez mapper bus-info à un port NIC physique en utilisant la documentation du serveur ou un schéma d’étiquetage.

Décision : Si vous avez plusieurs NIC, confirmez que vous dépannez le port qui correspond réellement au câble modifié. Cela évite la classique perte de temps « j’ai réparé la mauvaise interface ».

Task 16: Quick throughput sanity (is the wire the bottleneck?)

cr0x@server:~$ iperf3 -c 10.20.15.10 -P 4 -t 10
Connecting to host 10.20.15.10, port 5201
[  5] local 10.20.15.44 port 54122 connected to 10.20.15.10 port 5201
[SUM]   0.00-10.00  sec  2.10 GBytes  1.80 Gbits/sec  1420 retr

Signification de la sortie : Le débit est bien en dessous d’une attente 10G, avec un grand nombre de retransmissions. Cela pointe directement vers des problèmes physiques ou de congestion/bouclage sévère.

Décision : Si les retransmissions sont élevées, priorisez l’échange câble/optique/port et vérifiez les erreurs CRC. Si les retransmissions sont faibles mais le débit plafonne, enquêtez sur QoS, policing, ou mauvaise négociation de vitesse.

Trois mini-récits d’entreprise (anonymisés, plausibles, techniquement exacts)

Mini-récit 1 : La panne causée par une mauvaise hypothèse

Ils ajoutaient de la capacité à un cluster cloud privé. Nouveaux hyperviseurs, nouveaux top-of-rack, même playbook ancien. Le technicien qui patchait avait une hypothèse raisonnable : « Les deux switches sont une paire ; n’importe quel uplink est un uplink. » Il a connecté un membre du bond sur ToR-A et l’autre sur ToR-C, parce que les ports étaient adjacents et que les étiquettes étaient… aspirational.

Les voyants de lien se sont allumés. LACP s’est majoritairement activé. Puis la perte de paquets a commencé. Pas partout — juste assez pour faire remonter des timeouts stockage. Les migrations de VM se sont bloquées. Les bases ont commencé à signaler du lag de réplication. Les graphes ressemblaient à un bug applicatif intermittent. Plusieurs personnes ont regardé le tableau de stockage parce que le stockage se fait blâmer pour tout, y compris la gravité.

Le vrai problème était topologique, pas de bande passante. La paire MLAG était ToR-A et ToR-B ; ToR-C était une paire différente. Le bond était effectivement divisé entre deux switches non reliés, produisant du churn LACP et de l’occultation de trafic selon les résultats du hash.

Ça a pris plus de temps que nécessaire parce que l’équipe faisait confiance à l’état du lien. Une fois que quelqu’un a lancé LLDP depuis l’hôte et comparé au diagramme de rack, le décalage était évident. La correction fut embarrassante de simplicité : déplacer un câble vers le switch pair correct et voir le système se calmer instantanément.

Leçon : les hypothèses sont des exigences non documentées. Si votre design exige « ces deux ports doivent terminer sur cette paire MLAG », étiquetez-le comme il faut et validez-le par logiciel, pas par mémoire.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une initiative d’économie visait les optiques et le câblage. Le pitch procurement était simple : remplacer « optiques fournisseur coûteuses » par des « DAC tiers équivalents » pour les courtes liaisons. Le test en labo a passé. Le déploiement a commencé.

Ça a bien marché pendant des semaines. Puis une mise à niveau logicielle de switch a touché l’infrastructure. Une poignée de ports ne sont pas revenus. Les appareils ont redémarré, les ventilateurs se sont calmés, et les uplinks sont restés sombres. L’ingénieur on-call a fait le rituel normal — reload, reseat, swap ports — jusqu’à ce que quelqu’un remarque un motif : seuls les ports avec les nouveaux DAC étaient morts.

Le nouveau firmware a durci la validation des transceivers. Pas d’erreur criarde sur la console qui hurle « transceiver non supporté », plutôt un refus poli de monter le lien. Parfois il revenait à une vitesse inférieure ; parfois il restait down. L’« optimisation » s’est transformée en falaise de compatibilité.

Ils ont atténué en remettant les liens critiques sur des optiques connues supportées et en laissant les DAC douteux pour des segments moins critiques leaf-to-lab. La correction long terme fut procédurale : chaque changement de firmware planifié inclut maintenant une vérification de compatibilité des transceivers et un test de staging avec les mêmes numéros de pièce que la production.

Leçon : les optimisations de coût en couche 1 ne sont pas purement financières. Ce sont des décisions de fiabilité. Si vous ne pouvez pas tester la compatibilité à travers les cycles de firmware, vous n’économisez pas — vous empruntez sur le budget incident.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une équipe stockage exploitait des fabrics duals pour le bloc. Chaque hôte avait deux HBA, chacun connecté à un switch de fabric différent, et les switches étaient physiquement séparés. Ennuyeux. Coûteux. Correct.

Pendant une maintenance pressée, un sous-traitant a rebrassé un bundle et a accidentellement déplacé plusieurs liaisons Fabric A sur des ports Fabric B. Dans une configuration moins disciplinée, cela aurait dégénéré en panne multi-hôtes : confusion multipath, thrash de chemins, risques d’engorgements, et une longue nuit de « l’array meurt-il ? »

Mais l’équipe avait deux garde-fous. D’abord, un code couleur strict et un étiquetage de port : Fabric A toujours d’une couleur, Fabric B d’une autre, et les deux extrémités étiquetées device+port. Ensuite, ils exécutaient une vérification automatisée quotidienne validant la symétrie multipath : chaque hôte doit voir des chemins via les deux fabrics, et le nombre de chemins doit correspondre aux baselines attendues.

L’alerte s’est déclenchée en quelques minutes. La remédiation a été ciblée : identifier quels hôtes avaient perdu les chemins Fabric A, vérifier LLDP/FC neighbor, et rebrancher seulement les liaisons affectées. L’incident n’est jamais devenu visible pour les clients parce que la redondance est restée réelle, pas décorative.

Leçon : les pratiques « ennuyeuses » — étiquettes, couleurs, audits, séparation stricte — sont ce qui empêche votre architecture ingénieuse de s’effondrer sous les mains humaines.

Erreurs courantes : symptôme → cause racine → correction

1) Symptom: Link is up, but CRC errors climb

Cause racine : Mauvaise catégorie cuivre, câble patch endommagé, mauvaise terminaison, EMI, ou optiques marginaux.

Correction : Remplacez par un câble connu bon ; évitez les câbles « trouvés dans le tiroir ». Si fibre, nettoyez et inspectez les connecteurs ; vérifiez les niveaux DOM. Si cuivre, imposez Cat6A pour 10GBase-T et respectez les longueurs max.

2) Symptom: Bonded interface shows churn, intermittent packet loss

Cause racine : Un membre du bond patché sur le mauvais switch ou mauvais port-channel ; mismatch MLAG.

Correction : Utilisez LLDP pour confirmer les voisins ; vérifiez que les deux switchports appartiennent au même LAG/MLAG pair ; rebranchez le câble, ne reconfigurez pas autour de l’erreur.

3) Symptom: After reboot/upgrade, ports stay down with third-party optics

Cause racine : Firmware impose une allowlist de transceivers ; des pièces tolérées avant sont maintenant bloquées.

Correction : Tenez un inventaire des numéros de pièce et de compatibilité ; testez le firmware en staging avec les mêmes optiques ; gardez des pièces de secours connues pour rollback d’urgence.

4) Symptom: Some lanes up, others down on a QSFP breakout

Cause racine : Mauvais type de breakout ou orientation (câble directionnel), ou mode de breakout mal configuré.

Correction : Confirmez que le hardware supporte le breakout ; vérifiez la config switch correspondante (breakout activé) ; assurez-vous que le bon bout est connecté au QSFP.

5) Symptom: Storage latency spikes, multipath shows “enabled” but not “active”

Cause racine : Un chemin fabric perdu à cause d’un mauvais patch, VLAN erroné, ou switch incorrect ; trafic forcé sur un seul chemin ou groupe de chemins sous-optimal.

Correction : Restaurez le dual-path. Validez iSCSI/NVMe/TCP et les VLANs. Confirmez que chaque HBA/NIC termine sur le fabric prévu.

6) Symptom: Whole network feels slow; management plane unreachable

Cause racine : Boucle L2 créée par un mauvais patch, ou uplink OOB patché dans le VLAN de production (ou l’inverse).

Correction : Fermez rapidement les ports suspects ; reposez-vous sur loop guard/BPDU guard ; tracez physiquement les nouveaux patches ; restaurez l’isolation OOB et vérifiez avec LLDP voisins.

7) Symptom: Everything in one rack rebooted “randomly”

Cause racine : Erreur de câblage d’alimentation : mauvaise alimentation PDU, circuit surchargé, cordon sous-dimensionné chauffant, ou mauvais équilibrage de phase provoquant disjonctions/brownouts.

Correction : Vérifiez la consommation du rack ; inspectez les cordons pour leur cote et la chaleur ; assurez-vous que les PSUs redondants atterrissent sur des PDU/alimentations indépendants ; impliquez Facilities tôt.

8) Symptom: Link negotiates at 1G instead of 10G

Cause racine : Mauvaise catégorie de câble, course trop longue, paires endommagées, ou port mal configuré.

Correction : Remplacez par du Cat6A certifié ; vérifiez la configuration du port ; évitez les coupleurs inline et les panneaux cheap pour le cuivre haut-débit.

Blague #2 (courte, pertinente) : La différence entre un « petit changement de câblage » et une panne est généralement une personne qui dit « ça devrait aller » tout haut.

Listes de contrôle / plan pas à pas

Pendant un incident : triage câblage en 12 minutes

1. Geler les changements. Arrêtez tout patch supplémentaire tant que vous n’avez pas d’hypothèse. Les humains aiment « aider » une panne à durer plus longtemps.
2. Identifier les ports dernièrement touchés. Sortez le ticket de changement, les logs de chat, et les logs d’accès physique si vous en disposez.
3. Lancer LLDP sur les hôtes affectés. Vérifiez que le voisin correspond au switch et port prévus.
4. Vérifier les flaps de lien et erreurs. Consultez les logs kernel et ethtool -S pour CRC/FCS.
5. Valider l’état LACP/bond. Confirmez que tous les membres sont dans l’agrégateur correct et stables.
6. Vérifier la parité de configuration des switchports (si possible). Les deux extrémités doivent être d’accord sur trunk/access, VLANs, vitesse, et appartenance LAG.
7. Pour la fibre : vérifier les niveaux DOM. Un RX faible suggère connecteurs sales, mauvais type de fibre, ou courbures.
8. Pour le cuivre : confirmer catégorie et longueur. « Cat6-ish » n’est pas une spécification.
9. Remplacer une chose à la fois. Câble patch connu bon d’abord, puis optiques, puis port. Évitez « tout échanger » pour ne pas perdre la causalité.
10. Confirmer que la redondance est restaurée. Multipath a les deux fabrics ; bonds ont tous les membres ; uplinks équilibrés.
11. Enregistrer le mapping physique final. Mettez à jour la source de vérité tant que c’est frais.
12. Rédiger l’action préventive. Étiquettes, contrôles automatisés, ou une règle de blocage de changement — quelque chose qui rend la répétition plus difficile.

Avant un travail de câblage planifié : faites-le pour dormir tranquille

1. Exiger une « carte de ports » dans le changement. Appareil, port, destination, type de câble, longueur, et usage. Pas de carte = pas de changement.
2. Utiliser un étiquetage cohérent aux deux extrémités. Les étiquettes doivent résister à la chaleur et au nettoyage. Le ruban manuscrit est un aveu.
3. Code couleur par fonction. Exemple : fabric stockage A une couleur, fabric B une autre ; OOB distinct ; uplinks distincts. Gardez la consistance sur le site.
4. Utiliser le bon type de câble pour le port et la vitesse. DAC/AOC vs optique+fibre est un choix délibéré. Ne mélangez pas par « on avait ça. »
5. Pré-stocker des pièces de rechange. Patches et optiques testés et connus bons à portée de main. La panne aime les longues marches vers le magasin de pièces.
6. Valider les voisins après le patch. Les checks LLDP/CDP sont rapides et évitent des heures de confusion.
7. Valider les compteurs après trafic. Un câble peut passer un test de lien et quand même corrompre des trames.
8. Effectuer un audit de redondance. Confirmez que les deux fabrics/chemins et les deux membres de bond fonctionnent comme attendu.

Garde-fous opérationnels qui empêchent qu’un « mauvais câble » devienne une « grande panne »

• Source de vérité pour le câblage : une cartographie vivante, pas un wiki fossile. Si vous ne pouvez pas lui faire confiance, les gens arrêtent de l’utiliser.
• Détection automatique de dérive : checks nocturnes qui comparent les voisins LLDP et la topologie attendue ; alertes quand un uplink serveur bouge.
• Pièces standardisées : limiter les SKU de transceivers/câbles. La variété est la porte d’entrée des bugs de compatibilité.
• Fenêtres de changement avec étapes de validation : exiger une preuve (LLDP, compteurs, multipath) avant de clôturer.
• Formation incluant la couche physique : votre meilleur ingénieur réseau reste mortel face à une cassette MPO à 2 h du matin.

FAQ

1) Si le voyant de lien est allumé, comment le câble peut-il quand même être mauvais ?

Parce que « lien up » signifie seulement qu’un certain signal électrique/optique est détecté. Vous pouvez avoir un taux d’erreurs bit élevé, le mauvais VLAN/port, un mauvais câblage LACP, ou des optiques marginaux.

2) Quelle est la façon la plus rapide de prouver qu’un câble est branché sur le mauvais appareil ?

Les données voisins LLDP/CDP. Depuis un host Linux, lldpctl vous donne le nom du switch et le port. Si ça ne correspond pas au patch prévu, le câble est mauvais ou la documentation l’est.

3) Les câbles DAC sont-ils interchangeables entre fournisseurs ?

Parfois. Physiquement, beaucoup le sont ; opérationnellement, la compatibilité firmware et l’intégrité du signal varient. Traitez les DAC comme des optiques : les numéros de pièces comptent, et les upgrades peuvent changer le comportement.

4) Pourquoi les liaisons fibre échouent-elles de façon intermittente ?

Connecteurs sales, budget optique marginal, dérive liée à la température, ou contrainte de courbure qui évolue avec le flux d’air et le mouvement des câbles. « Intermittent » est souvent « à la limite de la tolérance ».

5) Comment distinguer une boucle d’un simple trafic intense ?

Les boucles montrent souvent des flaps MAC rapides, des pics de broadcast/multicast, et des douleurs côté plan de contrôle (le management devient non réactif). Depuis un hôte, vous verrez fréquemment des ARP/ND répétés et une perte de paquets qui ne corrèle pas avec la charge applicative.

6) Un mauvais câble peut-il causer une corruption stockage ?

Il peut provoquer des timeouts, perte de chemin et pics de latence. La corruption est moins fréquente avec les checksums end-to-end et le journaling modernes, mais ne tentez pas le diable. Stockage sur chemin unique plus liens instables est la porte ouverte au pire.

7) Est-il préférable d’utiliser optique + fibre plutôt que DAC/AOC ?

Pas universellement. Les DAC sont excellents pour les très courtes liaisons en armoire et peuvent être plus simples. Optique+fibre est meilleur pour la distance et le câblage structuré. Choisissez selon la distance, la densité de ports, le budget thermique, et votre capacité à standardiser et inventorier des pièces.

8) Que devrions-nous standardiser en premier pour réduire les incidents de « mauvais câble » ?

Standardisez l’étiquetage et le code couleur, puis standardisez les SKU câble/transceiver, puis automatisez les audits voisins et de redondance. Les gens peuvent contourner une doc imparfaite ; ils ne peuvent pas contourner le chaos.

9) Pourquoi les projets d’« optimisation » déclenchent-ils souvent des incidents de câblage ?

Parce qu’ils modifient beaucoup de petites dépendances physiques à la fois : numéros de pièce, tolérances, compatibilité firmware, et nombre d’adaptateurs dans la chaîne. Vous réduisez le coût, augmentez la variance, puis êtes surpris quand la variance mord.

10) Quel est le seul indicateur qui hurle « problème couche physique » ?

Les erreurs CRC/FCS sur les ports de switch ou les compteurs NIC. Un petit nombre peut arriver ; une tendance à la hausse sous charge est un signal réel. Traitez-le comme coupable jusqu’à preuve du contraire.

Conclusion : étapes suivantes pour éviter la répétition

Les pannes causées par un mauvais câble ne sont pas des « erreurs stupides ». Ce sont des résultats prévisibles quand le travail de couche physique est traité comme informel, non vérifié et mal documenté. La correction est aussi prévisible : faites du câblage une partie de premier plan des opérations.

Faites ceci ensuite :

1. Adoptez l’habitude de valider les voisins : après tout patch, vérifiez LLDP/CDP et la symétrie bond/multipath avant de quitter l’allée.
2. Standardisez et inventorie : limitez les SKU câbles et transceivers et gardez des pièces connues bonnes près du travail.
3. Automatisez la détection de dérive : alertez quand un uplink serveur atterrit sur le mauvais switchport ou quand le stockage perd un chemin fabric.
4. Inscrivez les cartes de ports dans les changements : « connecter A à B avec le type X » n’est pas de la bureaucratie ; c’est comment conserver la causalité.
5. Rendez la redondance réelle : des chemins doubles non validés sont juste des câbles supplémentaires pouvant être mal patchés.

Si vous exploitez des systèmes de production assez longtemps, vous apprendrez que la fiabilité est surtout un combat contre des détails minuscules, physiques et ennuyeux. Le fil gagne quand vous le laissez anonyme. Donnez-lui un nom, une étiquette et une étape de validation, et il devient une dépendance gérable comme les autres.