Troubleshooting - User Access: HUAWEI NE40E/NE80E Router V600R005C00

HUAWEI NE40E/NE80E Router
V600R005C00
Troubleshooting - User Access

Issue
03
Date
2013-08-15
HUAWEI TECHNOLOGIES CO., LTD.
Copyright Huawei Technologies Co., Ltd. 2013. All rights reserved.

No part of this document may be reproduced or transmitted in any form or by any means without prior written
consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions

and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and the
customer. All or part of the products, services and features described in this document may not be within the
purchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information,
and recommendations in this document are provided "AS IS" without warranties, guarantees or representations
of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute a warranty of any kind, express or implied.
Huawei Technologies Co., Ltd.

Address:
Huawei Industrial Base

Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website:
http://www.huawei.com
Email:
support@huawei.com
Issue 03 (2013-08-15)
Huawei Proprietary and Confidential

Copyright Huawei Technologies Co., Ltd.

About This Document
About This Document

Purpose
NOTE
l This document takes interface numbers and link types of the NE40E-X8 as an example. In working
situations, the actual interface numbers and link types may be different from those used in this
document.
l On NE80E/40E series excluding NE80E/40E-X1 and NE80E/40E-X2, line processing boards are
called Line Processing Units (LPUs) and switching fabric boards are called Switching Fabric Units
(SFUs). On the NE80E/40E-X1 and NE80E/40E-X2, there are no LPUs and SFUs, and NPUs
implement the same functions of LPUs and SFUs to exchange and forward packets.
This document describes the troubleshooting of user access, including information collection
methods, common processing flows, common troubleshooting methods, and troubleshooting
cases.
CAUTION
Note the following precautions:
l Currently, the device supports the AES and SHA2 encryption algorithms. AES is reversible,
while SHA2 is irreversible. A protocol interworking password must be reversible, and a local
administrator password must be irreversible.
l If the plain parameter is specified, the password will be saved in plaintext in the configuration
file, which has a high security risk. Therefore, specifying the cipher parameter is
recommended. To further improve device security, periodically change the password.
l Do not set both the start and end characters of a password to "%$%$." This causes the
password to be displayed directly in the configuration file.
Related Versions
The following table lists the product versions related to this document.
Issue 03 (2013-08-15)
Product Name
Version
HUAWEI NetEngine80E/40E
Router
V600R005C00

ii

About This Document
Intended Audience
This document is intended for:
l
Installation and commissioning engineer
NM configuration engineer
Technical support engineer
Symbol Conventions
The symbols that may be found in this document are defined as follows.
Symbol
Description
DANGER
WARNING
CAUTION
DANGER indicates a hazard with a high level or medium

level of risk which, if not avoided, could result in death or
serious injury.
WARNING indicates a hazard with a low level of risk which,
if not avoided, could result in minor or moderate injury.
CAUTION indicates a potentially hazardous situation that,
if not avoided, could result in equipment damage, data loss,
performance deterioration, or unanticipated results.
TIP
TIP indicates a tip that may help you solve a problem or save
time.
NOTE
NOTE provides additional information to emphasize or

supplement important points of the main text.
Command Conventions
The command conventions that may be found in this document are defined as follows.
Issue 03 (2013-08-15)
Convention
Description
Boldface
The keywords of a command line are in boldface.
Italic
Command arguments are in italics.
[]
Items (keywords or arguments) in brackets [ ] are optional.

iii

About This Document
Convention
Description
{ x | y | ... }
Optional items are grouped in braces and separated by

vertical bars. One item is selected.
[ x | y | ... ]
Optional items are grouped in brackets and separated by

vertical bars. One item is selected or no item is selected.
{ x | y | ... }*
Optional items are grouped in braces and separated by

vertical bars. A minimum of one item or a maximum of all
items can be selected.
[ x | y | ... ]*
Optional items are grouped in brackets and separated by

vertical bars. Several items or no item can be selected.
&<1-n>
The parameter before the & sign can be repeated 1 to n times.
A line starting with the # sign is comments.
Change History
Changes between document issues are cumulative. The latest document issue contains all the
changes made in earlier issues.
Changes in Issue 03 (2013-08-15)

The third commercial release.

The second commercial release.

Initial field trial release.
Issue 03 (2013-08-15)

iv

Contents
Contents
About This Document.....................................................................................................................ii
1 User Fails to Get Online Troubleshooting...............................................................................1
1.1 Method of Troubleshooting User Logout.......................................................................................................................2
1.1.1 Troubleshooting User Logout Faults...........................................................................................................................2
1.2 User Logout Cause.........................................................................................................................................................2
1.2.1 AAA access limit.........................................................................................................................................................2
1.2.2 AAA cut command......................................................................................................................................................3
1.2.3 AAA with Authentication no response........................................................................................................................3
1.2.4 AAA with authorization data error..............................................................................................................................3
1.2.5 AAA with flow limit....................................................................................................................................................4
1.2.6 AAA with pool filled fail.............................................................................................................................................4
1.2.7 AAA with RADIUS decode fail..................................................................................................................................4
1.2.8 AAA with RADIUS server cut command...................................................................................................................4
1.2.9 AAA with realtime accounting fail.............................................................................................................................5
1.2.10 AAA with start accounting fail..................................................................................................................................5
1.2.11 AAA with stop accounting fail..................................................................................................................................5
1.2.12 AM with lease timeout..............................................................................................................................................6
1.2.13 AM with Renew lease timeout..................................................................................................................................6
1.2.14 ARP with detect fail..................................................................................................................................................6
1.2.15 Authenticate fail........................................................................................................................................................6
1.2.16 Authentication method error......................................................................................................................................6
1.2.17 Author of IP address and ip-include conflict.............................................................................................................7
1.2.18 Bas interface access limit..........................................................................................................................................7
1.2.19 Block domain force user to offline............................................................................................................................8
1.2.20 CM with AAA auth ack time out...............................................................................................................................8
1.2.21 CM with AAA connect check fail.............................................................................................................................8
1.2.22 CM with AAA ipv6 update ack time out...................................................................................................................8
1.2.23 CM with AAA logout ack time out...........................................................................................................................9
1.2.24 CM with Framed IP address invalid..........................................................................................................................9
1.2.25 CM with Ifnet ipv6 protocol down............................................................................................................................9
1.2.26 CM with IP address alloc fail....................................................................................................................................9
1.2.27 CM with l2tp session fail.........................................................................................................................................10
Issue 03 (2013-08-15)


Contents
1.2.28 Dhcp decline............................................................................................................................................................10

1.2.29 Dhcp release............................................................................................................................................................10
1.2.30 Dhcp repeat packet..................................................................................................................................................11
1.2.31 DHCP wait client packet timeout............................................................................................................................11
1.2.32 DHCP with IP address conflict................................................................................................................................11
1.2.33 Dhcp with MTU limit..............................................................................................................................................12
1.2.34 DHCP with server nak.............................................................................................................................................12
1.2.35 DHCP with server no response................................................................................................................................12
1.2.36 Gateway different from former................................................................................................................................13
1.2.37 GTL license needed.................................................................................................................................................13
1.2.38 Idle cut.....................................................................................................................................................................13
1.2.39 Interface delete........................................................................................................................................................14
1.2.40 Interface down.........................................................................................................................................................14
1.2.41 Interface on Master down........................................................................................................................................14
1.2.42 IP alloc fail for trigger user......................................................................................................................................14
1.2.43 IPv6 address conflicts too much times....................................................................................................................15
1.2.44 L2TP cut command.................................................................................................................................................15
1.2.45 L2TP peer cleared tunnel.........................................................................................................................................15
1.2.46 L2TP remote slot.....................................................................................................................................................16
1.2.47 L2TP request offline................................................................................................................................................16
1.2.48 L2TP service is unavailable.....................................................................................................................................16
1.2.49 L2TP sessionlimit ...................................................................................................................................................17
1.2.50 LAC clear session....................................................................................................................................................17
1.2.51 LAC clear tunnel.....................................................................................................................................................17
1.2.52 LNS clear session....................................................................................................................................................18
1.2.53 LNS clear tunnel......................................................................................................................................................18
1.2.54 Mac-user ppp-preferred...........................................................................................................................................18
1.2.55 Netmask assigned by RDS error(Value invalid).....................................................................................................19
1.2.56 No available prefix for conflicts of the interface id specified by RADIUS............................................................19
1.2.57 No IPv6 address available.......................................................................................................................................19
1.2.58 No prefix available..................................................................................................................................................19
1.2.59 No response of control packet from peer.................................................................................................................20
1.2.60 Online user number exceed GTL license limit........................................................................................................20
1.2.61 Packet Authenticator Error......................................................................................................................................20
1.2.62 PPP negotiate fail.....................................................................................................................................................21
1.2.63 PPP up recv lcp again..............................................................................................................................................21
1.2.64 PPP user over LNS request......................................................................................................................................22
1.2.65 PPP user request......................................................................................................................................................22
1.2.66 PPP with authentication fail....................................................................................................................................22
1.2.67 PPP with echo fail....................................................................................................................................................23
1.2.68 Pre-Authentication Domain Has Value-Added-Service..........................................................................................23
Issue 03 (2013-08-15)

vi

Contents
1.2.69 RADIUS alloc incorrect IP......................................................................................................................................24

1.2.70 Radius client request................................................................................................................................................24
1.2.71 Renew timeout in shortlease....................................................................................................................................24
1.2.72 RUI request cold backup user offline for slave.......................................................................................................24
1.2.73 RUI request offline..................................................................................................................................................25
1.2.74 Service unavailable..................................................................................................................................................25
1.2.75 Session time out.......................................................................................................................................................25
1.2.76 Srvcfg cut command................................................................................................................................................25
1.2.77 SRVCFG failed to process......................................................................................................................................25
1.2.78 The domain does not bind IPv6 pool.......................................................................................................................26
1.2.79 The domain has not binded ip-pool or ipv6-pool....................................................................................................26
1.2.80 User access speed too fast.......................................................................................................................................26
1.2.81 User info is conflict with rui user............................................................................................................................26
1.2.82 Web user request.....................................................................................................................................................27
1.3 IPv4...............................................................................................................................................................................27
1.3.1 Troubleshooting IPoX...............................................................................................................................................27
1.3.2 Troubleshooting PPPoX............................................................................................................................................30
1.3.3 Troubleshooting Leased Line....................................................................................................................................36
1.3.4 Troubleshooting L3 Access.......................................................................................................................................39
1.3.5 802.1X Access Troubleshooting................................................................................................................................42
1.4 IPv6...............................................................................................................................................................................44
1.4.1 User Cannot Get Online in the Case of IPoE Stateful PD.........................................................................................45
1.4.2 User Cannot Get Online in the Case of IPoE Stateless PD.......................................................................................49
1.4.3 User Cannot Get Online in IPv6 IPoE Stateful Access Mode with a DSLAM Serving as the LDRA.....................53
1.4.4 DHCPv6 User Fails to Get Online Through the Remote Address Pool....................................................................56
1.4.5 IPv6 PPPoE Access Troubleshooting........................................................................................................................60
1.4.6 User Cannot Get Online or the User's Access Type Is Incorrect in the Case of PPPoE IPv6 Stateful Access.........64
1.4.7 IPv6 ND Access Troubleshooting.............................................................................................................................67
1.4.8 ND-Unshared User Cannot Get Online.....................................................................................................................71
1.4.9 User Cannot Get Online in the Case of Network-Side Relay and QinQ Configuration............................................75
1.4.10 IPv6 Layer 3 Leased Line User Cannot Get Online................................................................................................79
1.4.11 Static Users Cannot Get Online...............................................................................................................................82
1.4.12 Interconnection Fails Between the Device and the RADIUS Server......................................................................87
1.5 L2TP.............................................................................................................................................................................91
1.5.1 An L2TP User Fails to Get Online............................................................................................................................92
1.5.2 L2TP IPv6 Users Cannot Get Online........................................................................................................................96
1.5.3 IPv6 L2TP Access Troubleshooting........................................................................................................................100
1.5.4 An L2TP User Fails to Go Online on the Slave Device..........................................................................................104
1.6 Related Troubleshooting Cases..................................................................................................................................105
1.6.1 Local Authentication Fails Because Authorization Mode and Accounting Mode Are Incorrectly Set..................106
1.6.2 After an Accounting Failure, the Super Password Is Invalid After Being Entered.................................................107
Issue 03 (2013-08-15)

vii

Contents
1.6.3 Users Cannot Be Redirected to the Specified Web Page........................................................................................108

1.6.4 Unreachable RADIUS Server Causes Level-3 Users to Log In as Level-1 Users..................................................110
1.6.5 A DHCP Client Fails to Obtain an IP Address from the DHCP Server Through the BRAS..................................112
1.6.6 The Device Does not Respond to the Authentication Request Packet Sent by the Web Authentication Server
..........................................................................................................................................................................................114
1.6.7 Web Authentication Fails........................................................................................................................................115
1.6.8 Error 619 Occurs After Users Attached to the NE80E/40E Dial Up......................................................................117
1.6.9 Error Message, Indicating that Communication Between a User Access Device and a Portal Server Fails, Is Displayed
During Web Authentication..............................................................................................................................................118
1.6.10 router Fails to Communicate with a RADIUS Server Because an ACL Rule Is Configured on the router's Interface
Connected to the RADIUS Server....................................................................................................................................122
1.6.11 PPPoE Subscriber Fails to Dial in Because of the Transmission Limit................................................................123
1.6.12 Users Are Repeatedly Logged Out of the MAN Due to Route Flapping..............................................................124
1.6.13 Dial-up Fails Because the Format of the Packet Sent from the BRAS Is Inconsistent with That on the RADIUS
Server................................................................................................................................................................................129
1.6.14 Uses Fail to Log In Because the GTL License File Is Not Loaded.......................................................................131
1.6.15 Modems of a Certain Brand Fail to Access the Internet Because Multiple Interfaces Respond to the PADO Packet
..........................................................................................................................................................................................132
1.6.16 Setting up an L2TP Tunnel Fails Due to Slow Packet Processing on the LNS....................................................132
1.6.17 A User Cannot Obtain the Associated Authority Because the AAA Authorization Mode and AAA Authentication
Mode Are Inconsistent......................................................................................................................................................134
1.6.18 Ping from the LAC to a Server in the Same Subnet Fails.....................................................................................136
1.6.19 Failure to Obtain an IP Address............................................................................................................................137
1.6.20 Web Authentication Fails......................................................................................................................................140
1.6.21 Mandatory Web Authentication Fails....................................................................................................................143
2 Client Fails to Obtain an IP Address Troubleshooting.....................................................146

2.1 An Ethernet Client Fails to Obtain an IP Address (the HUAWEI NetEngine80E/40E Functions as the DHCP Server)
..........................................................................................................................................................................................148
2.1.1 Common Causes......................................................................................................................................................148
2.1.2 Troubleshooting Flowchart......................................................................................................................................148
2.1.3 Troubleshooting Procedure......................................................................................................................................150
2.1.4 Relevant Alarms and Logs......................................................................................................................................152
2.2 An Ethernet Client Cannot Obtain an IP Address (the HUAWEI NetEngine80E/40E Functions as the DHCP Relay)
..........................................................................................................................................................................................152
2.2.1 Common Causes......................................................................................................................................................152
2.3 A PPPoX/IPoX Client Fails to Obtain an IP Address (the HUAWEI NetEngine80E/40E Functions as the DHCP Server)
..........................................................................................................................................................................................156
2.3.1 Common Causes......................................................................................................................................................156
Issue 03 (2013-08-15)

viii

Contents

2.4 A PPPoX/IPoX Client Cannot Obtain an IP Address (the HUAWEI NetEngine80E/40E Functions as the DHCP Relay)
..........................................................................................................................................................................................161
2.4.1 Common Causes......................................................................................................................................................161
2.5 Troubleshooting in the Scenario Where the NE80E/40E Functions as a Local DHCPv6 Server..............................166
2.5.1 Typical Networking.................................................................................................................................................166
2.5.2 Troubleshooting Flow..............................................................................................................................................167
2.6 Troubleshooting in the Scenario Where the NE80E/40E Functions as a Delegating Router.....................................170
2.7 Troubleshooting in the Scenario Where the NE80E/40E Functions as a DHCPv6 Relay Agent..............................174
2.8 User Cannot Obtain an Address from the Address Pool According to the Pool ID Delivered by the RADIUS Server
..........................................................................................................................................................................................178
2.8.1 Common Causes......................................................................................................................................................178
2.9 Related Troubleshooting Cases..................................................................................................................................180
2.9.1 User Fails to Obtain an IP Address from a DHCP Relay Agent Connected to a DHCP Server over Active and Standby
Links.................................................................................................................................................................................180
Issue 03 (2013-08-15)

ix

1 User Fails to Get Online Troubleshooting
User Fails to Get Online Troubleshooting
About This Chapter

1.1 Method of Troubleshooting User Logout
1.2 User Logout Cause
1.3 IPv4
1.4 IPv6
1.5 L2TP
1.6 Related Troubleshooting Cases
Issue 03 (2013-08-15)


1.1 Method of Troubleshooting User Logout

1.1.1 Troubleshooting User Logout Faults
Method of troubleshooting the fault that a user fails to get online
Run the display aaa online-fail-record command to check why a user fails to get online.
For example, assume that the user HUAWEI-100-07002000000100 fails to get online.
<HUAWEI> display aaa online-fail-record username HUAWEI-100-07002000000100@isp1
user-type bind
------------------------------------------------------------------User name
: HUAWEI-100-07002000000100@isp1
Domain name
: isp1
User MAC
: 0016-ecb7-a879
User access type
: IPoE
User access interface : GigabitEthernet7/0/2.1
Qinq Vlan/User Vlan
: 0/100
User IP address
: 255.255.255.255
User ID
: 14
User authen state
: Authened
User acct state
: AcctIdle
User author state
: AuthorIdle
User login time
: 2007/12/04 16:49:07
User online fail reason: PPP with authentication fail
------------------------------------------------------------------Info: Are you sure to show some information?(y/n)[y]:n
Check the 1.2 User Logout Cause to find the reason of the login failure.
If the cause of the login failure cannot be found by using the preceding method, the link between
the user and the access device may be faulty. In this case, troubleshoot the link on the network.
Method of Troubleshooting the Fault that a User Is Logged out Unexpectedly

Run the display aaa abnormal-offline-record and display aaa offline-record commands to
check the logout reason.
1.2 User Logout Cause

1.2.1 AAA access limit
Display
AAA access limit
Common Causes
The number of access users using the same account exceeds the upper limit.
Issue 03 (2013-08-15)


Solution
1.
Run the display domain domain-name command and check the User-access-limit field in
the output. Run the display access-user domain domain-name command to check the
number of access users using the same account. If the number of access users using the
same account exceeds the upper limit, run the access-limit max-number command in the
AAA view to increase the maximum number of users allowed to access the network using
the same account.
2.
Run the display local-user domain domain-name command and check the Access-limit
field in the output. Run the display access-user domain domain-name command to check
the number of local access users using the same account. If the number of local access users
using the same account exceeds the upper limit, run the local-user user-name accesslimit max-number command in the AAA view to increase the maximum number of local
users allowed to access the network using the same account.
1.2.2 AAA cut command

Display
AAA cut command
Common Causes
The cut access-user command is run manually on the access device to log users out.
1.2.3 AAA with Authentication no response

Display
AAA with Authentication no response
Common Causes
When being authenticated by a remote or local server, a user does not receive any responses
from the authentication server before the authentication timeout period expires.
Solution
Run the display this command in the AAA view and check the name of the RADIUS server
group that is bound to the user domain. Run the display RADIUS-server configuration
group group-name command and check the Authentication-server field in the output to obtain
the IP address of the authentication server. Run the ping ip-address command to check whether
the authentication server is reachable. If the ping fails, see The Ping Operation Fails for details
on how to resolve the problem.
1.2.4 AAA with authorization data error

Display
AAA with authorization data error
Issue 03 (2013-08-15)


Common Causes
The RADIUS server has delivered an incorrect attribute value or the access device has no
corresponding RADIUS attributes. Therefore, adding user authorization information fails.
1.2.5 AAA with flow limit

Display
AAA with flow limit
Common Causes
The service traffic of a user reaches the upper limit.
Solution
Check whether the remaining traffic of the user on the accounting server is 0. If there is no
remaining traffic, the user is logged out normally and no further action is required.
1.2.6 AAA with pool filled fail

Display
AAA with pool filled fail
Common Causes
Obtaining the address pool list fails.
Solution
Contact Huawei technical support personnel.
1.2.7 AAA with RADIUS decode fail

Display
AAA with RADIUS decode fail
Common Causes
The RADIUS server has delivered attributes in an incorrect format. As a result, parsing a
RADIUS authentication response packet fails.
1.2.8 AAA with RADIUS server cut command

Display
AAA with RADIUS server cut command
Issue 03 (2013-08-15)


Common Causes
The RADIUS server forces a user to log out.
1.2.9 AAA with realtime accounting fail

Display
AAA with realtime accounting fail
Common Causes
The IP address of the accounting server is unreachable, and therefore real-time accounting for
a user fails.
Relevant Alarms and Logs

This log displays as "Failed to process the normal realtime accounting. (User=[STRING],
AcctSessionID=[STRING])".
1.2.10 AAA with start accounting fail

Display
AAA with start accounting fail
Common Causes
The IP address of the accounting server is unreachable, and therefore starting accounting for a
user fails.

This log displays as "Failed to start the normal accounting. (User=[STRING], AcctSessionID=
[STRING])".
1.2.11 AAA with stop accounting fail

Display
AAA with stop accounting fail
Common Causes
The IP address of the accounting server is unreachable, and therefore stopping accounting for a
user fails.

This log displays as "Failed to stop the normal accounting. (User=[STRING], AcctSessionID=
[STRING])".
Issue 03 (2013-08-15)


1.2.12 AM with lease timeout

Display
AM with lease timeout
Common Causes
A user does not extend the IP address lease, or the link at the user side is faulty so that the packets
for requesting extension of the IP address lease are lost. As a result, the IP address lease of the
user expires.
1.2.13 AM with Renew lease timeout

Display
AM with Renew lease timeout
Common Causes
The access device cannot communicate with the DHCP server, and therefore a PPPoE user fails
to apply for extension of the IP address lease to the DHCP server.
1.2.14 ARP with detect fail

Display
ARP with detect fail
Common Causes
l
The intermediate transmission device discards or modifies ARP probe packets.
Fibers or optical modules are not properly installed or a link fault occurs.
There are too many probe response packets, and therefore some are dropped.
1.2.15 Authenticate fail

Display
Authenticate fail
Common Causes
The user name or password used for authentication is incorrect.
1.2.16 Authentication method error

Display
Authentication method error
Issue 03 (2013-08-15)


Common Causes
The requested authentication type is different from the authentication type configured on the
interface from which the user gets online.
1.2.17 Author of IP address and ip-include conflict

Display
Author of IP address and ip-include conflict
Common Causes
The address pool in the dual-stack user domain is configured incorrectly.
1.2.18 Bas interface access limit

Display
Bas interface access limit
Common Causes
l
The number of online users on a BAS interface reaches the upper limit.
The number of online users on the physical interface for the BAS interface reaches the
upper limit.
1.
Check whether the number of online users on a BAS interface reaches the upper limit.
Procedure
Run the display bas-interface command to check Access limit configured for the BAS
interface. Run the display access-user interface command to check the number of online
users on the BAS interface.
l If the number of online users reaches Access limit, run the access-limit command in
the AAA domain view to set a larger access limit value.
l If the number of online users does not reach Access limit, perform Step 2.
2.
Check whether the number of online users on the physical interface for the BAS interface
reaches the upper limit.
Run the display this command to check port-access-limit configured for the physical
interface for the BAS interface. Run the display access-user interface command to check
the number of online users on the physical interface for the BAS interface.
l If the number of online users on the physical interface for the BAS interface reaches
port-access-limit, run the port-access-limit command to set a larger port access limit
value.
l If the number of online users on the physical interface for the BAS interface does not
reach port access limit, contact Huawei technical personnel.
Issue 03 (2013-08-15)


1.2.19 Block domain force user to offline

Display
Block domain force user to offline
Common Causes
The timer for blocking a domain expires, and therefore the domain users are forced offline.
1.2.20 CM with AAA auth ack time out

Display
CM with AAA auth ack time out
Common Causes
No AAA authentication response is received before the due time.
Solution
1.2.21 CM with AAA connect check fail

Display
CM with AAA connect check fail
Common Causes
Mappings between the UCM entries and AAA entries are incorrect.
Solution
1.2.22 CM with AAA ipv6 update ack time out

Display
CM with AAA ipv6 update ack time out
Common Causes
Waiting for an IPv6 entry update response from the AAA module times out.
Solution
Issue 03 (2013-08-15)


1.2.23 CM with AAA logout ack time out

Display
CM with AAA logout ack time out
Common Causes
Waiting for an AAA logout response times out.
Solution
1.2.24 CM with Framed IP address invalid

Display
CM with Framed IP address invalid
Common Causes
The IP address assigned by the RADIUS server has already been assigned to another device,
and therefore the IP address is invalid.
1.2.25 CM with Ifnet ipv6 protocol down

Display
CM with Ifnet ipv6 protocol down
Common Causes
IPv6 has been disabled on the access device or an access interface. As a result, IPv6 on the access
interface goes Down, causing an IPv6 user to be logged out or fail to log in.
1.2.26 CM with IP address alloc fail

Display
CM with IP address alloc fail
Common Causes
The UCM module fails to obtain an IP address.
Solution
Issue 03 (2013-08-15)


1.2.27 CM with l2tp session fail

Display
CM with l2tp session fail
Common Causes
An L2TP session fails to be set up.
Feature Type
L2TP
Solution
1.2.28 Dhcp decline

Display
Dhcp decline
Common Causes
The DHCP client sends a DHCPDECLINE message to the DHCP server because it detects that
the IP address it is assigned has already been assigned to another client.
Feature Type
IPoE

IPCONFLICT
1.2.29 Dhcp release

Display
Dhcp release
Common Causes
The UCM module instructs the AM module to reclaim an IP address that has been assigned by
the remote DHCP server.
Feature Type
IPoE
Issue 03 (2013-08-15)

10

Solution
1.2.30 Dhcp repeat packet

Display
Dhcp repeat packet
Common Causes
An online user sends DHCPDISCOVER packets again. As a result, the DHCP server considers
the user offline and logs out the user.
Feature Type
IPoE
1.2.31 DHCP wait client packet timeout

Display
DHCP wait client packet timeout
Common Causes
The fault that DHCP packets from a user are lost is commonly caused by one of the following:
l
Incorrect link bandwidth is configured.
A link is interrupted or the link delay is too long.
Some fields in packets cannot be identified by a transit device, causing packet loss.
Feature Type
IPoE
Solution
Troubleshoot the fault based on the actual networking and service requirements.
TIP
If DHCP snooping or broadcast suppression is configured on a transit device, DHCP packets may be
dropped mistakenly by the transit device.
1.2.32 DHCP with IP address conflict

Display
DHCP with IP address conflict
Issue 03 (2013-08-15)

11

Common Causes
An IP address conflict was detected.
Feature Type
IPoE
Solution
1.2.33 Dhcp with MTU limit

Display
Dhcp with MTU limit
Common Causes
The MTU value configured on an interface is too small, and therefore the interface cannot send
DHCP packets.
Feature Type
IPoE
1.2.34 DHCP with server nak

Display
DHCP with server nak
Common Causes
Multiple DHCP servers are deployed on the network. The IP address that a client obtains is
assigned by a DHCP server but not the access device, and therefore the IP address is not within
the assignable IP address segment of the access device.
Feature Type
IPoE
1.2.35 DHCP with server no response

Display
DHCP with server no response
Issue 03 (2013-08-15)

12

Common Causes
When applying for an IP address to the remote server, the access device receives no response
from the server. The fault is commonly caused by one of the following:
l
The remote server has no route to the access device.
The remote server has no assignable IP address.
The remote server fails to receive DHCPREQUEST packets from the access device due to
a link fault.
Feature Type
IPoE

AM_1.3.6.1.4.1.2011.6.8.2.2.0.4_hwDhcpServerDown
1.2.36 Gateway different from former

Display
Gateway different from former
Common Causes
A user obtains an incorrect IP address, or the address pool configured on the access device has
been modified. As a result, when the user sends ARP packets for getting online, the IP address
that the user uses is not within the address pool.
1.2.37 GTL license needed

Display
GTL license needed
Common Causes
The GTL license of the BRAS LPU from which a user gets online is not activated.

This log displays as "This slot did not have any GTL license. (Slot=[ULONG])".
1.2.38 Idle cut

Display
Idle cut
Issue 03 (2013-08-15)

13

Common Causes
The traffic volume of a user in the specific period of time is smaller than the set minimum traffic
volume of the BRAS, and therefore the user is forced offline.
Solution
Run the idle-cut idle-time idle-data command in the AAA domain view to change the idle time
of cutting a connection.
1.2.39 Interface delete

Display
Interface delete
Common Causes
The interface from which a user gets online is deleted.
1.2.40 Interface down

Display
Interface down
Common Causes
The shutdown command is run on the interface from which a user gets online, or the physical
link of the interface is faulty. As a result, the user is offline.
1.2.41 Interface on Master down

Display
Interface on Master down
Common Causes
The shutdown command is run on the interface from which a user gets online, or the physical
link of the interface is faulty. In addition, a master/slave MPU switchover is performed when
the user is logged out.
1.2.42 IP alloc fail for trigger user

Display
IP alloc fail for trigger user
Issue 03 (2013-08-15)

14

Common Causes
The IP address that a user applies for has been assigned to another user, and therefore the IP
address fails to be assigned to the user.
1.2.43 IPv6 address conflicts too much times

Display
IPv6 address conflicts too much times
Common Causes
There are attack devices on the network, causing more than three address conflicts.
1.2.44 L2TP cut command

Display
L2TP cut command
Common Causes
The reset tunnel command is run on the access device.
Feature Type
L2TP
1.2.45 L2TP peer cleared tunnel

Display
L2TP peer cleared tunnel
Common Causes
The LAC or LNS detects user logouts, and therefore tears down the tunnel (between the LAC
and LNS) for the logout users.
Feature Type
L2TP
Solution
Issue 03 (2013-08-15)

