Une erreur CRC est un symptôme, pas un emplacement — elle peut tout aussi bien provenir du port local, du câble ou du module optique, ou de l'appareil distant. Voici la procédure d'échange en trois étapes qui isole lequel des trois en ne changeant qu'une seule variable à la fois, et comment lire chaque résultat sans deviner.
By Yuwen Zhang (Atlas), founder of AtlasCommTech — 13 years of carrier & enterprise network deployments · Updated July 2026
Une erreur CRC indique seulement qu'une trame est arrivée corrompue — elle ne dit rien sur lequel des trois éléments physiques entre deux appareils l'a réellement corrompue.
Un compteur CRC en hausse sur display interface — qui fait partie du même chemin de rejet/erreur que couvre la note compagnon sur le diagnostic de perte de paquets — signifie que des trames arrivent avec une somme de contrôle qui ne correspond pas à leur contenu. Cela peut se produire à exactement trois endroits : le transceiver et le PHY du port local lui-même, le câble ou le module optique intermédiaire, ou le port de l'appareil distant. Le réflexe est de changer les trois à la fois — échanger le câble et le transceiver et passer à un autre port distant lors de la même intervention — mais cela indique seulement que le problème a disparu, pas quel changement l'a réellement corrigé.
La méthode en trois étapes ci-dessous ne change qu'une seule variable par étape, dans un ordre fixe, et indique, à partir du niveau de référence du compteur et du résultat de chaque étape, exactement où arrêter de chercher.
Chaque étape fige deux des trois éléments et n'échange que le troisième — le résultat de cette seule étape indique s'il faut escalader ou passer à la suivante.
Présenté sous forme d'arbre de décision, l'ordre compte : d'abord le port local, puis le lien physique, puis l'appareil distant — car chaque étape est plus rapide et moins coûteuse à tester que la suivante, et écarter d'abord les possibilités bon marché évite un échange de matériel inutile ou un appel inutile au support du pair.
Les légendes du schéma restent en anglais pour la clarté technique.
Avant d'exécuter l'une des trois étapes, effacez les compteurs de l'interface avec reset counters interface, afin que ce que vous lisez ensuite ne reflète que cette fenêtre de test, et non l'historique accumulé depuis le dernier redémarrage de l'appareil.
Un échange, une lecture propre du compteur, une décision — répété au maximum trois fois.
display interface accumule depuis le dernier redémarrage ou la dernière remise à zéro — le lire sans effacer au préalable mélange des semaines d'anciennes erreurs au test du jour.
<HUAWEI> reset counters interface GigabitEthernet 0/0/5
<HUAWEI> display interface GigabitEthernet 0/0/5
GigabitEthernet0/0/5 current state : UP
Line protocol current state : UP
Total Error: 10
CRC: 4, Giants: 0
Jabbers: 1, Fragments: 0
Runts: 0, DropEvents: 0
Alignments: 0, Symbols: 5
// CRC incrementing after a clean reset -- a real, current problem, not old history
Gardez le câble et le port distant exactement tels quels — changez uniquement le port local sur lequel le lien est branché.
Gardez le port local et le port distant exactement tels quels — changez uniquement le câble, la fibre ou le module optique entre les deux.
Gardez le port local et le lien exactement tels quels — changez uniquement ce qui se trouve à l'extrémité distante.
| Étape | Ce que vous avez échangé | Si l'erreur suit l'échange | Conclusion |
|---|---|---|---|
| 1 | Port local | L'erreur reste sur la position de port d'origine | Matériel de l'appareil local — ouvrir un dossier support |
| 1 | Port local | L'erreur disparaît lors du déplacement vers l'autre port | Le port est disculpé — passer à l'étape 2 |
| 2 | Câble / fibre | L'erreur suit le câble | Problème de qualité de liaison — inspecter et remplacer |
| 2 | Module optique | L'erreur suit le module certifié | Escalader vers la R&D du fournisseur — pas un simple échange |
| 2 | Câble et module | L'erreur reste malgré les deux échanges | Le lien est disculpé — passer à l'étape 3 |
| 3 | Port pair (pair multi-port) | L'erreur disparaît sur un autre port pair | Problème de port côté pair — équipe de support du pair |
| 3 | Appareil pair (pair mono-port) | L'erreur persiste sur un autre port ou unité pair | Problème de compatibilité — supports des deux fournisseurs ensemble |
La méthode est simple ; voici les façons dont on obtient en pratique une lecture faussée.
SYMPTOML'interface ne passe jamais en état admin ou opérationnel down, ce qui écarte tôt un problème de couche physique — un véritable défaut ferait sûrement tomber le lien.
CAUSEUn connecteur qui se dégrade, un câble marginal ou un budget optique limite ne fait pas nécessairement tomber le lien du tout — cela corrompt simplement une fraction croissante des trames pendant que le lien reste Up en permanence. Le compteur CRC est souvent le seul symptôme que vous obtiendrez avant qu'il ne finisse par tomber en panne franche.
FIXN'utilisez jamais « le lien est Up » comme raison pour sauter la méthode d'échange — un compteur CRC croissant sur une interface Up est exactement le cas pour lequel cette méthode est faite.
SYMPTOMUn port affiche un Total Error avec des erreurs CRC, Alignments et Symbol qui grimpent, accompagné d'un important compteur Discard sortant — et le port oscille de façon répétée entre Up et Down dans le journal.
CAUSEDans un cas réel, un port de commutateur a négocié automatiquement une baisse à 10Mbit/s semi-duplex face à un pair attendant du 1000Mbit/s en duplex intégral, parce que les modes de négociation des deux extrémités n'étaient pas cohérents. Le désaccord lui-même a produit les erreurs CRC/Alignment/Symbol et l'énorme compteur de rejets — aucun défaut de câble ou d'optique n'était en cause.
FIXAvant d'exécuter la méthode d'échange, vérifiez les champs Negotiation et Duplex avec display interface aux deux extrémités. En cas de désaccord, forcez les deux extrémités au même débit et duplex non auto-négociés plutôt que d'échanger du matériel.
<HUAWEI> display interface GigabitEthernet 0/0/5
Duplex: FULL, Negotiation: ENABLE // port working in auto-negotiation mode
// diagnostic log showed CurrDuplex=HALF, Speed=10M during the fault window
[HUAWEI] interface GigabitEthernet 0/0/5
[HUAWEI-GigabitEthernet0/0/5] undo negotiation auto
[HUAWEI-GigabitEthernet0/0/5] speed 1000
// confirm the peer is also forced to the same speed/duplex, non-auto-negotiation
SYMPTOMVous échangez le câble, attendez, et vérifiez display interface — le compte CRC est toujours non nul, donc la conclusion est que le câble n'était finalement pas le problème.
CAUSEdisplay interface accumule depuis le dernier redémarrage ou la dernière remise à zéro manuelle, pas depuis le moment de l'échange. Un compte non nul après la correction peut simplement être les erreurs survenues avant que vous ne changiez quoi que ce soit, toujours présentes dans le compteur.
FIXExécutez reset counters interface immédiatement après chaque échange, avant de générer tout trafic de test — ne lisez le compteur qu'après cette réinitialisation, jamais avant.
SYMPTOMQuelques pings de test après un échange montrent un compteur propre, si bien que l'étape est marquée comme résolue — puis le compte CRC revient quelques jours plus tard.
CAUSELes causes intermittentes — un câble sous contrainte mécanique, un budget optique marginal seulement à certaines températures, des interférences électromagnétiques qui n'apparaissent que sous un volume de trafic réel — ne se manifestent pas nécessairement dans une brève fenêtre de test à faible trafic juste après l'échange.
FIXLaissez chaque étape fonctionner sous du trafic de production réel pendant une fenêtre significative — des heures, pas quelques pings — avant de conclure que l'étape a résolu le problème.
SYMPTOML'étape 3 est exécutée, le port pair est échangé, et les mêmes erreurs CRC persistent — la conclusion immédiate est un problème d'interopérabilité entre fournisseurs.
CAUSEDes erreurs qui persistent après un échange de port pair pointent bien vers la compatibilité comme explication principale, mais seulement si les étapes 1 et 2 ont réellement été menées à bien proprement au préalable. Si le port local ou le lien n'a jamais été correctement disculpé comme cause, le résultat de l'étape 3 est ambigu, pas concluant.
FIXN'interprétez le résultat de l'étape 3 comme un problème de compatibilité qu'une fois que les étapes 1 et 2 ont chacune disculpé indépendamment leur élément — ne sautez pas directement à l'étape 3 pour gagner du temps.
Tirées directement du terrain — celles pour lesquelles il vaut la peine d'avoir une réponse prête.
Oui, si vous n'avez pas déjà une raison forte de suspecter un élément spécifique — l'ordre privilégie le moins coûteux et le plus rapide en premier. Mais si le même câble ou module optique a déjà montré un problème récemment sur une autre paire de ports, il est raisonnable de commencer à l'étape 2 plutôt que de refaire l'étape 1 depuis le début.
N'importe quel port du même appareil actuellement exempt d'erreurs sous un trafic similaire fait office de référence connue comme fonctionnelle — il n'a pas besoin d'être un type de port identique, seulement propre après reset counters interface.
Oui. Une croissance lente et régulière est souvent le signe précoce d'un connecteur en dégradation ou d'un câble approchant sa limite de rayon de courbure ou de longueur — exactement le genre de chose qui devient plus tard un véritable événement de panne physique si on le laisse tel quel. Le détecter pendant qu'il ne s'agit encore que d'une dérive lente du CRC coûte moins cher que de diagnostiquer une panne franche des heures plus tard.
Non. Si les erreurs ont disparu lorsque vous avez changé uniquement le câble ou la fibre en laissant le module optique intact, le lien (câble/fibre) est la cause confirmée — le module optique n'a pas besoin d'être remplacé ni escaladé séparément.
Oui — exécutez-la indépendamment aux deux extrémités, en commençant par celle qui a le compte CRC le plus élevé ou qui est la plus accessible. Si les deux directions se dégagent au même échange, cette étape était presque certainement la correction. Si elles se dégagent à des étapes différentes, vous avez peut-être affaire à deux pannes distinctes empilées sur le même lien, pas une seule.
Cette note s'appuie sur le modèle de compteur CRC/erreur du commutateur Huawei série S et son flux de travail reset counters interface / display interface, ainsi que sur les cas de terrain qui la sous-tendent. La méthode sous-jacente — isoler une variable par échange, dans un ordre de coût fixe — est indépendante du fournisseur et s'applique directement à d'autres plateformes, même si les commandes exactes changent. Elle ne couvre pas en profondeur les diagnostics de budget de puissance optique ou de niveau OTDR, et suppose que vous pouvez accéder physiquement aux deux extrémités pour échanger des éléments — une extrémité distante entièrement inaccessible vous limite aux étapes 0 et 1 seulement, les étapes 2 et 3 nécessitant quelqu'un sur place chez le pair.
Dites-nous à quelle étape vous en êtes, et ce que le compteur a fait avant et après, et nous vous aiderons à l'interpréter.