☰

¿Por qué una respuesta PING requiere una solicitud ARP para la MAC del host de origen?

tag-icon • tag-icon ping wireshark arp
¿Por qué una respuesta PING requiere una solicitud ARP para la MAC del host de origen?

Tengo un escenario como se muestra a continuación.
Aquí dos máquinas host están conectadas a través de un concentrador:

ingrese la descripción de la imagen aquí

Ok, entonces el host-1 quiere hacer ping al host-2 y configuré Wireshark en un tercer host conectado al mismo concentrador. Ahora, sorprendentemente, para que funcione un solo comando ping, veo 6 paquetes, mientras que debería haber 4. Esto es lo que veo en Wireshark:

ingrese la descripción de la imagen aquí

Ahora, lo que está más allá de mi comprensión es que el motivo por el que los paquetes 5 y 6 se generan mientras no están en el destino de respuesta ARP ya conoce la Mac del remitente.

¿O hay algún problema con mi comprensión? Por favor ayuda.

Respuesta1

Respuesta original

La primera respuesta proviene de la interfaz del concentrador, no de la interfaz del host-1. Al devolver cosas, aún necesita conocer la mac de la interfaz con la IP del host-1. Algunos conmutadores hacen esto automáticamente, otros no.

Respuesta mejorada:


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

network interfaces: 
i1, i2, hi1, hi2

Después de enviar algo al host-1 desde el host-2 a través de una dirección IP en la capa de aplicación, la respuesta inicial al host-2 (y todas las respuestas posteriores) provendrá de la hi2interfaz, no de la i1interfaz en el host-1.

Para enviar algo a la IP ya conocida del host-1, el host-2 aún necesitará saber dónde enviar paquetes en la capa de enlace. Para hacer eso, el host-2 debe solicitar la dirección MAC de la interfaz dejando al descubierto la IP del host-1.

Algunos conmutadores hacen este tipo de traducción automáticamente: recuerdan la ruta machacia atrás. La mayoría de los centros no lo hacen, de ahí la segunda solicitud.

Respuesta2

Creo que la respuesta dada es incorrecta. En mi opinión, el fenómeno ocurre debido a la implementación ARP del kernel de Linux para encontrar/evitar entradas STALE ARP. Una vez que aprende la dirección MAC del remitente, actualiza el caché ARP local en el receptor y coloca la entrada con un estado de 'RETRASO'. Después de esperar ~5 segundos (valor predeterminado, se puede cambiar en delay_first_probe_time), el receptor comprobará la accesibilidad y luego determinará que el host ahora se considera 'ALCANZABLE'.

Más detalles se pueden encontrar aquí:

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

información relacionada