Discar e acessar : """Integrated Services Digital Networks (ISDN), Channel-Associated Signaling (CAS)"""

Informações Importantes sobre Comandos Debug

1 Julho 2009 - Tradução Manual
Outras Versões: Versão em PDFpdf | Tradução por Computador (13 Setembro 2013) | Inglês (4 Fevereiro 2010) | Feedback

Índice

Introdução
Pré-requisitos
      Requisitos
      Componentes Utilizados
      Avisos
      Convenções
Antes da Depuração
      Obtenção de Saídas de Depuração
      Outras Tarefas Pré-depuração
      Para Interromper a Depuração
Uso do Comando debug ip packet
Depurações Disparadas Condicionalmente
Discussões relacionadas da comunidade de suporte da Cisco

Introdução

Esta página fornece algumas diretrizes gerais sobre como utilizar as depurações disponíveis nas plataformas Cisco IOS®, bem como exemplos de uso adequado do comando debug ip packet e da depuração condicional.

Nota: Este documento não explica como utilizar e interpretar comandos debug específicos e suas saídas. Consulte a documentação apropriada de Referência de Comandos Debug da Cisco para obter informações sobre comandos debug específicos.

A saída dos comandos debug EXEC privilegiados fornece informações de diagnóstico sobre diversos eventos de redes interconectadas relacionados ao status do protocolo e à atividade de rede em geral.

Pré-requisitos

Requisitos

Os leitores deste documento devem estar cientes das seguintes informações:

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

  • Problemas gerais de configuração do IOS.

  • Interpretando saídas de depuração do IOS

Componentes Utilizados

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

As informações apresentadas 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. Se a sua rede estiver em um ambiente de produção, esteja ciente do impacto potencial de qualquer comando antes de utilizá-lo.

Avisos

Utilize os comandos debug com cautela. Geralmente recomenda-se que esses comandos sejam utilizados somente sob a orientação do representante de suporte técnico do roteador durante o troubleshooting de problemas específicos.

A ativação da depuração poderá interromper a operação do roteador quando as redes interconectadas estiverem com condição de carga elevada. Portanto, se o registro em log estiver ativado, o servidor de acesso poderá travar de forma intermitente quando a porta do console ficar sobrecarregada com mensagens de log.

Antes de iniciar um comando debug, considere sempre a saída que ele gerará e o tempo que ele poderá levar. Por exemplo, se você tiver um roteador com uma BRI (interface de taxa básica), o comando debug isdn q931 provavelmente não prejudicará o sistema. No entanto, a execução do mesmo comando debug em um AS5800 com configuração E1 completa provavelmente gerará tanta entrada que ele poderá travar e parar de responder.

Antes da depuração, examine a carga da CPU com o comando show processes cpu. Verifique se a CPU tem capacidade suficiente disponível antes de iniciar as depurações. Para obter mais informações sobre como lidar com cargas elevadas da CPU, consulte o documento Troubleshooting da Utilização Elevada da CPU em Cisco Routers. Por exemplo, se você tiver um Cisco 7200 Router com uma interface ATM servindo de bridge -- dependendo da quantidade de subinterfaces configuradas -- a reinicialização do roteador poderá consumir grande parte de sua CPU. Isso ocorre porque, para cada VC (circuito virtual), um pacote BPDU (Bridge Protocol Data Unit) precisa ser gerado. Iniciar depurações em um momento crítico como esse poderá fazer com que a utilização da CPU aumente drasticamente e resultar em um travamento ou na perda de conectividade da rede.

Nota: Durante a execução de depurações, você normalmente não verá o prompt do roteador, especialmente se elas forem intensivas. Entretanto, na maioria dos casos, você poderá utilizar 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 utilizar depurações com segurança.

Convenções

Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.

Antes da Depuração

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. A seção a seguir contém algumas diretrizes.

Obtenção de Saídas de Depuração

Os roteadores podem exibir saídas de depuração para várias interfaces, incluindo as portas do console, aux e vty. Eles também podem registrar mensagens em um buffer interno de um servidor syslog unix externo. As instruções e limitações de cada método são abordadas abaixo:

Porta do Console

Com configurações normais, se você estiver conectado ao console, nenhum trabalho extra será necessário. A saída da depuração deverá ser exibida automaticamente. Entretanto, verifique se logging console level está definido como desejado e se o registro em log não foi desativado com o comando no logging console. Consulte o documento Utilizando Comandos Debug para obter mais informações.

aviso Aviso: Depurações excessivas na porta do console de um roteador poderão fazer com que ele trave. Isso ocorre porque o roteador prioriza automaticamente a saída do console em relação a 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 das depurações for excessiva, utilize as portas vty (telnet) ou os buffers de log para obter depurações. Mais informações são fornecidas a seguir.

Nota: Por padrão, o recurso de registro em log está ativado na porta do console. Dessa forma, a porta do console sempre processará a saída das depurações, mesmo que você esteja utilizando outra porta ou método (como Aux, vty ou buffer) para capturar a saída. Portanto, recomendamos que, sob condições operacionais normais, você mantenha o comando no logging console sempre ativado e utilize outros métodos para capturar depurações. Nas situações em que for necessário utilizar o console, ative temporariamente o recurso logging console de novo.

