- 产品与解决方案
- 行业解决方案
- 服务
- 支持
- 合作伙伴
- 关于我们
02-BRAS业务类故障处理指导
本章节下载： 02-BRAS业务类故障处理指导 (4.19 MB)
目 录
4.1.7 登录失败固定次数后，被禁止在指定的时间内再次登录
10.2.1 大量keepalive请求报文导致CPU占用率过高
11.2.1 AAA access limit under domain
11.2.2 AAA domain do not exist
11.2.3 AAA forces the PPPoEA user offline
11.2.4 AAA with Authentication no response
11.2.5 AAA with authorization data error
11.2.7 AAA with memory alloc fail
11.2.8 AAA with message send fail
11.2.9 AAA with radius decode fail
11.2.10 AAA with realtime accounting fail
11.2.11 AAA with start accounting fail
11.2.12 AAA with timer create fail
11.2.13 AAA with user information err
11.2.15 Add nat user data fail(IP Alloc Fail)
11.2.16 Add no backlist no Sub IfMaster
11.2.18 All prefix ranges in the DHCPv6 address pool group have been allocated
11.2.19 All prefix ranges in the DHCPv6 address pool have been allocated
11.2.20 All subnets in the DHCP address pool group have been allocated
11.2.21 All subnets in the DHCP address pool have been allocated
11.2.22 All subnets in the DHCPv6 address pool group have been allocated
11.2.23 All subnets in the DHCPv6 address pool have been allocated
11.2.26 Authentication method error
11.2.28 Base service address alloc failed
11.2.29 Cancelled PPPoE agency configuration
11.2.31 CP change from master to backup in cold mode
11.2.32 CP send message to UP failed
11.2.33 CPDR no permit users access
11.2.38 Cut command from domain
11.2.39 DHCP allocating IP from local pool failed
11.2.41 DHCP configuration synchronization between CTRL-VM and BRAS-VM failed
11.2.43 DHCP free lease with command
11.2.44 DHCP generate request pkt fail
11.2.45 DHCP invalid IP pool info
11.2.48 DHCP packet info did not match
11.2.50 DHCP retrieved unexpected IP address
11.2.52 DHCP user state timeout
11.2.53 DHCP VSRP status changed to Down
11.2.54 DHCP wait client packet timeout
11.2.55 DHCP wait up reply timeout
11.2.56 DHCP with IP address conflict
11.2.58 DHCP with server no response
11.2.60 Disable ipoe via command
11.2.64 Dpbackup Cfg Change Offline
11.2.66 Dynamic ipoe user forbidden
11.2.67 Enable/disable VSRP Instance command
11.2.68 failed to add nat user data(invalid private network address)
11.2.69 failed to add nat user data(license invalid)
11.2.70 Failed to associate the PPPoEA user with the BRAS user
11.2.71 Failed to authenticate for ldap configration changed
11.2.72 Failed to authenticate for no ldap binding user's DN
11.2.73 Failed to come online by using CGN because service-instance-group is invalid
11.2.74 Failed to compose tacacs request packet
11.2.75 Failed to connect with the ldap server
11.2.76 Failed to connect with the tacacs server
11.2.77 Failed to create a PPPoEA session
11.2.78 Failed to deliver PPPoEA user information to the kernel
11.2.79 Failed to encode the request packet
11.2.80 Failed to fill the authentication attributes
11.2.81 Failed to find AAA server
11.2.82 Failed to find the BRAS user
11.2.83 Failed to get NAT instance
11.2.84 Failed to get user’s DN from the ldap search result
11.2.85 Failed to inherit user information from PPPoE
11.2.86 Failed to obtain the secret
11.2.87 Failed to obtain user group information
11.2.88 Failed to parse AAA request message
11.2.89 Failed to smooth the PPPoEA session
11.2.90 Failed to switch workslot for user is not up
11.2.91 Failed to update the PPPoEA session
11.2.92 failover group becomes invalid
11.2.93 Flow-triggered port block assignment does not support CGN
11.2.94 Force user offline by CUSP aging
11.2.95 Going online failed because matching CGN doesn't support port block
11.2.96 Hardware not support IPV6 PD prefix with mask longer than 120
11.2.98 ICMPv6 with detect fail
11.2.100 Inherited PPPoE user went offline
11.2.101 Insufficient hardware resources
11.2.106 Invalid ldap username
11.2.107 Invalid username or password
11.2.110 IP address is not a valid user address
11.2.111 ip subscriber access-block
11.2.112 IP6CP is already down
11.2.113 IPoE access mode or authentication method error
11.2.114 IPoE lease sub-user without the main user
11.2.116 IPoELease main user offline
11.2.117 IPv6 PD prefix conflict
11.2.118 IPv6 user managed flag error
11.2.119 L2TP alloc sessionid fail
11.2.120 L2TP alloc tunnelid fail
11.2.121 L2TP checking ICCN error
11.2.122 L2TP checking ICRQ error
11.2.123 L2TP checking SCCRP error
11.2.125 L2TP instance cfg change
11.2.126 L2TP peer cleared tunnel
11.2.128 L2TP SCCCN check fail
11.2.129 L2TP SCCRQ check fail
11.2.134 L2TP service is unavailable
11.2.136 L2TP session wait for time out
11.2.138 L2TP with cut command
11.2.139 L2TP with memory alloc fail
11.2.140 L2TP with UP is not exist
11.2.143 LAC too many session in mid state tunnel
11.2.146 Ldap admin-binding operation failed
11.2.147 Ldap server connetion error occurred while authenticating
11.2.151 LNS mandatory-chap error
11.2.152 LNS proxy negotiation fail
11.2.155 Local-user access-limit
11.2.156 Logged out by the RADIUS proxy
11.2.157 Macauth without the ipoe user
11.2.159 Magic number check failed
11.2.160 Maximum concurrent users for the account has been reached
11.2.161 NAT instance state error
11.2.162 nat online failed because of match config failed
11.2.163 nat online failed because of match session-service-location failed
11.2.164 NAT Online failed by not bind vsrp
11.2.165 NAT Online failed by vsrp channel state error
11.2.167 No AAA response during realtime accounting
11.2.168 No AAA response for accounting start
11.2.170 No IPv6 address available
11.2.172 No response of control packet from peer
11.2.173 Old connection is exist
11.2.174 On-line user with the same mac exists
11.2.175 Only static leased users are permitted
11.2.176 Packet Authenticator Error
11.2.177 PPP authentication method error
11.2.179 PPP IPCP negotiate fail
11.2.181 PPP IPv6CP negotiate fail
11.2.183 PPP loopback detected
11.2.184 PPP magicnumber check fail
11.2.187 PPP recv ip6cp Protocol Reject
11.2.188 PPP recv ipcp Protocol Reject
11.2.189 PPP up recv ip6cp again
11.2.190 PPP up recv ipcp again
11.2.193 PPP wait chap response time out
11.2.194 PPP wait pap request time out
11.2.195 PPP wait pap response time out
11.2.197 PPPoE agency failed to start PPP
11.2.198 PPPOE send pads failed
11.2.199 PPPoEA session information failed to be synchronized between slots
11.2.200 proxy with smooth fail
11.2.201 Radius authentication and authorization do not same
11.2.202 RADIUS authentication rejected
11.2.203 Re-DHCP for IPoE Web authentication
11.2.204 Receive padt packet from user
11.2.208 Remote interface offline
11.2.211 Service-type mismatch with local-user's
11.2.213 Static user not config
11.2.215 TACACS authentication rejected
11.2.216 Tacacs continue authentication failed
11.2.217 Tacacs follow authentication failed
11.2.218 Tacacs restart authentication failed
11.2.220 The address state is incorrect
11.2.221 The authorized vpn is invalid
11.2.222 The BRAS user associated with the PPPoEA user is offline
11.2.223 The drv does not support
11.2.224 The IPoE lease user is confilct with the static user
11.2.225 The memory reached the restart threshold
11.2.226 The NAT instance was unbound from CGN-UP backup profile
11.2.227 The non-static user is kicked off the line by the static user
11.2.228 The number of terminals on this interface exceeds limit
11.2.229 The number of terminals on this machine exceeds limit
11.2.230 The number of users exceeds limit
11.2.231 The PPPoEA user already exists
11.2.232 The PPPoEA user does not exist in the PPPoE module
11.2.233 The PPPoEA user failed to select an access interface
11.2.234 The PPPoEA user failed to select an access interface because agency is not enabled
11.2.238 The PPPoEA user failed to switch the negotiation slot
11.2.239 The protocol stack on which the base service depends is IPv4
11.2.240 The protocol stack on which the base service depends is IPv6
11.2.241 The source IP address of the L2TP tunnel does not support backup
11.2.242 The user conflicts with an online user with the same DHCP client ID
11.2.243 The user group of the BRAS user changed
11.2.244 The user with the same MAC address already exists on the backup interface
11.2.245 The user with the same IP address already exists on the backup interface
11.2.246 The user's 802.1X client has not come online
11.2.247 The VPN bound to the IPoE static user and the authorized VPN are different
11.2.248 The VPN to which the subscriber belongs has been deleted
11.2.249 Tunnel with session null
11.2.250 UCM notifies the PPPoEA user to go offline
11.2.251 UCM portswitch process fail
11.2.252 Unmatched Vpn-Instance
11.2.255 UP Switch NO IfBackup
11.2.258 User binding attributes mismatch with local-user's
11.2.259 User is in local-user blacklist
11.2.263 Web with unknown error
本文档介绍BRAS业务常见故障的诊断及处理措施。
本文档假设您已了解BRAS业务相关技术知识，并熟悉H3C BRAS设备。
本文档适用的产品如表1-1所示。
|
产品 |
版本 |
|
SR8800-X |
R8380P09及以上 |
|
SR8800-X-S |
R8385P09及以上 |
|
SR8800-F |
R8385P09及以上 |
|
CR16000-F |
R8385P09及以上 |
|
CR16000-M |
R8385P09及以上 |
|
vBRAS1000-CP |
E2021P20及以上 |
|
vBRAS1000-vUP |
E3021P20及以上 |
本文档不严格与具体软、硬件版本对应，如果使用过程中与产品实际情况有差异，请以设备实际情况为准。
本文档中出现的接口编号仅作示例，并不代表设备上实际具有此编号的接口，实际使用中请以设备上存在的接口编号为准。
本文档中涉及的Debug调试命令的详细介绍，请参见产品Debugging命令参考。
(1) 确认故障的业务影响范围
包括故障的用户数量，把用户表述中的宽带业务、IPTV业务等业务类型转换为设备的接入业务类型，也就是PPPoE、IPoE等接入业务。
(2) 确认组网情况
用户的基本网络结构是如何搭建的，因为BRAS的问题跟网络也是强相关的。
(3) 确认出故障前后，网络是否有人在操作
包括修改配置，割接业务等，这一步主要是为了尽快确认问题可能的触发的原因。
(4) 确认故障用户的特点，故障用户是否有共同点
比如同一种接入模式，同一个二层交换机接入的等都有问题。
(5) 确认故障点
很多时候故障可能是网络中其他设备导致的，因此在排除掉BRAS设备的嫌疑后，需要指导现场通过QoS流统计、端口镜像等明确网络的故障点，协助客户排查问题。
(6) 确认问题严重性
如果严重需要尽快收集用户信息，然后恢复业务，如果不严重优先现网定位。
上述提供的是一个整体的排错思路，目的是为了尽快的缩小问题的范围，聚焦到对应的模块，并且根据问题的严重性和复杂性不同排错的思路顺序并不是固定的，同时维护人员经验丰富之后，可以结合自己的经验进行问题的快速确认。
本章节主要整理了BRAS设备的整体排错思路，分为控制平面故障排错和数据平面故障排错。
· 控制平面：运行路由、MPLS、链路层、安全等各种路由、信令和控制协议，生成各种转发表项以控制数据平面的转发行为。
· 数据平面：提供数据报文转发功能，包括本地报文的收发，即IPv4/IPv6协议栈、socket、基于各层转发表的数据转发功能等。
如图2-1所示，接入用户认证上线过程中会涉及到5大功能组件。其中UCM组件是其余四个组件之间的桥梁，负责协调各组件间的交互关系并协助完成用户连接的建立、维护和拆除等功能。
各组件基本功能如下：
· 用户接入识别组件
负责识别和处理用户的各种接入协议报文，并在用户认证过程中获取用户的用户名、密码及物理位置等信息，从而为实现合法用户接入提供信息依据和安全保障。
· UCM组件
是其他四个组件之间的桥梁，负责协调用户接入识别、AAA管理、地址管理等组间之间的交互关系，并协助完成用户连接的建立、维护和拆除等功能。
· AAA组件
负责对用户进行认证、授权和计费。
· 地址管理组件
负责为接入用户分配IP地址，并通过对用户IP地址的统一管理来确保IP地址资源等到合理使用。
· 业务控制组件
负责对用户接入的基本业务和增值业务的访问权限、带宽和QoS策略等进行控制。
控制平面故障排查思路如下：
(1) 收集故障用户的用户名、MAC、接入VLAN等信息。
通过如下trace access-user命令来单独跟踪这个用户的上线流程，这个命令可以跟踪到用户从接入到认证再到地址分配的整个过程，根据这个命令的调试结果可以确认故障阶段。
[bras] trace access-user object 1 ?
access-mode Specify users by access mode
c-vlan Specify users by Customer-VLAN
calling-station-id Specify users by calling station ID
interface Specify users by interface
ip-address Specify a user by IP address
mac-address Specify users by MAC address
s-vlan Specify users by Service-VLAN
tunnel-id Specify users by tunnel ID
username Specify a user by username
(2) 根据trace access-user的结果显示的故障位置优先排查配置是否正确，如果配置不正确则修改配置。
(3) 如果配置正确，故障可能出在接入模块、认证计费模块（radius模块）、地址分配模块、Portal模块、L2TP模块，根据故障所发生的模块，调用对应的命令继续分析即可，相应的调试命令参考产品Debugging命令参考。
trace access-user命令开启后，可以根据display trace access-user命令用来显示业务跟踪对象的配置信息，同时也能显示该trace剩余跟踪时间，如果跟踪时间为0，则trace功能失效，下次跟踪需要再次开启配置。
BRAS设备的数据转发是硬件转发实现的，因此出问题的可能性比较低，一般如果反馈数据流量故障，比如限速不准，丢包，不通，需要确认故障用户是否在线，服务器授权的限速等属性是否正确，用户的数据流量是否到BRAS，如果这些都排查完成了，都没有问题，流量也确实到BRAS设备了，这时候就联系收集故障信息，并联系技术支持人员。
现场业务故障的时候很多情况下光收集调试信息未必能马上确认现场业务的故障的原因，而用户急需恢复业务，不会给太多时间进行定位，因此需要同步收集用户信息，目前用户信息收集的命令做的已经相对比较完善了。如果是单个用户故障则可以考虑只收集单个用户对应的模块用户信息，并且收集一部分正常用户的对应模块的用户信息进行对比分析。如果是多用户故障那就需要第一时间收集所有故障用户的信息，并联系技术支持人员。
用户信息收集分为两类，一类是在线用户表项信息收集，一类是异常下线原因用户的信息收集，下面就是分这两类介绍信息收集命令。
本章节涉及到的display命令中参数支持情况不严格与具体软、硬件版本对应，如果使用过程中与产品实际情况有差异，请以设备实际情况为准。
这里主要收集的是用户在线信息，包括正常在线用户的信息，和临时用户的信息，以及一些残留的用户信息。
在使用本章节的命令收集在线用户信息之前请务必查看相应命令手册，详细了解每个细分参数具体可能获取到的信息，这样在实际信息收集过程中才能够快速有效地收集到需要的信息。例如，如果查询单个用户的信息建议携带verbose参数，这样收集到的用户信息会更加全面。
(1) 通过如下命令收集基于PPPoE接入的PPP用户的用户信息，一般以该命令收集为主。
<Sysname> display access-user user-type pppoe ?
> Redirect it to a file
>> Redirect it to a file in append mode
auth-type Specify a user by authentication type
count Display the total number of users
domain Specify users by ISP domain
interface Specify users by interface
ip-pool Specify users by an IP pool
ip-pool-group Specify users by an IP pool group
ip-type Specify users by IP type
ipv6-address-protocol Specify users by IPv6 address protocol
ipv6-pool Specify users by an IPv6 pool
ipv6-pool-group Specify users by an IPv6 pool group
lac-ip Specify users by the IP address of an LAC
lns-ip Specify users by the IP address of an LNS
mac-address Specify a user by MAC address
remote-name Specify users by the tunnel name
slot Specify the slot number
start-time Specify users by the start time of coming online
user-address-type Specify users by address type
user-group Specify users by a user group
username Specify a user by username
verbose Display detailed information about users
vpn-instance Specify a VPN instance
vxlan Specify users by a range of VXLANs
| Matching output
<cr>
(2) 通过如下命令收集基于PPPoE接入的PPPoE用户的用户信息，这个命令获取的信息和PPP调试获取的信息维度不同，是基于PPPoE收集的，所以用户信息比较少。
<Sysname> display pppoe-server ?
chasten PPPoE connection blocking
packet Packet statistics
session PPPoE session information
throttled-mac Throttled MAC information
(1) 通过如下命令收集IPoE的用户信息，也包括IPoE Web，可以通过参数来实现各种维度的收集
<Sysname> display access-user auth-type ?
admin Admin authentication
bind Bind authentication
dot1x 802.1X authentication
dvpn Dynamic VPN authentication
ike IKE authentication
mac-auth Mac authentication
portal Portal authentication
ppp PPP authentication
pre-auth Pre web authentication
sslvpn SSL VPN authentication
web-auth Web authentication
(2) IPoE bind认证用户信息收集命令如下。
<Sysname> display access-user auth-type bind ?
> Redirect it to a file
>> Redirect it to a file in append mode
count Display the total number of users
domain Specify users by ISP domain
interface Specify users by interface
ip-pool Specify users by an IP pool
ip-pool-group Specify users by an IP pool group
ip-type Specify users by IP type
ipv6-address-protocol Specify users by IPv6 address protocol
ipv6-pool Specify users by an IPv6 pool
ipv6-pool-group Specify users by an IPv6 pool group
lac-ip Specify users by the IP address of an LAC
lns-ip Specify users by the IP address of an LNS
mac-address Specify a user by MAC address
remote-name Specify users by the tunnel name
slot Specify the slot number
start-time Specify users by the start time of coming online
user-address-type Specify users by address type
user-group Specify users by a user group
user-type Specify users by type
username Specify a user by username
verbose Display detailed information about users
vpn-instance Specify a VPN instance
vxlan Specify users by a range of VXLANs
| Matching output
<cr>
(1) L2TP隧道承载的稳态用户信息通过如下命令收集
<Sysname> display l2tp session ?
> Redirect it to a file
>> Redirect it to a file in append mode
lac Display L2TP session information of LAC
lns Display L2TP session information of LNS
local-address Specify sessions by the local IP address
remote-address Specify sessions by the remote IP address
statistics Statistics information
temporary L2TP temporary session information
tunnel-id Specify sessions by the specified local tunnel ID
username Specify sessions by the username
verbose Display detailed L2TP session information
| Matching output
<cr>
(2) L2TP隧道承载的非稳态用户信息通过如下命令收集
<Sysname> display l2tp session temporary ?
> Redirect it to a file
>> Redirect it to a file in append mode
| Matching output
<cr>
(3) L2TP隧道信息通过如下命令收集
<Sysname> display l2tp tunnel ?
> Redirect it to a file
>> Redirect it to a file in append mode
group-name Specify tunnels by the group name
group-number Specify tunnels by the group number
lac Display L2TP tunnel information of LAC
lns Display L2TP tunnel information of LNS
local-address Specify tunnels by the local IP address
remote-address Specify tunnels by the remote IP address
statistics Statistics information
tunnel-id Specify tunnels by the local L2TP tunnel ID
tunnel-name Specify tunnels by the remote tunnel name
verbose Display detailed L2TP tunnel information
vsrp L2TP VSRP tunnel information
| Matching output
<cr>
(4) LAC上通过如下命令收集L2TP接入的PPP用户的用户信息
<Sysname> display access-user user-type lac ?
> Redirect it to a file
>> Redirect it to a file in append mode
auth-type Specify a user by authentication type
count Display the total number of users
domain Specify users by ISP domain
interface Specify users by interface
ip-pool Specify users by an IP pool
ip-pool-group Specify users by an IP pool group
ip-type Specify users by IP type
ipv6-address-protocol Specify users by IPv6 address protocol
ipv6-pool Specify users by an IPv6 pool
ipv6-pool-group Specify users by an IPv6 pool group
lac-ip Specify users by the IP address of an LAC
lns-ip Specify users by the IP address of an LNS
mac-address Specify a user by MAC address
remote-name Specify users by the tunnel name
slot Specify the slot number
start-time Specify users by the start time of coming online
user-address-type Specify users by address type
user-group Specify users by a user group
username Specify a user by username
verbose Display detailed information about users
vpn-instance Specify a VPN instance
vxlan Specify users by a range of VXLANs
| Matching output
<cr>
(5) LNS上通过如下命令收集L2TP接入的PPP用户的用户信息
<Sysname> display access-user user-type lns ?
> Redirect it to a file
>> Redirect it to a file in append mode
auth-type Specify a user by authentication type
count Display the total number of users
domain Specify users by ISP domain
interface Specify users by interface
ip-pool Specify users by an IP pool
ip-pool-group Specify users by an IP pool group
ip-type Specify users by IP type
ipv6-address-protocol Specify users by IPv6 address protocol
ipv6-pool Specify users by an IPv6 pool
ipv6-pool-group Specify users by an IPv6 pool group
lac-ip Specify users by the IP address of an LAC
lns-ip Specify users by the IP address of an LNS
mac-address Specify a user by MAC address
remote-name Specify users by the tunnel name
slot Specify the slot number
start-time Specify users by the start time of coming online
user-address-type Specify users by address type
user-group Specify users by a user group
username Specify a user by username
verbose Display detailed information about users
vpn-instance Specify a VPN instance
vxlan Specify users by a range of VXLANs
| Matching output
<cr>
(1) 收集DHCP server可以分配的空闲地址信息
<Sysname> display dhcp server free-ip ?
> Redirect it to a file
>> Redirect it to a file in append mode
pool Specify a DHCP pool
vpn-instance Specify a VPN instance
| Matching output
<cr>
(2) 收集DHCP server已经分配出去在用的地址信息
<Sysname> display dhcp server ip-in-use ?
> Redirect it to a file
>> Redirect it to a file in append mode
interface Specify the interface
ip Specify an IP address
pool Specify a DHCP pool
subnet Specify s subnet
up-backup-group Specify a UPBACKUPGROUP
up-id Specify a UP Id
vpn-instance Specify a VPN instance
vxlan Specify a VXLAN
| Matching output
<cr>
(3) DHCP server超期链表记录的ip和mac的绑定信息
<Sysname> display dhcp server expired ?
> Redirect it to a file
>> Redirect it to a file in append mode
interface Specify the interface
ip Specify an IP address
mac Specify a MAC address
pool Specify a DHCP pool
up-backup-group Specify a UPBACKUPGROUP
up-id Specify a UP Id
verbose Detailed information
vpn-instance Specify a VPN instance
vxlan Specify a VXLAN
| Matching output
<cr>
(4) DHCP server冲突链表记录的ip和mac的绑定信息
<Sysname> display dhcp server conflict ?
> Redirect it to a file
>> Redirect it to a file in append mode
interface Specify the interface
ip Specify an IP address
up-backup-group Specify a UPBACKUPGROUP
up-id Specify a UP Id
vpn-instance Specify a VPN instance
vxlan Specify a VXLAN
| Matching output
<cr>
(5) DHCP relay记录DHCP中继的用户地址表项信息
<Sysname> display dhcp relay client-information ?
> Redirect it to a file
>> Redirect it to a file in append mode
interface Specify the interface
ip Specify an IP address
| Matching output
<cr>
AAA模块用户相关的信息是没有对应的命令的，用户相关的信息都是由接入模块记录的。
这里主要收集的是异常下线用户的相关信息，包括用户下线的原因，以及各个模块的协议报文交互计数，用来分析用户真正下线的原因。
在使用本章节的命令收集异常下线用户信息之前请务必查看相应命令手册，详细了解每个细分参数具体可能获取到的信息，这样在实际信息收集过程中才能够快速有效地收集到需要的信息。
(1) 收集PPPoE的协商报文统计信息
<Sysname> display pppoe-server packet statistics ?
> Redirect it to a file
>> Redirect it to a file in append mode
slot Specify the slot number
| Matching output
<cr>
(2) 收集PPP的协商报文统计信息
<Sysname> display ppp packet statistics ?
> Redirect it to a file
>> Redirect it to a file in append mode
slot Specify the slot number
| Matching output
<cr>
(3) 收集PPP用户下线原因的统计信息
<Sysname> display aaa offline-record access-type ppp ?
> Redirect it to a file
>> Redirect it to a file in append mode
brief Display brief information
count Specify the number of records to be displayed
domain Specify an ISP domain
interface Specify an interface
ip Specify an IPv4 address
ipv6 Specify an IPv6 address
mac-address Specify a MAC address
s-vlan Specify a service provider network VLAN
slot Specify the slot number
username Specify a username
| Matching output
<cr>
(1) 收集异常下线DHCP接入用户的信息
<Sysname> display ip subscriber abnormal-logout ?
> Redirect it to a file
>> Redirect it to a file in append mode
interface Specify an interface
ip Specify the IP address
ip-type Specify users by IP type
ipv6 Specify the IPv6 address
mac Specify a MAC address
slot Specify the slot number
verbose Detailed information
| Matching output
<cr>
(2) 收集IPoE用户会话下线原因的统计信息。
<Sysname> display aaa offline-record access-type ipoe ?
> Redirect it to a file
>> Redirect it to a file in append mode
brief Display brief information
count Specify the number of records to be displayed
domain Specify an ISP domain
interface Specify an interface
ip Specify an IPv4 address
ipv6 Specify an IPv6 address
mac-address Specify a MAC address
s-vlan Specify a service provider network VLAN
slot Specify the slot number
username Specify a username
| Matching output
<cr>
(3) 收集IPoE用户的统计信息。
<Sysname> display access-user count ?
> Redirect it to a file
>> Redirect it to a file in append mode
| Matching output
<cr>
(1) 收集L2TP协议报文的统计信息。
<Sysname> display l2tp control-packet statistics ?
> Redirect it to a file
>> Redirect it to a file in append mode
summary Summary L2TP control packet statistics
tunnel L2TP control packet statistics of each tunnel
| Matching output
<cr>
(2) 收集L2TP的统计信息
<Sysname> display l2tp statistics ?
all All L2TP statistics
rdbm RedisDBM statistics
vsrp VSRP statistics
(1) 收集DHCP server的统计信息
<Sysname> display dhcp server statistics ?
> Redirect it to a file
>> Redirect it to a file in append mode
pool Specify a DHCP pool
vpn-instance Specify a VPN instance
| Matching output
<cr>
(2) 收集DHCP relay相关的统计信息
<Sysname> display dhcp relay packet statistics ?
> Redirect it to a file
>> Redirect it to a file in append mode
interface Specify the interface
| Matching output
<cr>
(1) 通过AAA模块收集用户异常下线的记录。
<Sysname> display aaa abnormal-offline-record ?
> Redirect it to a file
>> Redirect it to a file in append mode
access-type Specify an access type
domain Specify an ISP domain
interface Specify an interface
ip Specify an IPv4 address
ipv6 Specify an IPv6 address
mac-address Specify a MAC address
offline-reason Specify a user offline reason
s-vlan Specify a service provider network VLAN
slot Specify the slot number
time Specify a time range
username Specify a username
| Matching output
<cr>
(2) 通过AAA模块收集用户正常下线的记录。
<Sysname> display aaa normal-offline-record ?
> Redirect it to a file
>> Redirect it to a file in append mode
access-type Specify an access type
domain Specify an ISP domain
interface Specify an interface
ip Specify an IPv4 address
ipv6 Specify an IPv6 address
mac-address Specify a MAC address
s-vlan Specify a service provider network VLAN
slot Specify the slot number
time Specify a time range
username Specify a username
| Matching output
<cr>
(3) 通过AAA模块收集用户下线的记录。
<Sysname> display aaa offline-record ?
> Redirect it to a file
>> Redirect it to a file in append mode
access-type Specify an access type
domain Specify an ISP domain
interface Specify an interface
ip Specify an IPv4 address
ipv6 Specify an IPv6 address
mac-address Specify a MAC address
s-vlan Specify a service provider network VLAN
slot Specify the slot number
time Specify a time range
username Specify a username
| Matching output
<cr>
(4) 通AAA模块收集用户上线的记录。
<Sysname> display aaa online-fail-record ?
> Redirect it to a file
>> Redirect it to a file in append mode
access-type Specify an access type
domain Specify an ISP domain
interface Specify an interface
ip Specify an IPv4 address
ipv6 Specify an IPv6 address
mac-address Specify a MAC address
s-vlan Specify a service provider network VLAN
slot Specify the slot number
time Specify a time range
username Specify a username
| Matching output
<cr>
(5) 通过AAA模块收集RADIUS报文的统计信息。
<Sysname> display radius statistics ?
> Redirect it to a file
>> Redirect it to a file in append mode
server Specify a RADIUS server
| Matching output
<cr>
(6) 通过radius模块收集RADIUS服务器的负载统计信息。
<Sysname> display radius server-load statistics ?
> Redirect it to a file
>> Redirect it to a file in append mode
| Matching output
<cr>
(7) 通过radius模块收集ISP域的在线接入用户统计信息。
<Sysname> display domain access-user statistics ?
> Redirect it to a file
>> Redirect it to a file in append mode
| Matching output
<cr>
园区网应用故障处理适用于SR8800-X、SR8800-X-S、SR8800-F、CR16000-F和CR16000-M，不同产品对各故障处理章节的支持情况有所差异，请以设备实际情况为准。
在园区网应用中，BRAS业务常见故障类型及处理措施如表3-1所示。
表3-1 园区网应用中的BRAS业务故障处理
|
故障类型 |
故障处理措施 |
|
· 本地认证登录失败 |
|
|
· IPoE相关故障： |
|
|
· ITA业务不生效 |
|
|
· DHCP故障处理 |
运营商应用故障处理适用于CR16000-F、SR8800-F、vBRAS1000-CP和vBRAS1000-vUP，不同产品对各故障处理章节的支持情况有所差异，请以设备实际情况为准。
· 对于转发与控制分离组网和一体化组网的通用故障处理，因故障处理步骤和思路是相同的，本手册仅以一体化组网为例进行介绍。
· 如果是转发与控制分离组网，在使用本手册进行故障定位之前请务必查看vBRAS-CP产品手册，详细了解转发与控制分离组网架构（具体为产品手册“转发与控制分离业务配置指导”中的“转发与控制分离系统概述”）和各个业务模块的配置差异（如PPPoE、L2TP等），这样在实际排障过程中才能够快速有效地使用本手册进行故障处理。
· 对于转发与控制分离组网中，本手册涉及到的BRAS功能命令如无特殊说明均是指CP上执行的命令。
在运营商应用中，BRAS业务常见故障类型及处理措施如表3-2所示。
表3-2 运营商应用中的BRAS业务故障处理
|
故障类型 |
故障处理措施 |
|
· 本地认证登录失败 |
|
|
· IPoE相关故障： |
|
|
· ITA业务不生效 |
|
|
· 弹性伸缩相关故障： · UP备份相关故障： · 虚拟机相关故障： ¡ 镜像文件上传失败 ¡ VNF包上传失败 ¡ 虚拟机部署失败 ¡ VM注册失败 |
|
|
· DHCP故障处理 |
管理员登录设备后没有部分命令行的执行权限，系统打印提示信息 “Permission denied.”。
本类故障的主要原因为，给用户授权的用户角色权限过小。
本类故障的诊断流程如图4-1所示。
(1) 检查用户角色否为自定义用户角色。
请以超级管理员身份（即具有network-admin或者level-15用户角色）登录设备，执行display line命令查看登录用户线的认证方式，并根据不同的认证方式，采取不同的处理步骤：
<Sysname> display line
Idx Type Tx/Rx Modem Auth Int Location
0 CON 0 9600 - N - 0/0
+ 81 VTY 0 - N - 0/0
+ 82 VTY 1 - P - 0/0
+ 83 VTY 2 - A - 0/0
...
¡ 对于none和password认证方式（Auth字段：N、P），检查对应用户线视图下的用户角色是否为自定义用户角色。如果不是自定义用户角色，则通过user-role role-name命令设置权限更高的系统预定义角色。
¡ 对于scheme认证方式（Auth字段：A），首先查看登录用户认证域下配置的认证方法：
- 如果采用了Local认证方法，则通过display local-user命令查看用户角色是否为自定义用户角色。如果不是自定义用户角色，则通过authorization-attribute user-role role-name命令设置权限更高的系统预定义角色（下例为network-admin）。
<Sysname> system-view
[Sysname] local-user test class manage
[Sysname-luser-manage-test] authorization-attribute user-role network-admin
- 如果采用了远程认证方法，则联系远程认证服务器管理员，为用户授权权限更高的系统预定义角色。
(2) 检查不允许执行的命令行是否在自定义用户角色允许的权限范围内。
a. 执行命令display role name role-name，查看用户的自定义角色拥有的命令行权限规则。
b. 如果用户所执行的命令行不在所属用户角色拥有的命令行权限范围之内，则为其更换权限较高的系统域定义用户角色，或者通过命令rule为用户的自定义角色增加对应的命令行权限规则。需要注意的是，自定义用户角色即使配置了较高的权限规则，仍然有部分无法支持的命令行，这些命令行的明细请查看“基础配置指导”中的“RBAC”手册。
(3) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
无
无
管理员登录设备后无法创建或修改本地用户，系统打印提示信息“Insufficient right to perform the operation.”。
本类故障的主要原因为，给用户授权的用户角色权限不具备修改目标本地用户配置的权限。
本类故障的诊断流程如图4-2所示。
(1) 检查登录用户的角色是否为预定义的超级管理员角色，即为network-admin、level-15之一。
只有上述预定义用户角色才拥有创建本地用户的权限，其它用户角色只有进入自身本地用户视图的权限。如果登录用户不拥有如上预定义用户角色，则为其授权其中之一。如果重新授权后，故障仍未排除，请继续定位。
此步骤仅适用于无权限创建本地用户，若无权限修改本地用户，请执行步骤（2）。
(2) 比较登录用户和目标用户的权限范围。
执行命令display role name role-name，分别查看登录用户和目标用户的角色权限，并比较两者的权限大小。如果操作者权限较小，则为其更换拥有更高权限的用户角色。
(3) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
无
· LOCAL/5/LOCAL_CMDDENY
管理员无法成功登录设备，设备也没有提供三次登录尝试机会。例如，使用Telnet登录时，用户输入用户名和密码后，设备登录界面上既未打印提示信息“AAA authentication failed”，也未再次提示用户输入用户名和密码。
本类故障的主要原因为，没有为用户授权用户角色。
本类故障的诊断流程如图4-3所示。
(1) 检查是否为用户授权了用户角色。
请以超级管理员身份（即具有network-admin或者level-15用户角色）登录设备，执行display line命令查看登录用户线的认证方式，并根据不同的认证方式，采取不同的处理步骤：
<Sysname> display line
Idx Type Tx/Rx Modem Auth Int Location
0 CON 0 9600 - N - 0/0
+ 81 VTY 0 - N - 0/0
+ 82 VTY 1 - P - 0/0
+ 83 VTY 2 - A - 0/0
...
¡ 对于none和password认证方式（Auth字段：N、P），检查对应用户线视图下是否存在用户角色配置。如果不存在，则通过user-role role-name命令设置用户角色（下例中为abc）。
<Sysname> system-view
[Sysname] line vty 0 63
[Sysname-line-vty0-63] user-role abc
¡ 对于scheme认证方式（Auth字段：A），首先查看登录用户认证域下配置的认证方法：
- 如果采用了Local认证方法，则执行display local-user命令查看该用户的授权用户角色情况，如果显示信息中的“User role list：”字段为空，则表示该用户没有被授权任何用户角色。
<Sysname> display local-user user-name test class manage
Total 1 local users matched.
Device management user test:
State: Active
Service type: Telnet
User group: system
Bind attributes:
Authorization attributes:
Work directory: flash:
User role list:
...
此时，需要进入该本地用户视图，执行authorization-attribute user-role命令为用户授权角色（下例中为abc）。
<Sysname> system-view
[Sysname] local-user test class manage
[Sysname-luser-manage-test] authorization-attribute user-role abc
- 如果采用了远程认证方法，则联系远程认证服务器管理员确认是否为该用户授权了用户角色，若无，请为该用户添加用户角色属性。以Free RADIUS服务器为例，如果需要在users文件中添加用户角色network-admin，则需要编辑的脚本如下：
user Cleartext-Password := "123456"
H3C-User-Roles ="shell:roles=\"network-admin\""
其它RADIUS服务器上的用户角色添加方式请以实际情况为准。
(2) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
无
无
管理员登录设备失败，系统打印如下形式的日志信息：
Sysname LOGIN/5/LOGIN_INVALID_USERNAME_PWD: -MDC=1; Invalid username or password from xx.xx.xx.xx.
本类故障的主要原因为，用户输入的用户名中含有非法字符。
本类故障的诊断流程如图4-4所示。
本处理步骤仅适用于SSH及Telnet登录用户。
(1) 检查用户输入的用户名是否含有非法字符。
用户登录设备时，系统会检查用户输入的纯用户名以及域名的有效性，如果纯用户名中包含了非法字符“\”、“|”、“/”、“:”、“*”、“?”、“<”、“>”和“@”，域名中包含“@”，则不允许登录。此时，建议用户再次尝试登录，并输入正确的用户名。
(2) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
无
· LOGIN_INVALID_USERNAME_PWD
管理员采用本地认证方式登录设备失败。如果设备上同时打开了Local-Server的事件调试信息开关（通过执行debugging local-server event命令），系统会打印如下形式的调试信息：
*Aug 18 10:36:58:514 2021 Sysname LOCALSER/7/EVENT: -MDC=1;
Authentication failed, user password is wrong.
或者
*Aug 18 10:37:24:962 2021 Sysname LOCALSER/7/EVENT: -MDC=1;
Authentication failed, user "t4" doesn't exist.
本类故障的常见原因主要包括：
· 用户输入的密码错误。
· 本地用户名不存在。
本类故障的诊断流程如图4-5所示。
(1) 检查本地用户名是否存在。
执行display local-user命令查看是否存在与登录用户名相同的设备管理类本地用户。
¡ 如果不存在该本地用户，则需要使用local-user命令创建设备管理类本地用户（下例中用户名为test），并通知该用户再次尝试登录设备。
<Sysname> system-view
[Sysname] local-user test class manage
[Sysname-luser-manage-test]
¡ 如果存在该本地用户，请执行步骤（2）。
(2) 确认本地用户密码是否正确。
如果用户登录时系统提示密码错误，则进入对应的本地用户视图后，执行password命令重置密码（下例中为123456TESTplat&!），并通知该用户再次尝试登录设备。
<Sysname> system-view
[Sysname] local-user test class manage
[Sysname-luser-manage-test] password simple 123456TESTplat&!
(3) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息、调试信息。
无
无
管理员采用本地认证方式登录设备失败。如果设备上同时打开了Local-Server的事件调试信息开关（通过执行debugging local-server event命令），系统会打印如下形式的调试信息：：
*Aug 7 17:18:07:098 2021 Sysname LOCALSER/7/EVENT: -MDC=1; Authentication failed, unexpected user service type 64 (expected = 3072).
本类故障的主要原因为，用户的接入类型与设备上配置的本地用户服务类型不匹配，即用户的接入类型不在配置的服务类型范围之内。
本类故障的诊断流程如图4-6所示。
(1) 检查用户接入类型是否在本地用户配置的服务类型范围之内。
a. 执行display local-user命令查看本地用户的配置信息，用户服务类型由“Service type:”字段标识。
<Sysname> display local-user user-name test class manage
Total 1 local users matched.
Device management user test:
State: Active
Service type: Telnet
User group: system
Bind attributes:
Authorization attributes:
Work directory: flash:
User role list:
...
b. 在该用户的本地用户视图下，通过执行service-type type命令修改用户的服务类型为实际使用的接入类型（下例中为SSH）。
<Sysname> system-view
[Sysname] local-user test class manage
[Sysname-luser-manage-test] service-type ssh
(2) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息、调试信息。
无
无
管理员登录设备失败指定的次数后，在一定时间内被禁止再次登录设备。
本类故障的常见原因主要包括：
· 设备上开启了Login用户攻击防范功能。开启该功能后，会导致Login用户登录失败指定的次数后，若用户的IP地址被加入黑名单，则设备将会丢弃来自该IP地址的报文，使得该用户不能在指定的阻断时长内进行登录操作。
· 用户采用本地认证方式登录设备，且设备上开启了Password Control功能。用户登录认证失败后，系统会将该用户加入密码管理的黑名单，并根据配置的处理措施对其之后的登录行为进行相应的限制。当用户登录失败次数超过指定值后，系统禁止该用户登录，经过一段时间后，再允许该用户重新登录。
本类故障的诊断流程如图4-7所示。
(1) 等待一定时间后，尝试重新登录。
如果因为偶尔密码输入有误导致的禁止登录，属于正常现象，建议等待一定的时间后再次尝试重新登录。如果再次使用正确的用户名和密码登录设备遇到同样的问题，请更换其它可登录设备的管理员账号继续下面的处理步骤。
(2) 确认用户被阻断后能否发起登录连接。
¡ 如果该用户被阻断后，仍然可以向设备发起登录连接，但无法认证成功，则在任意视图下执行display password-control blacklist命令查看该用户是否被加入了黑名单。如果该用户在黑名单中，且显示信息中的Lock flag为lock，则表示用户被锁定了。
<Sysname> display password-control blacklist
Per-user blacklist limit: 100.
Blacklist items matched: 1.
Username IP address Login failures Lock flag
test 3.3.3.3 4 lock
对于加入黑名单的用户，有两种处理方式：
- 在系统视图下执行undo password-control enable命令关闭全局密码管理功能。
<Sysname> system-view
[Sysname] undo password-control enable
- 在用户视图下执行reset password-control blacklist命令清除密码管理黑名单中的用户（下例中为用户test）。
<Sysname> reset password-control blacklist user-name test
¡ 如果该用户被阻断后，根本无法向设备发起登录连接，则执行步骤（3）。
(3) 检查是否开启了Login用户攻击防范功能。
如果当前配置中存在attack-defense login开头的相关命令，则可以根据需要关闭Login用户攻击防范功能，或者改变Login用户登录连续失败的最大次数以及登录失败后的阻断时长。
¡ 通过执行attack-defense login max-attempt命令增加连续登录失败的最大次数，增大用户登录的尝试机会（下例为5次）。
<Sysname> system-view
[Sysname] attack-defense login max-attempt 5
¡ 通过执行attack-defense login block-timeout命令减小阻断时长（下例为1分钟），让用户尽快重新登录。
<Sysname> system-view
[Sysname] attack-defense login block-timeout 1
执行以上操作可能会减弱设备防范Login用户DoS攻击的力度，请慎重执行。
(4) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
无
无
管理员登录设备失败后，控制台无响应一定的时间，期间用户无法执行任何操作。
本类故障的主要原因主要为，设备上配置了Login延时认证功能。开启本功能后，用户登录失败后，系统将会延迟一定的时长之后再允许用户进行认证。
本类故障的诊断流程如图图4-8所示。
(1) 检查是否开启了Login延时认证功能。
如果当前配置中存在attack-defense login reauthentication-delay命令，则可以根据需要关闭Login延时认证功能，或修改重认证等待时长。
¡ 通过执行undo attack-defense login reauthentication-delay命令关闭延时认证功能。
<Sysname> system-view
[Sysname] undo attack-defense login reauthentication-delay
¡ 通过执行attack-defense login reauthentication-delay seconds命令减小用户登录失败后重新进行认证的等待时长（下例中为10秒）。
<Sysname> system-view
[Sysname] attack-defense login reauthentication-delay 10
执行以上操作可能会减弱设备防范Login用户字典序攻击的力度，请慎重执行。
(2) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
无
无
使用同一用户名接入设备的本地认证用户达到一定数量后，后续使用该用户名登录设备失败。
如果设备上同时打开了Local-Server的事件调试信息开关（通过执行debugging local-server event命令），系统会打印如下形式的调试信息：
*Aug 18 10:52:56:664 2021 Sysname LOCALSER/7/EVENT: -MDC=1;
Authentication failed, the maximum number of concurrent logins already reached for the local user.
本类故障的主要原因为，设备上设置了使用当前本地用户名接入设备的最大用户数。
本类故障的诊断流程如图4-9所示。
图4-9 使用相同用户名的上线用户数达上限后的故障诊断流程图
(1) 检查是否设置了使用当前本地用户名接入设备的最大用户数。
执行display local-user命令，查看该用户名的本地用户配置信息。如果其中的“Access limit:”字段取值为Enabled，则表示设置了使用当前本地用户名接入设备的最大用户数（下例中为2）。
<Sysname> display local-user user-name test class manage
Total 1 local users matched.
Device management user test:
Service type: SSH/Telnet
Access limit: Enabled Max access number: 2
Service type: Telnet
User group: system
Bind attributes:
Authorization attributes:
Work directory: flash:
User role list: test
...
可以根据需要在本地用户视图下取消或者改变使用当前本地用户名接入设备的最大用户数。
¡ 通过执行undo access-limit命令取消使用当前本地用户名接入的用户数限制。
<Sysname> system-view
[Sysname] local-user test class manage
[Sysname-luser-manage-test] undo access-limit
¡ 通过执行access-limit max-user-number命令增加最大用户数（下例中为10）。
<Sysname> system-view
[Sysname] local-user test class manage
[Sysname-luser-manage-test] access-limit 10
(2) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
无
无
使用同一登录方式接入设备的用户达到一定数量后，后续该类用户登录设备失败。
如果设备上同时打开了相关接入模块的事件调试信息开关，系统会打印如下形式的调试信息：
%Aug 18 10:57:52:596 2021 Sysname TELNETD/6/TELNETD_REACH_SESSION_LIMIT: -MDC=1; Telnet client 1.1.1.1 failed to log in. The current number of Telnet sessions is 5. The maximum number allowed is (5).
本类故障的主要常见原因为，设备上设置了采用指定登录方式登录设备并同时在线的用户数。
本类故障的诊断流程如图4-10所示：
图4-10 使用相同登录方式接入用户数达到上限后的故障诊断流程图
(1) 检查是否设置了采用指定登录方式登录设备并同时在线的用户数。
如果当前配置中存在aaa session-limit命令，则可以根据需要在系统视图下通过aaa session-limit { ftp | http | https | ssh | telnet } max-sessions命令改变使用当前登录方式接入设备的最大用户数（下例中为32）。
<Sysname> system-view
[Sysname] aaa session-limit telnet 32
(2) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
无
无
因为服务器无响应导致使用RADIUS认证服务器认证/授权/计费失败。如果设备上同时打开了RADIUS的事件调试信息开关（通过执行debugging radius event命令），系统会打印如下形式的调试信息：
*Aug 8 17:49:06:143 2021 Sysname RADIUS/7/EVENT: -MDC=1; Reached the maximum retries
本类故障的常见原因主要包括：
· RADIUS服务器上配置的共享密钥与接入设备上配置的共享密钥不一致。
· RADIUS服务器上没有添加接入设备的IP地址或者添加的IP地址不正确。
· RADIUS服务器与接入设备之间的网络存在问题，例如中间网络存在防火墙时，防火墙阻止了RADIUS服务器提供AAA服务的端口号（缺省认证端口号：1812，缺省计费端口号：1813）。
本类故障的诊断流程如图4-11所示。
图4-11 RADIUS服务器无响应的故障诊断流程图
(1) 检查RADIUS服务器上配置的共享密钥与接入设备上配置的是否一致。
¡ 如果共享密钥配置不一致，则：
- 在接入设备上，需要在RADIUS方案视图下执行key authentication、key accounting命令分别重新配置认证、计费共享密钥（下例中认证密钥为123、计费密钥为456）。
<Sysname> system-view
[Sysname] radius scheme radius1
[Sysname-radius-radius1] key authentication simple 123
[Sysname-radius-radius1] key accounting simple 456
- 在RADIUS服务器上，重新配置与接入设备交互RADIUS报文的共享密钥，保证与接入设备上配置的一致。
¡ 如果共享密钥配置一致，则执行步骤（2）。
(2) 检查设备和服务器之间的网络是否存在问题。
首先使用ping等手段排除设备与服务器之间的网络可达性，然后排查该网络中是否存在防火墙等设备。通常，如果网络中存在防火墙设备且不允许目的UDP端口号为RADIUS服务器端口号的报文通过（缺省的RADIUS认证端口号为1812，缺省的RADIUS计费端口号为1813），RADIUS报文将被丢弃。
(3) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息、调试信息。
无
无
使用HWTACACS认证服务器认证/授权/计费失败。如果同时在设备上执行debugging hwtacacs event命令打开HWTACACS事件调试信息开关，系统打印的事件调试信息中将出现“Connection timed out.”。
本类故障的常见原因主要包括：
· HWTACACS服务器上配置的共享密钥与接入设备上配置的共享密钥不一致。
· HWTACACS服务器上没有添加接入设备的IP地址或者添加的IP地址不正确。
· HWTACACS服务器与接入设备之间的网络存在问题，例如中间网络存在防火墙时，防火墙阻止了HWTACACS服务器提供AAA服务的端口号（缺省认证/授权/计费端口号为49）。
本类故障的诊断流程如图4-12所示。
图4-12 HWTACACS服务器无响应的故障诊断流程图
(1) 检查HWTACACS服务器上配置的共享密钥与接入设备上配置的是否一致。
¡ 如果共享密钥配置不一致，则：
- 在接入设备上，需要在HWTACACS方案视图下执行key authentication、key authorization、key accounting命令重新配置认证、授权、计费共享密钥（下例中认证和授权密钥为123、计费密钥为456）。
<Sysname> system-view
[Sysname] hwtacacs scheme hwt1
[Sysname-hwtacacs-hwt1] key authentication simple 123
[Sysname-hwtacacs-hwt1] key authorization simple 123
[Sysname-hwtacacs-hwt1] key accounting simple 456
- 在HWTACACS服务器上，重新配置与接入设备交互HWTACACS报文的共享密钥，保证与接入设备上配置的一致。
¡ 如果共享密钥配置一致，则执行步骤（2）。
(2) 检查HWTACACS服务器上是否添加了接入设备的IP地址或者添加的IP地址是否正确。
HWTACACS服务器上添加的设备IP地址必须是接入设备发送HWTACACS报文的源IP地址。接入设备发送HWTACACS报文使用的源IP地址可以通过相关命令设置。
接入设备按照以下顺序选择发送HWTACACS报文使用的源IP地址：
a. HWTACACS方案视图下配置的源IP地址（通过nas-ip命令）。
b. 系统视图下的配置的源IP地址（通过hwtacacs nas-ip命令）。
c. 发送HWTACACS报文的出接口的IP地址。
(3) 检查设备和服务器之间的网络是否存在问题。
首先使用ping等手段排除设备与服务器之间的网络可达性，然后排查该网络中是否存在防火墙等设备。通常，如果网络中存在防火墙设备且不允许目的TCP端口号为HWTACACS服务器端口号的报文通过（缺省的HWTACACS认证/授权/计费端口号为49），HWTACACS报文将被丢弃。
(4) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息、调试信息。
无
无
管理员采用本地认证登录设备失败。
本类故障的常见原因主要包括：
· 用户线下的认证方式配置错误。
· VTY用户线下支持的协议类型不正确。
· ISP域下配置的认证、授权、计费方案错误。
· 本地用户不存在、用户密码错误，或服务类型错误。
· 本地用户接入数量达到上限。
· 登录设备的用户数量到达上限。
· 全局密码管理功能开启的情况下，设备本地的lauth.dat文件异常。
本类故障的诊断流程如图4-13所示。
Web、NETCONF over SOAP、FTP类登录故障无需关心用户线（类）下的配置，其它排障步骤相同。
(1) 检查用户线下的配置。
执行line vty first-number [ last-number ]命令进入指定的VTY用户线视图，并通过display this命令查看如下配置是否准确：
¡ authentication-mode是否配置为scheme。
¡ 对于Telnet登录：protocol inbound是否配置为telnet或为缺省情况。
¡ 对于SSH登录：protocol inbound是否配置为ssh或为缺省情况。
(2) 检查用户线类下的配置。
(3) 用户线视图下的配置优先于用户线类视图下的配置。若用户线视图下未配置，则需要继续检查用户线类视图下的配置。
(4) 执行line class vty命令进入VTY用户线类视图，并通过display this命令查看如下配置是否准确：
¡ authentication-mode是否配置为scheme。
¡ 对于Telnet登录：protocol inbound是否配置为telnet或为缺省情况。
¡ 对于SSH登录：protocol inbound是否配置为ssh或为缺省情况。
如果用户线和用户线类下的配置均不准确，请按照需要在指定的用户线或用户线类下设置认证方案为scheme，并设置用户登录支持的协议类型。
(5) 检查ISP域下的在线用户数是否达到上限。
执行display domain命令查看用户认证域下的access-limit配置。
¡ 如果显示信息中的“Access limit:”字段为具体的数值，则执行display domain name isp-name access-user statistics命令查看“Online user count”字段取值是否达到Access limit数值。如果达到上，则根据需要采取以下措施之一：
- 在ISP域视图下执行access-limit命令扩大用户数上限（本例中为20）。
<Sysname> system-view
[Sysname] domain name test
[Sysname-isp-test] access-limit 20
- 在用户视图下执行free命令强制其它在线用户下线（本例中为强制释放VTY1上建立的所有连接）。
<Sysname> free line vty 1
Are you sure to free line vty1? [Y/N]:y
[OK]
¡ 如果“Access limit:”字段取值为“Not configured”，或者用户数未达到上限值，则继续定位。
(6) 检查ISP域下的认证、授权、计费方案配置是否准确。
执行display domain命令，查看显示信息：
¡ 如果用户的登录用户名中携带了域名（假设为test），则查看该域下的“Login authentication scheme:”字段取值是否为Local。如果该域下无“Login authentication scheme:”字段，再查看“Default authentication scheme:”字段取值是否为Local。
<Sysname> display domain test
Domain: test
State: Active
Login authentication scheme: Local
Default authentication scheme: Local
Default authorization scheme: Local
Default accounting scheme: Local
Accounting start failure action: Online
Accounting update failure action: Online
Accounting quota out action: Offline
Service type: HSI
Session time: Exclude idle time
NAS-ID: N/A
DHCPv6-follow-IPv6CP timeout: 60 seconds
Authorization attributes:
Idle cut: Disabled
Session timeout: Disabled
¡ 如果用户的登录用户名中未携带域名，则在系统视图下执行display this命令查看是否存在domain default enable isp-name配置。（下例中缺省域名为system）。
#
domain default enable system
#
- 如果存在该配置，则执行display domain命令查看isp-name域下的“Login authentication scheme:”字段取值是否为“Local”。如果该域下无“Login authentication scheme:”字段，再查看“Default authentication scheme:”字段取值是否为“Local”。
- 如果不存在该配置，则执行display domain命令查看system域下的“Login authentication scheme:”字段取值是否为“Local”。如果system域下无“Login authentication scheme:”字段，再查看“Default authentication scheme:”字段取值是否为“Local”。
授权、计费配置确认方式与认证类似，不再赘述。如果以上配置不准确，请在相关ISP下配置Login用户的认证/授权/计费方案均为Local。
(7) 检查用户名和密码是否正确。
执行display local-user命令查看是否存在对应的本地用户配置。
¡ 如果本地用户存在，则执行local-user username class manage命令进入本地用户视图，然后通过display this命令查看该视图下是否配置了密码，以及service-type配置是否为所需的服务类型。
- 若需要用户密码，则尝试重置一次密码（下例中为123456TESTplat&!）。
<Sysname> system-view
[Sysname] local-user test class manage
[Sysname-luser-manage-test] password simple 123456TESTplat&!
- 若服务类型错误，则配置与登录方式匹配的服务类型（下例中为SSH）。
<Sysname> system-view
[Sysname] local-user test class manage
[Sysname-luser-manage-test] service-type ssh
¡ 如果本地用户不存在，则执行local-user username class manage命令创建一个设备管理类本地用户（下例中用户名为test），并按需配置密码和服务类型。
<Sysname> system-view
[Sysname] local-user test class manage
[Sysname-luser-manage-test]
(8) 检查使用该本地用户名接入的用户数是否达到上限。
在本地用户视图下执行display this命令查看是否存在access-limit配置。
¡ 如果access-limit配置存在，则执行display local-user username class manage命令查看“Current access number:”字段取值是否达到配置的上限值。如果达到上限值，则根据需要采取以下措施之一：
- 在该本地用户视图下执行access-limit命令扩大用户数上限（下例中为20）。
<Sysname> system-view
[Sysname] local-user test class manage
[Sysname-luser-manage-test] access-limit 20
- 在用户视图下执行free命令强制其它在线用户下线（下例中为强制释放VTY1上建立的所有连接）。
<Sysname> free line vty 1
Are you sure to free line vty1? [Y/N]:y
[OK]
¡ 如果access-limit配置不存在，或者用户数未达到上限值，则继续定位。
(9) 检查指定登录类型的在线用户数是否到达上限。
a. 在系统视图下执行display this命令查看是否存在aaa session-limit的配置，若无此配置，则说明采用了缺省值32。
#
aaa session-limit ftp 33
domain default enable system
#
b. 执行display users查看当前用户线的用户登录情况，确认是否已到用户数上限。
c. 如果在线用户数到达上限，则根据需要采取以下措施之一：
- 在系统视图下执行aaa session-limit命令扩大用户数上限。
- 在用户视图下执行free命令强制其它在线用户下线。
(10) 检查本地lauth.dat文件是否正常。
开启全局密码管理功能后，设备会自动生成lauth.dat文件记录本地用户的认证、登录信息。如果手工删除或修改该文件，会造成本地认证异常。因此，请首先执行display password-control命令查看设备上是否开启了全局密码管理功能。
¡ 如果该文件不存在、大小为0或者很小（若小于20B，则大概率发生了异常），请优先联系技术支持人员协助处理，若当前配置需求紧迫，可尝试重新开启全局密码管理功能来解决此问题。
<Sysname> dir
Directory of flash: (EXT4)
0 drw- - Aug 16 2021 11:45:37 core
1 drw- - Aug 16 2021 11:45:42 diagfile
2 drw- - Aug 16 2021 11:45:57 dlp
3 -rw- 713 Aug 16 2021 11:49:41 ifindex.dat
4 -rw- 12 Sep 01 2021 02:40:01 lauth.dat
...
<Sysname> system-view
[Sysname] undo password-control enable
[Sysname] password-control enable
¡ 若未开启，则忽略此步骤。
(11) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息、诊断信息。
¡ 打开Local-Server调试信息开关（通过debugging local-server all命令），收集设备的调试信息。
· hh3cLogInAuthenFailure (1.3.6.1.4.1.25506.2.2.1.1.3.0.3)
· 模块名：HH3C-SSH-MIB
· hh3cSSHUserAuthFailure (1.3.6.1.4.1.25506.2.22.1.3.0.1)
· LOGIN/5/LOGIN_FAILED
· SSHS/6/SSHS_AUTH_FAIL
管理员采用RADIUS认证登录设备失败。
本类故障的常见原因主要包括：
· 用户线下的认证方式配置错误。
· VTY用户线下支持的协议类型不正确。
· ISP域下配置的认证、授权、计费方案错误。
· 与RADIUS服务器交互失败。
· RADIUS服务器下发的Login-Service属性值不正确。
· RADIUS服务器未下发用户角色权限。
本类故障的诊断流程如图4-14所示。
图4-14 RADIUS认证登录失败的故障诊断流程图
Web、NETCONF over SOAP、FTP类登录故障无需关心用户线（类）下的配置，其它排障步骤相同。
(1) 检查用户线下的配置。
执行line vty first-number [ last-number ]命令进入指定的VTY用户线视图，并通过display this命令查看如下配置是否准确：
¡ authentication-mode是否配置为scheme。
¡ 对于Telnet登录：protocol inbound是否配置为telnet或为缺省情况。
¡ 对于SSH登录：protocol inbound是否配置为ssh或为缺省情况。
(2) 检查用户线类下的配置。
(3) 用户线视图下的配置优先于用户线类视图下的配置。若用户线视图下未配置，则需要继续检查用户线类视图下的配置。
(4) 执行line class vty命令进入VTY用户线类视图，并通过display this命令查看如下配置是否准确：
¡ authentication-mode是否配置为scheme。
¡ 对于Telnet登录：protocol inbound是否配置为telnet或为缺省情况。
¡ 对于SSH登录：protocol inbound是否配置为ssh或为缺省情况。
如果用户线和用户线类下的配置均不准确，请按照需要，在指定的用户线或用户线类下设置认证方案为scheme，并设置用户登录支持的协议类型。
(5) 检查ISP域下的认证、授权、计费方案配置是否准确。
执行display domain命令，查看显示信息：
¡ 如果用户的登录用户名中携带了域名（假设为test），则查看该域下的“Login authentication scheme:”字段取值是否为“RADIUS=xx”。如果该域下无“Login authentication scheme:”字段，再查看“Default authentication scheme:”字段取值是否为“RADIUS=xx”。
<Sysname> display domain test
Domain: test
State: Active
Login authentication scheme: RADIUS=rds
Default authentication scheme: Local
Default authorization scheme: Local
Default accounting scheme: Local
Accounting start failure action: Online
Accounting update failure action: Online
Accounting quota out action: Offline
Service type: HSI
Session time: Exclude idle time
NAS-ID: N/A
DHCPv6-follow-IPv6CP timeout: 60 seconds
Authorization attributes:
Idle cut: Disabled
Session timeout: Disabled
¡ 如果用户的登录用户名中未携带域名，则在系统视图下执行display this命令查看是否存在domain default enable isp-name配置（下例中缺省域名为system）。
#
domain default enable system
#
- 如果存在该配置，则执行display domain命令查看isp-name域下的“Login authentication scheme:”字段取值是否为“RADIUS=xx”。如果该域下无“Login authentication scheme:”字段，再查看“Default authentication scheme:”字段取值是否为“RADIUS=xx”。
- 如果不存在该配置，则执行display domain命令查看system域下的“Login authentication scheme:”字段取值是否为“RADIUS=xx”。如果system域下无“Login authentication scheme:”字段，再查看“Default authentication scheme:”字段取值是否为“RADIUS=xx”。
授权、计费配置确认方式与认证类似，不再赘述。如果以上配置不准确，请在相关ISP域下配置Login用户采用RADIUS认证/授权/计费方案（下例中认证/授权/计费均采用RADIUS方案rd1）。
<Sysname> system-view
[Sysname] domain name test
[Sysname-isp-test] authentication login radius-scheme rd1
[Sysname-isp-test] authorization login radius-scheme rd1
[Sysname-isp-test] accounting login radius-scheme rd1
(6) 通过RADIUS的调试信息辅助排查如下故障。
¡ 执行debugging radius packet命令打开RADIUS报文调试信息开关，如果系统打印Authentication reject类的报文调试信息，则表示用户的认证请求被服务器拒绝。因此，需要继续查看RADIUS服务器上记录的认证日志，并通过日志中描述的失败原因联系服务器管理员进行相应的处理。
¡ 执行debugging radius error命令打开RADIUS错误调试信息开关，如果系统打印错误调试信息“Invalid packet authenticator.”，则表示设备与服务器的共享密钥不匹配，可以尝试在RADIUS方案下设置与服务器匹配的共享密钥。
¡ 执行debugging radius event命令打开RADIUS事件调试信息开关，如果系统打印事件调试信息“Response timed out. ”，则表示设备与服务器之间不可达，可以尝试排查设备和服务器中间链路不通的问题。
(7) 检查RADIUS服务器是否下发了正确的用户角色权限。
执行debugging radius all命令打开所有RADIUS调试信息开关后，如果用户输入用户名和密码后连接直接断开，且没有异常的RADIUS事件调试信息以及RADIUS错误调试信息输出，则有可能是RADIUS服务器未给用户下发用户角色或下发的用户角色错误导致。此时，可以查看RADIUS报文调试信息中是否包含“shell:roles="xx"”或“Exec-Privilege=xx”字段。
¡ 如果不包含，则表示RADIUS服务器未给用户下发用户角色权限，则可以选用如下方法之一解决：
- 在设备侧，可以通过执行role default-role enable rolename命令使能缺省用户角色授权功能，使得用户在没有被服务器授权任何角色的情况下，具有一个缺省的用户角色。
<Sysname> system-view
[Sysname] role default-role enable
- 联系RADIUS服务器管理员，为用户下发合适的用户角色。
¡ 如果包含，但指定的用户角色在设备上不存在，则需要联系RADIUS服务器管理员修改用户角色设置或者在设备上通过user-role role-name命令创建对应的用户角色。
(8) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息、诊断信息。
¡ 打开RADIUS调试信息开关（通过debugging radius all命令），收集设备的调试信息。
模块名：HH3C-UI-MAN-MIB
· hh3cLogInAuthenFailure (1.3.6.1.4.1.25506.2.2.1.1.3.0.3)
· 模块名：HH3C-SSH-MIB
· hh3cSSHUserAuthFailure (1.3.6.1.4.1.25506.2.22.1.3.0.1)
· LOGIN/5/LOGIN_AUTHENTICATION_FAILED
· LOGIN/5/LOGIN_FAILED
· SSHS/6/SSHS_AUTH_FAIL
管理员采用HWTACACS认证登录设备失败。
本类故障的常见原因主要包括：
· 用户线下的认证方式配置错误。
· VTY用户线下支持的协议类型不正确。
· ISP域下配置的认证、授权、计费方案错误。
· 与HWTACACS服务器交互失败。
· HWTACACS服务器未下发用户角色权限。
本类故障的诊断流程如图4-15所示。
图4-15 HWTACACS认证登录失败的故障诊断流程图
Web、NETCONF over SOAP、FTP类登录故障无需关心用户线（类）下的配置，其它排障步骤相同。
(1) 检查用户线下的配置。
执行line vty first-number [ last-number ]命令进入指定的VTY用户线视图，并通过display this命令查看如下配置是否准确：
¡ authentication-mode是否配置为scheme。
¡ 对于Telnet登录：protocol inbound是否配置为telnet或为缺省情况。
¡ 对于SSH登录：protocol inbound是否配置为ssh或为缺省情况。
(2) 检查用户线类下的配置。
(3) 用户线视图下的配置优先于用户线类视图下的配置。若用户线视图下未配置，则需要继续检查用户线类视图下的配置。
(4) 执行line class vty命令进入VTY用户线类视图，并通过display this命令查看如下配置是否准确：
¡ authentication-mode是否配置为scheme。
¡ 对于Telnet登录：protocol inbound是否配置为telnet或为缺省情况。
¡ 对于SSH登录：protocol inbound是否配置为ssh或为缺省情况。
¡ 如果用户线和用户线类下的配置均不准确，请按照需要，在指定的用户线或用户线类下设置认证方案为scheme，并设置用户登录支持的协议类型。
(5) 检查ISP域下的认证、授权、计费方案配置是否准确。
执行display domain命令，查看显示信息：
¡ 如果用户的登录用户名中携带了域名（假设为test），则查看该域下的“Login authentication scheme:”字段取值是否为“HWTACACS=xx”。如果该域下无“Login authentication scheme:”字段，再查看“Default authentication scheme:”字段取值是否为“HWTACACS=xx”。
<Sysname> display domain test
Domain: test
State: Active
Login authentication scheme: HWTACACS=hwt1
Default authentication scheme: Local
Default authorization scheme: Local
Default accounting scheme: Local
Accounting start failure action: Online
Accounting update failure action: Online
Accounting quota out action: Offline
Service type: HSI
Session time: Exclude idle time
NAS-ID: N/A
DHCPv6-follow-IPv6CP timeout: 60 seconds
Authorization attributes:
Idle cut: Disabled
Session timeout: Disabled
¡ 如果用户的登录用户名中未携带域名，则在系统视图下执行display this命令查看是否存在domain default enable isp-name配置。（下例中缺省域名为system）。
#
domain default enable system
#
- 如果存在该配置，则执行display domain命令查看isp-name域下的“Login authentication scheme:”字段取值是否为“HWTACACS=xx”。如果该域下无“Login authentication scheme:”字段，再查看“Default authentication scheme:”字段取值是否为“HWTACACS=xx”。
- 如果不存在该配置，则执行display domain命令查看system域下的“Login authentication scheme:”字段取值是否为“HWTACACS=xx”。如果system域下无“Login authentication scheme:”字段，再查看“Default authentication scheme:”字段取值是否为“HWTACACS=xx”。
授权、计费配置确认方式与认证类似，不再赘述。如果以上配置不准确，请在相关ISP域下配置Login用户采用HWTACACS认证/授权/计费方案（下例中认证/授权/计费均采用HWTACACS方案hwt1）。
<Sysname> system-view
[Sysname] domain test
[Sysname-isp-test] authentication login hwtacacs-scheme hwt1
[Sysname-isp-test] authorization login hwtacacs-scheme hwt1
[Sysname-isp-test] accounting login hwtacacs-scheme hwt1
(6) 通过HWTACACS的调试信息辅助排查如下故障。
¡ 执行debugging hwtacacs send-packet和debugging hwtacacs receive-packet命令打开HWTACACS报文发送/接收调试信息，如果系统打印应答报文调试信息中包含“status: STATUS_FAIL”，则表示用户的认证请求被服务器拒绝。因此，需要继续查看HWTACACS服务器认证日志中描述的失败原因，并根据具体的失败原因继续定位。
¡ 执行debugging hwtacacs error命令打开HWTACACS错误调试信息开关，如果系统打印错误调试信息“Failed to get available server.”，则通常表示设备与服务器的共享密钥不匹配，可以尝试在HWTACACS方案下设置与服务器匹配的共享密钥。
¡ 执行debugging hwtacacs event命令打开HWTACACS事件调试信息开关，如果系统打印事件调试信息“Connection timed out.”，则表示设备与服务器之间不可达，可以尝试排查设备和服务器中间链路不通的问题。
(7) 检查HWTACACS服务器是否下发了正确的用户角色权限。
执行debugging hwtacacs all命令打开所有HWTACACS调试信息开关后，如果发现客户端登录时直接断开连接，且没有异常的HWTACACS事件调试信息以及HWTACACS错误调试信息输出，则有可能是HWTACACS服务器未给用户下发用户角色权限导致。此时，可以查看HWTACACS的接收报文调试信息是否包含“priv-lvl=xx”或“roles=xx”字段。
¡ 如果不包含，则表示HWTACACS服务器未给用户下发用户角色权限，则可以选用如下方法之一解决：
- 在设备侧，可以通过执行role default-role enable rolename命令使能缺省用户角色授权功能，使得用户在没有被服务器授权任何角色的情况下，具有一个缺省的用户角色。
<Sysname> system-view
[Sysname] role default-role enable
- 联系HWTACACS服务器管理员，为用户下发合适的用户角色。HWTACACS服务器上的授权角色配置必须满足格式：roles="name1 name2 namen"，其中name1、name2、namen为要授权下发给用户的用户角色，可为多个，并使用空格分隔。
¡ 如果包含，但指定的用户角色在设备上不存在，则需要联系RADIUS服务器管理员修改用户角色设置或者在设备上通过user-role role-name命令创建对应的用户角色。
(8) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息、诊断信息。
¡ 打开HWTACACS调试信息开关（通过debugging hwtacacs all命令），收集设备的调试信息。
模块名：HH3C-UI-MAN-MIB
· hh3cLogInAuthenFailure (1.3.6.1.4.1.25506.2.2.1.1.3.0.3)
· 模块名：HH3C-SSH-MIB
· hh3cSSHUserAuthFailure (1.3.6.1.4.1.25506.2.22.1.3.0.1)
· LOGIN/5/LOGIN_AUTHENTICATION_FAILED
· LOGIN/5/LOGIN_FAILED
· SSHS/6/SSHS_AUTH_FAIL
PPPoE用户上线失败或异常下线。
本类故障的常见原因主要包括：
· 用户输入的用户名/密码错误。
· 用户连续认证失败次数达到允许的最大值被设备静默，当前还处于静默期。
· 配置错误。例如未配置IP地址池或配置的IP地址池中IP地址已耗尽等原因导致用户无法获取IP地址。
· 用户已欠费。
本类故障的诊断流程如图5-1所示：
图5-1 PPPoE用户上线失败和异常下线故障诊断流程图
(1) 查看PPPoE用户上线失败原因。
执行命令display aaa online-fail-record查看用户上线失败原因。
<Sysname> display aaa online-fail-record username aaa
Username: aaa
Domain: test
MAC address: 0010-9400-0007
Access type: PPPoE
Access interface: Ten-GigabitEthernet3/1/1
SVLAN/CVLAN: -/-
IP address: -
IPv6 address: -
Online request time: 2019/09/23 14:57:06
Online failure reason: PPP negotiation terminated.
其中Online failure reason显示的是用户上线失败的原因，根据原因可以大概判断故障，为后面的具体定位提供指引。请根据显示的原因查找“11.2 用户上线失败原因和异常下线原因”并按对应原因的处理方法排错。
有些原因是可以直接通过检查配置解决问题的，如Authentication method error、Local authentication request was rejected等。有些上线失败的原因里无法看到记录，请继续执行下一步。
(2) 查看PPPoE用户下线原因。
如果通过步骤1没有查看到用户上线失败原因，可能是用户上线成功后又被下线，此时通过执行display aaa offline-record命令查看用户下线原因进行定位。
<Sysname> display aaa online-fail-record username aaa
Username: aaa
Domain: test
MAC address: 0010-9400-0007
Access type: PPPoE
Access interface: Ten-GigabitEthernet3/1/1
SVLAN/CVLAN: -/-
IP address: 1.1.1.1
IPv6 address: -
Online request time: 2019/09/23 14:57:06
Online failure reason: ppp user request
如果用户上线之后又被下线，会通过Offline reason字段生成用户下线原因，根据此原因可以大概判断故障，为后面的具体定位提个指引。
请根据显示的原因查找“11.2 用户上线失败原因和异常下线原因”并按对应原因的处理方法排错。
如果无法通过display aaa offline-record命令查看用户下线原因，请继续执行下一步。
(3) 检查PPPoE用户相关配置是否正确。
请参考BRAS产品手册排查配置，例如参考相应模块配置手册中“配置任务简介”或“配置举例”进行排查。
¡ 如果配置错误，请更正配置后再尝试上线。
¡ 如果配置正确，但故障仍存在，则继续执行下一行。
(4) 检查用户是否被PPP静默抑制。
执行命令display ppp chasten user命令查看该用户是否被PPP静默抑制。
¡ 如果用户被静默抑制，根据显示的信息，待静默用户的剩余老化时间超时后，重新拨号。
¡ 如果用户没有被抑制，请继续执行下一步。
(5) 打开业务跟踪消息。
使用命令trace access-user打开用户的业务跟踪功能进行用户上线测试，在用户上线过程结束后，查看业务跟踪的消息报文。如果设备没有收到PADI或PADR报文，请检查二层网络是否可达、端口状态是否正常、接入类型是否是二层用户、认证方式是否包括PPP、接口下是否绑定了虚模板等。
(6) 检查用户是否被PPPoE静默抑制。
执行命令display pppoe-server chasten user命令查看该用户是否被PPPoE静默抑制。
¡ 如果用户被抑制，根据显示的信息，待静默用户的剩余老化时间超时后，重新拨号。
¡ 如果用户没有被抑制，请继续执行下一步。
(7) 检查设备故障。
如果出现看不到用户任何业务跟踪消息的情况，请检查以下配置：
¡ 确保设备物理连接均正常。
¡ 确保设备上相应的配置均正确无误。
¡ 确保二层网络配置正确。
¡ 确保报文可以到达设备。
可在Probe视图下执行display hardware internal rxtx packet statistic命令查看产品驱动收发包统计信息，检查用户报文是否上送至BRAS设备。（非vBRAS-CP设备）
在转发与控制分离组网，查看用户报文是否上送至BRAS设备的方法，请参见“9.1 转控分离组网中用户无法上线障故障处理”。
<Sysname> system-view
[Sysname-probe] probe
[Sysname-probe] display hardware internal rxtx packet statistic slot 3 cpu 0
Net port packet loss count:
code counter
Rx packets statistic:
counter success rate
NET ->RXTX : 171883335 171554546 342 pps
Cpu code input list:(Mgment to L1 queue)
code counter success(whitelist/normal)
5 14475 14475(0/14475)
6 2308 2308(0/2308)
17 262 262(0/262)
26 1013133 986703(0/986703)
30 6014064 6014064(0/6014064)
35 282 282(0/282)
37 79280 79280(0/79280)
43 2423 2423(0/2423)
44 44438 44438(0/44438)
45 1181 1181(0/1181)
49 60638 60638(0/60638)
50 25 25(0/25)
51 60361 60361(0/60361)
52 496 496(0/496)
53 115767 115767(115726/41)
54 83228 83228(83228/0)
61 191235 191235(0/191235)
77 12007 11988(0/11988)
99 6041569 6041569(0/6041569)
106 30 30(0/30)
149 158129148 157826808(0/157826808)
175 16985 16985(16979/6)
Callback function packets statistic:
total(r) success(r) total(c) success(c)
MACL: 0 0 0 0
NATL: 0 0 0 0
BFD: 0 0 0 0
(null): 0 0 0 0
Task input pkt statistics:
Task name total success
Main Task : 165540452 165540452
Icmp Task : 30 30
Cpu code input list:(L2 queue to platform)
code counter success drop rate
5 14475 14475 0 0
6 2308 2308 0 0
17 262 262 0 0
26 986703 986703 0 1
35 282 282 0 0
37 79280 79280 0 0
43 2423 2423 0 0
44 44438 44438 0 0
45 1181 1181 0 0
49 60638 60638 0 0
50 25 25 0 0
51 60361 60361 0 0
52 496 496 0 0
53 115767 115767 0 0
54 83228 83228 0 0
61 191235 191235 0 0
77 11988 11988 0 0
99 6041569 6041569 0 12
106 30 30 0 0
149 157826808 157826808 0 314
175 16985 16985 0 0
Cpu code to protocol:
5 ARP_REQ_LOCAL
6 ARP_REL
17 ARP_REQ
26 PPPOE
30 DIAG
35 ND_NA
37 LLDP,CDP
43 ND_NS
44 ND_RS
45 ND_RA
49 OSPF_HELLO,OSPF_LSU,OSPF_LSACK
50 OSPF_DD,OSPF_LSR
51 OSPFV3_HELLO,OSPFV3_LSU,OSPFV3_LSACK
52 OSPFV3_DD,OSPFV3_LSR
53 LDP_HELLO
54 LDP_NOTIF,LDP_INIT,LDP_KPALV,LDP_ADDR,LDP_LABEL
61 DHCP_IPOE,DHCP_SNOOPING,DHCP,DHCPv6_RELAY,DHCPv6_RELS,DHCPv6_SERV
77 IP_SUBNET
99 PPPOE_PPP
106 ICMP,ICMPV6
149 L2TP
175 APP_TELNET
Debug packets statistic:
counter counter rate
NET->RXTX->SERVICE: 0 0 0 pps
SERVICE->RXTX->NET: 0 0 0 pps
failed
MbufTrSend: 0
FoundIfindex: 0
SaveCoreSta: 0
MainCoreSta: 0
TxFailedSta: 0
26和99表示PPPoE、PPPoE_PPP，若26和99收包计数有增加则表示设备已收到PPP/PPPoE报文并已上送平台，可以通过转发的调试开关逐步排查报文丢弃在哪个一层，若此计数没有增加，则执行display hardware internal np pktcnt drop命令查看驱动是否有丢包计数。
<Sysname> system-view
[Sysname-probe] probe
[Sysname-probe] display hardware internal np pktcnt drop slot 3 （不同产品查看丢包计数的命令不太相同）
Current Mcode Type: SIRIUS_RELEASE
The NP 0 is Both NP
Drop packet statistics
32B7 116497 TOPparse total discarded pkts
350F 916677 TOPresolve total discarded pkts
51A 66 PRS Ingress route interface deny L2 forward
56B 384 PRS Ingress Route interface deny L2 forward
63C 403633 RSV Ingress ARP packet FTN or BROADCAST table no ma
tch
63E 372789 RSV Ingress PROTOCOL_MAC and BROADCAST table no mat
ch
641 161878 RSV Ingress PROTOCOL_MAC.THB is set, but BROADCAST
table no match
645 149489 RSV Ingress multicast, MULTICAST.DROP is set
646 144150 RSV Ingress multicast, match MULTICAST default entr
y, but BROADCAST table no match
663 4 RSV Ingress broadcast packets from route port, PROT
OCOL_PORT table no match
若有丢包计数持续增加，则根据丢包原因分析可能问题。
若丢包计数没有增加，报文上送CPU的计数也没有增加，则说明报文没有成功上送至BRAS设备，请收集故障信息并联系技术支持。
只要保证上述配置均是正确的，则通过业务跟踪功能一定可以看到跟踪消息。
如果确认用户上线失败原因是配置问题，请根据跟踪消息检查相应的本地配置。
¡ 对于采用RADIUS认证的用户，需要检查是否正确配置了RADIUS服务器，RADIUS服务器状态是否正常。
¡ 对于采用本地认证的用户，需要检查本地帐号的配置是否正确且没有接入数限制等。
(8) 判断LCP协商是否通过。
可以通过分别在BRAS设备和客户端上（客户端可采用抓包方式）获取协商报文统计信息进行判断，这样可以很快地定位出LCP协商失败是设备的原因还是客户端的原因，或是设备间的配合问题。
<Sysname> display ppp packet statistics
PPP packet statistics in slot 97:
-----------------------------------LCP--------------------------------------
SEND_LCP_CON_REQ : 6185 RECV_LCP_CON_REQ : 6177
SEND_LCP_CON_NAK : 0 RECV_LCP_CON_NAK : 0
SEND_LCP_CON_REJ : 0 RECV_LCP_CON_REJ : 0
SEND_LCP_CON_ACK : 6177 RECV_LCP_CON_ACK : 6000
SEND_LCP_CODE_REJ : 0 RECV_LCP_CODE_REJ : 0
SEND_LCP_PROT_REJ : 0 RECV_LCP_PROT_REJ : 0
SEND_LCP_TERM_REQ : 0 RECV_LCP_TERM_REQ : 0
SEND_LCP_TERM_ACK : 0 RECV_LCP_TERM_ACK : 0
SEND_LCP_ECHO_REQ : 0 RECV_LCP_ECHO_REQ : 0
SEND_LCP_ECHO_REP : 0 RECV_LCP_ECHO_REP : 0
SEND_LCP_FAIL : 0 SEND_LCP_CON_REQ_RETRAN : 185
-----------------------------------IPCP-------------------------------------
SEND_IPCP_CON_REQ : 0 RECV_IPCP_CON_REQ : 0
SEND_IPCP_CON_NAK : 0 RECV_IPCP_CON_NAK : 0
SEND_IPCP_CON_REJ : 0 RECV_IPCP_CON_REJ : 0
SEND_IPCP_CON_ACK : 0 RECV_IPCP_CON_ACK : 0
SEND_IPCP_CODE_REJ : 0 RECV_IPCP_CODE_REJ : 0
SEND_IPCP_PROT_REJ : 0 RECV_IPCP_PROT_REJ : 0
SEND_IPCP_TERM_REQ : 0 RECV_IPCP_TERM_REQ : 0
SEND_IPCP_TERM_ACK : 0 RECV_IPCP_TERM_ACK : 0
SEND_IPCP_FAIL : 0
-----------------------------------IPV6CP-----------------------------------
SEND_IPV6CP_CON_REQ : 0 RECV_IPV6CP_CON_REQ : 0
SEND_IPV6CP_CON_NAK : 0 RECV_IPV6CP_CON_NAK : 0
SEND_IPV6CP_CON_REJ : 0 RECV_IPV6CP_CON_REJ : 0
SEND_IPV6CP_CON_ACK : 0 RECV_IPV6CP_CON_ACK : 0
SEND_IPV6CP_CODE_REJ : 0 RECV_IPV6CP_CODE_REJ : 0
SEND_IPV6CP_PROT_REJ : 0 RECV_IPV6CP_PROT_REJ : 0
SEND_IPV6CP_TERM_REQ : 0 RECV_IPV6CP_TERM_REQ : 0
SEND_IPV6CP_TERM_ACK : 0 RECV_IPV6CP_TERM_ACK : 0
SEND_IPV6CP_FAIL : 0
-----------------------------------OSICP------------------------------------
SEND_OSICP_CON_REQ : 0 RECV_OSICP_CON_REQ : 0
SEND_OSICP_CON_NAK : 0 RECV_OSICP_CON_NAK : 0
SEND_OSICP_CON_REJ : 0 RECV_OSICP_CON_REJ : 0
SEND_OSICP_CON_ACK : 0 RECV_OSICP_CON_ACK : 0
SEND_OSICP_CODE_REJ : 0 RECV_OSICP_CODE_REJ : 0
SEND_OSICP_PROT_REJ : 0 RECV_OSICP_PROT_REJ : 0
SEND_OSICP_TERM_REQ : 0 RECV_OSICP_TERM_REQ : 0
SEND_OSICP_TERM_ACK : 0 RECV_OSICP_TERM_ACK : 0
SEND_OSICP_FAIL : 0
-----------------------------------MPLSCP-----------------------------------
SEND_MPLSCP_CON_REQ : 0 RECV_MPLSCP_CON_REQ : 0
SEND_MPLSCP_CON_NAK : 0 RECV_MPLSCP_CON_NAK : 0
SEND_MPLSCP_CON_REJ : 0 RECV_MPLSCP_CON_REJ : 0
SEND_MPLSCP_CON_ACK : 0 RECV_MPLSCP_CON_ACK : 0
SEND_MPLSCP_CODE_REJ : 0 RECV_MPLSCP_CODE_REJ : 0
SEND_MPLSCP_PROT_REJ : 0 RECV_MPLSCP_PROT_REJ : 0
SEND_MPLSCP_TERM_REQ : 0 RECV_MPLSCP_TERM_REQ : 0
SEND_MPLSCP_TERM_ACK : 0 RECV_MPLSCP_TERM_ACK : 0
SEND_MPLSCP_FAIL : 0
-----------------------------------AUTH-------------------------------------
SEND_PAP_AUTH_REQ : 0 RECV_PAP_AUTH_REQ : 6000
SEND_PAP_AUTH_ACK : 0 RECV_PAP_AUTH_ACK : 0
SEND_PAP_AUTH_NAK : 0 RECV_PAP_AUTH_NAK : 0
SEND_CHAP_AUTH_CHALLENGE: 0 RECV_CHAP_AUTH_CHALLENGE: 0
SEND_CHAP_AUTH_RESPONSE : 0 RECV_CHAP_AUTH_RESPONSE : 0
SEND_CHAP_AUTH_ACK : 0 RECV_CHAP_AUTH_ACK : 0
SEND_CHAP_AUTH_NAK : 0 RECV_CHAP_AUTH_NAK : 0
SEND_PAP_AUTH_FAIL : 0 SEND_CHAP_AUTH_FAIL : 0
比较常见的故障现象：
¡ 某些PPPoE客户端在LCP协商过程中，发送了config-request报文，设备响应并发送config-nak/config-reject报文，此时客户端应当根据设备响应报文修改相应config-request报文中的属性值，但客户端可能一直不改变这些协商属性导致协商失败。这种情况可通过抓包或执行debugging ppp all命令打开调试开关查看什么属性导致协商失败，并针对该属性检查相应配置，确保配置正确。如无法解决该问题，请联系技术支持人员。
¡ 设备配置了CHAP(Challenge-Handshake Authentication Protocol)验证，但客户端只支持PAP验证，所以LCP协商一直不通过导致失败等。这种情况需要在设备上更改CHAP验证为PAP验证。
(9) 判断认证是否通过。
如果是本地认证，认证失败的原因可能是本地帐号不存在、认证域未激活、帐号未激活、帐号类型不一致、接入限制等。
如果是RADIUS认证，认证失败的原因可能是设备没有收到RADIUS回应报文，或者RADIUS认证拒绝。
(10) 判断NCP协商是否通过。
NCP在PPPoE中一般只进行地址的协商，所以NCP协商失败也就是地址协商失败。可以按照本地分配地址、RADIUS分配地址及DHCP分配地址情况，检查相关配置。
(11) 判断计费是否正常。
如果这时用户仍无法上线，则可能是计费故障，最常见的是开始计费失败，此时需要检查设备与AAA服务器之间路由是否可达，以及AAA服务器计费功能配置是否正确。
(12) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
PPPoE代拨用户上线失败或异常下线。
本类故障的常见原因主要包括：
· PPPoE代拨用户对应的校内BRAS用户上线失败或异常下线。
· PPPoE代拨配置错误。例如：
¡ 校内BRAS设备上用于连接运营商BRAS设备的接口上未开启PPPoE代拨功能导致PPPoE代拨用户上线失败。
¡ 校内BRAS设备上为PPPoE代拨接口配置的PPPoE代拨组名称与校内AAA服务器通过COA下发的PPPoE代拨组名称不匹配导致PPPoE代拨用户上线失败。
¡ 在校内BRAS用户的user-group视图下执行undo pppoe-agency forward命令删除PPPoE代拨转发策略导致PPPoE代拨用户下线。
¡ 在校内AAA服务器上通过COA将校内BRAS用户的user-group属性更改为不支持PPPoE代拨功能的user-group，或者在校内BRAS设备的系统视图下执行undo user-group命令删除校内BRAS用户的user-group导致PPPoE代拨用户下线。
· 校内BRAS设备与运营商BRAS设备之间链路故障，例如PPPoE代拨接口DOWN。
· 校内AAA服务器强制PPPoE代拨用户下线。
· 用户流量耗尽、欠费等情况下运营商侧强制PPPoE代拨用户下线。
本类故障的诊断流程如图5-1所示。
图5-2 PPPoE代拨用户上线失败和异常下线故障诊断流程图
(1) 查看PPPoE代拨用户对应的校内BRAS用户是否已成功上线。
在校内BRAS设备上任意视图下执行display access-user命令查看PPPoE代拨用户对应的校内BRAS用户是否已成功上线。
¡ 如果校内BRAS用户上线失败或上线后异常下线，请根据校内BRAS用户采用的接入认证方式（IPoE或PPPoE）并参考“4 用户上线失败和异常下线故障处理”章节对应用户类型的上线失败和异常下线故障处理进行定位，解决校内BRAS用户无法上线问题。
¡ 如果校内BRAS用户正常上线，请继续执行下一步。
(2) 查看PPPoE代拨用户上线失败原因。
在校内BRAS设备上任意视图下执行display aaa online-fail-record命令查看PPPoE代拨用户上线失败原因。
<Sysname> display aaa online-fail-record username aaa
Username: aaa
Domain: test
MAC address: 0010-9400-0007
Access type: PPPoEA
Access interface: Ten-GigabitEthernet3/1/1
SVLAN/CVLAN: -/-
IP address: -
IPv6 address: -
Online request time: 2022/04/23 14:57:06
Online failure reason: Disabled PPPoE agency.
其中Online failure reason显示的是用户上线失败的原因，根据原因可以辅助判断故障。请根据显示的原因查找“9.2 用户上线失败原因和异常下线原因”并按对应原因的处理方法排错。
如上线失败的原因里无法看到记录，请继续执行下一步。
(3) 查看PPPoE代拨用户下线原因。
如果通过display aaa online-fail-record命令没有查看到用户上线失败原因，可能是用户上线成功后又被下线，此时通过在校内BRAS设备上任意视图下执行display aaa offline-record命令查看PPPoE代拨用户下线原因进行定位。
<Sysname> display aaa online-fail-record username aaa
Username: aaa
Domain: test
MAC address: 0010-9400-0007
Access type: PPPoEA
Access interface: Ten-GigabitEthernet3/1/1
SVLAN/CVLAN: -/-
IP address: 1.1.1.1
IPv6 address: -
Online request time: 2022/04/23 14:59:06
Online failure reason: The user group of the BRAS user changed
如果用户上线之后又被下线，会通过Offline reason字段生成用户下线原因，根据此原因可以大概判断故障，为后面的具体定位提个指引。
请根据显示的原因查找“9.2 用户上线失败原因和异常下线原因”并按对应原因的处理方法排错。
如果无法通过display aaa offline-record命令查看用户下线原因，请继续执行下一步。
(4) 基于RADIUS调试信息进行故障定位
如果上述步骤仍没有查看到相关原因，此时可在校内BRAS设备上的用户视图下执行debugging radius all命令打开RADIUS调试信息开关，通过查看调试信息中的“Reply-Message”字段取值进行故障定位。
“Reply-Message”字段取值即为PPPoE代拨失败的原因，请根据显示的原因查找“9.2 用户上线失败原因和异常下线原因”并按对应原因的处理方法排错。
(5) 查看校内BRAS设备是否收到校内AAA服务器发送的代拨请求。
在校内BRAS设备上任意视图下执行display radius statistics命令查看BRAS设备和校内AAA服务器之间交互的PPPoE代拨报文统计信息。
¡ 如果“COA requests”字段取值为0（或者多次显示发现该字段取值没有变化），则表示校内BRAS设备未收到校内AAA服务器发送的代拨请求，此时，请检查AAA服务器上PPPoE代拨用户相关设置是否正确，解决校内AAA服务器不发送代拨请求问题。
¡ 如果“COA requests”字段取值非0且多次显示该字段取值有变化，请继续执行下一步。
(6) 查看校内BRAS设备是否可以为校内用户提供PPPoE代拨服务。
在校内BRAS设备上任意视图下执行display pppoe-agency packet statistics命令查看PPPoE代拨的协商报文统计信息。
¡ 如果“SEND_PADI_PKT”字段取值为0（或者多次显示发现该字段取值没有变化），则表示在校内BRAS用户上线后并未触发代拨流程，请参照PPPoE配置指导做如下检查，解决无法触发代拨流程问题。
- 确保校内BRAS设备上用于连接运营商BRAS设备的接口开启了PPPoE代拨功能。
- 确保根据校内AAA服务器通过COA为校内BRAS用户授权的代拨组名称能够在BRAS设备上查找到对应的代拨接口，并且代拨接口为UP状态。
- 确保校内BRAS用户的user-group视图下正确配置了PPPoE代拨转发策略。
¡ 如果“SEND_PADI_PKT”字段取值非0且多次显示该字段取值有变化，但“RECV_PADO_PKT”字段取值为0（或者多次显示发现该字段取值没有变化），则表示在校内BRAS用户上线后触发了PPPoE代拨流程，但校内BRAS设备未收到运营商侧BRAS设备回应的PPPoE协议报文。请参照PPPoE配置指导做如下检查，解决校内BRAS设备无法收到运营商侧BRAS设备回应报文的问题。
- 确保运营商BRAS设备上用于连接校内BRAS设备的接口开启了PPPoE server功能。
- 确保运营商BRAS设备上用于连接校内BRAS设备的接口为UP状态。
¡ 如果校内BRAS设备收发PPPoE代拨的PPPoE协商报文均正常，请继续执行下一步。
(7) 在运营商BRAS侧进行故障排查。
对于运营商BRAS设备而言，校内PPPoE代拨用户就是一个普通的PPPoE用户，请在运营商BRAS侧并参考“4.1 PPPoE用户上线失败和异常下线故障处理”进行故障排查。
如排查完毕，故障仍存在，请继续执行下一步。
(8) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
无
无
PPPoE代拨组网中，已开通运营商“代拨”账号的校内用户采用IPoE或PPPoE方式上线后，仅可以访问校内网，但无法访问外网。
本类故障的常见原因主要包括：
· 校内BRAS用户对应的PPPoE代拨用户未上线。
· 校内BRAS设备上的PPPoE代拨转发策略配置错误。
· 校内BRAS设备上的PPPoE代拨转发策略配置正确，但策略中的ACL规则应用失败。
· 运营商侧BRAS问题。
本类故障的诊断流程如图8-2所示。
图5-3 PPPoE代拨组网中校内用户无法访问外网故障诊断流程图
(1) 查看校内BRAS用户对应的PPPoE代拨用户是否已成功上线。
在校内BRAS设备上任意视图下执行display access-user命令查看校内BRAS用户对应的PPPoE代拨用户是否已成功上线。
¡ 如果PPPoE代拨用户未上线，请根据“5.1 PPPoE用户上线失败和异常下线故障处理”，解决PPPoE代拨用户上线问题。
¡ 如果PPPoE代拨用户正常上线，请继续执行下一步。
(2) 检查PPPoE代拨转发策略配置是否正确。
在校内BRAS设备上检查代拨校内BRAS用户所属user-group的用户组视图下pppoe-agency forward { ipv4 | ipv6 } acl { acl-number | name acl-name }命令中指定的ACL规则是否配置正确。
¡ 若ACL规则配置错误（例如PPPoE代拨转发策略引用的ACL规则中不允许指定user-group参数，但配置ACL规则时却指定了user-group参数），请更正配置。
¡ 若ACL规则配置正确，请继续执行下一步。
(3) 检查PPPoE代拨转发策略中指定的ACL规则否应用成功。
在校内BRAS设备上任意视图下执行display pppoe-agency { ipv4 | ipv6 } acl statistics命令查看PPPoE代拨转发策略中指定的ACL规则是否应用成功。
¡ 若ACL规则应用失败，请根据显示的不同失败原因分别做如下处理：
- 若显示失败原因是“Hardware-count (Failed)”，请联系技术支持人员。
- 若显示失败原因是“Hardware-count(Not enough resources to complete the operation.)”，请在系统视图下执行display qos-acl resource命令收集当前ACL资源使用情况并联系技术支持人员。
- 若显示失败原因是“Hardware-count(The operation is not supported.)”，请参照产品手册检查是否满足产品软硬件限制要求，例如校内BRAS接入接口所在单板是否支持PPPoE代拨功能。
¡ 若ACL规则应用成功，请继续执行下一步。
(4) 在运营商侧BRAS进行故障排查
对于运营商BRAS设备而言，校内PPPoE代拨用户就是一个普通的PPPoE用户，请在运营商BRAS侧并参考“7.2 用户获取到IP地址后无法上网故障处理”进行故障排查。
如排查完毕，故障仍存在，请继续执行下一步。
(5) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
无
无
L2TP用户上线失败或异常下线。
本类故障的常见原因主要包括：
· LAC与LNS之间网络层转发不通。
· LAC与LNS之间建立隧道的业务板不支持L2TP功能。
· LAC或LNS未使能L2TP。
· LAC和LNS的L2TP组及属性配置不匹配。
· LAC和LNS的隧道认证方式或密码不一致。
· LAC端PPPoE接入业务故障。
· LAC和LNS端PPP认证方式不一致。
· LNS端配置了对应LAC类型的L2TP组，导致当前设备的角色变成了同时作为LNS和LAC的LTS（L2TP Tunnel Switch，L2TP隧道交换）设备。
· LNS端IP地址池配置错误，未对用户分配IP地址。
本类故障的诊断流程如图5-4所示：
图5-4 L2TP用户上线失败和异常下线故障诊断流程图
(1) 检查LAC端PPPoE接入业务是否正常。
具体方法可参见“5.1 PPPoE用户上线失败和异常下线故障处理”。
如果PPPoE接入业务正常，而故障现象仍未消除，请继续执行下一步。
(2) 在LNS端查看L2TP用户上下线失败原因。
¡ 执行命令display aaa online-fail-record查看用户上线失败原因。其中Online failure reason显示的是用户上线失败的原因，根据原因可以大概判断故障，为后面的具体定位提供指引。
¡ 如果没有查看到用户上线失败原因，可能是用户上线成功后又被下线，此时通过执行display aaa offline-record命令查看用户下线原因进行定位。如果无法通过display aaa offline-record命令查看用户下线原因，请继续执行下一步。
(3) 检查LAC端是否可以ping通LNS。
¡ 如果可以ping通，说明LAC和LNS之间网络层连通正常，请继续执行下一步。
¡ 如果ping不通，请检查LAC和LNS之间的网络层连通性。
(4) 检查LAC和LNS端建立隧道的业务板是否支持L2TP功能。
在LAC和LNS端分别执行display device命令，查看建立L2TP隧道的业务板类型。
¡ 如果是支持L2TP功能的业务板类型，请继续执行下一步。
¡ 如果不是支持L2TP功能的业务板类型，请结合组网应用情况，评估是否允许调整组网（例如将业务切换到支持L2TP功能的业务板），组网调整完成后如果故障现象仍未消除，请继续执行下一步。
(5) 检查LAC和LNS端是否使能了L2TP。
在LAC和LNS端分别执行display current-configuration命令，查看结果中是否显示“l2tp enable”。
¡ 如果显示“l2tp enable”，则说明L2TP已经被正确使能，请继续执行下一步。
¡ 如果未显示“l2tp enable”，则需要在设备上配置l2tp enable命令使能L2TP，配置完成后如果故障现象仍未消除，请继续执行下一步。
(6) 检查LAC端和LNS端L2TP组配置的属性是否正确。
¡ LAC端
在LAC端上执行display l2tp-group verbose命令，查看显示信息中“LNS IP”项，确认所指定的LNS地址是否与实际的LNS端地址一致。如果地址不一致，需要通过lns-ip命令将地址配置成一致。
¡ LNS端
在LNS端上执行display l2tp-group verbose命令，查看如下几项：
- 显示信息中“Remote tunnel name”项，确认LNS端L2TP组中配置的Tunnel名称是否与LAC端配置的名称一致。
- 显示信息中“Local IP address”项，确认是否与LAC端lns-ip配置的地址一致。
上述L2TP组属性均设置正确后如果故障现象仍未消除，请继续执行下一步。
(7) 检查LAC和LNS端是否正确配置了隧道验证和相符的验证密码。
在LAC端和LNS端分别执行display l2tp-group verbose命令，查看“Tunnel auth”项，查看隧道两端的验证方案是否一致。如果不一致，则需要在L2TP组视图下通过tunnel authentication命令配置一致。
¡ 如果配置了隧道认证，需要确认在LAC和LNS端所配置的密码一致，如果不一致，需要在L2TP组视图下通过tunnel password命令进行设置。
¡ 如果隧道两端的认证方式和密码均一致，而故障现象仍未消除，请继续执行下一步。
(8) 检查LAC和LNS端PPP认证方式是否一致。
在LAC和LNS端分别执行display current-configuration interface virtual-template number命令，查看结果中显示的“ppp authentication-mode”是否一致。
¡ 如果显示不一致，请通过interface virtual-template命令进入虚拟模板接口视图，通过ppp authentication-mode命令配置认证方式。
¡ 如果显示一致，请继续执行下一步。
(9) 检查LNS端是否存在对应的LAC类型的L2TP组。
在LNS端查看LAC类型的l2tp-group组，查看建立隧道触发条件user项配置。
¡ 如果不存在与LAC端相同的建立隧道触发条件，请继续执行下一步。
¡ 如果存在与LAC端相同的建立隧道触发条件，请通过undo user命令删除，配置删除后，如果障现象仍未消除，请继续执行下一步。
(10) 检查用户是否分配到IP地址。
¡ 如果用户未分配到IP地址，需要在LNS上配置正确的地址池。
¡ 如果用户分配到IP地址，而故障现象仍未消除，请继续执行下一步。
(11) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
本章主要介绍IPoE用户无法上线的通用故障的定位方法。DHCP用户、NDRS用户、静态用户、IPoE web用户的详细故障定位方法，具体请参见相应章节的故障处理。
IPoE用户上线失败或异常下线。
本类故障的常见原因主要包括：
· 认证域配置错误导致认证失败。
· IP地址池或DHCP服务器配置错误导致无法获取IP地址。
本类故障的诊断流程如图5-5所示：
图5-5 IPoE用户上线失败和异常下线故障诊断流程图
(1) 查看IPoE用户上线失败原因。
执行命令display aaa online-fail-record查看用户上线失败原因。
<Sysname> display aaa online-fail-record username aaa
Username: aaa
Domain: test
MAC address: 0010-9400-0007
Access type: IPoE
Access interface: Ten-GigabitEthernet3/1/1
SVLAN/CVLAN: -/-
IP address: -
IPv6 address: -
Online request time: 2019/09/23 14:57:06
Online failure reason: DHCP with server no response
其中Online failure reason显示的是用户上线失败的原因，根据原因可以大概判断故障，为后面的具体定位提供指引。
请根据显示的原因查找“11.2 用户上线失败原因和异常下线原因”并按对应原因的处理方法排错。
(2) 查看IPoE用户下线原因。
如果通过步骤1没有查看到用户上线失败原因，可能是用户上线成功后又被下线，此时通过执行display aaa offline-record命令查看用户下线原因进行定位。
如果用户上线之后又被下线，会通过Offline reason字段生成用户下线原因，根据此原因可以大概判断故障，为后面的具体定位提个指引。
请根据显示的原因查找“11.2 用户上线失败原因和异常下线原因”并按对应原因的处理方法排错。
如果无法通过display aaa offline-record命令查看用户下线原因，请继续执行下一步。
(3) 检查用户是否通过认证。
¡ 如果用户未通过认证，请根据IPoE认证方式，检查所使用的认证域相关配置。
¡ 如果用户通过了认证，请继续执行下一步。
(4) 检查用户是否获取IP地址。
¡ 如果用户未获取到IP地址，请检查IP地址池或DHCP服务器配置，例如DHCP服务是否开启等。
¡ 如果用户获取到IP地址，请继续执行下一步。
(5) 在系统视图下执行trace access-user命令，打开业务跟踪功能，通过跟踪用户上线过程来定位故障。
(6) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
· IPoE DHCP用户上线失败或异常下线。
本类故障的常见原因主要包括：
· 配置错误，比如对于DHCPv6用户，在用户上线接口没有配置M标记等。
· DHCP用户认证失败。
· DHCP用户上线成功后因会话超时等原因被下线。
· DHCP用户被抑制。
· DHCP用户报文未上送成功。
本类故障的诊断流程如图5-6所示：
图5-6 IPoE DHCP用户上线失败和异常下线故障诊断流程图
(1) 查看IPoE DHCP用户上线失败原因。
执行命令display aaa online-fail-record命令查看用户上线失败原因。
<Sysname> display aaa online-fail-record
Total count: 108
Username: 001094500021
Domain: dm1
MAC address: 0010-9450-0021
Access type: IPoE
Access UP ID: 1354
Access interface: XGE3/1/1
SVLAN/CVLAN: -/-
IP address: -
IPv6 address: -
Online request time: 2021/08/15 07:38:15
Online failure reason: DHCP with server no response
Online failure reason字段显示的是用户上线失败原因，如果DHCP用户报文已上送，此处会通过Online fail reason字段生成用户上线失败原因，根据原因可以大概判断故障，为后面的具体定位提供指引。
请根据显示的原因查找“11.2 用户上线失败原因和异常下线原因”并按对应原因的处理方法排错。
(2) 查看IPoE DHCP用户下线原因。
如果通过步骤1没有查看到用户上线失败原因，可能是用户上线成功后又被下线，此时通过执行display aaa offline-record命令查看用户下线原因进行定位。
<Sysname> display aaa offline-record
Total count: 4
Username: 001094500021
Domain: dm1
MAC address: 0010-9450-0021
Access type: IPoE
Access UP ID: 1354
Access interface: XGE3/1/1
SVLAN/CVLAN: -/-
IP address: 9.0.3.1
IPv6 address: -
Online request time: 2021/08/15 08:05:17
Offline time: 2021/08/15 08:09:08
Offline reason: DHCP release
如果用户上线之后又被下线，会通过Offline reason字段生成用户下线原因，根据此原因可以大概判断故障，为后面的具体定位提个指引。
请根据显示的原因查找“11.2 用户上线失败原因和异常下线原因”并按对应原因的处理方法排错。
如果无法通过display aaa offline-record命令查看用户下线原因，请继续执行下一步。
(3) 检查IPoE DHCP用户相关配置是否正确。
请参考BRAS产品手册排查配置，例如参考相应模块配置手册中“配置任务简介”或“配置举例”进行排查。
¡ 如果配置错误，请更正配置后再尝试上线。
¡ 如果配置正确，但故障仍存在，则继续执行下一行。
(4) 查看用户是否被静默抑制。
请从如下角度进行故障排查：
¡ 执行display ip subscriber chasten user quiet命令查看用户是否被静默抑制。如果用户被静默抑制，只需等待用户静默抑制老化后重新拔号上线即可。
¡ 执行display dhcp interface-rate-suppression命令查看用户是否被DHCP接口攻击抑制。如果State字段显示为“Restrain”，则表示用户被静默抑制，则需要考虑是否客户端存在DHCP报文多发情况，请结合现网情况通过dhcp interface-rate-suppression threshold命令合理调整DHCP接口攻击抑制阈值，以避免用户频繁被抑制。
若用户没有被静默抑制，则需要考虑是否是协议报文在上送过程中存在丢失情况，排查报文是否上送BRAS相关模块。
(5) 查看DHCP相关模块是否收到报文。
执行display dhcp-access packet statistics命令查看用户发送的DHCP协议报文是否到达BRAS设备，以排查DHCP协议报文丢失的阶段，然后再根据丢弃的原因进行故障定位。
<Sysname> display dhcp-access packet statistics
Received packets
Received from clients : 32
DHCPDISCOVER : 24
DHCPREQUEST : 4
DHCPDECLINE : 0
DHCPRELEASE : 4
DHCPINFORM : 0
Received from servers : 8
DHCPOFFER : 4
DHCPACK : 4
DHCPNAK : 0
Sent packets
Send to clients : 8
DHCPOFFER : 4
DHCPACK : 4
DHCPNAK : 0
Send to servers : 148135
DHCPDISCOVER : 148127
DHCPREQUEST : 4
DHCPDECLINE : 0
DHCPRELEASE : 4
回显中DHCPDISCOVER字段表示DHCP Discover报文上送到DHCP模块的计数，若此计数有增长，表示报文已上送到DHCP模块，此时可执行下列命令打开业务跟踪消息，根据跟踪消息进行故障定位，并搜集业务跟踪的消息。
¡ 执行命令trace access-user打开用户的业务跟踪功能。
¡ 执行debugging dhcp server packet命令打开DHCP协议报文调试开关。
¡ 执行terminal debugging命令和terminal monitor打开命令行用户终端显示功能。
若计数没有增长，则在用户视图下执行debugging ip subscriber all命令打开IPoE模块的调试开关，查看IPoE接入模块是否收到报文，若IPoE接入模块已收到报文但是将报文丢弃，则根据调试信息详细分析原因。若IPoE接口模块并没有收到报文，则继续执行下一步。
(6) 检查用户报文是否上送至BRAS设备。
Probe视图下执行display hardware internal rxtx packet statistic命令查看产品驱动收发包统计信息。（非vBRAS-CP设备）
在转发与控制分离组网，查看用户报文是否上送至BRAS设备的方法，请参见“9.1 转控分离组网中用户无法上线障故障处理”。
<Sysname> system-view
[Sysname-probe] probe
[Sysname-probe] display hardware internal rxtx packet statistic slot 3 cpu 0
Net port packet loss count:
code counter
Rx packets statistic:
counter success rate
NET ->RXTX : 3177780 3177780 9 pps
Cpu code input list:(Mgment to L1 queue)
code counter success(whitelist/normal)
5 2057 2057(0/2057)
6 2077 2077(0/2077)
17 98 98(0/98)
18 48 48(0/48)
30 2091197 2091197(0/2091197)
35 573 573(0/573)
43 565 565(0/565)
45 4327 4327(0/4327)
49 79488 79488(0/79488)
50 85 85(0/85)
53 69830 69830(69823/7)
54 46567 46567(46566/1)
57 161707 161707(0/161707)
59 13052 13052(13044/8)
60 26280 26280(13953/12327)
61 30 30(0/30)
153 593518 593518(593513/5)
185 4354 4354(0/4354)
194 81927 81927(0/81927)
Callback function packets statistic:
total(r) success(r) total(c) success(c)
MACL: 0 0 0 0
NATL: 0 0 0 0
BFD: 0 0 0 0
(null): 0 0 0 0
Task input pkt statistics:
Task name total success
Main Task : 1086583 1086583
Icmp Task : 0 0
Cpu code input list:(L2 queue to platform)
code counter success drop rate
5 2057 2057 0 0
6 2077 2077 0 0
17 98 98 0 0
18 48 48 0 0
35 573 573 0 0
43 565 565 0 0
45 4327 4327 0 0
49 79488 79488 0 0
50 85 85 0 0
53 69830 69830 0 0
54 46567 46567 0 0
57 161707 161707 0 0
59 13052 13052 0 0
60 26280 26280 0 0
61 30 30 0 0
153 593518 593518 0 1
185 4354 4354 0 0
194 81927 81927 0 0
Cpu code to protocol:
5 ARP_REQ_LOCAL
6 ARP_REL
17 ARP_REQ
18 ARP_REQ_PROXY
30 DIAG
35 ND_NA
43 ND_NS
45 ND_RA
49 OSPF_HELLO,OSPF_LSU,OSPF_LSACK
50 OSPF_DD,OSPF_LSR
53 LDP_HELLO
54 LDP_NOTIF,LDP_INIT,LDP_KPALV,LDP_ADDR,LDP_LABEL
57 ISIS
59 BGP
60 BGP4P_IPV6
61 DHCP_IPOE,DHCP_SNOOPING,DHCP,DHCPv6_RELAY,DHCPv6_RELS,DHCPv6_SERV
153 IP_VSRP
185 VXLAN_GPE
194 CUSP
Debug packets statistic:
counter counter rate
NET->RXTX->SERVICE: 0 0 0 pps
SERVICE->RXTX->NET: 0 0 0 pps
failed
MbufTrSend: 0
FoundIfindex: 0
SaveCoreSta: 0
MainCoreSta: 0
TxFailedSta: 0
61表示DHCP_IPOE,DHCP_SNOOPING,DHCP，若61收包计数有增加则表示设备已收到DHCP报文并已上送平台，可以通过转发的调试开关逐步排查报文丢弃在哪个一层，若此计数没有增加，则执行display hardware internal np pktcnt drop命令查看驱动是否有丢包计数。
<Sysname> system-view
[Sysname-probe] probe
[Sysname-probe] display hardware internal np pktcnt drop slot 3 （不同产品查看丢包计数的命令不太相同）
Current Mcode Type: SIRIUS_RELEASE
The NP 0 is Both NP
Drop packet statistics
32B7 116497 TOPparse total discarded pkts
350F 916677 TOPresolve total discarded pkts
51A 66 PRS Ingress route interface deny L2 forward
56B 384 PRS Ingress Route interface deny L2 forward
63C 403633 RSV Ingress ARP packet FTN or BROADCAST table no ma
tch
63E 372789 RSV Ingress PROTOCOL_MAC and BROADCAST table no mat
ch
641 161878 RSV Ingress PROTOCOL_MAC.THB is set, but BROADCAST
table no match
645 149489 RSV Ingress multicast, MULTICAST.DROP is set
646 144150 RSV Ingress multicast, match MULTICAST default entr
y, but BROADCAST table no match
663 4 RSV Ingress broadcast packets from route port, PROT
OCOL_PORT table no match
若有丢包计数持续增加，则根据丢包原因分析可能问题。
若丢包计数没有增加，报文上送CPU的计数也没有增加，则说明报文没有成功上送至BRAS设备，请继续执行下一步。
(7) 检查设备是否故障。
如果以上情况定位不到原因，请检查以下配置：
¡ 确认设备物理连接均正常。
¡ 确认网络配置正确。
(8) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
IPoE NDRS用户上线失败或异常下线。
本类故障的常见原因主要包括：
· 配置错误，比如上线接口未使能IPv6能力、IPoE接入模式配置错误、未授权IPv6前缀或ND前缀池配置错误等。
· 认证失败。
· 用户被抑制。
· 用户报文未上送成功。
本类故障的诊断流程如图5-7所示：
图5-7 IPoE NDRS用户上线失败和异常下线故障诊断流程图
(1) 查看IPoE NDRS用户上线失败原因。
执行命令display aaa online-fail-record命令查看用户上线失败原因。
<Sysname> display aaa online-fail-record
Username: user1
Domain: dm1
MAC address: 0000-5e00-01cc
Access type: IPoE
Access UP ID: 1353
Access interface: XGE3/1/1
SVLAN/CVLAN: -/-
IP address: -
IPv6 address: -
Online request time: 2021/08/15 06:09:54
Online failure reason: No prefix available
Online failure reason字段显示的是用户上线失败原因，根据原因可以大概判断故障，为后面的具体定位提供指引。
请根据显示的原因查找“11.2 用户上线失败原因和异常下线原因”并按对应原因的处理方法排错。
有些原因是可以直接通过检查配置解决问题的，如Authentication method error、Local authentication request was rejected、No prefix available等。有些上线失败的原因里无法看到记录，请继续执行下一步。
(2) 查看IPoE NDRS用户下线原因。
如果通过步骤1没有查看到用户上线失败原因，可能是用户上线成功后又被下线，此时通过执行display aaa offline-record命令查看用户下线原因进行定位。
如果用户上线之后又被下线，会通过Offline reason字段生成用户下线原因，根据此原因可以大概判断故障，为后面的具体定位提个指引。
请根据显示的原因查找“11.2 用户上线失败原因和异常下线原因”并按对应原因的处理方法排错。
如果无法通过display aaa offline-record命令查看用户下线原因，请继续执行下一步。
(3) 检查IPoE NDRS用户相关配置是否正确。
请参考BRAS产品手册排查配置，例如参考相应模块配置手册中“配置任务简介”或“配置举例”进行排查。
¡ 如果配置错误，请更正配置后再尝试上线。
¡ 如果配置正确，但故障仍存在，则继续执行下一行。
(4) 查看用户是否被静默抑制。
执行display ip subscriber chasten user quiet命令查看用户是否被静默抑制。
如果用户被静默抑制，只需等待用户静默抑制老化后重新拔号上线即可；若用户没有被静默抑制，则需要考虑是否是协议报文在上送过程中存在丢失情况，排查报文是否上送BRAS相关模块。
(5) 查看UCM、IPoE等相关功能模块是否收到报文。
执行下列命令打开业务跟踪消息，根据跟踪消息进行故障定位，并搜集业务跟踪的消息。
¡ 执行命令trace access-user打开用户的业务跟踪功能。
¡ 执行debugging ip subscriber all命令打开IPoE调试开关。
¡ 执行terminal debugging命令和terminal monitor打开命令行用户终端显示功能。
若没有收到报文，则继续执行下一步。
(6) 检查用户报文是否上送至BRAS设备。
Probe视图下执行display hardware internal rxtx packet statistic命令查看产品驱动收发包统计信息。（非vBRAS-CP设备）
在转发与控制分离组网，查看用户报文是否上送至BRAS设备的方法，请参见“9.1 转控分离组网中用户无法上线障故障处理”。
<Sysname> system-view
[Sysname-probe] probe
[Sysname-probe] display hardware internal rxtx packet statistic slot 3 cpu 0
Net port packet loss count:
code counter
Rx packets statistic:
counter success rate
NET ->RXTX : 3177780 3177780 9 pps
Cpu code input list:(Mgment to L1 queue)
code counter success(whitelist/normal)
5 2057 2057(0/2057)
6 2077 2077(0/2077)
17 98 98(0/98)
18 48 48(0/48)
30 2091197 2091197(0/2091197)
35 573 573(0/573)
43 565 565(0/565)
45 4327 4327(0/4327)
49 79488 79488(0/79488)
50 85 85(0/85)
53 69830 69830(69823/7)
54 46567 46567(46566/1)
57 161707 161707(0/161707)
59 13052 13052(13044/8)
60 26280 26280(13953/12327)
61 30 30(0/30)
153 593518 593518(593513/5)
185 4354 4354(0/4354)
194 81927 81927(0/81927)
Callback function packets statistic:
total(r) success(r) total(c) success(c)
MACL: 0 0 0 0
NATL: 0 0 0 0
BFD: 0 0 0 0
(null): 0 0 0 0
Task input pkt statistics:
Task name total success
Main Task : 1086583 1086583
Icmp Task : 0 0
Cpu code input list:(L2 queue to platform)
code counter success drop rate
5 2057 2057 0 0
6 2077 2077 0 0
17 98 98 0 0
18 48 48 0 0
35 573 573 0 0
43 565 565 0 0
45 4327 4327 0 0
49 79488 79488 0 0
50 85 85 0 0
53 69830 69830 0 0
54 46567 46567 0 0
57 161707 161707 0 0
59 13052 13052 0 0
60 26280 26280 0 0
61 30 30 0 0
153 593518 593518 0 1
185 4354 4354 0 0
194 81927 81927 0 0
Cpu code to protocol:
5 ARP_REQ_LOCAL
6 ARP_REL
17 ARP_REQ
18 ARP_REQ_PROXY
30 DIAG
35 ND_NA
43 ND_NS
45 ND_RA
49 OSPF_HELLO,OSPF_LSU,OSPF_LSACK
50 OSPF_DD,OSPF_LSR
53 LDP_HELLO
54 LDP_NOTIF,LDP_INIT,LDP_KPALV,LDP_ADDR,LDP_LABEL
57 ISIS
59 BGP
60 BGP4P_IPV6
61 DHCP_IPOE,DHCP_SNOOPING,DHCP,DHCPv6_RELAY,DHCPv6_RELS,DHCPv6_SERV
153 IP_VSRP
185 VXLAN_GPE
194 CUSP
Debug packets statistic:
counter counter rate
NET->RXTX->SERVICE: 0 0 0 pps
SERVICE->RXTX->NET: 0 0 0 pps
failed
MbufTrSend: 0
FoundIfindex: 0
SaveCoreSta: 0
MainCoreSta: 0
TxFailedSta: 0
若收包计数有增加则表示设备已收到ARP、ND或者未知源IP报文并已上送相关功能模块，若此计数没有增加，则执行display hardware internal np pktcnt drop命令查看驱动是否有丢包计数。
<Sysname> system-view
[Sysname-probe] probe
[Sysname-probe] display hardware internal np pktcnt drop slot 3 （不同产品查看丢包计数的命令不太相同）
Current Mcode Type: SIRIUS_RELEASE
The NP 0 is Both NP
Drop packet statistics
32B7 116497 TOPparse total discarded pkts
350F 916677 TOPresolve total discarded pkts
51A 66 PRS Ingress route interface deny L2 forward
56B 384 PRS Ingress Route interface deny L2 forward
63C 403633 RSV Ingress ARP packet FTN or BROADCAST table no ma
tch
63E 372789 RSV Ingress PROTOCOL_MAC and BROADCAST table no mat
ch
641 161878 RSV Ingress PROTOCOL_MAC.THB is set, but BROADCAST
table no match
645 149489 RSV Ingress multicast, MULTICAST.DROP is set
646 144150 RSV Ingress multicast, match MULTICAST default entr
y, but BROADCAST table no match
663 4 RSV Ingress broadcast packets from route port, PROT
OCOL_PORT table no match
若有丢包计数持续增加，则根据丢包原因分析可能问题。
若丢包计数没有增加，报文上送CPU的计数也没有增加，则说明报文没有成功上送至设备，请继续执行下一步。
(7) 检查设备故障。
如果以上情况定位不到原因，请检查以下配置：
¡ 确认设备物理连接均正常
¡ 确认网络配置正确
(8) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
IPoE静态用户上线失败或异常下线。
本类故障的常见原因主要包括：
· 配置错误。
· 地址占位失败。
· 认证失败。
· 用户被抑制。
· 用户报文未成功上送到BRAS设备。
本类故障的诊断流程如图5-8所示：
图5-8 IPoE静态用户上线失败和异常下线故障诊断流程图
(1) 查看IPoE静态用户上线失败原因。
执行命令display aaa online-fail-record命令查看用户上线失败原因。
<Sysname> display aaa online-fail-record
Username:
Domain:
MAC address: 0000-5e00-01cc
Access type: IPoE
Access UP ID: 1353
Access interface: XGE3/1/1
SVLAN/CVLAN: -/-
IP address: 2.2.2.9
IPv6 address: -
Online request time: 2021/08/15 06:09:54
Online failure reason: static user not config
Online failure reason字段显示的是用户上线失败原因，根据原因可以大概判断故障，为后面的具体定位提供指引。
请根据显示的原因查找“11.2 用户上线失败原因和异常下线原因”并按对应原因的处理方法排错。
有些原因是可以直接通过检查配置解决问题的，如Authentication method error、Local authentication request was rejected 、Static user not config等。有些上线失败的原因里无法看到记录，请继续执行下一步。
(2) 查看IPoE静态用户下线原因。
如果通过步骤1没有查看到用户上线失败原因，可能是用户上线成功后又被下线，此时通过执行display aaa offline-record命令查看用户下线原因进行定位。
如果用户上线之后又被下线，会通过Offline reason字段生成用户下线原因，根据此原因可以大概判断故障，为后面的具体定位提个指引。
请根据显示的原因查找“11.2 用户上线失败原因和异常下线原因”并按对应原因的处理方法排错。
如果无法通过display aaa offline-record命令查看用户下线原因，请继续执行下一步。
(3) 检查IPoE静态用户相关配置是否正确。
请参考BRAS产品手册排查配置，例如参考相应模块配置手册中“配置任务简介”或“配置举例”进行排查。
¡ 如果配置错误，请更正配置后再尝试上线。
¡ 如果配置正确，但故障仍存在，则继续执行下一行。
(4) 查看用户是否被静默抑制。
· 执行display ip subscriber chasten user quiet命令查看用户是否被静默抑制。
· 如果用户被静默抑制，只需等待用户静默抑制老化后重新拔号上线即可；若用户没有被静默抑制，则需要考虑是否是协议报文在上送过程中存在丢失情况，排查报文是否上送BRAS相关模块。
(5) 查看相关组件是否收到报文。
¡ 若是未知源IP触发静态用户上线，则执行debugging ip subscriber packet命令打开IPoE的报文收发调试开关，并根据调试信息进行定位。
¡ 若是ARP触发静态用户上线，则执行debugging arp packet interface ten-gigabitethernet xxx打开ARP的报文收发调试开关，并根据调试信息进行定位。
¡ 若是ND报文触发静态用户上线，则执行debugging ipv6 nd packet interface ten-gigabitethernet xxx命令打开ND的报文收发调试开关，并根据调试信息进行定位。
¡ 执行下列命令打开业务跟踪消息，根据跟踪消息进行故障定位，并搜集业务跟踪的消息。
- 执行命令trace access-user打开用户的业务跟踪功能。
- 执行debugging ip subscriber all命令打开IPoE调试开关。
- 执行terminal debugging命令和terminal monitor打开命令行用户终端显示功能。
¡ 若没有收到报文，则继续执行下一步。
(6) 检查用户报文是否上送至BRAS设备。
Probe视图下执行display hardware internal rxtx packet statistic命令查看产品驱动收发包统计信息。（非vBRAS-CP设备）
在转发与控制分离组网，查看用户报文是否上送至BRAS设备的方法，请参见“9.1 转控分离组网中用户无法上线障故障处理”。
<Sysname> system-view
[Sysname-probe] probe
[Sysname-probe] display hardware internal rxtx packet statistic slot 3 cpu 0
Net port packet loss count:
code counter
Rx packets statistic:
counter success rate
NET ->RXTX : 3177780 3177780 9 pps
Cpu code input list:(Mgment to L1 queue)
code counter success(whitelist/normal)
5 2057 2057(0/2057)
6 2077 2077(0/2077)
17 98 98(0/98)
18 48 48(0/48)
30 2091197 2091197(0/2091197)
35 573 573(0/573)
43 565 565(0/565)
45 4327 4327(0/4327)
49 79488 79488(0/79488)
50 85 85(0/85)
53 69830 69830(69823/7)
54 46567 46567(46566/1)
57 161707 161707(0/161707)
59 13052 13052(13044/8)
60 26280 26280(13953/12327)
61 30 30(0/30)
153 593518 593518(593513/5)
185 4354 4354(0/4354)
194 81927 81927(0/81927)
Callback function packets statistic:
total(r) success(r) total(c) success(c)
MACL: 0 0 0 0
NATL: 0 0 0 0
BFD: 0 0 0 0
(null): 0 0 0 0
Task input pkt statistics:
Task name total success
Main Task : 1086583 1086583
Icmp Task : 0 0
Cpu code input list:(L2 queue to platform)
code counter success drop rate
5 2057 2057 0 0
6 2077 2077 0 0
17 98 98 0 0
18 48 48 0 0
35 573 573 0 0
43 565 565 0 0
45 4327 4327 0 0
49 79488 79488 0 0
50 85 85 0 0
53 69830 69830 0 0
54 46567 46567 0 0
57 161707 161707 0 0
59 13052 13052 0 0
60 26280 26280 0 0
61 30 30 0 0
153 593518 593518 0 1
185 4354 4354 0 0
194 81927 81927 0 0
Cpu code to protocol:
5 ARP_REQ_LOCAL
6 ARP_REL
17 ARP_REQ
18 ARP_REQ_PROXY
30 DIAG
35 ND_NA
43 ND_NS
45 ND_RA
49 OSPF_HELLO,OSPF_LSU,OSPF_LSACK
50 OSPF_DD,OSPF_LSR
53 LDP_HELLO
54 LDP_NOTIF,LDP_INIT,LDP_KPALV,LDP_ADDR,LDP_LABEL
57 ISIS
59 BGP
60 BGP4P_IPV6
61 DHCP_IPOE,DHCP_SNOOPING,DHCP,DHCPv6_RELAY,DHCPv6_RELS,DHCPv6_SERV
153 IP_VSRP
185 VXLAN_GPE
194 CUSP
Debug packets statistic:
counter counter rate
NET->RXTX->SERVICE: 0 0 0 pps
SERVICE->RXTX->NET: 0 0 0 pps
failed
MbufTrSend: 0
FoundIfindex: 0
SaveCoreSta: 0
MainCoreSta: 0
TxFailedSta: 0
若收包计数有增加则表示设备已收到ARP、ND或者未知源IP报文并已上送平台，可以通过转发的调试开关逐步排查报文丢弃在哪个一层，若此计数没有增加，则执行display hardware internal np pktcnt drop命令查看驱动是否有丢包计数。
<Sysname> system-view
[Sysname-probe] probe
[Sysname-probe] display hardware internal np pktcnt drop slot 3 （不同产品查看丢包计数的命令不太相同）
Current Mcode Type: SIRIUS_RELEASE
The NP 0 is Both NP
Drop packet statistics
32B7 116497 TOPparse total discarded pkts
350F 916677 TOPresolve total discarded pkts
51A 66 PRS Ingress route interface deny L2 forward
56B 384 PRS Ingress Route interface deny L2 forward
63C 403633 RSV Ingress ARP packet FTN or BROADCAST table no ma
tch
63E 372789 RSV Ingress PROTOCOL_MAC and BROADCAST table no mat
ch
641 161878 RSV Ingress PROTOCOL_MAC.THB is set, but BROADCAST
table no match
645 149489 RSV Ingress multicast, MULTICAST.DROP is set
646 144150 RSV Ingress multicast, match MULTICAST default entr
y, but BROADCAST table no match
663 4 RSV Ingress broadcast packets from route port, PROT
OCOL_PORT table no match
若有丢包计数持续增加，则根据丢包原因分析可能问题。
若丢包计数没有增加，报文上送CPU的计数也没有增加，则说明报文没有成功上送至设备，请继续执行下一步。
(7) 检查设备故障。
如果以上情况定位不到原因，请检查以下配置：
¡ 确认设备物理连接均正常。
¡ 确认网络配置正确。
(8) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
用户访问任意非Web认证页面，或者直接访问Web认证页面，无法弹出Web认证页面。
本类故障的常见原因主要包括：
· 认证前域视图下的Web认证页面URL配置错误。
· 认证前域阶段的QoS策略配置错误。
· 主机、服务器和设备之间的路由不通。
· 浏览器开启了HTTP代理功能。
· 用户输入的网址内携带了非标准的TCP端口号。
· 中间网络或DNS服务器出现问题。
· 设备上的HTTPS重定向功能不能正常使用。
· 用户访问的HTTPS协议的网站开启了HSTS（HTTP Strict Transport Security，HTTP严格传输安全协议）功能。
· Portal服务器无法识别转义后的URL特殊字符。
· Portal服务器配置错误。
本类故障的诊断流程如图5-9所示：
图5-9 Web认证页面无法弹出故障诊断流程图
(1) 确认用户是否已在前域上线。
若用户未在前域上线，则解决用户前域上线问题。
(2) 确认Web认证相关置配置是否正确。
请从如下角度进行排查：
¡ 检查BRAS设备上Portal认证服务器IP地址配置是否正确。
¡ 检查BRAS设备上Web认证页面URL配置是否正确。
¡ 检查BRAS设备上认证前域阶段的QoS策略配置是否正确，即：
- 入方向：允许目的地址为Portal服务器的报文通过。
- 出方向：允许源地址为Portal服务器的报文通过。
¡ 检查Portal服务器上是否配置了IP地址组，以及是否将设备与IP地址组关联。
¡ 检查终端IP地址是否在Portal服务器上配置的IP地址组范围内。
(3) 确认终端和Portal服务器上的路由配置是否正确。
在终端上关闭防火墙功能后，执行Ping操作检查Portal服务器是否可达，如果Ping不通，首先需要确认终端和Portal服务器上的路由配置是否正确，同时需要注意：
¡ Portal服务器到终端的回程路由是否配置正确。
¡ 终端或者Portal服务器上是否存在有多个网卡。
在有多个网卡的情况下，终端和服务器之间的流量不一定全部经过配置有Portal认证的网络。以Windows终端为例，在cmd窗口上执行route print命令查看具体的路由信息，然后确定用户的Web访问流量是从哪个网卡出去。
最后，采取分段Ping的手段定位问题。首先从终端Ping网关（需要先取消认证，否则Ping不通），然后再从网关上Ping服务器。
(4) 终端的浏览器上是否开启了HTTP代理功能。
浏览器上开启了HTTP代理功能会导致用户无法访问Portal认证页面。以Windows IE浏览器为例，请打开IE浏览器，单击“工具”，选择“Internet选项>连接>局域网设置>代理服务器”中，关闭HTTP代理功能。
(5) 确认输入的网址是否使用非标准TCP端口。
非标准TCP端口是指非80或非443端口。用户输入的网址中若包含非标准TCP端口，会导致Portal认证页面无法弹出，例如http://10.1.1.1:18008。对于HTTP协议的网址，请使用80；对于HTTPS协议的网址，请使用443。
(6) 确认中间网络或DNS服务器是否出现问题。
a. 确认设备上是否将DNS服务器IP地址配置为允许访问的地址。
b. 检查中间网络连通性以及排查DNS服务器故障，在网关上进行流量统计（分别对连接终端下行接口和连接DNS服务器的上行接口）或镜像获取终端访问DNS服务器的报文，确认网关是否已将DNS请求发出，但却未收到回应报文。
(7) 确认HTTPS重定向功能是否正常。
a. 确认用户是否访问HTTPS网站。若是，请执行display current-configuration查看当前设备（非vBRAS-CP设备）上是否配置了http-redirect https-port命令：
- 若已配置，请执行display tcp命令查看http-redirect https-port命令中指定的侦听端口是否正常开启。若未开启，请执行http-redirect https-port命令重新配置，确保指定的侦听端口正常开启。
- 若未配置，则表示当前设备采用了http-redirect https-port命令的缺省端口6654。请执行display tcp命令查看缺省侦听端口6654是否正常开启。若未开启，请执行http-redirect https-port 6654命令重新配置，确保缺省侦听端口正常开启。
b. 检查HTTPS重定向服务器关联的SSL服务器端策略是否存在，若不存在，请完善相关配置。
(8) 确认HTTPS网站是否开启了HSTS功能。
HTTPS网站开启了HSTS功能后，要求浏览器必须使用HTTPS访问，而且证书必须要合法。设备对用户浏览器进行HTTPS重定向时，设备会使用自签名证书（设备没有目标网站的证书，只能使用自签名证书）伪装成目标网站和浏览器建立SSL连接，此时浏览器一旦检测到证书不受信任，将会导致HTTPS重定向失败，无法弹出Portal认证页面。这种情况依赖于具体网站配置的HSTS协议的强制要求，无法解决。此时，建议用户更换其他网站进行尝试。
(9) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息和告警信息。
¡ 服务器上Portal相关配置截图。
¡ 设备与服务器之间的抓包文件。
¡ 在浏览器上对问题现象进行截图。
¡ 出现问题时，在设备上通过debugging portal和debugging ip packet命令收集Debug信息。
Web用户认证失败或者认证异常。
本类故障的常见原因主要包括：
· BRAS设备上Portal认证服务器视图下配置的共享密钥和Portal认证服务器上的设置不一致。
· BRAS设备上Portal认证服务器视图下配置的Portal认证服务器地址不存在。
· BRAS设备收到的Portal报文非法。
· Web用户使用的认证域配置错误。
· RADIUS视图下配置共享密钥与RADIUS服务器上配置的不一致。
· RADIUS服务器认证拒绝。
· RADIUS服务器无响应。
本类故障的诊断流程如图5-10所示：
图5-10 Web认证页面登录失败故障诊断流程图
(1) 检查BRAS设备上Portal认证服务器视图下配置的共享密钥与Portal服务器上的是否一致。
如图5-11所示，以iMC服务器为例，当输入“用户名”和“账号密码”，点击“上线”后登录界面上出现“向设备发送请求超时”的提示，表示BRAS设备上Portal认证服务器视图下配置的共享密钥有可能与服务器上配置的不一致。
图5-11 Web登录界面打印错误提示
(2) 此时，可以通过如下方法来检查：
在BRAS设备上执行debugging portal error命令，打开Portal错误调试信息开关。如果设备上打印如下信息，则可以确认BRAS设备和Portal服务器配置的共享密钥不一致。
*Jul 28 17:51:20:774 2021 Sysname PORTAL/7/ERROR: -MDC=1; Packet validity check failed due to invalid key.
如果确认不一致，请修改BRAS设备上Portal服务器视图下配置的共享密钥或者Portal认证服务器上配置的共享密钥，使其两者保持一致。
(3) 检查BRAS设备上Portal认证服务器视图下配置的Portal认证服务器IP地址是否存在。
当Portal服务器收到BRAS设备发送的认证报文时，Portal服务器会校验报文的源IP是否Portal服务器上设置允许接入设备的IP地址，若不是则认为是非法报文，直接丢弃。
如图5-12所示，以iMC服务器为例，当输入“用户名”和“账号密码”，点击“上线”后登录界面上出现“向设备发送请求超时”的提示，表示设备上Portal认证服务器视图下配置的Portal认证服务器地址可能不存在。
图5-12 Web登录界面打印错误提示
(4) 此时，可以通过如下方法来检查：
¡ 在设备上执行debugging portal error命令，打开Portal错误调试信息开关。如果设备上打印如下信息，则可以确认设备上配置的Portal认证服务器IP地址错误。
*Jul 28 19:15:10:665 2021 Sysname PORTAL/7/ERROR: -MDC=1;Packet source unknown. Server IP:192.168.161.188, VRF Index:0.
如果确认不正确，请在设备的Portal服务器视图下，执行ip命令修改Portal服务器的IP地址。
(5) 检查设备上认证域配置是否正确。
检查配置确保认证域在设备上存在且配置正确，否则将会导致用户将无法认证。
¡ 如图5-13所示，以iMC为例，当输入“用户名”和“账号密码”，点击“上线”后登录界面上出现“设备拒绝请求”的提示，表示设备上认证域可能配置不正确。
图5-13 Web登录界面打印错误提示
此时，可以通过如下方法来检查：
¡ 在设备上执行debugging portal error命令，打开Portal错误调试信息开关。如果设备上打印如下信息，则可能是设备上认证域配置错误，需要进一步排查。
*Jul 28 19:49:12:725 2021 Sysname PORTAL/7/ERROR: -MDC=1; User-SM [21.0.0.21]: AAA processed authentication request and returned error.
如果认证域配置不正确，请执行相应的命令将Web用户使用的认证域配置修改正确。
(6) 检查RADIUS视图下配置共享密钥是否与RADIUS服务器上配置的一致。
(7) 如图5-14所示，以iMC服务器为例，当输入“用户名”和“账号密码”，点击“上线”后登录界面上出现“向设备发送请求超时”的提示，表示RADIUS视图下共享密钥和服务器上配置的不一致。
图5-14 Web认证登录界面打印错误提示
(9)
在设备上执行debugging radius error命令，打开RADIUS错误调试信息开关。如果设备上打印如下信息，则可以确认设备上RADIUS视图下配置共享密钥和RADIUS服务器上配置的不一致。
*Jul 28 19:49:12:725 2021 Sysname RADIUS/7/ERROR: -MDC=1; The response packet has an invalid Response Authenticator value.
当设备向RADIUS服务器发起认证请求时，服务器会首先对请求报文使用共享密钥进行校验，如果校验失败，服务器会通知设备校验失败。如果共享密钥配置错误，请将RADIUS视图下共享密钥和服务器上配置的保持一致。
(10) 检查Portal报文是否非法。
当设备收到Portal服务器发送过来的Portal协议报文时，对报文做合法性校验，如果报文长度不对、报文校验段错误，则该报文将被视为非法报文而丢弃。
可通过如下方法进行排查：
通过display portal packet statistics命令查看是否存在非法报文计数增长，如果计数增长，可通过在设备上执行debugging portal error命令，打开Portal错误调试信息开关排查具体原因。
如果Portal协议报文非法，请在技术支持人员的协助下确认报文非法的原因并进行修改，使Portal协议报文成为合法报文。
(11) 检查是否获取用户物理信息失败。
用户上线过程中Portal会查找用户物理信息，并根据对应的物理信息确定用户所在的接口等信息。如果查找物理信息失败，则用户会上线失败。
可通过如下方式进行检查：
在设备上执行debugging portal event命令，打开Portal事件调试信息开关。如果设备上打印如下信息，表示获取用户物理信息失败。
*Jul 28 19:49:12:725 2021 Sysname PORTAL/7/ERROR: -MDC=1; User-SM [21.0.0.21]: Failed to find physical info for ack_info.
确认获取用户物理信息失败后，请排查设备是否存在该认证用户的表项，如果不存在，请进一步排查具体原因。
(12) 检查RADIUS服务器是否认证拒绝。
RADIUS服务器回应认证拒绝有多种原因，最常见的有用户名密码错误、RADIUS服务器授权策略无法匹配等。这些问题，首先需要查看服务器端的认证日志或者在设备上通过debugging radius error命令打开RADIUS错误调试信息开关查看相关的Debug信息找到根本原因后，再调整服务器、终端或设备配置。
(13) 检查RADIUS服务器是否无响应。
¡ 可通过如下方法快速确认RADIUS服务器是否有回应。
¡ 在BRAS设备上执行display radius scheme命令查看服务器状态。如果为Blocked，则表示服务器不可用。
¡ 查看设备是否打印如下日志：
RADIUS/4/RADIUS_AUTH_SERVER_DOWN: -MDC=1; RADIUS authentication server was
blocked: server IP=192.168.161.188, port=1812, VPN instance=public.
¡ 在设备上执行debugging radius event命令打开RADIUS事件调试信息开关，如果设备上打印如下信息，表示RADIUS服务器无回应。
*Jul 28 19:49:12:725 2021 Sysname RADIUS/7/evnet: -MDC=1; Reached the maximum retries.
¡ 确认RADIUS服务器无响应后，可根据如下步骤进行处理：
a. 确认服务器是否添加了设备IP地址。
- 如果没有添加，请添加正确的设备IP地址。如果已经添加，那么需要确定服务器添加的设备IP地址与认证请求的源IP地址是否一致（设备默认出接口的IP地址作为向RADIUS服务器发送RADIUS报文时使用的源IP地址，该源IP地址可以根据实际需要通过命令进行修改，具体介绍请参见“BRAS业务命令参考/AAA”中的“source-ip命令”）。
- 如果已添加，则需确认服务器上添加的设备IP地址必须为认证请求的源IP地址。
b. 确认设备和服务器的中间链路是否存在问题，例如中间网络存在防火墙，防火墙未放通RADIUS（默认认证端口：1812）报文。如果出现大量用户无法认证，设备上的日志里出现RADIUS服务器Down记录，那么大概率是服务器或中间网络出现异常，需要逐一排查。
(14) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
¡ Portal服务器上Portal相关配置截图。
¡ 设备与AAA服务器间的抓包文件。
¡ 在客户端浏览器上对问题现象截图。
¡ 通过开启debugging portal命令收集调试信息。
用户上线后，ITA业务策略并未生效或者停止生效，即没有按照预期的计费级别对用户访问不同目的地址的业务流量进行独立计费和限速。
本类故障的常见原因主要包括：
· 用户的接入类型不支持ITA业务策略。
· 设备上未创建要授权给用户的ITA业务策略。
· RADIUS服务器未给用户授权ITA业务策略，且用户的认证域下未指定要采用的ITA业务策略。
· RADIUS服务器为用户授权了EDSG业务策略，且用户的认证域下指定了要采用的ITA业务策略。
· ITA业务策略中的计费配置不正确。
· 用于标记ITA业务流的QoS配置不正确。
· 用户的ITA业务流量配额耗尽。
本类故障的诊断流程如图6-1所示。
图6-1 ITA业务不生效的故障诊断流程图
(1) 确认用户的接入类型是否支持应用ITA业务策略。
目前，仅IPoE、PPP接入类型的用户支持ITA业务策略的应用，其他接入类型的用户暂不支持。
请执行命令display access-user显示接入用户的信息，并通过“Access type”字段确认用户的接入类型：
¡ 如果用户的接入类型为IPoE或PPP，则执行步骤(2)。
¡ 如果用户的接入类型为其它类型，则无需处理。
(2) 检查设备上是否创建了预期的ITA业务策略。
¡ 请执行命令display ita policy检查设备上是否存在指定的ITA业务策略：
¡ 如果不存在指定的ITA业务策略，则需要在系统视图下执行命令ita policy创建所需的ITA业务策略，并参考“BRAS业务命令参考”中的“增值业务命令”手册完成ITA业务策略配置。
¡ 如果存在指定的ITA业务策略，则执行步骤(3)。
(3) 检查是否为用户授权了ITA业务策略。
若RADIUS服务器为当前用户授权了ITA业务策略，设备将使用RADIUS服务器授权的ITA业务策略，否则使用用户认证域中指定的ITA业务策略。因此，需要首先检查RADIUS服务器是否为用户授权了ITA业务策略，然后再按需检查认证域下的配置。
a. 执行命令debugging radius packet打开RADIUS报文调试信息开关，如果用户上线时系统打印的RADIUS报文调试信息中包括“H3C-Ita-Policy="XXX"”格式的属性字符串，则表示RADIUS服务器授权了ITA业务策略，请执行步骤(4)，否则请继续执行步骤b。
b. 执行命令diplay domain查看用户认证域的配置信息，如果该域下的显示信息中存在“ITA service policy: XXX”（XXX为具体的策略名称），则表示该域中已指定ITA业务策略，请继续执行步骤c，否则请执行步骤d。
c. 检查RADIUS服务器是否为用户授权了EDSG业务策略。如果用户上线时系统打印的RADIUS报文调试信息中包含“H3C-AV-Pair := "edsg-policy:activelist=xxx"”或者“Cisco-AVPair := "edsg-policy:username=[xxx]xxx"”格式的属性字符串，则表示RADIUS服务器授权了EDSG业务策略。
若RADIUS服务器为用户授权了EDSG业务策略，则认证域中指定的ITA业务策略将不会生效。这种情况下，需要首先修改RADIUS服务器上的用户授权配置，取消下发的EDSG业务策略，然后执行步骤(4)。
d. 按照组网需求，采用不同的方式为用户授权ITA业务策略。
- 基于用户授权：在认证用户的RADIUS服务器上配置ITA业务策略，并让用户重新上线。
- 基于认证域授权：在用户上线使用的认证域视图下指定ITA业务策略，并让用户重新上线。
例如，在ISP域test中指定采用ITA业务策略ita1。
<Sysname> system-view
[Sysname] domain name test
[Sysname-isp-test] ita-policy ita1
(4) 检查ITA业务策略采用的计费方案是否可用。
¡ 执行命令display ita policy显示ITA业务策略的配置信息，并通过“Accounting method”字段确认ITA业务策略采用的计费方案。
例如，查看ITA业务策略ita1的配置信息。
<Sysname> display ita policy ita1
Accounting method : RADIUS=Rd1, None
Accounting merge : Enabled
Accounting levels :
Level 1 IPv4
Inbound CAR: CIR 100 kbps PIR 200 kbps
Outbound CAR: CIR 100 kbps PIR 200 kbps
Level 2 IPv6
Inbound CAR: CIR 300 kbps PIR 400 kbps
Level 3 IPv4
Level 8 IPv6
Traffic separation : Enabled
Separated levels: 1, 2, 3, 4
Traffic quota-out action: Online
Send accounting update: No
¡ 如果“Accounting method”取值为“None”，则表示未配置ITA业务策略采用的计费方案。此时，需要在ITA业务策略视图下配置采用的计费方案，并确保计费方案中的计费服务器可用。
例如，在ITA业务策略ita1中，指定采用的计费方案为radius1。
<Sysname> system-view
[Sysname] ita policy ita1
[Sysname-ita-policy-ita1] accounting-method radius-scheme radius1
¡ 如果“Accounting method”取值包含“RADIUS＝xxx”，则表示ITA业务策略采用RADIUS计费方案。这种情况下，需要保证RADIUS方案下的计费服务器可用，若计费服务器不可用，请参考“RADIUS服务器无响应”故障处理手册进一步定位和排除故障。
(5) 检查ITA业务是否按照流量计费级别进行计费。
¡ 流量计费级别是运营商对用户访问不同目的网络的流量收取费用的等级，需要通过ITA业务策略指定为哪些级别的流量进行独立计费。
a. 执行命令display ita policy显示ITA业务策略的配置信息，并通过“Accounting levels”区段确认ITA业务策略下配置的流量计费级别信息是否正确。
例如，查看ITA业务策略ita1的配置信息。
<Sysname> display ita policy ita1
Accounting method : RADIUS=Rd1, None
Accounting merge : Enabled
Accounting levels :
Level 1 IPv4
Inbound CAR: CIR 100 kbps PIR 200 kbps
Outbound CAR: CIR 100 kbps PIR 200 kbps
Level 2 IPv6
Inbound CAR: CIR 300 kbps PIR 400 kbps
Traffic separation : Enabled
Separated levels: 1, 2, 3, 4
Traffic quota-out action: Online
Send accounting update: No
- 如果“Accounting levels”取值为“None”，则表示未配置流量计费级别。此时，需要在ITA业务策略视图下配置该用户采用的流量计费级别。
例如，在ITA业务策略ita1中，指定需要计费的流量计费级别为2和5，其中2级作为IPv4流量计费，5级作为IPv6流量计费。
<Sysname> system-view
[Sysname] ita policy ita1
[Sysname-ita-policy-ita1] accounting-level 2 ipv4
[Sysname-ita-policy-ita1] accounting-level 5 ipv6
- 如果“Accounting levels”取值不为“None”，则表示已配置流量计费级别，请确认流量计费级别准确后继续执行步骤b。
b. 检查用于识别用户ITA业务流量的QoS策略配置是否准确。
- 如果基于授权User Profile为用户下发QoS策略，请进入授权给用户的User Profile视图下检查是否应用了QoS策略，并确保QoS策略中的流分类和重标记流量计费级别配置准确。
- 如果基于接口为用户下发QoS策略，请进入用户接入的接口视图下检查是否应用了指定的QoS策略，并确保QoS策略中的流分类和重标记流量计费级别配置准确。
(6) 检查ITA业务是否停止生效。
a. 执行命令display value-added-service user xxx verbose显示增值业务用户的详细信息，通过“Level-X State”取值是否为“Offline”判断该增值业务是否下线。
b. 若指定计费级别的业务已下线，则通过显示信息中的“Offline reason”字段判断增值业务下线的原因。“Offline reason”字段取值如下：
- Authentication failed：认证失败。
- Accounting failed：开始计费失败。
- Accounting update failed：计费更新失败。
- Failed to send accounting packets：计费报文发送失败。
- Traffic quota exhausted：授权流量配额耗尽。
- Session timed out：授权时长配额耗尽。
- Cut by the AAA server：DAE客户端发送DM请求，强制用户下线。
- Logged out by the RADIUS proxy：被RADIUS代理强制下线。
若配额耗尽，则属于正常情况，无需处理；若被强制下线，请和RADIUS管理员或者设备管理员确认是否为正常管理行为；其它情况，请首先参考“RADIUS服务器无响应”故障处理手册排除RADIUS服务器不可达故障，然后执行步骤(8)。
例如，查看IP地址1.1.1.1的增值业务用户详细信息。
<Sysname> display value-added-service user ip-address 1.1.1.1 verbose
Slot 97:
Basic：
User ID : 0x1
User name : user1
IP address : 1.1.1.1
IPv6 address : -
Service type : ITA
ITA:
Policy name : ita1
Accounting merge : Disabled
Traffic quota-out action : Offline
Level-1 State : Offline
Offline reason : Session timed out
Inbound CAR : CIR 1000kbps PIR 2000kbps
CBS -
Outbound CAR : CIR 1000kbps PIR 2000kbps
CBS -
Uplink packets/bytes : 4/392
Downlink packets/bytes : 4/392
IPv6 uplink packets/bytes : 0/0
IPv6 downlink packets/bytes : 0/0
Accounting start time : 2022-08-27 01:23:41
Online time (hh:mm:ss) : 0:00:12
Accounting state : Stop
Session timeout : Unlimited
Time remained : Unlimited
Realtime accounting interval: -
Traffic separate : Disabled
Traffic quota : Unlimited
Traffic remained : Unlimited
通过以上显示信息可见，“Level-1 State”取值为“Offline”，表示Level 1计费级别的ITA业务处于下线状态；“Offline reason”字段取值为“Session timed out”，表示Level 1计费级别的ITA业务配额已经耗尽。
(7) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
无
无
用户上线后，EDSG业务策略并未生效或者停止生效，即没有按照预期的EDSG增值业务参数对用户提供独立计费、动态限速服务。
本类故障的常见原因主要包括：
· 用户的接入类型不支持EDSG业务策略。
· 设备上未创建要授权给用户的EDSG业务策略。
· RADIUS服务器未给用户授权EDSG业务策略。
· RADIUS服务器为用户同时授权了EDSG业务策略和ITA业务策略。
· RADIUS服务器下发的EDSG业务策略信息（EDSG业务策略名称、用户名、密码）不合法，设备不能识别。
· EDSG业务策略中指定的认证&计费方案不可用。
· EDSG业务策略停止生效。
本类故障的诊断流程如图6-2所示。
图6-2 EDSG业务不生效的故障诊断流程图
(1) 确认用户的接入类型是否支持应用EDSG业务策略。
目前，仅IPoE、PPPoE接入类型的用户支持EDSG业务策略的应用，其他接入类型的用户暂不支持。
请执行命令display access-user显示接入用户的信息，并通过“Access type”字段确认用户的接入类型：
¡ 如果用户的接入类型为IPoE或PPPoE，则执行步骤(2)。
¡ 如果用户的接入类型为其它类型，则无需处理。
(2) 检查设备上是否创建了预期的EDSG业务策略。
¡ 请执行命令display service policy检查设备上是否存在指定的EDSG业务策略：
¡ 如果不存在指定的EDSG业务策略，则需要在系统视图下执行命令service policy创建所需的EDSG业务策略，并参考“BRAS业务命令参考”中的“增值业务命令”手册完成EDSG业务策略配置。
¡ 如果存在指定的EDSG业务策略，则执行步骤（3）。
(3) 检查RADIUS服务器是否为用户授权了EDSG业务策略。
¡ 设备仅能识别RADIUS服务器通过私有属性H3c-AV-Pair和Cisco-AVPair下发的EDSG业务策略信息（EDSG策略名称、用户名、密码）。
a. 执行命令debugging radius packet打开RADIUS报文调试信息开关，如果用户上线时系统打印的RADIUS报文调试信息中包含“H3C-AV-Pair := "edsg-policy:activelist=xxx"”或者“Cisco-AVPair := "edsg-policy:username=[xxx]xxx"”格式的属性字符串，则表示RADIUS服务器授权了EDSG业务策略，请执行步骤(4)，否则请继续执行步骤b。
b. 请在认证用户的RADIUS服务器上配置EDSG业务策略，并让用户重新上线。
(4) 检查RADIUS服务器是否为用户同时授权了ITA业务策略和EDSG业务策略。
¡ 对于同一个用户，若RADIUS服务器同时下发了ITA业务策略和EDSG业务策略，则EDSG业务策略不会生效。此时，需要修改RADIUS服务器上的用户授权配置，确保仅给该用户下发EDSG业务策略。
RADIUS报文调试信息开关处于开启的情况下，如果RADIUS服务器为用户授权了ITA业务策略，则用户上线时系统打印的RADIUS报文调试信息将包含“H3C-Ita-Policy="XXX"”格式的属性字符串。
¡
(5) 检查设备是否可以识别RADIUS服务器下发的EDSG业务策略信息。
由于设备仅能识别服务器通过私有属性H3c-AV-Pair或Cisco-AVPair下发的EDSG业务策略信息，因此需要与服务器管理员确认，为该用户授权EDSG业务策略的同时是否使用了其它属性下发了用户名和密码。
¡ 若同时下发了用户名和密码，则需要和服务器管理员确认使用的RADIUS属性名称，然后在用户认证使用的RADIUS方案视图下开启RADIUS属性解释功能，并配置RADIUS属性转换规则，将该属性转换成H3c-AV-Pair或者Cisco-AVPair。
例如，用户认证使用的RADIUS方案为rs1，在该方案视图下开启RADIUS属性解释功能，并配置将收到的H3c-Server-String属性转换为H3c-AVPair。
<Sysname> system-view
[Sysname] radius scheme rs1
[Sysname-radius-rs1] attribute translate
[Sysname-radius-rs1] attribute convert H3c-Server-String to H3c-AVPair received
¡ 若未同时下发用户名和密码，则执行步骤(6)
(6) 检查EDSG业务使用的认证、计费方案是否可用。
执行命令display service policy显示EDSG业务策略的配置信息，并通过“Authentication method”和“Accounting method”字段分别确认EDSG业务使用的认证方案、计费方案。
例如，查看EDSG业务策略sp1的配置信息。
<Sysname> display service policy sp1
Service policy: sp1
Service ID : 10
Authentication method : RADIUS=Rd1, None
Accounting method : RADIUS=Rd1, None
Traffic statistics : Separate
Inbound CAR : CIR=222 kbps, PIR=2222 kpbs, CBS=5678 bytes, EBS=5678 bytes
Outbound CAR : CIR=222 kbps, PIR=2222 kpbs
Dual-stack rate limit mode : Merge
Service rate-limit mode : Separate
¡ 如果“Authentication method”和“Accounting method”字段取值为“None”，则表示用户的EDSG业务无需单独认证和计费，请执行步骤(7)。
¡ 如果“Authentication method”和“Accounting method”字段取值包含“RADIUS＝xxx”，则表示用户的EDSG业务需要单独进行RADIUS认证、RADIUS计费。这种情况下，需要确保RADIUS方案下的RADIUS服务器可用，且服务器上已经创建了相应的认证用户名和密码。
若用户上线时服务器下发的EDSG业务策略携带了用户名和密码，则设备将使用该用户名和密码进行EDSG业务认证；否则使用用户上线时的用户名和密码进行EDSG业务认证。
(7) 检查EDSG业务是否停止生效。
a. 执行命令display value-added-service user xxx verbose显示增值业务用户的详细信息，通过“Level-X State”取值是否为“Online”判断业务是否在线。
b. 若指定计费级别的业务不在线，则可能的用户下线的原因包括：
- 认证失败。
- 开始计费失败。
- 计费更新失败。
- 计费报文发送失败。
- 授权流量配额耗尽。
- 授权时长配额耗尽。
- DAE客户端发送DM请求，强制用户下线。
- 被RADIUS代理强制下线。
若配额耗尽，则属于正常情况，无需处理；若被强制下线，请和RADIUS管理员或者设备管理确认是否为正常管理行为；其它情况，请首先参考“RADIUS服务器无响应”故障处理手册排除RADIUS服务器不可达故障，然后执行步骤(8)。
例如，查看IP地址1.1.1.1的增值业务用户详细信息。
<Sysname> display value-added-service user ip-address 1.1.1.1 verbose
Slot 97:
Basic:
User ID : 0x80000033
User name : pp3
IP address : 1.1.1.1
IPv6 address : -
Service type : EDSG
Service policy:
Service ID : 8
Policy name : sp8
Policy username : pp3
State : Offline
Offline reason : Session timed out
Traffic statistics : Separate
Service rate-limit mode : Separate
Dual-stack rate limit mode : Merge
Traffic quota-out action : Offline
Inbound CAR : -
Outbound CAR : -
Uplink packets/bytes : 0/0
Downlink packets/bytes : 0/0
IPv6 uplink packets/bytes : 0/0
IPv6 downlink packets/bytes : 0/0
Accounting start time : 2022-08-27 05:03:49
Online time (hh:mm:ss) : 0:03:13
Accounting state : Stop
Session timeout : Unlimited
Time remained : Unlimited
Realtime accounting interval : 20 seconds
Traffic quota : Unlimited
Traffic remained : Unlimited
(8) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
无
无
PPPoE转发常见故障现象有：
· 从客户端往公网侧的上行流量转发不通。
· 从公网侧往客户端的下行流量转发不通。
本类故障的常见原因主要包括：
· 用户不在线。
· 用户的所属VPN、User group等授权属性信息错误。
· 用户路由添加错误。
· 网络配置问题或者链路连接问题。
· 超过报文限速值。
本类故障的诊断流程如图7-1所示：
图7-1 PPPoE转发故障诊断流程图
(1) 检查用户是否正常在线。
执行display access-user verbose命令查看用户是否在线，如在线则检查各字段是否正确。
¡ 若用户不在线，则解决用户上线问题。
¡ 若用户在线，但用户信息错误（如用户IP地址、MAC地址、所属VPN和ISP域等），则更正配置后，让用户先下线再重新上线。
¡ 若用户在线，且用户信息正确，则继续下一步。
(2) 检查用户路由是否正确添加。
执行display ip routing-table命令查看用户UNR路由是否存在：
¡ 若存在，则继续下一步。
¡ 若不存在，则让用户下线后再重新上线。如无法解决，则继续下一步。
(3) 检查BRAS设备到外网路由是否可达。
在BRAS设备上ping某个外网IP地址，若可以ping通，则继续下一步。若ping不通，则排查报文转发路径上所有链路，解决路由故障问题。
(4) 检查是否做了限速配置。
从如下角度检查是否配置了报文限速，如是则检查用户报文速率超过了限速值，否则请继续下一步。
¡ 检查用户上线接口是否配置了限速策略。
¡ 检查用户接入ISP域或AAA服务器是否设置了用户授权CAR。
¡ 检查用户转发路径上的其它链路段设备是否配置了限速策略。
(5) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
L2TP转发常见故障现象有：
· 从客户端往LNS内网的上行流量转发不通。
· 从LNS内网往客户端的下行流量转发不通。
本类故障的常见原因主要包括：
· 用户不在线。
· 用户基本信息错误。
· 用户路由添加错误。
· 网络配置或者链路故障。
本类故障的诊断流程如图7-2所示：
图7-2 L2TP转发故障诊断流程图
(1) 检查用户是否正常在线。
分别在LAC和LNS上执行display access-user verbose命令查看用户是否在线，如在线则检查各字段是否正确。
¡ 若用户不在线，则解决用户上线问题。
¡ 若用户在线，但用户信息错误（如用户IP地址、MAC地址、所属VPN和ISP域等），则更正配置后，让用户先下线再重新上线。
¡ 若用户在线，且用户信息正确，则继续下一步。
(2) 检查用户路由是否正确添加。
在LNS上执行display ip routing-table命令查看用户UNR路由是否存在：
¡ 若存在，则继续下一步。
¡ 若不存在，则让用户下线后再重新上线。如无法解决，则继续下一步。
(3) 检查LAC和LNS之间路由是否可达。
在LAC设备上ping LNS设备的出口IP地址，若可以ping通，则继续下一步。若ping不通，则排查报文转发路径上所有链路，解决路由故障问题。
(4) 检查是否做了限速配置。
从如下角度检查是否配置了报文限速，如是则检查用户报文速率超过了限速值，否则请继续下一步。
¡ 检查用户上线接口是否配置了限速策略。
¡ 检查用户接入ISP域或AAA服务器是否设置了用户授权CAR。
¡ 检查用户转发路径上的其它链路段设备是否配置了限速策略。
(5) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
IPoE转发常见故障现象有：
· IPoE用户侧去往网络侧的流量不通。
· IPoE网络侧去往用户侧的流量不通。
本类故障的常见原因主要包括：
· 用户不在线。
· 用户基本信息错误。
· 用户路由添加错误。
· 网络配置或者链路连接故障。
本类故障的诊断流程如图7-3所示：
图7-3 IPoE转发故障诊断流程图
(1) 检查用户是否正常在线。
执行display access-user verbose命令查看用户是否在线，如在线则检查各字段是否正确。
¡ 若用户不在线，则解决用户上线问题。
¡ 若用户在线，但用户信息错误（如用户IP地址、MAC地址、所属VPN和ISP域等），则更正配置后，让用户先下线再重新上线。
¡ 若用户在线，且用户信息正确，则继续下一步。
(2) 检查用户路由是否正确添加。
执行display ip routing-table命令查看用户UNR路由是否存在：
¡ 若存在，则继续下一步。
¡ 若不存在，则让用户下线后再重新上线。如无法解决，则继续下一步。
(3) 检查BRAS设备到外网路由是否可达。
在BRAS设备上ping某个外网IP地址，若可以ping通，则继续下一步。若ping不通，则排查报文转发路径上所有链路，解决路由故障问题。
(4) 检查是否做了限速配置。
从如下角度检查是否配置了报文限速，如是则检查用户报文速率超过了限速值，否则请继续下一步。
¡ 检查用户上线接口是否配置了限速策略。
¡ 检查用户接入ISP域或AAA服务器是否设置了用户授权CAR。
¡ 检查用户转发路径上的其它链路段设备是否配置了限速策略。
(5) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
用户上网慢常见故障现象有：
· 观看视频卡顿、打开网页慢。
· 从客户端往公网侧的上行流量转发慢。
· 从公网侧往客户端的下行流量转发慢。
本类故障的常见原因主要包括：
· 网络配置问题或者链路故障。
· BRAS到DNS服务器之间链路质量差导致丢包。
本类故障的诊断流程如图8-1所示：
图8-1 用户获取到IP地址后上网慢故障诊断流程图
(1) 检查是否因用户局域网问题导致上网慢。
请从下列角度排查用户局域网问题：
¡ 家庭路由器和光猫长时间未重启，可重启家庭路由器和光猫后再尝试上网。
¡ 检查局域网内是否有其他用户在上传或下载超大文件，占用过多带宽。
¡ 检查用户上网终端硬件是否老旧、性能较低，如电脑网卡性能较差、内存较小等。
¡ 检查用户上网终端是否中了病毒。
¡ 检查家庭路由器、光猫老化或损坏。
¡ 检查网线是否老化、水晶头是否松动。
(2) 检查是否因内容服务商问题导致上网慢。
可能因内容服务商的服务器性能无法满足突发的网络需求，或者故障等原因导致访问相应网站速度慢。可以通过更换其它网站测试访问速度是否正常：
¡ 若正常，则表示是网站问题。
¡ 若问题仍存在，请继续执行下一步。
(3) 检查是否是运营商网络问题导致上网慢。
请从下列角度排查运营商网络问题：
¡ 在BRAS设备上ping DNS服务器地址，检查二者之间路由是否可达，如果路由不可达，则解决路由问题。如果路由可达，查看ping DNS服务器是否有丢包。
¡ 如果BRAS设备到DNS服务器之间路由可达，查看ping DNS服务器是否有丢包。如果有丢包，则在BRAS设备上做MQC流统计看是否在BRAS设备丢包。
- 如果是BRAS设备丢包，则收集故障信息，并联系技术支持人员。
- 如果不是BRAS设备丢包，则联系客户一起协助进行网络排查，包括DNS服务器是否满，中间设备是否有丢包等。
¡ 检查BRAS是否做了CGN，如果做了CGN，则需要参考NAT故障处理进行排查。
¡ BRAS设备上用户限速配置是否正确。
¡ 接入层、汇聚层、核心层设备是否出现故障，导致网络延时增大、数据丢失。
¡ 宽带线路是否老化。
(4) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
用户获取到IP地址后无法上网。
本类故障的常见原因主要包括：
· 用户还未上线成功。
· BRAS设备上用户路由没有添加或者添加错误。
· 网络配置故障或者链路连接故障。
本类故障的诊断流程如图8-2所示：
图8-2 用户获取到IP地址后无法上网故障诊断流程图
(1) 检查用户是否正常在线。
执行display access-user verbose命令查看用户是否在线，如在线则检查各字段是否正确。
¡ 若用户不在线，则解决用户上线问题。
¡ 若用户在线，但用户信息错误，如用户所属VPN等，则更正配置后，让用户先下线再重新上线。
¡ 若用户在线，且用户信息正确，则继续下一步。
(2) 检查用户路由是否正确添加
执行display ip routing-table命令查看用户UNR路由是否存在：
¡ 若存在，则继续下一步。
¡ 若不存在，则让用户下线后再重新上线。如无法解决，则继续下一步。
(3) 检查BRAS设备到外网路由是否可达。
在BRAS设备上ping某个外网IP地址，若可以ping通，则继续下一步。若ping不通，则排查报文转发路径上所有链路，解决路由故障问题。
(4) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
用户流量转发全部丢包或部分丢包。
本类故障的常见原因主要包括：
· 用户还未上线成功。
· 用户信息错误。
· 网络配置故障或者链路连接故障。
· 超过报文限速值。
本类故障的诊断流程如图8-3所示：
(1) 检查用户是否正常在线。
执行display access-user verbose命令查看用户是否在线，如在线则检查各字段是否正确。
¡ 若用户不在线，则解决用户上线问题。
¡ 若用户在线，但用户信息错误，如用户所属VPN等，则更正配置后，让用户先下线再重新上线。
¡ 若用户在线，且用户信息正确，则继续下一步。
(2) 检查用户路由是否正确添加。
执行display ip routing-table命令查看用户UNR路由是否存在：
¡ 若存在，则继续下一步。
¡ 若不存在，则让用户下线后再重新上线。如无法解决，则继续下一步。
(3) 检查BRAS设备到外网路由是否可达。
在BRAS设备上ping某个外网IP地址，若可以ping通，则继续下一步。若ping不通，则排查报文转发路径上所有链路，解决路由故障问题。
(4) 检查是否做了限速配置。
从如下角度检查是否配置了报文限速，如是则检查用户报文速率超过了限速值，否则请继续下一步。
¡ 检查用户上线接口是否配置了限速策略。
¡ 检查用户接入ISP域或AAA服务器是否设置了用户授权CAR。
¡ 检查用户转发路径上的其它链路段设备是否配置了限速策略。
(5) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
大量用户上线速度慢。
本类故障的常见原因主要包括：
· 配置错误，导致部分用户协商失败，报文重传。
· 报文限速，导致丢包。
· 设备与AAA服务器交互慢，导致认证授权计费慢等。
· 设备CPU占用率过高。
本类故障的诊断流程如图8-4所示：
(1) 检查是否有用户上线失败。
执行display aaa online-fail-record命令检查是否有用户上线失败，若存在用户上线失败，请根据上线失败原因排查上线失败原因；若是配置错误导致上线失败则更正配置后，再重新上线。
(2) 检查是否有用户异常下线。
执行命令display aaa offline-record检查是否有用户异常下线，若存在异常下线用户，请根据异常下线原因排查下线原因；若是配置错误导致异常下线则更正配置后，再重新上线。
(3) 检查驱动是否有限速丢包。（非vBRAS-CP设备）
Probe视图下执行display hardware internal np pktcnt drop命令查看驱动丢包统计，是否有异常丢包计数，若有则排查丢包原因，若是配置触发则修改配置重新上线。
(4) 检查报文是否有重传。
查看协议报文统计，查看报文是否有重传计数。
¡ DHCP协议报文：请执行display dhcp server packet statistics命令查看DHCP协议报文是否有重传计数。
¡ PPPoE协议报文：请执行display pppoe-server packet statistics命令查看PPPoE协议报文是否有重传计数。
¡ PPP协议报文：，请执行display ppp packet statistics命令查看PPP协议报文是否有重传计数。
若是PPPoE用户上线，则需要分析重传报文是发生在LCP协商阶段、认证阶段，还是IPCP协商阶段，以便进一步定位报文重传原因；若是认证阶段报文有大量重传，则继续下一步。
(5) 排查设备与AAA服务器间通信是否正常。
若认证方式是远端AAA认证，先临时将认证方式修改为不认证，查看上线速率是否有提升。若有提升，则表示设备与AAA服务器交互慢，继续排查设备与AAA服务器交互慢的原因，否则继续下一步。
(6) 检查设备状态。
(7) 执行display cpu-usage命令检查设备CPU占用率，若CPU占用较高，则继续执行monitor process命令查看是哪个进程占CPU比较多，收集相关信息并继续执行下一步。
(8) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
本章主要介绍转发与控制分离组网中的特有故障的定位方法。对于不是转发与控制分离组网中特有故障的定位方法，同普通BRAS接入故障处理，具体请参见相应章节的故障处理。
在转发与控制分离组网中，用户无法正常上线。
本类故障的常见原因主要包括：
· BRAS-VM注册故障。
· FWD-VM注册故障。
· CU间NETCONF通道故障。
· CU间CUSP通道故障。
· CU间VXLAN通道故障。
· 远程口没有被管理。
· 配置下发故障。
· 网络故障。
本类故障的诊断流程如图9-1所示：
(1) 检查BRAS-VM和FWD-VM是否注册成功。
在CP上执行display vm命令查看BRAS-VM和FWD-VM是否向CTRL-VM注册成功。
¡ 如果Registration字段显示为“Registered”，则表示注册成功。请继续执行下一步。
¡ 如果Registration字段显示不为“Registered”，则表示未注册成功。具体故障处理请参见“9.6.6 VM注册失败”。
(2) 检查NETCONF通道是否建立。
在CP上执行display netconfc session命令查看CP和UP之间的NETCONF通道是否建立。
¡ 如果可以看到显示信息，则表示NETCONF通道建立成功。请继续执行下一步。
¡ 如果看不到显示信息，则表示NETCONF通道未建立成功。具体故障处理请参见“9.2 CP-UP连接管理故障处理”。
(3) 检查CUSP通道是否建立。
在CP上执行display cusp controller命令查看CP和UP之间的CUSP通道是否建立。
¡ 如果Connection state字段显示为“Established”，则表示CUSP通道建立成功。请继续执行下一步。
¡ 如果Connection state字段显示不为“Established”，则表示CUSP通道未建立成功。具体故障处理请参见“9.2 CP-UP连接管理故障处理”。
(4) 检查VXLAN通道是否建立。
在CP上执行display protocol-tunnel verbose命令查看CP和UP之间的VXLAN通道是否建立。
¡ 如果Active字段显示为“Yes”，则表示VXLAN通道建立成功。请继续执行下一步。
¡ 如果Active字段显示为“No”，则表示VXLAN通道未建立成功。具体故障处理请参见“9.2 CP-UP连接管理故障处理”。
(5) 检查CP是否成功将UP所需BRAS相关配置下发到UP。
在UP上的用户上线接口视图下执行display this命令查看当前接口上是否存在cp-management配置。若存在则表示当前接口已正常接受CP的远程管理，BRAS相关配置被正常下发；若不存在则表示当前接口未接受CP的远程管理，请继续执行下一步。
(6) 检查UP是否收到报文。
在UP上执行display protocol-tunnel packet statistics命令，查看Output packet statistics字段统计：
¡ 若对应报文计数有增加，则继续下一步。
¡ 若对应报文计数没有增加，则先执行debugging ucm forward all命令打开UCM的调试信息开关：
- 若有调试信息输出，表示UP收到报文，请联系技术支持人员。
- 若调试信息输出，表示UP没有收到报文，请继续排查网络配置以及链路是否存在故障。
(7) 检查CP是否收到报文。
在CP上执行display protocol-tunnel packet statistics命令，查看Input packet statistics字段统计：
¡ 若对应的报文计数有增加，则继续下一步。
¡ 若对应的报文计数没有增加，则需要在UP上与CP连接的网卡通过tcpdump抓包。
¡ 若报文已上送CP，则在FWD的外部通信口通过Packet Capture功能抓包，查看报文是否已送到FWD，若报文已到达FWD，则在Probe视图下执行display driver gigabitethernet xxx message命令查看X86驱动的丢包统计，可能因为VLAN ID不对导致丢包，可以尝试重新创建VXLAN通道，重新上线。
(8) 根据PPPoE、L2TP或IPoE用户上线失败故障处理章节继续定位。
(9) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
转控分离架构下CP和指定UP间控制通道、管理通道或者协议通道的状态异常。在CTRL-VM上执行cudetect cu tunnel-state命令时，显示信息中的NETCONF Tunnel、CUSP Tunnel、Protocol Tunnel字段取值不全为OK。例如：
<Sysname> cudetect cu tunnel-state up-id 1024
Please wait a few minutes...
Finished.
NETCONF Tunnel: NOK
Please configure the source IP of the NETCONF connetion abc to a interface on CP.
Please check the route to destination IP on CP.
CUSP Tunnel: OK
Protocol Tunnel: NOK
Please check the listening IP of the CUSP controller and the source IP of the protocol tunnel on CP.
本类故障的常见原因主要包括如下几类：
· CP与UP之间管理通道配置错误，即NETCONF会话配置错误。
· CP与UP之间控制通道配置错误，即CUSP相关配置错误。
· CP与UP之间协议通道配置错误，即VXLAN隧道相关配置错误。
本类故障的诊断思路如下：
(1) 检查CP与UP之间管理通道配置。
(2) 检查CP与UP之间控制通道配置。
(3) 检查CP与UP之间协议通道配置。
本类故障的诊断流程如图9-2所示。
图9-2 CP-UP间通道故障探测排查步骤
(1) 检查CP和UP上管理通道的配置详细信息。
在CP上执行命令display current-configuration configuration netconf-client，检查CP侧管理通道的配置信息：
netconf-client
source-address 2.2.2.2
connection 1024
user-name netconf password cipher $c$3$gwdAnb/zm8CEwMs5H9eQ89Hf4JFKXw==
destination-address 1.1.1.1
在CP上执行命令display current-configuration configuration up-manage，检查该UP管理实例绑定的NETCONF连接策略，显示信息如下：
bind netconf-connection 1024
在UP上执行命令display current-configuration | begin ssh，检查UP侧管理通道相关配置信息：
ssh server enable
ssh user netconf service-type netconf authentication-type password
local-user netconf class manage
password hash
bDm4CAp6rlXr9txtlp2w0URVUj8iKJ5a6MhLHmBMoHw==
service-type ssh
authorization-attribute user-role network-admin
authorization-attribute user-role network-operator
netconf ssh server enable
¡ 在CTRL-VM的任意视图下，执行cudetect cu tunnel-state up-id up-id命令，如果显示信息中NETCONF Tunnel字段为NOK时，根据该命令的详细故障提示信息进一步判断：
- 详细提示为“Please configure the source IP of the NETCONF connetion connetion-name to a interface on CP.”时，表示CP侧接口上未配置IP地址，其中connetion-name表示NETCONF连接策略的名称。该情况下，请将CP侧用于NETCONF会话的Loopback接口IP地址与CP的netconf client视图下源地址设置保持一致。
- 详细提示为“Please check the route to destination IP on CP.”时，表示CP侧缺少到UP侧的路由。该情况下，请在CP上配置静态路由或路由协议，以保证NETCONF会话的源和目的地址之间可达。
- 详细提示为“Please check the username and password on CP.”时，表示CP侧配置的与UP侧建立NETCONF会话使用的用户名或密码不合法。请保证CP侧netconf client视图下user-name命令设置的用户名和密码与UP侧的SSH类型的本地用户配置匹配。UP侧的SSH类型的本地用户的认证方式为password。
- 详细提示为“Please check the network configuration between CP and UP.”时，表示UP侧可能未配置IP地址或到CP的路由，也可能是CP和UP间网络故障。请在UP侧规划用于NETCONF会话的接口上配置IP地址，该IP地址必须与CP侧netconf client视图下通过destination-address命令配置的目的地址保持一致。然后，在UP上执行命令display ip routing-table确认UP侧到CP的NECONF会话源地址（即CP侧netconf client视图下通过source-address命令配置的源地址）路由可达。如果不可达，请在UP侧配置静态路由或路由协议。
- 详细提示为“Please check the NETCONF SSH configuration between CP and UP.”时，表示CP和UP的SSH配置有误。请确认CP和UP上SSH配置无缺失。
- 如果是其它提示信息，请参见“9.2.2 CP和UP之间的管理通道创建失败”处理。
¡ 在CTRL-VM上执行cudetect cu tunnel-state up-id up-id命令，如果显示信息中NETCONF Tunnel字段为NA，则表示NETCONF模块本身状态异常，请参见“9.2.2 CP和UP之间的管理通道创建失败”继续处理。
¡ 在CTRL-VM上执行cudetect cu tunnel-state up-id up-id命令，如果显示信息中NETCONF Tunnel字段为OK，则表示CP与UP之间管理通道状态正常，请继续排除其它通道的配置问题。
(2) 检查CP和UP上控制通道的配置详细信息。
在CP上执行命令display current-configuration configuration cusp-controller和display current-configuration configuration up-manage检查CP和UP控制通道的配置信息：
cusp controller
listening-ip 2.2.2.2
agent up1
agent-ip 1.1.1.1
up-manage id 1024
control-tunnel cusp-agent up1
up-config
cusp agent up1
local-address 1.1.1.1
controller address 2.2.2.2
¡ 在CTRL-VM的任意视图下，执行cudetect cu tunnel-state up-id up-id命令，如果显示信息中CUSP Tunnel字段为NOK，请根据该命令的详细故障提示信息进一步判断：
- 详细提示为“Please configure the CUSP controller on CP.”时，表示CP侧未开启CUSP控制器功能，请在CP的系统视图下执行cusp controller命令开启CUSP控制器功能。
- 详细提示为“Please configure the listening IP on CP.”时，表示CP侧未配置CUSP控制器的监听地址，请在CP的cusp-controller视图下执行listening-ip命令配置CUSP控制器的监听地址。
- 详细提示为“Please configure the listening IP to an interface on CP.”时，表示CP侧未在接口上配置CUSP控制器的监听地址，请在规划的CUSP控制通道接口上配置IP地址，并保证该IP地址与CP的cusp-controller视图下listening-ip命令配置的监听地址一致。
- 详细提示为“Please configure the CUSP agent on CP.”时，表示CP侧未添加CUSP代理，请在CP的agent视图下执行agent命令添加CUSP代理。
- 详细提示为“Please configure the CUSP agent IP on CP.”时，表示CP侧CUSP控制器未配置允许连接的CUSP代理的IP地址，请在CP的agent视图下执行agent-ip命令配置IP地址。
- 详细提示为“Please check the IP version of the listening IP and CUSP agent IP on CP.”时，表示CP侧CUSP控制器的监听地址和CUSP代理的地址的版本不一致，请在CP的cusp-controller视图下通过listening-ip命令或者CP的agent视图下agent-ip命令修改IP地址，并保证两者同为IPv4或IPv6地址。
- 详细提示为“Please configure the VPN instance on CP.”时，表示CP侧未创建CUSP控制器所属的VPN实例。在CP的cusp-controller视图下执行listening-ip命令时请确认指定的VPN实例已创建。
- 详细提示为“Please check the listening IP on CP and the controller address on UP.”时，表示CP侧CUSP控制器的监听地址和UP侧配置的CUSP控制器的IP地址不一致。请在CP的cusp-controller视图下通过listening-ip命令或者cusp-agent视图下controller address命令修改IP地址，保持两者一致。
- 详细提示为“Please check the agent IP on CP and the local address on UP.”时，表示CP侧配置CUSP代理的IP地址和UP侧配置CUSP代理的本地IP地址不一致，请在CP的agent视图下通过agent-ip命令或cusp-agent视图下的local-address命令修改IP地址，保持两者一致。
- 详细提示为“Please configure the CUSP agent on UP.”时，表示UP侧未配置CUSP代理。请在CP的up-config视图下执行cusp agent命令配置CUSP代理。
- 详细提示为“Please configure the local address on UP.”时，表示UP侧未配置CUSP代理的本地IP地址。请在CP的cusp-agent视图下执行local-address命令配置CUSP代理的本地IP地址。
- 详细提示为“Please configure the controller address on UP.”时，表示UP侧未配置CUSP代理连接的CUSP控制器的IP地址。请在CP的cusp-agent视图下执行controller address命令配置CUSP控制器的IP地址。
- 详细提示为“Please check the IP version of the local address and controller address on UP.”时，表示UP侧CUSP控制器的IP地址和CUSP代理的本地IP地址的IP版本不一致。请在CP的cusp-agent视图下执行undo local-address命令或undo controller address命令，删除错误配置的IP地址后再重新配置。
- 详细提示为“Cannot check the UP configuration because of the disconnection of the CU NETCONF tunnel.”时，表示CP和UP间管理通道状态异常，CP侧无法检查UP侧CUSP配置。请返回步骤(1)检查CP和UP上管理通道的配置详细信息。
¡ 在CTRL-VM上执行cudetect cu tunnel-state up-id up-id命令，如果显示信息中CUSP Tunnel字段为NA表示无法检测具体错误原因，请参见“9.2.4 CP和UP之间的控制通道创建失败”继续处理。
¡ 在CTRL-VM上执行cudetect cu tunnel-state up-id up-id命令，如果显示信息中CUSP Tunnel字段为OK，CP与UP之间控制通道状态正常，请继续排除其它通道的配置问题。
(3) 检查CP和UP上协议通道的配置详细信息。
在CP上执行命令display current-configuration | begin up-manage检查CP侧和UP侧协议通道的配置信息：
up-manage id 1024
protocol-tunnel vxlan 10 source 2.2.2.2 destination 1.1.1.1
cu-agent
protocol-tunnel vxlan 10 source 1.1.1.1 destination 2.2.2.2
¡ 在CTRL-VM上执行cudetect cu tunnel-state up-id up-id命令，如果显示信息中Protocol Tunnel字段为NOK，根据该命令的详细故障提示信息进一步判断：
- 详细提示为“Please configure the protocol tunnel on CP.”时，表示CP侧未配置协议通道参数，请在CP侧UP管理视图下执行protocol-tunnel命令配置CP和UP之间的协议通道的参数。
- 详细提示为“Please check the listening IP of the CUSP controller and the source IP of the protocol tunnel on CP.”时，表示CP侧协议通道源IP地址和CUSP控制器监听地址不一致，请在CP侧UP管理视图下执行protocol-tunnel命令修改协议通道的源IP地址，并保证与listening-ip命令配置的监听地址一致。
- 详细提示为“Please check the agent IP of the CUSP controller and the destination IP of the protocol tunnel on CP.”时，表示CP侧协议通道目的IP地址和CUSP控制器代理地址不一致。请在CP侧UP管理视图下执行protocol-tunnel命令修改协议通道源的目的IP地址，并保证与agent-ip命令配置的代理地址一致。
- 详细提示为“Please check the source IP of the protocol tunnel on CP and the destination IP of the protocol tunnel on UP.”时，表示CP侧协议通道源IP地址和UP侧协议通道目的IP地址不一致。请在CP侧UP管理视图下执行protocol-tunnel命令修改CP侧的协议通道的源IP地址，或cu-agent视图下执行protocol-tunnel命令修改UP侧的协议通道的目的IP地址，并保证两者一致。
- 详细提示为“Please check the destination IP of the protocol tunnel on CP and the source IP of the protocol tunnel on UP.”时，表示CP侧协议通道目的IP地址和UP侧协议通道源IP地址不一致。请在CP侧UP管理视图下执行protocol-tunnel命令修改CP侧的协议通道的目的IP地址，或cu-agent视图下执行protocol-tunnel命令修改UP侧的协议通道的源IP地址，并保证两者一致。
- 详细提示为“Please configure the protocol tunnel on UP.”时，表示UP侧未配置协议通道参数。请在CP侧cu-agent视图下执行protocol-tunnel命令配置UP和CP之间的协议通道的参数。
- 详细提示为“Please check the local address of the CUSP agent and the source IP of the protocol tunnel on UP.”时，表示UP侧协议通道源IP地址和CUSP代理的本地地址不一致。请在CP侧cu-agent视图下执行protocol-tunnel命令修改UP侧协议通道源IP地址，并保证与local-address命令指定的地址一致。
- 详细提示为“Please check the controller address of the CUSP agent and the destination IP of the protocol tunnel on UP.”时，表示UP侧协议通道目的IP地址和CUSP代理的控制器地址不一致。请在CP侧cu-agent视图下执行protocol-tunnel命令修改UP侧协议通道目的IP地址，并保证与controller address命令指定的地址一致。
- 详细提示为“Please check the VXLAN ID of the protocol tunnel between CP and UP.”时，表示CP和UP间协议通道VXLAN编号不一致。请在CP侧UP管理视图下执行protocol-tunnel命令修改CP侧的VXLAN编号，或cu-agent视图下执行protocol-tunnel命令修改UP侧的VXLAN编号，并保证两者一致。
- 详细提示为“Please check the abnormal state of the CUSP tunnel between CP and UP.”时，表示CP和UP间控制通道状态异常。请返回步骤(1)检查CP和UP上控制通道的配置详细信息。
- 详细提示为“Cannot check the configuration of the protocol tunnel on UP because of the disconnection of the CU NETCONF tunnel.”时，表示CP和UP间管理通道状态异常，CP侧无法检查UP侧协议通道配置。请返回步骤(1)检查CP和UP上管理通道的配置详细信息。
¡ 在CTRL-VM上执行cudetect cu tunnel-state up-id up-id命令，如果显示信息中Protocol Tunnel字段为NA表示VXLAN模块本身状态异常，故障探测工具无法检测具体错误原因，请参见“9.2.6 CP和UP之间的协议通道创建失败”继续处理。
¡ 在CTRL-VM上执行cudetect cu tunnel-state up-id up-id命令，如果显示信息中Protocol Tunnel字段为OK，CP与UP之间协议通道状态正常。
(4) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
无
无
CP和UP之间未创建管理通道。在CP上执行display netconfc session命令时，没有显示指定UP（Peer ID）的NETCONF会话信息。
本类故障的常见原因包括：
· 物理链路故障，导致CP与UP设备之间的路由不通。
· CP或UP的管理通道配置错误。
本类故障的诊断流程如图9-3所示。
图9-3 CP和UP之间的管理通道创建失败的诊断流程图
(1) 检查物理链路是否存在故障。
在CP上尝试能否ping通UP设备上与CP直连接口的IP地址。
如果不能ping通，则在CP上执行display ip routing-table命令或者display route-static routing-table命令查看去往UP的路由出接口，再执行display interface命令检查该接口状态：
<CTRL-VM> display interface ten-gigabitethernet 1/5/0
Ten-GigabitEthernet1/5/0
Interface index: 386
Current state: Administratively DOWN
Line protocol state: DOWN
...
a. 如果Current state显示为Administratively DOWN，则在接口下执行undo shutdown命令打开关闭的接口。如果Current state显示为DOWN，则检查接口的物理连线是否正确。
b. 在UP上重复以上步骤检查和修复UP上去往CP的路由出接口状态。
c. 如果CP和UP之间存在其他设备，按上述步骤逐跳检查和修复CP和UP之间各设备连接的物理接口状态。
d. 如果CP和指定UP间物理链路正常，而问题仍未解决，请继续执行以下操作。
(2) 检查CP上的管理通道配置是否存在错误。
在CP上执行命令display current-configuration configuration netconf-client检查CP侧管理通道的配置信息：
<CTRL-VM> display current-configuration configuration netconf-client
#
netconf-client
source-address 2.2.2.2
connection 1024
user-name netconf password cipher $c$3$J29ZV3fWskY85w0NwEO1p/LAWauPdx6Kw4xiLOn
W2dPMGEs=
destination-address 1.1.1.1
connection 1025
user-name netconf password cipher $c$3$YhPZ2Xk+MH9BNcxshQ0w8fewibpnQw2ojT1xkP2
hax3HDaE=
destination-address 3.3.3.3
#
在CTRL-VM上执行cudetect cu tunnel-state up-id up-id命令，如果显示信息中“NETCONF Tunnel”字段为NOK或NA，请参见“9.2.1 CP-UP间通道故障探测”检查CP和UP上管理通道的配置详细信息；如果该字段显示为OK，而问题仍未解决，请继续执行以下操作。
(3) 检查UP上的管理通道配置是否存在错误。
在UP上执行display current-configuration | begin ssh命令：
<UP1024> display current-configuration | begin ssh
ssh server enable
ssh user netconf service-type netconf authentication-type password
...
local-user netconf class manage
password hash $h$6$nJfK2tYuvrbih32X$+reBw1rUDg9R3z1rJ2+cs09hYIVQT7IzzxdnZe2/Nsg
liHTsJI+qDT/dbRqLQpP+it44esvq9xRfcujMdRB9Bw==
service-type ssh
authorization-attribute user-role network-admin
authorization-attribute user-role network-operator
#
netconf ssh server enable
#
return
¡ 请确保UP上配置了ssh server enable命令。
¡ 请确保UP上开启了NETCONF over SSH的接入方式（netconf ssh server enable命令）。
(4) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
模块名：HH3C-NCM-MIB
· hh3cNcmCUConnectFailed (1.3.6.1.4.1.25506.2.201.3.0.3)
· NCM/2/NCM_CREATE_CHANNEL_FAILED
CP和UP之间的管理通道未能正常转发管理报文，导致用户业务流量被丢弃。
本类故障的常见原因为物理链路故障，导致CP与UP设备之间的路由不通。
本类故障的诊断流程如图9-4所示。
图9-4 CP和UP之间的管理通道报文转发异常的诊断流程图
(1) 检查物理链路是否存在故障。
在CP上尝试能否ping通UP设备上与CP直连接口的IP地址。
如果不能ping通，则在CP上执行display ip routing-table命令或者display route-static routing-table命令查看去往UP的路由出接口，再执行display interface命令检查该接口状态：
<CTRL-VM> display interface ten-gigabitethernet 1/5/0
Ten-GigabitEthernet1/5/0
Interface index: 386
Current state: Administratively DOWN
Line protocol state: DOWN
...
a. 如果Current state显示为Administratively DOWN，则在接口下执行undo shutdown命令打开关闭的接口。如果Current state显示为DOWN，则检查接口的物理连线是否正确。
b. 在UP上重复以上步骤检查和修复UP上去往CP的路由出接口状态。
c. 如果CP和UP之间存在其他设备，按上述步骤逐跳检查和修复CP和UP之间各设备连接的物理接口状态。
(2) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
模块名：HH3C-NCM-MIB
· hh3cNcmCUConnDisconnected (1.3.6.1.4.1.25506.2.201.3.0.1)
· NCM/1/NCM_SESSION_DISCONNECTED
CP和UP之间未创建控制通道。在CP上执行display cusp controller命令时，没有显示指定UP的CUSP代理信息（即Agent name及UP ID、Control tunnel state等字段）。
本类故障的常见原因包括：
· 物理链路故障，导致CP与UP设备之间的路由不通。
· CP或UP的控制通道配置错误。
本类故障的诊断流程如图9-5所示。
图9-5 CP和UP之间的控制通道创建失败的诊断流程图
(1) 检查物理链路是否存在故障。
在CP上尝试能否ping通UP设备上与CP直连接口的IP地址。
如果不能ping通，则在CP上执行display ip routing-table命令或者display route-static routing-table命令查看去往UP的路由出接口，再执行display interface命令检查该接口状态：
<CTRL-VM> display interface ten-gigabitethernet 1/5/0
Ten-GigabitEthernet1/5/0
Interface index: 386
Current state: Administratively DOWN
Line protocol state: DOWN
...
a. 如果Current state显示为Administratively DOWN，则在接口下执行undo shutdown命令打开关闭的接口。如果Current state显示为DOWN，则检查接口的物理连线是否正确。
b. 在UP上重复以上步骤检查和修复UP上去往CP的路由出接口状态。
c. 如果CP和UP之间存在其他设备，按上述步骤逐跳检查和修复CP和UP之间各设备连接的物理接口状态。
d. 如果CP和指定UP间物理链路正常，而问题仍未解决，请继续执行以下操作。
(2) 检查CP上的控制通道配置是否存在错误。
在CP上执行display current-configuration | begin cusp命令，查看是否配置了listening-ip、agent-ip命令：
<CTRL-VM> display current-configuration | begin cusp
cusp controller
listening-ip 2.2.2.2
agent up1024
agent-ip 1.1.1.1
agent up1025
agent-ip 3.3.3.3
...
在CTRL-VM上执行cudetect cu tunnel-state up-id up-id命令，如果显示信息中“CUSP Tunnel”字段为NOK或NA，请参见“9.2.1 CP-UP间通道故障探测”检查CP和UP上控制通道的配置详细信息；如果该字段显示OK，而问题仍未解决，请继续执行以下操作。
(3) 检查UP上的控制通道配置是否存在错误。
在UP上执行display current-configuration | begin cusp命令：
<UP1024> display current-configuration | begin cusp
cusp agent up1024
local-address 1.1.1.1
controller address 2.2.2.2
...
¡ 请确保UP上local-address命令（cusp-agent视图）和CP上agent-ip命令（agent视图）配置的IP地址一致。
¡ 请确保UP上controller address命令（cusp-agent视图）和CP上listening-ip命令（cusp-controller视图）配置的IP地址一致。
(4) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
模块名：HH3C-CUSP-MIB
· hh3cCuspServerDisconnect (1.3.6.1.4.1.25506.2.190.1.2.0.1)
· hh3cCuspClientDisconnect (1.3.6.1.4.1.25506.2.190.1.2.0.3)
· CUSP/5/CUSP_CP_DISCONNECT
· CUSP/5/CUSP_UP_DISCONNECT
CP和UP之间的控制通道未能正常转发控制报文，导致用户业务流量被丢弃。
本类故障的常见原因为物理链路故障，导致CP与UP设备之间的路由不通。
本类故障的诊断流程如图9-6所示。
图9-6 CP和UP之间的控制通道报文转发异常的诊断流程图
(1) 检查物理链路是否存在故障。
在CP上尝试能否ping通UP设备上与CP直连接口的IP地址。
如果不能ping通，则在CP上执行display ip routing-table命令或者display route-static routing-table命令查看去往UP的路由出接口，再执行display interface命令检查该接口状态：
<CTRL-VM> display interface ten-gigabitethernet 1/5/0
Ten-GigabitEthernet1/5/0
Interface index: 386
Current state: Administratively DOWN
Line protocol state: DOWN
...
a. 如果Current state显示为Administratively DOWN，则在接口下执行undo shutdown命令打开关闭的接口。如果Current state显示为DOWN，则检查接口的物理连线是否正确。
b. 在UP上重复以上步骤检查和修复UP上去往CP的路由出接口状态。
c. 如果CP和UP之间存在其他设备，按上述步骤逐跳检查和修复CP和UP之间各设备连接的物理接口状态。
(2) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
模块名：HH3C-CUSP-MIB
· hh3cCuspServerDisconnect (1.3.6.1.4.1.25506.2.190.1.2.0.1)
· hh3cCuspClientDisconnect (1.3.6.1.4.1.25506.2.190.1.2.0.3)
· CUSP/5/CUSP_CP_DISCONNECT
· CUSP/5/CUSP_UP_DISCONNECT
在CP和UP上分别执行display protocol-tunnel verbose命令，查看到CP和UP之间的VXLAN通道未正常建立，显示信息中的Active字段显示为“No”。
本类故障的常见原因主要包括：
· 协议通道VXLAN相关的配置错误。
· CP和指定UP间CUSP通道故障。
· 物理链路故障。
本类故障的诊断流程如图9-7所示。
图9-7 CP和UP之间的协议通道创建失败的故障诊断流程图
(1) 检查物理链路是否存在故障。
在CP上执行display ip routing-table命令或者display route-static routing-table命令查看去往UP的路由出接口，执行display interface命令检查出接口状态，例如，
<Sysname> display interface ten-gigabitethernet 1/5/0
Ten-GigabitEthernet1/5/0
Interface index: 386
Current state: Administratively DOWN
Line protocol state: DOWN
…
a. 如果Current state显示为Administratively DOWN，则在接口下执行undo shutdown命令打开关闭的接口。如果Current state显示为DOWN，则检查接口的物理连线。
b. 在UP上重复以上步骤检查和修复UP上去往CP的路由出接口状态。
c. 如果CP和UP之间存在其他设备，按上述步骤逐跳检查和修复CP和UP之间各设备连接的物理接口状态。
d. 如果CP和指定UP间物理链路正常，问题仍未解决，则请继续执行以下操作。
(2) 检查协议通道VXLAN相关的配置。
在CP上执行命令display current-configuration configuration up-manage检查CP侧和UP侧协议通道的详细配置信息：
<Sysname> display current-configuration configuration up-manage
up-manage id 1024
protocol-tunnel vxlan 10 source 2.2.2.2 destination 1.1.1.1
cu-agent
protocol-tunnel vxlan 10 source 1.1.1.1 destination 2.2.2.2
¡ 在CTRL-VM上执行cudetect cu tunnel-state up-id up-id命令，如果显示信息中Protocol Tunnel字段为NOK或NA时，请参见“9.2.1 CP-UP间通道故障探测”中的CP和UP上协议通道的配置检查部分排查和修改UP和CP间的协议通道配置。
¡ 如果协议通道VXLAN相关的配置正常，问题仍未解决，则请继续执行以下操作。
(3) 检查CP和指定UP间CUSP通道是否正常。
在CP上执行display cusp controller命令时：
¡ 如果没有显示指定UP的CUSP代理信息（即Agent name及UP ID、Control tunnel state等字段），则表示CUSP通道没有建立成功，请参见“9.2.4 CP和UP之间的控制通道创建失败”故障处理手册继续处理。
¡ 如果Connection state字段显示为“Established”，则表示CUSP通道建立成功。请继续执行下一步。
(4) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
无
无
CP和UP之间的协议通道未能正常转发VXLAN报文，导致用户业务流量被丢弃。
本类故障的常见原因主要包括：
· 协议通道VXLAN相关的配置错误。
· CP没有对UP上的用户上线接口的远程纳管。
· UP未正常上送报文到CP处理。
· CP与UP设备之间物理链路存在故障。
本类故障的诊断流程如图9-8所示。
图9-8 CP和UP之间的协议通道报文转发异常的故障诊断流程图
(1) 检查物理链路是否存在故障。
在CP上执行display ip routing-table命令或者display route-static routing-table命令查看去往UP的路由出接口，执行display interface命令检查出接口状态，例如，
<Sysname> display interface ten-gigabitethernet 1/5/0
Ten-GigabitEthernet1/5/0
Interface index: 386
Current state: Administratively DOWN
Line protocol state: DOWN
…
a. 如果显示为Administratively DOWN，则在接口下执行undo shutdown命令打开关闭的接口。如果Current state显示为DOWN，则检查接口的物理连线。
b. 在UP上重复以上步骤检查和修复UP上去往CP的路由出接口状态。
c. 如果CP和UP之间存在其他设备，按上述步骤逐跳检查和修复CP和UP之间各设备连接的物理接口状态。
d. 如果CP和指定UP间物理链路正常，问题仍未解决，则请继续执行以下操作。
(2) 检查协议通道VXLAN相关的配置。
在CP上执行命令display current-configuration configuration up-manage检查CP侧和UP侧协议通道的详细配置信息：
<Sysname> display current-configuration configuration up-manage
up-manage id 1024
protocol-tunnel vxlan 10 source 2.2.2.2 destination 1.1.1.1
cu-agent
protocol-tunnel vxlan 10 source 1.1.1.1 destination 2.2.2.2
¡ 在CTRL-VM上执行cudetect cu tunnel-state up-id up-id命令，如果显示信息中Protocol Tunnel字段为NOK或NA时，请参见“9.2.1 CP-UP间通道故障探测”中的CP和UP上协议通道的配置检查部分排查和修改UP和CP间的协议通道配置。
¡ 如果协议通道VXLAN相关的配置正常，问题仍未解决，则请继续执行以下操作。
(3) 检查远端接口是否被管理。
在UP上的用户上线接口下执行display this命令，查看当前接口上是否存在cp-management配置。
¡ 若存在则表示当前接口已正常接受CP的远程管理，BRAS相关配置被正常下发；
¡ 若不存在则表示当前接口未接受CP的远程管理，请参见“9.2.2 CP和UP之间的管理通道创建失败”和“9.2.4 CP和UP之间的控制通道创建失败”排查管理通道或控制通道故障。
¡ 如果远端接口被正常管理，问题仍未解决，则请继续执行以下操作。
(4) 检查CP和UP之间协议报文的交互是否正常。
在用户端模拟反复上线拨号操作，同时在CP上以一定的间隔（推荐30秒）重复执行display protocol-tunnel packet statistics命令，查看显示的协议通道的报文统计信息，并记录每次显示的Input packet statistics值：
¡ 若对应的报文计数有增加，则表示VXLAN协议通道正常。
¡ 若对应的报文计数没有增加，则表示CP上未收到UP的协议报文。以一定的间隔（推荐30秒）重复执行display protocol-tunnel packet statistics命令，并记录每次显示Output packet statistics值：
<Sysname> display protocol-tunnel packet statistics
Input packet statistics:
Total: 7283
PPPoE PADI and PADO: 3
Other PPPoE: 0
DHCP DISCOVER and OFFER: 129
Other DHCP: 181
DHCPv6: 0
ND: 6970
L2TP: 0
ARP: 0
IPv4 data miss: 0
IPv6 data miss: 0
Ethernet: 0
IPv4: 0
IPv6: 0
Drop: 0
Output packet statistics:
Total: 1121
PPPoE PADI and PADO: 6
Other PPPoE: 0
DHCP DISCOVER and OFFER: 284
Other DHCP: 393
DHCPv6: 0
ND: 0
L2TP: 0
ARP: 0
IPv4 data miss: 417
IPv6 data miss: 21
Ethernet: 0
IPv4: 0
IPv6: 0
Drop: 0
若对应报文计数没有增加，则执行debugging ucm forward all命令打开UCM的调试信息开关，收集调试信息，并继续执行以下操作。
(5) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
无
无
采用VNFM-vBRAS对VM进行手工扩缩容失败。
本类故障的常见原因主要包括：
· 对BRAS-VM进行手工缩容时，BRAS-VM关联了UP。
· vBRAS与VNFM-vBRAS之间的链路故障。
· vBRAS与VNFM-vBRAS之间的连接配置错误。
· 部署VM的服务器硬件资源不足。
本类故障的诊断流程如图9-9所示。
图9-9 对VM手动伸缩失败的故障诊断流程图
(1) 检查BRAS-VM是否关联了UP。
当进行手工扩容操作时，无论BRAS-VM是否关联UP，请执行步骤(2)。
当进行手工缩容操作时，请在CP上执行display bras-vm-up associated-info命令查看BRAS-VM与UP的关联信息。
<Sysname> display bras-vm-up associated-info
Slot UP ID
129, 130 1024
¡ 如果BRAS-VM关联了UP，则请在CP上执行up-migrate to bras-vm命令将UP从该BRAS-VM迁出。
¡ 如果BRAS-VM未关联UP，则执行步骤(2)。
(2) 检查vBRAS与VNFM-vBRAS之间的链路是否故障。
如果CP上输出如下日志信息，则表示vBRAS与VNFM-vBRAS之间的链路存在故障。
VMMGR/4/VMMGR_CREATE_FAIL: Failed to manually create VM 99 in group 67. Reason: Failed to connect to the vBRASSO server.
VMMGR/4/VMMGR_DELETE_FAIL: Failed to delete the manually created VM on slot 99 in group 67. Reason: Connection with the vBRASSO server timed out.
请在CTRL-VM上执行ping命令，检测到VNFM-vBRAS的IP地址的连通性。
¡ 如果不可以ping通，则请参见“Ping不通故障处理”进行定位。
¡ 如果可以ping通，则执行步骤(3)。
(3) 检查vBRAS与VNFM-vBRAS之间的连接配置是否错误。
如果存在以下情况，则表示vBRAS与VNFM-vBRAS之间的连接配置错误：
¡ CP上输出如下日志信息：
VMMGR/4/VMMGR_CREATE_FAIL: Failed to manually create VM 99 in group 67. Reason: Failed to connect to the vBRASSO server.
VMMGR/4/VMMGR_DELETE_FAIL: Failed to delete the manually created VM on slot 99 in group 67. Reason: Connection with the vBRASSO server timed out.
¡ 在CP上执行display vbras-cp stable state vnfm命令显示VNFM模块的运行状态信息，显示和VNFM的通信状态为Not configured或Disconnected。
<Sysname> display vbras-cp stable state vnfm
------------------------------VNFM state------------------------------
VNFM communication state: Connected
请在CP上执行display current-configuration命令查看VNFM-vBRAS的配置信息，需要确保vnfm address命令的配置和登录VNFM-vBRAS时实际使用的IP地址、端口号、用户名、密码和与VNFM-vBRAS通信的方式（HTTP或HTTPS）一致，以保证各功能模块能够和VNFM-vBRAS正常通信。
<Sysname> display current-configuration | include vnfm
vnfm address 192.168.73.33 user test password simple 123456789 http-method port 30000
¡ 如果VNFM-vBRAS配置不正确，则执行vnfm address命令修改VNFM-vBRAS的配置信息。
¡ 如果VNFM-vBRAS配置正确，则执行步骤(4)。
(4) 检查VM部署是否正常。
如果CP上输出如下日志信息，则表示VM部署不正常。
VMMGR/4/VMMGR_CREATE_FAIL: Failed to manually create VM 99 in group 67. Reason: The vBRASSO server failed to create the VM.
VMMGR/4/VMMGR_DELETE_FAIL: Failed to delete the manually created VM on slot 99 in group 67. Reason: The vBRASSO server failed to delete the VM.
¡ 如果VM部署不正常，则请参见“9.6.3 虚拟机部署失败”和“9.6.4 资源不足导致VM创建或启动失败”进行定位。
¡ 如果VM部署正常，则执行步骤(5)。
(5) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
模块名：HH3C-VNF-DEVICE-MIB
· hh3cVmCreateFail (1.3.6.1.4.1.25506.2.196.3.0.4)
· hh3cVmDeleteFail (1.3.6.1.4.1.25506.2.196.3.0.6)
· VMMGR/4/VMMGR_CREATE_FAIL
· VMMGR/4/VMMGR_DELETE_FAIL
对VM进行自动扩缩容失败。
本类故障的常见原因主要包括：
· 未开启BRAS-VM自动扩缩容功能。
· 自动扩缩容的延时时间到达后，不满足扩缩容条件。
· vBRAS与VNFM-vBRAS之间的链路故障。
· vBRAS与VNFM-vBRAS之间的连接配置错误。
· 部署VM的服务器硬件资源不足。
本类故障的诊断流程如图9-10所示。
图9-10 对VM自动扩缩容失败的故障诊断流程图
(1) 判断是否基于UP数进行自动扩缩容失败。
在CP上执行display bras-scale capacity命令查看当前BRAS-VM的扩缩容能力。
<Sysname> display bras-scale capacity slot 129
Slot: 129, 130
Current UP count: 16
UP count threshold: 64
Current user count: 1000
Max user count: 2000000
User count lower threshold: 200000
User count alert threshold: 1600000
User count upper threshold: 1800000
Current delay time: 300s(will expand to 600s after 2 retry)
¡ 如果Current UP count（当前UP数）字段的值大于等于UP count threshold（UP扩容门限）字段的值、或者Current UP count（当前UP数）字段的值为0，则表示基于UP数进行自动扩缩容失败，请执行步骤(2)。
¡ 如果Current UP count（当前UP数）字段的值小于UP count threshold（UP扩容门限）字段的值、或者Current UP count（当前UP数）字段的值不为0，则表示基于用户数进行自动扩缩容失败，请执行步骤(3)。
(2) 检查BRAS-VM自动扩缩容功能是否开启。
在CP上执行display current-configuration命令查看BRAS-VM自动扩缩容功能是否开启。
<Sysname> display current-configuration | include bras-scale
bras-scale enable
¡ 如果BRAS-VM自动扩缩容功能未开启，则在系统视图下执行bras-scale enable命令开启BRAS-VM自动扩缩容功能。
¡ 如果BRAS-VM自动扩缩容功能开启，则执行步骤(3)。
(3) 检查BRAS-VM自动扩缩容的超时时间是否到达。
如果CP上输出如下日志信息，则表示已到达BRAS-VM自动扩缩容的超时时间。
VMMGR/4/VMMGR_CREATE_FAIL_FINAL: Failed to automatically create VM 99 in group 67 after the maximum number of retries reached.
VMMGR/4/VMMGR_DELETE_FAIL_FINAL: Failed to delete the automatically created VM on slot 99 in group 67 after the maximum number of retries reached.
请在CP上执行display bras-scale capacity命令查看当前的自动扩缩容的延迟时间。
<Sysname> display bras-scale capacity slot 129
Slot: 129, 130
Current UP count: 16
UP count threshold: 64
Current user count: 1000
Max user count: 2000000
User count lower threshold: 200000
User count alert threshold: 1600000
User count upper threshold: 1800000
Current delay time: 300s(will expand to 600s after 2 retry)
¡ 如果Current delay time字段显示值大于bras-scale delay-time命令配置值，则表示自动扩缩容的超时时间超时，请等待Current delay time所对应的时间再进行用户上下线操作。
¡ 如果Current delay time字段显示值与bras-scale delay-time命令配置值相同，则表示自动扩缩容的超时时间未超时，请执行步骤(4)。
(4) 检查vBRAS与VNFM-vBRAS之间的链路是否故障。
如果CP上输出如下日志信息，则表示vBRAS与VNFM-vBRAS之间的链路存在故障。
VMMGR/4/VMMGR_CREATE_FAIL: Failed to manually create VM 99 in group 67. Reason: Failed to connect to the vBRASSO server.
VMMGR/4/VMMGR_DELETE_FAIL: Failed to delete the manually created VM on slot 99 in group 67. Reason: Connection with the vBRASSO server timed out.
请在CTRL-VM上执行ping命令，检测到VNFM-vBRAS的IP地址的连通性。
¡ 如果不可以ping通，则请参见“Ping不通故障处理”进行定位。
¡ 如果可以ping通，则执行步骤(5)。
(5) 检查vBRAS与VNFM-vBRAS之间的连接配置是否错误。
如果存在以下情况，则表示vBRAS与VNFM-vBRAS之间的连接配置错误：
¡ CP上输出如下日志信息：
VMMGR/4/VMMGR_CREATE_FAIL: Failed to manually create VM 99 in group 67. Reason: Failed to connect to the vBRASSO server.
VMMGR/4/VMMGR_DELETE_FAIL: Failed to delete the manually created VM on slot 99 in group 67. Reason: Connection with the vBRASSO server timed out.
¡ 在CP上执行display vbras-cp stable state vnfm命令显示VNFM模块的运行状态信息，显示和VNFM的通信状态为Not configured或Disconnected。
<Sysname> display vbras-cp stable state vnfm
------------------------------VNFM state------------------------------
VNFM communication state: Connected
请在CP上执行display current-configuration命令查看VNFM-vBRAS的配置信息，需要确保vnfm address命令的配置和登录VNFM-vBRAS时实际使用的IP地址、端口号、用户名、密码和与VNFM-vBRAS通信的方式（HTTP或HTTPS）一致，以保证各功能模块能够和VNFM-vBRAS正常通信。
<Sysname> display current-configuration | include vnfm
vnfm address 192.168.73.33 user test password simple 123456789 http-method port 30000
¡ 如果VNFM-vBRAS配置不正确，则执行vnfm address命令修改VNFM-vBRAS的配置信息。
¡ 如果VNFM-vBRAS配置正确，则执行步骤(6)。
(6) 检查VM部署是否正常。
如果CP上输出如下日志信息，则表示VM部署不正常。
VMMGR/4/VMMGR_CREATE_FAIL: Failed to manually create VM 99 in group 67. Reason: The vBRASSO server failed to create the VM.
VMMGR/4/VMMGR_DELETE_FAIL: Failed to delete the manually created VM on slot 99 in group 67. Reason: The vBRASSO server failed to delete the VM.
¡ 如果VM部署不正常，则请参见“9.6.3 虚拟机部署失败”和“9.6.4 资源不足导致VM创建或启动失败”进行定位。
¡ 如果VM部署正常，则执行步骤(7)。
(7) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
模块名：HH3C-VNF-DEVICE-MIB
· hh3cVmCreateFail (1.3.6.1.4.1.25506.2.196.3.0.4)
· hh3cVmDeleteFail (1.3.6.1.4.1.25506.2.196.3.0.6)
· VMMGR/4/VMMGR_CREATE_FAIL
· VMMGR/4/VMMGR_CREATE_FAIL_FINAL
· VMMGR/4/VMMGR_DELETE_FAIL
· VMMGR/4/VMMGR_DELETE_FAIL_FINAL
在CP上通过display bras-vm-up associated-info命令查看BRAS-VM与UP的关联信息，发现存在未被管理的UP，即UP无对应的BRAS-VM信息。
<CP> display bras-vm-up associated-info
Slot UP ID
1024
129, 130 1025
本类故障的常见原因主要包括：
· UP数或者用户数超过BRAS-VM的管理上限。
· 自动扩缩容时服务器资源不足，BRAS-VM扩缩容失败。
本类故障的诊断思路如下：
(1) 确认UP数是否超过BRAS-VM的管理上限。
(2) 确认用户数是否超过BRAS-VM的管理上限。
本类故障的诊断流程如图9-11所示。
图9-11 UP预分配失败故障诊断流程图
(1) 检查UP数是否超过了BRAS-VM的管理上限。
执行display bras-scale capacity命令查看当前BRAS-VM的扩缩容能力。
<Sysname> display bras-scale capacity slot 129
Slot: 129, 130
Current UP count: 16
UP count threshold: 64
Current user count: 1000
Max user count: 2000000
User count lower threshold: 200000
User count alert threshold: 1600000
User count upper threshold: 1800000
Current delay time: 300s(will expand to 600s after 2 retry)
¡ 如果Current UP count（当前UP数）字段的值大于等于UP count threshold（UP扩容门限）字段的值，则表示UP数超过了BRAS-VM的管理上限，请执行bras-scale capacity up-count-threshold命令调整UP扩容门限。
¡ 如果Current UP count（当前UP数）字段的值小于UP count threshold（UP扩容门限）字段的值，则表示UP数未超过了BRAS-VM的管理上限，请执行步骤(2)。
(2) 检查用户数是否超过了BRAS-VM的管理上限。
执行display bras-scale capacity命令查看当前BRAS-VM的扩缩容能力。
<Sysname> display bras-scale capacity slot 129
Slot: 129, 130
Current UP count: 16
UP count threshold: 64
Current user count: 1000
Max user count: 2000000
User count lower threshold: 200000
User count alert threshold: 1600000
User count upper threshold: 1800000
Current delay time: 300s(will expand to 600s after 2 retry)
¡ 如果Current user count（当前用户数）字段的值大于等于User count upper threshold（用户数扩容门限）字段的值，则表示用户数超过BRAS-VM的管理上限，请执行bras-scale capacity user-count-threshold命令调整用户数扩容门限。
¡ 如果Current user count（当前用户数）字段的值小于User count upper threshold（用户数扩容门限）字段的值，则表示用户数未超过BRAS-VM的管理上限，请执行步骤(3)。
自动扩缩容失败后，登录服务器主机的CAS管理页面，查看虚拟机资源使用情况：
¡ 如果服务器资源不足，则请对服务器进行扩容。
¡ 如果服务器资源充足，则执行步骤(4)。
(4) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
无
· UPLB_SCALE_EXPAND_FAILED
· UPLB_SCALE_SHRINK_FAILED
· 热备模式下，用户在主CP上线后，用户信息无法备份到备CP。
· 互为主备的CP无法协商出主备角色，出现双主或者双备。
· 主备切换后新用户无法通过新主CP上线。
本类故障的常见原因主要包括：
· 路由故障。
· CP心跳通道未建立成功。
· CP数据备份通道未建立成功。
· 设备发送RADIUS报文使用的源接口配置错误。
· 主备CP上配置不一致。
本类故障的诊断流程如图9-12所示：
图9-12 CP异地容灾故障诊断流程图
(1) 检查主备CP之间路由是否可达。
在其中一台CP上ping另一台CP，如果可以ping通，则继续下一步。如果不能ping通，则解决路由不通问题。
(2) 检查主备和UP之间路由是否可达。
在UP上分别ping主备CP，如果都可以ping通，则继续下一步。如果不能ping通，则解决路由不通问题。
(3) 检查主CP和AAA等服务器间路由是否可达。
在主CP上ping AAA等服务器，如果可以ping通，则继续下一步。如果不能ping通，则解决路由不通问题。
(4) 检查主备CP上BRAS相关配置是否一致。
在主备CP上均执行display current-configuration命令，对比主备CP上配置是否一致，例如IP地址池配置、设备发送RADIUS报文使用的源接口配置等。若一致，请继续下一步；若不一致，请修改为一致。
(5) 检查主备CP间容灾通道是否正常。
请执行下列操作，检查主备CP间容灾通道是否正常。
¡ 执行display cp disaster-recovery data-tunnel命令，查看数据备份通道连接状态，若未正常建立则检查数据通道配置以及网络配置、链路连接状态。
¡ 执行display cp disaster-recovery heartbeat-tunnel命令查看心跳通道的TCP连接状态，若未正常建立，则检查心跳通道相关配置以及网络配置、链路连接状态。
¡ 执行display cp disaster-recovery protect-tunnel statistics命令查看灾备保护通道的报文统计是否正常，若不正常，则检查相关配置以及网络配置、链路连接状态。
¡ 执行display cp disaster-recovery group命令查看CP灾备组的配置和运行数据信息，若CUSP通道连接异常则继续执行下一步。
(6) 检查CU通道是否连接正常
在CP执行命令display cusp controller显示CUSP控制器的连接信息。
在UP执行命令display cusp agent显示CUSP代理的连接信息。
若是CUSP通道连接异常，则检查CUSP配置，并根据CUSP连接故障处理手册继续排查。
(7) 检查设备是否处于稳态
在CP上执行display vbras-cp stable state命令查看转发与控制分离系统是否处于稳定状态。
(8) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
主备接口处于非正常工作状态。在CP设备上执行display up-backup-profile命令，显示信息中Master字段标识的主用接口对应的state字段取值不是master(normal)，或者Backup字段标识的备用接口对应的state字段取值不是backup(normal)。
<Sysname> display up-backup-profile
...
Interface group 1:
Master: Remote-XGE1024/1/0/1, state=backup(normal), VRID=1
Backup: Remote-XGE1025/1/0/1, state=master(normal)
...
本类故障的常见原因主要包括：
· UP上主备接口物理链路Down。
· 接口所在UP与CP之间的CUSP通道故障。
· UP上Track监测项状态异常。
· CP上关闭了故障恢复后的回切功能。
本类故障的诊断思路如下：
(1) 检查UP上主备接口物理链路状态是否正常。
(2) 通过备份策略模板的显示信息，查看故障的具体原因。
(3) 检查接口所在UP与CP之间的CUSP通道状态。
(4) 检查UP侧Track监控状态。
(5) 检查CP上的故障恢复后的回切功能是否正常。
本类故障的诊断流程如图9-13所示。
(1) 检查UP上主备接口物理链路状态是否正常。
在UP上执行display interface命令检查出接口状态，例如：
<Sysname> display interface ten-gigabitethernet 3/1/1
Ten-GigabitEthernet3/1/1
Interface index: 386
Current state: Administratively DOWN
Line protocol state: DOWN
…
a. 如果Current state显示为Administratively DOWN，则在接口下执行undo shutdown命令打开关闭的接口。
b. 如果Current state显示为DOWN，则检查接口的物理连线。
c. 在UP上重复以上步骤检查和修复UP上去往CP的路由出接口状态。
d. 如果CP和指定UP间物理链路正常，问题仍未解决，则请继续执行以下操作。
(2) 在CP上执行display up-backup-profile命令，查看备份策略模板的显示信息。有以下几种情况：
¡ 如果Reason字段显示为CUSP down，则表示主接口所在UP和CP之间的CUSP通道故障，请执行步骤(3)。
¡ 如果Reason字段显示为Track negative，则表示UP通过Track监控到网络侧接口的状态为Down，请执行步骤(4)。
¡ 如果Failure recovery字段显示为Disabled，则表示故障恢复的回切功能处于关闭状态，请执行步骤(5)。
(3) 检查接口所在UP与CP之间的CUSP通道状态。
在CP上执行display cusp controller命令显示指定的UP与CP间CUSP控制器的连接信息。
¡ 如果显示信息中Control tunnel state为Inactive，则请参考“9.2.4 CP和UP之间的控制通道创建失败”处理。
¡ 如果显示信息中Control tunnel state为Active，则表示CUSP通道状态正常，故障仍未解决，则请继续执行以下操作。
(4) 检查UP侧Track监控状态。
在CP上的UP备份策略模板视图下执行display this命令，查看是否配置了CP监控UP的网络侧Track监控命令：up-id up-id network-state track uplink-group group-name。
¡ 如果存在该配置，则需要在主用接口所在的UP上查找与CP侧匹配的Track项联动命令user-plane switchover track track-id uplink-group group-name，它们所属的uplink-group group-name相同。然后执行display track track-id命令，查看UP上的对应Track项的状态，如果State显示为Negative则表示Track项关联的监测对象异常。例如：
<Sysname> display track all
Track ID: 2
State: Negative
Duration: 0 days 0 hours 0 minutes 32 seconds
Tracked object type: BFD
Notification delay: Positive 20, Negative 30 (in seconds)
Tracked object:
BFD session mode: Echo
Outgoing interface: Ten-GigabitEthernet3/1/1
…
则按照Tracked object的信息，排查监测对象的异常。
¡ 如果不存在该配置，查看UP上的对应Track项的状态时，State显示为Positive，请继续以下操作排查其他原因。
(5) 检查CP上的故障恢复后的回切功能是否正常。
在CP上在UP备份策略模板视图下执行display this命令，检查CP上的故障恢复后的回切功能是否开启。
¡ 如果未开启，则执行failure-recovery-switch enable命令，开启主UP或主UP接口故障恢复后的回切功能。
¡ 如果故障恢复的回切功能已开启，请合理配置delay delay-time值，例如30秒。配置的delay-time过大时，主UP或主UP接口故障恢复后无法及时回切，可能会影响工作效率；配置的delay-time过小时，可能会导致主备切换频繁。
¡ 如果故障恢复后的回切功能配置正常，问题仍未解决，则请继续执行以下操作。
(6) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、告警信息
¡ 执行display system internal up-backup log event命令记录UP备份的日志事件信息。
无
· UPBAK/6/UPBAK_IF_STATE_CHANGE
· UPBAK/6/UPBAK_IF_STATE_SWITCH
主备接口切换耗时长，主接口故障后不能及时切换到备份接口或者主接口故障恢复后，不能及时回切，导致用户流量中断。
本类故障的常见原因主要包括：
· 设置的故障恢复回切延迟过长。
· 配置CUSP通道故障时的延迟切换时间过长。
· 配置CUSP通道故障恢复时的延迟回切时间过长。
· 业务模块处理慢。
本类故障的诊断思路如下：
(1) 检查是否配置的主UP或主UP接口故障恢复后的回切延迟时间过长。
(2) 检查是否配置CUSP通道故障时的延迟切换时间过长。
(3) 检查是否配置CUSP通道故障恢复时的延迟切换时间过长。
(4) 检查是否业务模块处理切换事件慢。
本类故障的诊断流程如图9-14所示。
(1) 在CP设备上执行display up-backup-profile命令，检查显示信息中Delay time的延迟时间，判断时延是否设置过长，例如：
<Sysname> display up-backup-profile 1
Profile ID: 1
Backup mode: Hot standby
Failure recovery: Enabled Delay time: 1800 seconds
CUSP tunnel down switchover Delay time: 1800 seconds
CUSP tunnel up switchover Delay time: 60000 milliseconds
Route advertise: Disabled
Interface backup mode: Inherit-main
Interface group 1:
Master: Remote-XGE2009/1/3/0, state=backup(normal), VRID=2
Backup: Remote-XGE2000/1/3/0, state=master(normal)
Switchback state: Waiting(remaining time: 1797 seconds)
¡ 显示信息中Failure recovery字段为Enabled，表示故障恢复的回切功能开启，故障回切时延取值范围为0～1800秒，默认值为30秒。如果Delay time远大于30秒，请执行步骤(2)。
¡ 显示信息中CUSP tunnel down switchover字段对应的Delay time表示CUSP通道故障时的延迟切换时间，取值范围是0～1800秒。缺省情况下，当CP设备和某个UP设备之间CUSP连接发生故障时，CP设备延迟50ms对UP设备或该UP设备上的接口做主备切换。如果Delay time远大于50ms，请执行步骤(3)。
¡ 显示信息中CUSP tunnel up switchover字段对应的Delay time表示CUSP通道故障恢复时的延迟切换时间，取值范围是0～60000毫秒，缺省情况下，当CP设备和某个UP设备之间CUSP连接的故障恢复时，CP设备在3秒后对该UP设备上的接口或UP做主备切换。如果Delay time远大于3秒，请执行步骤(4)。
(2) 如果步骤(1)中发现故障恢复的回切时延过长，则调整故障恢复回切延迟时间。
在CP上的UP备份策略模板视图或CGN-UP备份策略模板视图执行failure-recovery-switch enable [ delay delay-time ]命令，通过指定delay delay-time参数调整故障恢复回切延迟时间。如果故障恢复回切延迟时间合适，问题仍未解决，则请继续执行以下操作。
(3) 如果步骤(1)中发现CUSP通道故障时的延迟切换过长，则调整CUSP通道故障时的延迟切换时间。
在CP上的UP备份策略模板视图或CGN-UP备份策略模板视图执行control-tunnel-down switchover [ delay sec-delay-time | msec-delay msec-delay-time ]命令修改CUSP通道故障时的延迟切换时间。如果CUSP通道故障时的延迟切换时间合适，问题仍未解决，则请继续执行以下操作。
(4) 如果步骤(1)中发现CUSP通道故障恢复的延迟切换过长，则调整CUSP通道故障恢复的延迟切换时间。
在CP上的UP备份策略模板视图或CGN-UP备份策略模板视图执行control-tunnel-up switchover msec-delay delay-time命令修改CUSP通道故障恢复的延迟切换时间。如果CUSP通道故障恢复的延迟切换时间，问题仍未解决，则请继续执行以下操作。
(5) 如果存在业务模块阻塞，请等待60s后超时自动主备切换。如果等待60s后超时后，问题仍未解决，则请继续执行以下操作。
(6) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、告警信息。
¡ 执行display system internal up-backup log event命令记录UP备份的日志事件信息。
无
主备切换时，CP通知UP侧主用接口切换为备份工作状态、备用接口切换为主用工作状态，但主用接口状态未改变，导致存在双主接口。出现双主接口的场景时，与UP对接的用户接入设备会反复刷新业务转发接口，产生转发表项震荡，业务流量产生丢包。
在主备接口所在UP上分别执行display system internal up interface-backup命令，显示信息中主备接口的State字段都为Master。
<Sysname> system-view
[Sysname] probe
[Sysname-probe] display system internal up interface-backup
Interface: Ten-GigabitEthernet3/1/4
IfIndex: 65
State: Master
Backup mode: Hot standby
Interface backup mode: Inherit-main
Resource ID: 0x20001
Virtual MAC: 0000-5e00-0101
Switchover upon ctrl tunnel down: Enabled
Switchover delay: 0
本类故障的常见原因主要包括：
· 主用接口所在的UP与CP间CUSP通道故障，且配置了UP设备的主用接口不切换为备用接口。
· UCM业务模块未通知UP备份模块的主接口切换为备份工作状态。
本类故障的诊断思路如下：
(1) 在CP上检查备份组切换原因，在UP侧检查是否配置了UP设备的主用接口不切换为备用接口。
(2) 恢复CP和UP间的CUSP通道。
本类故障的诊断流程如图9-15所示。
图9-15 UP侧出现双主接口的诊断流程图
(1) 在CP上执行display up-backup-profile profile-id switch-history命令，检查最近一次的故障切换原因。
<Sysname> display up-backup-profile 1 switch-history
Reason Interface State Time
CUSP down Remote-XGE2009/1/3/0 Switchover to backup 2021-08-30 04:28:39
¡ 如果Reason字段显示为CUSP down表示最近一次切换是由CUSP故障导致，则执行步骤(2)，进一步排查UP侧配置，且修复CP和UP之间的CUSP通道。
¡ 如果Reason字段不显示为CUSP down，则表示业务模块可能存在问题导致UP侧双主，则执行步骤(3)，收集UP备份的日志事件信息。
(2) 检查UP侧配置，执行display current-configuration命令检查是否配置了UP设备的主用接口不切换为备用接口，具体命令形式为user-plane control-tunnel-down switchover track track-id。
在CP上执行display cusp controller命令显示指定的UP与CP间CUSP控制器的连接信息。
¡ 如果显示信息中Control tunnel state为Inactive，则请参考“9.2.4 CP和UP之间的控制通道创建失败”处理。
¡ 如果显示信息中Control tunnel state为Active，则表示CUSP通道状态正常，故障仍未解决，则请继续执行以下操作。
(3) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、告警信息。
¡ 执行display system internal up-backup log event命令记录UP备份的日志事件信息。
无
无
主备接口所在UP与CP间的CUSP通道都故障，CP无法通知主备接口状态切换，同时主备接口也都发生故障，此时存在双备接口的情况。用户的业务流量转发到主备UP上都会无法处理，此时用户无法上线。
在主备接口所在UP上分别执行display system internal up interface-backup命令，显示信息中主备接口的State字段都为Backup，
<Sysname> system-view
[Sysname] probe
[Sysname-probe]display system internal up interface-backup
Interface: Ten-GigabitEthernet3/1/4
IfIndex: 65
State: Backup
Backup mode: Hot standby
Interface backup mode: Inherit-main
Resource ID: 0x20001
Virtual MAC: 0000-5e00-0101
Switchover upon ctrl tunnel down: Enabled
Switchover delay: 0
本类故障的常见原因主要包括：
· 主备接口发生故障，主备接口所在UP与CP间的CUSP通道都故障，且均未配置UP设备的主用接口不切换为备用接口。
· UCM业务模块未通知UP备份模块的备用接口切换为主用工作状态。
本类故障的诊断思路如下：
(1) 检查UP上主备接口物理链路状态是否正常。
(2) 检查CP和UP间的CUSP是否故障。
(3) 记录UP备份的日志事件信息。
本类故障的诊断流程如图9-16所示。
图9-16 UP侧出现双备接口的诊断流程图
(1) 检查UP上主备接口物理链路状态是否正常。
在UP上执行display interface命令检查出接口状态，例如：
<Sysname> display interface ten-gigabitethernet 3/1/1
Ten-GigabitEthernet3/1/1
Interface index: 386
Current state: Administratively DOWN
Line protocol state: DOWN
…
a. 如果Current state显示为Administratively DOWN，则在接口下执行undo shutdown命令打开关闭的接口。
b. 如果Current state显示为DOWN，则检查接口的物理连线。
c. 在UP上重复以上步骤检查和修复UP上去往CP的路由出接口状态。
d. 如果CP和指定UP间物理链路正常，问题仍未解决，则请继续执行以下操作。
(2) 检查接口所在UP与CP之间的CUSP通道状态。
在CP上执行display cusp controller命令显示指定的UP与CP间CUSP控制器的连接信息。
¡ 如果显示信息中Control tunnel state为Inactive，则请参考“9.2.4 CP和UP之间的控制通道创建失败”处理。
¡ 如果显示信息中Control tunnel state为Active，则表示CUSP通道状态正常，故障仍未解决，则请继续执行以下操作。
(3) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、告警信息。
¡ 执行display system internal up-backup log event命令记录UP备份的日志事件信息。
无
· UPBAK/6/UPBAK_IF_STATE_NO_MASTER
在UP温备组网环境中，CP和主用UP上的用户数据不一致。
本类故障的常见原因主要包括：
· UP侧没有配置work-mode user-plane命令。
· CP和UP之间控制通道处于Inactive状态。
· CP和UP之间控制通道报文转发异常。
· 设备处于非稳态，例如：CP和UP正在平滑数据、UP的内存利用率过高、主备UP切换还未完成、用户正在下线或者上线。
本类故障的诊断流程如图9-17所示。
图9-17 CP和UP数据不一致故障处理的故障诊断流程图
(1) 检查UP是否配置work-mode user-plane命令。
在UP上执行命令display current-configuration查看是否配置work-mode user-plane命令：
¡ 如果未配置，则请在UP的系统视图下配置work-mode user-plane命令。
¡ 如果已配置，则执行步骤(2)。
(2) 检查CP和UP之间的控制通道状态是否正常。
在CP上执行display cusp controller命令、在UP上执行display cusp agent命令，通过Control tunnel state字段查看CP和UP之间的控制通道状态：
<CP> display cusp controller
CUSP version : 2
Controller IP : 2.2.2.2
VPN instance : --
SSL policy : --
BFD state : Disabled
BFD template : --
Echo interval : 30s
Echo timeout threshold : 4
Vendor ID : 25506
Keychain name : --
Disconnection entry aging time : Not aging
Agent name: up1
Vendor ID : 25506
CUSP version : 2
UP ID : 1026
Control tunnel state : Active
Agent IP : 1.1.1.1
Connection state : Established
Packets sent : 2209
Packets received : 2204
Standby controller : Disconnected
<UP> display cusp agent
Agent name : up1
Vendor ID : 25506
CUSP version : 2
Agent IP : 1.1.1.1
VPN instance : --
SSL policy : --
BFD state : Disable
BFD template : --
Echo interval : 30s
Echo timeout threshold : 4
Keychain name : --
Disconnection entry aging time : Not aging
First connection delay time : Not delayed
Controller information:
Vendor ID : 25506
Control tunnel state : Active
Controller IP : 2.2.2.2
Connection state : Established
Packets sent : 2204
Packets received : 2209
¡ 如果CP和UP之间控制通道状态为Inactive，则表示控制通道处于未激活状态，请参考“9.2.4 CP和UP之间的控制通道创建失败”处理。
¡ 如果CP和UP之间控制通道状态为Active，则表示控制通道处于激活状态，请执行步骤(3)。
(3) 检查CP和UP之间的控制通道的报文转发是否正常。
在CP上执行display cusp controller命令、在UP上执行display cusp agent命令，通过Packets sent和Packets received字段查看CP和UP之间的控制通道的报文收发情况：
<CP> display cusp controller
CUSP version : 2
Controller IP : 2.2.2.2
VPN instance : --
SSL policy : --
BFD state : Disabled
BFD template : --
Echo interval : 30s
Echo timeout threshold : 4
Vendor ID : 25506
Keychain name : --
Disconnection entry aging time : Not aging
Agent name: up1
Vendor ID : 25506
CUSP version : 2
UP ID : 1026
Control tunnel state : Active
Agent IP : 1.1.1.1
Connection state : Established
Packets sent : 2209
Packets received : 2204
Standby controller : Disconnected
<UP> display cusp agent
Agent name : up1
Vendor ID : 25506
CUSP version : 2
Agent IP : 1.1.1.1
VPN instance : --
SSL policy : --
BFD state : Disable
BFD template : --
Echo interval : 30s
Echo timeout threshold : 4
Keychain name : --
Disconnection entry aging time : Not aging
First connection delay time : Not delayed
Controller information:
Vendor ID : 25506
Control tunnel state : Active
Controller IP : 2.2.2.2
Connection state : Established
Packets sent : 2204
Packets received : 2209
¡ 如果CP上Packets sent和UP上Packets received字段数据相差较大，则表示控制通道报文转发异常，请按照CP和UP之间的控制通道报文转发异常故障进行定位。
¡ 如果CP上Packets sent和UP上Packets received字段数据基本一致，则表示控制通道报文转发正常，请执行步骤(4)。
(4) 检查UP的内存利用率是否过高。
在UP上执行display memory-threshold命令，通过Current free-memory state字段查看内存使用状态：
<UP> display memory-threshold
Memory usage threshold: 100%
Free-memory thresholds:
Minor: 235M
Severe: 156M
Critical: 78M
Normal: 313M
Early-warning: 391M
Secure: 470M
Current free-memory state: Normal (secure)
…
¡ 如果内存使用状态异常，则请按照内存占用率高故障进行定位。
¡ 如果内存使用状态正常，则执行步骤(5)。
(5) 检查主备UP切换是否完成。
在CP上执行display up-backup-profile switchover-history命令查看指定UP备份策略模板下的接口切换历史记录：
<CP> display up-backup-profile 1 switchover-history
Reason Interface State Time
IF down Remote-XGE2000/1/3/0 Switchover to backup 2022-06-09 12:24:36
…
¡ 如果刚刚发生过接口切换，则等待一段时间，再次观察CP和UP的用户数据。如果CP和UP仍旧存在大量用户数据不一致，则执行步骤(6)。
¡ 如果近期未发生过接口切换，则执行步骤(6)。
在CP上多次执行display access-user count命令，观察接入用户数：
<CP> display access-user count
Total users : 5
PPPoE users : 0
PPPoEA users : 0
PPPoA users : 0
PPPoFR users : 0
PPPoPhy users : 0
LNS users : 0
LAC users : 0
VPPP users : 0
L2 IPoE dynamic users : 1
L2 IPoE static users : 0
L2 IPoE interface leased users : 0
L2 IPoE subnet leased users : 0
L2 IPoE leased subusers : 0
IPoE L2VPN leased users : 0
L3 IPoE dynamic users : 0
L3 IPoE static users : 0
L3 IPoE interface leased users : 0
L3 IPoE subnet leased users : 0
Web auth users : 0
Portal users : 0
Telnet users : 1
SSH users : 0
HTTP users : 1
HTTPS users : 1
FTP users : 1
Command users : 0
PAD users : 0
Terminal users : 0
MAC auth users : 0
Dot1X users : 0
IKE users : 0
SSLVPN users : 0
DVPN users : 0
¡ 如果Total字段（接入用户数）前后差异较大，则表示当前存在用户上下线，请等用户稳定后再观察CP和UP的用户数据。
¡ 如果Total字段（接入用户数）前后差异较小，则表示用户未频繁上下线，请执行步骤(7)。
(7) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
无
无
在VNFM-vBRAS的镜像管理页面中，上传镜像文件失败。
本类故障的常见原因主要包括：
· 镜像文件不正确，如文件类型或名称错误、重复上传文件等。
· 容器状态异常。
本类故障的诊断流程如图9-18所示。
(1) 检查镜像文件类型和名称。
a. 若镜像文件类型或名称不正确，则根据提示信息进行相应处理。提示信息显示在系统弹出的“注意”提示框中，如图9-19所示。对于镜像文件类型和名称错误导致的上传失败，常见系统提示及处理方法如表9-1所示。处理完成后，重新尝试上传镜像文件，若仍然失败，则执行步骤(2)。
|
提示信息 |
处理方法 |
|
无效的镜像文件类型 |
镜像文件应为iso类型，名称应有“.iso”后缀，若镜像文件类型有误，请联系技术支持重新获取正确的镜像文件 |
|
无效的文件名称 |
修改文件名称后重新上传，系统支持的有效名称需符合以下规则： · 最长128个字符，区分大小写 · 仅支持字母、数字、下划线、小数点和连字符 |
|
指定的镜像文件已存在 |
此提示信息说明已上传过相同名称的镜像文件： · 若已上传的同名镜像文件可用，则无需再次上传 · 若已上传的同名镜像文件不可用，则需删除已上传的同名镜像文件或修改待上传镜像的文件名称 |
b. 若镜像文件类型和名称均正确无误，则执行步骤(2)。
(2) 登录Installer集群主Master节点所在统一数字底盘虚拟机的终端命令行。执行命令kubectl get pod –n vnfm，通过查看回显检查容器状态是否正常。
Installer集群部署成功后，如图9-20所示，左上角绿色星标的为主Master节点，其余未被标记的Master节点为备用Master节点。关于Installer集群部署的详细信息，请参见《H3C vBRAS系列转控分离路由器安装部署指导》。
a. 若灰色STATUS列显示字段为“Running”，说明容器状态正常，则执行步骤(3)。
[root@ucenter1 ~]# kubectl get pod -n vnfm
NAME READY STATUS RESTARTS AGE
vnfm-help-68497c48df-5qp5l 1/1 Running 0 111d
vnfm1-5b69d4865f-b6qqz 1/1 Running 0 111d
vnfm2-8f98fbc4d-ctdmn 1/1 Running 0 111d
vnfm3-c8bf6b777-r72t8 1/1 Running 0 111d
b. 若灰色STATUS列显示字段非“Running”，说明容器状态异常，则尝试重启容器。若重启容器后仍然上传失败，则执行步骤(3)。
(3) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
无
无
在VNFM-vBRAS的VNF包管理页面中，上传VNF包失败。
本类故障的常见原因主要包括：
· VNF包不正确，如VNF包名称或结构错误、重复上传VNF包等。
· VNF包内文件不正确，如yml文件结构错误或字段缺失、yml文件修改数据超出字段合法范围等。
本类故障的诊断流程如图9-21所示。
图9-21 上传VNF包失败的故障诊断流程图
(1) 检查VNF包类型、名称和结构。
a. 若VNF包类型、名称或结构不正确，则根据提示信息进行相应处理。提示信息显示在系统弹出的“注意”提示框中，如图9-22所示。对于VNF包错误导致的上传失败，常见系统提示及处理方法如表9-2所示。处理完成后，重新尝试上传VNF包，若仍然失败，则执行步骤(2)。
图9-22 VNF包检查提示框示例
表9-2 VNF包错误导致上传失败的常见提示信息及处理方法
|
提示信息 |
处理方法 |
|
无效的VNF包类型 |
VNF包应为zip压缩文件，名称应有“.zip”后缀，若VNF包类型有误，请联系技术支持重新获取正确的VNF包 |
|
无效的VNF包名称 |
修改VNF包名称后重新上传，系统支持的有效VNF包名称需符合以下规则： · 最长128个字符，区分大小写 · 仅支持字母、数字、下划线、小数点和连字符 |
|
指定的VNF包已存在 |
说明已上传过相同名称的VNF包： · 若已上传的同名VNF包可用，则无需再次上传 · 若已上传的同名VNF包不可用，则需删除已上传的同名VNF包或修改待上传VNF包名称 |
|
无效的VNF包结构 |
· 检查VNF包，确保其结构完整、层级正确、文件无缺失且各文件名称无误，如有错漏则需重新获取，正确的VNF包解压后应包含：Definitions文件夹（内含nodes.yml、vbras.yml两个文件）、TOSCA-Metadata文件夹（内含TOSCA.meta文件）、csar.meta文件 · 同时选择VNF包所有内容，打包为zip格式压缩文件，打包时需确保直接选中VNF包的所有内容（Definitions文件夹、TOSCA-Metadata文件夹、csar.meta文件）并进行压缩，不能有遗漏，也不能选择上层文件夹 |
b. 若VNF包类型、名称和结构均正确无误，则执行步骤(2)。
(2) 检查VNF包内文件内容和结构是否正确。
a. 若VNF包内文件内容或结构不正确，则根据提示信息进行相应处理。对于VNF包内文件错误导致的上传失败，常见系统提示及处理方法如表9-3所示。处理完成后，重新尝试上传VNF包，若仍然失败，则执行步骤(3)。
表9-3 VNF包内文件错误导致上传失败的常见提示信息及处理方法
|
提示信息 |
处理方法 |
|
Tosca模板解析错误 |
重新获取VNF包文件，解压后使用不会修改文件格式的文本编辑器修改vbras.yml配置文件，确保文件打开后缩进格式显示类似图9-23
VNFM-vBRAS需根据Tosca模板解析VNF包，包内yml文件内容需严格满足特定缩进格式，不能随意更改 |
|
无效的init节点属性 |
检查init节点中各个字段的属性值是否超出合法取值范围，并将其修改正确（例如CTRL-VM的slot编号取值范围为1和2，则ctrlvm_slot_id字段属性值范围不应超出“1-2”） |
|
无效的VM规格 |
检查各VM节点中各个字段的属性值是否超出合法取值范围，并将其修改正确 |
|
无效的网络绑定参数 |
检查各VM节点中“network_binding:”参数下的各个字段是否存在错漏，并将其修改正确 |
图9-23 vbras.yml配置文件结构示例
b. 若VNF包内文件内容和结构均正确无误，则执行步骤(3)。
(3) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
无
无
使用VNFM-vBRAS部署虚拟机失败。
本类故障的常见原因主要包括：
· CloudOS中组织资源配额不足，导致无法组织用户创建虚拟机。
· vbras.yml文件中，SR-IOV直通网卡的logical_nic_name未以“SRIOV”前缀定义，可能的情况包括：
¡ CloudOS经典网络名称不符合规则导致vbras.yml文件内容不正确。
¡ 修改vbras.yml文件时logical_nic_name属性字段填写错误。
· vbras.yml文件中，各虚拟机的storage属性字段属性值过小，导致存储资源不足。
· CloudOS中未正确配置和CAS对接的参数及固化，导致存储池资源剩余空间不足，无法创建虚拟机。
本类故障的诊断流程如图9-24所示。
(1) 在统一数字底盘VNFM-vBRAS组件[系统 -> 日志中心 -> 操作日志信息]页面中，查看部署虚拟机的相关日志信息，如图9-25所示。
a. 若失败原因列显示“Failed to create the VNF on the host”，则登录CloudOS云操作系统，进入[系统 -> 组织管理 -> 配额]页面，单击虚拟配额右侧的<修改>按钮，如图9-26所示。依次单击所有配额文本框右侧的蓝色“max”，将所有配额均设置为最大值。修改完成后，重新尝试部署虚拟机，若仍然失败，则执行步骤(2)。
b. 否则执行步骤(2)。
(2) 在CloudOS云操作系统[云服务 -> 经典网络]页面中，查看经典网络信息。
a. 若对于已配置SR-IOV的直通网卡，其相应的经典网络名称均以“SRIOV”为前缀，则执行步骤(3)。
b. 否则需修改经典网络名称，以确保SR-IOV直通网卡对应的经典网络名称均以“SRIOV”为前缀。例如，内部控制口对应的经典网络名称若为“Inner-Ctrl-DC1”，则需修改为“SRIOV-Inner-Ctrl-DC1”。修改完成后，重新尝试部署虚拟机，若仍然失败，则执行步骤(3)。
(3) 打开部署虚拟机时使用的VNF包中的vbras.yml文件，检查其中logical_nic_name字段属性值。
a. 若各个logical_nic_name字段属性值均与正确的CloudOS经典网络名称对应且一致，则执行步骤(4)。
b. 否则需修改vbras.yml文件，确保各个logical_nic_name字段属性值与CloudOS经典网络名称对应且一致。修改完成后，重新尝试部署虚拟机，若仍然失败，则执行步骤(4)。
(4) 在CAS云计算管理平台中，单击界面右上方的
图标，在弹出的任务台中，查看增加虚拟机失败的原因。
a. 若失败原因为“存储卷转换失败”，则需修改vbras.yml文件，以确保其中storage字段属性值至少为32768。修改完成后，重新尝试部署虚拟机，若仍然失败，则执行步骤(5)。
b. 若失败原因为“存储池资源剩余空间不足”，则需在CloudOS云操作系统中重新进行固化配置，具体固化配置步骤请参见《H3C vBRAS1000-CP安装部署指导》。固化配置完成后，请确认计算节点容器中/etc/nova/nova-compute.conf文件中是否存在useLocalStorage = True参数。若有该参数，重新尝试部署虚拟机，若仍然失败且无useLocalStorage = True参数，则执行步骤(5)。
c. 否则执行步骤(5)。
(5) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
无
无
虚拟机手动扩容、自动扩容和初始部署时，任意服务器主机上的VM创建或启动失败。
本类故障的常见原因包括：
· 服务器主机存储池的容量不足。
· 服务器主机剩余内存不满足要求。
· 服务器主机CPU个数不满足要求。
本类故障的诊断流程如图9-27所示。
(1) 检查虚拟机部署是否正常。
登录CAS云计算管理平台，在服务器主机管理页面的“云资源”页签查看虚拟机是否存在且处于“绿色”正常启动状态。
CAS云计算管理平台的登录方式与版本有关。以E0710P09版本为例，可通过在浏览器地址栏输入“http://IP地址:8080/cas”访问登录页面，其中“IP地址”为CVM双机热备虚IP。
(2) 如果虚拟机创建或启动失败，请参考“H3C CAS云计算管理平台维护手册”中的“一键巡检”处理。如果未解决，请继续执行以下操作。
(3) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
无
无
vBRAS-CP中部分VM无法正常启动。
本类故障的常见原因主要包括：
· 故障VM的软件版本和当前vBRAS-CP正在使用的软件版本不一致。
· 故障VM的软件版本文件有损坏。
· 故障VM在初始部署基础上进行过软件版本升级。
本类故障的诊断流程如图9-29所示：
图9-29 vBRAS-CP中部分VM无法正常启动故障诊断流程图
(1) 检查vBRAS-CP和VNFM-vBRAS之间连接是否正常。
在CTRL-VM上任意视图下执行display vbras-cp stable state vnfm命令查看CP设备和VNFM-vBRAS直接连接是否正常。
¡ 如果vBRAS-CP和VNFM-vBRAS之间连接正常，请继续步骤(2)。
¡ 如果vBRAS-CP和VNFM-vBRAS之间连接断开，请继续步骤(3)。
(2) 登录VNFM-vBRAS页面，重建故障VM。
a. 在本地PC浏览器地址栏中输入“http://IP地址:30000/uclogin/view/login.html”，按<Enter>键打开统一数字底盘登录页面。其中，“IP地址”为集群北向业务虚IP，30000为缺省端口号。
b. 输入统一数字底盘的用户名和密码，单击<登录>按钮，进入统一数字底盘主页面。
· 统一数字底盘页面的出厂默认账号密码与版本有关，本文以E0611版本为例。
· E0611版本出厂默认用户名为admin，密码为Pwd@12345。
· 将出厂默认账号密码修改为自定义后，请以自定义账号密码登录。
c. 在统一数字底盘页面上方的导航栏中，单击[vBRAS管理]菜单项，进入vBRAS管理页面，单击[部署管理->vBRAS资源]，选中故障VM，在故障VM对应操作列中，单击
重建图标，在弹出的“确认”提示框中，单击<确定>按钮，VM虚拟机将会重建，如图9-30所示。VNFM-vBRAS会先将原有虚拟机删除后，再进行重建，加载版本为原始部署的版本。
如果vBRAS-CP在此之前升级过版本，重建的VM将会是原始部署的版本，请注意将重建的VM升级至当前vBRAS-CP的软件版本。升级vBRAS-CP软件版本的步骤，请参见安装部署指导。
d. 重建完成后，请查看虚拟机能否正常启动，若仍然失败，则执行步骤(3)。
(3) 进入故障虚拟机的BOOTWARE页面。
vBRAS-CP故障虚拟机在进入BOOTWARE时需要键入CTRL+B，而有时可能会因为在CAS云计算管理平台的Web页面键入CTRL+B无响应，针对此问题，用以下两种情况分别说明进入BOOTWARE的方法。
情况一：如果CAS云计算管理平台的Web页面无法响应按键，则按如下方式处理：
a. 使用Mobaxterm软件登录到vBRAS-CP故障虚拟机所在服务器的后台。
b. 执行virsh命令进入virsh命令行操作界面，使用list命令查看需要进入BOOTWARE的虚拟机名称：
[root@CVK3594 ~]# virsh
Welcome to virsh, the virtualization interactive terminal.
Type: 'help' for help with commands
'quit' to quit
virsh # list
Id Name State
----------------------------------------------------
1 vUP1_1-82 running
2 CP1_BRAS-VM_97-140 running
3 CP1_CTRL-VM_1-138 running
4 CP1_FWD-VM_5-142 running
virsh #
c. 记住故障虚拟机名称，在CAS云计算管理平台的Web页面选中故障虚拟机，单击[关闭电源]，再单击[启动]，然后立即返回到SSH控制台输入命令：send-key --domain DOMAINNAME KEY_LEFTCTRL KEY_B（可提前编辑命令后进行粘贴，DOMAINNAME为故障虚拟机名称），多次输入该命令，就可能进入该故障虚拟机的BOOTWARE界面，如图9-31所示。若成功进入BOOTWARE界面，请继续执行步骤(4)。
virsh # send-key --domain CP1_FWD-VM_5-142 KEY_LEFTCTRL KEY_B
^[[A
^[[A
virsh # send-key --domain CP1_FWD-VM_5-142 KEY_LEFTCTRL KEY_B
virsh # send-key --domain CP1_FWD-VM_5-142 KEY_LEFTCTRL KEY_B
virsh # send-key --domain CP1_FWD-VM_5-142 KEY_LEFTCTRL KEY_B
d. 若进入BOOTWARE界面失败，则重复步骤c，若仍然失败请执行步骤(7)。
情况二：如果CAS云计算管理平台的Web页面可以响应按键，则按如下方式处理：
a. 登录CAS云计算管理平台。在CAS云计算管理平台页面左侧的导航树中，单击[云资源 ->主机池名称 ->集群名称]菜单项，进入待配置集群的概要信息页面，选择故障虚拟机。
CAS云计算管理平台的登录方式与版本有关。以E0710P09版本为例，可通过在浏览器地址栏输入“http://IP地址:8080/cas”访问登录页面，其中“IP地址”为CVM双机热备虚IP。
b. 进入虚拟机概要界面，选择“控制台”页签，找到远端控制台选项，单击[网页]，进入虚拟机的Web页面。单击[发送按键->Ctrl+Alt+Del]键，故障虚拟机将会重启，如图9-32所示。
c. 在本地键盘上快速不停的键入CTRL+B，则可进入该故障虚拟机的BOOTWARE页面。若成功进入BOOTWARE界面，请继续执行步骤(4)。
d. 如未进入请按上述步骤再次尝试，若仍然失败请执行步骤(7)。
(4) 在BOOTWARE界面中，根据脚本回显提示，先输入数字2进入文件控制菜单，再输入数字1查看所有文件，查看故障虚拟机上是否存在其他可用的版本文件。
¡ 如果有其他可用的软件版本，请继续步骤(5)。
¡ 如果没有其他可用的软件版本，请继续步骤(6)。
a. 如图9-33所示，在BOOTWARE界面中，根据脚本回显提示，先输入数字2进入文件控制菜单，再输入数字3设置Bin文件类型并进入选择版本文件界面。
b. 依次按照对应的文件序号选择同一版本的boot、system和devkit版本文件，选择完成后键入0退出，在键入1，如图9-34所示。
c. 完成版本文件选择后，根据脚本回显提示，先输入数字0退出file control界面，然后输入数字0重启故障虚拟机。
d. 重启完成后，请查看虚拟机能否正常启动，若仍然失败，则执行步骤(6)。
(6) 在CAS云计算管理平台中，为故障虚拟机上传可用的软件版本。
CAS云计算管理平台上无法在BOOTWARE中通过FTP/TFTP上传版本文件。
a. 在CAS云计算管理平台的Web页面，选择故障虚拟机，单击[修改虚拟机]，在弹出的窗口中，单击[磁盘]，复制源路径，如图9-35所示。
b. 在CAS云计算管理平台页面关闭故障虚拟机的电源。
c. SSH登录故障虚拟机所在CVK后台，将正常使用的版本文件传到CVK的/root/目录下：
[root@CVK3597 ~]# ll
total 94672
-rw------- 1 root root 7302 Jun 22 14:50 anaconda-ks.cfg
-rw------- 1 root root 6851 Jun 22 14:50 original-ks.cfg
-rw-r--r-- 1 root root 8351744 Aug 31 13:50 vBRAS1000-CP-FWD-CMW710-BOOT-E2022-X64.bin
-rw-r--r-- 1 root root 88573952 Aug 31 13:50 vBRAS1000-CP-FWD-CMW710-SYSTEM-E2022-X64.bin
[root@CVK3597 ~]#
d. 进入磁盘源路径中，找到与CAS云计算管理平台页面查询到与源路径一致的磁盘文件，guestfish -a编辑此文件，并将版本文件copy-in到镜像中，具体如下：
[root@CVK3597 ~]# cd /vms/isos/
[root@CVK3597 isos]# ll
total 5478900
-rw-r--r-- 1 root root 123797504 Jun 25 13:53 078d6414-96f9-42d8-b79b-8fd63b45f868
-rw-r--r-- 1 root root 123863040 Jun 30 10:42 2f78cb8f-a601-45c4-bd06-eac85479d2ec
-rw-r--r-- 1 root root 121110528 Jul 29 13:47 4c6f0a6a-ebdb-4a3b-9d11-f114c4ced2d8
-rw-r--r-- 1 root root 123863040 Jun 28 11:19 72aaad31-2dfe-406b-be54-31aba377c2a9
-rw-r--r-- 1 root root 1320943616 Aug 31 11:31 7791f71f-16a8-4582-b140-7d4f17852279
-rw-r--r-- 1 root root 3013672960 Aug 31 11:28 7af588d6-61fb-4a5b-beea-f80e3bed15bc
[root@CVK3597 isos]# guestfish -a 7791f71f-16a8-4582-b140-7d4f17852279
Welcome to guestfish, the guest filesystem shell for
editing virtual machine filesystems and disk images.
Type: 'help' for help on commands
'man' to read the manual
'quit' to quit the shell
><fs>run //必须先运行一下run命令，否则其他命令无法运行。
100% ⟦▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒⟧ 00:00
><fs> mount /dev/sda3 / //将此描述挂载到/目录。
><fs> copy-in /root/vBRAS1000-CP-FWD-CMW710-BOOT-E2022-X64.bin / //分别将版本文件拷copy-in到镜像中。
><fs> copy-in /root/vBRAS1000-CP-FWD-CMW710-SYSTEM-E2022-X64.bin /
><fs> umount /dev/sda3 //完成后取消挂载，此时描述位置得文件被修改成功。
><fs> quit
e. 在CAS云计算管理平台页面中给故障虚拟机上电，进入故障虚拟机的BOOTWARE，选择刚上传的版本文件作为启动文件，具体操作请参见步骤(3)、(5)。
27 -rw- 133372 Jan 01 2000 07:55:04 startup.mdb
28 drw- - Jan 01 2000 07:47:54 tracefile
29 -rw- 8200192 Jan 25 2000 02:15:32 vBRAS1000-UP-CMW710-BOOT-E3021-X64.
bin
30 -rw- 8201216 Oct 05 2000 10:45:40 vBRAS1000-UP-CMW710-BOOT-E3021P05-X
64.bin
31 -rw- 8317952 Jan 02 2001 10:34:14 vBRAS1000-UP-CMW710-BOOT-E3022-X64.
bin
32 -rw- 9467904 Jan 25 2000 02:16:10 vBRAS1000-UP-CMW710-DEVKIT-E3021-X6
4.bin
33 -rw- 9467904 Oct 05 2000 10:45:40 vBRAS1000-UP-CMW710-DEVKIT-E3021P05
-X64.bin
34 -rw- 9596928 Jan 02 2001 10:34:14 vBRAS1000-UP-CMW710-DEVKIT-E3022-X6
4.bin
35 -rw- 22734848 Sep 08 2021 17:34:52 vBRAS1000-UP-CMW710-PACKET-CAPTURE-
E3022-X64.bin
36 -rw- 88110080 Jan 25 2000 02:16:06 vBRAS1000-UP-CMW710-SYSTEM-E3021-X6
4.bin
37 -rw- 88312832 Oct 05 2000 10:45:40 vBRAS1000-UP-CMW710-SYSTEM-E3021P05
-X64.bin
38 -rw- 97087488 Jan 02 2001 10:34:14 vBRAS1000-UP-CMW710-SYSTEM-E3022-X6
4.bin
39 -rw- 119580 Jan 05 2001 07:10:10 version.log
32476656 KB total (32078432 KB free)
f. 重新加载版本文件并重启完成后，请查看虚拟机能否正常启动，若仍然失败，则执行步骤(7)。
(7) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
· vBRAS1000-CP VM注册失败：BRAS-VM和FWD-VM未向当前主用CTRL-VM注册，当前主用CTRL-VM无法管理这些BRAS-VM和FWD-VM。在CTRL-VM上执行display vm命令，VM的Registration字段值为Unregistered，表示该VM注册失败。
<CTRL-VM>display vm
Abbreviation: R-Role M-Master S-Standby MD-MAD down DING-DESTROYING
Slot VM name Type State(R) Registration
1 CP1_CTRL_VM_1 CTRL-VM Normal(M) --
2 CP1_CTRL_VM_2 CTRL-VM Absent(-) --
5 CP1_FWD_VM_5 FWD-VM Normal(-) Registered
6 CP1_FWD_VM_6 FWD-VM Absent(-) Unregistered
97 CP1_BRAS_VM_97 BRAS-VM Normal(M) Registered
98 CP1_BRAS_VM_98 BRAS-VM Absent(-) Unregistered
· vBRAS1000-vUP VM注册失败：LPU-VM未向当前主用MPU-VM注册，当前主用MPU-VM无法管理这些LPU-VM。在MPU-VM上执行display vm命令，VM的Registration字段值为Unregistered，表示该VM注册失败。
<MPU-VM>display vm
Abbreviation: R-Role M-Master S-Standby I-IO MD-MAD down DING-DESTROYING
Slot VM name Type State(R) Registration
1 UP1_MPU_VM_1 MPU-VM Normal(M) --
2 UP1_MPU_VM_2 MPU-VM Absent(-) --
5 UP1_LPU_VM_5 LPU-VM Normal(I) Registered
6 UP1_LPU_VM_6 LPU-VM Absent(-) Unregistered
· 本文以vBRAS1000-CP VM注册失败为例，介绍故障常见原因、故障分析和处理步骤。
· 若非特殊强调，下文描述中的VM均指未注册的BRAS-VM和FWD-VM。
· CTRL-VM之间通过LIPC（Leopard Inter-process Communication，Leopard版本进程间通信）机制交互信息。因此，备用CTRL-VM无需向主用CTRL-VM注册，不存在备用CTRL-VM注册故障的问题
本类故障的常见原因主要包括：
· VM创建失败。
· VM未上电。
· VM正在启动（未完成启动）。
· VM和CTRL-VM之间的控制链路通信异常。
· VM和CTRL-VM之间的NETCONF通道连接异常。
· VM和CTRL-VM之间的SSH连接异常。
· 在CloudOS中添加计算节点时，未将虚拟机初始化模式设置为专业模式。
本类故障的诊断流程如图9-36所示。
图9-36 VM注册失败故障诊断流程图
(1) 检查VM是否部署成功。
(2) 在CTRL-VM上执行display vm命令：
¡ 如果显示信息中VM的State(R)字段的值为Normal，则表示该VM部署成功。
¡ 如果显示信息中VM的State(R)字段的值为Absent，则表示该VM可能未部署或者部署失败，请参见“9.6.3 虚拟机部署失败”和“9.6.4 资源不足导致VM创建或启动失败”进行处理。
(3) 如果虚拟机部署成功后仍无法注册，请执行步骤(2)。
<Sysname> display vm
Abbreviation: R-Role M-Master S-Standby MD-MAD down DING-DESTROYING
Slot VM name Type State(R) Registration
1 CP1_CTRL_VM_1 CTRL-VM Normal(M) --
2 CP1_CTRL_VM_2 CTRL-VM Absent(-) --
5 CP1_FWD_VM_5 FWD-VM Normal(-) Registered
6 CP1_FWD_VM_6 FWD-VM Absent(-) Unregistered
97 CP1_BRAS_VM_97 BRAS-VM Normal(M) Registered
98 CP1_BRAS_VM_98 BRAS-VM Absent(-) Unregistered
(4) 确认VM是否上电。
登录CAS云计算管理平台，如图9-37所示，在CAS云计算管理平台左侧导航树中，展开“云资源”菜单项查看VM是否上电。
CAS云计算管理平台的登录方式与版本有关。以E0710P09版本为例，可通过在浏览器地址栏输入“http://IP地址:8080/cas”访问登录页面，其中“IP地址”为CVM双机热备虚IP。
¡ 如果VM对应图标为绿色，则表示该VM处于正常上电状态。
¡ 如果VM对应图标为红色，则表示该VM处于未上电状态，请通过CAS页面进行上电。
如果VM正常上电后仍无法注册，请执行步骤(3)。
图9-37 CAS云资源页面局部图
(5) 检查VM是否正在启动。
单击CAS云计算管理平台右上方的
图标，在弹出的任务台中，可以查看VM是否处于启动过程中。VM从上电到完成注册一般需要1～5分钟，这段时间叫做启动时间。如果VM启动过程没有超过VM启动时间，请耐心等待。
如果VM启动完毕后，VM仍无法注册，请执行步骤(4)。
(6) 检查VM光驱数量是否为2。
在CAS云计算管理平台中，通过VM对应虚拟机的“概要”页签可以查看该VM的硬件信息，正常情况下光驱数量应为2：
¡ 如图9-38所示，若光驱数量为2，则表示VM光驱正常。
¡ 如图9-39所示，若光驱数量非2，则表示VM光驱故障。
请先删除故障VM，然后通过CloudOS云操作系统，进入[资源 -> 虚拟化 -> 计算节点]页面。
单击故障VM所在集群对应计算节点右侧的<编辑>按钮，进入“编辑计算节点”页面，如图9-40所示。
单击<刷新>按钮，将“云主机初始化模式”修改为“专业模式”，单击<确认>完成修改后，尝试重新部署VM。
如果VM光驱数量为2且虚拟机初始化模式正确，但VM仍然无法注册，则执行步骤(5)。
(7) 检查未注册的BRAS-VM/FWD-VM和CTRL-VM之间的通信是否正常。
VM使用控制通道进行注册。在CTRL-VM的任意视图下，执行命令ping -vpn-instance vpn-instance-name host，查看能否Ping通VM控制通道接口的IP地址。
¡ 如果能Ping通，表示VM与CTRL-VM通信正常，请执行步骤(5)。
¡ 如果Ping失败，表示VM与CTRL-VM通信异常。请在技术支持人员的协助下，排除VM与CTRL-VM之间控制通道的链路故障。
以上ping命令中，vpn-instance-name参数的取值固定为__vm_private_ctrl_vpn，host参数为未注册FWD-VM和BRAS-VM控制通道的IP地址。请在CTRL-VM的用户视图执行more ovf-env-startup.xml命令，通过control-network-segment字段查看VM控制通道IP地址所在网段。然后根据如下地址分配规则，获得FWD-VM和BRAS-VM控制通道的IP地址：
¡ slot编号为5的FWD-VM的控制通道的IP地址为X.X.X.2。
¡ slot编号为6的FWD-VM的控制通道的IP地址为X.X.X.3。
¡ BRAS-VM的控制通道的IP地址为X.X.X.group-id，group-id为BRAS-VM所在的组号，两个BRAS-VM为一组，组号从66开始编号。例如，slot编号为97和98的BRAS-VM的控制通道的IP地址为X.X.X.66，slot编号为99和100的BRAS-VM的控制通道的IP地址为X.X.X.67，以此类推。
<CTRL-VM> more ovf-env-startup.xml
<?xml version="1.0" encoding="UTF-8"?>
<Environment
其它显示信息略……
<Property oe:key="CU-MAC" oe:value="stackmemberid:1;domain:1;datamac:0cda411df706;controlmac:0cda411d7a06;vm-name:ctrl-vm-1;control-tunnel-vlan:11;control-network-segment:192.168.1.1/16;data-tunnel-vlan:22;data-network-segment:192.158.1.1/16;"/>
</PropertySection>
</Environment>
(8) 检查未注册的BRAS-VM/FWD-VM和CTRL-VM之间的NETCONF通道会话连接是否正常。
# 在CAS上通过打开VM的远程控制台登录VM，在该VM的任意视图下执行display netconf session命令查看已创建的NETCONF会话的信息。
# 在BRAS-VM（Slot编号为97）上查看NETCONF会话信息。
[Sysname-vm-net-slot97] display netconf session
Session ID: 1 Session type : Agent
Username : __private_admin_user__
Login time : 2021-09-07T11:25:53
Client IP address : 192.168.0.1
Session statistics:
Received RPCs : 10 Received bad RPCs : 0
Output RPC errors: 1 Output notifications: 0
Session ID: 2 Session type : Agent
Username : __private_admin_user__
Login time : 2021-09-07T11:25:53
Client IP address : 192.168.0.1
Session statistics:
Received RPCs : 6 Received bad RPCs : 0
Output RPC errors: 0 Output notifications: 0
Session ID: 3 Session type : Agent
Username : __private_admin_user__
Login time : 2021-09-07T11:25:53
Client IP address : 192.168.0.1
Session statistics:
Received RPCs : 8 Received bad RPCs : 0
Output RPC errors: 0 Output notifications: 0
¡ 如果显示信息中包含三个Agent类型的NETCONF会话，且Username字段值均为__private_admin_user__，Client IP address字段值为CTRL-VM控制通道的IP地址，则表示NETCONF通道会话连接正常，请执行步骤(6)。否则，表示NETCONF通道会话连接异常。
¡ 如果NETCONF通道会话连接异常，请通过以下步骤查看是否开启NETCONF over SSH服务器功能。
# 在CAS上通过打开VM的远程控制台登录VM，在该VM的任意视图下执行命令display netconf service，查看NETCONF over SSH服务开启状态。
[Sysname-vm-net-slot97] display netconf service
NETCONF over SOAP over HTTP: Disabled (port 80)
NETCONF over SOAP over HTTPS: Disabled (port 832)
NETCONF over SSH: Enabled (port 830)
NETCONF over Telnet: Enabled
NETCONF over Console: Enabled
SOAP timeout: 10 minutes Agent timeout: 0 minutes
Active Sessions: 3
Service statistics:
NETCONF start time: 2021-09-07T09:37:07
Output notifications: 6
Output RPC errors: 2
Dropped sessions: 3
Sessions: 6
Received bad hellos: 0
Received RPCs: 72
Received bad RPCs: 0
- 如果显示信息中NETCONF over SSH字段的取值为Enabled，则表示功能已开启，请执行步骤(6)。
- 如果NETCONF over SSH的状态为Disabled，请参照以下步骤开启NETCONF over SSH功能。
[Sysname-vm-net-slot97] netconf ssh server enable
(9) 检查注册失败的BRAS-VM/FWD-VM和CTRL-VM之间的SSH会话连接是否正常。
# 在CAS上通过打开VM的远程控制台登录VM，在该VM的任意视图下执行display ssh server session命令查看已创建的SSH会话的信息。
[Sysname-vm-net-slot97] display ssh server session
UserPid SessID Ver Encrypt State Retries Serv Username
801 0 2.0 aes128-ctr Established 0 NETCONF __private_admin_user__
802 0 2.0 aes128-ctr Established 0 NETCONF __private_admin_user__
803 0 2.0 aes128-ctr Established 0 NETCONF __private_admin_user__
3363 0 2.0 aes128-ctr Established 0 Stelnet __private_admin_user__
¡ 如果显示信息中包含三个NETCONF服务会话，其中Username取值均为__private_admin_user__，Serv取值均为NETCONF，则表示SSH会话连接正常，请执行步骤(7)。否则，表示SSH会话连接异常。
¡ 如果SSH会话连接异常，可参照以下步骤解决SSH会话连接异常问题。
¡ # 在VM上执行display ssh server status命令，检查是否因为未开启Stelnet服务器功能，导致SSH会话连接异常。
[Sysname-vm-net-slot97] display ssh server status
Stelnet server: Enable
SSH version : 2.0
SSH authentication-timeout : 60 second(s)
SSH server key generating interval : 0 hour(s)
SSH authentication retries : 3 time(s)
SFTP server: Enable
SFTP Server Idle-Timeout: 10 minute(s)
NETCONF server: Enable
SCP server: Disable
- 如果Stelnet server字段取值为Enable，表示Stelnet服务器功能已开启。
- 如果Stelnet server字段取值为Disable，表示Stelnet服务器功能未开启，请执行以下操作开启Stelnet服务器功能。
[Sysname-vm-net-slot97] ssh server enable
# 检查是否因为公钥不一致，导致SSH会话连接异常。CTRL-VM上的本地vmmgrpublickey必须和BRAS-VM/FWD-VM上保存的对端vmmgrpublickeyCP公钥一致，否则，会导致SSH会话连接异常。
在CTRL-VM上查看公钥vmmgrpublickey的信息。
<Sysname> display public-key local rsa public name vmmgrpublickey
=============================================
Key name: vmmgrpublickey
Key type: RSA
Key length: 1024
Time when key pair created: 11:10:54 2021/09/22
Key code:
30819F300D06092A864886F70D010101050003818D0030818902818100AB0FF5506AD71A75
A775479827EB14B5584CB4E59BC154FC2C80F708A2241F2E7801C6B8863B31BD85B6F64622
1996E5FD8A04EB4ABEAC7A6A26FB2AC8CC38C1DB88DC9C3A6347765485C28190D9E7DD386C
F00AEB30D3D06D437BE1328B9E6914103726E0D9CEEB203AD2B237732225526B858C89BBF7
B195EDDDB2103E5F130203010001
在BRAS-VM或FWD-VM上查看对端公钥vmmgrpublickey的信息。
<Sysname-vm-net-slot97> display public-key peer name vmmgrpublickey
=============================================
Key name: vmmgrpublickey
Key type: RSA
Key length: 1024
Time when key pair created: 11:10:54 2021/09/22
Key code:
30819F300D06092A864886F70D010101050003818D0030818902818100AB0FF5506AD71A75
A775479827EB14B5584CB4E59BC154FC2C80F708A2241F2E7801C6B8863B31BD85B6F64622
1996E5FD8A04EB4ABEAC7A6A26FB2AC8CC38C1DB88DC9C3A6347765485C28190D9E7DD386C
F00AEB30D3D06D437BE1328B9E6914103726E0D9CEEB203AD2B237732225526B858C89BBF7
B195EDDDB2103E5F130203010001
- 如果CTRL-VM上的公钥与VM上保存的公钥的Key code不一致，请重启该VM。VM重启后，会自动同步CTRL-VM上的公钥，并重新注册。
- 如果公钥一致，请执行步骤(7)。
(10) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
模块名：HH3C-VNF-DEVICE-MIB
· hh3cVmUnregisterLongtime (1.3.6.1.4.1.25506.2.196.3.0.11)
无
· “BRAS-VM无法申请和释放网段”中的“网段”包括IP地址网段、IPv6地址网段和前缀段。
· “BRAS-VM无法申请和释放网段”主要针对L2TP、NAT-CENTRAL和ODAP三种类型的地址池。
· 本文主要排查CP内部CTRL-VM和BRAS-VM间的故障问题。由于CP与UP设备的连接异常导致CP无法接收DHCP地址申请（Request）和释放（Release）请求报文的故障处理步骤，请查看“CP-UP连接管理类故障处理手册”。
BRAS-VM无法申请和释放网段，主要表现在：
· BRAS-VM无法从CTRL-VM申请网段。执行如下显示命令指定相关BRAS-VM时，无已分配的网段信息：
¡ display dhcp dynamic-alloc address
¡ display ipv6 dhcp dynamic address
¡ display ipv6 dhcp dynamic prefix
· 在CTRL-VM上执行reset dhcp { l2tp | nat-central | odap } subnet/reset ipv6 dhcp odap subnet命令或用户主动释放网段资源后，执行如下显示命令时，释放的上述网段信息依然存在：
¡ display dhcp dynamic-alloc address
¡ display ipv6 dhcp dynamic address
¡ display ipv6 dhcp dynamic prefix
本类故障的常见原因主要包括：
· BRAS-VM未向CTRL-VM注册。
· CTRL-VM与BRAS-VM之间的DHCP进程连接异常。
· CTRL-VM上的网段资源耗尽。
本类故障的诊断流程如图9-41所示。
图9-41 BRAS-VM无法申请和释放网段故障诊断流程图
(1) 检查BRAS-VM是否已经向CTRL-VM成功注册。
(2) 当BRAS-VM未向CTRL-VM注册时，则表示CTRL-VM无法管理该BRAS-VM。
(3) 在CTRL-VM上执行display vm命令，查看BRAS-VM的注册情况。
<Sysname> display vm
Abbreviation: R-Role M-Master S-Standby MD-MAD down DING-DESTROYING
Slot VM name Type State(R) Registration
1 CP1_CTRL_VM_1 CTRL-VM Normal(M) --
2 CP1_CTRL_VM_2 CTRL-VM Normal(S) --
5 CP1_FWD_VM_5 FWD-VM Normal(-) Registered
6 CP1_FWD_VM_6 FWD-VM Normal(-) Registered
97 CP1_BRAS_VM_97 BRAS-VM Normal(M) Registered
98 CP1_BRAS_VM_98 BRAS-VM Normal(S) Registered
a. 如果Registration字段显示为Registered，则表示该BRAS-VM已注册。
b. 如果Registration字段显示为Unregistered，则表示该BRAS-VM未向CTRL-VM注册。BRAS-VM未成功注册的原因及故障处理步骤请查看“VM管理类故障处理手册”。
(4) 检查CTRL-VM与BRAS-VM之间的DHCP进程连接是否正常。
BRAS-VM上网段的申请和释放是通过CTRL-VM与BRAS-VM间DHCP进程的内部协议报文交互完成，DHCP进程连接故障则内部协议报文无法正常交互。
在CTRL-VM的Probe视图下执行display system internal dhcp server bras-connection命令或者display system internal ipv6 dhcp server bras-connection命令查看CTRL-VM与BRAS-VM间DHCP进程连接状态。
[Sysname-probe] display system internal dhcp server bras-connection
IP address Connected at
192.159.0.66 Jun 22 05:45:49 2022
[Sysname-probe] display system internal ipv6 dhcp server bras-connection
IP address Connected at
192.159.0.66 Jun 22 05:45:49 2022
a. 如果IP address和Connected at字段下显示出指定BRAS-VM的连接信息，则表示CTRL-VM与BRAS-VM之间的DHCP进程连接正常。
b. 如果IP address和Connected at字段下没有显示指定BRAS-VM的连接信息，则表示CTRL-VM与该BRAS-VM之间的DHCP进程连接异常。若已排除其它连接故障问题，请联系技术支持人员重启DHCP进程，恢复DHCP进程连接。
(5) 检查CTRL-VM上的网段资源是否耗尽。
在地址池视图下执行exhaustion log enable命令开启地址池资源耗尽或恢复日志告警功能后，当CTRL-VM上打印“DHCPS/4/DHCPS_NET_EXHAUST”、“DHCPS6_IP_NET_EXHAUST”或“DHCPS6_PD_NET_EXHAUST”时，则表示CTRL-VM上该地址池的网段资源已耗尽，此时需要管理员重新规划地址池资源。
请勿随意删除已有地址池重新规划，否则将导致已分配网段被回收，获得相关网段地址的客户端用户被迫下线。可以通过增加地址池或在原有地址池内增加从网段来扩充网段资源。
(6) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
¡ 执行debugging dhcp server、debugging ipv6 dhcp server命令收集的调试信息。
无
· DHCPS/4/DHCPS_NET_EXHAUST
· DHCPS6_IP_NET_EXHAUST
· DHCPS6_PD_NET_EXHAUST
vBRAS的转发平面用于实现二三层转发，控制平面主要用于实现转发的控制。相对应的，vBRAS的CPU也分为转发核和控制核。因为网络中一直有大量报文需要转发，所以，转发核可能一直处于占用率高的状态，这是正常现象。而控制核控制设备的运行以及指导转发，CPU控制核占用率过高会影响系统处理能力，进而引发业务异常。所以，我们需要关注CPU控制核占用率。本文仅描述CPU控制核占用率高的问题。
当出现以下情况时，说明设备的CPU控制核占用率高，需要确认CPU占用率高的具体原因。
· 对设备进行每日巡检时，连续使用display cpu-usage命令查看CPU的占用率，CPU占用率持续在80％以上。
# 执行display cpu-usage summary命令显示最近5秒、1分钟、5分钟内CPU占用率的平均值。
<CTRL-VM> display cpu-usage summary
Slot CPU Last 5 sec Last 1 min Last 5 min
1 0 85% 81% 16%
5 0 0% 0% 0%
97 0 0% 0% 0%
# 执行display cpu-usage history命令以图表的方式显示最近60个采样点的CPU占用率，观察CPU占用率是否持续在80％以上。显示信息中：
¡ 纵坐标表示CPU占用率，采用就近显示的原则。比如，占用率的间隔为5％，则实际统计值53％将被显示成55％，实际统计值52％将被显示成50％。
¡ 横坐标表示时间，时间越靠左表示距离当前时间越近。
¡ 用连续的#号表示该时刻的占用率，某个时间点上最高处的#号对应的纵坐标值即为该采样点计算的CPU占用率。采样间隔可通过monitor cpu-usage interval命令配置（缺省为1分钟）。
<Sysname> display cpu-usage history
100%|
95%|
90%|
85%|
80%|#
75%|#
70%|#
65%|#
60%|#
55%|#
50%|#
45%|#
40%|#
35%|#
30%|#
25%|#
20%|#
15%|# #
10%|# ### #
5%|# ########
------------------------------------------------------------
10 20 30 40 50 60 (minutes)
cpu-usage (Slot 1 CPU 0) last 60 minutes (SYSTEM)
其它CPU的显示信息略……
以Slot 1 CPU 0为例：以上显示信息表明系统（用“SYSTEM”表示）在最近60分钟内CPU的占用率情况：1分钟前大约为80％，12分钟前大约为5％，13分钟前大约为10％，14分钟前大约为15％，15分钟前大约为10％，16、17分钟前大约为5％，18分钟前大约为10％，19分钟前大约为5％，其它时间均小于或等于2％。
· 通过Telnet/SSH等方式登录设备，并执行命令行时，设备反应缓慢，出现卡顿现象。
· 设备上打印CPU占用率高的相关日志。
· SNMP网管上出现CPU占用率高的相关告警。
本类故障的常见原因主要包括：
· 网络攻击。
· 协议震荡，通常为路由协议震荡。
· 设备配置了流采样功能，流量太大或者采样频率太高，导致采样功能占用大量CPU资源。
· 设备产生海量日志，设备生成和管理这些日志需要占用大量CPU资源。
本类故障的诊断流程如图9-42所示。
图9-42 VM控制核CPU占用率高的故障诊断流程图
(1) 确认设备是否受到网络攻击。
现网中，导致设备CPU占用率高最常见的原因是网络攻击。攻击者发起大量非正常网络交互对设备产生冲击，例如短时间内发送大量TCP连接建立请求报文或者ICMP请求报文，设备忙于处理这些攻击报文，导致CPU占用率高，从而影响设备正常业务的运行。
执行display system internal control-plane statistics命令，查看控制平面报文的统计信息，关注丢弃报文的数量。如果当前CPU占用率高，且Dropped字段取值较大时，则设备大概率受到了报文攻击。
<CTRL-VM-vm-net> display system internal control-plane statistics slot 1
Control plane slot 1
Protocol: Default
Bandwidth: 15360 (pps)
Forwarded: 108926 (Packets), 29780155 (Bytes)
Dropped : 0 (Packets), 0 (Bytes)
Protocol: ARP
Bandwidth: 512 (pps)
Forwarded: 1489284 (Packets), 55318920 (Bytes)
Dropped : 0 (Packets), 0 (Bytes)
Protocol: HTTP
Bandwidth: 1024 (pps)
Forwarded: 0 (Packets), 0 (Bytes)
Dropped : 0 (Packets), 0 (Bytes)
Protocol: HTTPS
Bandwidth: 1024 (pps)
Forwarded: 0 (Packets), 0 (Bytes)
Dropped : 0 (Packets), 0 (Bytes)
Protocol: NTP
Bandwidth: 1024 (pps)
Forwarded: 0 (Packets), 0 (Bytes)
Dropped : 0 (Packets), 0 (Bytes)
其它显示信息略……
¡ 如果受到了网络攻击，则先解决网络攻击问题。
¡ 如果未受到网络攻击，则执行步骤(2)。
(2) 确认VM接入网络是否存在广播、组播、未知单播报文风暴。
当VM的接入交换机链路存在环路时，可能会将大量的广播、组播、未知单播报文发送给vCP。vCP将这些报文上送CPU处理，可能会导致CPU占用率升高。可通过以下步骤来确认设备是否存在广播、组播、未知单播报文风暴。
a. 清除接口的统计信息。
<CTRL-VM> reset counters interface
b. 从缺省配置环境切换到VM网络配置环境，并进入VM网络配置环境的用户视图。多次执行display counters rate inbound interface命令查看端口使用率是否明显增大。（VM网络配置环境才能查询内部接口MGE和VMC类型接口的统计信息）
<CTRL-VM> system-view
[CTRL-VM] switchto vm-net-setup
Enter password:
As a best practice, use the default VM network setup. Changes in the VM network
setup environment might cause the CP to malfunction. If you need to change a set
ting, make sure you understand its impact on the services.
<CTRL-VM-vm-net> display counters rate inbound interface
Usage: Bandwidth utilization in percentage
Interface Usage(%) Total(pps) Broadcast(pps) Multicast(pps)
XGE5/3/0 0.01 7 -- --
MGE0/31/0 0.01 1 -- --
MGE0/32/0 0.01 5 -- --
VMC1/1/0 0.05 60 -- --
VMC1/2/0 0.04 52 -- --
Overflow: More than 14 digits.
--: Not supported.
<CTRL-VM-vm-net>
c. 如果端口使用率明显增大，可继续多次执行display counters inbound interface命令查看接口收到的总报文数、广播和组播报文的数量，分别对应显示信息中Total(pkt)、Broadcast(pkt)、Multicast(pkt)字段的取值。如果广播和组播报文的增长速度快，广播、组播报文在接口收到的总报文数中占比大，则可能出现广播/组播风暴。如果广播和组播报文数量没有明显增加，但是接口收到的总报文数明显增加，则可能出现未知单播报文风暴。
<CTRL-VM-vm-net> display counters inbound interface
Interface Total(pkt) Broadcast(pkt) Multicast(pkt) Err(pkt)
XGE5/3/0 141 27 111 0
MGE0/31/0 274866 47696 0 --
MGE0/32/0 1063034 684808 2 --
VMC1/1/0 11157797 7274558 50 0
VMC1/2/0 9653898 5619640 52 0
Overflow: More than 14 digits (7 digits for column "Err").
--: Not supported.
<CTRL-VM-vm-net> quit
[CTRL-VM] quit
<CTRL-VM>
¡ 如出现广播、组播、未知单播报文风暴，可进行如下处理：
- 检查VM的接入交换机上是否存在物理线路，避免网络拓扑出现环路。
- 检查VM的接入交换机上VLAN、端口聚合等配置，避免配置错误导致环路。
- 在VM上使用QoS策略针对组播、广播和未知单播报文进行限速。
¡ 如未出现广播、组播、未知单播报文风暴，请执行步骤(3)。
(3) 确认是否配置了流统计和采样功能，以及配置的参数是否合适。
当设备上配置了NetStream、sFlow等网络流量监控功能后，设备会对网络流量进行统计分析。如果网络流量较高，可能会导致CPU占用率偏高。此时，可进行以下处理：
¡ 配置过滤条件来精确匹配流量，仅统计分析用户关心的流量。
¡ 配置采样器，调整采样比例，使得NetStream、sFlow收集到的统计信息既能基本反映整个网络的状况，又能避免统计报文过多影响设备转发性能。
(4) 确认设备当前是否正在生成海量日志。
某些异常情况下，例如，设备受到攻击、运行中发生了错误、端口频繁Up/Down等，设备会不停地产生诊断信息或日志信息。此时系统软件要频繁的读写存储器，会造成CPU占用率升高。
可通过以下方式来判断设备是否正在生成海量日志：
¡ Telnet登录到设备，配置terminal monitor命令允许日志信息输出到当前终端。
<CTRL-VM> terminal monitor
The current terminal is enabled to display logs.
配置该命令后，如果有大量异常日志或者重复日志输出到命令行界面，则说明设备正在生成海量日志。
¡ 执行display logbuffer命令，查看显示信息中是否有大量异常日志或者某一条信息大量重复出现。
<CTRL-VM> display logbuffer reverse
Log buffer: Enabled
Max buffer size: 1024
Actual buffer size: 512
Dropped messages: 0
Overwritten messages: 0
Current messages: 410
%Jan 15 08:17:24:259 2021 CTRL-VM SHELL/6/SHELL_CMD: -Line=vty0-IPAddr=192.168.2.108-User=**; Command is display logbuffer
%Jan 15 08:17:19:743 2021 CTRL-VM SHELL/4/SHELL_CMD_MATCHFAIL: -User=**-IPAddr=192.168.2.108; Command display logfile in view shell failed to be matched.
%Jan 15 07:12:54:584 2021 CTRL-VM SHELL/6/SHELL_CMD: -Line=vty0-IPAddr=192.168.2.108-User=**; Command is display counters rate in
其它显示信息略……
<CTRL-VM> display logbuffer summary
Slot EMERG ALERT CRIT ERROR WARN NOTIF INFO DEBUG
1 0 0 2 9 24 12 128 0
5 0 0 0 41 72 8 2 0
97 0 0 42 11 14 7 40 0
如果设备正在生成海量日志，可以通过以下方法减少日志的生成：
¡ 关闭部分业务模块的日志输出功能。
¡ 使用info-center logging suppress命令禁止指定模块日志的输出。
¡ 使用info-center logging suppress duplicates命令开启重复日志抑制功能。
如果设备未生成海量日志，则执行步骤(6)。
(5) 收集CPU占用率相关信息，找到CPU控制核占用率高的业务模块。
a. 确认每个VM的slot编号。
# 登录CTRL-VM，在CTRL-VM上执行display vm命令，可以查看每个VM的slot编号。
<CTRL-VM> display vm
Abbreviation: R-Role M-Master S-Standby MD-MAD down DING-DESTROYING
Slot VM name Type State(R) Registration
1 DC1_CP_CTRL_VM_1 CTRL-VM Normal(M) --
2 DC1_CP_CTRL_VM_2 CTRL-VM Normal(S) --
5 DC1_CP_FWD_VM_5 FWD-VM Normal(-) Registered
6 DC1_CP_FWD_VM_6 FWD-VM Normal(-) Registered
97 DC1_CP_BRAS_VM_97 BRAS-VM Normal(M) Registered
98 DC1_CP_BRAS_VM_98 BRAS-VM Normal(S) Registered
99 DC1_CP_BRAS_VM_99 BRAS-VM Normal(M) Registered
100 DC1_CP_BRAS_VM_100 BRAS-VM Normal(S) Registered
b. 确定每个VM上CPU控制核的编号。
# 分别登录每个VM，在该VM上执行display driver forward命令查看该VM的控制核的编号。下面以CTRL-VM上（slot 1）的操作为例。
<CTRL-VM> system-view
[CTRL-VM] probe
[CTRL-VM-probe] display driver forward slot 1 enable
Fwd Statistics Enabled!
[CTRL-VM-probe] display driver forward slot 1 core
CPU STATE PLANE STATISTICS
0 USED Ctrl Fwd 0
1 USED Ctrl Fwd 0
2 USED Data Dis Rx 2196 Tx 0
3 USED Data Fwd Fwd 5183
4 USED Data Dis Rx 0 Tx 3833
以上显示信息表明：在CTRL-VM上控制核的编号为0和1。
# 在CTRL-VM上通过VM的slot编号可步骤登录BRAS-VM和FWD-VM。例如，在CTRL-VM上登录FWD-VM（slot编号为5，IP地址为192.168.0.2）的步骤如下：
<CTRL-VM> system-view
[CTRL-VM] switchto vm-net-setup
Enter password:
As a best practice, use the default VM network setup. Changes in the VM network
setup environment might cause the CP to malfunction. If you need to change a set
ting, make sure you understand its impact on the services.
<CTRL-VM-vm-net> switchto vm slot 5
Press CTRL+C to abort.
Connecting to 192.168.0.2 port 22.
********************************************************************************
* Copyright (c) 2004-2021 New H3C Technologies Co., Ltd. All rights reserved.*
* Without the owner's prior written consent, *
* no decompiling or reverse-engineering shall be allowed. *
********************************************************************************
<CTRL-VM-slot5>
c. 确定对CPU控制核占用率高的任务。
# 分别登录每个VM，在该VM上执行display process cpu命令查看一段时间内占用CPU最多的任务。下面以CTRL-VM（slot 1）上的操作为例。
[CTRL-VM-probe] display process cpu slot 1
CPU utilization in 5 secs: 0.4%; 1 min: 0.2%; 5 mins: 0.2%
JID 5Sec 1Min 5Min Name
1 0.0% 0.0% 0.0% scmd
2 5.5% 5.1% 5.0% [kthreadd]
3 0.0% 0.0% 0.0% [ksoftirqd/0]
5 0.0% 0.0% 0.0% [kworker/0:0H]
7 0.0% 0.0% 0.0% [rcu_sched]
8 0.0% 0.0% 0.0% [rcu_bh]
9 0.0% 0.0% 0.0% [migration/0]
其他显示信息略……
如果某个进程的CPU占用率高于5%，则需要针对该进程继续定位。
# 分别登录每个VM，在该VM上执行monitor process dumbtty命令实时查看进程在指定CPU上的占用率。下面以CTRL-VM的slot 1 CPU 0为例。
[CTRL-VM-probe] monitor process dumbtty slot 1 cpu 0
206 processes; 342 threads; 5134 fds
Thread states: 4 running, 338 sleeping, 0 stopped, 0 zombie
CPU0: 99.04% idle, 0.00% user, 0.96% kernel, 0.00% interrupt, 0.00% steal
CPU1: 98.06% idle, 0.00% user, 1.94% kernel, 0.00% interrupt, 0.00% steal
CPU2: 0.00% idle, 0.00% user, 100.00% kernel, 0.00% interrupt, 0.00% steal
CPU3: 0.00% idle, 0.00% user, 100.00% kernel, 0.00% interrupt, 0.00% steal
CPU4: 0.00% idle, 0.00% user, 100.00% kernel, 0.00% interrupt, 0.00% steal
Memory: 7940M total, 5273M available, page size 4K
JID PID PRI State FDs MEM HH:MM:SS CPU Name
322 322 115 R 0 0K 01:48:03 20.02% [kdrvfwdd2]
323 323 115 R 0 0K 01:48:03 20.02% [kdrvfwdd3]
324 324 115 R 0 0K 01:48:03 20.02% [kdrvfwdd4]
376 376 120 S 22 159288K 00:00:07 0.37% diagd
1 1 120 S 18 30836K 00:00:02 0.18% scmd
379 379 120 S 22 173492K 00:00:11 0.18% devd
2 2 120 S 0 0K 00:00:00 0.00% [kthreadd]
3 3 120 S 0 0K 00:00:02 0.00% [ksoftirqd/0]
其他显示信息略……
- 在monitor process dumbtty命令显示信息中找到CPU占用率超过5%的进程的JID，再对这些进程执行display proce job命令，收集进程的详细信息，并确认该进程是否运行在控制核上。
如果display proce job命令的显示信息中LAST_CPU字段的取值为控制核的编号（例如0～1），则说明该进程运行在CPU控制核上，则需要进一步定位；如果显示信息中LAST_CPU字段的取值为非控制核的编号，则说明该进程运行在CPU转发核上，无需关注，请执行步骤(7)。下面以pppd进程为例，通过显示信息可以看到，该进程包含多个线程，这些线程都运行在控制核上。
<CTRL-VM> display process name pppd
Job ID: 515
PID: 515
Parent JID: 1
Parent PID: 1
Executable path: /sbin/pppd
Instance: 0
Respawn: ON
Respawn count: 1
Max. spawns per minute: 12
Last started: Wed Nov 3 09:52:00 2021
Process state: sleeping
Max. core: 1
ARGS: --MaxTotalLimit=2000000 --MaxIfLimit=65534 --CmdOption=0x01047fbf --bSaveRunDb --pppoechastenflag=1 --pppoechastennum=6 --pppoechastenperiod=60 --pppoechastenblocktime=300 --pppchastenflag=1 --pppchastennum=6 --pppchastenperiod=60 --pppchastenblocktime=300 --PppoeKChasten --bSoftRateLimit --RateLimitToken=2048
TID LAST_CPU Stack PRI State HH:MM:SS:MSEC Name
515 0 136K 115 S 0:0:0:90 pppd
549 0 136K 115 S 0:0:0:0 ppp_misc
557 0 136K 115 S 0:0:0:10 ppp_chasten
610 0 136K 115 S 0:0:0:0 ppp_work0
611 1 136K 115 S 0:0:0:0 ppp_work1
612 1 136K 115 S 0:0:0:0 ppp_work2
613 1 136K 115 S 0:0:0:0 mp_main
618 1 136K 115 S 0:0:0:110 pppoes_main
619 1 136K 115 S 0:0:0:100 pppoes_mesh
620 1 136K 115 S 0:0:0:120 l2tp_mesh
621 1 136K 115 S 0:0:0:20 l2tp_main
- 对于运行在控制核、CPU占用率超过5%的进程，查看进程的Name字段的取值来确定该进程是否为用户态进程。
如果Process的Name取值中包含“[ ]”，表示它是内核线程，无需执行monitor thread dumbtty命令；如果Process的Name取值中未包含“[ ]”，表示它是用户态进程，它可能包含多个线程。对于多线程的用户态进程，还需要对该用户态进程执行monitor thread dumbtty命令，如果显示信息中某线程LAST_CPU字段的取值为CPU控制核的编号，且CPU字段取值大于5%，则该线程可能为导致CPU控制核占用率高的线程，需要进一步定位。
<CTRL-VM> monitor thread dumbtty slot 1 cpu 0
206 processes; 342 threads; 5134 fds
Thread states: 4 running, 338 sleeping, 0 stopped, 0 zombie
CPU0: 98.06% idle, 0.97% user, 0.97% kernel, 0.00% interrupt, 0.00% steal
CPU1: 97.12% idle, 0.96% user, 0.96% kernel, 0.96% interrupt, 0.00% steal
CPU2: 0.00% idle, 0.00% user, 100.00% kernel, 0.00% interrupt, 0.00% steal
CPU3: 0.00% idle, 0.00% user, 100.00% kernel, 0.00% interrupt, 0.00% steal
CPU4: 0.00% idle, 0.00% user, 100.00% kernel, 0.00% interrupt, 0.00% steal
Memory: 7940M total, 5315M available, page size 4K
JID TID LAST_CPU PRI State HH:MM:SS MAX CPU Name
322 322 2 115 R 00:04:21 0 20.15% [kdrvfwdd2]
323 323 3 115 R 00:04:21 0 20.15% [kdrvfwdd3]
324 324 4 115 R 00:04:21 0 20.15% [kdrvfwdd4]
1 1 1 120 S 00:00:02 21 0.19% scmd
376 376 1 120 S 00:00:00 1 0.19% diagd
2 2 0 120 S 00:00:00 0 0.00% [kthreadd]
其他显示信息略……
d. 确认异常任务的调用栈。
分别登录每个VM，在该VM的Probe视图下执行follow job命令确认异常任务的调用栈。下面以CTRL-VM上（slot 1）pppd进程（进程编号为515）的操作为例。
<CTRL-VM> system-view
[CTRL-VM] probe
[CTRL-VM-probe] follow job 515 slot 1
Attaching to process 515 (pppd)
Iteration 1 of 5
------------------------------
Thread LWP 515:
Switches: 3205
User stack:
#0 0x00007fdc2a3aaa8c in epoll_wait+0x14/0x2e
#1 0x0000000000441745 in ppp_EpollSched+0x35/0x5c
#2 0x0000000000000004 in ??
Kernel stack:
[<ffffffff811f0573>] ep_poll+0x2f3/0x370
[<ffffffff811f06c0>] SyS_epoll_wait+0xd0/0xe0
[<ffffffff814aed79>] system_call_fastpath+0x16/0x1b
[<ffffffffffffffff>] 0xffffffffffffffff
Thread LWP 549:
Switches: 20
User stack:
#0 0x00007fdc2a3aaa8c in epoll_wait+0x14/0x2e
#1 0x00000000004435d4 in ppp_misc_EpollSched+0x44/0x6c
Kernel stack:
[<ffffffffffffffff>] 0xffffffffffffffff
其它显示信息略……
e. 根据a、b、c、d步骤找到的任务的名称，找到对应的业务模块，定位并处理业务模块的问题。例如，如果任务snmpd的CPU占用率较高，可能是因为设备受到了SNMP攻击，或者NMS对设备的访问太频繁。需要进一步定位SNMP业务模块的问题；如果任务nqad的CPU占用率较高，可能是因为NQA探测太频繁，需要进一步定位NQA业务模块的问题。
(6) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
· hh3cEntityExtCpuUsageThresholdNotfication
· hh3cEntityExtCpuUsageThresholdRecover
· hh3cCpuUsageSevereNotification
· hh3cCpuUsageSevereRecoverNotification
· hh3cCpuUsageMinorNotification
· hh3cCpuUsageMinorRecoverNotification
· DIAG/5/CPU_MINOR_RECOVERY
· DIAG/4/CPU_MINOR_THRESHOLD
· DIAG/5/CPU_SEVERE_RECOVERY
· DIAG/3/CPU_SEVERE_THRESHOLD
当出现以下情况时，说明CP设备（包括CTRL-VM、BRAS-VM和FWD-VM）的内存占用率高。
· 对CP设备进行每日巡检时，多次执行display memory或display health命令后，观察到内存占用率持续高并且在不断增长。
· 执行display memory-threshold命令后，观察到CP设备当前内存使用情况处于非正常状态。
· CP设备上打印内存占用率高的相关日志。
· SNMP网管上出现内存占用率高的相关告警。
本类故障的常见原因主要包括：
· 配置的内存利用率阈值过低。
· 配置的剩余空闲内存告警的门限值过高。
· 配置的DMA（Direct Memory Access，直接内存存取）空闲内存告警阈值过高。
· BRAS接入用户数超规格。
· VM内存泄露。
· BRAS接入用户上线或者下线速率过快导致UCM模块无法及时处理用户上线/下线请求消息，有消息队列积压。
本类故障的诊断流程如图9-43所示。
图9-43 CP设备的VM内存占用率高导致进入内存门限故障诊断流程图
(1) 确认配置的内存利用率阈值是否过低。
因CP设备每隔1分钟会对内存利用率进行采样，并将采样值和用户配置的内存利用率阈值（缺省值为100%）比较。当采样值较大时，则认为内存利用率过高，CP设备会生成Trap和日志告警。
为避免因配置不合理原因导致告警，请执行以下操作：
a. 在CTRL-VM上任意视图下执行display health slot命令查看指定VM的当前实际内存利用率。
<CTRL-VM> display health slot 1
Slot CPU Role CPU Usage(%) Memory Usage(%) Used/Total(MB) Disk Info
1 0 Master 0 50 5053/9917 855/31715(2)
b. 在CTRL-VM上任意视图下执行display memory-threshold slot命令查看指定VM上配置的内存利用率阈值。
<CTRL-VM> display memory-threshold slot 1
Memory usage threshold: 20% //配置的内存利用率阈值
Free-memory thresholds:
Minor: 495M
Severe: 396M
Critical: 297M
Normal: 595M
Current free-memory state: Critical
Free-memory event statistics:
……
如上，查看到的实际内存利用率为50%（不是太高），但配置的内存利用率阈值为20%（过低），因配置不合理导致指定VM误认为实际的内存利用率过高而产生Trap和日志告警。
针对这种情况，请在系统视图下执行undo memory-threshold usage命令恢复VM内存利用率阈值的缺省值（缺省值100%），或根据实际需要执行memory-threshold usage命令为各VM配置合理的内存利用率阈值。
memory-threshold usage命令仅对当前VM生效。如需修改多个VM的内存利用率阈值，请分别登录到对应的VM单独进行配置。
c. 若配置的内存利用率阈值高于实际内存利用率，故障仍存在，请继续执行下一步。
(2) 确认配置的剩余空闲内存告警的门限值是否过高。
当VM剩余空闲内存值从大于配置的某级别门限值变成小于该级别门限值时便会产生Trap和日志告警，如果配置的告警门限值过高，那么VM剩余空闲内存值很容易小于配置的告警门限值触发告警。
为避免因配置不合理原因导致告警，请执行以下操作：
a. 在CTRL-VM上任意视图下执行display health slot命令查看指定VM的内存总大小。
<CTRL-VM> display health slot 1
Slot CPU Role CPU Usage(%) Memory Usage(%) Used/Total(MB) Disk Info
1 0 Master 0 50 5053/9917 855/31715(2)
b. 在CTRL-VM上任意视图下执行display memory-threshold slot命令查看指定VM上配置的各级剩余空闲内存门限值以及系统当前内存使用状态。
<CTRL-VM> display memory-threshold slot 1
Memory usage threshold: 20%
Free-memory thresholds:
Minor: 5000M //配置的一级告警门限值
Severe: 4000M //配置的二级告警门限值
Critical: 3000M //配置的三级告警门限值
Normal: 6000M //配置的系统内存恢复正常状态时的内存大小
Current free-memory state: Minor //系统当前内存使用状态
Free-memory event statistics:
……
如上，查看到的内存总大小为9917MB，配置的一、二、三级剩余空闲内存告警门限值分别为5000M、4000M和3000M，即：
- （9917－5000）÷9917≈49.58% //内存使用率超49.58%产生一级告警
- （9917－4000）÷9917≈59.67% //内存使用率超59.67%产生二级告警
- （9917－3000）÷9917≈69.75% //内存使用率超69.75%产生三级告警
因配置的剩余空闲内存告警的门限值过高，导致在实际内存使用率不高的情况下，VM也很容易达到告警条件产生Trap和日志告警。
针对这种情况，请在系统视图下执行undo memory-threshold命令恢复VM剩余空闲内存告警门限的缺省值（不同类型VM的缺省值可能不同，请以实际情况为准），或根据实际需要执行memory-threshold [ slot slot-number [ cpu cpu-number ] ] [ ratio ] minor minor-value severe severe-value critical critical-value normal normal-value命令为各VM配置合理的剩余空闲内存告警的门限值。
· 如需修改多个VM的内存门限值，在CTRL-VM上执行memory-threshold命令时需要指定VM的slot来完成对指定VM的配置。
· 执行memory-threshold命令时，如果对应级别的门限值取值为0，则表示关闭该级门限告警功能。
· 若执行undo memory-threshold命令时提示“Please set all free-memory thresholds to 0 to disable the free-memory alarm functions first.”，则请先执行memory-threshold minor 0 severe 0 critical 0 normal 0命令，再执行undo memory-threshold命令恢复缺省值。
c. 若配置的剩余空闲内存告警的门限值不高，故障仍存在，请继续执行下一步。
(3) 确认配置的DMA空闲内存告警阈值是否过高。
因部分业务的运行需要使用DMA内存，如果DMA内存不足，会导致业务模块功能异常。系统周期监控DMA空闲内存大小：当DMA空闲内存小于或等于告警阈值，会产生Trap和日志告警事件，表示DMA内存可能不足。
如果配置的告警门限值过高，那么DMA空闲内存很容易小于配置的告警门限值触发告警。
为避免因配置不合理原因导致告警，请执行以下操作：
a. CTRL-VM上任意视图下执行display memory dma命令查看当前VM的DMA内存使用情况。
<CTRL-VM> display memory dma
DMA memory statistics measured in KB on slot 1:
Total Used Free FreeRatio
16380 504 15876 97%
b. 在CTRL-VM上任意视图下执行display memory-threshold dma命令查看当前VM上配置的DMA空闲内存告警阈值以及DMA内存的当前状态。
<CTRL-VM> display memory-threshold dma
Free DMA memory thresholds:
Critical: 16000KB //配置的DMA空闲内存告警阈值
Normal: 16000KB //配置的DMA空闲内存告警恢复阈值
Current DMA memory state: Critical //DMA内存的当前状态
Free memory event statistics:
[Back to normal state]
First notification: 0.0
Latest notification: 0.0
Total number of notifications sent: 0
[Entered to critcal state]
First notification: 2000-09-17 09:06:01.525
Latest notification: 2000-09-17 09:06:01.525
Total number of notifications sent: 1
如上，查看到的实际DMA空闲内存为15876KB，空闲率97%（内存使用率不高），但配置的DMA空闲内存告警阈值为16000KB（过高），因配置不合理导致当前VM误认为实际的DMA空闲内存过低而产生Trap和日志告警。
针对这种情况，请在系统视图下执行undo memory-threshold dma命令恢复VM的DMA空闲内存告警阈值的缺省值（不同类型VM的缺省值可能不同，请以实际情况为准），或根据实际需要执行memory-threshold dma [ slot slot-number [ cpu cpu-number ] ] [ ratio ] critical critical-value normal normal-value命令为各VM配置合理的DMA空闲内存告警阈值。
memory-threshold dma命令仅对当前VM生效。如需修改多个VM的内存利用率阈值，请分别登录到对应的VM单独进行配置。
c. 若配置的剩余DMA空闲内存的门限值不高，故障仍存在，请继续执行下一步。
(4) 收集在线BRAS接入用户数信息。
在CTRL-VM上任意视图下执行display access-user count命令收集CP设备当前在线用户数。
请继续执行下一步。
(5) 收集用户态和内核态各模块的内存占用信息。
在CTRL-VM上任意视图下：
¡ 重复执行display process memory slot命令通过每次指定不同的slot收集当前CP设备中所有VM用户态各模块的内存占用信息。
¡ 重复执行display system internal kernel memory pool tag slot命令通过每次指定不同的slot收集当前CP设备中所有VM内核态各模块的内存占用信息。
请继续执行下一步。
(6) 收集UCM主进程中不同消息队列接收到的消息数。
分别在CTRL-VM、BRAS-VM和FWD-VM上Probe视图下，执行display system internal ucm main-ctrl queue命令收集UCM主进程中不同消息队列接收到的消息数。
display system internal ucm main-ctrl queue命令仅对当前VM生效。对于CTRL-VM、BRAS-VM、FWD-VM，请分别登录到对应的VM单独执行该命令收集对应VM上UCM主进程中不同消息队列接收到的消息数。
请继续执行下一步。
(7) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
HH3C-LswTRAP-MIB
· hh3cMemoryUsageMinorNotification(1.3.6.1.4.1.25506.8.35.12.1.35)
· hh3cMemoryUsageMinorRecoverNotification(1.3.6.1.4.1.25506.8.35.12.1.36)
· hh3cMemoryUsageSevereNotification(1.3.6.1.4.1.25506.8.35.12.1.37)
· hh3cMemoryUsageSevereRecoverNotification(1.3.6.1.4.1.25506.8.35.12.1.38)
· hh3cMemoryUsageCriticalNotification(1.3.6.1.4.1.25506.8.35.12.1.39)
· hh3cMemoryUsageCriticalRecoverNotification(1.3.6.1.4.1.25506.8.35.12.1.40)
· hh3cMemoryUsageEarlyWarningNotification(1.3.6.1.4.1.25506.8.35.12.1.33)
· hh3cMemoryUsageEarlyWarningRecoverNotificatio(1.3.6.1.4.1.25506.8.35.12.1.34)
· DIAG_DMA_MEM_CRITICAL_THRESHOLD
· DIAG_DMA_MEM_RECOVERY
· KERNEL_MEMFRAGMT_BELOW_THRESHOLD
· KERNEL_MEMFRAGMT_EXCEED_THRESHOLD
· MEM_ALERT
· MEM_EXCEED_THRESHOLD
· MEM_BELOW_THRESHOLD
· MEM_USAGE_RECOVERY
· MEM_USAGE_THRESHOLD
DHCP Flood攻击是指攻击者短时间内恶意向DHCP服务器发送大量的DHCP请求报文申请IP地址，侵占DHCP服务器的系统资源，导致其它合法的DHCP交互无法正常进行。
针对DHCP Flood攻击，DHCP服务器上可采取的防范措施包括：
· DHCP Flood攻击防范功能
· DHCP接口抑制功能
· DHCP服务器上开启DHCP防Flood攻击功能后，仍存在大量的攻击报文上送CPU并占用系统资源。
· 合法用户请求报文被当成攻击报文处理，合法用户无法正常获得IP地址上线。
本类故障的常见原因主要包括：
· DHCP服务器与客户端相连的接口上未开启DHCP防Flood攻击功能。
· DHCP中继组网环境中，在DHCP服务器或非首跳中继上开启了DHCP Flood攻击防范功能。
· DHCP服务器上设置的防Flood攻击阈值不合理。
本类故障的诊断流程如图9-44所示。
图9-44 DHCP防Flood攻击功能异常故障诊断流程图
· DHCP Flood攻击防范功能的报文计数是针对源MAC固定的DHCP请求报文，但对于大量源MAC不相同的攻击报文，DHCP Flood攻击防范功能起不到限速作用。因此，为了达到更好的防Flood攻击效果，建议在接口上同时开启DHCP接口攻击抑制功能，基于接口收到的所有DHCP请求报文进行计数并限速。
· 本文将“DHCP Flood攻击防范功能”和“DHCP接口攻击抑制功能”统称为“DHCP防Flood攻击功能”。
· DHCPv6防Flood攻击与DHCP防Flood攻击除命令行略有差异外，其余故障处理步骤一致。
(1) DHCP服务器和客户端同网段的直连组网环境中，检查DHCP服务器与客户端相连的接口上是否开启了DHCP防Flood攻击功能。中继组网请执行步骤（2）。
在DHCP服务器连接客户端的接口视图下执行display this命令查看该接口下是否配置了DHCP Flood攻击防范功能和DHCP接口攻击抑制功能。对于DHCP Flood攻击防范功能，同时需要通过display dhcp flood-protection查看全局DHCP Flood攻击防范功能是否开启，全局开启的情况下，接口下可以不配置。
<Sysname> system-view
[Sysname] interface ten-gigabitethernet 3/1/1
[Sysname-Ten-GigabitEthernet3/1/1] display this
#
interface Ten-GigabitEthernet3/1/1
port link-mode route
dhcp flood-protection enable
dhcp interface-rate-suppression enable
...
<Sysname> display dhcp flood-protection
Global DHCP flood protection: Enabled
DHCP flood protection threshold: 100 packets/ 2000 milliseconds
Index MAC address UDP port SVLAN/CVLAN State
...
¡ 如果该接口上未开启DHCP防Flood攻击功能，则需要在该接口视图下通过dhcp flood-protection enable和dhcp interface-rate-suppression enable命令或全局视图下执行dhcp flood-protection global enable命令开启DHCP防Flood攻击功能。
¡ 如果该接口上开启了DHCP防Flood攻击功能，则执行步骤（3）。
(2) DHCP服务器和客户端不同网段的中继组网环境中，检查服务器或中继上的防Flood攻击功能是否配置正确。非中继组网请跳过本步骤。
a. 检查是否在服务器或中继与客户端相连的接口上开启DHCP接口攻击抑制功能。检查过程同步骤（1）。
b. 检查是否在DHCP服务器或非首跳中继与客户端相连的接口上开启了DHCP Flood攻击防范功能。
当DHCP报文通过链路中的三层设备转发给服务器时，报文头里的源MAC地址将被替换为该设备的MAC地址。如果在DHCP服务器或非首跳中继上开启了DHCP Flood攻击防范功能，当服务器或非首跳中继收到三层设备转发的同MAC报文数量过多时，会导致正常合法报文被DHCP服务器或非首跳中继误判为攻击报文。
因此中继组网环境中，建议在服务器或非首跳中继与客户端相连的接口视图下执行undo dhcp flood-protection enable关闭服务器或非首跳中继上的DHCP Flood攻击防范功能，仅在靠近DHCP客户端的第一跳DHCP中继设备与客户端相连的接口上开启DHCP Flood攻击防范功能。
判断中继上是否开启了DHCP Flood攻击防范功能的过程同步骤（1）。
(3) 检查DHCP防Flood攻击功能设置的防攻击阈值是否合理。
在DHCP服务器的任意视图下执行display dhcp flood-protection查看DHCP Flood攻击防范功能设置的报文限速阈值。
<Sysname> display dhcp flood-protection
Global DHCP flood protection: Enabled
DHCP flood protection threshold: 100 packets/ 2000 milliseconds
Index MAC address UDP port SVLAN/CVLAN State
...
在任意视图下执行display dhcp interface-rate-suppression查看DHCP抑制功能设置的报文限速阈值。
<Sysname> display dhcp interface-rate-suppression
DHCP attack suppression threshold: 100 packets/ 2000 milliseconds
Index Interface State
...
报文限速阈值设置过大，起不到防攻击效果；设置太小，影响正常用户报文上送。一般推荐使用设备的缺省阈值，但如果与设备实际使用中接收的DHCP请求报文速率相差较大，可在系统视图下执行dhcp flood-protection threshold和dhcp interface-rate-suppression threshold命令调整配置。
(4) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
¡ 执行debugging dhcp server all、debugging ipv6 dhcp server all命令收集的调试信息。
无
无
DHCP饿死攻击是指攻击者伪造chaddr（client hardware address，DHCP客户端的硬件地址）字段各不相同的DHCP请求报文，向DHCP服务器申请大量的IP地址。一方面导致DHCP服务器地址池中的地址耗尽，无法为合法的DHCP客户端分配IP地址；另一方面可能导致DHCP服务器消耗过多的系统资源，无法处理正常业务。
对于上述情况一，可以通过在DHCP服务器上配置DHCP防饿死攻击功能进行防范；对于上述情况二，配置DHCP防饿死攻击功能的同时需要开启DHCP Flood攻击防范功能。
· 开启DHCP防饿死攻击功能后，DHCP服务器上仍频繁出现地址池资源被耗尽的情况。
· 合法用户请求报文被当成攻击报文处理，合法用户无法正常获得IP地址上线。
本类故障的常见原因主要包括：
· DHCP服务器与客户端相连的接口上未开启DHCP防饿死攻击功能。
· DHCP中继组网环境中，在DHCP服务器或非首跳中继上配置了MAC地址检查功能。
· 接口上配置的允许接口学习到的最大ARP表项或MAC地址数不合理。
本类故障的诊断流程如图9-45所示。
图9-45 DHCP防饿死攻击功能异常故障诊断流程图
(1) DHCP服务器和客户端同网段的直连组网环境中，检查DHCP服务器与客户端相连的接口上是否开启了DHCP防饿死攻击功能。中继组网请执行步骤（2）。
为了更全面的进行DHCP饿死攻击防范，DHCP服务器上需要同时开启针对源MAC地址各不相同的DHCP请求报文和针对源MAC地址相同的DHCP请求报文的防饿死攻击功能：
¡ 针对源MAC地址各不相同的DHCP请求报文：
- 对于三层接口，可以在三层接口视图下执行arp max-learning-num命令设置允许接口学习的最大ARP表项数来防止饿死攻击。
- 对于二层接口，可以在二层接口视图下执行mac-address max-mac-count命令设置允许接口学习的最大MAC地址数，并执行undo mac-address max-mac-count enable-forwarding命令配置当达到接口的MAC地址数学习上限时，禁止转发源MAC地址不在MAC地址表里的报文来防止饿死攻击。
在DHCP服务器与客户端相连的接口上执行display this命令，查看当前接口下的配置。
# 显示三层接口配置
<Sysname> system-view
[Sysname] interface ten-gigabitethernet 3/1/1
[Sysname-Ten-GigabitEthernet3/1/1] display this
#
interface Ten-GigabitEthernet3/1/1
port link-mode route
arp max-learning-num 10
...
# 显示二层接口配置
<Sysname> system-view
[Sysname] interface ten-gigabitethernet 3/1/1
[Sysname-Ten-GigabitEthernet3/1/1] display this
#
interface Ten-GigabitEthernet3/1/1
port link-mode bridge
mac-address max-mac-count 600
undo mac-address max-mac-count enable-forwarding
...
如果未显示相应的防饿死攻击功能信息：
- 若接口为三层口，则在三层接口视图下执行arp max-learning-num命令配置允许接口学习的最大ARP表项数。
- 若接口为二层口，则在二层接口视图下执行mac-address max-mac-count和undo mac-address max-mac-count enable-forwarding命令配置MAC地址数学习上限以及禁止转发源MAC地址不在MAC地址表里的报文。
¡ 针对源MAC地址相同的DHCP请求报文，通过在DHCP服务器的接口视图下执行dhcp server check mac-address命令开启MAC地址检查功能来防止饿死攻击。开启该功能后，设备检查接收到的DHCP请求报文中的chaddr字段和数据帧的源MAC地址字段是否一致。如果一致，则认为该报文合法，继续后续处理；如果不一致，则丢弃该报文。
在DHCP服务器与客户端相连的接口上执行display this命令，查看当前接口下是否开启了MAC地址检查功能。
<Sysname> system-view
[Sysname] interface ten-gigabitethernet 3/1/1
[Sysname-Ten-GigabitEthernet3/1/1] display this
#
interface Ten-GigabitEthernet3/1/1
port link-mode route
dhcp server check mac-address
...
如果未显示相应的功能信息，则在接口视图下执行dhcp server check mac-address命令开启MAC地址检查功能。
(2) DHCP服务器和客户端不同网段的中继组网环境中，检查服务器或中继上的防饿死攻击功能是否配置正确。非中继组网请跳过本步骤。
a. 检查是否在服务器或中继与客户端相连的接口上配置了允许接口学习的最大ARP表项数或MAC地址数。检查过程同步骤（1）。
b. 检查是否在DHCP服务器或非首跳中继与客户端相连的接口上开启了MAC地址检查功能。
报文通过链路中的三层设备转发给服务器时，报文头里的源MAC地址均被替换为该设备的MAC地址。如果在DHCP服务器或非首跳中继上配置了MAC地址检查功能，当服务器或非首跳中继收到三层设备转发的同MAC报文时，将会导致合法报文被误判为攻击报文。
因此中继组网环境中，建议在DHCP服务器和非首跳中继的接口视图下分别执行undo dhcp server check mac-address和undo dhcp relay check mac-address命令关闭MAC地址检查功能，仅在靠近DHCP客户端的第一跳DHCP中继设备与客户端相连的接口上开启MAC地址检查功能。
判断第一跳中继上是否开启MAC地址检查功能的过程同步骤（1）。
(3) 检查允许接口学习的最大ARP表项数或最大MAC地址数是否配置不合理。
在DHCP服务器的任意视图下执行display this命令，查看当前接口下配置的允许接口学习的最大ARP表项数或最大MAC地址数的值。
# 显示三层接口配置
<Sysname> system-view
[Sysname] interface ten-gigabitethernet 3/1/1
[Sysname-Ten-GigabitEthernet3/1/1] display this
#
interface Ten-GigabitEthernet3/1/1
port link-mode route
arp max-learning-num 10
...
# 显示二层接口配置
<Sysname> system-view
[Sysname] interface ten-gigabitethernet 3/1/1
[Sysname-Ten-GigabitEthernet3/1/1] display this
#
interface Ten-GigabitEthernet3/1/1
port link-mode bridge
mac-address max-mac-count 600
...
如果配置值远大于DHCP服务器上可提供的IP地址数，则容易出现大量用户无法获得IP地址的情况；如果配置值太小，则容易导致合法用户请求报文被丢弃。
一般推荐使用设备配置的缺省值，但如果与实际使用中DHCP服务器上可提供的IP地址数以及上线用户数相差较大，可在接口下执行arp max-learning-num或mac-address max-mac-count命令调整配置。
(4) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
¡ 执行debugging dhcp server all命令收集的调试信息。
无
无
在接口上配置ARP报文限速功能后，该接口收到超过限速阈值的ARP报文时仍会上送CPU处理。
本类故障的常见原因主要包括：
· 接口未配置ARP报文限速功能。
· 接口上配置的ARP报文限速阈值不合理。
本类故障的诊断流程如图9-47所示。
图9-47 ARP报文限速功能异常故障诊断流程图
(1) 查看接口下是否配置了ARP报文限速功能。
在用户视图下执行debugging arp packet命令打开ARP的报文调试信息开关，查看设备收到的ARP报文的信息。
<Sysname> debugging arp packet
*Sep 19 17:15:09:564 2022 H3C ARP/7/ARP_RCV: -MDC=1;
Received an ARP message, operation: 1
Sender MAC : 9c06-1b04-3801 Sender IP : 55.168.81.100
Target MAC : 0000-0000-0000 Target IP : 55.168.80.6
Interface : XGE3/1/1 Port : --
SVLAN ID : 65535 CVLAN ID : 65535
VSI index : 0xffffffff Link ID : 0xffff
“Interface”字段为收到ARP报文的接口，请在该接口视图下，执行display this命令查看接口下的配置信息。
<Sysname> system-view
[Sysname] interface ten-gigabitethernet 3/1/1
[Sysname-Ten-GigabitEthernet3/1/1] display this
#
interface Ten-GigabitEthernet3/1/1
port link-mode route
arp rate-limit 200
...
根据接口下是否存在arp rate-limit配置，判断接口是否开启了ARP报文限速功能：
¡ 若不存在，则表示该接口未开启ARP报文限速功能，请在该接口视图下执行arp rate-limit命令开启ARP报文限速功能。
¡ 若存在，则表示该接口已开启ARP报文限速功能，请继续执行下一步。
(2) 查看配置的ARP报文限速阈值是否合理。
在Probe视图下执行display system internal arp statistics命令查看ARP报文的统计信息。
<Sysname> system-view
[Sysname] probe
[Sysname-probe] display system internal arp statistics slot 3
Entry statistics:
Valid = 16 Dummy = 0
Long static = 0 Short resolved = 0
Multiport = 0 L3 short = 0
Packet = 16 OpenFlow = 0
Rule = 0 ARP input = 286
Resolved = 0
...
在指定时间内，两次执行display system internal arp statistics命令查看ARP报文的统计信息。根据执行命令间隔时间T2-T1以及两次“ARP input”字段的差值N2-N1，估算接收的ARP报文速率Vt=（N2-N1）/（T2-T1）：
¡ 如果估算值明显大于ARP报文限速阈值，则表示ARP报文限速功能未生效，接口未起到拦截ARP攻击报文的作用。请在相同接口下重新执行arp rate-limit命令配置ARP报文限速功能。配置完成后再次通过执行display system internal arp statistics命令估算接收的ARP报文速率，若ARP报文限速功能仍未生效，请继续执行下一步。
¡ 如果估算值和配置的ARP报文限速阈值接近，则说明配置的ARP报文限速阈值不合理。ARP报文限速阈值过小会导致正常用户的ARP报文被丢弃；ARP报文限速阈值过大，则起不到拦截攻击报文的作用。限速阈值一般推荐使用设备的缺省值，若不符合实际应用场景，请接口视图下通过arp rate-limit命令进行适当调整。
(3) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
无
RXTX/4/PRO_ATTACK
· 本文主要针对DHCP服务器上的防攻击功能进行故障排查和处理。
· DHCP各类防攻击功能的具体实现请参见《DHCP防攻击技术白皮书》。
DHCP Flood攻击是指攻击者短时间内恶意向DHCP服务器发送大量的DHCP请求报文申请IP地址，侵占DHCP服务器的系统资源，导致其它合法的DHCP交互无法正常进行。
针对DHCP Flood攻击，DHCP服务器上可采取的防范措施包括：
· DHCP Flood攻击防范功能
· DHCP服务器上开启DHCP防Flood攻击功能后，仍存在大量的攻击报文上送CPU并占用系统资源。
· 合法用户请求报文被当成攻击报文处理，合法用户无法正常获得IP地址上线。
本类故障的常见原因主要包括：
· DHCP服务器与客户端相连的接口上未开启DHCP防Flood攻击功能。
· DHCP中继组网环境中，在DHCP服务器或非首跳中继上开启了DHCP Flood攻击防范功能。
· DHCP服务器上设置的防Flood攻击阈值不合理。
本类故障的诊断流程如图9-44所示。
图10-1 DHCP防Flood攻击功能异常故障诊断流程图
· DHCPv6防Flood攻击与DHCP防Flood攻击除命令行略有差异外，其余故障处理步骤一致。
(1) DHCP服务器和客户端同网段的直连组网环境中，检查DHCP服务器与客户端相连的接口上是否开启了DHCP防Flood攻击功能。中继组网请执行步骤（2）。
在DHCP服务器连接客户端的接口视图下执行display this命令查看该接口下是否配置了DHCP Flood攻击防范功能。对于DHCP Flood攻击防范功能，同时可以通过display dhcp flood-protection查看全局DHCP Flood攻击防范功能是否开启，全局开启的情况下，接口下可以不配置。
<Sysname> system-view
[Sysname] interface ten-gigabitethernet 1/1/0
[Sysname-Ten-GigabitEthernet1/1/0] display this
#
interface Ten-GigabitEthernet1/1/0
port link-mode route
dhcp flood-protection enable
...
<Sysname> display dhcp flood-protection slot 1
Global DHCP flood protection: Enabled
DHCP flood protection threshold: 100 packets/ 2000 milliseconds
Index MAC address UDP port SVLAN/CVLAN State
...
¡ 如果该接口上未开启DHCP防Flood攻击功能，则需要在该接口视图下通过dhcp flood-protection enable命令或全局视图下执行dhcp flood-protection global enable命令开启DHCP防Flood攻击功能。
¡ 如果该接口上开启了DHCP防Flood攻击功能，则执行步骤（3）。
(2) DHCP服务器和客户端不同网段的中继组网环境中，检查服务器或中继上的防Flood攻击功能是否配置正确。非中继组网请跳过本步骤。
a. 检查是否在DHCP服务器或非首跳中继与客户端相连的接口上开启了DHCP Flood攻击防范功能。
当DHCP报文通过链路中的三层设备转发给服务器时，报文头里的源MAC地址将被替换为该设备的MAC地址。如果在DHCP服务器或非首跳中继上开启了DHCP Flood攻击防范功能，当服务器或非首跳中继收到三层设备转发的同MAC报文数量过多时，会导致正常合法报文被DHCP服务器或非首跳中继误判为攻击报文。
因此中继组网环境中，建议在服务器或非首跳中继与客户端相连的接口视图下执行undo dhcp flood-protection enable关闭服务器或非首跳中继上的DHCP Flood攻击防范功能，仅在靠近DHCP客户端的第一跳DHCP中继设备与客户端相连的接口上开启DHCP Flood攻击防范功能。
判断中继上是否开启了DHCP Flood攻击防范功能的过程同步骤（1）。
(3) 检查DHCP防Flood攻击功能设置的防攻击阈值是否合理。
在DHCP服务器的任意视图下执行display dhcp flood-protection查看DHCP Flood攻击防范功能设置的报文限速阈值。
<Sysname> display dhcp flood-protection slot 1
Global DHCP flood protection: Enabled
DHCP flood protection threshold: 100 packets/ 2000 milliseconds
Index MAC address UDP port SVLAN/CVLAN State
...
报文限速阈值设置过大，起不到防攻击效果；设置太小，影响正常用户报文上送。一般推荐使用设备的缺省阈值，但如果与设备实际使用中接收的DHCP请求报文速率相差较大，可在系统视图下执行dhcp flood-protection threshold命令调整配置。
(4) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
¡ 执行debugging dhcp server all、debugging ipv6 dhcp server all命令收集的调试信息。
无
无
DHCP饿死攻击是指攻击者伪造chaddr（client hardware address，DHCP客户端的硬件地址）字段各不相同的DHCP请求报文，向DHCP服务器申请大量的IP地址。一方面导致DHCP服务器地址池中的地址耗尽，无法为合法的DHCP客户端分配IP地址；另一方面可能导致DHCP服务器消耗过多的系统资源，无法处理正常业务。
对于上述情况一，可以通过在DHCP服务器上配置DHCP防饿死攻击功能进行防范；对于上述情况二，配置DHCP防饿死攻击功能的同时需要开启DHCP Flood攻击防范功能。
· 开启DHCP防饿死攻击功能后，DHCP服务器上仍频繁出现地址池资源被耗尽的情况。
· 合法用户请求报文被当成攻击报文处理，合法用户无法正常获得IP地址上线。
本类故障的常见原因主要包括：
· DHCP服务器与客户端相连的接口上未开启DHCP防饿死攻击功能。
· DHCP中继组网环境中，在DHCP服务器或非首跳中继上配置了MAC地址检查功能。
· 接口上配置的允许接口学习到的最大ARP表项数不合理。
本类故障的诊断流程如图9-45所示。
图10-2 DHCP防饿死攻击功能异常故障诊断流程图
(1) DHCP服务器和客户端同网段的直连组网环境中，检查DHCP服务器与客户端相连的接口上是否开启了DHCP防饿死攻击功能。中继组网请执行步骤（2）。
为了更全面的进行DHCP饿死攻击防范，DHCP服务器上需要同时开启针对源MAC地址各不相同的DHCP请求报文和针对源MAC地址相同的DHCP请求报文的防饿死攻击功能：
¡ 针对源MAC地址各不相同的DHCP请求报文，可以在三层接口视图下执行arp max-learning-num命令设置允许接口学习的最大ARP表项数来防止饿死攻击。
在DHCP服务器与客户端相连的接口上执行display this命令，查看当前接口下的配置。
# 显示三层接口配置
<Sysname> system-view
[Sysname] interface ten-gigabitethernet 1/1/0
[Sysname-Ten-GigabitEthernet1/1/0] display this
#
interface Ten-GigabitEthernet1/1/0
port link-mode route
arp max-learning-num 10
...
如果未显示相应的防饿死攻击功能信息，则在三层接口视图下执行arp max-learning-num命令配置允许接口学习的最大ARP表项数。
¡ 针对源MAC地址相同的DHCP请求报文，通过在DHCP服务器的接口视图下执行dhcp server check mac-address命令开启MAC地址检查功能来防止饿死攻击。开启该功能后，设备检查接收到的DHCP请求报文中的chaddr字段和数据帧的源MAC地址字段是否一致。如果一致，则认为该报文合法，继续后续处理；如果不一致，则丢弃该报文。
在DHCP服务器与客户端相连的接口上执行display this命令，查看当前接口下是否开启了MAC地址检查功能。
<Sysname> system-view
[Sysname] interface gigabitethernet 1/1/0
[Sysname-Ten-Gigabitethernet1/1/0] display this
#
interface Ten-Gigabitethernet1/1/0
port link-mode route
dhcp server check mac-address
...
如果未显示相应的功能信息，则在接口视图下执行dhcp server check mac-address命令开启MAC地址检查功能。
(2) DHCP服务器和客户端不同网段的中继组网环境中，检查服务器或中继上的防饿死攻击功能是否配置正确。非中继组网请跳过本步骤。
a. 检查是否在服务器或中继与客户端相连的接口上配置了允许接口学习的最大ARP表项数。检查过程同步骤（1）。
b. 检查是否在DHCP服务器或非首跳中继与客户端相连的接口上开启了MAC地址检查功能。
报文通过链路中的三层设备转发给服务器时，报文头里的源MAC地址均被替换为该设备的MAC地址。如果在DHCP服务器或非首跳中继上配置了MAC地址检查功能，当服务器或非首跳中继收到三层设备转发的同MAC报文时，将会导致合法报文被误判为攻击报文。
因此中继组网环境中，建议在DHCP服务器和非首跳中继的接口视图下关闭MAC地址检查功能，仅在靠近DHCP客户端的第一跳DHCP中继设备与客户端相连的接口上开启MAC地址检查功能。
判断第一跳中继上是否开启MAC地址检查功能的过程同步骤（1）。
(3) 检查允许接口学习的最大ARP表项数是否配置不合理。
在DHCP服务器的任意视图下执行display this命令，查看当前接口下配置的允许接口学习的最大ARP表项数的值。
# 显示三层接口配置
<Sysname> system-view
[Sysname] interface ten-gigabitethernet 1/1/0
[Sysname-Ten-Gigabitethernet1/1/0] display this
#
interface Ten-Gigabitethernet1/1/0
port link-mode route
arp max-learning-num 10
...
如果配置值远大于DHCP服务器上可提供的IP地址数，则容易出现大量用户无法获得IP地址的情况；如果配置值太小，则容易导致合法用户请求报文被丢弃。
一般推荐使用设备配置的缺省值，但如果与实际使用中DHCP服务器上可提供的IP地址数以及上线用户数相差较大，可在接口下执行arp max-learning-num命令调整配置。
(4) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
¡ 执行debugging dhcp server all命令收集的调试信息。
无
无
设备因收到大量PPP协议的keepalive请求报文导致CPU占用率过高影响系统处理效率。
当出现以下情况时，说明设备的CPU占用率高，需要确认CPU占用率高的具体原因。
· 对设备进行每日巡检时，连续使用display cpu-usage命令查看CPU的占用率，CPU占用率持续在80％以上。（一体化场景）
· 对UP设备进行每日巡检时，连续使用display cpu-usage命令查看CPU的占用率，CPU占用率持续在80％以上。（转控分离场景）
# 执行display cpu-usage summary命令显示最近5秒、1分钟、5分钟内CPU占用率的平均值。
<Sysname> display cpu-usage summary
Slot CPU Last 5 sec Last 1 min Last 5 min
1 0 85% 81% 16%
5 0 0% 0% 0%
97 0 0% 0% 0%
# 执行display cpu-usage history命令以图表的方式显示最近60个采样点的CPU占用率，观察CPU占用率是否持续在80％以上。显示信息中：
¡ 纵坐标表示CPU占用率，采用就近显示的原则。比如，占用率的间隔为5％，则实际统计值53％将被显示成55％，实际统计值52％将被显示成50％。
¡ 横坐标表示时间，时间越靠左表示距离当前时间越近。
¡ 用连续的#号表示该时刻的占用率，某个时间点上最高处的#号对应的纵坐标值即为该采样点计算的CPU占用率。采样间隔可通过monitor cpu-usage interval命令配置（缺省为1分钟）。
<Sysname> display cpu-usage history
100%|
95%|
90%|
85%|
80%|#
75%|#
70%|#
65%|#
60%|#
55%|#
50%|#
45%|#
40%|#
35%|#
30%|#
25%|#
20%|#
15%|# #
10%|# ### #
5%|# ########
------------------------------------------------------------
10 20 30 40 50 60 (minutes)
cpu-usage (Slot 1 CPU 0) last 60 minutes (SYSTEM)
其它CPU的显示信息略……
以Slot 1 CPU 0为例：以上显示信息表明系统（用“SYSTEM”表示）在最近60分钟内CPU的占用率情况：1分钟前大约为80％，12分钟前大约为5％，13分钟前大约为10％，14分钟前大约为15％，15分钟前大约为10％，16、17分钟前大约为5％，18分钟前大约为10％，19分钟前大约为5％，其它时间均小于或等于2％。
· 通过Telnet/SSH等方式登录设备，并执行命令行时，设备反应缓慢，出现卡顿现象。
· 设备上打印CPU占用率高的相关日志。
· SNMP网管上出现CPU占用率高的相关告警。
本类故障的常见原因主要包括：
未开启或者误关闭keepalive报文的快速应答功能。
本类故障的诊断流程如图10-4所示。
图10-4 大量keepalive请求报文导致CPU占用率过高
(1) 确认是否受到keepalive报文攻击。
在设备上任意视图下执行display ppp packet statistics命令查看PPP协商报文统计信息。
¡ 若“RECV_LCP_ECHO_REQ”字段取值较大，且在任意视图下多次执行display ppp packet statistics命令后，观察到“RECV_LCP_ECHO_REQ”字段取值不断快速增长，请继续执行下一步。
¡ 若“RECV_LCP_ECHO_REQ”字段取值不大，或在任意视图下多次执行display ppp packet statistics命令后，观察到“RECV_LCP_ECHO_REQ”字段取值缓慢增长，甚至基本无变化，则说明非keepalive报文攻击导致CPU占用率过高，请直接执行步骤（4）。
(2) 开启keepalive报文的快速应答功能。
设备收到PPP用户的keepalive请求报文后会上送CPU处理，流量较大时需要消耗较多的CPU资源。如果设备遭受攻击，易出现CPU处理能力不足，产生拒绝服务，成为攻击者的目标。
开启keepalive报文的快速应答功能后，可以通过硬件识别keepalive请求报文并自动回复keepalive应答报文，从而减轻CPU的负担，避免设备成为拒绝服务攻击的目标。
为避免未开启或误关闭keepalive报文的快速应答功能，请执行以下操作：
a. 在系统视图下执行ppp keepalive fast-reply enable命令开启keepalive报文的快速应答功能（缺省情况下，该功能处于开启状态）。
b. 在用户视图下执行reset ppp packet statistics命令清除PPP协商报文统计信息。
c. 在任意视图下多次执行display ppp packet statistics命令：
- 若观察到“RECV_LCP_ECHO_REQ”字段取值缓慢增长或者基本无变化，请继续执行下一步。
- 若观察到“RECV_LCP_ECHO_REQ”字段取值不断快速增长，请直接执行步骤（4）。
(3) 查看CPU的占用率是否降低。
在任意视图下多次执行display cpu-usage命令：
¡ 若观察到CPU的占用率明显降低，且持续在80%以下，则故障排除。
¡ 若观察到CPU的占用率仍居高不下，且持续在80%以上，请继续执行下一步。
(4) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
(1) 确认是否受到keepalive报文攻击。
在UP设备上任意视图下执行display system internal ucm statistics user-detect命令查看当前设备上所有接口的UCM探测报文的统计信息。
¡ 若某接口的“RECV_PPP_ECHO_REQ”字段取值较大，且在任意视图下多次执行display system internal ucm statistics user-detect interface命令指定该接口后，观察到“RECV_PPP_ECHO_REQ”字段取值不断快速增长，请继续执行下一步。
¡ 若所有接口的“RECV_PPP_ECHO_REQ”字段取值不大，或在任意视图下多次执行display system internal ucm statistics user-detect命令后，观察到“RECV_PPP_ECHO_REQ”字段取值缓慢增长，甚至基本无变化，则说明非keepalive报文攻击导致CPU占用率过高，请直接执行步骤（4）。
(2) 开启keepalive报文的快速应答功能。
在转发与控制分离组网中，UP设备收到PPP用户的keepalive请求报文后会上送CPU处理，流量较大时需要消耗较多的CPU资源。如果UP设备遭受攻击，易出现CPU处理能力不足，产生拒绝服务，成为攻击者的目标。
开启UP设备的keepalive报文的快速应答功能后，可以通过硬件识别keepalive请求报文并自动回复keepalive应答报文，从而减轻CPU的负担，避免UP设备成为拒绝服务攻击的目标。
为避免未开启或误关闭keepalive报文的快速应答功能，请执行以下操作：
a. 在CP设备上系统视图下执行ppp keepalive fast-reply enable up-id up-id命令开启指定UP的keepalive报文的快速应答功能（缺省情况下，该功能处于开启状态）。
b. 在UP设备上用户视图下执行reset system internal ucm statistics user-detect interface命令清除步骤(1)中观察到的“RECV_PPP_ECHO_REQ”字段取值不断快速增长的接口的UCM探测报文的统计信息。
c. 在UP设备上任意视图下多次执行display system internal ucm statistics user-detect interface命令查看步骤(1)中观察到的“RECV_PPP_ECHO_REQ”字段取值不断快速增长的接口的UCM探测报文的统计信息：
- 若观察到“RECV_PPP_ECHO_REQ”字段取值缓慢增长或者基本无变化，请继续执行下一步。
- 若观察到“RECV_PPP_ECHO_REQ”字段取值不断快速增长，请直接执行步骤（4）。
(3) 查看CPU的占用率是否降低。
在UP设备的任意视图下多次执行display cpu-usage命令：
¡ 若观察到CPU的占用率明显降低，且持续在80%以下，则故障排除。
¡ 若观察到CPU的占用率仍居高不下，且持续在80%以上，请继续执行下一步。
(4) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
· hh3cEntityExtCpuUsageThresholdNotfication
· hh3cEntityExtCpuUsageThresholdRecover
· hh3cCpuUsageSevereNotification
· hh3cCpuUsageSevereRecoverNotification
· hh3cCpuUsageMinorNotification
· hh3cCpuUsageMinorRecoverNotification
· DIAG/5/CPU_MINOR_RECOVERY
· DIAG/4/CPU_MINOR_THRESHOLD
· DIAG/5/CPU_SEVERE_RECOVERY
· DIAG/3/CPU_SEVERE_THRESHOLD
PPP用户连续多次认证失败未被静默。
本类故障的常见原因主要包括：
· 未开启或者误关闭PPP用户静默功能。
· 用户虽有认证失败记录但尚未达到静默条件。
· 某些进程发生过异常导致PPP静默功能无法正常工作。
本类故障的诊断流程如图10-5所示。
图10-5 PPP用户连续多次认证失败未被静默
(1) 确认是否开启PPP静默功能。
在设备上任意视图下执行display current-configuration命令查看当前设备的运行配置文件，并参照如下原则确认当前设备是否已开启PPP静默功能。
¡ 若运行配置文件中查询不到如下PPP静默功能的配置命令，则表示PPP静默功能采用了缺省配置。
PPP静默功能的配置命令如下：
- ppp authentication chasten auth-failure auth-period blocking-period命令。（缺省情况下，PPP用户在60秒内连续认证失败次数达到6次时，将被静默300秒）
- ppp authentication chasten per-mac [ multi-sessions ] auth-failure auth-period blocking-period命令。（缺省情况下，PPP用户在60秒内连续认证失败次数达到6次时，将被静默300秒）
上述命令的详细介绍，请参见产品PPP命令参考。
¡ 若运行配置文件中可以查询到上述PPP静默功能的配置命令，则表示PPP静默功能已开启。
¡ 若运行配置文件中可以查询到如下PPP静默功能的undo命令，则表示PPP静默功能已关闭。
- undo ppp authentication chasten
- undo authentication chasten per-mac
根据PPP静默功能是否开启的确认结论，进行如下处理：
¡ 若未开启PPP静默功能，请参照产品PPP配置指导开启PPP静默功能。
¡ 若已开启PPP静默功能，请继续执行下一步。
(2) 查看设备上是否存用户的认证失败记录信息。
在设备上任意视图下分别执行display ppp chasten user auth-failed命令和display ppp chasten per-mac auth-failed命令查看是否存在用户的认证失败记录。
¡ 若任一存在，则说明用户虽有认证失败记录但尚未达到静默条件，故设备未对用户进行静默处理。
¡ 若两者都不存在，请继续执行下一步。
(3) 查看设备上是否存用户的静默表项。
在设备上任意视图下分别执行display ppp chasten user blocked命令和display ppp chasten per-mac blocked命令查看是否存在用户的静默表项。
¡ 若任一存在，则说明用户达到静默条件，已被静默处理。
¡ 若两者都不存在，请继续执行下一步。
(4) 重新配置PPP静默功能。
特殊情况下，因某些进程发生过异常，可能导致PPP静默功能无法正常工作。为排除上述原因，请执行以下操作：
a. 在系统视图下分别执行以下命令关闭PPP用户静默功能。
- undo ppp authentication chasten命令。
- undo authentication chasten per-mac命令。
b. 请参照产品PPP配置指导，并根据现网实际需要在系统视图下选择执行以下命令重新配置PPP静默功能。
- ppp authentication chasten auth-failure auth-period blocking-period命令。（缺省情况下，PPP用户在60秒内连续认证失败次数达到6次时，将被静默300秒）
- ppp authentication chasten per-mac [ multi-sessions ] auth-failure auth-period blocking-period命令。（缺省情况下，PPP用户在60秒内连续认证失败次数达到6次时，将被静默300秒）
c. 测试静默功能是否正常。
在不达到静默条件的情况下，让某PPP用户使用错误的用户名/密码连续认证失败几次后，重复执行步骤（2），确认是否可以查看到该用户的认证失败记录：
- 若是，则让用户继续使用错误的用户名/密码连续认证失败多次，并在失败次数达到静默条件后，重复执行步骤（3），确认是否可以查看到该用户的静默表项。若是，则表示静默功能正常；若否，请继续执行下一步。
- 若否，请继续执行下一步。
(5) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
(1) 确认是否开启PPP静默功能。
在CP设备上任意视图下执行display current-configuration命令查看当前设备的运行配置文件，并参照如下原则确认当前设备是否已开启PPP静默功能。
¡ 若运行配置文件中查询不到如下PPP静默功能的配置命令，则表示PPP静默功能采用了缺省配置。
PPP静默功能的配置命令如下：
- ppp authentication chasten auth-failure auth-period blocking-period命令。（缺省情况下，PPP用户在60秒内连续认证失败次数达到6次时，将被静默300秒）
- ppp authentication chasten per-mac [ multi-sessions ] auth-failure auth-period blocking-period命令。（缺省情况下，PPP用户在60秒内连续认证失败次数达到6次时，将被静默300秒）
上述命令的详细介绍，请参见产品PPP命令参考。
¡ 若运行配置文件中可以查询到上述PPP静默功能的配置命令，则表示PPP静默功能已开启。
¡ 若运行配置文件中可以查询到如下PPP静默功能的undo命令，则表示PPP静默功能已关闭。
- undo ppp authentication chasten
- undo authentication chasten per-mac
根据PPP静默功能是否开启的确认结论，进行如下处理：
¡ 若未开启PPP静默功能，请参照产品PPP配置指导开启PPP静默功能。
¡ 若已开启PPP静默功能，请继续执行下一步。
(2) 查看CP设备上是否存用户的认证失败记录信息。
在CP设备上任意视图下分别执行display ppp chasten user auth-failed命令和display ppp chasten per-mac auth-failed命令查看是否存在用户的认证失败记录。
¡ 若任一存在，则说明用户虽有认证失败记录但尚未达到静默条件，故CP设备未对用户进行静默处理。
¡ 若两者都不存在，请继续执行下一步。
(3) 查看CP设备上是否存用户的静默表项。
在CP设备上任意视图下分别执行display ppp chasten user blocked命令和display ppp chasten per-mac blocked命令查看是否存在用户的静默表项。
¡ 若任一存在，则说明用户达到静默条件，已被静默处理。
¡ 若两者都不存在，请继续执行下一步。
(4) 重新配置PPP静默功能。
特殊情况下，因某些进程发生过异常，可能导致PPP静默功能无法正常工作。为排除上述原因，请在CP设备上执行以下操作：
a. 在系统视图下分别执行以下命令关闭PPP用户静默功能。
- undo ppp authentication chasten命令。
- undo authentication chasten per-mac命令。
b. 请参照产品PPP配置指导，并根据现网实际需要在系统视图下选择执行以下命令重新配置PPP静默功能。
- ppp authentication chasten auth-failure auth-period blocking-period命令。（缺省情况下，PPP用户在60秒内连续认证失败次数达到6次时，将被静默300秒）
- ppp authentication chasten per-mac [ multi-sessions ] auth-failure auth-period blocking-period命令。（缺省情况下，PPP用户在60秒内连续认证失败次数达到6次时，将被静默300秒）
c. 测试静默功能是否正常。
在不达到静默条件的情况下，让某PPP用户使用错误的用户名/密码连续认证失败几次后，重复执行步骤（2），确认是否可以查看到该用户的认证失败记录：
- 若是，则让用户继续使用错误的用户名/密码连续认证失败多次，并在失败次数达到静默条件后，重复执行步骤（3），确认是否可以查看到该用户的静默表项。若是，则表示静默功能正常；若否，请继续执行下一步。
- 若否，请继续执行下一步。
(5) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
无
无
设备未对频繁上下线的PPPoE用户，或通过PPPoE协议报文发起攻击的非法PPPoE用户进行静默处理。
本类故障的常见原因主要包括：
· 未开启或者误关闭PPPoE用户静默功能。
· 某些进程发生过异常导致PPPoE静默功能无法正常工作。
图10-6 用户级PPPoE防攻击失效（一体化场景）
图10-7 用户级PPPoE防攻击失效（转控分离场景）
(1) 确认是否开启PPPoE静默功能。
在设备上任意视图下执行display pppoe-server chasten configuration命令，并参照表10-1确认是否已开启PPPoE静默功能。
# 显示全局PPPoE静默功能的配置信息和所有接口上PPPoE静默功能的配置信息。
<Sysname> display pppoe-server chasten configuration
Global configuration：
Method: MAC Quickoffline: Y
Multi-sessions-permac: Y Requests: 6
Request-period(S): 60 Blocking-period(S): 300
Global configuration：
Method: Option105 Quickoffline: N
Multi-sessions-permac: Y Requests: 6
Request-period(S): 60 Blocking-period(S): 300
Interface: XGE3/1/1
Method: MAC Quickoffline: Y
Multi-sessions-permac: Y Requests: 6
Request-period(S): 60 Blocking-period(S): 300
Interface: XGE3/1/2
Method: Option105 Quickoffline: N
Multi-sessions-permac: N Requests: 10
Request-period(S): 100 Blocking-period(S): 1000
表10-1 display pppoe-server chasten configuration命令显示信息描述表
|
字段 |
描述 |
|
Global configuration |
全局静默功能的配置信息 |
|
Interface |
指定接口上静默功能的配置信息 |
|
Method |
静默功能的检测方式，取值包括： · MAC：表示基于MAC地址的PPPoE用户静默功能 · Option105：表示基于Option 105的PPPoE用户静默功能 |
|
Quickoffline |
静默类型，取值包括： · Y：表示用户因在检测周期内、上线后立即下线的次数达到指定次数被静默 · N：表示用户因在检测周期内、请求连接的次数达到指定次数被静默 |
|
Multi-sessions-permac |
基于MAC地址对用户进行静默检测时，是否允许单个用户建立多个PPPoE会话，取值包括： · Y：允许 · N：不允许 |
|
Requests |
表示PPPoE请求连接的次数 |
|
Request-period(S) |
表示静默功能的检测周期，单位为秒 |
|
Blocking-period(S) |
表示对PPPoE用户进行静默的时长，单位为秒 |
¡ 若未开启PPPoE静默功能，请参照产品PPPoE配置指导开启PPPoE静默功能。
¡ 若已开启PPPoE静默功能，请继续执行下一步。
(2) 查看设备上是否存用户的静默表项。
在设备上任意视图下display pppoe-server chasten user命令查看是否存在用户的静默表项。
¡ 若存在，则说明该用户达到静默条件，已被静默处理。
¡ 若不存在，请继续执行下一步。
(3) 重新配置PPPoE静默功能。
特殊情况下，因某些进程发生过异常，可能导致PPPoE静默功能无法正常工作。为排除上述原因，请执行以下操作：
a. 在设备上分别执行以下命令关闭PPPoE用户静默功能
- 分别在系统视图和PPPoE用户接入接口视图下执行undo pppoe-server connection chasten命令。
- 分别在系统视图和PPPoE用户接入接口视图下执行undo pppoe-server connection chasten quickoffline命令。
- 分别在系统视图和PPPoE用户接入接口视图下执行undo pppoe-server connection chasten option105命令。
- 分别在系统视图和PPPoE用户接入接口视图下执行undo pppoe-server connection chasten option105 quickoffline命令。
b. 请参照产品PPPoE配置指导，并根据现网实际需要在设备上选择执行以下命令重新配置PPPoE静默功能。
（基于MAC地址的PPPoE静默功能，如下）
· 您既可在系统视图下配置本命令也可在接口视图下配置本命令，前者对所有PPPoE用户生效，后者只对通过该接口接入的PPPoE用户生效。如果在两个视图下都配置本命令，则先达到静默条件的命令生效。
· pppoe-server connection chasten命令根据配置中是否指定quickoffline参数来唯一标识一条有效配置。即设备仅允许同时存在一条带quickoffline参数的配置和不带quickoffline参数的配置，且二者同时生效。例如，当设备中已存在一条带quickoffline参数的配置时，如再配置一条带quickoffline参数的配置，后者将覆盖前者。
- 在系统视图下执行pppoe-server connection chasten [ quickoffline ] [ multi-sessions-permac ] requests request-period blocking-period命令。（缺省情况下，基于MAC地址的PPPoE用户在60秒内连续请求连接次数达到6次时，将被静默300秒）
- 在PPPoE用户接入接口视图下执行pppoe-server connection chasten [ quickoffline ] [ multi-sessions-permac ] requests request-period blocking-period命令。（缺省情况下，该功能处于关闭状态）
（基于Option 105的PPPoE静默功能，如下）
· 您既可在系统视图下配置本命令也可在接口视图下配置本命令，前者对所有PPPoE用户生效，后者只对通过该接口接入的PPPoE用户生效。如果在两个视图下都配置本命令，则先达到静默条件的命令生效。
· pppoe-server connection chasten option105命令根据配置中是否指定quickoffline参数来唯一标识一条有效配置。即设备仅允许同时存在一条带quickoffline参数的配置和不带quickoffline参数的配置，且二者同时生效。例如，当设备中已存在一条带quickoffline参数的配置时，如再配置一条带quickoffline参数的配置，后者将覆盖前者。
- 在系统视图下执行pppoe-server connection chasten option105 [ quickoffline ] requests request-period blocking-period命令。（缺省情况下，该功能处于关闭状态）
- 在PPPoE用户接入接口视图下执行pppoe-server connection chasten option105 [ quickoffline ] requests request-period blocking-period命令。（缺省情况下，该功能处于关闭状态）
c. 测试静默功能是否正常
让某PPPoE用户频繁上下线多次，并在次数达到静默条件后，重复执行步骤（2），确认是否可以查看到该用户的静默表项：
- 若是，则表示静默功能正常。
- 若否，请继续执行下一步。
(4) 收集PADI硬件资源信息。
在Probe视图下执行display hardware internal pppoe padi resource命令收集设备当前PADI硬件资源信息，然后继续执行下一步。
(5) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
(1) 确认是否开启PPPoE静默功能。
在CP设备上任意视图下执行display pppoe-server chasten configuration命令，并参照表10-2确认是否已开启PPPoE静默功能。
# 显示全局PPPoE静默功能的配置信息和所有接口上PPPoE静默功能的配置信息。
<Sysname> display pppoe-server chasten configuration
Global configuration：
Method: MAC Quickoffline: Y
Multi-sessions-permac: Y Requests: 6
Request-period(S): 60 Blocking-period(S): 300
Global configuration：
Method: Option105 Quickoffline: N
Multi-sessions-permac: Y Requests: 6
Request-period(S): 60 Blocking-period(S): 300
Interface: R-XGE1024/1/1/0
Method: MAC Quickoffline: Y
Multi-sessions-permac: Y Requests: 6
Request-period(S): 60 Blocking-period(S): 300
Interface: R-XGE1024/1/2/0
Method: Option105 Quickoffline: N
Multi-sessions-permac: N Requests: 10
Request-period(S): 100 Blocking-period(S): 1000
表10-2 display pppoe-server chasten configuration命令显示信息描述表
|
字段 |
描述 |
|
Global configuration |
全局静默功能的配置信息 |
|
Interface |
指定接口上静默功能的配置信息 |
|
Method |
静默功能的检测方式，取值包括： · MAC：表示基于MAC地址的PPPoE用户静默功能 · Option105：表示基于Option 105的PPPoE用户静默功能 |
|
Quickoffline |
静默类型，取值包括： · Y：表示用户因在检测周期内、上线后立即下线的次数达到指定次数被静默 · N：表示用户因在检测周期内、请求连接的次数达到指定次数被静默 |
|
Multi-sessions-permac |
基于MAC地址对用户进行静默检测时，是否允许单个用户建立多个PPPoE会话，取值包括： · Y：允许 · N：不允许 |
|
Requests |
表示PPPoE请求连接的次数 |
|
Request-period(S) |
表示静默功能的检测周期，单位为秒 |
|
Blocking-period(S) |
表示对PPPoE用户进行静默的时长，单位为秒 |
¡ 若未开启PPPoE静默功能，请参照产品PPPoE配置指导开启PPPoE静默功能。
¡ 若已开启PPPoE静默功能，请继续执行下一步。
(2) 查看CP设备上是否存用户的静默表项。
在CP设备上任意视图下display pppoe-server chasten user命令查看是否存在用户的静默表项。
¡ 若存在，则说明该用户达到静默条件，已被静默处理。
¡ 若不存在，请继续执行下一步。
(3) 重新配置PPPoE静默功能。
特殊情况下，因某些进程发生过异常，可能导致PPPoE静默功能无法正常工作。为排除上述原因，请在CP设备上执行以下操作：
a. 在CP设备上分别执行以下命令关闭PPPoE用户静默功能
- 分别在系统视图和PPPoE用户接入接口视图下执行undo pppoe-server connection chasten命令。
- 分别在系统视图和PPPoE用户接入接口视图下执行undo pppoe-server connection chasten quickoffline命令。
- 分别在系统视图和PPPoE用户接入接口视图下执行undo pppoe-server connection chasten option105命令。
- 分别在系统视图和PPPoE用户接入接口视图下执行undo pppoe-server connection chasten option105 quickoffline命令。
b. 请参照产品PPPoE配置指导，并根据现网实际需要在CP设备上选择执行以下命令重新配置PPPoE静默功能。
（基于MAC地址的PPPoE静默功能，如下）
· 您既可在系统视图下配置本命令也可在接口视图下配置本命令，前者对所有PPPoE用户生效，后者只对通过该接口接入的PPPoE用户生效。如果在两个视图下都配置本命令，则先达到静默条件的命令生效。
· pppoe-server connection chasten命令根据配置中是否指定quickoffline参数来唯一标识一条有效配置。即设备仅允许同时存在一条带quickoffline参数的配置和不带quickoffline参数的配置，且二者同时生效。例如，当设备中已存在一条带quickoffline参数的配置时，如再配置一条带quickoffline参数的配置，后者将覆盖前者。
- 在系统视图下执行pppoe-server connection chasten [ quickoffline ] [ multi-sessions-permac ] requests request-period blocking-period命令。（缺省情况下，基于MAC地址的PPPoE用户在60秒内连续请求连接次数达到6次时，将被静默300秒）
- 在PPPoE用户接入接口视图下执行pppoe-server connection chasten [ quickoffline ] [ multi-sessions-permac ] requests request-period blocking-period命令。（缺省情况下，该功能处于关闭状态）
（基于Option 105的PPPoE静默功能，如下）
· 您既可在系统视图下配置本命令也可在接口视图下配置本命令，前者对所有PPPoE用户生效，后者只对通过该接口接入的PPPoE用户生效。如果在两个视图下都配置本命令，则先达到静默条件的命令生效。
· pppoe-server connection chasten option105命令根据配置中是否指定quickoffline参数来唯一标识一条有效配置。即设备仅允许同时存在一条带quickoffline参数的配置和不带quickoffline参数的配置，且二者同时生效。例如，当设备中已存在一条带quickoffline参数的配置时，如再配置一条带quickoffline参数的配置，后者将覆盖前者。
- 在系统视图下执行pppoe-server connection chasten option105 [ quickoffline ] requests request-period blocking-period命令。（缺省情况下，该功能处于关闭状态）
- 在PPPoE用户接入接口视图下执行pppoe-server connection chasten option105 [ quickoffline ] requests request-period blocking-period命令。（缺省情况下，该功能处于关闭状态）
c. 测试静默功能是否正常。
让某PPPoE用户频繁上下线多次，并在次数达到静默条件后，重复执行步骤（2），确认是否可以查看到该用户的静默表项：
- 若是，则表示静默功能正常。
- 若否，请继续执行下一步。
(4) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
无
无
设备未对有大量PPPoE用户频繁上下线的接入接口，或者非法用户通过PPPoE协议报文发起攻击的目标接入接口进行限速处理。
本类故障的常见原因主要包括：
· 未开启或者误关闭PPPoE协议报文防攻击功能。
· 某些进程发生过异常导致PPPoE协议报文防攻击功能无法正常工作。
图10-8 接口级PPPoE防攻击功能失效（一体化场景）
图10-9 接口级PPPoE防攻击功能失效（转控分离场景）
(1) 确认是否开启PPPoE协议报文防攻击功能。
在设备上任意视图下执行display pppoe-server chasten per-interface configuration命令，并参照表10-3确认是否已开启PPPoE协议报文防攻击功能。
# 显示所有接口的PPPoE协议报文防攻击功能的配置信息。
<Sysname> display pppoe-server chasten per-interface configuration
Interface Number Interval(S) Rate-limit-period(S)
XGE3/1/1 6 60 300
XGE3/1/2 10 100 1000
表10-3 display pppoe-server chasten per-interface configuration命令显示信息描述表
|
字段 |
描述 |
|
Interface |
接口名称 |
|
Number |
表示收到PPPoE协议报文的个数 |
|
Interval(S) |
表示PPPoE协议报文防攻击功能的检测周期，单位为秒 |
|
Rate-limit-period(S) |
表示对PPPoE协议报文进行限速的时长，单位为秒 |
¡ 若未开启PPPoE协议报文防攻击功能，请参照产品PPPoE配置指导开启PPPoE协议报文防攻击功能。
¡ 若已开启PPPoE协议报文防攻击功能，请继续执行下一步。
(2) 查看设备上是否存接口的PPPoE防攻击表项。
在设备上任意视图下执行display pppoe-server chasten per-interface命令查看指定接口上是否存在防攻击表项。
¡ 若存在，则说明该接口达到PPPoE协议报文防攻击条件，在软件层面已被限速处理。请继续在Probe视图下执行display hardware internal pppoe padi if-chasten intf命令查看相同指定接口上否存在防攻击表项。
- 若存在，则说明该接口在硬件驱动层面也已被限速处理，即该接口在软硬件层面均已被限速处理，接口级防攻击功能工作正常。
- 若不存在，请继续执行下一步。
¡ 若不存在，请继续执行下一步。
(3) 重新配置PPPoE协议报文防攻击功能。
特殊情况下，因某些进程发生过异常，可能导致PPPoE协议报文防攻击功能无法正常工作。为排除上述原因，请执行以下操作：
a. 分别在系统视图和PPPoE用户接入接口视图下执行undo pppoe-server connection chasten per-interface命令关闭PPPoE协议报文防攻击功能。
b. 请参照产品PPPoE配置指导，并根据现网实际需要在设备上选择执行以下命令重新配置PPPoE协议报文防攻击功能。
您既可在系统视图下配置本命令也可在接口视图下配置本命令，前者对所有接口生效，后者只对该接口生效。如果在两个视图下都配置本命令，仅接口下的配置生效。
- 在系统视图下执行pppoe-server connection chasten per-interface number interval rate-limit-period命令。（缺省情况下，该功能处于关闭状态）
- 在PPPoE用户接入接口视图下执行pppoe-server connection chasten per-interface number interval rate-limit-period命令。（缺省情况下，该功能处于关闭状态）
c. 测试PPPoE协议报文防攻击功能是否正常。
让某接口下的PPPoE用户频繁上下线几次达到PPPoE协议报文防攻击条件后，重复执行步骤（2），确认是否可以查看到该接口的防攻击表项：
- 若是，则表示PPPoE协议报文防攻击功能正常。
- 若否，请继续执行下一步。
(4) 收集ACL和PADI硬件资源信息。
¡ 在任意视图下执行display qos-acl resource命令收集设备当前ACL硬件资源信息。
¡ 在Probe视图下执行display hardware internal pppoe padi resource命令收集设备当前PADI硬件资源信息，然后继续执行下一步。
(5) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
(1) 确认是否开启PPPoE协议报文防攻击功能。
在CP设备上任意视图下执行display pppoe-server chasten per-interface configuration命令，并参照确认是否已开启PPPoE协议报文防攻击功能。
# 显示所有接口的PPPoE协议报文防攻击功能的配置信息。
<Sysname> display pppoe-server chasten per-interface configuration
Interface Number Interval(S) Rate-limit-period(S)
R-XGE1024/1/1/0 6 60 300
R-XGE1024/1/2/0 10 100 1000
表10-4 display pppoe-server chasten per-interface configuration命令显示信息描述表
|
字段 |
描述 |
|
Interface |
接口名称 |
|
Number |
表示收到PPPoE协议报文的个数 |
|
Interval(S) |
表示PPPoE协议报文防攻击功能的检测周期，单位为秒 |
|
Rate-limit-period(S) |
表示对PPPoE协议报文进行限速的时长，单位为秒 |
¡ 若未开启PPPoE协议报文防攻击功能，请参照产品PPPoE配置指导开启PPPoE协议报文防攻击功能。
¡ 若已开启PPPoE协议报文防攻击功能，请继续执行下一步。
(2) 查看设备上是否存接口的PPPoE防攻击表项。
在CP设备上任意视图下执行display pppoe-server chasten per-interface命令查看指定接口上是否存在防攻击表项。
¡ 若存在，则说明该接口达到PPPoE协议报文防攻击条件，在CP设备的软件层面已被限速处理。请继续在UP设备上Probe视图下执行display hardware internal pppoe padi if-chasten intf命令查看和CP设备上远端接口对应的指定接口上是否存在防攻击表项。
- 若存在，则说明该接口在UP设备的硬件驱动层面也已被限速处理，即该接口在软硬件层面均已被限速处理，接口级防攻击功能工作正常。
- 若不存在，请继续执行下一步。
¡ 若不存在，请继续执行下一步。
(3) 重新配置PPPoE协议报文防攻击功能。
特殊情况下，因某些进程发生过异常，可能导致PPPoE协议报文防攻击功能无法正常工作。为排除上述原因，请执行以下操作：
a. 分别在系统视图和PPPoE用户接入接口视图下执行undo pppoe-server connection chasten per-interface命令关闭PPPoE协议报文防攻击功能。
b. 请参照产品PPPoE配置指导，并根据现网实际需要在设备上选择执行以下命令重新配置PPPoE协议报文防攻击功能。
您既可在系统视图下配置本命令也可在接口视图下配置本命令，前者对所有接口生效，后者只对该接口生效。如果在两个视图下都配置本命令，仅接口下的配置生效。
- 在系统视图下执行pppoe-server connection chasten per-interface number interval rate-limit-period命令。（缺省情况下，该功能处于关闭状态）
- 在PPPoE用户接入接口视图下执行pppoe-server connection chasten per-interface number interval rate-limit-period命令。（缺省情况下，该功能处于关闭状态）
c. 测试PPPoE协议报文防攻击功能是否正常。
让某接口下的PPPoE用户频繁上下线几次达到PPPoE协议报文防攻击条件后，重复执行步骤（2），确认是否可以查看到该接口的防攻击表项：
- 若是，则表示PPPoE协议报文防攻击功能正常。
- 若否，请继续执行下一步。
(4) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
无
无
如果用户上线失败，请执行display aaa online-fail-record命令查看用户上线失败原因。
例如，查询用户名为001094500020的用户上线失败原因。
<Sysname> display aaa online-fail-record username 001094500020
Total count: 116
Username: 001094500020
Domain: dm1
MAC address: 0010-9450-0020
Access type: IPoE
Access UP ID: 1353
Access interface: XGE3/1/1
SVLAN/CVLAN: -/-
IP address: -
IPv6 address: -
Online request time: 2021/08/15 07:42:15
Online failure reason: DHCP with server no response
根据Online failure reason字段提示信息，查看“11.2 用户上线失败原因和异常下线原因”对应原因码的故障处理方法。
若通过以上方法无法查到用户上线失败原因，可能是上线流程未走到AAA认证阶段或由于用户与设备间链路故障导致，此时可通过trace access-user命令（该命令的详细介绍请参见产品手册“BRAS业务命令参考”中的“UCM”）排查上线流程走到哪个阶段出现故障，以及根据实际组网情况排查链路故障。
如果用户上线后异常下线，请执行display aaa abnormal-offline-record命令和display aaa offline-record命令查看用户下线原因。
例如，查询用户名为001094500021的用户下线原因。
<Sysname> display aaa offline-record username 001094500021
Total count: 4
Username: 001094500021
Domain: dm1
MAC address: 0010-9450-0021
Access type: IPoE
Access UP ID: 1354
Access interface: XGE3/1/1
SVLAN/CVLAN: -/-
IP address: 9.0.3.1
IPv6 address: -
Online request time: 2021/08/15 08:05:17
Offline time: 2021/08/15 08:09:08
Offline reason: DHCP release
根据Offline reason字段提示信息，查看“11.2 用户上线失败原因和异常下线原因”对应原因码的故障处理方法。
若通过以上方法无法查到用户异常下线原因，可能由于用户与设备间链路故障导致，此时需要根据实际组网情况排查链路故障。
AAA domain do not exist
认证域下允许上线的用户数达到最大值。
在ISP域视图下执行access-limit命令扩大用户数上限，或者在用户视图下执行free命令强制其它在线用户下线。
AAA domain do not exist
用户的认证域不存在。
执行display domain命令检查用户使用的认证域在设备上是否存在，如果不存在，需要通过domain name命令创建对应的ISP域，并正确配置域下的认证、授权、计费方案。
AAA forces the PPPoEA user offline
AAA服务器强制PPPoE代拨用户下线。
请联系AAA服务器管理员，确认强制下线的原因。
AAA with Authentication no response
设备没有收到服务器的认证响应报文。
(1) 检查认证服务器上是否添加了接入设备的IP地址或者添加的IP地址不正确，确保服务器上添加的接入设备的IP地址与设备发送认证请求报文的源IP地址相同。
(2) 检查设备和计费服务器之间的网络是否存在问题，确保认证服务器可达。
AAA with authorization data error
设备解析服务器下发的授权信息失败。
(1) 打开RADIUS报文调试信息开关，查看授权的属性内容。
(2) 确保服务器端下发的授权属性准确。
AAA with flow limit
上线用户流量耗尽导致下线。
属于正常现象，无需处理。
AAA with memory alloc fail
分配内存失败导致用户无法上线。
(1) 通过display memory命令查看设备的内存使用情况，确认设备可用内存是否不足。
(2) 通过display memory-threshold命令查看是否有内存门限告警，结合显示信息中的“Current free-memory state:”字段判断内存告警状态。
(3) 按需清理内存，例如减少在线用户数或者关闭一些不需要的业务。
AAA with message send fail
设备向服务器发送报文失败。
检查设备向服务器发送报文的接口是否UP等。确保接口UP后，如果故障仍然无法排除，请联系技术支持人员。
AAA with radius decode fail
设备解析收到的RADIUS报文时，发生解析错误问题。
打开设备上的RADIUS报文调试信息开关，收集打印的调试信息，联系技术支持人员检查收到RADIUS报文格式是否正确。
AAA with realtime accounting fail
实时计费失败导致用户下线。
(1) 检查设备与计费服务器的共享密钥是否不匹配。若不匹配，请在对应的计费方案下设置与服务器匹配的共享密钥。
(2) 检查用户的认证域下是否配置了accounting update-fail [ max-times max-times ] offline命令。缺省情况下，如果用户实时计费失败，会继续保持在线。若不希望用户实时计费失败后下线，请在认证域下配置accounting update-fail online命令或者执行undo accounting update-fail命令恢复缺省情况。
(3) 如果故障仍然未能排除，请联系技术支持人员。
AAA with start accounting fail
用户上线计费失败。
(1) 检查认证域下的计费配置，确保计费方案配置正确。
(2) 检查用户的认证域下是否配置了accounting start-fail offline命令。缺省情况下，如果用户计费开始失败，会继续保持在线。若不希望用户在计费开始失败后下线，请在认证域下配置accounting start-fail online命令或者执行undo accounting start-fail命令恢复缺省情况。
AAA with timer create fail
设备上的AAA定时器创建失败。
(1) 通过display memory命令查看设备的内存使用情况，确认设备可用内存是否不足。
(2) 通过display memory-threshold命令查看是否有内存门限告警，结合显示信息中的“Current free-memory state:”字段判断内存告警状态。
(3) 按需清理内存，例如减少在线用户数或者关闭一些不需要的业务。
AAA with user information err
用户进行LDAP认证时，未提供必须的用户名。
请用户修改上线使用的用户名后，重新尝试上线。
access-block
在转发与控制分离组网中，上线用户的接入UP被配置了禁止UP接入新用户。
在上线用户接入UP的UP管理视图下执行undo access-block命令取消禁止UP接入新用户配置。例如：
<Sysname> system-view
[Sysname] up-manage id 1024
[Sysname-up-manage-1024] undo access-block
Add nat user data fail(IP Alloc Fail)
用户流量匹配到的NAT配置中，NAT地址组的公网地址资源不足。
NAT地址组中的公网地址资源获取方式有两种：
· 通过在NAT地址组视图下使用address命令添加地址资源。当地址资源不足时，请通过address命令增加地址资源。例如：
<Sysname> system-view
[Sysname] nat address-group 1
[Sysname-address-group-1] address 202.1.1.1 202.1.1.2
· NAT地址组与全局NAT地址池绑定，NAT地址组从全局NAT地址池中获取地址资源。
¡ 对于静态全局NAT地址池，当地址资源不足时，请增加全局NAT地址池中的地址资源。例如：
<Sysname> system-view
[Sysname] nat ip-pool pool1
[Sysname-nat-ip-pool-pool1] section 0 200.1.1.1 mask 24
¡ 对于动态全局NAT地址池，当NAT地址组的地址资源不足时，UP上的动态全局NAT地址池向CP上NAT-CENTRAL类型的IP地址池申请地址。如果CP无可用地址分配给UP，则会导致NAT地址组无可用地址进行分配。对于这种情况，请增加CP上NAT-CENTRAL类型的IP地址池的公网地址资源，例如：
<Sysname> system-view
[Sysname] ip pool 1 nat-central
[Sysname-ip-pool-1] network range 202.1.1.1 202.1.1.2
Add no backlist no Sub IfMaster
在UP备份组网中，发生了主备切换，当前配置备接口为实际运行主接口；配置主接口实际为运行备接口。这种情况下，用户通过配置备接口（运行主接口）的子接口接入，但是设备查找不到对应配置主接口（运行备接口）的子接口，导致用户无法上线。
检查配置主接口的子接口能否终结用户携带的VLAN Tag，例如配置主接口的子接口上只配置了支持终结携带VLAN 3 Tag的报文，未配置支持终结携带VLAN 2 Tag报文，但是用户携带的VLAN Tag是2，此时可以在配置主的子接口上增加如下支持终结携带VLAN 2 Tag报文的配置后再次尝试上线：
<Sysname> system-view
[Sysname] interface ten-gigabitethernet 3/1/1.2
[Sysname-Ten-GigabitEthernet3/1/1.2] vlan-type dot1q vid 2
After the IPoE Web user has come online in postauth by inheriting PPPoE user info, the BRAS rejects Web access requests from the user
在IPoE Web用户已经通过继承PPPoE用户信息在后域上线的情况下，当BRAS设备收到该IPoE用户的Web上线请求时，直接拒绝Web上线请求，该用户继续使用继承的PPPoE用户信息在后域保持在线。
属于正常情况，无需处理。
All prefix ranges in the DHCPv6 address pool group have been allocated
ODAP类型的IPv6地址池组中无空闲前缀段可分配。
创建新的ODAP类型的IPv6地址池，引用可分配的前缀池，将地址池通过pool命令添加到IPv6地址池组中。
All prefix ranges in the DHCPv6 address pool have been allocated
ODAP类型的IPv6地址池中无空闲前缀段可分配。
建议用户从其他接口重新上线，DHCP服务器将为用户授权新地址池。若DHCP服务器上无新地址池可授权，需要重新创建地址池。
All subnets in the DHCP address pool group have been allocated
ODAP类型的IP地址池组中无空闲子网段可分配。
· 在IP地址池组中的地址池下通过network secondary命令创建新的从网段，利用新从网段分配空闲子网段。
· 创建新的ODAP类型的IP地址池，配置可分配地址网段，将地址池通过pool命令添加到IP地址池组中。
All subnets in the DHCP address pool have been allocated
ODAP类型的IP地址池中无空闲子网段可分配。
· 在IP地址池下通过network secondary命令创建新的从网段，利用新从网段分配空闲子网段。
· 用户可以从其他接口重新上线，DHCP服务器将为用户授权新地址池。若DHCP服务器上无新地址池可授权，需要重新创建地址池。
All subnets in the DHCPv6 address pool group have been allocated
ODAP类型的IPv6地址池组中无空闲子网段可分配。
创建新的ODAP类型的IPv6地址池，配置可分配地址网段，将地址池通过pool命令添加到IPv6地址池组中。
All subnets in the DHCPv6 address pool have been allocated
ODAP类型的IPv6地址池中无空闲子网段可分配。
建议用户从其他接口重新上线，DHCP服务器将为用户授权新地址池。若DHCP服务器上无新地址池可授权，需要重新创建地址池。
ARP with detect fail
· 中间传输设备丢弃或者修改ARP探测报文。
· 链路故障。
· 探测报文被设备丢弃。
· 设备因接入方式、接口状态、用户信息等不正确导致丢弃报文。
查看用户上线和下线时间差，查看探测配置，执行命令trace access-user命令打开业务跟踪对象，查看报文收发情况，排查报文在哪个阶段被丢弃，并进行相应的故障处理。
Authenticate fail
本地管理类用户上线认证失败。
· 检查用户名和密码是否正确。
· 检查认证域下的认证配置，确保认证方案配置正确。
Authentication method error
· 配置的认证方法错误，比如上线静态专线但是配置的认证类型为web。
· LDAP仅支持PAP认证模式，客户端使用了非PAP认证模式。
修改配置重新触发上线。
Authorize fail
用户认证通过后，授权失败。
(1) 联系AAA服务器管理员，检查服务器上的授权属性设置是否正确，确保服务器下发的授权属性内容准确。
(2) 检查设备上对应的授权属性（例如授权ACL、VLAN）是否存在，确保用户能够获取到授权的信息。
(3) 如果故障仍然未能排除，请联系技术支持人员。
Base service address alloc failed
主业务依赖IP地址（主业务依赖的IP地址类型由ISP视图下basic-service-ip-type命令配置）分配失败，或者IP地址分配超时导致用户下线。
检查IP地址池配置是否正确，若IP地址池配置正确，请联系技术支持人员。
Cancelled PPPoE agnecy configuraton
执行undo pppoe-agency forward命令删除PPPoE代拨转发策略。
属于正常情况，无需处理。
Connect check fail
本地认证时，进程间通信异常。
请联系技术支持人员。
CP change from master to backup in cold mode
在CP灾备环境下，工作在冷备模式的主CP切换为备CP，主CP删除了其上的用户会话。
属于正常现象，无需处理。
CP send message to UP failed
在转发与控制分离组网中，CU间CUSP通道断开，导致CP向UP发送消息失败。
检查CUSP通道是否正常，若CUSP通道正常，请联系技术支持人员。
CPDR no permit users access
CP灾备组网，备CP无法接入用户。
执行display vbras-cp stable state命令查看转发与控制分离系统是否处于稳定状态，若处于非稳态，待状态稳定后让用户重新上线。
Create pppinfo failed
PPPoE通知PPP开启协商失败。
请联系技术支持人员。
CU Smoothing
· 在转发与控制分离组网中，CU正在数据平滑中，用户无法上线。
· 在转发与控制分离组网中，UP备份正在主备切换中，用户无法上线。
执行display vbras-cp stable state命令查看CUSP模块是否处于稳定状态，若处于非稳态，待CU平滑完成，UP备份切换完成后再让用户重新上线。
Cut by the AAA server
AAA服务器强制用户下线。
请联系AAA服务器管理员，确认强制下线的原因。
Cut command
管理员执行cut access-user命令强制用户下线。
属于正常现象，无需处理。
Cut command from domain
管理员在用户所属ISP域下执行state block offline命令强制用户下线。
属于正常现象，无需处理。
DHCP allocating IP from local pool failed
请求IP地址或地址网段失败。
执行命令debugging dhcp server/debugging dhcp relay/debugging dhcp-access packet命令打开服务器、中继或DHCP接入模块报文调试开关，查看报文交互流程及用户接入情况，并针对发现的问题进行相应的故障修复。若无法自行解决问题，请联系技术支持工程师。
DHCP BRAS OUT DELETE
转控分离组网，UP迁移，迁出设备上的租约及网段信息被删除。
属于正常情况，无需处理
DHCP configuration synchronization between CTRL-VM and BRAS-VM failed
转控分离组网，CTRL-VM与BRAS-VM平滑配置失败，设备上的租约及网段信息被删除。
检查并收集设备相关配置信息，联系技术支持工程师。
DHCP decline
检测到网络中可能存在IP地址冲突，客户端发送DECLINE报文拒绝租约。
正常情况下DHCP客户端会重新请求IP地址，如果始终无法获取到地址上线，请联系技术支持工程师。
DHCP free lease with command
通过reset dhcp server ip-in-use/reset ipv6 dhcp server ip-in-use/reset ipv6 dhcp server pd-in-use命令删除用户租约信息。
· 若配置了相关命令行删除用户租约，则属于正常情况，无需处理。
· 若未配置相关命令行删除用户租约，请联系技术支持工程师。
DHCP generate request pkt fail
DHCP接入用户采用松散模式重新上线，DHCP记录的地址和ARP等报文触发上线时携带的地址不一致。
联系技术支持工程师。
DHCP invalid IP pool info
地址池配置错误。
检查地址池相关配置，若无法定位错误的配置，联系技术支持工程师。
DHCP lease timeout
租约到期，删除用户租约信息。
执行命令debugging dhcp server/debugging dhcp relay/debugging dhcp-access packet命令打开服务器、中继或DHCP接入模块报文调试开关，查看用户续约报文交互流程。
· 若用户未主动续约，则属于正常下线。
· 若用户申请了续约，则需要通过以上Debug调试信息定位问题并进行故障修复。仍无法自行解决问题时，请联系技术支持工程师。
DHCP memory error
申请内存失败。
执行命令display memory查看设备内存情况，若达到内存使用上限，则待退出内存门限后重新上线；若内存未达到使用上限，则联系技术支持工程师。
DHCP packet info did not match
· DHCP中继收到DHCP服务器的应答报文后，检测到与记录的用户地址表项冲突，丢弃该应答报文，用户上线失败。
· ND RS接入用户上线，设备检查ND RS用户携带的客户端信息与授权信息不通过，用户上线失败。
联系技术支持工程师。
DHCP release
DHCP用户主动发送RELEASE报文请求下线。
属于正常情况，无需处理。
DHCP retrieved unexpected IP address
DHCP服务器无法分配客户端请求的指定IP地址。
查看DHCP服务器上地址的分配情况：
· 若客户端请求的指定地址已分配，基于客户端实现，用户自行决定是否重新申请地址。
· 若客户端请求的指定地址未分配，可能服务器状态异常，请联系技术支持工程师。
DHCP Smooth aging
DHCP租约表项被删除，UCM与DHCP信息平滑失败，删除用户。
联系技术支持工程师。
DHCP user state timeout
DHCP模块与UCM模块建立用户连接失败。
联系技术支持工程师。
DHCP VSRP status changed to Down
VSRP主设备或备用设备状态变DOWN，设备上的租约信息被删除。
· 属于正常情况，无需处理。
DHCP wait client packet timeout
DHCP客户端未响应。
执行命令debugging dhcp server/debugging dhcp relay/debugging dhcp-access packet命令打开服务器、中继或DHCP接入模块报文调试开关，查看用户上线报文交互流程。若无法自行解决问题，请联系技术支持工程师
DHCP wait up reply timeout
· UCM回复UP请求超时。
· UCM确认用户漫游身份超时。
· UCM回复用户，拒绝其以漫游身份上线。
联系技术支持工程师。
DHCP with IP address conflict
· 执行dhcp conflict-ip-address offline/ipv6 dhcp conflict-ip-address offline命令导致老用户下线。
· 用户请求的IP地址冲突。
联系技术支持工程师。
DHCP with server nak
· DHCP服务器回复NAK报文，拒绝客户端的地址申请。
· 服务器状态异常，无法给用户分配地址。
联系技术支持工程师。
DHCP with server no response
· DHCP服务未开启。
· IP地址池下未配置可分配的IP地址。
· DHCP服务器未响应，可能出现链路连接故障。
确保DHCP相关配置正确，如配置正确故障仍存在，请联系技术支持工程师。
DHCPv6 client release
DHCPv6用户主动发送RELEASE报文请求下线。
属于正常情况，无需处理。
Disable ipoe via command
接口关闭了IPoE功能。
检查用户接入接口是否开启了IPoE功能，并配置正确。
Disabled PPPoE agency
执行undo pppoe-agency bind命令关闭PPPoE代拨功能。
属于正常情况，无需处理。
Domain denied
用户上线的接口上禁止该认证域的用户上线。
检查接口上是否配置了禁止用户上线的ISP域，命令形式为aaa deny-domain isp-name。如下例所示，接口上存在禁止用户接入ISP域test的配置。
<Sysname> system-view
[Sysname] interface ten-gigabitethernet 3/1/1
[Sysname-Ten-GigabitEthernet3/1/1] display this
#
interface Ten-GigabitEthernet3/1/1
port link-mode route
aaa deny-domain test
#
如果需要取消此限制，请在接口上执行undo aaa deny-domain isp-name命令。
domain is block
用户的认证域处于阻塞状态，不允许该域下的用户请求网络服务。
检查用户的认证域下是否配置了state block offline命令，使得该域进阻塞状态后，强制用户下线。
<Sysname> system-view
[Sysname] domain name test
[Sysname-isp-test] display this
#
domain name test
state block offline
#
如果需要取消此配置，请在该域下执行undo state命令。
Dpbackup Cfg Change Offline
在转发与控制分离的UP备份组网中，UP备份策略配置变化导致用户下线。
如果是管理员已知的配置修改，则属于正常现象，无需处理，否则请排查是否存在非管理人员误操作，导致UP备份相关配置被错误修改。
Drv operation failed
用户的会话下驱动失败。
请联系技术支持人员。
Dynamic ipoe user forbidden
对于未知源IP报文触发方式，IPoE用户上线的接口上采用了matching-user模式，仅允许匹配到的静态用户、DHCP异常下线用户、漫游用户和采用松散模式上线的用户上线。
检查接口上是否存在配置ip subscriber initiator unclassified-ip enable matching-user，若存在则属性正常情况，无需处理。
Enable/disable VSRP Instance command
添加或者删除VSRP实例，触发删除已在线的老用户。
属于正常现象，无需处理。
failed to add nat user data(invalid private network address)
用户的私网地址无效。
(1) 删掉ISP域下NAT与BRAS联动的配置。例如：
<Sysname> system-view
[Sysname] domain name cgn
[Sysname-isp-cgn] undo user-address-type private-ipv4
支持BRAS联动功能的用户地址类型包括私网IP地址（private-ipv4）、私网双栈地址（private-ds）和轻量级双栈地址（ds-lite）。如果存在相关配置，请在ISP域下删除该配置。
(2) 取消负载分担用户组和NAT实例的绑定关系。例如：
<Sysname> system-view
[Sysname] domain name cgn
[Sysname-isp-cgn] undo user-group name ugrp
(3) 执行display access-user命令，检查“IP address”字段的取值。如果取值为“-”，说明用户未获取到私网地址，请检查用户上线相关配置。
failed to add nat user data(license invalid)
vBRAS设备没有安装NAT功能License。
购买并安装NAT功能License。
Failed to associate the PPPoEA user with the BRAS user
校内BRAS用户关联PPPoE代拨用户时，系统处理失败。
请联系技术支持人员。
Failed to authenticate for ldap configration changed
用户进行LDAP认证时，设备上的LDAP配置发生了改变。
执行display ldap scheme命令查看当前的LDAP配置信息，在确认当前配置准确的情况下，请用户重新尝试上线，在此期间不要修改设备上的LDAP配置。
Failed to authenticate for no ldap binding user's DN
用户进行LDAP认证时，设备无法发送查询用户DN的绑定请求。
进入对应的LDAP服务器视图，执行search-base-dn命令配置用户查询的起始DN。下例中设置的用户DN仅为示例。
<Sysname> system-view
[Sysname] ldap server ldap1
[Sysname-ldap-server-ldap1] search-base-dn dc=ldap,dc=com
Failed to come online by using CGN because service-instance-group is invalid
· NAT实例绑定的业务实例组不存在。
· NAT实例绑定的业务实例组没有关联生效的备份组。
· 如果NAT实例绑定的业务实例组不存在，请使用service-instance-group命令创建业务实例组，并通过failover-group命令将业务实例组和备份组关联。例如：
<Sysname> system-view
[Sysname] service-instance-group sgrp
[Sysname-service-instance-group-sgrp] failover-group failgrp
· 使用display failover命令查看备份组的信息，如果“Active Status”字段显示为“Initial”，说明该备份组中没有可以处理业务的节点；如果“Active Status”字段显示为“Primary”或“Secondary”，说明备份组可以正常处理业务。请将业务实例组与能够正常处理业务的备份组关联。
Failed to compose tacacs request packet
设备内存空间不足导致封装HWTACACS报文失败。
(1) 通过display memory命令查看设备的内存使用情况，确认设备可用内存是否不足。
(2) 通过display memory-threshold命令查看是否有内存门限告警，结合显示信息中的“Current free-memory state:”字段判断内存告警状态。
(3) 按需清理内存，例如减少在线用户数或者关闭一些不需要的业务。
Failed to connect with the ldap server
设备与LDAP服务器首次连接失败。
检查设备和LDAP服务器之间的链路故障问题。
Failed to connect with the tacacs server
设备与HWTACACS服务器连接失败。
检查设备和HWTACACS服务器之间的链路故障问题。
Failed to create a PPPoEA session
设备为PPPoE代拨用户创建会话失败。
请联系技术支持人员。
Failed to deliver PPPoEA user information to the kernel
PPPoE代拨用户信息下发到内核失败。
请联系技术支持人员。
Failed to encode the request packet
设备封装请求报文失败。
(1) 通过display memory命令查看设备的内存使用情况，确认设备可用内存是否不足。
(2) 通过display memory-threshold命令查看是否有内存门限告警，结合显示信息中的“Current free-memory state:”字段判断内存告警状态。
(3) 按需清理内存，例如减少在线用户数或者关闭一些不需要的业务。
Failed to fill the authentication attributes
因为存储空间不足，设备封装认证请求报文时填充属性失败。
(1) 通过display memory命令查看设备的内存使用情况，确认设备可用内存是否不足。
(2) 通过display memory-threshold命令查看是否有内存门限告警，结合显示信息中的“Current free-memory state:”字段判断内存告警状态。
(3) 按需清理内存，例如减少在线用户数或者关闭一些不需要的业务。
Failed to find AAA server
认证域下没有配置对应接入用户的认证、授权、计费方法。
在认证域下配置对应接入用户采用的认证/授权/计费方案，并确保指定的方案存在。
如下例所示，在ISP域test中配置PPP接入用户采用RADIUS认证、授权、计费。
<Sysname> system-view
[Sysname] domain name test
[Sysname-isp-test] authentication ppp radius-scheme rd1
[Sysname-isp-test] authorization ppp radius-scheme rd1
[Sysname-isp-test] accounting ppp radius-scheme rd1
Failed to find the BRAS user
PPPoE代拨用户上线过程中，对应的校内BRAS用户信息异常丢失，导致系统查找不到对应的校内BRAS用户。
请联系技术支持人员。
Failed to get NAT instance
用户上线授权的NAT实例不存在。
· 通过user-group bind nat-instance命令修改ISP域下负载分担用户组绑定的NAT实例，保证负载分担用户组绑定的NAT实例和设备上实际生效的NAT实例一致。例如：
<Sysname> system-view
[Sysname] domain name cgn
[Sysname-isp-cgn] user-group name ugrp bind nat-instance inst
· 转发与控制分离组网下，CP和UP上需要配置相同的NAT实例。例如：
CP执行如下配置后，UP需要执行相同的配置。
<Sysname> system-view
[Sysname] nat instance cgn1 id 1
Failed to get user’s DN from the ldap search result
设备未从LDAP服务器上获取到用户DN。
(1) 检查设备上对应的LDAP服务器视图下的search-base-dn配置是否准确。
(2) 联系LDAP服务器管理员，检查LDAP服务器上的用户DN设置是否正确，确保服务器上存在该用户的DN信息。
Failed to inherit user information from PPPoE
BRAS设备状态异常（比如进入内存门限等）或同MAC同VLAN的PPPoE用户状态异常。
请联系技术支持人员。
Failed to obtain the secret
用户进行LDAP认证时，未提供必须的用户密码。
请用户修改上线使用的密码后，重新尝试上线。
Failed to obtain user group information
转发与控制分离的NAT与BRAS联动场景中，ISP域视图下配置了负载分担用户组和NAT实例的绑定关系后，该域下的用户组负载分担功能会同时开启。接入用户认证上线之后，接入设备将依据以下原则将其加入一个负载分担用户组，并为其分配一个NAT实例进行NAT处理：
· 如果AAA服务器为接入用户授权了用户组，则该用户组就是用户的负载分担用户组，接入设备会根据认证域中配置的负载分担用户组与NAT实例的绑定关系为其分配一个NAT实例。如果认证域下未查询到与AAA服务器授权的用户组所绑定的NAT实例，则无NAT实例分配给该用户，用户将会下线。
· 如果AAA服务器没有给接入用户授权用户组，则接入设备将从认证域中指定的负载分担用户组中为其选择一个用户组，并将与其绑定的NAT实例分配给该用户。选择负载分担用户组的机制为：首先选择认证域中在线用户数最少的负载分担用户组，其次选择最后配置的用户负载分担组。
· 如果AAA服务器没有给接入用户授权用户组，且认证域下也没有指定负载分担用户组，则无NAT实例分配给该用户，用户将会下线。
如果联动用户所属的用户组不存在，则会输出“Failed to obtain user group information”。
转发与控制分离组网下，CP和UP上需要配置相同的用户组。例如：
<Sysname> system-view
[Sysname] user-group user
Failed to parse AAA request message
设备内存不足导致解析AAA认证请求消息失败。
(1) 通过display memory命令查看设备的内存使用情况，确认设备可用内存是否不足。
(2) 通过display memory-threshold命令查看是否有内存门限告警，结合显示信息中的“Current free-memory state:”字段判断内存告警状态。
(3) 按需清理内存，例如减少在线用户数或者关闭一些不需要的业务。
Failed to smooth the PPPoEA session
PPPoE模块和UCM模块之间平滑PPPoE代拨用户信息失败。
请联系技术支持人员。
Failed to switch workslot for user is not up
用户会话处于非稳态情况下，用户上线接口（如果为聚合口上线，则表示实际上线的成员接口所在单板）所在单板重启等原因触发协商板切换。
请联系技术支持人员。
Failed to update the PPPoEA session
设备更新PPPoE代拨用户会话信息失败。
请联系技术支持人员。
failover group becomes invalid
通过undo nat centralized-backup enable命令关闭集中式备份分布式CGN功能，流量回切到分布式部署CGN的NAT设备上，但是分布式部署CGN的NAT设备的备份组无法正常工作，导致用户下线。
关闭集中式备份分布式CGN功能前，请检查分布式部署CGN的NAT设备上的备份组是否有效。使用display failover命令查看备份组的信息，“Active Status”字段显示为“Initial”，说明备份组中没有可以处理业务的节点，请排除节点故障。
Flow-triggered port block assignment does not support CGN
NAT与BRAS联动的场景中，用户上线成功后，NAT为该用户分配公网地址以及端口块。此种端口块分配方式与通过nat port-block flow-trigger enable命令开启的流量触发分配端口块方式冲突。
检查系统视图和NAT实例下是否配置了nat port-block flow-trigger enable命令。如果配置了nat port-block flow-trigger enable命令，请在存在该配置的视图下使用undo nat port-block flow-trigger enable命令关闭流量触发分配端口块功能。例如：
<Sysname> system-view
[Sysname] nat instance cgn1 id 1
[Sysname-nat-instance-cgn1] undo nat port-block flow-trigger enable
Force user offline by CUSP aging
CUSP通道发生中断后，在设定的CUSP相关表项达老化时间（老化时间由cusp-controller视图下的disconnection entry-aging命令配置）超时时，CUSP通道仍未建立，导致用户下线。
在cusp-controller视图下执行undo disconnection entry-aging命令取消老化时间配置。
Going online failed because matching CGN doesn't support port block
NAT与BRAS联动的场景中，联动上线用户匹配上的NAT配置中缺少端口块参数的配置，导致该NAT配置无法为用户分配端口块。
在用户匹配的NAT配置所引用的地址组视图下，使用port-block命令配置端口块大小参数。例如：
<Sysname> system-view
[Sysname] nat address-group 1
[Sysname-address-group-1] port-block block-size 256 extended-block-number 1
Hardware not support IPV6 PD prefix with mask longer than 120
驱动不支持PD前缀长度大于120的用户。
检查PD前缀池相关配置，确保PD前缀长度不大于120。
ICMP with detect fail
· 客户端配置了防火墙后不对ICMP探测报文进行回应。
· 中间传输设备丢弃或者修改探测报文。
· 链路故障。
· 探测报文被设备丢弃。
· 设备因接入方式、接口状态、用户信息等不正确导致丢弃报文。
先关闭客户端防火墙（例如：Windows防火墙），如果问题仍未解决，则查看用户上线和下线时间差，查看探测配置，执行命令trace access-user打开业务跟踪对象，查看报文收发情况，排查报文在哪个阶段被丢弃，并进行相应的故障处理。
ICMPv6 with detect fail
· 客户端配置了防火墙后不对ICMPv6探测报文进行回应。
· 中间传输设备丢弃或者修改探测报文。
· 链路故障。
· 探测报文被设备丢弃。
· 设备因接入方式、接口状态、用户信息等不正确导致丢弃报文。
先关闭客户端防火墙（例如：Windows防火墙），如果问题仍未解决，则查看用户上线和下线时间差，查看探测配置，执行命令trace access-user打开业务跟踪对象，查看报文收发情况，排查报文在哪个阶段被丢弃，并进行相应的故障处理。
idle cut
单位时间内用户流量小于规定值，设备强制用户下线。
若授权时间合理，则属于正常现象，让用户重新上线即可。若授权时间不合理，请修改AAA服务器或者设备ISP域下的授权限制切断参数。
Inherited PPPoE user went offline
PPPoE用户下线，导致继承了该PPPoE用户信息的IPoE用户下线。
请查看PPPoE用户的下线原因，并根据下线原因进行定位。
Insufficient hardware resources
驱动资源不足。
通过执行display access-user count命令检查用户数。
通过执行下列命令查看驱动资源占用情况：
· display qos-acl resource
· display hardware internal pppoe record summary session
· display hardware internal ucm record type
Interface deactive
接口板重启或者接口删除等原因导致接口去激活，触发用户下线或者上线失败。
通过下列方法检查是否有板重启或者接口删除事件发生，若有但不是管理员手动操作则分析板重启原因，若没有请联系技术支持人员。
· display logbuffer命令用来显示日志缓冲区的状态和日志缓冲区记录的日志信息。
· 查看logfile，可先执行display logfile summary命令查看logfile的存储位置，然后直接在设备执行more命令再查看文件内容或将logfile文件导出到本地电脑上查看。
Interface down
用户上线接口所在链路down或者震荡过。
通过下列方法检查接口是否链路震荡，接口是否是down状态，若有震荡，则是正常下线无需处理，否则请联系技术支持人员。
· display logbuffer命令用来显示日志缓冲区的状态和日志缓冲区记录的日志信息。
· 查看logfile，可先执行display logfile summary命令查看logfile的存储位置，然后直接在设备执行more命令再查看文件内容或将logfile文件导出到本地电脑上查看。
Interface MAC change
上线接口的MAC地址变化，触发将记录到接口老MAC地址上的用户踢下线。
通过下列方法检查是否有在接口上执行mac-address命令更改了接口MAC地址，若有则属于正常现象，无需处理，否则请联系技术支持人员。
· display history-command all命令用来显示所有登录用户历史命令缓冲区中的命令。
· display logbuffer命令用来显示日志缓冲区的状态和日志缓冲区记录的日志信息。
· 查看logfile，可先执行display logfile summary命令查看logfile的存储位置，然后直接在设备执行more命令再查看文件内容或将logfile文件导出到本地电脑上查看。
Interface shutdown
接口被shutdown导致用户下线或者上线失败。
通过下列方法检查是否操作过接口shutdown，若有操作过，则属于正常现象，无需处理，否则请联系技术支持人员。
· display history-command all命令用来显示所有登录用户历史命令缓冲区中的命令。
· display logbuffer命令用来显示日志缓冲区的状态和日志缓冲区记录的日志信息。
· 查看logfile，可先执行display logfile summary命令查看logfile的存储位置，然后直接在设备执行more命令再查看文件内容或将logfile文件导出到本地电脑上查看。
Invalid ldap username
用户进行LDAP认证时，提供的用户名不合法。
检查用户名格式是否合法，比如用户名长度是否超过最大值255等。之后，请用户修改上线使用的用户名后，重新尝试上线。
Invalid username or password
用户名和密码无效。
检查输入的用户名和密码是否正确，并尝试重新登录。
Invalid Vlan value
DHCP用户上线过程中，设备主动发送ARP报文请求用户上线，触发相同用户上线，但是用户发送的ARP报文携带的VLAN与DHCP用户不一致，则无法上线成功。
请联系技术支持人员。
IP address conflict
· 当新用户上线时，因新用户和当前设备上已在某线用户的MAC地址、VLAN相同，但新用户获取到的IP地址（包括IPv4地址、IPv6地址、PD前缀）和该在线用户的IP地址不同，导致新用户上线失败。
· 当新用户上线时，因新用户获取到的IP地址（包括IPv4地址、IPv6地址）和当前设备上已在线某用户的IP地址相同，导致新用户上线失败。
(1) 请确认引起冲突的已在线用户是否为合法用户。
¡ 若是合法用户，则属于正常情况，无需处理。
¡ 若是非法用户，请执行cut access-user命令强制非法用户下线后，再让合法用户重新尝试上线。
(2) 执行以上操作后，若问题仍未解决，请收集如下信息，并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
IP address is not a valid user address
IP地址非法。
请联系技术支持人员。
ip subscriber access-block
用户上线接口上通过ip subscriber access-block命令了禁止IPoE用户上线。
在用户上线接口上执行undo ip subscriber access-block命令取消禁止IPoE用户上线配置后，让用户重新上线。
IP6CP is already down
DHCPv6请求连接UP时，PPP的IP6CP连接已经down掉。
在Probe视图下执行display system internal ucm access-user slot 1 user-id命令查看IP6CP连接down的原因，如无法根据显示信息自行解决问题，请联系技术支持人员。
IPoE access mode or authentication method error
带PD前缀的全局静态会话只能在二层接入且绑定认证方式时才允许用户上线。
检查IPoE全局静态会话配置。
IPoE lease sub-user without the main user
IPoE子用户上线时查找不到主用户。
请联系技术支持人员。
IPoE user conflict
在接口上有IPoE动态用户在线的情况下，配置IPoE接口专线或者L2VPN专线时，会强制当前接口上的动态用户下线。
属于正常情况，无需处理。
IPoELease main user offline
对于接口专线用户，当主用户下线时会将所有子用户也下线。
执行display aaa offline-record命令查看主用户下线原因，根据下线原因码判断是否是异常下线。
IPv6 PD prefix conflict
对于IPoE二层接入或者IPoE双栈静态用户，如果正在上线的用户存在MAC地址相同但PD前缀不同的用户，则会因PD前缀冲突导致用户无法上线。
请联系技术支持人员。
IPv6 user managed flag error
在IANA或IAPD应用中，用户上线接口没有配置M标记。
在用户上线接口（对于PPPoE，为VT口）配置ipv6 nd autoconfig managed-address-flag命令。对于PPP用户，还可以在用户所属ISP域下配置ipv6 nd autoconfig managed-address-flag命令。
L2TP alloc sessionid fail
会话超规格。
执行display l2tp session statistics命令查看L2TP会话总数，检查会话总数是否已超出设备规格。
L2TP alloc tunnelid fail
没有空闲的隧道ID可以分配，隧道数超过规格，导致隧道建立失败。
执行display l2tp tunnel statistics命令查看L2TP隧道总数，检查隧道总数是否已超出设备规格。
L2TP checking ICCN error
ICCN报文携带的AVP属性协商不通过，或者ICCN报文解析失败。
检查L2TP相关配置，若配置正确但仍无法协商成功，请联系技术支持人员。
L2TP checking ICRQ error
ICRQ报文携带的AVP属性协商不通过。
检查L2TP相关配置，若配置正确但仍无法协商成功，请联系技术支持人员。
L2TP checking SCCRP error
· SCCRP报文携带了无效的隧道ID。
· CHANLLENGE无效等原因导致AVP属性解析错误。
检查对端设备的L2TP配置，若配置正确但仍无法协商成功，请联系技术支持人员。
L2TP inner error
内部错误。
检查对端设备的L2TP配置，若配置正确但仍无法协商成功，请联系技术支持人员。
L2TP instance cfg change
· 隧道源IP地址变化，使得基于该源IP地址建立的L2TP隧道下线。
· BRAS-VM上UP ID删除，使得基于该UP ID的L2TP隧道下线。
属于正常现象，无需处理。
L2TP peer cleared tunnel
本端收到对端发送的stopCCN消息，清除本端L2TP隧道。
执行display l2tp statistics failure-reason命令查看对端清除隧道原因，并联系技术支持人员。
L2TP remote slot
用户上线接口（如果为聚合口上线，则表示实际上线的成员接口所在单板）所在单板被拔出导致用户下线。
属于正常现象，无需处理。
L2TP SCCCN check fail
· 解析SCCN报文出错。
· 本地无法识SCCN报文携带的AVP属性导致本端协商失败。
检查对端设备配置，联系技术支持人员。
L2TP SCCRQ check fail
· 根据SCCRQ报文中的host name获取L2TP组失败。
· SCCRQ报文携带了无效的隧道ID。
· CHANLLENGE无效等原因导致AVP属性解析错误。
检查对端设备的配置，若配置正确但仍无法协商成功，联系技术支持人员。
L2TP send ICCN fail
本端发送ICCN报文失败。
请联系技术支持人员。
L2TP send ICRP fail
本端发送ICRP报文失败。
请联系技术支持人员。
L2TP send ICRQ fail
本端发送ICRQ报文失败。
请联系技术支持人员。
L2TP send SCCRQ fail
本端发送SCCRQ报文失败，可能的原因是连接断开等。
请联系技术支持人员。
L2TP service is unavailable
本端没有开启L2TP功能，或者LAC与LNS之间网络不通。
检查配置，检查LAC与LNS是否能ping通。
L2TP session limit
L2TP隧道会话超规格。
执行l2tp session-limit命令调整UP上所能创建L2TP会话的最大数目后，让用户重新上线。
L2TP session wait for time out
L2TP会话协商定时器超时，可能是链路故障。
排查链路是否故障，若无法解决请联系技术支持人员。
L2TP tunnel time out
隧道保活超时，可能链路故障，也可能是流控序号没有对齐。
先检查链路，查看LAC和LNS间链路是否正常，若链路正常，再通过display l2tp control-packet statistics，display l2tp statistics all命令查看L2TP的报文统计计数，检查报文收发情况是否正常，若排查不出问题再继续排查报文丢弃点并联系技术支持人员。
L2TP with cut command
在本端执行reset l2tp tunnel命令删除隧道。
属于正常现象，无需处理。
L2TP with memory alloc fail
设备内存不足。
执行display memory检查设备内存，若内存足够，请联系技术支持人员。
L2TP with UP is not exist
在转发与控制分离组网中，创建L2TP隧道时对应的配置主UP不存在。
请联系技术支持人员。
LAC clear session
本端收到对端发送的CDN报文。
执行display l2tp statistics failure-reason命令查看报文交互，查看对端下线原因。
LAC clear tunnel
本端收到对端发送的stopCCN报文。
执行display l2tp statistics failure-reason命令查看报文交互，查看对端下线原因。
LAC too many session in mid state tunnel
L2TP隧道协商还未完成，基于该隧道创建的临时会话已超过300个，不允许用户再接入。
执行display l2tp tunnel命令查看隧道状态，待隧道协商完成后，再接入用户。
Layer2 IPoE leased subusers do not support access through IA_PD or the NDRS scenario of one prefix per user
由于二层IPoE专线子用户不支持通过IA_PD方式以及NDRS每用户每前缀方式接入，配置错误导致二层IPoE专线子用户通过IA_PD方式或者NDRS每用户每前缀方式接入时子用户上线失败。
请更改配置，避免二层IPoE专线子用户通过IA_PD或者NDRS每用户每前缀方式接入。
LB Offline
转控分离UP备份组网，同一个备份策略组的相同用户不允许在两个不同接口上线。
请联系技术支持人员。
Ldap admin-binding operation failed
设备上配置的管理员权限的用户DN和LDAP服务器上管理员的DN不一致。
进入对应的LDAP服务器视图，执行login-dn命令修改管理员用户DN，使之与LDAP服务器上的管理员DN保持一致。下例中设置的用户DN仅为示例。
<Sysname> system-view
[Sysname] ldap server ldap1
[Sysname-ldap-server-ldap1] login-dn cn=administrator,cn=users,dc=ld
Ldap server connetion error occurred while authenticating
用户认证时，设备与LDAP服务器连接失败。
执行display ldap scheme命令查看使用的LDAP服务器信息，然后排查设备和该LDAP服务器之间的链路故障问题。
LNS cfg change
allow l2tp配置变化，使得旧的虚拟模板口下的L2TP隧道被删除。
属于正常现象，无需处理。
LNS clear tunnel
收到对端发送的stopCCN报文。
执行display l2tp statistics failure-reason命令查看报文交互，查看对端下线原因。
LNS cleared session
收到对端发送的CDN报文。
执行display l2tp statistics failure-reason命令查看报文交互，查看对端下线原因。
LNS mandatory-chap error
配置了CHAP强制认证，但是VT口上没有CHAP配置。
在LNS模式的L2TP组视图下执行undo mandatory-chap命令删除CHAP强制认证配置后，让用户重新接入。
LNS proxy negotiation fail
预协商失败后，比如MRU协商失败或认证类型协商失败，重启了LCP协商。
排查L2TP配置，确保配置正确的情况下再重新接入。
Local no this user
采用本地认证方案时，查找不到本地认证用户。
执行display local-user命令查看是否创建了相应的本地认证用户，若未创建，则创建本地用户。
local no this user
用户采用本地认证上线，但设备上不存在对应的本地用户。
请执行display domain命令查看用户上线的认证域中是否设置了本地认证方案。缺省情况下，认证域会采用本地认证方案。如果用户的认证方案为本地认证，请执行display local-user命令查看是否存在对应的本地用户配置。如果本地用户不存在，则执行local-user命令创建本地用户，并按需配置密码和服务类型。
如下例所示，创建设备管理类本地用户test，配置密码为123456TESTplat&!，服务类型为SSH。
<Sysname> system-view
[Sysname] local-user test class manage
[Sysname-luser-manage-test] password simple 123456TESTplat&!
[Sysname-luser-manage-test] service-type ssh
Local-user access-limit
使用同一用户名接入设备的本地认证用户达到最大值。
根据需要在该用户的本地用户视图下取消或者改变使用当前本地用户名接入设备的最大用户数。
· 执行undo access-limit命令取消使用当前本地用户名接入的用户数限制。
<Sysname> system-view
[Sysname] local-user test class manage
[Sysname-luser-manage-test] undo access-limit
· 执行access-limit max-user-number命令增加最大用户数（下例中为10）。
<Sysname> system-view
[Sysname] local-user test class manage
[Sysname-luser-manage-test] access-limit 10
Logged out by the RADIUS proxy
部署了RADIUS代理功能的情况下，无线客户端下线导致对应的IPoE用户下线。
检查无线客户端下线的原因，若非异常下线，则无需处理。
Macauth without the ipoe user
MAC认证时查找不到IPoE用户，可能的原因是IPoE用户已下线。
查看前域用户下线原因，根据下线原因排查，若没有下线原因请联系技术支持人员。
MAC address conflict
接口上每个用户所能创建PPPoE会话的最大数目为1（由pppoe-server session-limit per-mac命令配置），并且当设备收到和在线用户MAC地址相同的PADR报文时，该在线用户完成NCP协商时间已超过30秒，为确保同MAC的新会话可以创建，设备会发送PADT报文通知在线用户下线，并拆除当前会话。
请根据现网实际情况确认，每个用户仅可创建1个PPPoE会话是否为真实需求。
· 若是，则属于正常情况，无需处理。
· 若否，请通过pppoe-server session-limit per-mac命令将每个用户所能创建PPPoE会话的最大数目配置为实际需要的值，并且，在所配置值大于等于2的情况下，必须同时配置remote address dhcp client-identifier命令并指定session-info参数，以使PPP会话参与DHCP客户端ID的生成。
Magic number check failed
开启了魔术字检查功能，LCP协商后本端保存的对端魔术字与对端发过来报文携带的魔术字不匹配。
抓包检查Echo-Request、Echo-Reply报文中的Magic-Number字段是否正确，请联系技术支持人员。
Maximum concurrent users for the account has been reached
AAA域下用户名能接入的用户的个数超过最大限制。
修改ISP域下access-limit配置后，让用户重新上线。
NAT instance state error
转发与控制分离的N:1温备场景下，CP上没有配置对应的CGN温备组。
创建CGN-UP备份策略模板，并与实际处理地址转换业务的NAT实例绑定。然后，配置备用UP和主用UP。例如：
<Sysname> system-view
[Sysname] cgn-backup-profile 1 warm-standby nat-instance cgn-a
[Sysname-cgn-backup-profile-1] backup up-id 1026
[Sysname-cgn-backup-profile-1] master up-id 1024
[Sysname-cgn-backup-profile-1] master up-id 1025
nat online failed because of match config failed
NAT与BRAS联动的场景中，联动用户无法匹配到nat outbound配置。
使用display nat outbound命令检查期望用户流量匹配的nat outbound配置，确保nat outbound配置引用的ACL规则能够匹配上用户流量。例如：
(1) 使用display nat outbound命令检查期望用户流量匹配的nat outbound配置，查看nat outbound配置中引用的ACL规则为ACL 2036。
<Sysname> display nat outbound
NAT outbound information:
Totally 1 NAT outbound rules.
Interface: Ten-GigabitEthernet3/1/1
ACL: 2036 Address group: 1 Port-preserved: Y
NO-PAT: N Reversible: N
Config status: Active
(2) 使用display acl命令检查ACL 2036的配置和运行情况。如果显示信息中未出现“xx times matched”，则说明该规则未匹配到流量，请修改ACL配置。
<Sysname> display acl 2036
Basic IPv4 ACL 2036, 1 rule,
ACL's step is 5
rule 0 permit source 10.210.0.0 0.0.0.255
nat online failed because of match session-service-location failed
接口NAT未配置基于会话业务的备份组，或者基于会话业务的备份组未能匹配用户流量。
使用display current-configuration | include session命令，检查是否存在session service-location acl的配置。例如：
<Sysname> display current-configuration | include session
session service-location acl 2000 failover-group aa
(1) 如果存在session service-location acl的配置，请使用display acl命令检查ACL的配置和运行情况。如果显示信息中未出现“xx times matched”，则说明该规则未匹配到流量，请修改ACL配置。例如：
<Sysname> display acl 2000
Basic IPv4 ACL 2000, 1 rule,
ACL's step is 5
rule 0 permit source 10.210.0.0 0.0.0.255
(2) 如果不存在session service-location acl的配置，请在系统视图下配置session service-location acl命令。例如：
<Sysname> system-view
[Sysname] session service-location acl 2010 failover-group aa
NAT Online failed by not bind vsrp
转发与控制分离的1:1热备或N:1温备场景中，相互备份的NAT设备上的NAT实例没有绑定相同的多机备份实例。
转发与控制分离的1:1热备或N:1温备场景中，相互备份的NAT设备上的NAT实例与相同的多机备份实例绑定。例如：
<Sysname> system-view
[Sysname] nat instance inst
[Sysname-nat-instance-inst] bind vsrp-instance 1
NAT Online failed by vsrp channel state error
转发与控制分离的1:1热备或N:1温备场景中，NAT实例绑定多机备份实例后，未能成功建立备份通道。
使用display vsrp instance命令检查UP间相同NAT实例下绑定的多机备份实例的配置，保证多机备份实例的备份标识符（Backup ID）一致。同时，保证NAT通过VSRP建立数据备份通道时使用的TCP端口号一致。否则，无法建立NAT数据备份通道。
如果不一致，请使用nat vsrp-port命令修改配置。例如：
<Sysname> system-view
[Sysname] nat vsrp-port 30000
ND detect fail
· 中间传输设备丢弃或者修改ND探测报文。
· 链路故障。
· 探测报文被设备丢弃。
· 设备因接入方式、接口状态、用户信息等不正确导致丢弃报文。
查看用户上线和下线时间差，查看探测配置，执行命令trace access-user打开业务跟踪对象，查看报文收发情况，排查报文在哪个阶段被丢弃，并进行相应的故障修复。
No AAA response during realtime accounting
设备没有收到计费服务器的实时计费报文响应报文。
(1) 检查计费服务器上是否添加了接入设备的IP地址或者添加的IP地址不正确，确保计费服务器上添加的接入设备的IP地址与设备发送计费请求报文的源IP地址相同。
(2) 检查设备和计费服务器之间的网络是否存在问题，确保计费服务器可达。
No AAA response for accounting start
设备没有收到计费服务器的计费开始响应报文。
(1) 检查计费服务器上是否添加了接入设备的IP地址或者添加的IP地址不正确，确保计费服务器上添加的接入设备的IP地址与设备发送计费请求报文的源IP地址相同。
(2) 检查设备和计费服务器之间的网络是否存在问题，确保计费服务器可达。
No available pool
AAA没有授权IP地址池或IP地址池组。
修改AAA域下的授权IP地址池或IP地址池组配置。
No IPv6 address available
IANA方式上线，但是AAA没有授权IPv6地址池或IPv6地址池组。
修改AAA域下的授权IPv6地址池或IPv6地址池组配置。
No prefix available
NDRS类型用户上线，AAA没有授权IPv6前缀，接口也没有配置IPv6地址或IPv6前缀，则无法上线。
修改AAA域下的授权配置，或者接口上的IPv6地址/RA前缀配置（可由ipv6 nd ra prefix命令配置接口的RA前缀，该方式不适用于非转发与控制分离组网）。
No response of control packet from peer
L2TP组网环境下，设备上的流控定时器创建失败。
请联系技术支持人员。
Old connection is exist
对于普通IP地址池，未配置网关IP地址。
在普通IP地址池视图下执行gateway-list命令配置DHCP服务器为DHCP客户端分配的网关地址。
On-line user with the same mac exists
动态用户上线时，查找到了相同MAC地址的在线静态用户。
执行display access-user命令查看是否存在相同MAC地址的静态用户，若存在则属于正常上线失败，无需处理，否则请联系技术支持人员。
Only static leased users are permitted
接口配置了静态专线，但是接入的用户信息和配置的专线信息不匹配，无法接入。
属于正常情况，无需处理。
Packet Authenticator Error
IPoE三层接入模式下，DHCP用户存在静默表项。
执行reset ip subscriber chasten user quiet命令手工解除静默，或者等静默表项超时老化后重新上线。
PPP authentication method error
设备配置CHAP认证，但是客户端是PAP认证，认证方式不匹配。
执行ppp authentication-mode命令修改PPP认证方式。
ppp chasten
PPP用户认证失败多次，被静默。
待静默用户超时老化后，让用户重新上线。
PPP IPCP negotiate fail
· 可能分配了无效的地址，或者分配地址失败。
· 收到未知报文。
· BRAS设备发送configure request等待用户返回configure ack超时。
检查设备的配置，收集交互的PPP协议报文信息，联系技术支持人员。
PPP IPCP terminate
收到客户端发的ipcp terminal request，强制用户下线。
属于正常现象，无需处理。
PPP IPv6CP negotiate fail
· 收到未知报文。
· BRAS设备发送configure request等待用户返回configure ack超时。
检查设备的配置，若配置正确但仍无法协商成功，请联系技术支持人员。
PPP IPv6CP terminate
收到客户端发的ipv6cp terminal request。
正常情况，无需处理。
PPP loopback detected
PPP协商报文发生环路，可能是链路连接发生错误。
排查链路故障，联系技术支持人员。
PPP magicnumber check fail
开启了PPP协议的魔术字检查功能，但是协商的魔术字不相等，导致协商失败。
在接口视图下执行undo ppp magic-number-check命令关闭PPP协议的魔术字检查功能。
PPP negotiate fail
PPP协商过程被中断。
检查设备的配置，若配置正确但仍无法协商成功，联系技术支持人员。
PPP Recover failed
PPP恢复会话失败。
请联系技术支持人员。
PPP recv ip6cp Protocol Reject
收到IPv6CP拒绝报文，可能是某些选项协商失败。
检查设备的配置，若配置正确但仍无法协商成功，联系技术支持人员。
PPP recv ipcp Protocol Reject
收到IPCP拒绝报文，可能是某些选项协商失败。
检查设备的配置，若配置正确但仍无法协商成功，联系技术支持人员。
PPP up recv ip6cp again
· IPv6CP处于open状态后，收到重复的IPv6CP协商报文，可能是客户端断开重新发起连接导致。
· IPv6CP协商报文重传或者报文有丢失。
执行display system internal ucm statistics packets命令排查设备是否有丢包计数，抓包分析，排查链路故障，若无法解决请联系技术支持人员。
PPP up recv ipcp again
· IPCP处于open状态后，收到重复的IPCP协商报文，可能是客户端断开重新发起连接导致。
· IPCP协商报文重传或者报文有丢失。
执行display system internal ucm statistics packets命令排查设备是否有丢包计数，抓包分析，排查链路故障，若无法解决请联系技术支持人员。
PPP user request
PPP用户通过发送Terminate Request主动发起下线。
客户端重新拨号。
PPP username is null
配置了用户名检查，但是设备收到用户名为空的认证信息。
若网络管理员要求PPP用户请求上线时必须带用户名，则属于正常现象，无需处理。若不要求PPP用户请求上线时必须带用户名，请在VT接口上执行undo ppp username check命令用来取消PPP用户请求上线时必须带用户名的配置后，让用户重新上线。
PPP wait chap response time out
设备等待CHAP验证结果超时，并且重传challenge验证请求超过最大次数，客户端断开连接或链路故障导致报文无法收到。
排查是否是客户端主动断开，若不是，则排查链路故障，若无法解决请联系技术支持人员。
PPP wait pap request time out
· 设备等待PAP验证请求超时，可能是客户端断开连接导致。
· 链路故障导致设备无法收到认证报文。
排查是否是客户端主动断开连接，若不是，则排查链路故障，若无法解决请联系技术支持人员。
PPP wait pap response time out
· 设备等待PAP验证结果超时，并且重传验证请求超过最大次数，可能是客户端断开连接导致。
· 链路故障导致设备无法收到认证报文。
排查是否是客户端主动断开连接，若不是，则排查链路故障，若无法解决请联系技术支持人员。
PPP with echo fail
· 中间传输设备丢弃或者修改PPP探测报文。
· 链路故障。
· 设备因接入方式、接口状态、用户信息等不正确导致丢弃报文。
查看用户上线和下线时间差，查看保活配置，执行display ppp packet statistics命令，查看报文收发情况，排查报文在哪个阶段被丢弃，并进行相应的故障修复，若查找不到丢包原因请联系技术支持人员。
PPPoE agency failed to start PPP
为该PPPoE代拨用户启动PPP协商失败。
请联系技术支持人员。
PPPoE send pads failed
设备发送PADS报文失败。
请联系技术支持人员。
PPPoEA session information failed to be synchronized between slots
PPPoE代拨用户的会话信息在各slot间同步失败。
请联系技术支持人员。
proxy with smooth fail
在转发与控制分离组网中，CU连接断开导致。
请联系技术支持人员。
Radius authentication and authorization do not same
用户进行RADIUS认证时，使用的RADIUS认证服务器和RADIUS授权服务器不同。
检查用户认证域下配置的RADIUS授权方法和RADIUS认证方法是否引用了不同的RADIUS方案。如果不同，请在该域下为用户配置相同的认证和授权方案。
<Sysname> system-view
[Sysname] domain name test
[Sysname-isp-test] authentication login radius-scheme rd
[Sysname-isp-test] authorization login radius-scheme rd
RADIUS authentication rejected
用户上线的RADIUS认证请求被服务器拒绝。
属于正常现象，可联系服务器管理确认拒绝原因。
Re-DHCP for IPoE Web authentication
IPoE web二次地址分配的用户收到计费应答后需要下线重新登录。
属于正常现象，无需处理。
Receive padt packet from user
收到客户端发的PADT（客户端通过发送PADT主动下线）。
属于正常情况，无需处理。
RedisDBM block
RMDB远程数据库数据正在自恢复中或者UP迁移中，不允许用户接入。
属于正常情况，无需处理，待UP迁移完成重新上线。
RedisDBM clear
在RMDB远程数据库组网中，UP迁移，UP从当前BRAS-VM迁出，则删除对应UP的用户。
属于正常情况，无需处理。
RedisDBM deactive
在RMDB远程数据库组网中，PPP恢复会话开始前，设备将还未协商完成的会话踢下线。
RMDB远程数据库数据自恢复完成，PPP恢复完成后，让用户重新拔号上线。
Remote interface offline
在转发与控制分离组网中，UP上因接口去激活等原因导致UP上用户接入接口不再被CP远程管理，触发用户下线。
属于正常情况，无需处理。
Server is disabled
在用户上线接口上关闭PPPoE使能，或者PPPoE绑定的接口被删除。
属于正常情况，无需处理。
Service unavailable
服务不可达，比如PPP模块与UCM模块内部连接还未建立。
请联系技术支持人员。
Service-type mismatch with local-user's
用户的接入类型与设备上对应的本地用户配置的服务类型不匹配。
执行display local-user命令查看该本地用户的配置信息，用户配置的服务类型由“Service type:”字段标识。如果用户的接入类型不在本地用户配置的服务类型范围之内，请在该用户的本地用户视图下，通过执行service-type type命令修改用户的服务类型为实际使用的接入类型。
session time out
用户会话超时，被强制下线。
打开RADIUS报文调试信息开关，查看服务器回应的计费更新报文中是否携带Session-Timeout属性，或者携带的Session-Timeout属性取值为0。
正常现象，无需处理。
Static user not config
· 触发上线的用户信息与配置的IPoE静态用户信息不匹配，需要检查配置。
· 对于NS/NA报文触发上线方式：在web阶段，因用户报文无法匹配静态用户和漫游用户，且不能按松散模式上线导致用户无法上线。
· 对于ARP报文触发上线方式：在web阶段，用户报文无法匹配静态用户和漫游用户，且不能按松散模式上线导致用户无法上线。
检查IPoE静态用户的配置，若配置正确故障仍存在，请联系技术支持人员。
Status Error
转控分离UP备份组网，主备UP切换时，用户重新接入的接口的状态不是运行主，可能原因是出现了主备接口都故障。
检查配置主接口和配置备接口是否都故障，若都故障则是正常情况无需处理，否则请联系技术支持人员。
TACACS authentication rejected
用户的HWTACACS认证请求被服务器拒绝。
(1) 检查设备与HWTACACS服务器的共享密钥是否不匹配。若不匹配，请在HWTACACS方案下设置与服务器匹配的共享密钥。
(2) 请用户使用正确的用户名和密码重新尝试上线。
(3) 如果故障仍然未能排除，请联系技术支持人员。
Tacacs continue authentication failed
用户进行HWTACACS认证时，向服务器发送携带密码的认证持续报文后，服务器回应认证失败。
(1) 检查设备与HWTACACS服务器的共享密钥是否不匹配。若不匹配，请在HWTACACS方案下设置与服务器匹配的共享密钥。
(2) 请用户使用正确的密码重新尝试上线。
(3) 如果故障仍然未能排除，请联系技术支持人员。
Tacacs follow authentication failed
HWTACACS认证过程中，切换到下一个服务器认证失败。
(1) 检查设备与HWTACACS服务器的共享密钥是否不匹配。若不匹配，请在HWTACACS方案下设置与服务器匹配的共享密钥。
(2) 通过display memory命令查看设备的内存使用情况，确认设备可用内存是否不足，并按需清理内存，例如减少在线用户数或者关闭一些不需要的业务。
(3) 如果故障仍然未能排除，请联系技术支持人员。
Tacacs restart authentication failed
对不同HWTACACS服务器发起的再次认证仍然失败。
(1) 检查设备与HWTACACS服务器的共享密钥是否不匹配。若不匹配，请在HWTACACS方案下设置与服务器匹配的共享密钥。
(2) 请用户使用正确的密码重新尝试上线。
(3) 如果故障仍然未能排除，请联系技术支持人员。
TERM with Ifnet down
接入口网络层down，触发子网专线用户下线。
检查链路状态，执行display interface命令查看物理层、链路层是否UP，若不是UP则排查链路故障。
The address state is incorrect
PPP地址占位，IP地址池中没有配置网关地址，并且接口下也没有配置网关。
检查IP地址池配置，以及接口下IP地址配置。
The authorized vpn is invalid
授权的VPN在设备上不存在。
在设备上创建AAA授权的VPN。
The BRAS user associated with the PPPoEA user is offline
PPPoE代拨用户对应的校内BRAS用户下线。
查看校内BRAS用户的下线原因，并根据下线原因进行故障定位。
The drv does not support
产品不支持当前用户接入。
请联系技术支持人员。
The IPoE lease user is confilct with the static user
对于未知源触发上线方式：用户同时匹配了接口专线和静态，因配置错误导致用户无法上线。
检查接口是否同时配置接口专线和静态，若没有配置错误，请联系技术支持人员。
The memory reached the restart threshold
系统内存到达告警门限导致用户无法上线。
执行display memory命令查看内存，待退出内存门限后重新上线。
The NAT instance was unbound from CGN-UP backup profile
转发与控制分离的N:1温备组网下，CP上删除CGN-UP备份策略模板的配置，导致用户下线。
用户在线时，请勿执行undo cgn-backup-profile命令删除CP上的CGN-UP备份策略模板配置。
The non-static user is kicked off the line by the static user
静态用户上线，检查到MAC冲突的已在线动态用户，将动态用户踢下线。
属于正常情况，无需处理。
The number of terminals on this interface exceeds limit
在线用户数已经达到接口上配置的允许接入最大用户数。
查看接口上的access-limit命令配置，若在线用户个数没有到达允许接入最大用户数，请联系技术支持人员。
The number of terminals on this machine exceeds limit
用户超出产品定制规格。
查看产品定制规格与已在线用户（可由display access-user count命令查看），若在线用户个数没有到达产品规格，请联系技术支持人员。
The number of users exceeds limit
用户数已达到了设备允许上线用户数的最大限制值。
执行display access-user count命令查看已在线用户数是否达到设备允许上线的最大用户数，检查设备规格。
The PPPoEA user already exists
PPPoE代拨用户已在线的情况下，再次收到相同校内接入认证用户的PPPoE代拨请求。
请联系技术支持人员。
The PPPoEA user does not exist in the PPPoE module
PPPoE模块中不存在该PPPoEA用户信息。
请联系技术支持人员。
The PPPoEA user failed to select an access interface
PPPoE代拨用户选择代拨接口失败，可能是PPPoE代拨组名称配置错误，或代拨接口DOWN。
(1) 检查pppoe-agency bind命令配置，确保PPPoE代拨接口与PPPoE代拨组正确绑定。
(2) 执行display interface interface-type interface-number命令查看接口状态，确保接口物理状态和协议状态都是UP。
(3) 若排查配置以及接口状态问题后，故障仍存在，请联系技术支持人员。
The PPPoEA user failed to select an access interface because agency is not enabled
未在正确的接口上执行pppoe-agency bind命令开启PPPoE代拨功能导致PPPoE代拨用户选择代拨接口失败。
(1) 检查PPPoE代拨接口视图下的pppoe-agency bind命令配置，确保该配置已存在并且PPPoE代拨接口与PPPoE代拨组正确绑定。
(2) 若排除配置问题后，故障仍存在，请联系技术支持人员。
The PPPoEA user failed to select an access interface because the interface control block does not exist
接口控制块不存在导致PPPoE代拨用户选择代拨接口失败。
(1) 检查PPPoE代拨接口视图下的pppoe-agency bind命令配置，确保PPPoE代拨接口与PPPoE代拨组正确绑定。
(2) 若排除配置问题后，故障仍存在，请联系技术支持人员。
The PPPoEA user failed to select an access interface because the interface is not permitted to access
在多机备份组网中，具有代拨权限的校内用户尝试通过备设备上的接口接入时导致PPPoE代拨用户选择代拨接口失败。
(1) 检查多机备份状态，若用户接入接口所在设备当前为备设备角色，则属于正常情况，无需处理。
(2) 若排除多机备份状态问题后，故障仍存在，请联系技术支持人员。
The PPPoEA user failed to select an access interface because the interface is physically down
代拨接口DOWN导致PPPoE代拨用户选择代拨接口失败。
(1) 执行display interface interface-type interface-number命令查看接口状态，确保接口物理状态和协议状态都是UP。
(2) 若排除接口状态问题后，故障仍存在，请联系技术支持人员。
The PPPoEA user failed to switch the negotiation slot
PPPoE代拨用户协商板切换失败。
请联系技术支持人员。
The protocol stack on which the base service depends is IPv4
配置了IPoE用户主业务依赖IPv4协议栈（由用户上线接口视图下ip subscriber basic-service-ip-type ipv4命令配置，或者由ip subscriber authentication-method命令中basic-service-ipv4参数配置），但是，当前用户的IPv4协议栈未上线，从而导致该用户的IPv6协议栈上线失败。
请确认配置的IPoE用户主业务依赖IPv4协议栈是否为现网真实需求：
· 若是，则表示配置正确，当前属于正常情况，无需处理。
· 若不是，则表示配置有误，请根据实际需要修改配置。
The protocol stack on which the base service depends is IPv6
配置了IPoE用户主业务依赖IPv6协议栈（由用户上线接口视图下ip subscriber basic-service-ip-type ipv6命令配置），但是，当前用户的IPv6协议栈未上线，从而导致该用户的IPv4协议栈上线失败。
请确认配置的IPoE用户主业务依赖IPv6协议栈是否为现网真实需求：
· 若是，则表示配置正确，当前属于正常情况，无需处理。
· 若不是，则表示配置有误，请根据实际需要修改配置。
The source IP address of the L2TP tunnel does not support backup
1:1热备、N:1温备和1:N温备组网中，在LAC UP使用tunnel up-id up-id source-ip source-ip-address [ vpn-instance vpn-instance-name ]命令配置的源端IP地址建立L2TP隧道的情况下，LAC UP发送主备切换时，L2TP用户切换到新主LAC UP后，会被下线。
请确认是否接受主备切换后L2TP用户被下线需重新上线操作：
· 若接受，则属于正常情况，让L2TP用户在新主LAC UP重新上线即可。
· 若不接受，请更改LAC UP建立L2TP隧道使用的源端IP地址的配置，避免下次发生主备切换时L2TP用户再被下线，例如改为l2tp-up-backup master up-id backup up-id lac-source-ip source-ip-address [ vpn-instance vpn-instance-name ] master-cost cost backup-cost cost命令，或l2tp-up-backup lac-source-ip-pool { ip-pool ip-pool-name | ip-pool-group ip-pool-group-name } [ vpn-instance vpn-instance-name ] master-cost cost backup-cost cost命令方式配置的源端IP地址。
The user conflicts with an online user with the same DHCP client ID
PPPoE用户上线过程中向DHCP模块请求分配IP地址等信息时，因DHCP模块查询到当前设备上已存在与新上线用户具有相同DHCP客户端ID（由MAC地址、VLAN等信息组成）的在线用户，导致新用户上线失败。
对于PPPoE用户上线失败，请在BRAS设备上任意视图下执行display access-user命令检查当前设备上是否存在与新上线用户相同MAC地址和相同VLAN的在线PPPoE用户：
· 若存在，则检查用户上线接口是否配置了携带session-info参数的remote address dhcp client-identifier命令：
¡ 若未配置，请根据实际需要决定是否配置携带session-info参数的该命令（携带session-info参数表示允许使用PPP会话参与生成DHCP客户端ID）。配置携带session-info参数的该命令后，让用户重新尝试上线，若用户仍不能成功上线，请联系技术支持人员。
¡ 若已配置，请联系技术支持人员。
· 若不存在，请联系技术支持人员。
对于除了PPPoE用户之外其它类型的用户上线失败，请联系技术支持人员。
The user group of the BRAS user changed
在校内AAA服务器上通过COA将校内BRAS用户的user-group属性更改为不支持PPPoE代拨功能的user-group，或者在设备上执行undo user-group删除校内BRAS用户的user-group。
属于正常情况，无需处理。
The user with the same MAC address already exists on the backup interface
在UP备份组网中，当新用户通过某接口上线时，因CP设备检查到该上线接口的备份接口上存在和新上线用户属于相同VLAN、相同MAC地址的在线用户导致新用户上线失败。
请确认当前已在线用户是否为正常用户：
· 若是，则属于正常情况，无需处理。
· 若否，可以先执行cut access-user命令手工删除备份接口上同VLAN同MAC地址的在线用户后，再让用户重新上线。
The user with the same IP address already exists on the backup interface
在UP备份组网中，当新用户通过某接口上线时，因CP设备检查到该上线接口的备份接口上存在和新上线用户同IP地址的在线用户导致新用户上线失败。
请确认当前已在线用户是否为正常用户：
· 若是，则属于正常情况，无需处理。
· 若否，可以先执行cut access-user命令手工删除备份接口上同IP地址的在线用户后，再让用户重新上线。
The user's 802.1X client has not come online.
在802.1X认证组网中，对于通过开启了静态802.1X用户认证功能（由ip subscriber static-dot1x-user enable命令配置）的接口接入的用户，如果在该用户的802.1X客户端认证上线前，BRAS设备收到该用户发送的ARP报文、未知源IP报文或NS/NA报文，将拒绝该用户作为静态802.1X用户上线。
先让用户将自己的802.1X客户端认证上线后，再让用户通过访问任意网络或者直接ping自己网关等方式触发用户终端发送APR报文、未知源IP报文或NS/NA报文重新尝试上线。
The VPN bound to the IPoE static user and the authorized VPN are different
IPoE静态用户绑定的VPN和AAA授权的VPN不一致导致用户无法上线。
根据网络实际规划将修改IPoE静态用户绑定的VPN或者修改AAA授权的VPN，确保IPoE静态用户绑定的VPN和AAA授权的VPN相同。
The VPN to which the subscriber belongs has been deleted
用户所属的VPN实例被删除。
检查用户所属VPN实例是否被误删，如果是管理员因网络规划变动做的正常配置删除，则属于正常情况，无需处理，否则需要重新创建相应VPN实例。
Tunnel with session null
修改L2TP配置（例如执行allow l2tp命令修改VT口编号）触发会话删除，会话删除完后删除隧道。
属于正常情况，无需处理。
UCM notifies the PPPoEA user to go offline
UCM模块通知PPPoE代拨用户下线。
请联系技术支持人员。
UCM portswitch process fail
IPoE用户漫游失败，内部处理错误。
请联系技术支持人员。
Unmatched Vpn-Instance
AAA授权需要检查VPN，但是AAA授权的VPN与接入接口配置的VPN不一致。
修改AAA域下授权属性，或者修改接口的VPN配置。
UP mode change
接口加入UP备份策略模板，导致接口上已在线用户被强制下线。
若是配置接口加入UP备份策略模板触发则需要正常情况，无需处理，否则请联系技术支持人员。
UP mode is standby
在UP备份组网中，当前接口的状态是运行备接口，用户无法通过该接口接入。
接口故障恢复或者切换完成后，重新触发上线，若仍出现问题，请联系技术支持人员。
UP Switch NO IfBackup
转控分离UP备份组网，UP切换时，用户的运行备接口无效。
检查配置主接口和配置备接口的子接口的VLAN终结配置或者用户VLAN配置，比如用户携带的VLAN ID为100，配置主运行主接口的子接口上有VLAN 100的VLAN终结配置，但是配置备运行备接口的子接口上没有VLAN 100的VLAN终结配置，则需要在配置备接口的子接口上增加配置VLAN 100的VLAN终结配置。
UP Switch Offline
转控分离UP备份组网，UP切换时用户处于非稳态，比如上线过程中进行UP切换，导致用户下线。
若在上线过程中进行UP切换，则是正常下线，否则请联系技术支持人员。
UPLB Delete
在转发与控制分离组网中，UP迁移，迁出设备上用户被删除。
属于正常情况，无需处理。
User binding attributes mismatch with local-user's
用户进行本地认证时，实际的属性与设备上对应的本地用户配置的绑定属性不一致。
执行display local-user命令查看该本地用户的配置信息，绑定属性由“Bind attributes:”字段标识。如果用户实际使用的属性不在本地用户配置的绑定属性范围之内，请在该用户的本地用户视图下，通过执行bind-attribute命令修改用户的绑定属性。
User is in local-user blacklist
设备上开启了Password Control功能，用户本地认证失败后，系统会将其加入密码管理的黑名单，当用户连续尝试认证的失败累加次数达到设置的尝试次数时，设备将根据配置的处理措施禁止该用户后续的登录行为。
在任意视图下执行display password-control blacklist命令查看该用户是否被加入了黑名单。如果该用户在黑名单中，请在用户视图下执行reset password-control blacklist命令清除密码管理黑名单中的该用户。之后，请用户重新尝试上线。
User request
· 接口上关闭IPoE功能。
· L2TP会话协商失败，发送CDN报文通知对端终止会话协商并拆除会话。
若不是接入配置去使能导致用户下线，则请联系技术支持人员。
VSRP status change
· VSRP双机备份环境，双机降备时将还未协商完成的会话踢下线。
· VSRP双机备份环境，备身份无法接入用户。
属于正常情况，无需处理。
Web user request
Web用户主动发起下线。
属于正常情况，无需处理。
Web with unknown error
Web重认证时，用户处于modify状态。
请联系技术支持人员。
When the IPoE Web user is coming online in postauth by inheriting PPPoE user info, the BRAS rejects Web access requests from the user
在IPoE Web前域用户正在通过继承PPPoE用户信息在后域上线的过程中，当BRAS设备收到该IPoE用户的Web上线请求时，直接拒绝Web上线请求，该用户继续按继承PPPoE用户信息方式在后域上线。
属于正常情况，无需处理。
不同款型规格的资料略有差异, 详细信息请向具体销售和400咨询。H3C保留在没有任何通知或提示的情况下对资料内容进行修改的权利!
支持
