6

This problem was presented to me by one of my professors because it only happened after switching from 100Mb cards to Gigabit NICs. The second arp request that comes from the computer being pinged (to send a reply back) doesn't get sent until after the pings have gone through.

I decided to do some testing at home with a couple VMs and see if I could find the cause.

Wireshark Capture Example

After clearing the arp cache on both machines (arp -d) and pinging I got the same results as my professor, but I can't seem to figure out why.

I did some googling and found someone with a similar issue using linux (I'm using Windows 10), it said something about there being a stale entry within the arp table as well as something called a first probe delay, but I was never able to find any information about either of those things for Windows.

Does anyone know why this might be happening? Or what that second arp request is for if it isn't to find the first device?

SkyParrillo
  • 61

1 Answers1

2

This appears to be what Bruce Hartpence calls a “Return ARP.” As described in this excerpt from Packet Guide to Core Network Protocols.

The conversation shown in Figure 4-12 illustrates another important facet of ARP—only the host originating the conversation (generating the ARP request) will place an entry for the destination host in its local ARP table. That is, other stations hearing the exchange, even if they are receiving the ARP request, will not add these stations to their own ARP tables. However, many hosts (especially routers) are aggressive when it comes to populating their tables and, upon hearing ARP traffic or being involved in ARP messages, will subsequently generate their own ARP requests to populate their tables.

Short answer. The destination host is populating it’s own ARP table now that it knows about the other host.

Appleoddity
  • 11,970