How to Fix an EtherNet/IP Multicast Storm on a Shared Switch
Legacy EtherNet/IP implicit I/O often uses multicast, and on a switch that does not manage multicast intelligently, every multicast I/O packet gets flooded to every port, so a modest rack of devices can bury an unrelated PC or a lightly-loaded device under traffic it never asked for. The symptom is a device or host that struggles under load with no obvious sender, and the cause is a switch flooding multicast to ports that have no interest in it. This page confirms the flooding, fixes it with IGMP snooping and a querier, and segregates the traffic so it cannot recur.
Fix EtherNet/IP Multicast Storm in one line: To fix an EtherNet/IP multicast storm on a shared switch, first confirm the switch is flooding multicast to every port by reading per-port traffic stats, where non-I/O ports carrying heavy multicast prove the flood. Enable IGMP snooping so the switch forwards each multicast group only to ports that joined it, and configure one IGMP querier on the segment so snooping has the periodic queries it needs to work. Where multicast and general traffic must coexist, separate I/O onto its own VLAN so a flood cannot reach unrelated hosts.
Confirm the Switch Is Flooding Multicast
First establish that the problem is multicast flooding and not a unicast overload, because the fix is specific. Multicast implicit I/O, described in the contrast between multicast and unicast I/O, sends one packet that the network is supposed to deliver only to interested listeners. A switch that does not snoop multicast treats those packets like broadcasts and floods them to every port. Read the per-port traffic statistics on a managed switch: a port connected to a device or PC that has no reason to receive I/O multicast, yet shows heavy inbound multicast, is receiving a flood.
Correlate the flood with load rather than assuming it. The flooded traffic scales with the multicast I/O rate, so it is heaviest when many connections run at a fast RPI, which links this problem to sizing an RPI against network bandwidth. A host that bogs down specifically when the I/O network is busy, and whose port statistics show that busyness arriving as multicast it does not use, has confirmed the diagnosis. This is different from a host slowed by its own unicast traffic, so the port stats distinguishing multicast from unicast are what pin it down.
Note whether the switch even supports multicast management, because an unmanaged switch cannot snoop and will always flood. If the segment carrying multicast I/O runs through an unmanaged switch, that switch is the flooding point and no configuration will fix it there; it needs replacing with a managed switch or removing from the multicast path. Confirming the switch's capability up front avoids trying to configure a feature the hardware does not have.
Enable IGMP Snooping and Segregate the Traffic
The core fix is IGMP snooping, which teaches the switch who actually wants each multicast group. With snooping enabled, the switch watches the IGMP join messages that listeners send and forwards each multicast group only out the ports whose devices joined that group, instead of flooding all ports. Enabling snooping on the managed switches carrying I/O confines each multicast stream to its real subscribers, which is precisely what stops the storm. This is the single most effective change for a multicast-flooding EtherNet/IP network.
IGMP snooping does not work on its own; it needs an IGMP querier. The querier is the device that periodically asks listeners to renew their group memberships, and without those periodic queries the switch's snooping table ages out and the switch reverts to flooding to be safe. Exactly one querier must exist on the segment, usually enabled on one managed switch or a router, and having zero queriers is the classic reason snooping is enabled yet the network still floods. Configure a single querier and confirm the snooping tables populate and stay populated.
Segregation is the durable safeguard on top of snooping. Placing EtherNet/IP I/O on its own VLAN, as the concept of a VLAN for OT networks describes, keeps I/O multicast inside that VLAN so it cannot reach PCs, HMIs, or business hosts on other VLANs even if something misconfigures snooping. The VLAN bounds the blast radius: a multicast flood confined to the I/O VLAN affects only I/O devices sized to handle that traffic, not an office PC that would grind to a halt. Snooping plus a querier plus a VLAN is the combination that both stops the current storm and prevents the next one.
Frequently Asked Questions
What causes an EtherNet/IP multicast storm?
A switch that does not manage multicast treats EtherNet/IP multicast I/O packets like broadcasts and floods them to every port, including ports whose devices have no interest in that traffic. As multicast I/O scales with the number of connections and their RPI, the flood grows until an unrelated host or a light device is buried under traffic it never requested. The root cause is a switch forwarding multicast blindly instead of only to subscribers.
Why is IGMP snooping enabled but the switch still floods multicast?
Almost always because there is no IGMP querier on the segment. Snooping relies on periodic IGMP queries to keep its membership table current; with no querier, the table ages out and the switch reverts to flooding to avoid dropping traffic. Exactly one querier must be configured on the segment, on a managed switch or router. Add a single querier and the snooping tables will populate and stay populated, ending the flood.
Should I put EtherNet/IP I/O on its own VLAN?
Yes, where I/O shares infrastructure with PCs, HMIs, or business traffic. A dedicated I/O VLAN keeps multicast I/O confined so it cannot reach hosts on other VLANs even if IGMP snooping is misconfigured, bounding the blast radius of any flood to devices sized for that traffic. Combined with IGMP snooping and a querier, a VLAN both stops a current multicast storm and prevents it from reaching unrelated systems in future.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.