En el momento en que un router o switch Huawei empieza a fallar, lo que se recopila en los primeros minutos decide si el siguiente paso es una solución o un segundo ida y vuelta. Este es el orden de recopilación tomado directamente del propio manual de mantenimiento de routers AR de Huawei y del manual de switches Huawei: un comando que captura casi todo, una lista de verificación básica, una recopilación correcta de registros y contadores, y una hoja de referencia de qué extraer exactamente una vez que ya se sospecha un tipo de falla específico.
Por Yuwen Zhang (Atlas), fundador de AtlasCommTech — 13 años de despliegues de redes de operadores y empresariales · Actualizado en julio de 2026
El objetivo no es más datos — es el dato específico que permite a otra persona localizar la falla sin una segunda llamada.
El propio manual de mantenimiento de switches de Huawei abre su capítulo de diagnóstico con una instrucción directa: cuando no pueda determinar la causa usted mismo, recopile la información de falla pertinente y entréguela al distribuidor o al soporte de Huawei para su localización. En la práctica, eso significa tres cosas cada vez — el momento y la topología en que ocurrió la falla, la identidad y el estado propios del equipo (nombre, versión, configuración actual, información de interfaz), y los registros y alarmas generados en ese momento.
A continuación, ese trabajo de recopilación en orden: el comando que captura casi todo en una sola pasada, una lista de verificación básica de los comandos display que vale la pena conocer por su nombre, cómo recopilar registros y reiniciar contadores sin engañarse sobre lo que realmente está activo, y una hoja de referencia de qué extraer una vez que ya se tiene una teoría de trabajo sobre qué subsistema falla — IPSec, OSPF, BGP, DHCP, un reinicio inesperado, o ARP.
Un comando, que agrupa la salida de docenas de otros — vale la pena ejecutarlo antes de cualquier acción específica de la falla.
display diagnostic-information recopila en una sola pasada la configuración de arranque del equipo, la configuración actual, la información de interfaz, el reloj, la versión de software y más — en la práctica, una ejecución por lotes de los comandos display que la mayoría pensaría en ejecutar uno por uno de todos modos.
<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.En un router AR, el mismo comando puede escribir directamente en un archivo .tar, y en un chasis con dos tarjetas de control principal, la información de diagnóstico del maestro y del respaldo debe extraerse por separado.
<Huawei> display diagnostic-information xxx.tar
<Huawei> diagnose
[Huawei-diagnose] local-telnet slave
<Huawei> display diagnostic-information xxx.tarEvite la salida directa a terminal y déle un nombre de archivo — la salida es larga, y un archivo guardado es lo que un ingeniero de soporte realmente quiere adjuntar al ticket.
Los comandos display que vale la pena conocer por su nombre, independientemente de cuál resulte ser la falla.
| Información | Comando | Por qué importa |
|---|---|---|
| Información básica | display diagnostic-information | El paquete de una sola pasada anterior — proporciónelo en cualquier solicitud de soporte, sea cual sea el tipo de falla. |
| Información del equipo | display device | Marca una tarjeta en estado Abnormal — lo primero que hay que revisar cuando se sospecha de una tarjeta concreta. |
| Información de interfaz | display interface | Estado físico, configuración y contadores de paquetes de una interfaz — la primera parada habitual para fallas de interconexión o pérdida de paquetes. |
| Información de versión | display version | Versiones de software, BootROM, tarjeta de control principal, tarjeta de interfaz y módulo de ventilador, además de los tamaños de memoria — a menudo lo primero que pedirá un ingeniero de soporte. |
| Información de parches | display patch-information | Versión y nombre del paquete de parches actual — importa porque el comportamiento puede diferir significativamente entre niveles de parche. |
| Etiqueta electrónica | display elabel | Identidad del hardware e información de fabricación — necesaria para un RMA o una devolución de hardware. |
| Salud del equipo | display health | Temperatura, alimentación, ventilador, consumo, uso de CPU/memoria y almacenamiento en una sola vista. |
| Configuración actual | display current-configuration | Lo que el equipo realmente está ejecutando en este momento — admite filtrado por expresiones regulares para acotarlo. |
| Configuración guardada | display saved-configuration | Lo que el equipo cargará en su próximo arranque — útil cuando el equipo arrancó pero no se comporta según lo configurado. |
| Reloj | display clock | Fija con precisión el momento en que ocurrió la falla — esencial para correlacionar con registros y alarmas. |
| Registro de usuario | display logfile buffer | Se ejecuta desde la vista diagnose; muestra el registro de usuario almacenado en búfer. |
| Registro de diagnóstico | display diag-logfile buffer | También desde la vista diagnose; el registro de diagnóstico de nivel más bajo, distinto del registro de usuario. |
| Información de alarmas | display trapbuffer | El búfer Trap del centro de información — la forma más rápida de ver qué alarmas realmente se dispararon. |
| Uso de memoria | display memory-usage | Agregue slot slot-id para la memoria de una tarjeta de interfaz; omítalo para la de la tarjeta de control principal. |
| Uso de CPU | display cpu-usage | Misma lógica de slot que el uso de memoria — control principal por defecto, tarjeta de interfaz con slot slot-id. |
Un registro que se olvidó de guardar y un contador que se olvidó de reiniciar cuentan la historia equivocada.
Extraer los archivos de registro reales
save logfile y save diag-logfile escriben el contenido del registro en búfer en archivos bajo flash:/logfile/, que luego se pueden extraer del equipo por FTP/TFTP.
<HUAWEI> save logfile
<HUAWEI> system-view
[HUAWEI] diagnose
[HUAWEI-diagnose] save diag-logfileReiniciar los contadores antes de confiar en ellos
display interface y display ip interface muestran estadísticas acumuladas desde que arrancó el equipo o desde que se reiniciaron por última vez los contadores — no desde que empezó el problema. Reinícielos primero, genere tráfico nuevo y vuelva a leer.
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 distinto de cero aquí solo indica que algo ocurrió en algún momento desde el último reinicio — reinicie el contador, vuelva a probar y vuelva a leer antes de tratarlo como un problema en vivo.
Una vez que ya se tiene una teoría de trabajo sobre qué subsistema falla, esto lo acota rápidamente.
| Categoría de falla | Comandos a ejecutar | Qué está buscando |
|---|---|---|
| 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 da directamente el motivo real del fallo de negociación IKE, en lugar de hacerle deducirlo de un simple estado "down". |
| OSPF | display ospf routing ipv4-address verbose display ospf peer verbose debugging ospf event debugging ospf packet hello | display ospf peer verbose muestra detalles de estado por vecino mucho más allá de 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 muestra directamente el código de error Down del vecino — la lectura más rápida sobre por qué una sesión se cayó. |
| L2TP / PPP | display l2tp session-down-reason display l2tp tunnel-down-reason display ppp state all debugging l2tp all / debugging ppp all | Los dos comandos down-reason existen precisamente porque un túnel o sesión L2TP no solo reporta "down" — registra el 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 | DHCP tiene tres roles distintos — cliente, relay, servidor — y los comandos de recopilación son específicos de cada rol; extraer estadísticas de relay de un equipo que actúa como servidor no mostrará nada útil. |
| Reinicio 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 estos comandos están diseñados para sobrevivir al propio reinicio, específicamente para responder después "por qué se reinició". |
| ARP | display arp history debugging arp packet | display arp history muestra cómo cambió realmente una entrada a lo largo del tiempo, no solo su estado actual. |
El mismo manual cubre más categorías con el mismo formato — SNMP, BFD, voz, fallas de módem 3G/LTE/5G y NQA entre ellas — siguiendo el mismo patrón: un comando display para el estado, un comando debugging para el rastreo en vivo.
Los propios comandos de recopilación tienen aristas — estas son las que sorprenden a los ingenieros.
SÍNTOMAEl uso de CPU se dispara justo cuando se ejecuta display diagnostic-information en un equipo que ya está bajo carga o en medio de un incidente.
CAUSAEl comando agrupa muchos comandos display y está explícitamente documentado como algo que puede aumentar el uso de CPU mientras se ejecuta — ejecutarlo desde varias sesiones de terminal en el mismo equipo a la vez puede subir el CPU notablemente más.
SOLUCIÓNNo lo ejecute de forma redundante desde varias sesiones a la vez, y no lo convierta en mantenimiento rutinario en un equipo sano — resérvelo para cuando la información realmente se necesite para un traspaso.
<HUAWEI> display diagnostic-information dia-info.txtSÍNTOMASe introduce un comando debugging xxx y no aparece nada en pantalla — o, el problema opuesto, el debugging queda activo mucho después del incidente y empieza a competir por CPU con todo lo demás.
CAUSALa información de debugging no se imprime en una sesión de terminal a menos que terminal debugging y terminal monitor estén explícitamente activados, con debug timeout 0 configurado para que no expire inesperadamente a mitad de la recopilación — y permanece activo hasta que alguien lo desactive explícitamente.
SOLUCIÓNEjecute el preámbulo de tres líneas antes de cualquier comando debugging, recopile durante una ventana acotada, y luego deshaga explícitamente ambos ajustes después.
terminal debugging
terminal monitor
debug timeout 0
...
undo terminal debugging
undo terminal monitorSÍNTOMAdisplay interface muestra Total Error mayor que cero, y es tentador concluir que el puerto está activamente averiado en este momento.
CAUSAEsos contadores se acumulan desde el arranque del equipo, o desde la última vez que se reiniciaron manualmente — un Total Error distinto de cero puede ser un remanente de algo que ocurrió hace días o semanas, no lo que está pasando ahora.
SOLUCIÓNReinicie los contadores, genere tráfico nuevo con ping, y vuelva a leer el mismo comando display — solo el delta durante esa ventana indica si el problema está en vivo.
reset counters interface ethernet 1/0/0
ping ...
display interface ethernet 1/0/0SÍNTOMADuplicar el tráfico de un puerto hacia Wireshark en una laptop para perseguir una falla a nivel de paquete parece un paso puramente técnico.
CAUSALa propia documentación del fabricante señala que esta función puede implicar la captura o almacenamiento del contenido de comunicaciones reales de alguien, y establece que solo debe habilitarse dentro del alcance que la ley local realmente permita — no algo a lo que recurrir automáticamente.
SOLUCIÓNConfirme el alcance y la autorización antes de configurar un puerto de observación y duplicar tráfico en vivo hacia él, especialmente antes de apuntar una herramienta de captura al flujo duplicado.
[Router] observe-port interface ethernet 5/0/0
[Router] interface gigabitethernet 0/0/0
[Router-GigabitEthernet0/0/0] mirror to observe-port inboundSÍNTOMAUn chasis con dos tarjetas de control principal conmuta o falla, y la información de diagnóstico recopilada solo cuenta la mitad de la historia.
CAUSAdisplay diagnostic-information ejecutado en la tarjeta de control principal activa solo captura el estado de esa tarjeta — la tarjeta en espera mantiene su propio estado y hay que acceder a ella por separado para extraer su propio archivo de diagnóstico.
SOLUCIÓNDesde la vista diagnose, use local-telnet slave para acceder a la tarjeta en espera y ejecute también allí display diagnostic-information, para que la información de ambas tarjetas llegue a quien esté resolviendo el problema.
<Huawei> diagnose
[Huawei-diagnose] local-telnet slave
<Huawei> display diagnostic-information xxx.tarEn orden — de "algo anda mal" a "adjunto al ticket".
Las etiquetas del diagrama se mantienen en inglés por claridad técnica.
Las preguntas que surgen primero cuando realmente se abre un ticket de soporte.
Empiece con display diagnostic-information (o la forma dia-info.txt del switch) más display clock para una marca de tiempo exacta, y anote la topología, qué desencadenó la falla, y qué está fallando realmente — antes de tocar cualquier comando específico de la falla.
No — el debugging es invasivo y debe limitarse a una categoría que ya se sospeche, por ejemplo debugging ospf packet hello solo una vez que OSPF sea la teoría de trabajo, envuelto en terminal debugging / terminal monitor / debug timeout 0, ejecutado durante una ventana acotada, y luego desactivado explícitamente.
save logfile, ejecutado desde la vista de usuario, guarda el registro operativo orientado al usuario; save diag-logfile, ejecutado desde la vista diagnose, guarda el registro de diagnóstico de nivel más bajo. Los ingenieros de soporte pueden pedir uno u otro según lo que estén buscando, y a veces ambos.
Sí — display reset-reason, las varias variantes de display inspect black-box record, display lastwords all y display kernel-logbuf last están diseñados específicamente para sobrevivir al reinicio y responder después "por qué se reinició".
Ambas cosas. La lista de verificación básica — captura en una sola pasada más información de equipo, versión, interfaz, configuración y registros — se aplica a casi cualquier cosa y vale la pena recopilarla primero sin importar la falla. La tabla por categoría de falla lo acota más una vez que ya existe una teoría de trabajo: IPSec, OSPF, BGP, DHCP, un reinicio inesperado, o ARP.
Esta es una guía de recopilación, no una guía de causa raíz. Se basa en el propio apéndice del manual de mantenimiento de routers AR sobre recopilación de información y comandos de diagnóstico, contrastado con el capítulo equivalente del manual de mantenimiento de switches Huawei. Una vez que un tipo de falla específico ya está confirmado — un túnel IPSec o un vecino OSPF que no sube, por ejemplo — el análisis profundo de causa raíz para ese tipo de falla es una nota aparte, no esta.
Envíenos el archivo diagnostic-information y cualquier salida por categoría de falla que haya extraído — le ayudamos a interpretarla.