缺省情况下，Telnet服务处于关闭状态。如果系统视图下执行display this命令后，没有显示telnet server enable的配置信息，表示Telnet服务处于关闭状态。请先执行telnet server enable命令开启Telnet服务，确保设备允许客户端通过Telnet登录。

(4) 检查客户端登录设备的用户名和密码是否正确。

当用户向设备发起Telnet连接，在Telnet客户端按照提示输入登录设备的用户名和密码后，若系统提示认证失败，则建议重新输入用户名和密码，再次尝试登录设备。如果依旧登录失败，可以查看LOGIN/5/LOGIN_INVALID_USERNAME_PWD日志，若日志中显示类似如下内容时表示用户输入无效的用户名或密码：

如果忘记正确的登录用户名或密码，请修改认证方式为不认证，或重置密码，并通知用户再次尝试登录设备。

¡ 在用户线视图或用户线类视图下执行authentication-mode none命令，设置用户登录设备时的认证方式为不认证，用户不需要输入用户名和密码，就可以使用该用户线登录设备，但这种方式存在安全隐患，请谨慎配置。

<Sysname> system-view

[Sysname] line vty 0 63

[Sysname-line-vty0-63] authentication-mode none

¡ 如果登录用户的认证方式为密码认证，在用户线视图或用户线类视图下执行set authentication password命令来重新设置认证密码。

<Sysname> system-view

[Sysname] line vty 0 63

[Sysname-line-vty0-63] authentication-mode password

[Sysname-line-vty0-63] set authentication password simple hello12345&！

¡ 如果登录用户的认证方式为AAA认证，请参见“AAA&PasswordControl故障处理手册”重置密码。

(5) 检查登录设备的用户数是否达到了上限。

从Console口登录到设备，在任意视图下执行display users命令查看当前的Telnet用户数。缺省情况下，同时在线的Telnet用户数上限为32个。

可以查看TELNETD/6/TELNETD_REACH_SESSION_LIMIT日志，若日志中显示类似如下内容，表示Telnet登录用户达到上限：

TELNETD/6/TELNETD_REACH_SESSION_LIMIT: Telnet client 1.1.1.1 failed to log in. The current number of Telnet sessions is 10. The maximum number allowed is (10).

如果登录设备的用户数已经达到了上限，可以先断开其他空闲Telnet用户的连接，或者执行aaa session-limit telnet命令增加允许同时在线的最大用户连接数，然后再向设备发起Telnet连接。

(6) 查看设备上是否引用了ACL对Telnet用户的访问进行控制。

在系统视图下执行display this命令，如果显示telnet server acl、telnet server ipv6 acl相关配置信息，表示引用了ACL对访问设备的Telnet的用户进行控制。

¡ 确认所引用的ACL规则中允许了Telnet客户端的IP地址、端口号、协议号等。可以查看TELNETD_ACL_DENY日志，若日志中显示类似如下内容，表示Telnet ACL规则限制登录IP地址：

TELNETD/5/TELNETD_ACL_DENY: The Telnet Connection 1.2.3.4(vpn1) request was denied according to ACL rules.

¡ 执行undo telnet server acl或undo telnet server ipv6 acl命令来取消ACL对Telnet用户的访问限制。

(7) 检查设备上认证方式配置是否正确。

在任意视图下执行display line命令查看用户线下用户登录设备时的认证方式，其中“Auth”字段表示使用该用户线登录的用户的认证方式，取值为“A”表示使用AAA认证方式，取值为“N”表示无需认证，取值为“P”表示使用当前用户线的密码进行认证。

¡ 如果使用命令authentication-mode password配置了VTY用户线下的登录认证方式为密码认证，还需要确保设置了认证密码。

¡ 如果使用命令authentication-mode scheme设置认证方式为AAA，则必须确保已经创建了AAA认证用户。

(8) 当Telnet客户端和Telnet服务器均为我司设备时，检查Telnet客户端上是否配置了发送Telnet报文的源地址或源接口。

在系统视图下执行display this命令，如果显示中包含telnet client source的相关配置信息，表示Telnet客户端上指定了发送Telnet报文的源IPv4地址和源接口，请确保用户从Telnet客户端上指定的源IPv4地址或源接口登录Telnet服务器。若登录失败，请选择以下配置后重新尝试登录：

¡ 执行telnet client source命令重新配置发送Telnet报文的源IPv4地址或源接口。

¡ 执行undo telnet client source命令来恢复缺省情况，即不指定发送Telnet报文的源IPv4地址和源接口，使用报文路由出接口的主IPv4地址作为Telnet报文的源地址。

需要注意的是，

¡ 在用户视图下执行telnet命令也可以指定Telnet报文的源接口或源IPv4地址，若同时使用telnet client source命令和telnet命令指定源IPv4地址或源接口，则以telnet命令指定的源IP地址或源接口为准。

¡ 在IPv6组网环境下，可以通过用户视图下的telnet ipv6命令来指定Telnet报文的源接口或源IPv6地址。

(9) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息。

5. 告警与日志

4.1.4 客户端可以Ping通CPE，也能Telnet到CPE，但是无法通过Web登录成功

1. 故障描述

客户端无法通过Web登录CPE，提示无法显示网页，但是从客户端可以Ping 通CPE，也可以Telnet登录到CPE。

2. 故障处理步骤

(1) 关闭Windows防火墙，Windows系统自带的防火墙开启后偶尔会造成此现象。

(2) Telnet登录到CPE，检查CPE配置，将HTTP服务开启。

(3) 如果故障仍然未能排除，请联系技术支持人员。

4.2 软件升级故障处理

4.2.1 设备启动失败

1. 故障描述

设备加载软件包后重启时，无法正常启动。

2. 常见原因

本类故障的常见原因为系统的BootWare版本与加载的软件包版本不匹配。

3. 处理步骤

(1) 在与Console口相连的PC上运行终端仿真程序，启动设备，然后通过登录过程中系统打印的如下信息确认系统的BootWare版本，然后执行第（2）步。

(2) 请与H3C技术支持工程师确认系统的BootWare版本是否为最新版本：

¡ 如果系统的BootWare版本是最新版本，请执行第（8）步。

