Dès que vous savez déjà quel sous-système vérifier sur un switch leaf ou spine CloudEngine, voici la commande à utiliser — regroupée comme un ingénieur y pense réellement : matériel, interface et perte de paquets, entrées de table MAC/ARP, protocole (OSPF, BGP, VXLAN, M-LAG), et trafic (miroir, QoS). Chaque commande ici provient directement du chapitre des commandes de diagnostic du manuel de maintenance CloudEngine 16800/9800/8800/6800.
By Yuwen Zhang (Atlas), founder of AtlasCommTech — 13 years of carrier & enterprise network deployments · Updated July 2026
L'un vous dit quoi collecter avant d'escalader. Celui-ci est le dictionnaire que vous consultez pendant que vous cherchez encore par vous-même.
Notre Liste de collecte des informations de panne couvre l'ordre de collecte à suivre dès qu'un problème survient — la capture en une passe, une liste de contrôle de base, la gestion des journaux, et un aide-mémoire organisé par type de panne (IPSec, OSPF, BGP, DHCP, redémarrage, ARP), indépendant de la plateforme pour les routeurs et switchs Huawei. Cette note est plus étroite et plus spécifique : c'est le propre chapitre du manuel de maintenance de la série CloudEngine 16800/9800/8800/6800 sur la collecte d'informations courante et les commandes de diagnostic, réorganisé selon les cinq groupes de scénarios auxquels pense réellement un ingénieur de datacenter.
Ces cinq groupes sont le matériel (cartes, alimentation, ventilateurs, optiques), l'interface et la perte de paquets (état du lien, compteurs, pertes CPU-defend), les entrées de table (MAC et ARP), le protocole (OSPF, BGP, tunnels VXLAN, état du pair M-LAG), et le trafic (miroir d'un port pour une capture, ou vérifier si une politique de trafic a réellement matché quelque chose). Associez le symptôme à un groupe, et la bonne commande se trouve généralement parmi deux ou trois.
Le même lot de base s'applique ici comme ailleurs — récupérez-le d'abord, puis cherchez la commande spécifique au scénario.
display diagnostic-information collecte en une seule passe les cartes de l'appareil, la configuration actuelle, les informations d'interface, l'horloge, la version logicielle et plus encore. Donnez-lui un nom de fichier pour que la sortie atterrisse sur la flash plutôt que de défiler sur le terminal.
<HUAWEI> display diagnostic-information dia-info.txt
100%
Info: The diagnostic information was saved to the device successfully.À partir de V300R022C10, il existe une alternative plus légère lorsque seuls les journaux, les données KPI et les fichiers PADS sont réellement nécessaires plutôt que le lot display complet : collect diagnostic information, exécuté depuis la vue utilisateur ou la vue diagnose, qui compresse directement le répertoire de journaux actuel en diagnostic_information.zip sous flash.
<HUAWEI> collect diagnostic informationCette commande est documentée comme pouvant augmenter l'utilisation du CPU pendant son exécution — évitez-la sur une console série, évitez de l'exécuter depuis plusieurs sessions de terminal à la fois, et n'en faites pas un entretien de routine sur un appareil sain.
Associez le symptôme, puis exécutez deux ou trois commandes — pas tout le manuel.
Matériel
| Commande | Ce que cela révèle |
|---|---|
| display device | État par carte — une carte signalant Abnormal est la première chose à confirmer. |
| display device alarm hardware | Alarmes d'alimentation, de ventilateur et de température réellement déclenchées sur l'appareil. |
| display device power system | Consommation électrique par rapport à la capacité d'alimentation — la vérification avant d'insérer une autre carte ou optique. |
| display device elabel | Identité matérielle et informations de fabrication, nécessaires pour un RMA. |
| display device board reset slot-id | À exécuter depuis la vue diagnose — la raison enregistrée pour laquelle une carte précise s'est réellement réinitialisée. |
Interface et perte de paquets
| Commande | Ce que cela révèle |
|---|---|
| display interface | État physique, configuration et compteurs de paquets — le premier arrêt classique pour un lien suspect. |
| display interface transceiver verbose | Puissance optique d'émission/réception, pour un lien qui est up mais peu fiable. |
| reset counters interface / ping / display interface | Réinitialiser, générer du trafic, relire — la seule façon pour que les compteurs reflètent cette fenêtre, pas les dernières semaines. |
| display cpu-defend statistics packet-type packet-type | Paquets réellement limités en débit ou abandonnés par la protection du plan CPU — une cause de perte de paquets que display interface seul ne révèle pas. |
Entrées de table — MAC et ARP
| Commande | Ce que cela révèle |
|---|---|
| display mac-address | Mappage MAC-VLAN-port — le premier arrêt quand le trafic est transféré au mauvais endroit. |
| display mac-address flapping | L'enregistrement en direct d'une adresse MAC se déplaçant entre ports ou VLAN, avec un compteur MoveNum. |
| display mac-address flapping aged-table | Enregistrements de flapping déjà expirés de la table en direct ci-dessus — voir le piège 2 pour comprendre pourquoi c'est important. |
| display arp | Type et état de l'entrée ARP pour une IP donnée — confirme si la table de la passerelle elle-même est le problème. |
| display arp statistics | Compteurs de la table ARP, pour une vue plus large du renouvellement de la table. |
Protocole — OSPF, BGP, VXLAN, M-LAG
| Commande | Ce que cela révèle |
|---|---|
| display ospf peer verbose | Détail de l'état par voisin, bien au-delà d'un simple up/down. |
| display bgp peer ipv4-address log-info | Le code d'erreur Down du voisin directement — la lecture la plus rapide sur la raison d'un flapping de session. |
| display vxlan troubleshooting | Une vérification automatisée en un clic par rapport à une bibliothèque de signatures de pannes VXLAN connues — voir le piège 3 pour ses limites. |
| display vxlan tunnel | État réel du tunnel et du pair VTEP pour l'overlay. |
| display dfs-group / display dfs-group consistency-check global | État du pair M-LAG, et une vérification conçue spécifiquement pour la dérive de configuration entre les deux appareils pairs. |
| display dfs black-box module | Un instantané d'état par module (arp, bridge-domain, adjacency et plus) — à exécuter sur les deux pairs M-LAG, voir le piège 4. |
[~Device1] display vxlan troubleshooting
[~Device1] display vxlan tunnel
<HUAWEI> display dfs-group
<HUAWEI> display dfs-group 1 consistency-check global
[~HUAWEI-diagnose] display dfs black-box arp
[~HUAWEI-diagnose] display dfs black-box bridge-domainTrafic — Miroir et QoS
| Commande | Ce que cela révèle |
|---|---|
| display port-mirroring | Confirme que l'appairage observe-port et mirror-port correspond réellement à ce qui a été configuré. |
| display interface brief (Input on the mirror port, Output on the observe port) | Confirme que le trafic miroir arrive réellement au port d'observation avant de blâmer l'outil de capture. |
| observe-port / mirroring / port-mirroring observe-port | Les commandes de configuration elles-mêmes — voir le piège 5 sur la limite de confidentialité avant de les activer. |
| display traffic-policy statistics interface interface inbound/outbound | Si une politique de trafic correspond réellement, et ce qu'elle fait aux paquets qui la touchent. |
[~HUAWEI] observe-port 1 interface 25GE1/0/1
[*HUAWEI-25GE1/0/2] port-mirroring observe-port 1 inbound
<HUAWEI> display port-mirroring
[~HUAWEI] display traffic-policy statistics interface 100GE 1/0/1 inboundCela s'applique à chaque groupe ci-dessus qui touche un compteur — cela vaut la peine de bien le faire une fois, pas par scénario.
display interface et display ip interface signalent 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. Sur un tissu spine-leaf avec des ports up depuis des mois, cet historique accumulé gêne la lecture de ce qui se passe en ce moment.
reset counters interface 100GE 1/0/1
ping -c 20 10.0.0.2
display interface 100GE 1/0/1Un Total Error non nul après cette séquence mérite d'être investigué. Avant la réinitialisation, il prouve seulement que quelque chose s'est produit à un moment donné depuis la dernière réinitialisation.
Les commandes ci-dessus ont leurs propres aspérités — voici celles qui prennent les ingénieurs de datacenter au dépourvu.
SYMPTÔMEdisplay diagnostic-information bloque une session de console série pendant longtemps, ou l'utilisation du CPU grimpe sensiblement quand elle est exécutée depuis deux terminaux à la fois.
CAUSELa commande est explicitement documentée comme augmentant l'utilisation du CPU pendant son exécution, et une connexion série est assez lente pour qu'un long vidage de diagnostic bloque toute la session — l'exécuter en redondance depuis plusieurs sessions aggrave les deux problèmes.
CORRECTIFUtilisez Telnet ou STelnet plutôt qu'une console série pour cette commande précise, ne l'exécutez jamais depuis deux sessions à la fois, et à partir de V300R022C10, utilisez plutôt collect diagnostic information lorsque seuls les journaux sont réellement nécessaires.
<HUAWEI> display diagnostic-information dia-info.txtSYMPTÔMEdisplay mac-address flapping continue de signaler la même valeur MoveNum quelle que soit la durée du flapping sous-jacent, donnant l'impression que les déplacements se sont arrêtés.
CAUSEMoveNum est un compteur borné qui plafonne à 65535 — une fois saturé, il cesse simplement de s'incrémenter, même si l'adresse MAC continue de se déplacer entre ports ou VLAN en arrière-plan.
CORRECTIFNe prenez pas un MoveNum statique comme preuve que le flapping s'est arrêté — vérifiez display mac-address flapping aged-table pour l'historique, et confirmez le comportement actuel avec les alarmes trapbuffer plutôt qu'avec le seul compteur en direct.
<HUAWEI> display mac-address flapping
<HUAWEI> display mac-address flapping aged-tableSYMPTÔMEdisplay vxlan troubleshooting revient propre, mais les locataires ne peuvent toujours pas se joindre à travers le fabric.
CAUSELa commande fait correspondre automatiquement une Event Description à une bibliothèque définie de signatures de pannes VXLAN connues — une panne réellement nouvelle, ou une panne se trouvant dans un sous-système adjacent tel que le mappage bridge-domain, l'IGP sous-jacent, ou l'état du peer-link M-LAG, échappe à ce qu'elle est conçue pour détecter.
CORRECTIFConsidérez un résultat propre comme un point de donnée, pas un feu vert — associez-le à display vxlan tunnel pour l'état réel du tunnel et du VTEP, et à display mac-address bridge-domain pour le bridge-domain concerné.
[~Device1] display vxlan troubleshooting
[~Device1] display vxlan tunnelSYMPTÔMEdisplay dfs black-box arp, ou toute autre variante de module black-box, semble correct sur l'appareil examiné, pourtant la paire M-LAG continue de se comporter comme si les deux appareils étaient en désaccord sur quelque chose.
CAUSEChaque commande display dfs black-box module ne capture que l'appareil sur lequel elle est exécutée — une paire M-LAG est deux appareils indépendants synchronisant leur état via un peer-link, et un écart n'apparaît qu'en comparant les deux côtés.
CORRECTIFRécupérez la même sortie black-box sur les deux appareils pairs, ou commencez par display dfs-group consistency-check global, qui existe spécifiquement pour détecter la dérive de configuration entre les deux avant de conclure que l'état est réellement cohérent.
[~HUAWEI-diagnose] display dfs black-box arp
<HUAWEI> display dfs-group 1 consistency-check globalSYMPTÔMEConfigurer observe-port et pointer un outil de capture dessus pour traquer une panne au niveau paquet entre leaf et spine semble être une étape purement technique.
CAUSELa documentation du fournisseur signale elle-même que le miroir peut impliquer la capture ou le stockage du contenu de communications réelles de quelqu'un, et indique qu'il ne doit être activé que dans la mesure où la loi locale le permet réellement — le fait que le port se trouve dans un fabric de datacenter plutôt qu'un réseau de campus ne change pas cette limite.
CORRECTIFConfirmez la portée et l'autorisation avant de configurer un observe-port et d'y miroiter du trafic en direct, surtout avant de pointer un outil de capture sur le flux miroité.
[~HUAWEI] observe-port 1 interface 25GE1/0/1
[*HUAWEI-25GE1/0/2] port-mirroring observe-port 1 inboundAssociez le symptôme à gauche au groupe à droite.
Les légendes du schéma restent en anglais pour la clarté technique.
Les questions qui reviennent en premier une fois que quelqu'un ouvre réellement le dictionnaire de commandes.
Cette note couvre l'ordre de collecte à suivre avant d'escalader une panne au support — capture en une passe, liste de contrôle de base, gestion des journaux, et aide-mémoire par type de panne, indépendant de la plateforme pour les routeurs et switchs Huawei. Celle-ci est le dictionnaire de commandes du quotidien spécifiquement pour les switchs de datacenter CloudEngine, organisé selon les cinq groupes de scénarios que vous consultez une fois que vous avez déjà une théorie de travail.
Commencez par display diagnostic-information (ou collect diagnostic information à partir de V300R022C10) pour l'instantané de base, puis associez le symptôme : un problème de carte, d'alimentation ou de ventilateur est Matériel ; un lien up mais qui perd des paquets est Interface et Perte de Paquets ; un trafic acheminé au mauvais endroit est Entrées de Table ; une session de routage ou d'overlay qui ne se forme pas est Protocole ; tout ce qui implique une capture ou un compteur de correspondance de politique de trafic est Trafic.
display mac-address flapping montre l'enregistrement de flapping en direct et son compteur MoveNum ; la variante aged-table montre les entrées déjà expirées de cette table en direct. C'est important car MoveNum plafonne à 65535 et cesse de s'incrémenter une fois saturé, donc l'historique expiré peut montrer un flapping que la vue en direct ne reflète plus.
Non — c'est une correspondance de motifs automatisée par rapport à des signatures de pannes VXLAN connues, pas un diagnostic complet. Associez un résultat propre à display vxlan tunnel pour l'état réel du tunnel et du VTEP, et à display mac-address bridge-domain pour un locataire précis.
Les deux. Chaque commande display dfs black-box module ne rapporte que l'appareil sur lequel elle est exécutée, donc un écart entre la paire ne devient visible qu'en comparant les deux côtés — ou en exécutant display dfs-group consistency-check global, conçu spécifiquement pour révéler ce type de dérive en une seule commande.
Oui — display diagnostic-information file-name est le même lot en une passe quelle que soit la plateforme, et à partir de V300R022C10, collect diagnostic information ajoute une option plus légère qui compresse uniquement les fichiers de journaux, KPI et PADS en diagnostic_information.zip sans le lot display complet.
Ceci est un dictionnaire de commandes, pas un guide de cause racine. Il s'appuie sur le propre chapitre du manuel de maintenance CloudEngine 16800/9800/8800/6800 consacré à la collecte d'informations courante et aux commandes de diagnostic, recoupé avec les chapitres de traitement des pannes matériel, MAC, ARP, VXLAN et M-LAG du même manuel. Pour l'ordre de collecte à suivre avant d'escalader toute panne, voir la Liste de collecte des informations de panne. Une fois qu'un type de panne précis est déjà confirmé — un port physiquement down, ou une utilisation CPU bloquée haute — l'analyse approfondie de cause racine fait l'objet d'une note séparée, pas celle-ci.
Envoyez-nous la sortie et le groupe dont elle provient — matériel, interface, entrées de table, protocole ou trafic — et nous vous aiderons à la lire.