NE40E Troubleshooting PDF

HUAWEI NetEngine80E/40E Router
V600R008C10
Troubleshooting - User Access
Issue 02
Date 2014-09-30
HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2014. 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 02 (2014-09-30) Huawei Proprietary and Confidential i

Copyright © Huawei Technologies Co., Ltd.
Troubleshooting - User Access About This Document
About This Document
Purpose
This document describes the troubleshooting of user access, including information collection
methods, common processing flows, common troubleshooting methods, and troubleshooting
cases.
NOTICE
Note the following precautions:
l The encryption algorithms DES/3DES/SKIPJACK/RC2/RSA (RSA-1024 or lower)/MD2/
MD4/MD5 (in digital signature scenarios and password encryption)/SHA1 (in digital
signature scenarios) have a low security, which may bring security risks. If protocols allowed,
using more secure encryption algorithms, such as AES/RSA (RSA-2048 or higher)/SHA2/
HMAC-SHA2, is recommended.
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.
Product Name Version
HUAWEI NetEngine80E/40E V600R008C10

Router
Intended Audience
This document is intended for:
Issue 02 (2014-09-30) Huawei Proprietary and Confidential ii

l Installation and commissioning engineer

l NM configuration engineer
l Technical support engineer
Symbol Conventions
The symbols that may be found in this document are defined as follows.
Symbol Description
Indicates an imminently hazardous situation which, if not

avoided, will result in death or serious injury.
Indicates a potentially hazardous situation which, if not

avoided, could result in death or serious injury.

avoided, may result in minor or moderate injury.

avoided, could result in equipment damage, data loss,
performance deterioration, or unanticipated results.
NOTICE is used to address practices not related to personal
injury.
Calls attention to important information, best practices and

tips.
NOTE is used to address information not related to personal
injury, equipment damage, and environment deterioration.
Command Conventions
The command conventions that may be found in this document are defined as follows.
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.
{ x | y | ... } Optional items are grouped in braces and separated by

vertical bars. One item is selected.
Issue 02 (2014-09-30) Huawei Proprietary and Confidential iii

Convention Description
[ 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 02 (2014-09-30)

This issue is the second official release.
Changes in Issue 01 (2014-06-30)

This issue is the first official release.
Issue 02 (2014-09-30) Huawei Proprietary and Confidential iv

Troubleshooting - User Access 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 Login and Logout Faults..........................................................................................................2
1.2 User Login and Logout Cause........................................................................................................................................2
1.2.1 AAA access limit.........................................................................................................................................................2
1.2.2 AAA cut command......................................................................................................................................................3
1.2.3 AAA send authen request fail......................................................................................................................................3
1.2.4 AAA with Authentication no response........................................................................................................................3
1.2.5 AAA with authorization data error..............................................................................................................................4
1.2.6 AAA with flow limit....................................................................................................................................................4
1.2.7 AAA with local bill pool no space..............................................................................................................................4
1.2.8 AAA with pool filled fail.............................................................................................................................................5
1.2.9 AAA with RADIUS decode fail..................................................................................................................................5
1.2.10 AAA with RADIUS server cut command.................................................................................................................5
1.2.11 AAA with realtime accounting fail...........................................................................................................................5
1.2.12 AAA with start accounting fail..................................................................................................................................6
1.2.13 AAA with stop accounting fail..................................................................................................................................6
1.2.14 AM with lease timeout..............................................................................................................................................6
1.2.15 AM with Renew lease timeout..................................................................................................................................7
1.2.16 ARP with detect fail..................................................................................................................................................7
1.2.17 Authenticate fail........................................................................................................................................................7
1.2.18 Authentication method error......................................................................................................................................7
1.2.19 Author of IP address and ip-include conflict.............................................................................................................8
1.2.20 Bas interface access limit..........................................................................................................................................8
1.2.21 Block domain force user to offline............................................................................................................................8
1.2.22 Cannot get all of authorized IP address.....................................................................................................................9
1.2.23 CM with AAA auth ack time out...............................................................................................................................9
1.2.24 CM with AAA connect check fail.............................................................................................................................9
1.2.25 CM with AAA ipv6 update ack time out...................................................................................................................9
1.2.26 CM with AAA logout ack time out.........................................................................................................................10
1.2.27 CM with access limit...............................................................................................................................................10
Issue 02 (2014-09-30) Huawei Proprietary and Confidential v

1.2.28 CM with Framed IP address invalid........................................................................................................................10

1.2.29 CM with Ifnet down................................................................................................................................................11
1.2.30 CM with Ifnet ipv6 protocol down..........................................................................................................................11
1.2.31 CM with IP address alloc fail..................................................................................................................................11
1.2.32 CM with l2tp session fail.........................................................................................................................................12
1.2.33 CM with PPP ipv6 conn up time out.......................................................................................................................12
1.2.34 CM with user blocked..............................................................................................................................................12
1.2.35 Dhcp decline............................................................................................................................................................13
1.2.36 DHCP lease timeout................................................................................................................................................13
1.2.37 Dhcp release............................................................................................................................................................14
1.2.38 DHCP receive discover from a working user..........................................................................................................14
1.2.39 Dhcp repeat packet..................................................................................................................................................14
1.2.40 Dhcp sever speed limit............................................................................................................................................15
1.2.41 DHCP wait client packet timeout............................................................................................................................15
1.2.42 DHCP with IP address conflict................................................................................................................................16
1.2.43 Dhcp with MTU limit..............................................................................................................................................16
1.2.44 DHCP with server nak.............................................................................................................................................16
1.2.45 DHCP with server no response................................................................................................................................17
1.2.46 DHCPV6 client decline...........................................................................................................................................17
1.2.47 DHCPV6 client release............................................................................................................................................18
1.2.48 DHCPV6 ip alloc fail..............................................................................................................................................18
1.2.49 DHCPV6 lease expired............................................................................................................................................19
1.2.50 DHCPV6 packet speed limit....................................................................................................................................19
1.2.51 DHCPV6 repeat solicit............................................................................................................................................19
1.2.52 DHCPV6 wait client timeout...................................................................................................................................20
1.2.53 DHCPV6 wait server timeout..................................................................................................................................20
1.2.54 Fill HQOS to ucm fail.............................................................................................................................................21
1.2.55 Gateway different from former................................................................................................................................21
1.2.56 GTL license needed.................................................................................................................................................22
1.2.57 Idle cut.....................................................................................................................................................................22
1.2.58 Idle timeout..............................................................................................................................................................22
1.2.59 Interface delete........................................................................................................................................................23
1.2.60 Interface down.........................................................................................................................................................23
1.2.61 Interface on Master down........................................................................................................................................23
1.2.62 IP alloc fail for trigger user......................................................................................................................................23
1.2.63 IP address conflict...................................................................................................................................................23
1.2.64 IPv6 address conflicts too much times....................................................................................................................24
1.2.65 L2TP cut command.................................................................................................................................................24
1.2.66 L2TP peer cleared tunnel.........................................................................................................................................24
1.2.67 L2TP remote slot.....................................................................................................................................................25
1.2.68 L2TP request offline................................................................................................................................................25
Issue 02 (2014-09-30) Huawei Proprietary and Confidential vi

1.2.69 L2TP service is unavailable.....................................................................................................................................25

1.2.70 L2TP sessionlimit ...................................................................................................................................................26
1.2.71 LAC clear session....................................................................................................................................................26
1.2.72 LAC clear tunnel.....................................................................................................................................................26
1.2.73 LAM access type is no match..................................................................................................................................27
1.2.74 LAM authentication fail..........................................................................................................................................27
1.2.75 LAM user does not exist..........................................................................................................................................27
1.2.76 LAM user state is block...........................................................................................................................................28
1.2.77 LNS clear session....................................................................................................................................................28
1.2.78 LNS clear tunnel......................................................................................................................................................29
1.2.79 LNS Multicast user resource full.............................................................................................................................29
1.2.80 Local authen reject...................................................................................................................................................29
1.2.81 local no this user......................................................................................................................................................29
1.2.82 Mac-user ppp-preferred...........................................................................................................................................30
1.2.83 ND Detect Fail.........................................................................................................................................................30
1.2.84 ND Repeat Request.................................................................................................................................................30
1.2.85 Netmask assigned by RDS error(Value invalid).....................................................................................................31
1.2.86 No available prefix for conflicts of the interface id specified by RADIUS............................................................31
1.2.87 No IPv6 address available.......................................................................................................................................31
1.2.88 No prefix available..................................................................................................................................................32
1.2.89 No response of control packet from peer.................................................................................................................32
1.2.90 Not bind IPv6 pool or ip alloc fail...........................................................................................................................32
1.2.91 Online user number exceed GTL license limit........................................................................................................33
1.2.92 Packet Authenticator Error......................................................................................................................................33
1.2.93 PPP negotiate fail.....................................................................................................................................................34
1.2.94 PPP up recv lcp again..............................................................................................................................................34
1.2.95 PPP user over LNS request......................................................................................................................................34
1.2.96 PPP user request......................................................................................................................................................35
1.2.97 PPP with authentication fail....................................................................................................................................35
1.2.98 PPP with echo fail....................................................................................................................................................35
1.2.99 Pre-Authentication Domain Has Value-Added-Service..........................................................................................36
1.2.100 RADIUS alloc incorrect IP....................................................................................................................................36
1.2.101 RADIUS authentication reject...............................................................................................................................37
1.2.102 Radius client request..............................................................................................................................................37
1.2.103 RADIUS decode packet fail..................................................................................................................................37
1.2.104 Renew timeout in shortlease..................................................................................................................................37
1.2.105 RUI request cold backup user offline for slave.....................................................................................................38
1.2.106 RUI request offline................................................................................................................................................38
1.2.107 Sending RADIUS packets failed due to speed-limit.............................................................................................38
1.2.108 Service unavailable................................................................................................................................................39
1.2.109 Session time out.....................................................................................................................................................39
Issue 02 (2014-09-30) Huawei Proprietary and Confidential vii

1.2.110 Session timeout......................................................................................................................................................39

1.2.111 Soft-GRE active user over limit............................................................................................................................39
1.2.112 Srvcfg cut command..............................................................................................................................................40
1.2.113 SRVCFG failed to process....................................................................................................................................40
1.2.114 TACACS authentication reject..............................................................................................................................40
1.2.115 The domain does not bind IPv6 pool.....................................................................................................................40
1.2.116 The domain has not binded ip-pool or ipv6-pool..................................................................................................41
1.2.117 The RADIUS server does not reply with Authentication ACK messages............................................................41
1.2.118 The vrf of domain is not accord with the pool......................................................................................................41
1.2.119 Up to user max session..........................................................................................................................................42
1.2.120 User access speed too fast.....................................................................................................................................42
1.2.121 User info is conflict with rui user..........................................................................................................................43
1.2.122 User's password expired........................................................................................................................................43
1.2.123 VPDN license not enable.......................................................................................................................................43
1.2.124 Web user request...................................................................................................................................................44
1.3 IPv4...............................................................................................................................................................................44
1.3.1 Troubleshooting IPoX...............................................................................................................................................44
1.3.2 Troubleshooting PPPoX............................................................................................................................................47
1.3.3 Troubleshooting Leased Line....................................................................................................................................53
1.3.4 Troubleshooting L3 Access.......................................................................................................................................56
1.3.5 802.1X Access Troubleshooting................................................................................................................................59
1.3.6 Users Go Offline at Low Speed.................................................................................................................................62
1.3.7 EAP-PEAP and EAP-SIM/AKA Users Cannot Go Online.......................................................................................63
1.4 IPv6...............................................................................................................................................................................66
1.4.1 User Cannot Get Online in the Case of IPoE Stateful PD.........................................................................................66
1.4.2 User Cannot Get Online in the Case of IPoE Stateless PD.......................................................................................71
1.4.3 User Cannot Get Online in IPv6 IPoE Stateful Access Mode with a DSLAM Serving as the LDRA.....................75
1.4.4 DHCPv6 User Fails to Get Online Through the Remote Address Pool....................................................................78
1.4.5 IPv6 PPPoE Access Troubleshooting........................................................................................................................82
1.4.6 User Cannot Get Online or the User's Access Type Is Incorrect in the Case of PPPoE IPv6 Stateful Access.........86
1.4.7 IPv6 ND Access Troubleshooting.............................................................................................................................89
1.4.8 ND-Unshared User Cannot Get Online.....................................................................................................................93
1.4.9 User Cannot Get Online in the Case of Network-Side Relay and QinQ Configuration............................................97
1.4.10 IPv6 Layer 3 Leased Line User Cannot Get Online..............................................................................................101
1.4.11 Static Users Cannot Get Online.............................................................................................................................104
1.4.12 Interconnection Fails Between the Device and the RADIUS Server....................................................................109
1.5 L2TP...........................................................................................................................................................................113
1.5.1 An L2TP User Fails to Get Online..........................................................................................................................114
1.5.2 L2TP IPv6 Users Cannot Get Online......................................................................................................................118
1.5.3 IPv6 L2TP Access Troubleshooting........................................................................................................................122
1.5.4 An L2TP User Fails to Go Online on the Slave Device..........................................................................................126
Issue 02 (2014-09-30) Huawei Proprietary and Confidential viii

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

2.1 An Ethernet Client Fails to Obtain an IP Address (the HUAWEI NetEngine80E/40E Functions as the DHCP Server)
..........................................................................................................................................................................................130
2.1.1 Common Causes......................................................................................................................................................130
2.1.2 Troubleshooting Flowchart......................................................................................................................................130
2.1.3 Troubleshooting Procedure......................................................................................................................................132
2.1.4 Relevant Alarms and Logs......................................................................................................................................134
2.2 An Ethernet Client Cannot Obtain an IP Address (the HUAWEI NetEngine80E/40E Functions as the DHCP Relay)
..........................................................................................................................................................................................134
2.2.1 Common Causes......................................................................................................................................................134
2.3 A PPPoX/IPoX Client Fails to Obtain an IP Address (the HUAWEI NetEngine80E/40E Functions as the DHCP Server)
..........................................................................................................................................................................................138
2.3.1 Common Causes......................................................................................................................................................138
2.4 A PPPoX/IPoX Client Cannot Obtain an IP Address (the HUAWEI NetEngine80E/40E Functions as the DHCP Relay)
..........................................................................................................................................................................................143
2.4.1 Common Causes......................................................................................................................................................143
2.5 Troubleshooting in the Scenario Where the NE80E/40E Functions as a Local DHCPv6 Server..............................148
2.5.1 Typical Networking.................................................................................................................................................148
2.5.2 Troubleshooting Flow..............................................................................................................................................149
2.6 Troubleshooting in the Scenario Where the NE80E/40E Functions as a Delegating Router.....................................152
2.7 Troubleshooting in the Scenario Where the NE80E/40E Functions as a DHCPv6 Relay Agent..............................156
2.8 User Cannot Obtain an Address from the Address Pool According to the Pool ID Delivered by the RADIUS Server
..........................................................................................................................................................................................161
2.8.1 Common Causes......................................................................................................................................................161
Issue 02 (2014-09-30) Huawei Proprietary and Confidential ix

3 RADIUS Troubleshooting.......................................................................................................163
3.1 The Dynamic ACL Delivered by the RADIUS Server Does Not Take Effect..........................................................164
3.1.1 Common Causes......................................................................................................................................................164
4 Hybrid Access Troubleshooting.............................................................................................168

4.1 An Overflow Tunnel Fails to Be Established.............................................................................................................169
4.1.1 Common Causes......................................................................................................................................................169
4.2 A Prior Tunnel Fails to Be Established......................................................................................................................172
4.2.1 Common Causes......................................................................................................................................................172
4.3 SOAP Fails.................................................................................................................................................................176
4.3.1 Common Causes......................................................................................................................................................177
4.4 Hybrid Access Users Fail to Go Online.....................................................................................................................180
4.4.1 Common Causes......................................................................................................................................................180
4.5 Hybrid Access Users Fail to Obtain IPv4 Addresses.................................................................................................185
4.5.1 Common Causes......................................................................................................................................................185
4.6 Hybrid Access Users Fail to Obtain IPv6 PD Prefixes..............................................................................................188
4.6.1 Common Causes......................................................................................................................................................188
4.7 FTP Upload and Download Fail for IPv6 Users.........................................................................................................191
4.7.1 Common Causes......................................................................................................................................................191
Issue 02 (2014-09-30) Huawei Proprietary and Confidential x


4.8 The Upstream Bonding Bandwidth Is Far Lower Than the Sum of LTE and DSL Link Bandwidth........................193
4.8.1 Common Causes......................................................................................................................................................193
Issue 02 (2014-09-30) Huawei Proprietary and Confidential xi

Troubleshooting - User Access 1 User Fails to Get Online Troubleshooting
1 User Fails to Get Online Troubleshooting
About This Chapter
1.1 Method of Troubleshooting User Logout
1.2 User Login and Logout Cause
1.3 IPv4
1.4 IPv6
1.5 L2TP
Issue 02 (2014-09-30) Huawei Proprietary and Confidential 1

1.1 Method of Troubleshooting User Logout
1.1.1 Troubleshooting User Login and 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 Login and 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 Login and 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.

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 access-
limit 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 send authen request fail
Message
AAA send authen request fail
Common Causes
No reachable routes exist between the user and RADIUS server.
Troubleshooting Procedure
Run the ping command or check the routing table to check whether there are reachable routes
between the user and RADIUS server.
1.2.4 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.5 AAA with authorization data error
Display
AAA with authorization data error
Common Causes
The Remote Authentication Dial In User Service(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.6 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.7 AAA with local bill pool no space
Message
AAA with local bill pool no space
Common Causes
The local bill pool is full.

1. Run the display local-bill information command to check the number of total local bills
and unused local bills. If the number of unused local bills (Void-No field) is 0, the local
bill pool is full.
2. Run the local-bill { cache | cfcard } backup-interval backup-interval command to enable
the device to automatically back up local bills to a bill server at a specified interval or run
the local-bill cache backup or local-bill cfcard backup command to manually back up
local bills to a bill server.
1.2.8 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.9 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.10 AAA with RADIUS server cut command
Display
AAA with RADIUS server cut command
Common Causes
The RADIUS server forces a user to log out.
1.2.11 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.12 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.13 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])".
1.2.14 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.15 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.16 ARP with detect fail
Display
ARP with detect fail
Common Causes
l The intermediate transmission device discards or modifies ARP probe packets.
l Fibers or optical modules are not properly installed or a link fault occurs.
l There are too many probe response packets, and therefore some are dropped.
1.2.17 Authenticate fail
Display
Authenticate fail
Common Causes
The user name or password used for authentication is incorrect.
1.2.18 Authentication method error
Display
Authentication method error
Common Causes
The requested authentication type is different from the authentication type configured on the
interface from which the user gets online.