¡ 如果系统的BootWare版本不是最新版本，请从官网获取最新版本BootWare软件包，然后执行第(3）步。

(3) 连接PC与设备的以太网接口，在PC上运行FTP/TFTP Server程序，并指定下载程序的文件路径，然后执行第（4）步。

FTP/TFTP Server软件由用户自己购买和安装，设备不附带此软件。

(4) 键入<0>退出到BootWare扩展段主菜单。在BootWare扩展段主菜单中，键入<7>，进入BootWare操作子菜单，然后执行第（5）步。

==========================<EXTENDED-BOOTWARE MENU>==========================

|<1> Boot System |

|<2> Enter Serial SubMenu |

|<3> Enter Ethernet SubMenu |

|<4> File Control |

|<5> Restore to Factory Default Configuration |

|<6> Skip Current System Configuration |

|<7> BootWare Operation Menu |

|<8> Skip Authentication for Console Login |

|<9> Storage Device Operation |

|<0> Reboot |

============================================================================

Ctrl+Z: Access EXTENDED ASSISTANT MENU

Ctrl+C: Display Copyright

Ctrl+F: Format File System

Enter your choice(0-9): 7

(5) 在BootWare操作子菜单中，键入<4>，选择通过以太网口升级BootWare。然后执行第（6）步。

=========================<BootWare Operation Menu>==========================

|Note:the operating device is flash |

|<1> Backup Full BootWare |

|<2> Restore Full BootWare |

|<3> Update BootWare By Serial |

|<4> Update BootWare By Ethernet |

|<0> Exit To Main Menu |

============================================================================

Enter your choice(0-4): 4

(6) 键入<4>，设置以太网口参数。然后执行第（7）步。

===================<BOOTWARE OPERATION ETHERNET SUB-MENU>===================

|<1> Update Full BootWare |

|<2> Update Extended BootWare |

|<3> Update Basic BootWare |

|<4> Modify Ethernet Parameter |

|<0> Exit To Main Menu |

============================================================================

Enter your choice(0-4): 4

(7) 设置以太网口参数后，键入<1>，上传BootWare软件包。BootWare软件包上传完成后，键入<0>，退出到BootWare操作子菜单。再键入<0>，退出到BootWare扩展段主菜单。在BootWare扩展段主菜单中键入<0>，重新启动设备：

¡ 如果设备正常启动，则故障排除。

¡ 如果设备没有正常启动，请执行第（8）步。

(8) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息。

4. 告警与日志

4.2.2 设备无法正常加载软件包

1. 故障描述

设备无法正常加载软件包，导致无法升级。

2. 常见原因

本类故障的常见原因主要为软件包损坏。

3. 处理步骤

(1) 在用户视图下通过md5sum命令来使用MD5摘要算法计算设备上待加载软件包的摘要值。

<Sysname> md5sum flash:/startup-a2105.ipe

MD5 digest:

f2054bc35cd13bf84038bd10fc7a3efd

(2) 在官网或H3C技术支持工程师处获得待加载软件包的标签，请自行获取MD5工具（利用搜索引擎或其他渠道），使用MD5工具计算标签的摘要值。

(3) 将设备上待加载软件包的摘要值和标签的摘要值比较：

¡ 如果两者一致，则说明软件包没有被损坏，请执行第（4）步。

¡ 如果两者不一致，则说明软件包被损坏，请联系H3C技术支持工程师获取新的软件包。

(4) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息。

4. 告警与日志

4.3 硬件资源管理故障处理

4.3.1 CPU占用率高

1. 故障描述

当出现以下情况时，说明设备的CPU控制核占用率高，需要确认CPU占用率高的具体原因。

· 对设备进行每日巡检时，连续使用display cpu-usage命令查看CPU的占用率，CPU占用率明显比日常平均值高。

# 执行display cpu-usage summary命令显示最近5秒、1分钟、5分钟内CPU占用率的平均值。

<Sysname> display cpu-usage summary

CPU Last 5 sec Last 1 min Last 5 min

0 5% 5% 4%

# 执行display cpu-usage history命令以图表的方式显示最近60个采样点的CPU占用率，观察到CPU占用率持续在增长或者明显比日常平均值高。

· 通过Telnet/SSH等方式登录设备，并执行命令行时，设备反应缓慢，出现卡顿现象。

· 设备上打印CPU占用率高的相关日志。

2. 常见原因

本类故障的常见原因主要包括：

· 协议震荡，通常为STP震荡、路由协议震荡等。

· 网络环路。

· 设备产生海量日志，设备生成和管理这些日志需要占用大量CPU资源。

3. 故障分析

本类故障的诊断流程如图4-4所示。

图4-4 CPU占用率高的故障诊断流程图

4. 处理步骤

(1) 确认设备是否出现协议震荡。

协议震荡会导致设备不断地处理协议报文、计算拓扑、更新表项，引起CPU占用率高。在实际应用中，最常见的协议震荡为STP协议震荡和OSPF协议震荡。

¡ 对于STP协议震荡，在系统视图执行stp port-log命令打开端口状态变化日志显示开关，如果命令行界面频繁输出以下日志，则说明出现了STP协议震荡。

STP/6/STP_DETECTED_TC: Instance 0's port GigabitEthernet1/0/1 detected a topology change.

STP/6/STP_DISCARDING: Instance 0's port GigabitEthernet1/0/1 has been set to discarding state.

STP/6/STP_NOTIFIED_TC: Instance 0's port GigabitEthernet1/0/1 was notified a topology change.

- 如果STP协议震荡，请先排除STP协议震荡问题。

- 如果STP协议没有震荡，则继续定位。

¡ 对于OSPF协议震荡，执行display ip routing-table命令，查看路由信息。如果路由表项中相同网段的路由条目被频繁反复地创建和删除，则表示路由震荡。

- 如果路由震荡，或者路由一直不存在，则先排除链路问题和IGP路由问题。

- 如果路由没有震荡，则执行步骤（2）。

(2) 确认是否存在网络环路。

当以太网接口工作在二层模式并且链路存在环路时，可能出现广播风暴和网络振荡。大量的协议报文上送CPU处理，从而导致CPU占用率升高。当存在网络环路时，设备很多端口的流量会明显变大，且广播和组播报文占比较大。可通过以下步骤来确认设备是否存在网络环路，设备是否存在广播、组播、未知单播报文风暴。

a. 清除接口的统计信息。

<Sysname> reset counters interface

b. 多次执行display counters rate inbound interface命令查看端口使用率是否明显增大。

<Sysname> display counters rate inbound interface

Usage: Bandwidth utilization in percentage

Interface Usage(%) Total(pps) Broadcast(pps) Multicast(pps)

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

c. 如果端口使用率明显增大，可继续多次执行display counters inbound interface命令查看接口收到的总报文数、广播和组播报文的数量，分别对应显示信息中Total(pkt)、Broadcast(pkt)、Multicast(pkt)字段的取值。如果广播和组播报文的增长速度快，广播、组播报文在接口收到的总报文数中占比大，则可能出现广播/组播风暴。如果广播和组播报文数量没有明显增加，但是接口收到的总报文数明显增加，则可能出现未知单播报文风暴。

<Sysname> display counters inbound interface

Interface Total(pkt) Broadcast(pkt) Multicast(pkt) Err(pkt)

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

¡ 如链路出现环路，可进行如下处理：

- 排查链路连接，避免物理拓扑出现环路。

- 使用display stp命令检查STP协议是否使能，配置是否正确。如果配置错误，请修改配置。

- 使用display stp brief和display stp abnormal-port命令检查邻接设备STP状态是否正常。请根据display stp abnormal-port命令显示信息中的BlockReason字段的取值，定位并解决STP异常问题。

如STP配置均正确，可能为STP协议计算错误或协议计算正确但端口驱动层没有正常Block阻塞，可以在发生环路的接口上执行shutdown/undo shutdown命令或者拔插网线让STP重新计算来快速恢复STP功能，消除环路。

- 在以太网接口视图下，使用broadcast-suppression命令开启端口广播风暴抑制功能，使用multicast-suppression命令开启端口组播风暴抑制功能，使用unicast-suppression命令开启端口未知单播风暴抑制功能。或者使用flow-control命令配置流量控制功能。

¡ 如未出现环，请执行步骤(3）。

(3) 确认设备当前是否正在生成海量日志。

某些异常情况下，例如，设备受到攻击、运行中发生了错误、端口频繁Up/Down等，设备会不停地产生诊断信息或日志信息。此时系统软件要频繁的读写存储器，会造成CPU占用率升高。

可通过以下方式来判断设备是否正在生成海量日志：

¡ Telnet登录到设备，配置terminal monitor命令允许日志信息输出到当前终端。

<Sysname> terminal monitor

The current terminal is enabled to display logs.

配置该命令后，如果有大量异常日志或者重复日志输出到命令行界面，则说明设备正在生成海量日志。

¡ 重复执行display logbuffer summary命令，如果日志信息总量有明显的增加，再使用display logbuffer reverse命令查看日志详情，确认是否有大量异常日志或者某一条信息大量重复出现。

<Sysname> display logbuffer summary

EMERG ALERT CRIT ERROR WARN NOTIF INFO DEBUG

0 0 2 9 24 12 128 0

0 0 0 41 72 8 2 0

0 0 42 11 14 7 40 0

<Sysname> 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 Sysname SHELL/6/SHELL_CMD: -Line=vty0-IPAddr=192.168.2.108-User=**; Command is display logbuffer

%Jan 15 08:17:19:743 2021 Sysname SHELL/4/SHELL_CMD_MATCHFAIL: -User=**-IPAddr=192.168.2.108; Command display logfile in view shell failed to be matched.

...

如果设备正在生成海量日志，可以通过以下方法减少日志的生成：

¡ 关闭部分业务模块的日志输出功能。

¡ 使用info-center logging suppress命令禁止指定模块日志的输出。

¡ 使用info-center logging suppress duplicates命令开启重复日志抑制功能。

如果设备未生成海量日志，则执行步骤（4）。

(4) 收集CPU占用率相关信息，找到CPU占用率高的业务模块。

a. 确定对CPU占用率高的任务。

# 在设备上执行display process cpu命令查看一段时间内占用CPU最多的任务。

<Sysname> display process cpu

CPU utilization in 5 secs: 0.5%; 1 min: 0.6%; 5 mins: 0.4%

JID 5Sec 1Min 5Min Name

1 0.0% 0.0% 0.0% scmd

...

如果某个进程的CPU占用率高于3%（经验值供参考），则需要针对该进程继续定位。

# 在设备上执行monitor process dumbtty命令实时查看进程在指定CPU上的占用率。

<Sysname> system-view

[Sysname] monitor process dumbtty

319 processes; 411 threads; 2093 fds

Thread states: 1 running, 410 sleeping, 0 stopped, 0 zombie

CPU0: 90.10% idle, 4.50% user, 5.40% kernel, 0.00% interrupt, 0.00% steal

CPU1: 99.10% idle, 0.00% user, 0.90% kernel, 0.00% interrupt, 0.00% steal

CPU2: 100.00% idle, 0.00% user, 0.00% kernel, 0.00% interrupt, 0.00% steal

CPU3: 100.00% idle, 0.00% user, 0.00% kernel, 0.00% interrupt, 0.00% steal

Memory: 967M total, 381M available, page size 4K

JID PID PRI State FDs MEM HH:MM:SS CPU Name

856 856 120 S 20 14956K 00:03:28 1.42% diagd

1 1 120 S 19 18764K 00:00:16 0.15% scmd

294 294 120 S 0 0K 00:02:15 0.15% [kworker/1:1

…

- 在monitor process dumbtty命令显示信息中找到CPU占用率超过3%（经验值供参考）的进程的JID，再对这些进程执行display process job命令，收集进程的详细信息，并确认该进程是否运行在控制核上。

如果display process job命令的显示信息中LAST_CPU字段的取值为控制核的编号（例如0～1），则说明该进程运行在CPU控制核上，则需要进一步定位；如果显示信息中LAST_CPU字段的取值为非控制核的编号，则说明该进程运行在CPU转发核上，无需关注，请执行步骤（5）。下面以pppd进程为例，通过显示信息可以看到，该进程包含多个线程，这些线程都运行在控制核上。

<Sysname> 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控制核占用率高的线程，需要进一步定位。

<Sysname> monitor thread dumbtty

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]

...

b. 确认异常任务的调用栈。

在Probe视图下执行follow job命令确认异常任务的调用栈。下面以Sysname上pppd进程（进程编号为515）的操作为例。

<Sysname> system-view

[Sysname] probe

[Sysname-probe] follow job 515

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

...

c. 根据a和b步骤找到任务名称，再根据任务名称找到对应的业务模块，定位并处理业务模块的问题。

(5) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息。

5. 告警与日志

4.4 生成树故障处理

4.4.1 设备连接成环时业务中断

1. 故障描述

多台设备通过物理链路连接成环时，业务流量中断。

2. 常见原因

本类故障的常见原因包括：

· 设备接口的物理状态为DOWN。

· 设备的生成树功能处于关闭状态。

3. 故障分析

本类故障的诊断流程如图4-5所示。

图4-5 设备连接成环时业务中断的故障诊断流程图

4. 处理步骤

(1) 检查承载业务流量的接口状态是否为UP。

a. 检查接口的物理状态是否为UP。

执行display interface brief命令，通过“Link”字段查看网络中的接口物理状态是否为UP，例如：

<Sysname> display interface brief

Brief information on interfaces in route mode:

Link: ADM - administratively down; Stby - standby

Protocol: (s) - spoofing

Interface Link Protocol Primary IP Description

Asy1/0/1 UP --

E-Ch1/0/1:0 DOWN DOWN --

InLoop0 UP UP(s) --

NULL0 UP UP(s) --

Vlan1 UP UP 192.168.100.2

Brief information on interfaces in bridge mode:

Link: ADM - administratively down; Stby - standby

Speed: (a) - auto

Duplex: (a)/A - auto; H - half; F - full

Type: A - access; T - trunk; H - hybrid

Interface Link Speed Duplex Type PVID Description

GE1/0/1 UP 1G(a) F(a) A 1

GE1/0/2 DOWN auto A A 1

WLAN-Radio1/0/1 UP -- -- -- --

WLAN-Radio1/0/2 UP -- -- -- --

- 如果网络中接口的状态为UP，请执行步骤b。

- 如果网络中接口的状态为ADM，请在接口视图下执行undo shutdown命令开启该接口。如果接口的状态仍为DOWN，请进行接口链路以及相关配置的排查；如果此时接口的状态为UP，但是故障仍未解决，请执行步骤b。

- 如果网络中接口的状态为DOWN，请进行接口链路以及相关配置的排查。接口状态恢复UP后，如果故障仍未解决，请执行步骤b。

b. 检查接口的数据链路层协议状态是否为UP。接口的数据链路层协议为DOWN的接口无法参与生成树拓扑的计算。

执行display interface命令，通过“Line protocol state”字段查看网络中的接口数据链路层协议状态是否为UP，例如：

<Sysname> display interface gigabitethernet 1/0/2

GigabitEthernet1/0/2

Current state: UP

Line protocol state: DOWN(LAGG)

...

DOWN(protocols)表示接口的数据链路层被一个或者多个协议模块关闭。例如，DOWN(LAGG)表示聚合接口中没有选中的成员端口而关闭接口的数据链路层。

如果接口的数据链路层被协议模块关闭，请检查并修改协议模块的配置，使得接口的数据链路层协议状态恢复为UP。如果接口的数据链路层协议状态恢复为UP后，故障仍未解决，请执行步骤（2）。

(2) 检查设备的生成树功能是否开启。

a. 检查设备上全局生成树功能是否开启。

执行display stp命令：

- 如果出现如下显示信息，则表示全局的生成树协议未开启：

<Sysname> display stp

Protocol status : Disabled

Protocol Std. : IEEE 802.1s

Version : 3

Bridge-Prio. : 32768

MAC address : 2eae-3769-0200

Max age(s) : 20

Forward delay(s) : 15

Hello time(s) : 2

Max hops : 20

TC Snooping : Disabled

<Sysname> display stp

STP is not configured.

请在系统视图下执行stp global enable命令开启全局的生成树功能。

- 如果出现生成树的状态和统计信息（如下所示），则说明全局的生成树功能已经开启，请继续执行步骤b。

<Sysname> display stp

-------[CIST Global Info][Mode MSTP]-------

Bridge ID : 32768.2eae-3769-0200

Bridge times : Hello 2s MaxAge 20s FwdDelay 15s MaxHops 20

Root ID/ERPC : 32768.2eae-3769-0200, 0

RegRoot ID/IRPC : 32768.2eae-3769-0200, 0

RootPort ID : 0.0

BPDU-Protection : Disabled

Bridge Config-

Digest-Snooping : Disabled

TC or TCN received : 0

Time since last TC : 0 days 2h:49m:11s

b. （仅生成树模式为PVST时适用，非PVST模式请继续执行步骤c）检查VLAN的生成树功能是否开启。

在系统视图下，执行display this命令，查看是否存在undo stp vlan enable命令的配置，例如：

[Sysname] display this

...

undo stp vlan 2 enable

stp mode pvst

stp global enable

...

如果存在上述配置且网络中需要开启对应VLAN的生成树功能，请在系统视图下执行stp vlan enable命令，开启VLAN的生成树功能。

c. 检查接口的生成树功能是否开启。

执行display stp命令，查看是否存在生成树功能未开启的接口，例如：

<Sysname> display stp

...

----[Port1(GigabitEthernet1/0/1)][DISABLED]----

Port protocol : Disabled

...

请在需要参与生成树计算的接口视图下执行stp enable命令，开启接口的生成树功能。

(3) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息。

5. 告警与日志

4.4.2 接入生成树网络的用户终端设备发生掉线

1. 故障描述

用户终端设备接入生成树网络时，连接终端设备的接口发生闪断，业务长时间丢包，造成终端设备掉线。

2. 常见原因

本类故障的常见原因为：连接用户终端设备的接口未被配置为边缘端口。

3. 故障分析

本类故障的诊断流程如图4-6所示。

图4-6 接入生成树网络的用户终端设备发生掉线的故障诊断流程图

4. 处理步骤

(1) 检查生成树网络中与用户终端设备直连的接口是否为边缘端口。

在与用户终端设备直连的生成树网络设备上执行display stp命令，查看与用户终端设备直连的接口是否为边缘端口，例如：

<Sysname> display stp

...

----[Port1(GigabitEthernet1/0/1)][FORWARDING]----

Port protocol : Enabled

Port role : Designated Port

Port ID : 128.2

Port cost(Legacy) : Config=auto, Active=20

Desg.bridge/port : 32768.2eae-3769-0200, 128.2

Port edged : Config=enabled, Active=enabled

Point-to-Point : Config=auto, Active=true

Transmit limit : 10 packets/hello-time

Protection type : Config=none, Active=none

Rapid transition : True

Port times : Hello 2s MaxAge 20s FwdDelay 15s MsgAge 0s

...

¡ 如果与用户终端设备直连的接口是边缘端口，请执行步骤（2）。

¡ 如果与用户终端设备直连的接口不是边缘端口，请进入该接口视图，并执行stp edged-port命令，将该端口配置为边缘端口。

(2) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息。

5. 告警与日志

4.4.3 非0实例端口状态为主端口且无法调整

1. 故障描述

在MSTP网络中，设备上除了MSTI 0之外的其他实例，本不应该是主端口角色的端口被计算为了主端口，且端口角色无法通过调整优先级、开销值等参数来改变。

2. 常见原因

本类故障的常见原因为：同一MST域内，不同设备对MST域的配置不一致。

3. 故障分析

如果两台设备对MST域的配置不一致，则设备会认为对端设备与本端设备不在同一个MST域中，导致与域内设备相连的端口也被计算为了主端口。所以本类故障的诊断思路为：检查同一MST域内设备的MST域配置信息，确保各个设备的配置保持一致。

本类故障的诊断流程如图4-6所示。

图4-7 非0实例端口状态为主端口且无法调整的故障处理流程图

4. 处理步骤

(1) 检查同一MST域内的设备对于MST域的域名、修订级别以及VLAN映射表配置是否相同，并确保这些参数的配置一致。

执行display stp region-configuration命令，显示设备生效的MST域配置信息。例如：

<Sysname> display stp region-configuration

Oper Configuration

Format selector : 0

Region name : hello

Revision level : 0

Configuration digest : 0x5f762d9a46311effb7a488a3267fca9f

Instance VLANs Mapped

0 21 to 4094

1 1 to 10

2 11 to 20

¡ Region name：MST域的域名，在系统视图下执行stp region-configuration命令进入MST域视图后，通过region-name命令进行配置。

¡ Revision level：MST域的修订级别，在系统视图下执行stp region-configuration命令进入MST域视图后，通过revision-level命令进行配置。

¡ Instance VLANs Mapped：MST域的VLAN映射关系，在系统视图下执行stp region-configuration命令进入MST域视图后，可以通过instance命令或vlan-mapping modulo命令进行配置。

如果同一MST域内不同设备的上述参数配置不相同，请执行上述操作将参数的配置修改为一致配置完MST域的相关参数后，必须在MST域视图下执行active region-configuration命令，用户对MST域的配置才能激活并生效，否则MST域仍会按照之前的配置生效。

(2) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息。

5. 告警与日志

4.5 ND故障处理

4.5.1 无法学习到ND表项

1. 故障描述

设备无法学习到ND表项，导致设备无法正常转发流量。

2. 常见原因

本类故障的常见原因主要包括：

· 内存不足导致无法学习到ND表项。

· 接口物理层未正常Up。

· 接口下配置的IPv6地址与对端接口不在同一网段。

· ND报文未上送到CPU。

· CPU繁忙导致ARP报文被丢弃。

3. 故障分析

本类故障的诊断流程如图4-8所示。

图4-8 ND表项学习失败的故障诊断流程图

4. 处理步骤

(1) 通过display memory-threshold命令查看是否由于内存不足导致无法学习到ND表项。

<Sysname> display memory-threshold

Memory usage threshold: 100%

Free-memory thresholds:

Minor: 96M

Severe: 64M

Critical: 48M

Normal: 128M

Early-warning: 256M

Secure: 304M

Current free-memory state: Normal (secure)

¡ 若系统当前内存使用状态（Current free-memory state）为“Normal”或“Normal (secure)”，请继续执行第（2）步。

¡ 若系统当前内存使用状态（Current free-memory state）为“Minor”、“Severe”、“Critical”或“Normal (early-warning)”，请检查设备内存的使用情况并排查内存不足问题。

(2) 查看网络配置以及接口状态。

依次检查如下配置：

a. 通过display interface命令查看接口是否处于UP状态。如果接口没有处于UP状态，请排查物理接口故障问题。

b. 通过display ipv6 fib ipv6-address命令查看IPv6 FIB表项的信息，ipv6-address为ND表项的IPv6地址。如果不存在对应的IPv6 FIB表项，则说明可能路由管理模块发生故障，请检查路由模块配置并排查问题。如果IPv6 FIB表中存在且转发的下一跳地址不是直连下一跳地址，则需检查设备与转发下一跳地址的连接情况。

c. 通过display ipv6 interface命令查看接口的的IPv6地址：

- 本端接口的IPv6地址是否与对端接口在同一网段。如果两端接口的IPv6地址不在同一网段，请在接口视图下执行ipv6 address命令修改两端的IPv6地址，使其在同一网段。

- 本端接口的IPv6地址是否与对端接口的IPv6地址发生冲突。如果两端接口的IPv6地址发生冲突，请在接口视图下执行ipv6 address命令修改两端的IPv6地址，使冲突消失。

- 查看对端接口是否为转发的下一跳所在的接口。

d. 通过ping ipv6命令检查链路是否存在故障。

(3) 检查IPv6报文是否正常收发。

a. 先通过debugging ipv6 packet命令打开IPv6的报文调试信息开关，再通过ping ipv6命令查看设备是否正常发送和接收IPv6报文。

<Sysname> debugging ipv6 packet

<Sysname> ping ipv6 -c 1 1::2

Ping6(56 data bytes) 1::1 --> 1::2, press CTRL+C to break

*Apr 26 11:37:33:402 2022 Sysname IP6FW/7/IP6FW_PACKET: -MDC=1;

LocalSending, version = 6, traffic class = 0,

flow label = 0, payload length = 64, protocol = 58, hop limit = 64,

Src = 1::1, Dst = 1::2,

prompt: Output an IPv6 Packet.

*Apr 26 11:37:33:402 2022 Sysname IP6FW/7/IP6FW_PACKET: -MDC=1;

Sending, interface = GigabitEthernet1/0/1, version = 6, traffic class = 0,

flow label = 0, payload length = 64, protocol = 58, hop limit = 64,

Src = 1::1, Dst = 1::2,

prompt: Sending the packet from local interface GigabitEthernet1/0/1.

以上信息表示设备在接口GigabitEthernet1/0/1上成功发送一个IPv6报文。

*Apr 26 11:37:33:402 2022 Sysname IP6FW/7/IP6FW_PACKET: -MDC=1;

LocalSending, version = 6, traffic class = 224,

flow label = 0, payload length = 32, protocol = 58, hop limit = 255,

Src = 1::1, Dst = ff02::1:ff00:2,

prompt: Output an IPv6 Packet.

*Apr 26 11:37:33:402 2022 Sysname IP6FW/7/IP6FW_PACKET: -MDC=1;

Sending, interface = GigabitEthernet1/0/1, version = 6, traffic class = 224,

flow label = 0, payload length = 32, protocol = 58, hop limit = 255,

Src = 1::1, Dst = ff02::1:ff00:2,

prompt: Sending the packet from local interface GigabitEthernet1/0/1.

56 bytes from 1::2, icmp_seq=0 hlim=64 time=19.336 ms

--- Ping6 statistics for 1::2 ---

1 packet(s) transmitted, 1 packet(s) received, 0.0% packet loss

round-trip min/avg/max/std-dev = 19.336/19.336/19.336/0.000 ms

<Sysname>*Apr 26 11:37:33:421 2022 Sysname IP6FW/7/IP6FW_PACKET: -MDC=1;

Receiving, interface = GigabitEthernet1/0/1, version = 6, traffic class = 0,

flow label = 0, payload length = 64, protocol = 58, hop limit = 64,

Src = 1::2, Dst = 1::1,

prompt: Received an IPv6 packet.

以上信息表示设备接收到IPv6报文。

*Apr 26 11:37:33:421 2022 Sysname IP6FW/7/IP6FW_PACKET: -MDC=1;

Delivering, interface = GigabitEthernet1/0/1, version = 6, traffic class = 0,

flow label = 0, payload length = 64, protocol = 58, hop limit = 64,

Src = 1::2, Dst = 1::1,

prompt: Delivering the IPv6 packet to the upper layer.

以上信息表示设备将接收到的IPv6报文上送到CPU处理。

%Apr 26 11:37:33:422 2022 Sysname PING/6/PING_STATISTICS: -MDC=1; Ping6 statistics for 1::2: 1 packet(s) transmitted, 1 packet(s) received, 0.0% packet loss, round-trip min/avg/max/std-dev = 19.336/19.336/19.336/0.000 ms.

¡ 若设备成功的发送和接收了IPv6报文，请继续执行第步。

¡ 若设备没有成功的发送和接收IPv6报文，请执行第4.6.1 4. (3)b步。

b. 通过debugging ipv6 error命令用来打开IPv6报文的错误调试信息开关，根据。表4-2中的内容确认设备无法成功发送或接收IPv6报文的原因。

表4-1 debugging ipv6 error命令输出信息描述表

字段	描述
Number of IPv6 fragments exceeded the threshold.	分片报文的数量超过了限制
Number of IPv6 reassembly queues exceeded the threshold.	重组队列的数量超过了限制
Invalid IPv6 packet.	IPv6报文非法
Failed to process the hop-by-hop extension header.	处理报文中逐跳扩展头失败
Failed to process the hop-by-hop option.	处理报文中逐跳选项失败
The packet was discarded by services.	业务禁止报文
The packet was administratively discarded.	IPv6报文被管理禁止

(4) 确认是否由于CPU繁忙导致ND报文被丢弃。通过view命令查看系统目录/proc/kque下的ND的相关内容，确认ND报文的丢弃情况及丢弃原因。

[Sysname-probe] view /proc/kque | in ND

0: dd0e0a00 ARP_SEND 1024/0/0/0 (0x4b515545)

0: dd0e6d00 ND_TIMER 1024/0/5/0 (0x4b515545)

0: dd0e6e00 ND_SINGLEEVENT 1/0/0/0 (0x4b515545)

0: dd0e6f00 ND_MACNOTIFYEVENT 1/0/0/0 (0x4b515545)

0: dcec4000 ND_RULE 4096/0/0/0 (0x4b515545)

0: dcec4200 ND_MICROSEGMENT 2048/0/0/0 (0x4b515545)

0: dcec4300 ND_MACNOTIFY 2048/0/0/0 (0x4b515545)

0: dcec4400 ND_MAC_EVENT 1/0/0/0 (0x4b515545)

0: d2da7800 OVERLAY_VNDEL 1/0/0/0 (0x4b515545)

0: ca5f3800 FIB6NDHRQ 1/0/0/0 (0x4b515545)

0: ca3f7600 ND_VSISUP_PKT 4096/0/0/0 (0x4b515545)

0: ca3f7400 NDSNP_PKT 4096/0/0/0 (0x4b515545)

0: ca3f7700 NDRAPG_PKT 4096/0/0/0 (0x4b515545)

0: ca3f7800 ND_EVENT 8192/0/1/0 (0x4b515545)

0: ca3f7900 ND_PKT 4096/0/1/0 (0x4b515545)

查看以上Probe信息中的“ND_PKT”字段，该字段取值表示“depth/cursize/max/drops”：

¡ “depth”为队列的容量，为固定值。

¡ “cursize”为当前队列的长度。

¡ “max”为队列的历史最大长度。

¡ “drops”为队列中丢弃的ARP报文的个数。

当“drops”不为0且“max”的值与“depth”相同时，说明因CPU繁忙导致ND报文被丢弃。如果“drops”为0，请执行第（5）步。

(5) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息。

5. 告警与日志

4.6 ARP故障处理

4.6.1 无法学习到ARP表项

1. 故障描述

设备无法学习到ARP表项，导致设备无法正常转发流量。

2. 常见原因

本类故障的常见原因主要包括：

· 内存不足导致无法学习到ARP表项。

· 接口物理层未正常Up。

· 接口下配置的IP地址与对端接口不在同一网段。

· ARP报文未上送到CPU。

· CPU繁忙导致ARP报文被丢弃。

3. 故障分析

本类故障的诊断流程如图4-9所示。

图4-9 无法学习到ARP表项的故障诊断流程图

4. 处理步骤

(1) 通过display memory-threshold命令查看是否由于内存不足导致无法学习到ARP表项。

<Sysname> display memory-threshold

Memory usage threshold: 100%

Free-memory thresholds:

Minor: 96M

Severe: 64M

Critical: 48M

Normal: 128M

Early-warning: 256M

Secure: 304M

Current free-memory state: Normal (secure)

¡ 若系统当前内存使用状态（Current free-memory state）为“Normal”或“Normal (secure)”，请继续执行第（2）步。

(2) 查看网络配置以及接口状态。

依次检查如下配置：

a. 通过display interface命令查看接口是否处于UP状态。如果接口没有处于UP状态，请排查物理接口故障问题。

b. 通过display fib ip-address命令查看FIB表项的信息，ip-address为ARP表项的IP地址。如果不存在对应的FIB表项，则说明可能路由模块发生故障，请检查路由模块配置并排查问题。如果FIB表存在且转发的下一跳地址不是直连下一跳地址，则需检查设备与转发下一跳地址的连接情况。

c. 通过display ip interface命令查看接口的IP地址：

- 本端接口的IP地址是否与对端接口在同一网段。如果两端接口的IP地址不在同一网段，请在接口视图下执行ip address命令修改两端的IP地址，使其在同一网段。

- 本端接口的IP地址是否与对端接口的IP地址发生冲突。如果两端接口的IP地址发生冲突，请在接口视图下执行ip address命令修改两端的IP地址，使冲突消失。

- 查看对端接口是否为转发的下一跳所在的接口。

d. 通过ping命令检查链路是否存在故障。

(3) 检查ARP报文是否正常收发。

a. 先通过debugging arp packet命令打开ARP的报文调试信息开关，再通过ping命令查看设备是否正常发送和接收ARP报文。

<Sysname> debugging arp packet

<Sysname> ping –c 1 1.1.1.2

Ping 1.1.1.2 (1.1.1.2): 56 data bytes, press CTRL+C to break

56 bytes from 1.1.1.2: icmp_seq=0 ttl=255 time=2.511 ms

--- Ping statistics for 1.1.1.2 ---

1 packet(s) transmitted, 1 packet(s) received, 0.0% packet loss

round-trip min/avg/max/std-dev = 2.511/2.511/2.511/nan ms

<Sysname>*Apr 18 17:28:22:879 2022 Sysname ARP/7/ARP_SEND: -MDC=1; Sent an ARP message, operation: 1, sender MAC: 68cb-978f-0106, sender IP: 1.1.1.1, target MAC: 0000-0000-0000, target IP: 1.1.1.2

以上信息表示设备成功发送一个ARP请求报文，目标IP地址为1.1.1.2，源IP地址为1.1.1.1。

*Apr 18 17:28:22:881 2022 Sysname ARP/7/ARP_RCV: -MDC=1; Received an ARP message, operation: 2, sender MAC: 68cb-9c3f-0206, sender IP: 1.1.1.2, target MAC: 68cb-978f-0106, target IP: 1.1.1.1

以上信息表示设备成功收到一个ARP应答报文，目标IP地址为1.1.1.1，源IP地址为1.1.1.2

¡ 若设备成功的发送和接收了ARP报文，请继续执行第（4）步。

¡ 若设备没有成功的发送和接收ARP报文，请执行第b步。

b. 通过debugging arp error命令用来打开ARP的错误调试信息开关，根据。表4-2中的内容确认设备无法成功发送或接收ARP报文的原因。

表4-2 debugging arp error命令显示信息描述表

字段	描述
Packet discarded for the network state of receiving interface is down.	接收接口网络层状态down，报文被丢弃
Packet discarded for the ARP packet is too short.	ARP报文长度太短，报文被丢弃
Packet discarded for the ARP packet is error.	ARP报文错误，报文被丢弃
Packet discarded for the link state of the port is down.	端口链路层状态down，报文被丢弃
Packet discarded for the sender IP is invalid.	报文源IP地址无效，报文被丢弃
Packet discarded for the sender IP is a broadcast IP.	报文源IP地址为广播IP，报文被丢弃
Packet discarded for the target IP is invaild.	报文请求的IP地址无效，报文被丢弃
Packet discarded for the target IP is a broadcast IP.	报文请求的IP地址为广播IP，报文被丢弃
Failed to get the source MAC of the ARP reply.	获取应答报文的源MAC失败
Packet discarded for the source MAC is a multicast address.	源MAC是组播MAC，报文被丢弃
Packet discarded for the source MAC is a broadcast address.	源MAC是广播MAC，报文被丢弃
Packet discarded for the sender MAC address is the same as the receiving interface.	源MAC和接口MAC相同，报文被丢弃
Packet discarded for the number of ARP entries reaches the limit.	ARP表项数目达到上限，报文被丢弃
Packet discarded for the type of receiving interface is L2VE.	报文入端口是L2VE口，报文被丢弃
Packet discarded for conflict with static entry.	和静态配置冲突，报文被丢弃
Packet discarded for memory alarm notification.	设备内存告警，报文被丢弃
Packet discarded for insufficient resources.	设备资源不足，导致ARP报文处理失败，报文被丢弃

(4) 确认是否由于CPU繁忙导致ARP报文被丢弃。通过view命令查看系统目录/proc/kque下的ARP的相关内容，确认ARP报文的丢弃情况及丢弃原因。

[Sysname-probe] view /proc/kque | in ARP

0: dd0e0800 ARP_TIMER 128/0/13/0 (0x4b515545)

0: dd0e0900 ARP_SINGLEEVENT 1/0/0/0 (0x4b515545)

0: dd0e0a00 ARP_SEND 1024/0/0/0 (0x4b515545)

0: dd0e0b00 ARP_RULE 4096/0/0/0 (0x4b515545)

0: dd0e0c00 ARP_RULE_ENTRY 4096/0/0/0 (0x4b515545)

0: dd0e0d00 ARP_RBHASHNOTIFY 1/0/0/0 (0x4b515545)

0: dd0e0f00 ARP_DTC 2048/0/0/0 (0x4b515545)

0: dd0e6200 ARP_MICROSEGMENT 2048/0/0/0 (0x4b515545)

0: dd0e6300 ARP_MACNOTIFY 4096/0/0/0 (0x4b515545)

0: dd0e6400 ARP_UNKNOWNSMAC_EVENT 1/0/0/0 (0x4b515545)

0: d06e5900 ARPSNP_PKT 4096/0/0/0 (0x4b515545)

0: d06e5a00 ARP_VSISUP_PKT 4096/0/0/0 (0x4b515545)

0: d06e5b00 ARP_EVENT 8192/0/2/0 (0x4b515545)

0: d06e5c00 ARP_FREQEVENT 8192/0/1/0 (0x4b515545)

0: d06e5d00 ARP_MACNOTIFYEVENT 1/0/0/0 (0x4b515545)

0: d06e5e00 ARP_PKT 4096/0/2/0 (0x4b515545)

0: ca5f3400 FIBARPHRQ 1/0/0/0 (0x4b515545)

查看以上Probe信息中的“ARP_PKT”字段，该字段取值表示“depth/cursize/max/drops”：

¡ “depth”为队列的容量，为固定值。

¡ “cursize”为当前队列的长度。

¡ “max”为队列的历史最大长度。

¡ “drops”为队列中丢弃的ARP报文的个数。

当“drops”不为0且“max”的值与“depth”相同时，说明因CPU繁忙导致ARP报文被丢弃。如果“drops”为0，请执行第（5）步。

(5) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息。

5. 告警与日志

4.6.2 不回应ARP请求报文

1. 故障描述

设备收到对端设备发送到ARP请求报文后，不回应ARP应答报文。

2. 常见原因

本类故障的常见原因主要包括：

· 接口收到的ARP请求报文的目的IP不是本机IP。

· 端设备发送的ARP请求报文触发了本端的源MAC地址固定的ARP攻击检测功能。

3. 故障分析

本类故障的诊断流程如图4-10所示。

图4-10 不回应ARP请求报文故障诊断流程图

4. 处理步骤

(1) 查看ARP报文信息，确认ARP报文是否已上送到CPU处理。

a. 先通过debugging arp packet命令打开ARP的报文调试信息开关，再触发对端设备向本端发送ARP请求报文。

<Sysname> debugging arp packet

<Sysname> *Apr 21 17:38:05:489 2022 Sysname ARP/7/ARP_RCV: -MDC=1; Received an ARP message, operation: 1, sender MAC: 68cb-9c3f-0206, sender IP: 1.1.1.2, target MAC: 0000-0000-0000, target IP: 1.1.1.1

¡ 如果“target IP”不是本机IP，请检查对端设备的路由表和转发表。

¡ 如果“target IP”是本机IP，请执行步骤b。

b. 通过debugging arp error命令打开ARP的错误调试信息开关，根据表4-3中的内容确认设备不回应ARP报文的原因。

表4-3 debugging arp error命令显示信息描述表

字段	描述
Packet discarded for the network state of receiving interface is down.	接收接口网络层状态down，报文被丢弃
Packet discarded for the ARP packet is too short.	ARP报文长度太短，报文被丢弃
Packet discarded for the ARP packet is error.	ARP报文错误，报文被丢弃
Packet discarded for the link state of the port is down.	端口链路层状态down，报文被丢弃
Packet discarded for the sender IP is invalid.	报文源IP地址无效，报文被丢弃
Packet discarded for the sender IP is a broadcast IP.	报文源IP地址为广播IP，报文被丢弃
Packet discarded for the target IP is invaild.	报文请求的IP地址无效，报文被丢弃
Packet discarded for the target IP is a broadcast IP.	报文请求的IP地址为广播IP，报文被丢弃
Failed to get the source MAC of the ARP reply.	获取应答报文的源MAC失败
Packet discarded for the source MAC is a multicast address.	源MAC是组播MAC，报文被丢弃
Packet discarded for the source MAC is a broadcast address.	源MAC是广播MAC，报文被丢弃
Packet discarded for the sender MAC address is the same as the receiving interface.	源MAC和接口MAC相同，报文被丢弃
Packet discarded for the number of ARP entries reaches the limit.	ARP表项数目达到上限，报文被丢弃
Packet discarded for the type of receiving interface is L2VE.	报文入端口是L2VE口，报文被丢弃
Packet discarded for conflict with static entry.	和静态配置冲突，报文被丢弃
Packet discarded for memory alarm notification.	设备内存告警，报文被丢弃
Packet discarded for insufficient resources.	设备资源不足，导致ARP报文处理失败，报文被丢弃

(2) 查看对端设备的MAC是否被加入攻击表项中。以本端接口GigabitEthernet1/0/1为例，通过display arp source-mac命令显示检测到的源MAC地址固定的ARP攻击检测表项。

<Sysname> display arp source-mac interface gigabitethernet 1/0/1

Source-MAC VLAN/VSI name Interface Aging-time (sec)

23f3-1122-3344 4094 GE1/0/1 10

¡ 如果存在源MAC地址固定的ARP攻击检测表项，且表项的MAC地址是对端设备的MAC地址，请根据业务情况通过arp source-mac threshold命令配置源MAC地址固定的ARP报文攻击检测阈值。

¡ 如果不存在对端设备MAC地址对应的源MAC地址固定的ARP攻击检测表项，请执行（3）。

(3) 通过debugging arp entry命令打开ARP表项状态调试信息开关，查看ARP表项的状态，收集ARP表项状态相关日志，发送给H3C技术支持工程师。

<Sysname> debugging arp entry

<Sysname> ping -c 1 192.168.111.188

PING 192.168.111.188 (192.168.111.188): 56 data bytes, press CTRL_C to break

56 bytes from 192.168.111.188: icmp_seq=0 ttl=128 time=1.000 ms

--- 192.168.111.188 ping statistics ---

1 packet(s) transmitted, 1 packet(s) received, 0.0% packet loss

round-trip min/avg/max/std-dev = 1.000/1.000/1.000/0.000 ms

*Dec 17 14:28:34:762 2012 Sysname ARP/7/ARP_ENTRY: -MDC=1; ARP entry status ch

anged: MAC address: 000a-eb83-691e, IP address: 192.168.111.188, INITIALIZE -> N

O_AGE

表4-4 debugging ARP entry命令显示信息描述表

字段	描述
ARP entry status changed	ARP表项发生变化
MAC address	ARP表项的MAC地址
IP address	ARP表项的IP地址
state1->state2	从状态state1迁移到状态state2，共有四种状态： · INITIALIZE：未解析状态 · NO_AGE：不老化状态 · AGING：老化处理状态 · AGED：老化待删除状态

(4) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息。

5. 告警与日志

4.7 NTP故障处理

4.7.1 NTP时钟未同步故障处理

1. 故障描述

设备作为NTP客户端，未能同步NTP服务器端的时钟。在设备上执行display ntp-service status命令，显示信息中Clock status字段的取值为unsynchronized，表示NTP时钟未同步。

2. 常见原因

本类故障的常见原因主要包括：

· NTP配置错误。

· NTP时间同步链路不通。

· 链路震荡，时延不稳定。

· NTP服务器端时间同步异常。

3. 故障分析

本类故障的诊断流程如图4-11所示。

图4-11 NTP时钟不同步的故障诊断流程图

4. 处理步骤

NTP支持以下几种工作模式：

· 客户端/服务器模式

· 对等体模式

· 广播模式

· 组播模式

其中客户端/服务器模式、广播模式和组播模式均基于C/S模型。以下处理步骤基于C/S模型，设备作为客户端、NTP时钟未同步的情况进行描述。如果采用对等体模式由本端同步对端的时间，也可使用下述处理步骤，此时本端相当于C/S模型中的客户端。

(1) 在设备上执行display ntp-service [ ipv6 ] sessions命令，如果没有显示信息，则表示未开启NTP功能，请参照配置手册先配置NTP功能。如果有显示信息，请按照以下步骤定位：

a. 查看source字段的取值是否为预期的NTP服务器端的IP地址。如果不是，请执行步骤（5）修改NTP的配置。

b. 对于IPv4 NTP功能，请查看stra字段的取值，对于IPv6 NTP功能，请查看Clock stratum字段的取值，如果取值为16，请登录NTP服务器端并执行ntp-service refclock-master命令修改NTP服务器端的NTP层级。时钟层数为16的设备不能对外提供时钟。

c. 对于IPv4 NTP功能，请查看reach字段的取值，对于IPv6 NTP功能，请查看Reachabilities字段的取值，如果取值为0，表示路由不可达，请执行步骤（3）来处理。

IPv4 NTP会话显示信息样例：

<Sysname> display ntp-service sessions

source reference stra reach poll now offset delay disper

********************************************************************************

[12345]LOCAL(0) LOCL 0 1 64 - 0.0000 0.0000 7937.9

[5]1.1.1.1 INIT 16 0 64 - 0.0000 0.0000 0.0000

Notes: 1 source(master), 2 source(peer), 3 selected, 4 candidate, 5 configured.

Total sessions: 1

IPv6 NTP会话显示信息样例：

<Sysname> display ntp-service ipv6 sessions

Notes: 1 source(master), 2 source(peer), 3 selected, 4 candidate, 5 configured.

Source: [12345]3000::32

Reference: 127.127.1.0 Clock stratum: 2

Reachabilities: 1 Poll interval: 64

Last receive time: 6 Offset: -0.0

Roundtrip delay: 0.0 Dispersion: 0.0

Total sessions: 1

(2) 检查NTP相关配置是否正确。

根据组网规划，确认设备使用的NTP工作模式。根据NTP使用的工作模式，在设备上执行display current-configuration | include ntp-service命令查看NTP相关配置，来进一步排查当前NTP相关配置是否正确。例如，当采用客户端/服务器模式，并且本端作为客户端进行时间同步时，要求：

¡ 服务器地址配置必须正确，对应的配置命令为系统视图下的ntp-service [ ipv6 ] unicast-server。

¡ 系统时间的获取方式为NTP，对应的配置命令为系统视图下的clock protocol ntp。

¡ 如果需要使用NTP验证功能，还要求在设备和NTP服务器端上均配置的认证密钥必须一致，且本设备上使用的认证密钥对应的秘钥ID在对端设备上是可信的。对应的配置命令为系统视图下的ntp-service authentication-keyid（配置的认证密钥）和ntp-service reliable authentication-keyid（配置认证密钥对应的秘钥ID是可信的）。

(3) 执行ping命令，检查设备和NTP服务器端之间是否路由可达。

¡ 如果可以Ping通，说明设备和NTP服务器端之间路由可达，请执行步骤（4）。

¡ 如果无法Ping通，请参见“Ping不通”故障处理方式，先解决网络不通问题。待设备和网管之间可以Ping通后，再执行步骤（4）。

(4) 配置debugging ntp-service all命令打开NTP调试信息开关，查看调试信息，出现以下两种情况时，本端不会同步NTP服务器端的时钟：

¡ 如果调试信息中出现“The packet from ip-address failed the validity tests result”，则表示设备从NTP服务器（IP地址为ip-address）接收到的报文未通过合法性检查，检查结果为result，设备不会同步该NTP服务器的时钟。

¡ NTP报文调试信息中，“rdel: delay”、“rdsp: disper”，如果delay>16000、disper>16000或delay/2+disper>16000，则表示NTP服务器提供的时钟偏差过大，设备不会同步该NTP服务器的时钟。

(5) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息。

NTP报文交互较慢，使用debugging ntp-service all命令开启NTP调试信息开关后，请等待5～10分钟后再收集调试信息。

5. 告警与日志

4.8 Ping和Tracert故障处理

4.8.1 Ping不通

1. 故障描述

在源端执行Ping操作，在一定时间范围内没有收到目的端对该请求的回应。

2. 常见原因

存在三种故障情形：

· 源端没有发出请求报文。

· 目的端没有发出应答报文。

· 中间设备丢包或传输时间长。

本类故障的常见原因主要包括：

· 链路传输时延较长。由于传输时延长，虽然源端接收到了目的端的回应报文，但已经超过等待时限而造成Ping不通的现象。

· 配置不当。例如，当Ping报文过大时，报文的出接口MTU值较小，且设置了不可分片的功能等。

· FIB表或ARP表中缺少对应的表项。

· 存在防攻击配置。

· 硬件故障。

3. 故障分析

本类故障的诊断思路如下：

(1) 检查Ping操作是否得当，调整Ping操作参数。

(2) 查看Ping报文的统计信息，确认出问题的节点。

(3) 检查是否存在到达目的端的ARP以及FIB表项。

(4) 排查是否因为防攻击配置导致Ping报文被丢弃。

本类故障的诊断流程如图4-12所示。

图4-12 Ping不通故障诊断流程图

4. 处理步骤

(1) 检查Ping操作是否得当。

a. 检查是否因为实际链路传输时延较长导致Ping不通。

检查是否执行了ping -t timeout命令，如果执行了此操作，可通过增加-t参数的值（建议取值大于等于1000，达到秒级）或者去掉-t参数重新Ping。如果故障消除，则说明较大概率属于实际网络时延大导致的Ping不通；如果故障未消除，请继续定位。

-t参数用来指定ICMP回显应答（ECHO-REPLY）报文的超时时间，单位为毫秒，缺省值为2000。如果源端在timeout时间内未收到目的端的ICMP回显应答（ECHO-REPLY）报文，则会认为目的端不可达。

b. 检查是否因为Ping报文过大而被丢弃。

检查是否执行了ping -f –s packet-size命令，如果执行了此操作，且报文转发路径上存在出接口的MTU小于报文长度packet-size的情况，则会导致报文因为超大且不允许被分片而被丢弃。可以通过减小报文长度或者取消-f参数来解决这个问题。

· -f参数表示将长度大于出接口MTU的报文直接丢弃，即不允许对发送的ICMP回显请求报文进行分片。

· -s packet-size参数用来指定发送的ICMP回显请求报文的长度（不包括IP和ICMP报文头），单位为字节，缺省值为56。

以太网接口MTU的缺省值为1500字节，可以通过执行display interface命令来查看接口的MTU值：

<Sysname> display interface gigabitethernet 1/0/1

GigabitEthernet1/0/1

Current state: UP

Line protocol state: UP

Description: GigabitEthernet1/0/1 Interface

Bandwidth: 1000000 kbps

Maximum transmission unit: 1500

其它显示信息略……

c. 检查是否指定了错误的出接口。

检查是否执行了ping -i interface-type interface-number命令指定Ping报文的出接口。如果指定了出接口，请确保该接口和目的端之间的物理链路是否可达。否则，请换成其它接口或者去掉-i参数。

-i interface-type interface-number参数用来指定发送ICMP回显请求报文的接口的类型和编号。不指定该参数时，将根据目的IP查找路由表或者转发表来确定发送ICMP回显请求报文的接口。

d. 检查是否指定了源地址。

检查是否执行了ping –a source-ip命令指定Ping报文的源地址。如果执行了该命令，请确保中间设备和目的端有到达源地址source-ip的路由。

-a source-ip：指定ICMP回显请求（ECHO-REQUEST）报文的源IP地址。该地址必须是设备上已配置的IP地址。不指定该参数时，ICMP回显请求报文的源IP地址是该报文出接口的主IP地址。

e. 检查是否为目的端指定了准确的VPN。

根据网络规划和部署情况，确认目的端是否属于某个VPN。如果目的端属于某个VPN，则需要在执行ping命令时通过-vpn-instance参数指定目的端所属的VPN。

(2) 查看源端、目的端以及中间设备的收发包统计，确认Ping故障发生的方向。

¡ 检查源端是否发出了ICMP回显请求报文，并收到了ICMP回显应答报文。

源端执行Ping操作后，在源端和目的端分别使用display icmp statistics命令查看ICMP报文收发情况。可以根据统计信息中Input和Output区段报文的数量来确定Ping出现问题的方向：

- 如果源端Output区段的echo值正常增加，但Input区段的echo replies值没有增加，则说明源端发出了请求但是没有收到回应；与此同时，如果目的端Input区段和Output区段的计数都没有变化，则说明目的端没有收到请求也没有给予回应。这样，就可以确定Ping报文是在从源端到目的端的方向上出现了转发故障。

- 如果源端Output区段的echo值正常增加，但Input区段的echo replies值没有增加，则说明源端发出了请求但是没有收到回应；与此同时，如果目的端Input区段和Output区段的计数都正常增加，则说明目的端收到了请求，同时发出了回应。这样，就可以确定Ping报文是在从目的端到源端的方向上出现了转发故障。

display icmp statistics命令显示信息示例如下：

<Sysname> display icmp statistics

Input: bad formats 0 bad checksum 0

echo 1 destination unreachable 0

source quench 0 redirects 0

echo replies 0 parameter problem 0

timestamp 0 information requests 0

mask requests 0 mask replies 0

time exceeded 0 invalid type 0

router advert 0 router solicit 0

broadcast/multicast echo requests ignored 0

broadcast/multicast timestamp requests ignored 0

Output: echo 0 destination unreachable 0

source quench 0 redirects 0

echo replies 1 parameter problem 0
timestamp 0 information replies 0

mask requests 0 mask replies 0

time exceeded 0 bad address 0

packet error 0 router advert 0

其它显示信息略……

当目的端是框式设备或者IRF设备，但ICMP报文到达目的端前被分片了，请在目的端执行display icmp statistics命令来查看ICMP报文统计信息即可。

(3) 确定出问题的节点。

确定了Ping故障的发生的方向后，请执行tracert命令确定该方向上报文丢失的位置。

¡ 如果源端到目的端方向出现了问题，请从源端开始排查。

¡ 如果目的端到源端方向出现问题，请从目的端开始排查。

如下例所示，可以通过tracert命令查看报文从源端到目的端（IP地址为1.1.3.2，属于vpn1）所经过的路径，并显示报文经过的私网中的三层设备的信息。

<Sysname> tracert –vpn-instance vpn1 –resolve-as vpn 1.1.3.2

traceroute to 1.1.3.2 (1.1.3.2), 30 hops at most, 40 bytes each packet, press CTRL+C to break

1 1.1.1.2 (1.1.1.2) 673 ms 425 ms 30 ms

2 1.1.2.2 (1.1.2.2) 580 ms 470 ms 80 ms

3 * * *

由以上信息可判断，Ping报文在1.1.2.2的下一跳设备上（即显示为“3 * * *”的节点）出现转发故障。

(4) 检查是否存在到达目的端和源端的FIB表项与ARP表项。

请在问题节点上执行以下操作：

¡ 执行display fib命令检查是否存在到达目的端和源端的路由。如果路由不存在，请检查OSPF、IS-IS、BGP等路由协议配置是否有误。

¡ 如果路由存在并且报文所经链路是以太链路，请执行display arp命令查看是否存在所需的ARP表项。如果ARP表项不存在，请首先排查ARP故障。

(5) 检查问题节点上是否配置ICMP防攻击功能。

如果设备上配置了ICMP攻击相关的防范策略，且设备检测到ICMP攻击，设备会将ICMP报文直接丢弃，从而导致Ping不通。

¡ 通过display attack-defense icmp-flood statistics ip命令查看统计信息的计数来判断设备是否受到了ICMP攻击。

¡ 通过display current-configuration | include icmp-flood、display current-configuration | include “signature detect”查看当前是否配置攻击防范策略。

如果设备受到了ICMP攻击，请先定位并解除ICMP攻击。

(6) 根据收发包统计，确认丢包位置和丢包原因。

在Ping报文途径的设备上：

a. 配置QoS策略，使用ACL源地址和目的地址过滤Ping报文，然后在Ping报文途径接口的入方向和出方向应用QoS策略。

b. 通过display qos policy interface命令查看应用QoS策略的接口上QoS策略匹配成功的报文个数。如果报文个数有增长，则说明设备收到了Ping报文；如果报文个数无增长，则说明设备没有收到Ping报文，此时，可以使用debugging ip packet命令打开IP报文调试信息开关，进一步排查设备没有收到Ping报文的原因并解决问题。

(7) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息。

5. 告警与日志

4.8.2 Tracert不通

1. 故障描述

执行Tracert操作，显示信息中出现“* * *”行，说明某些节点之间路由不可达，Tracert不通。

2. 常见原因

本类故障的常见原因主要包括：

· 无对应的路由或者ARP表项。

· 中间设备未开启ICMP超时报文发送功能。

· 目的端未开启ICMP目的不可达报文发送功能。

3. 故障分析

本类故障的诊断思路如下：

(1) 检查中间设备是否开启了ICMP超时报文发送功能。

(2) 检查目的端是否开启了ICMP目的不可达报文发送功能。

(3) 检查是否存在达到目的端的ARP以及FIB表项。

本类故障的诊断流程如图4-13所示。

图4-13 Tracert不通故障诊断流程图

4. 处理步骤

(1) 检查中间设备是否开启了ICMP超时报文发送功能。

# 查看报文从源端到目的端所经过的路径（假设源端到目的端只有两跳，目的端的IP地址为1.1.2.2）。

<Sysname> tracert 1.1.2.2

traceroute to 1.1.2.2 (1.1.2.2), 30 hops at most, 40 bytes each packet, press CTRL+C to break

1 * * *

2 1.1.2.2 (1.1.2.2) [AS 100] 580 ms 470 ms 80 ms

出现以上显示信息时，请登录中间设备，在中间设备上执行ip ttl-expires enable命令开启ICMP超时报文发送功能。如果故障排除，则说明中间设备未开启ICMP超时报文发送功能导致Tracert不通；如果故障未排除，请继续执行下面的步骤。

(2) 检查目的端是否开启了ICMP目的不可达报文发送功能。

# 查看报文从源端到目的端所经过的路径（假设源端到目的端只有两跳，目的端的IP地址为1.1.2.2）。

<Sysname> tracert 1.1.2.2

traceroute to 1.1.2.2 (1.1.2.2), 30 hops at most, 40 bytes each packet, press CTRL+C to break

1 1.1.1.2 (1.1.1.2) [AS 99] 560 ms 430 ms 50 ms

2 * * *

出现以上显示信息时，请在目的端执行ip unreachables enable命令开启ICMP目的不可达报文发送功能。如果故障排除，则说明目的端未开启ICMP目的不可达报文发送功能；如果故障未排除，请继续执行下面的步骤。

(3) 在问题节点上检查是否存在对应的FIB表项和ARP表项。

在未回应ICMP差错报文的设备（tracert命令执行结果中显示为“* * *”的设备）上执行display fib命令，检查是否存在到目的地址的路由。

¡ 如果路由不存在，请检查OSPF、IS-IS、BGP等路由协议配置是否有误。

¡ 如果路由存在并且报文所经链路是以太链路，请执行display arp命令查看Tracert的下一跳地址对应的ARP表项是否存在。如果不存在，请检查ARP配置是否有误。

(4) 检查Tracert发起端是否收到ICMP差错报文。

发起Tracert后，在Tracert发起端上多次执行display icmp statistics命令查看发起端是否收到ICMP差错报文，显示信息示例如下：

<Sysname> display icmp statistics

Input: bad formats 0 bad checksum 0

echo 0 destination unreachable 9

source quench 0 redirects 0

echo replies 7 parameter problem 0

timestamp 0 information requests 0

mask requests 0 mask replies 0

time exceeded 3 invalid type 0

router advert 0 router solicit 0

broadcast/multicast echo requests ignored 0

broadcast/multicast timestamp requests ignored 0

其它显示信息略……

观察以上ICMP报文的统计信息的变化，判断Input区段内的time exceeded和destination unreachable值的增量是否与Tracert报文发送个数相等，如果不等则表明发起端未收到ICMP差错报文。

(5) 根据收发包统计，确认丢包位置和丢包原因。

在Tracert报文途径的设备上：

a. 配置QoS策略，使用ACL源地址和目的地址过滤Tracert报文，然后在Tracert报文途径接口的入方向和出方向应用QoS策略。

b. 通过display qos policy interface命令查看应用QoS策略的接口上QoS策略匹配成功的报文个数。如果报文个数有增长，则说明设备收到了Tracert报文；如果报文个数无增长，则说明设备没有收到Tracert报文，此时，可以使用debugging ip packet命令打开IP报文调试信息开关，进一步排查设备没有收到Tracert报文的原因并解决问题。

(6) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息。

5. 告警与日志

4.9 广域网故障处理

4.9.1 接入5G网络后E-Ch1/0/1:0接口未获取到IP地址

1. 故障描述

CPE5100接入5G网络后，E-Ch1/0/1:0接口没有正常获取到IP地址。

2. 常见原因

本类故障的常见原因主要包括：

· 拨号参数（APN、用户名、密码等）配置错误

· NR信号质量差

· IMS的APN配置影响

3. 故障分析

4. 处理步骤

(1) 检查拨号配置（APN、用户名、密码等）是否正确。如果不正确，则需要修改为正确的配置。

(2) 检查接入小区的信号质量。在任意视图下执行display cellular命令可以查看接入小区的信号质量信息。如果信号质量差，可以能会导致不能正常接入，建议将设备放置在好点。信号质量参考值如下：

¡ 极好点：RSRP > -85dBm；SINR > 25。

¡ 好点：-85dBm ≥ RSRP > -95dBm；25 ≥ SINR ≥ 16。

¡ 中点：-95dBm ≥ RSRP > -105dBm；15 ≥ SINR ≥ 11。

¡ 差点：-105dBm ≥ RSRP > -115dBm；10 ≥ SINR ≥ 3。

¡ 极差点：RSRP ≤ -115dBm；SINR < 3。

(3) 有些SIM卡（如物联网卡等）需要去除IMS的APN配置，否则可能会拨号失败。

a. 进入Cellular接口视图。

b. 在Cellular接口视图下执行“sendat at+qnvfw=\”/nv/item_files/ims/IMS_enable\”,00”。

c. 掉电重启CPE。

(4) 如果故障仍然未能排除，请联系技术支持人员。

4.10 Portal故障处理

4.10.1 Portal认证页面无法弹出

1. 故障描述

用户访问任意非Portal Web服务器网页，或者直接访问Portal Web服务器，无法推出Portal登录页面。

2. 常见原因

本类故障的常见原因主要包括：

· 主机、服务器和设备之间的路由不通。

· 浏览器开启了HTTP代理功能。

· 用户输入的网址内携带了非标准的TCP端口号。

· 中间网络或DNS服务器出现问题。

· 设备上的HTTPS重定向功能不能正常使用。

· 用户访问的HTTPS协议的网站开启了HSTS（HTTP Strict Transport Security，HTTP严格传输安全协议）功能。

· Portal服务器无法识别转义后的URL特殊字符。

· Portal服务器配置错误。

3. 故障分析

本类故障的诊断流程如图4-14所示：

图4-14 Portal认证页面无法弹出的故障诊断流程图

4. 处理步骤

(1) 确认终端和Portal服务器上的路由配置是否正确。

在终端上关闭防火墙功能后，执行Ping操作检查Portal服务器是否可达，如果Ping不通，首先需要确认终端和Portal服务器上的路由配置是否正确，同时需要注意：

¡ Portal服务器到终端的回程路由是否配置正确。

¡ 终端或者Portal服务器上是否存在有多个网卡。

在有多个网卡的情况下，终端和服务器之间的流量不一定全部经过配置有Portal认证的网络。以Windows终端为例，在cmd窗口上执行route print命令查看具体的路由信息，然后确定用户的Web访问流量是从哪个网卡出去。

最后，采取分段Ping的手段定位问题。首先从终端Ping网关（需要先取消认证，否则Ping不通），然后再从网关上Ping服务器。

(2) 终端的浏览器上是否开启了HTTP代理功能。

浏览器上开启了HTTP代理功能会导致用户无法访问Portal认证页面。以Windows IE浏览器为例，请打开IE浏览器，单击“工具”，选择“Internet选项>连接>局域网设置>代理服务器”中，关闭HTTP代理功能。

(3) 输入的网址是否使用非标准TCP端口

非标准TCP端口是指非80或非443端口。用户输入的网址中若包含非标准TCP端口，会导致Portal认证页面无法弹出，例如http://10.1.1.1:18008。对于HTTP协议的网址，请使用80；对于HTTPS协议的网址，请使用443。

(4) 中间网络或DNS服务器出现问题。

a. 确认设备上是否将DNS服务器IP地址配置为允许访问的地址。

b. 检查中间网络连通性以及排查DNS服务器故障，在网关上进行流量统计（分别对连接终端下行接口和连接DNS服务器的上行接口）或镜像获取终端访问DNS服务器的报文，确认网关是否已将DNS请求发出，但却未收到回应报文。

(5) HTTPS网站开启了HSTS功能。

HTTPS网站开启了HSTS功能后，要求浏览器必须使用HTTPS访问，而且证书必须要合法。设备对用户浏览器进行HTTPS重定向时，设备会使用自签名证书（设备没有目标网站的证书，只能使用自签名证书）伪装成目标网站和浏览器建立SSL连接，此时浏览器一旦检测到证书不受信任，将会导致HTTPS重定向失败，无法弹出Portal认证页面。这种情况依赖于具体网站配置的HSTS协议的强制要求，无法解决。此时，建议用户更换其他网站进行尝试。

(6) Portal服务器不支持URL特殊字符的编码。

在实际应用中，一些Portal Web服务器无法识别URL中“$-_.+!*'();,/?:@”中任意字符的组合的转义字符，会导致Portal Web服务器向客户端提供Web认证页面失败。此时，请在设备上通过portal url-unescape-chars命令对这些特殊字符不进行转义处理。

# 配置重定向给用户的Portal Web服务器URL中不转义的特殊字符为“;()”。

<Sysname> system-view

[Sysname] portal url-unescape-chars ;()

(7) Portal服务器配置是否正确。

¡ 检查Portal服务器上是否配置了IP地址组，以及是否将设备与IP地址组关联。

¡ 检查终端IP地址是否在Portal服务器上配置的IP地址组范围内。

(8) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息和告警信息。

¡ 服务器上Portal相关配置截图。

¡ 设备与服务器之间的抓包文件。

¡ 在浏览器上对问题现象进行截图。

¡ 在设备上通过display portal rule命令查看用于报文匹配的Portal过滤规则信息。

¡ 出现问题时，在设备上通过debugging portal、debugging http-redirect all和debugging ip packet命令收集Debug信息。

5. 告警与日志

4.10.2 Portal认证失败

1. 故障描述

Portal用户认证失败或者认证异常。

2. 常见原因

本类故障的常见原因主要包括：

· 设备上Portal服务器视图下配置的共享密钥和Portal认证服务器上配置的不一致。

· 设备上Portal服务器视图下配置的Portal认证服务器地址不存在。

· Portal报文非法。

· Portal用户使用的认证域配置错误。

· RADIUS视图下配置共享密钥与RADIUS服务器上配置的不一致。

· 获取用户物理信息失败。

· RADIUS服务器认证拒绝。

· RADIUS服务器无响应。

· 授权ACL或者User Profile下发失败。

3. 故障分析

本类故障的诊断流程如图4-15所示。

图4-15 Portal认证失败的故障诊断流程图

4. 处理步骤

(1) 检查设备上Portal服务器视图下配置的共享密钥与Portal认证服务器上配置的是否一致。

如图4-16所示，以iMC服务器为例，当输入“用户名”和“账号密码”，点击“上线”后登录界面上出现“向设备发送请求超时”的提示，表示设备上Portal服务器视图下配置的共享密钥有可能与服务器上配置的不一致。

图4-16 Portal登录界面打印错误提示

此时，可以通过如下方法来检查：

¡ 在设备上执行debugging portal error命令，打开Portal错误调试信息开关。如果设备上打印如下信息，则可以确认设备和Portal服务器配置的共享密钥不一致。

*Jul 28 17:51:20:774 2021 Sysname PORTAL/7/ERROR: -MDC=1; Packet validity check failed due to invalid key.

¡ 通过display portal auth-error-record命令查看用户Portal认证异常记录中的Auth error reason字段是否显示为“Packet validity check failed due to invalid authenticator”。

如果确认不一致，请修改设备上Portal服务器视图下配置的共享密钥或者Portal认证服务器上配置的共享密钥，使其两者保持一致。

(2) 检查设备上Portal服务器视图下配置的Portal认证服务器地址是否存在。

当设备收到Portal服务器发送的认证报文时，设备会校验报文的源IP地址是否在设备上已配置的Portal认证服务器地址列表中。如果不在，则认为认证报文是非法报文，会将它丢弃。

如图4-17所示，以iMC服务器为例，当输入“用户名”和“账号密码”，点击“上线”后登录界面上出现“向设备发送请求超时”的提示，表示设备上Portal服务器视图下配置的Portal认证服务器地址可能不存在。

图4-17 Portal登录界面打印错误提示

此时，可以通过如下方法来检查：

¡ 在设备上执行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.

¡ 通过display portal auth-error-record命令查看用户Portal认证异常记录，查看Auth error reason字段中是否显示为“Packet source unknown. Server IP:X.X.X.X, VRF index:0”。

如果确认不正确，请在设备的Portal服务器视图下，执行ip命令修改Portal服务器的IP地址。

(3) 检查Portal报文是否非法。

设备收到Portal服务器发送的Portal协议报文后，会对报文做合法性校验。如果报文长度不对、报文校验段错误，则该报文将被视为非法报文而丢弃。

可以通过如下方法来检查Portal协议报文是否非法：

¡ 通过display portal packet statistics命令查看是否存在非法报文计数增长，如果存在，可通过在设备上执行debugging portal error命令，打开Portal错误调试信息开关排查具体原因。

¡ 通过display portal auth-error-record命令查看用户Portal认证异常记录，查看Auth error reason字段是否显示为“Packet type invalid”或者“Packet validity check failed because packet length and version don't match”。

如果Portal协议报文非法，请确认报文非法的原因并进行修改，使Portal协议报文成为合法报文。

(4) 检查Portal用户使用的认证域配置。

Portal用户将按照如下先后顺序选择认证域：接口或无线服务模板上指定的Portal用户使用的ISP域-->用户名中携带的ISP域-->系统缺省的ISP域。如果根据以上原则决定的认证域在设备上不存在，且设备上为未知域名的用户指定了此不存在的ISP域，将会导致用户将无法认证。

通过display portal命令查看认证接口上是否引用了认证域。

¡ 如果引用了认证域，确认设备上是否存在该认证域以及该域下的认证、授权、计费方案是否配置准确。

¡ 如果没有引用认证域，请检查用户名中携带的域是否存在，如果不存在，请检查是否存在缺省认证域并确认缺省域下配置是否正确。

如图4-18所示，以iMC为例，当输入“用户名”和“账号密码”，点击“上线”后登录界面上出现“设备拒绝请求”的提示，表示设备上认证域可能配置不正确。

图4-18 Portal登录界面打印错误提示

此时，可以通过如下方法来检查：

¡ 在设备上执行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.

¡ 通过display portal auth-fail-record命令查看Auth error reason字段是否显示为“AAA authentication failed”或“AAA returned an error”。

如果认证域配置不正确，请执行相应的命令将Portal用户使用的认证域配置修改正确。

(5) 检查RADIUS视图下配置共享密钥是否与RADIUS服务器上配置的一致。

如图4-19所示，以iMC服务器为例，当输入“用户名”和“账号密码”，点击“上线”后登录界面上出现“向设备发送请求超时”的提示，表示RADIUS视图下共享密钥和服务器上配置的不一致。

图4-19 Portal登录界面打印错误提示

在设备上执行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视图下共享密钥和服务器上配置的保持一致。

(6) 检查是否获取用户物理信息失败。

用户上线过程中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.

¡ 通过display portal auth-error-record或者display portal auth-fail-record命令查看Auth error reason字段是否显示为“Failed to obtain user physical information”或“Failed to get physical information”。

确认获取用户物理信息失败后，请排查设备是否存在该认证用户的表项，如果不存在，请进一步排查具体原因。

(7) 检查RADIUS服务器是否认证拒绝。

a. RADIUS服务器回应认证拒绝有多种原因，最常见的有用户名密码错误、RADIUS服务器授权策略无法匹配等。这些问题，首先需要查看服务器端的认证日志或者在设备上通过debugging radius error命令打开RADIUS错误调试信息开关查看相关的Debug信息找到根本原因后，再调整服务器、终端或设备配置。

b. 执行display portal auth-fail-record命令，通过查看显示信息中的Auth error reason字段确认用户Portal认证失败原因。

(8) 检查RADIUS服务器是否无响应。

可通过如下三种方式来检查RADIUS服务器是否回应。

¡ 执行display radius scheme命令，通过State字段查看服务器状态。如果为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地址必须为认证请求的源IP地址。

b. 确认设备和服务器上同时获取报文确认中间链路是否存在问题，例如中间网络存在防火墙，防火墙未放通RADIUS（默认认证端口：1812）报文。如果出现大量用户无法认证，设备上的日志里出现RADIUS服务器Down记录，那么大概率是服务器或中间网络出现异常，需要逐一排查。

(9) 检查是否授权ACL或者UserProfile下发失败。

如果设备上开启了Portal的授权信息严格检查模式，当认证服务器下发的授权ACL、User Profile在设备上不存在或者设备下发User Profile失败时，设备将强制Portal用户下线。

a. 通过查看display portal命令的Strict checking字段确认设备上是否开启了严格检查，再根据用户需求判断是否需要开启。如果不需要，直接关闭。如果需要，请执行步骤b。

b. 通过在设备上执行display acl或者display user-profile命令，确认AAA服务器是否授权了不存在的ACL或者User Profile。如果不存在，请确认服务器是否需要授权或者在设备上增加相应的ACL或User Profile配置。

(10) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息。

¡ display portal auth-error-record、display portal auth-fail-record收集信息。

¡ Portal服务器上Portal相关配置截图。

¡ 设备与AAA服务器间的抓包文件。

¡ 在客户端浏览器上对问题现象截图。

¡ 通过开启debugging portal命令收集调试信息。

5. 告警与日志

4.10.3 Portal认证用户掉线

Portal用户上线一段时间后掉线。

1. 常见原因

本类故障的常见原因主要包括：

· 用户会话超时时间超时。

· 用户闲置切断。

· 计费更新失败。

· 用户流量达到阈值。

· 服务器强制用户下线。

· 用户在线探测失败下线。

· 用户上线的接口down。

2. 故障分析

本类故障的诊断流程如图4-20所示。

图4-20 Portal认证用户掉线的故障诊断流程图

3. 处理步骤

(1) 通过portal logout-record enable命令，开启Portal用户下线信息记录功能。

(2) 检查用户会话超时时间是否超时。

如果AAA服务器给Portal用户下发了会话时长，即用户单次在线时长。用户在线时长超过会话时长后，设备会触发用户下线。

可通过如下三种方法确认是否因会话超时导致Portal用户下线：

¡ 查看AAA服务器上记录的用户下线记录。

¡ 通过display portal logout-record命令查询用户下线记录。

<Sysname> display portal logout-record all

Total logout records: 1

User name : gkt

User MAC : 0800-2700-94ad

Interface : Vlan-interface100

User IP address : 21.0.0.20

AP : N/A

SSID : N/A

User login time : 2021-07-29 11:05:58

User logout time : 2021-07-29 11:05:58

Logout reason : Session timeout

¡ 在设备上执行debugging portal error命令，打开Portal错误调试信息开关。如果设备上打印如下信息，则可以确认因用户会话超时导致Portal用户下线。

*Jul 28 17:51:20:774 2021 Sysname PORTAL/7/ERROR: -MDC=1; Session timer timed out and the user will be logged off.

用户会话超时触发的下线属于正常下线，用户重新上线即可。

(3) 检查是否为用户闲置切断。

如果设备或者AAA服务器授权了用户闲置切断时长，用户上线后，设备会周期性检测用户的流量，若某用户在指定的闲置检测时间内产生的流量小于指定的数据流量，则会被强制下线。

可通过如下三种方法确认是否因用户闲置切换功能导致Portal用户下线：

¡ 查看AAA服务器上记录的用户下线记录。

¡ 通过display portal logout-record命令查询用户下线记录。

<Sysname> display portal logout-record all

Total logout records: 1

User name : gkt

User MAC : 0800-2700-94ad

Interface : Vlan-interface100

User IP address : 21.0.0.20

AP : N/A

SSID : N/A

User login time : 2021-07-29 11:05:58

User logout time : 2021-07-29 11:05:58

Logout reason : Idle timeout

¡ 在设备上执行debugging portal error命令，打开Portal错误调试信息开关。如果设备上打印如下信息，则可以确认因用户会话超时导致Portal用户下线。

*Jul 28 17:51:20:774 2021 Sysname PORTAL/7/ERROR: -MDC=1; Idle-cut timer timed out and the user will be logged off.

用户闲置切断触发的下线属于正常下线，用户重新上线即可。

(4) 检查是否为计费更新失败。

远程Portal认证用户上线，设备会定期向AAA服务器发送计费更新报文。当设备与AAA服务器链路不通或者服务器故障时，计费更新报文会发送失败。当达到最大重传次数后，如果计费更新报文还是发送失败并且设备上配置了用户计费更新失败策略（通过accounting update-fail offline命令配置），则触发用户下线。

可通过如下方法确认是否因计费更新失败导致用户下线：

¡ 通过display portal logout-record命令查询用户下线记录。

<Sysname> display portal logout-record all

Total logout records: 1

User name : gkt

User MAC : 0800-2700-94ad

Interface : Vlan-interface100

User IP address : 21.0.0.20

AP : N/A

SSID : N/A

User login time : 2021-07-29 11:05:58

User logout time : 2021-07-29 11:05:58

Logout reason : Accounting update failure

¡ 通过display interface查看设备上连接AAA服务器的端口是否发生过变化，检查AAA服务器否有异常记录等。或者通过display radius scheme命令显示的State字段查看服务器状态是否为Block，如果是，则可能是计费更新失败导致的下线。

¡ 在设备上执行debugging portal error命令，打开Portal错误调试信息开关。如果设备上打印如下信息，则可以确认因用户会话超时导致Portal用户下线。

*Jul 28 17:51:20:774 2021 Sysname PORTAL/7/ERROR: -MDC=1; Processed accounting-update failed and user logout.

如果确认是计费更新失败导致的用户下线，请检查设备与服务器之间的链路状态，以及设备和AAA服务器的相关计费配置是否发生过更改。

(5) 检查是否为用户流量达到阈值。

用户上线时，如果AAA服务器下发了流量阈值，当用户的流量超过AAA服务器下发的流量阈值时，设备就会强制用户下线。

可通过如下方法确认是否因用户流量达到阈值导致用户下线：

¡ 查看AAA服务器上记录的用户下线记录。

¡ 通过display portal logout-record命令查询用户下线记录。

<Sysname> display portal logout-record all

Total logout records: 1

User name : gkt

User MAC : 0800-2700-94ad

Interface : Vlan-interface100

User IP address : 21.0.0.20

AP : N/A

SSID : N/A

User login time : 2021-07-29 11:05:58

User logout time : 2021-07-29 11:05:58

Logout reason : User traffic reached threshold

用户流量达到阈值触发的下线属于正常下线，用户重新上线即可。

(6) 检查是否为AAA服务器主动踢用户下线。

设备上开启了RADIUS session control功能后，若收到AAA服务器的断开连接请求，则会立马强制对应的用户下线。首先查看设备上是否开启了（通过radius session-control enable命令配置）。如果开启了，则可以通过如下方法查看是否因AAA服务器强制用户下线导致用户下线：

¡ 查看AAA服务器上记录的用户下线记录。

¡ 通过display portal logout-record命令查询用户下线记录。

<Sysname> display portal logout-record all

Total logout records: 1

User name : gkt

User MAC : 0800-2700-94ad

Interface : Vlan-interface100

User IP address : 21.0.0.20

AP : N/A

SSID : N/A

User login time : 2021-07-29 11:05:58

User logout time : 2021-07-29 11:05:58

Logout reason : Force logout by RADIUS server

服务器为何强制用户下线，请联系服务器管理员进行确认。

(7) 检查是否为Portal用户在线探测失败导致用户下线。

如果设备上开启了Portal用户在线探测功能（通过portal user-detect命令配置），设备会定期向用户终端发送探测报文。若在指定探测次数内，设备未收到终端的回应，则强制用户下线。

确认设备上是否开启了Portal用户在线探测功能。如果开启了，则可以通过如下方法确认是否因用户在线探测失败导致用户下线：

¡ 查看AAA服务器上记录的用户下线记录。

¡ 通过display portal logout-record命令查询用户下线记录。

<Sysname> display portal logout-record all

Total logout records: 1

User name : gkt

User MAC : 0800-2700-94ad

Interface : Vlan-interface100

User IP address : 21.0.0.20

AP : N/A

SSID : N/A

User login time : 2021-07-29 11:05:58

User logout time : 2021-07-29 11:05:58

Logout reason : User detection failure

如果确认是因Portal用户在线探测导致用户下线，请检查终端和设备之间的链路状态，排查终端没有回应探测报文的原因。

(8) 检查Portal用户上线的接口是否down。

如果Portal用户上线的接口down了一段时间后，设备会强制从该接口接入的Portal用户全部下线。

可通过如下方法确认是否因接口down导致用户下线：

¡ 查看AAA服务器上的用户下线记录。

¡ 通过display interface命令查看接口的状态是否发生过变化，如果发生变化的时间正好和用户下线的时间接近，则可能是接口down触发的用户下线。

¡ 通过display portal logout-record命令查询用户下线记录。

<Sysname> display portal logout-record all

Total logout records: 1

User name : gkt

User MAC : 0800-2700-94ad

Interface : Vlan-interface100

User IP address : 21.0.0.20

AP : N/A

SSID : N/A

User login time : 2021-07-29 11:05:58

User logout time : 2021-07-29 11:05:58

Logout reason : Interface down

如果确认是接口down导致的下线，请排查接口down的原因，如网线口松动等。

(9) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息。

¡ Portal服务器上Portal相关配置截图。

¡ AAA服务器上记录的用户下线记录。

¡ 设备与服务器间的抓包文件。

¡ 在客户端浏览器上对问题现象截图。

¡ 通过开启debugging portal命令收集调试信息。

4. 告警与日志

4.11 MAC地址认证故障处理

4.11.1 MAC地址认证失败

1. 故障描述

MAC地址认证用户认证失败或认证异常。

2. 常见原因

本类故障的常见原因主要包括：

· 用户已通过其它认证方式上线。

· 全局或接口MAC地址认证功能未开启。

· 设备配置的认证方式与RADIUS服务器不一致。

· MAC地址认证用户使用的认证域及相关配置错误。

· RADIUS服务器无回应。

· 本地认证或RADIUS服务器认证拒绝。

· 授权属性下发失败。

· 用户MAC地址被设置为静默MAC。

· MAC地址认证在线用户数达到最大值。

3. 故障分析

本类故障的诊断流程如图4-23所示。

图4-21 MAC地址认证用户认证失败的故障诊断流程图

4. 处理步骤

· Debug开关不能在设备正常运行时随意开启，可在故障发生后复现故障场景时打开。

· 请及时保存以下步骤的执行结果，以便在故障无法解决时快速收集和反馈信息。

(1) 检查用户是否已通过其它认证方式上线。

当前端口默认的认证方式顺序为：802.1X认证->MAC地址认证->Web认证。

通过display dot1x connection命令查看当前MAC地址是否已经通过了802.1X认证成功上线。如果已经在线，请判断是否需要通过MAC地址认证重新上线，如果需要，则将相应的802.1X用户下线并关闭802.1X认证功能，然后再尝试进行MAC地址认证。

(2) 检查全局或接口MAC地址认证功能是否开启。

a. 执行display mac-authentication命令，如果提示“MAC authentication is not configured.”，表示全局MAC地址认证未开启，需要在系统视图下执行mac-authentication命令。

b. 执行display mac-authentication命令，如果有全局配置信息，无接口下的配置信息显示，则需要在用户认证的接口视图下执行mac-authentication命令。

(3) 检查设备上配置的认证方法与RADIUS服务器是否一致。

设备上MAC地址认证支持两种认证方法：CHAP和PAP。

执行dis mac-authentication命令查看“Authentication method”字段显示的当前MAC地址认证的认证方法与RADIUS服务器上配置的认证方法是否一致。如果不一致，则可以执行mac-authentication authentication-method命令修改设备上的配置。

(4) 检查认证域及相关是否配置错误。

端口上接入的MAC地址认证用户将按照如下先后顺序选择认证域：端口上指定的认证域 > 系统视图下指定的认证域 > 系统缺省的认证域。

a. 通过在设备上执行display mac-authentication命令查看系统和认证接口下是否配置了MAC地址认证用户使用的认证域。

<Sysname> display mac-authentication

Global MAC authentication parameters:

MAC authentication : Enabled

Authentication method : PAP

Authentication domain : Not configured, use default domain

…

GigabitEthernet1/0/1 is link-up

MAC authentication : Enabled

Carry User-IP : Disabled

Authentication domain : Not configured

…

b. 如果认证接口下配置了MAC地址认证用户使用的认证域，请执行display domain命令检查认证域下的认证方案是否配置准确；如果认证接口下未配置认证域，而系统视图下配置了认证域，则同样通过display domain命令检查该认证域下的认证方案。

c. 如果认证接口和系统视图下都没有配置MAC地址认证用户使用的认证域，则检查缺省认证域的配置。

d. 如果不存在缺省认证域，若通过domain if-unknown命令配置了unknown域，则检查unknown域下的认证方案是否正确。

e. 如果根据以上原则决定的认证域在设备上都不存在，则用户无法完成认证。

(5) 检查RADIUS服务器有无响应。

请参见《AAA故障处理》的“RADIUS服务器无响应”进行故障定位和处理。

(6) 检查下线原因是否为认证拒绝。

执行debugging mac-authetication event命令打开MAC地址认证事件调试开关：

¡ 若系统打印调试信息“Local authentication request was rejected.”，则表示本地认证拒绝。导致本地认证拒绝的原因有本地用户不存在、用户名密码错误、服务类型错误等。

¡ 若系统打印调试信息“The RADIUS server rejected the authentication request.”，则表示RADIUS服务器认证拒绝。服务器认证拒绝有多种原因，最常见的有服务器上未添加用户名、用户名格式不一致、用户名密码错误、RADIUS服务器授权策略无法匹配等。在设备上通过debugging radius error命令打开RADIUS错误调试信息开关查看相关的Debug信息，并且同时可以在设备上执行test-aaa命令发起RADIUS请求测试，定位故障问题后，调整服务器、设备及客户端配置。

(7) 检查授权属性是否下发失败。

通过debugging mac-authentication event命令打开MAC地址认证事件调试开关。如果设备上打印了“Authorization failure.”的调试信息，则表示授权失败。

a. 检查设备的系统视图下是否通过port-security authorization-fail offline命令配置了授权失败用户下线功能。如果未配置授权失败用户下线功能，缺省情况下授权失败用户也可以保持在线，则用户不是因为授权失败而导致认证失败，继续定位其它可能原因。

b. 如果配置了授权失败用户下线功能，执行mac-authentication access-user log enable failed-login命令打开MAC地址认证上线失败日志功能，确认授权失败的属性有哪些（例如授权ACL、VLAN）。

c. 检查RADIUS服务器上的授权属性设置是否正确，确保服务器下发的授权属性内容准确。

d. 通过display acl或display vlan等命令查看设备上对应的授权属性是否存在，如果不存在，需要在设备上创建相应的授权属性，确保用户能够获取到授权的信息。

(8) 检查用户的MAC地址是否被设置为静默MAC。

执行display mac-authentication命令查看“Silent MAC users“字段显示的静默MAC信息。如果用户的MAC地址属于静默MAC，则需要等待静默时间老化后，才能再次进行MAC地址认证。用户可通过mac-authentication timer quiet命令重新配置静默时间。

(9) 检查MAC地址认证用户数是否达到了最大用户数限制。

a. 执行display mac-authentication查看认证接口下的信息，“Max online users”字段为该接口下配置的最大用户数，“Current online users”字段为接口下当前在线用户数，对比两组数据判断MAC地址认证在线用户数是否已经达到最大值。

b. 如果已经达到最大用户数，可以执行mac-authentication max-user命令增大最多允许同时接入的MAC地址认证用户数。

c. 如果MAC地址认证的在线用户数无法再增大，则需要等其他用户下线或切换用户的接入端口。

(10) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息。

¡ 执行mac-authentication access-user log enable命令收集的日志信息。

¡ 执行debugging mac-authentication all、debugging radius all命令收集的调试信息。

5. 告警和日志

4.11.2 MAC认证用户掉线

1. 故障描述

MAC地址认证用户认证成功在线后，异常掉线。

2. 常见原因

· 同一MAC地址的用户采用802.1X认证重新上线。

· 设备上MAC地址认证的相关配置发生变化。

· MAC地址认证用户流量实时计费失败。

· MAC地址认证用户重认证失败。

· 服务器强制用户下线。

· 开启下线检测后用户下线。

· 用户会话超时。

3. 故障分析

本类故障的诊断流程如图图4-24所示。

图4-22 MAC地址认证用户掉线的故障诊断流程图

4. 处理步骤

· Debug开关不能在设备正常运行时随意开启，可在故障发生后复现故障场景时打开。

· 请及时保存以下步骤的执行结果，以便在故障无法解决时快速收集和反馈信息。

(1) 检查是否因为802.1x用户上线导致同一MAC地址认证用户下线。

当前端口默认的认证方式顺序为：802.1X认证->MAC地址认证->Web认证。

如果用户首先通过MAC地址认证，Web认证会立即终止，但802.1X认证仍会继续进行。如果802.1X认证成功，则端口上生成的802.1X认证用户信息会覆盖已存在的MAC地址认证用户信息。

通过display dot1x connection命令查看当前MAC地址是否通过了802.1X认证成功上线。如果已经在线，请判断是否需要通过MAC地址认证重新上线，如果需要，则将相应的802.1X用户下线并关闭接口的802.1X认证功能，然后再尝试进行MAC地址认证。

(2) 检查设备上MAC地址认证的相关配置是否发生变化。

a. 通过display mac-authentication命令查看设备上MAC地址认证的相关配置（使能开关、认证方式等）是否发生变化。

b. 通过display domain命令查看用户认证域下的配置（授权属性等）是否发生变化。

(3) 检查实时计费是否失败。

执行debugging mac-authentication event命令打开MAC地址认证事件调试信息开关。如果系统打印事件调试信息“Real-time accounting failure.”，则表示实时计费失败。检查设备与计费服务器之间的链路状态，以及设备和计费服务器的相关计费配置是否发生过更改。

(4) 检查是否是因为重认证失败而掉线。

a. 执行display mac-authentication命令通过“Periodic reauth”字段查看认证接口下是否开启了MAC地址重认证功能。

b. 通过mac-authentication access-user log enable logoff命令打开MAC地址认证用户下线的日志信息功能。

c. 参考“4.11.1 MAC地址认证失败”故障处理定位重认证失败原因。

(5) 检查是否为RADIUS服务器强制用户下线。

执行debugging mac-authentication event命令打开MAC地址认证事件调试信息开关。如果系统打印事件调试信息“The RADIUS server forcibly logged out the user.”，则表示服务器强制用户下线。请联系服务器管理员定位服务器强制用户下线原因。

(6) 检查是否是因为下线检测定时器间隔内未收到用户报文。

a. 执行display mac-authentication命令查看认证接口下“Offline detection”字段，确认是否开启了MAC地址认证下线检测功能。

b. 执行debugging mac-authentication event命令打开MAC地址认证事件调试信息开关。如果系统打印事件调试信息“Offline detect timer expired.”，则表示下线检测定时器间隔内，未收到此端口下某MAC地址认证在线用户的报文，设备切断了用户连接，导致用户下线。

c. 检查客户端与设备之间的链路状态，排查客户端未发送报文原因。

(7) 检查用户会话是否超时。

a. 执行debugging radius packet命令打开RADIUS报文调试信息开关，确认服务器回应的报文中是否携带Session-Timeout属性。

b. 执行debugging mac-authentication event命令打开MAC地址认证事件调试信息开关。如果系统打印事件调试信息“User session timed out.”，则表示用户会话超时下线。

c. 用户会话超时触发的掉线情况属于正常现象，用户可重新发起上线。

(8) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息。

¡ 执行mac-authentication access-user log enable命令收集的日志信息。

¡ 执行debugging mac-authentication all、debugging radius all命令收集的调试信息。

5. 告警与日志

4.12 802.1X故障处理

4.12.1 802.1X用户认证失败

1. 故障描述

802.1X用户认证失败或认证异常。

2. 常见原因

本类故障的常见原因主要包括：

· 全局或接口802.1X功能未开启。

· 802.1X客户端不能正常发送或接收认证报文。

· 设备配置的认证方式与RADIUS服务器不一致。

· 802.1X用户使用的认证域及相关配置错误。

· RADIUS服务器无回应。

· RADIUS服务器认证拒绝。

· 授权属性下发失败。

· 802.1X认证用户的MAC地址被其它端口绑定。

· 802.1X用户处于静默状态。

· 802.1X在线用户数达到最大值。

3. 故障分析

本类故障的诊断流程如图4-23所示。

图4-23 802.1X用户认证失败的故障诊断流程图

4. 处理步骤

· Debug开关不能在设备正常运行时随意开启，可在故障发生后复现故障场景时打开。

· 请及时保存以下步骤的执行结果，以便在故障无法解决时快速收集和反馈信息。

(1) 检查设备全局或接口802.1X功能是否开启。

通过在设备上执行display dot1x命令，检查全局和认证接口上的802.1X功能是否开启。

¡ 如果提示“802.1X is not configured.”，表示全局802.1X功能未开启，请在系统视图下执行dot1x命令，开启全局802.1X认证功能。

¡ 如果有全局配置信息，无接口下的配置信息显示，则说明接口下未开启802.1X功能，请在认证接口视图下执行dot1x命令。

(2) 检查802.1X客户端是否能正常发送或接收认证报文。

¡ 检查802.1X客户端版本是否为设备和服务器支持的版本。

¡ 检查设备与802.1X客户端间的链路连接是否正常。

¡ 通过抓包检查设备与客户端间是否能正常收发数据报文，分析抓包文件进一步定位故障问题。

(3) 检查设备上配置的认证方法与RADIUS服务器是否一致。

设备上802.1X系统支持两种认证方法：EAP终结（PAP和CHAP）和EAP中继（EAP），配置EAP认证方法时需要注意以下几点：

¡ 保证设备和RADIUS服务器配置的认证方法一致，且客户端支持。

¡ 本地认证仅支持EAP终结方式。

通过在设备上执行display dot1x命令查看当前802.1X采用的认证方式。

<Sysname> display dot1x

Global 802.1X parameters:

802.1X authentication : Enabled

DR member configuration conflict : Unknown

EAP authentication : Enabled

…

如果与服务器不一致，可通过dot1x authentication-method命令修改。

(4) 检查认证域及相关配置是否正确。

802.1X用户按照如下先后顺序选择认证域：端口上指定的强制ISP域-->用户名中指定的ISP域-->系统缺省的ISP域。

a. 通过在设备上执行display dot1x命令查看认证接口下是否配置了802.1X用户的强制认证域。

<Sysname> display dot1x

…

GigabitEthernet1/0/1 is link-up

802.1X authentication : Enabled

…

Multicast trigger : Enabled

Mandatory auth domain : Not configured

…

如果配置了强制认证域，请执行display domain命令检查强制认证域下的认证方案是否配置准确。

b. 如果没有配置强制认证域，若802.1X用户名中包含域名，请确认域名分隔符与RADIUS服务器支持的域名分隔符保持一致，然后根据用户名中包含的域名找到指定域并检查其配置。

c. 如果802.1X用户名中未包含域名，则检查缺省认证域的配置。

d. 如果不存在缺省认证域，若通过domain if-unknown命令配置了unknown域，则检查unknown域下的认证方案是否配置准确。

e. 如果根据以上原则决定的认证域在设备上都不存在，则用户无法完成认证。

(5) 检查RADIUS服务器有无响应。

具体的故障定位操作请参见《AAA故障处理手册》的“RADIUS服务器无响应”。

(6) 检查下线原因是否为认证拒绝。

执行debugging dot1x event命令打开802.1X认证事件调试开关：

¡ 若系统打印调试信息“Local authentication request was rejected.”，则表示本地认证拒绝。导致本地认证拒绝的原因有本地用户不存在、用户名密码错误、用户服务类型错误等。

¡ 若系统打印调试信息“The RADIUS server rejected the authentication request.”，则表示RADIUS服务器认证拒绝。RADIUS服务器认证拒绝有多种原因，最常见的有服务器上未添加用户名、用户名密码错误、RADIUS服务器授权策略无法匹配等。通过执行debugging radius error命令打开RADIUS错误调试信息开关查看相关的Debug信息，并且同时可以在设备上执行test-aaa命令发起RADIUS请求测试，定位故障问题后，调整服务器、设备及客户端配置。

(7) 检查授权属性是否下发失败。

a. 执行debugging dot1x event打开802.1X认证事件调试开关。如果系统打印调试信息“Authorization failure.”，则表示授权失败。

b. 检查设备上是否通过port-security authorization-fail offline命令配置了授权失败用户下线功能。如果未配置授权失败用户下线功能，缺省情况下授权失败用户也可以保持在线，则用户不是因为授权失败而导致认证失败，继续定位其它故障原因。

c. 检查服务器上的授权属性（例如授权ACL、VLAN）设置是否正确，确保服务器下发的授权属性内容准确。

d. 执行display acl或display vlan命令检查设备上对应的授权属性是否存在，如果不存在，需要在设备上创建相应的授权属性，确保用户能够获取到授权的信息。

(8) 检查802.1X用户的MAC地址是否绑定失败。

执行debugging dot1x event命令打开802.1X事件调试信息开关。如果系统打印调试信息“MAC binding processing failure.”，则表示802.1X用户的MAC地址绑定处理失败。

(9) 检查802.1X用户是否处于静默状态。

在设备上执行display dot1x命令，显示信息中“Quiet timer”和“Quiet period”字段显示的是静默定时器的开启状态和静默时长，“Online 802.1X users”字段下如果用户的“Auth state”显示为“Unauthenticated”时，则表示该用户为802.1X静默用户。

静默期间，设备将不对静默用户进行802.1X认证处理。用户需等待静默时间老化后，重新发起802.1X认证，同时也可通过执行dot1x timer quiet-period命令重新设置静默时长。

(10) 检查802.1X在线用户数是否达到最大值。

a. 在设备上执行display dot1x interface查看认证接口下的信息，“Max online users”字段为该接口下配置的最大用户数，“Online 802.1X users”字段为接口下当前在线用户数，对比两组数据判断802.1X认证在线用户数是否已经达到最大值。

b. 如果接口接入的802.1X用户数达到最大值，可以通过dot1x max-user命令增大最多允许同时接入的802.1X用户数。

c. 如果接口接入的802.1X用户数无法再增加，则需要等其他用户下线或切换用户的接入端口。

(11) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息。

5. 告警与日志

4.12.2 802.1X用户掉线

1. 故障描述

802.1X用户认证成功上线后，异常掉线。

2. 常见原因

本类故障的常见原因主要包括：

· 设备上802.1X认证的相关配置变化。

· 在线用户握手失败。

· 实时计费失败。

· 802.1X用户重认证失败

· 服务器强制用户下线。

· 开启下线检测后用户下线。

· 用户会话超时。

3. 故障分析

本类故障的诊断流程如图图4-24所示。

图4-24 802.1X用户掉线的故障诊断流程图

4. 处理步骤

· Debug开关不能在设备正常运行时随意开启，可在故障发生后复现故障场景时打开。

· 请及时保存以下步骤的执行结果，以便在故障无法解决时快速收集和反馈信息。

(1) 检查设备上802.1X认证的相关配置是否发生变化。

a. 通过display dot1x命令查看设备上MAC地址认证的相关配置是否发生变化。

b. 通过display domain命令查看用户认证域下的配置是否发生变化。

(2) 检查802.1X在线用户握手交互是否失败。

a. 执行display dot1x命令通过“Handshake”字段查看认证接口下是否开启了802.1X在线用户握手功能。

b. 执行debugging dot1x event命令打开802.1X事件调试信息开关。如果系统打印事件调试信息“Handshake interaction failure.”，则表示握手交互失败。可以通过抓包检查设备与客户端间是否能正常收发EAP数据报文，分析抓包文件进一步定位问题。

(3) 检查实时计费是否失败。

执行debugging dot1x event命令打开802.1X事件调试信息开关。如果系统打印事件调试信息“Real-time accounting failure”，则表示实时计费失败。检查设备与计费服务器之间的链路状态，以及设备和服务器的相关计费配置是否发生过更改。

(4) 检查用户是否是因为重认证失败而掉线。

a. 执行display dot1x命令通过“Periodic reauth”字段查看认证接口下是否开启了802.1X周期性重认证功能。

b. 参考“4.12.1 802.1X用户认证失败”故障处理定位重认证失败原因。

(5) 检查是否为RADIUS服务器强制用户下线。

RADIUS远程认证情况下，执行debugging dot1x event命令打开802.1X事件调试信息开关。如果系统打印事件调试信息“The RADIUS server forcibly logged out the user”，则表示RADIUS服务器强制用户下线。请联系服务器管理员定位服务器强制用户下线原因。

(6) 检查是否是因为下线检测定时器间隔内未收到用户报文。

a. 执行display dot1x命令通过“Offline detection”字段查看认证接口下是否开启了802.1X下线检测功能。

b. 执行debugging dot1x event命令打开802.1X事件调试信息开关。如果系统打印事件调试信息“Offline detect timer expired”，则表示下线检测定时器间隔内，未收到此端口下该802.1X在线用户的报文，设备切断了用户连接，导致用户下线。

c. 检查客户端与设备之间的链路状态，排查客户端未发送报文原因。

(7) 检查用户会话是否超时。

a. 检查是否配置了802.1X认证用户会话超时时间。

- RADIUS远程认证情况下，执行debugging radius packet命令打开RADIUS报文调试信息开关，通过调试信息确认服务器回应的报文中是否携带Session-Timeout属性。

- 本地认证情况下，执行display local-user命令查看显示信息中是否包含“Session-timeout”字段。

b. 执行debugging dot1x event命令打开802.1X事件调试信息开关。如果系统打印事件调试信息“User session timed out.”，则表示用户会话超时下线。

c. 用户会话超时触发的掉线情况属于正常现象，用户可重新发起上线。

(8) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息。

¡ 执行debugging dot1x all、debugging radius all命令收集的调试信息。

5. 告警与日志

4.13 AAA故障处理

4.13.1 登录设备后无法执行部分命令行

1. 故障描述

管理员登录设备后没有部分命令行的执行权限，系统打印提示信息 “Permission denied.”。

2. 常见原因

本类故障的主要原因为，给用户授权的用户角色权限过小。

3. 故障分析

本类故障的诊断流程如图4-25所示。

图4-25 登录后无法执行部分命令行的故障诊断流程图

4. 处理步骤

(1) 检查用户角色否为自定义用户角色。

请以超级管理员身份（即具有network-admin或者level-15用户角色）登录设备，执行display line命令查看登录用户线的认证方式，并根据不同的认证方式，采取不同的处理步骤：

<Sysname> display line

Idx Type Tx/Rx Modem Auth Int Location

0 CON 0 115200 - N - 1/0

+ 81 VTY 0 - N - 1/0

+ 82 VTY 1 - P - 1/0

+ 83 VTY 2 - A - 1/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) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息。

5. 告警与日志

4.13.2 登录设备后无法创建或修改本地用户

1. 故障描述

管理员登录设备后无法创建或修改本地用户，系统打印提示信息“Insufficient right to perform the operation.”。

2. 常见原因

本类故障的主要原因为，给用户授权的用户角色权限不具备修改目标本地用户配置的权限。

3. 故障分析

本类故障的诊断流程如图4-26所示。

图4-26 登录后无法创建或修改本地用户的故障诊断流程图

4. 处理步骤

(1) 检查登录用户的角色是否为预定义的超级管理员角色，即为network-admin、level-15之一。

只有上述预定义用户角色才拥有创建本地用户的权限，其它用户角色只有进入自身本地用户视图的权限。如果登录用户不拥有如上预定义用户角色，则为其授权其中之一。如果重新授权后，故障仍未排除，请继续定位。

此步骤仅适用于无权限创建本地用户，若无权限修改本地用户，请执行步骤（2）。

(2) 比较登录用户和目标用户的权限范围。

执行命令display role name role-name，分别查看登录用户和目标用户的角色权限，并比较两者的权限大小。如果操作者权限较小，则为其更换拥有更高权限的用户角色。

(3) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息。

5. 告警与日志

4.13.3 管理员未被授权用户角色

1. 故障描述

管理员无法成功登录设备，设备也没有提供三次登录尝试机会。例如，使用Telnet登录时，用户输入用户名和密码后，设备登录界面上既未打印提示信息“AAA authentication failed”，也未再次提示用户输入用户名和密码。

2. 常见原因

本类故障的主要原因为，没有为用户授权用户角色。

3. 故障分析

本类故障的诊断流程如图4-27所示。

图4-27 管理员未被授权用户角色的故障诊断流程图

4. 处理步骤

(1) 检查是否为用户授权了用户角色。

<Sysname> display line

Idx Type Tx/Rx Modem Auth Int Location

0 CON 0 115200 - N - 1/0

+ 81 VTY 0 - N - 1/0

+ 82 VTY 1 - P - 1/0

+ 83 VTY 2 - A - 1/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) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息。

