preface - ztezte.by/magazine/maintenance experience, issue147(data products).pdf · preface...

Preface

Maintenance ExperienceEditorial Committee

Director: Qiu Weizhao

Deputy Director: Chen Jianzhou

Editors:Jiang Guobing, Zhang Shoukui, Wu Feng, Yuan Yufeng, Tang Hongxuan, Chen Huachun, Li Gangyi, Gu Yu, Song Jianbo, Tian Jinhua, D u J i a n l i , Q u R u i z h e n g , L i u X i a n m i n , Wang Zhaozheng, Liu Wenjun, Wang Yapping, Lei Kun, Wang Tiancheng, Cai Hongming Technical Senior Editors:Hu Jia, Zhang Jianping

Executive Editor:Zhang Fan

Maintenance ExperienceNewsroom

Maintenance Experience Editorial CommitteeZTE CorporationDecember, 2008

Maintenance ExperienceBimonthly for Data ProductsNo.68 Issue 147, December / 2008

Address: ZTE Plaza, Keji Road South, Hi-Tech

Industrial Park, Nanshan District,

Shenzhen, P.R.China

Postal code: 518057

Contact: Song Chunping

Tel: +86-755-26770600, 26771195

Fax: +86-755-26772236

Document Support Email: [email protected]

Technical Support Website: http://ensupport.zte.

com.cn

In this issue of ZTE's "Maintenance Experience", we continue to pass on various field reports and resolutions that are gathered by ZTE engineers and technicians around the world.

The content presented in this issue is as below:● Three Special Document● Six Maintenance Cases of ZTE's Data ProductsHave you examined your service polices and procedures

lately? Are you confident that your people are using all the tools at their disposal? Are they trained to analyze each issue in a logical manner that provides for less downtime and maximum customer service? A close look at the cases reveals how to isolate suspected faulty or mis-configured equipment, and how to solve a problem step by step, etc. As success in commissioning and service is usually a mix of both discovery and analysis, we consider using this type of approach as an example of successful troubleshooting investigations.

While corporate leaders maintain and grow plans for expansion, ZTE employees in all regions carry out with individual efforts towards internationalization of the company. Momentum continues to be built, in all levels, from office interns to veteran engineers, who work together to bring global focus into their daily work.

