No momento em que um roteador ou switch Huawei começa a apresentar problemas, o que você coleta nos primeiros minutos decide se o próximo passo é uma correção ou uma segunda rodada. Esta é a ordem de coleta tirada diretamente do próprio manual de manutenção de roteadores AR da Huawei e do manual de switches Huawei: um comando que captura quase tudo, uma checklist básica, coleta correta de logs e contadores, e uma folha de referência do que exatamente coletar assim que já se suspeita de um tipo de falha específico.
Por Yuwen Zhang (Atlas), fundador da AtlasCommTech — 13 anos de implantações de redes de operadoras e empresariais · Atualizado em julho de 2026
O objetivo não é mais dados — é o dado específico que permite que outra pessoa localize a falha sem uma segunda ligação.
O próprio manual de manutenção de switches da Huawei abre seu capítulo de diagnóstico com uma instrução direta: quando você não conseguir determinar a causa sozinho, colete as informações de falha pertinentes e as entregue ao revendedor ou ao suporte da Huawei para localização. Na prática, isso significa três coisas sempre — o horário e a topologia em que a falha ocorreu, a identidade e o estado do próprio equipamento (nome, versão, configuração atual, informações de interface), e quaisquer logs e alarmes gerados no momento.
A seguir está esse trabalho de coleta em ordem: o comando que captura quase tudo em uma única passada, uma checklist básica dos comandos display que vale a pena conhecer pelo nome, como coletar logs e resetar contadores sem se enganar sobre o que está realmente ativo, e uma folha de referência do que coletar assim que já existe uma teoria de trabalho sobre qual subsistema está com falha — IPSec, OSPF, BGP, DHCP, um reinício inesperado, ou ARP.
Um comando, agrupando a saída de dezenas de outros — vale a pena executá-lo antes de qualquer ação específica da falha.
display diagnostic-information coleta em uma única passada a configuração de inicialização do equipamento, a configuração atual, as informações de interface, o relógio, a versão de software e mais — na prática, uma execução em lote dos comandos display que a maioria pensaria em executar um por um de qualquer forma.
<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.Em um roteador AR, o mesmo comando pode gravar diretamente em um arquivo .tar, e em um chassi com duas placas de controle principal, as informações de diagnóstico da ativa e da em espera precisam ser coletadas separadamente.
<Huawei> display diagnostic-information xxx.tar
<Huawei> diagnose
[Huawei-diagnose] local-telnet slave
<Huawei> display diagnostic-information xxx.tarEvite a exibição direta no terminal e dê um nome de arquivo — a saída é longa, e um arquivo salvo é o que um engenheiro de suporte realmente quer anexar ao chamado.
Os comandos display que vale a pena conhecer pelo nome, independentemente de qual acabe sendo a falha.
| Informação | Comando | Por que importa |
|---|---|---|
| Informações básicas | display diagnostic-information | O pacote de uma única passada acima — forneça isso em qualquer solicitação de suporte, independentemente do tipo de falha. |
| Informações do equipamento | display device | Sinaliza uma placa em status Abnormal — a primeira coisa a verificar quando uma placa específica é suspeita. |
| Informações de interface | display interface | Estado físico, configuração e contadores de pacotes de uma interface — a primeira parada padrão para falhas de interconexão ou perda de pacotes. |
| Informações de versão | display version | Versões de software, BootROM, placa de controle principal, placa de interface e módulo de ventilador, além dos tamanhos de memória — geralmente a primeira coisa que um engenheiro de suporte vai pedir. |
| Informações de patch | display patch-information | Versão e nome do pacote de patch atual — importa porque o comportamento pode diferir bastante entre níveis de patch. |
| Etiqueta eletrônica | display elabel | Identidade do hardware e informações de fabricação — necessárias para um RMA ou devolução de hardware. |
| Saúde do equipamento | display health | Temperatura, energia, ventoinha, consumo, uso de CPU/memória e armazenamento em uma única visão. |
| Configuração atual | display current-configuration | O que o equipamento realmente está executando agora — suporta filtragem por expressão regular para restringir. |
| Configuração salva | display saved-configuration | O que o equipamento vai carregar na próxima inicialização — útil quando o equipamento subiu mas não se comporta conforme configurado. |
| Relógio | display clock | Determina exatamente quando a falha aconteceu — essencial para correlacionar com logs e alarmes. |
| Log de usuário | display logfile buffer | Executado a partir da view diagnose; mostra o log de usuário em buffer. |
| Log de diagnóstico | display diag-logfile buffer | Também a partir da view diagnose; o log de diagnóstico de nível mais baixo, distinto do log de usuário. |
| Informações de alarme | display trapbuffer | O buffer Trap da central de informações — a forma mais rápida de ver quais alarmes realmente dispararam. |
| Uso de memória | display memory-usage | Adicione slot slot-id para a memória de uma placa de interface; omita para a da placa de controle principal. |
| Uso de CPU | display cpu-usage | Mesma lógica de slot do uso de memória — controle principal por padrão, placa de interface com slot slot-id. |
Um log que você esqueceu de salvar e um contador que você esqueceu de zerar contam a história errada.
Extraindo os arquivos de log reais
save logfile e save diag-logfile gravam o conteúdo do log em buffer em arquivos sob flash:/logfile/, que depois podem ser retirados do equipamento via FTP/TFTP.
<HUAWEI> save logfile
<HUAWEI> system-view
[HUAWEI] diagnose
[HUAWEI-diagnose] save diag-logfileResetando contadores antes de confiar neles
display interface e display ip interface mostram estatísticas acumuladas desde que o equipamento ligou ou desde a última vez que os contadores foram zerados — não desde que o problema começou. Zere-os primeiro, gere tráfego novo e leia novamente.
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: 0Um Total Error diferente de zero aqui só indica que algo aconteceu em algum momento desde o último reset — zere o contador, teste novamente e leia novamente antes de tratar isso como um problema ao vivo.
Assim que já existe uma teoria de trabalho sobre qual subsistema está com falha, isso ajuda a restringir rapidamente.
| Categoria de falha | Comandos a executar | O que você está procurando |
|---|---|---|
| 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 dá diretamente o motivo real da falha de negociação IKE, em vez de fazer você deduzir isso de um simples estado "down". |
| OSPF | display ospf routing ipv4-address verbose display ospf peer verbose debugging ospf event debugging ospf packet hello | display ospf peer verbose mostra detalhes de estado por vizinho muito além de um simples 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 exibe diretamente o código de erro Down do vizinho — a leitura mais rápida sobre por que uma sessão oscilou. |
| L2TP / PPP | display l2tp session-down-reason display l2tp tunnel-down-reason display ppp state all debugging l2tp all / debugging ppp all | Os dois comandos down-reason existem precisamente porque um túnel ou sessão L2TP não apenas reporta "down" — ele registra o motivo. |
| 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 | O DHCP tem três papéis distintos — cliente, relay, servidor — e os comandos de coleta são específicos de cada papel; extrair estatísticas de relay de um equipamento que atua como servidor não mostrará nada útil. |
| Reinício inesperado | display reset-reason display inspect black-box record 6/8/10/11/12/13 0 0 0 display lastwords all display kernel-logbuf last | Todos esses comandos são feitos para sobreviver ao próprio reinício, especificamente para responder depois "por que reiniciou". |
| ARP | display arp history debugging arp packet | display arp history mostra como uma entrada realmente mudou ao longo do tempo, não apenas seu instantâneo atual. |
O mesmo manual cobre outras categorias no mesmo formato — SNMP, BFD, voz, falhas de modem 3G/LTE/5G e NQA entre elas — seguindo o mesmo padrão: um comando display para o estado, um comando debugging para o rastreio ao vivo.
Os próprios comandos de coleta têm arestas — estas são as que pegam os engenheiros de surpresa.
SINTOMAO uso de CPU dispara exatamente quando display diagnostic-information é executado em um equipamento que já está sob carga ou no meio de um incidente.
CAUSAO comando agrupa muitos comandos display juntos e é explicitamente documentado como algo que pode aumentar o uso de CPU enquanto executa — executá-lo a partir de várias sessões de terminal no mesmo equipamento ao mesmo tempo pode elevar ainda mais o CPU.
CORREÇÃONão execute isso de forma redundante em várias sessões ao mesmo tempo, e não faça disso uma manutenção de rotina em um equipamento saudável — reserve para quando a informação for realmente necessária para um repasse.
<HUAWEI> display diagnostic-information dia-info.txtSINTOMAUm comando debugging xxx é digitado e nada aparece na tela — ou, o problema oposto, o debugging fica rodando bem depois do incidente e começa a competir por CPU com tudo o mais.
CAUSAAs informações de debugging não são impressas em uma sessão de terminal a menos que terminal debugging e terminal monitor estejam ambos explicitamente ativados, com debug timeout 0 definido para não expirar inesperadamente no meio da coleta — e permanece ativo até alguém desativá-lo explicitamente.
CORREÇÃOExecute o preâmbulo de três linhas antes de qualquer comando debugging, colete durante uma janela limitada, e depois desfaça explicitamente ambas as configurações.
terminal debugging
terminal monitor
debug timeout 0
...
undo terminal debugging
undo terminal monitorSINTOMAdisplay interface mostra Total Error maior que zero, e é tentador concluir que a porta está com defeito ativo agora.
CAUSAEsses contadores se acumulam desde a inicialização do equipamento, ou desde a última vez que foram zerados manualmente — um Total Error diferente de zero pode ser resíduo de algo que aconteceu dias ou semanas atrás, não o que está acontecendo agora.
CORREÇÃOZere os contadores, gere tráfego novo com ping, e leia novamente o mesmo comando display — só o delta durante essa janela indica se o problema está ao vivo.
reset counters interface ethernet 1/0/0
ping ...
display interface ethernet 1/0/0SINTOMAEspelhar o tráfego de uma porta para o Wireshark em um notebook para caçar uma falha em nível de pacote parece uma etapa puramente técnica.
CAUSAA própria documentação do fabricante sinaliza que esse recurso pode envolver a captura ou o armazenamento do conteúdo de comunicações reais de alguém, e afirma que só deve ser habilitado dentro do escopo que a lei local realmente permite — não algo para usar automaticamente.
CORREÇÃOConfirme o escopo e a autorização antes de configurar uma porta de observação e espelhar tráfego ao vivo para ela, especialmente antes de apontar uma ferramenta de captura para o fluxo espelhado.
[Router] observe-port interface ethernet 5/0/0
[Router] interface gigabitethernet 0/0/0
[Router-GigabitEthernet0/0/0] mirror to observe-port inboundSINTOMAUm chassi com duas placas de controle principal faz failover ou se comporta mal, e as informações de diagnóstico coletadas só contam metade da história.
CAUSAdisplay diagnostic-information executado na placa de controle principal ativa só captura o estado dessa placa — a placa em espera mantém seu próprio estado e precisa ser acessada separadamente para extrair seu próprio arquivo de diagnóstico.
CORREÇÃOA partir da view diagnose, use local-telnet slave para acessar a placa em espera e execute display diagnostic-information também lá, para que as informações de ambas as placas cheguem a quem está solucionando o problema.
<Huawei> diagnose
[Huawei-diagnose] local-telnet slave
<Huawei> display diagnostic-information xxx.tarEm ordem — de "algo está errado" a "anexado ao chamado".
Os rótulos do diagrama permanecem em inglês para clareza técnica.
As perguntas que surgem primeiro quando alguém realmente abre um chamado de suporte.
Comece com display diagnostic-information (ou a forma dia-info.txt do switch) mais display clock para um timestamp exato, e anote a topologia, o que disparou a falha, e o que realmente está falhando — antes de mexer em qualquer comando específico da falha.
Não — o debugging é invasivo e deve ficar restrito a uma categoria já suspeita, por exemplo debugging ospf packet hello somente quando OSPF já for a teoria de trabalho, envolto em terminal debugging / terminal monitor / debug timeout 0, executado por uma janela limitada, e depois desativado explicitamente.
save logfile, executado a partir da view de usuário, salva o log operacional voltado ao usuário; save diag-logfile, executado a partir da view diagnose, salva o log de diagnóstico de nível mais baixo. Engenheiros de suporte podem pedir um ou outro dependendo do que estão buscando, e às vezes os dois.
Sim — display reset-reason, as várias variantes de display inspect black-box record, display lastwords all e display kernel-logbuf last são todos feitos especificamente para sobreviver ao reinício e responder depois "por que reiniciou".
Ambos. A checklist básica — captura em uma passada mais informações de equipamento, versão, interface, configuração e logs — se aplica a quase tudo e vale a pena coletar primeiro, independentemente da falha. A tabela por categoria de falha restringe ainda mais assim que já existe uma teoria de trabalho: IPSec, OSPF, BGP, DHCP, um reinício inesperado, ou ARP.
Este é um guia de coleta, não um guia de causa raiz. É construído a partir do próprio apêndice do manual de manutenção de roteadores AR sobre coleta de informações e comandos de diagnóstico, cruzado com o capítulo equivalente do manual de manutenção de switches Huawei. Assim que um tipo de falha específico já estiver confirmado — um túnel IPSec ou um vizinho OSPF que não sobe, por exemplo — a análise mais profunda de causa raiz para esse tipo de falha é uma nota separada, não esta.
Envie-nos o arquivo diagnostic-information e qualquer saída por categoria de falha que você tenha coletado — ajudamos a interpretar.