Maintenance Experience%2c Issue268(Data Products)_399285

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



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.


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.



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


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


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




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

1 3999 T1 156

2 3999 T3 155



Maintenance Instanceswww.zte.com.cn

9Data Products



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

1 3999 T1 2554

2 3999 T3 2554


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



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


11Data Products


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.



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:


13Data Products


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



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.


15Data Products


T160G-1#show ip igmp interface vlan411

vlan411




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



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



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


17Data Products


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:



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:



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:


Description is none


Duplex full

Mdi type:auto



20 seconds input rate : 2055 Bps, 31 pps


Interface peak rate :

input 2151 Bps, output 27 Bps


Input:



Broadcasts : 7 Undersize : 0

Oversize : 0 CRC-ERROR : 0

Dropped : 0 Fragments : 0

Jabber : 0 MacRxErr : 0

Output:



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


19Data Products


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


vlan20, Forward/Sparse, 00:00:09/00:03:21 C



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


21Data Products


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





!

ZXR10-8905B#show running-config interface gei_5/23

interface gei_5/23

ip access-group 110 out




!

ZXR10-8905B#show interface gei_5/22



Duplex full

Mdi type:auto



120 seconds input rate: 111 Bps, 1 pps


Interface peak rate : input 456Bps, output 127499770Bps


ZXR10-8905B#show interface gei_5/23



Duplex full

Mdi type:auto



120 seconds input rate: 112 Bps, 1 pps


Interface peak rate : input 446Bps, output 127495684Bps


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


23Data Products


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.



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



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


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)


ipLength 38



ipLength 38



ipLength 38



ipLength 38


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


25Data Products


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>


Join Srcs:

10.10.98.21/32 Flag S <S,G>


Join Srcs:

10.10.98.21/32 Flag S <S,G>




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


27Data Products


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





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



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.


Index VLAN Port State RemainTime Version

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

1 4000 fei_1/24 Dynamic 252 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


29Data Products


8905-2#show ip igmp int vlan 4000

vlan4000




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



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




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



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


Index VLAN Port State RemainTime Version

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


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.



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


31Data Products


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



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

*/



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


33Data Products


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



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.


35Data Products


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



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

Documents

Maintenance Experience%2c Issue268(Data Products)_399285