Ethernet bloqué à 100 Mbps : le mythe du câble vs la vraie solution

Ce que signifie réellement 100 Mbps (et ce que ça ne signifie pas)

Un lien à 100 Mbps sur une carte réseau et un switch compatibles gigabit est rarement un « problème de performance » stricto sensu. C’est un résultat de négociation. Les deux PHY (transceivers de couche physique) ont essayé de s’accorder sur le plus haut dénominateur commun et se sont retrouvés sur 100BASE-TX. Cela arrive généralement pour l’une des quatre raisons suivantes :

1. Seules deux paires fonctionnent effectivement (100BASE-TX utilise deux paires ; 1000BASE-T a besoin des quatre).
2. L’autonégociation est cassée ou discordante (vitesse/duplex forcés d’un côté ; appareil intermédiaire étrange).
3. La configuration du port du commutateur est volontairement limitée (politique de sécurité, accommodation d’un équipement ancien, idées reçues sur les économies d’énergie).
4. Le PHY est mécontent (erreurs, bizarreries EEE, problèmes de pilote/firmware, SNR marginal, ou port endommagé).

« Remplacer le câble » rassure parce que c’est mécanique et sans responsabilité. Mais si vous changez un cordon dans un chemin qui inclut un panneau de brassage, une prise murale, une course encastrée, une station d’accueil et un port de switch à moitié mort, vous faites de la science par intuition.

Blague #1 : Remplacer des câbles au hasard, c’est comme redémarrer des imprimantes : parfois ça marche, et personne ne sait pourquoi, y compris l’imprimante.

Autre point : ne confondez pas vitesse du lien et débit effectif. Vous pouvez avoir un lien 1 Gbps et obtenir 80 Mbps à cause de la congestion, du CPU, d’un mauvais MTU, du stockage, du fenêtrage TCP ou d’un pare-feu qui analyse les paquets avec l’enthousiasme d’un paresseux. Cet article traite du cas inverse : le lien lui‑même est bloqué à 100 Mbps.

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

Premier : confirmer ce qui négocie et où

• Sur l’hôte : confirmer la vitesse/duplex négociés réellement et si l’autonégociation est activée.
• Sur le commutateur : confirmer ce que le switch pense du port et si le port est forcé.
• Sur le chemin : identifier tout ce qui se trouve entre la NIC et le switch (station d’accueil, coupleur en ligne, prise murale, panneau de brassage).

Deuxième : isoler rapidement le chemin physique

• Déplacez l’hôte jusqu’au switch avec un court câble connu bon. S’il négocie en 1G là‑bas, le problème se situe dans le câblage structuré ou le matériel intermédiaire.
• Changez le port du commutateur. Si le problème suit le port, c’est de la config ou du matériel du port. Si le problème suit le câble/chemin, vous avez appris quelque chose.

Troisième : rechercher les tueurs de négociation

• Mauvaise correspondance vitesse/duplex forcée (classique : switch forcé à 100/full, hôte en auto).
• Interactions EEE (Energy Efficient Ethernet) sur des switches bon marché, docks et certaines NIC.
• Régressions de pilote/firmware, en particulier sur les NIC USB et les stations d’accueil.

Si vous effectuez ces trois passes, vous pouvez généralement arrêter de deviner en 10–15 minutes et commencer à réparer.

Le mythe du câble : pourquoi il est populaire, pourquoi il est incomplet

Les câbles tombent en panne. Mais « le câble » n’est rarement juste un câble. Dans les bureaux et les data centers, le « câble » est une chaîne : cordon de brassage → prise keystone → course murale → panneau de brassage → cordon de brassage → switch. À n’importe quel point de cette chaîne, une paire peut être perdue, un diaphonie introduite, ou une terminaison mal faite au point que le gigabit échoue mais que le 100 Mbps continue de « boiter ».

Voici la vérité inconfortable : 100BASE-TX est indulgent. Il peut fonctionner sur deux paires utilisables avec un bruit tolérable. 1000BASE-T ne l’est pas. Il a besoin des quatre paires et utilise un codage plus sophistiqué (PAM-5 avec annulation d’écho). Cela signifie qu’une seule terminaison marginale peut être invisible à 100 et catastrophique à 1000.

Donc oui, vous pourriez « régler » le problème en remplaçant un cordon de brassage — parce que vous avez involontairement retiré le segment défaillant. Mais si le vrai problème est un poinçonnage mal fait dans une prise murale, vous avez juste joué aux dés et appelé ça de l’ingénierie.

Les vraies causes : autonégociation, paires, erreurs PHY et bizarreries du switch

1) Une paire (ou deux) mauvaise(s) dans le chemin cuivre