Porta Aux

Se estiver conectado por meio de uma porta Auxiliar, digite o comando terminal monitor. Verifique também se o comando no logging on não foi ativado no roteador.

Nota: Se você utilizar a porta Aux para monitorar o roteador, lembre-se de que, quando o roteador for reiniciado, essa porta não exibirá a saída da sequência de inicialização. Para exibi-la, conecte-se à porta do console.

Portas VTY

Se estiver conectado por meio de uma porta Auxiliar ou via telnet, digite o comando terminal monitor. Verifique também se o comando no logging on não foi utilizado.

Registro de Mensagens em um Buffer Interno

O dispositivo de log padrão é o console; todas as mensagens serão exibidas nesse local a menos que especificado de outra forma.

Para registrar mensagens em um buffer interno, utilize o comando logging buffered de configuração do roteador. A sintaxe completa desse comando é apresentada a seguir:

logging buffered
no logging buffered

O comando logging buffered copia as mensagens de log em um buffer interno em vez de gravá-las no console. O buffer é circular por natureza; portanto, as mensagens mais recentes substituem as mais antigas. Para exibir as mensagens registradas no buffer, utilize o comando EXEC privilegiado show logging. A primeira mensagem exibida é a mais antiga no buffer. Você pode especificar o tamanho do buffer, bem como o nível de gravidade das mensagens a serem registradas.

Dica: Verifique se há memória suficiente disponível no roteador antes de especificar o tamanho do buffer. Utilize o comando show proc mem do IOS para ver a memória disponível.

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

Registro de Mensagens em um Servidor Syslog UNIX

Para registrar mensagens no host do servidor syslog, utilize o comando logging de configuração do roteador. A sintaxe completa desse comando é apresentada a seguir:

logging <ip-address>
no logging <ip-address>

O comando logging identifica um host do servidor syslog para receber mensagens de log. O argumento <ip-address> é o endereço IP do host. Executando esse comando mais de uma vez, você criará uma lista de servidores syslog que recebem mensagens de log.

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

Para obter mais informações sobre como configurar um servidor syslog, consulte o documento Utilizando Comandos Debug.

Outras Tarefas Pré-depuração

  1. Configure o software emulador de terminal (por exemplo, HyperTerminal) para capturar a saída da depuração em um arquivo. Por exemplo, no HyperTerminal, clique em Transfer e, em seguida, clique em Capture Text e escolha as opções adequadas. Para obter mais informações, consulte o documento Capturando a Saída de Texto do Hyperterminal. Para outro software emulador de terminal, consulte a documentação correspondente.

  2. Ative marcações de data e hora em milissegundos (ms) com o comando service timestamps:

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

Esses comandos adicionam marcações 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 esse relógio não tiver sido definido, a data e a hora serão precedidas por um asterisco (*) para indicar que provavelmente elas não estão corretas.

Geralmente, é aconselhável configurar essas marcações em milissegundos, pois isso fornece um alto nível de clareza quando se observa as saídas de depurações. As marcações de data e hora em milissegundos fornecem uma indicação melhor do timing entre os diversos eventos de depuração. Entretanto, observe que, quando a porta do console gera muitas mensagens, é possível que elas não estejam correlacionadas ao timing real do evento. Por exemplo, se ativarmos debug x25 em um roteador com 200 VCs, e a saída for registrada no buffer (com os comandos no logging console e logging buffered), a marcação de data e hora exibida na saída da depuração (no buffer) poderá não ser a hora exata em que o pacote passa pela interface. Portanto, não utilize marcações de data e hora em ms para comprovar problemas de desempenho, mas para obter informações relativas sobre quando os eventos ocorrem.

Para Interromper a Depuração

Para interromper uma depuração, utilize os comandos no debug all ou undebug all. Verifique se as depurações foram desativadas utilizando 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 na porta do console, Aux ou vty, respectivamente. Eles não interrompem a depuração e, portanto, consomem recursos do roteador.

Uso do Comando debug ip packet

O comando debug ip packet produz informações sobre os pacotes dos quais o roteador não efetua o switching rápido. Entretanto, como ele gera uma saída para todos os pacotes, a saída poderá ser extensa e, portanto, causar o travamento do roteador. Por essa razão, utilize o comando debug ip packet somente sob os controles mais estritos, conforme descrito nesta seção.

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

Antes de utilizar o comando debugging ip packet, observe que o roteador executa o switching rápido, por padrão, ou poderá executar o switching CEF se estiver configurado para isso. Isso significa que, após essas técnicas serem implementadas, o pacote não é fornecido ao processador e, portanto, a depuração não mostra nada. Para que isso funcione, é necessário desativar o switching rápido no roteador com no ip route-cache (para pacotes de unicast) ou com no ip mroute-cache (para pacotes de multicast). Esse recurso deve ser aplicado nas interfaces nas quais supostamente o tráfego deve fluir. Verifique isso com o comando show ip route.

