SPS208G SPS224G SPS2024 IGMP Snooping problem

Unanswered Question
Aug 4th, 2009
User Badges:

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

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
David Hornstein Sun, 09/06/2009 - 14:22
User Badges:
  • Gold, 750 points or more

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 Thu, 09/10/2009 - 05:41
User Badges:
  • Gold, 750 points or more

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

Actions

This Discussion

Related Content