First, there are those devices who have no interest in anything happening on any of my PLC sub-LANs. IGMP snooping will recognize this and prevent traffic from reaching those devices.
Yes and no. Let's step back - there are several layers of filtering here. A layer 2 switch has the concept of a forwarding table - it sends Ethernet frames to a particular destination (this destination is a switch port). If these devices here are not involved in any communications with other devices, on a switched network, then the switch will not typically forward frames to these devices. There are exceptions:
1. Broadcast traffic - this by definition goes everywhere.
2. Multicast traffic - if not handled properly. IGMP is one of the mechanisms that will handle this.
So the devices that have no interest will not receive unicast traffic (which is point-to-point) for other devices because of your Ethernet switches and has nothing to do with IGMP. This is filtering at layer 2. If you use hubs (don't, by the way) then even unicast traffic is treated as broadcast and sent everywhere - but this is why we use switches so this doesn't happen.
IGMP takes care of the multicast traffic only. Two very distinct levels of filtering.
Second, there are those PLC related field devices that have been configured for Unicast connections with their associated processor. Like those devices in the first catagory, only the specific communications from the processor will be sent to the device and then the specific responses from the device will be sent back to the processor.
I agree with this, on a switched network with unicast communications.
Thanks to IGMP snooping, none of these point-to-point specific communications will go anywhere else.
As in the first example, IGMP only takes care of multicast. Point-to-point communications is handled by the layer 2 switching.
Multicast traffic that other devices are using will not be forwarded to these devices because of IGMP.
Finally, there are the multicast communications where non-specific calls are made to all devices on the network. These calls, made by the processors, are seen and then responded to by any device out there who is not specifically configured to do otherwise.
I don't really understand this - in your scenario here it almost implies broadcast communications. EtherNet/IP does not really use broadcast mechanisms for communication so I don't see this happening (by way of counter example, CodeSys-based products can have the concept of network variables which can be configured to use true broadcast addresses).
If you choose to (or have to, based on product capability) use multicast then there is still the concept that specific devices are communicating with one another; an unfortunate side effect of multicast communications is that it is treated as broadcast by layer 2 switch devices so ALL devices on the local broadcast domain (i.e. subnet) will see the multicast traffic, even if they don't want it. Then IGMP is used to stop this.
Another view:
Layer 1
Device type: Hub
Notes: ALL Ethernet traffic is broadcast - sent out all ports
Layer 2
Device type : Switch
Notes: Unicast traffic is filtered for ONLY the ports that need it, based on destination address. Broadcast traffic (some amount is almost always necessary on modern Ethernet networks) is still sent out all ports so is 'broadcast'. Multicast traffic is treated as broadcast by default, so sent out all ports.
IGMP
Notes: Management mechanism for multicast traffic where hosts register what they want to see, and multicast traffic is sent to ONLY those ports that specifically request it.
So we have different levels of filtering going on - the switch does some for unicast traffic, IGMP does it for multicast traffic. In both cases, think of tables in the switch that show where traffic should go. Switches use MAC addresses, and the tables are based on destination MAC:
This is a forwarding table in a managed switch. ALL switches have such tables, but with unmanaged switches we just don't have access to it - you can't see or manipulate it.
The first entry is for a device: so the switch knows that to get to the device, send out port 8 ONLY (1.8 as shown in the table). The other 7 ports will not see this traffic. If we address an Ethernet frame to this MAC address, it will enter the switch, and go to port 8 only. This is MAC filtering, which all switches do. A hub, at layer 1, would send this same frame out ALL ports. Usually not good.
The second MAC is the MAC address of the managed switch itself, so if I try to manage the switch through the webpage, my Ethernet traffic destination will have this MAC, and will be forwarded to the CPU of the switch.
The third entry is for another device, this time located on port 7.
The last two are multicast addresses, with IGMP enabled. The entries show that multicast traffic will be forwarded to ports 7 ONLY, none of the other ones. If I turn off IGMP, these entries disappear and then this same multicast traffic would be forwarded to ALL ports, which is obviously not desirable.
What if two devices wanted the same multicast traffic, and we are using IGMP? I will edit the picture to show what it would look like. Perhaps there is a device on port 3 that wants the multicast traffic from the last row:
Now that same multicast Ethernet frame that enters the switch will be forwarded to BOTH ports 3 and 7.
