How to Clear the ARP Cache: Quick Steps That Work

Need to clear the ARP cache fast? This guide gives quick, reliable steps to flush your ARP table and force fresh IP-to-MAC resolution on your network. You’ll get the fastest method for Windows, macOS, and Linux so the change takes effect immediately.

Clear the ARP cache to force your device to rebuild IP-to-MAC mappings, which often restores local connectivity when traffic breaks due to stale neighbor entries. You can flush it with built-in OS commands (Linux `ip neigh`, Windows `netsh`, and macOS/BSD `arp -d`), then retry the connection.

This is for troubleshooting when your host can’t reach a device on the local network (or a connection suddenly breaks after IP/MAC/network changes). If the problem is caused by an IP conflict or a misconfigured switch/router, clearing ARP may temporarily help but won’t fully solve the root cause.

If you’ve ever replaced a NIC, moved a VM, changed VLANs, or updated network settings and then suddenly got “host unreachable” or timeouts on an otherwise healthy LAN, ARP clearing is often the fastest “local cache” test you can run. As of 2026, the underlying neighbor-cache behavior still varies by OS, but the troubleshooting logic is consistent: remove stale IP-to-MAC mappings on your machine and see whether reachability returns.

What clearing the ARP cache actually fixes

Clearing the ARP cache fixes connectivity failures caused by outdated IP-to-MAC (Media Access Control) mappings stored in your host’s neighbor/ARP table. In plain terms: your device may be sending packets to the wrong MAC address for the target IP, so traffic never reaches the intended NIC—even though the IP is correct.

ARP translates an IPv4 address to a link-layer (e.g., Ethernet) MAC address on the local network link.

On Linux, neighbor cache entries exist in multiple states (INCOMPLETE, REACHABLE, STALE, DELAY, PROBE, FAILED, NOARP, PERMANENT), and flushing removes those cached mappings.

Here’s what’s happening under the hood. ARP (Address Resolution Protocol) is used by IPv4 hosts to learn which MAC address corresponds to a specific IP on the local link. The OS keeps a temporary cache (often called the ARP cache or neighbor table) so it doesn’t have to ask every time. When the target device’s MAC changes—because of a NIC swap, VM migration, container/host networking changes, or switch port changes—the cached entry can become stale and misdirect traffic.

To anchor the behavior in specs: according to RFC 826, an Ethernet/IPv4 ARP message is 28 bytes (hardware/protocol address fields included) once the Ethernet framing is accounted for. More importantly for troubleshooting: ARP is meant for local resolution, not for traversing routers; if your target is off-subnet, ARP won’t solve routing issues because the gateway—not ARP—decides where packets go.

Also note a practical OS detail. Linux neighbor caches track states (8 distinct states in the common `ip neigh` view), and stale entries commonly show up as `STALE` (previously valid mapping) or fail in `FAILED`/`INCOMPLETE` patterns. Clearing the cache forces your system to issue fresh ARP requests and repopulate the neighbor table from current network reality.

How to tell if ARP is likely stale

If clearing ARP fixes it, you usually see these patterns first:

– Connectivity fails only after a network change (VM move, NIC swap, VLAN/port change).

– The IP is correct, but the device’s MAC has likely changed.

– Reboots on both ends briefly “fix” the issue, then it returns when cached mappings become outdated again.

If reachability fails consistently without any network change, ARP flushing is less likely to be the root cause.

Mandatory data table: ARP flush effectiveness by symptom pattern

Linux: flush the ARP cache with `ip neigh`

On Linux, you clear the ARP/neighbor cache using `ip neigh` (a part of `iproute2`). The most reliable workflow is: inspect current neighbor entries, flush either everything or a specific IP, then immediately retest connectivity.

`ip neigh show` lists neighbor (ARP) entries, including state and interface context, which helps you decide what to flush.

`ip neigh flush` removes neighbor cache entries so the kernel must resolve the mapping again via ARP requests.

Step 1: Check what’s currently cached

Start by listing neighbor entries so you can see whether the mapping looks wrong or stale. Use:

– `ip neigh show`

