Software Cisco IOS e NX-OS : Software Cisco IOS versões 12.1 Mainline

Entendendo os Comandos Ping e Traceroute

2 Abril 2008 - Tradução Manual
Outras Versões: Versão em PDFpdf | Tradução por Computador (29 Julho 2013) | Inglês (29 Novembro 2006) | Feedback


Índice

Introdução
Pré-requisitos
     Requisitos
     Componentes usados
     Convenções
Informações complementares
O Comando Ping
Por Que Eu Não Consigo Fazer um Ping?
     Problema de roteamento
     Interface inativa
     Comando de lista de acesso
     Problema de Protocolo de Resolução de Endereço (ARP)
     Retardo
     Endereço de Origem Correto
O Comando Traceroute
Desempenho
Use o Comando Debug.
Discussões relacionadas da comunidade de suporte da Cisco
Informações relacionadas

Introdução

Este documento ilustra o uso dos comandos ping e traceroute. Com o auxílio de alguns comandos debug, este documento captura uma visão mais detalhada da forma como estes comandos funcionam.

Observação: A habilitação de qualquer comando debug em um roteador de produção pode causar problemas sérios. Recomendamos que você leia atentamente a seção Usando o Comando Debug antes de executar os comandos debug.

Pré-requisitos

Requisitos

Não existem requisitos específicos para este documento.

Componentes usados

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

As informações apresentadas neste documento foram criadas a partir dos dispositivos em um ambiente de laboratório específico. Todos os dispositivos usados neste documento começaram com uma configuração vazia (padrão). Se a sua rede estiver ativa, certifique-se de entender o impacto potencial de todos os comandos.

Convenções

Para obter mais informações sobre convenções de documentos, consulte Convenções de dicas técnicas da Cisco.

Informações complementares

Este documento usa a configuração básica mostrada abaixo como base para os exemplos:

ping_traceroute1.gif

O Comando Ping

O comando ping é um método bastante comum para solucionar problemas de acessibilidade de dispositivos. Ele utiliza uma série de mensagens de eco de Protocolo de Mensagens de Controle da Internet (ICMP) para determinar:

  • Se um host remoto está ativo ou inativo.

  • Retardo round-trip na comunicação com o host.

  • Perda de pacotes.

O comando ping primeiro envia um pacote de requisição de eco a um endereço e depois aguarda uma resposta. O ping será bem-sucedido somente se:

  • a solicitação de eco chega ao destino e

  • o destino é capaz de devolver uma resposta de eco para a origem, em um período predeterminado, denominado expiração. O valor padrão dessa expiração é dois segundos em roteadores Cisco.

Para todas as opções sobre este comando, consulte "Ping” em Comandos de solução de problemas.

Segue um exemplo de saída mostrando o comando ping após a ativação do comando debug ip packet detail:

advertência Advertência: A habilitação de qualquer comando debug ip packet detail em um roteador de produção pode causar alta utilização de CPU. Isto pode resultar em degradação de desempenho ou em interrupção de rede. Recomendamos que você leia atentamente a seção Usando o Comando Debug antes de usar os comandos debug.

Router1#debug ip packet detail 
IP packet debugging is on (detailed)

Router1#ping 12.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.0.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/6/8 ms

Router1#
Jan 20 15:54:47.487: IP: s=12.0.0.1 (local), d=12.0.0.2 (Serial0), len 100,
  sending
Jan 20 15:54:47.491: ICMP type=8, code=0

               !--- Este é o pacote ICMP 12.0.0.1 enviado para 12.0.0.2.
!--- ICMP type=8 corresponde à mensagem de eco. 
            
Jan 20 15:54:47.523: IP: s=12.0.0.2 (Serial0), d=12.0.0.1 (Serial0), len 100,
  rcvd 3
Jan 20 15:54:47.527: ICMP type=0, code=0

               !--- Esta é a resposta recebida de 12.0.0.2.
!--- ICMP type=0 corresponde à mensagem de resposta de eco.
!--- Por padrão, a contagem de repetição é cinco vezes, então haverá cinco
!--- solicitações de eco e cinco respostas de eco.
            
         

A tabela a seguir lista os possíveis valores de tipo de ICMP.

Tipo de ICMP

Literal

0

resposta de eco

3

destino inalcançável

código 0 = rede inalcançável

1 = host inalcançável

2 = protocolo inacessível

3 = porta inacessível

4 = fragmentação necessária e DF definido

5 = falha na rota de origem

4

source-quench

5

redirecionar

código 0 = redireciona datagramas para a rede

1 = redireciona datagramas para o host

2 = redireciona datagramas para o tipo de serviço e rede

3 = redireciona datagramas para o tipo de serviço e host

6

endereço alternativo

8

eco

9

router-advertisement

10

solicitação de o roteador

11

tempo excedido