1.2.19 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.20 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.
l The number of online users on the physical interface for the BAS interface reaches the
upper limit.
Procedure
1. Check whether the number of online users on a BAS interface reaches the upper limit.
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.
1.2.21 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.22 Cannot get all of authorized IP address
Display
Cannot get all of authorized IP address
Common Causes
When a PPPoE or L2TP user went online, two or all of the IPv4, DHCPv6, and PD addresses
were assigned to the user in the domain or authorized to the user by a server. However, the client
initiated the negotiation of only one or two of these addresses. After the timer expired, the user
was logged out.
1.2.23 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.24 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.25 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
1.2.26 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.27 CM with access limit
Message
CM with access limit
Common Causes
The number of online users exceeds the allowable maximum number.
1. Run the display domain domain-name command to check whether the number of online
users exceeds the maximum number configured in the domain or delivered by the RADIUS
server.
2. If the number of online users exceeds the maximum number, run the access-limit max-
number command to reconfigure the allowable maximum number.
1.2.28 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.29 CM with Ifnet down
Message
CM with Ifnet down
Common Causes
The board or subcard for user login is reset or removed.
1. Run the display interface interface-type interface-number command to check the
interface's physical status (the GigabitEthernetX/X/X current state field) and link layer
protocol status (the Line protocol current state field).
l If both the physical status and link layer protocol status are Up, contact Huawei technical
support personnel.
l If only one or no status is Up, go to Step 2.
2. If the reset command is run, wait for the board or subcard to restart. If the board or subcard
is removed, reinstall it.
1.2.30 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.31 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

1.2.32 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.33 CM with PPP ipv6 conn up time out
Message
CM with PPP ipv6 conn up time out
Common Causes
IPv6 access is configured in a domain, but users do not use IPv6 to go online.
l If users do not use IPv6 to go online, delete the IPv6 access configuration from the domain.
1.2.34 CM with user blocked

Display
CM with user blocked
Common Causes
A BAS interface is blocked using the following command: block [ start-vlan { start-vlan [ end-
vlan end-vlan ] [ qinq pe-vlan ] | any qinq start-qinq-vlan [ end-qinq-vlan ] } | pvc start-vpi/
start-vci [ end-vpi/end-vci ] ]
Solution
Check whether the BAS interface is blocked.
l Run the display bas-interface command in the user view and check whether Manager
state is Block and whether Block PE VLAN/CE VLAN has a value in the command
output.

– If Manager state is Block, the BAS interface is blocked. Check whether you need to
block the BAS interface. If you do not want to block it, run the undo block [ start-
vlan { start-vlan [ end-vlan end-vlan ] [ qinq pe-vlan ] | any qinq start-qinq-vlan
[ end-qinq-vlan ] } | pvc start-vpi/start-vci [ end-vpi/end-vci ] ] command in the BAS
interface view.
– If Manager state is not Block, check whether Block PE VLAN/CE VLAN has a value.
– If Block PE VLAN/CE VLAN has a value, a specified VLAN is blocked on the
BAS interface. Check whether you need to block the VLAN on the BAS interface.
If you do not want to block it, run the undo block [ start-vlan { start-vlan [ end-
vlan end-vlan ] [ qinq pe-vlan ] | any qinq start-qinq-vlan [ end-qinq-vlan ] } |
pvc start-vpi/start-vci [ end-vpi/end-vci ] ] command in the BAS interface view.
– If Block PE VLAN/CE VLAN does not have a value, contact Huawei technical
support personnel.
1.2.35 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 (IP over Ethernet)

IPCONFLICT
1.2.36 DHCP lease timeout
Message
DHCP lease timeout
Common Causes
A DHCP user does not extend the IP address lease, or the user-side link fails. As a result, renewal
messages are lost.
1. Check whether renewal messages are correctly sent by the client.
2. Troubleshoot the user-side link failure.

3. Run the lease days [ hours [ minutes ] ] command in the IP address pool view to modify
the DHCP user IP address lease.
1.2.37 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
Solution
1.2.38 DHCP receive discover from a working user
Message
DHCP receive discover from a working user
Common Causes
A device has received Discover messages from online IPv4 users but does not have DHCPv4
message transparent transmission enabled.
1. Run the display this command in the system view to check whether DHCPv4 message
transparent transmission is enabled (whether undo dhcp through-packet is displayed in
the command output).
l If the undo dhcp through-packet command is not displayed, contact Huawei technical
support personnel.
l If the undo dhcp through-packet command is displayed, go to Step 2.
2. Run the dhcp through-packet command in the system view to enable DHCPv4 message
transparent transmission.
1.2.39 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.40 Dhcp sever speed limit
Message
Dhcp sever speed limit
Common Causes
The rate at which a DHCPv4 server sends messages exceeds the configured speed limit.
1. Run the display dhcp-server item ip-address command to check the speed limit (Speed
Limit field) of a DHCPv4 server.
l If the speed limit does not need to be adjusted, contact Huawei technical support
personnel.
l If the speed limit needs to be adjusted, go to Step 2.
2. Run the dhcp-server ip-address [ vpn-instance vpn-instance ] send-discover-speed
packet-number time command in the system view to reconfigure a speed limit at which a
DHCPv4 server sends messages.
1.2.41 DHCP wait client packet timeout
Display
DHCP wait client packet timeout
Common Causes
The fault that Dynamic Host Configuration Protocol(DHCP) packets from a user are lost is
commonly caused by one of the following:
l Incorrect link bandwidth is configured.

l A link is interrupted or the link delay is too long.
l 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.
NOTE
If DHCP snooping or broadcast suppression is configured on a transit device, DHCP packets may be
dropped mistakenly by the transit device.
1.2.42 DHCP with IP address conflict
Display
DHCP with IP address conflict
Common Causes
An IP address conflict was detected.
Feature Type
IPoE
Solution
1.2.43 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.44 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.45 DHCP with server no response
Display
DHCP with server no response
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.

l The remote server has no assignable IP address.
l 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.46 DHCPV6 client decline
Message
DHCPV6 client decline
Common Causes
The DHCPv6 client sends a Decline message to the DHCPv6 server because the client detects
that the IP address it is assigned has already been assigned to another client.
NOTE
To check whether the IPv6 prefix pool contains a conflicting prefix address, run the display ipv6 prefix
prefix-name used command. If Status is displayed as conflict, a conflict occurs.

1. Allow the user to go online again.
2. If the user still cannot log in, no available addresses exist in the IPv6 address pool. Run the
display ipv6 pool pool-name command to check the name of the IPv6 prefix pool bound
to the IPv6 address pool and run the prefix prefix-address/prefix-length command in the
IPv6 prefix pool view to
reconfigure an IPv6 address prefix.
1.2.47 DHCPV6 client release
Display
DHCPV6 client release
Common Causes
A Dynamic Host Configuration Protocol for IPv6 (DHCPv6) client sends a DHCP Release
packet to release its IP address.
This message is displayed when users go offline in the following scenarios:
l A PPPoE/LNS dual-stack user is configured to get offline when either of the user's IP
addresses is released. The client sends a DHCP Release packet to release its IPv6 address.
l A DHCPv6 client is an IPv6 user, and the DHCPv6 client sends a DHCP Release packet
to release its IP address.
l An IPv4/IPv6 dual-stack user uses DHCPv6 to apply for its IPv6 address. When the user
goes offline, its IPv4 address is released first, and the client sends a DHCP Release packet
to release its IPv6 address.
1.2.48 DHCPV6 ip alloc fail
Display
DHCPV6 ip alloc fail
Common Causes
l No IPv6 address pool is configured in the AAA domain.
l The IPv6 address pool is locked.
Procedure
1. Run the display this command in the AAA view to check domain configurations. If no
IPv6 address pool is configured, configure one. If an IPv6 address pool exists, go to Step
2.
2. Run the display this command in the IPv6 address pool view to check whether the IPv6
address pool has the lock command configuration. If this command configuration exists,
run the undo lock command to delete the configuration.

1.2.49 DHCPV6 lease expired
Message
DHCPV6 lease expired
Common Causes
A DHCPv6 user does not extend the IP address lease, or the user-side link fails. As a result,
renewal messages are lost.
1. Check whether renewal messages are correctly sent by the client.
2. Troubleshoot the user-side link failure.
3. Run the lifetime preferred-lifetime { days days-value [ hours hours-value [ minutes
minutes-value ] ] | infinite } valid-lifetime { days days-value [ hours hours-value
[ minutes minutes-value ] ] | infinite } command in the IPv6 prefix pool view to modify
the IPv6 prefix lease.
1.2.50 DHCPV6 packet speed limit
Message
DHCPV6 packet speed limit
Common Causes
The rate at which a DHCPv6 server sends messages exceeds the configured speed limit.
1. Run the displaydhcpv6-server item ipv6-address command to check the speed limit
(Speed Limit field) of a DHCPv6 server.
l If the speed limit does not need to be adjusted, contact Huawei technical support
personnel.
l If the speed limit needs to be adjusted, go to Step 2.
2. Run the dhcpv6-server ipv6-address [ vpn-instance vpn-instance ] send-solicit-speed
packet-number time command in the system view to reconfigure a speed limit at which a
DHCPv6 server sends messages.
1.2.51 DHCPV6 repeat solicit
Message
DHCPV6 repeat solicit

Common Causes
A device has received Solicit messages from online IPv6 users but does not have DHCPv6
message transparent transmission enabled.
1. Run the display this command in the system view to check whether DHCPv4 message
transparent transmission is enabled (whether undo dhcpv6 through-packet is displayed
in the command output).
l If the undo dhcpv6 through-packet command is not displayed, contact Huawei
technical support personnel.
l If the undo dhcpv6 through-packet command is displayed, go to Step 2.
2. Run the dhcpv6 through-packet command in the system view to enable DHCPv6 message
transparent transmission.
1.2.52 DHCPV6 wait client timeout
Message
DHCPV6 wait client timeout
Common Causes
Common causes are as follows:
l A DHCPv6 client does not receive the Advertise message from a DHCPv6 server.
l A DHCPv6 client fails to process the Advertise message from a DHCPv6 server.
l The link between a DHCPv6 client and server fails. As a result, the Request message from
the DHCPv6 client is lost.
1.2.53 DHCPV6 wait server timeout
Message
DHCPV6 wait server timeout
Common Causes
The link between a device and DHCPv6 server fails, or the DHCPv6 server goes Down.
1. Check whether the DHCPv6 server can be pinged.

l If the ping fails, check whether the link fails. If the link fails, troubleshoot the link
failure.
l If the ping succeeds, the physical link is working properly. Then go to Step 2.
2. Run the display dhcpv6-server item ipv6-address command to check whether the
DHCPv6 server is Up.
l If the DHCPv6 server is not Up, troubleshoot the DHCPv6 server Down failure.
l If the DHCPv6 server is Up, contact Huawei technical support personnel.
1.2.54 Fill HQOS to ucm fail
Message
Fill HQOS to ucm fail
Common Causes
The RADIUS-delivered QoS profile is not configured on the local device.
1. Run the display qos-profile configuration command to check whether a RADIUS-
delivered QoS profile is configured on the local device. By default, the device automatically
convert all QoS profile names to lowercase.
2. Perform either of the following operations:
a. If the RADIUS-delivered QoS profile is not configured on the local device, run the
radius-attribute qos-profile no-exist-policy online command in the RADIUS server
group view to allow users to keep online.
b. If the RADIUS-delivered QoS profile is configured on the local device but is
automatically changed to lowercase, the device fails to fill the HQoS parameter with
the originally delivered uppercase profile name. When this problem occurs, run the
radius-attribute case-sensitive qos-profile-name command in the RADIUS server
group view to allow the device to support case-sensitive QoS profiles.
1.2.55 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.56 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.57 Idle cut
Display
Idle cut
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.58 Idle timeout
Message
Idle timeout
Common Causes
The idle-cut function is configured, and the user traffic idle time exceeds the configured value.
1. Run the display domain domain-name command to check the configured idle-cut time
(Idle-data-attribute(time,flow) field).
2. If the configured idle-cut time needs to be modified, run the idle-cut idle-time { idle-
data | zero-rate } [ inbound | outbound ] command in the AAA domain view.

1.2.59 Interface delete
Display
Interface delete
Common Causes
The interface from which a user gets online is deleted.
1.2.60 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.61 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.62 IP alloc fail for trigger user
Display
IP alloc fail for trigger user
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.63 IP address conflict
Display
IP address conflict

Common Causes
The IP address assigned by the RADIUS server to a user has already been used.
Procedure
Re-plan an IP address for this user on the RADIUS server.
1.2.64 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.65 L2TP cut command
Display
L2TP cut command
Common Causes
The reset tunnel command is run on the access device.
Feature Type
L2TP
1.2.66 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

1.2.67 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.68 L2TP request offline
Display
L2TP request offline
Common Causes
An L2TP user sends a logout request.
Feature Type
L2TP
Solution
1.2.69 L2TP service is unavailable
Display
L2TP service is unavailable
Common Causes
L2TP is not enabled on the access device.
Feature Type
L2TP

1.2.70 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.71 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 offline-
record, 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.72 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