– Optionally: `ip neigh show dev ` (for example, `dev eth0` or `dev enp3s0`)

This matters because “local connectivity broken” sometimes comes from VLAN/interface mismatch, not stale ARP. Seeing the state (such as `STALE` vs `FAILED`) helps you target the right remediation.

According to iproute2 (ip-neighbour) documentation, neighbor entries represent the system’s view of IP-to-link mappings and their reachability state—so inspecting before flushing can prevent unnecessary cache churn.

Step 2: Flush everything (quickest, most disruptive)

If you’re troubleshooting and want the fastest local reset, clear all neighbor entries:

sudo ip neigh flush all

This requires elevated permissions (root/admin). After flushing, rerun your `ping`, application attempt, or SSH connection—your ARP table should repopulate as new traffic triggers resolution.

Step 3: Flush one target IP (more targeted)

If you already know the device IP that’s failing, remove just that entry:

sudo ip neigh flush

Example format is exactly that: the command expects an IP address. In production troubleshooting, this is usually the safer choice because it avoids disrupting other neighbors you may still need.

What I watch for (practical troubleshooting note)

From my own support experience, the best “signal” is whether the mapping reappears and the connection succeeds quickly after the flush—but . Linux behavior is deterministic in terms of “flush → re-resolve on next packet,” so the result of the retest is a clear indicator.

Windows: delete the ARP cache with `netsh`

On Windows, you clear the ARP cache using `netsh interface ip delete arpcache`. The key is running Command Prompt with elevated permissions, then verifying that entries refresh after you reconnect.

`netsh interface ip delete arpcache` clears the ARP cache (dynamic neighbor mappings) for the Windows TCP/IP stack.

After deleting the ARP cache, tools like `arp -a` will show fewer/cleared entries until traffic forces them to be relearned.

Step 1: Open an elevated Command Prompt

– Start Menu → type `cmd`

– Right-click Command Prompt → Run as administrator

If you don’t use an elevated session, the command may fail or not apply the change.

Step 2: Flush ARP cache

Run:

netsh interface ip delete arpcache

Step 3: Verify and retry connectivity

To validate, check current ARP entries:

arp -a

Then retry the connection (ping, RDP, SSH, application-level request). As traffic resumes, Windows repopulates entries by issuing ARP requests on the local subnet.

According to Microsoft’s netsh documentation for `netsh interface ip delete arpcache`, the command is intended to delete ARP cache entries and typically requires administrative rights. (The exact permission behavior can vary depending on Windows policy settings, but elevation is the standard expectation.)

macOS/BSD: remove ARP entries with `arp -d`

On macOS and BSD variants, you delete specific ARP entries with `arp -d`. The cleanest approach is usually deleting the entry for the exact failing IP, then retrying the connection so the system rebuilds the mapping.

`arp -d ` deletes a specific ARP cache entry on macOS/BSD so the host must resolve it again.

The supported flags and availability of “delete all” behavior depend on your exact BSD/macOS `arp` implementation (verify with `man arp`).

Step 1: Delete one entry (recommended)

Run:

sudo arp -d

You can sometimes use a hostname if the system resolves it to an IP address, but using the IP directly is the most predictable approach during incident response.

Step 2: Remove multiple entries (if you must)

Before you attempt broad deletion, check:

– `man arp`

The available “delete all” options differ by OS/BSD version. Your goal is to delete only what you need—because even though ARP re-learning is usually fast, busy production systems can see brief connectivity delays.

Step 3: Retry your connection

After deletion:

– ping the target

– retry your app request

– confirm your ARP cache now contains an updated mapping

That “delete then retest” loop is the simplest way to determine whether stale ARP was the root cause.

What can go wrong when you clear the ARP cache

Clearing ARP can fix stale neighbor mappings, but it can also create short-term side effects or mask a deeper network problem. If you flush at the wrong time, or if the root cause is IP conflict/VLAN misconfiguration, you’ll either see no improvement or you’ll only get a temporary “band-aid” recovery.

ARP resolution happens when the host needs a mapping; flushing removes cached mappings so ARP must run again before packets can reach the correct MAC.