5. 告警与日志

4.13.4 登录用户名含有非法字符

1. 故障描述

管理员登录设备失败，系统打印如下形式的日志信息：

Sysname LOGIN/5/LOGIN_INVALID_USERNAME_PWD: -MDC=1; Invalid username or password from xx.xx.xx.xx.

2. 常见原因

本类故障的主要原因为，用户输入的用户名中含有非法字符。

3. 故障分析

本类故障的诊断流程如图4-28所示。

图4-28 登录用户名含有非法字符的故障诊断流程图

4. 处理步骤

本处理步骤仅适用于SSH及Telnet登录用户。

(1) 检查用户输入的用户名是否含有非法字符。

用户登录设备时，系统会检查用户输入的纯用户名以及域名的有效性，如果纯用户名中包含了非法字符“\”、“|”、“/”、“:”、“*”、“?”、“<”、“>”和“@”，域名中包含“@”，则不允许登录。此时，建议用户再次尝试登录，并输入正确的用户名。

(2) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息。

5. 告警与日志

4.13.5 本地用户名或密码错误

1. 故障描述

管理员采用本地认证方式登录设备失败。如果设备上同时打开了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.

2. 常见原因

本类故障的常见原因主要包括：

· 用户输入的密码错误。

· 本地用户名不存在。

