Entender os comandos Ping e Traceroute

Introdução

Este documento descreve o uso dos comandos ping e traceroute nos roteadores Cisco.

Pré-requisitos

Requisitos

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

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 rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Conventions

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

Informações de Apoio

Observação: qualquer comando debug usado em um roteador de produção pode causar problemas graves. Leia a seção Usar o comando debug antes de emitir comandos debug.

Neste documento, essa configuração básica será usada para exemplos neste artigo:

Configuração básica de IPs e roteadores

O comando ping

O comando ping é um método muito comum usado para solucionar problemas de acessibilidade dos dispositivos. Usa uma série de mensagens de eco do protocolo Protocolo de controle de mensagens de Internet (ICMP) (ICMP) para determinar:

• Se um host remoto está ativo ou inativo.

• O atraso de ida e volta usado para se comunicar 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 intervalo. O valor padrão desse timeout é dois segundos em Cisco routers.

O valor TTL de um pacote de ping não pode ser mudado.

Este próximo exemplo de código mostra o comando ping depois que o comando debug ip packet detail é ativado.

Aviso: quando o comando debug ip packet detail é usado em um roteador de produção, ele pode causar alta utilização da CPU. Isso pode resultar em uma grave redução de desempenho ou uma interrupção da rede.

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

Router1#ping 172.16.0.12 
Type escape sequence to abort. 
Sending 5, 100-byte ICMP Echos to 172.16.0.12, 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=172.16.12.1 (local), d=172.16.0.12 (Serial0), len 100, 
  sending
Jan 20 15:54:47.491: ICMP type=8, code=0

!--- This is the ICMP packet 172.16.12.1 sent to 172.16.0.12. 
!--- ICMP type=8 corresponds to the echo message. 

Jan 20 15:54:47.523: IP: s=172.16.0.12 (Serial0), d=172.16.12.1 (Serial0), len 100, 
  rcvd 3
Jan 20 15:54:47.527: ICMP type=0, code=0

!--- This is the answer we get from 172.16.0.12. !--- ICMP type=0 corresponds to the echo reply message. 
!--- By default, the repeat count is five times, so there will be five 
!--- echo requests, and five echo replies.
 

Possíveis valores do tipo de ICMP

Tipo de ICMP	Literal
0	echo-reply
3	destination unreachable code 0 = net unreachable 1 = host unreachable 2 = protocol unreachable 3 = port unreachable 4 = fragmentation needed, and DF set 5 = source route failed
4	source-quench
5	reoriente o código 0 = reorienta datagramas para a rede 1 = reorienta datagramas para o host 2 = reorienta datagramas para o tipo de serviço e a rede 3 = reorienta datagramas para o tipo de serviço e o host
6	alternate-address
8	eco
9	router-advertisement
10	router-solicitation
11	código de tempo excedido 0 = Time to Live excedido no trânsito 1 = tempo de remontagem de fragmento excedido
12	problema de parâmetro
13	timestamp-request
14	timestamp-reply
15	requisição de informações
16	information-reply
17	mask-request
18	mask-reply
31	conversion-error
32	mobile-redirect

Possíveis caracteres de saída na instalação de ping

Caractere	Descrição
!	Cada ponto de exclamação indica o recibo de uma resposta.
.	Cada ponto indica que o servidor de rede atingiu o limite de tempo enquanto aguarda uma resposta.
U	Um erro de destino inalcançável PDU foi recebido.
P	A fonte extingue (destino demasiado ocupado).
M	Não foi possível fragmentar.
?	Tipo de pacote desconhecido.
&	Duração de pacote excedida.

Não é possível fazer ping

Se você não conseguir fazer ping em um endereço IP, considere as causas listadas nesta seção.

Problema do roteador

Estes são exemplos de tentativas mal-sucedidas de ping, que podem determinar o problema e o que fazer para resolvê-lo. Este exemplo é mostrado com este diagrama de topologia de rede:

Problemas de roteador

Router1# 
! 
interface Serial0 
ip address 172.16.12.1 255.255.255.0 
no fair-queue 
clockrate 64000 
! 

