Problem with L18ER-BB1B Compactlogix communication through Cisco Catalyst Express 500

Hi Sir/Ma'am, i'm having a trouble in communication of L18ER-BB1B when connected into a CCE500 switch. Please see attached images of the existing network and all the procedures i tested. Thank you for your kind comments, suggestions and recommendations. Please help me resolve this problem. Thank you!

Can you connect directly to the L16 and ping it? If that doesn't work check your IP settings in the PLC.

yes sir. If i am directly connected to the plc the communication is okay. but when i connect to the cisco switch the communication is unreachable.

If you can connect direct but not through the network then there are configuration issues with the Cisco Switches. You should get with your IT department and see if they can help you out.

Does the mac address of the new PLC show up in the ARP cache on the switches?

each port on cisco switch can map to diff. VLAN. easiest way to check is unplug existing port of S7 and plug your rockwell plc in

Verify the gateway address on the L18ER.

BachPhi said:

each port on cisco switch can map to diff. VLAN. easiest way to check is unplug existing port of S7 and plug your rockwell plc in

Click to expand...

If the L16 is using the same switch port as the equipment it replaced, no VLAN change is needed.

>> Does the mac address of the new PLC show up in the ARP cache on the switches?

Unless the PLC is actually communicating with the switch at layer 3, there is no reason to expect the MAC address of the PLC to be in the ARP cache of the switch. We would, however, expect it to be in the forwarding or MAC-address table.

No subnet masks are presented, but I would assume it is a /24 or 255.255.255.0. If so, then the PLC should show in the ARP cache of the PC that executes the ping. On Windows, this command would be:

c:\arp -a

I would bet it is not there. Can you get the MAC address of the device from a label on the PLC? Use that to compare.

>>Verify the gateway address on the L18ER.

If there is no routing going on, the gateway address should have no effect. Based on the IP addresses presented, routing is not likely required. We can only be 99% sure as the subnet masks are not presented.

This is an interesting problem because when the OP plugs a laptop into the PLC built-in switch, he can ping through it. This would indicate that the vlan is correct. But I could envision maybe the port is tagged (i.e. a trunk port), where it needs to be untagged. Maybe the CPU port of the PLC drops tagged frames (don't have one to test) so the ICMP echo requests are dropped. But the switch, when forwarding between ports, strips the tag so they pass through to the PC. Not likely, but something I would check. You most likely want access or edge ports, which are untagged.

Wireshark can be used to cut your problem space down. Sniff traffic at each link as you go. When the traffic stops, the device immediately preceding is the problem. Note that it takes special handling to capture the vlan header in an Ethernet frame as it is often stripped by the network interface, especially in Windows.

>>If the L16 is using the same switch port as the equipment it replaced, no VLAN change is needed.

In general I would definitely agree with this. Unless, of course, handling of the egress traffic from the switch is different because we have different devices. Unlikely, but not unheard of. Does anyone know if this model of PLC supports spanning tree? Looking at the spec sheet I see dualport/DLR, but did not see much else for specs.

Maybe post the switch configurations. Nice documentation of the problem, too, in the original post.

JeremyM said:

Verify the gateway address on the L18ER.

If the L16 is using the same switch port as the equipment it replaced, no VLAN change is needed.

Click to expand...

Theoretically, Yes. But what if someone switch the cable to another port.

Here is another way. plug in the laptop using that cable and see if you can ping the work station. If you can then , we verifed that there is a physical connnection between the PLC and work station. Turn off the wireless.

robertkjonesjr said:

>> Does the mac address of the new PLC show up in the ARP cache on the switches?

Unless the PLC is actually communicating with the switch at layer 3, there is no reason to expect the MAC address of the PLC to be in the ARP cache of the switch. We would, however, expect it to be in the forwarding or MAC-address table.

Click to expand...

Doh, You are correct. My mistake!

Am one of the guys also working with the same problem. We put another (a newer switch from cisco) switch after the last switch where the AB is connected (slide no. 4). After doing so, the workstation was able to connect with the PLC. Also, using another stratix unmanaged device, we were also able to communicate. It can be a way to resolve such issue, to put another switch, but the problem is we need to install around 37 units of AB PLCs and we cannot afford to buy 37 switches. Can anyone help to identify what really is the problem??

Coulombboy said:

Also, using another stratix unmanaged device, we were also able to communicate.

Click to expand...

We have been leading you to the path of a network issue and proposed several ideas on moving forward as to root cause. Your test provides evidence that indeed a network issue exists.

BachPhi said:

Theoretically, Yes. But what if someone switch the cable to another port.

Here is another way. plug in the laptop using that cable and see if you can ping the work station. If you can then , we verifed that there is a physical connnection between the PLC and work station. Turn off the wireless.

Click to expand...

We did this and we were able to ping the workstation. Only the PLC doesnt work with the network.

I found a rockwell knowledgebase document regarding Cisco and Rockwell Automation Hardware IP device tracking. The switch used is Cisco Catalyst 500 and IPDT might be implemented.

Below is the content of the document.

568750 False Duplicate IP detection on Ethernet modules when used with Cisco switches

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/addressresolutionprotocolarp/

118630technoteipdt00.

html

Workaround

Several workarounds to this issue exist. They all make suggestions using Cisco IOS commandline

interface commands.

Workaround 1

Architect manufacturing zone subnets such that:

1. IPDT is explicitly disabled on every trunk port with the following command:

Hostname (configif)#

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 usesvi

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 (configif)#

ip device tracking maximum 0

Do you guys encounter such??

Update

Please find the attach image for the update. When we connect the plc into the second switch as shown in the attached image we were able to ping it into the workstation.