3. 故障分析

本类故障的诊断流程如图4-29所示。

图4-29 本地用户名或密码错误的故障诊断流程图

4. 处理步骤

(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) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息、调试信息。

5. 告警与日志

4.13.6 本地用户的服务类型不匹配

1. 故障描述

管理员采用本地认证方式登录设备失败。如果设备上同时打开了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).

2. 常见原因

本类故障的主要原因为，用户的接入类型与设备上配置的本地用户服务类型不匹配，即用户的接入类型不在配置的服务类型范围之内。

3. 故障分析

本类故障的诊断流程如图4-30所示。

图4-30 本地用户服务类型不匹配的故障诊断流程图

4. 处理步骤

(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) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息、调试信息。

5. 告警与日志

4.13.7 登录失败固定次数后，被禁止在指定的时间内再次登录

1. 故障描述

管理员登录设备失败指定的次数后，在一定时间内被禁止再次登录设备。

2. 常见原因

本类故障的常见原因主要包括：

· 设备上开启了Login用户攻击防范功能。开启该功能后，会导致Login用户登录失败指定的次数后，若用户的IP地址被加入黑名单，则设备将会丢弃来自该IP地址的报文，使得该用户不能在指定的阻断时长内进行登录操作。

· 用户采用本地认证方式登录设备，且设备上开启了Password Control功能。用户登录认证失败后，系统会将该用户加入密码管理的黑名单，并根据配置的处理措施对其之后的登录行为进行相应的限制。当用户登录失败次数超过指定值后，系统禁止该用户登录，经过一段时间后，再允许该用户重新登录。