Router2# 
! 
interface Serial0 
ip address 10.0.2.23 255.255.255.0 
no fair-queue 
clockrate 64000 
! 
interface Serial1 
ip address 172.16.0.12 255.255.255.0 
! 
  

Router3# 
! 
interface Serial0 
ip address 172.16.3.34 255.255.255.0 
no fair-queue 
! 
interface Serial1 
ip address 10.0.3.23 255.255.255.0 
! 

Router4# 
! 
interface Serial0 
ip address 172.16.4.34 255.255.255.0 
no fair-queue 
clockrate 64000 
! 

Tente fazer ping no Router4 a partir do Router1:

Router1#ping 172.16.4.34 

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

Resultados:

Router1#debug ip packet
IP packet debugging is on

Aviso: quando o comando debug ip packet é usado em um roteador de produção, ele pode causar alta utilização da CPU. Isso pode resultar em uma grave redução de desempenho ou uma interrupção da rede. 

Router1#ping 172.16.4.34 

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

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

Como nenhum protocolo de roteamento é executado no Router1, ele não sabe para onde enviar o pacote e gera a mensagem "não roteável".

Adicione uma rota estática ao Router1:

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

Resultados:

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

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

Jan 20 16:05:30.659: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100, 
  sending
Jan 20 16:05:30.663:     ICMP type=8, code=0
Jan 20 16:05:30.691: IP: s=172.16.0.12 (Serial0), d=172.16.12.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=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100, 
  sending
Jan 20 16:05:30.703:     ICMP type=8, code=0
Jan 20 16:05:32.699: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100, 
  sending
Jan 20 16:05:32.703:     ICMP type=8, code=0
Jan 20 16:05:32.731: IP: s=172.16.0.12 (Serial0), d=172.16.12.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=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100, 
  sending
Jan 20 16:05:32.743:     ICMP type=8, code=0

Examine o que há de errado no Router2:

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

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

O Router1 enviou os pacotes corretamente para o Router2, mas o Router2 não sabe como acessar o endereço 172.16.4.34. O Roteador 2 retorna uma mensagem “ICMP não acessível” ao Roteador 1.

Ative o protocolo RIP no Router2 e no Router3:

Router2# 
router rip 
 network 172.16.0.7 
 network 10.0.7.23 
Router3# 
router rip 
 network 10.0.7.23 
 network 172.16.0.34 

Resultados:

Router1#debug ip packet
IP packet debugging is on

Router1#ping 172.16.4.34 

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

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

O Router1 envia os pacotes para o Router4, mas o Router4 não envia uma resposta.

Possível problema no Router4:

Router4#debug ip packet
IP packet debugging is on

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

O Router4 recebe os pacotes ICMP e tenta responder a 172.16.12.1. Porém, como não tem uma rota para essa rede, ocorre uma falha.

Adicione uma rota estática ao Router4:

Router4(config)#ip route 0.0.0.0 0.0.0.0 Serial0

Agora, os dois lados têm acesso um ao outro:

Router1#ping 172.16.4.34 

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

Interface down

Esta é uma situação em que as paradas de interface não funcionam mais. O próximo exemplo é uma tentativa de fazer ping no Router4 a partir do Router1:

Router1#ping 172.16.4.34 

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

Como o roteamento está correto, execute uma solução de problemas passo a passo. Tente fazer ping no Router2:

Router1#ping 172.16.0.12 

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

No exemplo anterior, o problema está entre o Router2 e o Router3. Uma possibilidade é que a interface serial no Router3 tenha sido fechada:

Router3#show ip interface brief 
Serial0   172.16.3.34    YES manual up                      up
Serial1   10.0.3.23    YES manual administratively down   down                      

Isso é simples de corrigir:

Router3#configure terminal 
Enter configuration commands, one per line.  End with CNTL/Z. 
Router3(config)#interface serial1 
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 da lista de acesso

Neste cenário, apenas o tráfego telnet tem permissão para entrar no Router4 através da interface Serial0.

