IntroductionEste documento descreve o uso dos comandos ping e traceroute nos roteadores Cisco. Show
PrerequisitesRequirementsNão existem requisitos específicos para este documento. Componentes UtilizadosEste 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. ConventionsFor more information on document conventions, refer to the Cisco Technical Tips Conventions. Informações de ApoioNote: 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 pingO 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:
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:
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. Valores possíveis do tipo ICMP
Possíveis caracteres de saída do recurso de ping
Não é possível fazer pingSe você não conseguir fazer ping com êxito em um endereço IP, considere as causas listadas nesta seção. Problema do roteadorAqui 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:
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 downEssa é 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 acessoNeste 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: 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". RetardoPor 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 corretoEste 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 altasQuando 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. 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 TracerouteO 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: 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
DesempenhoVocê 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 debugAntes 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: 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: 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
Qual protocolo de rede é usado no comando ping?O ping é um comando utilizado para testes de conectividade entre dois hosts, que utiliza o protocolo ICMP (Internet Control Message Protocol), que por sua vez atua na camada 3 do modelo OSI (Camada de rede).
O que é teste ICMP?O PROTOCOLO DE MENSAGENS DE CONTROLE DA INTERNET ou ICMP é usado principalmente para verificar a disponibilidade de um determinado dispositivo de rede e, ao mesmo tempo, garantir que o pacote de dados enviados chegue ao seu ponto de destino sem perdas.
Qual é a função do protocolo ICMP?Como funciona o ICMP? Ao contrário do protocolo de internet (IP), o ICMP não está associado a um protocolo de camada de transporte como TCP ou UDP. Isso torna o ICMP um protocolo sem conexão: um dispositivo não precisa abrir uma conexão com outro dispositivo antes de enviar uma mensagem ICMP.
Como fazer o teste de ping?Clique no ícone 'Comando' ou 'CMD'. A janela de Prompt de comando será aberta. Na primeira linha, digite PING e, em seguida, o endereço IP (exemplo: PING 10.26.76.1). Em seguida, pressione a tecla Enter.
|
Que protocolo é usado para testes de conectividade em rede com o comando ping?
Postagens relacionadas
direito autoral © 2024 cemle Inc.