3. 故障分析

本类故障的诊断流程如图4-31所示。

图4-31 指定时间内被阻断登录的故障诊断流程图

4. 处理步骤

(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

¡ 如果该用户被阻断后，根本无法向设备发起登录连接，则执行步骤（4）。

(3) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息。

5. 告警与日志

4.13.8 登录失败后需要等待一定时长再进行重认证

1. 故障描述

管理员登录设备失败后，控制台无响应一定的时间，期间用户无法执行任何操作。

2. 常见原因

本类故障的主要原因主要为，设备上配置了Login延时认证功能。开启本功能后，用户登录失败后，系统将会延迟一定的时长之后再允许用户进行认证。

3. 故障分析

本类故障的诊断流程如图4-32所示。

图4-32 登录失败后等待重认证的故障诊断流程图

4. 处理步骤

(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) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息。

5. 告警与日志

4.13.9 使用相同用户名接入设备的用户数达到上限

1. 故障描述

使用同一用户名接入设备的本地认证用户达到一定数量后，后续使用该用户名登录设备失败。

如果设备上同时打开了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.

2. 常见原因

本类故障的主要原因为，设备上设置了使用当前本地用户名接入设备的最大用户数。

3. 故障分析

本类故障的诊断流程如图4-33所示。

图4-33 使用相同用户名的上线用户数达上限后的故障诊断流程图

4. 处理步骤

(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) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息。

5. 告警与日志

4.13.10 相同接入类型的在线用户数达到上限

1. 故障描述

使用同一登录方式接入设备的用户达到一定数量后，后续该类用户登录设备失败。

如果设备上同时打开了相关接入模块的事件调试信息开关，系统会打印如下形式的调试信息：

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

2. 常见原因

本类故障的主要常见原因为，设备上设置了采用指定登录方式登录设备并同时在线的用户数。

3. 故障分析

本类故障的诊断流程如图4-34所示：

图4-34 使用相同登录方式接入用户数达到上限后的故障诊断流程图

4. 处理步骤

(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) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息。

5. 告警与日志

4.13.11 RADIUS服务器无响应

1. 故障描述

因为服务器无响应导致使用RADIUS认证服务器认证/授权/计费失败。如果设备上同时打开了RADIUS的事件调试信息开关（通过执行debugging radius event命令），系统会打印如下形式的调试信息：

*Aug 8 17:49:06:143 2021 Sysname RADIUS/7/EVENT: -MDC=1; Reached the maximum retries

2. 常见原因

本类故障的常见原因主要包括：

· RADIUS服务器上配置的共享密钥与接入设备上配置的共享密钥不一致。

· RADIUS服务器上没有添加接入设备的IP地址或者添加的IP地址不正确。

· RADIUS服务器与接入设备之间的网络存在问题，例如中间网络存在防火墙时，防火墙阻止了RADIUS服务器提供AAA服务的端口号（缺省认证端口号：1812，缺省计费端口号：1813）。

3. 故障分析

本类故障的诊断流程如图4-35所示。

图4-35 RADIUS服务器无响应的故障诊断流程图

4. 处理步骤

(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) 检查RADIUS服务器上是否添加了接入设备的IP地址或者添加的IP地址是否正确。

RADIUS服务器上添加的设备IP地址必须是接入设备发送RADIUS报文的源IP地址。接入设备发送RADIUS报文使用的源IP地址可以通过相关命令设置。

接入设备按照以下顺序选择发送RADIUS报文使用的源IP地址：

a. RADIUS方案视图下配置的NAS-IP地址（通过nas-ip命令）。

b. 系统视图下的配置的源NAS-IP地址（通过radius nas-ip命令）。

c. 发送RADIUS报文的出接口的IP地址。

(3) 检查设备和服务器之间的网络是否存在问题。

首先使用ping等手段排除设备与服务器之间的网络可达性，然后排查该网络中是否存在防火墙等设备。通常，如果网络中存在防火墙设备且不允许目的UDP端口号为RADIUS服务器端口号的报文通过（缺省的RADIUS认证端口号为1812，缺省的RADIUS计费端口号为1813），RADIUS报文将被丢弃。

(4) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息、调试信息。

5. 告警与日志

4.13.12 用户接入类型与RADIUS服务器下发的Login-Service属性值不匹配

1. 故障描述

由于设备不支持RADIUS服务器下发的Login-Service属性值，导致用户认证失败。

打开设备上RADIUS的报文调试信息开关（通过执行debugging radius packet命令），在如下形式的调试信息中查看到服务器下发的Login-Service属性类型为设备不支持的类型：

*Aug 3 02:33:18:707 2021 Sysname RADIUS/7/PACKET:

Service-Type=Framed-User

Idle-Timeout=66666

Session-Timeout=6000

2. 常见原因

本类故障的主要原因为，用户登录的业务类型与服务器下发的Login-Service属性所指定的业务类型不一致。

· 0：Telnet（标准属性）

· 50：SSH（扩展属性）

· 51：FTP（扩展属性）

· 52：Terminal（扩展属性）

· 53：HTTP（扩展属性）

· 54：HTTPS（扩展属性）

可以通过命令行设置设备对Login-Service属性的检查方式，控制设备对用户进行业务类型一致性检查的方式。

3. 故障分析

本类故障的诊断流程如图4-36所示。

图4-36 用户接入类型与RADIUS服务器下发的Login-Service属性值不匹配的故障诊断流程图

4. 处理步骤

(1) 检查RADIUS服务器下发的Login-Service属性与接入类型是否匹配。

在接入设备上执行display radius scheme命令，查看RADIUS方案下的“Attribute 15 check-mode”字段取值：

¡ 取值为Loose，表示采用松散检查方式，即使用Login-Service的标准属性值对用户业务类型进行检查。对于SSH、FTP、Terminal用户，在RADIUS服务器下发的Login-Service属性值为0（表示用户业务类型为Telnet）时才，这类用户才能够通过认证。

¡ 取值为Strict，表示采用严格检查方式，即使用Login-Service的标准属性值以及扩展属性值对用户业务类型进行检查。对于SSH、FTP、Terminal用户，当RADIUS服务器下发的Login-Service属性值为对应的扩展取值时，这类用户才能够通过认。

如果RADIUS服务器下发给用户的Login-Service属性不属于设备支持的Login-Service属性范围，则可以选用如下方法之一解决：

¡ 在RADIUS服务器上，设置服务器不下发Login-Service属性或者修改下发的属性值为接入设备支持的取值。

¡ 在接入设备上，进入相应的RADIUS方案，通过执行attribute 15 check-mode命令修改对Login-Service属性的检查方式（下例中为松散检查方式）。

<Sysname> system-view

[Sysname] radius scheme radius1

[Sysname-radius-radius1] attribute 15 check-mode loose

(2) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、调试信息、告警信息。

5. 告警与日志

4.13.13 本地认证登录失败

1. 故障描述

管理员采用本地认证登录设备失败。

2. 常见原因

本类故障的常见原因主要包括：

· 用户线下的认证方式配置错误。

· VTY用户线下支持的协议类型不正确。

· ISP域下配置的认证、授权、计费方案错误。

· 本地用户不存在、用户密码错误，或服务类型错误。

· 本地用户接入数量达到上限。

· 登录设备的用户数量到达上限。

· 全局密码管理功能开启的情况下，设备本地的lauth.dat文件异常。

3. 故障分析

本类故障的诊断流程如图4-37所示。

图4-37 本地认证登录失败的故障诊断流程图

4. 处理步骤

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) 检查用户线类下的配置。

