First let me apologize for this rather lengthy post, I have tried to condense the information the best I can. I am having problem setting up proper multicasting settings on the SLM series switches. The IGMP snooping doesn't seem to work as advertised/expected.
I've read the following threads, and it seems to have some similar veins but doesn't seem to address the SLM2024 issues I am seeing
No matter what I do, the 2024 seems to broadcast all multicast packets down every port. This doesn't seem to matter whether or not any hosts have asked to join a multicast group or not. Everyone gets everything. As you can see from the diagram below, that can result in quite a mess since each camera can use ~40+% of a GigE pipe.
The same thing occurs on the 2008 unless I turn off the option to broadcast unregistered multicast. But from what I see on wireshark, even multicast addresses with join requests are being flooded.
1. When multiple IGMP snooping switches are used as shown above, do the switches treat adjacent switches as "routers" as defined by rfc4541
2. The provider of a multicast stream may not be the one who joins the group first since it already has the data locally. If a stream starts up prior to anyone joining it, will the switch/es be smart enough to transition from treating the packets as unregistered multicast to treating them as registered ones?
An unregistered packet is defined as an IPv4 multicast packet with a destination address which does not match any of the groups announced in earlier IGMP Membership Reports.
3. So the way I read this is that once a group membership is received, the switch should cease flooding the packets associated with this membership and only forward them to the appropriate ports. Conversely I would also expect that should the last listener leave the group, the switch will begin to flood all ports with its data ... this sounds wrong.... Is that the case?
4. When looking at the port with Wireshark, I see a many join reports from other hosts.. Is this in conflict with rfc4541 2.1.1??
5. Is there a way to see what memberships groups the switch currently recognizes?
6. If 2 IGMP snooping switches are connected to each other, do they communicate so that only needed multicast packets pass between each other, Or will they forward all the packets? Two SLM2008 connected to each other appear to only forward the needed traffic, but if I connect the same 2008 to a 2024, it starts passing all the multicast to the 2024 without regard for the multicast joins. and the 2024 with flood each one of its ports with that traffic.
7. Pinging 188.8.131.52 should return the ip of all multicast capable hosts. when I try it, I end up getting multiple entries for the same IP/icmp_seq combo... I'm not sure what would cause this. Any thoughts?
8. Port mirroring on a port on a LAG doesn't seem to be allowed on the 2024 (even though it is allowed on the 2008).. The LAG isn't an option in the pulldown either. Am I doing something wrong?
Some side notes that maybe helpful:
1. I've tried both the 1.0.1 and the 184.108.40.206 version of the SLM2024 and I can't seem to get it to work.
2. The SLM2008 webgui is significantly different for the SLM2024 ( MUCH easier to setup/use and debugwith . Kudos to that development team)
The Status page is extremely useful, and I hope that it transitions over to the 2024 at some point. It also works with any browser as opposed to the
2024 that requires firefox or IE/activex etc.
3. I have IGMP snooping turned on all switches. All SLM2008 additionally have the option to broadcast unregistered multicast disabled.
Hello and good morning.
I checked the release notes and do not see any mention of known issues / limitations of our IGMP implementation. If you wish to call our support, please use this link to find the correct phone number for your country:
This might be a good idea since the support teams might have access to current or suspected bug info.
Here is the admin guide:
The admin guide describes the switch's behavior as well as required configs. Have you verified the configs versus the guide?
Some comments are below:
1) - RFC 4541 support? Not sure about this RFC, although supporting v1 and v2 would indicate we are compliant and should be able to intercept and understand IGMP join requests / group reports.
2-3) - Should there be any mcast on the network without a receiver? This begs the question, are you running dense mode of some sort? I do not have an understanding of your network design / layout, however most people are running sparse-mode.
From the source perspective, yes, the source will send traffic and the first hop router ought to register with the RP a new source. If a source has registered with the RP, and there are no receivers, then the RP will register the source and wait for receivers.
Do you have mcast traffic traversing your network without any receivers? If you have mcast traffic traversing your network without any receivers then I might suggest that you all re-visit your design.
Yes, the switch will build the igmp database based on the requests and reports received. It sounds as though this is not happening in your network. For this reason, it might be best to call support (see the link above)
4-5) Not sure we have implemented RFC 4541 and I am not sure how we interpreted this if we do. I do not see notice of it.
For show commands, you can use what is on WebUI, if it is not there then we do not have it avail.
6,7 and 8)
6 - it appears that IGMP snooping is working between two SLM2008s and not between the SLM2008 and 2024? It might be best to call support on this one, since I do not have access to the engineers and the question could be related to specific implementations and cross communication between the platforms. Have you configured trunk links between the switches?
7 - pinging the group 220.127.116.11 is an unreliable method for checking all hosts. For me, this seldom produces and outcome that I can use.
8 - Have you checked the admin guides? This might be a platform implementation limitation.
Some side notes:
Thanks for the nice comments, I will pass them on.
Interesting to hear this is for the cameras.
What type of routers are you using? I am curios only from a mcast perspective. Some routers might not support mcast, PIM, or IGMP ... and this makes things even more 'fun'.
On the SLM2024, have you considered hard coding the groups for each interface? if the groups are static, this might help you but would require additional configuration.
Have you considered a Cat 2960? The 2960 has many show commands and debugs which would greatly help your network installation and management. The Cat 2960 also has many many many additional features and functionality.
Here is a link to the latest 2960 Config guide.
You can use the left hand menu to select the feature or solution.
Do please respond and let me know your thoughts and commands. HTH and have a great day,
Andrew Lee Lissitz
I have just purchased a SG200-26 and have the same problem as is described above when IGMP snooping is enabled: with only one linux source of multicast packets and one linux listener using a small perl script to generate IGMPv3 queries, the listener gets the multicast stream even when it has no program subscribing to any stream. tcpdump verifies that the listener is not generating igmp joins, only the query packets are seen on the network. The switch has been changed from factory default to *only* enable igmp snooping on VLAN1. Does the SG200-26 require a full multicast router in order to filter? I don't need the streams to be routed out of VLAN 1.
I have diagnosed and fixed this problem. IGMP snooping does not work on a VLAN which is part of the switch's management VLAN. So create a video VLAN and enable IGMP snooping for that VLAN. You will also need some device on that VLAN issuing IGMP query packets. I run a perl script mentioned below to do that. The switch works perfectly running in that setup.
Ok, now I understand a little better of what you all are trying to do. For some reason I did not catch that this is on a single LAN.
Do please let me know what happens with the case, also, you can reference this link so that the folks in support can 'skip ahead' some. If you have not already done so, can you back up and get a copy of your configs? This might be required.
I have seen the hard coded groups work on the SRW switches, I am not sure about the SLMs. I have worked with a few partners via this community w/ hard coding the mcast groups. The admin guide does list this, so this should work. Please be sure to raise this as well.
Have you considered the ESW switches? Here is a link to the ESW datasheets:
These might be a bit more suited for the installation and are less money than the 2960s; more in between.
I am a big fan of the Catalyst switches ... not much these can't solve / solution. I understand how limited budgets can impact technology choices. As you have found, one of the bigger problems with the lower end switches is a lack of visibility and or tweaks; sometimes we need these and sometimes the installations require traditional Cisco.
None-the-less, do please let me know how you make out. Kindest regards,
I'm still waiting to hear back from the switch expert... I haven't heard anything yet... I hope I'm not falling through the cracks.
If it has been more than a day, then call back and ask for the case to be escalated immediately. If you like, you can also private message me the case number and I can try and look up the team, although I am not in the support group.
Andrew Lee Lissitz
For everyones benefit, sadly, this is where this issue currently lies.
The IGMP v1 & v2 protocols used by the Cisco Small Business Series (& Cisco Pro) switches do in fact flood the stream to the entire VLAN unlike the CGMP protocol available on our Enterprise level switches. I apologize for any inconvenience this may cause.
Do you have plans to change this??? I don't think we can classify the SLM2008 as a enterprise class switch, and it doesn't do this... Since the SLM2024 is in the same series it should support a feature that is enabled on the lower port variant. Our application is an embedded system without a router so using a enterprise switch is not an option.
There are no plans to change this to my knowledge. I will need to conduct some testing on the SLM2008. I need to acquire another multicast router and server before I can.
Thanks for the update JM.
I am going to follow up internally ... if I hear anything different I will update this posting.
Kindest regards JM,
I ended up getting this reply:
"I received a response from the product engineer. She reports we will not be adding this feature to the current shipping SLM2024 but this feature will be supported in the replacement of SLM2024 (Cisco SG 200-26).This new switch should be available by late 2010, or early 2011."
So buyer beware... If you buy this switch it will not do IGMP snooping as you would expect and cannot be used standalone in a system with a large number of multicast streams (ip-TV, Gig-e Vision.. etc) or even a few high-bandwidth streams.
If you used the SLM2008 to decide wether or not to purchase the SLM2024 like I did, you are out of luck. The 2 switches have completely different feature sets.
Many thanks for the update.
Any chance your SBMM or sales person can get you a sweetheart deal on the Catalyst series? Perhaps the sales person can look into the technology migration program and give you some credit for what you have already purchased.
(on a personal note)
For the environment you are describing, I would love to see this be done on the Catalyst switches. So much more you can do and pretty much work around and within any environment, ease of use in installation with CNA, greater visibility, security, QoS, expandable ... etc ...
Any who, thanks again for the update.
We are using this in a very embedded and low cost application. The catalyst is pretty-much out of the target price point for the quantities we are considering. What we need is a SLM2024 that works as well as the SLM2008. This is still quite a large pill to swallow that the lower cost, lower port, simpler interface switch supports features that its higher price brother doesn't.
Quite frankly I am very disappointed in how this was handled... I just don't understand why it takes 2.5 months, 3+ different people to tell me something I already knew... the switch doesn't work as well as it's low cost variant. I suppose I did get another piece to the puzzle. Cisco doesn't view this to be a big enough problem to fix it. It was a big enough problem to include the feature on the SLM2008 though. Sadly this isn't the first time this has come up.
That ended by driving the business to a competitor (HP). I fear I will end up in the same boat, and I don't have to tell you that once you push a customer away, they usually don't come back.
ps: I have no idea why "P_I_L_L" is considered a taboo word.
I understand what you mean; I do. I have once again picked this up and am asking for this to be escalated.
Thank you for this posting,
IGMP snooping does not work by itself. It relies on IGMP Queries to be generated and then it listens to the Membership Reports sent in response. I'm pretty sure that if this switch has the capability to enable IGMP Querier functionality, then it will begin to operate as expected. Another option is to connect a nearby router to the switch and turn it on there or enable PIM multicast routing. This isn't a Cisco or HP specific thing, it's how the protocol operates and just needs to be enabled.
Take a look at this:
"IGMP snooping querier should be used to support IGMP snooping in a VLAN where PIM and IGMP are not configured because the multicast traffic does not need to be routed.
In a network with IP multicast routing, the IP multicast router acts as the IGMP querier. If the IP-multicast traffic in a VLAN needs to be Layer 2 switched only, an IP-multicast router is not required, but without an IP-multicast router on a VLAN, you must configure another switch as the IGMP querier so that it can send queries.
When IGMP snooping querier is enabled, the IGMP snooping querier sends out periodic IGMP queries that trigger IGMP report messages from the switch that wants to receive IP multicast traffic. IGMP snooping listens to these IGMP reports to establish appropriate forwarding."
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" (18.104.22.168) 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 22.214.171.124. 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, "email@example.com"
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.