☰

Por que uma resposta PING requer uma solicitação ARP para o MAC dos hosts de origem?

tag-icon • tag-icon ping wireshark arp
Por que uma resposta PING requer uma solicitação ARP para o MAC dos hosts de origem?

Eu tenho um cenário conforme descrito abaixo.
Aqui, duas máquinas host estão conectadas por meio de um hub:

insira a descrição da imagem aqui

Ok, então o host-1 deseja executar ping no host-2 e eu configurei o wireshark em um terceiro host conectado ao mesmo hub. Agora, surpreendentemente, para que um único comando ping funcione, vejo 6 pacotes, enquanto deveria haver 4. Aqui está o que vejo no wireshark:

insira a descrição da imagem aqui

Agora, o que está além do meu entendimento é que o motivo pelo qual os pacotes 5 e 6 são gerados enquanto não estão no destino de resposta ARP já conhece o remetente Mac.

Ou há algo errado com meu entendimento, por favor ajude.

Responder1

Resposta original

A primeira resposta vem da interface do hub, não da interface do host-1. Ao enviar de volta você ainda precisa saber o mac da interface com IP do host-1. Alguns switches fazem isso automaticamente, outros não.

Resposta melhorada:


              .-----------.
              | hub       |
              |           |
[host-1 i1]+--+hi1     hi2+--+[i2 host-2]
              |           |
              `-----------´

network interfaces: 
i1, i2, hi1, hi2

Depois de enviar algo para o host-1 do host-2 por meio de um endereço IP na camada de aplicação, a resposta inicial para o host-2 (e todas as respostas subsequentes) virá da hi2interface, não da i1interface no host-1.

Para enviar qualquer coisa para o IP já conhecido do host-1, o host-2 ainda precisará saber para onde enviar pacotes na camada de enlace. Para fazer isso, o host-2 deve solicitar o endereço MAC da interface, descobrindo o IP do host-1.

Alguns switches fazem esse tipo de tradução automaticamente - eles lembram o mac-pathpara trás. A maioria dos hubs não, daí a segunda solicitação.

Responder2

Acredito que a resposta dada esteja incorreta. Na minha opinião, o fenômeno acontece devido à implementação ARP do kernel Linux para localizar/evitar entradas STALE ARP. Depois de aprender o endereço MAC do remetente, ele atualiza o cache ARP local no destinatário e coloca a entrada com o status 'DELAY'. Depois de esperar cerca de 5 segundos (padrão, pode ser alterado em delay_first_probe_time), o receptor testará a acessibilidade e então determinará que o host agora é considerado 'REACHABLE'.

Mais detalhes podem ser encontrados aqui:

https://osqa-ask.wireshark.org/questions/15792/arp-replies-appear-with-delay-in-wireshark-output/

informação relacionada