Packets of info being sent by PLC


Thread Starter


Hello all,

We have a machine in a train with two other machines and all have their own PLC. The machine strain is then tied to a network that looks at several machines. The IT folks tell me that the PLC on our machine is sending packets over the network taking up a lot of space. Our ethernet communications ladder has no MSG instruction and our programmer says this is not possible. HELP!

Curt Wuollet

Your programmer is mistaken. It's closed source secret software, it could be doing anything beneath the covers. Just because you aren't doing any explicit messaging doesn't mean the firmware isn't going nuts trying to get some piece of information it can't find on the network. If possible, simply shut it off for a bit and see if the traffic stops. Or set up a sniffer and see what it's trying to do. I've seen all sorts of gear jabber a network to death, hubs, switches, even a printer.


Dave Nardella

Most likely they are right : keep-alive, discovering functions and other low-level packets happen without plc instructions.

The point is, in my opinion, that a plc network (regardless of the vendor) should never be "mixed" with an IT network.

Anyway look at network design, with an honest net switch surely you can limit the network traffic inside your machines.

In the worst case, use wireshark tracking the plc IP address and say us what kind (protocol) of packet are circulating.


Gerald Beaudoin

> The point is, in my opinion, that a plc network (regardless of the vendor)
> should never be "mixed" with an IT network.

This is an essential point.....although it may all be called "EtherNet" whatever.....the types of traffic and the priorities are vastly different. If nothing else, just from a troubleshooting point of view....separate the networks.....and keep them that way.
Thank you...I will see what I can do about separating. It's not our network and I have to try to convince the IT folks!
I know this was suggested earlier but you really should try wireshark. You will probably need an old school hub (not switch) and plug both your wireshark PC and device into it (and of course the company LAN connection so that you can simulate the faulty behavior). This lets your PC "see" all of the traffic on the PLC and LAN connections. You can trigger off of the IP address of your PLC and you will see all of the traffic coming into and out of it. At least then you can tell your IT department exactly how much traffic your PLC is generating (or not).

I needed to hook up wireshark to a Mitsubishi PLC because I was getting strange delays in my responses and it turned out that it was waiting for a response from the PC at the other end before it would send the next message out. Windows PCs by default apparently don't send ack's right away on the first packet and if nothing else comes in it takes a second or two to timeout and send the ack. It turns out that I had to set a registry entry on the PC (server) to send ack every packet to handle this strange behavior in the Mitsubishi PLC. I'm sure this has nothing to do with your problem, but it illustrates just how strange PLCs can be in their implementations.

There are multiple cases of cyber accidents caused by PLC/Itnetwork interactions, including the famous HATCH nuclear reactor accident where an IT tech pinged the network causing a DOS attack on the PLC controlling the cooling tower pumps. This caused a hardwired reactor scram and the plant was out of service for several days.

Separate your networks. IT should know this. If they don't, please get them a copy of Joe Weiss' book on cybersecurity (Amazon has it).

Walt Boyes, FInstMC, Chartered Measurement and Control Technologist
Life Fellow, International Society of Automation
Editor in Chief, Control and
[email protected]
A few questions:

1. What PLCs? Make and model please.
2. What protocols are you using? CIP? Modbus? DNP3?

It's just a theory, but if those PLCs are accessible over the internet, they could be the targets of some massive Internet based scans that have been conducted for automation protocols over the past few weeks. The scans are using a new scanner that is highly bandwidth intensive, and if your systems are internet accessible you've likely been caught up in them.

First rule of Automation: Don't be internet accessible.

It's highly unlikely that your IT department knows much about automation, or those PLCs wouldn't be on 'their' network. The risk to production of keeping automation equipment on a corporate network is huge, get em off as soon as possible and on to their own network.

Mike Toecker, PE

Eddie Willers

If the CompactLogix has remote I/O modules connected to the Ethernet network, or is performing "Produced/Consumed Tag" data exchange with other controllers, it is very likely that you are seeing UDP Multicast traffic.

It will have multicast group destination addresses, rather than the ordinary IP destination addresses you are accustomed to, and it will show up immediately in Wireshark as CIP protocol traffic.

This is an ordinary I/O mechanism used by ControlLogix.

It can be made less impactful on the network by changing the connection type to Unicast instead of Multicast, or by using properly configured Ethernet switches that perform IGMP querying and snooping.