How to Fix a Duplicate IP Address on a Machine Network
A duplicate IP address on a machine network shows up as a device that intermittently drops, a controller that faults on an I/O connection, or a status LED flagging an address conflict after a spare was swapped in with its factory or last-job address still set. Two devices answering to the same IP corrupt the ARP tables of everything trying to reach that address, so traffic lands at the wrong node unpredictably. This page finds the second owner of the address, isolates it, reassigns it cleanly, and closes the gap that let the collision happen.
Fix Duplicate IP on Machine Network in one line: To fix a duplicate IP address on a machine network, read the conflict indication first: EtherNet/IP devices run address conflict detection and flag a duplicate on the network status LED and in diagnostics. Identify the two MAC addresses claiming the IP from a device's ARP table or a switch's MAC table, physically isolate the interloper by unplugging ports until the conflict clears, then reassign it a free address and correct whatever set it wrong. Confirm the original device recovers before reconnecting anything.
Read the Conflict Indication First
Do not start by guessing which device is wrong; read what the network is already telling you. EtherNet/IP adapters implement address conflict detection, which uses ARP probes at power-up and periodically to notice another node claiming their address, and they report the conflict on the network status LED and in the device's diagnostic web page or object data. A device showing a solid red or a specific flash pattern with a duplicate-IP message is telling you it has detected a twin. Note the symptom exactly, because a flickering status LED with a different cause is a different problem, covered in fixing a flickering network status LED.
Capture the timeline, because it usually names the culprit. A duplicate almost always appears right after something changed: a spare drive or adapter installed with its previous address, a laptop plugged in with a static IP that overlaps the machine range, a second machine cell patched into the same subnet. Ask what was touched immediately before the symptom started, and the new arrival is your prime suspect. The device that was working fine yesterday and is now conflicting rarely changed its own address on its own.
Confirm you are actually dealing with a duplicate and not a different addressing fault. A device that never comes online at all may have the wrong subnet mask or gateway rather than a conflicting address, which is a job for setting a static IP with BOOTP or DHCP, not for conflict resolution. A duplicate specifically means two nodes respond to the same IP, so the tell is intermittent reachability and ARP entries for that IP that change MAC address depending on when you look.
Find and Isolate the Second Owner
The definitive evidence is at Layer 2: two MAC addresses claiming one IP. From any reachable device, or a laptop on the subnet, inspect the ARP cache for the disputed IP and watch it flip between two MAC addresses over successive refreshes, because each device answers the ARP and the last answer wins. A managed switch settles it faster still: its MAC address table shows which physical port each of the two MACs lives on, pointing you straight at the two devices without tracing cable. If the switch is unmanaged you fall back to the unplug method below.
Isolate by unplugging, not by reconfiguring blind. With the two candidate ports identified, disconnect one and see whether the conflict indication clears on the device you want to keep. If it clears, the port you just pulled held the interloper; if it does not, pull the other. On an unmanaged switch, disconnect ports one at a time until the surviving device stops flagging the conflict, and the last port you pulled owns the duplicate. Physical isolation is unambiguous in a way that reading configuration screens is not, because the device that stops the conflict when unplugged is provably the twin.
Once isolated, reassign the interloper a genuinely free address, verify it against the machine's IP schedule, and correct the mechanism that set it wrong. A swapped spare needs its address set to the slot's assigned IP before it goes back on the network, ideally on a bench so it never touches the live subnet with the wrong address. A rogue laptop needs a DHCP address or a static IP outside the machine's reserved range. Only reconnect once the address is correct, then confirm the original device has fully recovered its connection to the controller before you consider the fault closed.
Prevent the Next Duplicate
A duplicate that happened once will happen again unless the process that caused it changes. The most common cause is spares carrying a stale address, so the durable fix is an addressing procedure that sets every spare to its target IP on the bench before installation, never in place. Keep the IP schedule for each machine as a living document, mapping every slot and device to its address, so the technician swapping a part knows the correct value without guessing. A spare set correctly before it ever sees the network cannot collide.
Address assignment discipline prevents the rest. Reserve a block of the subnet for infrastructure and machine devices and a separate block for temporary laptops and diagnostic tools, and enforce it so a plugged-in laptop cannot land on a device's address. Where devices are assigned by BOOTP or DHCP, bind each MAC to a fixed address in the server so a device always receives the same IP and no two ever receive the same one, the same reservation discipline that setting a static IP with BOOTP or DHCP relies on.
Finally, make duplicates visible before they cause an outage. A monitoring platform such as Merobix that trends device reachability and connection state will show a device flapping in and out well before an operator connects the dots at the panel, turning an intermittent duplicate into a clear signal on a trend. Watching for a device that repeatedly loses and regains its connection is often how an addressing conflict is caught early, because the pattern in the recorded data is unmistakable even when the panel looks momentarily fine.
Frequently Asked Questions
How do I tell which device has the duplicate IP?
Inspect the ARP cache for the disputed IP and watch it flip between two MAC addresses across refreshes, since both devices answer the ARP. A managed switch's MAC address table shows the physical port of each MAC, naming the two devices directly. On an unmanaged switch, unplug candidate ports one at a time until the device you want to keep stops flagging the conflict, and the last port pulled owns the duplicate.
Why does a duplicate IP cause intermittent drops rather than a hard failure?
Two devices answering one IP each respond to ARP requests, so the ARP tables of everything trying to reach that address get overwritten by whichever device answered last. Traffic then lands at the wrong node depending on timing, which looks like a device that drops and recovers unpredictably rather than one that is cleanly offline. That intermittent, timing-dependent reachability is the signature that separates a duplicate from a plain wrong-subnet fault.
How do I stop duplicate IPs from recurring after a spare swap?
Set every spare to its assigned address on the bench before installation, never on the live network, and keep an IP schedule mapping each slot and device to its address. Reserve separate subnet blocks for machine devices and for temporary laptops, and where BOOTP or DHCP assigns addresses, bind each MAC to a fixed reservation so a device always gets the same IP and no two ever share one.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.