CIP Protocol and IA Logix Driver

Ignition
1

Working with support on a device connection issue.
Gateway has 44 devices.
6 are AB controllers and are latent.
All 6 are IA Logix drivers, firmware 31+.
Gateway version is 8.1.17

We have figured out with IAs help gateway is not receiving CIP responses from one device we are focusing on. 100% request/response packets can be seen at the device. 95% of responses are MISSING at gateway. The chain of network hardware is long and contains big iron switches/firewalls.

Using Wireshark, recording from both gateway and device endpoints missing packets can be observed by examining the CIP sequence #s.

I am looking to understand the communication on a packet level. I found the document:
https://support.inductiveautomation.com/hc/en-us/articles/26305379355021-Understanding-Allen-Bradley#h_01HWNKB0WHYS5P5HAS9Y632ZD6

We are using post processing on Wireshark traces to determine how many response packets are not arriving at gateway for groups of devices. I would like to understand how ignition Logix connections work better.

My questions:
Using IA Logix Driver in v8.1.17
For a single device, what is the range of possible CIP Sequence values?
How is the cip.seq (CIP Sequence) number generated?
How often does the cip.seq reset?
What does the gateway do if responses do not arrive? Ask Again? New cip.seq?

I am willing to read on my own if there is an online resource someone can point me at.

2

It's a 2 byte sequence number that increments with every "connected" request and eventually rolls over.

A new sequence number is always used. If a response doesn't arrive the corresponding request fails. Nothing is retried, sequence is not reused.

3

Amazing, very much appreciate your help!

4

If you aren't an ODVA member then unfortunately you can't access the EtherNet/IP spec...

the Wireshark decoder actually does a pretty good job breaking down the generic upper layers of the protocol. It only turns to opaque data once you're looking and vendor-specific CIP services. For the most part.

1 Like
5

This is not strictly true--there can be repeats for connection keep-alive, which the recipient is required to discard after resetting the connection timeout.

6

They aren't reused by the Logix driver.

7

Many thanks for the info. We are taking synchronized traces from within our network. I expect today we will identify root cause.

The image shows a source device, destination gateway packet. There are 2 cip.seq values on a single packet.

Can you guys share what a single packet with multiple cip.seq values means?

image

8

I would expect that to be due to the concurrency setting in the driver. The nested packets would belong to different concurrent connection buffers. Your infra is simply merging TCP traffic into larger packets, which should not hurt anything.

(It does suggest that your infra is messing with the low-latency status of the TCP channel.)

9

Root Cause:
Damaged fiber connection. Connection had redundancy, shut down damaged fiber.

Devices are now very performant!

I VERY much appreciate everyone who helped us resolve the problem.

4 Likes
10

Thanks for the update. Saw this when it hit support yesterday and was curious what the root cause was going to be.

1 Like
11

You are welcome.

I have not interacted with support a lot, but the experience was world class. The collaboration was essential to resolve our problem and get our teams aligned.

4 Likes