código 0 = tempo até ao vivo excedido em trânsito 1 = tempo excedido de remontagem de fragmento

12

problema de parâmetro

13

timestamp-request

14

resposta de registro de data e hora

15

requisição de informações

16

resposta de informações

17

mask-request

18

mask-reply

31

conversion-error

32

redirecionamento de celular

A tabela a seguir lista os possíveis caracteres de saída da instalação de ping:

Caractere

Descrição

!

Cada ponto de exclamação indica o recebimento de uma resposta.

.

Cada ponto final indica a expiração do servidor de rede enquanto aguardava uma resposta.

U

Um erro de destino inacessível de PDU foi recebido.

Q

Contenção de origem (destino muito ocupado).

M

Fragmentação não foi possível.

?

Tipo de pacote desconhecido.

&

Duração de pacote excedida.

Por Que Eu Não Consigo Fazer um Ping?

Se você não consegue fazer um ping em um endereço, considere estas opções:

Problema de roteamento

Seguem alguns exemplos de tentativas de ping mal sucedidas, a determinação do problema e a resolução do problema.

Este cenário é explicado com uso do diagrama de topologia de rede a seguir:

ping_traceroute1.gif

            Router 1
!
!
interface Serial0
ip address 12.0.0.1 255.255.255.0
no fair-queue
clockrate 64000
!
!

Router 2
!
!
interface Serial0
ip address 23.0.0.2 255.255.255.0
no fair-queue
clockrate 64000
!
interface Serial1
ip address 12.0.0.2 255.255.255.0
!
!


Router 3
!
!
interface Serial0
ip address 34.0.0.3 255.255.255.0
no fair-queue
!
interface Serial1
ip address 23.0.0.3 255.255.255.0
!
!

Router 4
!
!
interface Serial0
ip address 34.0.0.4 255.255.255.0
no fair-queue
clockrate 64000
!
! 

Tentamos enviar um ping do Roteador 4 ao Roteador 1:

Router1#ping 34.0.0.4

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 34.0.0.4, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

Olhemos mais de perto o que aconteceu:

Router1#debug ip packet
IP packet debugging is on

advertência Advertência: O uso do comando debug ip packet em um roteador de produção pode causar alta utilização de CPU. Isto pode resultar em degradação de desempenho ou em interrupção de rede. Recomendamos que você leia atentamente a seção Usando o Comando Debug antes de usar os comandos debug.

Router1#ping 34.0.0.4

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 34.0.0.4, timeout is 2 seconds:

Jan 20 16:00:25.603: IP: s=12.0.0.1 (local), d=34.0.0.4, len 100, unroutable.
Jan 20 16:00:27.599: IP: s=12.0.0.1 (local), d=34.0.0.4, len 100, unroutable.
Jan 20 16:00:29.599: IP: s=12.0.0.1 (local), d=34.0.0.4, len 100, unroutable.
Jan 20 16:00:31.599: IP: s=12.0.0.1 (local), d=34.0.0.4, len 100, unroutable.
Jan 20 16:00:33.599: IP: s=12.0.0.1 (local), d=34.0.0.4, len 100, unroutable.
Success rate is 0 percent (0/5)

Já que nenhum protocolo de roteamento está em execução no Roteador 1, ele não sabe para onde enviar seu pacote, portanto, recebemos uma mensagem “unroutable”.

Vamos agora adicionar um roteiro estático ao Roteador 1:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#ip route 0.0.0.0 0.0.0.0 Serial0
         

Agora temos:

Router1#debug ip packet detail
IP packet debugging is on (detailed)

Router1#ping 34.0.0.4 
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 34.0.0.4, timeout is 2 seconds:
U.U.U
Success rate is 0 percent (0/5)

Jan 20 16:05:30.659: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 100,
  sending
Jan 20 16:05:30.663:     ICMP type=8, code=0
Jan 20 16:05:30.691: IP: s=12.0.0.2 (Serial0), d=12.0.0.1 (Serial0), len 56,
  rcvd 3
Jan 20 16:05:30.695:     ICMP type=3, code=1
Jan 20 16:05:30.699: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 100,
  sending
Jan 20 16:05:30.703:     ICMP type=8, code=0
Jan 20 16:05:32.699: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 100,
  sending
Jan 20 16:05:32.703:     ICMP type=8, code=0
Jan 20 16:05:32.731: IP: s=12.0.0.2 (Serial0), d=12.0.0.1 (Serial0), len 56,
  rcvd 3
Jan 20 16:05:32.735:     ICMP type=3, code=1
Jan 20 16:05:32.739: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 100,
  sending
Jan 20 16:05:32.743:     ICMP type=8, code=0

Examinemos o que há de errado com o Roteador 2:

Router2#debug ip packet detail
IP packet debugging is on (detailed)

Router2#
Jan 20 16:10:41.907: IP: s=12.0.0.1 (Serial1), d=34.0.0.4, len 100, unroutable
Jan 20 16:10:41.911:     ICMP type=8, code=0
Jan 20 16:10:41.915: IP: s=12.0.0.2 (local), d=12.0.0.1 (Serial1), len 56, sending
Jan 20 16:10:41.919:     ICMP type=3, code=1
Jan 20 16:10:41.947: IP: s=12.0.0.1 (Serial1), d=34.0.0.4, len 100, unroutable
Jan 20 16:10:41.951:     ICMP type=8, code=0
Jan 20 16:10:43.943: IP: s=12.0.0.1 (Serial1), d=34.0.0.4, len 100, unroutable
Jan 20 16:10:43.947:     ICMP type=8, code=0
Jan 20 16:10:43.951: IP: s=12.0.0.2 (local), d=12.0.0.1 (Serial1), len 56, sending
Jan 20 16:10:43.955:     ICMP type=3, code=1
Jan 20 16:10:43.983: IP: s=12.0.0.1 (Serial1), d=34.0.0.4, len 100, unroutable
Jan 20 16:10:43.987:     ICMP type=8, code=0
Jan 20 16:10:45.979: IP: s=12.0.0.1 (Serial1), d=34.0.0.4, len 100, unroutable
Jan 20 16:10:45.983:     ICMP type=8, code=0
Jan 20 16:10:45.987: IP: s=12.0.0.2 (local), d=12.0.0.1 (Serial1), len 56, sending
Jan 20 16:10:45.991:     ICMP type=3, code=1 

O roteador 1 está enviando seus pacotes corretamente para o roteador 2, mas este não sabe como acessar o endereço 34.0.0.4. O roteador 2 envia uma mensagem de "ICMP inacessível" para o roteador 1.

Agora vamos habilitar o Routing Information Protocol (RIP) no Roteador 2 e no Roteador 3:

Router2#
router rip
 network 12.0.0.0
 network 23.0.0.0
Router3#
router rip
 network 23.0.0.0
 network 34.0.0.0 

Agora temos:

Router1#debug ip packet
IP packet debugging is on

Router1#ping 34.0.0.4 

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 34.0.0.4, timeout is 2 seconds:

Jan 20 16:16:13.367: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 100,
 sending.
Jan 20 16:16:15.363: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 100,
 sending.
Jan 20 16:16:17.363: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 100,
 sending.
Jan 20 16:16:19.363: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 100,
 sending.
Jan 20 16:16:21.363: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 100,
 sending.
Success rate is 0 percent (0/5) 

Isso é um pouco melhor. O Roteador 1 está enviando pacotes ao Roteador 4, mas não está obtendo nenhuma resposta do Roteador 4.

Vejamos qual pode ser o problema no roteador 4:

Router4#debug ip packet
IP packet debugging is on

Router4#
Jan 20 16:18:45.903: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100,
  rcvd 3
Jan 20 16:18:45.911: IP: s=34.0.0.4 (local), d=12.0.0.1, len 100, unroutable
Jan 20 16:18:47.903: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100,
  rcvd 3
Jan 20 16:18:47.907: IP: s=34.0.0.4 (local), d=12.0.0.1, len 100, unroutable
Jan 20 16:18:49.903: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100,
  rcvd 3
Jan 20 16:18:49.907: IP: s=34.0.0.4 (local), d=12.0.0.1, len 100, unroutable
Jan 20 16:18:51.903: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100,
  rcvd 3
Jan 20 16:18:51.907: IP: s=34.0.0.4 (local), d=12.0.0.1, len 100, unroutable
Jan 20 16:18:53.903: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100,
  rcvd 3
Jan 20 16:18:53.907: IP: s=34.0.0.4 (local), d=12.0.0.1, len 100, unroutable

O Roteador 4 recebe os pacotes de ICMP e tenta responder à rede 12.0.0.1, mas, como não tem uma rota nessa rede, ele simplesmente falha.

Vamos agora adicionar um roteiro estático ao Roteador 4:

Router4(config)#ip route 0.0.0.0 0.0.0.0 Serial0
         

Agora ele funciona perfeitamente, e ambos os lados podem acessar um ao outro:

Router1#ping 34.0.0.4 

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 34.0.0.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/35/36 ms 

Interface inativa

Esta é uma situação em que a interface pára de funcionar. No exemplo abaixo, tentamos enviar um ping de Roteador1 a Roteador4:

Router1#ping 34.0.0.4 

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 34.0.0.4, timeout is 2 seconds:
U.U.U
Success rate is 0 percent (0/5) 

Como o roteamento está correto, vamos solucionar problemas passo a passo. Primeiro, tentemos fazer um ping no Roteador 2:

Router1#ping 12.0.0.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.0.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms 

De cima, vemos que o problema está entre os roteadores 2 e 3. Uma possibilidade é que a interface de série do roteador 3 foi desligada:

Router3#show ip interface brief 
Serial0   34.0.0.3    YES manual up                      up
Serial1   23.0.0.3    YES manual administratively down   down                      

Isto pode ser solucionado de forma simples:

Router3#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router3(config)#interface s1
Router3(config-if)#no shutdown
Router3(config-if)#
Jan 20 16:20:53.900: %LINK-3-UPDOWN: Interface Serial1, changed state to up
Jan 20 16:20:53.910: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1,
  changed state to up 

Comando de lista de acesso

Nesse cenário, nossa intenção é permitir que somente tráfego telnet entre no Roteador 4 via interface Serial0:

Router4(config)# access-list 100 permit tcp any any eq telnet 
Router4(config)#interface s0
Router4(config-if)#ip access-group 100 in


Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#access-list 100 permit ip host 12.0.0.1 host 34.0.0.4
Router1(config)#access-list 100 permit ip host 34.0.0.4 host 12.0.0.1
Router1(config)#end
Router1#debug ip packet 100
IP packet debugging is on
Router1#debug ip icmp
ICMP packet debugging is on

Consulte a seção Uso do Comando de Depuração para informações sobre como utilizar listas de acesso com comandos debug.

Agora quando tentamos fazer ping de Roteador4, temos o seguinte:

Router1#ping 34.0.0.4

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 34.0.0.4, timeout is 2 seconds:
U.U.U
Success rate is 0 percent (0/5)

Jan 20 16:34:49.207: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 100,
 sending
Jan 20 16:34:49.287: IP: s=34.0.0.4 (Serial0), d=12.0.0.1 (Serial0), len 56,
 rcvd 3
Jan 20 16:34:49.291: ICMP: dst (12.0.0.1) alcançável proibido administrativamente
 rcv from 34.0.0.4
Jan 20 16:34:49.295: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 100,
 sending
Jan 20 16:34:51.295: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 100,
 sending
Jan 20 16:34:51.367: IP: s=34.0.0.4 (Serial0), d=12.0.0.1 (Serial0), len 56,
 rcvd 3
Jan 20 16:34:51.371: ICMP: dst (12.0.0.1) administratively prohibited unreachable
 rcv from 34.0.0.4
Jan 20 16:34:51.379: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 100,
 sending

Ao final de um comando access-list , sempre temos um "deny all" implícito. Isso significa que os pacotes ICMP que estão entrando na interface Serial 0 no roteador 4 são negados e que o roteador 4 envia uma mensagem ICMP de "administratively prohibited unreachable” para a fonte do pacote original, como mostrado na mensagem debug. A solução é adicionar a linha a seguir no comando access-list:

Router4(config)#access-list 100 permit icmp any any
         

Problema de Protocolo de Resolução de Endereço (ARP)

Segue um cenário com uma conexão Ethernet:

ping_traceroute2.gif

Router4#ping 100.0.0.5 

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.0.0.5, timeout is 2 seconds:

Jan 20 17:04:05.167: IP: s=100.0.0.4 (local), d=100.0.0.5 (Ethernet0), len 100,
  sending
Jan 20 17:04:05.171: IP: s=100.0.0.4 (local), d=100.0.0.5 (Ethernet0), len 100,
  encapsulation failed.
Jan 20 17:04:07.167: IP: s=100.0.0.4 (local), d=100.0.0.5 (Ethernet0), len 100,
  sending
Jan 20 17:04:07.171: IP: s=100.0.0.4 (local), d=100.0.0.5 (Ethernet0), len 100,
  encapsulation failed.
Jan 20 17:04:09.175: IP: s=100.0.0.4 (local), d=100.0.0.5 (Ethernet0), len 100,
  sending
Jan 20 17:04:09.183: IP: s=100.0.0.4 (local), d=100.0.0.5 (Ethernet0), len 100,
  encapsulation failed.
Jan 20 17:04:11.175: IP: s=100.0.0.4 (local), d=100.0.0.5 (Ethernet0), len 100,
  sending
Jan 20 17:04:11.179: IP: s=100.0.0.4 (local), d=100.0.0.5 (Ethernet0), len 100,
  encapsulation failed.
Jan 20 17:04:13.175: IP: s=100.0.0.4 (local), d=100.0.0.5 (Ethernet0), len 100,
  sending
Jan 20 17:04:13.179: IP: s=100.0.0.4 (local), d=100.0.0.5 (Ethernet0), len 100,
  encapsulation failed.
Success rate is 0 percent (0/5)
Router4# 

Neste exemplo, o ping não funciona devido a uma falha de encapsulamento. Isso significa que o roteador sabe em que interface ele deve enviar o pacote, mas não sabe como fazê-lo. Neste caso, você deve entender como funciona o Protocolo de resolução de endereço (ARP). Consulte Configurando Métodos de Resolução de Endereço para obter uma explicação detalhada.