Router4(config)# access-list 100 permit tcp any any eq telnet 
Router4(config)#interface serial0
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 172.16.12.1 host 172.16.4.34
Router1(config)#access-list 100 permit ip host 172.16.4.34 host 172.16.12.1
Router1(config)#end
Router1#debug ip packet 100 
IP packet debugging is on
Router1#debug ip icmp
ICMP packet debugging is on

Tente fazer ping no Router4:

Router1#ping 172.16.4.34 

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

Jan 20 16:34:49.207: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100,
 sending
Jan 20 16:34:49.287: IP: s=172.16.4.34 (Serial0), d=172.16.12.1 (Serial0), len 56,
 rcvd 3
Jan 20 16:34:49.291: ICMP: dst (172.16.12.1) administratively prohibited unreachable
 rcv from 172.16.4.34
Jan 20 16:34:49.295: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100,
 sending
Jan 20 16:34:51.295: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100,
 sending
Jan 20 16:34:51.367: IP: s=172.16.4.34 (Serial0), d=172.16.12.1 (Serial0), len 56,
 rcvd 3
Jan 20 16:34:51.371: ICMP: dst (172.16.12.1) administratively prohibited unreachable
 rcv from 172.16.4.34
Jan 20 16:34:51.379: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100,
 sending

No final de um comando access-list, sempre há um deny all implícito. Isso significa que os pacotes ICMP que entram na interface Serial 0 no Router4 são negados e que o Router 4 envia uma mensagem ICMP de "administratively bidden unreachable" para a origem do pacote original, conforme mostrado na mensagem de debug. A solução é adicionar esta linha no comando access-list:

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

Problema do Address Resolution Protocol (ARP)

Neste cenário, esta é a conexão Ethernet:

Problemas de protocolo ARP

Router4#ping 172.16.100.5 

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

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

Neste exemplo, o ping não funciona devido à mensagem de "falha no encapsulamento". Isso significa que o roteador sabe para qual interface deve enviar o pacote, mas não sabe como fazer isso. Nesse caso, você precisa entender como funciona o protocolo ARP.

ARP é um protocolo usado para mapear o endereço de Camada 2 (endereço MAC) para um endereço de Camada 3 (endereço IP). É possível verificar isso com o comando show arp:

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

Retorne ao problema de "falha no encapsulamento", mas, dessa vez, ative o comando debug arp:

Router4#debug arp 
ARP packet debugging is on 

Router4#ping 172.16.100.5 

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

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

A saída anterior mostra que o Router4 transmite e envia os pacotes para o endereço de transmissão Ethernet FFFF.FFFF.FFFF. Aqui, o 0000.0000.0000 significa que o Router4 procura o endereço MAC do destino 172.16.100.5. Como ele não sabe o endereço MAC, enquanto o ARP é solicitado neste exemplo, ele usa 0000.0000.000 como espaço reservado nos quadros de transmissão enviados pela interface Ethernet 0 e pergunta qual endereço MAC corresponde a 172.16.100.5. Se não houver resposta, o endereço MAC correspondente ao endereço IP na saída do show arp será marcado como incompleto:

Router4#show arp 
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  172.16.100.4               -   0000.0c5d.7a0d  ARPA   Ethernet0
Internet  172.16.100.5               0   Incomplete      ARPA
Internet  172.16.100.7               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 não esteja na tabela ARP, o ping falhará como resultado de "falha no encapsulamento".

Retardo

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

Router1#ping 172.16.0.12 

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

Em redes com um enlace lento ou um retardo longo, dois segundos não são bastante. Você pode alterar esse padrão com um ping estendido:

Router1#ping 
Protocol [ip]: 
Target IP address:  172.16.0.12 
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 172.16.0.12, timeout is 30 seconds: 
!!!!! 
Success rate is 100 percent (5/5), round-trip min/avg/max = 1458/2390/6066 ms 

Para obter mais informações sobre o comando ping estendido, consulte Entender os comandos ping e traceroute estendidos.

No exemplo anterior, quando o limite de tempo foi aumentado, o ping foi realizado.

Observação: o tempo médio de ida e volta é de mais de dois segundos.

Endereço de origem correto

Este exemplo é um cenário comum:

Endereço de origem correto

