ICMP: Ping e Traceroute

O IP é um protocolo não confiável. Isso significa que ele não possui nenhum mecanismo de notificação e recuperação de erro. A confiabilidade, por exemplo, fica a cargo das camadas superiores. O IP, por si só, apenas possibilita o encaminhamento das mensagens entre origem e destino.

Essas mensagens podem ser ocasionalmente descartadas no destino ou sequer chegar até ele, quando são eliminadas nos dispositivos intermediários. A depender do IP, a origem jamais ficará sabendo por que a mensagem não foi recebida com sucesso no destino. A recuperação de erro poderá ser feita pelas camadas superiores, mas a causa do erro permanecerá desconhecida.

Foi justamente isso que motivou o surgimento do ICMP (Internet Control Message Protocol). Sua principal função é retornar notificações à origem quando um pacote não conseguir alcançar seu destino, por qualquer motivo que seja.

Existem dois utilitários que se valem do trabalho realizado pelo ICMP, conhecidos como Ping e Traceroute (ou Tracert). O Ping é usado para checar a alcançabilidade de um endereço IP por meio de mensagens Echo, e o Traceroute pode determinar a rota de uma comunicação através do uso inteligente das notificações retornadas pelo ICMP.

Vamos dar uma olhada na arquitetura e operação do protocolo e de seus utilitários.

O ICMP foi especificado pela primeira vez, da forma como o conhecemos hoje, na RFC 777, que foi tornada obsoleta pela RFC 792. Falaremos aqui apenas do ICMPv4 (para IPv4); o ICMPv6 (para IPv6) será abordado em outra ocasião.

ICMP

Algumas literaturas consideram o ICMP como um protocolo situado entre as camadas de rede e de transporte, numa tentativa de mencioná-lo como superior. No entanto, embora tenha surgido tempos depois, o ICMP faz parte do próprio IP, sendo ambos implementados em conjunto nos sistemas operacionais.

Ele é composto por uma série de mensagens identificadas por Types e especificadas por Codes. Os Types e Codes são números que nos dizem o que a mensagem quer notificar. Por exemplo, uma mensagem ICMP de Type 3 e Code 0 notifica que a rede de destino não pode ser alcançada:

  • Type 3 identifica a mensagem genericamente (o destino está inalcançável).
  • Code 0 determina a especificação (a rede de destino está inalcançável).

Se o Code fosse 1, teríamos o host de destino inalcançável.

A tabela abaixo lista os Types e Codes mais comuns.

Type Code
0 - Echo Reply 0 - No Code
3 - Destination Unreachable 0 - Net Unreachable
1 - Host Unreachable
2 - Protocol Unreachable
3 - Port Unreachable
4 - Fragmentation Needed and Don’t Fragment was Set
5 - Source Route Failed
6 - Destination Network Unknown
7 - Destination Host Unknown
8 - Source Host Isolated
9 - Communication with Destination Network is Administratively Prohibited
10 - Communication with Destination Host is Administratively Prohibited
11 - Destination Network Unreachable for Type of Service
12 - Destination Host Unreachable for Type of Service
13 - Communication Administratively Prohibited
14 - Host Precedence Violation
15 - Precedence cutoff in effect
5 - Redirect 0 - Redirect Datagram for the Network (or subnet)
1 - Redirect Datagram for the Host
2 - Redirect Datagram for the Type of Service and Network
3 - Redirect Datagram for the Type of Service and Host
8 - Echo 0 - No Code
9 - Router Advertisement 0 - Normal router advertisement
16 - Does not route common traffic
10 - Router Selection 0 - No Code
11 - Time Exceeded 0 - Time to Live exceeded in Transit
1 - Fragment Reassembly Time Exceeded
12 - Parameter Problem 0 - Pointer indicates the error
1 - Missing a Required Option
2 - Bad Length
13 - Timestamp 0 - No Code
14 - Timestamp Reply 0 - No Code
A lista completa de Types e Codes pode ser consultada no site da IANA.

As mensagens ICMP são encapsuladas em pacotes IP. De imediato, sua estrutura pode parecer simples:

No entanto, os campos do byte 4 em diante variam de acordo com o Type/Code.

As mensagens de erro encapsulam a mensagem original, integralmente ou apenas algumas partes dela. Veja um exemplo de mensagem de erro com Type 11 e Code 0 capturada com o Wireshark:

Observe que temos a mensagem ICMP atual (contida na moldura vermelha) e a mensagem original encapsulada (moldura amarela). A mensagem atual está notificando um erro ocorrido com a mensagem original encapsulada.

Outras mensagens ICMP, que não notificam erros, possuem uma estrutura mais simples, como as mensagens Echo (Type 8), por exemplo:

Vamos dar uma olhada em algumas notificações do ICMP na prática. Usaremos a seguinte topologia:

Considere que o roteamento estático está configurado adequadamente. O servidor à direita hospeda uma página web e também opera como o servidor DNS para PC1. Para fazer com que o ICMP retorne uma notificação de erro a PC1, podemos configurar uma ACL (Access Control List) em R2 negando o tráfego originado em PC1:

R2(config)# access-list 1 deny 192.168.0.1
R2(config)# access-list 1 permit any
R2(config)# interface g0/0
R2(config-if)# ip access-group 1 out