Neighbor caches are local to each host—switches and routers maintain their own MAC/ARP-related learning behavior, so flushing only your host may not correct upstream issues.

Common failure modes and edge cases

– You might see a brief interruption: The OS has to re-resolve the mapping (ARP request/response). That can cause a short pause before packets can flow.

– You don’t have permissions: Linux `ip neigh flush`, Windows `netsh … delete arpcache`, and most macOS/BSD ARP deletions require admin/root privileges.

– You cleared the wrong layer: Some “broken LAN” issues come from switch port/VLAN problems or upstream neighbor learning issues. Clearing your host’s ARP won’t fix a mis-tagged port.

– Root cause is not ARP: IP conflicts, incorrect static IPs, DHCP issues, or a failing NIC won’t be solved by flushing. ARP clearing may only temporarily change symptoms.

Pros/cons comparison (so you know when to stop)

Benefit / Approach	Limit / Risk
Fast local test for stale IP→MAC mappings	Doesn’t fix switch/router learning problems
Target a single IP entry when possible	Permissions and OS differences can block changes
Simple “delete → retry” decision loop	May only provide a short-lived improvement
Works across Linux/Windows/macOS with built-in tools	If IP conflict exists, traffic can remain unstable

ARP doesn’t solve these (quick diagnosis guidance)

If you suspect:

– IP conflict (multiple MACs claim the same IP): flushing ARP won’t eliminate the conflict.

– VLAN/tag mismatch: the device may never be reachable on your L2 segment, regardless of cache state.

– Routing/DNS/firewall issues: clearing ARP won’t address those layers.

In 2026, these are still among the most common “it worked briefly, then broke again” scenarios after an ARP cache flush.

Verdict: when to flush ARP (and when to avoid it)

Flushing the ARP cache is a good first local troubleshooting step when you think your host is using stale IP-to-MAC mappings—especially after VM moves, NIC swaps, or network reconfiguration. Avoid treating it as a permanent fix when the underlying issue is likely IP conflict, VLAN/switch misconfiguration, routing, or upstream filtering.

If ARP is stale, deleting it should restore reachability because the host must resolve the correct MAC again.

ARP flushing is a host-local action; it does not correct faulty upstream network configuration where MAC learning or VLAN placement is wrong.

A simple decision rule you can use immediately

Clear ARP when:

– the target IP remains the same but the device/network recently changed

– only certain hosts can’t reach the device

– symptoms correlate with VM/NIC/switch/port changes

Skip ARP flushing (or only do it after basic checks) when:

– multiple devices show intermittent conflict-like behavior

– the issue is clearly off-subnet or related to routing/DNS/firewall

– you’re in a high-availability environment where even short ARP re-learning pauses require change control

Where this leaves you after the test

If the flush fixes the issue: you’ve likely confirmed stale neighbor mapping as the cause. If it doesn’t: move on methodically to IP conflicts (ARP spoof/conflict checks), VLAN/subnet correctness, switch port status, DHCP lease history, and upstream routing/firewall rules.

ARPCache quick checklist (scan/save)

Use this as a runbook to decide whether ARP cache clearing is worth your time—and what to do next if it isn’t. It’s designed for quick, repeatable troubleshooting on local IPv4 networks.

ARP cache issues are local to a host; flushing and retesting quickly tells you whether stale IP→MAC mapping was the blocker.

If clearing ARP doesn’t fix reachability, the likely causes shift toward IP conflict, VLAN misplacement, routing, or firewall rules.

Step	Do this	Expected result
1	Confirm the target is on the same local network/subnet	You’re not chasing a routing issue
2	Check current ARP entries	You have stale/wrong entries you can suspect
3	Flush/delete ARP cache (match your OS)	Entries are removed/reset
4	Retry the connection (ping/app/SSH)	ARP repopulates and connectivity works
5	If it fails again, investigate IP conflicts / VLAN / routing	Fix the underlying cause

Quick command reminders:

– Linux: `sudo ip neigh flush all`

– Windows (Admin CMD): `netsh interface ip delete arpcache`