1.2.73 LAM access type is no match
Message
LAM access type is no match
Common Causes
The login user type and locally configured user type do not match.
1. Run the display local-user user-name command to check whether the configured user type
(the Service-type value) is the same as the login user type.
2. If the user types are not the same, run the local-user user-name service-type { ftp | ppp |
ssh | telnet | terminal | mml | qx } * command to set the local user type to be the same as
the login user type.
1.2.74 LAM authentication fail
Message
LAM authentication fail
Common Causes
The local authentication password is incorrect.
1. Run the display local-user user-name command to check whether the local user's password
(the Password value) is the same as the login password.
2. If the local user's password is not same as the login password, run the undo local-user
user-name command to delete the local user and run the local-user user-name password
{ cipher cipher-password | irreversible-cipher irreversible-password } command to
recreate a local user and password.
1.2.75 LAM user does not exist
Message
LAM user does not exist
Common Causes
The local user does not exist.

1. Run the display local-user command to check whether the local user exists.
2. If no such local user exists, run the local-user user-name password { cipher cipher-
password | irreversible-cipher irreversible-password } command to create such a local
user.
1.2.76 LAM user state is block
Message
LAM user state is block
Common Causes
The number of times that incorrect passwords are entered exceeds the threshold.
1. Run the display local-user user-name command to check whether the local user is blocked.
2. If the local user is blocked, the user will automatically be unblocked after the interval
specified by the local-user user-name state block fail-times interval interval command
expires. Alternatively, run the local-user user-name state active command to manually
unblock the user.
1.2.77 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 offline-
record, 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.78 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.79 LNS Multicast user resource full

Message
LNS Multicast user resource full
Common Causes
The number of multicast users that apply for downstream CAR resources exceeds the LNS-side
board specification.
A maximum of 32,768 (32K) multicast users are allowed to apply for downstream CAR
resources on an LNS-side board. If the number of users exceeds the specification, contact Huawei
technical support personnel.
1.2.80 Local authen reject
Message
Local authen reject
Common Causes
The login password is incorrect.
1. If the password is in plaintext, re-log in with the password.
2. If the password is in ciphertext, run the local-user user-name password { cipher cipher-
password | irreversible-cipher irreversible-password } command to reconfigure a
password.
1.2.81 local no this user

Message
local no this user
Common Causes
The local user is not configured on the device.
1. Run the display local-user command to check all local users.
2. If no such local user exists, run the local-user user-name password { cipher cipher-
password | irreversible-cipher irreversible-password } command to create such a local
user.
1.2.82 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.
1.2.83 ND Detect Fail
Message
ND Detect Fail
Common Causes
l A client does not reply to ND packets.

l The link between a client and server fails. As a result, the reply packets from the client are
lost.
1.2.84 ND Repeat Request
Message
ND Repeat Request

Common Causes
A device receives an online user's ND login request.
1. Check whether the user has roamed.
l If the user has not roamed, the ND login request may be an attack. Contact Huawei
technical support personnel to resolve this problem.
l If the user has roamed, go to Step 2.
2. Run the display access-user mac-address mac-address command to check whether there
is information about the online ND user.
l If there is information, the roaming user has re-logged in, and no action is required.
l If there is no information, go to Step 3.
3. Run the dhcp session-mismatch action offline command in the BAS interface view to
enable the interface to log out the online user when the user resends DHCP or ND login
requests.
1.2.85 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.86 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.87 No IPv6 address available

Display
No IPv6 address available

Common Causes
No IP address can be assigned.
Solution
1.2.88 No prefix available
Display
No prefix available
Common Causes
No IP address prefix can be assigned.
Solution
1.2.89 No response of control packet from peer
Display
No response of control packet from peer
Common Causes
The remote end fails to respond to all protocol packets along the L2TP tunnel. And then the
tunnel goes Down. The problem may be caused by a link failure, performance fault of the remote
end, or packet loss due to the CAR on the NE80E/40E.
Feature Type
L2TP
1.2.90 Not bind IPv6 pool or ip alloc fail
Message
Not bind IPv6 pool or ip alloc fail
Common Causes
No IPv6 address pools are configured in the domain, or the DHCPv6 server fails to assign IPv6
addresses.

1. Run the display domain domain-name command to check whether IPv6 address pools (the
IPv6-Pool-name value) are configured in the domain.
2. If no IPv6 address pools are configured, run the ipv6-pool pool-name command in the
domain view to configure an IPv6 address pool.
3. If the DHCPv6 server fails to assign IPv6 addresses, reapply for addresses.
1.2.91 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.92 Packet Authenticator Error
Display
Packet Authenticator Error
Fault Symptom
In Web authentication mode, a user fails to be authenticated.
Common Causes
l The key in an authentication packet sent by the portal server is different from the key
calculated by the HUAWEI NetEngine80E/40E.
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 instance-
name ] [ port portnum [ all ] ] [ key key ] [ NAS-ip-address ] command to change the key
to the same as that on the portal server.
l 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.93 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.
NOTE
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.94 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
1.2.95 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.96 PPP user request
Display
PPP user request
Common Causes
A PPP user sends a logout request.
Feature Type
PPP
1.2.97 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.
l The CPU usage is too high (remaining above than 95%).
Feature Type
PPP
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.98 PPP with echo fail
Display
PPP with echo fail

Common Causes
l The intermediate transmission device discards or modifies probe packets.
l 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.
l 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.99 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.
Solution
l Run the display this command in the pre-authentication domain to view whether VAS is
bound to the pre-authentication domain.
– 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.100 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.101 RADIUS authentication reject
Message
RADIUS authentication reject
Common Causes
The user name or password is different from that on the RADISU server.
Check whether the login user name or password and that on the RADIUS server are the same.
If not the same, change them to be the same and reapply for login.
1.2.102 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.103 RADIUS decode packet fail
Message
RADIUS decode packet fail
Common Causes
The device-delivered RADIUS attribute or format is different from that defined in the RADIUS
attribute document.
1. Run the debugging radius packet command to enable the debugging on RADIUS packets
and check the device-delivered RADIUS attribute or format.
2. Contact Huawei technical support personnel to check whether the device-delivered
RADIUS attribute or format is the same as that defined in the RADIUS attribute document.
If not the same, contact Huawei technical support personnel for modification.
1.2.104 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.105 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
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.106 RUI request offline
Display
RUI request offline
Common Causes
RUI triggers a user logout.
1.2.107 Sending RADIUS packets failed due to speed-limit
Display
Sending RADIUS packets failed due to speed-limit
Common Causes
The user access rate exceeded the threshold.
Procedure
1. Check the CPU usage of the router and neighboring NEs, such as the RADIUS server and
DHCP server. If their CPU usage is high, the user access rate limit is proper. Adjusting the
user access rate is not recommended.
2. Check the performance of the router and neighboring NEs. If their performance is adequate
for higher user access rate, run the access-speed command in the AAA view to set a higher
user access rate.

1.2.108 Service unavailable
Display
Service unavailable
Common Causes
An L2TP user attempts to log in to the access device where L2TP is disabled.
1.2.109 Session time out
Display
Session time out
Common Causes
A user has no remaining online time.
1.2.110 Session timeout
Message
Session timeout
Common Causes
The duration quota that a RADIUS delivers to a user is exhausted.
After the user's duration quota is exhausted, if the user needs to re-log in, the user must renew
the fee or apply for a new duration quota.
1.2.111 Soft-GRE active user over limit
Message
Soft-GRE active user over limit
Common Causes
The number of active soft-GRE users exceeds the maximum number supported by a device.
l Log out idle active users.

1.2.112 Srvcfg cut command
Display
Srvcfg cut command
Common Causes
A command is run to delete leased-line users.
1.2.113 SRVCFG failed to process
Display
SRVCFG failed to process
Common Causes
The access device fails to select a user authentication type.
Solution
1.2.114 TACACS authentication reject
Message
TACACS authentication reject
Common Causes
The user name or password is different from that on the TACACS server.
Check whether the login user name or password and that on the TACACS server are the same.
If not the same, change them to be the same and reapply for login.
1.2.115 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.116 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.117 The RADIUS server does not reply with Authentication

ACK messages
Display
The RADIUS server does not reply with Authentication ACK messages
Common Causes
l The RADIUS server fails.
l The RADIUS server is unreachable to the router at the IP layer, which may be caused by
an intermediate device failure.
Procedure
1. Run the ping command to check whether the RADIUS server is reachable to the router at
the IP layer. If the RADIUS server is unreachable to the router, check whether an
intermediate device fails. If so, rectify the fault. If the RADIUS server is reachable to the
router, go to Step 2.
2. Check whether the RADIUS server is working properly. If the RADIUS server is not
working properly, rectify the server fault.
1.2.118 The vrf of domain is not accord with the pool

Message
The vrf of domain is not accord with the pool
Common Causes
l The VPN instance configured in an AAA domain is different from that configured in any
address pool bound to the AAA domain.
l A device is configured to trust the VPN instance bound to a BAS interface in the AAA
domain view, but the VPN instance on the BAS interface is different from that configured
in any IP address pool bound to the AAA domain.
1. Run the display this command in the AAA domain view to check whether a device is
configured to trust the VPN instance bound to the BAS interface through which Layer 2

users go online (whether trust vpn-instance access-interface is displayed in the command

output).
l If the device is configured to trust the VPN instance bound to the BAS interface, go to
Step 2.
l If the device is not configured to trust the VPN instance bound to the BAS interface, go
to Step 3.
2. Run the display this command in the BAS interface view and IP address pool view and
check whether the VPN instance on the BAS interface is the same as that configured in the
IP address pool.
l If the VPN instances are different, run the vpn-instance instance-name command in
the BAS interface view or IP address pool view to ensure that the two VPN instances
are the same.
l If the VPN instances are the same, contact Huawei technical support personnel.
3. Run the display this command in the AAA domain view and IP address pool view and
check whether the VPN instance in the AAA domain is the same as that configured in the
IP address pool.
l If the VPN instances are different, run the vpn-instance instance-name command in
the AAA domain view or IP address pool view to ensure that the two VPN instances
are the same.
l If the VPN instances are the same, contact Huawei technical support personnel.
1.2.119 Up to user max session
Message
Up to user max session
Common Causes
The number of access sessions set up by users with the same user name exceeds the upper limit.
1. Run the display domain domain-name command to check the upper limit of the access
sessions set up by users with the same user name.
2. If the number of access sessions set up by users with the same user name exceeds the upper
limit, run the user-max-session max-session-number [ case-insensitive local-user-
name ] command to increase the upper limit.
1.2.120 User access speed too fast

Display
User access speed too fast
Common Causes
The user access speed is too fast.

1.2.121 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.
1.2.122 User's password expired
Message
User's password expired
Common Causes
A user's password expires.
1. Run the display local-user user name user-name command to check whether the user's
password expires.
l If Password expired is displayed as no, the password has not expired. In this situation,
contact Huawei technical support personnel.
l If Password expired is displayed as yes, the password expires. In this situation, go to
Step2.
2. Run the local-user user-name password { cipher cipher-password | irreversible-cipher
irreversible-password } command in the AAA view to re-create a password.
3. To modify the password lifetime, run the user-password expire expire-time prompt
prompt days command in the AAA view to set a password lifetime and enable a device to
prompt users to change the password n days (specified by prompt days) before the
password expires.
1.2.123 VPDN license not enable
Message
VPDN license not enable
Common Causes
The GTL license file does not contain the L2TP function.

Run the display license command to check whether LCR5L2TP00 Function YES LNS&LTS
Function is displayed in the command output.
l If LCR5L2TP00 Function YES LNS&LTS Function is displayed, the GTL license file
contains the L2TP function. In this situation, contact Huawei technical support personnel.
l If LCR5L2TP00 Function YES LNS&LTS Function is not displayed, the GTL license
file does not contain the L2TP function. In this situation, reapply for a GTL license file that
contains the L2TP function.
1.2.124 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 LAN Switch LAN Switch Router
Figure 1-4 Networking for IPoA and IPoEoA

RADIUS
User
Server
Internet
DSLAM Router

Troubleshooting Flowchart
Figure 1-5 IPoX troubleshooting flowchart

IPoX user
cannot go
online
Passed No Check authentication

authentication? domain or pre-
authentication domain
Yes
Obtained an IP No Configure address

pool or DHCP server
address?
properly
Yes
Enable service tracing

or debugging
No Technical
Fault removed?
support
Yes
End
Procedure
Step 1 Check whether the user passes authentication.
l If user authentication fails, check the authentication domain and pre-authentication domain
configurations based on the authentication mode.
l If user authentication is successful, go to Step 2.
Step 2 Check whether the user has obtained an IP address.
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.
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 LAN Switch Router
Figure 1-8 Networking for PPPoEoQ

Eth PPP Data Eth Tag PPP Data Eth Tag Tag PPP Data
I nt e rnet
subscriber LAN Switch LAN Switch Router

Figure 1-9 Networking for PPPoA and PPPoEoA

RADIUS
User
Server
Internet
DSLAM Router

Figure 1-10 PPPoX troubleshooting flowchart

PPPoX user
cannot go
online
No Remove
Configuration
proper? configuration fault
Yes
Display tracing
information
No
Tracing info Remove
displayed? device fault
Yes
LCP Yes
negotiation Authentication No Remove
successful? successful? authentication failure
No Yes
No
Remove NCP negotiation Remove IP address
device fault successful? allocation failure
Yes
Remove
accounting failure
No
Fault removed? 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
-------------------------------------------------------------------

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

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.
l 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.
Step 5 Check the configuration.

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.

