Accueil / Notes techniques / Dépannage de la perte de paquets

Perte de paquets réseau : diagnostic optique, erreurs CRC et Discard

La perte de paquets provient presque toujours de l'un de ces trois endroits : un module optique émettant un signal dégradé, une erreur de couche physique en entrée que l'interface compte comme CRC, Giants ou Runts, ou un Discard en sortie dû à une rafale de trafic que le port n'a pas pu mettre en file assez vite. Voici l'ordre pour les distinguer, les champs exacts de display interface qui les différencient, et comment lire les seuils de diagnostic optique sans deviner un chiffre en dBm « normal ».

Par Yuwen Zhang (Atlas), fondateur d'AtlasCommTech — 13 ans de déploiements de réseaux opérateurs et d'entreprise · Mis à jour en juillet 2026

« C'est juste de la perte de paquets » n'est pas un diagnostic

La perte de paquets sur un commutateur est un symptôme avec une liste courte et récurrente de causes — pas une panne unique à traquer à l'aveugle.

La perte de paquets se manifeste côté utilisateur bien avant que quiconque ne touche à une commande display : pages web se chargeant lentement ou partiellement, appels vidéo se transformant en mosaïque de blocs, clients de messagerie instantanée se déconnectant et se reconnectant, téléchargements traînant, un simple ping vers la passerelle qui expire, ou une session de gestion bloquée à la connexion. N'importe lequel de ces symptômes suffit à soupçonner une perte de paquets quelque part sur le chemin — mais ce « quelque part » doit encore être ramené à une interface et un compteur précis avant que quoi que ce soit ne soit corrigé.

Une fois ramenée à une interface de commutateur précise, la perte de paquets provient d'exactement trois endroits : un module optique émettant un signal dégradé, une erreur de couche physique en entrée que l'interface compte et étiquette elle-même, ou une file d'attente en sortie n'ayant pas pu absorber une rafale de trafic. Voici un arbre de décision pour les distinguer, les commandes et champs exacts pour chacun, cinq pièges qui transforment un compteur d'apparence propre en mauvais diagnostic, et cinq réponses de FAQ tirées de cas de terrain réels.

Les trois endroits d'où vient réellement la perte de paquets

Avant que l'une des trois sources n'importe, l'interface elle-même doit être réellement Up — sinon vous lisez un arbre de panne complètement différent.

Placer d'abord le symptôme sur cet arbre indique quelle section ci-dessous lire réellement, au lieu de vérifier les trois dans n'importe quel ordre.

Les légendes du schéma restent en anglais pour la clarté technique.

Évaluer chaque source à tour de rôle

Même interface, trois questions indépendantes — le champ qui répond à chacune est différent, et aucun ne remplace les autres.

Source 1 — Erreurs de bits du module optique

Une puissance optique « à peu près normale » n'est pas la même chose qu'une puissance optique dans les seuils propres de ce module précis — le bloc de diagnostic indique lequel des deux vous regardez.

Exécutez d'abord display interface transceiver sur l'interface et vérifiez le bloc Alarm information. Un LOS Alarm signifie que l'extrémité distante n'envoie aucun signal du tout — vérifiez avec display this si le port de l'une ou l'autre extrémité est arrêté avant de supposer que le module lui-même est défectueux.
Exécutez display interface transceiver verbose et lisez le bloc Diagnostic information : Current RX Power et Current TX Power, chacun comparé aux propres champs Default RX/TX Power High/Low Threshold de ce même module — pas un chiffre en dBm « normal » mémorisé, car différents types de modules rapportent des seuils différents.
Si Current RX Power est inférieur au Low Threshold propre du module, l'extrémité locale reçoit un signal trop faible — vérifiez la distance de transmission par rapport à la portée nominale du module, puis vérifiez la liaison fibre elle-même pour une perte de connecteur excessive ou une courbure trop serrée avant de supposer que le module est défectueux.
Si Current RX Power est supérieur au High Threshold propre du module, il s'agit généralement d'un module longue portée utilisé sur une liaison trop courte, si bien que le signal ne s'est jamais atténué naturellement — ajoutez un atténuateur optique pour protéger le module plutôt que de le remplacer.
Si Current TX Power sort de ses propres seuils dans un sens ou l'autre, cela pointe vers le module local lui-même : une puissance TX faible suggère un émetteur défaillant qui se traduira par un RX faible côté pair ; une puissance TX élevée risque de brûler à terme le récepteur du pair et impose un remplacement du module.

<HUAWEI> display interface 10ge1/0/1 transceiver verbose
... ...
-------------------------------------------------------------------
Warning information:
RxPower High
-------------------------------------------------------------------
Diagnostic information:
Temperature (Celsius)                :41.41
Voltage (V)                          :3.27
Bias Current (mA)                    :89.76|59.89 (Lane0|Lane1)
                                       71.61|63.70 (Lane2|Lane3)