A ACL 1 foi aplicada na interface de R2 que se conecta ao servidor. Vamos iniciar o Wireshark em PC1 e tentar acessar a página web hospedada no servidor:

Como esperado, não conseguimos acessar a página web. O tráfego foi bloqueado pela ACL aplicada em R2. Podemos confirmar isso analisando a notificação de erro retornada pelo ICMP:

Observe que a notificação foi gerada por R2 (8.0.0.2). Trata-se de uma mensagem de Type 3 e Code 13, Communication Administratively Prohibited. O Type informa que o destino está inalcançável, e o Code detalha por que ele está inalcançável: há uma configuração em R2 bloqueando o tráfego originado em PC1 (no caso, a ACL).

Os cabeçalhos IP e UDP da mensagem que foi descartada pela ACL estão encapsulados na notificação, destacados pela moldura amarela. A porta 53 nos diz que é uma mensagem DNS. Antes de solicitar a página web, PC1 precisa resolver o nome wolkartt-icmp.com. Como SRV1 é o servidor DNS de PC1, a mensagem DNS passa por R2 e é descartada pela ACL.

Podemos aprimorar a configuração em R2 para que apenas o tráfego HTTP seja bloqueado:

R2(config)# access-list 100 deny tcp host 192.168.0.1 host 50.0.0.1 eq 80
R2(config)# access-list 100 permit ip any any
R2(config)# interface g0/0
R2(config-if)# ip access-group 100 out

O tráfego DNS agora é permitido e consegue alcançar o servidor, mas as mensagens HTTP são descartadas:

A notificação acima encapsula o cabeçalho IP e parte do cabeçalho TCP que compõem a mensagem HTTP (porta 80). Esse encapsulamento da mensagem original, ou de parte dela, é feito apenas para que a origem saiba qual mensagem gerou a notificação. Observe que em ambos os casos analisados, o Type e Code são os mesmos. Sem a mensagem original encapsulada, PC1 ficaria sabendo qual foi o erro, mas não qual mensagem fez com que ele ocorresse.

Vamos dar uma olhada em outro exemplo. Podemos configurar R1 e R2 para que gerem propositadamente um loop de roteamento. Esse é o cenário ideal para que um pacote fique trafegando pela rede até esgotar o seu TTL (Time To Live). Quando isso acontecer, PC1 receberá uma notificação ICMP informando que a mensagem foi descartada devido ao TTL excedido.

A configuração de roteamento atual nos roteadores é a seguinte:

R1# show ip route
Gateway of last resort is not set

      8.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        8.0.0.0/30 is directly connected, GigabitEthernet0/1
L        8.0.0.1/32 is directly connected, GigabitEthernet0/1
      50.0.0.0/24 is subnetted, 1 subnets
S        50.0.0.0 [1/0] via 8.0.0.2
      192.168.0.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.0.0/24 is directly connected, GigabitEthernet0/0
L        192.168.0.254/32 is directly connected, GigabitEthernet0/0
R2# show ip route
Gateway of last resort is not set

      8.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        8.0.0.0/30 is directly connected, GigabitEthernet0/1
L        8.0.0.2/32 is directly connected, GigabitEthernet0/1
      50.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        50.0.0.0/24 is directly connected, GigabitEthernet0/0
L        50.0.0.254/32 is directly connected, GigabitEthernet0/0
S     192.168.0.0/24 [1/0] via 8.0.0.1

Precisamos apenas desabilitar a interface de R2 que se conecta ao servidor e adicionar uma rota estática inadequada”:

R2(config)# interface g0/0
R2(config-if)# shutdown
R2(config-if)# exit
R2(config)# ip route 50.0.0.0 255.255.255.0 8.0.0.1

R2 agora está configurado para enviar a R1 qualquer tráfego destinado à rede 50.0.0.0/24. Por sua vez, R1 envia para R2 todo tráfego destinado a essa rede. Quando PC1 tentar acessar a página web hospedada em SRV1, a mensagem DNS permanecerá em loop entre os dois roteadores até que o seu TTL esgote. Quando isso acontecer, PC1 receberá uma notificação ICMP:

A notificação foi gerada por R2 (8.0.0.2). O Type 11 e Code 0 indicam que a mensagem original circulou pela rede até alcançar a quantidade máxima de saltos definida no pacote IP, motivo pelo qual ela foi descartada por R2. Os cabeçalhos IP e UDP da mensagem estão encapsulados na notificação.

O TTL da mensagem original estava definido como 128:

Isso significa que a mensagem passou 64 vezes por R1 e outras 64 vezes por R2. A cada vez que passou por um roteador, o TTL foi decrementado em 1. Ao chegar pela 64ª vez em R2, o TTL estava igual a 1:

R2 decrementou esse valor em 1 e o TTL chegou a zero. A mensagem foi então descartada e a notificação ICMP foi enviada a PC1.

Ping

O Ping é um utilitário do ICMP cuja operação consiste no envio de mensagens Echo (Type 8) para checar a alcançabilidade de um endereço IP. Ele foi desenvolvido por Mike Muuss em dezembro de 1983. Muuss escolheu o termo Ping” inspirado no som emitido pelo sonar, um instrumento criado para localizar elementos submersos como submarinos e mergulhadores perdidos, e que hoje também é usado em pesquisas oceânicas e na pesca. Posteriormente, David L. Mills deu ao retroacrônimo Ping” o significado de Packet Internet Groper.