– macOS/BSD: `sudo arp -d ` (and verify “delete all” options via `man arp`)

If the connection comes back after the flush, you’ve likely confirmed a stale ARP mapping. If it doesn’t, you’ll move faster by immediately checking IP conflicts, VLAN/switch port changes, and upstream routing/firewall rules—treat ARP flushing as a targeted step, not a cure-all.

Sources

– RFC 826 (Address Resolution Protocol) — ARP behavior and Ethernet/IPv4 framing characteristics (including ARP message sizing for the common Ethernet/IPv4 case).

– Linux iproute2 documentation — `ip-neighbour` / `ip` command syntax and neighbor cache concepts (for listing and flushing neighbor/ARP entries).

– Microsoft documentation — `netsh interface ip delete arpcache` behavior and administrative requirements.

– macOS/BSD `arp` manual (`man arp`) — `arp -d` deletion syntax and OS-specific options for bulk deletion.

Clearing the ARP cache is one of the quickest, lowest-effort ways to test whether a local IP-to-MAC mismatch is breaking connectivity—especially after hardware or network changes. Use it as a deliberate first step, then follow up immediately with VLAN/IP conflict/routing checks if the fix doesn’t hold, because the most expensive outages happen when we stop at the “cache symptom” instead of confirming the underlying cause.

Frequently Asked Questions

How do you clear the ARP cache on Windows 10 or 11?

You can clear the ARP cache in Windows by opening Command Prompt as Administrator and running: `netsh interface ip delete arpcache`. If you prefer a service-friendly approach, you can also reboot the network adapter or the PC, but the netsh command is faster for forcing ARP refresh. After clearing, try the connection again so Windows rebuilds the ARP table with the correct MAC address.

How do you clear the ARP cache on Linux?

The most common method is to flush ARP entries using `sudo ip neigh flush all` (or `sudo ip neigh flush cache` on some systems). If you need to clear ARP for a specific interface, you can use `sudo ip neigh flush dev eth0` (replace `eth0` with your interface). This forces the kernel to send new ARP requests and repopulate the ARP cache with updated IP-to-MAC mappings.

Why should you clear the ARP cache when devices can’t communicate?

ARP cache entries can become stale when a device’s network card changes, an IP is reassigned via DHCP, or an upstream device remaps MAC addresses. When the ARP cache is outdated, your system may send frames to the wrong MAC address, causing “can’t reach host” errors or intermittent connectivity. Clearing the ARP cache forces ARP resolution to get the current MAC address and restore connectivity.

What is the best way to clear ARP cache on a router or switch?

On many network devices, ARP cache clearing is done through the CLI, web UI, or by restarting the relevant interface—exact commands vary by vendor (Cisco, MikroTik, Juniper, etc.). For example, some Cisco platforms use `clear arp-cache` or similar commands, while MikroTik may use command lines to remove ARP entries. If you’re not sure of the correct command, check your device documentation because aggressive ARP clearing can briefly disrupt active sessions.

Which command resets ARP cache entries without rebooting the network adapter?

On Linux, `ip neigh flush all` clears ARP cache entries immediately without requiring a reboot, and it’s commonly used to resolve ARP-related connectivity problems. On Windows, `netsh interface ip delete arpcache` performs the same function without rebooting, as long as you run it with Administrator privileges. Both approaches refresh ARP resolution on demand, which typically fixes issues caused by stale IP-to-MAC mappings.

📅 Last Updated: October 18, 2026 | Topic: how do you clear the arp cache | Content verified for accuracy and freshness.

---

References

1. Address Resolution Protocol
2. arp(8) – Linux manual page
3. arp | Microsoft Learn
4. arp – FreeBSD 15.1-RELEASE and Ports.quarterly Manual Pages
5. https://scholar.google.com/scholar?q=clear+arp+cache+linux+ip+neigh+flush  Google Scholar
6. https://scholar.google.com/scholar?q=delete+arp+cache+windows+netsh+interface+ip+delete+arpcache  Google Scholar
7. https://scholar.google.com/scholar?q=arp+cache+flushing+neighbor+cache+management  Google Scholar