"Every so often the network drops for a moment, and nobody knows why." The classic. In a 40-person office it went on for two weeks: every morning just after eight, when the first colleague opened their laptop, every ping died. Two minutes later everything was back. The router log showed one IP address on two devices — that is an IP address conflict.

This article is a pragmatic guide for the real-world case: how to recognize an address conflict, how to find the culprit, and — more importantly — how to make sure it never happens again. All with commands that work on both Windows and Linux, no magic.

What is actually happening?

Every device on a network needs a unique IP address — that is how ARP figures out which MAC address a packet should be sent to. When two devices use the same IP address, it comes down to whoever is currently in the ARP cache of the switches and neighbors. Sometimes device A answers, sometimes device B. The result is sporadic connection drops, packet loss, and the famous Windows warning "There is an IP address conflict detected".

The tricky part: not everything breaks. The file server keeps running because it has a different address. Only the device that shares the IP behaves unpredictably — and depending on how often ARP caches expire in your network, it can take minutes or days before it strikes again.

The most common causes

In most cases it is one of these five setups:

1. Static IP meets DHCP. A printer has a fixed address (e.g. 192.168.1.50), and the DHCP range covers exactly that address too. The server hands it to a laptop — conflict. This is by far the most common case.

2. Cloned virtual machines. You copy a VM, and the hypervisor forgets to assign a new MAC address. Both VMs end up with the same MAC — and therefore the same IP via DHCP. Fast to happen, and a fresh conflict on every reboot.

3. Duplicate DHCP reservation. Two devices have the same IP in the reservation list of your DHCP server. Easy when you let the list grow for years without cleaning it up.

4. Misconfigured DHCP range. A second DHCP server on the network (which can also be a router or a NAS with built-in DHCP) hands out overlapping ranges.

5. Orphaned ARP entries after a move. A device gets a new IP, but some switch or firewall still caches the old combination and forwards packets to a now-foreign MAC address.

How to recognize the conflict

First: confirm it really is an IP conflict and not something else. Three quick checks:

Windows: The OS reports "There is an IP address conflict detected" in the Network Center. In Event Viewer (System, source Tcpip, Event ID 4199) you'll find the conflicting address and the other device's MAC.

Linux: ip neigh shows the ARP table. If one address has two entries with different MACs, that is a fairly clear sign.

Ping and ARP: The most reliable toolkit. Ping the address from a third machine, then look at the ARP table — you'll see which MAC answered. Do it a few times and the MAC keeps switching: conflict.

The quick proof (Linux): for i in $(seq 1 10); do ping -c1 192.168.1.50 >/dev/null; arp -n | grep 192.168.1.50; sleep 1; done — if the MAC changes across several runs, two devices share that IP.

Finding the culprit

Now you need to find out who is using the address twice. The fastest way is an ARP sweep across the subnet:

# Wake up every reachable device in the subnet (ARP to all)
# Linux (needs root):
sudo arp-scan --localnet
# Windows (no extra tools): fill the ARP cache and dump it
for /L %i in (1,1,254) do @ping -n 1 -w 50 192.168.1.%i >nul
arp -a

The result is a list of IP-to-MAC mappings. Cross-reference the MAC address from the Windows error or the ip neigh log — and you have the manufacturer from the first three octets (OUI prefix, arp-scan shows it automatically). A print server, an old PC, a Raspberry Pi reporting as "something with an Intel MAC" — you already have a short list of candidates.

If the MAC can't be mapped to any device: shut down the switch segment where the suspicious MAC should logically live, one by one. As soon as the conflict stops, you're heading in the right direction. It's crude, but effective.

How to fix it for good

Putting out the fire is one thing; preventing the repeat is the other. The clean solution is DHCP reservation instead of a static IP — at least for devices that need a fixed address:

1. Replace static IPs with reservations. Printers, NAS, cameras, access points: enter the IP as a fixed DHCP reservation (MAC → fixed address) instead of configuring it statically on the device. That way the server can never hand out the same address twice. On the device itself, switch to "DHCP".

2. Decouple the DHCP range from reservations. Reservations should typically live outside the dynamic pool. Example: pool 192.168.1.100–199, reservations for fixed devices in 192.168.1.10–99. Then the pool can never collide with a reservation. You can draw out the right pool and subnet boundaries cleanly with the bitcalc Subnet Calculator.

3. Give cloned VMs new MACs. In VMware/VirtualBox/Hyper-V, explicitly assign a new MAC after cloning — then the copy is guaranteed its own IP. And after a snapshot restore, check whether the MAC changed.

4. Only one DHCP server per subnet. Disable DHCP on routers, NAS devices and firewalls that only run as a second or third instance. Use dhcploc (Windows Sysinternals) or a port mirror + Wireshark to find rogue DHCP servers.

5. ARP inspection where your switch supports it. Managed switches from Cisco, HP/Aruba and Netgear can often block ARP spoofing and therefore address conflicts directly (Dynamic ARP Inspection). That's the enterprise solution — for small networks, clean IP management is usually enough.

Prevention: ARP and IP hygiene

The real goal is that address conflicts never arise in the first place. A few habits that pay off:

Keep an IP documentation. A list of all reservations with MAC, device, location and assignment date. Sounds boring, but it saves exactly the two weeks of troubleshooting this article is about. As soon as two devices in the doc would share an IP, you'll notice before the DHCP server does.

Watch DHCP leases. The lease scope of your DHCP server shows which IP goes to which MAC. Unexpected addresses in the reservation zone, or suddenly duplicate MAC entries, are early warning signs.

Take subnet planning seriously. The cleaner the subnets are divided (clients, servers, IoT separated), the less likely two devices are to cross paths. You don't need to be an IPv6 expert — a tidy /24 with separate zones is plenty in most small networks.

Wrap-up

An IP address conflict is almost never a coincidence — it's almost always a matter of IP management: somewhere a static assignment lives where DHCP rules, or a VM was cloned without anyone looking at the MAC. The way out is always the same: confirm the conflict with ARP and ping, find the MAC, locate the device, then replace static with a DHCP reservation.

That office case, by the way, ended like this: it was the printer, which had carried a static address for years, right in the middle of the DHCP pool. Five minutes of reservation — no more drops. Sometimes it really is that banal, and that is exactly why the craft is worth learning.