Mike Muuss escreveu o código do Ping e as alterações do kernel do UNIX para suporte a sockets ICMP brutos em uma única noite. Recomendo a leitura da história do Ping escrita por ele próprio.

A escolha do termo Ping” em analogia ao som do sonar não foi à toa. Quando o sonar emite seus pulsos sonoros, as ondas de som se propagam água abaixo até alcançarem algum obstáculo. Quando isso acontece, o som bate” e volta para o emissor. Com a medição do tempo que o som leva para ir e voltar, é possível calcular a distância do obstáculo e estimar sua localização.

O Ping opera de forma semelhante. Uma mensagem ICMP de Type 8 (Echo) é enviada para um determinado endereço IP. Se tudo estiver certo, a origem receberá de volta uma mensagem ICMP de Type 0 (Echo Reply) indicando que o endereço IP está configurado adequadamente no dispositivo de destino e que ele pode ser alcançado a partir desta origem. Porém, se algo der errado, a origem receberá uma mensagem ICMP notificando o erro (que poderá ser identificado através dos Types e Codes).

Além disso, as mensagens do ping são cronometradas para que se possa determinar o RTT (Round Trip Time, o tempo que o Echo leva entre a origem e o destino somado ao tempo que o Echo Reply leva entre o destino e a origem). Quando a localização do destino é desconhecida, o RTT pode indicar a distância até ele. Por outro lado, um RTT consideravelmente alto entre dois pontos próximos um do outro pode revelar problemas de latência no caminho percorrido, exigindo uma apuração mais detalhada. Um RTT alto também pode ser consequência da quantidade de saltos entre a origem e o destino, saturação dos links da rede e até mesmo interferência nos cabos. Essas e outras percepções, como a porcentagem de pacotes perdidos na comunicação, por exemplo, são feitas com a ajuda do ping.

Considere a seguinte topologia:

O roteamento estático está configurado adequadamente. Vamos acessar R1 e executar um ping para o endereço IP 8.0.0.2 de R2:

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

Por padrão, o Cisco IOS envia cinco pings a cada execução do comando. Observe na terceira linha que cada mensagem ICMP Echo enviada possui 100 bytes, com timeout de 2 segundos. Esses 100 bytes incluem o cabeçalho IP, mas não o cabeçalho de camada 2. Em nosso caso, o ping foi enviado em um enlace Ethernet, cujo cabeçalho é composto por 14 bytes:

O Wireshark exibe um tamanho total de 114 bytes, porém, o rodapé do frame Ethernet não é considerado (o rodapé é descartado pela placa de rede antes da captura do Wireshark). Se considerarmos o tamanho do rodapé, a mensagem completa chega a 118 bytes.

Os Echo Replies retornados pelo dispositivo de destino possuem o mesmo tamanho.

O timeout determina quanto tempo a origem vai esperar por uma resposta do destino. Os pings com timeout esgotado podem indicar congestionamento na rede (o que impossibilita o Echo de chegar ao destino; os roteadores dão prioridade baixa ao processamento de pacotes ICMP), problemas com o ARP em redes Ethernet (quando não é possível encontrar o endereço MAC do destino), filtragem de pacotes (feita pelos firewalls, tanto na borda da rede como nos dispositivos finais) ou ausência de rota (quando o ping é executado a partir de um roteador que não possui rota em sua tabela de roteamento para o destino especificado).

No exemplo acima os pings foram executados com sucesso, ou seja, os Echos foram enviados e os Echo Replies foram recebidos. Sabemos disso porque o resultado na quarta linha exibe um sinal de exclamação (!) para cada ping com sucesso. O Cisco IOS utiliza caracteres para os diferentes resultados possíveis, conforme listados na tabela abaixo.

Caractere Descrição
! Echo Reply (Type 0)
. Timeout
TTL Exceeded (Type 11)
Could not fragment (Type 3, Code 4)
U Destination Unreachable (Type 3)
? Unknown packet type
Algumas literaturas listam outros caracteres, como & e C. Porém, eles não são usados para pings executados em redes IP. O caractere &, por exemplo, significa packet lifetime exceeded em redes IPX, e C pode ser congested network em redes IPX ou checksum error em redes AppleTalk. Tais caracteres não são encontrados em redes IP.

Para visualizar o resultado do ping com mais detalhes, basta habilitar o debug do ICMP:

R1# debug ip icmp
ICMP packet debugging is on

Ao executar o ping novamente, temos:

R1# ping 8.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.0.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
*Oct 17 16:13:59.671: ICMP: echo reply rcvd, src 8.0.0.2, dst 8.0.0.1, topology BASE, dscp 0 topoid 0
*Oct 17 16:13:59.671: ICMP: echo reply rcvd, src 8.0.0.2, dst 8.0.0.1, topology BASE, dscp 0 topoid 0
*Oct 17 16:13:59.671: ICMP: echo reply rcvd, src 8.0.0.2, dst 8.0.0.1, topology BASE, dscp 0 topoid 0
*Oct 17 16:13:59.672: ICMP: echo reply rcvd, src 8.0.0.2, dst 8.0.0.1, topology BASE, dscp 0 topoid 0
*Oct 17 16:13:59.672: ICMP: echo reply rcvd, src 8.0.0.2, dst 8.0.0.1, topology BASE, dscp 0 topoid 0

