IGMP Snooping problem on SLM2024

Unanswered Question

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.

Network.jpg

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
I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
alissitz Mon, 12/07/2009 - 07:27

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

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:
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 Sat, 11/05/2011 - 16:02

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 Mon, 11/07/2011 - 19:48

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 Mon, 12/07/2009 - 08:40

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

alissitz Wed, 12/09/2009 - 06:51

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

     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 Mon, 01/25/2010 - 08:16

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

     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 Tue, 02/23/2010 - 06:21

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

     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 Wed, 02/24/2010 - 15:14

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 Thu, 03/11/2010 - 12:13

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

MikeLight Thu, 03/11/2010 - 12:40

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" (224.0.0.1) 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.

Disclaimer:

While I am very familiar with these switches, I do not work for Cisco, and do not represent them (or anyone else, really ...)

Mike

response3 Thu, 03/11/2010 - 13:41

Mike -

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.

All-

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

MikeLight Thu, 03/11/2010 - 16:45

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

Mike

     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.

~JM

alissitz Tue, 03/16/2010 - 07:21

Hey team,

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.

Kindest regards,

Andrew

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?

~JM

alissitz Wed, 03/17/2010 - 08:26

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.

Andrew