Le gigabit a besoin des quatre paires : (1,2), (3,6), (4,5), (7,8). Le 100 Mbps utilise seulement (1,2) et (3,6). Si la paire (4,5) ou (7,8) est ouverte, court‑circuitée, inversée ou à peine en contact, l’autonégociation retombe souvent à 100.

Causes courantes :

• Prise keystone poinçonnée avec mauvais contact sur une paire.
• Terminaison du panneau de brassage faite par quelqu’un pressé.
• Ancien câble avec coudes, agrafes ou rayons de courbure trop serrés (oui, des gens agrafent Ethernet ; oui, c’est aussi mauvais que cela en a l’air).
• Coupleurs en ligne et prolongateurs bon marché qui ne sont pas réellement certifiés Cat5e/6.

2) Discordance d’autonégociation et réglages forcés

L’autonégociation n’est pas optionnelle pour le gigabit en pratique. La norme 1000BASE-T attend l’autonégociation pour établir le timing master/slave et les capacités. Si un côté est forcé et l’autre en auto, vous pouvez vous retrouver avec 100 Mbps, du semi‑duplex, ou un lien qui flappera.

Mode de défaillance classique en entreprise : quelqu’un a forcé 100/full sur le switch « pour la stabilité » il y a des années, puis a oublié. Le port devient un piège pour tout endpoint moderne qui attend le gigabit.

3) Mismatch de duplex (encore présent, mais plus sournois)

Le mismatch de duplex est moins fréquent maintenant parce que auto/auto fonctionne généralement. Mais il survit avec des configs forcées, du matériel ancien ou des appareils intermédiaires. Les symptômes peuvent ressembler à « le lien est up, mais tout est cassé » : nombreux late collisions, mauvaises performances TCP, retransmissions aléatoires.

4) Energy Efficient Ethernet (EEE) et fonctionnalités « économes »

EEE (802.3az) peut très bien fonctionner. Il peut aussi être une nuisance de négociation sur certaines puces et surtout sur des docks/NIC USB. Si vous voyez des flaps de lien ou une négociation obstinée à 100 Mbps sur un chemin par ailleurs bon, tester en désactivant EEE vaut les 60 secondes nécessaires.

5) Docks, NIC USB et adaptateurs « utiles »

Les adaptateurs Ethernet USB et les stations d’accueil sont des miracles de productivité… jusqu’à ce qu’ils ne le soient plus. Beaucoup ont des PHY marginaux, un firmware étrange et des magnétiques bas de gamme. Ils introduisent aussi plus de connecteurs et donc plus de points de défaillance.

Règle : si un portable via dock est bloqué à 100 Mbps, testez le même câble avec un appareil non docké connu bon, ou contournez totalement le dock. Ne discutez pas. Prouvez.

6) Dégradation matérielle du port du commutateur ou contamination

Les ports de commutateur peuvent s’endommager. Le connecteur RJ‑45 d’un cordon souvent déplacé aussi. Dans des environnements poussiéreux, les ports accumulent des débris invisibles jusqu’à ce que l’on éclaire et qu’on constate que les contacts ressemblent à un petit champ de bataille.

7) Régressions pilote/firmware

Surtout sur des serveurs avec NICs spécifiques, une mise à jour de firmware peut modifier le comportement d’autonégociation ou les paramètres EEE. En entreprise, cela se manifeste souvent après une fenêtre de maintenance où « rien de réseau n’a changé », sauf que tout a changé.

8) L’ennuyeux mais réel : politique et limitation volontaire

Certaines organisations configurent volontairement des ports d’accès à 100 Mbps pour réduire l’impact des broadcasts, décourager les switchs non autorisés, ou accommoder des équipements anciens. Si vous dépannez, considérez toujours que « cassé » peut en réalité être « configuré ».

Tâches pratiques (commandes, sorties, décisions)

Ce ne sont pas des théories. Ce sont les actions à mener un mardi quand les gens attendent et que la foule « remplacez le câble » plane autour.

Task 1: Confirm the negotiated speed/duplex on Linux (ethtool)

cr0x@server:~$ sudo 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
	                        100baseT/Full
	                        10baseT/Full
	Advertised auto-negotiation: Yes
	Speed: 100Mb/s
	Duplex: Full
	Auto-negotiation: on
	Link detected: yes

Ce que cela signifie : La NIC supporte le gigabit mais est actuellement à 100/full. L’autonégociation est activée. Cela oriente le diagnostic loin d’un « 100 forcé sur l’hôte » et vers le câble/chemin, la config du switch, ou l’autre extrémité qui n’annonce que du 100.

Décision : Vérifier l’état du port du switch et les compteurs ensuite. Si le switch rapporte aussi 100, vous avez affaire à un résultat de négociation. Si le switch rapporte 1000 mais que l’hôte montre 100, vous avez un problème côté hôte de pilote/firmware.

Task 2: Show link state quickly (ip)