O resultado da sexta linha em diante é gerado pelo debug, informando que as mensagens Echo Reply foram recebidas.

Observe que na quinta linha temos a porcentagem de sucesso dos pings enviados (100% no caso, já que todos os Echo Replies correspondentes foram recebidos) e a estatística do RTT (o menor, a média e o maior entre os cinco pings).

Vamos configurar R2 com a mesma rota estática inadequada” usada em outro exemplo para que o erro de TTL excedido seja apresentado no resultado do ping. A rota para a rede 192.168.20.0/24 vai apontar para 8.0.0.1 (R1) ao invés de apontar para a interface Loopback0, que será desabilitada:

R2(config)# interface lo0
R2(config-if)# shutdown
R2(config-if)# exit
R2(config)# ip route 192.168.20.0 255.255.255.0 8.0.0.1

Com o debug do ICMP ainda habilitado em R1, podemos executar o ping para checar o resultado:

R1# ping 192.168.20.254
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.20.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
*Oct 17 18:09:35.588: ICMP: time exceeded rcvd from 8.0.0.2
*Oct 17 18:09:37.590: ICMP: time exceeded rcvd from 8.0.0.2
*Oct 17 18:09:39.593: ICMP: time exceeded rcvd from 8.0.0.2
*Oct 17 18:09:41.589: ICMP: time exceeded rcvd from 8.0.0.2
*Oct 17 18:09:43.594: ICMP: time exceeded rcvd from 8.0.0.2

O valor de TTL padrão aplicado pelo Cisco IOS é 255.

Vamos agora executar o ping com destino a um endereço IP desconhecido por R1:

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

R1 não possui nenhuma rota em sua tabela de roteamento que lhe possibilite encaminhar os Echos destinados a 10.0.0.1. As mensagens sequer saíram do roteador. Nesse caso, R1 ficará aguardando pelas respostas aos Echos enviados” (que, na realidade, foram descartados por ele próprio). Como nenhuma resposta é recebida, o timeout de 2 segundos se esgota e R1 exibe o resultado. Observe que, no caso de timeouts esgotados, o debug do ICMP não gera nenhum log.

Para visualizarmos outro erro, podemos excluir a rota estática inadequada” de R2 e manter a interface Loopback0 desabilitada. Como R2 não vai encontrar nenhuma rota em sua tabela de roteamento para a rede 192.168.20.0/24, ele retornará a R1 uma mensagem ICMP Host Unreachable (Type 3, Code 1):

R2(config)# no ip route 192.168.20.0 255.255.255.0 8.0.0.1
R2(config)# exit
R2# show ip route
Gateway of last resort is not set

      8.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        8.0.0.0/30 is directly connected, GigabitEthernet0/1
L        8.0.0.2/32 is directly connected, GigabitEthernet0/1
S     192.168.10.0/24 [1/0] via 8.0.0.1

R1# ping 192.168.20.254
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.20.254, timeout is 2 seconds:
U.U.U
Success rate is 0 percent (0/5)
*Oct 17 18:52:08.552: ICMP: dst (8.0.0.1) host unreachable rcv from 8.0.0.2
*Oct 17 18:52:10.554: ICMP: dst (8.0.0.1) host unreachable rcv from 8.0.0.2
*Oct 17 18:52:12.554: ICMP: dst (8.0.0.1) host unreachable rcv from 8.0.0.2

Dentre os cinco pings enviados, dois são ignorados por R2 e terminam com o timeout esgotado. Os outros três são respondidos por R2 com a notificação ICMP de Host Unreachable para informar que ele não sabe como alcançar a rede de destino (192.168.20.0/24).

Você pode estar se perguntando: por que Host Unreachable? Quando os Echos enviados por R1 chegam em R2, eles são descartados porque R2 não encontra uma rota em sua tabela de roteamento para a rede 192.168.20.0/24. Ou seja, R2 não pode alcançar a rede de destino, de modo que a notificação ICMP mais adequada seria Network Unreachable (Type 3, Code 0). Porém, o Cisco IOS simplesmente ignora isso e não retorna notificações de Network Unreachable, substituindo-as por Host Unreachable.

Se trocarmos R2 por um roteador MikroTik, por exemplo, vamos obter a notificação ICMP correta:

[admin@MikroTik] > ip address print
 #   ADDRESS            NETWORK         INTERFACE
 0   8.0.0.2/30         8.0.0.0         ether1
[admin@MikroTik] > 
[admin@MikroTik] > ip route print
 #       DST-ADDRESS      PREF-SRC     GATEWAY     DISTANCE
 0 ADC   8.0.0.0/30       8.0.0.2      ether1             0

Observe que o MikroTik não possui rota para a rede 192.168.20.0/24. Ao executar o ping em R1, a notificação de Network Unreachable será retornada pelo MikroTik:

R1# ping 192.168.20.254
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.20.254, timeout is 2 seconds:
UUUUU
Success rate is 0 percent (0/5)
*Oct 17 21:11:14.322: ICMP: dst (8.0.0.1) net unreachable rcv from 8.0.0.2
*Oct 17 21:11:14.322: ICMP: dst (8.0.0.1) net unreachable rcv from 8.0.0.2
*Oct 17 21:11:14.323: ICMP: dst (8.0.0.1) net unreachable rcv from 8.0.0.2
*Oct 17 21:11:14.323: ICMP: dst (8.0.0.1) net unreachable rcv from 8.0.0.2
*Oct 17 21:11:14.324: ICMP: dst (8.0.0.1) net unreachable rcv from 8.0.0.2