用户线视图下的配置优先于用户线类视图下的配置。若用户线视图下未配置，则需要继续检查用户线类视图下的配置。

执行line class vty命令进入VTY用户线类视图，并通过display this命令查看如下配置是否准确：

¡ authentication-mode是否配置为scheme。

¡ 对于Telnet登录：protocol inbound是否配置为telnet或为缺省情况。

¡ 对于SSH登录：protocol inbound是否配置为ssh或为缺省情况。

如果用户线和用户线类下的配置均不准确，请按照需要在指定的用户线或用户线类下设置认证方案为scheme，并设置用户登录支持的协议类型。

(3) 检查ISP域下的认证、授权、计费方案配置是否准确。

执行display domain命令，查看显示信息：

¡ 如果用户的登录用户名中携带了域名（假设为test），则查看该域下的“Login authentication scheme:”字段取值是否为Local。如果该域下无“Login authentication scheme:”字段，再查看“Default authentication scheme:”字段取值是否为Local。

<Sysname> display domain test

Domain: test

State: Active

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

IGMP access limit: 4

MLD access limit: 4

¡ 如果用户的登录用户名中未携带域名，则在系统视图下执行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。

(4) 检查用户名和密码是否正确。

执行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]

(5) 检查使用该本地用户名接入的用户数是否达到上限。

在本地用户视图下执行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配置不存在，或者用户数未达到上限值，则继续定位。

(6) 检查指定登录类型的在线用户数是否到达上限。

a. 在系统视图下执行display this命令查看是否存在aaa session-limit的配置，若无此配置，则说明采用了缺省值32。

aaa session-limit ftp 33

domain default enable system

b. 执行display users查看当前用户线的用户登录情况，确认是否已到用户数上限。

c. 如果在线用户数到达上限，则根据需要采取以下措施之一：

- 在系统视图下执行aaa session-limit命令扩大用户数上限。

- 在用户视图下执行free命令强制其它在线用户下线。

(7) 检查本地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

¡ 若未开启，则忽略此步骤。

(8) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息、诊断信息。

¡ 打开Local-Server调试信息开关（通过debugging local-server all命令），收集设备的调试信息。

5. 告警与日志

4.13.14 RADIUS认证登录失败

1. 故障描述

管理员采用RADIUS认证登录设备失败。

2. 常见原因

本类故障的常见原因主要包括：

· 用户线下的认证方式配置错误。

· VTY用户线下支持的协议类型不正确。

· ISP域下配置的认证、授权、计费方案错误。

· 与RADIUS服务器交互失败。

· RADIUS服务器下发的Login-Service属性值不正确。

· RADIUS服务器未下发用户角色权限。

3. 故障分析

本类故障的诊断流程如图4-38所示。

图4-38 RADIUS认证登录失败的故障诊断流程图

4. 处理步骤

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) 检查用户线类下的配置。

用户线视图下的配置优先于用户线类视图下的配置。若用户线视图下未配置，则需要继续检查用户线类视图下的配置。

执行line class vty命令进入VTY用户线类视图，并通过display this命令查看如下配置是否准确：

¡ authentication-mode是否配置为scheme。

¡ 对于Telnet登录：protocol inbound是否配置为telnet或为缺省情况。

¡ 对于SSH登录：protocol inbound是否配置为ssh或为缺省情况。

如果用户线和用户线类下的配置均不准确，请按照需要，在指定的用户线或用户线类下设置认证方案为scheme，并设置用户登录支持的协议类型。

(3) 检查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

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

IGMP access limit: 4

MLD access limit: 4

¡ 如果用户的登录用户名中未携带域名，则在系统视图下执行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 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

(4) 通过RADIUS的调试信息辅助排查如下故障。

¡ 执行debugging radius packet命令打开RADIUS报文调试信息开关，如果系统打印Authentication reject类的报文调试信息，则表示用户的认证请求被服务器拒绝。因此，需要继续查看RADIUS服务器上记录的认证日志，并通过日志中描述的失败原因联系服务器管理员进行相应的处理。

¡ 执行debugging radius error命令打开RADIUS错误调试信息开关，如果系统打印错误调试信息“Invalid packet authenticator.”，则表示设备与服务器的共享密钥不匹配，可以尝试在RADIUS方案下设置与服务器匹配的共享密钥。

¡ 执行debugging radius event命令打开RADIUS事件调试信息开关，如果系统打印事件调试信息“Response timed out. ”，则表示设备与服务器之间不可达，可以尝试排查设备和服务器中间链路不通的问题。

(5) 检查RADIUS服务器下发的Login-Service属性值是否为设备支持的业务类型。

执行debugging radius packet命令打开RADIUS的报文调试信息开关后，查看RADIUS服务器下发的Login-Service属性情况，并采用“4.13.12 用户接入类型与RADIUS服务器下发的Login-Service属性值不匹配”介绍的方法解决故障。

(6) 检查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命令创建对应的用户角色。

(7) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息、诊断信息。

¡ 打开RADIUS调试信息开关（通过debugging radius all命令），收集设备的调试信息。

5. 告警与日志

4.13.15 HWTACACS认证登录失败

1. 故障描述

管理员采用HWTACACS认证登录设备失败。

2. 常见原因

本类故障的常见原因主要包括：

· 用户线下的认证方式配置错误。

· VTY用户线下支持的协议类型不正确。

· ISP域下配置的认证、授权、计费方案错误。

· 与HWTACACS服务器交互失败。

· HWTACACS服务器未下发用户角色权限。

3. 故障分析

本类故障的诊断流程如图4-39所示。

图4-39 HWTACACS认证登录失败的故障诊断流程图

4. 处理步骤

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) 检查用户线类下的配置。

用户线视图下的配置优先于用户线类视图下的配置。若用户线视图下未配置，则需要继续检查用户线类视图下的配置。

执行line class vty命令进入VTY用户线类视图，并通过display this命令查看如下配置是否准确：

¡ authentication-mode是否配置为scheme。

¡ 对于Telnet登录：protocol inbound是否配置为telnet或为缺省情况。

¡ 对于SSH登录：protocol inbound是否配置为ssh或为缺省情况。

¡ 如果用户线和用户线类下的配置均不准确，请按照需要，在指定的用户线或用户线类下设置认证方案为scheme，并设置用户登录支持的协议类型。

(3) 检查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

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

IGMP access limit: 4

MLD access limit: 4

¡ 如果用户的登录用户名中未携带域名，则在系统视图下执行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

(4) 通过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.”，则表示设备与服务器之间不可达，可以尝试排查设备和服务器中间链路不通的问题。

(5) 检查HWTACACS服务器是否下发了正确的用户角色权限。

执行debugging hwtacacs all命令打开所有HWTACACS调试信息开关后，如果发现客户端登录时直接断开连接，且没有异常的HWTACACS事件调试信息以及HWTACACS错误调试信息输出，则有可能是HWTACACS服务器未给用户下发用户角色权限导致。此时，可以查看HWTACACS的接收报文调试信息是否包含“priv-lvl=xx”或“roles=xx”字段。

¡ 如果不包含，则表示HWTACACS服务器未给用户下发用户角色权限，则可以选用如下方法之一解决：

<Sysname> system-view

[Sysname] role default-role enable

- 联系HWTACACS服务器管理员，为用户下发合适的用户角色。HWTACACS服务器上的授权角色配置必须满足格式：roles="name1 name2 namen"，其中name1、name2、namen为要授权下发给用户的用户角色，可为多个，并使用空格分隔。

(6) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息、诊断信息。

¡ 打开HWTACACS调试信息开关（通过debugging hwtacacs all命令），收集设备的调试信息。

5. 告警与日志

4.13.16 LDAP认证登录失败

1. 故障描述

管理员采用LDAP认证登录设备失败。

2. 常见原因

本类故障的常见原因主要包括：

· 用户线下的认证方式配置错误。

· VTY用户线下支持的协议类型不正确。

· ISP域下配置的认证、授权、计费方案错误。

· 与LDAP服务器交互失败。

3. 故障分析

本类故障的诊断流程如图4-40所示。

图4-40 LDAP认证登录失败的故障诊断流程图

4. 处理步骤

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) 检查用户线类下的配置。

用户线视图下的配置优先于用户线类视图下的配置。若用户线视图下未配置，则需要继续检查用户线类视图下的配置。

执行line class vty命令进入VTY用户线类视图，并通过display this命令查看如下配置是否准确：

¡ authentication-mode是否配置为scheme。

¡ 对于Telnet登录：protocol inbound是否配置为telnet或为缺省情况。

¡ 对于SSH登录：protocol inbound是否配置为ssh或为缺省情况。

如果用户线和用户线类下的配置均不准确，请按照需要，在指定的用户线或用户线类下设置认证方案为scheme，并设置用户登录支持的协议类型。

(3) 检查ISP域下的认证、授权、计费方案配置是否准确。

执行display domain命令，查看显示信息：

¡ 如果用户的登录用户名中携带了域名（假设为test），则查看该域下的“Login authentication scheme:”字段取值是否为“LDAP=xx”。如果该域下无“Login authentication scheme:”字段，再查看“Default authentication scheme:”字段取值是否为“LDAP=xx”。

<Sysname> display domain test

Domain: test

State: Active

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

IGMP access limit: 4

MLD access limit: 4

¡ 如果用户的登录用户名中未携带域名，则在系统视图下执行display this命令查看是否存在domain default enable isp-name配置（下例中缺省域名为system）。

domain default enable system

- 如果存在该配置，则执行display domain命令查看isp-name域下的“Login authentication scheme:”字段取值是否为“LDAP=xx。如果该域下无“Login authentication scheme:”字段，再查看“Default authentication scheme:”字段取值是否为“LDAP=xx”。

- 如果不存在该配置，则执行display domain命令查看system域下的“Login authentication scheme:”字段取值是否为“LDAP=xx”。如果system域下无“Login authentication scheme:”字段，再查看“Default authentication scheme:”字段取值是否为“LDAP=xx”。

如果以上配置不准确，请在相关ISP域下配置Login用户采用LDAP认证方案。LDAP服务器一般只作为认证服务器，授权和计费通常配置为其它方式，比如local、RADIUS或HWTACACS（下例中，认证采用LDAP方案ccc、授权和计费为local）。

<Sysname> system-view

[Sysname] domain test

[Sysname-isp-test] authentication login ldap-scheme ccc

[Sysname-isp-test] authorization login local

[Sysname-isp-test] accounting login local

(4) 通过LDAP的调试信息辅助排查如下故障。

执行debugging ldap error命令打开LDAP错误调试信息开关，可根据系统打印的如下调试信息定位问题：

¡ “Failed to perform binding operation as administrator.“表示LDAP服务器视图下配置的管理员用户DN不存在或管理员密码不正确。针对此问题，可以进入LDAP服务器视图，执行login-dn和login-password命令修改管理员用户DN和密码配置（下例中管理员权限的用户DN为cn=administrator,cn=users,dc=ld、管理员密码为admin!123456）。

<Sysname> system-view

[Sysname] ldap server ldap1

[Sysname-ldap-server-ldap1] login-dn cn=administrator,cn=users,dc=ld

[Sysname-ldap-server-ldap1] login-password simple admin!123456

¡ “Failed to get bind result.errno = 115”表示对端未开启LDAP服务或LDAP服务器异常。针对此问题，可以联系LDAP服务器管理员解决。

¡ “Bind operation failed.”表示设备与LDAP服务器之间不可达，可以尝试排查设备和服务器中间链路不通的问题。

¡ “Failed to perform binding operation as user.”表示LDAP用户密码错误。

¡ “Failed to bind user username for the result of searching DN is NULL.”表示LDAP用户不存在。针对此问题，可以联系LDAP服务器管理员解决。

(5) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息、诊断信息。

¡ 打开LDAP调试信息开关（通过debugging ldap all命令），收集设备的调试信息。

5. 告警与日志

4.13.17 RADIUS认证服务器下发的动态VLAN不生效

1. 故障描述

802.1X或MAC地址认证用户在线的情况下，RADIUS认证服务器为其动态下发的VLAN授权属性不生效。

2. 常见原因

本类故障的常见原因主要包括：

· 未开启RADIUS DAE服务。

· RADIUS下发的授权属性内容不正确。

· 接入用户未获取到动态VLAN。

· 动态授权的VLAN所属接口类型配置错误。

· 动态授权的VLAN不存在。

3. 故障分析

本类故障的诊断流程如图4-50所示。

4.14 Password Control故障处理

4.14.1 管理员登录时系统要求修改密码

1. 故障描述

管理员采用本地认证方式登录设备时，系统判断密码强度不符合要求，提示用户修改当前的登录密码。

2. 常见原因

本类故障的常见原因主要包括：

· 本地用户视图下配置的Password Control密码检查强度高。

· 本地用户组视图下配置的Password Control密码检查强度高。

· 系统视图下配置的Password Control密码检查强度高。

3. 故障分析

本类故障的诊断流程如图4-41所示。

图4-41 管理员登录时要求修改密码故障诊断流程图

4. 处理步骤

(1) 判断是否降低当前密码检查强度。

开启全局密码管理功能后，通过Telnet、SSH、HTTP、HTTPS方式登录的设备管理类用户，输入登录密码时，系统会根据当前设定的Password control密码组合检测策略、密码最小长度限制以及密码复杂度检查策略检查对用户的登录密码进行检查，若不符合以上密码检查策略要求，则视为弱密码。系统缺省的密码检查策略请查看“安全配置指导”中的“Password Control”。

缺省情况下，用户使用弱密码登录设备时，系统会打印弱密码提示信息。如果当前的密码检查强度高于实际登录控制需求，请在确定修改范围（指定的本地用户、指定的用户组、所有本地用户）之后，按照如下步骤降低相应视图下的密码检查强度。

(2) 降低本地用户的Password Control密码检查强度。

执行local-user命令，进入本地用户视图：

¡ 通过password-control composition命令配置密码组合策略（下例中密码元素的最少组合类型为4种，至少要包含每种元素的个数为5个）。

¡ 通过password-control length命令配置密码最小长度（下例中密码最小长度为16个字符）。

¡ 通过password-control complexity命令配置密码复杂度检查策略（下例中为检查密码中是否包含用户名）。

<Sysname> system-view

[Sysname] local-user test class manage

[Sysname-luser-manage-test] password-control composition type-number 4 type-length 5

[Sysname-luser-manage-test] password-control length 16

[Sysname-luser-manage-test] password-control complexity user-name check

(3) 降低用户组的Password Control密码检查强度。

执行user-group命令，进入本地用户视图：

¡ 通过password-control composition命令配置密码组合策略。

¡ 通过password-control length命令配置密码最小长度。

¡ 通过password-control complexity命令配置密码复杂度检查策略。

(4) 降低所有本地用户的Password Control密码检查强度。

在系统视图下：

¡ 通过password-control composition命令配置密码组合策略。

¡ 通过password-control length命令配置密码最小长度。

¡ 通过password-control complexity命令配置密码复杂度检查策略。

(5) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、诊断信息、提示信息。

5. 告警与日志

4.14.2 创建本地用户或配置用户密码失败

1. 故障描述

创建本地用户失败，系统打印提示信息“Add user failed.”。

配置本地用户密码失败，系统打印提示信息“Operation failed.”。

2. 常见原因

本类故障的常见原因主要包括：

· 设备的内存使用率达到指定门限。

· 设备的本地文件系统存储空间不足。

· 设备本地的lauth.dat文件异常。

3. 故障分析

本类故障的诊断流程如图4-42所示。

图4-42 创建本地用户或配置密码失败故障诊断流程图

4. 处理步骤

(1) 检查设备剩余空闲内存值是否进入指定的内存门限。

如果是修改本地用户密码失败，则无需关注内存门限问题，直接进入步骤（2）。

执行display memory-threshold命令查看显示内存告警门限相关信息，通过“Current free-memory state:”字段查看当前内存使用状态。系统内存进入一级（Minor）、二级（Severe）、三级（Critical）告警门限状态期间，不允许创建本地用户。

<Sysname> display memory-threshold

Memory usage threshold: 100%

Free-memory thresholds:

Minor: 96M

Severe: 64M

Critical: 48M

Normal: 128M

Current free-memory state: Normal (secure)

...

可在任意视图下通过执行monitor process命令查看进程统计信息，输入“m”后按照显示的内存排序定位占用内存资源过多的进程，按需进行内存清理。等待内存门限解除后，再次尝试创建本地用户。

(2) 检查设备的本地文件系统存储空间是否不足。

如果设备上输出如下任意一类日志信息，则表示文件系统异常导致此问题：

¡ PWDCTL/3/PWDCTL_FAILED_TO_OPENFILE: Failed to create or open the password file.

¡ PWDCTL/3/PWDCTL_FAILED_TO_WRITEPWD: Failed to write the password records to file.

¡ PWDCTL/3/PWDCTL_NOENOUGHSPACE: Not enough free space on the storage media where the file is located.

请在用户视图下执行dir命令查看本地存储介质（例如flash）的剩余容量信息，如果剩余空间不足，则需要删除无用的文件。

(3) 检查本地lauth.dat文件是否正常。

开启全局密码管理功能后，设备会自动生成lauth.dat文件记录本地用户的认证、登录信息。如果手工删除或修改该文件，会造成本地认证异常。请在用户视图下执行dir命令查看本地存储介质中（例如flash）的lauth.dat文件存在情况。

<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

...

如果该文件不存在、大小为0或者很小（若小于20B，则大概率发生了异常），请优先联系技术支持人员协助处理，若当前配置需求紧迫，可尝试重新开启全局密码管理功能来解决此问题。

<Sysname> system-view

[Sysname] undo password-control enable

[Sysname] password-control enable

以上问题解决后，请尝试重新创建本地用户或配置用户密码。

(4) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、诊断信息、提示信息。

5. 告警与日志

4.14.3 管理员因闲置超时无法登录

1. 故障描述

管理员采用本地认证方式登录设备时，因账户闲置超时无法成功登录，系统打印提示信息“Failed to login because the idle timer expired.”。

2. 常见原因

本类故障的主要原因为，用户自从最后一次成功登录之后，在配置的闲置时间内再未成功登录过，那么该闲置时间到达之后此用户账号立即失效，系统不再允许使用该账号的用户登录。

3. 故障分析

本类故障的诊断流程如图4-43所示。

图4-43 管理员因闲置超时无法登录故障诊断流程图

4. 处理步骤

(1) 确认是否有其它管理员或其它途径可以登录设备。

¡ 如果有其它管理员或其它途径（例如Console口）可以登录设备，则表示仅该用户被禁止登录，因此可以由其它管理员登录后删除该本地用户后重新创建此用户，或修改用户账号的闲置时间（通过password-control login idle-time命令）。若将闲置时间修改为0，则会立即关闭闲置超时检查。

¡ 如果无其它管理员或其它途径可以登录设备，则执行步骤（2）。

(2) 确认设备是否开启了SNMP功能。

尝试是否可以通过NMS（Network Management System，网络管理系统）登录设备：

¡ 若开启了SNMP功能，则可以使用MIB修改系统时间，将系统时间修改为闲置超时之前的某个时间点，再使用此管理员帐号登录设备。修改系统时间对应的MIB节点为HH3C-SYS-MAN-MIB中的hh3cSysLocalClock (1.3.6.1.4.1.25506.2.3.1.1.1)。

