How to Troubleshoot IPTV Blank Display or Erratic Display (Wired Environment)?

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.