If you would like to subscribe to this magazine (electronic version) or review additional articles and relevant technical materials concerning ZTE products, please visit the technical support website of ZTE Corporation (http://ensupport.zte.com.cn).

If you have any ideas and suggestions or want to offer your contributions, you can contact us at any time via the following email: [email protected].

Thank you for making ZTE a part of your telecom experience!

Contents

IGMP Mechanism ...................................................................................................................................... 2

PIM-SM Configuration ............................................................................................................................... 5

Cross-VLAN Multicast on ZXR10 Switches ............................................................................................. 17

Butt Joint Malfunction of ZXR10 T64G and HW NE80 ............................................................................ 24

High CPU Utilization Ratio Caused by Multicast ..................................................................................... 26

Multicast Malfunction on T64G ................................................................................................................ 29

DR Handover on VRRP Interface ............................................................................................................ 31

IPTV Service Interruption Caused by DR Priority .................................................................................... 33

IPTV Service Malfunction Processing ..................................................................................................... 35

Maintenance Experience2

December 2008 Issue 147

⊙ Zhang Jintao / ZTE Corporation

IGMP Mechanism

IGMP OverviewIn multicast network, Internet Group

Management Protocol (IGMP) is used

between the host and switch to manage

member actions, such as member joining,

leaving and forwarding packets.

There are two versions of IGMP:

IGMPv1 and IGMPv2. IGMPv2 is usually

used. The differences between IGMPv1

and IGMPv2 are described below.

● IGMPv1 and IGMPv2 have different

message formats.

Message format of IGMPv1 is shown

in Figure 1.

Key words: IGMP, IGMPv2, IGMP Snooping, IGMP Proxy

Figure 1. Message Format of IGMPv1

Message format of IGMPv2 is shown

in Figure 2.

Figure 2. Message Format of IGMPv2

● IGMPv1 and IGMPv2 have different working

modes.

IGMPv1 uses “query-report” mode. When a

member wants to leave the multicast group, it

does not respond to the Query message sent by

multicast router. If the multicast router does not

receive Report message from the member within a

time period, the Query message will time out and

the member leaves multicast group quietly.

IGMPv2 also uses “query-report” mode. When

a member wants to leave the multicast group, it can

leave quietly. It can also send a Leave message to

the multicast router and leave the group on its own.

IGMP Working ProcedureIGMPv2 is used more frequently than IGMPv1.

Data Products

www.zte.com.cn

3

Therefore only IGMPv2 working procedure is

described here. A network topology is shown in

Figure 3.

IGMPv2 working procedure is described as

follows.

1. PC1 sends a Report message, indicating

that it wants to join the multicast group 239.1.1.1.

2. The Report message goes through

SW and is forwarded to the multicast routers

transparently.

3. There are two multicast routers, RT1 and

RT2. Both routers receive the Report message

sent by PC1.

4. Before the two routes process the Report

message from PC1, an election is implemented.

One of the routers is elected as the querier.

According to the election rule that the router with

the smallest IP address on the network segment

becomes the querier, RT1 is elected as the querier.

5. When RT1 receives Report message

from PC1 for joining multicast group, it forwards

multicast group packets 239.1.1.1 and sets the last

reporter as PC1.

6. The quer ie r sends Genera l Query

messages to all hosts periodically to maintain

member relationship. The destination address of

the messages is 224.0.0.1.

7. When the hosts receive General Query

messages, only one host in each group sends

Report message. Other hosts in each group are

suppressed.

8. When the quer ie r rece ives Repor t

messages, it goes on to maintain the multicast

group 239.1.1.1 and refreshes the last reporter. For

example, PC2 sends Report message this time,

the last reporter becomes PC2 (1.1.1.2).

9. When a member in a group wants to

leave, it will send Leave message to both multicast

routers. The destination address of the message is

224.0.0.2.

10. When the querier receives the Leave

message, it judges whether the message is sent

Figure 3. IGMP Working Procedure

by the last reporter. If it is not sent by the

last reporter, the querier will still send

General Query messages periodically. If

the message is sent by the last reporter,

it will send Specific Query message to

check whether there are other members in

the group. In this example, the destination

address of the Specific Query message

is 239.1.1.1. If there are other members,

the querier refreshes the last reporter and

maintains the group. Otherwise, the group

is deleted.

IGMP Snooping and IGMP Proxy Overview

Seen from the working procedure

of IGMPv2, there is a disadvantage. As

shown in Figure 3, Layer 2 switch SW

is responsible for transmitting the IGMP

messages (Query, Report and Leave)

between multicast router and the members

transparently. Therefore, the ports on SW

connecting to PC1, PC2, PC3, RT1 and



RT2 should be in the same VLAN, for

example, VLAN10.

Multicast MAC address is converted by

multicast IP address. That is, the multicast

MAC address is not an actual physical

address of any device in the network.

Therefore, for the multicast messages

from RT1 to SW, when SW searches the

port corresponding to the MAC address,

SW fails to find it out and it floods it as an

unknown unicast message.

Messages f rom mul t icast router

to members are flooded on SW. This

increases the load of the switch and costs

bandwidth, and also increases the CPU

load of PCs that did not send Report

messages.

Therefore, it is necessary to use a

mechanism to make the switch forward

the messages to the port through which

Repor t messages a re sen t . IGMP

Snooping and IGMP Proxy can do it.

IGMP SnoopingAfter IGMP Snooping is configured,

the switch monitors the request multicast

messages sent to multicast router by the

members, and then creates a dynamic

MAC table for each multicast group. The

MAC table includes multicast group MAC

address and corresponding port number.

In Figure 3, suppose PC1 and PC2

send Report messages to join multicast

group 239.1.1.1, and PC3 does not send

the Report message. RT1 is the querier of

the group. After enabling IGMP Snooping

on SW, a MAC table for group 239.1.1.1 is

created, as shown below.

MAC PORT

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

0100.5E01.0101 fei_1/1 fei_1/2

When SW receives messages from group

239.1.1.1, it searches in the MAC table and finds

out that the ports corresponding to the destination

MAC address (0100.5E01.0101) in the message

are fei_1/1 and fei_1/2. Therefore, messages are

forwarded to the two ports and PC3 will not receive

the messages.

IGMP ProxyThe functions of IGMP Proxy and IGMP

Snooping are the same, that is, to avoid flooding.

But they are implemented in different ways. The

differences are described as follows.

1. IGMP Snooping creates the relationships

between multicast MAC addresses and member

ports by monitoring the IGMP messages from hosts

to multicast router.

2. IGMP Proxy intercepts and processes the

IGMP messages from hosts to multicast router and

then forwards to the router.

Working procedure of IGMP Proxy is described

below.

1. The downlink port on the switch works as

the multicast router and acts according to IGMPv2

mechanism, such as querier election, sending

General Query messages periodically and sending

Specific Query messages when it is receiving

Leave message.

2. The uplink port on the switch works as the

multicast members. It can respond to the Query

messages from multicast router. When the last

member leaves the group, it sends Leave message

to the router.

3. Multicast MAC table is created on the

switch, including the corresponding relationship

between multicast group and ports. Messages

from multicast router to members are forwarded

according to the table.

When there is no router in network, Proxy

can acts as querier, which decreases the load of

multicast router. IGMP Proxy has better ability to

support extending multicast routing function than

IGMP Snooping. ■

Data Products

www.zte.com.cn

5

Experience Collections

1 PIM-SM OverviewIP multicast is a point-to-multipoint or multipoint-

to-multipoint communication. That is, multiple

receivers receive the same information from one

source at the same time.

IP multicast protocols include Internet Group

Management Protocol (IGMP) and Multicast Route

Protocols (MRP). IGMP is used to manage joining

and leaving of multicast group members. MRPs

are used to exchange information and establish

multicast tree among routers. MRPs include

Protocol Independent Multicast Sparse Mode (PIM-

SM) and Multicast Source Discovery Protocol

(MSDP). Among MRPs, PIM-SM is used most

widely.

In PIM-SM domain, routers running PIM-SM

send Hello messages periodically to discover

neighbor PIM routers and elect designated router

(DR) in multi-access network. DR is responsive

for sending joining and pruning messages on the

direction of root nodes on multicast distribution

tree for members connecting to DR directly. DR is

also responsive for sending messages from direct-

connected multicast source to multicast distribution

tree.

PIM-SM forwards packets by establishing

multicast distribution tree. There are two types of

multicast distribution trees, shared tree and the

shortest path tree.

PIM-SM establishes and maintains multicast

distribution tree by explicit joining and pruning

mechanism.

As shown in Figure 1, DR receives a Joining

message from a receiver, then it send a (*, G)

⊙ Ke Jinshui / ZTE Corporation

PIM-SM Configuration

Key words: PIM-SM, DR, RP, BSR, RPF

message on the direction of RP to add the

receiver to the shared tree.

When a sender sends multicast data,

the data is encapsulated in registration

message and is unicast to RP by DR. Then

RP decapsulates the message and sends

the data to members along the shared

tree. RP sends (S, G) Joining message

on the direction of sender to add to the

shortest path tree. Therefore, multicast

data is sent to RP along the shortest path

tree without encapsulation. When the

first multicast data reaches RP, RP sends

stooping registration message to source

DR to inform DR of stopping encapsulate

registration message. After that, source

multicast data is not encapsulated in

registration messages, but it is sent to

Figure 1. Explicit Joining Mechanism of PIM-SM



RP along the shortest path tree and then

sends to members by RP along the shared

tree.

When multicast data is not needed

any more, DR of receiver sends pruning

messages to RP hop by hop to cut off the

shared tree.

PIM-SM has a mechanism for RP

election. In PIM-SM domain, one or more

Candidate-BSRs are configured. BSR is

elected among Candidate-BSRs according

to rules. In PIM-SM domain, there are

some Candidate-RPs. These RPs send

unicast messages that contain information

of their addresses and multicast groups

tha t they can se rve to BSR. BSR

generates election messages including

information of RP and corresponding

group address termly. These election

messages are sent hop by hop in the

whole domain. Router receives and saves

these election messages and calculates to

choose the RP of each multicast group.

2 PIM-SMConfigurationProcedurePIM-SM configuration procedure is

described below.

1. Configure interface addresses and

unicast routes on the devices.

2. Enab le IP mul t i cas t rou t ing

function and PIM-SM globally.

3. C o n f i g u r e i p p i m s m o n

corresponding interfaces.

4. Configure RP. There are static

RP and dynamic RP. Usually static RP is

used.

Configuring interface addresses and

unicast routes on devices is the base to

configure PIM-SM. To implement projects,

it is advertised to configure unicast route in

the whole network and ensure that unicast

routes are correct and then configure multicast

function.

For RP configuration, it is suggested to use

static RP. In a multicast domain, usually there is

one core device working as RP. Use the loopback

address of the device as the RP address, and other

devices in the multicast domain will designate this

address as the RP.

3 ConfiguringPIM-SMTo configure PIM-SM, perform the following

steps.

1. To enable IP multicast routing function, use

the following command.

ZXR10(config)#ip multicast-routing2. To enable PIM-SM, use the following

command.

ZXR10(config)#router pimsmIf IP multicast routing function is not enabled,

PIM-SM can not be enabled.

3. To configure PIM-SM on an interface, use

the following command.

ZXR10(config-if)#ip pim smPIM-SM can not be configured on an interface

if IP multicast routing function and global PIM-SM

are not enabled.

4. To configure static RP, use the following

command.

ZXR10(config-router)#static-rp <ip-address>

[group-list <access-l ist-number>] [priority

<priority>]

A static RP can be configured for one or more

specific groups and the same static RP should be

configured for the group on all PIM-SM multicast

routers in the multicast domain. RP addresses

should be reachable from other routers. Use

loopback interface address to reduce the network

oscillations due to physical interface up/down.

When a static RP is configured, the candidate RP

is not needed for the group.

5. To configure candidate BSR, use the

following command.

Data Products

www.zte.com.cn

7

ZXR10 (con f i g - r ou te r ) # bsr -cand ida te

<interface-name> [<hash-mask-length>] [<priority>]

When static RP mechanism is not used,

candidate BSRs should be configured on one or

more than one multicast routers in each multicast

domain. The BSR sends boots t rap (BSR)

messages periodically to advertise RP conditions.

Routers running PIM-SM update the RP states

according to the latest advertisement messages.

The bootstrap messages sent by BSR are also

used to elect formal BSR from the candidate BSRs.

Default priority of a candidate BSR is 0.

Candidate BSR with the highest priority becomes

the formal BSR. If multiple routers have the

same BSR priority, IP addresses are compared.

Candidate BSR with the largest address becomes

the formal BSR.

6. To conf igure candidate RP, use the

following command.

ZXR10(config-router)#rp-candidate <interface-

name> [group-list <access-list-number>] [priority <priority>]

In PIM-SM, RP is the root of a shared multicast

tree. It is responsible for sending multicast packets

to the downstream receiving group members along

the shared tree. A multicast group can only have

one formal RP.

4 PIM-SMConfigurationGuidelinesWhen configuring PIM-SM, pay attention to the

following points.

1. If switch (such as G series, 59 series and

39 series) connects to multicast receivers directly,

IGMP should be enabled on the port that connects

to receivers. Use the following command.

ZXR10(config-if)#protocol-protect mode igmp enable

2. If software version of G series switches is

V2.6, IP multicast message is forwarded in tag

mode by default. To make IP multicast message

forwarded in untag mode, use the following

command.

ZXR10(config-if)#multicast untag-vlan <vlan-id>

3. If software version of G series

switches is V2.8, it is not necessary to

configure the above command.

When implementing projects, if the

following three conditions are met at the

same time, configure the above command

on the port for inter-connection:

1) Multicast data is forwarded to the

