Quando eu tenho pingum endereço IP de host na minha LAN, meu host transmite uma ARPsolicitação. Após receber uma ARPresposta do host de destino, ele inicia uma sessão de ICMP echomensagens com suas respostas.
Quando o host de destino está recebendo do ARP requestmeu host de origem, o host de destino está atualizando o ARPcache com as informações incorporadas na solicitação (já que a origem MAC addressestá presente no ARP request)?
Se sim, por que o host de destino às vezes envia outro ARP requestendereço IP para o meu host de origem e descarta todas ICMP echoas solicitações até receber um ARP replyretorno?
Observe que esse comportamento é ocasional e, às vezes, a ICMP echoresposta é feita antes de um ARP requestdo meu host de destino, mas esse tipo de resposta ARP requestsempre ocorre em algum lugar no meio de uma sessão de ping.
Não sei se isso se deve à atualização das tabelas ARP dos hosts de sessões de ping anteriores ou se o segundo ARP requesté apenas um protocolo e o host de destino já tem as informações do host de origem MAC addressdo primeiro ARP request.
Ou será que o host de destino nem precisa do host de origem MAC addressem primeiro lugar, já que ele é sempre encapsulado em cada ICMP echosolicitação e a resposta a cada uma dessas solicitações usa as informações recebidas sobre eles MAC addressese os alterna no quadro de resposta?
Edição 1: Após alguma pesquisa, descobri que o host de destino não preenche seu próprio ARP cachepassivo ARP requests, ou seja, de solicitações de outros hosts. Ele preenche seu ARP cachesomente das ARPrespostas que recebe de suas próprias solicitações.
Edição 2: Seguindo de Edit 1, o segundo ARP requestdo host de destino antes de qualquer ICMP echoresposta indica que a origem MAC addressnão está em seu ARP cacheou se tornou STALE, acionando assim outro ARP requestantes de responder à ICMP echosolicitação. (Às vezes, um STALEendereço é primeiro verificado por meio de uma sondagem e, se o mapeamento for inválido ou a sondagem expirar, a nova sondagem ARP requestocorre.
Assim, o segundo ARP requestocorrendo no meio da pingsessão, indica que a fonte MAC addresstinha se tornado STALEno meu host de destino ARP cachedevido a alguns ARP timeout value(configurado em 60 segundos em meus hosts), o que disparou um segundo ARP request. Além disso, essas segundas ARPsolicitações esclarecem que, embora o host de destino não precise que a fonte MAC addressseja preenchida em seu ARP cachee use as informações sobre ARP requesta fonte MAC addresspara responder a ela, ele realmente precisa saber a fonte MAC addresspara responder a uma TCMP echosolicitação.
Ainda assim, quaisquer respostas que elaborem ou corrijam quaisquer erros nas descobertas acima são muito apreciadas.