Adicione uma interface LAN no Router1:

Router1(config)#interface ethernet0
Router1(config-if)#ip address 10.0.0.1 255.255.255.0 

Você pode fazer o ping no Roteador1 de uma estação no LAN. Do Roteador 1 é possível executar o ping do Roteador 2. Mas, a partir de uma estação na LAN, você não pode efetuar ping no Router2.

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 Router2 não tem informações sobre essa nova LAN. Se ele precisar responder a um pacote dessa rede, ele não saberá como lidar com isso.

Router1#debug ip packet
IP packet debugging is on

Aviso: quando o comando debug ip packet é usado em um roteador de produção, ele pode causar alta utilização da CPU. Isso pode resultar em uma grave redução de desempenho ou uma interrupção da rede.

Router1#ping 172.16.0.12 

Type escape sequence to abort. 
Sending 5, 100-byte ICMP Echos to 172.16.0.12, 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=172.16.12.1 (local), d=172.16.0.12 (Serial0), len 100, sending
Jan 20 16:35:54.259: IP: s=172.16.0.12 (Serial0), d=172.16.12.1 (Serial0), len 100, rcvd 3

O exemplo de saída anterior funciona porque o endereço de origem do pacote enviado é 172.16.12.1. Para simular um pacote da LAN, você precisa usar um ping estendido:

Router1#ping 
Protocol [ip]: 
Target IP address: 172.16.0.12 
Repeat count [5]: 
Datagram size [100]: 
Timeout in seconds [2]: 
Extended commands [n]: y 
Source address or interface: 10.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 172.16.0.12, timeout is 2 seconds: 

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

Desta vez, o endereço de origem é 10.0.0.1 e não funciona. Os pacotes são enviados, mas nenhuma resposta é recebida. Para corrigir esse problema, adicione uma rota a 10.0.0.0 no Router2. A regra básica é que o dispositivo com ping também deve saber como enviar a resposta para a origem do ping.

Quedas de fila de entrada altas

Quando um pacote entra no roteador, o roteador tenta encaminhá-lo a um nível de interrupção. Se uma combinação não pode ser encontrada em uma tabela de cache apropriada, o pacote está enfileirado na fila de entrada da interface de entrada a ser processada. Alguns pacotes sempre são processados, mas com a configuração apropriada e nas redes estáveis, a taxa de pacotes processados nunca deve congestionar a fila de entrada. Se a fila de entrada estiver cheia, o pacote será descartado

Embora a interface esteja ativa, você não possa fazer ping no dispositivo devido a muitos descartes na fila de entrada. Você pode verificar os descartes de entrada com o comando show interface.

Router1#show interface Serial0/0/0

Serial0/0/0 is up, line protocol is up 
  
  MTU 1500 bytes, BW 1984 Kbit, DLY 20000 usec, 
     reliability 255/255, txload 69/255, rxload 43/255
  Encapsulation HDLC, loopback not set
  Keepalive set (10 sec)
  Last input 00:00:02, output 00:00:00, output hang never
  Last clearing of "show interface" counters 01:28:49
  Input queue: 76/75/5553/0 (size/max/drops/flushes);
     Total output drops: 1760
  Queueing strategy: Class-based queueing
  Output queue: 29/1000/64/1760 (size/max total/threshold/drops) 
     Conversations  7/129/256 (active/max active/max total)
     Reserved Conversations 4/4 (allocated/max allocated)
     Available Bandwidth 1289 kilobits/sec
  

!--- Output supressed

Como considerado do para output, a queda de fila de entrada é alta. Consulte Solucionar problemas de descartes na fila de entrada e na fila de saída.

O comando Traceroute

O comando traceroute é usado para descobrir as rotas que os pacotes realmente percorrem quando trafegam até o 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 de TTL de 1 faz com que o datagrama atinja o "limite de tempo" assim que chega ao primeiro roteador no caminho. Esse roteador responde com uma mensagem de tempo excedido (TEM) do ICMP, que indica 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 realmente alcancem o outro destino. Como esses datagramas tentam acessar uma porta inválida no host de destino, as mensagens de porta inacessível do ICMP são retornadas e indicam uma porta inacessível. Esse evento sinaliza ao programa Traceroute que ele foi concluído.

