Ethernet/IP (I/O) across a gateway/router

jdbrandt · Sep 12, 2016

Well, I came across this gem in some Rockwell documentation today:

You cannot bridge EtherNet/IP I/O across networks. I/O modules must be configured in either a local chassis or a remote chassis. You cannot go through a gateway chassis to control I/O even though, in some circumstances, RSLogix 5000 software accepts such a configuration in the I/O Configuration folder.

Now, I suppose, it all depends on your definition of a 'gateway chassis', but there is a specific reason this is interesting.

I have a PLC (192.168.1.2) with a real gateway/router at (192.168.1.1), and lost of EIP I/O in the 192.168.1.xxx...all that works.

We are doing MSGing across this router, with success, to the other network.

I'd like to access an Ethernet/IP I/O device on another network, through the (192.168.1.1) gateway/router, and it doesn't work.
If I connect the device to the local network, and re-address it in the 192.168.1.xxx range (like the already-working local I/O), it works...which shows me the device is happy.

If I connect the device (reset to its address on the 'other' network, directly to the gateway's external network port, it still doesn't work...proving that its not a network infrastructure problem on the other network.

So, the real question for plcs.net is: Does all this sound right? More importantly, What is so different about a router/gateway accessed address, versus an address on the local network, that does not allow Ethernet/IP (for I/O) to work?

robertkjonesjr · Sep 13, 2016

jdbrandt said:
So, the real question for plcs.net is: Does all this sound right? More importantly, What is so different about a router/gateway accessed address, versus an address on the local network, that does not allow Ethernet/IP (for I/O) to work?

Yes, it sounds correct if you are using multicast with your EtherNet/IP Class 1 I/O connections. Per ODVA spec, the TTL for the multicast packets is 1 so they cannot cross a router. But even before this comes into play, it takes special care to route multicast - usually we use PIM. Do you have a PIM-capable router, and is it configured properly? Try PIM-sparse mode, but if that doesn't work, you can try one of the others (sparse-dense is what Cisco likes to use with their PIM capable gear).

This assumes multicast is in use, and it may not be. If not, I am not sure of the root cause. A packet trace is an excellent way to troubleshoot this issue if you can get one. The symptoms for multicast would be, in the trace: connection establishment for the Forward_open to start up the I/O comms should be fine - it is unicast/TCP. Then UDP traffic will flow; multicast from the Target (T->O), and unicast from Originator (O->T). So depending on where you capture the traffic you will see different things. If you capture on the target side of the router, you will see all traffic but it should then timeout. It won't be obvious what is happening or wrong - all data is there. If you capture on the originator side, you will see Forward_open, then the unicast/UDP traffic O->T, but will not see any incoming data from the I/O device. The timeout will be obvious here.

Of course, perhaps there is a general routing issue and the Forward_open never never succeeds. Or a host of any other possible issues...

If you are using multicast, switch to unicast. I don't have a trace handy, but I recall the unicast variant from Rockwell had a TTL that is a little more normal, and this should route fine. The reason messaging works is because that is unicast/TCP, so will generally route fine. It may also be possible to adjust the TTL of multicast comms through one of the CIP network objects, but then you still need a multicast capable router.

jdbrandt · Sep 13, 2016

robertkjonesjr said:
Yes, it sounds correct if you are using multicast with your EtherNet/IP Class 1 I/O connections. Per ODVA spec, the TTL for the multicast packets is 1 so they cannot cross a router. But even before this comes into play, it takes special care to route multicast - usually we use PIM. Do you have a PIM-capable router, and is it configured properly? Try PIM-sparse mode, but if that doesn't work, you can try one of the others (sparse-dense is what Cisco likes to use with their PIM capable gear).

This assumes multicast is in use, and it may not be. If not, I am not sure of the root cause. A packet trace is an excellent way to troubleshoot this issue if you can get one. The symptoms for multicast would be, in the trace: connection establishment for the Forward_open to start up the I/O comms should be fine - it is unicast/TCP. Then UDP traffic will flow; multicast from the Target (T->O), and unicast from Originator (O->T). So depending on where you capture the traffic you will see different things. If you capture on the target side of the router, you will see all traffic but it should then timeout. It won't be obvious what is happening or wrong - all data is there. If you capture on the originator side, you will see Forward_open, then the unicast/UDP traffic O->T, but will not see any incoming data from the I/O device. The timeout will be obvious here.

Of course, perhaps there is a general routing issue and the Forward_open never never succeeds. Or a host of any other possible issues...

If you are using multicast, switch to unicast. I don't have a trace handy, but I recall the unicast variant from Rockwell had a TTL that is a little more normal, and this should route fine. The reason messaging works is because that is unicast/TCP, so will generally route fine. It may also be possible to adjust the TTL of multicast comms through one of the CIP network objects, but then you still need a multicast capable router.

Awesome reply, thanks. I need to do a little more research, of course. But, I do know that we do NOT have Multicast selected (which is to say we DO select UNICAST).
What is PIM and TTL?

robertkjonesjr · Sep 13, 2016

TTL is for Time-To-Live, but really it represents the number of hops. The idea is that we don't want packets lasting forever so this field in the IP header is decremented by one each time it crosses a router. When it gets to zero, it is dropped. So multicast packets, for EIP I/O, are set to one so the first time they hit a router, they are dropped.

PIM is a routing protocol for multicast, and it stands for protocol independent multicast. I need to run this to route multicast across my various subnets. It's usually a more expensive feature in routers.

A trace is recommended then if you are using unicast comms. Something else is wrong and it will likely be evident from analyzing the trace. It could be the unicast/UDP data packets have TTL of 1, but from memory they were much higher, 32, 64, whatever.

Ethernet/IP (I/O) across a gateway/router

jdbrandt

Lifetime Supporting Member

robertkjonesjr

Member

jdbrandt

Lifetime Supporting Member

robertkjonesjr

Member

Similar Topics