PrefaceMaintenance ExperienceEditorial Committee
Maintenance ExperienceNewsroom
Address: ZTE Plaza,No. 55, Hi-tech Road
South, ShenZhen, P.R.China
Postal Code: 518057
Contact: Ning Jiating
Tel: +86-755-26776049
Fax: +86-755-26772236
Document Cupport Email: [email protected]
Technical Cupport Website: http://ensupport.
zte.com.cn
Maintenance ExperienceBimonthly for Data ProductsNo. 18 Issue 268, December 2011
Director: Qiu Weizhao
Deputy Director: Huang Dabin
Editors:Fang Xi, Wang Zhaozheng, Xu Xinyong,
Zhang Jian, Zhang Jiebin, Zhao Cen,
Zhou Guifeng, Xiao Shuqing, Ge Jun,
Zhao Haitao, Huang Ying, Xu Zhijun,
Jiang Haijun, Dong Yemin, Dong Wenbin
Technical Senior Editors:Hu Jia, Tao Minjuan, Zhang Jianping
Executive Editor:Zhang Fan
Maintenance Experience Editorial CommitteeZTE CorporationDecember, 2011
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:● A Special Document
● Nine Maintenance Cases of ZTE's Data Products
Have you examined your service policies 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
Multicast Overview ......................................................................................................................................2
Period of Multicast Message is Abnormal....................................................................................................7Multicast IPTV Is Interrupted .......................................................................................................................11Multicast Stream Fails to be Received ........................................................................................................16The Period of Multicast Messages is Abnormal...........................................................................................20Interconnection Fault of Multicast Devices ..................................................................................................23Higher CPU Usage for 8905 Multicast Fault................................................................................................26Relocation Configuration of BAS Defaulting Subscribers ............................................................................30DHCP Client Fails to Obtain IP Addresses ..................................................................................................33
Technical Specials
Maintenance Instances
Maintenance Experience2
December 2011 Issue 268 Technical SpecialsTechnical Specials
Multicast Overview⊙Qian Yuemei / ZTE Corporation
Abstract: This section describes the basic concept and configuration of the multicast, the
multicast protocol, and the IGMP protocol.
Key words: Multicast, IGMP, SPT, RPT, and RPF
1 Multicast OverviewMulticast is a point-to-multipoint or
multipoint-to-multipoint communication
mode. That is to say, multiple receivers
receive information from the same source.
The following applications base on the
multicast, including videoconference,
d i s t a n c e l e a r n i n g , a n d s o f t w a r e
distribution.
The multicast protocol includes the
group member management protocol and
the multicast routing protocol.
1. The group member management
protocol is used to manage the adding and
deleting of the members in the multicast
group.
2. The multicast routing protocol is used
for information interaction between the
routers so as to establish multicast trees.
2 Multicast AddressIn a multicast network, the sender,
ca l led the mul t icast source, sends
packages to multiple receivers. Multiple
receivers for the same package can be
identified with the same ID, which is called
multicast address.
In the IP address allocation scheme,
the address of type D is the multicast
address, 224.0.0.0-239.255.255.255. In
which, 224.0.0.0-224.0.0.255 and 239.0.0.
0-239.255.255.255 addresses are used for
research and management.
3 Multicast TreeIn the TCP/IP network, to realize the multicast
communication, the multicast source, receiver, and
the path must exist. The tree-based routing is a
normal method used for path selection. The tree-
based routing has the following two advantages:
1. The packages are sent to different receivers
through the branches in parallel.
2. The packages are duplicated in the crotch. In
this case, the branch packages transmitted in the
network are the least.
The multicast tree is a set composed of ingress
interfaces and egress interfaces of a series of
routers. It determines a unique path between the
sub-net of the multicast source and all sub-nets
including the group members.
Two methods are used to establish a multicast
tree, including the source-based multicast tree
(SPT), and the shared multicast tree (RPT).
1. Source-based multicast tree
The source-based multicast tree is also called
the shortest path tree. It establishes a tree from
each source to all receivers. This tree is from the
root node, which is the source, to the network of
all receivers. One multicast group may include
multiple multicast sources. For each source, or
each muticast (S,G), there is a corresponding
multicast tree.
Reverse path forwarding (RPF) is used to
establish a multicast tree based on the source.
Technical Specialswww.zte.com.cn
3Data Products
Technical Specials
Each router can f ind a shor test path and
corresponding egress interfaces to the source
according to the unicast routing. When a multicast
package is received, the router will check whether
the ingress interface is the egress interface of the
shortest unicast path to the source. If so, it will
forward the multicast package according to the
multicast routing. Otherwise, it will discard the
multicast package.
2. Shared multicast tree
The shared mult icast tree establishes a
multicast routing tree for each multicast group. This
multicast routing tree is shared by all members in
this group, and it is not for only one muliticast (S,G).
The member who wants to receive the multicast
packages of this group needs to be added to this
shared multicast tree.
The shared multicast tree uses one or a set
of routers as the core of this multicast tree. All
packages from the source pass through this
center, and then are forwarded through the shared
multicast tree in multicast mode.
4 Multicast ProtocolThe multicast protocol is classified into the
group member relationship protocol between hosts
and routers, and the multicast routing protocol
between the routers, as shown in Figure 1.
4.1 IGMP4.1.2 IGMP Overview
If a host wants to receive multicast
packages from a specific group, it needs
to intercept all the packages sent to this
group. To select the path selection of
the multicast packages on Internet, the
host needs to notify the group where the
multicast router is added to or deleted.
The multicast uses the Internet Group
Management Protocol (IGMP) to complete
this task. The IGMP, which realizes the
bidirectional function, runs between the
host and the routers connected to the
host. ● The host notifies the router the
name of a specific multicast group through
the IGMP function, and then it will receive
messages from this multicast group.● The router checks whether the
members in the multicast group in the
local area network are in active status
through the IGMP function periodically so
as to maintain and collect the members of
the connected network segment.
Figure 1. Multicast Protocol
Maintenance Experience4
December 2011 Issue 268 Technical SpecialsTechnical Specials
T h e I G M P u s e s t w o t y p e s o f
messages, including group member
query message and group member report
message.● The multicast router sends group
member query messages to all hosts
periodically so as to know whether the
connected sub-networks also have group
members. The hosts return a member
repor t message, which repor ts the
belonging multicast group.● When a host is added to a new
group, it sends a member report message
immediately. In this case, the first member
can receive multicast data immediately.● When a host acting as a member
of one group begins to receive messages,
the multicast router checks whether
the network also has group members
periodically. If so, the multicast router
continues forwarding data.● When the host is deleted from
a group, it sends a deletion message to
the multicast router. The multicast router
checks whether this group still has active
group members immediately. If so, the
multicast router continues forwarding data.
If not, it does not forward data any longer.
In this case, the multicast router knows
whether the network still has multicast
members so as to determine whether to
forward multicast packages to this network.
When a multicast router receives a multicast
package, it checks the multicast destination
address of the package, and then forwards the
package to the interfaces of the members in this
group or to the downstream router.
The IGMP has the following three versions:● IGMPv1 (RFC 1112) defines the basic
group member query and report.● Based on IGMPv1, the deletion mechanism
is added in IGMPv2 (RFC 2236).● IGMPv3 (RFC 3376) is added with the
multicast source selection function so as to support
the SSM model.
4.1.2 IGMP ConfigurationI G M P c o n f i g u r a t i o n i n c l u d e s v e r s i o n
configuration, IGMP group configuration on the
interface, and IGMP timer adjustment.
The IGMP function of ZTE is based on the
PIM interface, so the IGMP function is enabled
automatically together with the PIM interface. The
following takes ZXR10 M6000 as an example to
describe the configuration mode.
1. Configure the IGMP version. The IGMP
function has three versions, namely, V1, V2, and
V3. The default version is V2. You can adjust
the version by running the version <version>
command as requi red. The IGMP vers ion
configuration is based on interfaces, so different
interfaces can be configured with different versions.
2. Configure the IGMP group on the interface,as
shown in Table 1.
Table 1. Configure the IGMP Group on the Interface
Step Command Function
1 ZXR10(config-igmp-if)#access-
group <access-list-number>Configures the group used to add IGMP. The IGMP can be added to all groups by default.
2ZXR10(config-igmp-if)#static-
group <group-address>
Configures the static group members for the IGMP interface. <group-address> refers to the address of the static group where the IGMP is added.
3ZXR10(config-igmp-
if)#immediate-leave [group-list <access-list-number>]
Configures the group that allows members to leave immediately.
Technical Specialswww.zte.com.cn
5Data Products
Technical Specials
3. Adjust the IGMP timer as required.
When the IGMP function is enabled on the
interface that connects to a shared network
segment, select an optimal querier that acts as this
network segment to send query messages so as to
obtain the information of group members.
After a querier sends query messages, it will
wait for the member report from the receiver within
a while. This waiting interval is the max response
time carried by the query messages. The default
value is 10 seconds.
After the host members in this network segment
receive query messages, they will subtract a
random deviation value based on the maximum
response time. The result will be the response time.
During this interval, the report from other hosts will
be cancelled. Otherwise, the host report will be
sent. In this case, when the maximum response
time is increased, the waiting opportunity is added,
and the unexpected host reports in the network
segment will be reduced.
According to the real network, you can
adjust the values of several timers related to the
querier,as shown in Table 2.
In which, the default value in Step 3
is calculated according to the following
formula:
<que ry - i n te rva l>×<robus tness -
count>+<query-max-response-time> /2
Unit: s
<robustness-count> refers to the
robustness coefficient of a query.
4.2 Multicast Routing ProtocolsThe multicast routing protocol is used
for information interaction between the
routers so as to establish a multicast tree.
The method is based on the multicast
routing protocol. To meet the distribution of
multicast subscribers in the network, the
multicast routing protocol is classified into
two categories, including dense mode and
sparse mode.
1. Dense Mode
The premise for the dense mode is that
the multicast subscribers in the network
are very dense, and the bandwidth is very
sufficient. With this mode, the multicast
packages flood in the whole network so as
Table 2. The Values of Several Timers Related to the Querier
Step Command Function
1ZXR10(config-igmp-if)#query-interval
<seconds>
Configures the query interval for the IGMP protocol. The default value is 125 seconds.
2ZXR10(config-igmp-
if)#query-max-response-time <seconds>
Configures the max response time carried by the query message sent by the IGMP protocol. This function is valid for only V2 and V3. The default value is 10s.
3ZXR10(config-igmp-if)#querier-timeout
<seconds>Configures the timeout time for the IGMP querier.
4ZXR10(config-igmp-
if)#last-member-query-interval <seconds>
Configures the query interval for an IGMP special group. This function is valid only for V2. The default value is 1s.
5ZXR10(config-igmp-
if)#robusrness-count <times>
Configures the robusrness coefficient for the IGMP querier that is the number of times that a message is sent. Range: 2-7.
6ZXR10(config-igmp-
if)#shaping-packets-number <number>
Limits the number of sent messages. <number> refers to the number of sent messages. Range: 1-maximum available number.
Maintenance Experience6
December 2011 Issue 268 Technical SpecialsTechnical Specials
to establish and maintain a multicast tree
periodically. That is to say, the router that
uses the multicast routing protocol floods
received packages to all other interfaces.
When the neighbor router of one
interface reports that one group does not
exist, this interface will be deleted from
this multicast tree. This deletion operation
is called pruning. When a neighbor router
reports that the receiver of this group
exists in the network again, this interface
will be added to the multicast tree of this
group. This operation is called graft.
The multicast routing protocols in
dense mode include: ● Distance Vector Multicast Routing
Protocol (DVMRP)● Multicast Open Shortest Path First
(MOSPF)
● Protocol Independent Multicast Dense
Mode (PIM-DM)
2. Sparse Mode
The sparse mode is used when the multicast
receivers in the network are very sparse. In this
case, if a dense mode is used to flood all packages,
it is a big waste for the bandwidth. In sparse mode,
to receive multicast packages, a network device
must be added to the multicast routing tree.
The multicast routing protocols in sparse mode
include:● Core-Based Trees (CBT)● Protocol Independent Multicast Sparse
Mode (PIM-SM)
The following details the related principle and
configuration of the common multicast routing
protocol, PIM-DM and PIM-SM. ■
Technical Specialswww.zte.com.cn
7Data Products
Technical Specials
Period of Multicast Message is Abnormal⊙Feng Chao / ZTE Corporation
Abstract: The period when the device in the network receives IGMP Query messages is
abnormal, so the multicast service is interrupted. Through fault elimination and
analysis, the engineer finds that the SDH device in the network loops back the
Query messages.
Key words: IGMP, Query, loopback, period
1 Network DescriptionAs shown in Figure 1, the multicast VLAN 3999
passes from the terminal subscribers to the BAS.
The following contents are enabled on ZXR10
8905 :
ip igmp snooping
ip igmp snooping proxy
ip igmp snooping querier
!
vlan 3999
igmp snooping querier
set igmp snooping enable
set igmp snooping add vlan 3999
Configure the IGMP SNOOPING function on
ZXR10 5116:
The SDH device is used for the interconnection
between ZXR10 5116 and the CS network. The
static port link aggregation is used between SDH-1
and ZXR10 5116, and between SDH-2 and the C5
network.
ZTE OLT device can be considered as a normal
layer-2 switch.
Figure 1. Multicast Network
Maintenance Experience8
December 2011 Issue 268 Maintenance InstancesMaintenance Instances
2 Fault SymptomThe following faults occur during the network running:
1. The period when the LAPTOP receives Query messages from ZXR10 8905 is three times of
the real query period.
2. The capturing results show that LAPTOP receives two continuous sudden Query messages
sent by ZXR10 8905 each time (less than 100 ms).
3. During the multicast service test under OLT, the engineer finds that the multicast service is
interrupted every five minutes.
3 Fault Analysis1. First, check the IGMP Query period configuration on ZXR10 8905 and ZXR10 5116. The
engineer finds that the period configuration is normal, because it is set to 125 s.
2. The engineer doubts that maybe the Query message on ZXR10 8905 is limited. The mr-port
table item of router 8905 is as follows:
8905#show ip igmp snooping mr-port-info
Index VLAN Port State RemainTime
--------------------------------------------------
1 3999 gei_2/35 Dynamic 227
2 3999 gei_2/38 Dynamic 220
3 3999 smartgroup17 Dynamic 214
The result shows that the SmartGroup17 interface is set to mr-port. Only when IGMP Query
message is received, will the corresponding interface become mr-port. The above interface value
means that SmartGroup17 has received IGMP Query messages.
3. Further check where the IGMP Query message is looped back.
The log information on ZXR10 5116 is as follows:
5116(cfg)#show igmp snooping vlan 3999 router
Last IGMP_QUERY_ROUTER's ip is 10.40.92.106
Num VlanId PortId Expiry
---- ------ ------- ----------
1 3999 T1 177
2 3999 T3 176
5116(cfg)#show igmp snooping vlan 3999 router
Last IGMP_QUERY_ROUTER's ip is 10.40.92.106
Num VlanId PortId Expiry
---- ------ ------- ----------
1 3999 T1 156
2 3999 T3 155
5116(cfg)#show igmp snooping vlan 3999 router
Last IGMP_QUERY_ROUTER's ip is 10.40.92.106
Maintenance Instanceswww.zte.com.cn
9Data Products
Maintenance Instances
Num VlanId PortId Expiry
---- ------ ------- ----------
1 3999 T1 2554
2 3999 T3 2554
5116(cfg)#show igmp snooping vlan 3999 router
The above information indicates that: ● ZXR10 5116 receives Query messages
sent by ZXR10 8905 from the downlink T1, which
is the aggregation link interface connected to the
downlink SDH-1 device.● The address of this query message is
10.40.92.106, which means that this message is
sent by ZXR10 8905.● After receiving Query messages from
T3, ZXR10 5116 receives Query messages with
the same format from T1 immediately (within one
second).
The above information shows that the fault is
caused by the device under ZXR10 5116, maybe
the SDH device, or the C5 network.
4. Further locate the fault.
As shown in Figure 2, perform the following
operations:
(1) If the fault still exists when Link3 and Link4
are broken at the same time, it means that the
loopback is not caused by HW C5.
(2) If the fault still exists when Link1, Link2, and
Link3 are broken at the same time, it means that
the loopback is not between different interfaces of
SDH1.
(3) The fault disappears when the one interface
on the SDH1 side exists, and the interface is set to
a physical interface.
Till now, the engineer finds that the trunk (static
aggregation) on the SDH1 device results in the
Query message loopback.
Based on the above results, the analysis on fault 1 is as follows:
The IGMP Query message sent by ZXR10 8905
passes through ZXR10 5116 and the connected Figure 2. Device Connection under ZXR10 5116
network, and then it loops back. In this
case, the sg17 of ZXR10 8905 receives
the Query message sent by itself, so
the sg17 of ZXR10 8905 is added to the
mroute list.
The aging time of the mroute list is 260
s. Within this 260 s, the sg17 interface is
the mroute interface. The sending of the
Query message is limited, and it can be
sent only after an aging interval (260 s)
and a query interval (125 s).
Maintenance Experience10
December 2011 Issue 268 Maintenance InstancesMaintenance Instances
The second Query message sent by
ZXR10 8905 is looped back immediately,
so it is in another l imited period. In
this case, ZXR10 8905 sends a Query
message every 375 s.
The analysis on fault 2 is as follows:One Query message is sent by
ZXR10 8905 directly, and the other Query
message is a loopback message on the
5116-SDH side through ZXR10 8905.
The analysis on fault 3 is as follows:The IGMP Snooping funct ion on
OLT is enabled, so LAPTOP refreshes the IGMP
Snooping item on the related OLT through a
passive response Query message. The period
when ZXR10 8905 sends a Query message is 375
seconds. It is longer than the aging time of the
default IGMP Snooping table item on the layer-2
devices, such as OLT. In this case, the service is
interrupted periodically.
4 Lessons LearnedPay attention to the principle of the protocol,
and confirm the reason why the Query message is
limited. ■
Maintenance Instanceswww.zte.com.cn
11Data Products
Maintenance Instances
Multicast IPTV Is Interrupted⊙Ke Jinshui / ZTE Corporation
Abstract: The IGMP query and the protocol protection configuration are incorrect, so the
multicast is interrupted. The section analyzes this fault in detail.
Key words: IGMP, Query, querier, protocol protection, and IGMP Snooping
1 Network DescriptionF igu re 1 shows t he IPTV ne two rk i ng
application. ● The Client is an IPTV set-top box, which
is used to receive video streams. The IP address
is 10.177.240.19, and the gateway is on T160G-1
(10.177.240.1, VLAN411).● 3928, T64G-1, and T160G-2 are layer-2
devices, which transmit VLAN411, and VLAN411
transparently. The terminal is T160G-1.● T160G-2 is connected to the BRAS device
(10800E) through the gei_7/10 port which is added
to VLAN411.
Figure 1. IPTV Network Architecture
● The IGMP Snooping, and IGMP
Proxy functions are enabled on T160G-2,
and T64G-1. The layer-3 in ter face
VLAN411 on T160G-1 is configured with
ip pim sm and static RP. The T160G is
the edge point of the layer-3 multicast
network.
2 Fault SymptomThe top-set box cannot receive any
channels even if it is restarted.
Maintenance Experience12
December 2011 Issue 268 Maintenance InstancesMaintenance Instances
3 Fault Analysis1. Check whether the communication
between the top-set box and the gateway
device is normal. The engineer finds that
he can ping the top-set box successfully
from T160G-1, and the ARP and the MAC
table are normal.
2. Check the device configuration.
The engineer finds that the version of G
network is 2602D. If the IGMP message
received by the port needs to be sent to
CPU for handling, you must configure
the IGMP protocol protection function by
running the protocol-protect mode igmp enable command.
The following devices in the network
need to handle the IGMP message:● The gei_1/1 port of the T160G-1
layer-3 device is used to handle the IGMP
message.● The gei_2/1, and gei_5/1 ports of
the T160G-2 device, and the gei_5/1, and
gei_1/12 ports of the T64G- device. These
two devices are configured with the igmp snooping function, so the corresponding
interface needs to be configured with the
protocol protection function. Otherwise,
the layer-2 snooping table item cannot be
formed.
T160G-2#show ip igmp snooping
Totol group num 1,has host group num 1
S = Static; D = Dynamic.
Index VLAN Group ID
LiveTime Ports
--------------------------------------
1 411 233.233.201.104
0:00:03:09 gei_5/1/D,
● The VLAN411 interface of the T160G-
1device needs to be configured with the ip pim sm function.
After the related configuration is modified, the
top-set box can receive multicast streams, and the
video is normal.
However, the stream is interrupted every five
minutes after the top-set box is restarted, which
means that the fault still exists.
3. The fault period is fixed, so the engineer
doubts that this fault results from the aging of the
layer-2 multicast table. To reduce the fault range,
the engineer connects the top-set box to the
T160G-2 device to receive multicast. In this case,
the fault is the same, which means that the T64G-1
and 3928 are normal.
4. Run the show ip igmp snooping command
on the T160G-2 device. The result is as follows:
Maintenance Instanceswww.zte.com.cn
13Data Products
Maintenance Instances
When running this command repeatedly, the
engineer finds that the table item disappears when
the LiveTime is near five minutes. At the same
time, when running the show ip mroute command
on the T160G-1 device, the engineer finds that
egress of the layer-3 multicast routing table also
disappears.
To find the fault reason, the engineer analyzes
the normal network.
1. The top-set box sends IGMP Report
messages to T64G-1 through 3928 transparently.
2. After receiving IGMP Report messages, the
T64G-1 device forms a layer-2 IGMP table item
because the IGMP Snooping function is enabled.
At the same time, T64G-1 continues sending IGMP
Report messages to the T160G-2 device because
the IGMP Proxy function is enabled.
3. After receiving IGMP Report messages from
T64G-1, the T64G-2 uses the method used by
T64G-1 to handle the messages.
4. After receiving IGMP Report messages from
T160G-2, the T160G-1 device sends PIM Join
messages to RP hop-to-hop. Finally, the multicast table
items (*,g) and (s,g) are formed. The multicast stream is
from T160G-1 to the top-set box through VLAN411.
To ensure that th is mult icast stream is
continuous, you must make sure that the top-set
box or T160G-1 VLAN411 sends IGMP Report
messages periodically. In general, the multicast
router sends IGMP Query messages
actively.
The device that receives the IGMP
Query message must handle this message
correctly. If T160G-1 receives no response
after the IGMP Query message is sent, the
layer-3 multicast table will be aged after
three times of queries. In this case, the
multicast stream will be interrupted.
To keep the IGMP Snooping table
item, the layer-2 device between the top-
set box and the T160G-1 device also
need to receive IGMP Report message
continuously. Otherwise, the multicast
stream will be interrupted.
In all, the descriptions are as follows:
1. When the IGMP query timer on
the T160G-1 device expires, it will send
general Query messages to gei_1/1 in
vlan 411.
2. Af ter receiv ing general query
messages, on the one hand, the T160G-2
device sends general queries to the
downstream device (T64G-1); on the other
hand, it sends IGMP Report messages
to the upper stream device (T160G-1)
to respond to the general query sent by
T160G-1.
3. The handling steps of T64G-1 are
Maintenance Experience14
December 2011 Issue 268 Maintenance InstancesMaintenance Instances
T160G-1#show ip igmp interface vlan411
vlan411
Internet address is 10.177.240.1, subnet mask is 255.255.255.0
IGMP is enabled on interface
Current IGMP version is 2
IGMP query interval is 125 seconds
IGMP last member query interval is 60 seconds
IGMP query max response time is 10 seconds
IGMP querier timeout period is 251 seconds
IGMP querier is 10.41.0.11, expire timer: 00:00:30
T160G-2#show ip igmp snooping mr-port-info
Index VLAN Port State RemainTime
------------------------------------------------------------------------------
1 412 gei_4/1 Dynamic 160 /*The mroute interface learnt dynamically*/
2 411 gei_2/1 Static 65535 /*The mroute interface specified statically*/
the same as those of T160G-2. When T160G-2 receives IGMP Report messages from T64G-1, it
can refresh the IGMP Snooping timer.
When the above flow is known, the engineer enables the debug function on the device to find
the fault when there are less multicast services.
1. When running the debug ip igmp-snooping command, the engineer finds that the T160G-2
device does not receive general query messages from T160G-1.
2. The engineer doubts that the mroute port is not formed on the T160G-2 device. In this case,
the engineer runs the igmp snooping mrouter interface gei_2/1 command on vlan 411 so as to
configure the mroute port on T160G-2.
However, the engineer finds that the fault still exists after the configuration.
3. The engineer finds that another gei_7/10 port on T160G-2 is connected to 10800E, and this
port is also in VLAN411.
After deleting gei_7/10 from VLAN411, the engineer finds that the top-set box is normal, and
the stream is not interrupted after five minutes.
4. The engineer continues to analyse this fault.
After checking the related configurations on 10800E, the engineer finds that pim sm is
configured incorrectly on VLAN411. T160G-1 also has a layer-3 multicast interface in VLAN411.
In this case, the engineer needs to select a querier. In general, the querier will be with a smaller
address. The querier is used to send general query messages.
The engineer doubts that the address of 10800E is smaller, so it will be the querier. However,
it does not send any query messages or the sent query messages are not received by other
devices. When checking the interface on T160G-1, the engineer finds that the address of the
querier is that of 10800E.
Maintenance Instanceswww.zte.com.cn
15Data Products
Maintenance Instances
T160G-1#show ip igmp interface vlan411
vlan411
Internet address is 10.177.240.1, subnet mask is 255.255.255.0
IGMP is enabled on interface
Current IGMP version is 2
IGMP query interval is 125 seconds
IGMP last member query interval is 60 seconds
IGMP query max response time is 10 seconds
IGMP querier timeout period is 251 seconds
IGMP querier is 10.177.240.1, never expire /*Address of T160G-1*/
Inbound IGMP access group is not set
IGMP immediate leave control is not set
/*After confirmation, the engineer finds that this IP address is that of VLAN411
on 10800E.*/
Inbound IGMP access group is not set
IGMP immediate leave control is not set
In the planning, the gei_7/10 is not required to handle the IGMP message, so the
corresponding protocol protection function is disabled. Even if 10800E sends query messages,
T160G-2 does not handle it. Till now, the fault reason is found.
5. After the pim sm configuration is deleted from 10800E, the querier is changed to T160G-1,
this fault disappears even if the gei_7/10 port is added to VLAN411.
4 SolutionsThis fault is solved after the gei_7/10 port is deleted from VLAN411.
5 Lessons LearnedDuring the investigation of multicast faults, it is very important to know the protocol and the
correction configuration. ■
Maintenance Experience16
December 2011 Issue 268 Maintenance InstancesMaintenance Instances
Multicast Stream Fails to be Received⊙ Zhang Fan / ZTE Corporation
Abstract: The multicast stream fails to be received because the multicast source setting
is incorrect.
Key words: Multicast source, TTL, counting
1 Fault SymptomAs shown in Figure 1, ZXR10 5252,
R1, and SW layer-3 switch are enabled
with the layer-3 multicast function.
Figure 1 Multicast Network
Figure 2 Multicast Network Test
As shown in Figure 2, when performing
the multicast test on ZXR10 5252, the
engineer finds that the connected PC
cannot receive multicast streams.
2 Fault Analysis1. When checking the multicast configuration
on ZXR10 5252, the engineer finds that the
configuration is correct.
interface loopback1
ip address 1.1.1.1 255.255.255.255
out_index 27
!
interface vlan 10
ip address 10.1.1.1 255.255.255.0
out_index 28
ip pim sm
!
interface vlan 20
ip address 20.1.1.1 255.255.255.0
out_index 29
ip pim sm
ip multicast-routing
!
!
router pimsm
static-rp 1.1.1.1
!
ip igmp snooping
Maintenance Instanceswww.zte.com.cn
17Data Products
Maintenance Instances
ZXR10#show interface gei_1/1 /*This interface is used to connect to a
multicast source*/
gei_1/1 is up, line protocol is up
Description is none
The port is electric
Duplex full
Mdi type:auto
MTU 1500 bytes BW 100000 Kbits
Last clearing of "show interface" counters 0Day(s) 0Hour(s) 0Min(s) 22Sec(s)
20 seconds input rate : 370360 Bps, 272 pps
20 seconds output rate: 5 Bps, 0 pps
Interface peak rate :
input 333324 Bps, output 4 Bps
Interface utilization: input 2%, output 0%
Input:
Packets : 4903 Bytes : 6666492
Unicasts : 0 Multicasts: 4894
Broadcasts : 9 Undersize : 0
Oversize : 0 CRC-ERROR : 0
Dropped : 0 Fragments : 0
Jabber : 0 MacRxErr : 0
Output:
Packets : 1 Bytes : 96
Unicasts : 0 Multicasts: 1
Broadcasts : 0 Collision : 0
LateCollision: 0
Total:
64B : 0 65-127B : 10
128-255B : 0 256-511B : 0
512-1023B : 0 1024-2047B: 4894
ZXR10#show inter gei_1/2 /*This interface is used to connect to a multicast
receiving PC*/
2. Check the multicast count of the port:
Maintenance Experience18
December 2011 Issue 268 Maintenance InstancesMaintenance Instances
3. The bold font shows that the multicast source has sent the multicast stream. However, the
receivable port (1/2) receives no multicast streams.
4. Check the multicast routing table. The details are as follows:
gei_1/2 is up, line protocol is up
Description is none
The port is electric
Duplex full
Mdi type:auto
MTU 1500 bytes BW 1000000 Kbits
Last clearing of "show interface" counters 0Day(s) 0Hour(s) 0Min(s) 44Sec(s)
20 seconds input rate : 2055 Bps, 31 pps
20 seconds output rate: 0 Bps, 0 pps
Interface peak rate :
input 2151 Bps, output 27 Bps
Interface utilization: input 0%, output 0%
Input:
Packets : 1275 Bytes : 84132
Unicasts : 1266 Multicasts: 2
Broadcasts : 7 Undersize : 0
Oversize : 0 CRC-ERROR : 0
Dropped : 0 Fragments : 0
Jabber : 0 MacRxErr : 0
Output:
Packets : 4 Bytes : 558
Unicasts : 0 Multicasts: 4
Broadcasts : 0 Collision : 0
LateCollision: 0
Total:
64B : 9 65-127B : 1268
128-255B : 2 256-511B : 0
512-1023B : 0 1024-2047B: 0
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,
* -Assert flag
Maintenance Instanceswww.zte.com.cn
19Data Products
Maintenance Instances
The engineer finds (*, G) and (S,G), but the count is abnormal (bold font).
5. The above results show that this fault results from the multicast source.
6. When checking the multicast source, the engineer finds that the TTL is set to 1.
3 SolutionsThe PC can receive multicast stream normally after the TTL is set to 5. ■
Statistic:Receive packet count/Send packet count
Timers:Uptime/Expires
Interface state:Interface,Next-Hop or VCD,State/Mode
(*, 234.1.1.1), 00:00:57/00:03:34, RP 1.1.1.1 , 0/0, flags: SC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
vlan20, Forward/Sparse, 00:00:09/00:03:21 C
(10.1.1.2, 234.1.1.1), 00:00:57/00:03:34 , 265/35, flags: CTA
Incoming interface: vlan10, RPF nbr 0.0.0.0
Outgoing interface list:
vlan20, Forward/Sparse, 00:00:09/00:03:21 C
Maintenance Experience20
December 2011 Issue 268 Maintenance InstancesMaintenance Instances
The Period of Multicast Messages is Abnormal⊙Zhu Xiancheng / ZTE Corporation
Abstract: Overload streams exist in the network, so the system cannot receive the
multicast stream completely and continuously. This fault is solved after overload
multicast streams are filtered through ACL.
Key words: MDU, 8905, mosaic, encoded channel, and stream
1 Network DescriptionAs shown in Figure 1, ZXR10 8905 is
a core router used to access the bearer
IPTV service. The subscriber requires
real iz ing the dual-backup f rom the
multicast source (encoder) of equipment
room A to equipment room B.● T h e m u l t i c a s t s t r e a m d a t a
sent from encoder passes through two
switches, two 8905 devices in equipment
room A, and receives equipment room B
through VLAN50 and VLAN70. ● Some encoded channels are sent
to the stream media server (MDU) through
DRM. Some unencrypted channels
are sent to MDU directly. In this case, the MDU
converts the user data stream and sends it to the
metro area network.
2 Fault SymptomThe program cannot be recorded completely
because the multicast stream received by the MDU
has package loss phenomenon. In this case, the
user monitoring has mosaic phenomenon.
3 Fault Analysis1. The engineer doubts that the bandwidth
from equipment room A to equipment room B is
insufficient. After confirmation, the engineer finds
that the bandwidth is sufficient.
Figure 1. Network Architecture of IPTV Bear Network
Maintenance Instanceswww.zte.com.cn
21Data Products
Maintenance Instances
2. When checking the port stream of ZXR10 8905 in equipment room B, the engineer finds that
the stream to the MDU is near 900 M. In this case, some packages on the port of the MDU are lost
for overload, as shown below.
3. Analyze the reason why the stream is increased. According to the requirements of design
and dual-backup, each channel received by the MDU has dual-code streams. During the
construction, the users always require to change unencrypted channels to encrypted channels.
In the end, almost all unencrypted channels are changed to encrypted channels, so the stream
is doubled. The initial planned stream is about 500 M. However, the real stream is about 1 G, so
some packages are lost for overload.
4 SolutionsTo solve this problem, it is required to filter some unencrypted channels which are changed
to encrypted channels in the interface between ZXR10 8905 and the MDU in equipment room B
through ACL, and control the stream within 600 M, as shown below.
extended acl 110
rule 1 deny ip any 10.10.204.3 0.0.0.0
rule 2 deny ip any 10.10.204.5 0.0.0.0
……
rule 100 deny ip any 10.10.204.203 0.0.0.0
rule 200 permit ip any any
ZXR10-8905B#show running-config interface gei_5/22
interface gei_5/22
ip access-group 110 out
switchport hybrid vlan 41 untag
Maintenance Experience22
December 2011 Issue 268 Maintenance InstancesMaintenance Instances
switchport hybrid vlan 50 untag
switchport hybrid vlan 70 untag
!
ZXR10-8905B#show running-config interface gei_5/23
interface gei_5/23
ip access-group 110 out
switchport hybrid vlan 41 untag
switchport hybrid vlan 50 untag
switchport hybrid vlan 70 untag
!
ZXR10-8905B#show interface gei_5/22
gei_5/22 is up, line protocol is up
The port is electric
Duplex full
Mdi type:auto
MTU 1500 bytes BW 1000000 Kbits
Last clearing of "show interface" counters 62Day(s) 0Hour(s) 7Min(s) 15Sec(s)
120 seconds input rate: 111 Bps, 1 pps
120 seconds output rate: 73089761 Bps, 53662 pps
Interface peak rate : input 456Bps, output 127499770Bps
Interface utilization: input 0%, output 58%
ZXR10-8905B#show interface gei_5/23
gei_5/23 is up, line protocol is up
The port is electric
Duplex full
Mdi type:auto
MTU 1500 bytes BW 1000000 Kbits
Last clearing of "show interface" counters 62Day(s) 0Hour(s) 7Min(s) 19Sec(s)
120 seconds input rate: 112 Bps, 1 pps
120 seconds output rate: 73089596 Bps, 53662 pps
Interface peak rate : input 446Bps, output 127495684Bps
Interface utilization: input 0%, output 58%
After filtering, the video can be recorded completely and the fault is solved.
5 Lessons LearnedDuring the construction, make records and notify some professional staff if the requirement is
changed.
During prior planning, consider the influence of requirement change. ■
Maintenance Instanceswww.zte.com.cn
23Data Products
Maintenance Instances
Interconnection Fault of Multicast Devices⊙Zhang Xing / ZTE Corporation
Abstract: The multicast service is interrupted because the length of join/prune messages
is longer than the maximum transmission unit of the device after the broken link
is reconnected.
Key words: join/prune, MTU, PIM-SM, 8905, and Register-Stop
1 Network DescriptionAs shown in Figure 1, ZXR10 8905 is connected
to the metro area network ME through PIM-SM.
After the network is connected, all services are
normal, and the subscribers connected to two MEs
can receive multicast code streams.
2 Fault SymptomPerform the active/standby redundancy test
between ZXR10 8905 and two MEs.
Figure 1. Metro Area PIM-SM Network
1. When performing the shutdown
operation for the link between ZXR10
8905-2 and ME-2, the engineer finds that
all services belonging to ME-1 and ME-2
are normal.
2. When performing the no shutdown
operation for the links between ZXR10
8905-2 and ME-2, the engineer finds that
the unicast services are normal. However,
the multicast services are interrupted.
Maintenance Experience24
December 2011 Issue 268 Maintenance InstancesMaintenance Instances
3 Fault Analysis1. When checking the multicast routing table for ZXR10 8905-2, the engineer finds that there is
no interface to ME-2, as shown below.
8905-1#show ip mroute group 239.1.1.73
(*, 239.1.1.73), 2d23h/00:03:33, RP 10.10.8.106 , 9/9, flags: S
Incoming interface: vlan600, RPF nbr 10.10.98.2
Outgoing interface list:
vlan601, Forward/Sparse, 2d16h/00:03:06
(10.10.98.21, 239.1.1.73), 00:20:54/00:03:33 , 0/0, flags: T
Incoming interface: vlan602, RPF nbr 0.0.0.0
Outgoing interface list: null
8905-2#debug ip pimsm message-recv
PIMSM message-recv debugging is on
4d16h PIMSM: Received Register-Stop message on vlan600 from 10.10.8.106,
ipLength 38
4d16h PIMSM: Received Register-Stop message for (10.10.98.20,239.1.1.14)
4d16h PIMSM: Received Register-Stop message on vlan600 from 10.10.8.106,
ipLength 38
4d16h PIMSM: Received Register-Stop message for (10.10.98.19,239.1.1.108)
4d16h PIMSM: Received Register-Stop message on vlan600 from 10.10.8.106,
ipLength 38
4d16h PIMSM: Received Register-Stop message for (10.10.98.21,239.1.1.71)
4d16h PIMSM: Received Register-Stop message on vlan600 from 10.10.8.106,
ipLength 38
4d16h PIMSM: Received Register-Stop message for (10.10.98.20,239.1.1.74)
4d16h PIMSM: Received Register-Stop message on vlan600 from 10.10.8.106,
ipLength 38
4d16h PIMSM: Received Register-Stop message for (10.10.98.19,239.1.1.58)
2. The engineer analyzes that maybe 8905-2 does not receive any join/prune messages.
When analyzing the debug information on 8905-2, the engineer confirms that 8905-2 receives
Register-Stop messages instead of join/prune messages, as shown below.
3. After analyzing the debug information on the ME-2 device, the engineer finds that the ME-2
device has sent join/prune messages, as shown below.
143 2011/04/19 14:48:13.35 WIB MINOR: DEBUG #2001 Base PIM[Instance 1 Base]
"PIM[Instance 1 Base]: Join/Prune
[091 11:21:57.950] PIM-TX ifId 35 ifName iptv-source -> 224.0.0.13 Length:
2314
Maintenance Instanceswww.zte.com.cn
25Data Products
Maintenance Instances
4. The engineer analyzes why 8905-2 does not receive join/prune messages after the ME-2
sends join/prune messages. In the ME-2 debug information, the engineer finds the following fields:
"PIM[Instance 1 Base]: Join/Prune
[091 11:21:57.950] PIM-TX ifId 35 ifName iptv-source -> 224.0.0.13 Length:
2314
This field indicates that the length of the join/prune message sent by ME-2 is 2314 bytes.
However, the length of MTU corresponding to the 8905-2 device is 1500 bytes, so the 8905-2
does not receive join/prune messages.
4 SolutionsThrough further check, the engineer finds that the MTU of the ME-2 device is set to 9212
bytes. After the MTU is set to 1500 bytes, the fault is solved.
5 Lessons LearnedThe join/prune messages packets all multicast groups to be added together. During the service
construction, the multicast channels are added step by step. The length of the join/prune message
is short, and it is less than 1500 bytes. In this case, ZXR10-8905-2 can receive join/prune
messages normally.
During the redundancy test, all channels of the ME-2 device are added together after you
perform the no shutdown operation on the port. In this case, the length of the join/prune message
is 2314 bytes, which is longer than 1500 bytes. 8905-2 cannot receive join/prune messages, there
is no interface from the multicast routing table to the ME-2 device, and the subscriber connected
to the ME device cannot receive multicast code streams. ■
PIM Version: 2 Msg Type: Join/Prune Checksum: 0x062d
Upstream Nbr IP : 10.10.98.5 Resvd: 0x0, Num Groups 115, HoldTime 210
Group: 239.1.1.116/32 Num Joined Srcs: 1, Num Pruned Srcs: 0
Join Srcs:
10.10.98.21/32 Flag S <S,G>
Group: 239.1.1.70/32 Num Joined Srcs: 1, Num Pruned Srcs: 0
Join Srcs:
10.10.98.21/32 Flag S <S,G>
Group: 239.1.1.114/32 Num Joined Srcs: 1, Num Pruned Srcs: 0
Join Srcs:
10.10.98.21/32 Flag S <S,G>
Group: 239.1.1.34/32 Num Joined Srcs: 1, Num Pruned Srcs: 0
Maintenance Experience26
December 2011 Issue 268 Maintenance InstancesMaintenance Instances
Higher CPU Usage for 8905 Multicast Fault⊙Liu Jiangdong / ZTE Corporation
Abstract: The CPU usage is too high because 8905 receives a lot of multicast messages.
The analysis results show that the DR and the query on the layer-3 interface
connected to the multicast subscribers are not on the same device.
Key words: DR, querier, IPTV, VRRP, higher CPU usage
1 Network DescriptionAs shown in Figure 1, two 8905 switches bear the IPTV services. The whole network uses the
layer-3 multicast routing technology of VRRP and PIM-SM to realize the multicast and redundancy
function.
The normal service flow is as follows: the VS8000C obtains the code stream of the multicast
channel from the multicast source, and the subscribers on the client of the multicast obtain the
multicast code stream from VS8000C through a top-set box.
Figure 1. Network Architecture of IPTV Services
Maintenance Instanceswww.zte.com.cn
27Data Products
Maintenance Instances
2 Fault SymptomWhen a fault occurs, the multicast client can view the multicast stream normally. However, the
CPU usage of the main control and the cable clip on the 8905-1 device is too high, and the CPU
alarm occurs.
8905-1#show processor
M: Master processor
S: Slave processor
PhyMem: Physical memory (megabyte)
Panel CPU(5s) CPU(1m) CPU(5m) PhyMem Buffer Memory
MP(M) 1 22% 24% 21% 1024 0% 43.155%
MP(S) 2 10% 8% 8% 1024 0% 41.754%
NP(M) 1 26% 23% 21% 1024 0% 27.157%
NP(M) 2 10% 10% 10% 1024 0% 27.160%
NP(M) 3 10% 9% 8% 1024 0% 27.118%
08:40:44 06/02/2011 UTC alarm 29440 occurred %MUX% the CPU port COS0 enters
hold state sent by NPC 1
08:40:54 06/02/2011 UTC alarm 29440 occurred %MUX% the CPU port COS0 enters
hold state sent by NPC 1
08:41:04 06/02/2011 UTC alarm 29440 occurred %MUX% the CPU port COS0 enters
hold state sent by NPC 1
3 Fault Analysis1. Generally, the higher CPU usage results from a lot of unknown messages. COS0 shows that
the device receives a lot of unknown messages. Check these messages on the 8905-1 device by
capturing CPU.
8905-1(config)#capture npc 1 readspeed 10
vty2(172.16.101.201) has entered the configure mode, must avoid conflict.
start capture npc 1
8905-1(config)#
IP Packet on NPC: 1
ProType DST_IP SRC_IP ovid ivid TTL PRO SRCPN DSTPN DIR Port
(null) 235.0.0.8 172.16.6.20 4000 NULL 63 17 12418 8246 RX 13
(null) 235.0.0.3 172.16.6.21 4000 NULL 63 17 12406 8216 RX 13
(null) 235.0.0.8 172.16.6.20 4000 NULL 63 17 12418 8246 RX 13
(null) 235.0.0.3 172.16.6.21 4000 NULL 63 17 12406 8216 RX 13
(null) 235.0.0.8 172.16.6.20 4000 NULL 63 17 12418 8246 RX 13
(null) 235.0.0.3 172.16.6.21 4000 NULL 63 17 12406 8216 RX 13
(null) 235.0.0.8 172.16.6.20 4000 NULL 63 17 12418 8246 RX 13
(null) 235.0.0.3 172.16.6.21 4000 NULL 63 17 12406 8216 RX 13
(null) 235.0.0.8 172.16.6.20 4000 NULL 63 17 12418 8246 RX 13
(null) 235.0.0.3 172.16.6.21 4000 NULL 63 17 12406 8216 RX 13
Maintenance Experience28
December 2011 Issue 268 Maintenance InstancesMaintenance Instances
The package capture results show that the 1/13 interface (connecting to 3928) of 8905-1
receives a lot of multicast messages. The message sent from 8905-2 is sent to 8905-1 through
3928, so the CPU usage of 8905-1 is increased greatly. Why does 3928 send the multicast
messages from 8905-2 to 8905-1?
2. Check the multicast forwarding table on 3928.
3928#show ip igmp snooping mr-port-info
Index VLAN Port State RemainTime Version
----------------------------------------------------
1 4000 fei_1/24 Dynamic 252 V2SpecialQuery
2 4000 fei_1/23 Dynamic 250 V2SpecialQuery
The results show that two uplink ports on 3928 are forwarding ports of the multicast. In this
case, the stream will be forwarded to 8905-1.
After receiving a normal multicast query message, 3928 will establish a multicast forwarding
table. In this case, we need to know the multicast querier. After a router enables the multicast
service, it is considered as a querier, and it sends normal query messages. After receiving query
messages from the source with smaller IP addresses, the querier stops sending query messages,
and it becomes a non-querier.
The 3928 switch is configured with a management IP address, which is in the network segment
of that of two 8905 switches, and is bigger than the IP address of these two 8905 switches. In this
case, 8905-1 and 8905-2 consider themselves as a querier. 3928 enables the multicast agent
function by default, and it cannot forward the multicast query messages. After two 8905 switches
send query messages to 3928, two routing forwarding tables are established, so the multicast
stream is sent to 8905-1.
3. Change the multicast agent mode of 3928 to transparent mode. After the modification, 3928
transmits query messages transparently. The IP address of 8905-1 is smaller than that of 8905-2,
so 8905-1 is the querier. When you run the show ip igmp interface vlan 4000 command, you can
find that there is only one querier.
However, the multicast is abnormal, and the client cannot view the multicast now.
4. Further analyze the reason. To view the multicast normally, after the client sends a multicast
adding request, the DR must give a response to the request, report the request to RP, and then
transmit the multicast stream to the client through DR.
In a shared network, if there is no DR, each router can send graft or pruning messages to
the upstream. This is not reasonable. The PIM Hello message includes a priority. When a router
receives a PIM Hello message, it will compare the priority. The device with a higher priority will be
the DR. If the priority level is the same, the device with a bigger IP address will be the DR.
In this case, the 8905-1 device will be the querier because its IP address is smaller, and the
8905-2 device will be DR because its IP address is bigger. If there is no agent, the client can view
the multicast only when the DR and the querier are on the same device.
4 SolutionsAfter the multicast transferring mode of the 3928 device to the transparent mode, two 8905
Maintenance Instanceswww.zte.com.cn
29Data Products
Maintenance Instances
8905-2#show ip igmp int vlan 4000
vlan4000
Internet address is 172.16.101.2, subnet mask is 255.255.255.0
IGMP is enabled on interface
Current IGMP version is 2
IGMP query interval is 125 second(s)
IGMP last member query interval is 1 second(s)
IGMP query max response time is 10 second(s)
IGMP querier timeout period is 251 second(s)
IGMP querier is 172.16.101.2, never expire
Inbound IGMP access group is not set
IGMP immediate leave control is not set
8905-2#show ip pimsm int vlan 4000
Address Interface State Nbr Query DR DR
Count Intvl Priority
172.16.101.2 vlan4000 Up 1 30 172.16.101.2 2
8905-1#show ip igmp int vlan 4000
vlan4000
Internet address is 172.16.101.3, subnet mask is 255.255.255.0
IGMP is enabled on interface
Current IGMP version is 2
IGMP query interval is 125 second(s)
IGMP last member query interval is 1 second(s)
IGMP query max response time is 10 second(s)
IGMP querier timeout period is 251 second(s)
IGMP querier is 172.16.101.2, expire timer: 00:02:20
Inbound IGMP access group is not set
IGMP immediate leave control is not set
8905-1#show ip pimsm int vlan 4000
Address Interface State Nbr Query DR DR
Count Intvl Priority
172.16.101.3 vlan4000 Up 1 30 172.16.101.2 1
3928#show ip igmp snooping mr-port-info
Index VLAN Port State RemainTime Version
--------------------------------------------------------------------------
1 4000 fei_1/24 Dynamic 230 V2SpecialQuery
switches can set the device with smaller IP addresses as the querier. No command can be used to
modify the querier. Run the ip pim dr-priority 2 command on the layer-3 interface to set the DR
priority of the 8905-1 device to 2. The DR priority of ZTE is set to 1 by default.
After modification, query the multicast forwarding table for the querier, DR, and the 3928 switch
on 8905.
Maintenance Experience30
December 2011 Issue 268 Maintenance InstancesMaintenance Instances
Relocation Configuration of BAS Defaulting Subscribers⊙Li Lei / ZTE Corporation
Abstract: This section describes how to configure the relocation function for defaulting
subscribers on 10800E.
Key words: 10800E, PPPoE, RADIUS, defaulting, relocation
1 Function DescriptionThe RADIUS authentication is used
for the user online. For a defaulting
subscriber, the RADIUS Server will apply
for the RADIUS attribute authentication
which indicates that this is a defaulting
subscriber. When the defaulting subscriber
accesses any webpage, the system will
relocate the HTTP request to a specific
defaulting page.
The relocated URL of the subscriber
defaul t ing page also can be added to the
successful RADIUS authentication package,
or you can configure the relocated URL in the
user template locally. The fixed defaulting server
provides the user relocation page.
After successful authentication, the defaulting
subscribers will be relocated to the defaulting
page when they access a network. In addition, the
defaulting subscribers are not allowed to access
other networks.
After that, the multicast services are
normal, and the CPU usage of two 8905
devices is normal. The fault is solved.
5 Lessons LearnedTo view the multicast in this type of
networking mode, the following conditions
must be met:
1. For the layer-3 interface that
connects two 8905 devices to the multicast source,
the querier and DR have no requirements.
2. For the layer-3 interface connected to
VS8000C, ensure that DR must be connected to
the device that connects to the main MDU board of
VS8000C. There is no requirement on the querier.
3. For the layer-3 interface connected to the client
of the multicast, if there is no agent, ensure that the
querier and the DR are on the same device. ■
Maintenance Instanceswww.zte.com.cn
31Data Products
Maintenance Instances
2 Configuration CommandsThis function only adds the URL relocation command in the user template, and the defaulting
label auth-action is issued from RADIUS.
BRAS(config-bras)#domain 1997
BRAS(config-domain-1997)#subscriber-template
BRAS(config-domain-subtmp)#redirect-url <URL>
WORD URL (1-63 character(s))
3 Configuration InstanceUse the specia acl configuration, and apply it to the corresponding vbui interface.
10800E(config)#acl extended number ?
<100-199> Configure extended ACL number
<1500-1999> Configure extended ACL number (expanded range)
<25001-25500> Set extended security ACL number
10800E (config)#acl extended number 1500
acl extended number 1500
rule 1 permit ip any 202.102.224.68 0.0.0.0
rule 2 permit ip any 202.102.227.68 0.0.0.0
rule 3 permit ip any 218.100.0.252 0.0.0.0
/* A defaulting subscriber can access DNS. This is a forced defaulting
service.*/
interface vbui120
ip address 218.28.94.17 255.255.255.252
out_index 38
access-list 100
special-acl 1500
/* Configure ACL. If ACL is not configured, the default subscriber cannot access
any website.*/
ip proxy-arp none
dhcp idle period 300 traffic 0
dns primary 202.102.224.68
dns secondary 202.102.227.68
dhcp trust-option82
web authentication subscriber none
ip pool 4 test 218.28.94.18 218.28.94.18 ppp
!
/* Note: Bind the access control list to the vbui interface. If the ACL is
modified,delete special-acl 1500 and then bind the interface. That is to say,
it cannot be sent dynamically.
*/
Maintenance Experience32
December 2011 Issue 268 Maintenance InstancesMaintenance Instances
domain 1
accounting-group 1
accounting-type radius
authentication-group 1
authentication-type radius
lns-load-share none
max-subscriber 32000
user-max-session 100000
ppp web-force timer 5 count 0
service-type framed
alias dial
subscriber-template
ip address vrf
redirect-url http://www.kuandai.net.cn/pause.html
$
$
/*Note 2: Configure the defaulting relocation function in the domain. Before
redirect-url http://www.kuandai.net.cn/pause.html is configured, you need to
configure special-acl 1500 for the vbui interface. Otherwise, the defaulting
subscriber cannot access any website.*/
4 Lessons Learned1. Only the PPPoE subscriber is
supported. The V2.08.22.B50 version or
latter of 10800E can support the relocation
func t i on o f t he PPPoE de fau l t i ng
subscriber.
2. The priority of the relocation URL
issued by RADIUS is higher than that of relocation
URL configured in the local user template. When
the relocation URL issued by RADIUS is null or it
is not issued, the relocation URL configured in the
local user template takes effect.
3. You can access the defaulting page forcedly
for many times. ■
Maintenance Instanceswww.zte.com.cn
33Data Products
Maintenance Instances
DHCP Client Fails to Obtain IP Addresses⊙Kou Gaocan / ZTE Corporation
Abstract: This section details the dynamic host configuration protocol, and describes how
to handle this fault when the DHCP client fails to obtain IP addresses.
Key words: DHCP, fault handling, flow chart, address pool, lease
1 DHCP OverviewThe Dynamic Host Configuration Protocol
(DHCP) uses the client/ server communication
mode.
1. The client sends message configuration
request messages, including the allocated IP
address, the sub-net mask, and the default
gateway.
2. The server returns the corresponding
message configuration so as to allocate information
dynamically, such as IP address.
3. Both the request message and the response
message are encapsulated through the UDP.
The DHCP client obtains the IP address
dynamically from the DHCP server through four
steps, as shown in Figure 1.
1. Discover phase. In this phase, the DHCP
client finds the DHCP server. The client sends
DHCP-DISCOVER messages in broadcast mode. Figure 1. DHCP Interconnection Flow
Maintenance Experience34
December 2011 Issue 268 Maintenance InstancesMaintenance Instances
2. Offer phase. In this phase, the
DHCP server provides an IP address. After
receiving DHCP-DISCOVER messages
from the client, the DHCP server selects
an IP address according to the priority
allocated by the IP address, and then
sends it to the client together with other
parameters through DHCP-DISCOVER
messages.
3. Request phase. In this phase, the
DHCP client selects an IP address. If more
DHCP servers send DHCP-DISCOVER
messages to this client, the client only
rece ives the f i rs t rece ived DHCP-
DISCOVER message, and then sends the
DHCP-REQUEST message in broadcast
mode. This message includes the IP
address allocated by the DHCP server in
Figure 2. DHCP Network Architecture
the DHCP-OFFER message.
4. Acknowledge phase. In this phase, the
DHCP server acknowledges the IP address. After
the DHCP server receives the DHCP-REQUEST
message from the DHCP client, the servers
selected by the client will perform the following
operations. If this address needs to be allocated
to the client, the corresponding DHCP server will
return the DHCP-ACK message. Otherwise, it will
return the DHCP-NAK message, which indicates
that this IP address cannot be allocated to the
client.
2 Fault SymptomAs shown in Figure 2, the DHCP client cannot
obtain the IP address from the DHCP server in
DHCP mode.
Maintenance Instanceswww.zte.com.cn
35Data Products
Maintenance Instances
3 Fault Handling FlowThe DHCP client fails to obtain the IP address
from the DHCP server through the DHCP mode.
The flow is shown in Figure 3.
4 Fault Handling Steps1 . Check whe the r the phys ica l
connection is normal.
Figure 3. DHCP Fault Handling Flow
Maintenance Experience36
December 2011 Issue 268 Maintenance InstancesMaintenance Instances
As shown in Figure 2, the DHCP server
is connected to the DHCP client through
an interface. Configure the IP address for
the network card connected to the server
on the client. The IP address and the IP
address of the interworking interface of the
server are in the same network segment.
If the IP address for the interworking
interface of the server can be pinged
successfully, it means that the physical
connection is normal.
You can a lso enab le the DHCP
debugging switch on the DHCP server
to check whether the DHCP-DISCOVER
message can be received from the DHCP
client.
2. Check whether the DHCP server is
enabled.
Log in to the device and then check
whether the DHCP server is enabled. If
not, run the ip dhcp enable command to
enable the DHCP server.
3. Check the address pool configuration of the
DHCP server
Run the show ip local pool [<pool-name>]
command to check the configuration of the address
pool, whether the address pool whose network
segment is the same as the IP address of the
received message is configured, or whether the
address pool that contains the IP address of the
received message is configured.
4. Check whether the network segment
configuration of the DHCP server is correct
If the DHCP client requests a unicast response
from the DHCP server, the configured address pool
and the IP of a received interface should be in the
same network segment. Otherwise, the message
will fail to be responded to.
5. Check whether available IP addresses exist
in the address pool
Run the show ip dhcp server user <interface>
command to check the user list of the current
online subscriber corresponding to the DHCP
Server, so as to confirm whether the DHCP server
has allocable addresses. ■