A finalidade atrás desta é gravar a fonte de cada Time Exceeded Message ICMP para fornecer um traço do trajeto que o pacote tomou para alcançar o destino.

Router1#traceroute 172.16.4.34 

Type escape sequence to abort. 
Tracing the route to 172.16.4.34 

  1 172.16.0.12 4 msec 4 msec 4 msec 
  2 10.0.3.23 20 msec 16 msec 16 msec 
  3 172.16.4.34 16 msec *  16 msec 
  
Jan 20 16:42:48.611: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 28,
 sending
Jan 20 16:42:48.615:     UDP src=39911, dst=33434
Jan 20 16:42:48.635: IP: s=172.16.0.12 (Serial0), d=172.16.12.1 (Serial0), len 56,
 rcvd 3
Jan 20 16:42:48.639:     ICMP type=11, code=0                     

!--- ICMP Time Exceeded Message from Router2.

Jan 20 16:42:48.643: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 28,
 sending
Jan 20 16:42:48.647:     UDP src=34237, dst=33435
Jan 20 16:42:48.667: IP: s=172.16.0.12 (Serial0), d=172.16.12.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=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 28,
 sending
Jan 20 16:42:48.679:     UDP src=33420, dst=33436
Jan 20 16:42:48.699: IP: s=172.16.0.12 (Serial0), d=172.16.12.1 (Serial0), len 56,
 rcvd 3
Jan 20 16:42:48.703:     ICMP type=11, code=0

Esta é a primeira sequência de pacotes enviada com um TTL=1. O primeiro roteador, neste caso o Router2 (172.16.0.12), descarta o pacote e retorna para a origem (172.16.12.1) a mensagem de ICMP tipo=11. Isso corresponde à Mensagem de tempo excedido.

Jan 20 16:42:48.707: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 28,
 sending
Jan 20 16:42:48.711:     UDP src=35734, dst=33437
Jan 20 16:42:48.743: IP: s=10.0.3.23 (Serial0), d=172.16.12.1 (Serial0), len 56,
 rcvd 3   
Jan 20 16:42:48.747:     ICMP type=11, code=0         

!--- ICMP Time Exceeded Message from Router3.

Jan 20 16:42:48.751: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 28,
 sending
Jan 20 16:42:48.755:     UDP src=36753, dst=33438
Jan 20 16:42:48.787: IP: s=10.0.3.23 (Serial0), d=172.16.12.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=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 28,
 sending
Jan 20 16:42:48.799:     UDP src=36561, dst=33439
Jan 20 16:42:48.827: IP: s=10.0.3.23 (Serial0), d=172.16.12.1 (Serial0), len 56,
 rcvd 3
Jan 20 16:42:48.831:     ICMP type=11, code=0

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

Jan 20 16:42:48.839: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 28,
 sending
Jan 20 16:42:48.843:     UDP src=34327, dst=33440
Jan 20 16:42:48.887: IP: s=172.16.4.34 (Serial0), d=172.16.12.1 (Serial0), len 56,
 rcvd 3
Jan 20 16:42:48.891:     ICMP type=3, code=3

!--- Port Unreachable message from Router4.
                      
Jan 20 16:42:48.895: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 28,
 sending
Jan 20 16:42:48.899:     UDP src=37534, dst=33441
Jan 20 16:42:51.895: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 28,
 sending
Jan 20 16:42:51.899:     UDP src=37181, dst=33442
Jan 20 16:42:51.943: IP: s=172.16.4.34 (Serial0), d=172.16.12.1 (Serial0), len 56,
 rcvd 3
Jan 20 16:42:51.947:     ICMP type=3, code=3

Com um TTL=3, o Router4 é finalmente acessado. 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 próxima tabela lista os caracteres que podem aparecer na saída do comando traceroute.

Caracteres de texto traceroute de IP