Se executarmos o ping no Mikrotik, R1 retornará uma notificação imprópria de Host Unreachable:

[admin@MikroTik] > ip route add dst-address=0.0.0.0/0 gateway=8.0.0.1
[admin@MikroTik] >
[admin@MikroTik] > ping 10.0.0.1
  SEQ   HOST         SIZE  TTL  TIME  STATUS
    0   8.0.0.1        56  255  0ms   host unreachable
    1   8.0.0.1        56  255  0ms   host unreachable
    2   8.0.0.1        56  255  0ms   host unreachable

Enviamos o ping para qualquer endereço IP desconhecido por R1. Apesar de não conseguir alcançar a rede de destino, R1 retorna para o MikroTik a notificação Host Unreachable ao invés de Network Unreachable.

Por fim, vamos voltar com R2 e configurar nele uma ACL para negar o tráfego originado em R1:

R2(config)# access-list 1 deny 8.0.0.1
R2(config)# access-list 1 permit any
R2(config)# interface g0/1
R2(config-if)# ip access-group 1 in

Quando R1 executar um ping para 8.0.0.2, R2 retornará uma notificação ICMP de Type 3 e Code 13 (Communication Administratively Prohibited):

R1# ping 8.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.0.0.2, timeout is 2 seconds:
U.U.U
Success rate is 0 percent (0/5)
*Oct 17 20:37:03.564: ICMP: dst (8.0.0.1) administratively prohibited unreachable rcv from 8.0.0.2
*Oct 17 20:37:05.572: ICMP: dst (8.0.0.1) administratively prohibited unreachable rcv from 8.0.0.2
*Oct 17 20:37:07.574: ICMP: dst (8.0.0.1) administratively prohibited unreachable rcv from 8.0.0.2

Os Echos enviados por R1 foram descartados pela ACL configurada em R2.

R1# undebug ip icmp
ICMP packet debugging is off

R2(config)# no access-list 1
R2(config)# interface g0/1
R2(config-if)# no ip access-group 1 in
R2(config-if)# interface lo0
R2(config-if)# no shutdown

Nos comandos acima, o debug do ICMP foi desabilitado em R1 e, em R2, a ACL foi excluída e a interface Loopback0 foi habilitada novamente.

Ping Estendido

O ping estendido é um recurso do Cisco IOS que possibilita a execução do ping através de um wizard. Com ele podemos alterar alguns parâmetros dos Echos enviados. Embora o propósito do ping seja testar a alcançabilidade de um endereço IP, o utilitário é tão bom que, no decorrer do tempo, passou a ser usado também para outros testes mais específicos. Ainda utilizando a topologia anterior, vamos entrar em R1 e executar um ping estendido para R2:

R1# ping
Protocol [ip]:
Target IP address: 8.0.0.2
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface:
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 8.0.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

Para executar o ping estendido, basta digitar apenas o comando ping. No exemplo acima não alteramos nenhum parâmetro, deixando tudo conforme indicado entre colchetes (os valores padrões). O parâmetro Source address or interface também não foi especificado, de modo que o roteador escolherá como origem o endereço IP configurado na interface de saída da rota. Por exemplo, considere a tabela de roteamento de R1:

R1# show ip route
Gateway of last resort is not set

      8.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        8.0.0.0/30 is directly connected, GigabitEthernet0/1
L        8.0.0.1/32 is directly connected, GigabitEthernet0/1
      192.168.10.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.10.0/24 is directly connected, Loopback0
L        192.168.10.1/32 is directly connected, Loopback0
S     192.198.20.0/24 [1/0] via 8.0.0.2

Um ping executado a partir de R1 com destino a 8.0.0.2 usará a rota que possui a interface de saída GigabitEthernet0/1, então o endereço IP configurado nessa interface (8.0.0.1) será usado como origem. A mesma coisa aconteceria se o ping fosse executado para 192.168.20.1: a rota aponta para 8.0.0.2, e R1 faria uma busca recursiva na tabela de roteamento e encontraria uma rota para 8.0.0.0/30 apontando para a interface GigabitEthernet0/1.

A especificação do endereço ou interface de origem é útil para evitar resultados falso-positivos. Digamos que você queira testar, a partir de R1, se a rede 192.168.10.0/24 está conseguindo acessar a rede 192.168.20.0/24. Se o ping fosse executado apenas como ping 192.168.20.1, o endereço de origem seria 8.0.0.1 e o resultado daria certamente positivo, pois o roteador vizinho (R2) está diretamente conectado à rede 8.0.0.0/30 e saberia como encaminhar a resposta de volta para R1.

Porém, não dá para prever se R2 possui uma rota para a rede 192.168.10.0/24. Sem a definição explícita do endereço ou interface de origem, o resultado do teste pode dar falso-positivo: você vai concluir que a rede 192.168.10.0/24 está conseguindo acessar a rede 192.168.20.0/24, quando na realidade esse acesso pode não estar ocorrendo. O teste correto seria com um ping estendido colocando 192.168.10.1 ou Loopback0 como endereço ou interface de origem, respectivamente.