peer device from G series switches.

2) The peer device is not a switch of G

series.

3) Connection mode on the peer

device is access.

5 PIM-SMConfigurationExamplesAs shown in Figure 2, Server is a

multicast server and Client is a multicast

receiver. 3906 works as a multicast router

connecting to source directly. T64G works

as the RP in the multicast domain, using

its loopback address as RP address. 3928

works as a multicast router connecting

to receiver. Static RP is configured in the

network. PIM-SM is enabled on 3906,

T64G and 3928. After the configuration,

Client can receive multicast data from

Server.

Figure2.PIM-SMConfigurationExample

Configuration on the switches is given

in the following topics.



5.1Configurationon3906Configuration on 3906 is described below.

1. Configure interface address and unicast route.

3906(config)#interface fei_1/1

3906(config-if)#switchport access vlan 100

3906(config-if)#exit


3906(config-if)#switchport mode trunk

3906(config-if)#switchport trunk vlan 200


3906(config)#interface loopback1

3906(config-if)#ip address 1.1.1.1 255.255.255.255


3906(config)#interface vlan 100






3906(config)#router ospf 2

3906(config-router)#network 1.1.1.1 0.0.0.0 area 0


3906(config-router)#redistribute connected

3906(config-router)#exit

Note: Configure unicast on the three switches first, and then configure IP multicast routing

function.

2. Enable IP multicast routing function and PIM-SM globally.

3906(config)#ip multicast-routing

3906(config)#router pimsm


3. Enable PIM-SM on a Layer 3 interface.


3906(config-if)#ip pim sm



Data Products

www.zte.com.cn

9



Note: The whole configuration should be implemented according to the configuration

procedure strictly. Otherwise, system will prompt error information.

4. Configure static RP.

Suppose the loopback address 2.2.2.2 of T64G is the RP address, designate this address as

the RP on all devices that run PIM-SM.


3906(config-router)#static-rp 2.2.2.2


5.2ConfigurationonT64GAs the RP, configuration points on T64G are the same as that of other switches in the network.

1. Configure interface address and unicast route.

T64G(config)#interface fei_1/1

T64G(config-if)#switchport mode trunk

T64G(config-if)#switchport trunk vlan 200

T64G(config-if)#exit

T64G(config)#interface fei_1/2

T64G(config-if)#switchport mode trunk

T64G(config-if)#switchport trunk vlan 300


T64G(config)#interface loopback1

T64G(config-if)#ip address 2.2.2.2 255.255.255.255

T64G(config-if)#ex

T64G(config)#interface vlan 200






T64G(config)#router ospf 2

T64G(config-router)#network 2.2.2.2 0.0.0.0 area 0



T64G(config-router)#redistribute connected

T64G(config-router)#exit




T64G(config)#ip multicast-routing

T64G(config)#router pimsm




T64G(config-if)#ip pim sm



T64G(config-if)#ip pim sm

T64G(config-vlan)#exit




T64G(config)#router pimsm

T64G(config-router)#static-rp 2.2.2.2


5.3Configurationon39281. Configure interface address and unicast route.


3928(config-if)#switchport mode trunk

3928(config-if)#switchport trunk vlan 300





3928(config)#interface loopback1









Data Products

www.zte.com.cn

11

3928(config)#router ospf 2



3928(config-router)#redistribute connected



3928(config)#ip multicast-routing









3928(config-vlan)#exit





3928(config-router)#static-rp 2.2.2.2


5. By default, physical ports on switch of G series, 39 series and 59 series do not send IGMP

messages from multicast receiver to CPU. Shared tree can not be established if CPU does not

receive these messages. Therefore, when switches of G series, 39 series and 59 series connect

to multicast receiver directly, it is necessary to modify the configuration on corresponding ports.

In this example, 3928 connects to multicast receiver through fei_1/2. Therefore, modify the

configuration on fei_1/2, as shown below.



3928(config-if)#protocol-protect mode igmp enable



6PIM-SMMaintenanceandDiagnosisCommands for PIM-SM maintenance and diagnosis are described below.

6.1showipigmpgroupsThis command is used to view multicast group information on a layer 3 interface. When a

multicast receiver connects to a device that runs PIM-SM, this command can be used to judge

whether the device receives IGMP report message from the receiver. An example is shown below.

ZXR10#show ip igmp groups

IGMP Connected Group Membership

Group addr Interface Present Expire Last Reporter

233.18.1.1 vlan400 00:03:15 00:03:10 192.168.4.2

ZXR10#show ip igmp groups 233.18.1.1

IGMP Connected Group Membership

Group addr Interface Present Expire Last Reporter

