Preface

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

Maintenance Experience
Bimonthly for Data Products No. 18 Issue 268, December 2011

Maintenance Experience Editorial Committee

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

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: doc@ zte.com.cn. Thank you for making ZTE a part of your telecom experience!

Maintenance Experience Newsroom

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: doc@zte.com.cn Technical Cupport Website: http://ensupport. zte.com.cn

Maintenance Experience Editorial Committee ZTE Corporation December, 2011

Contents

Technical Specials
Multicast Overview.......................................................................................................................................2

Maintenance Instances
Period of Multicast Message is Abnormal....................................................................................................7 Multicast IPTV Is Interrupted........................................................................................................................11 Multicast Stream Fails to be Received.........................................................................................................16 The Period of Multicast Messages is Abnormal...........................................................................................20 Interconnection Fault of Multicast Devices...................................................................................................23 Higher CPU Usage for 8905 Multicast Fault................................................................................................26 Relocation Configuration of BAS Defaulting Subscribers. ...........................................................................30 DHCP Client Fails to Obtain IP Addresses...................................................................................................33

December 2011

Issue 268

Technical 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 Overview
Multicast 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, distance learning, and software 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.

research and management.

3 Multicast Tree
In 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 treebased 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.

2 Multicast Address
In a multicast network, the sender, called the multicast 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

Maintenance Experience

www.zte.com.cn

Each router can find a shortest 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 multicast 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.

between the routers, as shown in Figure 1.

4.1 IGMP
4.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.

4 Multicast Protocol
The multicast protocol is classified into the group member relationship protocol between hosts and routers, and the multicast routing protocol

Figure 1. Multicast Protocol

Data Products

December 2011

Issue 268

Technical Specials

The IGMP uses two types of messages, including group member query message and group member report message.

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:

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 report message, which reports the belonging multicast group.

IGMPv1 (RFC 1112) defines the basic Based on IGMPv1, the deletion mechanism IGMPv3 (RFC 3376) is added with the

group member query and report.

is added in IGMPv2 (RFC 2236).

When a host is added to a new

multicast source selection function so as to support the SSM model.

group, it sends a member report message immediately. In this case, the first member can receive multicast data immediately.

4.1.2 IGMP Configuration

IGMP configuration includes version 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 required. The IGMP version 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.

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.
Table 1. Configure the IGMP Group on the Interface Step 1 Command

Function

ZXR10(config-igmp-if)#access- Configures the group used to add IGMP. The IGMP can be added group <access-list-number> to all groups by default. Configures the static group members for the IGMP interface. ZXR10(config-igmp-if)#static<group-address> refers to the address of the static group where group <group-address> the IGMP is added. ZXR10(config-igmpif)#immediate-leave [group-list Configures the group that allows members to leave immediately. <access-list-number>]

Maintenance Experience

www.zte.com.cn

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: <query-interval><robustnesscount>+<query-max-response-time> /2 Unit: s <robustness-count> refers to the robustness coefficient of a query.

4.2 Multicast Routing Protocols

The 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 1 Command ZXR10(config-igmpif)#query-interval <seconds> Function Configures the query interval for the IGMP protocol. The default value is 125 seconds.

ZXR10(config-igmpConfigures the max response time carried by the query message sent if)#query-max-response- by the IGMP protocol. This function is valid for only V2 and V3. The time <seconds> default value is 10s. ZXR10(config-igmpif)#querier-timeout <seconds> Configures the timeout time for the IGMP querier.

ZXR10(config-igmpConfigures the query interval for an IGMP special group. This function if)#last-member-queryis valid only for V2. The default value is 1s. interval <seconds> ZXR10(config-igmpif)#robusrness-count <times> ZXR10(config-igmpif)#shaping-packetsnumber <number> Configures the robusrness coefficient for the IGMP querier that is the number of times that a message is sent. Range: 2-7. Limits the number of sent messages. <number> refers to the number of sent messages. Range: 1-maximum available number.

Data Products

December 2011

Issue 268

Technical 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:

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.

Distance Vector Multicast Routing Multicast Open Shortest Path First

Protocol (DVMRP)

(MOSPF)

Maintenance Experience

www.zte.com.cn

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 Description
As 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

Configure the IGMP SNOOPING function on ZXR10 5116:

set igmp snooping enable set igmp snooping add vlan 3999

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

Data Products

December 2011

Issue 268

Maintenance Instances

2 Fault Symptom
The 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 Analysis
1. 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 1 2 3 VLAN 3999 3999 3999 Port State RemainTime 227 220 214

-------------------------------------------------gei_2/35 gei_2/38 Dynamic Dynamic Dynamic