15

1.2.46 L2TP remote slot

Display
L2TP remote slot
Common Causes
A board for L2TP user access is faulty, causing users that have gone online from the board to
be logged out.
Feature Type
L2TP
1.2.47 L2TP request offline

Display
L2TP request offline
Common Causes
An L2TP user sends a logout request.
Feature Type
L2TP
Solution
1.2.48 L2TP service is unavailable

Display
L2TP service is unavailable
Common Causes
L2TP is not enabled on the access device.
Feature Type
L2TP
Issue 03 (2013-08-15)

16

1.2.49 L2TP sessionlimit

Display
L2TP sessionlimit
Common Causes
The number of users whose services are transmitted using the same L2TP tunnel reaches the
upper limit that is configured on the access device or delivered by the RADIUS server.
Feature Type
L2TP
1.2.50 LAC clear session

Display
LAC clear session
Common Causes
When the LAC is faulty or detects that L2TP users are offline, the LAC sends requests to log
out related users to the LNS.
Feature Type
L2TP
Solution
"LAC clear session" is displayed on the LNS that runs properly. Run the display aaa offlinerecord, display aaa online-fail-record, and display aaa abnormal-offline-record commands
on the LAC to check the offline reason. Then, further locate the fault based on the offline reason
and troubleshooting manuals.
1.2.51 LAC clear tunnel

Display
LAC clear tunnel
Common Causes
The LAC detects a user logout, and therefore tears down the tunnel for the user.
Feature Type
L2TP
Issue 03 (2013-08-15)

17

1.2.52 LNS clear session

Display
LNS clear session
Common Causes
The LNS is faulty or detects that an L2TP user logs out, and therefore sends a request to log out
the user to the LAC.
Feature Type
L2TP
Solution
"LNS clear session" is displayed on the LAC that runs properly. Run the display aaa offlinerecord, display aaa online-fail-record, and display aaa abnormal-offline-record commands
on the LNS to check the offline reason. Then, further locate the fault based on the offline reason
and troubleshooting manuals.
1.2.53 LNS clear tunnel

Display
LNS clear tunnel
Common Causes
The LNS detects local user logouts, and therefore tears down the corresponding tunnels.
Feature Type
L2TP
1.2.54 Mac-user ppp-preferred

Display
Mac-user ppp-preferred
Common Causes
PPP take precedence over DHCP when users attempt to get online from the access device.
Therefore, when a user uses PPP to get online after getting online using DHCP, it is logged out
as a DHCP user.
Issue 03 (2013-08-15)

18

1.2.55 Netmask assigned by RDS error(Value invalid)

Display
Netmask assigned by RDS error (Value invalid)
Common Causes
The RADIUS server mistakenly delivers the IP address of the access device to a PPPoE user.
1.2.56 No available prefix for conflicts of the interface id specified

by RADIUS
Display
No available prefix for conflicts of the interface id specified by RADIUS
Common Causes
The IPv6 address (consisting of an interface ID delivered by the RADIUS server and an IP
address prefix) has been assigned to another user.
Solution
1.2.57 No IPv6 address available

Display
No IPv6 address available
Common Causes
No IP address can be assigned.
Solution
1.2.58 No prefix available

Display
No prefix available
Common Causes
No IP address prefix can be assigned.
Issue 03 (2013-08-15)

19

Solution
1.2.59 No response of control packet from peer

Display
No response of control packet from peer
Common Causes
The physical link to the peer LAC or LNS device is faulty and therefore response packets from
the peer LAC or LNS device are not received.
Feature Type
L2TP
1.2.60 Online user number exceed GTL license limit

Display
Online user number exceed GTL license limit
Common Causes
The number of online users exceeds the limit allowed by the GTL license.

This log displays as "The number of users exceeded the limit allowed by the GTL license."
1.2.61 Packet Authenticator Error

Display
Packet Authenticator Error
Fault Symptom
In Web authentication mode, a user fails to be authenticated.
Common Causes
l
Issue 03 (2013-08-15)
The key in an authentication packet sent by the portal server is different from the key
calculated by the HUAWEI NetEngine80E/40E.
20

Procedure
Check whether the key configured on the HUAWEI NetEngine80E/40E is the same as that
configured on the portal server.
l
If the keys are different, run the web-auth-server server-ip [ vpn-instance instancename ] [ port portnum [ all ] ] [ key key ] [ NAS-ip-address ] command to change the key
to the same as that on the portal server.
If the keys are the same, check whether the user can be authenticated successfully. If the
authentication is successful, no action is required.
If the authentication failure persists, contact Huawei technical support personnel.
1.2.62 PPP negotiate fail

Display
PPP negotiate fail
Common Causes
PPP negotiation is interrupted.
Solution
Mirror on the interface from which the user gets online. Check PPP packets, and locate the fault
based on interaction packets.
TIP
l If the user sends the same type of PPP negotiation packet many times, check whether the access device
supports this type of PPP negotiation.
l Check the type and content of the negotiation packet that the user sends before the LCP or PPPoE
termination packet to confirm whether the access device supports this type of PPP negotiation.
1.2.63 PPP up recv lcp again

Display
PPP up recv lcp again
Common Causes
A user tears down and re-initiates a connection, and therefore the access device receives LCP
negotiation packets.
Feature Type
PPP
Issue 03 (2013-08-15)

21

1.2.64 PPP user over LNS request

Display
PPP user over LNS request
Common Causes
A user fails to set up a session, and therefore the user fails to get online.
Feature Type
PPP
Solution
1.2.65 PPP user request

Display
PPP user request
Common Causes
A PPP user sends a logout request.
Feature Type
PPP
1.2.66 PPP with authentication fail

Display
PPP with authentication fail
Common Causes
l
Too many users attempt to get online in a specified period of time.
The CPU usage is too high (remaining above than 95%).
Feature Type
PPP
Issue 03 (2013-08-15)

22

Solution
Run the display this command in the AAA view to check whether the access speed command
has been configured. If the access speed command has been configured, check whether the user
access rate exceeds the upper limit.
Run the display cpu-usage command to check the CPU usage. If the CPU usage remains above
than 95%, locate and resolve this problem.
1.2.67 PPP with echo fail

Display
PPP with echo fail
Common Causes
l
The intermediate transmission device discards or modifies probe packets.
Fibers or optical modules are improperly installed or a link fault occurs.
Solution
Run the display aaa offline-record command to check the user login time and logout time.
Run the display this command in the virtual template (VT) view to check the interval at which
PPP Keepalive packets are sent.
l
If the difference between the user login time and logout time is equal to the interval, user
packets are properly transmitted but no response to KeepAlive packets is received. Get
packets head on the downstream device to check where the response packets are discarded
and rectify the fault.
If the difference between the user login time and logout time is unequal to the interval,
KeepAlive packets can be received and there are responses to KeepAlive packets. In this
situation, check whether the user functions properly and rectify any detected fault.
1.2.68 Pre-Authentication Domain Has Value-Added-Service

Display
Pre-authentication domain has value-added-service
Common Causes
l
Value-added-service (VAS) cannot be bound to the pre-authentication domain. If VAS is

configured in the pre-authentication domain, web users cannot be switched to the
authentication domain and fail to log in.
Run the display this command in the pre-authentication domain to view whether VAS is
bound to the pre-authentication domain.
Solution
Issue 03 (2013-08-15)

23

If VAS is bound to the pre-authentication domain, run the undo value-added-service

policy command to delete VAS from the pre-authentication domain.
If VAS is not bound to the pre-authentication domain, contact Huawei technical support
personnel.
1.2.69 RADIUS alloc incorrect IP

Display
RADIUS alloc incorrect IP
Common Causes
The address pool containing the IP address that the RADIUS server assigns to an IPoE user
cannot be found on the access device.
1.2.70 Radius client request

Message
Radius client request
Common Cause
The AC sends a request to the RADIUS server to log out the user.
1.2.71 Renew timeout in shortlease

Display
Renew timeout in shortlease
Common Causes
A user does not extend the short lease of an IP address, or the link at the user side is faulty so
that the packets for requesting the extension of the short lease are lost. As a result, the short lease
of the IP address expires.
1.2.72 RUI request cold backup user offline for slave

Display
RUI request cold backup user offline for slave
Common Causes
In the dual-system hot backup scenario, when the remote backup template on the master access
device becomes backup, the users that do not support dual-system host backup are logged out.
The possible cause is that VRRP tracked by the remote backup profile on the local access device
Issue 03 (2013-08-15)

24

detects a fault on a network-side port, or a fault of peer VRRP that has a higher priority than
VRRP on the local access device is rectified.
1.2.73 RUI request offline

Display
RUI request offline
Common Causes
RUI triggers a user logout.
1.2.74 Service unavailable

Display
Service unavailable
Common Causes
An L2TP user attempts to log in to the access device where L2TP is disabled.
1.2.75 Session time out

Display
Session time out
Common Causes
A user has no remaining online time.
1.2.76 Srvcfg cut command

Display
Srvcfg cut command
Common Causes
A command is run to delete leased-line users.
1.2.77 SRVCFG failed to process

Display
SRVCFG failed to process
Issue 03 (2013-08-15)

25

Common Causes
The access device fails to select a user authentication type.
Solution
1.2.78 The domain does not bind IPv6 pool

Display
The domain does not bind IPv6 pool
Common Causes
No IPv6 address pool is bound to a user domain, and therefore IPv6 users in the domain cannot
get online.
1.2.79 The domain has not binded ip-pool or ipv6-pool

Display
The domain has not binded ip-pool or ipv6-pool
Common Causes
No address pool is bound to a user domain, and therefore users in the domain cannot get online.
1.2.80 User access speed too fast

Display
User access speed too fast
Common Causes
The user access speed is too fast.
1.2.81 User info is conflict with rui user

Display
User info is conflict with rui user
Common Causes
A fault occurs at the network side in the dual-system hot backup networking, causing the users
of the master device to get offline. Online users, however, are not synchronized to the backup
device. As a result, RUI forces these online users to go offline.
Issue 03 (2013-08-15)

26

1.2.82 Web user request

Display
Web user request
Common Causes
A Web user sends a logout request.
Feature Type
Web
1.3 IPv4
1.3.1 Troubleshooting IPoX
This section describes the configuration notes, flows, and procedures for IPoX troubleshooting
based on the typical IPoX networking.
Typical Networking
Figure 1-1 IPoE networking
Eth
IP
Data
I n t e rn e t
subscriber
Router
Figure 1-2 Networking for IPoEoV and static user
Eth IP Data
Eth Tag IP Data

I n t e rnet
subscriber
LAN Switch
Router
Figure 1-3 Networking for IPoEoQ
Eth IP Data
Eth
Tag
IP Data
Eth
Tag
Tag
IP Data
I n t e rn et
subscriber
Issue 03 (2013-08-15)
LAN Switch
LAN Switch

Router
27

Figure 1-4 Networking for IPoA and IPoEoA
User
RADIUS
Server
Internet
DSLAM
Issue 03 (2013-08-15)
Router

28

Troubleshooting Flowchart
Figure 1-5 IPoX troubleshooting flowchart
IPoX user
cannot go
online
Passed
authentication?
No
Check authentication
domain or preauthentication domain
Yes
Obtained an IP
address?
No
Configure address
pool or DHCP server
properly
Yes
Enable service tracing

or debugging
Fault removed?
No
Technical
support
Yes
End
Troubleshooting Procedure
Procedure
Step 1 Check whether the user passes authentication.
l If the web authentication fails, solve the problem by referring to 1.6.20 Web Authentication
Fails .
l If the mandatory web authentication fails, solve the problem by referring to 1.6.21
Mandatory Web Authentication Fails .
Step 2 Check whether the user has obtained an IP address.
Issue 03 (2013-08-15)

29

The IP addresses of IPoX users can be assigned by the local router or the remote DHCP server:
l If the IP address is assigned by the local device, check the configuration of the local address
pool.
l If the IP address is assigned by the remote DHCP server, check the communication between
the local device and the DHCP server.
For detailed procedure, see 1.6.19 Failure to Obtain an IP Address .
Step 3 Enable service tracing to locate the fault through the login process.
Step 4 Enable debugging.
The output information of debugging is more specific than the service tracing information. It
helps you locate the fault.
If the fault persists, contact Huawei engineers.
NOTE
Debugging cannot be performed for a single user. Therefore, it is not recommended.
----End
1.3.2 Troubleshooting PPPoX

This section describes the configuration notes, flows, and procedures for PPPoX troubleshooting
based on the typical PPPoX networking.
Typical Networking
Figure 1-6 PPPoE networking
Eth
IP
Data
I n t e rnet
subscriber
Router
Figure 1-7 Networking for PPPoEoV

Eth
PPP IP
Data
Eth Tag PPP
IP Data
I nt e r net
subscriber
Issue 03 (2013-08-15)
LAN Switch
Router

30

Figure 1-8 Networking for PPPoEoQ

Eth
PPP
Data
Eth Tag
Eth
PPP Data
Tag
Tag
PPP Data
I nt e rnet
subscriber
LAN Switch
LAN Switch
Router
Figure 1-9 Networking for PPPoA and PPPoEoA

User
RADIUS
Server
Internet
DSLAM
Issue 03 (2013-08-15)
Router

31

Figure 1-10 PPPoX troubleshooting flowchart
PPPoX user
cannot go
online
Configuration
proper?
No
Remove
configuration fault
Yes
Display tracing
information
Tracing info
displayed?
No
Remove
device fault
Yes
LCP
negotiation
successful?
Yes
Authentication
successful?
No
Remove
device fault
No
Remove
authentication failure
Yes
NCP negotiation
successful?
No
Remove IP address
allocation failure
Yes
Remove
accounting failure
Fault removed?
No
Technical
support
Yes
End
Procedure
Step 1 Run the display aaa online-fail-record command to display the cause of online failure.
<HUAWEI> display aaa online-fail-record username test@hauwei
-------------------------------------------------------------------
Issue 03 (2013-08-15)

32

User name
: test@radius
User MAC
: 0001-0101-0101
User access type
: PPPoE
User interface
: Atm4/0/2
User Pe Vlan
: 99
User Ce Vlan
: 99
User IP address
: User ID
: 233
User authen state : Authened
User acct state
: AcctIdle
User author state : AuthorIdle
User login time
: 2009-09-04 15:14:14
Online fail reason : PPP with authentication fail
-------------------------------------------------------------------
Here, User online fail reason indicates why the user fails to go online. From the information,
you can judge the fault and find out how to locate the fault.
Table 1-1 Reasons for online failure
Issue 03 (2013-08-15)
User online fail reason
Meaning
PPP with authentication fail
Indicates the PPP authentication failure.
IP address alloc fail
Indicates the failure to assign IP addresses.
IP address conflict
Indicates the IP address conflict.
mac address conflict
Indicates the MAC address conflict.
Start accounting fail
Indicates the failure to start accounting.
Domain or user access limit
Indicates the limit on domain or user

access.
Port access limit
Indicates the access limit on the port.
PPP negotiate fail
Indicates the PPP negotiation failure.
Send authentication request fail
Indicates the failure to send the

authentication request.
Radius authentication reject
Indicates that the RADUIS server rejects

the authentication request.
Radius authentication send fail
Indicates the failure to send the RADIUS

Local authentication reject
Indicates that the local authentication is

rejected.
Local authentication no user
Indicates that the user cannot be found in

the local authentication domain.
Local Authentication user type not match
Indicates that the user type does not match

with the local domain.
Local Authentication user block
Indicates that the account is not activated

in the local authentication.

33

Step 2 Check the configuration.