Caractere	Descrição
nn msec	Para cada nó, o Round-Trip Time nos milissegundos para o número especificado de pontas de prova
*	O tempo da prova esgotou
R	Administrativamente proibido (exemplo, lista de acesso)
P	Contenção de origem (destino muito ocupado)
I	Teste interrupção do usuário
U	Porta inalcançável
H	Host inalcançável
N	Rede inacessível
P	Protocolo inacessível
T	Timeout
?	Tipo de pacote desconhecido

Desempenho

Você pode obter o tempo de ida e volta (RTT) com os comandos ping e traceroute. Esse é o tempo necessário para enviar um pacote de eco e obter uma resposta. Isso pode dar uma ideia aproximada do atraso no link. Contudo, estas figuras não são precisas bastante ser usadas para a avaliação de desempenho.

Quando um destino do pacote é o roteador próprio, este pacote tem que ser comutado por processamento. O processador precisa lidar com as informações desse pacote e enviar uma resposta. Este não é o principal objetivo de um roteador. Por definição, um roteador é construído para rotear pacotes. Um ping respondido é oferecido como o melhor serviço possível.

Para ilustrar isso, este é um exemplo de ping do Router1 para o Router2:

Router1#ping 172.16.0.12 

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

O RTT é aproximadamente quatro milissegundos. Depois que você permite alguns recursos de processo intensivos em Roteador 2, tente executar o ping no Roteador 2 do Roteador 1.

Router1#ping 172.16.0.12 

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

O RTT aumentou dramaticamente. O Router2 está bastante ocupado e a prioridade é não responder ao ping. Uma maneira melhor de testar o desempenho do roteador é com o tráfego que passa pelo roteador.

Tráfego através do roteador

O tráfego é comutado rapidamente e tratado pelo roteador com a mais alta prioridade. A rede básica ilustra isso:

Rede básica com 3 roteadores

Ping no Router3 a partir do Router1:

Router1#ping 10.0.3.23 

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

O tráfego passa pelo Router2 e agora é comutado rapidamente. Ative o recurso de processo intensivo no Router2:

Router1#ping 10.0.3.23 

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

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

Utilizar o comando debug

Antes de utilizar comandos debug, consulte Informações Importantes sobre Comandos Debug.

Os diferentes comandos debug usados neste artigo mostram o que acontece quando um comando ping ou traceroute é usado. Esses comandos podem ajudar você a solucionar problemas. No entanto, em um ambiente de produção, os debugs devem ser usados com cuidado. Se seu CPU não é poderoso, ou se você tem muitos pacotes comutados por processamento, estes podem facilmente parar seu dispositivo. Há diversas maneiras de minimizar o impacto do comando debug no roteador. Uma maneira é usar listas de acesso para restringir o tráfego específico a ser monitorado.

Aqui está 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 172.16.12.1 host 172.16.4.34 
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 172.16.12.1 host 172.16.4.34 (5 matches) 

Com essa configuração, o Roteador4 imprime apenas a mensagem de depuração que coincide com a lista de acesso 150. Um ping a partir do Router1 faz com que esta mensagem seja exibida:

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

A resposta para o problema não vem do Router4 porque esses pacotes não correspondem a access-list. Para vê-los, adicione:

Router4(config)#access-list 150 permit ip host 172.16.12.1 host 172.16.4.34 
Router4(config)#access-list 150 permit ip host 172.16.4.34 host 172.16.12.1 

Resultados:

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

Outra maneira de reduzir o impacto do comando debug é armazenar em buffer as mensagens de debug e exibi-las com o comando show log assim que o debug for desativado:

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 172.16.12.1 

Type escape sequence to abort. 
Sending 5, 100-byte ICMP Echos to 172.16.12.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=172.16.4.34 (local), d=172.16.12.1 (Serial0), len 100,
 sending
Jan 20 16:55:46.679: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100,
 rcvd 3

Os comandos ping e traceroute são utilitários úteis que você pode usar para solucionar problemas de acesso à rede. Eles também são muito fáceis de utilizar. Esses dois comandos são amplamente usados pelos engenheiros de rede.

Informações Relacionadas

• Entender os comandos ping e traceroute estendidos
• Suporte Técnico - Cisco Systems