Entender informações importantes sobre os comandos debug

Introdução

Este documento descreve as diretrizes gerais sobre o uso dos comandos debug, inclusive o comando debug ip packet disponível nas plataformas Cisco IOS®.

Pré-requisitos

Requisitos

A Cisco recomenda que você tenha conhecimento destes tópicos:

• Conectando-se ao roteador usando o console, portas aux e vty.

• Problemas gerais de configuração do Cisco IOS.

• Interpretação das saídas de depuração do Cisco IOS.

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Informações de Apoio

Este documento fornece diretrizes gerais para o uso de comandos debug em plataformas Cisco IOS®. Ele também inclui exemplos e uma visão geral da depuração condicional.

Os comandos EXEC privilegiados debug fornecem informações de diagnóstico sobre eventos de rede, status de protocolo, processamento de pacotes e atividade geral de rede. Esses comandos ajudam a identificar a causa de problemas específicos durante a solução de problemas.

No entanto, os comandos debug podem gerar uma grande quantidade de informações de saída e podem afetar o desempenho do dispositivo, especialmente em roteadores que já estão lidando com alto tráfego ou alta utilização da CPU. Por esse motivo, execute os comandos de depuração com cuidado e somente quando necessário para a solução de problemas.

Avisos

Execute os comandos debug com cuidado. Em geral, use esses comandos somente sob a direção do representante de suporte técnico ao solucionar problemas específicos.

A habilitação da depuração pode interromper a operação do roteador, especialmente quando a rede estiver sob carga pesada. Se o registro estiver ativado, o servidor de acesso poderá congelar intermitentemente quando a porta do console ficar sobrecarregada com mensagens de registro.

Antes de executar um comando debug, considere a quantidade de saída que o comando pode gerar e por quanto tempo a sessão de depuração pode ser executada.

Por exemplo, em um roteador com uma Basic Rate Interface, é improvável que o debug isdn q931 afete o sistema. No entanto, executar o mesmo comando de depuração em um AS5800 com uma configuração E1 completa pode gerar saída suficiente para fazer o dispositivo travar ou parar de responder.

Antes da depuração, verifique a carga da CPU executando o comando show processes cpu. Verifique se há capacidade de CPU suficiente disponível antes de habilitar a depuração. É assim.

Por exemplo, se um roteador Cisco 7200 com uma interface ATM estiver executando o Bridging, reiniciar o roteador poderá consumir recursos significativos da CPU, dependendo do número de subinterfaces configuradas. Para cada circuito virtual (VC), um pacote de Bridge Protocol Data Unit (BPDU) deve ser gerado. Habilitar a depuração durante esse período crítico pode fazer com que a utilização da CPU aumente drasticamente, o que pode resultar em parada do dispositivo ou perda de conectividade de rede.

Antes da depuração

Além dos pontos mencionados acima, certifique-se de que você compreende o impacto das depurações na estabilidade da plataforma. Você também deve considerar qual interface no roteador deve ser conectada antes de ativar qualquer comando de depuração.

Obtendo saídas de depuração

Os roteadores podem exibir saídas de depuração para várias interfaces, incluindo as portas de console, aux e vty. Os roteadores também registram mensagens em um buffer interno de um servidor syslog unix externo.

Porta de Console

Se você estiver conectado ao console em configurações normais, nenhum trabalho extra precisará ser feito. A saída da depuração deve ser exibida automaticamente. No entanto, verifique se o nível do console de registro está definido como desejado e se o registro não foi desativado com o comando no logging console.

Porta Aux

Se você estiver conectado através de uma porta auxiliar, execute o comando terminal monitor. Verifique também se o comando no logging on não está ativado no roteador.

Portas VTY

Se você estiver conectado por uma porta auxiliar ou via telnet, digite o comando terminal monitor. Verifique também se o comando no logging on não está sendo usado.

Registrando as mensagens em um buffer interno

O dispositivo de registro padrão é o console; todas as mensagens são exibidas no console, a menos que especificado de outra forma.

Para registrar mensagens em um buffer interno, execute o comando de configuração do roteador logging buffered. Esta é a sintaxe completa deste comando:

logging buffered
no logging buffered

O comando logging buffered copia as mensagens de registro em um buffer interno em vez de gravá-las no console. O buffer é circular por natureza; portanto, as mensagens mais recentes substituem as novas mais antigas.

Para exibir mensagens registradas no buffer, use o comando EXEC privilegiado show logging. A primeira mensagem exibida é a mensagem mais antiga no buffer. Você pode especificar o tamanho do buffer e o nível de gravidade das mensagens a serem registradas.

O comando no logging buffered cancela o uso do buffer e grava as mensagens no console (o padrão).

Registrando mensagens para um UNIX Syslog Server

Para registrar mensagens no host do servidor syslog, execute o comando logging router configuration. Veja a sintaxe completa deste comando:

logging 
no logging 

O comando logging identifica um host de servidor de syslog para receber mensagens de registro. O argumento < ip-address > é o endereço IP do host. Emitindo esse comando mais de uma vez, você cria uma lista de servidores syslog que recebe mensagens de registro.

O comando no logging exclui o servidor syslog com o endereço especificado da lista de syslogs.

Outras tarefas de pré-depuração

1. Configure o software emulador de terminal para que ele capture a saída de depuração para um arquivo. Consulte a documentação do emulador de terminal de software.

2. Habilitar timestamps de milissegundos (msec) executando o comando service timestamps:

    router(config)#service timestamps debug datetime msec 
    router(config)#service timestamps log datetime msec
   

