How to fix an IP address conflict: diagnose, trace and prevent

How to tell it is really an IP address conflict

An IP address conflict means two devices on the same network segment both answer ARP requests for the same IPv4 address. Before you start tracing, make sure the symptoms are not coming from a flaky gateway or a bad link. The usual signs are:

• Windows shows “Windows has detected an IP address conflict”, and the System log holds an event from source Tcpip with ID 4199 that names the conflicting hardware (MAC) address;
• Linux shows no warning by default. Instead the connection comes and goes, ping loses packets in a regular pattern, or the ARP table keeps changing the MAC recorded for that IP;
• On the gateway, show ip arp (Cisco IOS) reports a MAC for the address that does not match your records, or the entry flips between two MACs;
• If the two devices also share a MAC address, as carelessly cloned VMs sometimes do, the switch logs MAC flapping between two ports, for example Cisco’s %SW_MATM-4-MACFLAP_NOTIF.

The quickest confirmation is arping. The iputils version sends ARP requests to the target address; every device holding that address replies, so two different MACs in the replies means a conflict:

# Send 5 ARP requests from eth0 and watch the MAC in each reply
arping -I eth0 -c 5 192.168.10.50

# Duplicate address detection mode: exit 0 = nobody answered (free), 1 = in use
arping -D -I eth0 -c 3 192.168.10.50; echo $?

Debian and Ubuntu ship two tools with the same name. iputils-arping uses -I for the interface; Thomas Habets’ arping uses -i and has a -d flag that reports duplicate replies directly. To check a whole subnet at once, arp-scan --localnet lists every responding host and marks duplicates with (DUP: 2).

On Windows, check the recorded MAC and pull the conflict events:

arp -a | findstr 192.168.10.50
Get-NetNeighbor -IPAddress 192.168.10.50
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Tcpip'; Id=4199} | Select-Object -First 5

What causes IP address conflicts

Cause	Typical scenario	How to recognize it
Manual misconfiguration	A typo, a NIC config copied from another server, a VM template cloned with a static IP still in it	The second MAC belongs to a device that just came online
DHCP and static mixed	A static address sits inside the DHCP scope; a device goes offline, its lease expires, the address is leased to someone else and the device comes back	The second device got the address from DHCP and shows up in the lease table
Customers changing their own IP	A colocation or dedicated-server customer sets a neighboring free address, or someone else’s, on their NIC; common with multi-IP servers	The second MAC belongs to another customer’s server
Leftovers from migration	A decommissioned server is powered on again, a standby machine boots, or both NICs of a dual-homed host carry the same address	The second MAC is listed as “decommissioned” or “spare” in your records
High-availability split-brain	Both nodes behind a keepalived, VRRP or Windows cluster VIP believe they are the master	Both MACs belong to servers in the same application
VLAN leak	A wrong port VLAN, or a trunk allowing a VLAN it should not, merges two segments that reuse the same private range	The second MAC comes from another VLAN or from a downstream switch

In a data center the first three account for most cases, and “customers changing their own IP” is the one you cannot solve by talking to people. It needs enforcement on the switch, which is covered below.

Step by step: from the ARP table to the switch port

1. Get both MAC addresses. Read the ARP table on an affected host or on the gateway, or capture the replies directly:

# Show only ARP packets for this address; the replies carry two different sender MACs
tcpdump -ni eth0 arp and host 192.168.10.50
ip neigh show 192.168.10.50

2. Decide which MAC is legitimate. Compare both against the MAC recorded for that address in your IPAM; the other one is the intruder. The first three bytes (the OUI) identify the NIC vendor and hint at the device type: 52:54:00 is a KVM virtual machine, 00:50:56 is VMware.
3. Look the MAC up on the switch to find the port:

! Cisco IOS
show mac address-table address 5254.00ab.cdef
show ip arp 192.168.10.50

On Junos the equivalents are show ethernet-switching table and show arp; Huawei and H3C use display mac-address and display arp.

4. Follow the port to the device. If the port is an access port facing a server, your rack and port records tell you which machine it is. If it is an uplink, the device sits behind the next switch: repeat step 3 there.
5. Stop the damage first. If the intruder is disrupting a paying customer, shutdown the port, then contact whoever owns the device.
6. Correct the configuration and clear stale ARP entries. Once the intruder has been moved to the right address, flush the old entries on the affected hosts and on the gateway, otherwise you wait for them to age out:

# Linux host
ip neigh flush all
# Windows host
arp -d *
# Cisco gateway
clear ip arp 192.168.10.50

7. Let the legitimate host announce itself. Send a gratuitous ARP from the correct host so every neighbor updates its cache at once:

arping -U -I eth0 -c 3 192.168.10.50

Fixing each cause for good

DHCP and static mixed. Keep static addresses outside the DHCP scope and exclude that range on the server. On Windows DHCP, add an exclusion range to the scope and set “conflict detection attempts” to 1 or 2 in the server properties. In ISC DHCP, add ping-check true;. On a Cisco router, use ip dhcp excluded-address 192.168.10.1 192.168.10.100 and ip dhcp ping packets 2 so the server probes an address before leasing it.

Customers changing their own IP. Beyond the conversation, bind IP to MAC on the access port and turn on IP source guard. Packets with any other source address are dropped by the switch, so the customer notices right away that the changed address does not work:

! Cisco IOS: static bindings rely on DHCP snooping being enabled on the VLAN
ip dhcp snooping
ip dhcp snooping vlan 10
ip source binding 5254.00ab.cdef vlan 10 192.168.10.50 interface GigabitEthernet1/0/5
interface GigabitEthernet1/0/5
 ip verify source

Juniper EX switches provide the same protection as IP source guard, Huawei uses user-bind static with ip source check user-bind enable, and H3C uses ip source binding with ip verify source. The idea is identical on every platform: a static IP-to-MAC-to-port binding, and a check that drops anything else.

Leftovers from migration. Add “wipe the NIC configuration or unplug the cable” to your decommissioning checklist, and give standby machines their own temporary addresses. For critical addresses, configure a static ARP entry on the gateway, for example arp 192.168.10.50 5254.00ab.cdef arpa on Cisco IOS. Even if someone misconfigures a host, the gateway only talks to the recorded MAC.

High-availability split-brain. Check the heartbeat link between the nodes and whether the switch is filtering VRRP packets (multicast 224.0.0.18, or unicast if configured that way), then verify priorities and preemption settings. While the cluster is split, stop keepalived on one node to restore service.

VLAN leak. Compare the port’s native VLAN (PVID) and the trunk’s allowed VLAN list against your design, and remove the VLAN that should not be there.

How to prevent IP conflicts in a data center

Resolving one conflict is easy; the goal is never seeing it again. Four practices that work in colocation and hosting environments:

1. Every address has an owner. Register every public, private and IPMI address in an IPAM with the server, MAC, customer and status, and hand out addresses only from that record. No verbal “just use this one for now”.
2. Probe before you assign. Before configuring an address for a customer, run arping -D from a machine on the same segment. A reply means your records and reality disagree, so investigate before assigning:

if arping -D -I eth0 -c 3 192.168.10.50 >/dev/null; then
  echo "free, safe to assign"
else
  echo "someone answered, hold the assignment and check"
fi

3. Lock it on the switch. Bind IP to MAC on access ports and enable IP source guard, so a customer who changes their address cannot send a single packet. The conflict is stopped at the port instead of spreading across the segment.
4. Keep listening. Run arpwatch on the gateway’s VLAN. It emails you the moment an IP’s MAC changes or flips back and forth, long before a customer complains.

Toplink DCIM combines the first three. IP address management records who owns every address and skips in-use and locked addresses during automatic assignment, while switch management pushes ARP binding and source guard to the port. Server-side MACs are learned and bound automatically, so re-cabling and migrations no longer need a manual check.