Posted by: Harold Ennulat | January 18, 2010

EtherNet/IP I/O Mischief

Does anyone one know what you get when you attempt to put Ethernet I/O directly on to the Business network?

In the previous post, it was pointed out that for security reasons the I/O network should be separated from the business Ethernet or any other Ethernet network.  However, aside from the security concerns why would putting the I/O directly on the business LAN be of concern?  Apparently this has been tried with the result of bringing down the entire plant business operations!

When using Ethernet for I/O, the devices do not wait to be polled typically. The I/O devices are set up to communicate at a fixed periodic rate. This communications burst is not addressed to a particular PLC, instead the data is typically multicast, which means that every device on the network sees this traffic and needs to figure out if the message is for them. Normal Printers and network attached devices just can’t handle such requests at a rate of every 20 milliseconds for 100 or more devices. While the wire can support speeds of 100 MB per second, very few Ethernet cards can handle this much communications especially if they are comprised of thousands of short messages.

The above reflects my experience with Allen Bradley Ethernet/IP I/O networks. The above discussion should be true for any Ethernet/IP networks that use multicasting. There is an option now to use unicasting for I/O which communicates to a particular PLC.  Does anyone have experience with unicasting?  I expect there are some considertions here as well.

Another topic of interest is the necessity of adding IGMP snooping Ethernet switches in I/O networks such as the N-Tron 500 series switches. IGMP snooping built into switches read multicast messages from each port and determine which port to route the message to. This keeps network traffic down along each cable segment. Is this really needed if the I/O network is already isolated?  I initially thought that it might not be, however in posing this question on the LinkedIn “Automation & Controls” group, I was reminded that I/O adaptors themselves may be trying to figure out if messages from other multicast devices are for them.  Problems have been reported, so the answer for now is to continue to use IGMP snooping switches.

Post updated 1/20/2010   Thanks to Dean Colwell, Chris Craig, and Jason Kuhr for their contributions.


  1. When it comes to business networks (IT normally controls) and they either not prepared for multicasting (the proper switch mechanisms have not been turned on) or they do not allow multicast entirely. Important to note that you’ll see multicasting when using implicit messaging with Ethernet/IP (in a Produced/Consumed scenario). A switch (that sees multicast packets without having IGMP on), treats them as broadcasts and *shoots* them out all ports– which is why the whole network has the potential to be brought down. There is an option to do Unicasting in Ethernet/IP too (with the proper versions) if you don’t really need multiple clients — just a thought.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s


%d bloggers like this: