Detecting IP Address Conflicts on Linux and Windows

A ping reply does not establish an IP address conflict. Stronger evidence includes different MAC addresses claiming the same IPv4 address or repeated changes in its neighbor mapping. Even then, rule out intentional virtual-IP movement and proxy ARP before changing anything.

The examples use 192.168.1.50 and Linux interface enp1s0. Replace both with your authorized test target and actual interface. All sample output below is illustrative, not a measurement performed for this article. ARP tests concern the local link; they do not discover a remote device's MAC through a router.

Confirm the interface and route

ip route get 192.168.1.50

A directly attached example might look like this:

192.168.1.50 dev enp1s0 src 192.168.1.20 uid 1000
    cache

If a via gateway is present, do not assume local ARP will identify the remote endpoint. Check routing, VLAN membership and the correct observation location first. On Windows, ipconfig /all helps identify the active adapter, address and mask. Keep VPN and virtual adapters separate from the intended LAN interface.

Inspect Linux neighbor entries without clearing them

ping -c 1 192.168.1.50
ip neigh show to 192.168.1.50 dev enp1s0

Read the link-layer address after lladdr. A STALE entry is an aging cache entry, not a duplicate-address alarm. FAILED or INCOMPLETE also does not prove duplication: the device may be absent or the Layer 2 path incorrect. See the ip-neighbour manual.

For a bounded observation on Linux with Bash and iputils ping:

for i in {1..6}; do
  ping -c 1 -W 1 192.168.1.50 >/dev/null
  ip neigh show to 192.168.1.50 dev enp1s0
  sleep 2
done

Changing addresses warrant correlation with switch and server records. One stable cache entry does not rule out another device that is asleep or disconnected.

Use arping with the implementation in mind

Before assigning a candidate address, iputils arping provides a duplicate-address-detection mode:

sudo arping -D -I enp1s0 -c 3 192.168.1.50
echo $?

For iputils arping, this mode succeeds with exit code 0 when no replies are received. Replies indicate that something claims the address, potentially including a proxy. An error exit also requires reading the error text; do not classify every nonzero result as a confirmed conflict. Silence in three probes does not establish long-term availability.

Different tools share the arping name. Check arping --help on the actual machine. If the target address is already assigned to the interface performing the test, use a separate authorized host on the same VLAN to avoid self-observation confusion.

Compare the Windows ARP record

ping -n 1 192.168.1.50
arp -a 192.168.1.50

Read the entry under the correct interface heading. Repeat at known times and compare its physical address. The Windows arp reference describes lookup and deletion options.

Do not clear the entire table just to obtain a fresh screenshot. If a stale target entry genuinely obstructs a controlled test, deleting only that entry with arp -d 192.168.1.50 requires appropriate privileges and should be done only with local/recovery access. Avoid deleting a neighbor on which your remote management session depends.

Observe claims on the wire

On an authorized Linux test host, a limited capture can show ARP traffic visible to that interface:

sudo tcpdump -c 20 -eni enp1s0 arp

It stops after 20 captured ARP packets; if insufficient traffic arrives it waits, and Ctrl+C stops it. From another terminal, a short sudo arping -I enp1s0 -c 3 192.168.1.50 can solicit replies. Distinct source MAC addresses claiming the target strengthen the case for investigation. Remove unrelated device details before sharing a capture.

Correlate the claims with DHCP leases and the managed switch's MAC table. A manually configured second device may not appear in DHCP. If a MAC is learned through an uplink, follow the path to the next switch; wireless clients may require the access point's client table.

Exclude legitimate movement before renumbering

• A cluster or virtual IP may move during failover.
• A gateway may intentionally answer through proxy ARP.
• A remote destination may have been mistaken for a local neighbor.
• An old lease record may not describe a current online claimant.

After identifying unintended duplicate owners, correct static allocations, exclusions, reservations or overlapping scopes according to the address plan. The conflict overview explains those causes. Do not pick a new last octet at random.

Verify under conditions that could reproduce the fault

Repeat the scoped neighbor and ARP checks while both known devices are online, then test the affected service. If a target-cache reset is necessary, use only a local test host and the single target: sudo ip neigh flush to 192.168.1.50 dev enp1s0. It is optional, not a required first step.

Five replies from one MAC show stability during that observation window, not proof that a sleeping duplicate has disappeared. Keep the corrected allocation records and verify that the problem does not return when the second device reconnects.