Dès qu'un routeur ou un switch Huawei commence à mal se comporter, ce que vous collectez dans les premières minutes détermine si l'étape suivante est une correction ou un second aller-retour. Voici l'ordre de collecte tiré directement du manuel de maintenance des routeurs AR de Huawei et du manuel des switchs Huawei : une commande qui capture presque tout, une liste de contrôle de base, une collecte correcte des journaux et des compteurs, et un aide-mémoire de ce qu'il faut exactement prélever une fois qu'un type de panne précis est suspecté.
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
L'objectif n'est pas plus de données — c'est la donnée précise qui permet à quelqu'un d'autre de localiser la panne sans un second appel.
Le manuel de maintenance des switchs de Huawei ouvre son chapitre diagnostics par une instruction sans détour : lorsque vous ne pouvez pas déterminer vous-même la cause, collectez les informations de panne pertinentes et transmettez-les au revendeur ou au support Huawei pour localisation. En pratique, cela signifie trois choses à chaque fois — l'heure et la topologie où la panne s'est produite, l'identité et l'état propres de l'appareil (nom, version, configuration actuelle, informations d'interface), et les journaux et alarmes générés au moment des faits.
Voici ce travail de collecte dans l'ordre : la commande qui capture presque tout en une seule passe, une liste de contrôle de base des commandes display à connaître par leur nom, comment collecter les journaux et réinitialiser les compteurs sans se mentir sur ce qui est réellement en cours, et un aide-mémoire de ce qu'il faut prélever une fois qu'une théorie de travail existe déjà sur le sous-système en cause — IPSec, OSPF, BGP, DHCP, un redémarrage inattendu, ou ARP.
Une commande, regroupant la sortie de dizaines d'autres — à exécuter avant toute action spécifique à la panne.
display diagnostic-information collecte en une seule passe la configuration de démarrage de l'appareil, la configuration actuelle, les informations d'interface, l'horloge, la version logicielle et plus encore — un lot regroupant en fait les commandes display que la plupart des gens penseraient de toute façon à exécuter une à une.
<HUAWEI> display diagnostic-information dia-info.txt
This operation will take several minutes, please wait.........................
................................................................................
...
Info: The diagnostic information was saved to the device successfully.Sur un routeur AR, la même commande peut écrire directement dans une archive .tar, et sur un châssis à deux cartes de contrôle principal, les informations de diagnostic du maître et du secondaire doivent être extraites séparément.
<Huawei> display diagnostic-information xxx.tar
<Huawei> diagnose
[Huawei-diagnose] local-telnet slave
<Huawei> display diagnostic-information xxx.tarÉvitez l'affichage direct au terminal et donnez-lui un nom de fichier — la sortie est longue, et un fichier enregistré est ce qu'un ingénieur support veut réellement joindre au ticket.
Les commandes display à connaître par leur nom, indépendamment de la nature finale de la panne.
| Information | Commande | Pourquoi c'est important |
|---|---|---|
| Informations de base | display diagnostic-information | Le lot en une passe ci-dessus — à fournir pour toute demande de support, quel que soit le type de panne. |
| Informations sur l'appareil | display device | Signale une carte en état Abnormal — la première chose à vérifier quand une carte précise est suspectée. |
| Informations d'interface | display interface | État physique, configuration et compteurs de paquets d'une interface — le premier arrêt classique pour les pannes d'interconnexion ou la perte de paquets. |
| Informations de version | display version | Versions logicielles, BootROM, carte de contrôle principal, carte d'interface et module ventilateur, plus les tailles mémoire — souvent la première chose qu'un ingénieur support demandera. |
| Informations de patch | display patch-information | Version et nom du paquet de patch actuel — important car le comportement peut différer sensiblement selon le niveau de patch. |
| Étiquette électronique | display elabel | Identité matérielle et informations de fabrication — nécessaires pour un RMA ou un retour matériel. |
| État de santé de l'appareil | display health | Température, alimentation, ventilateur, consommation, utilisation CPU/mémoire et stockage en une seule vue. |
| Configuration actuelle | display current-configuration | Ce que l'appareil exécute réellement en ce moment — prend en charge le filtrage par expression régulière pour affiner. |
| Configuration enregistrée | display saved-configuration | Ce que l'appareil chargera à son prochain démarrage — utile quand l'appareil a démarré mais ne se comporte pas comme configuré. |
| Horloge | display clock | Fixe précisément le moment où la panne s'est produite — essentiel pour corréler avec les journaux et alarmes. |
| Journal utilisateur | display logfile buffer | Exécuté depuis la vue diagnose ; affiche le journal utilisateur mis en tampon. |
| Journal de diagnostic | display diag-logfile buffer | Également depuis la vue diagnose ; le journal de diagnostic de plus bas niveau, distinct du journal utilisateur. |
| Informations d'alarme | display trapbuffer | Le tampon Trap du centre d'information — le moyen le plus rapide de voir quelles alarmes se sont réellement déclenchées. |
| Utilisation de la mémoire | display memory-usage | Ajoutez slot slot-id pour la mémoire d'une carte d'interface ; omettez-le pour celle de la carte de contrôle principal. |
| Utilisation du CPU | display cpu-usage | Même logique de slot que l'utilisation mémoire — carte de contrôle principal par défaut, carte d'interface avec slot slot-id. |
Un journal qu'on a oublié d'enregistrer et un compteur qu'on a oublié de réinitialiser racontent tous deux la mauvaise histoire.
Extraire les fichiers journaux réels
save logfile et save diag-logfile écrivent le contenu du journal mis en tampon dans des fichiers sous flash:/logfile/, qui peuvent ensuite être récupérés de l'appareil via FTP/TFTP.
<HUAWEI> save logfile
<HUAWEI> system-view
[HUAWEI] diagnose
[HUAWEI-diagnose] save diag-logfileRéinitialiser les compteurs avant de leur faire confiance
display interface et display ip interface affichent des statistiques accumulées depuis le démarrage de l'appareil ou depuis la dernière réinitialisation des compteurs — pas depuis le début du problème. Réinitialisez-les d'abord, générez du trafic frais, puis relisez.
Input: 736 packets, 344842 bytes
Unicast: 0, Multicast: 714
Broadcast: 22, Jumbo: 0
Discard: 0, Total Error: 0
Output: 2911 packets, 514228 bytes
Unicast: 0, Multicast: 2910
Broadcast: 1, Jumbo: 0
Discard: 0, Total Error: 0Un Total Error non nul ici indique seulement que quelque chose s'est produit à un moment donné depuis la dernière réinitialisation — réinitialisez le compteur, retestez et relisez avant de le traiter comme un problème en direct.
Une fois qu'une théorie de travail existe déjà sur le sous-système en cause, ceci permet d'affiner rapidement.
| Catégorie de panne | Commandes à exécuter | Ce que vous recherchez |
|---|---|---|
| IPSec | display ike error-info verbose [ peer remote-address ] display ike proposal number display ipsec sa display ike peer name peer-name display ipsec statistics display ipsec global config debugging ikev1 all / debugging ikev2 all / debugging ipsec all | display ike error-info verbose donne directement la véritable raison d'échec de la négociation IKE, au lieu de vous forcer à la déduire d'un simple état « down ». |
| OSPF | display ospf routing ipv4-address verbose display ospf peer verbose debugging ospf event debugging ospf packet hello | display ospf peer verbose montre un détail d'état par voisin bien au-delà d'un simple up/down. |
| BGP | display bgp peer ipv4-address log-info display bgp routing-table ipv4-address debugging bgp [ peer ipv4-address ] all | display bgp peer log-info fait remonter directement le code d'erreur Down du voisin — la lecture la plus rapide pour savoir pourquoi une session a oscillé. |
| L2TP / PPP | display l2tp session-down-reason display l2tp tunnel-down-reason display ppp state all debugging l2tp all / debugging ppp all | Les deux commandes down-reason existent précisément parce qu'un tunnel ou une session L2TP ne se contente pas de signaler « down » — elle en enregistre la raison. |
| DHCP | display dhcp configuration display dhcp client / display dhcp client statistics display dhcp relay configuration / statistics display dhcp server configuration / statistics display ip pool interface interface-type interface-number debugging dhcp client / relay / server all | Le DHCP a trois rôles distincts — client, relais, serveur — et les commandes de collecte sont spécifiques au rôle ; extraire les statistiques de relais d'un appareil agissant comme serveur ne montrera rien d'utile. |
| Redémarrage inattendu | display reset-reason display inspect black-box record 6/8/10/11/12/13 0 0 0 display lastwords all display kernel-logbuf last | Toutes ces commandes sont conçues pour survivre au redémarrage lui-même, spécifiquement pour répondre après coup à « pourquoi a-t-il redémarré ». |
| ARP | display arp history debugging arp packet | display arp history montre comment une entrée a réellement changé dans le temps, pas seulement son instantané actuel. |
Le même manuel couvre d'autres catégories selon le même format — SNMP, BFD, voix, pannes de modem 3G/LTE/5G et NQA entre autres — suivant le même schéma : une commande display pour l'état, une commande debugging pour la trace en direct.
Les commandes de collecte elles-mêmes ont des angles coupants — voici celles qui prennent les ingénieurs au dépourvu.
SYMPTÔMEL'utilisation du CPU grimpe justement au moment où display diagnostic-information est exécuté sur un appareil déjà en charge ou en pleine panne.
CAUSELa commande regroupe de nombreuses commandes display et est explicitement documentée comme pouvant augmenter l'utilisation du CPU pendant son exécution — l'exécuter depuis plusieurs sessions terminal sur le même appareil à la fois peut pousser le CPU encore plus haut.
CORRECTIFNe l'exécutez pas de manière redondante depuis plusieurs sessions à la fois, et n'en faites pas une routine d'entretien sur un appareil sain — réservez-la au moment où l'information est réellement nécessaire pour une transmission.
<HUAWEI> display diagnostic-information dia-info.txtSYMPTÔMEUne commande debugging xxx est saisie et rien ne s'affiche à l'écran — ou, problème inverse, le debugging reste actif longtemps après l'incident et commence à concurrencer tout le reste pour le CPU.
CAUSELes informations debugging ne s'affichent pas dans une session terminal à moins que terminal debugging et terminal monitor soient tous deux explicitement activés, avec debug timeout 0 réglé pour éviter une expiration inattendue en cours de collecte — et cela reste actif jusqu'à ce que quelqu'un le désactive explicitement.
CORRECTIFExécutez le préambule de trois lignes avant toute commande debugging, collectez pendant une fenêtre limitée, puis annulez explicitement les deux réglages ensuite.
terminal debugging
terminal monitor
debug timeout 0
...
undo terminal debugging
undo terminal monitorSYMPTÔMEdisplay interface montre Total Error supérieur à zéro, et il est tentant de conclure que le port est activement en panne en ce moment.
CAUSECes compteurs s'accumulent depuis le démarrage de l'appareil, ou depuis leur dernière réinitialisation manuelle — un Total Error non nul peut être un reliquat de quelque chose survenu il y a des jours ou des semaines, pas ce qui se passe maintenant.
CORRECTIFRéinitialisez les compteurs, générez du trafic frais avec ping, puis relisez la même commande display — seul le delta pendant cette fenêtre indique si le problème est en direct.
reset counters interface ethernet 1/0/0
ping ...
display interface ethernet 1/0/0SYMPTÔMEMettre en miroir le trafic d'un port vers Wireshark sur un ordinateur portable pour traquer une panne au niveau paquet ressemble à une étape purement technique.
CAUSELa documentation du fournisseur lui-même signale que cette fonctionnalité peut impliquer la capture ou le stockage du contenu de communications réelles de quelqu'un, et indique qu'elle ne devrait être activée que dans la mesure où la loi locale le permet réellement — pas quelque chose à utiliser automatiquement.
CORRECTIFConfirmez le périmètre et l'autorisation avant de configurer un port d'observation et d'y mettre en miroir du trafic en direct, surtout avant de pointer un outil de capture sur le flux en miroir.
[Router] observe-port interface ethernet 5/0/0
[Router] interface gigabitethernet 0/0/0
[Router-GigabitEthernet0/0/0] mirror to observe-port inboundSYMPTÔMEUn châssis à deux cartes de contrôle principal bascule ou se comporte mal, et les informations de diagnostic collectées ne racontent que la moitié de l'histoire.
CAUSEdisplay diagnostic-information exécuté sur la carte de contrôle principal active ne capture que l'état de cette carte — la carte de secours conserve son propre état et doit être atteinte séparément pour extraire son propre fichier de diagnostic.
CORRECTIFDepuis la vue diagnose, utilisez local-telnet slave pour atteindre la carte de secours et exécutez-y aussi display diagnostic-information, afin que les informations des deux cartes parviennent à la personne qui dépanne.
<Huawei> diagnose
[Huawei-diagnose] local-telnet slave
<Huawei> display diagnostic-information xxx.tarDans l'ordre — de « quelque chose ne va pas » à « joint au ticket ».
Les légendes du schéma restent en anglais pour la clarté technique.
Les questions qui viennent en premier une fois qu'on ouvre réellement un ticket de support.
Commencez par display diagnostic-information (ou la forme dia-info.txt du switch) plus display clock pour un horodatage exact, et notez la topologie, ce qui a déclenché la panne, et ce qui échoue réellement — avant de toucher à toute commande spécifique à la panne.
Non — le debugging est invasif et doit rester limité à une catégorie déjà suspectée, par exemple debugging ospf packet hello seulement une fois qu'OSPF est la théorie de travail, enveloppé dans terminal debugging / terminal monitor / debug timeout 0, exécuté pendant une fenêtre limitée, puis explicitement désactivé.
save logfile, exécuté depuis la vue utilisateur, enregistre le journal opérationnel destiné à l'utilisateur ; save diag-logfile, exécuté depuis la vue diagnose, enregistre le journal de diagnostic de plus bas niveau. Les ingénieurs support peuvent demander l'un ou l'autre selon ce qu'ils recherchent, et parfois les deux.
Oui — display reset-reason, les diverses variantes de display inspect black-box record, display lastwords all et display kernel-logbuf last sont toutes conçues spécifiquement pour survivre au redémarrage et répondre après coup à « pourquoi a-t-il redémarré ».
Les deux. La liste de contrôle de base — capture en une passe plus informations sur l'appareil, la version, l'interface, la configuration et les journaux — s'applique à presque tout et mérite d'être collectée en premier quelle que soit la panne. Le tableau par catégorie de panne affine ensuite dès qu'une théorie de travail existe déjà : IPSec, OSPF, BGP, DHCP, un redémarrage inattendu, ou ARP.
Ceci est un guide de collecte, pas un guide de cause racine. Il s'appuie sur l'annexe du manuel de maintenance des routeurs AR consacrée à la collecte d'informations et aux commandes de diagnostic, recoupée avec le chapitre équivalent du manuel de maintenance des switchs Huawei. Une fois qu'un type de panne précis est déjà confirmé — un tunnel IPSec ou un voisin OSPF qui ne monte pas, par exemple — l'analyse approfondie de cause racine pour ce type de panne fait l'objet d'une note séparée, pas celle-ci.
Envoyez-nous le fichier diagnostic-information et toute sortie par catégorie de panne que vous avez extraite — nous vous aiderons à la lire.