Avisos:

  • A desativação do switching rápido em um roteador que lida com um grande número de pacotes poderá fazer com que a utilização da CPU aumente, resultando no travamento do roteador ou na perda de sua conexão com os peers.

  • Não desative o switching rápido em um roteador que executa o MPLS (Multi Protocol Label Switching). O MPLS é utilizado junto com o CEF. Portanto, a desativação do switching rápido na interface poderá ter um efeito desastroso.

Vamos considerar um exemplo de cenário:

debug1.gif

A lista de acesso configurada no router_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 no outro sentido. É importante permitir que os pacotes trafeguem nos dois sentidos ou o roteador poderá descartar o pacote ICMP de retorno.

Agora vamos remover o switching rápido somente em uma interface do router_122. Isso significa que só podemos ver as depurações referentes aos pacotes destinados a essa interface, conforme observado sob a perspectiva do IOS que intercepta o pacote. Nas depurações, esses pacotes aparecerão com "d=". Como ainda não desativamos o switching rápido na outra interface, o pacote de retorno não será submetido a debug ip packet. A saída a seguir mostra como desativar o switching rápido:

router_122(config)#interface virtual-template 1
router_122(config-if)#no ip route-cache
router_122(config-if)#end

Agora devemos ativar debug ip packet com a lista de acesso definida anteriormente (lista de acesso 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

! -- Pacote de ICMP de 13.1.1.1 para 10.10.10.2.
! -- Este pacote é exibido porque atende aos
! -- requisitos de origem e destino na lista de acesso 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 o switching rápido da outra interface (no router_122). Isso significa que todos os pacotes nessas duas interfaces estão agora comutados (o que é um requisito do comando 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

! -- Pacote de ICMP (echo) de 10.10.10.2 para 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

! -- Pacote de retorno de ICMP (echo-reply) de 13.1.1.1 para 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 a saída do comando debug ip packet não mostra os pacotes que não atendem aos critérios da lista de acesso. Para obter mais informações sobre esse procedimento, consulte o documento Compreendendo os Comandos Ping e Traceroute.

Para obter mais informações sobre como criar listas de acesso, consulte o documento Configurando Listas de Acesso IP.

Depurações Disparadas Condicionalmente

Quando o recurso de Depuração Disparada Condicionalmente está ativado, o roteador gera mensagens de depuração para os pacotes que entram ou saem através de uma interface especificada; ele não gera uma saída de depuração para os pacotes que entram ou saem através de outra interface. Para obter informações sobre os usos de Depurações Condicionais, consulte o documento Depurações Disparadas Condicionalmente.

Vamos examinar uma implementação simples de depurações condicionais. Considere o seguinte cenário: o roteador mostrado abaixo (trabol) possui duas interfaces (serial 0 e serial 3) que executam o encapsulamento HDLC.

Utilizamos o comando debug serial interface normal para observar os keepalives HDLC recebidos em todas as interfaces. Podemos observar os keepalives nas duas 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

! -- Keepalive HDLC na interface Serial 0

*Mar  8 09:42:34.855: Serial3: HDLC myseq 26, mineseen 26*, yourseen 27, line up

! -- Keepalive HDLC na 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

Agora vamos ativar depurações condicionais para a interface serial 3. Isso significa que somente as depurações dessa interface são exibidas. Utilize o comando debug interface <interface_type interface_number>.

traxbol#debug interface serial 3
Condition 1 set

Utilize o comando show debug condition para verificar se a depuração condicional está ativa. Observe que uma condição para a interface serial 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

Para remover a depuração condicional, utilize o comando undebug interface <interface_type interface_number>. É recomendável desativar as depurações (por exemplo, com debug all) antes de remover o disparador condicional. O objetivo disso é 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, observamos que as depurações das interfaces serial 0 e 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 Aviso: Algumas operações de depuração são condicionais por natureza. Um exemplo é a depuração atm. Com a depuração ATM, você deve especificar explicitamente a interface para as quais as depurações devem ser ativadas, em vez de ativar depurações em todas as interfaces ATM e especificar uma condição.

A seção a seguir 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

!--- Observe que especificamos de forma explícita a subinterface que será usada na depuração

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 poderá travar caso possua um grande número de subinterfaces ATM. Um exemplo do método incorreto para depuração ATM é mostrado.

Nesse caso, observe que uma condição é aplicada, mas não tem nenhum efeito. Ainda é possível ver o pacote da outra interface. Neste cenário de laboratório, temos apenas duas interfaces e pouquíssimo tráfego. Se o número de interfaces for alto, a saída das depurações referente a todas as interfaces será extremamente elevada, o que poderá provocar o travamento do roteador.

arielle-nrp2#show debugging condition
Condition 1: interface AT0/0/0.1 (1 flags triggered)
Flags: AT0/0/0.1

! -- Uma condição para uma interface específica.


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):

! -- Vemos depurações da interface ATM0/0/0/.2, ainda que a condição
! -- especificasse SOMENTE 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):

!--- Vemos também depurações para a interface ATM0/0/0.1, que era o desejado.

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 

Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.


Document ID: 10374