$ sudo arp -avn
? ( at 00:cc:cc:bb:dd:86 [ether] on eth0

$ sudo arp --delete

$ sudo arp -avn
? ( at <incomplete> [ether] on eth0

After --delete I expected no entry for Unexpectedly, the entry remains and is marked <incomplete>.

Using Ubuntu 10.04.

4 Answers 4


The entry will be removed, just be patient.

(If you want the shortest possible answer: incomplete == deleted)

Let's say "delete" is the wrong word for the action. What's really happening here is that the entry is manually set to the state "request sent, no answer" (thus "incomplete" ARP process) as if the machine would be really unreachable.

Now, the entry will be completely removed soon unless it gets a new valid ARP response in the meantime. In that case the entry would be re-added anyways even if it was removed instead of being marked as incomplete. So there's no actual pro or con to this behaviour.

But keep in mind that we're talking of a cache. Deleting things from caches is hard and expensive. It's way more efficient to invalidate an entry and wait if it gets replaced before it is finally removed. But for the system it's totally no difference if the entry is gone from the list or just marked incomplete.

  • And there is no way to really delete it so that a subsequent need to know the destination would trigger a "new" ARP query?
    – Skaperen
    Feb 7, 2013 at 2:09
  • 1
    But exactly that's the case here. If anything looks up an entry that is marked "incomplete" a new ARP request is send. If it is answered, the entry is updated and no longer "incomplete". If no answer returns, the entry is removed from the list after some time. (That's why I think it's pretty useless to "--delete" an entry manually. If the machine lives, the entry will be refreshed. If it is really gone, then why "--delete" the entry manually anyways?) Feb 7, 2013 at 2:29
  • ... it comes to my mind that you might want to "change" the ARP address for an IP address. In this special case you can "--delete" manually and have the next ARP request return the new address. But for this scenario, it doesn't matter at all if the entry is visibly removed from the list or marked "incomplete". For the tech involved, it's the same. Feb 7, 2013 at 2:45
  • @KarmaFusebox do you know where this cache exists? Is it in process memory? If so, which process? or is it maintained by the kernel? In a file on-disk? elsewhere? Jun 6, 2015 at 22:19
  • @KarmaFusebox Deleting an entry makes sense if the entries were also added manually (and therefore have the permanent flag set)
    – cha5on
    Jan 26, 2017 at 4:15

Just to complement all other answers, I found this link very useful.

In some cases using ip is more appropriate, like the command:

# ip -s -s neigh flush all

Results may depend on your linux kernel.

  • This worked perfectly for me. Anyone who is having trouble with other responses should try it.
    – Iakovos
    May 3, 2017 at 11:33

Apart from the other fine answers it worths mentioning that it is possible to completely eredicate the arp cache by removing it. One of the less painful ways is:

ip link set arp off dev eth0 ; ip link set arp on dev eth0

This should remove all entries, be they in whatever state.

Alternative methods include downing and upping the interface and similar ways to make the arp cache completely removed and recreated.

  • 1
    This is the correct answer. I needed exactly this. Not just marking some entry for "incomplete" or "has not been reached for a while". Thank you. Jan 10, 2019 at 8:36

I know this could sound obvious, but, for those not used to work with the shell, this is my suggestion:

Starting from the answer of @KarmaFusebox, why not simply grep the results...? :

arp -a | grep "incomplet" -i -v

It will show you only the existing/active cache entries.
I think it keeps being a POSIX compliant command. And it is a scriptable method, if that is what you need.

  • I'm looking for a reasonable explanation of why arp behaves this way. It seems peculiar. Tangentially, could arp be forced to remove the <incomplete> entries? Jun 7, 2015 at 15:53
  • Well, @JamesThomasMoon1979, I would rather say that, on systems that seem not to behave this way (i.e: Windows console), they really are. The only difference is they don't show incomplete entries on the arp cache list command. Jun 7, 2015 at 16:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .