Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
Very interesting. So from a design point of view, I would imagine it would be a best practice to keep source subnets very small, no? I would imagine for many use cases, sources would be in "server subnets" with no clients in the same subnet which means all other servers in the "server subnet" would be hammered with the multicast traffic that they're not interested in. If this traffic is significant (like IPTV, etc.) this could cause significant issues. Does anyone have real world experience with such environments and care to comment?
Well if you have some form of multicast replication suppression, like ICMP snooping, other hosts shouldn't be subjected to the lost bandwidth if they're on a switch port. Also, depends somewhat on the volume of multicast traffic, for example some network control announcements (e.g. routing protocols) use multicast and we don't worry too much about the impact of this traffic on all the other hosts on the same segment. Last, also keep in mind the hosts themselves don't really get "hammered" by undesired multicast traffic as their NIC should just filter it out (like it would traffic to a different unicast address). (Note: one "gotcha" exception, the issue of IP multicast IPs mapping into the same Ethernet MAC multicast address. NIC will accept frame; higher level will have to determine if it's a desired frame.) (Also again, on a switch getting needless multicast traffic, that traffics does consume port bandwidth.)
Also BTW, in original broadcast Ethernet multicast saved bandwidth; in switched Ethernet w/o something like ICMP snooping it uses additional bandwidth (because of replication to each port) and uses additional switch resources (for packet replications to multiple ports).
Design wise, you will often find multicast sources only on server subnets mainly because some special server is what's generating the multicast flow.
PS:
Thinking some more about your design question, there's one port that's may be "hammered" even if it doesn't need the multicast packets; that port would be the multicast router's interface. Additionally it may need to accept and open these frames to determine if they're needed to forward off the local segment.