cr0x@server:~$ ip -br link show enp3s0
enp3s0             UP             3c:ec:ef:12:34:56 <BROADCAST,MULTICAST,UP,LOWER_UP>

Ce que cela signifie : L’interface est administrativement up et a du carrier. Cela ne vous dit pas la vitesse, mais vous indique que vous ne dépannez pas un lien down.

Décision : Si le carrier manque (pas de LOWER_UP), arrêtez et inspectez la connexion physique, un port err‑disable du switch, ou les politiques VLAN avant de toucher aux réglages de vitesse.

Task 3: Check kernel messages for link renegotiation flaps (dmesg)

cr0x@server:~$ sudo dmesg -T | tail -n 12
[Mon Feb  5 10:12:03 2026] e1000e 0000:03:00.0 enp3s0: Link is Up 100 Mbps Full Duplex, Flow Control: Rx/Tx
[Mon Feb  5 10:14:17 2026] e1000e 0000:03:00.0 enp3s0: Link is Down
[Mon Feb  5 10:14:20 2026] e1000e 0000:03:00.0 enp3s0: Link is Up 100 Mbps Full Duplex, Flow Control: Rx/Tx

Ce que cela signifie : Le lien clignote. Cela indique fortement un problème marginal de couche physique (câble/terminaison/port) ou un comportement étrange lié à l’économie d’énergie/EEE.

Décision : Changez de port sur le switch et contournez tout dock/adaptateur. Si cela se stabilise à 1G avec un court câble connu bon, vous avez isolé le câblage structuré ou l’appareil intermédiaire.

Task 4: Look for CRC, frame, and alignment errors (ethtool -S)

cr0x@server:~$ sudo ethtool -S enp3s0 | egrep -i 'crc|align|error|drop' | head
     rx_crc_errors: 184
     rx_frame_errors: 0
     rx_errors: 184
     rx_dropped: 3
     tx_errors: 0

Ce que cela signifie : Les erreurs CRC indiquent des trames corrompues à la couche 2 — souvent un problème de couche physique (paires/câble, EMI, port défectueux) ou un mismatch duplex.

Décision : Si les CRC augmentent régulièrement sous faible charge, traitez‑le d’abord comme un problème physique : câble/chemin/port. Si les CRC montent seulement sous forte charge et que le duplex est discordant, corrigez la configuration duplex/autonégociation.

Task 5: Confirm what the NIC is advertising (ethtool advertise)

cr0x@server:~$ sudo ethtool enp3s0 | egrep -A2 'Advertised link modes|Advertised auto'
	Advertised link modes:  1000baseT/Full
	                        100baseT/Full
	                        10baseT/Full
	Advertised auto-negotiation: Yes

Ce que cela signifie : L’hôte annonce 1000/full. Donc si vous êtes bloqué à 100, l’autre extrémité n’offre peut‑être pas 1000 (config ou limitation), ou la couche physique empêche le training gigabit.

Décision : Connectez‑vous au switch et vérifiez si le port est en auto et s’il supporte le gigabit.

Task 6: Force a renegotiation without rebooting (bounce the interface)

cr0x@server:~$ sudo ip link set dev enp3s0 down
cr0x@server:~$ sudo ip link set dev enp3s0 up
cr0x@server:~$ sudo ethtool enp3s0 | egrep 'Speed|Duplex|Auto-negotiation|Link detected'
	Speed: 1000Mb/s
	Duplex: Full
	Auto-negotiation: on
	Link detected: yes

Ce que cela signifie : La renégociation a réussi. Cela peut arriver lorsque l’autre extrémité était dans un état étrange ou qu’un dock/NIC avait un problème transitoire.

Décision : Si cela « règle » le problème de manière répétée, vous avez quand même une cause racine — souvent EEE, firmware, ou câblage marginal. Ne déclarez pas victoire tant que cela ne tient pas à l’inactivité, sous charge, et après quelques événements de lien.

Task 7: Disable EEE temporarily to test (ethtool –set-eee)

cr0x@server:~$ sudo ethtool --show-eee enp3s0
EEE Settings for enp3s0:
	EEE status: active
	Tx LPI: enabled
	Rx LPI: enabled
	Supported EEE link modes: 1000baseT/Full
	Advertised EEE link modes: 1000baseT/Full
	Link partner advertised EEE link modes: 1000baseT/Full

cr0x@server:~$ sudo ethtool --set-eee enp3s0 eee off
cr0x@server:~$ sudo ethtool --show-eee enp3s0 | egrep 'EEE status|Tx LPI|Rx LPI'
	EEE status: disabled
	Tx LPI: disabled
	Rx LPI: disabled

Ce que cela signifie : EEE est maintenant désactivé côté hôte. Si le lien négocie correctement et cesse de flapper, vous avez trouvé une incompatibilité.

