Some of the most widely used industrial protocols send their I/O data as multicast, one producer transmitting to many consumers at once, and that is efficient in principle. The catch is that a switch, left to its defaults, treats multicast like a broadcast and floods it out of every port, so a single busy producer can bury every device on the network in traffic that most of them do not want. IGMP snooping is the feature that fixes this by learning who actually wants each multicast stream and delivering it only to them. This page explains what IGMP snooping is, the role of the querier, and why forgetting to enable it is a classic cause of mysterious I/O timeouts.
IGMP snooping in one line: IGMP snooping is a switch feature that watches the IGMP messages devices use to join and leave multicast groups, so the switch learns which ports have devices that actually want each multicast stream and forwards that stream only to those ports instead of flooding it everywhere. In SCADA it matters because multicast-heavy protocols such as EtherNet/IP producer-consumer traffic and some PROFINET communication can otherwise flood every device on the switch. Without IGMP snooping, and a querier to keep it working, that flood can overwhelm device network interfaces and cause the I/O timeouts that look like random communication failures.
Multicast is a way of sending one copy of data to many recipients at once: a producer transmits to a multicast group address, and every device that has joined that group receives it, which is far more efficient than the producer sending a separate copy to each consumer. Industrial protocols use this heavily because it fits how control data is shared, where one device's measurements or outputs are of interest to several others simultaneously. In principle the network carries the data once and everyone who cares gets it, which is exactly what you want on a busy control network.
The problem is what an ordinary switch does with multicast when it has not been told any better. A switch forwards frames based on the destination address, but multicast group addresses do not map to a single port the way a normal device address does, so without extra intelligence the switch cannot tell which ports have interested devices. Its fallback is to treat the multicast like a broadcast and flood it out of every port except the one it came in on. That means every device on the switch receives every multicast stream, whether or not it subscribed, and has to spend effort inspecting and discarding the ones it does not want.
On a lightly loaded network this waste is tolerable, but industrial multicast can be relentless. A producer-consumer protocol may transmit I/O data many times a second, and a network with many producers generates a continuous, heavy stream of multicast that, when flooded to every port, lands on every device at once. Small industrial devices with modest network processors are hit hardest, because they must examine each flooded frame only to throw it away, and that overhead competes directly with the work of servicing their real communications. The default flooding behaviour, harmless on an office LAN, becomes a genuine load problem on a multicast-heavy control network.
IGMP snooping fixes this by having the switch listen in on the IGMP messages that devices already send to manage their multicast group memberships. When a device wants a particular multicast stream, it sends an IGMP membership report, in effect announcing that it wishes to join that group. A switch with IGMP snooping enabled watches for these reports and notes which port the joining device is on, building a table of which multicast groups have interested devices on which ports. Armed with that table, the switch stops flooding and instead forwards each multicast stream only out of the ports where a device has actually asked for it, which is precisely the pruning that eliminates the waste.
For this to keep working, the group memberships have to be refreshed, and that is the job of the querier. A querier periodically sends IGMP query messages asking devices which groups they still want to be in, and the devices respond with fresh membership reports, so the switch's table stays current and it does not either keep sending a stream nobody wants anymore or stop sending one that is still needed. The critical practical point is that a network doing IGMP snooping needs exactly one active querier somewhere, and if no device is playing that role, the queries stop, the membership reports age out, and snooping can break down. A network can have IGMP snooping enabled on its switches and still misbehave because nobody enabled a querier, so one switch is typically configured to be the querier for the network.
When snooping and a querier are both working, the effect on a multicast-heavy control network is dramatic. The multicast that would have flooded every port is confined to the ports that subscribed, so devices no longer waste their interfaces discarding streams they never wanted, and the overall load on the network drops to what the actual subscriptions require. This is why IGMP snooping is not an optional refinement on an EtherNet/IP or comparable multicast network; it is part of making that network function, and it must be enabled consistently across the switches in the multicast domain, because a single switch that floods can undo the pruning done by the rest.
The classic failure is a network that works fine when small and then starts throwing intermittent I/O timeouts as it grows, and the root cause turns out to be multicast flooding because IGMP snooping was never enabled or the querier was never set up. When flooded multicast piles onto a device's network interface, the device can miss or delay the messages that actually matter, and a producer-consumer connection that does not hear from its partner within its expected interval declares a timeout and drops the I/O. To the operator this looks like random controllers or I/O modules losing communication for no obvious reason, often under load, which is a maddening symptom to chase because nothing is physically broken.
What makes it so easy to miss is that everything appears correct on inspection. The cabling is fine, the devices are healthy, the configuration of the control logic is right, and at low traffic the network passes every test. The trouble only appears when enough multicast is flowing that the flooded load crosses the threshold where small devices start dropping frames, which may be well after commissioning as more equipment is added. Because the cause is a network-wide forwarding behaviour rather than any single faulty component, technicians can spend a long time swapping cables and devices before someone thinks to check whether IGMP snooping and a querier are actually enabled and working across all the switches.
This is where monitoring turns a mystery into a diagnosis. A managed switch can report its port traffic levels and error counts, and multicast flooding shows up as unusually high, broadly uniform traffic on ports that have no business receiving that much, which is a fingerprint quite different from a genuine device fault. Feeding those switch statistics and the pattern of I/O timeouts into a cloud SCADA platform such as Merobix lets staff correlate the timeouts with traffic surges and see that many devices are being hit at once, which points straight at a flooding problem rather than a failing device. The lasting fix is always the same, enable IGMP snooping consistently on every switch in the multicast domain and make sure exactly one querier is active, and confirming that in the network configuration is a standard early check whenever a multicast control network starts timing out.
Any protocol that carries its I/O or data as multicast benefits from IGMP snooping, and the most common example is EtherNet/IP using its producer-consumer model, where a producer multicasts data to multiple consumers. Some PROFINET communication and various other real-time industrial protocols also use multicast. If a network carries heavy multicast from these protocols and IGMP snooping is not enabled, the switches flood that multicast to every port, so enabling snooping is effectively a requirement rather than a tuning option on such networks.
IGMP snooping relies on hearing regular membership reports from devices, and those reports are prompted by the periodic queries a querier sends. With snooping on but no querier, the queries never go out, the membership reports are not refreshed, and the switch's picture of who wants which multicast group ages out and becomes unreliable. This can cause multicast to be dropped for devices that still want it or handled inconsistently, so a snooping network must have exactly one active querier, usually configured on one switch, for the feature to work properly.
Yes, and it is a classic cause. Without IGMP snooping, multicast I/O traffic is flooded to every port, and on a busy network that flood can overwhelm the modest network interfaces of small industrial devices, making them miss the messages their I/O connections depend on. A producer-consumer connection that does not hear from its partner in time declares a timeout and drops, which looks to operators like intermittent, unexplained communication failures under load. Because nothing is physically broken, it is easy to chase the wrong cause, so checking that IGMP snooping and a querier are enabled is a standard early diagnostic step.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.