Dlaczego drugie żądanie ARP czeka, aż ping się skończy?

Ten problem został mi przedstawiony przez jednego z moich profesorów, ponieważ zdarzyło się to dopiero po przełączeniu z kart 100 Mb na NIC Gigabit. Drugie żądanie arp, które pochodzi z pingowanego komputera (aby wysłać odpowiedź z powrotem), nie jest wysyłane, dopóki nie minie pingi.

Postanowiłem przeprowadzić kilka testów w domu z kilkoma maszynami wirtualnymi i sprawdzić, czy uda mi się znaleźć przyczynę.

Wireshark Capture Example

Po wyczyszczeniu pamięci podręcznej arp na obu komputerach (arp -d) i pingowaniu otrzymałem takie same wyniki jak mój profesor, ale nie mogę zrozumieć dlaczego.

Zrobiłem kilka googlingów i znalazłem kogoś z podobnym problemem używając linuxa (używam Windows 10), powiedział coś o tym, że w tabeli arp znajduje się nieaktualny wpis, a także coś, co nazywa się pierwszym opóźnieniem sondy, ale nigdy nie byłem w stanie znaleźć informacje na temat jednej z tych rzeczy dla systemu Windows.

Czy ktoś wie, dlaczego tak się dzieje? Albo po co to drugie żądanie arp, jeśli nie ma znaleźć pierwszego urządzenia?

To wydaje się być tym, co Bruce Hartpence nazywa „Zwrotem ARP” ten fragment od pakietu Packet Guide do Core Network Protocols.

Rozmowa pokazana na rysunku 4-12 ilustruje inną ważną   aspekt ARP - tylko host inicjujący rozmowę (generowanie   żądanie ARP) umieści wpis dla hosta docelowego w swoim   lokalna tabela ARP. Oznacza to, że inne stacje słuchające wymiany, nawet jeśli   odbierają żądanie ARP, nie dodają tych stacji do   własne tabele ARP. Jednak wiele hostów (zwłaszcza routerów) to   agresywny, jeśli chodzi o zaludnianie swoich stołów i po wysłuchaniu   Ruch ARP lub udział w wiadomościach ARP będzie później   wygeneruj własne żądania ARP, aby wypełnić ich tabele.

Krótka odpowiedź. Host docelowy zapełnia własną tabelę ARP, ponieważ wie o innym hoście.