smartgroup17

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 Num 1 2 VlanId PortId 3999 3999 T1 T3 Expiry 177

Last IGMP_QUERY_ROUTER's ip is 10.40.92.106 ---- ------ ------- ---------176

5116(cfg)#show igmp snooping vlan 3999 router Num 1 2 VlanId PortId 3999 3999 T1 T3 Expiry 156 155

Last IGMP_QUERY_ROUTER's ip is 10.40.92.106 ---- ------ ------- ----------

5116(cfg)#show igmp snooping vlan 3999 router

Last IGMP_QUERY_ROUTER's ip is 10.40.92.106

Maintenance Experience

www.zte.com.cn

Num 1 2

---- ------ ------- ---------3999 3999 T1 T3 2554 2554

VlanId PortId

Expiry

5116(cfg)#show igmp snooping vlan 3999 router

The above information indicates that:

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).

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

Data Products

December 2011

Issue 268

Maintenance Instances

The second Query message sent by ZXR10 8905 is looped back immediately, so it is in another limited 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 function 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 Learned
Pay attention to the principle of the protocol, and confirm the reason why the Query message is limited.

10

Maintenance Experience

www.zte.com.cn

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 Description
Figure 1 shows the IPTV networking application.

The IGMP Snooping, and IGMP

Proxy functions are enabled on T160G-2, and T64G-1. The layer-3 interface 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.

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.

2 Fault Symptom
The top-set box cannot receive any channels even if it is restarted.

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

Data Products

11

December 2011

Issue 268

Maintenance Instances

3 Fault Analysis
1. 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 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:
T160G-2#show ip igmp snooping Totol group num 1,has host group num 1 S = Static; D = Dynamic. Index VLAN LiveTime 1 411 Group ID Ports 233.233.201.104 gei_5/1/D,

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.

-------------------------------------0:00:03:09

12

Maintenance Experience

www.zte.com.cn

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 e n s u r e t h a t t h i s m u l t i c a s t s t r e a m i s 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 topset 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 . Afte r re ce i vi n g g e n e ra l q u e ry 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

Data Products

13

December 2011

Issue 268

Maintenance Instances

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.
T160G-2#show ip igmp snooping mr-port-info Index 1 2 VLAN 412 411 Port gei_4/1 gei_2/1 State Dynamic Static RemainTime 160 65535 /*The mroute interface learnt dynamically*/ /*The mroute interface specified statically*/

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

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.
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

14

Maintenance Experience

www.zte.com.cn

/*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.
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 Inbound IGMP access group is not set IGMP immediate leave control is not set /*Address of T160G-1*/

4 Solutions
This fault is solved after the gei_7/10 port is deleted from VLAN411.

5 Lessons Learned
During the investigation of multicast faults, it is very important to know the protocol and the correction configuration.

Data Products

15

December 2011

Issue 268

Maintenance 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 Symptom
As shown in Figure 1, ZXR10 5252, R1, and SW layer-3 switch are enabled with the layer-3 multicast function.

2 Fault Analysis
1. 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 !

Figure 1 Multicast Network

As shown in Figure 2, when performing the multicast test on ZXR10 5252, the engineer finds that the connected PC cannot receive multicast streams.

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

Figure 2 Multicast Network Test

16

Maintenance Experience

www.zte.com.cn

2. Check the multicast count of the port:

ZXR10#show interface gei_1/1 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 370360 Bps, 5 Bps, 4 Bps output Bytes 0% : 6666492 272 pps 0 pps Last clearing of "show interface" counters 0Day(s) 0Hour(s) 0Min(s) 22Sec(s) 20 seconds input rate : 20 seconds output rate: Interface peak rate input Input: Packets Unicasts Broadcasts Oversize Dropped Jabber Output: Packets Unicasts Broadcasts Total: 64B 128-255B : 0 : 0 65-127B 256-511B : 10 : 0 : 1 : 0 : 0 Bytes : 96 Multicasts: 1 Collision : 0 : 4903 : 0 : 9 : 0 : 0 : 0 Multicasts: 4894 Undersize : 0 CRC-ERROR : 0 Fragments : 0 MacRxErr : 0 : 333324 Bps, output 2%, /*This interface is used to connect to a

Interface utilization: input

LateCollision: 0

512-1023B : 0 ZXR10#show inter gei_1/2 receiving PC*/