管理员再次成功登录后，需要第一时间将系统时间恢复，并关闭用户账号闲置超时检查。

¡ 若未开启SNMP功能，则无法使用MIB。可尝试重启设备，并按提示进入BootWare扩展段菜单后，选择跳过console口认证或者跳过配置文件选项来进入系统。建议在技术支持人员指导下执行此步骤。

(3) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、诊断信息、提示信息。

5. 告警与日志

4.15 SSH故障处理

4.15.1 SSH客户端登录设备失败

1. 故障描述

设备作为SSH服务器，用户使用SSH客户端登录设备失败。

2. 常见原因

本类故障的常见原因主要包括：

· SSH客户端与设备之间路由不通，无法建立TCP连接。

· 设备未开启SSH服务器功能。

· 设备上配置了对SSH客户端的访问控制，且客户端的IP地址不在ACL定义的permit规则范围内。

· 客户端指定的服务端口号与服务器端不一致。

· 设备上的SSH版本与客户端不兼容。

· 设备上未生成本地密钥对。

· 服务器主机密钥与设备上缓存的密钥不匹配。

· 用户线的认证方式或接入协议配置不正确。

· 设备上的本地用户视图下未配置SSH服务。

· SSH用户的服务类型或认证方式配置不正确。

· 设备上SSH2协议使用的算法与客户端不匹配。

· 设备上VTY用户线资源不足。

· 设备上SSH登录用户数达到上限。

3. 故障分析

本类故障的诊断流程如图4-44所示。

图4-44 SSH登录失败故障诊断流程图

4. 处理步骤

(1) 检查客户端能否Ping通设备。

使用ping命令检查网络连接情况。

¡ 如果Ping不通，请参见“Ping不通的定位思路”继续定位，确保SSH客户端能Ping通服务器端。

¡ 如果可以Ping通，请执行步骤（2）。

(2) 检查SSH服务器功能是否开启。

当设备上出现如下日志时，表示SSH服务器功能未开启。

SSHS/6/SSHS_SRV_UNAVAILABLE: The SCP server is disabled or the SCP service type is not supported.

可以在设备上执行display ssh server status命令，检查Stelnet服务器功能、SFTP服务器功能、NETCONF over SSH服务器功能和SCP服务器功能是否按需开启。

<Sysname> display ssh server status

Stelnet server: Disable

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

SFTP Server Idle-Timeout: 10 minute(s)

NETCONF server: Disable

SCP server: Disable

¡ 如果未开启，请在设备上执行如下命令，开启相关的SSH服务器功能。

<Sysname> system-view

[Sysname] ssh server enable

[Sysname] sftp server enable

[Sysname] scp server enable

[Sysname] netconf ssh server enable

¡ 如果已开启，请执行步骤（3）。

(3) 检查是否设置了对客户端的访问控制。

首先检查设备上是否通过ssh server acl命令设置了对客户端的访问控制。

¡ 如果已设置，请检查客户端的IP地址是否在ACL的permit规则中。

当设备上出现如下日志时，表示客户端的IP地址不在ACL的permit规则中。

SSHS/5/SSH_ACL_DENY: The SSH connection request from 181.1.1.10 was denied by ACL rule (rule ID=20).

SSHS/5/SSH_ACL_DENY: The SSH connection request from 181.1.1.11 was denied by ACL rule (default rule).

- 如果不在，请修改ACL配置，使得客户端的IP地址在ACL的permit规则中。如果对所有SSH客户端都不需要进行访问控制，请删除对客户端的访问控制。

- 如果在，请执行步骤（4）。

¡ 如果未设置，请执行步骤（4）。

(4) 检查客户端指定的服务端口号是否与服务器端一致。

如果服务器端修改了SSH服务端口号，客户端仍然使用缺省端口号登录时，会出现登录失败。

以我司设备作为客户端为例，会出现如下错误提示信息：Failed to connect to host 10.1.1.1 port 100.

¡ 如果客户端登录时指定的端口号与服务器端不一致，请在服务器端设备上执行display current-configuration | include ssh命令查看服务器端配置的端口号，将客户端登录时指定的端口修改为与服务器端一致。

¡ 如果客户端登录时指定的端口号与服务器端一致，请执行步骤（5）。

(5) 检查服务器的SSH版本与客户端版本是否兼容。

当设备上出现如下日志时，表示设备的SSH版本与客户端版本不兼容。

SSHS/6/SSHS_VERSION_MISMATCH: SSH client 192.168.30.117 failed to log in because of version mismatch.

如果使用SSH1版本的客户端登录设备，可以在设备上执行display ssh server status命令查看SSH version字段确认SSH版本。

¡ 如果SSH version显示为1.99，则表示设备可以兼容SSH1版本的客户端，请执行步骤（6）。

¡ 如果SSH version显示为2.0，请在设备上执行ssh server compatible-ssh1x enable命令设置设备兼容SSH1版本的客户端。

(6) 检查服务器上是否生成了本地密钥对。

设备作为SSH服务器时，必须配置本地非对称密钥对。虽然一个客户端只会采用DSA、ECDSA或RSA公钥算法中的一种来认证服务器，但是由于不同客户端支持的公钥算法不同，为了确保客户端能够成功登录服务器，建议在服务器上生成DSA、ECDSA和RSA三种密钥对。

在设备上执行display public-key local public命令查看当前设备上的密钥对信息。

¡ 如果DSA、ECDSA和RSA三种密钥对都不存在，请执行public-key local create命令依次进行配置。

¡ 如果已配置，请执行步骤（7）。

(7) 检查服务器主机密钥与客户端上缓存的服务器主机密钥对是否一致。

如果客户端首次登录服务器设备时选择保存了服务器端主机密钥，当服务器设备更新本地密钥对后，将会导致客户端认证服务端失败。

以我司设备作客户端为例，当客户端登录时，出现如下提示信息，则表示服务器主机密钥与客户端上本地缓存的密钥不一致。

The server's host key does not match the local cached key. Either the server administrator has changed the host key, or you connected to another server pretending to be this server. Please remove the local cached key, before logging in!

¡ 如果不一致，请执行undo public-key peer命令，删除客户端保存的旧的服务端主机密钥。

¡ 如果一致，请执行步骤（8）。

(8) 查看VTY用户线下配置的认证方式及允许接入的协议是否正确。

当客户端为Stelnet客户端和NETCONF over SSH客户端时，需要在VTY用户线视图下，执行display this命令查看配置的认证方式是否为scheme、允许接入的协议是否包含SSH。

[Sysname] line vty 0 63

[Sysname-line-vty0-63] display this

line vty 0 63

authentication-mode scheme

user-role network-admin

idle-timeout 0 0

¡ 如果认证方式或者接入协议配置不正确，请将认证方式修改为scheme、将允许接入的协议修改为包含SSH。

¡ 如果均配置正确，请执行步骤（9）。

(9) 检查本地用户是否授权了SSH服务。（仅针对本地认证）

在本地用户视图下，执行display this命令查看用户可以使用的服务类型是否包含SSH。

[Sysname] local-user test

[Sysname-luser-manage-test] display this

local-user test class manage

service-type ssh

authorization-attribute user-role network-admin

authorization-attribute user-role network-operator

¡ 如果不包含，请在本地用户视图下通过service-type命令修改配置。

¡ 如果包含，请执行步骤（10）。

如果为远程认证方式，请参见“AAA故障处理”进行定位。

(10) 检查是否配置了SSH用户并指定正确的服务类型和认证方式。

SSH支持Stelnet、SFTP、NETCONF和SCP四种用户服务类型。

首先，根据服务器采用的认证类型，根据如下规则，查看设备上是否创建正确的SSH用户。

¡ 如果服务器采用了publickey认证，则必须在设备上创建相应的SSH用户，以及同名的本地用户（用于下发授权属性：工作目录、用户角色）。

¡ 如果服务器采用了password认证，则必须在设备上创建相应的本地用户（适用于本地认证），或在远程服务器（如RADIUS服务器，适用于远程认证）上创建相应的SSH用户。这种情况下，并不需要通过本配置创建相应的SSH用户，如果创建了SSH用户，则必须保证指定了正确的服务类型以及认证方式。

¡ 如果服务器采用了keyboard-interactive、password-publickey或any认证，则必须在设备上创建相应的SSH用户，以及在设备上创建同名的本地用户（适用于本地认证）或者在远程认证服务器上创建同名的SSH用户（如RADIUS服务器，适用于远程认证）。

接着，根据检查的结果，进行如下操作：

¡ 如果未创建且无需创建，请执行步骤（11）；如果未创建但有需求创建，请通过ssh user命令进行配置。

¡ 如果已创建，检查SSH用户的服务类型和认证方式。

- SSH用户指定的服务类型必须与客户端类型（Stelnet客户端、SFTP客户端、SCP客户端和NETCONF over SSH客户端）相匹配，否则将会因为服务类型不匹配而登录失败。SSH用户服务类型是否正确，通过如下方式来检查：

以SCP客户端为例，如果设备上出现如下日志，表示服务类型不匹配。SSHS/6/SSHS_SRV_UNAVAILABLE: The SCP server is disabled or the SCP service type is not supported.

请在设备系统视图下执行ssh user命令，修改SSH用户的服务类型。

- 请在设备上执行display ssh user-information命令，查看SSH服务器采用的认证方式，根据具体的认证方式检查设备上SSH用户的配置是否正确。

(11) 检查设备上SSH2协议使用的算法列表是否与客户端匹配。

通过display ssh2 algorithm命令查看当前SSH2协议使用的算法列表，检查客户端支持的算法是否包含在算法列表中。比如，设备上配置了不使用CBC相关的加密算法，但SSH客户端仅支持CBC相关加密算法，将导致该客户端无法登录服务器。

当设备上出现如下日志信息时，表示设备上SSH2协议使用的算法列表是否与客户端不匹配。

SSHS/6/SSHS_ALGORITHM_MISMATCH: SSH client 192.168.30.117 failed to log in because of encryption algorithm mismatch.

¡ 如果客户端使用的算法与设备上的算法不匹配，可通过如下两种方式进行修改：

- 设备可以通过执行ssh2 algorithm cipher、ssh2 algorithm key-exchange、ssh2 algorithm mac或ssh2 algorithm public-key命令修改相关算法列表，增加客户端支持的算法。

- 在客户端添加服务端支持的相关算法。

¡ 如果客户端使用的算法与设备上的算法能够匹配，请执行步骤（12）。

(12) 检查设备上VTY用户数是否达到允许用户数的上限。

SSH用户与Telnet用户登录均使用VTY用户线，但是VTY用户线是有限资源。若VTY类型用户线都已被占用，则后续使用Stelnet及NETCONF over SSH服务的客户端将无法登录，使用SFTP及SCP服务的客户端不占用用户线资源，不受影响，仍可登录。

当设备上出现如下日志时，表示设备上VTY用户数已达到允许用户数的上限。

SSHS/6/SSHS_REACH_USER_LIMIT: SSH client 192.168.30.117 failed to log in, because the number of users reached the upper limit.

通过display line命令查看VTY用户线资源是否充足。

¡ 如果VTY用户线资源不足，可将空闲且非scheme认证方式的VTY类型用户线认证方式修改为scheme认证方式；若所有VTY类型用户线都已是scheme认证方式且均处于active状态，可执行free line vty命令强制释放VTY用户线，使得新的SSH用户能够上线。

¡ 如果VTY用户线资源充足，请执行步骤（13）。

(13) 检查登录服务器的SSH用户数是否达到允许用户数的上限。

通过display ssh server session命令查看服务器的会话信息，以及查看通过aaa session-limit ssh命令配置的SSH最大用户连接数。

当设备上出现如下日志时，表示登录服务器的SSH用户数已达到允许用户数的上限。

SSHS/6/SSHS_REACH_SESSION_LIMIT: SSH client 192.168.30.117 failed to log in. The number of SSH sessions is 10, and exceeded the limit (10).

¡ 如果SSH会话数已达到上限，可通过执行aaa session-limit ssh命令调大上限；如果配置的最大用户连接数已为可配置的最大值，可执行free ssh命令强制释放已建立的部分SSH连接或者执行free line vty命令强制释放VTY用户线，使得新的SSH用户能够上线。

¡ 如果未达上限，请执行步骤（14）。

(14) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息。

5. 告警与日志

4.15.2 设备作为SSH服务器，用户使用password认证方式登录失败

1. 故障描述

设备作为SSH服务器，用户使用密码认证登录设备失败。

2. 常见原因

本类故障的常见原因主要包括：

· SSH客户端与设备之间路由不通，无法建立TCP连接。

· SSH客户端登录密码不正确。

· 设备未开启SSH服务器功能。

· SSH服务器上不存在该SSH登录用户。

· 设备上配置了对SSH客户端的访问控制，且客户端的IP地址不在ACL定义的permit规则范围内。

· 设备上SSH登录用户数达到上限。

· 设备上的SSH版本与客户端不兼容。

· SSH用户的服务类型或认证方式配置不正确。

· 设备上未生成本地密钥对。

· SCP/SFTP工作目录不正确。

3. 故障分析

本类故障的诊断流程如图4-45所示。

图4-45 SSH客户端使用password认证方式登录服务器失败（设备作为服务器）故障诊断流程图

4. 处理步骤

(1) 检查客户端能否Ping通设备。

使用ping命令查看网络连接情况。

¡ 如果Ping不通，请参见“Ping不通的定位思路”继续定位，确保SSH客户端能Ping通服务器端。

¡ 如果可以Ping通，请执行步骤（2）。

(2) 检查登录密码是否正确。

a. 如果服务器采用本地认证，请确认当前用户登录的密码是否与设备上设备管理类本地用户视图下配置的密码一致：

- 如果不一致，请重新输入正确的密码。若忘记密码，可以进入设备管理类本地用户视图（用户名为当前登录的用户）下，执行password命令重新配置新的密码，确保登录密码与配置的密码一致。

- 如果一致，请执行步骤4.15.1 4. (2)。

b. 如果服务器采用远程认证，请确认当前用户登录的密码是否与认证服务器上配置的一致：

- 如果不一致，请重新输入正确的密码。若忘记密码，可以在服务器上为登录用户重新设置密码，确保登录密码与认证服务器上配置的一致。

- 如果一致，请执行步骤4.15.1 4. (2)。

(3) 检查SSH服务器功能是否开启。

当设备上出现如下日志时，表示SSH服务器功能未开启。

SSHS/6/SSHS_SRV_UNAVAILABLE: The SCP server is disabled or the SCP service type is not supported.

可以在设备上执行display ssh server status命令，检查Stelnet服务器功能、SFTP服务器功能、NETCONF over SSH服务器功能和SCP服务器功能是否按需开启。

<Sysname> display ssh server status

Stelnet server: Disable

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

SFTP Server Idle-Timeout: 10 minute(s)

NETCONF server: Disable

SCP server: Disable

¡ 如果未开启，请在设备上执行如下命令，开启相关的SSH服务器功能。

<Sysname> system-view

[Sysname] ssh server enable

[Sysname] sftp server enable

[Sysname] scp server enable

[Sysname] netconf ssh server enable

¡ 如果已开启，请执行步骤（4）。

(4) 检查客户端指定的服务端口号是否与服务器端一致。

如果服务器端修改了SSH服务端口号，客户端仍然使用缺省端口号登录时，会出现登录失败。

以我司设备作为客户端为例，会出现如下错误提示信息：Failed to connect to host 10.1.1.1 port 22.

¡ 如果客户端登录时指定的端口号与服务器端一致，请执行步骤（5）。

(5) 检查是否设置了对客户端的访问控制。

首先检查设备上是否通过ssh server acl命令设置了对客户端的访问控制。

¡ 如果已设置，请检查客户端的配置是否在ACL的permit规则中，请先在设备上通过ssh server acl-deny-log enable命令开启匹配ACL deny规则后打印日志信息功能。

当设备上出现如下日志时，表示客户端的IP地址不在ACL的permit规则中。

SSHS/5/SSH_ACL_DENY: The SSH connection request from 181.1.1.10 was denied by ACL rule (rule ID=20).

SSHS/5/SSH_ACL_DENY: The SSH connection request from 181.1.1.11 was denied by ACL rule (default rule).

- 如果不在，请修改ACL配置，使得客户端的IP地址在ACL的permit规则中。如果对所有SSH客户端都不需要进行访问控制，请删除对客户端的访问控制。

- 如果在，请执行步骤4.15.1 4. (5)。

¡ 如果未设置，请执行步骤4.15.1 4. (5)。

(6) 检查服务器的SSH版本与客户端版本是否兼容。

当设备上出现如下日志时，表示设备的SSH版本与客户端版本不兼容。

SSHS/6/SSHS_VERSION_MISMATCH: SSH client 192.168.30.117 failed to log in because of version mismatch.

如果使用SSH1版本的客户端登录设备，可以在设备上执行display ssh server status命令查看SSH version字段确认SSH版本。

¡ 如果SSH version显示为1.99，则表示设备可以兼容SSH1版本的客户端，请执行步骤4.15.1 4. (8)。

¡ 如果SSH version显示为2.0，请在设备上执行ssh server compatible-ssh1x enable命令设置设备兼容SSH1版本的客户端。

(7) 查看VTY用户线下配置的认证方式及允许接入的协议是否正确。

当客户端为Stelnet客户端或NETCONF over SSH客户端时，需要在VTY用户线视图下，执行display this命令查看配置的认证方式是否为scheme、允许接入的协议是否包含SSH。

[Sysname] line vty 0 63

[Sysname-line-vty0-63] display this

line vty 0 63

authentication-mode scheme

user-role network-admin

idle-timeout 0 0

¡ 如果认证方式或者接入协议配置不正确，请通过authentication-mode scheme命令将认证方式修改为scheme、通过protocol inbound ssh命令将允许接入的协议修改为包含SSH。

¡ 如果均配置正确，请执行步骤4.15.1 4. (12)。

(8) 检查设备上VTY用户数是否达到允许用户数的上限。

当设备上出现如下日志时，表示设备上VTY用户数已达到允许用户数的上限。

SSHS/6/SSHS_REACH_USER_LIMIT: SSH client 192.168.30.117 failed to log in, because the number of users reached the upper limit.

通过display line命令查看VTY用户线资源是否充足。

¡ 如果VTY用户线资源充足，请执行步骤（13）。

(9) 检查登录服务器的SSH用户数是否达到允许用户数的上限。

通过display ssh server session命令查看服务器的会话信息，以及查看通过aaa session-limit ssh命令配置的SSH最大用户连接数。

当设备上出现如下日志时，表示登录服务器的SSH用户数已达到允许用户数的上限。

SSHS/6/SSHS_REACH_SESSION_LIMIT: SSH client 192.168.30.117 failed to log in. The number of SSH sessions is 10, and exceeded the limit (10).

¡ 如果SSH会话数已达到上限，可通过执行aaa session-limit ssh命令调大上限；如果配置的最大用户连接数已为可配置的最大值，可执行free line vty命令强制释放VTY用户线，使得新的SSH用户能够上线。

¡ 如果未达上限，请执行步骤（10）。

(10) 检查服务器上是否生成了本地密钥对。

为了防止“伪服务器欺骗”，客户端验证服务器身份时，首先判断服务器发送的公钥与本地保存的服务器公钥是否一致，确认服务器公钥正确后，再使用该公钥对服务器发送的数字签名进行验证。如果客户端没有保存服务器的公钥或保存的服务器公钥不正确，则服务器身份验证将会失败，从而导致客户端无法登录服务器。因此，客户端登录服务器之前，需要先在服务器端创建密钥对，并将正确的服务器公钥保存在客户端。

虽然一个客户端只会采用DSA、ECDSA或RSA公钥算法中的一种来认证服务器，但是由于不同客户端支持的公钥算法不同，为了确保客户端能够成功登录服务器，建议在服务器上生成DSA、ECDSA和RSA三种密钥对。

在设备上执行display public-key local public命令查看当前设备上的密钥对信息。

¡ 如果DSA、ECDSA和RSA三种密钥对都不存在，请执行public-key local create命令依次进行配置，并确保将服务器上生成的公钥保存到客户端。

¡ 如果已配置，请执行步骤4.15.1 4. (10)。

(11) 检查是否配置了SSH用户并指定正确的服务类型和认证方式。

SSH支持Stelnet、SFTP、NETCONF和SCP四种用户服务类型。

首先，根据服务器采用的认证类型，查看设备上是否创建正确的SSH用户。

由于服务器采用了password认证，必须在设备上创建相应的本地用户（适用于本地认证），或在远程服务器（如RADIUS服务器，适用于远程认证）上创建相应的SSH用户。对于采用远程认证方式的情况，不需要通过本配置创建相应的SSH用户，如果创建了SSH用户，则必须保证指定了正确的服务类型以及认证方式。

接着，根据检查的结果，进行如下操作：

¡ 如果未创建且无需创建，请执行步骤（12）；如果未创建且需要创建，请通过ssh user命令进行配置。

¡ 如果已创建，检查SSH用户的服务类型和认证方式。

- 请在设备上执行display ssh user-information命令，分别通过“Service-type”和“Authentication-type”字段查看SSH用户的服务类型及认证方式。其中，服务类型必须与客户端类型（Stelnet客户端、SFTP客户端、SCP客户端或NETCONF over SSH客户端）相匹配，认证方式必须为password。

- 请在设备系统视图下执行ssh user命令，将SSH用户的服务类型和认证方式修改正确。

(12) 检查SCP/SFTP工作目录配置是否正确。

当SSH用户的服务方式为SCP/SFTP时，需要为用户设置授权目录。如果所配置的授权目录不存在，SCP/SFTP客户端通过该用户连接SCP/SFTP服务器就会失败。对于password认证方式的用户，请检查通过AAA授权的工作目录是否存在。

¡ 如果不存在，请通过本地用户视图下的authorization-attribute work-directory directory-name命令修改授权的工作目录。

¡ 如果存在，请执行步骤（13）。

(13) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息。

5. 告警与日志

4.15.3 设备作为SSH服务器，用户使用publickey认证方式登录失败

1. 故障描述

设备作为SSH服务器，用户使用公钥认证登录失败。

2. 常见原因

本类故障的常见原因主要包括：

· SSH客户端与设备之间路由不通，无法建立TCP连接。

· 服务器端配置的用户公钥不正确。

· 设备未开启SSH服务器功能。

· SSH服务器上不存在该SSH登录用户。

· 设备上配置了对SSH客户端的访问控制，且客户端的IP地址不在ACL定义的permit规则范围内。

· 设备上SSH登录用户数达到上限。

· 设备上的SSH版本与客户端不兼容。

· SSH用户的服务类型或认证方式配置不正确。

· 设备上未生成本地密钥对。

· SCP/SFTP工作目录不正确。

3. 故障分析

本类故障的诊断流程如图1-2所示。

图4-46 SSH客户端使用publickey认证方式登录服务器失败（设备作为服务器）故障诊断流程图

4. 处理步骤

(1) 检查客户端能否Ping通设备。

使用ping命令查看网络连接情况。

¡ 如果Ping不通，请参见“Ping不通的定位思路”继续定位，确保SSH客户端能Ping通服务器端。

¡ 如果可以Ping通，请执行步骤（2）。

(2) 检查服务器端配置的用户公钥和用户使用的私钥是否匹配。