Esses comandos adicionam timestamps às depurações no formato MMM DD HH:MM:SS, indicando a data e a hora de acordo com o relógio do sistema. Se o relógio do sistema não tiver sido definido, a data e a hora serão precedidas por um asterisco (*) para indicar que a data e a hora provavelmente estão incorretas.

É geralmente aconselhável configurar timestamps de milissegundos, pois isso fornece um alto nível de clareza ao revisar saídas de depuração. Os timestamps de milissegundos fornecem uma melhor indicação do tempo de vários eventos de depuração relativos um ao outro. No entanto, quando a porta de console envia muitas mensagens, elas não podem se correlacionar com a temporização real do evento.

Por exemplo, se você habilitar debug x25all em uma caixa que tem 200 VCs e a saída estiver registrada no buffer (executando os comandos no logging console e logging buffered), o carimbo de data e hora exibido na saída da depuração (dentro do buffer) não pode ser a hora exata em que o pacote passa pela interface. Portanto, não use timbres de tempo em ms para provar questões de desempenho, mas para obter informações relativas sobre quando os eventos ocorrem.

Parar Depuração

Para interromper uma depuração, use os comandos no debug all ou undebug all. Verifique se as depurações foram desativadas usando o comando show debug.

Lembre-se de que os comandos no logging console e terminal no monitor apenas impedem que a saída seja gerada no console, aux ou vty, respectivamente. Ele não interrompe a depuração e consome os recursos do roteador.

Usando o comando debug ip packet

Nos roteadores Cisco IOS® clássicos, o debug ip packet vê principalmente o tráfego comutado por processo. O tráfego encaminhado através de Fast Switching ou CEF não aparece a menos que o encaminhamento seja forçado para o caminho de switching de processo. No entanto, como gera uma saída para cada pacote, a saída pode ser extensa e faz com que o roteador trave. Por esse motivo, execute apenas o debug ip packet sob os controles mais estritos, conforme descrito nesta seção.

A melhor maneira de limitar a saída debug ip packet é criar uma lista de acesso vinculada à depuração. Somente os pacotes que correspondem aos critérios da lista de acesso podem estar sujeitos ao debug ip packet. Essa lista de acesso não precisa ser aplicada a nenhuma interface, mas sim à operação de depuração.

Antes de executar o debugging ip packet, observe que o roteador está usando a switching rápida por padrão ou pode estar usando a switching CEF se configurado para fazê-lo. Isso significa que, uma vez que essas técnicas estejam em vigor, o pacote não é fornecido ao processador, a depuração não mostra nada. Para que isso funcione, você deve desativar a switching rápida no roteador sem ip route-cache (para pacotes unicast) ou no ip mroute-cache (para pacotes multicast). Isso deve ser aplicado nas interfaces onde o tráfego deve fluir. Verifique isso com o comando show ip route.

Depurações disparadas condicionalmente

Quando o recurso Conditionally Triggered Debugging (Depuração acionada condicionamente) está ativado, o roteador gera mensagens de depuração para os pacotes que entram ou saem do roteador em uma interface especificada; o roteador não gera saída de depuração para pacotes que estão entrando ou saindo por uma interface diferente.

Observe uma implementação simples de depurações condicionais. Considere este cenário: o roteador mostrado a seguir (trabol) tem duas interfaces (serial 0 e serial 3) executando o encapsulamento HDLC.

Você pode executar o comando normaldebug serial interface para observar os keepalives HDLC recebidos em todas as interfaces. Você pode observar os keepalives em ambas as 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

Ative as depurações condicionais para a interface serial 3, o que significa que somente as depurações para a interface serial 3 são exibidas. Execute o comando debug interface <interface_type interface_number >:

traxbol#debug interface serial 3 
Condition 1 set

Execute o comando show debug condition para verificar se a depuração condicional está ativa (uma condição para a interface serial 3 está ativa):

traxbol#show debug condition 

Condition 1: interface Se3 (1 flags triggered) 
Flags: Se3 
traxbol#

Agora, somente as depurações da interface serial 3 são exibidas:

*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

Execute o comando undebug interface <interface_type interface_number> para remover a depuração condicional. É recomendável que você desligue as depurações (por exemplo, usando undebug all) antes de remover o acionador condicional. Isso é para evitar a inundação de saídas de depuração quando a condição for removida.

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

Você pode observar a depuração para ambas as exibições da interface serial 0 e 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

Esta seção mostra a maneira correta de limitar a depuração de pacotes ATM a uma subinterface:

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#

Se você tentar ativar a depuração ATM em todas as interfaces (com uma condição aplicada), o roteador poderá travar se tiver um grande número de subinterfaces ATM. Um exemplo do método incorreto para depuração ATM é fornecido.

Nesse caso, você pode ver que uma condição foi aplicada, mas também ver que isso não tem efeito. Você ainda pode ver o pacote de outra interface.

Neste cenário de laboratório, você tem apenas duas interfaces e muito pouco tráfego. Se o número de interfaces for alto, a saída de depuração de todas as interfaces também será extremamente alta e poderá causar a paralisação do roteador:

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

Informações Relacionadas

• Suporte à tecnologia de discagem e acesso
• Suporte técnico e downloads da Cisco

Histórico de revisões

Revisão	Data de publicação	Comentários
5.0	22-Jun-2026	Espaçamento de introdução atualizado, outros espaços dentro do artigo, gramática, ortografia, recuo.
4.0	19-Aug-2024	Recertificação
2.0	29-Apr-2022	Links quebrados atualizados e removidos.
1.0	02-Dec-2013	Versão inicial