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.
Esta página fornece algumas diretrizes gerais sobre o uso das depurações disponíveis nas plataformas do Cisco IOS®, bem como exemplos para o uso correto do comando debug ip packet
e debugging condicional.
Note: Este documento não explica como usar e interpretar saídas e comandos debug específicos. Consulte a documentação apropriada de referência de comando de depuração da Cisco para obter informações sobre debug
comandos.
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.
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.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
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
sempre considere a saída que esse comando gerará e a quantidade de 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 vai prejudicar o sistema. Mas, fazer a mesma depuração em um AS5800 com configuração E1 completa provavelmente gerará tanta entrada que ele pode travar e parar de responder.
Antes de depurar, examine 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, dependendo da quantidade de subinterfaces configuradas, reiniciar o roteador pode consumir muita 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 em um momento crítico como este pode fazer com que a utilização da CPU aumente drasticamente e resultar na suspensão ou perda da conectividade da rede.
Note: Quando a depuração está 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 Obtenção de Saídas de Depuração para obter mais informações sobre como usar depurações com segurança.
Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.
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 qual interface do roteador 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. Instruções e advertências de cada método serão abordadas abaixo:
Se você estiver conectado ao console, em configurações normais, nenhum trabalho extra precisará ser feito. A saída de depuração deve ser exibida automaticamente. Mas, certifique-se de que logging console level
é definido como desejado e que o registro não foi desativado com o comando no logging console
comando.
aviso: Depurações excessivas na porta do console de um roteador podem fazer com que ele trave. Isso é porque o roteador prioriza automaticamente a saída do console a frente de outras funções do roteador. Assim, o roteador poderá travar se estiver processando uma grande quantidade de saída para a porta do console. 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.
Note: Por padrão, o registro é ativado na porta do 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 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.
Note: Se você usar a porta Aux para monitorar o roteador, tenha em mente 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 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 log 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.
Tip: 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 em Transfer
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 timbres de hora em milissegundo (msec) 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 data e 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 do console gera muitas mensagens, elas podem não estar relacionadas ao tempo real do evento. Por exemplo, se você habilitar debug x25
tudo em uma caixa com 200 VCs, e a saída é registrada no buffer (usando o comando no logging console
e logging buffered
), o carimbo de data e hora exibido na saída de depuração (dentro do buffer) pode não 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.
Para interromper uma depuração, use o comando no debug all
or undebug all
comandos. 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
só evite que a saída seja saída no console, no Aux ou no 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 isso, use somente debug ip packet
sob os controlos mais rigorosos descritos na presente seção.
A melhor maneira de limitar a saída de debug ip packet
é criar uma lista de acesso vinculada à depuração. Apenas os pacotes que correspondem aos critérios da lista de acesso estarão 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 utilizar debugging ip packet
, observe que o roteador está fazendo fast-switching 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). Isto deve ser aplicado nas interfaces nas quais supostamente 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.
Vamos considerar um exemplo de cenário:
A lista de acesso configurada no roteador_122 é:
access-list 105 permit icmp host 10.10.10.2 host 13.1.1.1 access-list 105 permit icmp host 13.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 13.1.1.1), bem como na outra direção. É importante permitir que os pacotes trafeguem nos dois sentidos ou o roteador poderá descartar o pacote de ICMP de retorno.
Remova o fast-switching em apenas uma interface no router_122. Isso significa que você só pode ver as depurações dos pacotes destinados a essa interface, como visto da perspectiva do 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=13.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 13.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=13.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=13.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 vamos remover a switching rápida da 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=13.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 13.1.1.1 00:11:57: IP: s=13.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 13.1.1.1 to 10.10.10.2 00:11:57: IP: s=10.10.10.2 (Virtual-Access1), d=13.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=13.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 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 abaixo (trabol) tem duas interfaces (serial 0 e serial 3), ambas executando o encapsulamento HDLC.
Você pode usar o 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 may 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, especifique explicitamente a interface em que a depuração deve ser habilitada, 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 |
---|---|---|
2.0 |
29-Apr-2022 |
Links quebrados atualizados e removidos. |
1.0 |
02-Dec-2013 |
Versão inicial |