Comprensión de información importante sobre comandos de depuración
Contenido
Introducción
Este documento describe los lineamientos generales sobre el uso de comandos de depuración, incluido el comando debug ip packet disponible en las plataformas Cisco IOS®.
Prerequisites
Requirements
Cisco recomienda que tenga conocimiento sobre estos temas:
-
Conexión del router utilizando los puertos VTY, auxiliares y de consola.
-
Problemas generales de configuración de Cisco IOS.
-
Interpretación de resultados de depuración de Cisco IOS.
Componentes Utilizados
Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.
La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.
Antecedentes
Este documento proporciona pautas generales para utilizar los comandos debug en las plataformas Cisco IOS®. También incluye ejemplos y una descripción general de la depuración condicional.
Los comandos EXEC privilegiados debug proporcionan información de diagnóstico sobre los eventos de red, el estado del protocolo, el procesamiento de paquetes y la actividad general de la red. Estos comandos ayudan a identificar la causa de problemas específicos durante la resolución de problemas.
Sin embargo, los comandos debug pueden generar una gran cantidad de información de salida y pueden afectar el rendimiento del dispositivo, especialmente en los routers que ya manejan un tráfico alto o un uso elevado de la CPU. Por esta razón, ejecute los comandos debug con cuidado y sólo cuando sea necesario para la solución de problemas.
Nota: Este documento no explica cómo utilizar o interpretar comandos debug específicos y su resultado. Para obtener detalles sobre los comandos debug individuales, consulte la documentación apropiada de Referencia de Comandos Debug de Cisco.
Advertencias
Ejecute los comandos debug con precaución. En general, utilice estos comandos sólo bajo la dirección de su representante de soporte técnico cuando resuelva problemas específicos.
La habilitación de la depuración puede interrumpir el funcionamiento del router, especialmente cuando la red está bajo una carga pesada. Si el registro está habilitado, el servidor de acceso puede congelarse intermitentemente cuando el puerto de la consola se sobrecarga con mensajes de registro.
Antes de ejecutar un comando debug, considere la cantidad de resultados que puede generar el comando y cuánto tiempo puede ejecutarse la sesión de depuración.
Por ejemplo, en un router con una Interfaz de velocidad básica, es poco probable que debug isdn q931 afecte al sistema. Sin embargo, ejecutar el mismo comando debug en un AS5800 con una configuración E1 completa puede generar suficiente salida para que el dispositivo se cuelgue o deje de responder.
Antes de depurar, verifique la carga de la CPU ejecutando el comando show processes cpu. Verifique que haya suficiente capacidad de CPU disponible antes de habilitar la depuración, éste es el camino.
Por ejemplo, si un router Cisco 7200 con una interfaz ATM está ejecutando el bridging, reiniciar el router puede consumir recursos significativos de la CPU, según el número de subinterfaces configuradas. Para cada circuito virtual (VC), se debe generar un paquete de unidad de datos de protocolo de puente (BPDU). La habilitación de la depuración durante este período crítico puede hacer que la utilización de la CPU aumente drásticamente, lo que puede dar lugar a un bloqueo del dispositivo o a la pérdida de conectividad de red.
Nota: Cuando se ejecutan las depuraciones, a menudo no ve el mensaje del router, especialmente cuando la depuración es intensiva. Sin embargo, en la mayoría de los casos, puede ejecutar los comandos no debug all o undebug all para detener depuraciones.
Antes de la depuración
Además de los puntos mencionados anteriormente, asegúrese de comprender el impacto de las depuraciones en la estabilidad de la plataforma. También debe considerar qué interfaz del router debe conectar antes de habilitar cualquier comando debug.
Cómo obtener las salidas de los depuradores
Los routers pueden mostrar resultados de depuración para diversas interfaces, dentro de los cuales se encuentran los puertos de consola, auxiliares y vty. Los routers también pueden registrar mensajes a un búfer interno, a un servidor syslog unix externo.
Puerto de consola
Si está conectado a la consola con configuraciones normales, no es necesario realizar ningún trabajo adicional. El resultado de la depuración debe mostrarse automáticamente. Sin embargo, asegúrese de que el nivel de la consola de registro esté configurado como desee y de que el registro no se haya deshabilitado con el comando no logging console.
Advertencia: Los debugs excesivos al puerto de consola de un router pueden hacer que se bloquee. Esto se debe a que el router da prioridad automáticamente a la salida de la consola por encima de otras funciones del router. Si el router está procesando una salida de depuración grande al puerto de la consola, puede bloquearse. Si el resultado de la depuración es excesivo, utilice los puertos vty (telnet) o los búferes de registro para obtener sus depuraciones.
Nota: De forma predeterminada, el registro está habilitado en el puerto de consola. El puerto de la consola siempre procesa la salida de depuración incluso si está utilizando algún otro puerto o método (como aux, vty o buffer) para capturar la salida. Cisco recomienda que, en condiciones de funcionamiento normales, ejecute el comando no logging console y estará habilitado en todo momento y utilice otros métodos para capturar depuraciones. En situaciones en las que deba utilizar la consola, vuelva a activar temporalmente la consola de registro.
Puerto auxiliar
Si está conectado a través de un puerto auxiliar, ejecute el comando terminal monitor. Verifique también que el comando no logging on no esté activado en el router.
Nota: Si utiliza el puerto auxiliar para monitorear el router, tenga en cuenta que cuando el router se reinicia, el puerto auxiliar no muestra la salida de la secuencia de inicio. Conéctese al puerto de la consola para ver la secuencia de arranque.
Puertos VTY
Si está conectado por medio de un puerto auxiliar o Telnet, escriba el comando terminal monitor. También verifique que el comando no logging on no esté siendo utilizado.
Registro de mensajes en una memoria intermedia interna
El dispositivo de registro predeterminado es la consola; todos los mensajes se muestran en la consola, a menos que se indique lo contrario.
Para registrar mensajes en un buffer interno, ejecute el comando de configuración logging buffered router. Esta es la sintaxis completa de este comando:
logging buffered no logging buffered
El comando logging buffered copia los mensajes de registro en un buffer interno en lugar de escribirlos en la consola. El búfer es originalmente circular, por lo que los mensajes nuevos sobrescriben a los anteriores.
Para mostrar los mensajes registrados en el búfer, utilice el comando EXEC privilegiado show logging. El primer mensaje mostrado es el más antiguo del buffer. Puede especificar el tamaño del búfer y el nivel de gravedad de los mensajes que se van a registrar.
Nota: Asegúrese de que haya suficiente memoria disponible en el cuadro antes de introducir el tamaño del búfer. Utilice el comando show proc mem para ver la memoria disponible.
El comando no logging buffered cancela el uso de la memoria intermedia y manda mensajes a la consola (predeterminada).
Mensajes de registro a un servidor UNIX Syslog.
Para registrar mensajes en el host del servidor syslog, ejecute el comando logging router configuration. Ver la sintaxis completa de este comando:
loggingno logging
El comando logging identifica un host del servidor syslog para recibir los mensajes de registro. El argumento < ip-address> es la dirección IP del host. Al ejecutar este comando más de una vez, se crea una lista de servidores syslog que reciben mensajes de registro.
El comando no logging elimina el servidor syslog con la dirección especificada de la lista de syslogs.
Otras tareas previas a la depuración
-
Configure el software del emulador de terminal para que capture el resultado de la depuración en un archivo. Consulte la documentación de su emulador de terminal de software.
-
Habilite los sellos de hora en milisegundos (msec) que ejecutan el comando service timestamps:
router(config)#service timestamps debug datetime msec router(config)#service timestamps log datetime msec
Estos comandos agregan marcas de tiempo a las depuraciones en el formato MMM DD HH:MM:SS, indicando la fecha y la hora según el reloj del sistema. Si no se ha establecido el reloj del sistema, la fecha y la hora van precedidas de un asterisco (*) para indicar que la fecha y la hora son probablemente incorrectas.
Por lo general, se recomienda configurar las marcas de tiempo en milisegundos, ya que esto proporciona un alto nivel de claridad al revisar las salidas de depuración. Las marcas de tiempo en milisegundos proporcionan una mejor indicación de la temporización de varios eventos de depuración entre sí. Sin embargo, cuando el puerto de la consola emite muchos mensajes, no pueden correlacionarse con la temporización real del evento.
Por ejemplo, si habilita debug x25all en un cuadro que tiene 200 VC y la salida se registra en el buffer (ejecutando los comandos no logging console y logging buffered), la marca de tiempo que se muestra en la salida de debug (dentro del buffer) no puede ser la hora exacta en que el paquete pasa a través de la interfaz. Por lo tanto, no utilice sellos de hora mseg para demostrar problemas de rendimiento sino para obtener información relativa acerca de cuándo tienen lugar los eventos.
Detener depuración
Para parar un debug, utilice los comandos no debug all o undebug all. Verifique que las depuraciones se hayan desactivado mediante el comando show debug.
Recuerde que los comandos no logging console y terminal no monitor solamente evitan que la salida se emita en la consola, aux o vty respectivamente. No detiene la depuración y utiliza los recursos del router.
Uso del comando debug ip packet
En los routers Cisco IOS® clásicos, el debug ip packet ve principalmente el tráfico conmutado por proceso. El tráfico reenviado a través de Fast Switching o CEF no aparece a menos que el reenvío sea forzado en el trayecto de process-switching. Sin embargo, debido a que genera una salida para cada paquete, la salida puede ser extensa y hace que el router se cuelgue. Por esta razón, ejecute solamente el debug ip packet bajo los controles más estrictos como se describe en esta sección.
La mejor manera de limitar la salida de debug ip packet es crear una lista de acceso que esté vinculada a la depuración. Solamente los paquetes que coinciden con los criterios de la lista de acceso pueden estar sujetos al paquete debug ip. Esta lista de acceso no necesita aplicarse en ninguna interfaz, sino que se aplica a la operación de debugging.
Antes de ejecutar el paquete ip de depuración, observe que el router está usando fast-switching de forma predeterminada, o puede estar usando CEF switching si está configurado para hacerlo. Esto significa que, una vez que esas técnicas están en su lugar, el paquete no se proporciona al procesador, la depuración no muestra nada. Para que esto funcione, debe inhabilitar el fast switching en el router sin ip route-cache (para paquetes unicast) o sin ip mroute-cache (para paquetes multicast). Esto debe aplicarse en las interfaces donde se supone que fluye el tráfico. Verifíquelo con el comando show ip route.
Nota: En las plataformas más nuevas, el reenvío se suele gestionar mediante CEF o switching basado en hardware, por lo que ya no es aplicable ni recomendable desactivar el fast switching. Como resultado, debug ip packet puede fallar al mostrar de manera confiable el tráfico de tránsito, y la solución de problemas moderna generalmente se basa en la captura específica de la plataforma o en las herramientas de hardware en su lugar.
Depuraciones accionadas de manera condicional
Cuando se habilita la función Conditionally Triggered Debugging, el router genera mensajes de debugging para los paquetes que entran o salen del router en una interfaz especificada; el router no genera un resultado de la depuración para los paquetes que entran o salen por una interfaz diferente.
Observe una implementación simple de depuraciones condicionales. Tenga en cuenta esta situación: el router que se muestra a continuación (trabol) tiene dos interfaces (serial 0 y serial 3) que ejecutan encapsulación HDLC.
Puede ejecutar el comando normaldebug serial interface para observar los keepalives HDLC recibidos en todas las interfaces. Puede observar las señales de mantenimiento en ambas interfaces:
traxbol#debug serial interface Serial network interface debugging is on traxbol# *Mar 8 09:42:34.851: Serial0: HDLC myseq 28, mineseen 28*, yourseen 41, line up ! -- HDLC keeplaive on interface Serial 0 *Mar 8 09:42:34.855: Serial3: HDLC myseq 26, mineseen 26*, yourseen 27, line up ! -- HDLC keeplaive on interface Serial 3 *Mar 8 09:42:44.851: Serial0: HDLC myseq 29, mineseen 29*, yourseen 42, line up *Mar 8 09:42:44.855: Serial3: HDLC myseq 27, mineseen 27*, yourseen 28, line up
Habilite los debugs condicionales para la interfaz serial 3, lo que significa que sólo se muestran los debugs para la interfaz serial 3. Ejecute el comando debug interface <interface_type interface_number >:
traxbol#debug interface serial 3 Condition 1 set
Ejecute el comando show debug condition para verificar que el debug condicional está activo (una condición para la interfaz serial 3 está activa):
traxbol#show debug condition Condition 1: interface Se3 (1 flags triggered) Flags: Se3 traxbol#
Ahora solo se muestran los debugs para la interfaz serial 3:
*Mar 8 09:43:04.855: Serial3: HDLC myseq 29, mineseen 29*, yourseen 30, line up *Mar 8 09:43:14.855: Serial3: HDLC myseq 30, mineseen 30*, yourseen 31, line up
Ejecute el comando undebug interface <interface_type interface_number> para quitar la depuración condicional. Se recomienda desactivar las depuraciones (por ejemplo, con undebug all) antes de eliminar el activador condicional. Esto es así para evitar un aluvión de salidas de depuración cuando se elimina la condición.
traxbol#undebug interface serial 3 This condition is the last interface condition set. Removing all conditions can cause a flood of debugging messages to result, unless specific debugging flags are first removed. Proceed with removal? [yes/no]: y Condition 1 has been removed traxbol
Puede observar la depuración tanto para la interfaz serial 0 como para la interfaz serial 3:
*Mar 8 09:43:34.927: Serial3: HDLC myseq 32, mineseen 32*, yourseen 33, line up *Mar 8 09:43:44.923: Serial0: HDLC myseq 35, mineseen 35*, yourseen 48, line up
Advertencia: Algunas operaciones de debugging son condicionales en sí mismas. Un ejemplo es la depuración atm; con la depuración ATM, debe especificar explícitamente la interfaz para la que se deben habilitar las depuraciones en lugar de habilitar las depuraciones en todas las interfaces atm y especificar una condición.
Esta sección muestra la forma correcta de limitar la depuración de paquetes de ATM a una subinterfaz:
arielle-nrp2#debug atm packet interface atm 0/0/0.1 !--- Note that you explicitly specify the sub-interface to be used for debugging ATM packets debugging is on Displaying packets on interface ATM0/0/0.1 only arielle-nrp2# *Dec 21 10:16:51.891: ATM0/0/0.1(O): VCD:0x1 VPI:0x1 VCI:0x21 DM:0x100 SAP:AAAA CTL:03 OUI:0080C2 TYPE:0007 Length:0x278 *Dec 21 10:16:51.891: 0000 FFFF FFFF FFFF 0010 7BB9 BDC4 0800 4500 025C 01FE 0000 FF11 61C8 0A30 *Dec 21 10:16:51.891: 4B9B FFFF FFFF 0044 0043 0248 0000 0101 0600 0015 23B7 0000 8000 0000 0000 *Dec 21 10:16:51.891: 0000 0000 0000 0000 0000 0000 0010 7BB9 BDC3 0000 0000 0000 0000 0000 0000 *Dec 21 10:16:51.891: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:16:51.891: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:16:51.891: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:16:51.891: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:16:51.895: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:16:51.895: arielle-nrp2#
Si intenta habilitar la depuración atm en todas las interfaces (con una condición aplicada), el router puede bloquearse si tiene un gran número de subinterfaces ATM. Se muestra un ejemplo del método incorrecto para depurar el atm.
En este caso, puede ver que se aplica una condición, pero también que ésta no tiene ningún efecto. Aún puede ver el paquete desde la otra interfaz.
En este escenario de laboratorio, solo tiene dos interfaces y muy poco tráfico. Si el número de interfaces es alto, el resultado de la depuración para todas las interfaces también es extremadamente alto y puede hacer que el router se cuelgue:
arielle-nrp2#show debugging condition Condition 1: interface AT0/0/0.1 (1 flags triggered) Flags: AT0/0/0.1 ! -- A condition for a specific interface. arielle-nrp2#debug atm packet ATM packets debugging is on Displaying all ATM packets arielle-nrp2# *Dec 21 10:22:06.727: ATM0/0/0.2(O): ! -- You see debugs from interface ATM0/0/0/.2, even though the condition ! -- specified ONLY AT0/0/0.1 VCD:0x2 VPI:0x5 VCI:0x37 DM:0x100 SAP:AAAA CTL:03 OUI:0080C2 TYPE:000E Length:0x2F *Dec 21 10:22:06.727: 0000 0000 0180 0000 107B B9BD C400 0000 0080 0000 107B B9BD C480 0800 0014 *Dec 21 10:22:06.727: 0002 000F 0000 *Dec 21 10:22:06.727: un a *Dec 21 10:22:08.727: ATM0/0/0.2(O): VCD:0x2 VPI:0x5 VCI:0x37 DM:0x100 SAP:AAAA CTL:03 OUI:0080C2 TYPE:000E Length:0x2F *Dec 21 10:22:08.727: 0000 0000 0180 0000 107B B9BD C400 0000 0080 0000 107B B9BD C480 0800 0014 *Dec 21 10:22:08.727: 0002 000F 0000 *Dec 21 10:22:08.727: ll *Dec 21 10:22:10.727: ATM0/0/0.2(O): VCD:0x2 VPI:0x5 VCI:0x37 DM:0x100 SAP:AAAA CTL:03 OUI:0080C2 TYPE:000E Length:0x2F *Dec 21 10:22:10.727: 0000 0000 0080 0000 107B B9BD C400 0000 0080 0000 107B B9BD C480 0800 0014 *Dec 21 10:22:10.727: 0002 000F 0000 *Dec 21 10:22:10.727: *Dec 21 10:22:12.727: ATM0/0/0.2(O): VCD:0x2 VPI:0x5 VCI:0x37 DM:0x100 SAP:AAAA CTL:03 OUI:0080C2 TYPE:000E Length:0x2F *Dec 21 10:22:12.727: 0000 0000 0080 0000 107B B9BD C400 0000 0080 0000 107B B9BD C480 0800 0014 *Dec 21 10:22:12.727: 0002 000F 0000 *Dec 21 10:22:12.727: *Dec 21 10:22:13.931: ATM0/0/0.1(O): !--- You also see debugs for interface ATM0/0/0.1 as you wanted. VCD:0x1 VPI:0x1 VCI:0x21 DM:0x100 SAP:AAAA CTL:03 OUI:0080C2 TYPE:0007 Length:0x278 *Dec 21 10:22:13.931: 0000 FFFF FFFF FFFF 0010 7BB9 BDC4 0800 4500 025C 027F 0000 FF11 6147 0A30 *Dec 21 10:22:13.931: 4B9B FFFF FFFF 0044 0043 0248 0000 0101 0600 001A 4481 0000 8000 0000 0000 *Dec 21 10:22:13.931: 0000 0000 0000 0000 0000 0000 0010 7BB9 BDC3 0000 0000 0000 0000 0000 0000 *Dec 21 10:22:13.931: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:22:13.931: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:22:13.931: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:22:13.931: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:22:13.935: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
Información Relacionada
Historial de revisiones
| Revisión | Fecha de publicación | Comentarios |
|---|---|---|
5.0 |
22-Jun-2026
|
Actualizado Introducción espaciado, otros espaciados dentro del artículo, gramática, ortografía, sangría. |
4.0 |
19-Aug-2024
|
Recertificación |
2.0 |
29-Apr-2022
|
Actualización y eliminación de enlaces rotos. |
1.0 |
02-Dec-2013
|
Versión inicial |
Comentarios