IPTV problem - image blocks

[lmferreira]

We have a IPTV system with two channels: one for inside workers and another to visitors. The IPTV system in on a VLAN, and the television boxes are in the same VLAN. Each box connects to the streaming server by a multicast address.

We have a 8212zl core switch which makes the routing, where is implemented the "ip multicast-routing" command. In every point that we have the TV boxes, we have HP 5412zl or HP 5406zl and the VLAN is configured with "ip igmp high-priority-forward" command.

However we have a lot of drops and collisions in every port that we have the boxes installed:

Totals (Since boot or last clear) :
Bytes Rx : 554,639,083
Bytes Tx : 311,286,753
Unicast Rx : 2,696,723
Unicast Tx : 2,488,234
Bcast/Mcast Rx : 273,704 Bcast/Mcast Tx : 3,854,301,027
Errors (Since boot or last clear) :
FCS Rx : 358
Drops Tx : 50,903,859
Alignment Rx : 0 Collisions Tx : 2,900,274
Runts Rx : 0
Late Colln Tx : 0
Giants Rx : 0
Excessive Colln : 0
Total Rx Errors : 358
Deferred Tx : 0

We already test the connect box interfaces forced to 10 full duplex, 100 full duplex, and auto, but we have problems in any way.

All the switches are connected with 10 Gbps Fiber Optic.

The problem is sometimes we see the image perfectly and many others we see the image blocking, with pixel and later the image gets completely pixelized and stuck on this.

Some boxes work well for about two weeks and then get mad. The behaviour in very inconsistent and fuzzy.

We have dhcp-snooping implemented.

I really need a hint. Thanks for any help you may provide

[cenk sasmaztin]

please send me sh tech print your 8212 core swich and one 5400 switch

[cenk sasmaztin]

and send me ip tv producer and model number information

[rick jones]

Collisions - that implies half-duplex, and that implies 100BT. I'm attaching some old boilerplate about autonegotiation which may be of some help here, particularly if the forcing of duplex isn't perfectly symmetric on either end of the cables.

Can't say if that will address the seemingly high numbers for Drops Tx, but I will ask - while the switches are all connected via 10G, none of the streams (or sets of streams) being sent out to the boxes ever gets close to 100 Mbit/s right? (or 10 Mbit/s in the case of forcing speed to 10 Mbit/s)

[abdullah shboull]

I advised that:
- Ports connecting to normal IPTV STB #spanning-tree admin-edge-port
- Ports connecting to other switches (uplinks) #no spanning-tree auto-edge-port

tell me what happen after this

[Mohammed Faiz]

You'll also have trouble with multicast if you are running K14.41 code.

[abdullah shboull]

I have the same type of the switch with the same running firmware, and without any problem, but I faced the same problem before.
I recommend if you send me the core switch â show tech allâ output, but are sure from bellow
You have to check the following:
1. check the igmp querier is the core switch
2. check the cpu utilization on the core switch and it should less than 20%
3. Ports connecting to normal IPTV STB #spanning-tree admin-edge-port
4. Ports connecting to other switches (uplinks) #no spanning-tree auto-edge-port
5. Put on the IPTV VLAN the command â qos priority 7â
6. Use the MSTP on all your network implement the same command at all switches:
a. spanning-tree config-name test
b. spanning-tree config-revision 1
7. be sure the querier is the root bridge

let me know if this help you?

[lmferreira]

Hi!

Thank you for your reply. Sorry for say nothing till now but i'm so busy that i have no time to reply.

My core switch software version is K.14.41

I never configured MSTP and i have a little bit affraid of. Is really necessary?

Here is some data. Monday i send the sh tech all from the core and the 5400

-----------------

VLAN ID : 200
VLAN Name : TVCorp
Querier Address : This switch is Querier

Active Group Addresses Reports Queries Querier Access Port
---------------------- ------- ------- -------------------
224.6.6.70 12129 0
224.6.6.71 6621 0
224.7.11.215 37204 0
234.5.6.0 36590 0
235.6.7.2 2918 0
235.6.7.10 8 0
235.6.7.11 37391 0
239.255.255.250 2033 0


SW8200MIGOF10A# sh cpu

2 percent busy, from 300 sec ago
1 sec ave: 2 percent busy
5 sec ave: 2 percent busy
1 min ave: 2 percent busy

[abdullah shboull]

send the show tech all file plz

[Mohammed Faiz]

I'd advise upgrading to K14.47 (http://www.procurve.com/customercare/support/software/summarypages/k-j8692-c.htm) before trying anything else.

Here's just a sample of the multicast fixes (there are a lot more!)

PIM (PR_0000040412) â When software is routing multicast packets, the packets are sent
as CPU originated packets. As a result, features that rely on knowing the inbound source
port (e.g. source port filtering) do not get applied.

PIM-SM (PR_0000042163) â Multicast traffic is lost for 20-30 seconds, approximately 5
minutes after a failed-over topology has recovered.

PIM (PR_0000043798) â PIM debug output has the wrong bits set for (*,G) join-prune
packets.

PIM-SM (PR_0000045837) â Following link failover and failback along the active data
path, PIM-SM floods the UDP stream from the source to multiple RP's.

PIM-SM (PR_0000041446) â When a Bootstrap Router (BSR) receives a Candidate-RP
Advertisement (C-RP-Adv) with a zero holdtime, it does not send a Bootstrap Message (BSM)
with a zero holdtime; instead, it stops including the C-RP in subsequent bootstrap messages.