Bias High Threshold (mA)             :130.00
Bias Low Threshold (mA)              :1.00
Current RX Power (dBm)               :-3.23|-3.11 (Lane0|Lane1)
                                       -2.90|-1.09 (Lane2|Lane3)
Default RX Power High Threshold (dBm):-0.50
Default RX Power Low Threshold (dBm) :-23.98
Current TX Power (dBm)               :0.71|1.21 (Lane0|Lane1)
                                       0.99|0.92 (Lane2|Lane3)
Default TX Power High Threshold (dBm):5.90
Default TX Power Low Threshold (dBm) :-5.90
-------------------------------------------------------------------
// compare Current RX/TX Power against THIS module's own threshold fields,
// never against a memorized "normal" dBm number -- different modules differ

Source 2 — Erreurs physiques en entrée (CRC / Giants / Runts)

Le bloc Input de display interface décompose une plainte générique de « paquets erronés » en compteurs nommés — chacun pointant vers une correction différente.

Exécutez display interface sur l'interface concernée pendant que le trafic métier circule réellement, et lisez Total Error ainsi que les compteurs individuels CRC, Giants, Jabbers, Fragments, Runts, DropEvents, Alignments et Symbols — ce sont tous des compteurs d'entrée, ce qui signifie que la panne est du côté émetteur ou sur le support physique amenant le trafic, pas dans la file de sortie de ce port.
Si le type d'erreur est CRC et que le nombre est faible par rapport au trafic total, vérifiez si le connecteur à l'une des extrémités est desserré ou si le support de transmission — fibre, cuivre, module — est physiquement endommagé ; remettez en place ou remplacez ce qui est endommagé, puis exécutez restart sur l'interface.
Si le type d'erreur est Runts, vérifiez la longueur de trame réellement envoyée par le pair. Si elle est véritablement inférieure à 64 octets, la configuration du pair doit être corrigée ; si la longueur de trame est normale, redémarrez plutôt l'interface locale.
Si le type d'erreur est Giants, comparez la longueur de trame reçue au propre champ The Maximum Frame Length de display interface sur cette interface. Si le pair envoie des trames plus longues que cette valeur, augmentez-la localement avec jumboframe enable value1 ; si la limite locale est déjà à son plafond, faites plutôt réduire au pair son propre MTU avec mtu mtu.

<HUAWEI> system-view
[HUAWEI] display interface 10GE1/0/1
... ...
Total Error: 0
CRC: 0, Giants: 0
Jabbers: --, Fragments: 0
Runts: 0, DropEvents: 0
Alignments: 0, Symbols: 0
Output:
Unicast: 0, Multicast: 1438
Broadcast: 0, Jumbo: 0
Discard: 0, Buffers Purged: 0
Pause: 0

<HUAWEI> display interface 10GE1/0/1
10GE1/0/1 current state : UP (ifindex: 45)
Line protocol current state : UP
Description:
Switch Port, PVID : 1, TPID : 8100(Hex), The Maximum Frame Length is 9216
// compare received frame length against The Maximum Frame Length above

[HUAWEI] interface 10GE1/0/1
[HUAWEI-10GE1/0/1] jumboframe enable 9600
// or, on the sending peer instead:
[peer] mtu 1500

Source 3 — Discard en sortie (congestion)

Discard se trouve dans le bloc Output, pas dans le bloc Input — cela signifie que la file de sortie propre à ce port n'a pas pu suivre, pas que quelque chose en amont est endommagé.