233.18.1.1 vlan400 00:04:12 00:02:13 192.168.4.2

The above result shows that a multicast receiver 192.168.4.2 sends IGMP report message to

join multicast group 233.18.1.1. The message is received in VLAN 400.

Displayed information instructions:

Item Description

Group addr Multicast group address

Interface Interface

Present The time when the member appears

Expire The left time of timeout timer. If the value is never, it indicates that there is a static group.

Last Reporter Host address of the last reporter

6.2showipmrouteThis command is used to view multicast routing table. Multicast router forwards multicast

packets when it has the multicast routing table. If a receiver can not receive multicast packets of

the group, check whether there are multicast routes of the group on the multicast router.

An example is shown below.

ZXR10#show ip mroute

IP Multicast Routing Table

Flags: D -Dense, S -Sparse, C -Connected, L -Local, P -Pruned,

R -RP-bit set, F -Register flag, T -SPT-bit set, J -Join SPT,

M -MSDP created entry, N -No Used, U -Up Send,

A -Advertised via MSDP, X -Proxy Join Timer Running,

Data Products

www.zte.com.cn

13

* -Assert flag

Statistic:Receive packet count/Send packet count

Timers:Uptime/Expires

Interface state:Interface,Next-Hop or VCD,State/Mode

(*, 233.18.1.1), 00:05:55/00:03:33, RP 2.2.2.2 , flags: SP

Incoming interface: vlan200, RPF nbr 192.168.2.2

Outgoing interface list: NULL

(192.168.1.2, 233.18.1.1), 00:05:55/00:03:33 , flags: FT


Outgoing interface list:

vlan200, Forward/Sparse, 00:05:42/00:02:36

The above information shows that there are multicast routes of multicast group 233.18.1.1

on the device. The source address of the group is 192.168.1.2. If multicast packets are received

normally, (*, g) and (s, g) exists at the same time. In this example, (*, g) is (*, 233.18.1.1), and (s, g)

is (192.168.1.2, 233.18.1.1).

Incoming interface of (s, g) indicates the interface on which interface multicast packers are

received. It can not be NULL. In this example, it is VLAN 100, indicating that multicast packers are

received in VLAN 100.

Outgoing interface list of (s, g) indicates the interface from which interface multicast packers

are sent. If it is NULL, it indicates that multicast packers are not sent to any interface. In this

example, it is VLAN 200, indicating that multicast packers are sent from VLAN 200.

6.3showipmforwardingThis command is used to view information in single forwarding table.

If multicast routing table on device is normal but the receiver can not receive multicast packets,

except that the receiver did not send IGMP report message and CPU did not send the messages

to CPU, use this command for diagnosis.

Information displayed by this command on switch of G series is different from that on 39 series

and 59 series.


T64G#show ip mforwarding module 2 group 224.1.1.1

IP Forwarding Multicast Routing Table

Flags: N -No Used,U -Up Send,L -Limit upSend,A - Assert send

(10.1.1.2, 224.1.1.1), Flags:A, HitFlag:1, Incoming interface: vlan10 2/1, LastSrcIp: 0.0.0.0

Outgoing vlan interface list: 20

L2bitmap:0x4000000000000000 L3bitmap:0x0000000000000008

Phyport information:



port4

untag vlanlist:20

tag vlanlist:

(*, 224.1.1.1), Flags:A, HitFlag:0, Incoming interface: Null, LastSrcIp: 10.1.1.2

Outgoing vlan interface list: 20

L2bitmap:0x0000000000000000 L3bitmap:0x0000000000000000


1. HitFlag: If multicast packets are forwarded by this forwarding table, it is 1. Otherwise, it is 0.

2. Incoming interface: If incoming interface of (10.1.1.2, 224.1.1.1) is vlan10 2/1, this indicates

that multicast packets forwarded by (10.1.1.2, 224.1.1.1) should come from vlan10 2/1. Otherwise,

the multicast packets are discarded.

3. Outgoing interface: It includes vlan interface and physical port information. It indicates that

multicast packets forwarded by this (S, G) will be sent from the designated VLAN and physical

port.

6.4showippimrpmappingThis command is used to view information of RP and corresponding multicast group.


ZXR10#show ip pim rp mapping

Group(s) 224.0.0.0/4

RP 2.2.2.2, Static, Priority :192

The above information shows that RP 2.2.2.2 is static configuration, and its corresponding

multicast range is 224.0.0.0/4.


Item Description

Group Address and mask of multicast group advertised by BSR

RP RP address advertised by the multicast group

static The RP is statically configured

6.5showippimsmneighborThis command is used to view neighbor information of PIM-SM. When multicast routing table

can not be established, use this command to check when the neighbor enables PIM-SM.


ZXR10#show ip pimsm neighbor

Neighbor Address Interface DR Priority Uptime Expires Ver

192.168.3.1 vlan300 1 01:04:19 00:01:23 V2

Data Products

www.zte.com.cn

15

The above information shows that interface vlan300 on the device has a PIM-SM neighbor.


Item Description

Neighbor Address IP address of neighbor

Interface Interface name

DR Priority DR priority of neighbor

Uptime Living time of neighbor

Expires Expired time of neighbor

6.6showippimsminterfaceThis command is used to view information of interfaces that run PIM-SM on the device.


ZXR10#show ip pimsm interface

Address Interface State Nbr Count Query Intvl DR DR Priority

192.168.3.2 vlan300 Up 1 30 192.168.3.2 1

192.168.4.1 vlan400 Up 0 30 192.168.4.1 1

The above information shows that there are two interfaces enabled PIM-SM on the device.

They are VLAN 300 and VLAN 400.


Item Description

Address Interface address

Interface Neighbor interface

NbrCount Numbers of neighbors

State Interface state

QueryIntvl Interval to send Hello messages

DR DR of the interface

DR Priority DR priority of the interface

6.7showiprpfThis command is used to view reverse path forwarding information of a multicast source. If

reversed path forwarding information or RPF neighbor does not exist, multicast packets can not be

forwarded normally.


ZXR10#show ip rpf 2.2.2.2



RPF information:

RPF interface vlan300 pimsm RPF neighbor 192.168.3.1 (is neighbor) RPF metric preference 110

RPF metric value 2

RPF type : unicast

The above information shows reversed path forwarding information of 2.2.2.2.


Item Description

RPF interface RPF interface to source address

RPF neighbor RPF neighbor to source address

RPF metic preference Priority of route to source address

RPF metric Metric of route to source address


1. RPF interface vlan300 pimsm: This indicates that RPF interface on local device to 2.2.2.2 is

VLAN 300, and it is configured with PIM-SM.

2. RPF neighbor 192.168.3.1 (is neighbor): This indicates that RPF interface neighbor of local

device to 2.2.2.2 is192.168.3.1, and it is configured with PIM-SM.

If VLAN 300 on local device and peer interface are not configured with PIM-SM, reversed path

forwarding information is shown below.

ZXR10#show ip rpf 2.2.2.2

RPF information:

RPF interface vlan300

RPF neighbor 192.168.3.1 (isn’t neighbor)

RPF metric preference 110

RPF metric value 2

RPF type : unicast

Data Products

www.zte.com.cn

17

EMS Cases

1 Network TopologyAs shown in Figure 1, access VLAN 3997-3999

and multicast VLAN 29 are configured on an

aggregation switch connecting to IPTV bearer

network. VLAN 3997 is for unicast service on

switch of 39/32 series. VLAN 3998 is for STB

connecting to switch-1 (short for 2000 series

switch-1) to obtain IP address, and VLAN 3999

is for STB connecting to switch-2 (short for 2000

series switch-2) to obtain IP address. VLAN 29 is

used for multicast.

When a STB is booted, it obtains IP address

from access VLAN. When a user wants to watch

programs of a channel, STB sends IGMP report

messages to apply for program multicast packets.

The multicast VLAN used in the whole network is

VLAN 29.

Now it is required to implement cross-VLAN

⊙ Wang Guozhong / ZTE Corporation

Cross-VLAN Multicast on ZXR10 Switches

Key words: multicast, VLAN, IPTV, Set-Top Box (STB)

Figure 1. Network Topology



multicast in each access VLAN on the switches (including switch of 39/32 series, switch-1 and

switch-2). Report messages received from access VLANs are sent to the multicast VLAN and

then to IPTV bearer network. Multicast packets of IPTV system are sent to users through multicast

VLAN 29.

Multicast packets are forwarded in untag mode from the downlink interfaces on switch-1 and

switch-2. The downlink interfaces should be in VLAN 29. Therefore, services are distinguished by

configuring PVID.

2 ConfigurationsonSwitchesConfigurations on switches are described below.

2.1ConfigurationonSwitchof39/32SeriesConfiguration on switch of 39/32 series is shown below.

1. VLAN configuration:

ZXR10(config)#vlan 29

ZXR10(config-vlan)#vlan 3997



2. Port configuration:

ZXR10(config)#interface fei_1/1 //interface connecting to STB


ZXR10(config-if)#negotiation auto

ZXR10(config-if)#switchport access vlan 3997

ZXR10(config-if)#switchport qinq normal

ZXR10(config)#interface gei_2/1 //uplink interface



ZXR10(config-if)#hybrid-attribute fiber

ZXR10(config-if)#switchport mode trunk

ZXR10(config-if)# switchport trunk native vlan 1

ZXR10(config-if)#switchport trunk vlan 29

ZXR10(config-if)#switchport trunk vlan 3997-3999


ZXR10(config)#interface gei_2/2 //downlink interface



ZXR10(config-if)#hybrid-attribute fiber

ZXR10(config-if)#switchport mode trunk

ZXR10(config-if)#switchport trunk native vlan 1

ZXR10(config-if)#switchport trunk vlan 29

Data Products

www.zte.com.cn

19

ZXR10(config-if)#switchport trunk vlan 3998-3999


ZXR10(config-if)#exit

3. Configuration related to IGMP Snooping:

ZXR10(config)#ip igmp snooping

//it is enabled by default

ZXR10(config)#ip igmp snooping proxy

//it is enabled by default

ZXR10(config)#ip igmp snooping querier

//enable igmp snooping querier globally

ZXR10(config)#igmp snooping querier

//enable querier function on access VLAN for STB. If there are multiple VLANs, enable this

function on each VLAN. It is to make switch of 39/32 series send query messages termly,

ensuring service not interrupted

Note: Do not enable querier function in multicast VLAN.

4. Configuration of IPTV control:

ZXR10(config)#nas

//enter nas configuration mode

ZXR10(config-nas)#iptv control enable

//enable iptv control to implement cross-VLAN multicast

ZXR10(config-nas)#create iptv channel general [256 | 1024]

//define general channel. General channel does not restrict multicast group. General

channel number of C series version is 256, and that of D series version is 1024

ZXR10(config-nas)#iptv channel 256 mvlan 29

//designate the multicast VLAN

ZXR10(config-nas)#create iptv cac-rule 1

//create rule 1 for all VLANs



ZXR10(config-nas)#iptv cac-rule 1 right order [256 | 1024]

//buy a channel for rule 1, here general channel is bought

ZXR10(config-nas)#create iptv cac-rule 2 port gei_2/1

//create rule 2. It is to set the port to mr-port after it receives query message from multicast

router. When the port becomes mr-port, it can forward report message in uplink port.

ZXR10(config-nas)#iptv cac-rule 2 right query [256或1024]

//buy a channel for rule 2

2.2ConfigurationonSwitchof2000SeriesConfiguration on switch of 2000 series is shown below.

1. VLAN and port configuration:

zte(cfg)#set vlan 29,3998,3999 enable

zte(cfg)#set vlan 29,3998,3999 add port [uplink interface] tag

//add the uplink interface to VLAN in tag mode

zte(cfg)#set vlan 29 add port [downlink interface] untag

//add the downlink interface connecting to STB to multicast VLAN in untag mod, ensuring

that multicast packets can be sent to STB on downlink interface through multicast VLAN

zte(cfg)#set vlan 3998 add port [downlink interface] untag

//add downlink interface connecting to STB to VLAN 3998 in untag mode

zte(cfg)#set vlan 29,3999 add port [downlink interface] tag

//add downlink interface connecting to other ports to corresponding VLAN in tag mode

zte(cfg)#set port [downlink interface] pvid 3998

//set pvid of ownlink interface connecting to STB as 3998

2. IGMP Snooping related configuration:

zte(cfg)#set igmp snooping enable

//enable igmp snooping

zte(cfg)#set igmp snooping add vlan 29

//enable to snooping VLAN 29

zte(cfg)#set igmp snooping fastleave enable

//enable fast leaving

Data Products

www.zte.com.cn

21

3. IPTV control configuration:

zte(cfg)#config nas

//enter nas configuration mode

zte(config-nas)#iptv control enable

//enable iptv control to implement cross-VLAN multicast

zte(config-nas)#create iptv channel general 256

// define general channel. General channel does not restrict multicast group

zte(config-nas)#iptv channel 256 mvlan 29

// designate the multicast VLAN

zte(config-nas)#create iptv cac-rule 1 vlan 3999

//create a rule for access VLAN 399. One rule can only associated with one access VLAN

zte(config-nas)#iptv cac-rule 1 right order 256

//designate the right for rule 1

2.3ConfigurationDifferenceThe important differences between configurations on switch of 39/32 series and switch of 2000

series are described below.

1. Do not add the downlink interface connecting to STB on switch of 39/32 series to multicast

VLAN.

2. On switch of 39/32 series, enable querier function in access VLANs, and do not enable the

function in multicast VLAN.

3 Maintenance and Diagnosis CommandsMaintenance and diagnosis commands are described below.

