Is lots of multicast/broadcast Ethernet traffic common with CompactLogix?

We have 7 CompactLogix L35E PLCs at an installation. Watching the network, I can see there is lots of multicast/broadcast traffic going on. A packet sniff reveals the PLCs are originating this traffic. Is this a normal mode of operation for these PLCs?

We have Wonderware SCADA terminals using the ArchestrA DAServer (DASABCIP and DASMBTCP), directly communicating with the PLC IP addresses.

I'm not clear on why there's a need for lots of multicast traffic, since the PLCs know each other's IP address for messaging, and the SCADA software directly addresses the PLCs also.

I'm simply trying to determine if this traffic can be eliminated to reduce network congestion.

Thanks for any info.

You need to provide more details about your network hardware and configuration in order to answer your question. What type of switches are you using (brand, part number). Are you using unicast connections for PLC to PLC communications? What firmware are you running in the processors? Perhaps upload a network drawing. We need more information in order to answer your question.

Logix before V18 support mutlicast only, I believe.

Yes, this is typical and it's been discussed quite a bit here. It's the reason that cheap home grade switch can kill your network. You need to look for switch that supports IGMP Snooping.

Hello, I apologize for the lack of info in the previous post. A network diagram is below.

All PLCs are running v15 firmware. I don't know how to tell if they are using multicast messaging - can someone explain how to check? would this simply be by looking at the MSG instructions used, or within the Interface Configuration?



We have multiple buildings connected via fiber-to-Ethernet. Each building has a PLC cabinet with PLC, Ethernet Switch, fiber converter, etc. Everything is on the same subnet (10.0.0.x).

Everything is run to two central gigabit Ethernet switches, which are connected together also, to bridge our PC network and PLC/control network. There are more devices connected but not shown for simplicity

We just added Wifi access points at the various buildings, as shown.

Some supporting hardware etc omitted for simplicity.

We can observe multicast traffic by watching the RX/TX lights on the switches, which all blink in unison. Also, doing packet sniffing reveals a lot of traffic to multicast addresses originating from the PLCs.

Disconnecting the PLCs from the network eliminates the broadcast traffic.



Network diagram: http://www.gliffy.com/go/publish/10865353

Thanks for the info harryting. You said that pre-18 firmware uses multicast only. Is this simply cross-PLC communication? or would it also be utilized for PLC-to-SCADA comms also, even if the SCADA driver is connecting directly to the IP addresses of the individual PLCs?

If it's PLC-to-PLC only, shouldn't I be able to define VLANs at the switch level to only pass this traffic between the PLCs and filter from the rest of the network?

Here's a good thread on this topic:

http://www.plctalk.net/qanda/showthread.php?t=56325

Ryan,

This Multicast traffic could be communications to its IO, or potentially tags shared on a peer to peer basis between PLCs. I would expect SCADA traffic to be unicast, but I'm not sure.

As harryting said, the correct thing to do to manage multicast traffic is to use IGMP snooping.

The problem with using VLANs to separate the PLCs from the rest of the traffic is that you need SOME of the traffic to go through, but not all of it. I'm not saying it is impossible to configure with VLANs to accomplish this goal, but it certainly isn't a straight forward problem. Generally, VLANs should be used for devices that are to be isolated from each other (or on different subnets), and then you would use routers to connect them to the rest of the network.

This a totally normal and very common effect of ControlLogix and CompactLogix I/O over Ethernet and sharing of Produced/Consumed Tags. I used to dedicate nearly half of my classes on EtherNet/IP to the use and mis-use of multicast I/O and IGMP Snooping features.

You definitely want to pursue figuring this out and configuring your network to handle it; those poor WiFi access points are probably choking on this traffic.

A good place to start is the Ethernet Design Considerations network configuration and planning reference manual:

http://literature.rockwellautomation.com/idc/groups/literature/documents/rm/enet-rm002_-en-p.pdf

And the Troubleshooting EtherNet/IP Networks application manual:

http://literature.rockwellautomation.com/idc/groups/literature/documents/at/enet-at003_-en-p.pdf

Thank you! I now have a lot of reading to do!

As has been mentioned (and hinted at), RA implemented Unicast addressing starting in v16 and improving/evolving later for many of the functions that had been Multicast (only or by default) previously. Many ControlLogix and CompactLogix systems today can do all their work with no Multicast traffic at all, making configuration and maintenance of the Ethernet networks easier.

Here's a concise guide to Unicast support for various functions in various ControlLogix and CompactLogix controllers: RA Knowledgebase Article ID 66324, Unicast I/O Support in Logix (Access Level: Everyone).

The 1769-L35E controller started with v12 firmware** and ran all the way to v20, so a firmware update might be an appropriate way to improve your network functionality.


** There are more details about the history of the CompactLogix family, but I deduce that you have 1769-L35E Series A controllers, so let's keep it simple.