Basicamente, o ARP é um protocolo usado para mapear o endereço da camada 2 (endereço MAC) para o endereço da camada 3 (endereço IP). Você pode verificar esse mapeamento usando o comando show arp :

Router4#show arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  100.0.0.4               -   0000.0c5d.7a0d  ARPA   Ethernet0
Internet  100.0.0.1              10   0060.5cf4.a955  ARPA   Ethernet0

Volte para o problema "falha de encapsulamento". Temos uma idéia melhor do problema ao utilizarmos o comando debug :

Router4#debug arp 
ARP packet debugging is on

Router4#ping 100.0.0.5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.0.0.5, timeout is 2 seconds:

Jan 20 17:19:43.843: IP ARP: creating incomplete entry for IP address: 100.0.0.5
  interface Ethernet0
Jan 20 17:19:43.847: IP ARP: sent req src 100.0.0.4 0000.0c5d.7a0d,
                 dst 100.0.0.5 0000.0000.0000 Ethernet0.
Jan 20 17:19:45.843: IP ARP: sent req src 100.0.0.4 0000.0c5d.7a0d,
                 dst 100.0.0.5 0000.0000.0000 Ethernet0.
Jan 20 17:19:47.843: IP ARP: sent req src 100.0.0.4 0000.0c5d.7a0d,
                 dst 100.0.0.5 0000.0000.0000 Ethernet0.
Jan 20 17:19:49.843: IP ARP: sent req src 100.0.0.4 0000.0c5d.7a0d,
                 dst 100.0.0.5 0000.0000.0000 Ethernet0.
Jan 20 17:19:51.843: IP ARP: sent req src 100.0.0.4 0000.0c5d.7a0d,
                 dst 100.0.0.5 0000.0000.0000 Ethernet0.
Success rate is 0 percent (0/5)

A saída acima mostra que o Roteador 4 está fazendo broadcast de pacotes enviando-os para o endereço de difusão de Ethernet FFFF.FFFF.FFFF. Aqui, 0000.0000.0000 significa que o roteador 4 está buscando o endereço MAC do destino 100.0.0.5. Como ele não conhece o endereço MAC durante a solicitação ARP neste exemplo, é usado 0000.0000.000 como placeholder nos quadros de broadcast enviados da interface Ethernet 0, solicitando que endereço MAC corresponde a 100.0.0.5. Se não for obtida uma resposta, o endereço correspondente na saída show arp será marcado como incompleto:

Router4#show arp 
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  100.0.0.4               -   0000.0c5d.7a0d  ARPA   Ethernet0
Internet  100.0.0.5               0   Incompleto      ARPA
Internet  100.0.0.1               2   0060.5cf4.a955  ARPA   Ethernet0

Após um período predeterminado, esta entrada incompleta é removida da tabela ARP. Contanto que o endereço MAC correspondente não esteja na tabela ARP, o ping falha em resultado da falha de encapsulamento.

Retardo

Por padrão, se você não receber uma resposta da extremidade remota dentro de dois segundos, haverá falha de ping:

Router1#ping 12.0.0.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.0.0.2, a expiração é de 2 segundos: 
.....
Success rate is 0 percent (0/5) 

Em redes com link lento ou retardo grande, dois segundos não são suficientes. É possível alterar esse padrão usando um ping estendido:

Router1#ping 
Protocol [ip]:
Target IP address:  12.0.0.2
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]: 30 
Extended commands [n]:
Sweep range of sizes [n]:

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.0.0.2, timeout is 30 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1458/2390/6066 ms 

No exemplo acima, aumentar a expiração levou a um ping bem-sucedido.

Observação: O tempo médio de round-trip é maior do que dois segundos.

Endereço de Origem Correto

Abaixo encontra-se um exemplo de uma situação típica:

ping_traceroute3.gif

Adicionar uma interface LAN ao Roteador1:

Router1(config)#interface e0
Router1(config-if)#ip address
Router1(config-if)#ip address 20.0.0.1 255.255.255.0 
         

A partir da estação na LAN, você pode fazer o ping do roteador 1. A partir do roteador 1, você pode fazer o ping do roteador 2. Mas a partir da estação da LAN, não é possível fazer o ping do roteador 2.

A partir do Roteador 1, é possível executar o ping no Roteador 2 pois, por padrão, você usa o endereço IP da interface de saída como o endereço de origem no seu pacote ICMP. O Roteador2 não tem nenhuma informação sobre esta nova LAN. Se ele tiver que responder para um pacote vindo da rede, ele não sabe como tratar o mesmo.

Router1#debug ip packet
IP packet debugging is on

Advertência: O uso do comando debug ip packet em um roteador de produção pode causar alta utilização de CPU. Isto pode resultar em degradação de desempenho ou em interrupção de rede. Recomendamos que você leia atentamente a seção Usando o Comando Debug antes de usar os comandos debug.

Router1#ping 12.0.0.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.0.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/7/9 ms
Router1#

Jan 20 16:35:54.227: IP: s=12.0.0.1 (local), d=12.0.0.2 (Serial0), len 100, sending
Jan 20 16:35:54.259: IP: s=12.0.0.2 (Serial0), d=12.0.0.1 (Serial0), len 100, rcvd 3

O exemplo de saída acima funciona porque o endereço de origem do pacote enviado é s=12.0.0.1. Se quisermos simular um pacote vindo da LAN, temos que utilizar um ping externo:

Router1#ping
Protocol [ip]:
Target IP address: 12.0.0.2
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 20.0.0.1 
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.0.0.2, timeout is 2 seconds:

Jan 20 16:40:18.303: IP: s=20.0.0.1 (local), d=12.0.0.2 (Serial0), len 100,
 sending.
Jan 20 16:40:20.303: IP: s=20.0.0.1 (local), d=12.0.0.2 (Serial0), len 100,
 sending.
Jan 20 16:40:22.303: IP: s=20.0.0.1 (local), d=12.0.0.2 (Serial0), len 100,
 sending.
Jan 20 16:40:24.303: IP: s=20.0.0.1 (local), d=12.0.0.2 (Serial0), len 100,
 sending
Jan 20 16:40:26.303: IP: s=20.0.0.1 (local), d=12.0.0.2 (Serial0), len 100,
 sending.
Success rate is 0 percent (0/5)

Dessa vez, o endereço de origem é 20.0.0.1 e não está funcionando! Estamos enviando nossos pacotes, mas não estamos recebendo nada. Para corrigir esse problema, temos que adicionar uma rota a 20.0.0.0 no Roteador2.

A regra básica é que o dispositivo que recebeu o ping também deve saber como enviar a resposta à origem do ping.

O Comando Traceroute

O comando traceroute é utilizado para descobrir as rotas que os pacotes fazem quando vão até seu destino. O dispositivo (por exemplo, um roteador ou um PC) envia uma seqüência de datagramas de Protocolo UDP para um endereço de porta inválido no host remoto.

Três datagramas são enviados, cada um com um valor de campo Time-To-Live (TTL) definido como um. O valor TTL de 1 faz com que o datagrama expire assim que atingir o primeiro roteador no caminho; este roteiro então responde com uma mensagem de tempo esgotado (TEM) ICMP indicando que o datagrama expirou.

Outras três mensagens de UDP são agora enviadas, cada uma com o valor de TTL definido como 2, que faz com que o segundo roteador retorne ICMP TEMs. Este processo continua até que os pacotes cheguem ao destino. Como esses datagramas estão tentando acessar uma porta inválida no host de destino, o host responde com mensagens do ICMP indicando porta inalcançável e este evento sinaliza o programa Traceroute que está concluído.

A finalidade por trás do comando traceroute é registrar a origem de cada mensagem de tempo esgotado do ICMP para fornecer um rastreamento do caminho tomado pelo pacote para alcançar o destino. Para obter todas as opções sobre este comando, consulte Trace (privileged).

Router1#traceroute 34.0.0.4 

Type escape sequence to abort.
Tracing the route to 34.0.0.4

  1 12.0.0.2 4 msec 4 msec 4 msec
  2 23.0.0.3 20 msec 16 msec 16 msec
  3 34.0.0.4 16 msec *  16 msec

Jan 20 16:42:48.611: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 28,
 sending
Jan 20 16:42:48.615:     UDP src=39911, dst=33434
Jan 20 16:42:48.635: IP: s=12.0.0.2 (Serial0), d=12.0.0.1 (Serial0), len 56,
 rcvd 3
Jan 20 16:42:48.639:     Tipo de ICMP=11, código=0
            
               !--- Mensagem de tempo esgotado de ICMP do Roteador 2.
            
Jan 20 16:42:48.643: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 28,
 sending
Jan 20 16:42:48.647:     UDP src=34237, dst=33435
Jan 20 16:42:48.667: IP: s=12.0.0.2 (Serial0), d=12.0.0.1 (Serial0), len 56,
 rcvd 3
Jan 20 16:42:48.671:     ICMP type=11, code=0
Jan 20 16:42:48.675: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 28,
 sending
Jan 20 16:42:48.679:     UDP src=33420, dst=33436
Jan 20 16:42:48.699: IP: s=12.0.0.2 (Serial0), d=12.0.0.1 (Serial0), len 56,
 rcvd 3
Jan 20 16:42:48.703:     ICMP type=11, code=0

Esta é a primeira seqüência de pacotes enviada com TTL=1. O primeiro roteador, nesse caso, o Roteador 2 (12.0.0.2), desconecta o pacote e retorna à origem (12.0.0.1) uma mensagem ICMP tipo=11. Isso corresponde à Mensagem de tempo excedido.

