Jumping in late, but still -
The SLM's (and SRW's) do support IGMP snooping.
I strongly suspect either a misconfiguration of the switch, or a NW issue.
From what I see, both the actual MC data and the IGMP reports (the JOINs) are flooded.
to me, this means the SLM thinks the port is a "Mrouter" port (or a "forward-all") port, and therefore it is flooding everything to these ports.
I suggest turning off "auto-learn" and manually telling the SLM where the Mrouter is. IF "auto learn" is enabled (as it is by default) then
if the switch sees anything that suggest a router is connected to the port (e.g. a DVMRP, PIM, MOSPF or even IGMP Query) that ports will
go to flooding.
Other things to note
1. You need to enable IGMP snooping globally and per-VLAN.
2. In "bridge multicast" web page, you should be able to see what IGMP snooping has learned - which ports
(per VLAN) have been added to the distribution list of a MC group. If none - the4 JOINs were lost. If even one
ports is seen as having dynamicaly joined, that MC group, in that VLAN will stop flooding - except to 'forward-all" and "MROUTER" ports
3. Note also the check-box for enabling/disabling the MC filtering. IF this is OFF you will get flooding in that VLAN
4. The fact that you get the wrong result when you ping "all hosts" (126.96.36.199) shows your hosts are doing non-standard things for MC. Could it be
they are sending Queries? or the Joins they are sending are for the wrong MC groups?
if you can upload your CFG file, I coud take a look.
While I am very familiar with these switches, I do not work for Cisco, and do not represent them (or anyone else, really ...)
I don't think the problem is that IGMP snooping isn't enabled or supported, it's that IGMP snooping does not function as you might expect UNLESS there is an IGMP Querier device on the network.
IGMP snooping, as implied by the name, is a feature that allows the switch to "listen in" on the IGMP conversation between hosts and routers. Here's an example of what might be happening based on my understanding of how the protocol works:
Host 1 boots up and joins MC group 188.8.131.52. To let others know to deliver this stream, it sends an IGMP unsolicited Membership Report to that multicast address indicating it's willingness to recieve traffic.
The IGMP snooping switch will then intercept this report and add Host 1 to it's snooping table with a default timeout of 300 seconds. This should prevent flooding until the timer expires.
Now,we need a layer 3 device to generate Membership Queries in order to renew this timer and keep the table populated. Cisco does this every 60 seconds. If this switch supports IGMP Queries, then a router is not needed.
If IGMP Querier is not enabled, then no IGMP Membership Queries will be sent to Host 1 in order to renew the timer on the IGMP Snooping table. Therefore, the entry will be flushed from the table and flooding will occur.
"Response3" - Everything you say is 100% correct, BUT
I got the impression in the initial question that the hosts ARE sending IGMP reports (In fact, at one point the original questions says the IGMP reports themselves are flooded).
So - either there IS a querier (which is not shown in the drawing), or the hosts are configured (somehow) to send IGMP JOINs even w/o a querier.
If there are joins but no querier, I am not sure what will (or should) happen.
On The one hand, the JOINs can be used to infer who wants to see what (and, by extension, who doesn't, which is the point of IGMP snooping).
But, without a query, what will the switch use to set the various timers?
Usually, the switch (any Switch) has a timer that starts when query is seen, and determines how long to wait until a response
should be seen - or until it can be concluded that no response is coming.
To have IGMP snooping work, the NW multicast support must work as per standard - Sources and distributors sending IGMP queries, receivers responding with IGMP reports, and switches snooping this in-flight. IF the NW does not have Queriers at all, It is probably best to add a synthetic IGMP querier (in each VLAN) that will send periodical IGMP general queries (for all groups). As an alternative, it is probably safer to manually set the Multicast distribution ports per MC group in the switches.
I wish I could draw a picture for all the configurations I tried, but that would take a lot of time... the bottom line is that a network composed of SLM2008 works great, but if you connected that network to any SLM2024 it messes the whole world up (including the 2008). My request is that the options available of the SLM2008 should exists on the SLM2024... There is question also of following the RFC with regards to flooding unregistered multicasts. Doing so has some serious limitations on a network used for multimedia transfer if you see the linking of a multicast address to a channel. According to the RFC if nobody is watching the channel, you can flood the channel to everyone. As you can see this is a problem if you have 12 cameras on the network.
The question of making sure a querier exists on the net is a good one... this would matter once the timeout is reached, but the problem with the SLM2024 exist immediately, not 300 seconds later. Either way we have a software querier running on one of the computers.
This has been a great discussion. We are looking to solve this in a future release via a querier.
JM - if you do not mind saying so, which software querier are you using? That was a great idea you have.
It's a perl script we found online...
The querier doesn't solve the problem though.... If the multicast isn't registered by someone, everyone gets the message, so you see that this is still a major problem with the 2024. Is this issue actually getting worked for this switch? Or is this being worked for the vapor-ware switch tobe?
If you have one, a windows server can also act as a querier with the
routing and remote access service started.
On Mar 16, 2010, at 9:26 AM, "firstname.lastname@example.org"
JM - As I understand it, our current plans are to add the querier / additional functionality to the switch (as eluded to in your Feb 23rd posting).
I am not a product manager and only things that are commited make it into the releases ... however this is my understanding. Perhaps a 'stay tuned' message is the best.
I hope this is helpful, and I greatly appreciate this conversation / posting. Over 1000+ views now ... so it seems a lot of other people are gaining from this too.