Décision : Si EEE-off règle le problème, envisagez de désactiver EEE côté switch aussi (ou de mettre à jour le firmware du dock/NIC). Puis décidez si les économies d’énergie valent les incidents récurrents. Habituellement : non.

Task 8: Verify the PCIe NIC model/driver (lspci)

cr0x@server:~$ lspci -nnk | grep -A3 -i ethernet
03:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Connection I219-LM [8086:15d7] (rev 31)
	Subsystem: Dell Device [1028:07a1]
	Kernel driver in use: e1000e
	Kernel modules: e1000e

Ce que cela signifie : Vous connaissez le chipset et le pilote. Cela compte lorsque vous corrélez avec des bizarreries d’autonégociation connues ou des exigences de firmware.

Décision : Si c’est une NIC USB ou un chipset moins réputé et que vous voyez des négociations répétées à 100 Mbps, testez avec un autre adaptateur. La vie est courte.

Task 9: Check switch-side errors from the host perspective (LLDP neighbor)

cr0x@server:~$ sudo lldpctl enp3s0
-------------------------------------------------------------------------------
LLDP neighbors:
-------------------------------------------------------------------------------
Interface:    enp3s0, via: LLDP, RID: 1, Time: 0 day, 00:00:25
  Chassis:
    ChassisID:    mac 00:11:22:33:44:55
    SysName:      access-sw-7f
  Port:
    PortID:       ifname Gi1/0/17
    PortDescr:    GigabitEthernet1/0/17

Ce que cela signifie : Vous avez identifié le switch exact et le port sans jouer à « quel placard ? » avec les Facilities.

Décision : Vous pouvez maintenant vérifier la configuration et les compteurs de cette interface spécifique sur le switch. Si LLDP est absent, vous êtes peut‑être connecté via un appareil intermédiaire basique (mini‑switch, dock, convertisseur média) qui ne parle pas LLDP.

Task 10: On the switch, check interface status and negotiation (Cisco-style)

cr0x@server:~$ ssh netops@access-sw-7f "show interfaces gi1/0/17 status"
Port      Name               Status       Vlan       Duplex  Speed Type
Gi1/0/17  user-desk-117      connected    20         a-full  a-100  10/100/1000BaseTX

Ce que cela signifie : Le switch est d’accord : autoneg full duplex, vitesse auto mais atterri à 100. Le port est capable de gigabit, donc la limitation est de la négociation/physique, pas de la capacité du port.

Décision : Vérifiez les compteurs d’erreurs et confirmez que le port n’est pas manuellement plafonné.

Task 11: Check switch port counters for CRC and input errors (Cisco-style)

cr0x@server:~$ ssh netops@access-sw-7f "show interfaces gi1/0/17 counters errors"
Port        Align-Err  FCS-Err  Xmit-Err  Rcv-Err  UnderSize  OutDiscards
Gi1/0/17           0      219         0        0          0            0

Ce que cela signifie : Les erreurs FCS correspondent à l’historique CRC côté hôte. Les problèmes de couche physique sont maintenant le suspect principal.

Décision : Déplacez l’endpoint sur un câble/port connu bon ; si les erreurs s’arrêtent, le chemin de câblage est mauvais. Si les erreurs persistent malgré le changement de câble, suspectez le port NIC ou le port du switch en défaut.

Task 12: Check whether the switch port is forced to 100 (Cisco-style running-config)

cr0x@server:~$ ssh netops@access-sw-7f "show running-config interface gi1/0/17"
Building configuration...

Current configuration : 162 bytes
!
interface GigabitEthernet1/0/17
 description user-desk-117
 switchport access vlan 20
 spanning-tree portfast
 speed auto
 duplex auto
end

Ce que cela signifie : Le port n’est pas forcé. Si vous aviez vu speed 100 ou duplex half, vous auriez votre réponse immédiatement.

Décision : Si le port est forcé, corrigez‑le (mettez en auto sauf si vous avez une raison documentée et spécifique). S’il est en auto, concentrez‑vous sur les paires du câble, les terminaisons, les appareils intermédiaires ou les ports défectueux.

Task 13: Use a packet test to prove throughput vs link speed (iperf3)

cr0x@server:~$ iperf3 -c 10.20.30.40 -P 4 -t 10
Connecting to host 10.20.30.40, port 5201
[SUM]   0.00-10.00  sec   112 MBytes  94.1 Mbits/sec  0             sender
[SUM]   0.00-10.00  sec   111 MBytes  93.2 Mbits/sec                receiver

Ce que cela signifie : Vous atteignez le plafond d’un lien 100 Mbps (après overhead). Cela confirme que le symptôme n’est pas « l’application est lente » ; le lien est réellement plafonné.

Décision : Arrêtez d’optimiser la couche 4/7. Réglez d’abord la négociation du lien.