1024-2047B: 4894 /*This interface is used to connect to a multicast

Data Products

17

December 2011

Issue 268

Maintenance Instances

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 2055 Bps, 0 Bps, 27 Bps output Bytes 0% : 84132 31 pps 0 pps Last clearing of "show interface" counters 0Day(s) 0Hour(s) 0Min(s) 44Sec(s) 20 seconds input rate : 20 seconds output rate: Interface peak rate input Input: Packets Unicasts Broadcasts Oversize Dropped Jabber Output: Packets Unicasts Broadcasts Total: 64B 128-255B : 9 : 2 65-127B 256-511B : 1268 : 0 : 4 : 0 : 0 Bytes : 558 Multicasts: 4 Collision : 0 : 1275 : 1266 : 7 : 0 : 0 : 0 Multicasts: 2 Undersize : 0 CRC-ERROR : 0 Fragments : 0 MacRxErr : 0 : 2151 Bps, output 0%,

Interface utilization: input

LateCollision: 0

512-1023B : 0

1024-2047B: 0

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:
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

18

Maintenance Experience

www.zte.com.cn

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

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 Solutions
The PC can receive multicast stream normally after the TTL is set to 5.

Data Products

19

December 2011

Issue 268

Maintenance Instances

Zhu Xiancheng / ZTE Corporation

The Period of Multicast Messages is Abnormal

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 Description
As shown in Figure 1, ZXR10 8905 is a core router used to access the bearer IPTV service. The subscriber requires realizing the dual-backup from the multicast source (encoder) of equipment room A to equipment room B.

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 Symptom
The 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.

The multicast stream data

sent from encoder passes through two switches, two 8905 devices in equipment room A, and receives equipment room B through VLAN50 and VLAN70.

3 Fault Analysis
1. 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.

Some encoded channels are sent

to the stream media server (MDU) through DRM. Some unencrypted channels

Figure 1. Network Architecture of IPTV Bear Network

20

Maintenance Experience

www.zte.com.cn

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 Solutions
To 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

Data Products

21

December 2011

Issue 268

Maintenance 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, Duplex full Mdi type:auto MTU 1500 bytes BW 1000000 Kbits rate: : input 0%, 111 Bps, 73089761 Bps, 456Bps, output output 58% 1 pps 53662 pps 127499770Bps Last clearing of "show interface" counters 62Day(s) 0Hour(s) 7Min(s) 15Sec(s) 120 seconds input Interface peak rate 120 seconds output rate: Interface utilization: input ZXR10-8905B#show interface gei_5/23 gei_5/23 is up, Duplex full Mdi type:auto MTU 1500 bytes BW 1000000 Kbits rate: : input 0%, 112 Bps, 73089596 Bps, 446Bps, output output 58% 1 pps 53662 pps 127495684Bps Last clearing of "show interface" counters 62Day(s) 0Hour(s) 7Min(s) 19Sec(s) 120 seconds input Interface peak rate 120 seconds output rate: Interface utilization: input line protocol is up The port is electric line protocol is up The port is electric

After filtering, the video can be recorded completely and the fault is solved.

5 Lessons Learned
During the construction, make records and notify some professional staff if the requirement is changed. During prior planning, consider the influence of requirement change.

22

Maintenance Experience

www.zte.com.cn

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 Description
As 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.

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.

2 Fault Symptom
Perform the active/standby redundancy test between ZXR10 8905 and two MEs.

Figure 1. Metro Area PIM-SM Network

Data Products

23

December 2011

Issue 268

Maintenance Instances

3 Fault Analysis
1. 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

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.
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)

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 2314 -> 224.0.0.13 Length:

24

Maintenance Experience

www.zte.com.cn

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

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 2314 -> 224.0.0.13 Length:

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 Solutions
Through 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 Learned
The 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.

Data Products

25

December 2011

Issue 268

Maintenance Instances

Liu Jiangdong / ZTE Corporation

Higher CPU Usage for 8905 Multicast Fault

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 Description
As 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

26

Maintenance Experience

www.zte.com.cn

2 Fault Symptom
When 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 Panel 1 2 1 2 3

PhyMem: Physical memory (megabyte) MP(M) MP(S) NP(M) NP(M) NP(M) 22% 10% 26% 10% 10% 24% 8% 23% 10% 9% 21% 8% 21% 10% 8%

CPU(5s) CPU(1m) CPU(5m)

PhyMem 1024 1024 1024 1024 1024

Buffer 0% 0% 0% 0% 0%

Memory

43.155% 41.754% 27.157% 27.160% 27.118%

08:40:44 06/02/2011 UTC alarm 29440 occurred %MUX% hold state sent by NPC 1 hold state sent by NPC 1 hold state sent by NPC 1 08:40:54 06/02/2011 UTC alarm 29440 occurred %MUX% 08:41:04 06/02/2011 UTC alarm 29440 occurred %MUX%

the CPU port COS0 enters the CPU port COS0 enters the CPU port COS0 enters

3 Fault Analysis
1. 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 start capture npc 1 8905-1(config)# ProType DST_IP (null) (null) (null) (null) (null) (null) (null) (null) (null) (null) IP Packet on NPC: 1 235.0.0.8 235.0.0.3 235.0.0.8 235.0.0.3 235.0.0.8 235.0.0.3 235.0.0.8 235.0.0.3 235.0.0.8 235.0.0.3

vty2(172.16.101.201) has entered the configure mode, must avoid conflict.

SRC_IP

172.16.6.20 172.16.6.21 172.16.6.20 172.16.6.21 172.16.6.20 172.16.6.21 172.16.6.20 172.16.6.21 172.16.6.20 172.16.6.21

ovid ivid TTL PRO SRCPN DSTPN DIR 4000 NULL 63 4000 NULL 63 4000 NULL 63 4000 NULL 63 4000 NULL 63 4000 NULL 63 4000 NULL 63 4000 NULL 63 4000 NULL 63 4000 NULL 63 17 17 17 17 17 17 17 17 17 17 12418 8246 12406 8216 12418 8246 12406 8216 12418 8246 12406 8216 12418 8246 12406 8216 12418 8246 12406 8216 RX RX RX RX RX RX RX RX RX RX

Port 13 13 13 13 13 13 13 13 13 13

Data Products

27

December 2011

Issue 268

Maintenance 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 1 2 VLAN Port State

---------------------------------------------------4000 4000 fei_1/24 fei_1/23 Dynamic Dynamic 252 250 V2SpecialQuery V2SpecialQuery

RemainTime Version

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 Solutions
After the multicast transferring mode of the 3928 device to the transparent mode, two 8905

28

Maintenance Experience

www.zte.com.cn

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.
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 8905-2#show ip pimsm int vlan 4000 Address Interface vlan4000 IGMP immediate leave control is not set State Nbr Up 1 Query DR 30 172.16.101.2 DR 2

172.16.101.2

Count Intvl

Priority

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) Inbound IGMP access group is not set

IGMP querier is 172.16.101.2, expire timer: 00:02:20 IGMP immediate leave control is not set 8905-1#show ip pimsm int vlan 4000 Address Interface vlan4000

State Nbr Up 1

172.16.101.3

Count Intvl 30

Query DR 172.16.101.2

DR 1

Priority

3928#show ip igmp snooping mr-port-info Index 1 VLAN Port State

-------------------------------------------------------------------------4000 fei_1/24 Dynamic 230 V2SpecialQuery

RemainTime

Version

Data Products

29

December 2011

Issue 268

Maintenance Instances

After that, the multicast services are normal, and the CPU usage of two 8905 devices is normal. The fault is solved.

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.

5 Lessons Learned
To view the multicast in this type of networking mode, the following conditions must be met: 1 . Fo r th e l a y e r - 3 i nterface that

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 Description
The 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 defaulting 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.

30

Maintenance Experience

www.zte.com.cn

2 Configuration Commands
This 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 Instance
Use the specia acl configuration, and apply it to the corresponding vbui interface.
10800E(config)#acl extended number ? <100-199> <1500-1999> <25001-25500> Configure extended ACL number Configure extended ACL number (expanded range) 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. */

Data Products

31

December 2011

Issue 268

Maintenance 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 configure special-acl 1500 for the vbui interface. Otherwise, the defaulting subscriber cannot access any website.*/ redirect-url http://www.kuandai.net.cn/pause.html is configured, you need to

4 Lessons Learned
1. Only the PPPoE subscriber is supported. The V2.08.22.B50 version or latter of 10800E can support the relocation function of the PPPoE defaulting 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.

32

Maintenance Experience

www.zte.com.cn

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 Overview
The 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

Data Products

33

December 2011

Issue 268

Maintenance 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 receives the first received DHCPDISCOVER message, and then sends the DHCP-REQUEST message in broadcast mode. This message includes the IP address allocated by the DHCP server in

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 Symptom
As shown in Figure 2, the DHCP client cannot obtain the IP address from the DHCP server in DHCP mode.

Figure 2. DHCP Network Architecture

34

Maintenance Experience

www.zte.com.cn

3 Fault Handling Flow

The 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 Steps

1. Check whether the physical connection is normal.

Figure 3. DHCP Fault Handling Flow

Data Products

35

December 2011

Issue 268

Maintenance 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. Yo u c a n a l s o e n a b l e t h e D H C P 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.

36

Maintenance Experience