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."