Task 14: Identify whether a USB NIC is involved (lsusb)

cr0x@server:~$ lsusb | grep -i ethernet
Bus 001 Device 006: ID 0bda:8153 Realtek Semiconductor Corp. RTL8153 Gigabit Ethernet Adapter

Ce que cela signifie : Vous utilisez un adaptateur gigabit USB. Ceux‑ci peuvent être parfaitement corrects, mais sont aussi des coupables fréquents pour des négociations bizarres et des bizarreries EEE.

Décision : Testez avec un autre adaptateur ou une NIC directe si disponible. Si le problème disparaît, cessez de blâmer le câblage du bâtiment. Il n’était pas innocent, mais pas coupable non plus.

Task 15: On Windows, confirm negotiated speed (PowerShell)

cr0x@server:~$ powershell.exe -NoProfile -Command "Get-NetAdapter | Select-Object Name, Status, LinkSpeed"
Name      Status LinkSpeed
----      ------ ---------
Ethernet  Up     100 Mbps

Ce que cela signifie : Windows confirme 100 Mbps. Ce n’est pas un problème uniquement lié au pilote Linux.

Décision : Vérifiez le câblage, la configuration du switch et les appareils intermédiaires. Si une seule OS voit 100, concentrez‑vous sur les paramètres de pilote pour cet OS (Speed & Duplex, EEE).

Task 16: Reset Windows adapter advanced properties (Speed & Duplex)

cr0x@server:~$ powershell.exe -NoProfile -Command "Get-NetAdapterAdvancedProperty -Name Ethernet | Where-Object DisplayName -Match 'Speed|Duplex' | Select-Object DisplayName, DisplayValue"
DisplayName       DisplayValue
-----------       ------------
Speed & Duplex    Auto Negotiation

Ce que cela signifie : L’adaptateur est en auto, ce qui est généralement correct. Si ceci était forcé à 100, vous auriez une blessure auto‑infligée.

Décision : Laissez en auto sauf si vous dépannez un bug connu. Forcer le gigabit d’un côté est une façon de créer un nouvel incident en « résolvant » l’actuel.

Trois mini-récits en entreprise depuis le terrain

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Dans une entreprise moyenne avec un bureau hybride, une équipe finance s’est plainte que « le partage de fichiers rame ». L’équipe stockage a vérifié le NAS : disques OK, CPU OK, graphiques réseau sans histoire. Le blâme a donc migré — parce que le blâme migre toujours — vers « la nouvelle politique de signature SMB » et « les mises à jour Windows ».

Un administrateur junior a fait comme tout le monde : il a changé le cordon de brassage au bureau de l’utilisateur. Le lien est revenu à 1 Gbps. Ticket clos. Tout le monde est passé à autre chose. Deux jours plus tard, le même utilisateur a ouvert le même ticket. Cordon remplacé encore. Correctif temporaire encore.

Finalement quelqu’un a fait l’impensable : il a tracé le chemin. Cordon de bureau → prise murale → panneau de brassage → switch. Ils ont déplacé le port du panneau de brassage de l’utilisateur sur un autre port du switch et le problème a disparu définitivement. Le vrai souci était un port de switch unique devenu instable ; il négociait à 100 sous certaines conditions de température et de charge et jetait parfois des erreurs FCS.

L’hypothèse erronée était « c’est le câble parce que le remplacement a aidé ». La vraie leçon : la corrélation temporaire n’est pas une causalité. Le changement de câble a modifié la pression de contact et réinséré les connecteurs, masquant le composant défaillant réel.

Après que le port ait été retiré du service, ils ont documenté une règle : si un problème 100 Mbps revient deux fois au même endroit, cessez de remplacer les cordons et commencez à isoler ports et terminaisons. Cette règle a évité de futurs incidents de déjà‑vu.

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

Une autre organisation a décidé de standardiser les ports de bureau à 100 Mbps « pour réduire les tempêtes de broadcast et améliorer la stabilité ». C’était vendu comme une optimisation propre : moins de bruit, moins de risques, moins de tickets. Cela sonnait aussi délicieusement décisif, ce qui attire dans certaines réunions.

Pendant un temps, tout allait bien. La plupart des charges de travail de bureau ne criaient pas. Puis la société a déployé des sauvegardes chiffrées d’endpoints sur le LAN la nuit. Soudain, le job nocturne débordait jusqu’au matin. Les portables téléchargeaient toujours à l’arrivée des utilisateurs et les performances interactives se sont effondrées. Le helpdesk a été submergé de rapports « VPN lent » et « Wi‑Fi cassé », car les utilisateurs ne distinguent pas les méthodes d’accès ; ils ressentent juste la douleur.

