IGMP Snooping problem on SLM2024

[jhenriette]

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

https://www.myciscocommunity.com/thread/4528

https://www.myciscocommunity.com/message/14577

http://tools.ietf.org/html/rfc4541

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.

Questions:

     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??

a snooping switch should not forward IGMP Membership Reports to ports on which only hosts are attached.   An administrative control may be provided to override this restriction, allowing the report messages to be  flooded to other ports......... Sending membership reports to other hosts can result, for IGMPv1 and IGMPv2,  in unintentionally preventing a host from joining a specific multicast group.

     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 224.0.0.1 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 2.0.0.8 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.

4. If I only use SLM2008 in my network with snooping on and unregistered multicast flooding disabled. things seem to work as expected.  This is

obviously a huge limitation and shouldn't be the case, but that seems to be the only way to make it work at the moment.

5.  each camera has it's own multicast address located in the 136s.

6. all multicast address in our applications are being joined by at least one host, so the address really shouldn't be classified as unregistered..?

Please help!!

I have a customer demo this week and would rather not have to kludge things together with a bunch of 8 port switches. :( :(

~JM

[alissitz]

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:

http://www.cisco.com/en/US/support/tsd_cisco_small_business_support_center_contacts.html

This might be a good idea since the support teams might have access to current or suspected bug info.

Here is the admin guide:

https://www.cisco.com/en/US/docs/switches/lan/csbss/slm2024/administration/guide/SLM2024_V10_UG_B-Web.pdf

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

Additional comments.

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.

http://www.cisco.com/en/US/partner/docs/switches/lan/catalyst2960/software/release/12.2_52_se/configuration/guide/swigmp.html#wp1020177

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

[jhenriette]

thank you for the quick reply.

I've poured over users guide several times, sadly it doesn't cover my case, and is outdated for the 2.0.0.8 version of the software I am using.

1. RFC 4541 is the rfc that guides multicast behavior for IGMP snooping switches. I found out about it through one of the other forum links I listed

2-3 In the case of video.. it is quite possible and likely that you may have multicast flying around without listeners such is the case for IPTV.  See these previous posts:

https://www.myciscocommunity.com/message/13351

https://www.myciscocommunity.com/message/14577

None of my multicast video streams are unregistered however (this is different from IPTV) I happen to always be listening somewhere to all the video, so it shouldn't ever be listed as unregistered.

I'm not sure what you mean by dense vs sparse mode... We are running stand alone and without a multicast router. all multicast TTLs are set to 1.

6.  I believe that I have configured the trunk lines properly... I've tried it with only one connection made and it does the same thing, so the LAG doesn't appear to be affecting things negatively.

7. I understand that pinging 224.0.0.1 isn't a particularly reliable way to check for possible multicast host (similarly to pinging the local broadcast)  it is still strange however that of the host that reply, I get multiple returns if a 2024 is plugged into the network.

8. I did read the admin guide.  No answers there. The SLM2008 allows me to port mirror a port in a LAG while the 2024 doesn't.

I did try hard-coding some of the multicast to see if that did anything... I didn't work, or I didn't configure it properly.

I don't need the majority of the features of the Cat 2960 and then there is the price:

Cat 2960=$2300

SLM2024=$400

I had tried some tests on the SLM2008 and figured the 2024 was just a bigger brother with similar features, but the two are vastly different which is really too bad.  the SLM2008 is such a cinch to set up!

I have a case open and will report back what I find.

~JM

[rrobinet1949]

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.

Rob

[rrobinet1949]

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.

[alissitz]

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:

https://www.myciscocommunity.com/docs/DOC-7526

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,

Andrew

[jhenriette]

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.

~JM

[alissitz]

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. 

Kindest regards,

Andrew Lee Lissitz

[jhenriette]

     For everyones benefit, sadly, this is where this issue currently lies.

Support:

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.

Me:

    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.

Support:

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.

~JM

[alissitz]

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,

Andrew

[jhenriette]

     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.

~JM

[alissitz]

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.

Andrew

[jhenriette]

     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.

https://www.myciscocommunity.com/message/15988

Re: SPS208G SPS224G SPS2024 IGMP Snooping problemhttps://www.myciscocommunity.com/thread/4528

     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.

:(

~JM

ps:  I  have no idea why "P_I_L_L" is considered a taboo word.

[alissitz]

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,

Andrew Lissitz

[response3]

Hi all,

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

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.1E/native/configuration/guide/multi.html#wp1061511