• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

ARP caching peristence?

M

Mark R

Diamond Member
As above. How long do cached ARP records persist (typically)? And is it different on routers and general-purpose nodes.

Scenario:
We're swapping a service from one vendor to another. Essentially, we're firing the incumbent (vendor A).
Vendor B has configured their system with the same static IP as vendor A's system, and it has the same machine ID, certificates, and credentials.
The clients that will be connecting are a large bunch of embedded devices which cannot be reconfigured, most are on the same VLAN and subnet as the server.

The plan is to cut over by pulling the patch cord out of Vendor A's server and plugging it into Vendor B's server. This isn't the way Vendor B would normally do it, but due to vendor A giving us the run-around, we're forced into a "hostile takeover" scenario.

Once we swap the cables, we reckon we have about 30 minutes during which we can test, and if necessary roll back to vendor A's system. More than that, and we risk not being able to rollback seamlessly, so the decision needs to be made very quickly.

Do we risk having connectivity tests fail because of stale ARP entries in the client devices following cut over? If so, how do we manage this? The new server will be a HA cluster with virtual IP, but the incumbent is just a regular static IP.

The best solution I've come up with, is that we power-off all the clients prior to cut-over and reboot them after, and at the same time we have the network guys flush the ARP caches on all the relevant routers. I was just hoping that there was a less disruptive way of doing it.
 
Three minutes used to be the norm; I'm not sure if that's still the convention.
It is also possible that there are static entries that are forever. You can force a cache flush with arp -f.
Other options can be seen with arp/? In windows or "man Arp" in *nix.
 
Last edited:
It shouldn't be a problem.

When a device (host or router) sees an interface going up, it should do an arp-request for its own IP address. This is a broadcast. This broadcast has 2 functions:

1) Check if there is another device on the network which thinks it has the exact same IP address as the device that does the probe. This would detect duplicate IP addresses.

2) The arp-request has the IP address and the MAC address of the sender in it too. As it is a broadcast packet, all devices on the segment will receive and process the request. None should send a reply. But when they receive the request, the info from the sender (ipaddr,macaddr) can be inserted in their own arp-table. This will refresh the arp-entry for the IP address.

The question is: will the tcp/ip stack on vendor B's machine do this ? You can test this by connecting machine B in your lab to another machine, and checking the arp packets with a sniffer, or a tool like WireShark.
 
It's OS dependent. Default for cisco routers is 4 hours. If you have trouble, you can ping a device from the one that changed and that will update the other ends ARP.
 
You must log in or register to reply here.

TRENDING THREADS

Back
Top