IP Conflict

Hi,
Recently we had an IP conflict at our plant that caused the cisco switch to crash which our PLC's are connected to. Non of our HMI screens would work. They had red X's on all devices. The process continued to run.....it was a little scary though because we had no control. I found a red light blinking on every one of our PLC's there was a communication fault. The only way I could connect to the PLC was by USB. After connecting USB and logging in I tried to clear the fault but it wouldn't let me. We ended up cycling power to each PLC in order to get them back online. When I cycled power to the PLC everything obviously shut down simultaneously which isn't good. A controlled shutdown would have been preferred.
Does any body know if there is a way to clear the faults on the PLC with out cycling power. Could have I unplugged the network cable and would have that let me then clear the faults in Studio5000? Or could have I pulled the network module from the slot and re inserted and would have this cleared the fault?
It would be nice if I could learn to clear the faults with out cycling the power to the PLC.
We are using Logix 5572 processors with Firmware V21. The network modules are ENT2 Ethernet over IP.

any input is much appreciated.

Thanks

I cannot answer your question but I will say that you need to find the pc or device that created the ip conflict to start with. It took me several months to discover our problem, a device that hasn't been used in several years was turned on to replace a similar device that died.

james

I had a flexio device that would die from time to time. I used the dos command arp -a on my programming laptop and saw the problem ip returned with a mac address that wasn't in the allen bradley range.

The mac address gave enough clues to tell me what device to look for out our network and it turned out to be a training laptop that only was powered up on an infrequent basis. It sure caused a lot of grief.

A network loop can cause a network-wide IP conflict on Rockwell ethernet devices if Spanning Tree Protocol isn't used on your switch. Since it's a Cisco switch, Cisco Discovery Protocol IP Device Tracking (IPDT) has also been documented to cause this issue.

That said, you only have to power down the ports (unplug the network cables momentarily) on the ethernet bridge module. You can also reseat the card. Restarting the system is not needed.

Very important! There is a Cisco / Rockwell bug.

See this thread and scroll down for my previous posts on it.

http://www.plctalk.net/qanda/showthread.php?t=103094

I ran into this same problem this weekend. Makes me wonder if Cisco forced an update or something.


From knowledge base
Problem
When Rockwell Automation EtherNet/IP modules are connected to a subnet containing Cisco switches with "IP device tracking" (IPDT) enabled, the modules may go into a duplicate IP address state after a restart/reset.

Environment
Any layer two networks that contain both Rockwell Automation EtherNet/IP modules and Cisco switches running IPDT.
IPDT is much more likely to be implemented on Cisco switches as of August, 2013 because of a behavior change which enables this command if any feature which requires it is enabled.
This behavior change also removes the ability to turn off IPDT without first turning off any features which require IPDT.

The Stratix line of switches will not have “IP device tracking” enabled by default until a permanent solution is in place.
Cause
The IPDT feature sends probe ARP packets with a source IP address of 0.0.0.0., the source MAC ID of the switch, and the target IP and MAC ID for the device being probed to check that it is still connected and responsive.

When a device becomes disconnected, and then is reconnected within the configurable IPDT timeout period, probe ARP packets may be received by a Logix Ethernet module at the same time as it is in its Address Conflict Detection mechanism. If this happens, the EtherNet/IP module will immediately go into a duplicate IP state, and stop communicating.

IPDT when activated on a Cisco switch will try to probe for every IP connected on the subnet, regardless of whether it is connected to that switch or not.

Testing has shown that this affects the majority of Ethernet modules sold by Rockwell Automation.

Solution
Cisco is continually updating the latest workarounds.
Here is a link to Cisco’s technote:
http://www.cisco.com/c/en/us/support/docs/ip/address-resolution-protocol-arp/118630-technote-ipdt-00.html


Workaround
Several workarounds to this issue exist. They all make suggestions using Cisco IOS command-line interface commands.
Workaround 1

Architect manufacturing zone subnets such that:
1. IPDT is explicitly disabled on every trunk port with the following command:

Hostname (config-if)# ip device tracking maximum 0
2. IPDT probe delay is manually configured on any access port connected to a Rockwell Automation Ethernet module with the following command:

Hostname (config)# ip device tracking probe delay 10
Workaround 2

If the switch in question has an administration IP (SVI) configured on the subnet/VLAN in question the Cisco CLI command:

Hostname (config)# ip device tracking probe use-svi
will insert the administration IP into the source IP in the IPDT packet. This packet will not impact Address Conflict Detection operation.

Workaround 3

Disable IPDT on any Cisco switch ports with IPDT enabled that subsequently connect to a Rockwell Automation Ethernet module with the following command:

Hostname (config-if)# ip device tracking maximum 0