Que protocolo é usado para testes de conectividade em rede com o comando ping?

Introduction

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

Prerequisites

Requirements

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.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Conventions

For more information on document conventions, refer to the Cisco Technical Tips Conventions.

Informações de Apoio

Note: Qualquer comando debug usado em um roteador de produção pode causar problemas sérios. Leia a seção Use the Debug Command antes de executar os comandos debug .

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

O comando ping

O comando ping é um método muito comum usado para solucionar problemas de acessibilidade de 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 é habilitado.

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 degradação do 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.

Valores possíveis do tipo ICMP

Possíveis caracteres de saída do recurso de ping

Não é possível fazer ping

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

Problema do roteador

Aqui estão exemplos de tentativas de ping malsucedidas, que podem determinar o problema, e o que fazer para resolver o problema. Este exemplo é mostrado com este diagrama de topologia de rede:

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 de Router4 de 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 degradação do 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 seu pacote e causa uma mensagem "não roteável".

Adicione uma rota estática 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

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 está errado no Roteador2:

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 Roteador 1 enviou corretamente seus pacotes ao Roteador 2, mas o Roteador 2 não sabe como acessar o endereço 172.16.4.34. O Roteador 2 retorna uma mensagem "ICMP inalcançável" ao Roteador 1.

Ative o Routing Information Protocol (RIP) nos roteadores 2 e 3:

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 Roteador 1 envia pacotes ao Roteador 4, mas o Roteador 4 não envia uma resposta de volta.

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 Roteador 4 recebe os pacotes ICMP e tenta responder a 172.16.12.1, mas como não tem uma rota para essa rede, ele falha.

Adicione uma rota estática ao Roteador4:

Router4(config)#ip route 0.0.0.0 0.0.0.0 Serial0

Agora ambos os lados podem acessar 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

Essa é uma situação em que a interface pára e não funciona mais. Neste próximo exemplo, há uma tentativa de fazer ping do Router1 para o 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)

Como o roteamento está correto, faça um troubleshooting passo a passo do problema. Tente fazer ping de 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

A partir do exemplo anterior, o problema está entre o Roteador2 e o Roteador3. Uma possibilidade é que a interface serial no Roteador3 tenha sido desativada:

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, somente o tráfego telnet tem permissão para entrar no Roteador 4 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 , há sempre um deny all implícito. Isso significa que os pacotes ICMP que entram na interface Serial 0 no Router4 são negados, e o Router 4 envia uma mensagem ICMP "administratively bidden unreachable" para a origem do pacote original, como mostrado na mensagem 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:

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 "encapsulation failed". Isso significa que o roteador sabe em que interface deve enviar o pacote, mas não sabe como fazê-lo. Nesse caso, você precisa entender como o Address Resolution Protocol (ARP) funciona.

O 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). Você pode 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 "encapsulation failed", mas desta vez habilite 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 Roteador4 envia pacotes por broadcast e os envia para o endereço de broadcast Ethernet FFFF.FFFF.FFFF. Aqui, 0000.0000.0000 significa que o Roteador4 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 000.0000.000 como um espaço reservado nos quadros de broadcast enviados da interface Ethernet 0 e pergunta qual endereço MAC corresponde a 172.16.100.5. Se não houver resposta, o endereço MAC que corresponde ao endereço IP na saída de show arp é 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 de 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 Compreender os Comandos Ping Estendido e Traceroute Estendido .

No exemplo anterior, quando o tempo limite foi aumentado, o ping teve êxito.

Note: O tempo médio de round-trip é maior do que dois segundos.

Endereço de origem correto

Este exemplo é um cenário comum:

Adicione uma interface LAN ao Router1:

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

A partir de uma estação na LAN, você pode fazer ping no Roteador 1. A partir do Roteador 1 você pode fazer ping no Roteador 2. Mas a partir de uma estação na LAN, você não pode fazer ping no 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 informações sobre essa nova LAN. Se tiver que responder a um pacote dessa rede, ele não saberá como tratá-lo.

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 degradação do 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 Roteador 2. A regra básica é que o dispositivo que recebeu o 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 e você não possa fazer ping no dispositivo devido a quedas altas na fila de entrada. Você pode verificar as quedas 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 Perdas de Filas de Entrada e Saída para solucionar problemas de perdas de filas de Entrada/Saída.

O comando Traceroute

O comando traceroute é usado para descobrir as rotas que os pacotes realmente fazem quando trafegam 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 provoca "timeout" no datagrama assim que este bate o primeiro roteador no trajeto; esse roteador responde com uma mensagem de tempo excedido (TEM) 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, mensagens ICMP de porta inalcançável são retornadas e indicam uma porta inalcançável; este sinais de evento o programa Traceroute que está terminado.

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

Essa é a primeira sequência de pacotes enviada com um TTL=1. O primeiro roteador, nesse caso, o Roteador2 (172.16.0.12), descarta o pacote e envia de volta à origem (172.16.12.1) uma mensagem 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 Roteador4 é finalmente alcançado. 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

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 fornecer 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 um serviço de melhor esforço.

Para ilustrar isso, este é um exemplo de um ping do Roteador 1 para o Roteador 2:

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

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

Faça ping no Roteador 3 a partir do Roteador 1:

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 Roteador 2 e agora é comutado rapidamente. Ative o recurso de processamento intensivo no Roteador 2:

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 ajudá-lo a solucionar problemas. No entanto, em um ambiente de produção, as depurações devem ser usadas 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 Roteador 4 imprime apenas a mensagem de depuração que corresponde à lista de acesso 150. Um ping do Roteador 1 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 à lista de acesso. 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 depuração e exibi-las com o comando show log depois que a depuração for desativada:

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

Qual protocolo de rede é usado no comando ping?

O que é teste ICMP?

Qual é a função do protocolo ICMP?

Como fazer o teste de ping?