Step 6 Obtain the packets at the client to check whether the LCP negotiation is complete.
By obtaining 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 Challenge-Handshake Authentication Protocol
(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.

– 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
LAN
User Router
Switch
As shown in Figure 1-12, the layer-3 leased line user accesses the VLAN on an interface or sub-
interface of the NE80E/40E through a router.

Figure 1-12 Layer-3 leased line networking
I n t e rnet
L3
User Router
Switch
Figure 1-13 Static user Layer-2 leased line Troubleshooting flowchart
A layer- 2 leased
line user cannot
go online
No
Sub-interface Configure the sub
Up? - interface to Up
Yes
BAS No
configuration Configure BAS
proper?
Yes
Domain Configure
configuration No authentication /
proper ? accounting /RADIUS
servers
Yes
Address pool No Configure the

configured ? address pool
Yes
No
IP address of Exclude the IP
static user address from
excluded ? address pool
Yes
Enable service
tracing
Device received No Check the fault on

The DHCP or ARP layer - 2 network
sent by user ?
Yes
Fault No Technical
?
removed support
Yes
End

Figure 1-14 Layer-3 leased line troubleshooting flowchart
A layer 3 leased line

user cannot go
online
Configure an IP
No
Sub- interface Up? address for the
interface
Yes
BAS No
configuration Configure BAS
proper ?
Yes
Configure
Domain No
authentication /
configured properly ? accounting /RADIUS
servers
Yes
No
Technical
Fault removed ?
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

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 LAN Switch L3 Switch Router

10.164.44.2/24 192.168.1.1/24 192.168.1.2/24
l The ordinary L3 user configures an IP address or obtains an IP address from the DHCP
server.
l The user accesses the Internet through the router, and the router should manage the user.

Figure 1-16 L3 access troubleshooting flowchart
Layer 3 users fail

to go online
Any record Yes Rectify the fault

of failures in getting based on the
online? records
No
Is the
physical status of No Rectify the fault on
the Layer 3 interface the interface
normal?
Yes
Are device No Correctly configure

configurations
Layer 3 users
correct?
Yes
Enable service
tracking to locate the
fault
Is the fault No Seek technical

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

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 Virtual Private Network(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.

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 Switch Switch BRAS

Figure 1-20 802.1X troubleshooting flowchart
802.1X
authentication
fails
BAS No Configure the

interface correctly BAS interface
configured? correctly
Yes
No Configure the
Domaincorrectly domain
configured? correctly
Yes
EAPtermination
No configured?
Yes
User
RADIUS information
server correctly correctly
configured? Yes configured?
Seek
No technical No
support
Configure
user Is fault Yes
End
information rectified?
correctly
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.

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.3.6 Users Go Offline at Low Speed

This section describes how to troubleshoot the problem that users go offline at low speed on a
BRAS device.
Common Causes
This fault is commonly caused by one of the following:
l A limit is configured on the user offline speed.
The default user offline speed is 256 users per second on a BRAS. If users go offline at a speed
lower than 256 users per second, the user offline speed is low. To monitor the user offline speed,
run the display access-user online-total-number command repeatedly.
Figure 1-21 shows the troubleshooting flowchart.
Figure 1-21 Troubleshooting flowchart for the problem that users go offline at low speed
Users go offline at low

speed.
Limit on the No Configure the Yes

user offline speed correct user The fault is rectified.
is correct. offline speed.
Yes No
Contact Huawei
technical support End
personnel.
Before you perform the following steps, run the display aaa configuration command to check
whether a smaller value is configured for the user offline speed. The default user offline speed
is 256 users per second.
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 the current user offline speed.
Run the display access-user online-total-number command repeatedly to estimate the current
user offline speed.

l If the user offline speed is about 256 users per second, the users go offline at a normal
speed.
l If the user offline speed is far less than 256 users per second, the users go offline at a low
speed. Go to step 2.
Step 2 Check whether a limit is configured for the user offline speed.
Run the display aaa configuration command in the user view to check the user offline speed
configured on the device.
l If the configured user offline speed is less than 256 users per second, go to Step 3.
l If the configured user offline speed is 256 users per second, go to Step 4.
Step 3 Reset the user offline speed.

Check that the configured user offline speed is not required and run the offline-speed 256
command in the AAA view. Then, run the display access-user online-total-number command
repeatedly to check the current user offline speed.
l If the user offline speed is normal, the problem is solved.
l If the user offline speed is abnormal, go to Step 4.
Step 4 Collect the following information and contact Huawei technical support personnel.
l Result of the preceding procedure
l Trap, log, and configuration information
----End
Relevant Alarms
None
Relevant Logs
None
1.3.7 EAP-PEAP and EAP-SIM/AKA Users Cannot Go Online

This section describes the troubleshooting procedure and how to troubleshoot the problem that
EAP-PEAP and EAP-SIM/AKA users cannot go online when the NE80E/40E functions as a
BRAS.
Common Causes
l The AC group is incorrectly configured.

l The BAS interface is disabled from sending PMK to a specified AC.
l The configuration of another device on the link is faulty.

l The physical link becomes faulty.
When the NE80E/40E functions as a BRAS, EAP-PEAP and EAP-SIM/AKA users cannot go
online.
The troubleshooting roadmap is as follows:
l Check whether the AC group is correctly configured globally.
l Check whether the BAS interface is enabled to send PMK to the specified AC.
l Check whether the configuration of the other devices on the link is correct.
l Check whether the physical link is faulty.
Figure 1-22 Troubleshooting flowchart for the problem that EAP-PEAP and EAP-SIM/AKA
users cannot go online
EAP-PEAP and EAP-
SIM/AKA users cannot
go online.
The AC group is No Configure a correct Yes

configured correctly. The fault is rectified.
AC group.
No
Yes
The BAS Configure the

interface is enabled No Yes
to send PMK to the correct IP address The fault is rectified.
specified AC. of the PCP server.
Yes No
The
configurations No Configure the other Yes
of other devices The fault is rectified.
devices correctly.
are correct.
Yes No
The link No Yes

functions properly. Restore the link. The fault is rectified.
No
Yes
Contact Huawei
personnel.
NOTE

Procedure
Step 1 Check whether the AC group is correctly configured globally.
Run the display current-configuration | include ac-group command to check whether the AC
group is correctly configured globally.
l If no information is displayed, there is no AC group configured. Run the ac-group group-

name command to create an AC group and display the AC group view. Then, run the
authorization-ac { ip-address [ vpn-instance vpn-name ] [ port-num ] | share-key key-
value | source interface interface-type interface-number } command to configure
parameters about the AC group.
l If AC group information is displayed, there is an AC group configured. Run the ac-
group group-name command to display the AC group template. Then, run the display
this command to check whether the IP address, VPN instance name, and source interface
of the AC group are correctly configured.
– If the configurations are incorrect, run the ac-group group-name command to create an
AC group and display the AC group view. Then, run the authorization-ac { ip-
address [ vpn-instance vpn-name ] [ port-num ] | share-key key-value | source
interface interface-type interface-number } command to reconfigure parameters about
the AC group.
– If the configurations are correct, go to step 2.
Step 2 Check whether the BAS interface is enabled to send PMK to the specified AC.
Run the display current-configuration | include authorization-pmk-send ac-group

command to check whether PMK of an AC group is bound to the BAS interface. By default, a
BAS interface is disabled from sending PMK to a specified AC.
l If no information is displayed, the BAS interface is disabled from sending PMK to the
specified AC. Run the authorization-pmk-send ac-group group-name command in the
BAS interface view to enable the BAS interface to send PMK to the specified AC. The
group-name parameter must be the same as that in the ac-group group-name command.
l If information is displayed, check whether the group-name parameter is the same as that
in the ac-group group-name command.
– If this parameter is different, run the authorization-pmk-send ac-group group-name
command in the BAS interface view to reconfigure it.
– If this parameter is the same, go to Step 3.
Step 3 Check whether the configuration of the other devices on the link is correct.
Check whether the configurations are correct based on the manuals of the related devices. If the
configurations are incorrect, modify the relevant configurations. If the CPE client traffic still
cannot be forwarded, go to Step 4.
Step 4 Check whether the link is normal.

Check whether the AC can ping the BRAS, whether the AC can ping the AP, and whether the
link connected to the authentication server is normal.
l If the link is faulty, restore the link.
l If the link is normal but users cannot access the network, go to Step 5.

l Result of the preceding procedure

l Trap, log, and configuration information
----End
Relevant Alarms
None
Relevant Logs
None
1.4 IPv6
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
l The IPv6 function is not globally enabled.

l DUID is not configured globally.
l The IPv6 protocol on the user-side interface is Down.
l The M/O value has been configured on the user-side interface.
l Bind authentication is not configured on the user-side interface with the BAS.
l 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.
l Check that the IPv6 protocol is Up on the user-side interface.

l Check that the M/O value has been configured on the user-side interface.
l Check that bind authentication has been configured on the interface with the BAS.

l Check that address pools have been correctly configured.

Figure 1-23 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 Yes
The IPv6 function is Globally enable
Is fault rectified?
globally enabled? the IPv6 function
Yes No
No Yes
s the DUID function Globally enable
Is fault rectified?
globally enabled? the DUID function
Yes No
The user-side No Ensure that the Yes

interface is user-side interface Is fault rectified?
physically up? is physically up
No
Yes
No Yes
The IPv6 protocol Ensure that the
is up on the user- IPv6 protocol is up Is fault rectified?
side interface? on the interface
Yes No
No Yes
Configure the M/O Configure the M/O
vaule on the interface vaule on the Is fault rectified?
interface
Yes No
No Yes
Bind authentication has Configure bind
been configured on the Is fault rectified?
user-side interface with authentication
the BAS?
No
Yes
No Yes
Are the local address Correctly configure
pool and the delegation Is fault rectified?
address pools
address pool
configured?
Issue 02 (2014-09-30) Yes
Huawei Proprietary and Confidential 68
No
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
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 duidduid-
value 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.

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 other-
flag 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 pool-
name 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.
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.

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.
l 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.
l Check that the unshared mode of prefix assignment has been configured in the domain
view.

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

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

The IPv6 protocol is up IPv6 protocol is
on the user-side Is fault rectified?
up on the user-
interface?
side interface
No
Yes
No Yes
Bind authentication
has been configured Configure bind
Is fault rectified?
on the user-side authentication
interface with the
BAS?
No
Yes
No Configure an ND- Yes

An ND-unshared
unshared
delegation address pool Is fault rectified?
delegation
has been configured?
address pool
No
Yes
No Configure a PD- Yes

A PD-unshared
unshared
delegation
address pool
Yes
No
The unshared mode of No Configure the Yes

prefix assignment and unshared mode of
address pools have been
Issue 02 (2014-09-30) correctly configured in Huawei Proprietary and Confidential
prefix assignment Is fault rectified? 72
the authentication and correct
domain view?Copyright © Huawei Technologies Co., Ltd.
address pools
Yes No
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 duidduid-
value command in the system view to enable the DUID function.
the interface is physically Up.


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

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.
l The IPv6 address pool is incorrectly configured.
l The address allocation mode is not configured on the user-side interface.
l 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.

l Check that the DUID function is enabled in the system view.
l Check that a correct IPv6 address pool has been configured.
l Check that bind authentication has been configured on the user-side interface.
l 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.)

Figure 1-25 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 No Yes

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

Globally enable the
Is fault rectified?
globally enabled? DUID function
No
Yes
The IPv6 address pool has No Correctly configure the Yes

been correctly configured? IPv6 address pool Is fault rectified?
No
Yes
Bind authentication has Configure bind

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

correctly configured on the Is fault rectified?
and stateful access
user-side interface
No
Yes
Seek technical support
End

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 user-
side 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 managed-
address-flag command in the user-side interface view to configure the address allocation
mode.

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.

l The DUID function was not globally enabled.
l The remote address pool was incorrectly configured.
l The remote server was incorrectly configured.
l Bind authentication was not configured on the user-side interface.
l The address allocation mode was incorrectly configured on the user-side interface.
l 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 Check that the remote address pool has been correctly configured.
l Check that the remote server has been correctly configured.
l Check that bind authentication has been configured on the user-side interface.
l Check that the address allocation mode has been correctly configured on the user-side
interface.

Figure 1-26 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 Yes
Is fault rectified?
Yes No
No Yes
The DHCPv6 DUID Globally enable
function is globally the DHCPv6 Is fault rectified?
enabled? DUID function
Yes
No
The remote No Correctly Yes

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

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.

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 managed-
address-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-27 shows the typical networking of PPPoE access. PPPoE access troubleshooting is
based on this networking.

Figure 1-27 Typical networking diagram of PPPoE access

DNS server RADIUS server
3001:0410::1:2 129.6.55.55
Access GE8/0/3 GE7/0/3

Internet
Network
subscriber
Router
@isp5
As shown in Figure 1-27:
l The user is connected to the NE80E/40E through a Layer 2 network, and the user gets online
by dialing in through PPP.
l The NE80E/40E is connected to the RADIUS server to implement authentication and
accounting for users.
l 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.

Figure 1-28 Troubleshooting flowchart of PPPoE access
A Client cannot get online
Does the
No Check the Yes
physical connection
physical connection Is fault
between the client and the
between the client and rectified?
server work
the server
normally?
Yes No
Is the No Check the Yes

Is fault
configuration of the interface configuration of the
rectified?
correct? interface
Yes No
Is the prefix
No Configure a prefix
pool configured Yes
address and configure Is fault
and Is a prefix address
a prefix address for rectified?
configured for
the pool
the pool?
No
Yes
Is an
No Configure an address Yes
address pool Is fault
pool and bind some
configured and some rectified?
addresses to the
addresses bound to this
address pool
address pool?
No
Yes
Is the IPv6 No Bind the IPv6 address Yes

address pool bound to Is fault
pool to the user
the user domain? rectified?
domain
Yes No
Does
the address No Configure a new Yes
pool have an available address pool, prefix Is fault
address to be allocated pool, and prefix rectified?
to the client? addressed
Yes No

End

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

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.
l The IPv6 address pool is incorrectly configured.
l The address allocation mode is not configured.
l 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.


l Check that a correct IPv6 address pool has been configured.
l 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-29 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
No
The IPv6 function is Globally enable the Yes
Is fault rectified?
globally enabled? IPv6 function
No
Yes
No Yes
The DUID function is Globally enable the
Is fault rectified?
globally enabled? DUID function
No
Yes
No
Yes
The IPv6 address pool has Correctly configure
Is fault rectified?
been correctly configured? the IPv6 address pool
No
Yes
No Yes
The M value has been Configure the M value
Is fault rectified?
configured in the and stateful access
domain view?
No
Yes
Seek technical
support End

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.

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-30 shows the typical networking of ND access. ND access troubleshooting is based
on this networking.
Figure 1-30 Typical networking diagram of ND access

3001:0410::1:2 129.6.55.55

Internet
Network
subscriber
Router
@isp6
l The user accesses the NE80E/40E through a Layer 2 network.


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.

Figure 1-31 Troubleshooting flowchart of ND access
A client cannot get

online
Does the physical No

Check the physical Yes
connection between the connection between the Is fault rectified?
client and the server work client and the server
normally?
No
Yes
No Check the Yes

Is the configuration of
configuration of the Is fault rectified?
the interface correct?
interface
Yes No
Is an prefix pool No Configure a prefix

Yes
configured and is a prefix address and configure a
Is fault rectified?
address configured for the prefix address for the
pool? pool
No
Yes
Is an address pool Configure an address Yes

No
configured and are some pool and bind some Is fault rectified?
addresses bound to this addresses to the
address pool? address pool
No
Yes
No
Is the IPv6 address Bind the IPv6 address Yes
Is fault rectified?
pool bound to the user pool to the user domain
domain?
Yes No
Configure a new Yes

Does the address pool No address pool, prefix Is fault rectified?
have an available address pool, and prefix
to be allocated to the addresses
client?
No
Yes
Seek technical End

support

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-unshare-
only 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 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 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.
l 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.

l Check that a correct prefix pool has been configured.
l Check that the unshared mode of prefix assignment has been configured in the domain
view.

Figure 1-32 Troubleshooting flowchart for the fault that the ND-unshared user cannot get online
The ND-unshared
user cannot get
online
Yes
No
Is fault rectified?
Yes No
Ensure that Yes

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

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

The M/O value is No M/O vaule is not
disabled on the user- configured on the Is fault rectified?
side interface? user-side
interface
Yes No
Yes
Bind authentication No
has been configured Configure bind
authentication
interface with the
BAS?
No
Yes
Configure an ND- Yes

An ND-unshared No
unshared
delegation
address pool
Yes No
The unshared Yes

mode of prefix No
assignment has Configure the
Is fault rectified?
been configured in unshared mode
the authentication
Issue 02 (2014-09-30) domain view? Huawei Proprietary and Confidential 95
Yes 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 other-
flag 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.


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

l The DUID was not globally configured.

l The IPv6 function was not globally enabled.
l The interface was physically down.
l QinQ was not configured on the inbound interface of the relay agent.
l An IPv6 global unicast address was not configured for the inbound interface of the relay
agent.
l No IPv6 address for the relay or BAS interface was configured on the inbound interface of
the relay agent.
l No M value was configured on the inbound interface of the relay agent.
l No IPv6 link-local address was configured on the the inbound or outbound interface of the
relay agent.
l IPv6 was disabled on the inbound or outbound interface of the relay agent.
l The IPv6 addresses configured on the BAS port and outbound interface of the relay agent
were in different network segments.
l Layer 3 access was not configured on the user-side interface of the server.
l An IPv6 relay address pool was not configured on the server.
l 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.
l Check that a correct IPv6 global unicast address has been configured for the inbound
interface of the relay agent.
l Check that an outbound interface has been configured for the inbound interface of the relay
agent.
l Check that the address allocation mode has been configured.
l 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.
l Check that an IPv6 relay address pool has been configured on the server.
NOTE

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.

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.

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.
l The link layer protocol of the interface is down.
l The configured username or password is incorrect.
l 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.
l Check that an IPv6 address has been correctly configured on the user access interface.
l Check that the IPv6 function is globally enabled in the system view.
l Check that correct Layer 3 leased line user information has been configured on the interface
with the BAS.

of IPv6 Layer 3 leased line access
The user cannot get

online in the case of IPv6
L3 private line access
No
The IPv6 function is The IPv6 function is Yes
Is fault rectified?
globally enabled? globally enabled?
No
Yes
The interface configured Ensure that the user- Yes

with the L3 private line side interface is Is fault rectified?
service is physically up? physically up
No
Yes
No Yes
A correct IPv6 address Correctly configure the
Is fault rectified?
has been configured? IPv6 address
No
Yes
The IPv6 protocol is up No Ensure that the IPv6 Yes

on the interface
protocol is up on the Is fault rectified?
configured with the L3
private line service? interface
No
Yes
No Modify L3 private line

The configured user Yes
configuration to ensure
name and password are Is fault rectified?
that the user name and
correct?
password are correct
No
Yes
No Yes
The authentication domain has Correctly specify the
Is fault rectified?
been specified? authentication domain
Yes
No
Seek technical
support
End

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

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.
l The address of the PD access user does not match the PD prefix configured for static users.
l 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.
l 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.
l The user access interface is not the interface configured for static users.
l 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.

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.
l 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.
l Check that the user access interface is the interface configured for static users.
l Check that ARP/ND Trigger or IPv4/v6 Trigger has been configured.
l Check that the detect keyword has been configured in the buildrun information about static
users.

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

online
The source address Ensure that the source

of the request packet No Yes
from the IPv6 or PD address of the packet is
Is fault rectified?
user is the IPv6 the address configured
address or PD prefix for the static user
configured for the
static user
No
Yes
The L2 information about No Modify the L2 Yes

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

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

configured on the interface with them against the Is fault rectified?
the BAS is correct? configuration manual
No
Yes
No Correctly configure
Are ND Trigger and IPv6 Yes
them against the Is fault rectified?
Trigger correctly configured?
configuration manual
No
Yes
No Yes
The detect keyword has been Correctly configure
Is fault rectified?
configured? the detect keyword
No
Yes
Seek technical
End
support
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 | { ip-

addressstart-ip-address [ end-ip-address ] | ipv6-addressstart-ipv6-address [ end-ipv6-
address ] | delegation-prefixstart-ipv6-prefix [ end-ipv6-prefix ] prefix-length } [ vpn-
instanceinstance-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-ipv6-
address ] | [ delegation-prefixstart-ipv6-prefix [ end-ipv6-prefix ] prefix-length ] } [ vpn-
instanceinstance-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.

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 accounting-
schemescheme-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-typelayer2-
subscriber [ default-domain { [ authentication [ force | replace ] dname ] [ pre-
authenticationpredname ] } | bas-interface-namebname | accounting-copyRADIUS-
serverrd-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 [ end-
ip-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-ipv6-
prefix [ end-ipv6-prefix ] prefix-length ] ipv6-gatewayipv6-address } *[ vpn-
instanceinstance-name ] [ domain-namedomain-name | interfaceinterface-typeinterface-
number [ 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.

----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.
l The physical network between the device and the RADIUS server fails.
l The RADIUS server becomes faulty.
l The user information sent by the device to the RADIUS server is incorrect, causing an
authentication failure.
l 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

l RADIUS authentication request send fail

l 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.
l 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 test-
aaa user-name password RADIUS-group group-name [ chap | pap ] [ test-group test-
group-name ] command with user access attributes to locate the server reject cause.

Figure 1-35 Troubleshooting flowchart for the interconnection failure between the RADIUS
server and the device
The RADIUS
user cannot get
online
Check the physical

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

server fault rectified?
No
Confirm that the

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

support engineers
Check the reply

The user's access request is Yes message in the Is fault Yes
denied by the server? access failure rectified?
record
No
No
Run the test-aaa

command to verify Yes
Is fault
the correctness of
rectified?
user access
information
No

support engineers
Refer to the manual Yes

Is fault
about user access
rectified?
failure
No

End
support engineers
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 RADIUS-
server 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

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 RADIUS-
server 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 domain-
included command, the user name will include a domain name. If you run the RADIUS-server user-
name 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

1.5.1 An L2TP User Fails to Get Online
Common Causes
l Layer 3 forwarding between the LAC and the LNS fails.

l L2TP is not enabled on the LAC or the LNS.
l L2TP group attributes of the LAC and the LNS are not matched.
l The LAC and the LNS do not have the consistent tunnel authentication scheme or password.
l 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.
l The LNS group is incorrectly bound to the tunnel board and loopback interface.
l The PPPoX service fails.
l The IP address pool is incorrectly configured, and the IP address pool fails to allocate a
correct IP address to the L2TP user.
l 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.

Figure 1-36 Troubleshooting flowchart for the failure of the L2TP user to get online
An L2TP user
fails to get online
Yes
No Rectify the fault of the link

Can the LAC ping the LNS successfully? Is fault rect
between the LAC and the LNS.
No
Yes
No
Is L2TP enabled on the LAC and the Enable L2TP Is fault rect
LNS?
No
Yes
No
Are the L2TP group and its attributes Correctly configure the L2TP
correctly configured for the LAC and the Is fault rect
group and its attributes
LNS?
No
Yes
Configure tunnel authentication

Are the tunnel authentication No
for the LAC and the LNS and
mode and password correct for the LAC Is fault rect
and the LNS? set the matched user name
and password
No
Yes
Is AAA authentication Configure tunnel authentication

configured on the LAC? Is the No and consistent user names and
remote tunnel name configured on the LAC Is fault rect
consistent with the tunnel name passwords for the LAC
configured on the LNS? and LNS
No
Yes
No
Correctly configure the LNS
Is the LNS group correctly configured? Is fault rect
group and its attributes
No
Yes
No
Is the PPPoX service normal? Correctly configure user access Is fault rect
No
Yes
Issue 02 (2014-09-30) Huawei Proprietary and Confidential

No
115
Correctly configure an IP
Copyright © Huawei Technologies Co., Ltd. address pool for the user Is fault rect
Can the L2TP obtain an IP address?
domain on the LNS side
No
Yes
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

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

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.

l L2TP was not enabled globally.
l L2TP tunnels or sessions cannot be established.
l The address allocation mode is not correctly configured.
l The DUID function is not configured when addresses are allocated in DHCPv6 mode.

l The IPv6 function is disabled on the source interface of the L2TP tunnel on the LNS.
l 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.
l Check that an IPv6 address pool has been correctly configured.
l Check that other IPv6-related information has been correctly configured.

Figure 1-37 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 No Refer to relevant

sessions can be manuals to correct Is fault rectified?
established? wrong items
Yes
No Yes
The IPv6 function is Enable the IPv6
Is fault rectified?
globally enabled? function globally
Yes
The IPv6 function is Enable the IPv6 Yes

No
enabled on the interface function on the Is fault rectified?
associated with the LNS
group? interface
Yes
The IPv6 address Yes

The IPv6 address pool No
pool has been Is fault rectified?
has been correctly correctly configured?
configured?
Yes
Refer to relevant Yes

The M value and DUID No
operation steps to Is fault rectified?
are correctly configured?
correct wrong items
Yes
Seek technical
support
End

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.

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-38 shows the typical networking of L2TP access. L2TP access troubleshooting is based
on this networking.
Figure 1-38 Typical networking diagram of L2TP access

RADIUS server DNS server
20.20.20.1 3001:0410::1:2
Headquarter
PSTN/ISDN
GE1/0/1 Tunnel
GE1/0/2 GE2/0/1 GE2/0/2
subscriber
RouterA RouterB
@isp1 (LAC) (LNS)

l The NE80E/40E functions as an L2TP Access Concentrator (LAC) or L2TP network server
(LNS).
l 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.

Figure 1-39 Troubleshooting flowchart of L2TP access
A Client cannot get online
No Yes
Is the Check the
Is fault
configuration of user access configuration of the
rectified?
correct? interface
Yes No
No Check the physical Yes
Can the
connection and the Is fault
LAC and the LNS ping
route between the rectified?
through each other?
LAC and the LNS
Yes No
Is L2TP No Yes
Is fault
enabled on the LAC and Enable L2TP
rectified?
the LNS?
Yes No
Are the
configuration of the No Yes
Correctly configure the
L2TP groups on the LAC and Is fault
L2TP groups and the
the LNS and attributes of the rectified?
attributes
L2TP groups
correct?
Yes No
Are the Modify the tunnel

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

End

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.

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.
l 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.
l Check whether L2TP configurations on the slave device are the same with those on the
master device.
l 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.

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

Troubleshooting - User Access 2 Client Fails to Obtain an IP Address Troubleshooting
2 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

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-IPv6-
Pool or HUAWEI No.191 attribute Delegated-IPv6-Prefix-Pool.

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.

l 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.
l 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.
l The IP address pool has no assignable IP address.
l The link between the DHCP server and the client is faulty.
l 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.
l Check the link between the DHCP server and the client is normal.
l Check that other devices along the link are correctly configured.

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
No
Is DHCP enabled? Enable DHCP Is fault rectified?
Yes
No
Yes
Is the interface at the user No Configure a correct IP

Is fault rectified?
side assigned a correct IP address
Yes
address?
No
Yes
No Create an IP address
Does an IP address pool Is fault rectified?
pool
exist? Yes
No
Yes
Rectify the fault

Is the IP address pool No according to the specific
Is fault rectified?
correctly configured? troubleshooting
Yes
procedure
No
Yes
Increase the number of IP

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

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

Are other devices correctly according to user manual Is fault rectified?
configured? for these devices Yes
No
Yes
Seek technical support End

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.
l 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 ip-
address command to correctly configure an IP address.
l 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.
l 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.

Item Field Correct Value Restoration

Procedure
Check whether the Position Server If the field is

type of the IP address displayed as Local or
pool is Server. 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 Status Unlocked If the field is

address pool is displayed as
locked. Locked, run the
undo lock command
to unlock the IP
address pool.
Check whether the IP idle If the idle field is l If there are

address pool has conflicted displayed as a value conflicting IP
assignable IP larger than 0, it addresses, run the
addresses. indicates that reset conflict-ip-
assignable IP address
addresses exist in the command to
IP address pool. mark the
If the conflicted field conflicting IP
is displayed as 0, it addresses as idle.
indicates that there l Re-plan the
are no conflicting IP network and
addresses. 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.
l 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.

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.

l Incorrect DHCP option number, relay agent address, or DHCP server address is configured.
l The link between the DHCP relay and the DHCP server or between the DHCP relay and
the client is faulty.
l 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 Check that the DHCP relay is correctly configured.

l Check the link connectivity between the DHCP relay and the DHCP server or between the
DHCP relay and the client.
l 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.

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
No
Is DHCP enabled? Enable DHCP Is fault rectified?
Yes
Yes No
No
Is DHCP relay enabled? Enable DHCP relay Is fault rectified?
Yes
Yes No
No Correctly configure
Are DHCP relay
DHCP relay Is fault rectified?
attributes correct?
attributes Yes
No
Yes
Is the link between the

No
DHCP relay and DHCP Rectify the link fault Is fault rectified?
server/client normal?
Yes
No
Yes
Check whether the

DHCP relay-enabled Interface is Run the dhcp
the sub-interface for dot1q or qinq No relay Userinfo
VLAN tag termination and a VLAN enable Is fault rectified?
Yes
segment is Configured on the VLAN command
Of the interface.
No
Yes
Rectify the fault

Are other devices No according to user
Is fault rectified?
correctly configured? manual for these
devices Yes
Yes No

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.
l 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.
l 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.
l 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. source-
ip-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.
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
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.

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.
l The BAS interface is incorrectly configured.

l 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.
l Check the link connectivity between the DHCP server and the client.

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
No
Is the interface bound Bind the correct domain
Is fault rectified?
to a correct domain? to the interface
Yes
Yes No
No
Is the domain bound to Bind a correct IP address
Is fault rectified?
a correct IP address? to the domain
Yes
No
Yes
Is the IP address pool No Rectify the fault according to

the specific troubleshooting Is fault rectified?
correctly configured.
procedure
Yes
Yes No
No Increase the number of IP

Does the IP address pool addresses in the IP address
Is fault rectified?
have assignable IP pool or solve the IP address
addresses? conflict problem Yes
Yes No
Is the BAS interface No Rectify the fault according to

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

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

Are other devices correctly to the user manual for the Is fault rectified?
configured? specific device Yes
No
Yes
End


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


Procedure
Check whether the Position Local If the field is

type of the IP address displayed as
pool is Local. Remote or Server,
run the ip pool pool-
name bas local
command again to
configure the IP
address pool to the
Local type.

undo lock command
to unlock the IP
address pool.
Check whether the IP idle If the idle field is l If there are

address pool has conflicted displayed as a value conflicting IP
assignable IP larger than 0, it addresses, run the
addresses. indicates that reset conflict-ip-
assignable IP address
addresses exist in the command to
IP address pool. mark the
If the conflicted field conflicting IP
is displayed as 0, it addresses as idle.
indicates that there l Re-plan the
are no conflicting IP network and
addresses. 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.

l 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.
l The BAS interface is incorrectly configured.
l The link between the DHCP relay and the DHCP server or between the DHCP relay and
the client is faulty.


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.
l Check the link connectivity between the DHCP relay and the DHCP server or between the
DHCP relay and the client.

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 No Bind the correct domain

Is fault rectified?
to a correct domain? to the interface
Yes
Yes No
No
Is the domain bound to a Bind a correct IP address
Is fault rectified?
correct IP address pool? pool to the domain
Yes
Yes
No
Rectify the fault

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

Is the BAS interface No according to the specific
Is fault rectified?
correctly configured? troubleshooting
procedure Yes
No
Yes
Is the link between the

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

according to the user
Are other devices correctly Is fault rectified?
manual for the specific
configured?
device Yes
No
Yes


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

Procedure
Check whether the IP Position Remote If the field is

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


Procedure

undo lock command
to unlock the IP
address pool.
Check whether the IP 1. Run the display Correct DHCP server l If the DHCP
address pool is ip pool name name and address server group is
configured with an pool-name incorrectly
correct DHCP server command to view configured for the
address. the DHCP-Group IP address pool,
field. configure it
2. Then, run the correctly by
display dhcp- running the
server group dhcp-server
group-name group group-
command to view name command.
the Primary- l If the DHCP
Server and server address is
Secondary- incorrectly
Server fields. configured for the
IP address pool,
configure it
correctly by
running the
dhcp-server ip-
address
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).

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

Figure 2-5 Typical networking where the NE80E/40E functions as a local DHCPv6 server
3002:3101::2:2 129.6.55.55

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

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 No Check the physical Yes

connection between the connection between the Is fault recified?
client and the server work client and the server
normally?
No
Yes
No Yes
Is the configuration of the Check the configuration
interface correct? of the interface Is fault recified?
No
Yes
Is a prefix pool No Configure a prefix Yes

configured and is a prefix address and configure a
Is fault recified?
address configured for the prefix address for the
pool? pool
No
Yes
Is an address pool Configure an address Yes

No
configured and are some pool and bind some
Is fault recified?
addresses bound to this addresses to the address
address pool? pool
Yes No
No Yes
Is the IPv6 address pool Bind the IPv6 address
Is fault recified?
bound to the user domain? pool to the user domain
No
Yes
Is the server enabled No Enable IPv6 on the Yes

with IPv6 and is a server server and set a DUID Is fault recified?
DUID set? for the server
No
Yes
Does the address pool No Configure a new address Yes

have an available address pool, prefix pool, and Is fault recified?
to be allocated to the prefix addressed
client?
No
Yes
Seek technical
End
support

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.

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 A client is a Layer 2 access user.

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

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 C h e ck th e co n n e ctio n
co n n e ctio n b e tw e e n th e No Yes
b e tw e e n th e re q u e stin g
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 Is fa u lt re cifie d ?
ro u te r a n d d e le g a tin g
w o rk
N o rm a lly? ro u te r
No
Yes
See “ PPPoE
No T ro u b le sh o o tin g ” o r“ IP Yes
Is th e clie n t a L a ye r 2
a cce ss u se r? o E T ro u b le sh o o tin g ” to Is fa u lt re cifie d ?
so lve th e a cce ss
p ro b le m
No
Yes
No Yes
Is th e co n fig u ra tio n o f th e C h e ck th e co n fig u ra tio n
in te rfa ce co rre ct? o f th e in te rfa ce Is fa u lt re cifie d ?
No
Yes
Is a p re fix p o o l C o n fig u re a p re fix

No Yes
C o n fig u re d a n d is a p re fix a d d re ss a n d co n fig u re a
Is fa u lt re cifie d ?
a d d re ss co n fig u re d fo r th e p re fix a d d re ss fo r th e
p o o l? pool
No
Yes
Is a n a d d re s s p o o l C o n fig u re a n a d d re ss
No p o o l a n d b in d so m e Yes
c o n fig u re d a n d a re s o m e Is fa u lt re cifie d ?
a d d re s s e s b o u n d to th is a d d re sse s to th e a d d re ss
A d d re s s p o o l? pool
No
Yes
Is th e IP v6 a d d re ss p o o l No B in d th e IP v6 a d d re ss Yes
Is fa u lt re cifie d ?
b o u n d to th e u se r d o m a in ? p o o l to th e u se r d o m a in
No
Yes
Is th e se rve r e n a b le d No E n a b le IP v6 o n th e Yes
W ith IP v6 a n d is a se rve r se rve r a n d se t a D U ID Is fa u lt re cifie d ?
D U ID se t? fo r th e se rve r
No
Yes
D o e s th e a d d re ss p o o l No C o n fig u re a n e w a d d re ss Yes
h a ve a n a va ila b le a d d re ss p o o l, p re fix p o o l, a n d Is fa u lt re cifie d ?
to b e a llo ca te d to th e p re fix a d d re sse d
C lie n t?
No
Yes
S e e k te ch n ica l
su p p o rt End

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

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.

Figure 2-9 Typical networking where the NE80E/40E functions as a DHCPv6 relay agent
3002:3101::2:2 129.6.55.55
GE1/0/1 GE1/0/2 GE1/0/1 GE1/0/2

Internet
user@isp1 Router B Router A
l The Router B functions as a DHCPv6 relay agent.

l The Router A is connected to the RADIUS server to implement authentication and
l 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.

local DHCPv6 server
A client cannot obtain an IPv6
address
Does
the physical
connection between the client No Check the physical
Yes
and the DHCPv6 relay agent connection between Is fault
and the connection between the the client and the rectified?
DHCPv6 relay agent and server
the DHCPv6 server
work normally?
Yes No
Is the
No Check the Yes
configuration of the Is fault
inbound/outbound Interface of configuration of the
rectified?
the DHCPv6 relay agent interface
correct?
Yes No
Can the No Check statistics of

Yes
inbound interface receive received online Is fault
online request packets from request packets on rectified?
the client? the inbound interface
No
Yes
Can the No Check statistics of Yes

Is fault
outbound Interface forward forwarded packets on
rectified?
packets normally? the outbound interface
Yes No
No Yes
Does other Is fault
Check other devices
devices work normally? rectified?
Yes No

End

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.

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.
Step 5 Check whether the number of access users exceeds the maximum number allowed by the
DHCPv6 relay agent.
Run the display dhcpv6 relay userinfo table [ { interface interface-type interface-number
[.subinterface-number ] [ pevlan pevlan-id [ end-pevlan-id ] [ cevlan cevlan-id [ end-cevlan-
id ] ] ] | slot slot-id [ card card-id ] } | mac-address mac-address | index index | client-duid
client-duid | server-duid server-duid | server-address ipv6-address [ vpn-instance vpn-
instance-name ] | client-address ipv6-address [ vpn-instance vpn-instance-name ] ]
[ statistics ] command in the system view to check whether the number of access users exceeds
the maximum number allowed by the DHCPv6 relay agent.
l If the number of access users exceeds the maximum number allowed by the DHCPv6 relay
agent, log out some users based on the situations on the live network.
l If the number of access users does not exceed the maximum number allowed by the DHCPv6
relay agent, go to Step 6.
Step 6 Check the reason why the user entry is deleted.
Run the display dhcpv6 relay client-info [ interface interface-type interface-number

[.subinterface-number ] [ pevlan pevlan-id [ end-pevlan-id ] [ cevlan cevlan-id [ end-cevlan-
id ] ] ] | mac-address mac-address | client-duid client-duid ] command in the system view.
l If the DHCPv6 server allocates conflicted IPv6 addresses or prefixes or responds with a
Reply packet whose lifetime is 0 or status is not Success, rectify any faults on the DHCPv6
server.
l If the client does not receive a Reply packet from the DHCPv6 server within the timeout
period, rectify any faults on the DHCPv6 server.
l If the DHCPv6 relay agent does not receive a packet from the client within the timeout period,
rectify any faults on the client.
----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-IPv6-
Pool 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.
l 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.
l 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.
l Check that the address pool type matches the pool ID delivered by the RADIUS server.
l Check that no prefixes are available in the prefix pool.
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 Delegated-
IPv6-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
Relevant Alarms
None.
Relevant Logs
None.

Troubleshooting - User Access 3 RADIUS Troubleshooting
3 RADIUS Troubleshooting
About This Chapter
3.1 The Dynamic ACL Delivered by the RADIUS Server Does Not Take Effect
procedure for the fault that the dynamic ACL delivered by the RADIUS server does not take
effect.

3.1 The Dynamic ACL Delivered by the RADIUS Server

Does Not Take Effect
procedure for the fault that the dynamic ACL delivered by the RADIUS server does not take
effect.
3.1.1 Common Causes

l The HW-Data-Filter attribute is not configured on the RADIUS server.
l The RADIUS server is not configured to dynamically deliver ACLs on the device.
l The resource for dynamic traffic classifier-behavior pairs is insufficient.
l The resource for rules is insufficient on the device.
l Rules are incorrectly delivered.

l Check whether the RADIUS server configuration on the NE80E/40E is correct.
l Check whether the HW-Data-Filter attribute is configured on the RADIUS server.
l Check whether the RADIUS server is configured to dynamically deliver ACLs on the
NE80E/40E.
l Check whether the number of traffic classifier-behavior pairs dynamically delivered by the
RADIUS server exceeds the specification supported by the NE80E/40E.
l Check whether the number of rules exceeds the specification supported by the NE80E/
40E.
l Check whether rules are correctly delivered.

Figure 3-1 Troubleshooting flowchart for the fault that the ACL delivered by the RADIUS
server does not take effect
ACL delivered by
the RADIUS
server does not
take effect
Is RADIUS No Yes
Reconfigure the Is the fault
configuration
RADIUS server rectified?
correct?
No
Yes
Is RADIUS No Configure the HW-

Is the fault Yes
configured with HW- Data-Filter attribute on
rectified?
Data-Filter? the RADIUS server
No
Yes
Configure the
Can RADIUS No RADIUS server to Is the fault Yes
dynamically deliver dynamically deliver rectified?
ACLs? ACLs
No
Yes
Does the pair Reclaim the idle traffic

No Is the fault Yes
number exceed the classifier-behavior
rectified?
specification? pairs
No
Yes
Does the rule No Release some rule Is the fault Yes

number exceed the resources rectified?
specification?
No
Yes
No Deliver the correct Is the fault Yes

Are rules correct? rules rectified?
No
Yes
Contact Huawei
personnel

Context
NOTE
Procedure
Step 1 Check that the RADIUS server configuration on the NE80E/40E is correct.
Run the test-aaa user-name password radius-group group-name command to check whether
the RADIUS server works properly.
l If the RADIUS server does not work properly, reconfigure the RADIUS server based on the
guide. For configuration details, see Configuring the RADIUS Server.
l If the RADIUS server works properly, go to step 2.
Step 2 Check that the HW-Data-Filter attribute is configured on the RADIUS server.
The RADIUS server can dynamically deliver ACLs only after the HW-Data-Filter attribute is
configured on the RADIUS server.
l If the HW-Data-Filter attribute is not configured on the RADIUS server, configure the HW-
Data-Filter attribute on the RADIUS server.
l If the HW-Data-Filter attribute is configured on the RADIUS server, go to step 3.
Step 3 Check that the RADIUS server is configured to dynamically deliver ACLs on the NE80E/40E.
Run the display this command in the system view to check whether the remote-download acl
enable command is configured.
NOTE
If the traffic classifier carried in the HW-Data-Filter attribute contains the name of a user group that does
not exist on the NE80E/40E, enable the RADIUS server to dynamically create user groups.
l If the RADIUS server is not configured to dynamically deliver ACLs on the NE80E/40E,
run the remote-download acl enable command in the AAA view to enable the RADIUS
server to dynamically deliver ACLs. To enable the RADIUS server to dynamically create
user groups, run the remote-download user-group enable command in the AAA view.
l If the RADIUS server is configured to dynamically deliver ACLs on the NE80E/40E, go to
step 4.
Step 4 Check that the number of traffic classifier-behavior pairs dynamically delivered by the RADIUS
server does not exceed the specification supported by the NE80E/40E.
Run the display aaa remote-download acl item command to check whether the number of
traffic classifier-behavior pairs delivered by the RADIUS server exceeds the specification
supported by the NE80E/40E, or run the display alarm active command to check whether a
hwRemoteDownloadAclThresholdAlarm alarm is generated.
NOTE
The NE80E/40E supports a maximum number of 1024 traffic classifier-behavior pairs. If the number of
traffic classifier-behavior pairs delivered by the RADIUS server exceeds 1024, subsequent pairs fail to be
delivered.

l If the number of traffic classifier-behavior pairs delivered by the RADIUS server exceeds
1024, run the recycle remote-download acl classifier command to reclaim the idle
classifier-behavior pairs.
l If the number of traffic classifier-behavior pairs delivered by the RADIUS server does not
exceed 1024, go to step 5.
Step 5 Check that the number of rules does not exceed the specification supported by the NE80E/
40E.
Check whether a hwXQoSRuleFaileAlarm alarm is generated on the NMS.
NOTE
A traffic classifier-behavior pair can contain multiple rules. If the number of rules, including those carried
in the dynamically delivered traffic classifier-behavior pairs and those configured using commands,
exceeds the specification supported by the NE80E/40E, subsequent rules cannot take effect.
l If a hwXQoSRuleFaileAlarm alarm is generated, reclaim some rules.
l If a hwXQoSRuleFaileAlarm alarm is not generated, go to step 6.
Step 6 Check that rules are correctly delivered in the traffic classifier-behavior pairs.
Run the display aaa remote-download acl item verbose command to check detailed
information about traffic classifier-behavior pairs and determine whether rules are correctly
delivered.
l If no rules are delivered or rules are incorrectly delivered, configure the RADIUS server to
deliver correct rules in the HW-Data-Filter attribute of the RADIUS Access-Accept packets
or CoA packets.
l If rules are correct, go to step 7.
l Results of the troubleshooting procedure
l Configuration files, log files, and alarm files from the devices
l Debugging information about the devices
----End
Relevant Alarms
AAA_1.3.6.1.4.1.2011.5.2.2.2.0.29 hwRemoteDownloadAclThresholdAlarm
NE5KQOS_1.3.6.1.4.1.2011.5.25.32.4.1.11.11 hwXQoSRuleFaileAlarm
Relevant Logs
None

Troubleshooting - User Access 4 Hybrid Access Troubleshooting
4 Hybrid Access Troubleshooting
About This Chapter
NOTE
Hybrid Access enables two GRE tunnels to be bundled on the HG and Hybrid Access device. One is the
priority tunnel, and the other is the overflow tunnel. Unless otherwise specified in this chapter, a DSL
tunnel is used as the priority tunnel, and an LTE tunnel is used as the overflow tunnel.
4.1 An Overflow Tunnel Fails to Be Established
4.2 A Prior Tunnel Fails to Be Established
4.3 SOAP Fails
4.4 Hybrid Access Users Fail to Go Online
4.5 Hybrid Access Users Fail to Obtain IPv4 Addresses
4.6 Hybrid Access Users Fail to Obtain IPv6 PD Prefixes
4.7 FTP Upload and Download Fail for IPv6 Users
4.8 The Upstream Bonding Bandwidth Is Far Lower Than the Sum of LTE and DSL Link
Bandwidth

4.1 An Overflow Tunnel Fails to Be Established
4.1.1 Common Causes

l Hybrid Access is not configured on the tunnel interface.
l The protocol status of the tunnel interface is not Up.
l The destination IP address carried in the request packet is not a T2 address.
l The AVPs carried in the request packet are incorrect.
l The same tunnel has existed.
l The client identification name (CIN) is not in the allowed list (CINs in the list can be
configured using the cin filter command).
l The authentication fails.
l The authentication expires and no authentication response is received.
l A T3 address is not used for overflow tunnel reestablishment, and no session ID is carried.
NOTE
T2 address: IP address of a Hybrid Access, which is used as the destination IP address carried in a tunnel
establishment request initiated by an HG. Each Hybrid Access pool uses the same address.
AVP: information that is carried in a request packet and is used to establish a tunnel.

l Check whether Hybrid Access is correctly configured.
l Check whether the protocol status of the tunnel interface is Up.
l Check whether the same tunnel exists.
l Check whether the overflow tunnel is reestablished.
l Run the debugging tunnel all command to check whether the destination IP address and
AVPs carried in the request packet are correct.
l Run the debugging tunnel all command to check whether the CIN is in the allowed list.
l Check whether the authentication configuration is correct.

Figure 4-1 Troubleshooting flowchart for the failure to establish an overflow tunnel
An overflow tunnel fails to

be established.
No Configure hybrid access Yes

Is hybrid access Is the fault
correctly according to the
configured correctly? rectified?
configuration guide.
No
Yes
Configure the source
No Yes
Is the tunnel interface interface of the tunnel Is the fault
Up? interface correctly according rectified?
to the configuration guide.
No
Yes
Does the same tunnel Yes

exist?
No
No
Is the destination IP
address the T2 address?
Yes
Is the tunnel
reestablished? Is the T3 No
address used? Is the
session ID carried?
Yes
Are the AVPs No

carried in the request
packet correct?
Yes
Is the CIN No
Carried in the allowed
list?
Yes
No Perform correct Yes

Is the authentication Is the fault
configurations according to
successful? rectified?
the configuration guide.
Yes No
Contact Huawei technical

End
support personnel.

Context
NOTE
Procedure
Step 1 Check that Hybrid Access is correctly configured.
Run the display this command in the tunnel interface view to check whether Hybrid Access is
l If Hybrid Access is not correctly configured, configure Hybrid Access correctly according
to the configuration guide.
l If Hybrid Access is correctly configured, go to Step 2.
Step 2 Check that the protocol status of the tunnel interface is Up.
Run the display this interface or display this ipv6 interface command in the tunnel interface
view to check whether the IPv4 or IPv6 status of the tunnel interface is Up.
l If the IPv4 or IPv6 status of the tunnel interface is Up, go to Step 3.
l If the IPv4 or IPv6 status of the tunnel interface is not Up, check whether the source interface
of the tunnel interface is correctly configured. If the source interface of the tunnel interface
is not correctly configured, configure the source interface of the tunnel interface correctly
according to the configuration guide.
Step 3 Check that the same entry does not exist.
Run the debug tunnel all command to enable tunnel debugging and obtain the source IP address
of the request packet. Run the display hybrid-access tunnel all | include X.X.X.X command to
check whether the same entry exists.
l If the same entry exists, an overflow tunnel has been established.

l If the same entry does not exist, go to Step 4.
Step 4 Check that the overflow tunnel is not reestablished.
Run the debug tunnel all command to enable tunnel debugging and obtain the destination IP
address of the request packet. Check whether the destination IP address of the request packet is
the T2 or T3 address.
l If the destination IP address of the request packet is the T2 address, the overflow tunnel is
not reestablished. Go to Step 5.
l If the destination IP address of the request packet is the T3 address, the overflow tunnel is
reestablished. Check whether the debugging information contains the session ID. If the
debugging information contains the session ID and the display hybrid-access user-info
user-id user-id command output shows that a prior tunnel exists, the session ID is correct.
Go to Step 5.
l If the destination IP address of the request packet is neither the T2 nor T3 address, the
destination IP address of the request packet is incorrect and the request packet is discarded.

NOTE
The value of user-id in the display hybrid-access user-info user-id user-id command is the session ID in
the debugging information.
For details about how to configure T2 and T3 addresses, see Configuring T2 and T3 Addresses in HUAWEI
NetEngine80E/40E Router Configuration Guide - User Access.
Step 5 Check that the AVPs carried in the request packet are correct.
Run the debug tunnel all command to enable tunnel debugging and obtain the AVPs carried in
the request packet.
l If the CIN and IPv6 prefix carried in the request packet are correct, go to Step 6.
l If the CIN and IPv6 prefix carried in the request packet are incorrect, this is not a fault. The
request packet is discarded.
Step 6 Check that the CIN is in the allowed list.
Run the debug tunnel all command to enable tunnel debugging and obtain the CIN carried in
the request packet.
l If the CIN is in the allowed list, go to Step 7.
l If the CIN is not in the allowed list, this is not a fault. The request packet is discarded.
Step 7 Check that the HASM configuration is correct.
For troubleshooting details, see 4.4 Hybrid Access Users Fail to Go Online. If the fault persists,
go to Step 8.
Step 8 Collect the following information and contact Huawei technical support personnel:
l Configuration, log, and alarm files of the devices
l Device debugging information
----End
Relevant Alarms
None
Relevant Logs
None
4.2 A Prior Tunnel Fails to Be Established
4.2.1 Common Causes


l Hybrid Access is not configured on the tunnel interface.

l The protocol status of the tunnel interface is not Up.
l The destination IP address carried in the request packet is not a T3 address.
l The AVPs carried in the request packet are incorrect.
l The same tunnel has existed.
l The corresponding overflow tunnel does not exist.
l The authentication fails.
l The authentication expires and no authentication response is received.
NOTE
T3 address: source IP address used for a Hybrid Access to establish a GRE tunnel.

l Check whether Hybrid Access is correctly configured.
l Check whether the protocol status of the tunnel interface is Up.
l Check whether the same tunnel exists.
l Check whether the corresponding overflow tunnel exists.
l Obtain the packet header or run the debugging tunnel all command to check whether the
destination IP address and AVPs carried in the request packet are correct.
l Check whether the authentication configuration is correct.

Figure 4-2 Troubleshooting flowchart for the failure to establish a priority tunnel
A prior tunnel fails to be

established.
No Configure hybrid access Yes

Is hybrid access Is the fault
correctly according to the
configured correctly? rectified?
configuration guide.
No
Yes
Configure the source interface
No Yes
Is the tunnel interface of the tunnel interface correctly Is the fault
Up? according to the configuration rectified?
guide.
No
Yes
Does the same tunnel Yes

exist?
No
Is the No
destination IP address
the T3 address?
Yes
Is the Session No
ID carried in the request
packet?
Yes
Does the No
corresponding overflow
tunnel exist?
Yes
Are the AVPs No

carried in the request
packet correct?
Yes
No Perform correct configurations Yes

Is the authentication Is the fault
according to the configuration
successful? rectified?
guide.
No
Yes

End
support personnel.

Context
NOTE
Procedure
Step 1 Check that Hybrid Access is correctly configured.
Run the display this command in the tunnel interface view to check whether Hybrid Access is
l If Hybrid Access is not correctly configured, configure hybrid access correctly according to
the configuration guide.
l If Hybrid Access is correctly configured, go to Step 2.
Step 2 Check that the protocol status of the tunnel interface is Up.
Run the display this interface or display this ipv6 interface command in the tunnel interface
view to check whether the IPv4 or IPv6 status of the tunnel interface is Up.
l If the IPv4 or IPv6 status of the tunnel interface is Up, the protocol status of the tunnel
interface is correct, go to Step 3.
l If the IPv4 or IPv6 status of the tunnel interface is not Up, check whether the source interface
of the tunnel interface is correctly configured.
– If the source interface of the tunnel interface is not correctly configured, configure the
source interface of the tunnel interface correctly according to the configuration guide.
– If the source interface of the tunnel interface is correctly configured, go to Step 3.
Step 3 Check that the same entry does not exist.
Run the debug tunnel all command to enable tunnel debugging and obtain the source IP address
of the request packet. Run the display hybrid-access tunnel all | include X.X.X.X command to
check whether the same entry exists.
l If the same entry exists, a prior tunnel has been established.

l If the same entry does not exist, go to Step 4.
Step 4 Check that the destination IP address of the request packet is the T3 address.
Run the debug tunnel all command to enable tunnel debugging and obtain the destination IP
address of the request packet. Check whether the destination IP address of the request packet is
the T3 address.
l If the destination IP address of the request packet is the T3 address, go to Step 5.

l If the destination IP address of the request packet is not the T3 address, the request packet is
incorrect.
NOTE
For details about how to configure a T3 address, see Configuring T2 and T3 Addresses in HUAWEI
NetEngine80E/40E Router Configuration Guide - User Access.
Step 5 Check that the request packet contains the session ID.

the request packet. Check whether the session ID exists.
l If the session ID exists, go to Step 6.

l If the session ID does not exist, the request packet is incorrect.
Step 6 Check that the corresponding overflow tunnel exists.
Run the debug tunnel all command to enable tunnel debugging and obtain the session ID carried
in the request packet. Run the display hybrid-access user-info user-id user-id command to
check whether the corresponding overflow tunnel exists.
NOTE
The value of user-id in the display hybrid-access user-info user-id user-id command is the session ID in
the debugging information.
l If the corresponding overflow tunnel does not exist, establish an overflow tunnel first.
l If the corresponding overflow tunnel exists, go to Step 5.
Step 7 Check that the AVPs carried in the request packet are correct.
the request packet.
l If the session ID and IPv6 prefix carried in the request packet are correct, go to Step 6.
l If the session ID and IPv6 prefix carried in the request packet are incorrect, this is not a fault.
The request packet is discarded.
Step 8 Check that the HASM configuration is correct.
For troubleshooting details, see 4.4 Hybrid Access Users Fail to Go Online. If the fault persists,
go to Step 7.
----End
Relevant Alarms
None
Relevant Logs
None
4.3 SOAP Fails

4.3.1 Common Causes

l A SOAP server group is not correctly configured in a domain.
l The SOAP authentication fails.
l The SOAP authorization fails.
l The SOAP service expires.

l Check whether the SOAP server group is correctly configured in a domain.
l Check whether the SOAP server group is correctly configured in the SOAP view.
l Check the cause of the authentication or authorization failure.

Figure 4-3 Troubleshooting flowchart for the SOAP failure
The SOAP authentication

or authorization fails.
No Perform correct configurations Yes

Are the configurations in Is the fault
according to the configuration
the domain correct? rectified?
guide.
Yes No
Is the SOAP No Configure the SOAP server Yes

Is the fault
server group configured group correctly according to
rectified?
correctly? the configuration guide.
Yes No
Check the cause of the

authentication or authorization
failure.
Does SOAP
No The SOAP service is working Yes
messages fail to be sent Is the fault
properly. Analyze the failure for
or parsed? Does SOAP rectified?
a specific cause description.
responses expire?
No
Yes
No Ensure that the link works Is the fault Yes

Is the link normal? properly. rectified?
No
Yes
Are the service No Yes

Start the SOAP service and Is the fault
and port on the SOAP
enable the port. rectified?
server normal?
Yes No
Can SOAP No Ensure that the WSDL files on Yes

Is the fault
messages be sent or the device and SOAP server
rectified?
received correctly? are correct.
Yes No
Contact Huawei technical End

support personnel.

Context
NOTE
Procedure
Step 1 Check that the SOAP server group is correctly configured in a domain.
Run the display this command in the AAA domain view to check whether the SOAP server
group is correctly configured.
l If the SOAP server group is not correctly configured, configure the SOAP server group
correctly according to the configuration guide.
l If the SOAP server group is correctly configured, go to Step 2.
Step 2 Check that the SOAP server group is correctly configured in the SOAP view.
Run the display this command in the SOAP view to check whether the SOAP server group is
l If the SOAP server group is not correctly configured, configure the SOAP server group
correctly according to the configuration guide.
l If the SOAP server group is correctly configured, go to Step 3.
Step 3 Check the cause of the authentication or authorization failure.
Run the display hybrid-access online-fail-record command to check the cause of the
authentication or authorization failure.
l If the cause is that the authentication or authorization message fails to be sent or parsed or
that the timer for waiting for a response from the SOAP server expires, go to Step 4.
l If the cause is others, the SOAP service is working properly. Analyze the failure for a specific
cause description.
Step 4 Check that the device communicates properly with the SOAP server.
Run the ping command to check whether the device communicates properly with the SOAP
server.
l If the device does not communicate properly with the SOAP server, run the display
interface command to check whether the interface connected to the SOAP server is Up. If
the interface connected to the SOAP server is Up, check whether the SOAP service on the
SOAP server is working and whether the SOAP service listening port is enabled.
l If the fault persists, go to Step 5.
Step 5 Check that the interaction messages are correct.
Obtain the packet headers and check whether the SOAP request message received by the SOAP
server and its sent response messages are correct.

l If these messages are incorrect, check whether the WSDL file on the device or SOAP server
is correct.
– If the WSDL file is incorrect, ensure that the WSDL file is correct.
– If the WSDL file is correct, go to Step 6.
l If these messages are correct, go to Step 6.
----End
Relevant Alarms
HASM_1.3.6.1.4.1.2011.5.25.324.2.2.0.5 hwHAAPSOAPServerTimeout
Relevant Logs
None
4.4 Hybrid Access Users Fail to Go Online
4.4.1 Common Causes

l No T2 address is configured.
l The service board's type is not set to hybrid-access.
l The domain to which Hybrid Access users belong is not configured.
l The authentication or authorization mode in the domain is not correctly configured.
l No SOAP server group or SOAP server address is configured during SOAP authentication
and authorization.
l No SOAP server group is bound to the domain during SOAP authentication and
authorization.
l The route to the authentication or authorization server is unreachable.

l Check whether the T2 address has been configured.

l Check whether the service board's type is set to hybrid access.

l Check whether the hybrid-access-service enable command is configured in the domain
to which Hybrid Access users belong.
l Check whether the authentication and authorization modes configured in the domain to
which Hybrid Access users belong are correct.
l Check whether the SOAP authentication and authorization server addresses and SOAP
server group are configured during SOAP authentication and authorization.
l Check whether the SOAP server group is bound to the domain during SOAP authentication
and authorization.
l Check whether the SOAP authentication and authorization servers are routable.

Figure 4-4 Troubleshooting flowchart for hybrid access users' failure to go online
Hybrid access users fail

to go online.
Configure hybrid-access-
Is the T2 address No Is the fault Yes
service enable and the IP
configured? address on the loopback rectified?
interface.
Yes No
No Set the service board's type to Yes

Is the service board's Is the fault
hybrid-access in the user
type set to hybrid- rectified?
view.
access ?
No
Yes
Is
No Is the fault Yes
hybrid-access-service Configure hybrid-access-
enable configured in the service enable in the domain. rectified?
domain?
No
Yes
Are the
authentication and No Yes
Configure none or soap in the Is the fault
authorization modes domain. rectified?
configured correctly in
the domain?
No
Yes
Are the Configure the SOAP

SOAP server addresses No authentication and Is the fault Yes
and SOAP server group authorization server addresses rectified?
configured? and SOAP server group.
No
Yes
No Yes
Is the SOAP server group Bind the SOAP server group to Is the fault
bound to the domain? the domain. rectified?
No
Yes
Are the SOAP Ensure that the SOAP

authentication and No authentication and Is the fault Yes
authorization servers authorization servers can be rectified?
routable? pinged.
Yes No
Contact Huawei technical End

support personnel.

Context
NOTE
Procedure
Step 1 Check that the T2 address has been configured.
Run the display this command on the loopback interface to check whether hybrid-access-
service enable and the IPv4/IPv6 address are configured.
l If hybrid-access-service enable and the IP address are not configured, configure them.
l If hybrid-access-service enable and the IPv4/IPv6 address are configured, go to Step 2.
Step 2 Check that the service board's type is set to hybrid-access.
Run the display board-type slot command in the user view to check whether the service board's
type is set to hybrid-access.
l If the service board's type is not set to hybrid-access, run the set board-type slot slot-id
hybrid-access command in the user view.
l If the service board's type is set to hybrid-access, go to Step 3.
Step 3 Check whether the hybrid-access-service enable command is configured in the domain to
which Hybrid Access users belong.
Run the display this command in the AAA view to check whether hybrid-access-service
enable is configured in the domain.
l If hybrid-access-service enable is not configured in the domain, configure it.

l If hybrid-access-service enable is configured in the domain, go to Step 4.
Step 4 Check that the authentication and authorization modes configured in the domain to which Hybrid
Access users belong are correct.
The authentication and authorization modes for Hybrid Access users are classified as non-
authentication or SOAP authentication and authorization.
Run the display this command in the view of the domain to which Hybrid Access users belong
to obtain the bound authentication and authorization templates. Then run the display this
command in the authentication and authorization template views to check whether the
authentication and authorization modes are none or soap and whether they are consistent.
l If the authentication and authorization modes are not none or soap, configure
authentication-mode { soap | none } in the authentication template and authorization-
mode { soap | none } in the authorization template.
l If the authentication and authorization modes are none or soap and they are consistent, go
to Step 5.
Step 5 Check that the SOAP authentication and authorization server addresses and SOAP server group
are configured during SOAP authentication and authorization.
Run the display soap-instance all command in the system view to check whether the SOAP
authentication and authorization server address instances are configured. Run the display

current-configuration | include soap-server command to check whether soap-server group

is configured. Then run the display this command in the SOAP server group view to check
whether the SOAP authentication and authorization server instances are configured.
l If the SOAP authentication and authorization server address instances are not configured,
run the soap-instance instance-name tcp-domain local-site ip-address tcp-port port-id
target-host address ip-address tcp-port port-id command in the SOAP server group view
to configure them. Run the soap-server group group-name command to create a SOAP
server group, and then run the soap-server authentication instance soap-instance-name
and soap-server authorization instance soap-instance-name commands in the SOAP server
group view to specify the SOAP authentication and authorization server instances.
l If the SOAP authentication and authorization server instances are configured, go to Step 6.
Step 6 Check that the SOAP server group is bound to the domain during SOAP authentication and
authorization.
to check whether soap-server group group-name is configured.
l If soap-server group group-name is not configured, configure it in the domain.

l If soap-server group group-name is configured, go to Step 7.
Step 7 Check that the SOAP authentication and authorization servers are routable.
In the user view, check whether the SOAP authentication and authorization servers can be
pinged.
l If the SOAP authentication and authorization servers cannot be pinged, check whether the
server addresses are correctly configured, whether the servers are working properly, and
whether the routes to the server addresses exist. If the next hop addresses to the servers are
not configured, configure them.
l If the SOAP authentication and authorization servers can be pinged, go to Step 8.
----End
Relevant Alarms
HASM_1.3.6.1.4.1.2011.5.25.324.2.2.0.5 hwHAAPSOAPServerTimeout
HASM_1.3.6.1.4.1.2011.5.25.324.2.2.0.6 hwHAAPOnlineFailAlarm
HASM_1.3.6.1.4.1.2011.5.25.324.2.2.0.11 hwHAAPServerRejectAlarm
Relevant Logs
None

4.5 Hybrid Access Users Fail to Obtain IPv4 Addresses
4.5.1 Common Causes

l An IPv4 address pool is not configured or incorrectly configured.
l No IPv4 address pool is bound to the domain to which Hybrid Access users belong.
l All addresses in the address pool bound to the domain have been assigned.
l Hybrid Access users fail to go online.

l Check whether the IPv4 bas local address pool is configured and whether the gateway and
section are configured in the address pool.
l Check whether the IPv4 bas local address pool is bound to the domain to which Hybrid
Access users belong.
l Check whether all addresses in the address pool bound to the domain have been assigned.
l Check whether Hybrid Access users fail to go online.

Figure 4-5 Troubleshooting flowchart for Hybrid Access users' failure to obtain IPv4 addresses

to obtain IPv4 addresses.
Configure the IPv4 bas local

Is the IPv4 bas local No Is the fault Yes
address pool and configure the
address pool configured? gateway and section in the rectified?
address pool.
Yes No
Is the IPv4 bas local No Yes

Bind the IPv4 bas local Is the fault
address pool bound to
address pool to the domain. rectified?
the domain?
No
Yes
Are there idle addresses No Add an IPv4 bas local address Is the fault Yes
in the address pool? pool and bind it to the domain. rectified?
No
Yes
No Yes
Do hybrid access users Ensure that hybrid access Is the fault
successfully go online? users successfully go online. rectified?
No
Yes

support personnel. End
Context
NOTE
Procedure
Step 1 Check that the IPv4 bas local address pool is configured and that the gateway and section are
configured in the address pool.
Run the display ip pool command in the system view to check whether the IPv4 bas local address
pool is configured. Then run the display ip pool name pool-name command to check whether
the gateway and section are configured in the address pool.

l If the IPv4 bas local address pool is not configured, run the ip pool pool-name bas local
command in the system view to configure it. Then run the gateway ip-address mask and
section section-id start-ip-address end-ip-address commands to configure the gateway and
section in the address pool.
l If the IPv4 bas local address pool is configured and the gateway and section are configured
in the address pool, go to Step 2.
Step 2 Check that the IPv4 bas local address pool is bound to the domain to which Hybrid Access users
belong.
to check whether ip-pool pool-name is configured.
l If ip-pool pool-name is not configured, run the ip-pool pool-name command to bind the IPv4
bas local address pool to the domain.
l If ip-pool pool-name is configured correctly, go to Step 3.
Step 3 Check that the hybrid-access-service enable command is configured in the domain to which
Hybrid Access users belong.
Run the display this command in the AAA view to check whether hybrid-access-service
enable is configured in the domain.
l If hybrid-access-service enable is not configured in the domain, configure it.

l If hybrid-access-service enable is configured, go to Step 4.
Step 4 Check that addresses in the address pool bound to the domain are not completely assigned.
Run the display ip pool name pool-name command in the system view to check whether the
number of idle addresses is 0.
l If the number of idle addresses is 0, create an IPv4 bas local address pool and bind it to the
domain (see Steps 1 and 2).
l If the number of idle addresses is not 0, go to step 5.
Step 5 Check that Hybrid Access users successfully go online.
Run the display hybrid-access user-info all command in the system view to check whether the
corresponding Hybrid Access users are online.
l If the corresponding Hybrid Access users are offline, rectify the fault according to 4.4 Hybrid
Access Users Fail to Go Online.
l If the corresponding Hybrid Access users are online, go to Step 6.
----End

Relevant Alarms
AM_1.3.6.1.4.1.2011.6.8.2.2.0.14 hwUsedIPExhaust
Relevant Logs
None
4.6 Hybrid Access Users Fail to Obtain IPv6 PD Prefixes
4.6.1 Common Causes

l No DHCPv6 DUID is configured.
l An IPv6 address pool is not configured or incorrectly configured.
l No IPv6 address pool is bound to the domain to which Hybrid Access users belong.
l All PD prefixes in the IPv6 address pool bound to the domain have been assigned.
l Hybrid Access users fail to go online.

l Check whether a DHCPv6 DUID is configured in the system view.
l Check whether the IPv6 bas delegation address pool is configured and whether the
delegation prefix pool with 56-bit prefixes is bound to the address pool.
l Check whether the IPv6 bas delegation address pool is bound to the domain to which Hybrid
l Check whether all PD prefixes in the IPv6 address pool bound to the domain have been
assigned.
l Check whether Hybrid Access users fail to go online.

Figure 4-6 Troubleshooting flowchart for Hybrid Access users' failure to obtain IPv6 PD
prefixes

to obtain IPv6 PD
prefixes.
Is the DHCPv6 DUID No Is the fault Yes

Configure the DHCPv6 DUID in
configured? the system view. rectified?
Yes No
Configure the IPv6 bas

Is the IPv6 bas No Yes
delegation address pool and bind Is the fault
delegation address pool
the delegation prefix pool with 56- rectified?
configured?
bit prefixes to the address pool.
No
Yes
Is the IPv6 bas No Yes

Bind the IPv6 bas delegation Is the fault
delegation address pool
address pool to the domain. rectified?
bound to the domain?
No
Yes
No Add an IPv6 bas delegation Yes

Are there idle PD prefixes Is the fault
address pool and bind it to the
in the address pool? rectified?
domain.
No
Yes
Do hybrid access users No Ensure that hybrid access users Is the fault Yes
successfully go online? successfully go online. rectified?
No
Yes

End
support personnel.
Context
NOTE

Procedure
Step 1 Check that a DHCPv6 DUID is configured in the system view.
Run the display current-configuration | include duid command in the system view to check
whether a DHCPv6 DUID is configured.
l If a DHCPv6 DUID is not configured, run the dhcpv6 duid { llt | duid-value } command to
configure it.
l If a DHCPv6 DUID is configured, go to Step 2.
Step 2 Check that the IPv6 bas delegation address pool is configured and that the delegation prefix pool
with 56-bit prefixes is bound to the address pool.
Run the display ipv6 pool command in the system view to check whether the IPv6 bas delegation
address pool is configured. Run the display ipv6 pool pool-name command to check whether
the delegation prefix pool is bound to the address pool. Then run the display ipv6 prefix prefix-
name command to check whether the PD prefix length in the bound prefix pool is 56 bits.
l If the IPv6 bas delegation address pool and delegation prefix pool are not configured, perform
the following operations:
1. Run the ipv6 prefix prefix-name delegation command in the system view to create an
IPv6 prefix pool.
2. Run the prefix X:X::X:X/M delegating-prefix-length 56 command in the IPv6 prefix
pool view to configure an IPv6 address prefix.
3. Return to the system view and run the ipv6 pool pool-name bas delegation command
to create an IPv6 address pool.
4. Run the prefix prefix-name command in the IPv6 address pool view to bind the
configured prefix pool.
l If the IPv6 bas delegation address pool and delegation prefix pool are correctly configured,
go to Step 3.
Step 3 Check that the IPv6 bas delegation address pool is bound to the domain to which Hybrid
to check whether ipv6-pool pool-name is configured.
l If ipv6-pool pool-name is not configured, run the ipv6-pool pool-name command to bind
the IPv6 bas delegation address pool to the domain.
l If ipv6-pool pool-name is configured, go to Step 4.
Step 4 Check that PD prefixes in the IPv6 address pool bound to the domain are not completely assigned.
Run the display ipv6 prefix prefix-name command in the system view to check whether the
number of free prefixes is 0.
l If the number of free prefixes is 0, create an IPv6 bas delegation address pool and bind it to
the domain (see Steps 2 and 3).
l If the number of free prefixes is not 0, go to Step 5.
Step 5 Check that Hybrid Access users successfully go online.

Run the display hybrid-access user-info all command in the system view to check whether the
corresponding Hybrid Access users are online.
l If the corresponding Hybrid Access users are offline, rectify the fault according to 4.4 Hybrid
Access Users Fail to Go Online.
l If the corresponding Hybrid Access users are online, go to Step 6.
----End
Relevant Alarms
AM_1.3.6.1.4.1.2011.6.8.2.2.0.20 hwIPv6AddressExhaustAlarm
Relevant Logs
None
4.7 FTP Upload and Download Fail for IPv6 Users

This section describes how to troubleshoot FTP upload and download failures for IPv6 users on
the NE80E/40E.
4.7.1 Common Causes

l FTP ALG is not enabled.
l Other devices on the link are incorrectly configured.

l Check that FTP ALG is enabled in the Hybrid Access view.
l Check that other devices on the link are correctly configured.

Figure 4-7 Flowchart for troubleshooting FTP upload and download failures
FTP upload
and download
fail for IPv6
users.
Is NAT66 ALG Enable NAT66

No Is the fault
enabled for FTP ALG for FTP
rectified?
packets? packets.
No
Yes
Yes
Are the other Correctly
No Is the fault Yes
devices correctly configure the
rectified?
configured? other devices.
No
Yes
Contact End
Huawei.
Context
NOTE
Save the results of each troubleshooting step. If the fault persists after following this procedure, Huawei
will need these results for further troubleshooting.
Procedure
Step 1 Check that FTP ALG is enabled in the Hybrid Access view.
Run the display this command and check whether the nat66 alg ftp command configuration
exists in the hybrid-access view.
l If the nat66 alg ftp command configuration exists in the Hybrid Access view, FTP ALG is
enabled. Go to Step 2.
l If the nat66 alg ftp command configuration does not exist in the Hybrid Access view, run
the nat66 alg ftp command in the Hybrid Access view.

Step 2 Check that other devices on the link are correctly configured.
Check whether the configurations are correct based on the manuals of the related devices. If the
configurations are incorrect, modify the relevant configurations. If FTP upload and download
still fail for IPv6 users, go to Step 3.
Step 3 Contact Huawei and provide the following information:

l Results of this troubleshooting procedure
l Configuration, log, and alarm files
l Debugging files
----End
Relevant Alarms
None
Relevant Logs
None
4.8 The Upstream Bonding Bandwidth Is Far Lower Than

the Sum of LTE and DSL Link Bandwidth
NOTE
A fault occurs if the upstream bonding bandwidth is lower than or equal to 80% of the sum of LTE and
DSL link bandwidth.
4.8.1 Common Causes

l Packet ordering configurations for upstream traffic are incorrect.
l The LTE and DSL links significantly vary in packet delay, causing failures in packet
ordering for upstream traffic.
l The LTE link is unstable, causing severe packet loss.

l Check that the packet ordering configurations for upstream traffic on the Hybrid Access
are correct.
l Check the packet delay on the LTE and DSL links.
l Check that no severe packet loss occurs on the LTE link.

Figure 4-8 Flowchart for troubleshooting the problem that the upstream Bonding bandwidth is
far lower than the sum of LTE and DSL link bandwidth
Upstream Bonding
bandwidth is far
lower than the sum
of the LTE and DSL
link bandwidth.
Check whether the Yes Set the packet ordering Is the fault Yes
packet ordering cache cache time to a proper
rectified?
time is 0. value.
No No
Yes Check whether

packets are sent in a
correct order?
No
Check whether delay Yes Set the cache time to a Is the fault Yes
difference is higher than value higher than the
rectified?
the cache time? delay difference.
No
No
Check whether severe Yes Yes

Check the LTE link Is the fault
packet loss occurs? status. rectified?
No
No
Contact Huawei. End
Context
NOTE
Save the results of each troubleshooting step. If the fault persists after following this procedure, Huawei
will need these results for further troubleshooting.
Procedure
Step 1 Check that the packet ordering configurations for upstream traffic on the Hybrid Access are
correct.

Run the display this command in the hybrid-access view to check whether the keep-order
cache-time value is 0.
l If the keep-order cache-time value is 0, packet ordering configurations for upstream traffic
are incorrect. In this case, run the keep-order cache-time command in the hybrid-access
view to set a proper cache time.
l If the keep-order cache-time value is not 0, packet ordering configurations for upstream
traffic are correct. In this case, go to Step 2.
Step 2 Check that packets are sent in a correct order.
Run the display hybrid-access ordering-board statistics flow slot slot-id command to check
the Transmit GRE Data Packet Unorderly value of the packet ordering board.
l If the Transmit GRE Data Packet Unorderly value is quite small (the GRE Packet
Unorder Percentage value is lower than 10%), go to Step 4.
l If the Transmit GRE Data Packet Unorderly value is quite large (the GRE Packet
Unorder Percentage value is higher than 10%) and keeps increasing, go to Step 3.
Step 3 Check the packet delay on the LTE and DSL links.
Check the packet delay on the LTE and DSL links on the HG and compare the difference between
them with the configured packet ordering cache time.
l If the difference between LTE and DSL link delay is higher than the packet ordering cache
time, run the keep-order cache-time command in the hybrid-access view to set a packet
ordering cache time that is higher than the difference between LTE and DSL link delay.
l If the difference between LTE and DSL link delay is lower than the packet ordering cache
time, go to Step 4.
Step 4 Check that no severe packet loss occurs on the LTE link.
Run the display hybrid-access ordering-board statistics flow slot slot-id command to check
whether the GRE Packet Discard In Tunnel value rapidly increases.
l If the GRE Packet Discard In Tunnel value rapidly increases, the LTE link is unstable and
encounters severe packet loss. In this case, check the LTE link status.
l If the GRE Packet Discard In Tunnel value is normal (the GRE Packet Discard
Percentage value is lower than 10%), go to Step 5.
Step 5 Contact Huawei and provide the following information:

l Results of this troubleshooting procedure
l Configuration, log, and alarm files
l Debugging information
----End
Relevant Alarms
None

Relevant Logs
None


NE40E Troubleshooting PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

NE40E Troubleshooting PDF

Încărcat de

Drepturi de autor:

Formate disponibile

HUAWEI NetEngine80E/40E Router

Troubleshooting - User Access

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue 02 (2014-09-30) Huawei Proprietary and Confidential i

About This Document

Product Name Version

HUAWEI NetEngine80E/40E V600R008C10

Issue 02 (2014-09-30) Huawei Proprietary and Confidential ii

l Installation and commissioning engineer

Indicates an imminently hazardous situation which, if not

Indicates a potentially hazardous situation which, if not

Indicates a potentially hazardous situation which, if not

Indicates a potentially hazardous situation which, if not

Calls attention to important information, best practices and

Boldface The keywords of a command line are in boldface.

Italic Command arguments are in italics.

[] Items (keywords or arguments) in brackets [ ] are optional.

{ x | y | ... } Optional items are grouped in braces and separated by

Issue 02 (2014-09-30) Huawei Proprietary and Confidential iii

[ x | y | ... ] Optional items are grouped in brackets and separated by

{ x | y | ... }* Optional items are grouped in braces and separated by

[ x | y | ... ]* Optional items are grouped in brackets and separated by

# A line starting with the # sign is comments.

Changes in Issue 02 (2014-09-30)

Changes in Issue 01 (2014-06-30)

Issue 02 (2014-09-30) Huawei Proprietary and Confidential iv

About This Document.....................................................................................................................ii

Issue 02 (2014-09-30) Huawei Proprietary and Confidential v

1.2.28 CM with Framed IP address invalid........................................................................................................................10

Issue 02 (2014-09-30) Huawei Proprietary and Confidential vi

1.2.69 L2TP service is unavailable.....................................................................................................................................25

Issue 02 (2014-09-30) Huawei Proprietary and Confidential vii

1.2.110 Session timeout......................................................................................................................................................39

Issue 02 (2014-09-30) Huawei Proprietary and Confidential viii

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

Issue 02 (2014-09-30) Huawei Proprietary and Confidential ix

2.8.4 Relevant Alarms and Logs......................................................................................................................................162

4 Hybrid Access Troubleshooting.............................................................................................168

Issue 02 (2014-09-30) Huawei Proprietary and Confidential x

4.7.3 Troubleshooting Procedure......................................................................................................................................192

Issue 02 (2014-09-30) Huawei Proprietary and Confidential xi

1 User Fails to Get Online Troubleshooting

About This Chapter

1.1 Method of Troubleshooting User Logout

1.2 User Login and Logout Cause

Issue 02 (2014-09-30) Huawei Proprietary and Confidential 1

1.1 Method of Troubleshooting User Logout

1.1.1 Troubleshooting User Login and Logout Faults

Method of troubleshooting the fault that a user fails to get online

Method of Troubleshooting the Fault that a User Is Logged out Unexpectedly

1.2 User Login and Logout Cause

1.2.1 AAA access limit

Issue 02 (2014-09-30) Huawei Proprietary and Confidential 2

1.2.2 AAA cut command

1.2.3 AAA send authen request fail

1.2.4 AAA with Authentication no response

Issue 02 (2014-09-30) Huawei Proprietary and Confidential 3

1.2.5 AAA with authorization data error

1.2.6 AAA with flow limit

1.2.7 AAA with local bill pool no space

Issue 02 (2014-09-30) Huawei Proprietary and Confidential 4