Redes: entendendo o ICMP e o ARP
agosto 21, 2008 – 11:59 amAlém do TCP e do UDP, temos o ICMP (Internet Control Message Protocol), um protocolo de controle, que opera no nível 3 do modelo OSI (junto com o protocolo IP). Ao contrário do TCP e do UDP, o ICMP não é usado para a transmissão de dados, mas nem por isso deixa de desempenhar diversas funções importantes. A mais trivial delas é o ping, que usamos para verificar se uma determinada máquina está online.
Outra função importante do ICMP é o controle do TTL (time to live) de cada pacote TCP ou UDP. Os pacotes tem vida curta e sua única função é carregar os dados até o destino. Eles são transmitidos de um roteador a outro e, uma vez que chegam ao destino, são desmontados e destruídos. Mas, o que acontece em casos onde não existe uma rota possível até o destino, seja porque a máquina está desligada, por erro no endereçamento, ou por um problema em algum dos links?
Existem duas possibilidades. A primeira é um roteador próximo perceber que a máquina está fora do ar e destruir o pacote. Neste caso, ele responde ao emissor com um pacote ICMP "Destination Unreachable", avisando do ocorrido. Caso isso não aconteça, o pacote fica circulando pela rede, passando de um roteador a outro, sem que consiga chegar ao destino final.
O TTL existe para evitar que estes pacotes fiquem em loop eterno, sendo retransmitidos indefinidamente e assim consumindo banda de forma desnecessária. Graças a ele, os pacotes têm "vida útil".
O TTL default varia de acordo com o sistema operacional usado. No Windows XP o default são 128 hops, enquanto nas versões atuais do Linux os pacotes são criados com um TTL de 64 hops. Cada vez que o pacote passa por um roteador, o número é reduzido em um. Se o número chegar a zero, o roteador destrói o pacote e avisa o emissor enviando um pacote ICMP "Time Exceeded".
Na Internet, os roteadores são espertos o suficiente para conhecerem os roteadores vizinhos e escolherem a melhor rota para cada destino. Sempre que um roteador fica congestionado, os demais passam a evitá-lo, escolhendo rotas alternativas. Essa comunicação é feita através de pacotes ICMP "Redirect", que avisam o emissor que uma rota mais rápida está disponível e os pacotes seguintes devem ser encaminhados através dela.
Naturalmente, este sistema não é infalível. Corrupções nas tabelas de roteamento, bugs nos softwares de controle, panes e defeitos em geral podem comprometer o trabalho dos roteadores, fazendo com que alguns pontos da rede fiquem inacessíveis. Surge então o clássico problema de um determinado endereço ou faixa de endereços ficar inacessível para usuários de um determinado provedor, muito embora continue disponível para o resto da rede.

Dentro da rede local, os pacotes são transformados em frames, onde são endereçados ao endereço MAC da placa de rede destino e não ao endereço IP. Acontece que, inicialmente, o sistema não sabe quais são os endereços MAC das placas dos outros micros da rede local, sabe apenas os endereços IP que deve acessar.
O ARP (Address Resolution Protocol) faz compania ao IP e ao ICMP na camada 3 do modelo OSI, oferecendo justamente uma forma simples de descobrir o endereço MAC de um determinado host, a partir do seu endereço IP. A estação manda um pacote de broadcast (chamado "ARP Request"), contendo o endereço IP do host destino e ele responde com seu endereço MAC. Como os pacotes de broadcast são custosos em termos de banda da rede, cada estação mantém um cache com os endereços conhecidos.
Naturalmente, isso é feito de forma transparente. É mais um detalhe técnico com o qual você não precisa se preocupar se quer apenas usar a rede, mas que é interessante estudar quando está interessado em entender seu funcionamento. Você pode verificar o cache de endereços ARP do seu micro (no Linux) usando o comando "arp".
Existe também o "RARP" (reverse ARP), que tem a função oposta: contatar um host da rede quando o endereço MAC é conhecido, mas o endereço IP não. Embora menos usado, o RARP também é importante, pois ele é usado quando uma estação precisa obter sua configuração de rede via DHCP.
Ao receber o pacote de broadcast enviado pela estação, o servidor DHCP sabe apenas o endereço MAC da estação e não seu endereço IP (que afinal ainda não foi definido). Ele é capaz de responder à solicitação graças ao RARP. Sem ele, não teríamos DHCP.
» Leia mais: Redes: entendendo o ICMP e o ARP







7 Responses to “Redes: entendendo o ICMP e o ARP”
Muito explicativo, prático e fácil de entender. Parabéns Morimoto!!!
Então uma dúvida surge:
Segundo o que você disse o TTL de um pacote varia conforme o sistema operacional em questão, sendo 128 p/ Win XP e 64 p/ Linux.
Mas se para uma determinada comunicação, o pacote tivesse que passar por um Número superior de roteadores ao TTL permitido pelo SO?
Vamos supor que eu esteja usando o Linux e precise estabelecer uma conexão com um PC distante a 70 roteadores.
Obs.: não há outra rota alternativa com menos hops.
By Leonardo on ago 21, 2008
"Vamos supor que eu esteja usando o Linux e precise estabelecer uma conexão com um PC distante a 70 roteadores."
Simples, você aumenta o TTL padrão :)
http://www.gdhpress.com.br/redes/leia/index.php?p=cap4-4
By Carlos Morimoto on ago 21, 2008
Só para aproveitar então: e no Windows? será que ele automatiza isso caso o numero de hops seja superior a 128?
Obrigado!
By Leonardo on ago 21, 2008
Posso estar enganado, mas acredito que não exista alguma situação legítima em que um pacote precise de mais do que 128 hops para chegar a outro. Mesmo o limite de 64 hops do Linux nunca é atingido (caso contrário aumentariam o valor default). Na maioria dos casos, são necessários apenas 20 ou 25 hops para chegar de um host qualquer a outro.
De qualquer forma, o TTL do Windows pode ser ajustado através de uma chave de registro, é só perguntar pro google.
By Carlos Morimoto on ago 21, 2008
Sim, claro, na prática é estranho pensar em 128 roteadores, até pq imagine o tempo de resposta nessa situação, nem se fala!
By Leonardo on ago 21, 2008
Artigo prático e direto, nota 10!
By Adriano on ago 22, 2008
Artigo nota 10. Primeira de luxo. Esse Morimoto é show de bola.
By Pedro Júnior on ago 24, 2008