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.
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.
Sx550X, Sx350X, Sx250: PSE will Supply Power to Catalyst PSE Ports
May 31, 2016
June 5, 2017
Configure Remote Network Monitoring (RMON) Events Control Settings on a Switch through the Command Line Interface (CLI)
Remote Network Monitoring (RMON) was developed by the Internet Engineering Task Force (IETF) to support...