Key Words IPTV blank display, IPTV erratic display, IPTV frame freezing Issue Description Symptom: In a wired network environment, IPTV experiences blank display, erratic display, or frame freezing. Network description: Hotel customers usually deploy private IPTV environments, which commonly employ a network setup as shown below. Specifically, the IPTV server and IPTV client are on the Layer 2 network. The IPTV server is connected to a core switch, which is typically a Ruijie campus aggregation switch (the S5700 or S6120 series). The IPTV client is located in guest rooms and connected to an access switch, which is typically an NBS3200/NBS3100 series switch. ![]() 1. Cause Analysis 1.1 Cable/Port failure or insufficient interface bandwidth 1.2 IPTV client abnormalities 1.3 Excessive multicast traffic overwhelming the device capacity 1.4 Access/Core switch configuration issues 1.5 Access/Core switch software or hardware issues 1.6 IPTV server abnormalities 2. Troubleshooting Steps 2.1 Cable/Port failure or insufficient interface bandwidth If the issue is frame freezing or erratic display on individual IPTVs, the cause may be packet loss due to cable or port failures. Follow the troubleshooting steps below: 1. Check the interface information of the NBS switch. ![]() If a cable failure is suspected, replace the cable and test it or perform a cross-test between a working IPTV and the problematic IPTV to confirm the cable failure. A cable failure can be determined based on the following conditions: 1)The negotiated rate (indicated in the Rate column) is lower than the maximum rate supported by the client network interface card (for example, the IPTV network interface card is 1000M, but the negotiated rate is only 100M or 10M). 2) The CRC/FCS error packet count is not zero and keeps increasing (as checked every 5 minutes). If the Rx speed reaches 80% or higher of the negotiated rate, it may indicate insufficient interface bandwidth. In this case, confirm with the customer the normal service flow size and IPTV bit rate. If the flow size is normal, contact Ruijie Intelligent Technical Assistant to check whether the device capacity is sufficient. 2. Check the interface information of Ruijie campus switch. You can view the port information of Ruijie campus switch using the following commands. Show int g0/x //View port information, where g0/x is the port number. Oper speed indicates the negotiated rate. ![]() show int g0/x counter //View detailed packet statistics, where g0/x is the port number. For example, show int g0/1 co Interface : GigabitEthernet 0/1 10 seconds input rate :49470 bits/sec, 55 packets/sec //Average input rate in 10 seconds 10 seconds output rate :3299 bits/sec, 2 packets/sec //Average output rate in 10 seconds Rxload : 0% InOctets : 54323451718 InPkts : 72255431 (Unicast: 2%, Multicast: 88%, Broadcast: 10%) //Proportions of unicast, multicast, and broadcast data InUcastPkts : 1197201 InMulticastPkts : 63442644 InBroadcastPkts : 7615586 Txload : 0% OutOctets : 71646459 OutPkts : 368206 (Unicast: 91%, Multicast: 9%, Broadcast: 0%) OutUcastPkts : 335682 OutMulticastPkts : 32223 OutBroadcastPkts : 301 Undersize packets : 0 Oversize packets : 0 collisions : 0 Fragments : 0 Jabbers : 0 CRC alignment errors : 0 //CRC error count AlignmentErrors : 0 FCSErrors : 0 //FCS error count dropped packet events (due to lack of resources): 0 //Dropped packet count packets received of length (in octets): 64 : 3222496 65-127 : 28561931 128-255 : 1850876 256-511 : 1221474 512-1023 : 253572 1024-1518 : 37145082 Interface : GigabitEthernet 0/1 Packet increment in last sampling interval (5 seconds): InOctets : 37012 InPkts : 325 (Unicast: 5%, Multicast: 75%, Broadcast: 20%) InUcastPkts : 15 InMulticastPkts : 244 InBroadcastPkts : 66 OutOctets : 3076 OutPkts : 20 (Unicast: 100%, Multicast: 0%, Broadcast: 0%) OutUcastPkts : 20 OutMulticastPkts : 0 OutBroadcastPkts : 0 You can use the above-mentioned commands to view the average rates, error counts, and dropped packet count of the port. If there is an increase in the error count or dropped packet count, troubleshoot the cable and port. If the average rate exceeds 80%, contact Ruijie Intelligent Technical Assistant to check if the device capacity is sufficient. 2.2 IPTV client abnormalities If the display issue occurs only on some IPTV terminals and still persists after the interface/link troubleshooting according to Section 2.1, consider abnormalities on the IPTV client. In this case, it is recommended to replace the IPTV client to observe whether the issue disappears. 2.3 Excessive multicast traffic overwhelming the device capacity Follow the procedure in Section 2.1 to check if there is excessive multicast traffic on the IPTV access port and switch interconnection port. Excessive multicast traffic can cause the following issues: 1) Erratic display or frame freezing on IPTV If the bandwidth utilization of the IPTV access interface/switch interconnection interface exceeds 80% or is obviously abnormal (judged by the actual service flow), or the traffic exceeds the multicast forwarding capacity of the switch port or the device, packets may get lost. 2) Blank display on IPTV When there is excessive traffic on the access port of the IPTV client (commonly when IGMP Snooping is not enabled), the IPTV may be incapable of processing all the traffic, resulting in blank display. Solutions: 1) Enable IGMP Snooping. See Section 2.4 for the configuration method. 2) Avoid using static multicast entries for the IPTV access port on the access switch. 2.4 Access/Core switch configuration issues 1) IGMP Snooping is not configured. As mentioned in Section 2.3, if IGMP Snooping is not configured, multicast will be flooded and forwarded throughout the Layer 2 domain. If the multicast traffic is not significant, such as having only one IPTV channel, multicast forwarding may not be a problem. However, when there are too many multicast groups and a large amount of data, flooding can cause excessive traffic on the interface and packet loss. Therefore, it is recommended to enable IGMP Snooping in real-world service environments. For the network setup in this case, the following IGMP Snooping configuration is recommended. (1) Core switch: ip igmp snooping ivgl ip igmp snooping querier ip igmp snooping querier address 1.1.1.1 //Configure a querier on the switch to which the IPTV server is connected, to query addresses. ip igmp snooping vlan 1 querier (2) Access switch Configure the IGMP protocol. The default version is IGMPv2. ![]() Enable IGMP Snooping. ![]() Enable multicast for the IPTV service VLAN. ![]() ![]() 2) No multicast querier is configured, resulting in the IGMP Snooping-enabled device not learning multicast entries. In a typical Layer 3 multicast environment, the gateway has the IGMP or PIM protocol enabled and acts as the querier, while Layer 2 devices (with IGMP Snooping enabled) listen to IGMP messages to maintain multicast entries. However, a Layer 2 environment does not have a querier by default because there is no gateway. Therefore, a querier needs to be configured separately. Only one querier can exist in a network, and if multiple queriers are configured, the one with the smaller IP address takes precedence. Devices in a network need to listen to multicast query messages to learn multicast routing ports. Therefore, it is recommended to set the querier on the switch closest to the multicast source. 3) The multicast querier is configured incorrectly, resulting in incorrect learning of multicast routing ports. As shown in the following figure, the multicast upstream port should be 16, but due to the configuration of a querier on the access switch, the routing port learned is incorrect. You are advised to configure only one querier on a network (and set the querier on the switch closest to the multicast source). ![]() 4) The IGMP protocol version is configured incorrectly. If the IGMP version running on the router interface is lower than that of the host, the router will be unable to recognize IGMP report messages sent by the host. If the access switch has IGMP Snooping enabled but cannot learn any multicast member ports, check the IGMP version used on the IPTV. 5) Static multicast is configured on the access switch, causing the IPTV to receive a large amount of multicast data. As shown in the following figure, the customer has enabled IGMP Snooping, but due to the static configuration of all multicast groups on the access switch, data from all channels are forwarded to the IPTV, overwhelming the capacity of IPTV and making video playback unavailable. ![]() 6) The multicast querier is not configured on the switch closest to the source, while IGMP Snooping is configured on the upstream switch. In this architecture, the downstream switch does not send report messages to the upstream switch, causing the upstream switch to fail in establishing multicast member entries. As shown in the following figure, all the switches have IGMP Snooping configured and the querier is set on the core switch. The core switch SW3 and the access switch SW1 can learn multicast member port entries normally. However, SW2 is unable to establish multicast entries because SW3 cannot learn routing ports (due to not receiving query messages from the upstream) and therefore does not send report messages to SW2. ![]() For this scenario, there are two solutions: 1) Move the multicast querier to SW2. When a downstream device receives a query message, it dynamically learns multicast routing ports along the path. When the access switch receives a report message from a member, it forwards the message to the routing port, dynamically learning multicast member ports along the path. This can establish end-to-end connectivity for multicast entries. 2) Keep the querier on SW3, but configure a static routing port on SW3. For example, if port 17 of SW3 is connected to SW2, configure port 17 as a static routing port using this command: ip igmp snooping vlan 30 mrouter interface TenGigabitEthernet 1/0/17 [strong]2.5 Access/Core switch software or hardware issues[/strong] If the issue still persists after the above-mentioned troubleshooting is completed, it is recommended to troubleshoot the issue by bypassing the switches one by one. For example, bypass the access switch and observe if there is any problem between the core switch and the multicast source. Then, Bypass the intermediate switch to directly connect the multicast source to the IPTV server, and observe if there is any problem between the multicast source and the IPTV server. When a switch is identified as problematic through the bypass method, collect the following information and contact Ruijie Intelligent Technical Assistant. 1) Description of the issue, preferably with a video record of the IPTV playback issue 2) Network topology, clearly describing the position of the IPTV/server, the quantity of IPTV devices, bit rate information, and the quantity of channels. 3) For Ruijie switches, collect the following information: terminal length 0 show version show version slots show run show log show ip interface brief show interface status show interface counter sum show interface counter sum show interface counter sum show interface counter rate show interface counter rate show interface counter rate show interfaces counters errors show interfaces counters errors show interfaces counters errors show interfaces counters show interfaces counters show interfaces counters show arp counter show arp show cpu show cpu-protect mb show cpu-protect mb show cpu-protect mb show cpu-protect show cpu-protect slot X //X indicates the slot. For example, to view slot 4 of the standalone switch 8610, run the show cpu-pro slot 4 command; to view slot 4 of chassis 2 in a VSU, run the show cpu-pro slot 2/4 command. show cpu-protect slot X //X indicates the slot. For example, to view slot 4 of the standalone switch 8610, run the show cpu-pro slot 4 command; to view slot 4 of chassis 2 in a VSU, run the show cpu-pro slot 2/4 command. show spanning-tree show spanning-tree summary show ip igmp snooping show ip igmp snooping gda-table show ip igmp snooping interfaces show ip igmp snooping mrouter show ip igmp snooping querier show ip igmp snooping statistics show ip igmp profile show msf nsf show msf msc 2.6 IPTV server abnormalities If the issue still persists when all the switches between the multicast source and the IPTV are bypassed, contact the IPTV vendor for further troubleshooting. |
This site contains user submitted content, comments and opinions and is for informational purposes only. Ruijie may provide or recommend responses as a possible solution based on the information provided; every potential issue may involve several factors not detailed in the conversations captured in an electronic forum and Ruijie can therefore provide no guarantee as to the efficacy of any proposed solutions on the community forums. Ruijie disclaims any and all liability for the acts, omissions and conduct of any third parties in connection with or related to your use of the site. All postings and use of the content on this site are subject to the Ruijie Community Terms of Use.
More ways to get help: Visit Support Videos, call us via Service Hotline, Facebook or Live Chat.
©2000-2023 Ruijie Networks Co,Ltd