Quando especificamos a interface de origem, o Cisco IOS utiliza o endereço IP configurado na interface.

O parâmetro Protocol é usado para especificar outros protocolos além do IP (versão 4), sejam aqueles que ainda são usados, como MPLS e IPv6, por exemplo, ou tecnologias legadas como AppleTalk, Novell IPX, ATM, XNS, entre outras. Esse parâmetro só aceitará um valor diferente de ip se houver outro tipo de rede configurado no roteador. Por exemplo, o valor ipx só será aceito se o roteamento IPX estiver habilitado:

R1# ping
Protocol [ip]: ipx
% Unknown protocol - "ipx", type "ping ?" for help
R1#
R1# configure terminal
R1(config)# ipx routing
R1(config)# exit
R1# 
R1# ping
Protocol [ip]: ipx
Target IPX address:

A mesma ideia vale para os outros protocolos: apollo, appletalk, atm, clns, decnet, ipv6, mpls, sna, srb, vines, xns etc. As opções variam de acordo com o suporte do roteador e do Cisco IOS. O padrão, claro, é o ip, conforme indicado entre colchetes.

O parâmetro Target IP address é o destino do ping.

Repeat count é a quantidade de Echos que serão enviados.

Datagram size é o tamanho das mensagens ICMP. No Cisco IOS, esse valor corresponde ao tamanho da carga útil (payload) da mensagem ICMP somado ao tamanho dos cabeçalhos de camada 3. Vamos dar uma olhada na captura de um ping enviado com Datagram size de 500 bytes:

Observe que o campo Data (payload) possui 28 bytes a menos que o tamanho especificado no ping estendido. Isso acontece porque os 500 bytes incluem o cabeçalho ICMP (8 bytes) e o cabeçalho IP (20 bytes), que juntos somam 28 bytes. Em outros sistemas operacionais, como o Windows, por exemplo, a especificação de tamanho refere-se apenas à carga útil (nesses casos, o campo Data seria composto de 500 bytes).

O tamanho total do frame é exibido como 514 bytes, incluindo os 14 bytes do cabeçalho Ethernet. Se considerarmos o rodapé, que não é exibido pelo Wireshark, o frame chega a 518 bytes.

O parâmetro Timeout in seconds, como o próprio nome indica, define o valor de timeout dos Echos enviados.

Extended commands não é um parâmetro, mas um questionamento” que o Cisco IOS faz para saber se você deseja visualizar os outros parâmetros do ping estendido. Se você responder y (yes), as seis linhas correspondentes serão exibidas; se a resposta for n (no, valor padrão), essas seis linhas serão ignoradas e o ping estendido vai pular para o último parâmetro, Sweep range of sizes:

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

Considerando a resposta y, os seis parâmetros da continuação do ping estendido permitem, sobretudo, a manipulação de alguns campos do cabeçalho IP que vai compor as mensagens Echo. Também é possível definir o conteúdo do campo Data e ainda se a origem deve validar os Echo Replies recebidos através da checagem do rodapé dos frames. Os campos do cabeçalho IP que podem ser manipulados estão destacados na imagem abaixo:

Eles também podem ser vistos no Wireshark:

O parâmetro Type of service corresponde ao campo Differentiated Services destacado no Wireshark. Esse campo é usado para QoS (Quality of Service), e a manipulação dele no ping estendido permite executar testes relacionados a QoS.

O bit Don’t Fragment (DF) no cabeçalho IP determina se o pacote deve ser fragmentado ou não. Quando o tamanho de um pacote é maior que o MTU (Maximum Transmission Unit) suportado pela rede, o roteador pode fragmentar o pacote para que ele consiga ser encaminhado. Fragmentar significa dividir em pedaços menores. Por padrão, o bit DF do cabeçalho IP é igual a 0, de modo que o roteador é instruído a fragmentar o pacote caso ele seja maior que o MTU. Se o bit for alterado para 1, o roteador não poderá fragmentar o pacote e, por isso, deverá descartá-lo (uma vez que, sem a fragmentação, ele não pode ser enviado adiante).

O MTU para redes Ethernet é igual a 1.500 bytes. Esse é o tamanho máximo que um pacote IP pode ter para ser encaminhado nesse tipo de rede. Se o roteador precisar encaminhar um pacote maior que 1.500 bytes, ele deverá antes fragmentá-lo.

Se o parâmetro do ping estendido Set DF bit in IP header for respondido como yes, os Echos enviados não serão fragmentados. Caso o ping seja executado numa rede Ethernet e o tamanho do pacote for maior que 1.500 bytes, o roteador retornará uma notificação ICMP de Type 3 e Code 4, Fragmentation Needed and Don’t Fragment was Set:

R1# debug ip icmp
ICMP packet debugging is on
R1# ping
Protocol [ip]:
Target IP address: 8.0.0.2
Repeat count [5]:
Datagram size [100]: 1501
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface:
Type of service [0]:
Set DF bit in IP header? [no]: yes
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, 1501-byte ICMP Echos to 8.0.0.2, timeout is 2 seconds:
Packet sent with the DF bit set
.....
Success rate is 0 percent (0/5)
*Oct 22 19:56:36.000: ICMP: dst (8.0.0.2): frag. needed and DF set
*Oct 22 19:56:38.001: ICMP: dst (8.0.0.2): frag. needed and DF set
*Oct 22 19:56:40.002: ICMP: dst (8.0.0.2): frag. needed and DF set
*Oct 22 19:56:42.002: ICMP: dst (8.0.0.2): frag. needed and DF set
*Oct 22 19:56:44.005: ICMP: dst (8.0.0.2): frag. needed and DF set