3.1MaintenanceandDiagnosisCommandsforSwitchof39/32SeriesMaintenance and diagnosis commands for switch of 39/32 series are described below.

1.This example shows how to view information of whole multicast group.

3928# show ip igmp snooping iptv channel

S = Static; D = Dynamic.

Index Vlan Group ID Hosts

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

1 29 239.255.40.2 1

2 29 239.255.40.1 1

2. This example shows how to view detailed information of a group.



3928#show ip igmp snooping iptv port-info 239.255.40.1 vlan 29

Num Out_vid Ports PortState RemainTime

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

1 29 gei_2/2 V2Report 230

Note: The above information shows that there is user accessing to VLAN 29 through gei_2/2.

3. This example shows how to view mr-port information.

3928#show ip igmp snooping mr-port-info

Index VLAN Port State RemainTime

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

1 29 gei_2/1 Dynamic 186

4. This example shows how to view brief access information of IPTV client.

3928#show iptv client

MaxUserNum :2048

CurrentUserNum :2 HistoryUserNum :17

Index Name Port Vlan Rule ChNum

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

0 gei_3/2 3997 1 1

1 gei_2/2 29 1 1

5. This example shows how to view detailed information of an IPTV client.

3928#show iptv client index 0

Index :0 Name :

port :gei_3/2 Vlan :3997

Mac :00.e0.8e.d0.07.32 Ip address :10.132.98.90

Channel number :1

Channel UserType MultiAddress ElapsedTime

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

1024 order 239.255.40.2 0:1:10:51

3.2 Maintenance and Diagnosis Commands for Switch of 2000 SeriesMaintenance and diagnosis commands for switch of 2000 series are described below.

1. This example shows how to view IGMP Snooping table of VLAN 29.

Data Products

www.zte.com.cn

23

2818S(cfg)#show igmp snooping vlan 29

Maximal group number: 256

Current group number: 1

Num VlanId Group Last_Report PortMember

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

1 29 239.255.40.4 10.132.98.15 1,3

2. This example shows how to view brief access information of IPTV client.

2818S(cfg)#show iptv client

MaxClientNum:256

CurClientNum:1

HisClientNum:942

Index Name Rule Vlan Port ChNum

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

0 1 3998 3 1

3. This example shows how to view detailed information of an IPTV client.

2818S(cfg)#show iptv client index 0

Index :0 Name :

Rule :1 Vlan :3998

Port :3 ChNum :1

Mac :00.e0.8e.d0.a8.3a Ip :10.132.98.15

Channel UserType MultiAddress ElapsedTime

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

256 order 239.255.40.4 0:0:8:15



Network TopologyAs shown in Figure 1, the network

comprises the following parts:

1. Multicast source network: VS8000

works as multicast source. VRRP is

configured on the two T64G switches as

the redundant gateway of VS8000.

2. Content Distribution Network (CDN):

PIM SM is configured on the two T64G

switches, two NE80 routers and MA5200G

to establish a multicast distribution tree.

RP is on NE80-1.

3. Multicast receiver network: The STB

works as the receiver, with its gateway

on MA5200G. Packets are transmitted

transparently by DSLAM.

⊙ Zhang Jintao / ZTE Corporation

Butt Joint Malfunction of ZXR10 T64G and HW NE80

Key words: PIM-SM, PIM Snooping, IGMP Snooping


The expectant result is that users can

watch living programs provided by VS8000

through STB.

Malfunction SituationUsers failed to watch living programs provided

by VS8000 through STB. When the STB was

connected to T64G-1, users could watch living

programs. If the link between T64G-1 and T64G-2

was cut down, and STB was connected to T64G-2,

users could not watch living programs.

Malfunction AnalysisWhen the STB is connected to T64G-1, users

can watch living programs. This indicates that

the malfunction is not caused by multicast source

VS8000.

When the link connected multicast source and

STB, users can not watch living programs. This

indicates that the malfunction may be caused by

multicast butt joint between T64G and NE80.

To find out the problem, engineers viewed

abnormal debugging information. They found the

following two pieces of information.

1. When engineers input debug pim sm message-send on T64G-2, they found that T64G-2

was always sending registration messages to RP

(NE80-1), as shown below.

ZXR10 T64G-2#debug ip pimsm message-

send

04:05:05 PIMSM: Send Register message to

58.51.253.100 (loopback2 on RP NE80E)

Data Products

www.zte.com.cn

25

04:05:05 PIMSM: Send Register message to 58.51.253.100





04:05:05 PIMSM: Send Register message to 58.51.253.100w

……

2. Engineers checked PIM-SM messages received on T64G-2. The received error packets

are shown below.

ZXR10 T64G-2#debug ip pimsm message-recv

03:54:43 PIMSM: Received Hello message on vlan2003 from 121.60.176.21, ipLength 54

03:54:43 PIMSM: Wrong OptionType(2) in Hello packet for port:vlan2003 and

SourceAddr:121.60.176.21

03:55:02 PIMSM: Received Hello message on vlan2002 from 121.60.176.17, ipLength 54

03:55:02 PIMSM: Wrong OptionType(2) in Hello packet for port:vlan2002 and

SourceAddr:121.60.176.17

OptionType(2) is an option in PIM-SM. Current version of T64G does not support this option

and this does affect the multicast butt joint.

Therefore, the problem may be caused by the first piece of abnormal information. That is,

T64G-2 did not register to RP (NE80-1) successfully.

Procedure of registration to RP on DR is described below.

1. Multicast source sends unicast registration message to RP.

2. RP sends Join message to multicast source DR.

3. Multicast source DR sends multicast packets to RP.

4. RP stops sending registration message to multicast source DR. Then registration

procedure is finished.

According to the procedure and debugging information on T64G-2, DR (T64G-2) did not

register to RP (NE80-1) successfully, because DR (T64G-2) did not receive Join/Prune message

from RP (NE80).

Engineers of HW checked debugging information on NE80-1, and they found that NE80-1 sent

the Join/Prune messages. That is, NE80-1 sent the Join/Prune messages, but T64G-2 may fail to

receive the messages.

Engineers checked the routes between T64G-2 and NE80-1. There was no problem on the

links. Therefore, T64G-2 may have received the Join/Prune messages from NE80-1, but it did

process it and discarded it directly.

Engineers checked commands related to multicast in the VLAN that connects T64G-2 and

NE80-1. There were two commands: pim snooping and igmp snooping.When the malfunction occurred, igmp snooping was enabled and pim snooping was



disabled. Engineers disabled igmp snooping. The malfunction disappeared, and T64G-2

registered to NE80-1 successfully. When engineers enabled both pim snooping and igmp snooping, T64G-2 also registered to NE80-1 successfully. Users could watch living programs.

SolutionFor PIM-SM butt joint between T64G and NE80, configuration for the inter-connection VLAN

should be one of the following types:

● Enabling pim snooping and igmp snooping at the same time

● Disabling pim snooping and igmp snooping at the same time ■

