[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1781
  • Last Modified:

Clearing the ARP table on a L2 switch when installing a new device

We have a L2 switch in a remote location; it is connected to HQ by a metro-ethernet.   We replaced a server on Fa0/5, keeping the same IP address.   We could not PING the new device, from either direction.  I was unable to find the ARP entry in the L2 switch, but I did clear it in the HQ router (which was attached to the metro-ethernet).  Once I did that, every thing worked fine.   My question is:  why did I have to manually clear the ARP entry?  Why didn't the PING from either direction force-clear it?   I know I've replaced servers in the past, without having to manually clear ARP.  Did the metro-ethernet complicate things?
  • 2
2 Solutions
Andrej PirmanCommented:
The ARP cache expire could be set on routers in wide range, from few minutes and even to no-expire, which may cause a lot of problems.
The solution would be to BROADCAST the arp with the source of the IP.

On Linux machines you can do it by installing "arping":

apt-get install arping

Then issue this command:

arping -S -B

where is our IP. That will broadcast our source IP and direct it to the broadcast address ( After this, all should be ok and the remote device should cache the new arp entry, invalidating the existing cached one.
Ken BooneNetwork ConsultantCommented:
So you won't see the ARP entry in the l2 switch UNLESS the management IP interface on the l2 switch is on the same IP network as the server.  So the ARP entry would definitely be on the the L3 router assuming the metro-e is strictly a layer 2 connection.    If you pinged from the new server to the other side, it would have had to send out an arp request to the device - if on the same network, or to the l3 gateway.  If that happened, the receiving device would have seen the arp request from the host, and should have updated its ARP table with the new MAC address.  If the ping was initiated from the other side, it would not have needed to send out a new ARP request since the old entry was cached and it would have failed.  But you indicated you tried this from both directions.  I have seen this from time to time.  I have also had a metro-e provided that actually tracked the MAC addresses, and whenever we changed something we had to have the metro E provider flush their tables.  So to answer your question - I don't know.  You are thinking correctly about how things work, and most of the time its not an issue.   It could be a client thing, or a metro-E thing or just some quirk thing thats typically not normal.
jimmycherAuthor Commented:
Lasby, Ken,    

Thanks for prompt and enlightening responses.  

We only have one active network at the remote site, but I put the SVI on a seperate "mgmt" subnetwork.    I assume that is best practise, but if it makes things simpler, should I put the SVI on the same subnet as my active hosts?

I didn't get the chance to open an unused switch port, but moving the device to a clean port would have certainly cleared the issue as well, yes?

Ken BooneNetwork ConsultantCommented:
Given that the mgmt subnet is on a different subnet simply means that the ARP entries in the switch are irrelevant.  That switch will only see ARP entries on the mgmt network.  

Best practice would be to do what you are doing.  It won't solve anything by putting it on the same network.

Featured Post

Get quick recovery of individual SharePoint items

Free tool – Veeam Explorer for Microsoft SharePoint, enables fast, easy restores of SharePoint sites, documents, libraries and lists — all with no agents to manage and no additional licenses to buy.

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now