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

Informações Importantes sobre Comandos de Depuração

19 Setembro 2015 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Tradução Manual (1 Julho 2009) | Inglês (22 Agosto 2015) | Feedback


Índice


Introdução

Esta página fornece algumas diretrizes gerais na utilização debuga disponível em Plataformas do � do Cisco IOS, assim como exemplos para corretamente usar o comando debug ip packet e o debugging condicional.

Nota: Este documento não explica como usar e interpretar comandos debug e saídas específicos. Refira a documentação de referência apropriada do comando Debug de Cisco para obter informações sobre dos comandos debug específicos.

A saída dos comandos debug privileged exec fornece a informação de diagnóstico que incluem uma variedade de eventos de comunicação inter-redes em relação ao status do protocolo e à atividade de rede geralmente.

Pré-requisitos

Requisitos

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

  • Conectando ao roteador que usa o console, auxiliar e portas VTY

  • Edições gerais da configuração do IOS da Cisco

  • Interpretando resultados do debug 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 sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.

Avisos

Use comandos 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. Daqui, se registrar é permitido, o servidor de acesso pode intermitentemente congelar-se assim que a porta de Console obtiver sobrecarregada com os mensagens de registro.

Antes que você comece um comando debug, considere sempre a saída que este comando gerará e a quantidade de tempo isto pode tomar. Por exemplo, se você tem um roteador com um Basic Rate Interface (BRI), debugar o q931 de ISDN provavelmente não prejudicará o sistema. Mas, fazendo o mesmos debugar em um AS5800 com configuração E1 completa pode provavelmente gerar tanto a entrada que pode pendurar e parar de responder.

Antes de debugar, olhe sua carga de CPU com o comando show processes cpu. Verifique que você tem o CPU amplo disponível antes que você comece debugar. Refira pesquisando defeitos a utilização elevada da CPU em roteadores Cisco para obter mais informações sobre de como segurar cargas da alta utilização da CPU. Por exemplo, se você tem um Cisco 7200 Router com uma interface ATM que faz a construção de uma ponte sobre então, segundo a quantidade de subinterfaces configuradas, reiniciando o roteador pôde usar muito seu 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.

Nota: Quando debuga estão sendo executado, você não veem geralmente a alerta de roteador, especialmente quando debugar é intensivo. Mas, na maioria dos casos, você pode usar os comandos no debug all or undebug all a fim parar debuga. Refira a seção que obtém resultados do debug para obter mais informações sobre com segurança da utilização debuga

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ê deve igualmente considerar que relação no roteador você deve conectar. Esta seção tem algumas diretrizes.

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. Instruções e advertências de cada método serão abordadas abaixo:

Porta de Console

Se você é conectado no console, sob configurações normal, nenhum trabalho extra precisa de ser feito. O resultado do debug deve automaticamente ser indicado. Mas, certifique-se que o nível de console de registro está ajustado como desejado e aquele que registra não foi desabilitado com o comando no logging console. Refira a utilização de comandos Debug para mais informação.

aviso aviso: Excessivo debuga à porta de Console de um roteador pode fazer com que pendure. 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.

Nota: À revelia, registrar é permitido 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. Daqui, Cisco recomenda que, sob condições de operação normal, você tem o comando no logging console permitido em todas as vezes e usa outros métodos para capturar debuga. Nas situações em que é necessário o uso de console, ative temporariamente o console de logon.

Porto auxiliar

Se você é conectado através de um porto auxiliar, datilografe o comando terminal monitor. Verifique também se o comando no logging on não foi ativado no roteador.

Nota: Se você usa o porto auxiliar para monitorar o roteador, mantenha na mente que, quando as repartições do roteador, o porto auxiliar não indicam as saídas de sequência de inicialização. Conecte à porta de Console a fim ver a sequência de inicialização.

Portas VTY

Se você é conectado através de um porto auxiliar ou através do telnet, datilografe o comando terminal monitor. Verifique também se nenhum comando de registro foi usado.

Registrando as mensagens em um buffer interno

O dispositivo de logging padrão é o console; todas as mensagens são indicadas no console salvo disposição em contrário.

Para registrar mensagens em um buffer interno, use o comando logging buffered router configuration. Esta é a sintaxe cheia deste comando:

logging buffered
no logging buffered

O comando logging buffered copia mensagens de registro a um buffer interno em vez de escrevê-los ao 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 para mostrar o registro. A primeira mensagem indicada é a mensagem a mais velha no buffer. Você pode especificar o tamanho do buffer e também o nível de gravidade das mensagens a serem registradas.

Dica: Faça a certo bastante memória está disponível na caixa antes de incorporar o tamanho de buffer. Use o comando show proc mem do Cisco IOS a fim 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).

Registrando mensagens para um UNIX Syslog Server

Para registrar mensagens no host do servidor syslog, use o comando logging router configuration. A sintaxe completa deste comando é:

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

O comando logging identifica um host de servidor de syslog para receber mensagens de registro. O argumento < do IP address > é o endereço IP de Um ou Mais Servidores Cisco ICM NT do host. Emitindo este comando mais de uma vez, você constrói uma lista de servidores de SYSLOG que recebem mensagens de registro.

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

Para obter mais informações sobre de estabelecer um servidor de SYSLOG, refira a utilização de comandos Debug.

Outras tarefas de pré-depuração

  1. Setup seu software de simulador terminal (por exemplo, HyperTerminal) de modo que possa capturar o resultado do debug a um arquivo. Por exemplo, no HyperTerminal, transferência do clique, clica então o texto da captação, e escolhe as opções apropriadas. Para mais informação, refira a captura de saídas de texto do HyperTerminal. Para o outro software de simulador terminal, refira a documentação de software.

  2. Habilite timbres de hora de milissegundos (ms) com o comando service timestamps:

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