L’ingénierie a creusé et a trouvé l’évidence a posteriori : certains endpoints étaient en gigabit et terminaient vite, d’autres étaient artificiellement limités à 100 et créaient de la congestion longue durée. Le réseau n’est pas devenu plus stable. Il est devenu plus prévisiblement saturé.

Le retour de bâton n’était pas seulement le débit. Certains ports étaient forcés à 100/full tandis que les endpoints restaient en auto. Quelques-uns ont négocié incorrectement, entraînant des symptômes de mismatch de duplex et des tempêtes de retransmission qui ressemblaient à « instabilité réseau aléatoire ».

Ils ont fini par revenir en arrière : par défaut auto/auto à 1G, et ils ont traité les tempêtes de broadcast avec de vrais contrôles (storm control, segmentation, DHCP snooping, bonne hygiène des switches). L’optimisation était un raccourci. Les raccourcis sont bien, jusqu’à ce qu’ils deviennent la route.

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

Une équipe de data center avait une pratique que personne ne vantait : chaque nouvelle course cuivre était certifiée avec un testeur de câble et étiquetée bout à bout, y compris les IDs de port de panneau de brassage. Ils gardaient aussi une petite réserve de courts cordons de brassage connus bons scellés dans une boîte, utilisés uniquement pour le dépannage.

Un après‑midi, une nouvelle baie de serveurs est mise en service et la moitié des nœuds négociaient à 100 Mbps. Le chaos habituel a essayé de se former. Mais l’équipe avait des reçus : le câblage horizontal était certifié, et les cordons utilisés pour le déploiement provenaient d’un lot neuf qui n’avait pas été validé.

Ils ont branché un serveur sur un cordon connu bon issu de la boîte scellée : 1 Gbps instantanément. Ils ont testé quelques cordons du nouveau lot : plusieurs avaient des paires défaillantes. Pas « basse qualité » — réellement défectueux.

Parce que l’équipe avait des étiquettes bout à bout et des enregistrements de certification, le dépannage ne s’est pas transformé en dispute. Ils ont isolé la variable, confirmé, remplacé tout le lot et sont passés à autre chose. Pas d’héroïsme. Pas de veillée.

C’est l’intérêt des pratiques ennuyeuses : elles ne vous font pas sentir malin. Elles vous font sentir fini.

Erreurs courantes : symptômes → cause racine → correction

1) « C’est du Cat5, donc ça ne peut pas faire du gigabit »

Symptôme : Le lien négocie à 100 ; quelqu’un pointe le blouson du câble.

Cause racine : Confusion entre la catégorie indiquée et la qualité réelle de l’installation. Beaucoup de courses Cat5 peuvent faire du gigabit sur de courtes distances ; beaucoup de Cat5e échouent au gigabit à cause de terminaisons défectueuses.

Correction : Ne discutez pas à partir de l’étiquette. Testez en déplaçant vers un court câble connu bon directement au switch. Si cela donne 1G, faites certifier le câblage structuré ou re‑terminez la prise/panneau.

2) « Forcer la vitesse résout les problèmes de négociation »

Symptôme : Quelqu’un force 1000/full sur l’hôte ou le switch ; le lien devient instable ou reste à 100.

Cause racine : Le gigabit attend l’autonégociation en pratique. Forcer un côté peut casser l’accord de timing master/slave et provoquer des retours silencieux.

Correction : Utilisez auto/auto sauf si vous travaillez autour d’un bug documenté — et alors corrigez le bug, ne vivez pas avec le contournement indéfiniment.

3) « Pas d’erreurs dans les logs applicatifs, donc ce n’est pas le réseau »

Symptôme : Les utilisateurs rapportent de la lenteur ; l’application semble OK ; le lien est à 100.

Cause racine : Le réseau fonctionne simplement en plafond. Beaucoup d’applications ne loggent pas « votre NIC a mal négocié aujourd’hui ».

Correction : Vérifiez d’abord la vitesse négociée. C’est plus rapide que de lire des logs applicatifs sur lesquels vous ne pouvez rien agir.

4) « Ça doit être le switch, les switches sont maléfiques »

Symptôme : Plusieurs endpoints sur différents ports affichent 100 Mbps, de façon intermittente.

Cause racine : Souvent un lot de cordons de brassage défectueux, une rangée de panneau de brassage douteuse, ou un nouveau modèle de dock déployé.

Correction : Identifiez la chose commune : même panneau de brassage, même dock, même lot de câbles. Utilisez LLDP pour pointer les ports et corréler.

5) « Le Wi‑Fi est plus rapide que l’Ethernet ici »

Symptôme : Le portable obtient de meilleurs débits en Wi‑Fi qu’en filaire.

Cause racine : La liaison filaire est bloquée à 100 à cause des paires/négociation ; le Wi‑Fi se connecte à des débits PHY supérieurs et offre alors un meilleur débit ponctuellement.

Correction : Traitez‑le comme un problème de câblage/port, pas comme une condamnation d’Ethernet en général.