Jan 20 16:42:48.707: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 28,
 sending
Jan 20 16:42:48.711:     UDP src=35734, dst=33437
Jan 20 16:42:48.743: IP: s=23.0.0.3 (Serial0), d=12.0.0.1 (Serial0), len 56,
 rcvd 3
Jan 20 16:42:48.747:     Tipo de ICMP=11, código=0
            
               !--- Mensagem de tempo esgotado de ICMP do Roteador 3.
            
Jan 20 16:42:48.751: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 28,
 sending
Jan 20 16:42:48.755:     UDP src=36753, dst=33438
Jan 20 16:42:48.787: IP: s=23.0.0.3 (Serial0), d=12.0.0.1 (Serial0), len 56,
 rcvd 3
Jan 20 16:42:48.791:     ICMP type=11, code=0
Jan 20 16:42:48.795: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 28,
 sending
Jan 20 16:42:48.799:     UDP src=36561, dst=33439
Jan 20 16:42:48.827: IP: s=23.0.0.3 (Serial0), d=12.0.0.1 (Serial0), len 56,
 rcvd 3
Jan 20 16:42:48.831:     ICMP type=11, code=0

O mesmo processo ocorre para o Roteador3 (23.0.0.3) com um TTL=2:

Jan 20 16:42:48.839: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 28,
 sending
Jan 20 16:42:48.843:     UDP src=34327, dst=33440
Jan 20 16:42:48.887: IP: s=34.0.0.4 (Serial0), d=12.0.0.1 (Serial0), len 56,
 rcvd 3
Jan 20 16:42:48.891:     Tipo de ICMP=3, código=3
            
               !--- Mensagem de porta inalcançável do Roteador 4.
            
Jan 20 16:42:48.895: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 28,
 sending
Jan 20 16:42:48.899:     UDP src=37534, dst=33441
Jan 20 16:42:51.895: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 28,
 sending
Jan 20 16:42:51.899:     UDP src=37181, dst=33442
Jan 20 16:42:51.943: IP: s=34.0.0.4 (Serial0), d=12.0.0.1 (Serial0), len 56,
 rcvd 3
Jan 20 16:42:51.947:     ICMP type=3, code=3

Com TTL=3, finalmente chegamos ao Roteador 4. Dessa vez, já que a porta não é válida, o roteador 4 envia de volta para o roteador 1 uma mensagem ICMP com tipo=3, uma mensagem de destino inalcançável e um código=3 de porta inalcançável.

A tabela a seguir lista os caracteres que podem ser exibidos na saída do comando traceroute.

Caracteres de texto traceroute de IP

Caractere

Descrição

nn msec

Para cada nó, o tempo de ida e volta em milissegundos para o número especificado de provas

*

O tempo da prova esgotou

A

Administrativamente proibido (exemplo, lista de acesso)

Q

Contenção de origem (destino muito ocupado)

I

Teste interrompido pelo usuário

U

Porta inalcançável

H

Host inalcançável

N

Rede inacessível

P

Protocolo inacessível

T

Expiração

?

Tipo de pacote desconhecido

Desempenho

Usando os comandos ping e traceroute, conseguimos o tempo de percurso de ida e volta (RTT). Este é o tempo necessário para enviar um pacote de eco e obter uma resposta de volta. Isso pode ser útil para se ter uma idéia do retardo no link. Entretanto, estes valores não são precisos o suficiente para serem utilizados para avaliação de desempenho.

Quando o destino de um pacote é o roteador em si, este pacote tem de ser comutado pelo processo. O processador tem de lidar com as informações do pacote e enviar uma resposta. Este não é o principal objetivo de um roteador. Por definição, um roteador é construído para rotear pacotes. A resposta a um ping é oferecida como um empenho máximo de serviço.

Para ilustrar essa situação, veja um exemplo de um ping do Roteador1 para o Roteador2:

Router1#ping 12.0.0.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.0.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms  

O RTT é de aproximadamente quatro milissegundos. Após habilitar recursos intensivos em processo no roteador 2, tente fazer um ping no roteador 2 do roteador 1.

Router1#ping 12.0.0.2

Type seqüência de escape to abort.
Sending 5, 100-byte ICMP Echos to 12.0.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/25/28 ms

Aqui o RTT aumentou drasticamente. Roteador2 está muito ocupado e responder ao ping não é sua prioridade principal.

Uma forma melhor de testar o desempenho do roteador é com tráfego passando pelo roteador:

ping_traceroute4.gif

O tráfego é rapidamente comutado e é tratado pelo roteador com a prioridade mais alta. Para ilustrar isso, voltemos à rede básica:

ping_traceroute5.gif

Vamos fazer um ping do Roteador 3 ao Roteador 1:

