Le graphique de débit moyen d'un commutateur peut sembler parfaitement plat alors qu'un port perd discrètement des paquets à cause d'une rafale n'ayant duré qu'une seule milliseconde. Voici comment reconnaître le symptôme, capturer et lire la rafale réelle, parcourir un cas réel où le journal de panne pointait vers la mauvaise cause, et les mesures d'atténuation qui tiennent la route une fois le problème identifié.
By Yuwen Zhang (Atlas), founder of AtlasCommTech — 13 years of carrier & enterprise network deployments · Updated July 2026
J'ai vu un graphique d'utilisation moyenne sur cinq minutes rester sous 30 % alors que ce même port perdait discrètement des paquets — l'outil ne regardait tout simplement pas à la bonne échelle de temps.
Les plateformes de gestion réseau et les outils de supervision des performances calculent généralement l'utilisation sur plusieurs secondes à quelques minutes. À cette résolution, la courbe de trafic d'un port paraît lisse et sans particularité. Mais une seconde représente une durée immense pour une interface qui traite des paquets à un débit de plusieurs gigabits — en zoomant à l'échelle de la milliseconde, le même trafic se révèle régulièrement en dents de scie, avec des pointes atteignant plusieurs fois sa propre moyenne. Lorsque la pointe est assez sévère pour dépasser le tampon du commutateur, c'est une microrafale, et elle produit des rejets qui n'apparaissent jamais comme un problème d'utilisation soutenue.
Voici à quoi ressemble réellement une microrafale, l'ordre de vérification à suivre sans deviner, un cas réel de terrain où les journaux de classification des pannes pointaient directement vers la mauvaise cause, et les mesures d'atténuation qui tiennent la route une fois le problème confirmé.
Les microrafales durent de 1 à 100 millisecondes et peuvent atteindre des pointes de plusieurs dizaines voire centaines de fois le débit moyen — parfois au-delà de la bande passante propre du port.
Une microrafale est une rafale de trafic très courte et très dense sur un port — typiquement 1 à 100 ms — qui atteint un débit instantané bien supérieur à la moyenne mesurée, et dans le pire des cas, supérieur à la bande passante physique du port lui-même. Ce n'est pas un échec de la supervision de la manquer à une résolution de 5 minutes ; c'est un décalage de résolution. Le trafic sous une courbe macro d'apparence plate est régulièrement une courbe micro en dents de scie, et lorsque les dents deviennent assez grandes, c'est la rafale.
Les légendes du schéma restent en anglais pour la clarté technique.
Trois conditions se combinent pour créer la plupart des microrafales : un comportement applicatif en rafales (schémas requête/réponse, trafic sensible à la latence essayant d'envoyer le plus vite possible), plus de bande passante entrante que sortante sur le même chemin de transfert (un gros tuyau alimentant un petit, ou plusieurs ports de même débit convergeant vers un seul), et le classique motif en dents de scie du TCP sous évitement de congestion (démarrage lent puis réduction de moitié). Aucune des trois ne nécessite une mauvaise configuration — ce sont des comportements de trafic normaux qui se heurtent à un tampon trop petit pour l'instant donné.
Les compteurs de rejets et les alarmes QoS indiquent qu'une microrafale s'est probablement produite ; la capture par mirroring et les fonctions de détection propres au commutateur indiquent son ampleur et sa fréquence.
Chacun des symptômes ci-dessous signifie « une microrafale s'est probablement produite ici », pas une confirmation — ce sont les vérifications suivantes qui la confirment réellement.
<HUAWEI>display interface 10GE1/0/1
10GE1/0/1 current state : UP (ifindex: 8)
Line protocol current state : UP
Last 300 seconds input rate: 225 bits/sec, 0 packets/sec
Last 300 seconds output rate: 2075 bits/sec, 1 packets/sec
Input peak rate 2387819 bits/sec, Record time: 2025-11-26 16:11:22+08:00
Output peak rate 1277476 bits/sec, Record time: 2025-11-26 15:51:14+08:00
Input:
Discard: 0, Frames: --
Output:
Discard: 89, Buffers Purged: 0
// average rate looks trivial -- but 89 egress discards already happenedLes rejets côté sortant, et non entrant, constituent la signature caractéristique d'une microrafale plutôt que d'un problème CRC ou de couche physique.
<HUAWEI>display qos queue statistics interface 10GE1/0/1
Queue CIR/PIR Passed Pass Rate Dropped Drop Rate Drop Time
(% or kbps) (Packets/Bytes) (pps/bps) (Packets/Bytes) (pps/bps)
----------------------------------------------------------------------------------------------
6 0 21 0 0 0 -
10000000 6930 88 0 0
----------------------------------------------------------------------------------------------
7 0 255 0 0 0 -
10000000 31365 492 0 0Un graphique d'E/S à la milliseconde est la granularité réellement nécessaire pour qu'une microrafale devienne visible — l'intervalle par défaut de plusieurs secondes ne montre que la même courbe plate déjà fournie par la plateforme de supervision.
Deux fonctions intégrées permettent cela sans aucune capture par mirroring — aucune n'est disponible sur tous les modèles de commutateur, donc vérifiez la prise en charge de votre matériel avant de la supposer présente.
[HUAWEI] interface 100GE 1/0/1
[HUAWEI-100GE1/0/1] qos buffer-monitoring percent low 60 high 90
<HUAWEI> display qos buffer-monitoring result interface 100GE 1/0/1
Queue Time BufferUsage(Bytes) Percent(%)
----------------------------------------------------------------
0 2015-11-11 14:36:15.208 1602016 100
// a saved record here confirms a microburst occurred, and precisely when
[HUAWEI] qos micro-burst detection enhanced enable
[HUAWEI] interface 100GE 1/0/1
[HUAWEI-100GE1/0/1] qos micro-burst detection enableUn client réseau de campus sur une pile S12700E-8 signalait des expirations de délai intermittentes des clients via le commutateur central — les longs pings ne se perdaient jamais, les pings avec gros paquets non plus, seul le trafic applicatif réel était touché. Les journaux montraient une alarme de ratio de changement de débit sortant sur un port GigabitEthernet, associée à un journal « Packets are discarded for congestion » qui, sur cette version logicielle, se lisait exactement comme une congestion inter-cartes. Supprimer une grande pile de configuration de mirroring de port a atténué le symptôme sans le résoudre. display qos micro-burst statistics sur l'interface concernée montrait un trafic très loin du plafond de transfert réel de la plateforme — cela n'aurait donc pas dû être une congestion inter-cartes. Le mirroring de cette même interface a montré une capture en dents de scie avec une fenêtre d'une milliseconde atteignant environ 8 à 9 mégabits — soit environ 8Gb/s — sur un port à débit Gigabit ; une capture de paquets supplémentaire sur la même interface a surpris un hôte spécifique envoyant plusieurs paquets surdimensionnés dans cette même milliseconde. La leçon : sur cette plateforme et cette version, la congestion ordinaire au niveau du port est journalisée avec le même libellé que la congestion inter-cartes, ce qui oriente à tort le diagnostic vers « le plan de commutation ne peut pas transférer autant » alors que la cause réelle est un seul port subissant un pic instantané bien au-delà de sa propre bande passante. Jugez en combinant les signaux — utilisation de bande passante de l'interface, qos micro-burst statistics et capture par mirroring — jamais sur le seul libellé du journal.
Une fois qu'une rafale est confirmée, voici les erreurs d'interprétation qui poussent à chercher au mauvais endroit.
SYMPTOMLes rejets augmentent, mais l'appareil n'a jamais levé la moindre alarme sur l'utilisation du tampon — on suppose donc que les tampons vont bien et que le compteur de rejets mesure autre chose.
CAUSELa lecture de l'occupation du tampon nécessite un scrutin par le CPU, la même contrainte qui limite la fréquence d'échantillonnage de l'utilisation elle-même. Scruter assez agressivement pour saisir un événement à l'échelle de la milliseconde pousserait l'utilisation CPU assez haut pour ralentir tout l'appareil, donc le commutateur évite délibérément d'alarmer sur l'état du tampon à cette résolution.
FIXConsidérez les compteurs de rejets, la capture par mirroring et la fonction dédiée de détection de microrafale comme les substituts prévus à une alarme de tampon qui ne viendra jamais — ne l'attendez pas.
SYMPTOMLe graphique d'utilisation du port ne dépasse jamais 20 à 30 %, si bien qu'une hypothèse de perte de paquets liée à une rafale est écartée d'emblée.
CAUSEL'utilisation moyenne et le débit instantané de rafale ne sont pas la même mesure, tout comme la vitesse et l'accélération ne sont pas la même chose. Une carte réseau émet à son plein débit physique ou pas du tout — jamais à un débit fractionnaire — donc un port au repos à 20-30 % en moyenne peut très bien fonctionner à 100 % du débit de ligne pendant quelques millisecondes, puis rester inactif.
FIXNe jamais écarter une microrafale sur la seule utilisation moyenne — passez directement à une capture par mirroring à l'échelle de la milliseconde ou à la fonction de détection intégrée.
SYMPTOMC'est le commutateur qui journalise les rejets, donc c'est lui qu'on considère comme défaillant.
CAUSEHormis une petite quantité de trafic protocolaire, les commutateurs ne génèrent pas le trafic qui déborde leurs propres tampons — ce sont les hôtes finaux qui le font. Ce que le commutateur peut faire, c'est amplifier une rafale : plusieurs ports de même débit envoyant vers un seul, ou un taux de convergence défavorable, empilent les pics de plusieurs rafales au moment précis où ils entrent en collision sur le port sortant partagé.
FIXRecherchez la source du trafic et le taux de convergence dans la conception du réseau, pas seulement l'interface qui a par hasard journalisé la perte.
SYMPTOML'application est décrite comme ayant un trafic imprévisible et de faible intensité, si bien qu'une rafale sérieuse paraît peu plausible.
CAUSELa carte réseau d'un serveur émet à son plein débit physique de liaison dès qu'elle a quelque chose en file d'attente, puis reste inactive en attendant la couche applicative. Moyenné dans le temps, cela peut ressembler à 20-30 % d'utilisation, mais à l'échelle de la microseconde, c'est en réalité 100 % ou 0 %, jamais entre les deux — ce dont est précisément constituée une microrafale.
FIXNe prenez pas « l'application n'est pas si occupée » comme prétexte pour sauter une capture à l'échelle de la milliseconde — c'est précisément le motif de trafic le plus susceptible d'en produire une.
SYMPTOMUne capture par mirroring sur une interface chargée à plus de 10Gbps montre des pertes ou des résultats incohérents d'une exécution à l'autre, même si la configuration de la capture elle-même semble correcte.
CAUSEUne capture sur PC n'est fiable que jusqu'à environ 1Gbps de débit d'interface, et une capture sur serveur jusqu'à environ 10Gbps ; au-delà, l'outil de capture lui-même devient le goulot d'étranglement et commence à perdre ou déformer des paquets — exactement ce que vous essayez d'observer.
FIXAu-delà d'environ 10Gbps, ou pour toute fenêtre de surveillance soutenue, utilisez un appareil tiers dédié à la capture et à l'analyse plutôt qu'un PC ou serveur généraliste exécutant Wireshark.
Dans à peu près l'ordre où elles valent la peine d'être essayées — le moins coûteux et à moindre effet secondaire d'abord.
[HUAWEI-GigabitEthernet0/0/1] qos burst-mode enhanced
[HUAWEI] traffic classifier c_latency
[HUAWEI-classifier-c_latency] if-match dscp af41
[HUAWEI] traffic behavior b_latency
[HUAWEI-behavior-b_latency] remark local-precedence 6
[HUAWEI] traffic policy p_edge
[HUAWEI-trafficpolicy-p_edge] classifier c_latency behavior b_latency
[HUAWEI-GigabitEthernet0/0/2] traffic-policy p_edge inbound
[HUAWEI-GigabitEthernet0/0/1] qos queue 3 shaping cir 500 mbps pir 800 mbps
// shaping adds latency -- reach for it after the other options, not beforeTirées directement du terrain — celles pour lesquelles il vaut la peine d'avoir une réponse prête.
Non. Une congestion ordinaire et soutenue apparaît aussi sur le graphique de débit moyen — c'est exactement ce que la supervision de routine, y compris les vérifications de notre note sur le contrôle de santé des commutateurs de datacenter, est conçue pour détecter. Une microrafale est spécifiquement une rafale si courte — 1 à 100 millisecondes — qu'elle est invisible à la résolution normale de supervision tout en débordant quand même le tampon du port pendant cet instant.
Parce que la lecture de l'occupation du tampon nécessite un scrutin CPU, et scruter assez agressivement pour saisir un événement à l'échelle de la milliseconde pousserait l'utilisation CPU assez haut pour ralentir tout l'appareil. C'est exactement pourquoi les compteurs de rejets, la capture par mirroring et la fonction dédiée de détection de microrafale existent comme substituts à une alarme qui ne viendra pas.
Si vous avez seulement besoin de confirmer qu'une rafale s'est produite et à peu près quand, le buffer-monitoring de la surveillance de congestion est plus léger et pris en charge sur plus de modèles. Si vous avez besoin du débit et de la durée réels pour la planification de capacité, le mode renforcé de la détection de microrafale fournit de vrais chiffres par interface à une résolution de 1ms — au prix de ne fonctionner que sur une seule interface à la fois.
Oui, et c'est de loin l'erreur d'interprétation la plus courante des données. L'utilisation moyenne et le débit instantané de rafale ne sont pas la même mesure, pas plus que la vitesse et l'accélération ne sont la même chose. Un port au repos à 20-30 % en moyenne peut très bien fonctionner à 100 % du débit de ligne pendant quelques millisecondes, parce que c'est littéralement ainsi qu'une carte réseau émet — à plein débit physique ou pas du tout.
À peu près dans l'ordre où elles aident sans effets secondaires : ajoutez de la bande passante sortante sur le lien goulot d'étranglement ; évitez les schémas de trafic plusieurs-vers-un dans la conception ; activez qos burst-mode enhanced pour que les ports chargés puissent emprunter davantage au tampon dynamique partagé ; séparez le trafic sensible à la latence dans une file de priorité supérieure pour qu'il ne soit pas celui qui est rejeté ; et ne recourez au façonnage en sortie qu'en dernier, car il corrige la perte en ajoutant de la latence de transfert, ce qui est un compromis en soi.
Cette note s'appuie sur le modèle de tampon/QoS des commutateurs de campus et châssis Huawei série S — display interface, display qos queue statistics, qos buffer-monitoring, qos micro-burst detection — et le cas de terrain qui la sous-tend. Si votre plateforme est d'un autre fournisseur, les commandes exactes changent, mais le concept sous-jacent s'applique directement : la supervision au débit moyen manque par conception les rafales à la milliseconde, et les confirmer nécessite soit une capture par mirroring, soit une fonction de détection dédiée. Elle ne couvre pas en profondeur l'absorption des rafales dans les fabrics sans perte leaf-spine de datacenter (PFC, ECN) — c'est le sujet de la solution de stockage sans perte associée.
Dites-nous quelle interface, le compteur de rejets, et si vous avez déjà essayé une capture par mirroring, et nous vous aiderons à l'interpréter.