Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Some clients in the subnet has cached the IP with old MAC address, I want them to update the new value by doing a ARP broadcast, is it possible in Linux?

share|improve this question
up vote 19 down vote accepted

Yes, it's called "Unsolicited ARP" or "Gratuitous ARP". Check the manpage for arping for more details, but the syntax looks something like this:

arping -U

If you're spoofing an address, you may need to run this first:

echo 1 > /proc/sys/net/ipv4/ip_nonlocal_bind

Finally, because of its spoofing ability, sending Unsolicited ARP packets is sometimes considered a "hostile" activity, and may be ignored, or might lead to being blocked by some third-party firewalls.

share|improve this answer
Under debian, the command for me was arping -S -i ethX Example: arping -S -i eth0 – radicand Apr 1 '13 at 16:39
I found it necessary to do an arping to a router as described above in Linux when the IP is an alias on the device (i.e. either a secondary NIC is using the IP or if it's an alias on an existing NIS which was setup using a ifconfig ethx:x type of alias). If it's the primary, it never seems to be necessary. – user168904 Apr 10 '13 at 14:05

What you are looking for is called "Gratuitous ARP" and can be done using "arping". If your IP address is on eth0, you would use this command:

arping -A -I eth0

You can verify the ARP is being sent using "tcpdump" while the "arping" is running, in this case I am watching "wlan0":

laptop:~$ sudo tcpdump -lni wlan0 arp    
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan0, link-type EN10MB (Ethernet), capture size 65535 bytes
12:14:11.219936 ARP, Reply is-at a4:77:03:d2:9b:c4, length 28
12:14:12.220119 ARP, Reply is-at a4:77:03:d2:9b:c4, length 28
12:14:13.220288 ARP, Reply is-at a4:77:03:d2:9b:c4, length 28
3 packets captured
3 packets received by filter
0 packets dropped by kernel
share|improve this answer

It is not necessary. As in: when you changed the IP, the computer should have done so automatically. If the clietns are hardcoded, a broadcast will not change the hadcoded override.

I do IT for about 20 years now, and in all this time I have NEVER (!) had this happen without faulty equipment.

share|improve this answer
The problem is I accidentally assign a new machine with an used IP, so they conflict the IP. I can't access the old machine using SSH. Now I remotely shutdown the wrong (new) machine, but I still cannot access the old machine, I suspect the router has cached MAC address in its ARP table. – Howard Aug 29 '10 at 9:12
This is called ''gratuitous ARP'' - see… – Kimvais Aug 29 '10 at 9:14
Should work after the arp cache expires. You can also try flushing the arp table on the machine you are trying to access the old machine from – Kimvais Aug 29 '10 at 9:16
@TomTom - perhaps you just haven't been working in the right environment to see it. Sending unsolicited ARP packets is a common way to quickly re-route traffic to a new server in a failover situation. Many high-end switches and routers can take several minutes to recognize that an IP address has moved to a different physical port otherwise. Cisco switches are notorious for this. – tylerl Aug 29 '10 at 9:28
@TomTom: Yes, if you are failing over via heartbeat/corosync, whatever. However, if you manually move services from one machine to another, particularly if you are on Cisco gear, manually sending a gratuitous ARP is extremely useful. I agree that it isn't something you do frequently, but as someone who has also been doing IT for 20 years, I have found myself in a number of situations where I needed to do it. – Sean Reifschneider Mar 2 '13 at 19:00

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.