No exemplo acima, os Echos sequer conseguiram sair de R1, já que o tamanho dos pacotes é igual a 1.501 bytes (1 byte a mais que o MTU) e o roteador foi instruído a não fragmentá-los, sendo obrigado a descartá-los.

Somado ao tamanho do frame Ethernet, a mensagem completa pode ter no máximo 1.518 bytes (14 bytes do cabeçalho e 4 bytes do rodapé).

O parâmetro Validate reply data instrui o roteador a checar o rodapé dos Echo Replies recebidos. Por padrão, o roteador não faz a checagem do rodapé dos Echo Replies, que é o meio de verificar se as mensagens foram corrompidas no caminho.

O parâmetro Data pattern define o conteúdo do campo Data das mensagens Echo e Echo Reply. O conteúdo padrão inserido pelo Cisco IOS é 0xABCD (o 0x antes do conteúdo nos diz que ele está representado em formato hexadecimal). Esse conteúdo vai ser repetido quantas vezes forem necessárias para que o campo Data seja preenchido por completo:

A manipulação do campo Data é útil para testar conexões físicas que podem apresentar erros dependendo do conteúdo desse campo, como links seriais configurados incorretamente, por exemplo. Os padrões 0x0000 (todos os bits iguais a 0), 0xFFFF (todos os bits iguais a 1) e 0xAAAA (com os bits alternando entre 1 e 0) são os mais usados. Também é possível definir o valor rotate no parâmetro Data pattern para instruir o roteador a preencher o campo Data com um conteúdo alternado, conforme mostra a imagem abaixo (o parâmetro Datagram size foi definido como 300 bytes):

O parâmetro Loose, Strict, Record, Timestamp, Verbose reúne cinco opções que não são usadas por padrão. Começando de trás para frente, a opção Verbose (V) pode ser selecionada sozinha, mas sempre que outra opção é usada, a Verbose também é selecionada automaticamente. Isso porque ela permite que o resultado do ping seja exibido com mais detalhes, como mostra o exemplo abaixo:

R1# undebug ip icmp
ICMP packet debugging is off
R1# ping
Protocol [ip]:
Target IP address: 8.0.0.2
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface:
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose [none]: v
Loose, Strict, Record, Timestamp, Verbose [V]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.0.0.2, timeout is 2 seconds:
Reply to request 0 (1 ms)
Reply to request 1 (1 ms)
Reply to request 2 (1 ms)
Reply to request 3 (1 ms)
Reply to request 4 (1 ms)

Com a Verbose habilitada, o debug do ICMP pode não ser necessário. Além disso, ela é a única opção do parâmetro que não faz parte do campo Options do cabeçalho IP (ela é usada apenas para ativar um resultado mais detalhado).

A opção Timestamp (T) instrui os roteadores intermediários a inserirem um carimbo” com a hora em que o pacote foi processado. Roteadores intermediários são aqueles que estão no meio do caminho entre a origem e o destino. O conjunto de timestamps adicionados pelos roteadores intermediários é retornado à origem na resposta do ping. Com isso, a origem pode estimar a quantidade de tempo que o pacote levou para ser encaminhado de um roteador a outro. Se o tempo de encaminhamento entre um roteador e outro for muito grande, uma verificação mais detalhada nesse ponto a ponto pode ser necessária.

A opção Record (R) permite identificar os roteadores que compõem a rota entre origem e destino. A cada roteador que o pacote passa, o endereço IP desse roteador é gravado no pacote. Isso acontece na ida (pacotes Echo) e na volta (pacotes Echo Reply). Essa é a grande diferença entre a opção Record e o traceroute, que veremos adiante. O traceroute traça somente a rota de ida. Se o roteamento for assimétrico (ou seja, se o pacote percorrer um caminho na ida e outro caminho na volta), a rota da volta não será traçada pelo traceroute.

As opções Strict (S) e Loose (L) são usadas para que a origem preestabeleça a rota que o pacote vai usar para alcançar o destino. Se uma dessas opções for selecionada, será necessário especificar os endereços IP dos roteadores que compõem a rota a ser percorrida. Ambas as opções demandam que o pacote passe obrigatoriamente por todos os roteadores especificados. A diferença entre elas é que a opção Strict, como o nome sugere, exige que o pacote passe somente pelos roteadores especificados; se o pacote chegar a um roteador que não foi especificado, ele será descartado e uma notificação ICMP de Type 3 e Code 5 (Source Route Failed) será enviada à origem. Já a opção Loose permite que o pacote passe por outros roteadores que não foram especificados.

A lista completa das opções do cabeçalho IPv4 pode ser consultada no site da IANA. Muitas foram tornadas obsoletas pela RFC 6814. No mais, somente as quatro descritas acima podem ser selecionadas no ping estendido do Cisco IOS.

O último parâmetro do ping estendido é o Sweep range of sizes. Ele é usado para que cada ping seja executado com um tamanho diferente. Dê uma olhada no exemplo abaixo:

