Re: IGMP Snooping problem on SLM2024 - Page 2

jhenriette · ‎12-05-2009

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

MikeLight · ‎03-11-2010

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 · ‎03-11-2010

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 · ‎03-11-2010

"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

jhenriette · ‎03-16-2010

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 · ‎03-16-2010

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

jhenriette · ‎03-16-2010

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

response3 · ‎03-16-2010

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, "jhenriette@gdrs.com"

jhenriette · ‎03-16-2010

yep, but that still doesn't solve the unregistered multicast problem.

~JM

alissitz · ‎03-17-2010

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