Paul

Yes it is an interesting post and I am glad to see it come up again. My experience is that sending the arp request is not based on 50 % of the timeout. I believe that the results of your test are skewed by your choice of a quite short arp timeout. With a timeout of 4 minutes the request is sent at close to 2 minutes. But if you had set the timeout to an hour I am confident that the request would have come closer to 58 minutes than to 30 minutes.

A while back I had an experience that may shed some light on this question. I was working on a problem in a customer network where the timing of the arp request seemed to be part of the issue. And we were not able to get a consistent measurement of the arp request was generated.  I opened a case with Cisco TAC about it. What the TAC engineer explained to me was that the request to refresh the arp entry is generated near the end of the arp lifetime. But that Cisco adds a variable amount of time in determining when to generate the arp request. The logic in that is that they want to avoid synchronization of the arp entries. If we have flushed all the entries in the table and re-learned all the entries at approximately the same time then when they are about to expire we do not want to flush them all at the same time and relearn them again in a big batch. So the timeout is somewhat variable. But it is within some number of minutes of the timeout and not based on a percentage of the timeout.

HTH

Rick