Re: SPS208G SPS224G SPS2024 IGMP Snooping problem

lukasz_naumowicz · ‎08-04-2009

Dear Support Team,

One of our partners encountered problems with multicasts running on SPS series switches(they’ve checked it on 3 different models, mentioned in subject). Partner wants to use SPS series switches with IPTV, unfortunately they observe problems with IGMP Snooping, I’ve attached brief description of observed problems below:

- Switch is configured to IGMP Snooping, at the beginning everything seems to be fine, multicast packets are send only to the eth ports that require this traffic. Other eth ports in this vlan doesn’t receive multicast packets.

- Problem arises during fast channel changing, after changing few channels on a set top box, IGMP Snooping stops to work on whole switch – multicast packets are send to all eth ports on the switch(even if those ports doesn’t require that traffic). Problem arises even with one Set Top Box connected, when we connect more devices, due to congestion TV will stop working everywhere.

- Such problem wasn’t observed with switches of another vendors.

Please find also detailed description of one test below:

Computer with Wireshark(log attached) connected to TV VLAN with IGMP Snooping enabled.

Set Top Box connected to another port of the TV VLAN.

1. After start of Set Top box we start to change channels(one channel changed every 5 seconds after last channel was observed on TV)

2.About packet no. 170 we start to change channels faster(one channel changed every 2 seconds after last channel was observed on TV). As you can see in the log starting from packet 362, UDP traffic on the computer increases significantly, and stays on that level until no. 484659.

3.We are starting to change channels faster again about packet no. 484975, again we can observe increased UDP traffic on the port the computer is connected and that doesn’t require it. Increased UDP traffic persists until packet

In both mentioned points 2, 3 IGMP Snooping stopped to work after longer period of time, during other tests it happened that it stopped working instantly after starting to change channels. In the attached logs we’ve cut out some of the multicast traffic so there is no continuous numbering(the original log is about 1 GB, but it’s also available if it’s required). I’ve attached also output from the configuration file of SPS208G.

Tested versions(also SPS208G):

SPS2024:SW version    1.0.1 ( date 22-May-2008 time 15:01:47 )
Boot version    1.0.0.01 ( date 01-Nov-2007 time 13:19:38 )
HW version    00.03.00

SPS224G4:SW version    1.0.2 ( date 18-Nov-2008 time 12:38:16 )
Boot version    1.0.2 ( date 13-Nov-2007 time 14:11:51 )
HW version    00.03

I’m not sure if it’s something wrong with the configuration or with the switches, we didn’t find any mistakes by ourselves.

Thank you,

Lukasz

David Hornstein · ‎09-06-2009

Hi Lukasz,

Have a look at the following RFC; http://tools.ietf.org/html/rfc4541 It's not too boring and it's brief, it should not put you to sleep.

It suggests under section 2.1.2 sub-section 3.

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.

If a switch receives an unregistered packet, it must forward that packet on all ports to which an IGMP router is attached. A switch may default to forwarding unregistered packets on all ports.

But what happens in a snooping switch when it receives a membership report for that unregistered group is another story.

It sure would be interesting to dig deeper into your story, it would be good to see a simple topology diagram, I'm guessing that;.

1. Layer 3 Querier ip= 10.200.224.193 maybe Huawei router

2. Video source=10.200.200.203 I would have to assume coming from behind the huawei box

3. Kreatel top Box= 10.200.224.198 maybe

regards Dave

David Hornstein · ‎09-10-2009

hi Lukasz

Check my last response at the bottom of the thread in the following link to wonderful folks from Savant;

https://www.myciscocommunity.com/thread/4528?tstart=0

Might i suggest you place a call with the SBSC , i have included contacts link below;

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

Please open a case regarding your issue, and refer the folks to my answer given to Savant, I want to be sure that a behaviour change to the way IGMP works is added to your switch series.

Even though the behaviour conforms to the RFC mentioned previously, the flooding of multicast IPTV UDP packets would just over subscribe those fastEthernet ports. It makes sense, if a L3 mrouter is in place , not to flood those IPTV channels except to the Mrouter ports.

Unicast me via the community email function if you have any questions and we can get in contact.

regards Dave