SSH客户端可能支持多种公钥算法，每种公钥算法对应不同的非对称密钥对。只有服务器端保存的用户公钥类型与用户登录时使用的私钥类型一致时，用户认证才会成功。例如，服务器端为某用户指定了DSA类型的公钥，用户也持有与之相匹配的私钥，但是登录时用户使用的私钥类型为RSA，此时用户认证会失败。通过在设备上执行display public-key peer命令查看保存在设备上的客户端公钥信息，判断是否与正在登录用户使用的私钥类型一致：

¡ 如果不一致，请执行public-key local create命令在设备上生成相应类型的密钥对。

¡ 如果一致，请执行步骤（3）。

(3) 检查SSH服务器功能是否开启。

当设备上出现如下日志时，表示SSH服务器功能未开启。

SSHS/6/SSHS_SRV_UNAVAILABLE: The SCP server is disabled or the SCP service type is not supported.

可以在设备上执行display ssh server status命令，检查Stelnet服务器功能、SFTP服务器功能、NETCONF over SSH服务器功能和SCP服务器功能是否按需开启。

<Sysname> display ssh server status

Stelnet server: Disable

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

SFTP Server Idle-Timeout: 10 minute(s)

NETCONF server: Disable

SCP server: Disable

¡ 如果未开启，请在设备上执行如下命令，开启相关的SSH服务器功能。

<Sysname> system-view

[Sysname] ssh server enable

[Sysname] sftp server enable

[Sysname] scp server enable

[Sysname] netconf ssh server enable

¡ 如果已开启，请执行步骤（4）。

(4) 检查客户端指定的服务端口号是否与服务器端一致。

如果服务器端修改了SSH服务端口号，客户端仍然使用缺省端口号登录时，会出现登录失败。

以我司设备作为客户端为例，会出现如下错误提示信息：Failed to connect to host 10.1.1.1 port 100.

¡ 如果客户端登录时指定的端口号与服务器端一致，请执行步骤（5）。

(5) 检查是否设置了对客户端的访问控制。

首先检查设备上是否通过ssh server acl命令设置了对客户端的访问控制。

¡ 如果已设置，请检查客户端配置是否在ACL的permit规则中，请先在设备上通过ssh server acl-deny-log enable命令开启匹配ACL deny规则后打印日志信息功能。

当设备上出现如下日志时，表示客户端的IP地址不在ACL的permit规则中。

SSHS/5/SSH_ACL_DENY: The SSH connection request from 181.1.1.10 was denied by ACL rule (rule ID=20).

SSHS/5/SSH_ACL_DENY: The SSH connection request from 181.1.1.11 was denied by ACL rule (default rule).

- 如果不在，请修改ACL配置，使得客户端的IP地址在ACL的permit规则中。如果对所有SSH客户端都不需要进行访问控制，请删除对客户端的访问控制。

- 如果在，请执行步骤（6）。

¡ 如果未设置，请执行步骤（6）。

(6) 检查服务器的SSH版本与客户端版本是否兼容。

当设备上出现如下日志时，表示设备的SSH版本与客户端版本不兼容。

SSHS/6/SSHS_VERSION_MISMATCH: SSH client 192.168.30.117 failed to log in because of version mismatch.

如果使用SSH1版本的客户端登录设备，可以在设备上执行display ssh server status命令查看SSH version字段确认SSH版本。

¡ 如果SSH version显示为1.99，则表示设备可以兼容SSH1版本的客户端，请执行步骤（7）。

¡ 如果SSH version显示为2.0，请在设备上执行ssh server compatible-ssh1x enable命令设置设备兼容SSH1版本的客户端。

(7) 查看VTY用户线下配置的认证方式及允许接入的协议是否正确。

[Sysname] line vty 0 63

[Sysname-line-vty0-63] display this

line vty 0 63

authentication-mode scheme

user-role network-admin

idle-timeout 0 0

¡ 如果均配置正确，请执行步骤（8）。

(8) 检查设备上VTY用户数是否达到允许用户数的上限。

当设备上出现如下日志时，表示设备上VTY用户数已达到允许用户数的上限。

SSHS/6/SSHS_REACH_USER_LIMIT: SSH client 192.168.30.117 failed to log in, because the number of users reached the upper limit.

通过display line命令查看VTY用户线资源是否充足。

¡ 如果VTY用户线资源充足，请执行步骤（9）。

(9) 检查登录服务器的SSH用户数是否达到允许用户数的上限。

通过display ssh server session命令查看服务器的会话信息，以及查看通过aaa session-limit ssh命令配置的SSH最大用户连接数。

当设备上出现如下日志时，表示登录服务器的SSH用户数已达到允许用户数的上限。

SSHS/6/SSHS_REACH_SESSION_LIMIT: SSH client 192.168.30.117 failed to log in. The number of SSH sessions is 10, and exceeded the limit (10).

¡ 如果未达上限，请执行步骤（10）。

(10) 检查服务器上是否生成了本地密钥对。

在设备上执行display public-key local public命令查看当前设备上的密钥对信息。

¡ 如果DSA、ECDSA和RSA三种密钥对都不存在，请执行public-key local create命令依次进行配置。

¡ 如果已配置，请执行步骤（11）。

(11) 检查是否配置了SSH用户并指定正确的服务类型和认证方式。

SSH支持Stelnet、SFTP、NETCONF和SCP四种用户服务类型。

首先，根据服务器采用的认证类型，查看设备上是否创建正确的SSH用户。

由于服务器采用了publickey认证，则必须在设备上创建相应的SSH用户，以及同名的本地用户（用于下发授权属性：工作目录、用户角色）。

接着，根据检查的结果，进行如下操作：

¡ 如果未创建，请通过ssh user命令进行配置。

¡ 如果已创建，检查SSH用户的服务类型和认证方式。

- 请在设备系统视图下执行ssh user命令，将SSH用户的服务类型和认证方式修改正确。。

(12) 检查SCP/SFTP工作目录配置是否正确。

当SSH用户的服务方式为SCP/SFTP时，需要为该用户设置授权目录。如果所配置的授权目录不存在，SCP/SFTP客户端通过该用户连接SCP/SFTP服务器就会失败。对于publickey认证方式的用户，请检查通过AAA授权的工作目录是否存在。

¡ 如果不存在，请通过本地用户视图下的authorization-attribute work-directory directory-name命令修改授权的工作目录。

¡ 如果存在，请执行步骤（13）。

(13) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息。

5. 告警与日志

4.15.4 设备作为SSH客户端，用户使用password认证方式登录失败

1. 故障描述

设备作为SSH客户端，用户使用password认证方式登录SSH服务器失败。

2. 常见原因

本类故障的常见原因主要包括：

· SSH客户端与服务器端之间路由不通，无法建立TCP连接。

· SSH客户端登录密码不正确。

· 服务器上未生成本地密钥对。

· 服务器主机密钥与SSH客户端上缓存的密钥不匹配。

· 客户端的SSH版本与服务器端不兼容。

3. 故障分析

本类故障的诊断流程如图4-47所示。

图4-47 设备作为客户端采用password认证方式登录SSH服务器失败故障诊断流程图

4. 处理步骤

(1) 检查客户端能否Ping通服务器端。

使用ping命令查看网络连接情况。

¡ 如果Ping不通，请参见“Ping不通的定位思路”继续定位，确保SSH客户端能Ping通服务器端。

¡ 如果可以Ping通，请执行步骤（2）。

(2) 检查登录密码是否正确。

a. 如果服务器采用本地认证，请确认当前用户登录的密码是否与设备上设备管理类本地用户视图下配置的密码一致：

- 如果不一致，请重新输入正确的密码。若忘记密码，可以在服务器上进入设备管理类本地用户视图（用户名为当前登录的用户）下，执行password命令重新配置新的密码，确保登录密码与配置的密码一致（此处以我司设备作为SSH服务器为例）。

- 如果一致，请执行步骤（3）。

b. 如果服务器采用远程认证，请确认当前用户登录的密码是否与认证服务器上配置的一致：

- 如果不一致，请重新输入正确的密码。若忘记密码，可以在服务器上为登录用户重新设置密码，确保登录密码与认证服务器上配置的一致。

- 如果一致，请执行步骤（3）。

(3) 检查服务器上是否生成了本地密钥对。

以我司设备作为SSH服务器为例，在服务器上执行display public-key local public命令查看当前服务器上的密钥对信息。

¡ 如果DSA、ECDSA和RSA三种密钥对都不存在，请执行public-key local create命令依次进行配置，并确保将服务器上生成的公钥保存到客户端。

¡ 如果已配置，请执行步骤（4）。

(4) 检查服务器的SSH版本与客户端版本是否兼容。

以我司设备作为SSH服务器为例，当服务器上出现如下日志时，表示服务器的SSH版本与客户端版本不兼容。

SSHS/6/SSHS_VERSION_MISMATCH: SSH client 192.168.30.117 failed to log in because of version mismatch.

如果使用SSH1版本的客户端登录设备，可以在服务器上执行display ssh server status命令查看SSH version字段确认SSH版本。

¡ 如果SSH version显示为1.99，则表示服务器上可以兼容SSH1版本的客户端，请执行步骤（7）。

¡ 如果SSH version显示为2.0，请在服务器上执行ssh server compatible-ssh1x enable命令设置设备兼容SSH1版本的客户端。

(5) 检查服务器主机密钥与客户端上缓存的服务器主机密钥对是否一致。

如果客户端首次登录服务器设备时选择保存了服务器端主机密钥，当服务器设备更新本地密钥对后，将会导致客户端认证服务端失败。

以我司设备作为SSH服务器为例，当设备作为客户端登录时，若出现如下提示信息，则表示服务器主机密钥与客户端上本地缓存的密钥不一致。

¡ 如果不一致，请在客户端上执行undo public-key peer命令，删除客户端保存的旧的服务端主机密钥。

¡ 如果一致，请执行步骤（6）。

(6) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息。

5. 告警与日志

4.15.5 设备作为SSH客户端，用户使用publickey认证方式登录失败

1. 故障描述

设备作为SSH客户端，用户使用publickey认证方式登录SSH服务器失败。

2. 常见原因

本类故障的常见原因主要包括：

· SSH客户端与服务器端之间路由不通，无法建立TCP连接。

· 服务器上未生成本地密钥对。

· 服务器端配置的用户公钥不正确。

· 服务器主机密钥与SSH客户端上缓存的密钥不匹配。

· 客户端的SSH版本与服务器端不兼容。

3. 故障分析

本类故障的诊断流程如图4-48所示。

图4-48 设备作为客户端使用publickey认证方式登录SSH服务器失败故障诊断流程图

4. 处理步骤

(1) 检查客户端能否Ping通服务器端。

使用ping命令查看网络连接情况。

¡ 如果Ping不通，请参见“Ping不通的定位思路”继续定位，确保SSH客户端能Ping通服务器端。

¡ 如果可以Ping通，请执行步骤（2）。

(2) 检查服务器端配置的用户公钥和用户使用的私钥是否匹配。

SSH客户端可能支持多种公钥算法，每种公钥算法对应不同的非对称密钥对。只有服务器端保存的用户公钥类型与用户登录时使用的私钥类型一致时，用户认证才会成功。例如，服务器端为某用户指定了DSA类型的公钥，用户也持有与之相匹配的私钥，但是登录时用户使用的私钥类型为RSA，此时用户认证会失败。

以我司设备作为SSH服务器为例，通过在服务器上执行display public-key peer命令查看保存在设备上的客户端公钥信息，判断是否与正在登录用户使用的私钥类型一致：

¡ 如果不一致，请执行public-key local create命令在服务器上生成相应类型的密钥对。

¡ 如果一致，请执行步骤（3）。

(3) 检查服务器上是否生成了本地密钥对。

以我司设备作为SSH服务器为例，在服务器上执行display public-key local public命令查看当前服务器上的密钥对信息。

¡ 如果DSA、ECDSA和RSA三种密钥对都不存在，请执行public-key local create命令依次进行配置。

¡ 如果已配置，请执行步骤（4）。

(4) 检查服务器的SSH版本与客户端版本是否兼容。

当服务器上出现如下日志时，表示服务器的SSH版本与客户端版本不兼容。

SSHS/6/SSHS_VERSION_MISMATCH: SSH client 192.168.30.117 failed to log in because of version mismatch.

以我司设备作为SSH服务器为例，如果使用SSH1版本的客户端登录设备，可以在服务器上执行display ssh server status命令查看SSH version字段确认SSH版本。

¡ 如果SSH version显示为1.99，则表示服务器上可以兼容SSH1版本的客户端，请执行步骤（5）。

¡ 如果SSH version显示为2.0，请在服务器上执行ssh server compatible-ssh1x enable命令设置设备兼容SSH1版本的客户端。

(5) 检查服务器主机密钥与客户端上缓存的服务器主机密钥对是否一致。

如果客户端首次登录服务器设备时选择保存了服务器端主机密钥，当服务器设备更新本地密钥对后，将会导致客户端认证服务端失败。

以我司设备作为SSH服务器为例，当设备作为客户端登录时，若出现如下提示信息，则表示服务器主机密钥与客户端上本地缓存的密钥不一致。

¡ 如果不一致，请在客户端上执行undo public-key peer命令，删除客户端保存的旧的服务端主机密钥。

¡ 如果一致，请执行步骤（6）。

(6) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息、告警信息。

5. 告警与日志

4.16 QoS故障处理

4.16.1 流量不匹配分类的定位思路

1. 故障描述

执行display qos policy interface命令查看指定接口上QoS策略的配置信息和运行情况时，发现当前接口上的流量未匹配到QoS策略中的流分类规则。

如下显示信息指定的流分类1中Matched字段为0 (Packets) 0 (Bytes)，表示接口上符合流分类规则的数据包数目为0。需要注意的是，QoS策略中默认存在名称为default-class的流分类，未匹配到QoS策略中其他流分类规则的流量均匹配default-class的流分类。

<Sysname> display qos policy interface gigabitethernet 1/0/1 inbound

Interface: GigabitEthernet1/0/1

Direction: Inbound

Policy: 1

Classifier: default-class

Matched : 213126 (Packets) 40928738 (Bytes)

5-minute statistics:

Forwarded: 20/4208 (pps/bps)

Dropped : 0/0 (pps/bps)

Operator: AND

Rule(s) :

If-match any

Behavior: be

-none-

Classifier: 1

Matched : 0 (Packets) 0 (Bytes)

5-minute statistics:

Forwarded: 0/0 (pps/bps)

Dropped : 0/0 (pps/bps)

Operator: AND

Rule(s) :

If-match acl 3000

Behavior: 1

Marking:

Remark dscp 3

2. 常见原因

本类故障的常见原因主要包括：

· 应用了QoS策略的接口状态为Down，没有转发流量。

· 流分类配置错误，不能匹配到转发流量。

· 流分类中ACL规则匹配的流量执行了更高优先的策略。

3. 故障诊断流程

本类故障的诊断流程如图4-49所示。

图4-49 流量不匹配分类的故障诊断流程图

4. 故障处理步骤

(1) 检查接口物理链路状态是否正常。

在设备上执行display interface命令检查接口状态，例如：

<Sysname> display interface gigabitethernet 1/0/1

GigabitEthernet1/0/1

Interface index: 386

Current state: Administratively DOWN

Line protocol state: DOWN

…

a. 如果Current state显示为Administratively DOWN，则在接口下执行undo shutdown命令打开关闭的接口。

b. 如果Current state显示为DOWN，则检查接口的物理连线。

c. 如果接口物理链路正常，问题仍未解决，则请继续执行以下操作。

(2) 检查设备接口下应用的QoS策略中的流分类配置。

在设备上执行display traffic classifier user-defined命令检查用户定义的流分类的配置信息，关于if-match命令的匹配规则详细信息，请参见“ACL和QoS命令参考”中的“QoS”。

如果流分类的配置错误，则执行traffic classifier命令进入该流分类视图，并执行if-match命令修改流分类的匹配规则。例如：

[Sysname-classifier-1] if-match dscp ef

[Sysname-classifier-1] display this

traffic classifier a operator or

if-match protocol ipv6

if-match dscp ef

请确认Operator字段显示的各规则之间的逻辑关系是否准确。AND表示该流分类下的规则之间是逻辑与的关系，即数据包必须匹配全部规则才属于该类。OR表示该流分类下的规则之间是逻辑或的关系，即数据包匹配任一规则均属于该类。本例中，如果Rule(s)中流分类规则不止一条，且Operator显示字段为AND，则表示该流分类下的规则之间是逻辑与的关系，即数据包必须匹配全部规则才属于该类。此时，请执行traffic classifier命令指定operator参数为or。

<Sysname> display traffic classifier user-defined

User-defined classifier information:

Classifier: 1 (ID 101)

Operator: AND

Rule(s) :

If-match dscp ef

Classifier: 2 (ID 102)

Operator: AND

Rule(s) :

If-match dscp af21

Classifier: 3 (ID 103)

Operator: AND

Rule(s) :

If-match dscp af11

如果QoS策略中的流分类配置正确，问题仍未解决，则请继续执行以下操作。

(3) 当流分类中引用ACL规则进行流量报文匹配时，也可能由于该ACL规则匹配到的流量报文执行了其他更高优先的策略行为导致MQC方式配置的QoS策略未生效，不同策略行为的优先顺序为：

在报文出方向：报文过滤>全局应用MQC方式配置的QoS策略>接口应用MQC方式配置的QoS策略。

在报文入方向：报文过滤>接口应用MQC方式配置的QoS策略>全局应用MQC方式配置的QoS策略。

请执行display current-configuration命令检查当前生效的配置中是否存在上述更高优先级的策略行为相关配置。如果不存在相关配置，问题仍未解决，请继续执行以下操作。

(4) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、日志信息。

5. 告警与日志

6. 处理步骤

(1) 检查RADIUS DAE服务功能是否开启。

请在系统视图下执行display current-configuration | include radius命令查看radius dynamic-author server配置是否存在。

¡ 如果该配置存在，则执行radius dynamic-author server命令进入RADIUS DAE服务器视图下检查RADIUS DAE客户端以及RADIUS DAE服务端口配置是否正确。

<Sysname> system-view

[Sysname] radius dynamic-author server

[Sysname-radius-da-server] display this

radius dynamic-author server

port 3790

client ip 3.3.3.3 key cipher $c$3$kiAORLht3S3rTCmFq0uWXPgV8PjI2Q==

¡ 如果该配置不存在，则执行radius dynamic-author server命令开启RADIUS DAE服务，并进入RADIUS DAE服务器视图配置RADIUS DAE客户端以及RADIUS DAE服务端口（下例中客户端的IP地址为1.1.1.1、共享密钥为123456、服务端口号为3798）。

<Sysname> system-view

[Sysname] radius dynamic-author server

[Sysname-radius-da-server] client ip 1.1.1.1 key simple 123456

[Sysname-radius-da-server] port 3798

(2) 检查RADIUS服务器下发的VLAN属性内容是否准确。

执行debugging radius packet命令打开RADIUS报文调试信息开关，同时让RADIUS服务器尝试再次下发VLAN属性。

RADIUS服务器需要同时下发如下3个标准属性来下发VLAN信息：

¡ 64号属性Tunnel-Type，Integer类型，取值固定为13（VLAN）

¡ 65号属性Tunnel-Medium-Type，Integer类型，取值固定为6（IEEE 802）。

¡ 81号属性Tunnel-Private-Group-Id，String类型，取值为具体的VLAN ID或VLAN名称。

查看打印的RADIUS报文调试信息，检查COA request报文信息中是否携带了上述三个标准属性，如下例所示。

*Aug 3 02:33:18:700 2021 Sysname RADIUS/7/PACKET:

Received a RADIUS packet

Server IP : 128.11.3.48

NAS-IP : 128.11.30.69

VPN instance : --(public)

Server port : 55805

Type : COA request

Length : 41

Packet ID : 34

User-Name="user"

Tunnel-Type:0=VLAN

Tunnel-Medium-Type:0=IEEE-802

Tunnel-Private-Group-Id:0="2"

如果打印的授权属性不准确，请联系RADIUS服务器管理员修改授权VLAN配置并尝试重新下发VLAN，否则继续定位。

(3) 检查用户是否成功获得下发的VLAN信息。

执行display dot1x connection或display mac-authentication connection命令，查看相关在线用户信息中是否存在服务器动态下发的授权VLAN信息：

¡ 如果存在授权VLAN信息，说明VLAN下发成功。

¡ 如果不存在授权VLAN信息，说明VLAN没有下发成功。此时，建议在技术支持人员的指导下，结合RADIUS调试信息继续定位故障发生的原因。

(4) 检查授权的VLAN是否存在。

执行display vlan brief命令查看动态下发的VLAN是否存在。如果该VLAN不存在，请在系统视图下执行vlan vlan-id命令创建。

(5) 检查VLAN所在接口类型是否正确。

不同类型的接口成功加入授权VLAN的要求有所不同，具体配置要求请参见“安全配置指导”中的“802.1X”和“MAC地址认证”。

(6) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

¡ 设备的配置文件、调试信息、诊断信息。

7. 告警与日志

4.17 无线故障处理

CPE5100支持作为AP使用，本手册中的描述和图示不区分AP和CPE。

4.17.1 未开启自动AP配置功能造成AP无法注册

1. 故障描述

在AC上打开调试信息，AC上能够收到AP的报文，但无法注册。

2. 故障处理步骤

(1) 确认AC上是否已经创建手工AP或者已开启自动AP功能，如果没有，则在AC上创建手工AP或者开启自动AP功能。

(2) 如果故障仍然未能排除，请联系技术支持人员。

4.17.2 在AC上无法修改自动AP方式生成的AP服务模板

1. 故障描述

FIT模式下的CPE接入AC后，无法修改其通过自动AP方式生成的AP服务模板。

2. 常见原因

系统固有实现，不支持在AC上修改自动AP方式下的AP服务模板。

3. 故障处理步骤

(1) 登录AC CLI，在系统视图下执行wlan auto-ap persistent命令将自动AP固化为手工AP。

(2) 如果故障仍然未能排除，请联系技术支持人员。

热门推荐

热门推荐

H3C服务器

HPE服务器

热门推荐

H3C存储

HPE存储

热门推荐

商用台式机

商用笔记本

商用显示器

配件

热门推荐

热门推荐

智能终端

技术解决方案

热门推荐

热门推荐

热门推荐

热门推荐

热门推荐

热门推荐

热门推荐

专业安全服务

安全运营服务

热门推荐

热门推荐

热门推荐

热门推荐

热门推荐

技术支持

自助服务

热门推荐

热门推荐

热门推荐

热门推荐

合作伙伴培训与认证

热门推荐

热门推荐

公司刊物

加入我们

国家/地区

H3C CPE5100系列5G无线数据终端 故障处理手册(E1103P01)-5W102

目录

1.1 故障处理注意事项

2.1.1 CPE上电后，串口没有打印信息

2. 故障处理步骤

2. 故障处理步骤

3 Web类故障处理

3.1.1 通过Web登录时，提示“用户数超限！”

2. 常见原因

3. 故障处理步骤

3.1.2 设备升级以后，重新登录Web时失败，提示“功能函数错误”

2. 常见原因

3. 故障处理步骤

4.1.1 Console口密码遗忘

1. 故障描述

2. 常见原因

3. 故障分析

4. 处理步骤

5. 告警与日志

相关告警

相关日志

4.1.2 Telnet登录密码遗忘

1. 故障描述

2. 常见原因

3. 故障分析

4. 处理步骤

5. 告警与日志

相关告警

相关日志

4.1.3 Telnet登录失败

1. 故障描述

2. 常见原因

3. 故障分析

4. 处理步骤

5. 告警与日志

相关告警

相关日志

4.1.4 客户端可以Ping通CPE，也能Telnet到CPE，但是无法通过Web登录成功

H3C CPE5100系列5G无线数据终端故障处理手册(E1103P01)-5W102