⊙ Shan Changliang / ZTE Corporation

High CPU Utilization Ratio Caused by Multicast

Key words: PIM-SM, CPU, RPF, ACL

Network TopologyAs shown in Figure 1, T64G is a switch in IPTV

bearer network, connecting to multicast source

VS8000. Malfunction Situation

If PIM-SM function and PIM Snooping function

were enabled on T64G, when there was no user,

utilization ratio CPU of NP 2 (gei_2/14 connecting

to VS8000) kept a high value, as shown below.Figure 1. Network Topology

Data Products

www.zte.com.cn

27

ZXR10#show process

M: Master processor

S: Slave processor

Peak CPU: CPU peak utility measured in 2 minutes

PhyMem: Physical memory (megabyte)

Panel CPU(5s) CPU(30s) CPU(2m) Peak CPU PhyMem Buffer Memory

MP(M)1 3% 3% 3% 5% 512 0% 38.717%

MP(S)2 1% 1% 1% 4% 512 0% 20.779%

NP(M) 2 31% 31% 9% 42% 128 0% 53.495%

NP(M) 4 8% 8% 8% 11% 128 0% 50.872%

Malfunction AnalysisTo find out the problem, engineers input debug ip pimsm command on T64G. The result is

shown below.

ZXR10#debug ip pimsm

PIMSM debugging is on

ZXR10#

01:24:01 PIMSM: Received multicast data packet (10.0.0.1, 239.0.0.2) from vlan5

01:24:01 PIMSM: Received multicast data from 10.0.0.1, wrong RPF port vlan5











The above information showed that the source address of the multicast packets sent by

VS8000 was 10.0.0.1. This was not correct. In fact, it should be 172.16.0.10.

Obviously, multicast packets sent by VS8000 used the wrong source address. There was no

unicast route to 10.0.0.1 (10.0.0.1 was an un-distributed IP) on T64G. This led to Reverse Path

Forwarding (RPF) failure. Then VS8000 kept sending multicast packets and CPU of N2 on T64G

was busy with reverse path forwarding. Therefore, CPU utilization ratio kept high.

Engineers input debug ip source command on T64G. The result is shown below, which proofs

the analysis.



ZXR10#debug ip source 10.0.0.1

IP source debugging is on

ZXR10#

01:22:49 IP source:10.0.0.1 rcvd src 10.0.0.1(vlan5),dst 239.0.0.2






SolutionThe engineers configured ACL to filter the packets with source IP address of 10.0.0.1, as

shown below.

ZXR10(config)#acl basic number 2

ZXR10(config-basic-acl)#rule 1 deny 10.0.0.1 0.0.0.0

ZXR10(config-basic-acl)#rule 2 permit any

ZXR10(config-basic-acl)#exit

ZXR10(config)#interface gei_2/14

ZXR10(config-if)#ip access-group 2 in

ZXR10(config-if)#exit

CPU utilization ratio came to a normal value, as shown below.

ZXR10#show process

M: Master processor

S: Slave processor

Peak CPU: CPU peak utility measured in 2 minutes

PhyMem: Physical memory (megabyte)

Panel CPU(5s) CPU(30s) CPU(2m) Peak CPU PhyMem Buffer Memory

MP(M)1 3% 3% 3% 5% 512 0% 38.717%

MP(S)2 1% 1% 1% 4% 512 0% 20.779%

NP(M)2 12% 31% 9% 42% 128 0% 53.495%

NP(M)4 8% 8% 8% 11% 128 0% 50.872%

The problem was solved. ■

Data Products

www.zte.com.cn

29

Network TopologyAs shown in Figure 1, mult icast source

connects to T64G-1; users connect to IPTV

network through MAN. STB connects to HW

6506R. HW 6506R, T160G and T64G run PIM-SM.

Malfunction Situation

Users could receive TV signals, but signals on

STB were interrupted entirely from time to time.

Malfunction AnalysisHW 6506R connected to T160G through dual-

links. Engineers cut off the link between HW 6506R

and T160G-2. The problem was not solved. When

the malfunction occurred, engineers monitored a

channel. They viewed multicast routing table of the

group on T160G-1, and they found that outgoing

interface corresponding to (S, G) timed out. That is,

⊙ Zhang Xing / ZTE Corporation

Multicast Malfunction on T64G

Key words: PIM-SM, ACL


there was no outgoing interface; therefore,

the signals were interrupted.

Multicast routing table of the group on

T160G-1 is shown below.



(*, 233.18.204.194), 13:30:03/00:03:35, RP 218.1.0.10 , flags: S







(218.83.166.66, 233.18.204.194), 13:29:36/00:03:35 , flags: T







In the above information, the time before / is cumulative time, and the time after / is aging time.

From 13:30, when it is 2:30, it goes back to 13:30 again. That is, aging time is refreshed when

multicast Join messages are received every minute. If Join messages can not be received, or

illegal Join messages are discarded, the port will be cut off from the tree.

Engineers captured packets on the port of T160G-1 that connected to HW 6506R. They found

that Join messages from HW 6506R included a multicast group 233.255.255.250. It was a private

group, so T160G-1 considered that the messages were illegal messages and then discarded

them. Therefore, the port was cut off from the tree.

On T160G-1, there was the following configuration, as shown below. So T160G-1 considered

that the messages including group 233.255.255.250 were illegal messages.

ZXR10(config)#router pimsm

ZXR10(config-router)#static-rp 218.1.0.10 group-list 1 priority 0


ZXR10(config-basic-acl)#rule 1 permit 233.18.204.0 0.0.0.255


SolutionEngineers added a multicast group 233.255.255.250 to ACL on T160G-1.





The problem is solved.

Data Products

www.zte.com.cn

31

Network TopologyAs shown in Figure 1, 5928-2 and 5928-3 run

PIM-SM. Two switching boards on server VS8000

generate multicast packets for two multicast

groups. VS8000 connects to 5928-2 and 5928-3

through trunk ports. Multicast packets are born in

VLAN 7, VLAN 10 and VLAN 11.

5928-2 and 5928-3 run VRRP. For VLAN 7

and VLAN 10, active interface is on 5928-2, and

standby interface is on 5928-3. For VLAN 11,

active interface is on 5928-3, and standby interface

is on 5928-2.

Multicast packets are received in Area 1

through this network.


When there was only 5928-2 working, multicast packets could be received in area 1. When

5928-3 was enabled, some multicast packets would be lost.

Malfunction AnalysisMulticast is implemented on the base of unicast. Therefore, engineers checked unicast routes.

There were static routes and there was no problem.

Multicast packets went by DR. When 5928-3 was enabled, DR may be handed over. Engineers

considered that this caused the problem.

Priority on 5928-2 and 5928-3 was the same. It was 1 by default. Interface address of VLAN

11 on 5928-2 was 10.20.10.126, and interface address of VLAN 11 on 5928-3 was 10.20.10.125.

