How do I make ARP cache age in 30 seconds?

How can I get an ARP cache to age in, say, 30 seconds.  What I've got is the following:

A device with a given IP, say IP1, has a MAC address, say MAC1.  During a short time interval, this device gets a new MAC address, MAC2.  While IP1 has MAC1, it does a tftp transfer of a file from the tftp server.  After IP1 gets MAC2, it tries to do another tftp, but tftp times out since the tftp server still sees MAC1 mapped to IP1.

I can manually intervene and do an "arp -d IP1" to clear the ARP entry, and then try the tftp transfer again with IP1+MAC2, which updates the ARP cache, and everything's fine.

Anyone have good ideas how to manage this without manual intervention?

What would happen if something were running on the tftp server to periodically clear the ARP entry for IP1, and this entry got cleared DURING a tftp transfer?  Would it barf completely and stop, or just recover with a new ARP and be basically invisible?
Who is Participating?
bknowlesConnect With a Mentor Commented:
Flushing the ARP cache during a connection (either the entire cache or just the one entry) should have no permanent long-term effects, just perhaps delay the tftp for a fraction of a second as the machine where the cache got flushed re-acquires the MAC address.
It would depend on the quality of implementation of
the TFTP requestor.  Most will work fine.

However, when a device changes its *IP* address, it issues a "gratuitous ARP" packet, saying
      IP1 is-at MAC1
This is how you detect IP address clashes.   So if you can get the device which is changing its MAC address to issue a gratuitous ARP when its MAC changes, everything should work seamlessly.

Failing that, depending again on the TCPIP implementation of the TFTPing device, you may be able to put the interface in promiscuous mode and so catch packets intended for IP1 no matter if they're sent to MAC1 or MAC2.  

This often won't work because ethernet drivers check that the packet sent to them really is directed at them -- in this way they can support IP multicast when the ethernet card has no packet-filtering logic at all - they just put the interface into promisc mode and do the checks in software.

Can I ask *why* you're changing MAC?

mruddickAuthor Commented:
Jyoungman -

Yes, changing MACs seems like a strange thing to do, but it's in a product test environment, so it's not like it's the only *weird* thing I'm doing to the product.  I'm trying to automate some testing tasks, but was having trouble with this particular bit.
The MAC of a LAN-machine can be found using the function GetMacAddresses(const Machine: string; const Addresses: TStrings): Integer; found in the JEDI Code Library (JCL). This can be fetched from It is free, it works and it doesn't spawn external processes to resolve the MAC.

What it exactly does, I don't know, but it works :o)

Hope any of you can use it. Enjoy :)
All Courses

From novice to tech pro — start learning today.