Estes selos de tempo dos comandos add a debugam no formato MMM DD HH: MILÍMETRO: SS, indicando a data e hora de acordo com o relógio de 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 formatos de tempo de milisegundo fornecem uma indicação melhor do sincronismo do vário debugam os eventos relativos a. Contudo, note que, quando as saídas de porta de Console muitas mensagens, elas não puderam correlacionar com a cronometragem real do evento. Por exemplo, se você permite o debug x25 all em uma caixa que tenha 200 VC, e a saída é registrada ao buffer (que usa os comandos no logging console and logging buffered), o timestamp indicado no resultado do debug (dentro do buffer) não pôde ser o tempo exato em que o pacote passa através da relação. 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 a depuração

Para parar debugar, use os comandos no debug all or undebug all. Verifique que debuga estiveram girados fora de usar o comando show debug.

Recorde que os comandos no logging console e terminal no monitor impedem somente que a saída estado output no console, auxiliar ou vty respectivamente. Ele não interrompe a depuração e, portanto, consome os recursos do roteador.

Usando o comando debug ip packet

O comando 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 essa razão, somente utilize debug ip packet sob os controles mais estritos, como descrito nesta seção.

A melhor maneira de limitar a saída do debug ip packet é criar uma lista de acesso vinculada à depuração. Somente os pacotes que combinam os critérios da lista de acesso serão sujeitos debugar o pacote IP. Esta lista de acesso não precisa de ser aplicada em nenhuma relação, mas é aplicada um pouco à operação debugar.

Antes de usar a depuração no pacote, observe que o roteador está realizando por padrão a switching rápida ou poderá realizar a switching CEF caso esteja 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 isto trabalhe, você precisa de desabilitar o switching rápido no roteador sem o cache de rota IP (para pacotes do unicast) ou o no ip mroute-cache (para pacotes de transmissão múltipla). Isto deve ser aplicado nas interfaces nas quais supostamente o tráfego deve fluir. Verifique isto com o comando show ip route.

Avisos:

  • 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 conjuntamente 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:

http://www.cisco.com/c/dam/en/us/support/docs/dial-access/integrated-services-digital-networks-isdn-channel-associated-signaling-cas/10374-debug1.gif

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

Esta lista de acessos permite todo o pacote do Internet Control Message Protocol (ICMP) do host router_121 (com endereço IP 10.10.10.2) hospedar router_123 (com endereço IP 13.1.1.1) assim como no outro sentido. É importante permitir que os pacotes trafeguem nos dois sentidos ou o roteador poderá descartar o pacote de ICMP de retorno.

Remova o switching rápido em somente uma relação no roteador_122. Isto significa que você pode somente ver que debuga para os pacotes que são destinados para essa relação, como visto da perspectiva dos IO que interceptam o pacote. Do debuga, tais pacotes aparecem com “d=”. Desde que você não girou ainda fora rapidamente ligar a outra relação, o pacote de informação de retorno não é sujeito debugar o pacote IP. Esta saída mostra como você pode desabilitar o interruptor rápido:

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

Você deve agora ativar debuga o pacote IP com a lista de acesso definida mais cedo (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 

! -- 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 estão 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 

! -- 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

Note que a saída do pacote debugar IP não mostra nenhuns pacotes que não combinam os critérios da lista de acesso. Para algumas informações adicionais sobre deste procedimento, refira a compreensão dos comandos ping and traceroute.

Para obter mais informações sobre de como construir listas de acesso, refira o Standard IP Access List Logging.

Depurações disparadas condicionalmente

Quando a característica de debugging condicionalmente provocada é permitida, o roteador gera mensagens de debugging para os pacotes que inscrevem ou que deixam o 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. Para obter informações sobre dos usos para condicional debuga, referem a eliminação de erros condicionalmente provocada.

Olhe uma aplicação simples de condicional debuga. Considere esta encenação: o roteador mostrado abaixo (trabol) tem duas relações (serial0 e série 3) ambas encapsulamento de HDLC sendo executado.

Você pode usar o comando normal debug serial interface a fim observar as manutenções de atividade de HDLC recebidas em todas as relações. Você pode observar o Keepalives em ambas as relações.

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

Permita os debug condicional para interface serial 3. Isto significa que que debuga somente para a série 3 da relação são indicados. Use o comando debug interface <interface_type interface_number>.

traxbol#debug interface serial 3 
Condition 1 set

Use o comando show debug condition a fim verificar que o condional debuga é ativo. 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 comando undebug interface <interface_type interface_number> a fim remover o condicional debugam. Recomenda-se que você gira fora debuga (por exemplo, usando o undebug todo) antes que você remova o disparador 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

Você pode agora observar que que debuga para ambo o interface serial 0 assim como série 3 são indicados.

*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 da eliminação de erros são condicionais sós. Um exemplo é eliminação de erros 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 limitar o pacote ATM que debuga 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 tentar ativar o atm debugging em todas as interface (com uma condição aplicada), o roteador poderá ser desconectado caso possua um número grande de subinterfaces ATM. Um exemplo do método incorreto para depuração ATM é fornecido.

Neste caso você pode ver que uma circunstância é aplicada mas você igualmente vê que esta não tem nenhum efeito. Você pode ainda ver o pacote da outra relação. Neste cenário de laboratório você tem somente dois relações e muito tráfegos pequenos. Se o número de relações é alto, a seguir o resultado do debug para todas as relações é extremamente alta e pode fazer com que o roteador pendure.

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

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.


Informações Relacionadas


Document ID: 10374