Router1#ping 23.0.0.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 23.0.0.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/32/32 ms 

O tráfego está passando por Roteador2 e agora possui comutação rápida.

Agora habilitamos o recurso intensivo em processo no roteador 2:

Router1#ping 23.0.0.3 

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 23.0.0.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/32/36 ms

Praticamente não há diferença. Isto porque, no Roteador2, os pacotes agora são tratados no nível de interrupção.

Use o Comando Debug.

Antes de emitir comandos debug, consulte Informações Importantes sobre Comandos de Depuração.

Os diferentes comandos debug usados até agora fornecem um insight do que acontece quando usamos um comando ping ou traceroute. Elas também podem ser úteis para a solução de problemas. Entretanto, em um ambiente de produção, os debugs devem ser usados com cuidado. Se a sua CPU não é poderosa ou se você tem vários pacotes comutados por processo, isto pode facilmente interromper o seu dispositivo. Há algumas formas de minimizar o impacto do comando debug sobre o roteador. Uma maneira é usar listas de acesso para restringir o tráfego específico a ser monitorado. Segue um exemplo:

Router4#debug ip packet ? 
  <1-199>      Access list
  <1300-2699>  Access list (expanded range)
  detail       Print more debugging detail

Router4#configure terminal
Router4(config)#access-list 150 permit ip host 12.0.0.1 host 34.0.0.4 
Router4(config)#^Z

Router4#debug ip packet 150 
IP packet debugging is on for access list 150

Router4#show debug 
Generic IP:
  IP packet debugging is on for access list 150

Router4#show access-list
Extended IP access list 150
    permit ip host 12.0.0.1 host 34.0.0.4 (5 matches) 

Com esta configuração, o roteador 4 somente imprime a mensagem de depuração que corresponde à lista de acesso 150. Um comando ping do roteador 1 faz com que a mensagem a seguir seja exibida:

Router4#
Jan 20 16:51:16.911: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100,
 rcvd 3
Jan 20 16:51:17.003: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100,
 rcvd 3
Jan 20 16:51:17.095: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100,
 rcvd 3
Jan 20 16:51:17.187: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100,
 rcvd 3
Jan 20 16:51:17.279: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100,
 rcvd 3

A resposta do Roteador 4 não é mais visível porque tais pacotes não correspondem à lista de acesso. Para visualizá-los, deve-se incluir o seguinte:

Router4(config)#access-list 150 permit ip host 12.0.0.1 host 34.0.0.4 
Router4(config)#access-list 150 permit ip host 34.0.0.4 host 12.0.0.1 
         

Temos então:

Jan 20 16:53:16.527: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100,
 rcvd 3
Jan 20 16:53:16.531: IP: s=34.0.0.4 (local), d=12.0.0.1 (Serial0), len 100,
 sending
Jan 20 16:53:16.627: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100,
 rcvd 3
Jan 20 16:53:16.635: IP: s=34.0.0.4 (local), d=12.0.0.1 (Serial0), len 100,
 sending
Jan 20 16:53:16.727: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100,
 rcvd 3
Jan 20 16:53:16.731: IP: s=34.0.0.4 (local), d=12.0.0.1 (Serial0), len 100,
 sending
Jan 20 16:53:16.823: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100,
 rcvd 3
Jan 20 16:53:16.827: IP: s=34.0.0.4 (local), d=12.0.0.1 (Serial0), len 100,
 sending
Jan 20 16:53:16.919: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100,
 rcvd 3
Jan 20 16:53:16.923: IP: s=34.0.0.4 (local), d=12.0.0.1 (Serial0), len 100,
 sending

Outra maneira de minimizar o impacto do comando debug é colocar em buffer as mensagens de depuração e mostrá-las com o comando show log após a desativação da depuração.

Router4#configure terminal
Router4(config)#no logging console 
Router4(config)#logging buffered 5000 
Router4(config)#^Z

Router4#debug ip packet
IP packet debugging is on
Router4#ping 12.0.0.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.0.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/37 ms

Router4#undebug all 
All possible debugging has been turned off

Router4#show log 
Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)
    Console logging: disabled
    Monitor logging: level debugging, 0 messages logged
    Buffer logging: level debugging, 61 messages logged
    Trap logging: level informational, 59 message lines logged

Log Buffer (5000 bytes):

Jan 20 16:55:46.587: IP: s=34.0.0.4 (local), d=12.0.0.1 (Serial0), len 100,
 sending
Jan 20 16:55:46.679: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100,
 rcvd 3

Conforme você pode ver, os comandos ping e traceroute são utilitários bastante úteis que podem ser usados para solucionar problemas de acesso da rede. Eles também são muito fáceis de utilizar. Como estes dois comandos são mais utilizados por engenheiros de rede, entende-los é crucial para solucionar problemas de conectividade de rede.

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