O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.
A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
Este documento descreve as diretrizes gerais sobre o uso debug
incluindo o comando debug ip packet
disponível nas plataformas Cisco IOS®.
A Cisco recomenda que você tenha conhecimento destes tópicos:
Conexão com o roteador usando o console, as portas aux e vty
Problemas gerais de configuração do Cisco IOS
Interpretação das saídas de depuração do Cisco IOS
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.
Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.
Esta página fornece algumas diretrizes gerais sobre o uso das depurações disponíveis nas plataformas Cisco IOS, bem como exemplos para o uso adequado do comando debug ip packet
e a depuração condicional.
Observação: este documento não explica como usar e interpretar comandos e saídas de depuração específicos. Consulte a documentação de referência de comando de depuração da Cisco apropriada, para obter informações sobre comandos debug específicos.
A saída de debug
Os comandos EXEC privilegiados fornecem informações de diagnóstico que incluem uma variedade de eventos de internetworking relacionados ao status do protocolo e à atividade da rede em geral.
Uso debug
com cuidado. Geralmente, recomenda-se que esses comandos sejam somente utilizados sob a coordenação do representante de suporte técnico do roteador quando Troubleshooting problemas específicos.
Habilitar a depuração pode interromper a operação do roteador quando as inter-redes estiverem com condição de carga elevada. Portanto, se o log estiver ativado, o servidor de acesso poderá congelar intermitentemente assim que a porta do console for sobrecarregada com mensagens de log.
Antes de iniciar um debug
considere sempre a saída que esse comando pode gerar e o tempo que isso pode levar. Por exemplo, se você tiver um roteador com uma interface de taxa básica (BRI), debug isdn q931
provavelmente não danifica o sistema. Mas, fazer a mesma depuração em um AS5800 com configuração E1 completa provavelmente pode gerar tanta entrada que ele pode travar e parar de responder.
Antes de depurar, observe a carga da CPU com o comando show processes cpu
comando. Verifique se você tem CPU suficiente disponível antes de iniciar as depurações. Consulte Solução de problemas de alta utilização da CPU nos roteadores Cisco, para obter mais informações sobre como lidar com altas cargas de CPU. Por exemplo, se você tiver um roteador Cisco 7200 com uma interface ATM fazendo bridging, então, dependendo da quantidade de subinterfaces configuradas, reiniciar o roteador pode usar muito de sua CPU. A razão aqui é que, para cada VC (Circuito virtual), um pacote de BPDU (Unidade de dados do protocolo de ponte) precisa ser gerado. Iniciar depurações durante esse tempo crítico pode fazer com que a utilização da CPU aumente drasticamente e resultar em uma suspensão ou perda de conectividade da rede.
Observação: quando as depurações estão em execução, você normalmente não vê o prompt do roteador, especialmente quando a depuração é intensiva. Mas, na maioria dos casos, você pode usar os comandos no debug all ou undebug all para interromper as depurações. Consulte a seção Obter saídas de depuração para obter mais informações sobre o uso seguro de depurações.
Além dos pontos mencionados acima, verifique se você entendeu o impacto das depurações na estabilidade da plataforma. Você também deve considerar a que interface do roteador você deve se conectar. Esta seção tem algumas diretrizes.
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. As instruções e advertências para cada método são discutidas a seguir:
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. Mas, certifique-se de que o logging console level
está definido como desejado e que o registro não foi desativado com o comando no logging console
comando.
Aviso: depurações excessivas na porta de console de um roteador podem causar travamento. Isso é porque o roteador prioriza automaticamente a saída do console a frente de outras funções do roteador. Portanto, se o roteador estiver processando uma grande saída de depuração para a porta de console, ele poderá travar. Portanto, se a saída de depurações for excessiva, use as portas vty (telnet) ou os buffers de registro para obter depurações. Mais informações são fornecidas a seguir.
Observação: por padrão, o registro está habilitado na porta de console. Dessa forma, a porta do console sempre processará a saída de depurações, mesmo que você esteja usando na prática outro método ou porta (como Aux, vty ou buffer) para capturar a saída. Portanto, a Cisco recomenda que, em condições operacionais normais, você tenha o comando no logging console ativado o tempo todo e use outros métodos para capturar depurações. Nas situações em que é necessário o uso de console, ative temporariamente o console de logon.
Se você estiver conectado por uma porta Auxiliar, digite o comando terminal monitor
comando. Verifique também se o no logging on
não foi ativado no roteador.
Observação: se você usar a porta Aux para monitorar o roteador, lembre-se de que, quando o roteador for reinicializado, a porta Aux não exibirá a saída da sequência de inicialização. Conecte-se à porta do console para visualizar a sequência de inicialização.
Se você estiver conectado por uma porta Auxiliar ou via telnet, digite o comando terminal monitor
comando. Verifique também se o no logging on
não foi usado.
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, use o comando logging buffered
comando de configuração do roteador. Esta é a sintaxe completa deste comando:
logging buffered no logging buffered
O logging buffered
copia mensagens de registro para 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 as 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 também o nível de gravidade das mensagens a serem registradas.
Observação: verifique se há memória suficiente disponível na caixa antes de inserir o tamanho do buffer. Usar o Cisco IOS show proc mem
para ver a memória disponível.
O no logging buffered
cancela o uso do buffer e grava mensagens no console (o padrão).
Para registrar mensagens no host do servidor syslog, use o comando logging router configuration. A sintaxe completa deste comando é:
loggingno logging
O logging
identifica um host do servidor syslog para receber mensagens de registro. O argumento < ip-address > é o endereço IP do host. Ao emitir esse comando mais de uma vez, você cria uma lista de servidores syslog que recebem mensagens de registro.
O no logging
exclui o Servidor syslog com o endereço especificado da lista de syslogs.
Configure o software emulador de terminal (por exemplo, HyperTerminal) para que ele possa capturar a saída de depuração em um arquivo. Por exemplo, no HyperTerminal, clique emTransfer
e clique em Capture Text
e escolha as opções apropriadas. Para obter mais informações, consulte Captura de saída de texto do HyperTerminal. Para outro software de emulador de terminal, consulte a documentação do software.
Habilitar timestamps de milissegundos (ms) usando o comando service timestamps
comando:
router(config)#service timestamps debug datetime msec router(config)#service timestamps log datetime msec
Esses comandos adicionam carimbos de hora à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 precedidos por um asterisco (*) de forma a indicar que a data e a hora provavelmente não estão corretas.
Geralmente, é aconselhável configurar os timbres de hora em milisegundos, visto que isso fornece um alto nível de clareza quando se observa saídas de depuração. Os carimbos de hora em milissegundos fornecem uma indicação melhor do tempo dos vários eventos de depuração em relação um ao outro. No entanto, observe que, 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 x25
tudo em uma caixa que tem 200 VCs e a saída é registrada no buffer (usando o comando no logging console
e logging buffered
), o timestamp exibido na saída de depuração (dentro do buffer) não pode ser o horário exato 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.
Para parar uma depuração, use o comandono debug all
orundebug all
comandos. Verifique se as depurações foram desativadas usando o comandoshow debug
.
Lembre-se de que os comandos no logging console
e terminal no monitor
evite apenas que a saída seja gerada no console, Aux ou vty, respectivamente. Ele não interrompe a depuração e, portanto, consome os recursos do roteador.
O debug ip packet
produz informações sobre pacotes que não são comutados rapidamente pelo roteador. Todavia, como ele gera uma saída para cada pacote, a saída pode ser extensiva e, por isso, causar a suspensão do roteador. Por esse motivo, use somente debug ip packet
sob os controles mais rigorosos descritos nesta seção.
A melhor maneira de limitar a saída de 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 a debug ip packet
. Essa lista de acesso não precisa ser aplicada a nenhuma interface, mas sim à operação de depuração.
Antes de usar debugging ip packet
, observe que o roteador está fazendo switching rápida por padrão ou pode estar fazendo switching CEF se configurado para isso. Isso significa que, após aquelas técnicas serem implementadas, o pacote não é fornecido ao processador e, portanto, a depuração não mostra nada. Para que isso funcione, você precisa desativar a switching rápida no roteador com no 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
comando.
A desabilitação da switching rápida em um roteador que lida com um grande número de pacotes pode fazer com que a utilização de CPU aumente, de modo que a caixa trava ou perde sua conexão com os peers.
Não desabilite a comutação rápida em um roteador que executa o Multi Protocol Label Switching (MPLS). O MPLS é usado com o CEF. Portanto, a desativação da switching rápida na interface por ter um efeito desastroso.
Considere este exemplo de cenário:
A lista de acesso configurada no roteador_122 é:
access-list 105 permit icmp host 10.10.10.2 host 10.1.1.1 access-list 105 permit icmp host 10.1.1.1 host 10.10.10.2
Essa lista de acesso permite qualquer pacote ICMP (Internet Control Message Protocol) do host router_121 (com endereço IP 10.10.10.2) para o host router_123 (com endereço IP 10.1.1.1), bem como na outra direção. É importante que você permita os pacotes em qualquer direção, caso contrário o roteador poderá descartar o pacote ICMP de retorno.
Remova o fast-switching em apenas uma interface no router_122. Isso significa que você só pode ver as depurações para os pacotes destinados a essa interface, como visto da perspectiva do Cisco IOS que intercepta o pacote. Nas depurações, esses pacotes aparecem com "d =". Como você ainda não desativou a comutação rápida na outra interface, o pacote de retorno não está sujeito a debug ip packet
. Esta saída mostra como você pode desativar o fast-switching:
router_122(config)#interface virtual-template 1 router_122(config-if)#no ip route-cache router_122(config-if)#end
Agora você deve ativar debug ip packet
com a lista de acesso definida anteriormente (access-list 105).
router_122# debug ip packet detail 105 IP packet debugging is on (detailed) for access list 105 router_122# 00:10:01: IP: s=10.1.1.1 (Serial3/0), d=10.10.10.2 (Virtual-Access1), g=10.10.10.2, len 100, forward 00:10:01: ICMP type=0, code=0 ! -- ICMP packet from 10.1.1.1 to 10.10.10.2. ! -- This packet is displayed because it matches the ! -- source and destination requirements in access list 105 00:10:01: IP: s=10.1.1.1 (Serial3/0), d=10.10.10.2 (Virtual-Access1), g=10.10.10.2, len 100, forward 00:10:01: ICMP type=0, code=0 00:10:01: IP: s=10.1.1.1 (Serial3/0), d=10.10.10.2 (Virtual-Access1), g=10.10.10.2, len 100, forward 00:10:01: ICMP type=0, code=0
Agora, remova a switching rápida na outra interface (no roteador_122). Isso significa que todos os pacotes nessas duas interfaces agora são comutados por pacotes (o que é um requisito para debug ip packet
router_122(config)#interface serial 3/0 router_122(config-if)#no ip route-cache router_122(config-if)#end router_122# 00:11:57: IP: s=10.10.10.2 (Virtual-Access1), d=10.1.1.1 (Serial3/0), g=172.16.1.6, len 100, forward 00:11:57: ICMP type=8, code=0 ! -- ICMP packet (echo) from 10.10.10.2 to 10.1.1.1 00:11:57: IP: s=10.1.1.1 (Serial3/0), d=10.10.10.2 (Virtual-Access1), g=10.10.10.2, len 100, forward 00:11:57: ICMP type=0, code=0 ! -- ICMP return packet (echo-reply) from 10.1.1.1 to 10.10.10.2 00:11:57: IP: s=10.10.10.2 (Virtual-Access1), d=10.1.1.1 (Serial3/0), g=172.16.1.6, len 100, forward 00:11:57: ICMP type=8, code=0 00:11:57: IP: s=10.1.1.1 (Serial3/0), d=10.10.10.2 (Virtual-Access1), g=10.10.10.2, len 100, forward 00:11:57: ICMP type=0, code=0
Observe que o debug ip packet output não mostra nenhum pacote que não corresponda aos critérios da lista de acesso. Para obter mais informações sobre este procedimento, consulte Noções básicas sobre os comandos Ping e Traceroute.
Para obter mais informações sobre como criar listas de acesso, consulte Registro de lista de acesso de IP padrão.
Quando o recurso de depuração disparada condicionalmente está habilitado, o roteador gera mensagens de depuração para pacotes que entram ou saem do roteador em uma interface especificada; o roteador não gera saída de depuração para pacotes que entram ou saem 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 usar o comando debug 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
Habilite a depuração condicional da interface serial 3. Isso significa que somente as depurações para a interface serial 3 são exibidas. Use o debug interface <interface_type interface_number >
comando.
traxbol#debug interface serial 3 Condition 1 set
Use o show debug condition
para verificar se a depuração condicional está ativa. Observe que uma condição para o serial de interface 3 está ativa.
traxbol#show debug condition Condition 1: interface Se3 (1 flags triggered) Flags: Se3 traxbol#
Observe que 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
Use o 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
Agora, você pode observar que a depuração para a interface serial 0 e a serial 3 são exibidas.
*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
Aviso: algumas operações de depuração são condicionais por si só. Um exemplo é a depuração de atm. Com a depuração ATM, você deve especificar explicitamente a interface para a qual as depurações devem ser habilitadas, em vez de habilitar depurações em todas as interfaces ATM e especificar uma condição.
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 atm debugging
em todas as interfaces (com uma condição aplicada), o roteador pode 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 para todas as interfaces será extremamente alta e poderá causar a interrupçã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
Revisão | Data de publicação | Comentários |
---|---|---|
3.0 |
24-Aug-2023 |
Recertificação |
2.0 |
29-Apr-2022 |
Links quebrados atualizados e removidos. |
1.0 |
02-Dec-2013 |
Versão inicial |