According to the rule that the switch with bigger interface address becomes DR, when 5928-3 was

enabled, VRRP was handed over. Gateway of VLAN 11 was on 5928-3. However, DR was not

handed over, and 5928-2 was still the DR. 5928-3 would not forward multicast packets of VLAN

11. Therefore, multicast packets of VLAN 11 were lost.

SolutionEngineers modified the DR priority on 5928-3 in VLAN 11, and then 5928-3 always worked as

⊙ Li Donglei / ZTE Corporation

DR Handover on VRRP Interface

Key words: PIM-SM, VLAN, VRRP, DR




DR. The configuration is shown below.

5928-3 (config-if)#ip pim dr-priority 100

Engineers viewed DR information on 5928-3, as shown below.

5928-3#show ip pimsm interface

Address Interface State Nbr Count Query Intvl DR DR Priority

10.20.10.250 vlan7 Up 1 30 10.20.10.249 1

10.20.10.94 vlan10 Up 1 30 10.20.10.93 1

10.20.10.125 vlan11 Up 1 30 10.20.10.125 100

Multicast packets could be received in area 1 normally. The problem was solved. ■

Data Products

www.zte.com.cn

33

Network TopologyAs shown in Figure 1, IPTV service is needed in

the exhibition hall, so a special line with bandwidth

of 20M is used to connect the head office and

exhibition hall. With streaming media, coder and

program source in the header office, only a STB is

needed in the exhibition hall.

Malfunction SituationAfter PIM-SM function was configured on

ZXR10 T64G in exhibition hall, only default

programs could be watched, and all living programs

could not be watched. At the same, programs

from the source also could not be watched in the

head office. Users disabled the special line in

this situation. IPTV service recovered within two

minutes.

Malfunction AnalysisWhen the service was interrupted, engineers

viewed multicast routes on T40G in the head

office. They found that after the source tree

disappeared for some minutes, the shared tree

also disappeared. However, shared tree packets of

multicast source sent by program source appeared

on T64G in the exhibition hall.

Multicast is implemented on the base of unicast.

However, static routes were configured on the two

switches. This could not cause the problem.

When T64G in the exhibition hall joined, it

⊙ Huang Hongru / ZTE Corporation

IPTV Service Interruption Caused by DR Priority

Key words: PIM-SM, IPTV, DR


took multicast packets to exhibition hall

and multicast packets went through DR.

Therefore, engineers considered that the

problem may be caused by PIM DR.

Engineers input show ip pimsm interface command on T40G in the head

office to view DR information. DR was

different before and after T64G in the

exhibition hall was enabled in the network.

When service was normal, DR was

80.20.28.201 on T40G in the head office,



as shown below.

T40G#show ip pimsm interface

Address Interface State Count Nbr Intvl Query DR DR Priority

80.20.28.201 vlan2 Up 0 30 80.20.28.201 1

80.20.28.197 vlan3 Up 1 30 80.20.28.198 1

When service was abnormal, 80.20.28.204 on T64G in the exhibition hall became the DR, as

shown below.

T40G#show ip pimsm interface

Address Interface State Count Nbr Intvl Query DR DR Priority

80.20.28.201 vlan2 Up 1 30 80.20.28.204 1

80.20.28.197 vlan3 Up 1 30 80.20.28.198 1

When service was abnormal, engineers checked special line interface on T64G, and found that

there was a lot of incoming traffic, as shown below.

Interface utilization: input 21%, output 0%

Due to the number limit of IP addresses, IP addresses distributed to inter-connection and IP

address of program source were in the same segment. Bandwidth of the special line was also

limited. Priority of PIM interfaces on the switches was 1. Therefore, the switch with bigger IP

address became the DR. Once T64G was enabled in the network, multicast packets went through

the DR, that is, T64G in the exhibition hall. Living traffic of more than 100 channels was huge, so

the special line of 20M could not sustain. There was only traffic coming, but no traffic going. As a

result, multicast packets from program source could not be received by STB in the exhibition hall

and IPTV service was interrupted.

SolutionEngineers modified the DR priority on VLAN interface of T40G in head office, which resulted in

T40G to work as DR. The configuration is shown below.

ZXR10(config-if)#ip pim dr-priority 10

Engineers viewed DR information on T40G, as shown below.

ZXR10#show ip pimsm interface

Address Interface State Count Nbr Intvl Query DR DR Priorit

80.20.28.201 vlan2 Up 0 30 80.20.28.201 10

80.20.28.197 vlan3 Up 1 30 80.20.28.198 1

The problem was solved. ■

Data Products

www.zte.com.cn

35

Network TopologyAs shown in Figure 1, users watch IPTV

programs through ADSL network.


When a user watches IPTV programs, system

prompted no signal for same channels. For some

channels, there was only sound but no image.

For some channels, service was normal. Such

problems did not appear on other devices in the

network. Users could get on-line with normal

network speed.

Malfunction AnalysisTo find out the problem, engineers took the

following steps.

1. Engineers disabled IGMP Snooping

function on ZXR10 3906 to make the switch flood

IPTV packets. The problem still existed, indicating

that this problem was not caused by multicast

packet forwarding on ZXR10 3906.

2. Engineers enabled IGMP Snooping

function on ZXR10 3906 to make the user watch

IPTV programs. At the same time, engineers input

debug igmp-snooping command on ZXR10 3906

to view packet sending and receiving information.

They found that when the user changed channels,

ZXR10 3906 did not receive Report message and

Leave message, or ZXR10 3906 received Report

message but no Leave message.

Engineers input show igmp snooping command

on ZXR10 3906. They found that the old channels

⊙ Zhang Hailong / ZTE Corporation

IPTV Service Malfunction Processing

Key words: PIM-SM, IPTV, ADSL, VLAN


in the multicast forwarding table were still

forwarded. Therefore, there were multicast

packets for multiple channels forwarded to

the same port. Due to downlink bandwidth

of ADSL, if the user changed channels

for several times, bandwidth would be

congested. As a result, for some channels,

system prompted no signal; for some

channels, there was only sound but no



image.

3. Engineers enabled cross-VLAN

multicast function on ZXR10 3906 and

tested IPTV services. Results showed that

it had no problem.

4. Engineers enabled cross-VLAN

multicast function on DSLAM and viewed

the multicast forwarding table. Result

showed that DSLAM did not receive

Report message and Leave message,

or it received Report message but no

Leave message. When engineers tested

IPTV services on the Ethernet interface of DSLAM

directly, results showed that it had no problem. This

indicated that the problem may be caused by ADSL

terminal or the user board of DSLAM.

SolutionEngineers changed ADSL terminal and the user

could watch IPTV program normally. The problem

was solved.

Engineers checked the ADSL terminal, and

they found that the buffer of the ADSL terminal was

not large enough. ■

Data Products

www.zte.com.cn

37

preface - ztezte.by/magazine/maintenance experience, issue147(data products).pdf · preface...

Documents