preface - ztezte.by/magazine/maintenance experience, issue147(data products).pdf · preface...
TRANSCRIPT
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
Maintenance Experience4
December 2008 Issue 147
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
Maintenance Experience6
December 2008 Issue 147
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.
Maintenance Experience8
December 2008 Issue 147
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)#interface fei_1/2
3906(config-if)#switchport mode trunk
3906(config-if)#switchport trunk vlan 200
3906(config-if)#exit
3906(config)#interface loopback1
3906(config-if)#ip address 1.1.1.1 255.255.255.255
3906(config-if)#exit
3906(config)#interface vlan 100
3906(config-if)#ip address 192.168.1.1 255.255.255.0
3906(config-if)#exit
3906(config)#interface vlan 200
3906(config-if)#ip address 192.168.2.1 255.255.255.0
3906(config-if)#exit
3906(config)#router ospf 2
3906(config-router)#network 1.1.1.1 0.0.0.0 area 0
3906(config-router)#network 192.168.2.0 0.0.0.255 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
3906(config-router)#exit
3. Enable PIM-SM on a Layer 3 interface.
3906(config)#interface vlan 100
3906(config-if)#ip pim sm
3906(config-if)#exit
3906(config)#interface vlan 200
Data Products
www.zte.com.cn
9
3906(config-if)#ip pim sm
3906(config-if)#exit
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 pimsm
3906(config-router)#static-rp 2.2.2.2
3906(config-router)#exit
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-if)#exit
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-if)#ip address 192.168.2.2 255.255.255.0
T64G(config-if)#exit
T64G(config)#interface vlan 300
T64G(config-if)#ip address 192.168.3.1 255.255.255.0
T64G(config-if)#exit
T64G(config)#router ospf 2
T64G(config-router)#network 2.2.2.2 0.0.0.0 area 0
T64G(config-router)#network 192.168.2.0 0.0.0.255 area 0
T64G(config-router)#network 192.168.3.0 0.0.0.255 area 0
T64G(config-router)#redistribute connected
T64G(config-router)#exit
Maintenance Experience10
December 2008 Issue 147
2. Enable IP multicast routing function and PIM-SM globally.
T64G(config)#ip multicast-routing
T64G(config)#router pimsm
T64G(config-router)#exit
3. Enable PIM-SM on a Layer 3 interface.
T64G(config)#interface vlan 200
T64G(config-if)#ip pim sm
T64G(config-if)#exit
T64G(config)#interface vlan 300
T64G(config-if)#ip pim sm
T64G(config-vlan)#exit
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.
T64G(config)#router pimsm
T64G(config-router)#static-rp 2.2.2.2
T64G(config-router)#exit
5.3Configurationon39281. Configure interface address and unicast route.
3928(config)#interface fei_1/1
3928(config-if)#switchport mode trunk
3928(config-if)#switchport trunk vlan 300
3928(config-if)#exit
3928(config)#interface fei_1/2
3928(config-if)#switchport access vlan 400
3928(config-if)#exit
3928(config)#interface loopback1
3928(config-if)#ip address 3.3.3.3 255.255.255.255
3928(config-if)#exit
3928(config)#interface vlan 300
3928(config-if)#ip address 192.168.3.2 255.255.255.0
3928(config-if)#exit
3928(config)#interface vlan 400
3928(config-if)#ip address 192.168.4.1 255.255.255.0
3928(config-if)#exit
Data Products
www.zte.com.cn
11
3928(config)#router ospf 2
3928(config-router)#network 3.3.3.3 0.0.0.0 area 0
3928(config-router)#network 192.168.3.0 0.0.0.255 area 0
3928(config-router)#redistribute connected
3928(config-router)#exit
2. Enable IP multicast routing function and PIM-SM globally.
3928(config)#ip multicast-routing
3928(config)#router pimsm
3928(config-router)#exit
3. Enable PIM-SM on a Layer 3 interface.
3928(config)#interface vlan 300
3928(config-if)#ip pim sm
3928(config-if)#exit
3928(config)#interface vlan 400
3928(config-if)#ip pim sm
3928(config-vlan)#exit
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.
3928(config)#router pimsm
3928(config-router)#static-rp 2.2.2.2
3928(config-router)#exit
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)#interface fei_1/2
3928(config-if)#switchport access vlan 400
3928(config-if)#protocol-protect mode igmp enable
Maintenance Experience12
December 2008 Issue 147
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
Incoming interface: vlan100, RPF nbr 0.0.0.0
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.
An example is shown below.
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:
Maintenance Experience14
December 2008 Issue 147
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
Displayed information instructions:
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.
An example is shown below.
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.
Displayed information instructions:
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.
An example is shown below.
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.
Displayed information instructions:
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.
An example is shown below.
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.
Displayed information instructions:
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.
An example is shown below.
ZXR10#show ip rpf 2.2.2.2
Maintenance Experience16
December 2008 Issue 147
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.
Displayed information instructions:
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
Displayed information instructions:
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
Maintenance Experience18
December 2008 Issue 147
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
ZXR10(config-vlan)#vlan 3998
ZXR10(config-vlan)#vlan 3999
2. Port configuration:
ZXR10(config)#interface fei_1/1 //interface connecting to STB
ZXR10(config-if)#protocol-protect mode igmp enable
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)#protocol-protect mode igmp enable
ZXR10(config-if)#negotiation auto
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-if)#switchport qinq normal
ZXR10(config)#interface gei_2/2 //downlink interface
ZXR10(config-if)#protocol-protect mode igmp enable
ZXR10(config-if)#negotiation auto
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)#switchport qinq normal
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
Maintenance Experience20
December 2008 Issue 147
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.
Maintenance Experience22
December 2008 Issue 147
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
Maintenance Experience24
December 2008 Issue 147
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
Figure 1. Network Topology
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.100
04:05:05 PIMSM: Send Register message to 58.51.253.100
04:05:05 PIMSM: Send Register message to 58.51.253.100
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
Maintenance Experience26
December 2008 Issue 147
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
01:24:01 PIMSM: Received multicast data packet (10.0.0.1, 239.0.0.0) from vlan5
01:24:01 PIMSM: Received multicast data from 10.0.0.1, wrong RPF port vlan5
01:24:01 PIMSM: Received multicast data packet (10.0.0.1, 239.0.0.4) from vlan5
01:24:01 PIMSM: Received multicast data from 10.0.0.1, wrong RPF port vlan5
01:24:06 PIMSM: Received multicast data packet (10.0.0.1, 239.0.0.2) from vlan5
01:24:06 PIMSM: Received multicast data from 10.0.0.1, wrong RPF port vlan5
01:24:06 PIMSM: Received multicast data packet (10.0.0.1, 239.0.0.0) from vlan5
01:24:06 PIMSM: Received multicast data from 10.0.0.1, wrong RPF port vlan5
01:24:06 PIMSM: Received multicast data packet (10.0.0.1, 239.0.0.4) from vlan5
01:24:06 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.
Maintenance Experience28
December 2008 Issue 147
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
01:22:49 IP source:10.0.0.1 rcvd src 10.0.0.1(vlan5),dst 239.0.0.0
01:22:49 IP source:10.0.0.1 rcvd src 10.0.0.1(vlan5),dst 239.0.0.4
01:22:54 IP source:10.0.0.1 rcvd src 10.0.0.1(vlan5),dst 239.0.0.4
01:22:54 IP source:10.0.0.1 rcvd src 10.0.0.1(vlan5),dst 239.0.0.2
01:22:54 IP source:10.0.0.1 rcvd src 10.0.0.1(vlan5),dst 239.0.0.0
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
Figure 1. Network Topology
there was no outgoing interface; therefore,
the signals were interrupted.
Multicast routing table of the group on
T160G-1 is shown below.
Maintenance Experience30
December 2008 Issue 147
(*, 233.18.204.194), 13:30:03/00:03:35, RP 218.1.0.10 , flags: S
Incoming interface: vlan2105, RPF nbr 218.83.168.46
Outgoing interface list:
vlan2100, Forward/Sparse, 13:29:35/00:03:06
vlan2101, Forward/Sparse, 13:30:01/00:02:58
vlan2102, Forward/Sparse, 02:38:46/00:02:59
vlan2103, Forward/Sparse, 13:30:01/00:02:46
(218.83.166.66, 233.18.204.194), 13:29:36/00:03:35 , flags: T
Incoming interface: vlan2014, RPF nbr 218.83.166.49
Outgoing interface list:
vlan2100, Forward/Sparse, 13:29:35/00:03:06
vlan2101, Forward/Sparse, 13:29:36/00:02:58
vlan2102, Forward/Sparse, 02:38:46/00:03:22
vlan2103, Forward/Sparse, 13:29:36/00:02:46
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)#acl basic number 1
ZXR10(config-basic-acl)#rule 1 permit 233.18.204.0 0.0.0.255
ZXR10(config-basic-acl)#exit
SolutionEngineers added a multicast group 233.255.255.250 to ACL on T160G-1.
ZXR10(config)#acl basic number 1
ZXR10(config-basic-acl)#rule 1 permit 233.18.204.0 0.0.0.255
ZXR10(config-basic-acl)#rule 2 permit 233.255.255.250 0.0.0.0
ZXR10(config-basic-acl)#exit
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.
Malfunction Situation
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
Figure 1. Network Topology
Maintenance Experience32
December 2008 Issue 147
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
Figure 1. Network Topology
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,
Maintenance Experience34
December 2008 Issue 147
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.
Malfunction Situation
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
Figure 1. Network Topology
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
Maintenance Experience36
December 2008 Issue 147
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