6) « C’est en full duplex, donc ça ne peut pas être physique »

Symptôme : Le duplex affiche full des deux côtés ; pourtant c’est 100 Mbps et des erreurs apparaissent.

Cause racine : Le full duplex peut exister à 100 alors que le training gigabit échoue à cause d’une paire manquante ou d’un SNR faible.

Correction : Recherchez CRC/FCS et isolez les segments de câble. Le full duplex n’est pas un certificat de bonne santé.

7) « Le port indique GigabitEthernet, donc c’est gigabit »

Symptôme : Le nom du port sur le switch suggère du gigabit ; la vitesse négociée est 100.

Cause racine : La capacité du port n’est pas le résultat. Le lien choisit ce qu’il peut supporter de manière fiable.

Correction : Vérifiez la vitesse négociée aux deux extrémités, et regardez ce qui est annoncé. Puis réparez la raison pour laquelle la négociation n’atteint pas 1000.

8) « On a remplacé le câble deux fois ; ce n’est pas le câblage »

Symptôme : Plusieurs remplacements de câble n’ont pas aidé.

Cause racine : Le câble n’est pas le seul composant physique. La prise, le panneau et le port comptent aussi. De plus : les gens remplacent toujours par la même pièce de rechange douteuse du tiroir « divers ».

Correction : Utilisez un cordon de brassage testé et connu bon, contournez les appareils intermédiaires, et déplacez les ports. Considérez le dépannage comme de l’isolation, pas un rituel.

Checklists / plan pas à pas

Pas à pas : isoler le problème en 20 minutes

1. Confirmer le symptôme : lancez ethtool (Linux) ou Get-NetAdapter (Windows) et enregistrez vitesse/duplex/autonégociation.
2. Identifier le switchport : utilisez LLDP si disponible ; sinon tracez via les tables MAC (demandez à NetOps si nécessaire).
3. Vérifier la config du switchport : assurez‑vous que vitesse/duplex sont en auto sauf exception documentée.
4. Vérifier les compteurs du switchport : FCS/CRC indiquent couche physique ; des compteurs propres pointent vers la config ou l’endpoint.
5. Contourner les intermédiaires : retirez docks, coupleurs, prolongateurs en ligne et plaques murales si possible.
6. Cordon court connu bon jusqu’au switch : c’est le test d’isolation physique le plus rapide.
7. Changer de port sur le switch : migrez sur un autre port avec config connue et observez la négociation.
8. Tester un autre endpoint : si un autre hôte négocie 1G sur le même câble/chemin, la NIC/dock original est suspect.
9. Désactiver EEE comme test : si cela corrige les flaps ou la négociation obstinée, décidez d’un changement de config permanent.
10. Documenter la cause racine : « cordon de brassage défectueux » est acceptable seulement si vous pouvez reproduire la panne avec ce cordon ailleurs ou valider avec un testeur.

Checklist opérationnelle : ce qu’il faut standardiser pour éviter la répétition

• Conserver un jeu scellé de cordons courts connus bons uniquement pour le dépannage.
• Exiger la certification (ou au moins un test de continuité des paires) pour les nouvelles courses structurées et le travail sur panneaux de brassage.
• Par défaut, configurer les ports d’accès switch en auto/auto et documenter toute exception forcée avec raison et propriétaire.
• Suivre les modèles de dock/NIC USB et les versions de firmware ; traitez‑les comme des équipements réseau, car ils le sont.
• Surveiller les compteurs d’erreurs des switchports (FCS, input errors) et les flaps de lien ; « 100 Mbps » est souvent précédé d’une instabilité physique.

Faits et histoire qui aident vraiment

• 100BASE-TX utilise deux paires ; 1000BASE-T en utilise quatre. Une paire morte signifie souvent « 100 Mbps pour toujours ».
• 10BASE-T et 100BASE-TX peuvent souvent passer sur du câblage imparfait ; le gigabit est moins indulgent car il pousse plus de bits sur le même cuivre.
• L’autonégociation est devenue essentielle avec l’augmentation des débits. Les jours où l’on pouvait forcer partout sont terminés pour la plupart des environnements.
• L’Ethernet sur paire torsadée a été conçu pour être bon marché et résilient, ce qui explique pourquoi cela fonctionne du tout à travers des murs et des terminaisons douteuses.
• Les labels de catégorie ne garantissent pas la performance. La qualité d’installation (rayon de courbure, terminaison, diaphonie) domine souvent le résultat réel.
• Le gigabit cuivre utilise annulation d’écho et DSP sophistiqué. C’est pourquoi les PHY peuvent « s’entraîner » et décider que le canal n’est pas assez bon.
• EEE (802.3az) est arrivé pour réduire la consommation au repos. Dans certaines combinaisons d’appareils, il est aussi arrivé pour créer des « flaps mystères ».
• Le nommage des ports de switch peut induire en erreur. « GigabitEthernet » est une capacité, pas une garantie de vitesse négociée.
• Les cordons de brassage tombent en panne plus qu’on ne le croit parce qu’ils sont pliés, roulés sous des chaises et remplacés constamment — leur vie est plus dure que celle du câble encastré.