Exécutez display interface (ou display this depuis la vue d'interface) et vérifiez si Discard augmente pendant la fenêtre réelle où l'impact métier a été signalé — un Discard non nul datant de plusieurs semaines n'explique pas une plainte survenant maintenant.
Sur les cartes qui le prennent en charge, exécutez display qos queue statistics interface pour l'interface concernée et lisez les colonnes Passed / Dropped / Drop Rate par file — la congestion sur un port planifié en QoS est par file, une file peut donc perdre massivement pendant qu'une autre passe proprement.
Activez le mode rafale amélioré pour la gestion des tampons de l'interface et observez si Discard continue d'augmenter — cela cible spécifiquement les microrafales, des pics de trafic de quelques millisecondes qu'une moyenne d'échantillonnage multi-seconde ne montre jamais comme un problème de bande passante.
Si Discard continue d'augmenter, mettez en forme ou limitez le débit du trafic réellement à l'origine de la rafale au niveau de sa file source, déplacez le trafic sensible à la latence vers une file de priorité plus élevée, ou augmentez la bande passante disponible — une vitesse d'interface plus rapide, ou l'agrégation de liens sur plusieurs ports physiques.
Si l'on ne sait toujours pas si un ralentissement intermittent est réellement dû à la congestion, capturez le trafic et lisez-le dans l'IO Graph de Wireshark avec l'axe X réglé en millisecondes et l'axe Y en bits — cela révèle le pic de débit instantané qu'une moyenne de compteur d'appareil sur 300 secondes dissimule complètement.

<HUAWEI> display interface 10GE1/0/1
... ...
Output:
Unicast: 0, Multicast: 2033
Broadcast: 0, Jumbo: 0
Discard: 0, Buffers Purged: 0
Pause: 0
Input bandwidth utilization threshold : 90.00%
Output bandwidth utilization threshold: 90.00%
Last 300 seconds input utility rate: 0.01%
Last 300 seconds output utility rate: 0.01%

<HUAWEI> display qos queue statistics interface 10GE1/0/1
Queue CIR/PIR   Passed          Pass Rate   Dropped         Drop Rate
      (kbps)     (Packets/Bytes) (pps/bps)  (Packets/Bytes) (pps/bps)
----------------------------------------------------------------------
0     0/200000000  0              0          0               0
----------------------------------------------------------------------
7     0/200000000  1751           0          208369          507
----------------------------------------------------------------------

<HUAWEI> system-view
[HUAWEI] interface 10ge1/0/1
[HUAWEI-10GE1/0/1] qos burst-mode enhanced
[HUAWEI-10GE1/0/1] qos queue 0 shaping cir 200 mbps pir 200 mbps

5 pièges qui transforment un compteur d'apparence normale en mauvais diagnostic

Chaque compteur ci-dessus est réel et exact — voici comment il est quand même mal interprété.

1. Une puissance optique dans la plage déclenche quand même des alarmes — il n'existe pas de chiffre en dBm « normal » universel

SYMPTÔMEdisplay interface transceiver verbose affiche un avertissement RxPower High ou RxPower Low même si la valeur brute ressemble à un petit nombre banal.

CAUSELes seuils sont rapportés par le module lui-même — Default RX/TX Power High/Low Threshold — et diffèrent selon le type de module et la portée nominale, ce n'est pas une valeur fixe mémorisable d'un modèle à l'autre. Un module longue portée sur une liaison courte se lit « trop élevé » par rapport à son propre seuil, alors que le même chiffre serait banal sur un autre module.

CORRECTIONComparez toujours Current RX/TX Power aux propres champs de seuil de ce module précis dans le même bloc de sortie, jamais à un chiffre en dBm mémorisé ; ajoutez un atténuateur optique lorsqu'un module longue portée est déployé sur une liaison courte.

2. CRC et Discard peuvent sembler identiques sur un tableau de bord — ce sont des directions opposées

SYMPTÔMEUn tableau de bord de trafic affiche un pourcentage de perte global, et personne n'a réellement vérifié dans quelle direction se trouve ce compteur.

CAUSECRC, Giants et Runts sont des compteurs d'entrée — la panne est du côté émetteur ou sur le support physique amenant le trafic. Discard est un compteur de sortie — la panne est une file de sortie de ce port en surabonnement. Remplacer un câble pour un problème de Discard, ou modifier la mise en forme de file pour un problème de CRC, ne résout rien.

CORRECTIONLisez les blocs Input et Output de display interface comme deux questions distinctes avant de décider laquelle des sources ci-dessus s'applique réellement.

3. Un compteur Discard datant de plusieurs semaines n'explique pas la plainte du jour

SYMPTÔMEDiscard est non nul, la congestion est donc blâmée par défaut, alors même que le problème de l'utilisateur se produit en ce moment.

CAUSEDiscard est cumulatif depuis la dernière remise à zéro du compteur ; une rafale unique survenue une fois, des semaines plus tôt, laisse un compteur non nul permanent qui n'a rien à voir avec le ticket actuel.

CORRECTIONObservez si Discard continue d'augmenter pendant la fenêtre réelle d'impact métier, ou vérifiez display qos queue statistics interface pour un Drop Rate par file en direct plutôt que de faire confiance au seul total cumulé.

4. Une boucle ou une attaque produit exactement le même symptôme qu'une congestion ordinaire

SYMPTÔMEDiscard et l'utilisation CPU montent ensemble, et aucune mise en forme ni réglage de file ne fait redescendre Discard.

CAUSEUne boucle de niveau 2 provoquant un flapping de MAC, ou une attaque active — ARP, ICMP, tempête de diffusion — inonde le port d'un trafic qu'une mise en forme légitime n'a jamais été conçue pour absorber, car ce trafic ne devrait tout simplement pas être sur ce port.

CORRECTIONVérifiez display trapbuffer pour un trap de boucle et display mac-address flapping avant de présumer une congestion ; vérifiez display cpu-defend statistics all et display cpu-usage avant de passer du temps à optimiser des files qui n'ont jamais été le vrai goulot d'étranglement.

5. Giants n'apparaît que lorsque quelqu'un modifie le MTU de l'autre côté

SYMPTÔMEUn compteur Giants apparaît après des mois de fonctionnement propre, sans aucun changement de configuration sur le commutateur local.

CAUSELe propre The Maximum Frame Length de cette interface n'a pas changé — mais le MTU de l'appareil pair a changé, et il envoie maintenant des trames plus longues que ce que ce port accepte, ce qui s'enregistre ici en Giants d'entrée et est abandonné.

CORRECTIONComparez la longueur de trame reçue à The Maximum Frame Length de display interface ; augmentez-la localement avec jumboframe enable value1, ou faites réduire au pair son MTU avec mtu mtu — selon le côté qui est réellement censé changer.

Cinq questions qui reviennent constamment

Tirées directement du terrain — celles pour lesquelles il vaut la peine d'avoir une réponse prête.

CRC ou Discard — lequel vérifier en premier ?

Aucun des deux, techniquement — vérifiez d'abord display interface brief, car un port Down ou en ERROR DOWN rend CRC et Discard hors sujet ; voir notre note sur le port Ethernet physiquement down pour cet arbre de panne distinct. Une fois le port confirmé Up, traitez les erreurs d'entrée et le Discard de sortie comme deux questions indépendantes, pas une seule — un port peut avoir l'un, l'autre, les deux, ou aucun.

Le module optique n'affiche aucune Alarm information — puis-je écarter complètement l'optique ?

Pas tout à fait. Alarm information ne signale que les conditions que le module lui-même considère comme anormales, comme LOS ou RX LOL. Il vaut toujours la peine de lire l'intégralité du bloc Diagnostic information et de comparer Current RX/TX Power aux propres champs de seuil du module — une valeur proche d'un seuil, sans le dépasser, peut encore être corrélée à des erreurs intermittentes, surtout quand la température varie au fil de la journée.

Pourquoi display qos queue statistics interface montre-t-il des pertes sur certaines files et pas d'autres ?

Parce que la congestion sur un port planifié en QoS est par file, pas par port. Une file de priorité basse peut perdre massivement pendant qu'une file de priorité élevée transportant de la voix ou du contrôle passe proprement — c'est exactement ce pour quoi la planification par priorité a été configurée. Vérifiez dans quelle file le trafic concerné est réellement classé avant de conclure que tout le port est surabonné.

J'ai remplacé le câble et CRC est tombé à zéro, mais les utilisateurs signalent toujours des lenteurs — que reste-t-il ?

Revérifiez Discard sur la même interface ; un problème de couche physique et un problème de congestion peuvent coexister sur la même liaison montante chargée, et résoudre l'un ne touche pas l'autre. Si les deux reviennent propres, passez aux vérifications de boucle et d'attaque — display trapbuffer pour le flapping MAC, display cpu-defend statistics all pour le trafic d'attaque — avant de supposer que le problème s'est déplacé ailleurs sur le chemin.

Existe-t-il un moyen de prouver qu'un ralentissement intermittent est une congestion quand Discard ne semble jamais bouger ?

Oui. Les compteurs côté appareil font la moyenne sur des intervalles d'interrogation de plusieurs secondes, si bien qu'une véritable microrafale peut faire un pic dans une file et perdre des paquets entre deux interrogations sans jamais être enregistrée comme Discard. Capturer le trafic et le lire dans l'IO Graph de Wireshark, avec l'axe X en millisecondes et l'axe Y en bits, montre le pic de débit instantané qu'une moyenne sur 300 secondes dissimule complètement.

Limites honnêtes de cette note

Limites honnêtes de cette note

Cette note s'appuie sur le modèle de classification des pannes des commutateurs Huawei série S pour la perte de paquets réseau et les commandes display interface / display interface transceiver verbose / display qos queue statistics qui le sous-tendent, ainsi que sur les cas de terrain documentés à leurs côtés. Si votre commutateur est d'une autre marque, les commandes changent mais la logique des trois sources — optique, erreurs d'entrée, congestion de sortie — s'applique directement. Elle garde volontairement brefs la détection de boucle, le traçage d'attaque et la limitation de débit CPCAR, chacun de ces sujets méritant sa propre note ; considérez le piège ci-dessus comme un pointeur pour les vérifier, pas la procédure complète.

Pas encore sûr de laquelle des trois il s'agit ?

Envoyez-nous la sortie display interface du port concerné — les blocs Input et Output — et nous vous aiderons à déterminer de quelle source elle provient réellement.

WhatsApp avec un ingénieur →