R1# ping
Protocol [ip]:
Target IP address: 8.0.0.2
Repeat count [5]: 1
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface:
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose [none]: v
Loose, Strict, Record, Timestamp, Verbose [V]:
Sweep range of sizes [n]: y
Sweep min size [36]: 100
Sweep max size [18024]: 200
Sweep interval [1]: 10
Type escape sequence to abort.
Sending 11, [100..200]-byte ICMP Echos to 8.0.0.2, timeout is 2 seconds:
Reply to request 0 (1 ms) (size 100)
Reply to request 1 (1 ms) (size 110)
Reply to request 2 (1 ms) (size 120)
Reply to request 3 (1 ms) (size 130)
Reply to request 4 (1 ms) (size 140)
Reply to request 5 (1 ms) (size 150)
Reply to request 6 (1 ms) (size 160)
Reply to request 7 (1 ms) (size 170)
Reply to request 8 (1 ms) (size 180)
Reply to request 9 (1 ms) (size 190)
Reply to request 10 (1 ms) (size 200)
Success rate is 100 percent (11/11), round-trip min/avg/max = 1/1/1 ms

Observe que o Repeat count foi definido como 1. Quando o Sweep range of sizes é usado, a quantidade de pings enviados vai depender dos valores de Sweep min, Sweep max e Sweep interval. No exemplo acima, o ping com menor tamanho possui 100 bytes (Sweep min) e o ping com maior tamanho possui 200 bytes (Sweep max). A variação do tamanho é de 10 bytes (Sweep interval), de modo que o primeiro ping terá 100 bytes, o segundo terá 110, o terceiro terá 120, e assim por diante, até chegar ao ping de 200 bytes. Com essa variação de 10 em 10, a quantidade de pings necessária entre 100 e 200 bytes é igual a 11. Essa foi a quantidade de pings enviados. Se o Repeat count ficasse com o valor padrão de 5, teríamos um total de 55 pings enviados (11 multiplicado por 5). Além disso, a opção Verbose foi selecionada para que o resultado do ping tivesse mais detalhes. Caso contrário, o resultado seria genérico:

R1# ping
Protocol [ip]:
Target IP address: 8.0.0.2
Repeat count [5]: 1
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]:
Sweep range of sizes [n]: y
Sweep min size [36]: 100
Sweep max size [18024]: 200
Sweep interval [1]: 10
Type escape sequence to abort.
Sending 11, [100..200]-byte ICMP Echos to 8.0.0.2, timeout is 2 seconds:
!!!!!!!!!!!
Success rate is 100 percent (11/11), round-trip min/avg/max = 1/1/1 ms

A maioria dos parâmetros e opções disponíveis no ping estendido é usada apenas em testes muito específicos, cujo objetivo seja encontrar um determinado problema ou tentar resolvê-lo. Fora isso, eles podem não ser necessários.

Dependendo do dispositivo e da versão do Cisco IOS, os parâmetros Ingress ping e DSCP Value também são fornecidos. O Ingress ping é usado para especificar a interface pela qual os Echos devem ser enviados e as respostas devem ser recebidas. O DSCP Value é usado para testes de QoS. O objetivo desses dois parâmetros pode ser alcançado com os parâmetros Source address or interface e Type of service, respectivamente. Quando a interface/endereço de origem dos pings é especificada no parâmetro Source address or interface, as respostas são retornadas para essa mesma interface/endereço. Já o valor de DSCP (Differentiated Services Code Point) pode ser definido através de um mapeamento com os antigos valores de ToS (Type of Service, que é um recurso legado). É muito provável que a Cisco tenha inserido esses dois novos parâmetros para que eles substituam, futuramente, o Source address or interface e o Type of service:

Router# ping
Protocol [ip]: 
Target IP address: 10.0.0.1
Repeat count [5]: 
Datagram size [100]: 
Timeout in seconds [2]: 
Extended commands [n]: y
Ingress ping [n]:
Source address or interface: 
DSCP Value [0]:
Type of service [0]: 
Set DF bit in IP header? [no]: 
Validate reply data? [no]: 
Data pattern [0x0000ABCD]: 
Loose, Strict, Record, Timestamp, Verbose [none]: 
Sweep range of sizes [n]:

Por fim, o ping estendido também pode ser executado de forma mais rápida, sem a utilização do wizard:

R1# ping 8.0.0.2 ?
data      specify data pattern
df-bit    enable do not fragment bit in IP header
repeat    specify repeat count
size      specify datagram size
source    specify source address or name
timeout   specify timeout interval
tos       specify type of service value
validate  validate reply data
<cr>

Todos os parâmetros do ping estendido estão disponíveis como argumentos do comando ping, exceto Loose, Strict, Record, Timestamp, Verbose e Sweep range of sizes.

R1# ping 8.0.0.2 source Lo0 repeat 10 size 500
Type escape sequence to abort.
Sending 10, 500-byte ICMP Echos to 8.0.0.2, timeout is 2 seconds:
Packet sent with a source address of 192.168.10.1
!!!!!!!!!!
Success rate is 100 percent (10/10), round-trip min/avg/max = 1/1/1 ms

No exemplo acima, o ping com destino a 8.0.0.2 foi executado na interface de origem Loopback0 com 10 Echos enviados, cada um com tamanho de 500 bytes.

Traceroute

sds..

Continue Lendo...