From step 1, you can learn that some failures are caused by configurations, for example, "Local
authentication no user" and "Domain or user access limit." In this case, modify the configuration.
Sometimes, the user fails to go online because no PPPoX link is set up. It is possible that the
user is still offline, so there is no offline record of the user.
Step 3 Check whether the user has been forbidden to access the device.
Run the display ppp [ slot slot-number ] chasten-user [ [ mac-address mac-address ] |
[ option105 [ circuit-id circuit-id ] [ remote-id remote-id ] ] command to check whether the
user has been forbidden to access the device.
l
If the user access is forbidden, dial up again after the user access is not forbidden.
If the user access is not forbidden, go to Step 4.
Step 4 Enable service tracing.

Run the trace mac command to enable service tracing and test the online process. When the
user gets offline, display the output information of service tracing.
If the router does not receive the PADI or PADR packet. Check the layer 2 network connectivity,
the port state, the access type (layer2-subscriber), the authentication method (PPP must be
allowed), and the VT bound to the interface.
NOTE
If the service tracing function outputs no information, it indicates that the user sends no packets to the
router. The possible causes are as follows:
l User access type is incorrect.
l The authentication method is incorrect.
l The physical port is not bound to any VT.
l The physical connections on the device are incorrect.
l The layer 2 devices are configured incorrectly.

If the service tracing function does not output any information, check whether:
l The devices are connected to each other correctly.
l The configurations on the NE80E/40Eare correct.
l The layer-2 devices are configured correctly.
l The user packets can reach the NE80E/40E.
If the incorrect configurations cause the online failure, check the related local configurations
l Run the display access-user mac-address [ mac ] command to see whether a user has already
gone online by using the MAC address.
l Check the configuration of the authentication method. If the user is authenticated by the
RADIUS server, the RADIUS configurations on the NE80E/40E must be correct. The user
name must be included in the correct domain and the RADIUS server operates normally.
Check whether the local account is configured properly and the number of access users is
not limited.
Issue 03 (2013-08-15)

34

Step 6 Capture the packets at the client to check whether the LCP negotiation is complete.
By capturing packets, you can learn whether the LCP negotiation failure is caused by the NE80E/
40E, the client, or the improper interoperation between them.
The following lists the common faults:
1.
A non-standard PPPoE client sends the config-request packet to the NE80E/40E. The
NE80E/40E responds with a config-nak/config-reject packet. If the client keeps the
attributes in the config-request packet unmodified, the LCP negotiation fails.
2.
The NE80E/40E is configured with the CHAP authentication while the client is configured
with the PAP authentication. The LCP negotiation fails.
Step 7 Check whether the authentication succeeds.

If the local authentication for some reasons, for example, invalid local account, inactive domain,
inactive account, inconsistent account type, or access limit, you can see the cause of the failure
in authentication messages.
In case of RADIUS authentication, the service tracing function also outputs the information that
can help you locate the fault.
The failure may be caused by the RADIUS server, because the RADIUS server fails to respond
to the router. If you cannot judge the fault from the output, check the RADIUS server.
For details, see 5 "RADIUS Troubleshooting."
Step 8 Check whether the NCP negotiation succeeds.
The key of PPPoE NCP negotiation is the IP address, and therefore NCP negotiation equals the
address negotiation..
Check IP address assignment.
l The IP address is assigned by the NE80E/40E.
Check the configuration of the domain: the referenced IP address pool and the availability
of IP addresses. If the IP address pool is specified by the RADIUS server, make sure that the
RADIUS server delivers the correct attribute (88, Framed-Pool), If the delivered string
contains @ or #, the characters before @ or # are used as the address pool name. In addition,
the specified address pool must be configured on the NE80E/40E.
l The IP address is assigned by the RADIUS server.
Check the Framed-IP-Address attribute in the RADIUS response packet.
If the Framed-IP-Address attribute is 255.255.255.255 or 255.255.255.254, it indicates that
the IP address is assigned by the NE80E/40E, and the domain need reference the correct
address pool. If the RADUIS response does not contain this attribute, it also indicates the IP
address is assigned by the NE80E/40E. If the attribute value is incorrect, no IP address is
assigned to the user.
l The NE80E/40E serves as the client, requiring the external DHCP server to assign IP
addresses.
If the IP assignment procedure is incorrect, check whether:
The DHCP server group is configured correctly on the NE80E/40E and referenced by the
correct address pool.
Issue 03 (2013-08-15)

35

There is a reachable route to the DHCP server group.

The DHCP server group operates well.
The IP address assigned by the DHCP server is valid.
The assigned IP address falls into the address pool configured on the NE80E/40E.
The mask is the same as that of the address pool configured on the NE80E/40E.
The IP address is already used by another online user.
If the fault persists, contact the Huawei customer service center.
Step 9 Check the accounting.
If the user is still offline, it indicates that a fault has occurred on the accounting.The common
fault is "Start accounting fail."
The NE80E/40E supports RADIUS accounting, HWTACAS accounting, and no accounting.
That is, the NE80E/40E cannot conduct accounting for users locally.
NOTE
If the RADIUS accounting or HWTACACS accounting fails, the NE80E/40E stores the accounting data
locally and generates CDRs. When the accounting server recovers, the NE80E/40E sends the CDRs to the
accounting server. If the local storage space is full, while the accounting server does not recover, the
NE80E/40E discards the latter accounting data.
----End
Follow-up Procedure
1.3.3 Troubleshooting Leased Line

This section describes the configuration notes, flows, and procedures for leased line
troubleshooting based on the typical leased line networking.
Typical Networking
As shown in Figure 1-11, the layer-2 leased line user accesses the NE80E/40E through a LAN
switch.
Figure 1-11 Layer-2 leased line networking
I n t e r ne t
User
LAN
Switch
Router
As shown in Figure 1-12, the layer-3 leased line user accesses the VLAN on an interface or subinterface of the NE80E/40E through a router.
Issue 03 (2013-08-15)

36

Figure 1-12 Layer-3 leased line networking

I n t e rnet
L3
Switch
User
Router
Figure 1-13 Static user Layer-2 leased line Troubleshooting flowchart
A layer- 2 leased
line user cannot
go online
Sub-interface
Up?
Yes
BAS
configuration
proper?
No
Configure the sub

- interface to Up
No
Configure BAS
Yes
Domain
configuration
proper ?
Configure
authentication /
accounting /RADIUS
servers
No
Yes
Address pool
configured ?
No
Configure the
address pool
Yes
IP address of
static user
excluded ?
No
Exclude the IP
address from
address pool
Yes
Enable service
tracing
Device received
The DHCP or ARP
sent by user ?
No
Check the fault on

layer - 2 network
Yes
Fault
?
removed
No
Technical
support
Yes
End
Issue 03 (2013-08-15)

37

Figure 1-14 Layer-3 leased line troubleshooting flowchart

A layer 3 leased line
user cannot go
online
Configure an IP
address for the
interface
No
Sub- interface Up?

Yes
No
BAS
configuration
proper ?
Configure BAS
Yes
Domain
configured properly ?
Configure
authentication /
accounting /RADIUS
servers
No
Yes
No
Fault removed ?
Technical
support
Yes
End
Procedure
Step 1 Run the display interface command to check whether the sub-interface of the leased line user
is Up.
Step 2 Run the display bas-interface command to check the BAS configuration on the interface. Make
sure that the leased line type is configured properly.
Step 3 Run the display domain command to check the configuration of the domain, including
authentication mode and accounting mode. Make sure that the NE80E/40E and the RADIUS
server can communicate with each other.
Step 4 Run the display domain command to check whether the address pool is configured in the domain
of the layer-2 leased line user.
Step 5 Check whether the IP address of the static user is excluded from the address pool.
Step 6 For the layer-3 leased line user, check the IP address of the interface, and the route of the user.
----End
Issue 03 (2013-08-15)

38

Follow-up Procedure
1.3.4 Troubleshooting L3 Access

This section describes the configuration notes, flows, and procedures for L3 access
troubleshooting based on the typical L3 networking.
Typical Networking
Figure 1-15 shows the typical networking of L3 users. The troubleshooting procedure is based
on this networking.
Figure 1-15 L3 access networking
Internet
User
10.164.44.2/24
LAN Switch
L3 Switch
Router
192.168.1.1/24 192.168.1.2/24
The ordinary L3 user configures an IP address or obtains an IP address from the DHCP
server.
The user accesses the Internet through the router, and the router should manage the user.
Issue 03 (2013-08-15)

39

Figure 1-16 L3 access troubleshooting flowchart
Layer 3 users fail
to go online
Any record
of failures in getting
online?
Yes
Rectify the fault

based on the
records
No
Rectify the fault on

the interface
No
Correctly configure
Layer 3 users
No
Is the
physical status of
the Layer 3 interface
normal?
Yes
Are device
configurations
correct?
Yes
Enable service
tracking to locate the
fault
Is the fault
removed?
No
Seek technical
support
Yes
End
Procedure
Step 1 Check the record of login failure.
Run the display aaa online-fail-record command to check the record of login failure.
The possible failure causes are as follows:
Issue 03 (2013-08-15)

40

l The authentication fails. That is, the authentication packets cannot be sent or start-accounting
fails. Check the home domain of the L3 access user. The authentication mode and accounting
mode of the domain should be none authentication and none accounting.
l The VPN configuration is inconsistent. Check whether the configuration of VPN instance in
the domain is consistent with the VPN configuration on the interface.
Step 2 Check the status of the physical interface.
Run the display interface command to check the status of the physical interface. Check whether
the interface and the protocol are up and the packets are sent and received on the interface.
<HUAWEI> display interface gigabitethernet 1/0/0
GigabitEthernet1/0/0 current state : UP
Line protocol current state : UP
Description : HUAWEI, GigabitEthernet1/0/0 Interface, Route Port
The Maximum Transmit Unit is 1500 bytes, Hold timer is 10(sec)
Internet Address is 192.168.1.2/24
IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is 00e0-fc87-f1b9
the Vendor PN is HFBR-5710L
Port BW:1G, Transceiver max BW:1G, Transceiver Modes: MutipleMode
WaveLength:850nm,Transmission Distance:550m
Loopback:none, full-duplex mode, negotiation: disable
Statistics last cleared:2006-09-15 17:50:54
Last 5 minutes input rate: 0 bits/sec, 0 Packets/sec
Last 5 minutes output rate: 0 bits/sec, 0 Packets/sec
Input: 0 Bytes, 0 Packets
Output: 0 Bytes, 0 Packets
Input:
Unicast
:
0, Multicast
:
0
Broadcast :
0, JumboOctets
:
0
CRC
:
0, Symbol
:
0
Overrun
:
0, InRangeLength
:
0
LongPacket:
0, Jabber
:
0, Alignment: 0
Fragment :
0, Undersized Frame:
0
RxPause
:
0
Output:
Unicast
:
0, Multicast :
0
Broadcast :
0, JumboOctets:
0
Lost
:
0, Overflow
:
0, Underrun: 0
TxPause
:
0
Step 3 Check the configuration of the L3 access user.

For details, refer to section 1.3.4 Troubleshooting L3 Access Check whether the route in the
network segment of the L3 access user is added.
Step 4 Enable service tracing to locate the fault.
Perform service tracing based on the IP address of the user. Collect the tracing information to
locate the fault. For example, if "fail to get domain of layer3 user" is displayed in the tracing
information, check whether the VPN configuration of the user is consistent with the VPN
configuration on the interface.
----End
Follow-up Procedure
If the fault persists, contact Huawei technical personnel.
Issue 03 (2013-08-15)

41

1.3.5 802.1X Access Troubleshooting

This section describes the notes about configuring 802.1X access, and provides the 802.1X
access troubleshooting flowchart and the troubleshooting procedure in a typical network.
Typical Networking
802.1X access networking is similar to IPoE networking, IPoEoVLAN networking, and IPoEoQ
networking. The EAP packet can be encapsulated into an EAPoL packet on the Ethernet interface
of a PC. The EAPoL packet is then sent to the BRAS directly. Alternately, the EAPoL packet
can be attached with a VLAN tag by a LAN switch or be encapsulated through AAL5 by a
DSLAM before it arrives at the BRAS.
By decapsulating packets and identifying VLAN IDs of packets, the BRAS obtains physical
information about users, and user names and passwords. The BRAS then provides data for the
access authentication of users based on the obtained information.
Figure 1-17 Networking diagram of 802.1X access
Internet
subscriber
BRAS
Figure 1-18 Networking diagram of the 802.1XoEoV service
Internet
subscriber
Switch
BRAS
Figure 1-19 Networking diagram of the 802.1XoEoQ service
Internet
subscriber
Issue 03 (2013-08-15)
Switch
Switch
BRAS

42

Figure 1-20 802.1X troubleshooting flowchart
802.1X
authentication
fails
BAS
interface correctly
configured?
No
Configure the
BAS interface
correctly
No
Configure the
domain
correctly
Yes
Domaincorrectly
configured?
Yes
EAPtermination
configured?
No
RADIUS
server correctly
configured?
Yes
Seek
technical
support
No
Configure
user
information
correctly
Yes
User
information
correctly
configured?
No
Is fault
rectified?
Yes
End
No
Seek
technical
support
Procedure
Step 1 Check that the BAS interface is correctly configured.
Enter the BAS interface view and then run the display this command to view the configuration.
Issue 03 (2013-08-15)

43

l Check whether the access type is Layer 2 access and whether a VLAN is configured for a
sub-interface. No VLAN configuration is required for the access through a main interface.
l Check whether an authentication domain is configured and whether dot1x authentication is
adopted as the authentication method.
l If the configuration is correct, proceed to Step 2.
Step 2 Check that the authentication domain is correctly configured.
Enter the AAA view and then run the display this command to view the configuration about
the AAA domain.
l The domain must be bound to an address pool and the authentication, authorization, and
accounting templates.
l A RADIUS server group must be bound to the domain if RADIUS authentication is adopted.
l The dot1x-template must be bound to the domain.
Step 3 Check that the dot1x-template is correctly configured.
Enter the view of the dot1x-template bound to the AAA domain from the system view, and then
run the display this command to view configurations of the dot1x-template.
l If the eap-end command is configured for the template, termination authentication is
adopted. In this manner, only 802.1X MDS authentication and PAP authentication are
supported.
l If the eap-end command is configured for the template, relay authentication is adopted. This
requires that RADIUS authentication be configured in the domain and the RADIUS server
support 802.1X authentication.
Step 4 Check that user information is correctly configured on the authentication server.
l If termination authentication is adopted, check that user information is correctly configured
on the associated authentication server.
l If relay authentication is adopted, check that user information is correctly configured on the
RADIUS server that supports 802.1X authentication.
Step 5 Check that the NE80E/40E is correctly configured for user access.
l In the case of the wired access to the NE80E/40E, Web authentication and 802.1X
authentication cannot be configured on a BAS interface at the same time; EAP authentication
cannot be triggered by sending ARP, IP, or DHCP packets; users must pass the 802.1X
authentication before they can obtain IP addresses.
l In the case of the wireless access to the NE80E/40E, check whether WLAN is correctly
configured.
l If the configuration is correct whereas the fault persists, contact Huawei technical personnel.
----End
1.4 IPv6
Issue 03 (2013-08-15)

44

1.4.1 User Cannot Get Online in the Case of IPoE Stateful PD

This section describes the troubleshooting flowchart and provides a step-by-step troubleshooting
procedure for the fault that the user cannot get online when the NE80E/40E is configured with
IPoE stateful PD.
Common Causes
This fault is commonly caused by one of the following:
l
The IPv6 function is not globally enabled.
DUID is not configured globally.
The IPv6 protocol on the user-side interface is Down.
The M/O value has been configured on the user-side interface.
Bind authentication is not configured on the user-side interface with the BAS.
The prefix pool is incorrectly configured.
This section describes the troubleshooting flowchart for the fault that the user cannot get online
when the NE80E/40E is configured with IPoE stateful PD.
The troubleshooting roadmap is as follows:
l
Check that the IPv6 protocol is Up on the user-side interface.
Check that the M/O value has been configured on the user-side interface.
Check that bind authentication has been configured on the interface with the BAS.
Check that address pools have been correctly configured.
Figure 1-21 shows the troubleshooting flowchart.
Issue 03 (2013-08-15)

45

Figure 1-21 Troubleshooting flowchart for the fault that the user cannot get online in the case
of IPoE stateful PD
The stateful PD
user cannot get
online
No
The IPv6 function is
globally enabled?
Yes
Globally enable
the IPv6 function
Yes
Is fault rectified?
No
No
s the DUID function
globally enabled?
Yes
Globally enable
the DUID function
Yes
Is fault rectified?
No
The user-side
interface is
physically up?
No
Ensure that the

user-side interface
is physically up
Yes
Is fault rectified?
No
Yes
The IPv6 protocol

is up on the userside interface?
No
Ensure that the

IPv6 protocol is up
on the interface
Yes
Yes
Is fault rectified?
No
No
Configure the M/O
vaule on the interface
Configure the M/O

vaule on the
interface
Yes
Is fault rectified?
No
Yes
Yes
No
Bind authentication has
been configured on the
user-side interface with
the BAS?
Configure bind
authentication
Is fault rectified?
No
Yes
Issue 03 (2013-08-15)
Are the local address

pool and the delegation
address pool
configured?
Yes
No
Yes
Correctly configure
address pools

No
Is fault rectified?
46
No
Yes

Before performing the following steps, you can refer to Common Causes for Failing to Get
Online and correct the fault according to prompts displayed by the device.
NOTE
Saving the results of each troubleshooting step is recommended. If your troubleshooting fails to correct
the fault, you will have a record of your actions to provide Huawei technical support personnel.
Procedure
Step 1 Check that the IPv6 function is globally enabled.
Run the display this command in the system view to check whether the IPv6 function is globally
enabled. The IPv6 function is disabled by default.
l If ipv6 is not displayed, the IPv6 function is not globally enabled. Run the ipv6 command
in the system view.
l If ipv6 is displayed, the IPv6 function is globally enabled. Go to step 2.
Step 2 Check that the DUID function is globally enabled.
Run the display this command in the system view to check whether the DUID function is
enabled. The DUID function is disabled by default.
l If dhcpv6 duid is not displayed, the DUID function is disabled. Run the dhcpv6 duidduidvalue command in the system view to enable the DUID function.
l If dhcpv6 duid is displayed, go to step 3.
Step 3 Check that the user-side interface is physically Up.
Run the display this ipv6 interface command in the user-side interface view to check whether
the interface is physically Up.
l If current state is down, the physical link is faulty. Remove the link fault.
l If current state is up, the physical link is working properly. Go to step 4.
Step 4 Check that the IPv6 protocol is Up on the user-side interface.
the IPv6 protocol is Up.
l If IPv6 protocol current state is down, check whether the configured link-local address
conflicts with that of the peer device.
l If IPv6 protocol current state is up, go to step 5.
Step 5 Check that the M/O value has been correctly configured on the user-side interface. That is, check
what the ipv6 nd autoconfig managed-address-flag or ipv6 nd autoconfig other-flag
command is displayed.
Run the display this command in the user-side interface view to check whether the M/O value
has been configured.
Issue 03 (2013-08-15)

47

l If ipv6 nd autoconfig managed-address-flag or ipv6 nd autoconfig other-flag is

displayed, go to step 6.
l Otherwise, run the ipv6 nd autoconfig managed-address-flag or ipv6 nd autoconfig otherflag command to correctly configure the M/O value.
Step 6 Check that bind authentication has been configured on the user-side interface with the BAS.
Run the display this command on the user-side interface with the BAS to check whether bind
authentication has been configured.
l If no bind authentication information is displayed, run the authentication-method-ipv6
bind command to configure bind authentication.
l If authentication-method-ipv6 bind is displayed, go to step 7.
Step 7 Check that address pools have been correctly configured.
Run the display ipv6 pool [ pool-name ] command in the system view to check whether a local
address pool and a delegation address pool already associated with prefix pools have been
configured.
l If one of the two address pools is missing, refer to the configuration manual to properly
configure the address pool.
l If both address pools have been configured, go to step 8.
Step 8 Check that the authentication domain has been correctly configured.
Run the display this command in the AAA domain view to check whether the authentication
domain has been correctly configured.
l If the local address pool or the delegation pool is not configured, run the ipv6-pool poolname command to configure the pool.
l If the configuration is correct, go to step 9.
Step 9 Check that there are assignable IPv6 addresses in the address pool.
Run the display ipv6 prefix prefix-name command in the system view to view the Free Prefix
Count field. This field displays the number of assignable addresses in the prefix pool.
Step 10 Collect the following information and contact Huawei technical support personnel.
l Results of the preceding troubleshooting procedure.
l Configuration files, log files, and alarm files of the devices.
----End

Relevant Alarms
None.
Relevant Logs
None.
Issue 03 (2013-08-15)

48

1.4.2 User Cannot Get Online in the Case of IPoE Stateless PD

IPoE stateless PD.
Common Causes
l
DUID is not configured globally.
The unshared mode of prefix assignment is not configured in the domain view.
when the NE80E/40E is configured with IPoE stateless PD.
l
Check that a correct prefix pool has been configured.
Check that the unshared mode of prefix assignment has been configured in the domain
view.
Issue 03 (2013-08-15)

49

of IPoE stateless PD
The stateless PD
user cannot get
online
No
globally enabled?
Globally
enable the
IPv6 function
Yes
Yes
Is fault rectified?
No
No
Yes
Globally enable
the DUID function
Is the DUID function

globally enabled?
No
Yes
The user-side
interface is
physically up?
No
Ensure that the

user-side
interface is
physically up
No
The IPv6 protocol is up
on the user-side
interface?
Ensure that the

IPv6 protocol is
up on the userside interface
Yes
Is fault rectified?
No
Yes
Yes
No
Configure bind
authentication
Is fault rectified?
No
Yes
An ND-unshared
delegation address pool
has been configured?
Yes
Is fault rectified?
No
Yes
Bind authentication
has been configured
on the user-side
interface with the
BAS?
Is fault rectified?
No
Configure an NDunshared
delegation
address pool
Yes
Is fault rectified?
No
Yes
A PD-unshared
Yes
Issue 03 (2013-08-15)
No
Configure a PDunshared
delegation
address pool
Yes
Is fault rectified?
No
Configure the
The unshared mode of
No
prefix assignment and
unshared mode of
address pools have been
Huawei
Proprietary
and Confidential
Is fault rectified?
prefix assignment
correctly configured in
the authentication
and correct
domain view?Copyright Huawei
Technologies
Co.,
Ltd.
address pools
Yes
No
Yes
50

NOTE
Procedure
to enable the IPv6 function in the system view.
Step 2 Check that the DUID function is globally enabled.
Run the display this command in the system view to check whether the DUID function is
enabled. The DUID function is disabled by default.
l If dhcpv6 duid is not displayed, the DUID function is disabled. Run the dhcpv6 duidduidvalue command in the system view to enable the DUID function.
the interface is physically Up.
Issue 03 (2013-08-15)

51


Step 6 Check that a correct ND-unshared prefix pool has been configured.
Run the display ipv6 prefix [ prefix-name [ all | used ] ] command in the system view to check
whether a correct ND-unshared prefix pool has been configured.
l If slaac-unshare-only is FALSE, run the slaac-unshare-only command to correct the
configuration.
l If slaac-unshare-only is TRUE, go to step 7.
Step 7 Check that a correct PD prefix pool has been configured.
Run the display ipv6 pool [ pool-name ] command in the system view to check whether a correct
PD prefix pool has been configured.
l If pd-unshare-only is FALSE, run the pd-unshare-only command in the address pool view
to correct the configuration.
l If pd-unshare-only is TRUE, go to step 8.
l If prefix-assign-mode unshared is not displayed, run the prefix-assign-mode unshared
command to configure the unshared mode of prefix assignment.
l If the local address pool or the delegation pool is not configured, run the ipv6-poolpoolname command to configure the pool.
Run the display ipv6 prefixprefix-name command in the system view to view the Free Prefix
Count field. This field displays the number of assignable addresses in the prefix pool.
l Results of the preceding troubleshooting procedure
l Configuration files, log files, and alarm files of the devices
----End

Relevant Alarms
None.
Relevant Logs
None.
Issue 03 (2013-08-15)

52

1.4.3 User Cannot Get Online in IPv6 IPoE Stateful Access Mode
with a DSLAM Serving as the LDRA
A digital subscriber line access multiplexer (DSLAM) can serve as a layer 2 (L2) forwarding
device capable of handling DHCPv6 relay packets to encapsulate device information in the
header of a DHCPv6 relay packet to be sent to the server. This section describes the
troubleshooting flowchart and provides a step-by-step troubleshooting procedure for the fault
that the user cannot get online or the user's access status type is incorrect when the NE80E/
40E is configured with IPv6 stateful access and a DSLAM serves as the LDRA.
Common Causes
l
The DUID function is not globally enabled.
The IPv6 address pool is incorrectly configured.
The address allocation mode is not configured on the user-side interface.
Bind authentication is not configured on the user-side interface.
when the NE80E/40E is configured with IPv6 IPOE stateful access.
l
Check that the IPv6 function is globally enabled.
Check that the DUID function is enabled in the system view.
Check that a correct IPv6 address pool has been configured.
Check that bind authentication has been configured on the user-side interface.
Check that the address allocation mode has been configured on the user-side interface. (If
the user successfully gets online, check the state of the online user. The address allocation
mode is incorrect.)
Issue 03 (2013-08-15)

53

Figure 1-23 Troubleshooting flowchart for the fault that the user cannot get online or the address
allocation mode is incorrect in the case of IPv6 IPOE stateful access
The user cannot get online
in the case of IPv6 IPOE
stateful access
The IPv6 function is globally

enabled?
No
Yes
Globally enable the

IPv6 function
Is fault rectified?
Yes
No
The DUID function is

globally enabled?
No
Globally enable the

DUID function
Yes
Is fault rectified?
No
Yes
The IPv6 address pool has

been correctly configured?
No
Correctly configure the

IPv6 address pool
Is fault rectified?
Yes
No
Yes
Bind authentication has

been configured on the
user-side interface?
No
Configure bind
authentication on the
interface
Is fault rectified?
Yes
No
Yes
The M value has been

correctly configured on the
user-side interface
No
Configure the M value

and stateful access
Is fault rectified?
Yes
No
Yes
Seek technical support

End
Issue 03 (2013-08-15)

54

NOTE
Procedure
in the system view.
Step 2 Check that the DHCPv6 DUID generation mode is globally enabled.
Run the display this command in the system view to check whether the DHCPv6 DUID function
is globally enabled.
l If dhcpv6 duid is not displayed, run the dhcpv6 duid llt command in the system view.
Step 3 Check that an IPv6 address pool has been correctly configured.
Run the display this command in the AAA domain view to check whether a correct IPv6 address
pool has been configured.
l If the configured IPv6 address pool is incorrect, configure a correct IPv6 address pool in the
AAA domain.
l If the IPv6 address pool has been correctly configured, go to step 4.
Step 4 Check that bind authentication has been configured on the user-side interface.
Run the display this command in the user-side interface view to check whether bind
authentication has been configured. That is, check whether authentication-method-ipv6
bind is displayed.
l If bind authentication is not configured, run relevant commands to configure it.
l If bind authentication has been configured, go to step 5.
Step 5 Check that the address allocation mode has been configured in the domain view.
Run the display access-user user-iduser-id [ verbose ] command after the user gets online. If
the command output indicates that the user address is not obtained using DHCP, enter the userside interface view and run the display this command to check whether the address allocation
mode has been configured. If the ipv6 nd autoconfig managed-address-flag command is
displayed, the address allocation mode has been configured.
l If the address allocation mode is not configured, run the ipv6 nd autoconfig managedaddress-flag command in the user-side interface view to configure the address allocation
mode.
Issue 03 (2013-08-15)

55

l If the address allocation mode has been configured, go to step 6.

----End

Relevant Alarms
None.
Relevant Logs
None.
1.4.4 DHCPv6 User Fails to Get Online Through the Remote

Address Pool
procedure for the fault that the user cannot get online in remote address pool mode through the
NE80E/40E.
Common Causes
l
The IPv6 function was not globally enabled.
The DUID function was not globally enabled.
The remote address pool was incorrectly configured.
The remote server was incorrectly configured.
Bind authentication was not configured on the user-side interface.
The address allocation mode was incorrectly configured on the user-side interface.
The IPv6 address configured for the network-side interface and the IPv6 address of the
remote DHCPv6 server were in different network segments.
in DHCPv6 remote address pool mode through the NE80E/40E.
l
Issue 03 (2013-08-15)

56

Check that the remote address pool has been correctly configured.
Check that the remote server has been correctly configured.
Check that bind authentication has been configured on the user-side interface.
Check that the address allocation mode has been correctly configured on the user-side
interface.
Issue 03 (2013-08-15)

57

Figure 1-24 Troubleshooting flowchart for the fault that the user cannot get online in DHCPv6
remote address pool mode
Addresses cannot be
obtained from the DHCPv6
remote address pool
No
globally enabled?
Yes
Globally enable
the IPv6 function
Is fault rectified?
Yes
No
The DHCPv6 DUID

function is globally
enabled?
No
Globally enable
the DHCPv6
DUID function
Yes
Is fault rectified?
Yes
No
The remote
address pool has
been correctly
configured?
No
Correctly
configure the
remote address
pool
Yes
Is fault rectified?
Yes
No
The remote server

has been correctly
configured?
No
Correctly
configure the
remote server
Yes
Is fault rectified?
No
Yes
Bind configuration
has been configured
on the user-side
interface
Yes
No
Configure bind
configuration
Is fault rectified?
No
Yes
The M value has

been correctly
configured on
the user-side
interface
No
Yes
Correctly
configure the M
value
Is fault rectified?
Yes
No
Contact Huaweri
technical support
engineers
Issue 03 (2013-08-15)

End
58

NOTE
Procedure
Run the display current-configuration command to check whether the IPv6 function is globally
in the system view to enable the IPv6 function.
Step 2 Check that the DHCPv6 DUID function is globally enabled.
Run the display this command to check whether the DHCPv6 DUID function is globally
enabled.
l If dhcpv6 duid is not displayed, run the dhcpv6 duid { duid-value | llt } command in the
system view.
Step 3 Check that the remote address pool has been correctly configured.
Verify that a remote prefix pool is configured. Run the display this command in the remote
prefix pool view to check whether a correct link address has been configured.
l If the link address is not configured, run the link-address link-address/prefix-length
command to correctly configure the link address.
l If the link address has been correctly configured, go to step 4.
Step 4 Check that the remote server has been correctly configured.
Run the display dhcpv6-server group group-name command in the system view to check the
status of the remote server.
l If the remote server is not Up, correctly configure the remote server group and associate the
group with the remote address pool.
l If the remote server is Up, go to step 5.
Step 5 Check that bind authentication has been configured on the user-side interface.
Run the display this command in the user-side interface view to check whether bind
authentication has been configured. If the authentication-method-ipv6 bind command is
displayed, bind authentication has been configured.
Issue 03 (2013-08-15)

59

l If bind authentication is not configured, run the authentication-method-ipv6 bind

command to configure bind authentication in the user-side interface view.
l If bind authentication has been configured, go to step 6.
Step 6 Check that the M value has been correctly configured on the interface.
Run the display this command in the user-side interface view to check whether the address
allocation mode has been configured. If the ipv6 nd autoconfig managed-address-flag
command is displayed, the address allocation mode has been configured.
l If the address allocation mode is not configured, run the ipv6 nd autoconfig managedaddress-flag command to configure the address allocation mode in the user-side interface
view.
----End

Relevant Alarms
None.
Relevant Logs
None.
1.4.5 IPv6 PPPoE Access Troubleshooting

This section describes the notes about configuring PPPoE access, and provides the PPPoE access
troubleshooting flowchart and the troubleshooting procedure in a typical PPPoE access
networking.
Typical Networking
Figure 1-25 shows the typical networking of PPPoE access. PPPoE access troubleshooting is
based on this networking.
Issue 03 (2013-08-15)

60

Figure 1-25 Typical networking diagram of PPPoE access

RADIUS server
DNS server
3001:0410::1:2
Access
Network
subscriber
@isp5
129.6.55.55
GE7/0/3
GE8/0/3
Internet
Router
As shown in Figure 1-25:

l
The user is connected to the NE80E/40E through a Layer 2 network, and the user gets online
by dialing in through PPP.
The NE80E/40E is connected to the RADIUS server to implement authentication and

accounting for users.
The NE80E/40E is connected to an IPv6 DNS server.
The user accesses the NE80E/40E through PPPoE. The NE80E/40E assigns an IPv6 address to
the user and manages the user.
On the network shown in Typical Networking, a user accesses the router through PPPoE;
however, the user cannot obtain an IPv6 address and therefore fails to get online. You can locate
the fault based on the following troubleshooting flowchart.
Issue 03 (2013-08-15)

61

Figure 1-26 Troubleshooting flowchart of PPPoE access

A Client cannot get online
Does the
physical connection
between the client and the
server work
normally?
No
Check the
physical connection
between the client and
the server
Yes
Is fault
rectified?
No
Yes
Is the
configuration of the interface
correct?
No
Check the
configuration of the
interface
Yes
Is fault
rectified?
No
Yes
Is the prefix
pool configured
and Is a prefix address
configured for
the pool?
No
Configure a prefix
address and configure
a prefix address for
the pool
Yes
Is fault
rectified?
No
Yes
Is an
address pool
configured and some
addresses bound to this
address pool?
No
Configure an address
pool and bind some
addresses to the
address pool
Yes
Is fault
rectified?
No
Yes
Is the IPv6
address pool bound to
the user domain?
No
Bind the IPv6 address

pool to the user
domain
No
Yes
Does
the address
pool have an available
address to be allocated
to the client?
No
Configure a new
address pool, prefix
pool, and prefix
addressed
Yes
Yes
Is fault
rectified?
No
Issue 03 (2013-08-15)
Yes
Is fault
rectified?

End
62

Procedure
Step 1 Check that the physical connection between the client and server works properly.
Check whether the client and server can ping through each other. If they can ping through each
other, the physical connection between them works properly. If they fail to ping through each
other, rectify the fault on the physical connection, and then check whether the problem persists.
If the problem persists, go to Step 2.
Step 2 Check that the configuration of the interface connecting the server to the client is correct.
Run the display this command in the interface view to check whether the configuration of the
interface is correct. For the correct interface configuration, refer to the chapter "Configuring the
IPv6 Access Service" in the Configuration Guide - BRAS.
l If the interface configuration is incorrect, modify the interface configuration to be correct.
For details, refer to the chapter "Configuring the IPv6 Access Service" in the Configuration
Guide - BRAS.
l If the interface configuration is correct, go to Step 3.
Step 3 Check that the prefix pool is correctly configured.
Run the display ipv6 prefix command in the system view to check whether an IPv6 prefix pool
is configured.
l If there is no IPv6 prefix pool, run the ipv6 prefix prefix-name local command to create the
local prefix pool, enter the prefix pool view, and then run the prefix prefix-address prefixlength command to configure an IPv6 prefix address.
l If there is an IPv6 prefix pool, run the ipv6 prefix prefix-name command to enter the prefix
pool view, and then run the display this command to check whether an IPv6 prefix address
is configured in this prefix pool. If no IPv6 prefix address is configured in this prefix pool,
run the prefix prefix-address prefix-length command to configure an IPv6 prefix address.
Step 4 Check that the address pool is correctly configured.
Run the display ipv6 pool command in the system view to check whether an IPv6 address pool
is configured.
l If there is no IPv6 address pool, run the ipv6 pool pool-name bas local command to create
the local address pool, enter the address pool view, and then run the prefix prefix-name
command to bind the prefix pool in Step 3 to this address pool.
l If there is an IPv6 address pool, run the ipv6 pool pool-name command to enter the address
pool view, and then run the display this command to check whether this address pool is
bound to the prefix pool in Step 3. If they are not bound, run the prefix prefix-name command
to bind the prefix pool in Step 3 to this address pool.
Step 5 Check that the user domain is bound to the IPv6 address pool.
Run the display this command in the AAA view to check whether the user domain is bound to
an IPv6 address pool.
Issue 03 (2013-08-15)

63

l If the user domain is not bound to the IPv6 address pool, run the ipv6-pool pool-name
command in the domain view to bind the user domain to the IPv6 address pool.
l If the user domain is bound to the IPv6 address pool, go to Step 6.
Run the display ipv6 prefix prefix-name all command in the system view to check whether the
number of online users in the prefix pool reaches 1024.
l If the value of the Online-user field is displayed as 1024, there are no assignable addresses
in this prefix pool. In this case, configure a new prefix pool and a new address pool and then
bind the new address pool to the user domain.
l If the value of the Online-user field is less than 1024, there are assignable addresses in this
prefix pool.
If the client still cannot obtain an IPv6 address, contact Huawei technical personnel.
Step 7 Check that the system is not suppressed from advertising RA messages.
Run the display this command in the AAA domain view to check whether the router is
suppressed from sending RA messages in the user domain.
If the client needs to obtain IPv6 addresses using stateless address autoconfiguration, the router
cannot be suppressed from sending RA messages. If the router is not suppressed from sending
RA messages and the client still cannot obtain an IPv6 address, contact Huawei technical support
personnel.
----End
1.4.6 User Cannot Get Online or the User's Access Type Is Incorrect
in the Case of PPPoE IPv6 Stateful Access
procedure for the fault that the user cannot get online or the user's access type is incorrect when
the NE80E/40E is configured with PPPoE IPv6 stateful access.
Common Causes
l
The DUID function is not globally enabled.
The IPv6 address pool is incorrectly configured.
The address allocation mode is not configured.
The authentication mode is not set to PPP on the BAS interface.
The user information indicates that the user cannot get online when the NE80E/40E is configured
with PPPoE IPv6 stateful access.
Issue 03 (2013-08-15)

64


l
Check that a correct IPv6 address pool has been configured.
Check that the authentication mode has been set to PPP on the BAS interface.
The user successfully gets online. Query the status of the online user. The results, however,
indicate that the address allocation mode is incorrect.
l
Check that the address allocation mode has been configured in the domain view.

Figure 1-27 Troubleshooting flowchart for the fault that the user cannot get online or the address
allocation mode is incorrect in the case of IPv6 PPPoE stateful access
The user cannot get
online in the case of
PPPoE IPv6 stateful
access

globally enabled?
No
Globally enable the

IPv6 function
Yes
Is fault rectified?
No
Yes
No
Globally enable the
DUID function
The DUID function is

globally enabled?
Yes
Is fault rectified?
No
Yes
No
The IPv6 address pool has
been correctly configured?
Correctly configure
the IPv6 address pool
No
Yes
The M value has been

configured in the
domain view?
No
Configure the M value

and stateful access
Yes
Is fault rectified?
No
Yes
Seek technical
support
Issue 03 (2013-08-15)
Yes
Is fault rectified?

End
65

NOTE
Procedure
Step 2 Check that the DHCPv6 DUID function is globally enabled.
Run the display current-configuration command to check whether the DHCPv6 DUID
function is globally enabled.
l If dhcpv6 duid is not displayed, run the dhcpv6 duid llt command in the system view.
Step 3 Check that the IPv6 address pool has been correctly configured.
Run the display this command in the authentication domain view to check whether a correct
IPv6 address pool has been configured.
l If the configured IPv6 address pool is incorrect, configure a correct IPv6 address pool in the
authentication domain view.
Step 4 Check that the authentication mode has been set to PPP on the BAS interface.
Run the display this command on the user access interface to check whether the authentication
mode has been set to PPP on the interface with the BAS.
l If the authentication mode is not ppp, run the authentication-method-ipv6 ppp command
on the interface with the BAS to change the authentication mode to PPP.
l If authentication-method-ipv6 is not displayed, the authentication mode is PPP by default.
Go to step 5.
Step 5 Check that the address allocation mode has been configured in the domain view.
If the user properly gets online, run the display access-user user-id user-id command. If the
display information indicates that the way to obtain the user address is incorrect, check whether
the address allocation mode has been configured in the domain view. If the ipv6 nd autoconfig
managed-address-flag command is displayed, the address allocation mode has been
configured.
Issue 03 (2013-08-15)

66

l If the address allocation mode is not configured, run relevant commands to correctly
configure it.
----End

Relevant Alarms
None.
Relevant Logs
None.
1.4.7 IPv6 ND Access Troubleshooting

This section describes the notes about configuring ND access, and provides the ND access
troubleshooting flowchart and the troubleshooting procedure in a typical ND access networking.
Typical Networking
Figure 1-28 shows the typical networking of ND access. ND access troubleshooting is based
on this networking.
Figure 1-28 Typical networking diagram of ND access
RADIUS server
DNS server
3001:0410::1:2
Access
Network
subscriber
@isp6
129.6.55.55
GE7/0/3
GE8/0/3
Internet
Router

l
Issue 03 (2013-08-15)
The user accesses the NE80E/40E through a Layer 2 network.

67


accounting for the user.
The user accesses the NE80E/40E in ND mode. The NE80E/40E assigns an IPv6 prefix to the
user and manages the user.
On the network shown in Typical Networking, after a local address pool is configured, the user
cannot obtain an IPv6 address and therefore fails to get online. You can locate the fault based
on the following troubleshooting flowchart.
Issue 03 (2013-08-15)

68

Figure 1-29 Troubleshooting flowchart of ND access

A client cannot get
online
Does the physical

connection between the
client and the server work
normally?
No
Check the physical

client and the server
Is fault rectified?
No
Yes
Is the configuration of
the interface correct?
No
Check the
interface
Yes
Is fault rectified?
No
Yes
Is an prefix pool
configured and is a prefix
address configured for the
pool?
No
Configure a prefix
address and configure a
prefix address for the
pool
Yes
Is fault rectified?
No
Yes
Is an address pool
configured and are some
address pool?
No
pool and bind some
addresses to the
address pool
Yes
Is fault rectified?
No
Yes
Is the IPv6 address

pool bound to the user
domain?
No

pool to the user domain
Yes
Is fault rectified?
Yes
No
Does the address pool

have an available address
to be allocated to the
client?
No
Configure a new
address pool, prefix
pool, and prefix
addresses
Yes
Is fault rectified?
No
Yes
Seek technical
support
Issue 03 (2013-08-15)
Yes

End
69

Procedure
other, it indicates that the physical connection between them works properly. If they fail to ping
through each other, you need to rectify the fault on the physical connection, and then check
whether the problem persists. If the problem persists, go to Step 2.
l If the interface configuration is incorrect, you need to modify the interface configuration to
be correct. For details, refer to the chapter "Configuring the IPv6 Access Service" in the
Configuration Guide - BRAS.
Step 3 Check that the ND prefix pool is correctly configured.
is configured.
l If there is no IPv6 prefix pool, run the ipv6 prefix prefix-name delegation command to create
a delegation prefix pool, enter the prefix pool view, and then run the prefix prefix-address
delegating-prefix-length command to configure an IPv6 prefix address.
pool view, and then run the display this command to check whether an IPv6 prefix address
is configured in this prefix pool. If no IPv6 prefix address is configured in this prefix pool,
run the prefix prefix-address delegating-prefix-length command to configure an IPv6 prefix
address.
Run the display this command to view configurations. Check whether the slaac-unshareonly command is displayed. If the command is not displayed, run the slaac-unshare-only
command.
is configured.
l If there is no IPv6 address pool, run the ipv6 pool pool-name bas delegation command to
create the delegation address pool, enter the address pool view, and then run the prefix prefixname command to bind the prefix pool in Step 3 to this address pool.
Issue 03 (2013-08-15)

70


Step 5 Check that the user domain is bound to an IPv6 address pool.
command in the domain view to bind the user domain to the IPv6 address pool.
l If the user domain is bound to the IPv6 address pool, go to Step 6.
Run the display ipv6 prefix prefix-name used command in the system view to check whether
the number of assignable IPv6 prefixes is 0.
l If the value of the Free Prefix Count field is displayed as 0, there is no assignable address in
this prefix pool. In this case, configure a new prefix pool and a new address pool and then
bind the new address pool to the domain to which the client belongs.
l If the value of the Free Prefix Count field is not displayed as 0, there are assignable addresses.
----End
1.4.8 ND-Unshared User Cannot Get Online

ND-unshared access.
Common Causes
l
The M/O value has been configured on the user-side interface.
The unshared mode of prefix assignment is not configured in the domain view.
when the NE80E/40E is configured with ND-unshared access.
l
Check that the M/O value is disabled on the user-side interface. The M/O value is disabled
by default.
Issue 03 (2013-08-15)

71

Check that a correct prefix pool has been configured.
Check that the unshared mode of prefix assignment has been configured in the domain
view.
Issue 03 (2013-08-15)

72

Figure 1-30 Troubleshooting flowchart for the fault that the ND-unshared user cannot get online
The ND-unshared
user cannot get
online

globally enabled?
No
Yes
Globally enable
the IPv6 function
Yes
Is fault rectified?
No
The user-side interface is

physically up?
No
Ensure that
the user-side
interface is
physically up
Yes
Is fault rectified?
Yes
No

on the user-side
interface?
No
Ensure that the

IPv6 protocol is
up on the userside interface
Yes
Yes
Is fault rectified?
No
The M/O value is

disabled on the userside interface?
No
Ensure that the

M/O vaule is not
configured on the
user-side
interface
Yes
Is fault rectified?
No
Yes
Bind authentication
has been configured
on the user-side
interface with the
BAS?
No
Yes
Configure bind
authentication
Is fault rectified?
No
Yes
An ND-unshared
No
Configure an NDunshared
delegation
address pool
The unshared
No
mode of prefix
Configure the
assignment has
been configured in
unshared mode
the authentication
domain view? Huawei Proprietary and Confidential

Yes
Is fault rectified?
No
Yes
Issue 03 (2013-08-15)
Yes
Yes
Is fault rectified?
73
No

NOTE
Procedure
in the system view.
Run the display this interface command in the user-side interface view to check whether the
interface is physically Up.
Step 4 Check that the M/O value is disabled on the user-side interface.
Run the display this command in the user-side interface view to check whether the M/O value
is configured. If ipv6 nd autoconfig managed-address-flag or ipv6 nd autoconfig otherflag is displayed, the M/O value is configured.
l If the M/O value has been configured, delete the configuration.
l If the M/O value is not configured, go to step 5.
Issue 03 (2013-08-15)

74


Step 6 Check that a correct prefix pool has been configured.
Run the display ipv6 prefix [ prefix-name [ all | used ] ] command in the system view to check
whether a correct prefix pool has been configured.
l If slaac-unshare-only is FALSE, run the slaac-unshare-only command to correct the
configuration.
l If slaac-unshare-only is TRUE, go to step 7.
Step 7 Check that the unshared mode of prefix assignment has been configured in the authentication
domain view.
l If prefix-assign-mode unshared is not displayed, run the prefix-assign-mode unshared
command to configure the unshared mode of prefix assignment.
l If prefix-assign-mode unshared is displayed, go to step 8.
----End

Relevant Alarms
None.
Relevant Logs
None.
1.4.9 User Cannot Get Online in the Case of Network-Side Relay

and QinQ Configuration
A user packet carries double VLAN tags. You can configure the user access port on the NE80E/
40E as a QinQ interface, so that the NE80E/40E serves as the DHCP relay agent to send the
packet to the remote server. You can also configure Layer 3 access on the ports of the NE80E/
40E serving as the server. This section describes the troubleshooting flowchart and provides a
step-by-step troubleshooting procedure for the fault that the user cannot get online when the
NE80E/40E is configured as a network-side relay agent.
Common Causes
Issue 03 (2013-08-15)

75

The DUID was not globally configured.
The IPv6 function was not globally enabled.
The interface was physically down.
QinQ was not configured on the inbound interface of the relay agent.
An IPv6 global unicast address was not configured for the inbound interface of the relay
agent.
No IPv6 address for the relay or BAS interface was configured on the inbound interface of
the relay agent.
No M value was configured on the inbound interface of the relay agent.
No IPv6 link-local address was configured on the the inbound or outbound interface of the
relay agent.
IPv6 was disabled on the inbound or outbound interface of the relay agent.
The IPv6 addresses configured on the BAS port and outbound interface of the relay agent
were in different network segments.
Layer 3 access was not configured on the user-side interface of the server.
An IPv6 relay address pool was not configured on the server.
The server only supported 64-bit local prefix pool.
when the NE80E/40E is configured with QinQ and as a network-side relay agent.
l
Check that QinQ has been correctly configured on the inbound interface of the relay agent.
Check that a correct IPv6 global unicast address has been configured for the inbound
interface of the relay agent.
Check that an outbound interface has been configured for the inbound interface of the relay
agent.
Check that the address allocation mode has been configured.
Check that the IPv6 address configured for the outbound interface of the relay agent and
that configured for the BAS interface of the directly-connected server are within the same
network segment.
Check that an IPv6 relay address pool has been configured on the server.
NOTE
Issue 03 (2013-08-15)

76

Procedure
l If ipv6 is not displayed, the IPv6 function is not globally enabled. Configure the ipv6 function
in the system view.
Step 2 Check that the inbound interface of the relay agent is physically up.
Run the display this interface command in the inbound interface view of the IPv6 relay agent
to check whether the interface is physically up.
Step 3 Check that QinQ has been configured on the inbound interface of the relay agent.
If users are Layer 3 users, configure the termination mode. Run the mode user-termination
command on a main interface, and run the control-vid vid qinq-termination command on its
sub-interface.
Run the display this command in the inbound interface view of the relay agent to check whether
QinQ has been correctly configured. That is, check whether qinq termination pe-vid pe-vid
ce-vid { low-ce-vid [ to high-ce-vid ] } [ sub-group groupname ] is displayed.
l If QinQ is incorrectly configured on the interface, run relevant commands to correctly
configure QinQ.
l If QinQ is correctly configured, go to step 4.
Step 4 Check that a correct IPv6 address has been configured for the inbound interface of the relay
agent.
a correct IPv6 global unicast address has been configured. That is, check whether ipv6 address
{ ipv6-address prefix-length | ipv6-address/prefix-length } is displayed.
l If the IPv6 global unicast address is not configured, run relevant commands to configure a
correct IPv6 global unicast address.
l If a correct IPv6 address has been configured, go to step 5.
Step 5 Check that an outbound interface has been configured for the inbound interface of the relay
agent.
an outbound interface has been configured for the relay agent. That is, check whether dhcpv6
relay interface is displayed.
l If the outbound interface of the relay agent is not configured, run relevant commands to
configure the outbound interface.
l If the outbound interface of the relay agent has been configured, go to step 6.
Step 6 Check that the address allocation mode has been configured on both the inbound interface and
the outbound interface of the relay agent.
Issue 03 (2013-08-15)

77

Run the display this command in the inbound interface view and outbound interface view of
the relay agent to check whether the address allocation mode has been configured. If ipv6 nd
autoconfig managed-address-flag is displayed, the address allocation mode is configured.
l If the address allocation mode is not configured, run relevant commands to configure the
mode.
Step 7 Check that the IPv6 address configured for the outbound interface of the relay agent and that
configured for the inbound interface of the directly-connected server are within the same network
segment.
Run the display this command in the outbound interface view of the relay agent to check whether
the IPv6 address configured for the outbound interface of the relay agent and that configured
for the inbound interface of the directly-connected server are within the same network segment.
l If the two addresses are not within the same network segment, reconfigure them so that they
are within the same network segment.
l If the two addresses are within the same network segment, go to step 8.
Step 8 Check that layer 3 access has been configured on the BAS interface of the server.
Run the display this command on the BAS interface view of the server to check whether L3
access has been configured on the BAS interface of the server.
l If L3 access is not configured on the BAS interface of the server, configure L3 access for the
BAS interface. For details, refer to the configuration manual.
l If L3 access has been configured on the BAS interface of the server, go to step 10.
Step 9 Check that a relay address pool has been configured on the server.
Run the display ipv6 pool [ pool-name ] command on the system view of the server to check
whether a relay address pool has been configured.
l If the relay address pool is not configured, configure an IPv6 address pool of the relay type.
l If the relay address pool has been configured, go to step 11.
----End

Relevant Alarms
None.
Relevant Logs
None.
Issue 03 (2013-08-15)

78

1.4.10 IPv6 Layer 3 Leased Line User Cannot Get Online

IPv6 Layer 3 leased line access.
Common Causes
l
The interface is physically down.
The link layer protocol of the interface is down.
The configured username or password is incorrect.
The authentication domain is incorrectly configured.
when the NE80E/40E is configured with Layer 3 leased line access.
l
Check that the physical connection of the interface configured with the Layer 3 leased line
service is normal. If the interface is a trunk interface, check that the member interfaces of
the trunk interface are normal.
Check that an IPv6 address has been correctly configured on the user access interface.
Check that the IPv6 function is globally enabled in the system view.
Check that correct Layer 3 leased line user information has been configured on the interface
with the BAS.
Issue 03 (2013-08-15)

79

of IPv6 Layer 3 leased line access
The user cannot get
online in the case of IPv6
L3 private line access

globally enabled?
No

globally enabled?
Yes
Is fault rectified?
No
Yes
The interface configured

with the L3 private line
service is physically up?
Ensure that the userside interface is

physically up
Yes
Is fault rectified?
No
Yes
A correct IPv6 address

No

IPv6 address
Yes
Is fault rectified?
No
Yes

on the interface
configured with the L3
private line service?
No
Ensure that the IPv6

protocol is up on the
interface
Yes
Is fault rectified?
No
Yes
The configured user

name and password are
correct?
No
Modify L3 private line

configuration to ensure
that the user name and
password are correct
Yes
Is fault rectified?
No
Yes
The authentication domain has

been specified?
No
Correctly specify the

authentication domain
Yes
Is fault rectified?
Yes
Seek technical
support
No
End
Issue 03 (2013-08-15)

80

NOTE
Procedure
Run the display this interface command on the interface configured with the IPv6 Layer 3
leased line service to check whether the interface is physically Up.
Step 3 Check that the IPv6 address has been correctly configured.
Run the display this command on the interface configured with the IPv6 Layer 3 leased line
service to check whether a correct IPv6 global unicast address has been configured.
l If the global unicast IPv6 address is not configured, run relevant commands to configure a
correct IPv6 global unicast address.
l If a correct IPv6 global unicast address has been configured, go to step 4.
Step 4 Check that the user name and password in Layer 3 leased line configuration information are
correct.
service to check whether the user name and password in IPv6 Layer 3 leased line configuration
information are consistent with the plan.
l If the user name and password are inconsistent with the plan, run the access-type layer3leased-line user-name uname password { cipher | simple } password [ default-domain
authentication dname ] command to correct the configuration information about the user
name and password of the leased line user.
l If the user name and password are consistent with the plan, go to step 5.
service to check whether the configured authentication domain is correct.
Issue 03 (2013-08-15)

81

l If the authentication domain is incorrectly configured, run the undo access-type to delete
the Layer 3 leased line user, and then run the access-type layer3-leased-line user-name
uname password { cipher | simple } password [ default-domain authentication dname ]
command to reconfigure the authentication domain for the Layer 3 leased line user.
l If the authentication domain has been correctly configured, go to step 6.
----End

Relevant Alarms
None.
Relevant Logs
None.
1.4.11 Static Users Cannot Get Online

procedure for the fault that Layer 2 or Layer 3 static users cannot get online.
Common Causes
l
The source address of the packet from the user is not the configured static user address.
The address of the PD access user does not match the PD prefix configured for static users.
For an L2 static user, if detect is configured, the NE80E/40E will initiate an NS packet,
and the user will return an NA packet in the normal case. The user, however, may fail to
get online or may fail to return the NA packet for reasons such as line faults or firewall
protection, causing a probe failure.
If the access user is an L2 static user, the L2 information about the user, such as the source
MAC address and VLAN ID, is different from the L2 information configured through the
command line.
The user access interface is not the interface configured for static users.
The ARP/ND Trigger is not configured or does not act when the NE80E/40E needs to
initiate an ND packet to trigger user access; or the IPv4/v6 Trigger is not configured or
does not act when NE80E/40E needs to initiate an IPv4/IPv6 packet to trigger user access.
Issue 03 (2013-08-15)

82

This section describes the troubleshooting flowchart for the fault that a Layer 2 or Layer 3 static
user cannot get online through IPv4/IPv6 or ND packet triggering.
l
Check that the source address of the request packet from the IPv6 or PD user is consistent
with the configured static user address or PD prefix.
If the user to get online is a Layer 2 static user, check that the Layer 2 information about
the user, such as the source MAC address and VLAN ID, is consistent with the Layer 2
information configured through the command line.
Check that the user access interface is the interface configured for static users.
Check that ARP/ND Trigger or IPv4/v6 Trigger has been configured.
Check that the detect keyword has been configured in the buildrun information about static
users.
Issue 03 (2013-08-15)

83

Figure 1-32 Troubleshooting flowchart for the fault that a Layer 2 static user cannot get online
The user cannot get
online
The source address

of the request packet
from the IPv6 or PD
user is the IPv6
address or PD prefix
configured for the
static user
No
Ensure that the source

address of the packet is
the address configured
for the static user
Yes
Is fault rectified?
No
Yes
The L2 information about

the user matches the L2
information configured for
static users
No
Modify the L2
information about
static users
Yes
Is fault rectified?
No
Yes
The address pools,

authentication scheme, and
accounting scheme have
been correctly configured
in the domain view?
No
Correctly configure
them against the
configuration manual
Yes
Is fault rectified?
No
Yes
The authentication mode

configured on the interface with
the BAS is correct?
Correctly configure
them against the
Is fault rectified?
Yes
No
Yes
Are ND Trigger and IPv6

Trigger correctly configured?
No
Correctly configure
them against the
Is fault rectified?
Yes
No
Yes
No
The detect keyword has been
configured?
Yes
Correctly configure
the detect keyword
Is fault rectified?
No
Yes
Issue 03 (2013-08-15)

Seek technical
support
84
End

NOTE
Procedure
Step 1 Check that the source address of the request packet from the IPv6 or PD user is the IPv6 address
or PD prefix configured for the static user.
Run the display static-user [ [description ] interfaceinterface-type interface-number | { ipaddressstart-ip-address [ end-ip-address ] | ipv6-addressstart-ipv6-address [ end-ipv6address ] | delegation-prefixstart-ipv6-prefix [ end-ipv6-prefix ] prefix-length } [ vpninstanceinstance-name ] ] * command to check whether the IPv6 address or PD prefix has been
configured for the access user.
l If the IPv6 address or PD prefix is not configured, run relevant commands to correctly
configure the IPv6 address or PD prefix.
l If the IPv6 address or PD prefix has been configured, go to step 2.
Step 2 Check that the Layer 2 information about the access user matches the Layer 2 information
configured for static users.
Run the display this command in the system view of the HUAWEI NetEngine80E/40E to check
buildrun information about static users and the user's Layer 2 information, including whether
the source MAC address and VLAN ID configured for the user are correct.
NOTE
The Layer 2 information is optional. If configured, however, it must match the user's configuration
information.
l If the Layer 2 information about static users does not match the user's Layer 2 information,
run the undo static-user { start-ip-address [ end-ip-address ]| start-ipv6-address [ end-ipv6address ] | [ delegation-prefixstart-ipv6-prefix [ end-ipv6-prefix ] prefix-length ] } [ vpninstanceinstance-name ] command to cancel the configuration, and then configure correct
static user information.
l If the Layer 2 information about static users matches the user's Layer 2 information, go to
step 3.
Step 3 Check that the address pools, authentication scheme, and accounting scheme have been correctly
configured in the domain view.
Run the aaa command in the system view to enter the AAA view, and then run the display
this command to check configuration information about the domain to which the access user
belongs.
Issue 03 (2013-08-15)

85

l If the authentication scheme is not configured or incorrectly configured, run the

authentication-schemescheme-name command to add an authentication scheme or modify
the authentication scheme.
l If the accounting scheme is not configured or incorrectly configured, run the accountingschemescheme-name command to add an accounting scheme or modify the accounting
scheme.
l If no address pool has been configured in the domain view, run the ipv6-poolpool-name
command to add the address pool to the domain.
If the configuration is correct, go to step 4.
Step 4 Check that the authentication mode configured on the interface with the BAS is correct.
Enter the user access interface, and then run the display this command to check whether the
authentication mode configured on the interface with the BAS is bind authentication.
l If the authentication mode is not bind authentication, run the authentication-method-ipv6
bind command in the BAS interface view to set the authentication mode to bind
authentication.
l If the authentication mode is bind authentication, go to step 5.
Step 5 Check that ND Trigger and IPV6 Trigger have been correctly configured.
Enter the user access interface, and then run the display this command to check whether the
BAS interface configuration information is correct. That is, whether access-typelayer2subscriber [ default-domain { [ authentication [ force | replace ] dname ] [ preauthenticationpredname ] } | bas-interface-namebname | accounting-copyRADIUSserverrd-name ]* and authentication-method-ipv6 bind is displayed. Ensure that at least one
of ND Trigger and IPV6 Trigger has been configured.
l If ND Trigger and IPV6 Trigger are not configured, run relevant commands to correctly
configure them.
Step 6 Check that the detect keyword has been configured through the command line.
Enter the system view, and then run the display this command to check whether the detect
keyword has been configured in the buildrun information about static users.
l If the detect keyword is not configured, run the undo static-user { start-ip-address [ endip-address ]| start-ipv6-address [ end-ipv6-address ] | [ delegation-prefixstart-ipv6-prefix
[ end-ipv6-prefix ] prefix-length ] } [ vpn-instanceinstance-name ] command to delete the
static user, and then run the static-user[description ] { start-ip-address [ end-ip-address ]
gatewayip-address| start-ipv6-address [ end-ipv6-address ] [ delegation-prefixstart-ipv6prefix [ end-ipv6-prefix ] prefix-length ] ipv6-gatewayipv6-address } *[ vpninstanceinstance-name ] [ domain-namedomain-name | interfaceinterface-typeinterfacenumber [ vlanvlan-id [ qinqqinq-vlan ] | pvcvpi/vci ] | mac-addressmac-address | detect ]
* command to configure the detect keyword.
l If the detect keyword has been configured, go to step 7.
Issue 03 (2013-08-15)

86


----End

Relevant Alarms
None.
Relevant Logs
None.
1.4.12 Interconnection Fails Between the Device and the RADIUS

Server
procedure for the fault that the interconnection fails between the device and the RADIUS server.
Common Causes
l
The share-key configured on the device is inconsistent with the share-key configured on
the RADIUS server.
The physical network between the device and the RADIUS server fails.
The RADIUS server becomes faulty.
The user information sent by the device to the RADIUS server is incorrect, causing an
authentication failure.
Network access server (NAS) records on the RADIUS server do not contain any
information about the device.
If the user cannot get online after the RADIUS authentication policy and the RADIUS server
group are configured in the domain view, run the display aaa offline-record command to check
the item User offline reason.
The interconnection between the RADIUS server and the device fails if User offline reason is
displayed as one of the following:
l
RADIUS authentication reject
RADIUS authentication request send fail

Issue 03 (2013-08-15)

87

If the failure cause is displayed as RADIUS authentication request send fail, run the
ping command to check the connectivity of the physical network between the device and
the RADIUS server.
If the failure cause is displayed as RADIUS authentication reject, check the reply message
returned by the RADIUS server to determine the fault cause. Alternatively, run the testaaa user-name password RADIUS-group group-name [ chap | pap ] [ test-group testgroup-name ] command with user access attributes to locate the server reject cause.
Issue 03 (2013-08-15)

88

Figure 1-33 Troubleshooting flowchart for the interconnection failure between the RADIUS
server and the device
The RADIUS
user cannot get
online
The RADIUS server fails

to send the packet?
Check the physical

network connection
between the device
and the RADIUS
server
Yes
Is fault
rectified?
Yes
No
No
Check and modify
RADIUS-related
configuration
information on the
device
Is fault
rectified?
Rectify the RADIUS

server fault
Is fault
rectified?
Yes
No
Yes
No
Confirm that the

share-key and
NAS IP address
configured on the
server are correct
Is fault
rectified?
Yes
No
Contact Huaweri technical

support engineers
The user's access request is

denied by the server?
Yes
Check the reply

message in the
access failure
record
Is fault
rectified?
Yes
No
No
Run the test-aaa
command to verify
the correctness of
user access
information
Is fault
rectified?
Yes
No

support engineers
Refer to the manual

about user access
failure
Is fault
rectified?
Yes
No
Issue 03 (2013-08-15)
support engineers
Huawei Proprietary
and Confidential
End
89

NOTE
Procedure
Step 1 If the user cannot get online, run the display aaa offline-fail-record command to check the
failure record about the user.
l If the failure cause is displayed as RADIUS authentication request send fail, go to step 2.
l If the failure cause is displayed as RADIUS authentication reject, go to step 6.
l If the failure cause is neither of the two, refer to other sections in this manual to find the
solution.
Step 2 Run the ping command to check the connectivity of the physical network between the device
and the RADIUS server.
l If the ping operation fails, check the physical network between the device and the RADIUS
server. For details, refer to the HUAWEI NetEngine80E/40E Router Troubleshooting - IP
Forwarding and Routing.
l If the ping operation succeeds, go to step 3.
Step 3 Check that the RADIUS server information configured on the device is correct.
Run the display RADIUS-server configuration [group groupname ] command in the system
view to check whether the port number of the RADIUS authentication and accounting server
configured in the RADIUS server group view on the device is the same as the actual monitoring
port of the RADIUS server and whether the RADIUS server is Up.
l If the RADIUS server is Up but the port number of the RADIUS server is incorrectly
configured, run the RADIUS-server group groupname command to enter the RADIUS
group view, and then run the RADIUS-server accounting ip-address port or RADIUSserver authentication ip-address port command to modify the port number of the RADIUS
server.
l If the RADIUS server is Down, wait for a moment for the RADIUS server to automatically
become Up before performing the preceding operations.
If the user can get online, the fault is corrected; otherwise, go to step 4.
Step 4 Check that the RADIUS server is working properly.
l If the RADIUS server is not working properly, contact engineers of the RADIUS server
provider for a solution.
l If the RADIUS server is working properly, go to step 5.
Step 5 Check the settings of the RADIUS server.
Run the display this command on the device interface connecting the RADIUS server to check
the NAS IP address of the device. Run the display RADIUS-server configuration [group
Issue 03 (2013-08-15)

90

groupname] command in the system view to check the share-key of the device. Configure a
share-key on the RADIUS server, and ensure that the share-key is consistent with the share-key
configured on the device.
Step 6 Run the display aaa offline-fail-record command to check the reply message in the failure
record.
Determine the reason that the user's authentication request is denied by the RADIUS server
according to the reply message returned by the RADIUS server.
NOTE
A common user name error is that the user name configured on the RADIUS server is inconsistent with
the user name sent by the device. For example, the user name configured on the device does not carry any
domain name, but the user name sent by the device may carry a domain name. In that case, run the RADIUSserver group groupname command to enter the RADIUS group view and then run the RADIUS-server
user-name { domain-included | original } command to set whether to carry a domain name in the user
name. If you run the undo RADIUS-server user-name domain-included command, the user name in a
RADIUS packet will not include any domain name. If you run the RADIUS-server user-name domainincluded command, the user name will include a domain name. If you run the RADIUS-server username original command, the original user name will be carried.
Step 7 Check that the user access information is correct.

Run the trace command to view the access attributes in the user's RADIUS authentication
packets, configure access attributes in RADIUS-test-group mode, and change the values of these
access attributes. Then run the test-aaa user-name password RADIUS-group group-name
[ chap | pap ] [ test-group test-group-name ] command to check whether the RADIUS
authentication packets are authenticated by the RADIUS server to locate the fault cause.
----End

Relevant Alarms
None.
Relevant Logs
None.
1.5 L2TP
Issue 03 (2013-08-15)

91

1.5.1 An L2TP User Fails to Get Online

Common Causes
l
Layer 3 forwarding between the LAC and the LNS fails.
L2TP is not enabled on the LAC or the LNS.
L2TP group attributes of the LAC and the LNS are not matched.
The LAC and the LNS do not have the consistent tunnel authentication scheme or password.
Strict tunnel authentication has been configured for the LAC, and the remote tunnel name
configured on the LAC is inconsistent with the tunnel name configured on the LNS.
The LNS group is incorrectly bound to the tunnel board and loopback interface.
The PPPoX service fails.
The IP address pool is incorrectly configured, and the IP address pool fails to allocate a
correct IP address to the L2TP user.
The VPN accessed by the L2TP user is incorrectly configured.
After L2TP is configured, it is found that L2TP users cannot get online.
1.
Check the Layer 3 connectivity between the LAC and the LNS.
2.
Check that L2TP configurations are correct and attributes are matched.
3.
Check other features relevant to the L2TP networking.
Issue 03 (2013-08-15)

92

Figure 1-34 Troubleshooting flowchart for the failure of the L2TP user to get online
An L2TP user
fails to get online
Yes
Can the LAC ping the LNS successfully?
No
Rectify the fault of the link

between the LAC and the LNS.
Is fault rect
No
Yes
Is L2TP enabled on the LAC and the

LNS?
No
Enable L2TP
Is fault rect
No
Yes
No
Are the L2TP group and its attributes
correctly configured for the LAC and the
LNS?
Correctly configure the L2TP

group and its attributes
Is fault rect
No
Yes
Are the tunnel authentication

mode and password correct for the LAC
and the LNS?
No
Configure tunnel authentication

for the LAC and the LNS and
set the matched user name
and password
Is fault rect
No
Yes
Is AAA authentication
configured on the LAC? Is the
remote tunnel name configured on the LAC
consistent with the tunnel name
configured on the LNS?
No
Configure tunnel authentication

and consistent user names and
passwords for the LAC
and LNS
Is fault rect
No
Yes
No
Is the LNS group correctly configured?
Correctly configure the LNS

group and its attributes
Is fault rect
No
Yes
No
Is the PPPoX service normal?
Correctly configure user access
Is fault rect
No
Yes
Issue 03 (2013-08-15)

No
Correctly configure an IP
Copyright Huawei Technologies Co., Ltd. address pool for the user
Can the L2TP obtain an IP address?
Yes
93
Is fault rect
domain on the LNS side

No

NOTE
Procedure
Step 1 Check that the LAC can ping the LNS successfully.
If the ping operation succeeds, it indicates that the Layer 3 forwarding between the LAC and
the LNS is normal. Then, go to Step 2.
If the ping operation fails, you need to check the Layer 3 connectivity between the LAC and the
LNS. For details, refer to the HUAWEI NetEngine80E/40E Router Troubleshooting - IP
Forwarding and Routing.
Step 2 Check that L2TP is enabled on the LAC and the LNS.
Run the display current-configuration | include l2tp command on the LAC and the LNS.
If the command output shows l2tp enable, it indicates that L2TP is correctly enabled on the
LAC and the LNS. In this case, go to Step 3.
If the command output does not show l2tp enable, you need to configure the l2tp enable
command to enable L2TP. After the configuration, if the fault persists, go to Step 3.
Step 3 Check that the L2TP group attributes of the LAC and the LNS are correctly configured.
l On the LAC
Run the display l2tp-group group-name command and check whether the LNS address
specified by the LnsIPAddress field is the same as the actual LNS address. If they are
different, run the start l2tp command to set them the same.
l On the LNS
Run the display l2tp-group group-name command to check the following fields.
Check the RemoteName field to see whether the tunnel name specified on the LNS is
the same as the tunnel name specified on the LAC.
Check the VTNum field to see whether the bound VT is the same as the VT of the tunnel
interface.
NOTE
The name of the remote tunnel end, that is, remote-name, must be specified for the L2TP group (except
the default L2TP group, default-lns) when the L2TP tunnel is configured on the LNS.
If the specified remote tunnel end is inconsistent with the actual remote tunnel end, you need
to run the allow l2tp virtual-template virtual-template-number remote remote-name
command to make them the same.
If the L2TP group attributes are correctly configured but the fault persists, go to Step 4.
Step 4 Check that the LNS group is correctly configured.
Run the display lns-group name lns-name command on the LNS to check the Slot and
Interface fields to see whether the tunnel group is bound to the tunnel board and loopback
Issue 03 (2013-08-15)

94

interface. If the tunnel group is not bound to the tunnel board and loopback interface, run the
bind slot slot-id and the bind source interface-type interface-number commands in the LNS
group view to bind them.
If the LNS group is correctly configured but the fault persists, go to Step 5.
Step 5 Check that consistent tunnel authentication scheme and password are configured on the LAC
and the LNS.
Run the display l2tp-group group-name command on the LAC and the LNS to check the
TunnelAuth, Tunnel aaa Auth, and RADIUS-auth fields. These fields show whether the
authentication schemes of both the LAC and the LNS are the same. If these fields indicate that
the authentication schemes are different, you need to set them the same. For details, refer to
"L2TP Configuration" in the HUAWEI NetEngine80E/40E Router Configuration Guide - User
Access.
If the tunnel authentication scheme is configured, you need to check whether the tunnel
authentication passwords configured on the LAC and the LNS are the same. If they are different,
run the tunnel password { simple | cipher } password command to set the same password.
NOTE
The tunnel authentication request can be initiated by the LAC or the LNS. As long as one end is enabled
with tunnel authentication, the authentication is performed in the tunnel setup process. The tunnel can be
set up only if the passwords of both ends are the same and not vacant.
If the authentication schemes and passwords are the same on both tunnel ends but the fault
persists, go to Step 6.
Step 6 Check that strict tunnel authentication is configured for the LAC, and the remote tunnel name
configured on the LAC is consistent with the tunnel name configured on the LNS.
Run the display l2tp-group group-name command on the LAC. If Use tunnel authentication
strict is displayed in the TunnelAuth field, strict tunnel authentication is configured for the
LAC.
l
If strict tunnel authentication is used, check that the remote tunnel name configured on the
LAC is consistent with the tunnel name configured on the LNS.
If they are inconsistent, run the start l2tp [ ip ip-address [ weight lns-weight ] ] & <1-8>
command on the LAC and run the tunnel name tunnel-name command on the LNS to
change the remote tunnel name on the LAC and the tunnel name on the LNS to be
consistent.
If they are consistent, go to Step 7.
If strict tunnel authentication is not configured, go to Step 7.
Step 7 Check that the PPPoX service is normal.

For details, refer to "A PPPoX User Fails to Get Online" in the HUAWEI NetEngine80E/40E
Router Troubleshooting - User Access.
If the PPPoX service is normal but the fault persists, go to Step 7.
Step 8 Check that the L2TP user is assigned an IP address.
If the user is not assigned an IP address, you need to correctly configure the IP address pool on
the LNS. For details, refer to "Locating the Fault that a Client Fails to Obtain an IP Address" in
the HUAWEI NetEngine80E/40E Router Troubleshooting - User Access
Issue 03 (2013-08-15)

95

If the user is assigned a correct IP address but the fault persists, go to Step 8.
Step 9 Check that the VPN instance is correctly configured.
If the L2TP user accesses the VPN, run the display current-configuration command to check
the following:
l Check whether the VPN instance is configured with the RD.
l Check whether the interface connecting to the enterprise is bound to a VPN instance.
l Check whether the domain is bound to the VPN instance.
l Check whether the IP address pool is bound to the VPN instance.
If the VPN instance is correctly configured but the fault persists, go to Step 9.
----End

Relevant Alarms
L2TP_1.3.6.1.4.1.2011.5.25.40.3.2.2.0.1 hwL2tpTunnelUpOrDown
Relevant Logs
None.
1.5.2 L2TP IPv6 Users Cannot Get Online

procedure for the fault that an L2TP user cannot get online when the user attempts to access the
IPv6 network.
NOTE
See Roadmap for Locating L2TP Users Login Failure.
Common Causes
l
GTL was not enabled.
L2TP was not enabled globally.
L2TP tunnels or sessions cannot be established.
The address allocation mode is not correctly configured.
The DUID function is not configured when addresses are allocated in DHCPv6 mode.
Issue 03 (2013-08-15)

96

The IPv6 function is disabled on the source interface of the L2TP tunnel on the LNS.
The IPv6 address pool is not configured or incorrectly configured.
This section describes the troubleshooting flowchart for the fault that an L2TP user cannot obtain
an IPv6 address and cannot get online when the user attempts to access the IPv6 network.
l
Check that both L2TP tunnels and sessions can be properly established.
Check that an IPv6 address pool has been correctly configured.
Check that other IPv6-related information has been correctly configured.
Issue 03 (2013-08-15)

97

Figure 1-35 Troubleshooting flowchart for the fault that L2TP IPv6 users cannot get online
The user cannot
get online in the
case of L2TP
IPv6 access
L2TP tunnels and

sessions can be
established?
Refer to relevant
manuals to correct
wrong items
Is fault rectified?
No
Enable the IPv6

function globally
Is fault rectified?
No
Enable the IPv6

function on the
interface
Is fault rectified?
No
The IPv6 address

pool has been
correctly configured?
Is fault rectified?
No
Refer to relevant
operation steps to
correct wrong items
Is fault rectified?
No
Yes

globally enabled?
Yes
Yes

enabled on the interface
associated with the LNS
group?
Yes
Yes
The IPv6 address pool

has been correctly
configured?
Yes
Yes
The M value and DUID

are correctly configured?
Yes
Yes
Seek technical
support
End
Issue 03 (2013-08-15)

98

NOTE
NOTE
Before performing the following steps, ensure that GTL is enabled, and L2TP is enabled globally.
Procedure
Step 1 Check that both L2TP tunnels and sessions can be properly established.
Run the test l2tp-tunnel l2tp-group group-name ip-address ip-address command in the user
view to check whether L2TP tunnels and sessions can be properly established.
l If Test L2TP tunnel connectivity success is displayed, L2TP tunnels and sessions can be
properly established. Go to step 2.
l If Test L2TP tunnel connectivity fail is displayed, L2TP tunnels or sessions cannot be
properly established. Refer to the section about the failure of L2TP users to get online.
Run the display current-configuration command on the LNS to check whether the IPv6
function is globally enabled.
l If the IPv6 function is globally enabled, go to step 3.
l If the IPv6 function is not globally enabled, globally enable the IPv6 function. If the fault
persists, go to step 3.
Step 3 Check that the IPv6 function is enabled on the source interface of the L2TP tunnel on the LNS.
Run the display this command in the interface view to check whether the IPv6 function is
enabled and whether the IPv6 link-local address has been configured.
l If the IPv6 function is enabled and the IPv6 link-local address has been configured, go to
step 4.
l If the IPv6 function is disabled, run the ipv6 enable command to enable the IPv6 function,
and then run the ipv6 address auto link-local command to configure the IPv6 link-local
address.
Step 4 Check that an IPv6 address pool has been correctly configured.
Check whether the corresponding IPv6 prefix pool and address pool have been configured, and
whether the domain is associated with the IPv6 address pool. If VPNs have been configured,
ensure that the VPN configured for the domain and the VPN configured for the IPv6 address
pool are the same.
l If the IPv6 address pool is incorrectly configured, modify the address pool configuration
information.
Step 5 Check that the address allocation mode and DUID have been correctly configured, including
whether the configuration is necessary.
The address allocation mode of an L2TP user is configured in the domain view. If IPv6 addresses
are obtained through the DHCPv6 protocol, the address allocation mode and DHCPv6 DUID
must be configured; otherwise, they do not need to be configured.
Issue 03 (2013-08-15)

99

Run the display this command in the domain view to check whether the address allocation mode
value has been correctly configured. If ipv6 nd autoconfig managed-address-flag is displayed,
the address allocation mode has been configured.
Run the display this command in the system view to check whether the DUID function has been
correctly configured. If dhcpv6 duid duid-value is displayed, the DUID function has been
configured.
l If the M value and the DUID function have been correctly configured, go to step 6.
l If the configuration is incorrect, correctly configure the M value and the DUID function.
----End

Relevant Alarms
Relevant Logs
None.
\
1.5.3 IPv6 L2TP Access Troubleshooting

This section describes the notes about configuring L2TP access, and provides the L2TP access
troubleshooting flowchart and the troubleshooting procedure in a typical L2TP access
networking.
Typical Networking
Figure 1-36 shows the typical networking of L2TP access. L2TP access troubleshooting is based
on this networking.
Figure 1-36 Typical networking diagram of L2TP access
RADIUS server
20.20.20.1
DNS server
3001:0410::1:2
Headquarter
PSTN/ISDN
subscriber
@isp1
Issue 03 (2013-08-15)
Tunnel
GE1/0/1
GE1/0/2
RouterA
(LAC)

GE2/0/1 GE2/0/2
RouterB
(LNS)
100


l
The NE80E/40E functions as an L2TP Access Concentrator (LAC) or L2TP network server
(LNS).
The client is connected to the LAC through an access network.

accounting for the user.
The user accesses the LAC in L2TP mode. The LNS assigns an IPv6 address to the user and
manages the user.
On the network shown in Typical Networking, after an L2TP server is configured, the user
cannot get online. You can locate the fault based on the following troubleshooting flowchart.
Issue 03 (2013-08-15)

101

Figure 1-37 Troubleshooting flowchart of L2TP access

A Client cannot get online
Is the
configuration of user access
correct?
No
Check the
interface
Yes
Yes
Is fault
rectified?
No
Can the
LAC and the LNS ping
through each other?
No
Check the physical

connection and the
route between the
LAC and the LNS
Is fault
rectified?
Yes
No
Yes
Is L2TP
enabled on the LAC and
the LNS?
No
Enable L2TP
Is fault
rectified?
Yes
No
Yes
Are the
L2TP groups on the LAC and
the LNS and attributes of the
L2TP groups
correct?
No

L2TP groups and the
attributes
No
Modify the tunnel

authentication modes
and authentication
passwords configured
on the LAC and the
LNS to be consistent
No
Yes
Yes
Correctly configure
user access
Is fault
rectified?
No
Yes
Is the configuration
of the LNS correct?
Is fault
rectified?
No
Yes
Is the configuration
of PPPOX correct?
Yes
No
Yes
Are the
tunnel authentication
mode and authentication
password configured on the
LAC consistent with those
configured on
the LNS?
Is fault
rectified?
No

LNS group and its
attributes
Yes
Is fault
rectified?
Yes
No

End
Issue 03 (2013-08-15)

102

Procedure
l If the interface configuration is incorrect, you need to modify the interface configuration to
be correct. For details, refer to the chapter "Configuring the IPv6 Access Service" in the
Step 2 Check that there are reachable routes between the LAC and LNS.
Ping the LNS from the LAC to check whether the ping operation succeeds.
l If the ping succeeds, it indicates that there are reachable routes between them.
l If the ping fails, it indicates that there are no reachable routes between them. In this case, you
need to ensure that there are reachable routes between them.
Step 3 Check that L2TP is enabled on the LAC and the LNS.
Run the display this command in the system views of the LAC and the LNS to check whether
L2TP is enabled.
l If l2tp enable is not displayed in the command output, it indicates that L2TP is not enabled
on the LAC or the LNS. You need to run the l2tp enable command in the system views of
the LAC and the LNS to enable L2TP.
l If L2TP is enabled, go to 4.
Step 4 Check that the L2TP group of the LAC and attributes of the L2TP group are correctly configured.
Run the display this command in the L2TP group view of the LAC to check whether the LNS
address configured in the L2TP group is consistent with the address configured on the LNS.
l If they are inconsistent, run the start l2tp ip ip address command in the L2TP group view
of the LAC to configure an LNS address to be consistent with the address configured on the
LNS.
l If they are consistent, go to Step 5.
Step 5 Check that the L2TP group of the LNS and attributes of the L2TP group are correctly configured.
Run the display this command in the L2TP group view of the LNS to check whether the
configured tunnel name and VT are correct.
l If they are incorrect, run the allow l2tp virtual-template virtual-template-number remote
lac-name command to configure a correct tunnel name and a VT. Ensure that the tunnel name
configured on the LNS is the same as that configured on the LAC.
l If they are correct, go to Step 6.
Step 6 Check that the LAC and the LNS are configured with the same tunnel authentication mode and
authentication password.
Issue 03 (2013-08-15)

103

Run the display this command in the L2TP group views of the LAC and the LNS to check
whether they are configured with the same tunnel authentication mode and authentication
password.
If they are configured with different authentication modes or authentication passwords, modify
the configuration of one end to be the same as the configuration of the other end.
----End
1.5.4 An L2TP User Fails to Go Online on the Slave Device

This section provides the troubleshooting flowchart and procedure for the fault that when an
L2TP user attempts to go online but fails after data is backed up on the slave device.
Common Causes
l
The RBPs bound to interfaces on the master and slave devices are not the same.
User entries of the MPU and LPU on the slave device are not associated.
A user attempts to go online but fails after data is backed up on the slave device.
l
Check whether backup-ids of the RBP bound to interfaces on the master and slave devices
are the same.
Check whether L2TP configurations on the slave device are the same with those on the
master device.
Check whether user entries of the MPU and LPU on the slave device are associated.
Before performing the following steps, users can check the Common Causes for Failure in
Going Online to correct the fault according to the prompts.
NOTE
Saving the results of each troubleshooting step is recommended. If troubleshooting fails to correct the fault,
you will have a record of your actions to provide Huawei technical support personnel.
Procedure
Step 1 Check whether the RBP is bound to BAS interfaces on the master and slave devices.
Run the display remote-backup-profile command to check whether the RBP is configured at
BAS interfaces.
Issue 03 (2013-08-15)

104

l If yes, go to Step 2.
l If no, run the remote-backup-profile command to configure the RBP at BAS interfaces in
the BAS interface view. If the fault is not corrected, go to Step 2.
Step 2 Check whether backup-ids of the RBP bound to interfaces on the master and slave devices are
the same.
Run the display remote-backup-profile command to check whether backup-ids of the RBP
bound to interfaces on the master and slave devices are the same.
l If no, run the backup-id backup-id remote-backup-service name command to configure
the two devices with the same backup-id in the RBP view. If the fault is not corrected, go to
Step 3.
Step 3 Check whether L2TP configurations on the slave device and those on the master device are the
same.
l If no, modify L2TP configurations on the slave device to be the same with those on the master
device. See L2TP Users Fail to Go Online for detailed troubleshooting methods.
Step 4 Check whether entries of the MPU and LPU on the slave device are associated.
Run the display l2tp tunnel command to view the Sessions.
l If the Sessions value is 0, go to Step 5.
l If the Sessions value is not 0, run the display l2tp session lac command to view the
information.
1.
If user information is displayed, the fault is corrected.
2.
If no user information is displayed, entries of the MPU and LPU are not associated. In
this case, go to Step 5.
l Results of the preceding troubleshooting procedure;
----End
Alarms and Logs

Alarms
Logs
None

Issue 03 (2013-08-15)

105

1.6.1 Local Authentication Fails Because Authorization Mode and

Accounting Mode Are Incorrectly Set
The system is configured to perform local authentication when the HWTACACS server is Down
(there is no response to HWTACACS authentication). However, the configuration does not take
effect.
Fault Symptom
The system is configured to perform local authentication when the HWTACACS server is Down
(there is no response to HWTACACS authentication).
Despite the configuration, local authentication of Telnet users fails when the HWTACACS
server is Down.
Fault Analysis
1.
When the HWTACACS server is Up, Telnet users are authenticated by the HWTACACS
server. This indicates that the HWTACACS server is properly configured. When the
HWTACACS server is Down, local authentication is not performed. Therefore, it can be
concluded that local authentication is not correctly configured.
2.
Check configurations of the device, and you can find the following configurations:
authentication-scheme tacacs
authentication-mode hwtacacs local
authentication-super hwtacacs super
#
authorization-scheme tacacs
authorization-mode hwtacacs
authorization-cmd 3 hwtacacs
#
accounting-scheme tacacs
accounting-mode hwtacacs
The preceding configurations show that the authentication mode is hwtacacs local, which
indicates that HWTACACS authentication is performed before local authentication, and
the authorization mode and accounting mode are both hwtacacs. The authentication mode
is properly configured. When the HWTACACS server goes Down, the system performs
the local authentication. HWTACACS authorization and accounting, however, cannot be
performed because the HWTACACS server is now unavailable. As a result, local
authentication fails.
Procedure
Step 1 Run the system-view command to enter the system view.
Step 2 Run the aaa command to enter the AAA view.
Step 3 Configure an authorization mode and an accounting mode.
l Configuring the authorization mode as HWTACACS authorization before local
authorization
1.
Issue 03 (2013-08-15)
Run the authorization-scheme tacacs command to enter the authorization scheme

view.
106

2.
Run the authorization-mode hwtacacs local command to configure the authorization

mode as HWTACACS authorization before local authorization.
l Configuring the accounting mode as HWTACACS accounting before non-accounting

1.
Run the accounting-scheme tacacs command to enter the accounting scheme view.
2.
Run the accounting-mode hwtacacs none command to configure the accounting mode
as HWTACACS accounting before non-accounting.
You do not have to configure the accounting mode. This is because accounting does
not take effect with administrator users, whose accounting mode is non-accounting by
default.
After the preceding operations, local authentication is successfully performed on Telnet users
when the HWTACACS server goes Down. The fault is cleared.
----End
Summary
User management includes authentication, authorization, and accounting. When configuring the
authentication mode, ensure the consistency between the authorization and accounting modes
to guarantee successful login for Telnet users.
1.6.2 After an Accounting Failure, the Super Password Is Invalid

After Being Entered
The super password is invalid.
Fault Symptom
On the network shown in Figure 1-38, the RADIUS server is used to authenticate access users
and implement accounting for access users. In addition, the authentication mode for upgrading
the user level in an authentication scheme is set to super.
After a user runs the super command and enters the super password, the message aaa cut
user is displayed on the router. The user fails the authentication.
Figure 1-38 After an accounting failure, the super password is invalid after being entered
Access users
Router
RADIUS Server
10.1.1.1/24
Network
Issue 03 (2013-08-15)

107

Fault Analysis
1.
The super password is statically configured on the router and is by no means invalid. The
following information is displayed in the logs on the router:
RDS/4/RDACCTDOWN: RADIUS accounting server (IP:10.1.1.1) is down!
The preceding information indicates that the communication between the RADIUS
accounting server and the router is interrupted, but the RADIUS authentication server
communicates normally with the router.
2.
After the display this command is run in the AAA view of the router, the AAA
configurations are displayed as follows:
accounting-scheme default
accounting-mode RADIUS
The preceding information indicates that the RADIUS accounting mode is adopted. It is
inferred that the communication between the RADIUS accounting server and the router is
interrupted and therefore an accounting failure occurs. As a result, the router is logged out.
It is suspected that the RADIUS accounting server is disabled or faulty or the link is faulty.
Procedure
Step 1 Check whether the RADIUS accounting server is disabled or faulty. If so, restore the RADIUS
server.
Step 2 Check whether the link works properly. If so, restore the link.
NOTE
You can also run the accounting-mode none command in the accounting scheme view to change the accounting
mode to non-accounting. Accounting is insignificant for administrator users.
After the preceding operations, the user can pass the authentication after entering the super
password. The fault is rectified.
----End
Summary
User management includes authentication, authorization, and accounting.
You should consider authentication, authorization, and accounting in a comprehensive manner
when configuring AAA. A user cannot pass the authentication if failing any one of the operations.
1.6.3 Users Cannot Be Redirected to the Specified Web Page

Fault Symptom
Users are connected to the router through access devices. The router is configured with Web
authentication to authenticate users in RADIUS mode. After the RADIUS server delivers the
Huawei RADIUS attribute Portal-URL (26-27) to the router, logged-in users cannot be
redirected to the specified Web page.
Issue 03 (2013-08-15)

108

Figure 1-39 Users failing to be redirected to the specified Web page
DNS Server
Web Server
RADIUS Server
Access
Network
User
Router
Fault Analysis
1.
The cause of this problem may be either of the following: the RADIUS server delivers an
incorrect attribute; the Huawei device cannot correctly parse the attribute delivered by the
RADIUS server.
2.
Run the debug RADIUS packet command on the router to enable RADIUS packet
debugging, and then check the No. 26-27 attribute delivered by the RADIUS server.
ID
: 233
[Session-TimeOut(27)
[Input-Average-Rate(26-2)
[Input-Peak-Rate(26-3)
[Output-Average-Rate(26-5)
[Output-Peak-Rate(26-6)
[PortalURL(26-27)
[RADIUS-Mp-VT-Number(26-30)
[Service-Type(6)
[Framed-Protocol(7)
[Framed-Netmask(9)
[Unknow-attr
[Unknow-attr
[Unknow-attr
] [6
] [6
] [6
] [6
] [6
] [27]
] [6
] [6
] [6
] [6
] [6
] [6
] [6
] [43201]
] [524288]
] [524288]
] [2097152]
] [2097152]
[http://huawei.com]
] [0]
] [2]
] [1]
] [255.255.255.0]
] [00000000]
] [000005dc]
] [00000001]
The command output shows that the attribute is correctly delivered. Therefore, it can be
concluded that the router did not correctly parse the domain name http://huawei.com, and
as a result, users could not be redirected to the specified Web page.
3.
Run the display current-configuration | begin dns command on the router to check all
the configurations starting with the string "dns". No DNS configuration is found.
Procedure
Step 2 Run the dns resolve command to enable DNS-based dynamic domain name resolution.
Step 3 Run the dns server 172.16.1.1 command to configure an IP address for the domain name server.
Step 4 Run the dns domain com command to configure a domain name suffix .com.
Step 5 Run the dns domain net command to configure a domain name suffix .net.
Issue 03 (2013-08-15)

109

Step 6 Run the dns domain cn command to configure a domain name suffix .cn.
After the preceding operations, users can be redirected to the specified Web page. The fault is
rectified.
----End
Summary
Before a device is able to receive a domain name from a RADIUS server, you need to configure
domain name resolution on the device to resolve the domain name.
1.6.4 Unreachable RADIUS Server Causes Level-3 Users to Log In

as Level-1 Users
Fault Symptom
On a network shown in Figure 1-40, users access the Internet through the router in RADIUS
authentication mode. After the RADIUS server becomes unreachable, although users are
configured as level-3 users, the login users can operate only as level-1 users.
Figure 1-40 Unreachable RADIUS server causing level-3 users to log in as level-1 users
Router
RADIUS
Server
Internet
User
Fault Analysis
1.
Users log in to the router as level-1 users, indicating that they have been authenticated and
authorized successfully. Nevertheless, the users are authenticated and authorized not by
RADIUS and therefore they are level-1 users but not level-3 users.
2.
Check user names used by them to log in to the router. As the user names do not contain
domain names, the system uses the default domain name to authenticate and authorize the
users.
3.
Run the display this command in the AAA view to check the configuration on the router.
The command output is as follows:
aaa
authentication-scheme
default0
Issue 03 (2013-08-15)

110

authentication-mode RADIUS
local
huawei
authentication-mode RADIUS
#
authorization-scheme
default0
authorization-mode ifauthenticated
authorization-scheme
huawei
authorization-mode if-authenticated
#
domain
default0
RADIUS-server group
isp
domain
huawei
huawei
RADIUS-server group isp
The command output shows that the default domain-based authentication scheme is
RADIUS authentication followed by local re-authentication. In addition, the authorization
scheme is if-authenticated authentication.
If the RADIUS server is unreachable, RADIUS authentication is unavailable. In this case,
local re-authentication is adopted. After passing local re-authentication, the users will be
authorized in if-authenticated authorization mode. If-authenticated authorization is invalid
for users that are authorized in local mode. Therefore, the authorization level provided by
the system to the authenticated users is the VTY default level (level 1). If local authorization
is adopted, the system provides a locally-set authorization level for users.
Procedure
Step 3 Run the authorization-scheme default command to enter the default authentication scheme
view.
Step 4 Run the authorization-mode if-authenticated local command to authenticate users in ifauthenticated mode and then in local mode.
After the preceding operations, users log in to the router as level-3 users. The fault is then
rectified.
----End
Summary
When users log in without domain names, the system uses the default domain name to perform
authentication and authorization. If local authentication is adopted, the system provides locallyset level for users only after the local authorization mode is adopted; if the local authorization
mode is not adopted, the system provides the default VTY level (level 1) for users.
Issue 03 (2013-08-15)

111

1.6.5 A DHCP Client Fails to Obtain an IP Address from the DHCP

Server Through the BRAS
Fault Symptom
In the networking shown in Figure 1-41, the AP is connected to the BRAS in VLAN access
mode; the BRAS functions as the gateway of the AP. The AP is configured to obtain an IP
address from the DHCP server through the BRAS. After the configuration, the AP cannot obtain
an IP address from the DHCP server.
Figure 1-41 Networking for a DHCP client failing to obtain an IP address from the DHCP server
through the BRAS
DHCP Server
AP
Switch
BRAS
Fault Analysis
1.
The ping from the BRAS to the AC is successful.
2.
Run the trace mac enable command to globally enable MAC trace.
3.
Run the trace mac mac-address vlan vlan-id command to check the connectivity between
the BRAS and AP.
-[2010/5/22 16:34:41-][DHCPR][0023-8902-5120]:Receive OFFER packet
successfully
(Ciadd:0.0.0.0 Yiadd:172.16.32.3 Siadd:0.0.0.0 Giadd:172.16.32.1 chaddr:
0023-8902-5120
RouteIP:172.16.32.1 SubMask:255.255.255.0 ServerId:1.1.1.1 lease:1800s
The command output shows that the BRAS has received a DHCPOFFER message sent
from the DHCP server.
4.
Run the display aaa online-fail-record interface interface-type interface-number

command to check the cause of user access failure.
-------------------------------------------------------------------------User name
: SD-WH-GQHWBS-2.M-02001000002...
Domain name
: fit-apnm
User MAC
:
0023-8902-5120
User access type
:
IPoE
Issue 03 (2013-08-15)

112

User access interface : GigabitEthernet1/0/1.1

Qinq Vlan/User Vlan:
0/2512
User IP address
:
255.255.255.255
User ID
:
100734
User authen state :
Authened
User acct state
:
AcctIdle
User author state :
AuthorIdle
User login time
: 2010/05/22
17:12:48
User online fail reason: DHCP server no response
------------------------------------------------------------------Are you sure to show some information?(y/n)[y]:
5.
Run the debugging ip packet command, and you can find that the source IP address of the
DHCPOFFER message is 222.175.193.178. The IP address of the DHCP server in the
DHCP server group configured on the BRAS, however, is 222.174.192.22.
*2.2206331108 SD-WH-GQHW-BS-2.MAN IP/7/
debug_case:Slot=1;
Receiving, interface = GigabitEthernet1/0/1.1, version = 4, headlen = 20, tos
= 96,
pktlen = 369, pktid = 2298, offset = 0, ttl = 255, protocol =
17,
checksum = 17582, s = 2.2.2.2, d = 172.16.32.1
prompt: Receiving IP packet from GigabitEthernet1/0/1.1
After the BRAS receives the DHCPOFFER message, it finds that the source IP address of
the message is not the IP address of the DHCP server. Therefore, the BRAS considers the
message invalid and discards the message. In this manner, the AP cannot obtain an IP
address.
Procedure
Step 1 Run the system-view view to enter the system view.
Step 2 Run the dhcp-server group group-name command to enter the DHCP server group view.
Step 3 Run the dhcp-server 2.2.2.2 command to configure the IP address of the DHCP server to be the
source IP address of the DHCPOFFER message.
After that, the AP can obtain an IP address from the DHCP server through the BRAS.
Or, you can set the IP address of the actual DHCP server to 222.174.192.22. After that, the AP
can obtain an IP address from the DHCP server through the BRAS.
----End
Summary
If a user cannot obtain an IP address from the DHCP server through the BRAS, you can check
whether the IP address of the DHCP server is the same as that configured on the BRAS. If the
IP addresses are different, configure them to be the same.
Issue 03 (2013-08-15)

113

1.6.6 The Device Does not Respond to the Authentication Request

Packet Sent by the Web Authentication Server
The device receives the authentication request packet from the Web authentication server. The
Web authentication server, however, fails to receive a reply from the device.
Fault Analysis
1.
Run the debugging web packet command in the user view to view the debugging
information about the Web module.
*0.890027513 BAS02 WEB/7/DEBUG:
packet received from socket( len = 52 Vrf =
0):
ver
:
2
type
: auth
req
Method :
pap
SerialNo:
63489
ReqID
:
0
UserIP :
10.1.1.1
ErrCode :
0
AttrNum :
2
*0.890027514 BAS02 WEB/7/
DEBUG:
02 03 01 00 f8 01 00 00 3d b2 ed 0a 00 00 00
02
a1 04 35 5c cc b4 62 f2 40 d0 bc 3c 07 d9 70
8a
01 0a 64 6f 6e 67 68 70 32 30 02 0a 64 6f 6e
67
68 70 32
30
*0.890027514 BAS02 WEB/7/
DEBUG:
The command output shows that the device receives the authentication request packet from
the Web authentication server of portal version 2.0.
2.
Run the display web-auth-server configuration command on the device to view the
configuration of the Web authentication server.
Source interfce
Listening port
:
2000
Portal
: version 1, version
2
Display reply message :
enabled
-----------------------------------------------------------------------Server
Share-Password
Port NAS-IP Vpninstance
-----------------------------------------------------------------------10.2.2.2
50100
Issue 03 (2013-08-15)

114

NO
-----------------------------------------------------------------------1 Web authentication server(s) in total
The displayed Portal item shows that the Web authentication server configured on the
device also supports portal version 2.0. In addition, the IP address and port number of the
Web authentication server configured on the device are the same as that of the actual Web
authentication server. The shared key, however, is not configured. If the protocol between
the device and the Web authentication server is portal version 2.0 or a later version, you
must configure the shared key.
Procedure
Step 2 Run the web-auth-server server-ip key key command to configure the shared key for the Web
authentication server. After the configuration, the device can communicate with the Web
authentication server.
----End
Summary
If the protocol between the device and the Web authentication server is portal version 2.0 or a
later version, you must configure the shared key.
1.6.7 Web Authentication Fails

Fault Symptom
In the networking shown in Figure 1-42, a user needs to be authenticated by the Web
authentication server through the device. After the configuration, the use can open the Web page
and enter the user name and password. After that, the system prompts that the network access
times out. User authentication therefore fails.
Figure 1-42 Networking for Web authentication failure
Radius Server
Backbone
PC
Issue 03 (2013-08-15)
Router
NAT

115

Fault Analysis
1.
Run the debugging web packet command in the user view to check information about
Web authentication packets.
*1.1043515286 BRAS WEB/7/DEBUG:
packet received from socket( len = 65 Vrf = 0):
ver
: 2
type
: auth req
Method : pap
SerialNo: 1280
ReqID
: 0
UserIP : 10.1.1.1
ErrCode : 0
AttrNum : 2
*1.1043515286 BRAS WEB/7/DEBUG:
02 03 01 00 05 00 00 00 76 76 a6 f3 00 00 00 02
d2 9f db 59 67 f1 9d 1c 68 5f ec 78 69 5a a6 22
02 08 31 31 31 31 31 31 01 19 64 78 31 74 40 77
6c 61 6e 2e 73 63 2e 63 68 6e 74 65 6c 2e 63 6f 6d
*1.1043515286 BRAS WEB/7/DEBUG:
*1.1043515385 BRAS WEB/7/DEBUG:
packet sent to socket( len = 32 Vrf = 0):
ver
: 2
type
: auth ack
Method : pap
SerialNo: 1280
ReqID
: 0
UserIP : 10.1.1.1
ErrCode : 0
AttrNum : 0
*1.1043515385 BRAS WEB/7/DEBUG:
02 04 01 00 05 00 00 00 76 76 a6 f3 00 00 00 00
64 16 d9 a8 91 f7 29 22 63 19 37 c5 c7 4d f1 b1
*1.1043545315 BRAS WEB/7/DEBUG:
*1.1043545315 BRAS WEB/7/DEBUG:
*1.1043545315 BRAS WEB/7/DEBUG:
packet sent to socket( len = 32 Vrf = 0):
ver
: 2
type
: logout ntf
Method : pap
SerialNo: 0
ReqID
: 0
UserIP : 10.1.1.1
ErrCode : 0
AttrNum : 0
*1.1043545315 BRAS WEB/7/DEBUG:
02 08 01 00 00 00 00 00 76 76 a6 f3 00 00 00 00
7b ec ab c0 c7 5d a8 66 00 e0 51 6b fa 64 66 ad
The command output shows that the device has sent an ACK packet indicating successful
authentication to the Web authentication server but receives no response (type : logout
ntf).
2.
Check information on the firewall, and you can find that the source IP address of the ACK
packet is the IP address of the upstream interface on the device. The Web authentication
server, however, is configured to receive only packets with the IP address of the loopback
interface on the device. This indicates that user authentication fails because the source IP
address of packets sent by the device is incorrectly configured.
Procedure
Issue 03 (2013-08-15)

116

Step 2 Run the web-auth-server source interface interface-type interface-number command

configure the source interface on the device for sending packets to the Web authentication server
to be the loopback interface on the device.
After the configuration, user authentication is successful.
----End
Summary
If a user fails Web authentication through the device, you can check whether the IP address of
the actual Web authentication server is the same IP address of the Web authentication server
configured on the device. If the IP addresses are different, configure them to be the same.
1.6.8 Error 619 Occurs After Users Attached to the NE80E/40E Dial
Up
Fault Symptom
Error 619 occurs on PCs after users access the BRAS (the NE80E/40E) and dial up. The
following figure shows the networking diagram.
Figure 1-43 Networking diagram of user accessing the NE80E/40E
PC
S-switch
Router
Internet
Fault Analysis
After PADS packets arrive at PCs, LCP packets cannot be exchanged between PCs NE80E/
40E during PPP negotiation, causing error 619.
1.
Run the display license resource usage command to check entry-specific resource usage
defined in the license file. Resource usage of access user traffic is 16125/32768, indicating
that the number of login users is lower than the upper limit defined in the license file.
2.
Run the display ip pool command to check information about address pools. The free item
is 1258, indicating that certain addresses are available.
3.
Run the display domain command to check the domain configurations. The Online item
displays the number of online users in each domain.
4.
Run the display access-user slot command to check the online user list. All online users
are attached to one LPU of the NE80E/40E, and the number of online users reached to the
maximum number of allowed PPPoX and DHCP users.
Issue 03 (2013-08-15)

117

Procedure
Step 1 Switch services on certain interfaces of the LPU to another LPU. Error 619 is not displayed. The
fault is then rectified.
----End
Summary
Error 619 occurs usually because of the BRAS specifications such as maximum number of
allowed access users defined in a license file, maximum number of addresses in an address pool,
or maximum number of allowed access users on a specific LPU. Check the BRAS specifications
before performing configurations.
1.6.9 Error Message, Indicating that Communication Between a

User Access Device and a Portal Server Fails, Is Displayed During
Web Authentication
Fault Symptom
On the network shown in Figure 1-44, a device is configured with RADIUS authentication and
provides access services for WLAN users. WLAN users need to pass Web authentication. After
accessing the device, a user obtains an IP address and is directed to a correct Web page. The
user then enters the user name, password, and verification code for authentication. The system
then prompts an error message indicating that the device fails to communicate with the portal
server.
Issue 03 (2013-08-15)

118

Figure 1-44 Networking diagram of a Web authentication failure
Portal Server
BRAS
Radius Server
Switch
AP
PC
PHONE
Fault Analysis
1.
Run the display domain domain-name command to check the configuration of the
authentication domain. The configuration is correct.
2.
Run the display RADIUS-server configuration command to check RADIUS attributes.

RADIUS attributes are correct.
3.
Run the debugging RADIUS packet command to check packets exchanged between the
device and the RADIUS server.
May 29 2010 10:49:41.230.1 1.1.111.4 RDS/7/
DEBUG:
RADIUS Sent a
Packet
Server Template:
6
Server IP
:
190.93.254.251
Vpn-Instance:
NAS Port
:
Issue 03 (2013-08-15)

119

1812
Protocol:
Standard
Code
: Authentication
request
Len
:
279
ID
:
36
[User-Name(1)
[test@ld]
[User-Password(2)
[8b17c44b1201d848959fd18c50690f9e]
[NAS-Port(5)
[68173824]
[NAS-IP-Address(4)
[190.93.16.4]
[Service-Type(6)
[2]
[Framed-Protocol(7)
[1]
[Filter-ID(11)
[0]
[Vendor-Specific(26)
[ ]
[NAS-Identifier(32)
[1.1.111.4]
[NAS-Port-Type(61)
[15]
[NAS-Port-Id(87)
0/0/0/0/0/0]
[Acct-Session-Id(44)
[1.1.11104104000000000a7a7cf000020]
[Connect-Info(77)
[1000000000]
] [9 ]
] [18]
] [6 ]
] [6 ]
] [6 ]
] [6 ]
] [6 ]
] [6 ]
] [11]
] [6 ]
] [33] [eth 4/1/4:4096.4096
] [35]
] [12]
The command output shows that the vendor-specific attribute numbered 26 delivered by
the RADIUS server cannot be identified.
4.
Run the RADIUS-attribute disable vendor-specific send command to disable the

RADIUS server from sending the vendor-specific attribute.
The fault persists.
5.
Run the debugging RADIUS packet command again to check packets exchanged between
the device and the RADIUS server.
May 29 2010 11:10:41.230.1 1.1.111.4 RDS/7/
DEBUG:
RADIUS Sent a
Packet
Server Template:
6
Server IP
:
190.93.254.251
Vpn-Instance:
NAS Port
:
1812
Protocol:
Standard
Code
: Authentication
request
Len
:
279
ID
:
36
[User-Name(1)
] [9 ]
Issue 03 (2013-08-15)

120

[test@ld]
[User-Password(2)
[8b17c44b1201d848959fd18c50690f9e]
[NAS-Port(5)
[68173824]
[NAS-IP-Address(4)
[190.93.16.4]
[Service-Type(6)
[2]
[Framed-Protocol(7)
[1]
[Filter-ID(11)
[0]
[Vendor-Specific(26)
[ ]
[NAS-Identifier(32)
[1.1.111.4]
[NAS-Port-Type(61)
[15]
[NAS-Port-Id(87)
0/0/0/0/0/0]
[Acct-Session-Id(44)
[1.1.11104104000000000a7a7cf000020]
[Connect-Info(77)
[1000000000]
] [18]
] [6 ]
] [6 ]
] [6 ]
] [6 ]
] [6 ]
] [6 ]
] [11]
] [6 ]
] [33] [eth 4/1/4:4096.4096
] [35]
] [12]
The command output shows that the user group that the RADIUS server delivers to the
device is policy 0.
6.
Run the display this command in the domain view to check the configurations of the
domain.
service-type
hsi
web-server
219.150.59.241
web-server url https://wlan.ct10000.com/
nm/
web-server mode
post
user-group
wlan
ip-pool wlan
The command output shows that the user group configured in the domain is wlan. The user
group configured in the domain is different from that delivered by the RADIUS server,
causing the Web authentication failure.
Procedure
Step 3 Run the domain domain-name command to enter the domain view.
Step 4 Run the user-group 0 command to configure a user group the same as that delivered by the
RADIUS server. The user can be authenticated. The fault is then rectified.
----End
Issue 03 (2013-08-15)

121

Summary
When a user accessing a device needs to be authenticated by a Web server, ensure that the user
group attribute configured on the RADIUS server is the same as that configured on the device;
otherwise, the device fails to communicate with the portal server during Web authentication.
1.6.10 router Fails to Communicate with a RADIUS Server Because

an ACL Rule Is Configured on the router's Interface Connected to
the RADIUS Server
Users access the router fail to pass authentication.
Fault Symptom
On the network shown in Figure 1-45, Router B is newly deployed and configured with RADIUS
authentication and accounting. All users at the site access the Internet through Router B. Router
A is a non-Huawei device.
After the configuration, all dial-up users at this site fail to pass authentication.
Figure 1-45 Networking diagram of a connection between the router and the RADIUS server
Radius
Server
Network
Router A
Router B
Access
Network
Fault Analysis
1.
Run the debugging RADIUS packet command to enable the debugging. The command
output shows that the router has sent a request carrying the Code field being 1 for
authentication, but does not receive a response from the RADIUS server.
2.
Check debugging information on the RADIUS server. It has received the request and replied
with a packet carrying the Code field being 2.
Issue 03 (2013-08-15)

122

As the reply packet is not received, the reply packet may be discarded during forwarding
or the route for the reply packet is incorrect.
3.
Ping the RADIUS server from the router. The ping is successful, indicating that the route
for the returned packet is correct. The replied packet must have been discarded during
forwarding.
4.
Change the source IP address to another IP address in a different network segment for the
packet sent from the router to the RADIUS server. The reply packet can be received, and
then users can go online.
Considering that IP packets are sent successfully and UDP packets are returned by the
RADIUS server, an intermediate device may apply an ACL rule to UDP packets with source
IP addresses in a specified network segment.
5.
On the basis of a check, Router A is configured with an ACL rule, therefore discarding
UDP packets replied by the RADIUS server.
Procedure
Step 1 Delete the ACL rule on Router A. The RouterB can communicate with the RADIUS server. The
fault is then rectified.
----End
Summary
When users cannot go online, first check whether the Router sends requests for authentication
and receives replies. In this troubleshooting case, the RADIUS server has received a request for
authentication and sent a reply. The Router cannot receive the reply, which is caused by incorrect
ACL rule set on a device between the Router and the RADIUS server.
1.6.11 PPPoE Subscriber Fails to Dial in Because of the

Transmission Limit
Fault Symptom
The NE80E/40E serves as the access device. When the PPPoE subscriber tries to access the
network through the NE80E/40E, the system prompts error code 678. The networking diagram
is as follows:
Figure 1-46 Typical networking of PPPoE subscriber's access through the NE80E/40E
PC
SwitchA
Transmission
Device
SwitchB
Router
Internet
Issue 03 (2013-08-15)

123

Fault Analysis
1.
Run the trace object mac-address mac-address command to trace the MAC address of
the PPPoE subscriber who fails to dial up with an error code 678. The command output
shows that the PPPoE subscribe can receive the PADI packet and send the PADO packet.
It can therefore be concluded that the link is normal.
2.
Run the display access-user interface interface-type interface-number command on the

interface where the fault occurs. The command output shows that other users can access
the network through this interface. It can therefore be concluded that the device
configuration is correct.
3.
Get packets head on the outbound interface of the switch SwitchB. The result shows that
the PADO packet has been sent from the outbound interface but is discarded during the
transmission process. As a result, the user side does not receive the PADO packet.
4.
Check the transmission device. The result shows that its minimum transmission unit is 64
bytes, and the length of the PADO packet, however, is smaller than 64 bytes. As a result,
the PADO packet is therefore discarded by the transmission device and the system prompts
error code 678.
Procedure
Step 2 Run the sysname host-name command to lengthen the PADO packet.
NOTE
Alternatively, you can rectify the fault by changing the minimum transmission unit of the transmission
device.
----End
Summary
The PADO packet has an AC_NAME field, which is filled with the name of the NE80E/40E.
When the PPPoE subscriber fails to dial in and the system prompts error code 687, you can
rectify the fault by changing the name of NE80E/40E to ensure that the length of the PADO
packet is greater than the minimum transmission unit of the transmission device.
1.6.12 Users Are Repeatedly Logged Out of the MAN Due to Route
Flapping
Users are repeatedly logged out of the MAN. A check of the LSDB shows that conflicting IP
addresses and router IDs exist in the network, which cause the OSPF route flapping.
Fault Symptom
On the network shown in Figure 1-47, users attached to Router E are repeatedly logged out of
the MAN.
Issue 03 (2013-08-15)

124

Figure 1-47 Networking diagram for the case in which users are repeatedly logged out of the
MAN due to route flapping
RouterA
RouterID 1.1.1.1
GE1/0/1
10.0.0.1/30
GE1/0/1
10.0.0.2/30
RouterB
RouterID 2.2.2.2
RouterC
RouterID 3.3.3.3
GE1/0/1
40.0.0.1/30
Metro Ethernet Network
GE1/0/1
40.0.0.2/30
RouterD
RouterID 4.4.4.4
RouterE
RouterID 5.5.5.5
User
Fault Analysis
1.
Since the users all access the MAN through Router E, maybe there is a problem with the
forwarding on Router E. Run the display ospf lsdb command on Router E several times
to check the OSPF LSDB. The command output shows that the value of the LS age field
in the Network LSA with the Link State ID being 10.0.0.2 is always smaller than 20 and
the LSA is aged out frequently (the age value changes to 3600). In normal situations,
however, the age value is not always smaller than 20 or aged out frequently.
<RouterE> display ospf lsdb
OSPF Process 1 with Router ID 5.5.5.5
Link State Database
Area: 0.0.0.0
2.
Issue 03 (2013-08-15)
Type
LinkState ID
AdvRouter
Network
10.0.0.2
2.2.2.2
Age
Len
Sequence
32
800029BE
Metric
Run the display ospf lsdb network 10.0.0.2 command repeatedly on Router E to view
detailed information about this LSA. The command output shows that the ID of the router
advertising this LSA is 2.2.2.2, but the attached router frequently changes between 1.1.1.1
and 3.3.3.3. It is possible that an IP address conflict occurs on the network.
125

<RouterE> display ospf lsdb network 10.0.0.2

Area: 0.0.0.0
Link State Database
Type
: Network
Ls id
: 10.0.0.2
Adv rtr
: 2.2.2.2
Ls age
: 7
Len
: 32
Options
: E
seq#
: 80002ca3
chksum
: 0x8995
Net mask : 255.255.255.252
Attached Router
1.1.1.1
Attached Router
2.2.2.2
<RouterE> display ospf lsdb network 10.0.0.2
Area: 0.0.0.0
Link State Database
Type
:
Ls id
:
Adv rtr
:
Ls age
:
Len
:
Options
:
seq#
:
chksum
:
Net mask :
Attached
Attached
3.
Network
10.0.0.2
2.2.2.2
7
32
E
80002ca3
0x8995
255.255.255.252
Router
3.3.3.3
Router
2.2.2.2
The initial network planning scheme is as follows:

l The IP address of GE 1/0/1 on Router A is 10.0.0.1/30, and that on Router B is
10.0.0.2/30.
l The IP address of GE 1/0/1 on Router C is 40.0.0.1/30, and that on Router D is
40.0.0.2/30.
l The router IDs of Router A, Router B, Router C, and Router D are 1.1.1.1, 2.2.2.2,
3.3.3.3, and 4.4.4.4 respectively.
Based on the preceding network planning scheme, Router B should be the router advertising
the Network LSA with the Link State ID being 10.0.0.2 and the attached routers should be
1.1.1.1 and 2.2.2.2.
4.
In this case, it is possible that an IP address conflict occurs on the network segment where
both Router C and Router D reside. Run the display ip interface brief and display ospf
brief commands on RouterA, RouterB, RouterC, and Router D. The actual configurations
on the devices are as follows (as shown in Figure 1-48):
l All the configurations on Router A and Router B are the same as that in the network
planning scheme.
l The IP addresses of GE 1/0/1 on Router C and Router D are 10.0.0.1/30 and 10.0.0.2/30,
which differ from that in the network planning scheme and conflict with the IP addresses
of Router A and Router B.
l The router ID of Router D is 2.2.2.2, which differs from that in the network planning
scheme and conflicts with the router ID of Router B.
Issue 03 (2013-08-15)

126

l Both Router B and Router D are DRs.

Figure 1-48 Networking diagram where conflicting IP addresses and router IDs are
configured
RouterA
RouterID 1.1.1.1
GE1/0/1
10.0.0.1/30
GE1/0/1
10.0.0.2/30
RouterB
RouterID 2.2.2.2
RouterC
RouterID 3.3.3.3
GE1/0/1
10.0.0.1/30
Metro Ethernet Network
GE1/0/1
10.0.0.2/30
RouterD
RouterID 2.2.2.2
RouterE
RouterID 5.5.5.5
User
5.
As the DRs on the network segment 10.0.0.0/30, both Router B and Router D send the
Network LSA with the following information:
l Link State ID: 10.0.0.2
l Advertising Router: 2.2.2.2
l In the LSA sent from Router B, the attached routers are 1.1.1.1 and 2.2.2.2; in the LSA
sent from Router D, the attached routers are 3.3.3.3 and 2.2.2.2.
According to OSPF, a device determines whether a received LSA was generated by itself
based on the standard and procedure shown in Figure 1-49.
Issue 03 (2013-08-15)

127

Figure 1-49 Standard and procedure used to determine whether the LSA was generated by
the system itself
An LSA is received.
Yes
Is the Advertising
Router the same as
the local Router ID?
No
Is the Link State ID the

same as the IP address
of a local interface?
No
Yes
Is the device able to

genarate the LSA?
No
The LSA is aged and advertised.
A new LSA is generated

and advertised.
When Router B receives a Network LSA with the Link State ID being 10.0.0.2 from
Router D, it determines that the LSA was generated by itself because:
l The value of the Advertising Router field in the LSA is 2.2.2.2, which is the router ID
of Router B, and the Link State ID in the LSA is the same as the IP address of GE 1/0/1
on Router B.
l Router B is a DR; so, it is able to generate the Network LSA.
Then, Router B advertises an updated Network LSA. When Router D receives the LSA
from Router B, it also advertises the updated LSA. As a result, Router B and Router D
repeatedly update the LSA, which leads to the frequent change in the LSDB on each device
and causes route flapping.
Procedure
Step 1 Run the system-view to enter the system view.
Issue 03 (2013-08-15)

128

NOTE
The configuration is performed on Router B. The configuration steps of Router A are similar to that of
Router B except the router ID, and are not mentioned here.
Step 2 Run the interface interface-type interface-number command to enter the interface view.
Step 3 Run the ip address ip-address command to assign a correct IP address.
Step 4 Run the quit command to return to the system view.
Step 5 Run the router id router-id command to set a correct router ID.
Step 6 Run the return command to return to the user view.
CAUTION
Restarting an OSPF process leads to the re-establishment of all neighbor relationships in the
process and transient interruption of services.
Step 7 Run the reset ospf process-id process command to restart the OSPF process.
After the configuration is complete, run the display ospf lsdb command repeatedly to ensure
that the LSDB has stabilized. At that time, the users can normally access the MAN, and the fault
is rectified.
----End
Summary
In normal situations, the value of the LS age field in an LSA increases from 0. When a
corresponding Link State Update packet is received, the age value of the LSA is updated based
on the Age field in that Link State Update packet. If the age value of an LSA is small for a long
time and then suddenly changes to 3600, it indicates that the network topology is unstable, which
is possibly due to loops or IP address conflicts.
In this case, you can repeatedly run the display ospf lsdb command to check the LSDB and find
the unstable LSA. If the networking is complicated, you can also run the tracert command to
isolate the problem to a device.
1.6.13 Dial-up Fails Because the Format of the Packet Sent from the
BRAS Is Inconsistent with That on the RADIUS Server
Fault Symptom
On the network shown in Figure 1-50, a user accesses the interface GE 1/0/1 on the router
through the switch in QinQ mode. VLAN tags are terminated on the router. The user account is
bound to a specific interface in a VLAN on the RADIUS server.
Issue 03 (2013-08-15)

129

Figure 1-50 Networking diagram of the unsuccessful dial-up because the format of the packet
sent from the device is inconsistent with that on the RADIUS server
User
GE 1/0/1
Network
Switch
Router
A "691" error is prompted when the user dials up.
Fault Analysis
1.
Check that the information about the interface and VLAN bound to the user account on the
RADIUS server is the same as the actual interface and VLAN for the user traffic.
2.
Run the display this command in the view of GE 1/0/1 on the router to check the
configurations on the interface. The command output shows the outer VLAN and inner
VLAN configured on the interface are correct.
3.
Enable the debugging of the RADIUS server. The following information is displayed:
[Reply-Message(18)
[175] [29;User(ntest0001)'s Authen
Attrib ai-vlan-id: NAS is 601.1001, RADIUS is
ge--1,0,1:601.1001--0,0,0,0,0,0, Not match)
Attrib(Authen
NAS is 601.1001 is the user information sent from the BRAS to the RADIUS server;
RADIUS is ge--1,0,1:601.1001 is the user information stored on the RADIUS server. The
router only sends the user VLAN information (601.1001) to the RADIUS server. The
RADIUS server, however, stores information about both the VLAN (601.1001) and
interface (ge--1,0,1) bound to the user account. The information sent for authentication
does not completely match the information stored on the RADIUS server. Therefore, the
user fails the authentication.
On the router, the attribute carrying the user information is NAS-Port-Id, which has four formats.
By default, the attribute is in the version 2.0 format. In this case, the format should be changed
to standard so that it can be consistent with the packet format (VLAN+interface) on the RADIUS
server.
Procedure
Step 3 Run the vlanpvc-to-username standard command to set the format of NAS-Port-Id to be sent
by the router to the RADIUS server to standard.
After the format has been changed, the user successfully dials up.
----End
Issue 03 (2013-08-15)

130

Summary
The possible causes of a "691" error in user dial-up are as follows:
l
The interface and VLAN bound to the user account are different from the planned interface
and VLAN
The VLANs configured on the interface of the BRAS are incorrect.
The format of user information sent from the BRAS is different from that on the RADIUS
server.
A certain policy is created to control communication between the router and the RADIUS
server, which causes the router unable to communicate with the RADIUS server.
1.6.14 Uses Fail to Log In Because the GTL License File Is Not
Loaded
Fault Symptom
One router is newly deployed at a site. After PPPoE services are configured on the router, dialup users fail to access the device and "619" errors are prompted.
Fault Analysis
1.
Run the display aaa online-fail-record command to find the cause of the user login failure.
The command output does not contain a cause.
2.
Run the debugging ucm all command. The command output shows an error message "This
slot did not have any GTL license. (Slot=3)."
The cause is that the GTL license file is not loaded to the router.
Procedure
Step 1 Contact Huawei technical support personnel to obtain the correct GTL license file, and then
upload the file to the cfcard:/ path on the router.
Step 2 Run the license active filename command in the user view to activate the GTL license file and
obtain the authority of corresponding functions.
----End
Summary
A correct GTL license file must be obtained before the deployment of a device at a new site;
otherwise, users cannot access the device.
The GTL license provides a control on the BAS function of boards and a control over the number
of users on an entire device. By default, the BAS function of boards is disabled; so, you need to
buy a GTL license. In addition, you need to run the bas enable command in the slot view to
enable the BAS function on the board.
By default, a device supports the access of 4K users. It means that the device supports the access
of 4K users when there are board licenses. If more than 4K users access the device, you need to
buy a GTL license.
Issue 03 (2013-08-15)

131

1.6.15 Modems of a Certain Brand Fail to Access the Internet

Because Multiple Interfaces Respond to the PADO Packet
Fault Symptom
On a network, three routers process user Internet services. Each router has two LPUs on which
sub-interfaces terminate all user VLAN tags, and all users can normally access the network.
Later, one more router is added for expansion, and each router now has four LPUs. Since then,
a lot of users make complaints that they fail to access the Internet. The analysis of the MAC
addresses of the modems of those users shows that their modems are of the same brand.
Fault Analysis
1.
Run the trace access-user object object-id command on any one of the routers to trace the
users failing to log in. The command output shows that the router has received the PPP
negotiation request but the negotiation process stopped at the LCP negotiation phase.
2.
Get packets head on one of the modems. It is found that the modem sends a PADR packet
after receiving the first PADO packet. After the router replies with a PADS packet, the
modem does not complete PPP negotiation but directly sends a PADT packet to terminate
the negotiation. The session ID of the PADT packet head is 0. It indicates that the modem
processes only the PADO packets sent from the routers.
3.
Users can access the Internet before the network expansion. The only change on the network
after expansion is that the number of BAS interfaces increases. After the modem sends the
PADI packet, the number of received PADO packets increases from 6 to 16. This may
cause the failure of PPP negotiation.
Then, adjust the number of BAS interfaces that respond to the modem. A test shows that
the modem counts the received PADO packets right after sending the PADI packet. If more
than 10 PADO packets are received, the modem stops PPP negotiation.
Procedure
Step 1 Reduce the number of BAS interfaces that respond to a user's authentication request through
certain network optimization.
----End
Summary
The protocol processing flow may vary with the brands or models of modems. In network
planning, try to reduce the number of BAS interfaces that respond to a user's authentication
request.
1.6.16 Setting up an L2TP Tunnel Fails Due to Slow Packet

Processing on the LNS
Issue 03 (2013-08-15)

132

Fault Symptom
The router functions as a LAC, and another vendor's device functions as an LNS. The tunnel
parameters are delivered by the RADIUS server. The user device initiates PPPoE dialing. After
successful user authentication, the LAC starts to set up a tunnel with the LNS.
Figure 1-51 Networking diagram of unsuccessful setup of an L2TP tunnel due to slow packet
processing on the LNS
User
Network
L2TP Tunnel
LAC
LNS
After the configuration is complete, L2TP services are unavailable for the user. After the display
l2tp tunnel command is run, the output shows that no tunnel is set up between the LAC and
LNS.
Fault Analysis
1.
Run the ping command to check the route between the LAC and LNS. The command output
shows that the route is reachable.
2.
Run the trace access-user command to check user dialing. The command output shows
that the user passes authentication and the LAC sends a request to the LNS for setting up
a tunnel. So, there is no problem with user dialing and authentication.
During the setup of the tunnel, however, a failure message is output by the LAC, which is
as follows: "Failed to create L2TP session and notify server user down."
3.
Check the tunnel parameters delivered by the RADIUS server together with the RADIUS
vendor and confirm that the delivered tunnel parameters are correct.
4.
Enable the debugging of L2TP on the LNS. The debugging result shows that the LNS
receives an SCCRQ packet from the LAC and starts to set up a tunnel with the LAC. Before
the tunnel is set up, the LNS receives another SCCRQ packet and considers this as an
exception. As a result, the LNS stops the setup of the tunnel. As the process repeats, no
tunnel is set up between the LAC and LNS.
It is confirmed that the LNS does not complete the setup of the tunnel before the tunnel timeout
period expires on the LAC. Then, the LAC sends a request for setting up a tunnel again, which
causes the LNS to stop the ongoing tunnel setup.
Procedure
Step 2 Run the l2tp-group group-name command to enter the L2TP group view.
Step 3 Run the tunnel timeout 5 command to set the tunnel timeout period to 5 seconds.
Issue 03 (2013-08-15)

133

By default, the L2TP tunnel timeout period is 2 seconds. When the period is changed to 5 seconds,
the fault is rectified.
----End
Summary
The possible causes of the unsuccessful L2TP tunnel setup are as follows:
l
The route between the LAC and LNS is unreachable.
Dial-up users fail the authentication, and as a result, the LAC does not send a request to
the LNS for setting up a tunnel.
The tunnel parameters delivered by the RADIUS server are incorrect.
The tunnel parameters set on the LNS and LAC do not match.
In this case, the fault is due to the last cause.
1.6.17 A User Cannot Obtain the Associated Authority Because the

AAA Authorization Mode and AAA Authentication Mode Are
Inconsistent
Fault Symptom
On the router, AAA local authentication is configured for a Telnet user and the level-15 authority
is assigned to the user.
After a VTY user logs in, run the display user-interface command to view the authority of the
VTY user. You can find that the VTY user can obtain only the level-0 authority, not the level-15
authority.
<HUAWEI> display userinterface
Idx Type
Tx/Rx
0
CON 0
9600
33
AUX 0
9600
+ 34
VTY 0
Modem Privi ActualPrivi Auth Int

3
N
-
N
0
The VTY user can obtain the level-15 authority only after the super command is run.
Fault Analysis
1.
Run the display current-configuration command to check the authentication mode

configured on the VTY user interface.
<HUAWEI> display current-configuration
user-interface vty 0 4
authentication-mode aaa
protocol inbound all
The command output shows that the VTY user interface is correctly configured with the
AAA authentication mode.
2.
Run the display current-configuration command to check the AAA configuration.

<HUAWEI> display current-configuration
#
Issue 03 (2013-08-15)

134

aaa
local-user ipopss password cipher .J]K3BK;Q!!
local-user ipops service-type telnet ssh
local-user ipops level 15
authentication-scheme default
authentication-mode local
authentication-super super
#
authorization-scheme default
authorization-mode if-authenticated
#
accounting-scheme default
accounting start-fail online
#
domain default
#
The command output shows that the authorization mode used in the authentication scheme
is if-authenticated. In if-authenticated mode, a user can obtain the related authority only
after the user passes the authentication that is not in none mode.
When a VTY user logs in, the router authorizes the VTY user in if-authenticated mode.
Although the local user is configured with the level-15 authority, the VTY user cannot
obtain the level-15 authority, because the authorization mode is not local authorization.
Instead, the default authority is assigned to the VTY user. The default authority of a VTY
user is the level-0 authority, and therefore the VTY user is assigned the level-0 authority.
Procedure
Step 3 Run the authorization-scheme default command to enter the default authentication scheme
view.
Step 4 Run the authentication-mode local command to configure the local authentication mode.
After the configuration, when the VTY user logs in, run the display user-interface command
to view the authority of the VTY user.
<HUAWEI> display userinterface
Idx Type
Tx/Rx
0
CON 0
9600
33
AUX 0
9600
+ 34
VTY 0
Modem Privi ActualPrivi Auth Int

3
N
-
N
15
The command output shows that the VTY user can obtain the level 15 authority. Therefore, the
fault is rectified.
----End
Summary
When configuring the AAA authentication mode, ensure that the authentication mode and the
authorization mode are consistent.
Issue 03 (2013-08-15)

135

1.6.18 Ping from the LAC to a Server in the Same Subnet Fails
Fault Symptom
On the network shown in Figure 1-52, an L2TP tunnel is set up between the user PC and the
router, and the router is directly attached to a server. The PC can obtain an IP address from the
IP address pool on the router. The obtained IP address and that of the server are on the same
network segment.
Figure 1-52 Networking diagram of unsuccessful ping from the LAC to a server in the same
subnet
LAC
Internet
LNS
L2TP Tunnel
PC
Internal
Server
After the PC accesses the VPN, the ping from the PC to the physical interface on the router
succeeds, but the ping from the PC to the server in the same subnet fails. The ping from the
router to the PC and server succeeds.
Fault Analysis
1.
There is no problem with L2TP configurations because the PC obtains an IP address through
L2TP dial-up and the ping from the PC to the physical interface on the router is successful.
2.
There is no problem with the route from the router to the server because the ping from the
router to the server is successful. The unsuccessful ping from the PC to the server may be
due to the ARP problem.
3.
Check the ARP entries on the server. The check result shows that the server has not learned
the ARP entry of the PC.
The PC accesses the intranet in L2TP mode and a point-to-point connection is set up
between the PC and LNS. All the traffic from the PC is forwarded by the router to the
server. Receiving a ping request packet, the server finds that the source address in the packet
is in the same network segment as the IP address of the server. Then, the server checks
ARP entries and finds that only the interface on the router is directly connected to itself.
The server does not have the ARP entry of the PC. Therefore, it is impossible for the server
to respond to this ping request packet.
To rectify the fault, you can enable the ARP proxy function on the router.
Procedure
Step 1 Run the system-view command on the router to enter the system view.
Step 2 Run the interface interface-type interface-number command to enter the view of the interface
connected to the server.
Issue 03 (2013-08-15)

136

Step 3 Run the arp-proxy enable command to enable the ARP proxy function on the interface.
When the configuration is complete, the ping from the PC to the server succeeds, and the fault
is rectified.
Step 4 Run the return command to return to the user view and run the save command to save the
modification.
----End
Summary
The ARP proxy function needs to be enabled when the IP address allocated by the router to the
PC in L2TP access mode is on the same subnet as the connected customer-facing interface on
the LNS.
1.6.19 Failure to Obtain an IP Address

Scenario
Figure 1-53 IPoX networking
RADIUS
Server
I n t e r ne t
subscriber
Router
Fault Analysis
The possible causes are as follows:
l
If the IP address is assigned by the local router, the failure may be caused by the improper
configuration of the local address pool.
If the IP address is assigned by the remote DHCP server, the failure may be caused by the
improper configuration of address pool or communication error.
The authentication mode of the domain is incorrect.
Procedure
Step 1 Check whether the IP address is assigned by the router or the remote DHCP server.
Step 2 Check the configuration of local IP address assignment.
If the IP address is assigned by the local router, run the display domain command to check the
address pool referenced by the domain.
Issue 03 (2013-08-15)

137

l For a web authentication user, check the configuration of pre-authentication domain.

l For a binding authentication user, check the configuration of authentication domain.
l Run the display ip pool command to check that there is idle IP address in the address pool.
Step 3 Check the DHCP server.
If the IP address is assigned by the remote DHCP server, do as follows:
l Run the ping command to check the communication between the remote DHCP server and
the NE80E/40E .
l Run the display domain command to check whether the address pool referenced by the
domain is correct.
l Run the display ip pool command to check whether the address pool type is remote and the
address pool has referenced the DHCP server group.
Step 4 Check the authentication.
To obtain an IP address, the user must pass the authentication of the domain.
l The web authentication user is authenticated in the pre-authentication domain and adopts the
account format of the binding authentication.
l The binding authentication user is authenticated in the authentication domain.
l For the local authentication or RADIUS user, the user name and password must be configured
on the AAA server.
Step 5 Enable service tracing.
The key messages in service tracing are as follows:
l DHCP DISCOVER packet
Dec 4 2009 16:39:38.940.2 HUAWEI DHCPACC/7/
DHCPACC_DBG:
PKT INFO: Hardware Type = 1, Hardware Address Length =
6
Hops = 0, Transaction ID =
0
Seconds = 0, Broadcast Flag =
1
Client IP Address = 0.0.0.0, Your IP Address =
0.0.0.0
Server IP Address = 0.0.0.0, Gateway IP Address =
0.0.0.0
Client Hardware Address =
0001-9901-0101
Server Host Name = [N/A], Boot File Name = [N/
A]
Dhcp message type = DHCP_DISCOVER
This is the first DHCP message. If the message is not included in the output, check if the
layer-2 network operates well. The access type configured on BAS interface is layer2subscriber. The web authentication and fast authentication are configured on the BAS
interface. The BAS interface is up.
NOTE
If the user gets online more than once, the DHCP Request packet is sent, while this message is not sent.
l Authentication message
[UCM DBG]MSG Recv From:DHCP Code:DHCPACC_UCM_CONN_REQ(200) Event:CONN_REQ Src:
635 Dst:4294967295
Issue 03 (2013-08-15)

138

[UCM DBG]MSG Send To:AAA Code:UCM_AAA_AUTH_REQ(83) Src:628 Dst:628

Dec 4 2009 16:39:38.940.30 HUAWEI UCM/7/DebugInfo:
[UCM DBG]UserName:HUAWEI@kouki
[UCM DBG]UCM -> AAA : Send Msg Success
The preceding message shows that the CM sends the authentication request after it receives
the connection request of the user.
l
Dec 4 2009 16:39:38.940.46 HUAWEI AAA/7/AAADBG:

[AAA debug] Code: AAA->UCM
authen ack UserID: 628
Dec 4 2009 16:39:38.940.47 HUAWEI AAA/7/AAADBG:
AAA EVENT:CID = 628,UserName = HUAWEI@kouki Authen State is OK
[UCM DBG]Translate Msg(84) to Event(3)
[UCM DBG]MSG Recv From:AAA Code:AAA_UCM_AUTH_ACK(84) Event:AUTH_PASS Src:628
Dst:628
l Connection response message

Dec 4
[UCM
Dec 4
[UCM
Dec 4
[UCM
Dec 4
[UCM
2009 16:39:38.940.56 HUAWEI UCM/7/DebugInfo:

DBG]Send Connect Ack to DHCPACC. Lease Time = 0 NeedReAuthen = 0
DBG]MSG Send To:DHCP Code:UCM_DHCPACC_CONN_ACK(201) Src:628 Dst:635
DBG]Result:0 Server:0 Gate:ffffffff
DBG]UCM -> DACC : Send Msg Success
After the authentication succeeds, the CM sends the connection response message to the
DHCPACC.
l IP address assignment request
Dec 4 2009 16:39:38.940.71 HUAWEI DHCPS/7/DHCPS_DBG: Event:
Enter AM_DHCPS_ReqIp to apply ip [ffffffff]
The applied free ip is a000061
Dec 4 2009 16:39:38.940.73 HUAWEI DHCPS/7/DHCPS_DBG:AM_DHCPS_ReqIp return
VOS_OK
DHCPS:AM_DHCPS_ReqIp return VOS_OK.Apply OK and send Offer.
After the DHCPACC receives the connection response message, it forwards the DHCP
Discover message to the DHCPS. Then, the DHCPS applies for IP address to the address
manager (AM).
Sep 5 2009 11:31:54.230.5 HUAWEI DHCPACC/7/DHCPACC_DBG: Event: DHCPACC_UcmAcp
tForDiscover: Send discover packet to server successfully and useris state is c
hanged to DHCPACC_DIS_WAIT_SERVER_OFFER
If successfully is not included in the preceding message, check the configuration of the local
address pool.
l DHCP protocol packet
Dec
[
[
[
[
[
[
[
[
[
[
[
[
[
Issue 03 (2013-08-15)
4 2009 16:39:38.940.77 HUAWEI DHCPS/7/DHCPS_DBG:

DHCPS send ] : =====
Xid
]:0
cmd
]:2
Htype ]:1
Hlen ]:6
Hops ]:0
Secs ]:0
Flag ]:32768
Ciadd ]:0.0.0.0
Yiadd ]:10.0.0.97
Siadd ]:0.0.0.0
Giadd ]:10.0.0.1
Sname ]:

139

[ File ]:
[ Option]:----Message type:OFFER
Server id:10.0.0.1
leasetime:259200s
Renewtime:129600s
Rebindtime:226800s
Option82 :RID:HUAWEI-0100-0000-GE,CID:0100-0000-GE
From the preceding three messages, you can learn whether the DHCP Offer, DHCP Request,
or DHCP Ack packets fail. Analyze the returned packet to find the cause of the fault.
If the IP address is assigned by a remote DHCP server, the output of the service tracing also
shows you how the device interoperates with the DHCP server.
Step 6 Analyze the debugging information.
The output information of debugging is more specific than the service tracing information. It
helps you locate the fault.
----End
Summary
To use the DHCP server to assign IP addresses, make sure that the DHCP server can
communicate with the NE80E/40E .
1.6.20 Web Authentication Fails

Scenario
The networking is as shown in 1.6.19 Failure to Obtain an IP Address .
Fault Analysis
l
The web authentication is configured improperly.
An error occurs on the RADIUS server.
Procedure
Step 1 Display the online failure records.
<HUAWEI> display aaa online-fail-record
------------------------------------------------------------------User name
: 0001-0101-0101@local
User MAC
: 0001-0101-0101
User access type
: IPoE
User interface
: Atm4/0/2
User Pe Vlan
: 0
User Ce Vlan
: 0
User IP address
: User ID
: 14
User authen state : Authened
User acct state
: AcctIdle
User author state : AuthorIdle
User login time
: 2009-09-05 12:58:05
Online fail reason : LAM user does not exist
-------------------------------------------------------------------------------------------------------------------------------------
Issue 03 (2013-08-15)

140

Table 1-2shows the reasons why the user fails to go online.

Table 1-2 Reasons for online failure
User Online Fail Reason
Meaning
Web user request
Indicates that the user sends an offline request.
DHCP decline
Indicates the DHCP decline.
IP address alloc fail
Indicates the failure to assign IP addresses.
IP address conflict
Indicates that the IP addresses conflict.
MAC address conflict
Indicates that the MAC addresses conflict.
Start accounting fail
Indicates the failure to start accounting.
Domain or user access limit
Indicates the limit on domain or user access.
Port access limit
Indicates the access limit on the port.
Send authentication request fail
Indicates the failure to send the authentication

request.
RADIUS authentication reject
Indicates that the RADUIS server rejects the

RADIUS authentication send fail
Indicates the failure to send the RADIUS

Local authentication reject
Indicates that the local authentication is rejected.
Local authentication no user
Indicates that the user name cannot be found in the

local authentication domain.
Local Authentication user type not

match
Indicates that the user type does not match with the
local domain.
Local Authentication user block
Indicates that the account is not activated in the

local authentication.
Step 2 Troubleshoot the Web authentication.

If there is no corresponding online failure record or the failure record is "web user request", it
indicates the Web authentication is not complete or an error occurs in the authentication. In this
case, debug the Web authentication and analyze the output of the debugging command.
Dec 4 2009 10:54:58.190.7 HUAWEI WEB/8/DEBUG:
Received packet from socket (length = 32 Vrf = 0):
Version
: 2
Type
: challenge request
Method
: chap
SerialNo
: 112
RequestID
: 0
UserIP
: 4.2.127.242
ErrorCode
: 0
AttributeNumber : 1
Issue 03 (2013-08-15)

141


02 01 00 00 00 4d 00 00 03 03 c8 c3 00 00 00 00
56 74 98 e8 7e b7 a4 5d 7c 6a 74 11 2c f9 66 94
Dec 4 2009 10:54:58.190.9HUAWEI WEB/8/DEBUG:
Sent packet to socket (length = 50 Vrf = 0):
Version
: 2
Type
: challenge ack
Method
: chap
SerialNo
: 77
RequestID
: 14
UserIP
: 4.2.127.242
ErrorCode
: 0
AttributeNumber : 1
02 02 00 00 00 4d 00 0e 03 03 c8 c3 00 00 00 01
fb 08 7e 70 27 36 37 c5 9b cb 9b 14 cf ac 40 38
03 12 49 eb 51 11 bd 15 63 ff 8b c7 59 ad 61 59
30 30 30 30 30 40 76 6c 61 6e
If the web server is of V1, the preceding information is not included in the output. If the web
server is of version 2, the info req packet is received before the info ack request. If the NE80E/
40E cannot receive the info rep packet, check the configuration of the web server.
Version
: 2
Type
: authentication request
Method
: chap
SerialNo
: 77
RequestID
: 14
UserIP
: 3.3.200.195
ErrorCode
: 0
AttributeNumber : 2
02 01 00 00 00 62 00 00 0c 2f 7f ff 00 00 00 00
c3 12 23 44 44 ae 92 67 4e e5 c3 99 7d 8b 43 2a
In case of CHAP authentication, the web server sends the challenge req request. If the NE80E/
40E cannot receive this message, check the configuration of the Web server.
Version
: 2
Type
: authentication ack
Method
: chap
SerialNo
: 77
RequestID
: 14
UserIP
: 3.3.200.195
ErrorCode
: 0
AttributeNumber : 0
02 04 00 00 00 4d 00 0e 03 03 c8 c3 00 00 00 00
a9 ae 06 5f 62 94 f7 9a b2 a5 35 f8 12 95 dc 6f
89 03
Version
: 2
Type
: ack of authentication ack
Method
: chap
SerialNo
: 77
RequestID
: 14
UserIP
: 3.3.200.195
ErrorCode
: 0
AttributeNumber : 0
02 07 00 00 00 4d 00 0e 03 03 c8 c3 00 00 00 00
1e 66 fb e1 e5 2a 4f e3 c7 c3 35 45 f3 79 c3 cd
Issue 03 (2013-08-15)

142

In the authentication request, if the PAP authentication is used, the method field in the packet
is PAP. If the user does not receive this packet in authentication, check the web server.
Version
: 2
Type
: authentication ack
Method
: chap
SerialNo
: 77
RequestID
: 14
UserIP
: 3.3.200.195
ErrorCode
: 0
AttributeNumber : 0
02 04 00 00 00 4d 00 0e 03 03 c8 c3 00 00 00 00
a9 ae 06 5f 62 94 f7 9a b2 a5 35 f8 12 95 dc 6f
The preceding information is the authentication response that informs the web server of the
authentication result. If the NE80E/40E receives the logout req packet immediately after or
before the auth ack packet, check whether the interval between the auth ack packet and the auth
req packet exceeds the time-out time of the web server.
Version
: 2
Type
: ack of authentication ack
Method
: chap
SerialNo
: 77
RequestID
: 14
UserIP
: 3.3.200.195
ErrorCode
: 0
AttributeNumber : 0
02 07 00 00 00 4d 00 0e 03 03 c8 c3 00 00 00 00
1e 66 fb e1 e5 2a 4f e3 c7 c3 35 45 f3 79 c3 cd
After receiving the authentication success response, the web server needs to display the
authentication success page for the user. If the success page is not displayed, the user cannot go
online. The NE80E/40E allows the user to access the Internet and conducts the accounting for
the user only after receiving the result from the web server.
You can analyze the output of service tracing in the same way you analyze the debugging
information and get the same result.
For details, see 1.3.1 Troubleshooting IPoX .
Step 4 Troubleshoot the RADIUS server.
For the RADIUS authentication failure, refer to 5 "Interconnection Fails Between the Device
and the RADIUS Server."
If the fault persists, contact Huawei technical personnel.
----End
1.6.21 Mandatory Web Authentication Fails

Scenario
The networking is as shown in 1.6.19 Failure to Obtain an IP Address .
Issue 03 (2013-08-15)

143

Fault Analysis
l
The user does not obtain an IP address.
The route of the web server is wrong.
The ACL is applied.
The server works abnormally.
The user group is configured improperly.
The DNS server is configured improperly.
Procedure
Step 1 Check whether the user has obtained an IP address.
An IP address is the prerequisite to any online activity. If the user cannot obtain an IP address,
solve the problem by referring to 1.6.19 Failure to Obtain an IP Address .
Step 2 Access the web server with the IP address.
After obtaining the IP address, enter the IP address of the web server in the browser. If the web
page is displayed, it indicates that the traffic policy, the route, and the server work properly.
If you fail to open the web page, do as follows:
l Check the route to the web server by using the ping and tracert commands.
l Check the traffic policy, the classifier, and the behavior. Make sure the traffic policy is applied
to the correct interface.
l Check whether the web server works normally.
Step 3 Access a website that you are not authorized to.
If you can get access to the web server, try to access an IP address that you are not authorized
to. If you cannot be redirected to the web page, it indicates that the configuration of the mandatory
web authentication is improper.
In this case, do as follows:
l Check the user group by using the display access-user command.
l Check the traffic policy. Only the web server and DNS can be accessed. Do not forbid the
authorized addresses.
l Check the interface that the traffic policy is applied to. For some users, the traffic policy is
applied to the sub-interface, not the main interface.
Step 4 Enter the domain name in the browser.
If you can be redirected to the web page after entering an IP address, try to enter a domain name
in the browser. If you are not redirected to the web server, check the following:
l Whether the DNS is configured with an ACL permitting the user access.
l Whether the route to the DNS is reachable.
l Whether the DNS operates well.
Issue 03 (2013-08-15)

144

Besides, you can also replace the DNS with another one to see if the mandatory web
authentication failure is caused by the DNS.
----End
Summary
If mandatory web authentication does not work, check the configurations of the user group
number and the traffic policy.
If you are redirected to the mandatory web server by entering any IP address, rather than domain
name, the failure may be caused by the DNS server.
Issue 03 (2013-08-15)

145

2 Client Fails to Obtain an IP Address Troubleshooting
Client Fails to Obtain an IP Address

Troubleshooting
About This Chapter
2.1 An Ethernet Client Fails to Obtain an IP Address (the HUAWEI NetEngine80E/40E

Functions as the DHCP Server)
procedure for the fault that an Ethernet client fails to obtain an IP address when the HUAWEI
NetEngine80E/40E functions as the DHCP server.
2.2 An Ethernet Client Cannot Obtain an IP Address (the HUAWEI NetEngine80E/40E
Functions as the DHCP Relay)
NetEngine80E/40E functions as the DHCP relay.
2.3 A PPPoX/IPoX Client Fails to Obtain an IP Address (the HUAWEI NetEngine80E/40E
Functions as the DHCP Server)
procedure for the fault that a PPPoX/IPoX client fails to obtain an IP address when the HUAWEI
2.4 A PPPoX/IPoX Client Cannot Obtain an IP Address (the HUAWEI NetEngine80E/40E
Functions as the DHCP Relay)
procedure for the fault that a PPPoX/IPoX client cannot obtain an IP address when the HUAWEI
2.5 Troubleshooting in the Scenario Where the NE80E/40E Functions as a Local DHCPv6
Server
This section describes the notes about configuring the NE80E/40E as a local DHCPv6 server,
and provides the troubleshooting flowchart and the troubleshooting procedure in a networking
where the NE80E/40E functions as a local DHCPv6 server.
2.6 Troubleshooting in the Scenario Where the NE80E/40E Functions as a Delegating Router
Issue 03 (2013-08-15)

146

This section describes the notes about configuring the NE80E/40E as a delegating server, and
provides the troubleshooting flowchart and the troubleshooting procedure in a networking where
the NE80E/40E functions as a delegating server.
2.7 Troubleshooting in the Scenario Where the NE80E/40E Functions as a DHCPv6 Relay Agent
This section describes the notes about configuring the NE80E/40E as a DHCPv6 relay agent,
where the NE80E/40E functions as a DHCPv6 relay agent.
2.8 User Cannot Obtain an Address from the Address Pool According to the Pool ID Delivered
by the RADIUS Server
procedure for the fault that the NE80E&40E cannot allocate an address from the corresponding
address pool to the user after the RADIUS server delivers No.100 attribute Framed-IPv6Pool or HUAWEI No.191 attribute Delegated-IPv6-Prefix-Pool.
Issue 03 (2013-08-15)

147

2.1 An Ethernet Client Fails to Obtain an IP Address (the

HUAWEI NetEngine80E/40E Functions as the DHCP
Server)
2.1.1 Common Causes

l
DHCP is not enabled.
The IP address of the interface connecting to the client is incorrect, or the IP address pool
whose gateway is the same as the IP address of the interface connecting to the client does
not exist.
The IP address pool is incorrectly configured. For example, the IP address pool is
configured to be the Server or Remote type, or the IP address pool is locked.
The IP address pool has no assignable IP address.
The link between the DHCP server and the client is faulty.
Another device along the link is incorrectly configured.
2.1.2 Troubleshooting Flowchart

When the HUAWEI NetEngine80E/40E functions as the DHCP server, a PPPoX/IPoX client
cannot obtain an IP address.
l
Check that the IP address pool of the DHCP server is correctly configured and IP addresses
can be assigned.
Check the link between the DHCP server and the client is normal.
Check that other devices along the link are correctly configured.
Issue 03 (2013-08-15)

148

Figure 2-1 Troubleshooting flowchart for the fault that an Ethernet client fails to obtain an IP
address (the HUAWEI NetEngine80E/40E functions as the DHCP server)
A client fails to obtain an IP
address
Is DHCP enabled?
No
Enable DHCP
Is fault rectified?
Yes
No
Yes
Is the interface at the user

side assigned a correct IP
address?
No
Configure a correct IP
address
Yes
No
Yes
Does an IP address pool

exist?
No
Create an IP address
pool
Is fault rectified?
Yes
No
Yes
Is the IP address pool

No
Rectify the fault

according to the specific
troubleshooting
procedure
Is fault rectified?
Yes
No
Yes
Does the IP address pool

have assignable IP
addresses?
No
Increase the number of IP

addresses in the IP
address pool or solve the
IP address conflict
problem
Is fault rectified?
Yes
No
Yes
Is the link between the

DHCP server and the
client normal?
No
Rectify the link fault
Is fault rectified?
Yes
No
Yes
Are other devices correctly

configured?
No
Rectify the fault

according to user manual
for these devices
Is fault rectified?
Yes
No
Yes
Issue 03 (2013-08-15)
Is fault rectified?

End
149

2.1.3 Troubleshooting Procedure

Before performing the following procedure, you can also refer to common causes for users fail
to get online to solve this fault.
NOTE
Procedure
Step 1 Check that the DHCP function is enabled.
Run the display current-configuration | include undo dhcp enable command to check whether
the DHCP function is enabled. By default, the DHCP function is enabled.
l
If the command output shows undo dhcp enable, it indicates that the DHCP function is
disabled, and you need to run the dhcp enable command to enable the DHCP function.
If there is no command output, it indicates that the DHCP function is enabled. Then, go to
Step 2.
Step 2 Check that the interface connecting to the client is configured with a correct IP address.
Run the display this command in the view of the interface connecting to the client to check
whether an IP address is configured for the interface.
l
If the IP address is incorrect or no IP address is configured, run the ip address ipaddress command to correctly configure an IP address.
If the IP address is correct, go to Step 3.
Step 3 Check that the IP address pool is correctly configured.

Run the display current-configuration filter gateway ip-address mask command to check
whether there is a local IP address pool whose IP addresses belong to the same network segment
with the gateway (relay access) or with the IP address of an interface (non-relay access).
l
If there is no command output, it indicates that the IP address pool does not exist. In this
case, run the following commands.
Run the ip pool pool-name server command to create an IP address pool.
Run the gateway ip-address { mask | mask-length } command to create the gateway of
the IP address pool.
Run the section section-num start-ip-address [ end-ip-address ] to configure the range
of assignable IP addresses.
For detailed configurations of the IP address pool, refer to the HUAWEI NetEngine80E/
40E Configuration Guide - User Access.
If the correct IP address pool exists, go to Step 4.
Step 4 Check that the IP address pool is correctly configured and IP addresses can be assigned.
Run the display ip pool name pool-name command to check whether the corresponding fields
have the correct values based on the following check steps. If any field has an incorrect value,
rectify the fault based on the following rectification procedure.
Issue 03 (2013-08-15)

150

Item
Field
Correct Value
Restoration
Procedure
Check whether the

type of the IP address
pool is Server.
Position
Server
If the field is
displayed as Local or
Remote, run the ip
pool pool-name bas
remote command
again to set the IP
address pool to the
Server type.
Check whether the IP

address pool is
locked.
Status
Unlocked
If the field is
displayed as
Locked, run the
undo lock command
to unlock the IP
address pool.

address pool has
assignable IP
addresses.
idle
If the idle field is

displayed as a value
larger than 0, it
indicates that
assignable IP
addresses exist in the
IP address pool.
l If there are
conflicting IP
addresses, run the
reset conflict-ipaddress
command to
mark the
conflicting IP
addresses as idle.
conflicted
If the conflicted field

is displayed as 0, it
indicates that there
are no conflicting IP
addresses.
l Re-plan the
network and
increase the
number of IP
addresses in the
IP address pool.
After the preceding steps, if the client still cannot acquire an IP address, go to Step 5.
Step 5 Check that the link between the DHCP server and the client is normal.
On the client, configure an IP address to make the client and the IP address pool of the DHCP
server on the same network segment (note that the IP address of the client cannot conflict with
an assigned IP address). Then, ping the IP address on the DHCP server to check whether the
link between the DHCP server and the client is normal.
l
If the ping operation fails, it indicates that a routing fault occurs between the DHCP server
and the client, and you need to rectify the fault immediately.
If the ping operation succeeds, go to Step 6.
Step 6 Check that the configurations of other devices along the link are correct, including the DHCP
relay, DSLAM, LAN switch, and the client.
Issue 03 (2013-08-15)

151

Check whether the configurations of these devices are correct based on the device manuals. If
not, modify the configurations. After the preceding steps, if the client still cannot acquire an IP
address, go to Step 7.
----End
2.1.4 Relevant Alarms and Logs

Relevant Alarms
None.
Relevant Logs
None.
2.2 An Ethernet Client Cannot Obtain an IP Address (the

HUAWEI NetEngine80E/40E Functions as the DHCP Relay)
2.2.1 Common Causes

l
DHCP relay is not enabled.
Incorrect DHCP option number, relay agent address, or DHCP server address is configured.
The link between the DHCP relay and the DHCP server or between the DHCP relay and
the client is faulty.
The dhcp relay userinfo enable command is not used.

When the HUAWEI NetEngine80E/40E functions as the DHCP relay, an Ethernet client enabled
with DHCPv4 cannot obtain an IP address.
l
Issue 03 (2013-08-15)
Check that the DHCP relay is correctly configured.

152

Check the link connectivity between the DHCP relay and the DHCP server or between the
DHCP relay and the client.
Check whether the VLAN segment configured on the DHCP relay-enabled interface is one
of the VLAN segments configured on the sub-interface for dot1q or qinq VLAN tag
termination. If the VLAN segment configured on the DHCP relay-enabled interface is one
of the VLAN segments configured on the sub-interface for dot1q or qinq VLAN tag
termination, check whether the dhcp relay userinfo enable command is used.
Issue 03 (2013-08-15)

153

Figure 2-2 Troubleshooting flowchart for the fault that an Ethernet client fails to obtain an IP
address (the HUAWEI NetEngine80E/40E functions as the DHCP relay)
A client fails to obtain an
IP address
Is DHCP enabled?
No
Enable DHCP
No
Enable DHCP relay
No
Correctly configure
DHCP relay
attributes
Yes
Is fault rectified?
Yes
No
Yes
DHCP relay and DHCP
server/client normal?
Is fault rectified?
No
Yes
Are DHCP relay

attributes correct?
Yes
No
Yes
Is DHCP relay enabled?
Is fault rectified?
No
Is fault rectified?
Yes
No
Yes
Check whether the

DHCP relay-enabled Interface is
the sub-interface for dot1q or qinq
VLAN tag termination and a VLAN
segment is Configured on the VLAN
Of the interface.
No
Run the dhcp

relay Userinfo
enable
command
Is fault rectified?
Yes
No
Yes
Are other devices

No
Rectify the fault

according to user
manual for these
devices
Yes
Is fault rectified?
Yes
No
End

Issue 03 (2013-08-15)

154

NOTE
Procedure
Step 1 Check that the DHCP function is enabled.
Run the display current-configuration | include undo dhcp enable command to check whether
the DHCP function is enabled. By default, the DHCP function is enabled.
l
If the command output shows undo dhcp enable, it indicates that the DHCP function is
disabled, and you need to run the dhcp enable command to enable the DHCP function.
If there is no command output, it indicates that the DHCP function is enabled. Then, go to
step 2.
Step 2 Check that the DHCP relay function is enabled and correct attributes are configured.
Run the display dhcp relay address interface interface-type interface-number command.
l
If there is no command output, it indicates that the DHCP relay function is disabled or the
IP address of the DHCP server is not configured. Therefore, run the dhcp select relay
command to enable the DHCP relay function, and then run the ip relay address command
to configure the IP address of the DHCP server.
If the field, Dhcp Option (DHCP option number), Relay Agent IP (IP address of the relay
agent), or Server IP (IP address of the DHCP server), is incorrectly displayed, run the ip
relay address command to modify the relevant attribute.
If all these fields are correctly displayed, go to step 2.
Step 3 Check that the link between the DHCP relay and the DHCP server is normal.
Run the ping -a source-ip-address destination-ip-address command on the DHCP relay. sourceip-address indicates the IP address of the interface on the DHCP relay connecting to a client,
and destination-ip-address indicates the IP address of the DHCP server.
l
If the ping operation fails, it indicates that a routing fault occurs between the DHCP relay
and the DHCP server, and you need to rectify the fault immediately.
If the ping operation succeeds, go to step 3.
Step 4 Check that the link between the DHCP relay and the client is normal.
On the client end, configure an IP address to make the client and the DHCP relay on the same
network segment (note that the IP address of the client cannot conflict with an assigned IP
address). Then, ping the IP address on the DHCP relay to check whether the link between the
DHCP relay and the client is normal.
l
If the ping operation fails, it indicates that a routing fault occurs between the DHCP relay
If the ping operation succeeds, go to step 5.
Step 5 Check whether the DHCP relay-enabled interface is the sub-interface for dot1q or qinq VLAN
tag termination and a VLAN segment is configured on the VLAN of the interface.
Issue 03 (2013-08-15)

155

l If the DHCP relay-enabled interface is the sub-interface for dot1q or qinq VLAN tag
termination and a VLAN segment is configured on the VLAN of the interface, check whether
the dhcp relay userinfo enable command is used. If the dhcp relay userinfo enable
command is not used, run the dhcp relay userinfo enable command in the system view.
l If the DHCP relay-enabled interface is not the sub-interface for dot1q or qinq VLAN tag
termination on which a VLAN segment is configured, go to step 6.
Step 6 Check that configurations of other devices along the link are correct, including the DHCP server,
DSLAM, LAN switch, and the client.
Check whether the configurations of these devices are correct based on the device manuals. If
not, modify the configurations. After the preceding steps, if the client still cannot acquire an IP
address, go to step 7.
l Results of the preceding troubleshooting procedure.
----End

Relevant Alarms
None.
Relevant Logs
None.
2.3 A PPPoX/IPoX Client Fails to Obtain an IP Address (the

HUAWEI NetEngine80E/40E Functions as the DHCP
Server)
procedure for the fault that a PPPoX/IPoX client fails to obtain an IP address when the HUAWEI
2.3.1 Common Causes

l
The client is bound to an incorrect domain.
configured to be the Server or Remote type, or the IP address pool is locked.
The BAS interface is incorrectly configured.
Issue 03 (2013-08-15)

156

The link between the DHCP server and the client is faulty.

When the HUAWEI NetEngine80E/40E functions as the DHCP server, a PPPoX/IPoX client
enabled with DHCPv4 cannot obtain an IP address.
l
Check that the IP address pool and BAS interface of the DHCP server are correctly
configured and IP addresses can be assigned.
Check the link connectivity between the DHCP server and the client.
Issue 03 (2013-08-15)

157

Figure 2-3 Troubleshooting flowchart for the fault that a PPPoX/IPoX client cannot obtain an
IP address (the HUAWEI NetEngine80E/40E functions as the DHCP server)
address
Is the interface bound

to a correct domain?
No
Bind the correct domain

to the interface
Yes
Is fault rectified?
Yes
No
Is the domain bound to

a correct IP address?
No
Bind a correct IP address

to the domain
Is fault rectified?
Yes
No
Yes

correctly configured.
No Rectify the fault according to

the specific troubleshooting
procedure
Yes
Is fault rectified?
Yes
No
Does the IP address pool

have assignable IP
addresses?
No
Increase the number of IP

addresses in the IP address
pool or solve the IP address
conflict problem
Yes
Is fault rectified?
Yes
No
Is the BAS interface

No Rectify the fault according to

the specific troubleshooting
procedure
Yes
Is fault rectified?
Yes
No
Is the link between

the DHCP server and the
client normal?
No
Is fault rectified?
Yes
Yes
No

configured?
No
Rectify the fault according

to the user manual for the
specific device
Yes
No
Yes
Issue 03 (2013-08-15)
Is fault rectified?

End
158


NOTE
Procedure
Step 1 Check that the interface connecting to the client is bound to the correct domain.
Run the display this command on the interface to check whether the interface is bound to the
correct domain.
l
If the incorrect domain is bound, run the default-domain authentication domain-name

command to bind the interface to the correct domain.
If the correct domain is bound, go to Step 2.
Step 2 Check that the domain is bound to a correct IP address pool.

Run the display domain domain-name command to check the IP-address-pool-name field to
see whether the correct IP address pool is bound.
l
If the incorrect IP address pool is bound, run the ip-pool pool-name command to bind the
domain to the correct IP address pool.
NOTE
The IP address pool specified by pool-name must be created in advance. Details are as follows:
l Run the ip pool pool-name local command to create an IP address pool.
l Run the gateway ip-address { mask | mask-length } command to create the gateway of the IP address
pool.
l Run the section section-num start-ip-address [ end-ip-address ] to configure the range of assignable
IP addresses.
For detailed configurations of the IP address pool, refer to the HUAWEI NetEngine80E/40E Configuration
Guide - User Access.
If the correct IP address pool is bound, go to Step 3.
Step 3 Check that the IP address pool is correctly configured and IP addresses can be assigned.
Run the display ip pool name pool-name command to check whether the corresponding fields
have the correct values based on the following check steps. If any field has the incorrect value,
rectify the fault based on the following procedure.
Issue 03 (2013-08-15)

159

Item
Field
Correct Value
Restoration
Procedure
Check whether the

type of the IP address
pool is Local.
Position
Local
If the field is
displayed as
Remote or Server,
run the ip pool poolname bas local
command again to
configure the IP
address pool to the
Local type.

address pool is
locked.
Status
Unlocked
If the field is
displayed as
Locked, run the
undo lock command
to unlock the IP
address pool.

address pool has
assignable IP
addresses.
idle
If the idle field is

displayed as a value
larger than 0, it
indicates that
assignable IP
addresses exist in the
IP address pool.
l If there are
conflicting IP
addresses, run the
reset conflict-ipaddress
command to
mark the
conflicting IP
addresses as idle.
conflicted
If the conflicted field

is displayed as 0, it
indicates that there
are no conflicting IP
addresses.
l Re-plan the
network and
increase the
number of IP
addresses in the
IP address pool.
Step 4 Check that the interface at the client side and BAS are correctly configured.
For detailed configurations of BAS, refer to the HUAWEI NetEngine80E/40E Configuration
Guide - User Access. After the preceding steps, if the client still cannot acquire an IP address,
go to Step 5.
Step 5 Check that the link between the DHCP server and the client is normal.
On the client, configure an IP address to make the client and the IP address pool of the DHCP
server on the same network segment (note that the IP address of the client cannot conflict with
an assigned IP address). Then, ping the IP address on the DHCP server to check whether the
link between the DHCP server and the client is normal.
Issue 03 (2013-08-15)

160

If the ping operation fails, it indicates that a routing fault occurs between the DHCP server
Check whether the configurations of these devices are correct. If not, modify the configurations.
----End

Relevant Alarms
None.
Relevant Logs
None.
2.4 A PPPoX/IPoX Client Cannot Obtain an IP Address (the

HUAWEI NetEngine80E/40E Functions as the DHCP Relay)
procedure for the fault that a PPPoX/IPoX client cannot obtain an IP address when the HUAWEI
2.4.1 Common Causes

l
The client is bound to an incorrect domain.
configured to be the Server or Remote type, the IP address pool is locked, or the IP address
of the DHCP server is incorrect.
The BAS interface is incorrectly configured.
The link between the DHCP relay and the DHCP server or between the DHCP relay and
the client is faulty.
Issue 03 (2013-08-15)

161


When the HUAWEI NetEngine80E/40E functions as the DHCP relay, a PPPoX/IPoX client
enabled with DHCPv4 cannot obtain an IP address.
l
Check that the IP address pool and BAS interface of the DHCP relay are correctly
configured.
Check the link connectivity between the DHCP relay and the DHCP server or between the
DHCP relay and the client.
Issue 03 (2013-08-15)

162

Figure 2-4 Troubleshooting flowchart for the fault that a PPPoX/IPoX client cannot obtain an
IP address (the HUAWEI NetEngine80E/40E functions as the DHCP relay)
address
Is the interface bound

to a correct domain?
No
Bind the correct domain

to the interface
Is fault rectified?
Yes
No
Yes
Is the domain bound to a

correct IP address pool?
No
Bind a correct IP address

pool to the domain
Yes
Is fault rectified?
Yes
No

correctly configured.
No
Rectify the fault

troubleshooting
procedure
Is fault rectified?
Yes
No
Yes
Is the BAS interface

No
Rectify the fault

troubleshooting
procedure
Is fault rectified?
Yes
No
Yes

DHCP relay and DHCP
server/client normal?
No
Is fault rectified?
Yes
No
Yes
No
configured?
Rectify the fault

according to the user
manual for the specific
device
Is fault rectified?
Yes
No
Yes
End

Issue 03 (2013-08-15)

163

NOTE
Procedure
Step 1 Check that the interface on the user end is bound to the correct domain.
Run the display this command on the interface to check whether the interface is bound to the
correct domain.
l
If the incorrect domain is bound, run the default-domain authentication domain-name

command to bind the interface to the correct domain.
If the correct domain is bound, go to Step 2.
Step 2 Check that the domain is bound to a correct IP address pool.

Run the display domain domain-name command to check the IP-address-pool-name field to
see whether the bound IP address pool is correct.
l
If the incorrect IP address pool is bound, run the ip-pool pool-name command to bind the
domain to the correct IP address pool.
NOTE
The IP address pool specified by pool-name must be created in advance. Details are as follows:
l Run the ip pool pool-name remote command to create an IP address pool.
l Run the gateway ip-address { mask | mask-length } command to create the gateway of the IP address
pool.
l Run the dhcp-server group group-name command to configure the DHCP server group.
For detailed configurations of the IP address pool, refer to the HUAWEI NetEngine80E/40E Configuration
Guide - User Access.
If the correct IP address pool is bound, go to Step 3.
Step 3 Check that the IP address pool and the IP address of the DHCP server are correctly configured.
Run the display ip pool name pool-name command to check whether values of the
corresponding fields are correct. If any field is displayed with an incorrect value, rectify the fault
based on the following rectification procedure.
Issue 03 (2013-08-15)
Item
Field
Correct Value
Restoration
Procedure

address pool is a
remote IP address
pool.
Position
Remote
If the field is
displayed as Local or
Server, run the ip
pool pool-name bas
remote command
again to configure
the IP address pool to
the Remote type.

164

Item
Field
Correct Value
Restoration
Procedure

address pool is
locked.
Status
Unlocked
If the field is
displayed as
Locked, run the
undo lock command
to unlock the IP
address pool.

address pool is
configured with an
correct DHCP server
address.
1. Run the display

ip pool name
pool-name
command to view
the DHCP-Group
field.
Correct DHCP server

name and address
l If the DHCP
server group is
incorrectly
configured for the
IP address pool,
configure it
correctly by
running the
dhcp-server
group groupname command.
2. Then, run the

display dhcpserver group
group-name
command to view
the PrimaryServer and
SecondaryServer fields.
l If the DHCP
server address is
incorrectly
configured for the
IP address pool,
configure it
correctly by
running the
dhcp-server ipaddress
command.
Step 4 Check that the interface at the client side and BAS are correctly configured.
For detailed configurations of BAS, refer to the HUAWEI NetEngine80E/40E Configuration
Guide - User Access. After the preceding steps, if the client still cannot acquire an IP address,
go to Step 5.
Step 5 Check that the links between the DHCP relay and the DHCP server and between the DHCP relay
and the client are normal.
Run the ping command on the DHCP relay to check whether the route between the DHCP server
and the client is normal.
NOTE
Since the client cannot acquire an IP address automatically, you need to first assign IP addresses of the same
network segment to the interfaces between the client and the DHCP relay (note that the configured IP addresses
cannot conflict with existing IP addresses).
Issue 03 (2013-08-15)

165

If the ping operation fails, it indicates that a routing fault occurs, and you need to rectify
the fault immediately.
Check whether the configurations of these devices are correct. If not, modify the configurations.
----End

Relevant Alarms
None.
Relevant Logs
None.
2.5 Troubleshooting in the Scenario Where the NE80E/40E

Functions as a Local DHCPv6 Server
This section describes the notes about configuring the NE80E/40E as a local DHCPv6 server,
where the NE80E/40E functions as a local DHCPv6 server.
2.5.1 Typical Networking

Figure 2-5 shows a typical networking where the NE80E/40E functions as a local DHCPv6
server. The following describes how to perform DHCPv6 server troubleshooting based on this
networking.
Issue 03 (2013-08-15)

166

Figure 2-5 Typical networking where the NE80E/40E functions as a local DHCPv6 server
RADIUS server
DNS server
3002:3101::2:2
Access
Network
129.6.55.55
GE1/0/2
GE1/0/1
Internet
Router
suberscriber@isp1

l
A client is a Layer 2 access user and needs to apply to the NE80E/40E for an IPv6 address
to get online.

accounting for clients.
The NE80E/40E functions as a local DHCPv6 server to allocate IPv6 addresses to clients and
manage clients.
2.5.2 Troubleshooting Flow

On the network shown in 2.5.1 Typical Networking, after a local address pool is configured, a
client cannot obtain an IPv6 address and therefore fails to get online. You can troubleshoot the
fault based on Figure 2-6.
Issue 03 (2013-08-15)

167

Figure 2-6 Troubleshooting flowchart for the scenario where the NE80E/40E functions as a
local DHCPv6 server
A Client cannot
obtain an IPv6
address
Does the physical

client and the server work
normally?
No
Check the physical

client and the server
No
Yes
Is the configuration of the

interface correct?
No
Check the configuration

of the interface
Yes
Is fault recified?
No
Yes
Is a prefix pool
configured and is a prefix
address configured for the
pool?
No
Configure a prefix
address and configure a
prefix address for the
pool
Yes
Is fault recified?
No
Yes
Is an address pool
configured and are some
address pool?
No
pool and bind some
addresses to the address
pool
Yes
Is fault recified?
No
Yes
Is the IPv6 address pool

bound to the user domain?
No

pool to the user domain
Is fault recified?
Yes
No
Yes
Is the server enabled

with IPv6 and is a server
DUID set?
No
Enable IPv6 on the

server and set a DUID
for the server
Yes
Is fault recified?
No
Yes
Does the address pool

have an available address
to be allocated to the
client?
No
Configure a new address

pool, prefix pool, and
prefix addressed
Yes
Is fault recified?
No
Yes
Seek technical
support
Issue 03 (2013-08-15)
Yes
Is fault recified?

End
168


Procedure
other, it indicates that the physical connection between them works properly; otherwise, you
need to rectify the fault on the physical connection, and then check whether the problem persists.
Step 2 Check that the interface is correctly configured.
interface is correct. For the correct interface configuration, refer to the chapter "DHCPv6 Access
Service Configuration" in the Configuration Guide - BRAS.
l If the configuration of the interface is incorrect, you need to modify the configuration to be
correct. For details, refer to the chapter "DHCPv6 Access Service Configuration" in the
is configured.
l If there is no IPv6 prefix pool, run the ipv6 prefix prefix-name local command to create a
local prefix pool, enter the local prefix pool view, and then run the prefix prefix-address
prefix-length command to configure an IPv6 prefix address.
pool view, and then run the display this command to check whether an IPv6 prefix is
configured in this prefix pool. If no IPv6 prefix address is configured in this prefix pool, run
the prefix prefix-address prefix-length command to configure an IPv6 prefix address.
is configured.
l If there is no IPv6 address pool, run the ipv6 pool pool-name bas local command to create
a local address pool, enter the local address pool view, and then run the prefix prefix-name
command to bind the prefix pool in Step 3 to this address pool.
Issue 03 (2013-08-15)

169

command in the domain view to bind the domain to an IPv6 address pool.
l If the user domain is bound to an IPv6 address pool, go to Step 6.
Step 6 Check that IPv6 is enabled on the DHCPv6 server and the server DUID is set.
Run the display this command in the system view to check configurations.
l If the command output shows "ipv6", it indicates that the IPv6 function is enabled; otherwise,
run the ipv6 command to enable IPv6.
l If the command output shows "dhcpv6 duid", it indicates that the server DUID is set;
otherwise, run the dhcpv6 duid command to set the server DUID.
----End

Functions as a Delegating Router
This section describes the notes about configuring the NE80E/40E as a delegating server, and
provides the troubleshooting flowchart and the troubleshooting procedure in a networking where
the NE80E/40E functions as a delegating server.

Figure 2-7 shows a typical networking where the NE80E/40E functions as a delegating router.
The following describes how to perform delegating router troubleshooting based on this
networking.
Figure 2-7 Typical networking where the NE80E/40E functions as a delegating router
Requesting Router
Figure 2-7 is a typical networking of DHCPv6 prefix delegation (PD). In this networking:
l
Issue 03 (2013-08-15)
A client is a Layer 2 access user.

170

The requesting router obtains an IPv6 address from the delegating router.

The NE80E/40E is responsible for allocating IPv6 prefixes for requesting routers and managing
requesting routers.

As shown in the networking diagram in the section "2.6.1 Typical Networking", after a local
address pool is configured, a client cannot obtain an IPv6 address and therefore fails to get online.
You can troubleshoot the fault based on Figure 2-8.
Issue 03 (2013-08-15)

171

delegating router
A re q u e stin g ro u te r
ca n n o t o b ta in a n
IP v6 p re fix
D o e s th e p h ysica l
co n n e ctio n b e tw e e n th e
R e q u e stin g ro u te r a n d d e le g a tin g ro u te r
w o rk
N o rm a lly?
No
C h e ck th e co n n e ctio n
b e tw e e n th e re q u e stin g
ro u te r a n d d e le g a tin g
ro u te r
No
Yes
Is th e clie n t a L a ye r 2
a cce ss u se r?
No
See PPPoE
T ro u b le sh o o tin g o r IP
o E T ro u b le sh o o tin g to
so lve th e a cce ss
p ro b le m
Yes
Is fa u lt re cifie d ?
No
Yes
Is th e co n fig u ra tio n o f th e
in te rfa ce co rre ct?
No
C h e ck th e co n fig u ra tio n
o f th e in te rfa ce
Yes
No
Yes
Is a p re fix p o o l
C o n fig u re d a n d is a p re fix
a d d re ss co n fig u re d fo r th e
p o o l?
No
C o n fig u re a p re fix
a d d re ss a n d co n fig u re a
p re fix a d d re ss fo r th e
pool
Yes
No
Yes
Is a n a d d re s s p o o l
c o n fig u re d a n d a re s o m e
a d d re s s e s b o u n d to th is
A d d re s s p o o l?
No
C o n fig u re a n a d d re ss
p o o l a n d b in d so m e
a d d re sse s to th e a d d re ss
pool
Yes
No
Yes
Is th e IP v6 a d d re ss p o o l
b o u n d to th e u se r d o m a in ?
No
B in d th e IP v6 a d d re ss
p o o l to th e u se r d o m a in
Yes
No
Yes
Is th e se rve r e n a b le d
W ith IP v6 a n d is a se rve r
D U ID se t?
No
E n a b le IP v6 o n th e
se rve r a n d se t a D U ID
fo r th e se rve r
Yes
No
Yes
D o e s th e a d d re ss p o o l
h a ve a n a va ila b le a d d re ss
to b e a llo ca te d to th e
C lie n t?
No
C o n fig u re a n e w a d d re ss
p o o l, p re fix p o o l, a n d
p re fix a d d re sse d
Yes
No
Yes
S e e k te ch n ica l
su p p o rt
Issue 03 (2013-08-15)
Yes

End
172


Procedure
other, it indicates that the physical connection between them works properly; otherwise, you
need to rectify the fault on the physical connection, and then check whether the problem persists.
Step 2 Check that the requesting router can normally get online through PPPoE or IPoE.
Check whether the requesting router can obtain an IPv6 address from the delegating router and
get online normally.
l If the requesting router fails to get online, refer to PPPoE troubleshooting procedure or IPoE
troubleshooting procedure in the Troubleshooting - BRAS and ensure that the requesting
router can access the delegating router.
l If the requesting router can normally get online, go to Step 3.
Step 3 Check that the interface is correctly configured.
interface is correct. For the correct interface configuration, refer to the chapter "DHCPv6 Access
Service Configuration" in the Configuration Guide - BRAS.
l If the configuration of the interface is incorrect, you need to modify the configuration to be
correct. For details, refer to the chapter "DHCPv6 Access Service Configuration" in the
l If the configuration of the interface is correct, go to Step 4.
is configured.
l If there is no IPv6 prefix pool, run the ipv6 prefix prefix-name delegation command to create
a delegation prefix pool, enter the delegation prefix pool view, and then run the prefix prefixaddress prefix-length command to configure an IPv6 prefix address.
pool view, and then run the display this command to check whether an IPv6 prefix is
configured in this prefix pool. If no IPv6 prefix address is configured in this prefix pool, run
the prefix prefix-address prefix-length command to configure an IPv6 prefix address.
is configured.
l If there is no IPv6 address pool, run the ipv6 pool pool-name bas delegation command to
create a delegation address pool, enter the local address pool view, and then run the prefix
prefix-name command to bind the prefix pool in Step 3 to this address pool.
Issue 03 (2013-08-15)

173

command in the domain view to bind the domain to an IPv6 address pool.
l If the user domain is bound to an IPv6 address pool, go to Step 7.
Step 7 Check that IPv6 is enabled on the DHCPv6 server and the server DUID is set.
Run the display this command in the system view to check configurations.
l If the command output shows "ipv6", it indicates that the IPv6 function is enabled; otherwise,
run the ipv6 command to enable IPv6.
l If the command output shows "dhcpv6 duid", it indicates that the server DUID is set;
otherwise, run the dhcpv6 duid command to set the server DUID.
----End

Functions as a DHCPv6 Relay Agent
This section describes the notes about configuring the NE80E/40E as a DHCPv6 relay agent,
where the NE80E/40E functions as a DHCPv6 relay agent.

Figure 2-9 shows a typical networking where the NE80E/40E functions as a DHCPv6 relay
agent. The following describes how to perform DHCPv6 relay agent troubleshooting based on
this networking.
Issue 03 (2013-08-15)

174

Figure 2-9 Typical networking where the NE80E/40E functions as a DHCPv6 relay agent
RADIUS server
DNS server
3002:3101::2:2
GE1/0/1
user@isp1
GE1/0/2
Router B
GE1/0/1
129.6.55.55
GE1/0/2
Internet
Router A

l
The Router B functions as a DHCPv6 relay agent.
The Router A is connected to the RADIUS server to implement authentication and

The Router A is connected to an IPv6 DNS server.
Users can access the network through one or multiple relay agents. In the preceding figure, the
NE80E/40E (Router B) functions as a DHCPv6 relay agent.

On the network shown in 2.7.1 Typical Networking, after a relay address pool is configured, a
client cannot obtain an IPv6 address and therefore fails to get online. You can troubleshoot the
fault based on Figure 2-10.
Issue 03 (2013-08-15)

175

local DHCPv6 server
A client cannot obtain an IPv6
address
Does
the physical
connection between the client
and the DHCPv6 relay agent
and the connection between the
DHCPv6 relay agent and
the DHCPv6 server
work normally?
No
Check the physical

connection between
the client and the
server
No
Check the
interface
No
Check statistics of
received online
request packets on
the inbound interface
No
Check statistics of
forwarded packets on
the outbound interface
Yes
Does other
devices work normally?
Yes
Is fault
rectified?
Yes
No
Yes
Can the
outbound Interface forward
packets normally?
Is fault
rectified?
No
Yes
Can the
inbound interface receive
online request packets from
the client?
Yes
No
Yes
Is the
inbound/outbound Interface of
the DHCPv6 relay agent
correct?
Is fault
rectified?
Is fault
rectified?
Yes
No
No
Check other devices
Yes
Is fault
rectified?
Yes
No

End
Issue 03 (2013-08-15)

176

Procedure
Step 1 Check that the physical connections work properly.
Check whether the connection between the DHCPv6 relay agent and the client (or the superior
relay agent) and the connection between the DHCPv6 relay agent and the DHCPv6 server (or
the subordinate relay agent) work normally. If the connection fails, you need to rectify the fault
on the physical connection and then check whether the problem persists. If the problem persists,
go to Step 2.
Step 2 Check that the inbound and outbound interfaces of the DHCPv6 relay agent are correctly
configured.
Run the display this command in the inbound interface view to check the following:
l Whether the IPv6 function is enabled
l Whether a link-local address is configured
l Whether an IPv6 address is configured
NOTE
If the DHCPv6 relay agent is a first relay agent, the IPv6 address assigned to the relay agent must be on the
same network segment with the addresses in the address pool configured on the DHCPv6 server. If the
DHCPv6 relay agent is not a first relay agent, any IPv6 address can be assigned to the relay agent based on
the network planning.
l Whether DHCPv6 is enabled

l Whether the relay function is enabled and the address of the DHCPv6 server or outbound
interface of DHCPv6 packet is set
Run the display this command in the outbound interface view to check the following:
l Whether the IPv6 function is enabled
l Whether a link-local address is configured
l Whether an IPv6 address is configured
If the configuration of the interface is incorrect, modify the configuration based on
"Configuration Notes".
If the configuration of the interface is correct, go to Step 3.
Step 3 Check that the inbound interface has received packets.
Run the display interface interface-type interface-number command in the system view to check
whether the inbound interface has received packets and view statistics on input packets.
NOTE
If the DHCPv6 relay agent is a first relay agent, check whether the statistics on multicast packets increase;
if the DHCPv6 relay agent is not a first relay agent, check whether the statistics on unicast packets increase.
l If the inbound interface of the DHCPv6 relay agent receives no packets (that is, the "Input"
field is displayed as 0), check the connection between the relay agent and the superior device
and then check whether the superior device can forward packets normally.
l If the inbound interface of the DHCPv6 relay agent has received packets, go to Step 4.
Step 4 Check that the outbound interface forwards packets normally.
Issue 03 (2013-08-15)

177

Run the display interface interface-type interface-number command in the system view to check
whether the outbound interface has forwarded packets and view statistics on the output packets.
l If packet forwarding on the outbound interface fails (that is, the "Output" field is displayed
as 0), check the physical connection between the DHCPv6 relay agent and the subordinate
device and check whether the IPv6 address of this interface is on the same network segment
with that of the inbound interface of the superior device.
l If packet forwarding succeeds, it indicates that the DHCPv6 relay agent works normally.
Then, check whether other devices work normally.
If the client still cannot get online, contact Huawei technical support personnel.
----End
2.8 User Cannot Obtain an Address from the Address Pool

According to the Pool ID Delivered by the RADIUS Server
procedure for the fault that the NE80E&40E cannot allocate an address from the corresponding
address pool to the user after the RADIUS server delivers No.100 attribute Framed-IPv6Pool or HUAWEI No.191 attribute Delegated-IPv6-Prefix-Pool.
2.8.1 Common Causes

l
The address pool with the specified pool ID is not configured on the device.
The address pool type does not match the pool ID delivered by the RADIUS server. If the
RADIUS server delivers No.100 attribute Framed-IPv6-Pool, the address pool can be a
local or delegation address pool. If the RADIUS server delivers HUAWEI No.191 attribute
Delegated-IPv6-Prefix-Pool, the address pool can be a delegation address pool only.
No prefixes are available in the prefix pool.

This section describes the troubleshooting flowchart for the fault that the user cannot obtain an
address from the address pool after the RADIUS server delivers the pool ID.
l
Check that the address pool with the specified pool ID has been configured on the device.
Check that the address pool type matches the pool ID delivered by the RADIUS server.
Check that no prefixes are available in the prefix pool.
Issue 03 (2013-08-15)

178


NOTE
Procedure
Step 1 Check that an address pool with the specified pool ID has been configured on the device.
Run the display ipv6 pool pool-name command in the system view to check whether an address
pool with the specified pool ID has been configured on the device.
l If This pool does not exist is displayed, the address pool is not configured. Run the ipv6
pool pool-name { bas { local | delegation } } command on the device to configure the address
pool.
l If information about the address pool is displayed, the address pool has already been
configured. Go to step 2.
Step 2 Check that the address pool type configured on the device matches the pool ID delivered by the
RADIUS server.
Run the display ipv6 pool pool-name command in the system view to check whether the pool
type indicated in the command output information matches the pool ID delivered by the RADIUS
server. If the RADIUS server delivers No.100 attribute Framed-IPv6-Pool, the address pool
can be a local or delegation address pool. If the RADIUS server delivers HUAWEI No.191
attribute Delegated-IPv6-Prefix-Pool, the address pool can be a delegation address pool only.
l If the pool type does not match the pool ID delivered by the RADIUS server, reconfigure
the address pool type. If the RADIUS server delivers HUAWEI No.191 attribute DelegatedIPv6-Prefix-Pool, run the ipv6 pool pool-name bas delegation command to configure the
address pool as a delegation address pool. If the RADIUS server delivers No.100 attribute
Framed-IPv6-Pool, the address pool can be a local or delegation address pool.
l If the pool type matches the pool ID delivered by the RADIUS server, go to step 3.
Step 3 Check that no prefixes are available in the address pool.
If the address pool is a delegation address pool, run the display ipv6 prefix prefix-name used
command in the system view to check whether the value of Free Prefix Count is 0.
l If the value of Free Prefix Count is 0, no prefixes are available in the prefix pool. Run the
ipv6 prefix prefix-name [ local | delegation ] command in the system view to enter the prefix
pool view, and then run the prefix prefix-address/prefix-length [ delegating-prefix-length
length ] command to configure the address pool.
l If the value of Free Prefix Count is not 0, go to step 4.
----End
Issue 03 (2013-08-15)

179


Relevant Alarms
None.
Relevant Logs
None.

2.9.1 User Fails to Obtain an IP Address from a DHCP Relay Agent
Connected to a DHCP Server over Active and Standby Links
Fault Symptom
A user needs to obtain an address from a remote DHCP server before going online. A router
functions as a DHCP relay agent and is connected to a remote DHCP server over active and
standby links. The user accessing the DHCP relay agent fails to obtain the address from the
DHCP server.
Figure 2-11 Networking diagram of DHCP Relay agent connected to a DHCP server over active
and standby links
DHCP Relay
DHCP Server
Access
Network
10.1.1.2
Access
Users
Fault Analysis
1.
On the router, ping the remote DHCP server. The ping is successful, indicating that the
router properly communicates with the remote DHCP server.
2.
Run the display current-configuration command to check the router configurations. The
router configurations are correct and unchanged.
Issue 03 (2013-08-15)

180

3.
Check the DHCP process on the remote DHCP server. The DHCP process has been started
normally.
4.
On the remote DHCP server, check whether certain addresses in the DHCP address pool
are idle. A number of IP addresses in the DHCP address pool are idle.
5.
On the remote DHCP server, check the received DHCPREQUEST messages.

DHCPREQUEST messages have been received. The source IP address in the received
DHCPREQUEST messages, which is different from the router's source IP address
configured on the remote DHCP server, is the interface address of the standby link of the
router.
6.
On the remote DHCP server, ping the IP address of the connected router interface of the
active link. The ping fails, indicating that the active link fails.
When the router's active link connected to the remote DHCP server fails, the router sends
DHCPREQUEST messages to the remote DHCP server by using the interface of the standby
link. The DHCPREQUEST messages carry the interface address of the standby link as DHCP
client's source IP address, but the remote DHCP server is configured with the interface address
of the active link.
The remote DHCP server sends DHCPREPLY messages along the active link. As a result, the
router fails to receive the DHCPREPLY messages, and therefore the user fails to obtain an
address.
Procedure
Step 1 Perform the following procedures to rectify the fault:
1.
Create the interface named Loopback 10. Assign an IP address to this loopback interface.
Configure a routing protocol on Loopback 10.
After the configuration, the DHCP server can successfully ping Loopback 10 on the
router.
2.
Run the system-view command to enter the system view.
3.
Run the dhcp select relay interface loopback 10 command to enable DHCP relay on
Loopback 10.
4.
Run the ip relay address 10.1.1.2 interface loopback 10 command to allow Loopback 10
to function as the DHCP server agent.
Step 2 On the remote DHCP server, change the DHCP client's source IP address to the address of
Loopback 10.
The user can obtain an address. The fault is then rectified.
Step 3 Repair the active link and configure it as the standby link.
----End
Summary
l
Issue 03 (2013-08-15)
When a DHCP relay agent is connected to a remote DHCP server along active and standby
links, configure the remote DHCP server with client's source IP address to a logical interface
(for example, a loopback interface) of the DHCP relay agent, preventing packet loss after
a physical link fails.
181

Issue 03 (2013-08-15)
It is recommended that you restore the services before rectifying the link fault in the case
of service interruption caused by the active link failure and active/standby switchover.

182

Troubleshooting - User Access: HUAWEI NE40E/NE80E Router V600R005C00

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Troubleshooting - User Access: HUAWEI NE40E/NE80E Router V600R005C00

Hochgeladen von

Copyright:

Verfügbare Formate

HUAWEI NE40E/NE80E Router