Fix ARP table issues by inspecting the cache with arp -a (Windows/macOS) or ip neigh (Linux), flushing stale entries with netsh interface ip delete arpcache or ip -s -s neigh flush all, then forcing a re-resolution by pinging the target. If a wrong MAC persists, check for duplicate IPs or ARP spoofing.
Symptoms
- Host reaches the internet intermittently but cannot ping the default gateway or another LAN device.
- arp -a lists the same MAC address bound to two different IPs, or shows 00-00-00-00-00-00.
- Traffic to a known server routes to an unexpected MAC, or a MAC flaps between switch ports.
- Static ARP entries survive reboots and override the correct dynamic mapping learned from the network.
- Wireshark shows gratuitous ARP replies from an unknown host claiming the gateway IP.
Common Causes
Stale dynamic entries after IP change
An endpoint changed NIC or received a new DHCP lease, but neighboring hosts still cache the old MAC until the entry ages out (typically 2–4 hours on Windows, shorter on Linux).
Duplicate IP address on the LAN
Two devices claim the same IPv4 address, so ARP replies overwrite each other. The cache flips between MACs and connectivity becomes erratic.
Incorrect static ARP binding
A permanent entry added with arp -s (or a DHCP reservation mismatch) points to a MAC that no longer owns that IP, silently breaking reachability.
ARP spoofing or poisoning
A rogue host on the segment sends unsolicited ARP replies mapping the gateway IP to its own MAC, redirecting traffic through the attacker.
Switch or router misconfiguration
VLAN mismatches, proxy-ARP disabled where expected, or an ARP inspection ACL dropping legitimate replies prevents the cache from populating correctly.
Step-by-Step Fix
- Read the current ARP cache and identify the bad entry
Run arp -a on Windows or macOS, ip neigh show on Linux, or show ip arp on Cisco IOS. Note which IP maps to which MAC and the entry state (dynamic, static, incomplete, stale). Compare the gateway MAC against the one printed on the router or in DHCP logs. - Flush the local ARP cache
On Windows open an elevated command prompt and run netsh interface ip delete arpcache, or arp -d * for a quick wipe. On Linux use sudo ip -s -s neigh flush all. On macOS use sudo arp -a -d. On Cisco IOS use clear arp-cache in enable mode. - Force ARP re-resolution and verify
Ping the affected host or the gateway to trigger a fresh ARP request, then re-check the table. The new entry should appear as REACHABLE (Linux) or dynamic (Windows). If it stays INCOMPLETE, the target is not answering on layer 2. - Remove or correct static ARP entries
List static entries and delete stale ones with arp -d <ip> on Windows/macOS or sudo ip neigh del <ip> dev <iface> on Linux. On Cisco remove with no arp <ip>. Only re-add a static entry when you have verified the MAC directly on the device. - Hunt duplicate IPs and MAC conflicts
From a Linux host run arping -D -I <iface> <ip> to detect duplicates, or check switch logs for DUPLICATE_IP messages. On Cisco use show ip arp <ip> and show mac address-table address <mac> to see which port a MAC lives on. - Investigate for ARP spoofing
Capture with tcpdump -i <iface> arp or Wireshark and look for gratuitous replies claiming the gateway IP from an unknown MAC. Cross-reference the MAC OUI with the vendor. If poisoning is confirmed, isolate the offending port and rotate credentials that may have crossed the wire. - Harden the switch and re-test
Enable Dynamic ARP Inspection tied to the DHCP snooping database on managed switches, and port-security to bind expected MACs. After enabling, ping across the segment and re-read the ARP tables on both endpoints to confirm stable, matching mappings.
Common ARP symptoms mapped to likely cause and first fix
| Symptom | Likely cause | First action |
|---|---|---|
| arp entry shows 00-00-00-00-00-00 or incomplete | Target host offline or blocked at layer 2 | Ping the host, check cable/VLAN, verify it is powered |
| Two IPs share one MAC | Proxy-ARP enabled or NIC teaming | Confirm expected on the router; disable proxy-ARP if unintended |
| One IP flaps between two MACs | Duplicate IP address on the LAN | Run arping -D, locate second device, reassign |
| Gateway MAC differs from router label | Possible ARP spoofing | Capture ARP traffic, isolate suspect port |
| Static entry overrides correct MAC | Legacy arp -s command | Delete with arp -d <ip>, let dynamic resolution run |
| Entry never ages out | Static or very long timeout | Check with netsh int ip show interface or arp -a state |
Prevention
- Enable DHCP snooping and Dynamic ARP Inspection on access switches that carry user traffic.
- Reserve critical IPs in DHCP instead of hand-coding static ARP entries on endpoints.
- Monitor for gratuitous ARP bursts with an IDS rule or arpwatch on each broadcast domain.
- Document the gateway and server MAC addresses so operators can spot a substitution during triage.
FAQ
Do I need admin rights to flush the ARP cache?
Yes on every modern OS. netsh interface ip delete arpcache on Windows requires an elevated prompt, and ip neigh flush on Linux needs sudo or root. Read-only commands like arp -a and ip neigh show run without elevation, which is handy for triage before you make changes.
Will clearing the ARP cache disconnect users?
Briefly, yes. Active sessions pause for a few hundred milliseconds while the host re-resolves the gateway MAC through a new ARP request. TCP connections normally survive because the retransmit covers the gap. Avoid flushing during time-sensitive traffic like VoIP calls or backups when possible.
How is ARP poisoning different from a duplicate IP?
A duplicate IP is usually accidental. Two devices answer ARP requests for the same address and the cache flips between their MACs. ARP poisoning is deliberate: an attacker sends unsolicited replies binding the gateway IP to their MAC to intercept traffic. Wireshark plus a check against the DHCP snooping table quickly tells them apart.
Contact RankNow's network team for hands-on ARP and layer-2 troubleshooting support.