Une idée paraphrasée, portée par l’esprit de fiabilité de W. Edwards Deming, convient parfaitement au réseau : idée paraphrasée — « Sans données, vous n’êtes qu’une autre personne avec une opinion. » — W. Edwards Deming

Blague #2 : L’autonégociation, c’est comme la diplomatie : quand les deux côtés refusent de parler, tout le monde retombe sur d’anciens accords.

FAQ

Pourquoi un mauvais câble fonctionne souvent encore à 100 Mbps ?

Parce que 100BASE-TX n’a besoin que de deux paires et tolère des conditions de signal plus marginales. Le gigabit nécessite les quatre paires et de meilleures caractéristiques de canal.

Si j’ai du Cat6, pourquoi suis‑je toujours bloqué à 100 ?

Parce que la catégorie indiquée n’est pas la même chose qu’un chemin correctement terminé et intact. Un cordon Cat6 branché sur une prise keystone mal poinçonnée reste une prise mal poinçonnée.

Forcer 1000 Mbps est‑ce une solution valide ?

Presque jamais. Forcer les réglages est un bon outil de diagnostic seulement si vous comprenez les deux extrémités et pouvez revenir en arrière en toute sécurité. En production, auto/auto est la valeur par défaut pour une raison.

Un mismatch duplex est‑il possible si les deux côtés disent « full » ?

Si les deux côtés négocient réellement le full et sont d’accord, le mismatch est improbable. Mais si un côté est forcé et l’autre en auto, le côté auto peut mal détecter le duplex. Vérifiez toujours les configurations réelles des deux côtés, pas seulement la lecture courante.

Quelle est la façon la plus rapide de prouver que ce n’est pas le switch ?

Amenez l’endpoint au switch et utilisez un court câble connu bon. S’il négocie en 1G là‑bas, le switch est probablement OK et le chemin structuré ne l’est pas.

Les docks et adaptateurs USB Ethernet causent‑ils vraiment des négociations à 100 Mbps ?

Oui. Ils peuvent avoir des PHYs de moindre qualité, des firmware bizarres et plus de points de connexion physiques. Testez en contournant le dock/adaptateur et comparez les résultats.

Comment savoir si un port de switch est configuré pour être limité à 100 ?

Vérifiez la configuration en cours pour cette interface. Sur de nombreux switches vous verrez explicitement speed 100 ou équivalent. S’il est en auto mais reste à 100, le port réagit à la négociation/aux conditions physiques.

Mon lien est à 1 Gbps mais les performances restent mauvaises. Est‑ce lié ?

Problème différent. Vous regardez maintenant la congestion, les paramètres d’offload CPU, les mismatches MTU, les goulets de stockage, la perte de paquets ou des limites applicatives. Ne cherchez pas des corrections 100 Mbps quand vous avez un lien 1 Gbps.

Une seule broche tordue dans une prise RJ‑45 peut‑elle provoquer cela ?

Oui. Des contacts pliés ou contaminés peuvent couper une paire de façon intermittente. Le lien peut se stabiliser à 100 Mbps parce que le training gigabit échoue. Inspectez et testez avec des composants connus bons.

Est‑il sûr de désactiver EEE partout ?

Généralement oui dans les réseaux d’accès en entreprise, surtout si vous avez observé des problèmes. Les économies d’énergie sont habituellement faibles comparées au coût opérationnel de liens instables. Validez cependant selon votre banque de matériel.

Conclusion : étapes suivantes qui ne vous feront pas perdre la journée

Si votre liaison Ethernet est bloquée à 100 Mbps, ne partez pas des folklore. Partez des preuves.

1. Vérifiez la vitesse/duplex/autonégociation négociés sur l’hôte et le switch.
2. Identifiez le port du switch exact (LLDP aide) et vérifiez les compteurs pour CRC/FCS.
3. Isolez le chemin avec un court câble connu bon directement au switch ; contournez les docks et intermédiaires.
4. Si c’est physique, réparez le physique : re‑terminez la prise/panneau, remplacez le lot de cordons défectueux, ou retirez le port défaillant.
5. Si c’est de la configuration, normalisez en auto/auto et documentez toute exception comme vous documenteriez une règle de firewall : avec un propriétaire et une raison.

L’objectif n’est pas d’« obtenir du 1G une fois ». L’objectif est de le faire tenir à 1G après redémarrages, événements de lien, et la prochaine personne qui « range » le placard.