I have noticed the following behavior with Windows 10. I am sending an ICMP packet every second or so to a valid IPV4 address using the Windows ping utility. I then remove the device from the network so the pings begin to fail. After a random time between 15 and 45 seconds according to https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/address-resolution-protocol-arp-caching-behavior it stops sending the ICMP packets and instead starts sending ARP request packets. This is well understood and meets specifications.
Then after about 6 seconds of sending ARP requests every seconds or so, it slows down to sending them only every 61 seconds, 2 packets spaced apart by 1 second. This means that if a device is temporarily unavailable, it may take up to 61 seconds to be rediscovered once it becomes available again. I have verified this also happens with UDP packets instead of ICMP.
This is causing me trouble in my application. A device is rebooted and then needs to be communicated with as soon as possible after it boots up. It takes about 30 seconds to reboot. If the timing lines up poorly, it might take about a 90 seconds to be discovered, causing slowdowns and timeout errors in our system. It is an IPV4 only system.
Is there any way to change this behavior? I have seen various parameter in the IPV4 parameters that related to the 15-45 second values for a device to be marked as stale. However, I haven't seen anything that controls the 61 second retry interval after multiple failed ARPs (typically 6).
Other ideas for solving this? Assuming modifying the supervising application to change timeouts is not feasible.
