如果IRF运行过程中发生过主设备和备设备的角色倒换，则倒换前的主设备和倒换后的主设备上都会存在普通日志文件、诊断日志文件，请按照成员设备编号来命名文件夹，将不同成员设备导出的普通日志文件和诊断日志文件有序的保存至存储路径，以免不同成员设备记录的日志信息相互混淆，影响管理员监控设备运行情况和诊断网络故障。

表1 日志文件介绍

分类	文件名	内容
普通日志文件	logfile.log	设备运行中执行的命令行、发生的事件、状态的变化等信息
诊断日志文件	diagfile.log	设备运行中产生的诊断日志信息，如系统运行到错误流程时的参数值、设备无法启动时的信息、成员设备间通信异常时的握手信息
诊断信息	XXX.tar.gz	系统当前多个功能模块运行的统计信息，包括设备状态、CPU状态、内存状态、配置情况、软件表项、硬件表项等

1.2.2 收集普通日志

(1) 执行logfile save命令将日志文件缓冲区中的内容全部保存到日志文件中。日志文件缺省存储在flash的logfile目录中。

<Sysname> logfile save

The contents in the log file buffer have been saved to the file flash:/logfile/logfile.log

(2) 查看各成员设备中日志文件名称。

¡ 主设备logfile日志：

<Sysname> dir flash:/logfile/

Directory of flash:/logfile

0 -rw- 21863 Jul 11 2015 16:00:37 logfile.log

251904 KB total (147468 KB free)

¡ 从设备（slot 2）上的logfile日志：

<Sysname> dir slot2#flash:/logfile/

Directory of slot2#flash:/logfile

0 -rw- 21863 Jul 11 2015 16:00:37 logfile.log

251904 KB total (147468 KB free)

(3) 使用FTP、TFTP或者USB接口将日志文件传输到指定位置。

1.2.3 收集诊断日志

(1) 执行diagnostic-logfile save命令将诊断日志文件缓冲区中的内容全部保存到诊断日志文件中。诊断日志文件缺省存储在flash的diagfile目录中。

<Sysname> diagnostic-logfile save

The contents in the diagnostic log file buffer have been saved to the file flash:/diagfile/diagfile.log

(2) 查看各成员设备中诊断日志文件的名称。

¡ 主设备diagfile日志：

<Sysname> dir flash:/diagfile/

Directory of flash:/diagfile

0 -rw- 161321 Jul 11 2015 16:16:00 diagfile.log

251904 KB total (147468 KB free)

¡ 从设备（slot 2）上的diagfile日志：

<Sysname> dir slot2#flash:/diagfile/

Directory of slot2#flash:/diagfile

0 -rw- 161321 Jul 11 2015 16:16:00 diagfile.log

251904 KB total (147468 KB free)

(3) 使用FTP或者TFTP接口将日志文件传输到指定位置。

1.2.4 收集诊断信息

诊断信息可以通过两种方式收集：将诊断信息保存到文件，或者将诊断信息直接显示在屏幕上。为保证信息收集的完整性，建议您使用将诊断信息保存到文件的方式收集诊断信息。

需要注意的是，成员设备越多，诊断信息收集的时间越长，信息收集期间不能输入命令，请耐心等待。

通过Console口收集诊断信息所用的时间比通过业务网口收集所用的时间要长。在有可用业务网口或管理口的情况下，建议通过业务网口或管理口登录和传输文件。

(1) 执行display diagnostic-information命令收集诊断信息。

<Sysname> display diagnostic-information

Save or display diagnostic information (Y=save, N=display)? [Y/N] :

(2) 选择将诊断信息保存至文件中，还是将直接在屏幕上显示。

¡ 输入Y，以及保存诊断信息的路径和名称，将诊断信息保存至文件中。

Save or display diagnostic information (Y=save, N=display)? [Y/N] : Y

Please input the file name(*.tar.gz)[flash:/diag_Sysname_20160101-000704.tar.gz] :flash:/diag.tar.gz

Diagnostic information is outputting to flash:/diag.tar.gz.

Please wait...

Save successfully.

<Sysname> dir flash:/

Directory of flash:

……

6 -rw- 898180 Jun 26 2013 09:23:51 diag.tar.gz

251904 KB total (147468 KB free)

¡ 输入N，将诊断信息直接显示在屏幕上（诊断信息的显示随设备型号和版本不同有所差异，请以实际情况为准）。

Save or display diagnostic information (Y=save, N=display)? [Y/N] :N

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

===============display clock===============

23:49:53 UTC Tue 01/01/2016

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

---- More ----

1.3 故障处理求助方式

当故障无法自行解决时，请准备好设备运行信息、故障现象等材料，发送给H3C技术支持人员进行故障定位分析。

用户支持邮箱：service@h3c.com

技术支持热线电话：400-810-0504（手机、固话均可拨打）

技术支持知了社区：http://zhiliao.h3c.com（在线快速问题答复）

2 开局自检

2.1 自检目的

针对客户的项目，提供有针对性的开局指导，规范开局配置，提前消除开局隐患，杜绝低级配置错误，保证项目的顺利进行。

另外，由于产品支持多种组网应用，各个局点的配置均不尽相同。本自检表检查一个比较全面的开局组网，实际开局时可以根据具体情况采用实际应用部分进行自检。

2.2 开局自检项

编码	检查项目	检查分项目	检查方法	结果	备注
1	环境及设备/单板硬件状态检查	环境状况	display environment	□合格 □不合格 □不涉及	设备当前温度应比一般级高温告警门限低20度左右。
		风扇状况	display fan	□合格 □不合格 □不涉及	风扇应该显示Normal。
		电源状况	display power	□合格 □不合格 □不涉及	电源应该显示Normal。
		指示灯状况	观察所有设备/单板的运行灯及告警灯的运行状况	□合格 □不合格 □不涉及	设备/单板运行灯应正常，告警灯应常灭。
		设备/单板运行状况	display device	□合格 □不合格 □不涉及	不应出现absent/fault状态（没插单板的槽位显示为absent状态，此为正常现象）
2	双主控设备自检	主备板软件版本是否一致？	display boot-loader	□合格 □不合格 □不涉及	确保主备板的软件版本一致。
2	双主控设备自检	备用主控板是否保存有配置文件？	使用命令dir	□合格 □不合格 □不涉及	如果不存在配置文件，请执行save命令保存。
3	CPU占用率	CPU的占用率是否忽高忽低？震荡比较大或者一直高？	多次使用display cpu-usage查看	□合格 □不合格 □不涉及	如果CPU占用率过高，请打开debug ip packet查看上CPU报文，根据报文分析原因。
4	内存占用率	设备/主控板/业务板内存占用率是否过高	display memory	□合格 □不合格 □不涉及	排查占用内存过大的模块。
5	端口自检	端口是否协商出了半双工？	display interface brief	□合格 □不合格 □不涉及	例如：如果显示某个端口状态为half，需要确认是否两端配置不一致导致。
		是否在没有必要启动流控端口配置流控？	查看配置,是否开启flow-control 配置	□合格 □不合格 □不涉及	关闭该端口流控:undo flow-control。
		端口出/入方向是否有大量的错误报文？	多次执行display interface，查看errors部分是否有较大数据，并且在增加	□合格 □不合格 □不涉及	1：检查线路和中间连接的光电连接器。 2：两端配置是否一致？例如，是否一端为强制而对端为协商？
		是否有比较频繁的端口UP/DOWN？	display logbuffer	□合格 □不合格 □不涉及	1：检查线路和中间连接的光电连接器。 2：端口检查光功率是否处于临界值？ 3：检查两端配置是否一致？
6	光口自检	光口两端是否配置一致？	display current-configuration interface	□合格 □不合格 □不涉及	H3C设备与其它厂商设备互连，建议光口速率和双工设置要完全一致。
6	光口自检	光口是否有CRC错误？是否在增长？	display interface	□合格 □不合格 □不涉及	检查光功率是否处于临界值？可以通过更换光模块、更换尾纤或清洗光模块连接器的方式解决。
7	Trunk端口的配置自检	端口PVID是否和对端的PVID一致？	display current-configuration interface	□合格 □不合格 □不涉及	两台设备之间互连的Trunk端口允许通过的VLAN配置为一致，并且两端PVID配置为一致。
		端口允许通过的VLAN是否和对端允许通过的VLAN一致？	display current-configuration interface	□合格 □不合格 □不涉及	两台设备之间互连的Trunk端口允许通过的VLAN配置为一致，避免一端配置为允许所有VLAN通过，另外一端没有配置允许所有VLAN通过。
		两台设备互连的端口是否一端配置成Trunk，另一端配置成Access？	display current-configuration interface	□合格 □不合格 □不涉及	根据实际组网情况调整两端的配置到一致状态。
		VLAN 1中是否存在环路？	使用display interface命令查看是否所有设备的Trunk端口都允许VLAN 1通过	□合格 □不合格 □不涉及	根据网络实际情况调整，在不需要VLAN 1通过的端口上取消允许VLAN 1通过。
8	STP自检	检查STP时间因子的设置情况？	display current-configuration	□合格 □不合格 □不涉及	查看配置中是否存在stp timer-factor的配置，如果不存在，建议配置stp timer-factor的值在5～7之间，增加STP的稳定性。
		设备连接PC的端口是否配置为边缘端口？	使用display current interface命令查看端口的配置，如果配置了边缘端口，配置中会有stp edged-port enable的显示	□合格 □不合格 □不涉及	建议您将设备连接PC的端口配置为边缘端口或者关闭该端口的STP功能，将设备与不支持STP的设备相连的端口关闭STP，避免这些端口的UP/DOWN状态干扰STP的计算。
		是否存在运行MSTP/STP/RSTP的H3C设备和运行PVST+的思科设备互通的情况？	检查各个设备上STP的状态计算是否正常	□合格 □不合格 □不涉及	如果存在，建议将H3C设备与思科设备的互连方式改为三层互连，避免MSTP/STP/RSTP和思科私有的PVST＋协议互通。
		不同生成树实例的拓扑是否存在过多重叠路径？	使用display current-configuration interface查看端口配置	□合格 □不合格 □不涉及	根据实际组网需求合理划分VLAN和VLAN与实例的映射关系，尽量使不同VLAN的流量沿不同路径转发。避免不同生成树实例的拓扑有过多重叠路径。
		是否存在TC攻击，导致端口STP状态不停切换？	使用display stp tc，display stp history命令查看端口收发的TC报文计数和STP状态切换时间记录	□合格 □不合格 □不涉及	确认设备和PC连接的端口配置stp edged-port enable或者关闭STP。设备和不支持STP的设备互连的端口关闭STP。
9	VRRP自检	握手时间是否设置成3秒？两端的VRRP握手时间是否一致？	display vrrp	□合格 □不合格 □不涉及	如果VRRP组在5个以下可以统一将VRRP握手时间改为3秒，如果VRRP组过多，可以将VRRP分为五个或三个一组，每组的VRRP握手时间分别配置为3秒、5秒、7秒……
10	OSPF自检	是否有设备Router ID设置成相同？	display ospf peer	□合格 □不合格 □不涉及	如果存在这个问题，会导致路由学习错误，需要修改Route ID后，执行reset ospf process命令重启OSPF进程。
		是否有大量错误？	display ospf statistics error	□合格 □不合格 □不涉及	如果存在大量的OSPF统计错误信息记录，并且还在不断增加，需要抓取信息进一步分析。
		路由是否存在较大震荡？	display ip routing-table statistics 查看added和deleted数据与系统运行时间对应是否比较大	□合格 □不合格 □不涉及	如果有，请仔细分析变化的具体路由，然后根据该路由查找到路由的源设备，分析具体震荡原因。可以在出现故障时，使用display ospf lsdb命令多次查看路由的age信息，确认哪条路由在频繁振荡。
		OSPF状态是否稳定？	display ospf peer	□合格 □不合格 □不涉及	查看OSPF邻居的UP时间。
11	ARP检查	是否存在大量ARP冲突？	display logbuffer	□合格 □不合格 □不涉及	检查冲突地址，根据IP地址排除该主机。
12	路由检查	缺省路由是否正常？是否存在路由环路？	使用tracert 1.1.1.1等明显不存在网段看是否存在路由环路，使用debug ip packet，打印部分报文，看是否存在TTL=1或者=0的报文	□合格 □不合格 □不涉及	如果存在路由环路，请检查对应的设备是否配置正确。调整路由，去掉路由环路。如果存在TTL超时报文，请分析对应网段路由是否正常。
14	攻击检查	是否有大量报文攻击cpu？	通过Probe视图下debug rxtx softcar show命令查看设备/单板的报文限速信息记录	□合格 □不合格 □不涉及	某类报文的统计计数不断增长，说明有攻击存在。

不同产品支持的命令行有所不同。对于上述自检项，可能存在产品不支持相关命令的情况，请根据产品实际情况进行自检。

3 硬件类故障处理

3.1 系统类故障

3.1.1 终端无显示或显示乱码

1. 故障描述

设备上电启动时，配置终端无显示或显示乱码。

2. 常见原因

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

· 电源工作异常。

· 主控板工作异常。

· 配置电缆未连接到设备/主控板的配置口。

· 配置终端参数设置错误。

· 配置电缆故障。

3. 故障分析

本类故障的诊断流程如图1所示：

图1 故障诊断流程图

4. 处理步骤

(1) 检查电源工作是否正常。

如果电源模块指示灯状态异常，请参考电源故障处理章节进行处理。

(2) 检查主控板工作是否正常。

如果主控板指示灯状态异常，请参考主控板故障处理章节进行处理。

(3) 检查配置电缆是否已经连接到设备/主控板的配置口。

(4) 检查配置终端COM口连接是否正确，实际选择的串口与终端设置的串口要一致，串口参数设置是否正确。

串口参数如下：波特率为9600，数据位为8，奇偶校验为无，停止位为1，流量控制为无，选择终端仿真为VT100。不同设备配置的串口参数请以设备实际情况为准。

(5) 更换配置电缆。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

3.1.2 设备异常重启

1. 故障描述

设备在运行中发生异常重启。

2. 常见原因

本类故障的常见原因启动文件故障。

3. 故障分析

本类故障的诊断流程如图2所示：

图2 设备异常重启故障诊断流程图

4. 处理步骤

(1) 查看设备重启后能否进入命令行状态

若设备能够进入命令行状态，请使用display diagnostic-information命令收集设备的诊断信息，待收集完成后，将设备信息导出后发给H3C技术人员寻求支持。

执行display diagnostic-information命令时，可指定key-info参数仅收集关键诊断信息，从而减少收集时间。

(2) 检查启动文件是否正常

若设备无法进入命令行状态，请通过Console口连接设备后再次重启设备，如果BootWare提示CRC错误或者找不到启动文件，请使用BootWare菜单重新下载启动文件，并设置该文件为当前启动文件（在BootWare加载过程中，BootWare能自动将该文件设置为当前启动文件）。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

3.1.3 温度异常告警

1. 故障描述

系统出现温度告警，打印温度过高等告警信息，例如：

%Jun 26 10:13:46:233 2013 H3C DRVPLAT/4/DrvDebug: Temperature of the board is too high!

2. 常见原因

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

· 机房通风不畅或空调制冷故障等造成环境温度过高。

· 设备风扇故障或出入风口被异物堵塞。

· 设备防尘网积灰过多。

· 温度告警门限设置过低。

· 软件获取温度数据失败，错误告警。

3. 故障分析

本类故障的诊断流程如图3所示：

图3 温度异常故障诊断流程图

4. 处理步骤

(1) 检查环境温度是否过高

如果温度过高，请增加空调或者采取其他散热措施降低环境温度。

(2) 检查设备温度是否过高

执行display environment命令查看设备当前温度值。若显示为255，则表示软件获取温度数据失败。可多次执行display environment命令至温度数据正常显示后，判断设备温度是否过高。

若是设备温度过高（设备温度超过一般级高温告警门限），确认设备风扇是否正常并检查出入风口是否被异物堵塞。

使用display fan命令查看风扇框是否运行正常。若不正常，请参见风扇模块故障章节排除风扇故障。

(3) 检查防尘网是否洁净

如果风扇正常，则检查防尘网是否洁净。清理防尘网后，看温度是否能恢复正常。

(4) 重新设置温度告警门限

使用temperature-limit命令重新设置温度告警门限值。通过display environment命令可以查看温度告警门限是否设置成功。请注意，本步骤需要在研发人员的指导下进行操作，避免告警门限值设置的不合理。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

3.1.4 内存异常告警

1. 故障描述

系统打印内存异常告警信息，例如：

DIAG/1/MEM_EXCEED_THRESHOLD: Memory minor threshold has been exceeded.

2. 常见原因

· 设备正在执行一些文件类操作。

· 设备出现内存泄露。

3. 故障分析

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

图4 内存占用率高故障诊断流程图

4. 处理步骤

(1) 确定各内存块使用情况

通过Probe视图下的display system internal kernel memory pool命令查看各块内存使用情况，找出使用率不正常和不断增加的内存模块。

<Sysname> system-view

[Sysname] probe

[Sysname-probe] display system internal kernel memory pool slot 1

Active Number Size Align Slab Pg/Slab ASlabs NSlabs Name

9126 9248 64 8 32 1 289 289 kmalloc-64

105 112 16328 0 2 8 54 56 kmalloc-16328

14 14 2097096 0 1 512 14 14 kmalloc-2097096

147 225 2048 8 15 8 12 15 kmalloc-2048

7108 7232 192 8 32 2 226 226 kmalloc-192

22 22 524232 0 1 128 22 22 kmalloc-524232

1288 1344 128 8 21 1 64 64 kmalloc-128

0 0 67108808 0 1 16384 0 0 kmalloc-67108808

630 651 4096 8 7 8 93 93 kmalloc-4096

68 70 131016 0 1 32 68 70 kmalloc-131016

1718 2048 8 8 64 1 31 32 kmalloc-8

1 1 16777160 0 1 4096 1 1 kmalloc-16777160

2 15 2048 0 15 8 1 1 sgpool-64

0 0 40 0 42 1 0 0 inotify_event_cache

325 330 16328 8 2 8 165 165 kmalloc_dma-16328

0 0 72 0 30 1 0 0 LFIB_IlmEntryCache

0 0 1080 0 28 8 0 0 LFIB_IlmEntryCache

0 0 1464 0 21 8 0 0 MFW_FsCache

1 20 136 0 20 1 1 1 L2VFIB_Ac_cache

0 0 240 0 25 2 0 0 CCF_JOBDESC

0 0 88 0 26 1 0 0 NS4_Aggre_TosSrcPre

0 0 128 0 21 1 0 0 IPFS_CacheHash_cachep

---- More ----

请重点查看Number列和Size列的统计结果。如果发现某块内存在不停增加，那么表示该块内存在被不断使用。需要注意的是：

¡ 有些内存块使用率的增加是正常的，例如设备正在上传大文件或配置启动文件，也可能造成内存告警，此时可观察内存能否快速恢复。

¡ Number*Size是某个模块使用的内存大小。判断内存使用率是否正常可能需要持续观察内存增长速度和内存使用的多少，进行综合分析判断。

¡ 有些内存的泄漏过程比较缓慢，所以需要比较长的时间（甚至是几周的时间）来对比观察。

(2) 收集信息并寻求技术支持

通过上述步骤只是确定了问题的范围，但还需继续收集信息以确定具体的故障。由于后续信息收集要求较高，不建议用户操作，请与H3C的技术支持工程师联系。

需要注意的是，请不要重启设备，否则会将故障信息破坏，给故障定位带来困难。

5. 告警与日志

3.1.5 CPU占用率高

1. 故障描述

连续使用命令display cpu-usage查看CPU的占用率。如果CPU占用率持续在70％以上，说明有某个任务长时间占用CPU，需要确认CPU高的具体原因。

<Sysname> display cpu-usage

Slot 1 CPU 0 CPU usage:

70% in last 5 seconds

70% in last 1 minute

70% in last 5 minutes

2. 常见原因

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

· 路由振荡

· 报文攻击

· 链路环路

3. 故障分析

本类故障的诊断流程如图5所示：

图5 CPU占用率高故障诊断流程图

4. 处理步骤

(1) 检查是否发生路由振荡

路由表中条目频繁变化，可能导致CPU占用率过高。当发生路由震荡时，请收集信息并联系H3C技术人员寻求技术支持。

首次查看路由表：

[Sysname] display ip routing-table

Destinations : 9 Routes : 9

Destination/Mask Proto Pre Cost NextHop Interface

0.0.0.0/32 Direct 0 0 127.0.0.1 InLoop0

10.1.1.0/24 OSPF 150 1 11.2.1.1 Vlan100

127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0

127.0.0.0/32 Direct 0 0 127.0.0.1 InLoop0

127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0

127.255.255.255/32 Direct 0 0 127.0.0.1 InLoop0

224.0.0.0/4 Direct 0 0 0.0.0.0 NULL0

224.0.0.0/24 Direct 0 0 0.0.0.0 NULL0

255.255.255.255/32 Direct 0 0 127.0.0.1 InLoop0

再次查看路由表：

[Sysname] display ip routing-table

Destinations : 8 Routes : 8

Destination/Mask Proto Pre Cost NextHop Interface

0.0.0.0/32 Direct 0 0 127.0.0.1 InLoop0

127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0

127.0.0.0/32 Direct 0 0 127.0.0.1 InLoop0

127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0

127.255.255.255/32 Direct 0 0 127.0.0.1 InLoop0

224.0.0.0/4 Direct 0 0 0.0.0.0 NULL0

224.0.0.0/24 Direct 0 0 0.0.0.0 NULL0

255.255.255.255/32 Direct 0 0 127.0.0.1 InLoop0

(2) 检查是否受到报文攻击

部分机型Probe视图下支持debug rxtx softcar show命令，可以查看软件收包是否堵塞丢包。

<Sysname> system-view

[Sysname] probe

[Sysname-probe] debug rxtx softcar show slot 1

ID Type RcvPps Rcv_All DisPkt_All Pps Dyn Swi Hash ACLmax

0 ROOT 0 0 0 300 S On SMAC 0

1 ISIS 0 0 0 200 D On SMAC 8

2 ESIS 0 0 0 100 S On SMAC 8

3 CLNP 0 0 0 100 S On SMAC 8

4 VRRP 0 0 0 1024 S On SMAC 8

5 UNKNOWN_IPV4MC 0 0 0 100 S On SMAC 8

6 UNKNOWN_IPV6MC 0 0 0 100 S On SMAC 8

7 IPV4_MC_RIP 0 0 0 150 D On SMAC 8

8 IPV4_BC_RIP 0 0 0 150 D On SMAC 8

9 MCAST_NTP 0 0 0 100 S On SMAC 8

10 BCAST_NTP 0 0 0 100 S On SMAC 8

如果某类报文的统计计数在不断增长，说明有攻击存在，可通过抓包确认攻击源。在设备端口抓包，使用报文捕获工具（如Sniffer、Wireshark、WinNetCap等）分析报文特征，确认攻击源。然后针对攻击源配置报文防攻击。关于报文防攻击的详细介绍和配置，请参见“安全配置指导”中的“攻击检测与防范”。

(3) 检查是否存在链路环路

链路存在环路时，可能出现广播风暴和网络振荡，大量的协议报文上送CPU处理可能导致CPU占用率升高，设备很多端口的流量会变得很大，端口使用率达到90%以上：

<Sysname> display interface gigabitethernet3/0/1

GigabitEthernet3/0/1

Current state: UP

Line protocol state: UP

Description: GigabitEthernet3/0/1 Interface

Bandwidth: 1000000 kbps

Maximum transmission unit: 1500

Internet address: 2.1.1.2/24 (primary)

IP packet frame type: Ethernet II, hardware address: 0000-fc00-9276

IPv6 packet frame type: Ethernet II, hardware address: 0000-fc00-9276

Loopback is not set

Media type is twisted pair, port hardware type is 1000_BASE_T

Port priority: 0

1000Mbps-speed mode, full-duplex mode

Link speed type is autonegotiation, link duplex type is autonegotiation

Flow-control is not enabled

Maximum frame length: 9216

Last clearing of counters: Never

Peak input rate: 8 bytes/sec, at 2016-03-19 09:20:48

Peak output rate: 1 bytes/sec, at 2016-03-19 09:16:16

Last 300 second input: 26560 packets/sec 123241940 bytes/sec 99%

Last 300 second output: 0 packets/sec 0 bytes/sec 0%

……

如链路出现环路：

¡ 排查链路连接、端口配置是否正确。

¡ 对于二层口，是否使能STP协议，配置是否正确。

¡ 对于二层口，邻接设备STP状态是否正常。

¡ 如以上配置均正确，可能为STP协议计算错误或协议计算正确但端口驱动层没有正常Block阻塞，可以shutdown环路上端口、拔插端口让STP重新计算来快速恢复业务。

(4) 确定CPU占用率高的任务

如果通过上述步骤无法解决故障，请通过display process cpu命令观察占用CPU最多的任务。

<Sysname> display process cpu slot 1

CPU utilization in 5 secs: 2.4%; 1 min: 2.5%; 5 mins: 2.4%

JID 5Sec 1Min 5Min Name

1 0.0% 0.0% 0.0% scmd

2 0.0% 0.0% 0.0% [kthreadd]

3 0.0% 0.0% 0.0% [migration/0]

4 0.0% 0.0% 0.0% [ksoftirqd/0]

5 0.0% 0.0% 0.0% [watchdog/0]

6 0.0% 0.0% 0.0% [migration/1]

7 0.0% 0.0% 0.0% [ksoftirqd/1]

8 0.0% 0.0% 0.0% [watchdog/1]

9 0.0% 0.0% 0.0% [migration/2]

10 0.0% 0.0% 0.0% [ksoftirqd/2]

11 0.0% 0.0% 0.0% [watchdog/2]

……

各列分别表示某任务平均5sec、1min、5min占用CPU的百分比和任务名。某任务占用率越高，说明相应的任务占用CPU的资源越多。正常情况任务对CPU的占用率一般低于5%，这个命令可以查看明显高出正常占用率的任务。

(5) 确认异常任务的调用栈

通过Probe视图下的follow job job-id命令确认异常任务的调用栈，请查询5次以上，发送给技术支持人员分析，以便于分析该任务具体在做什么处理导致CPU占用率持续升高。此处以显示JID 145的调用栈为例。

<Sysname> system-view

[Sysname] probe

[Sysname-probe] follow job 145 slot 1

Attaching to process 145 ([dGDB])

Iteration 1 of 5

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

Kernel stack:

[<ffffffff80355290>] schedule+0x570/0xde0

[<ffffffff80355da8>] schedule_timeout+0x98/0xe0

[<ffffffff802047e4>] ep_poll+0x4b4/0x5e0

[<ffffffffc05587a8>] DRV_Sal_EVENT_Read+0x1f8/0x290 [system]

[<ffffffffc07351e4>] drv_sysm_gdb_console+0xc4/0x2d0 [system]

[<ffffffffc1a04114>] thread_boot+0x84/0xa0 [system]

[<ffffffff8015c420>] kthread+0x130/0x140

[<ffffffff801183d0>] kernel_thread_helper+0x10/0x20

Iteration 2 of 5

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

Kernel stack:

[<ffffffff80355290>] schedule+0x570/0xde0

[<ffffffff80355da8>] schedule_timeout+0x98/0xe0

[<ffffffff802047e4>] ep_poll+0x4b4/0x5e0

[<ffffffffc05587a8>] DRV_Sal_EVENT_Read+0x1f8/0x290 [system]

[<ffffffffc07351e4>] drv_sysm_gdb_console+0xc4/0x2d0 [system]

[<ffffffffc1a04114>] thread_boot+0x84/0xa0 [system]

[<ffffffff8015c420>] kthread+0x130/0x140

[<ffffffff801183d0>] kernel_thread_helper+0x10/0x20

Iteration 3 of 5

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

Kernel stack:

[<ffffffff80355290>] schedule+0x570/0xde0

[<ffffffff80355da8>] schedule_timeout+0x98/0xe0

[<ffffffff802047e4>] ep_poll+0x4b4/0x5e0

[<ffffffffc05587a8>] DRV_Sal_EVENT_Read+0x1f8/0x290 [system]

[<ffffffffc07351e4>] drv_sysm_gdb_console+0xc4/0x2d0 [system]

[<ffffffffc1a04114>] thread_boot+0x84/0xa0 [system]

[<ffffffff8015c420>] kthread+0x130/0x140

[<ffffffff801183d0>] kernel_thread_helper+0x10/0x20

Iteration 4 of 5

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

Kernel stack:

[<ffffffff80355290>] schedule+0x570/0xde0

[<ffffffff80355da8>] schedule_timeout+0x98/0xe0

[<ffffffff802047e4>] ep_poll+0x4b4/0x5e0

[<ffffffffc05587a8>] DRV_Sal_EVENT_Read+0x1f8/0x290 [system]

[<ffffffffc07351e4>] drv_sysm_gdb_console+0xc4/0x2d0 [system]

[<ffffffffc1a04114>] thread_boot+0x84/0xa0 [system]

[<ffffffff8015c420>] kthread+0x130/0x140

[<ffffffff801183d0>] kernel_thread_helper+0x10/0x20

Iteration 5 of 5

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

Kernel stack:

[<ffffffff80355290>] schedule+0x570/0xde0

[<ffffffff80355da8>] schedule_timeout+0x98/0xe0

[<ffffffff802047e4>] ep_poll+0x4b4/0x5e0

[<ffffffffc05587a8>] DRV_Sal_EVENT_Read+0x1f8/0x290 [system]

[<ffffffffc07351e4>] drv_sysm_gdb_console+0xc4/0x2d0 [system]

[<ffffffffc1a04114>] thread_boot+0x84/0xa0 [system]

[<ffffffff8015c420>] kthread+0x130/0x140

[<ffffffff801183d0>] kernel_thread_helper+0x10/0x20

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

3.1.6 USB状态异常

2. 常见原因

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

· USB设备故障。

· USB口无法识别插入的USB设备。

3. 故障分析

本类故障的诊断流程如图6所示：

图6 USB状态异常故障诊断流程图

4. 处理步骤

(1) 查看设备USB的信息，检查USB状态是否正常

<Sysname> display device usb

slot 1:

Device Name : usba

State : Absent

如果USB状态显示为Absent，则表示设备的USB口未识别插入的USB设备。

(2) 尝试更换其他USB设备插入设备USB口

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

3.2 电源类故障

3.2.1 电源模块状态异常

1. 故障描述

电源模块状态指示灯异常或者电源运行中上报Fault。

2. 常见原因

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

· 电源模块型号和主机不匹配。

· 电源模块安装不到位。

· 电源线缆没有插牢。

· 电源模块温度过高。

· 电源模块故障。

3. 故障分析

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

图7 故障诊断流程图

4. 处理步骤

(1) 检查电源模块的型号是否和主机型号匹配。

(2) 检查设备连接的供电系统：确认供电系统正常供电，电压正常。

(3) 通过电源模块上的指示灯初步判断电源模块是否存在输出短路、输出过流、输出过压、输入欠压、温度过高等问题。不同主机电源指示灯状态有所差异，具体请参见相应主机的硬件手册。

(4) 检查电源模块状态。

使用display power命令显示电源模块状态，查看是否存在Fault、Error或Absent状态的电源模块。

<Sysname> display power

Slot 1:

PowerID State Mode Current(A) Voltage(V) Power(W)

1 Normal DC -- -- 0

2 Fault AC -- -- 0

(5) 如果电源模块状态为Absent，请按如下子步骤进行定位处理。

a. 请将该电源模块拆卸后重新安装，重新安装前请检查电源连接器是否完好。

b. 重新安装后，该电源模块的状态未恢复为Normal，则请将该电源模块与正常的电源模块更换槽位再做一次交叉验证。

c. 如果该电源模块仍然显示为Absent，则请更换新的电源模块。

d. 更换新的电源模块后，此故障仍然存在，请执行步骤7。

(6) 如果电源模块状态为Fault或Error，请按如下子步骤进行定位处理。

a. 检查电源线是否脱落或者是否正确连接。

b. 如果电源线连接正常，交叉验证下电源线是否故障。

c. 如果电源线正常，可能是电源模块本身温度过高导致。请查看电源模块积灰情况，如果灰尘较多，请清理灰尘，并将电源模块拆卸后重新安装。

d. 重新安装后，电源模块状态未恢复为Normal，请将该电源模块与正常的电源模块更换槽位做一次交叉验证。

e. 如果该电源模块仍然显示为Fault状态，请更换电源模块。

f. 更换新电源模块后，此故障仍然存在，请执行步骤7。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

3.3 风扇类故障

3.3.1 风扇模块状态异常

2. 常见原因

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

· 风扇未插紧。

· 机箱出风口、入风口被异物堵塞。

· 风扇硬件故障。

· 风扇的实际风道方向与设备期望的风道方向不一致（仅部分机型涉及）。

3. 故障分析

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

图8 故障诊断流程图

4. 处理步骤

(1) 查看风扇模块指示灯状态是否正常，不同主机风扇指示灯状态有所差异，具体请参见相应主机的硬件手册。如果所有指示灯都为灭，请确认电源模块是否正常工作，或整机开关接线是否开路，具体请参见3.2.1 电源模块状态异常。

(2) 查看风扇框状态。

使用display fan命令查看风扇框状态（不同产品的显示信息不同，请以产品的实际情况为准）。

<Sysname> display fan

Slot 1:

Fan 1:

State : Normal

Airflow Direction: Port-to-power

Prefer Airflow Direction: Port-to-power

(3) 检查风扇框是否安装牢固。

对于部分机型，如果风扇框工作状态显示为FanDirectionFault，表示设备期望的风道方向与风扇框的实际风道方向不一致，此时可通过fan prefer-direction命令配置期望的风道方向，使其和风扇框的实际风道方向一致，或者可以更换相同风道方向的风扇框。

如果风扇框工作状态显示为Absent，表示风扇框不在位或者没有安装牢固。如果风扇框在位，请将该风扇框拆卸后重新安装，重新安装前请检查风扇连接器是否完好，然后查看风扇框状态是否显示为Normal状态。如果仍然显示为Absent状态，请更换风扇框。如果更换新风扇框后仍然显示为Absent状态，请执行步骤5。

(4) 检查设备的工作环境信息。

如果风扇框工作状态显示为Fault，表示该风扇框异常，无法提供抽风散热功能。请使用下述步骤进一步定位。

a. 使用display environment命令查看系统温度是否持续升高。如果系统温度持续升高，建议用手在设备出风口触摸进一步判断出风口是否有出风。如果温度持续升高，且出风口无风，表示风扇框异常。

b. 检查机箱出风口、入风口是否被异物堵塞。如果有异物，请将其清理。

c. 查看各个风扇的转速是否正常。使用Probe视图下的debug sysm fan fan-id get-speed命令查看风扇转速（不同设备对此命令的支持情况存在差异，请以设备实际情况为准）。如果speed字段信息显示风扇转速小于500/rpm，表示风扇异常。

d. 如果确定风扇异常，请将风扇框拆卸后重新安装，重新安装前请检查风扇连接器是否完好，然后使用display fan命令查看是否恢复为Normal状态。

e. 如果仍然不能恢复为Normal状态，请更换该风扇框。如果现场没有风扇框，不能立即更换，请关闭设备以免温度过高导致电路烧坏；如果有降温措施保证系统工作在50摄氏度以下，也可以继续使用设备。

f. 如果更换新的风扇框仍然不能恢复为Normal状态，请执行步骤5。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

3.4 接口模块扩展卡故障

3.4.1 接口模块扩展卡状态异常

2. 常见原因

· 设备不支持该类型的扩展卡

· 扩展卡没有安装牢固

· 设备的扩展卡接口故障

3. 故障分析

本类故障的诊断流程如图9所示：

图9 接口模块扩展卡状态异常故障诊断流程图

4. 故障处理步骤

(1) 检查设备是否支持该扩展卡

查看设备配套的安装指导或硬件描述手册，查看设备所支持的扩展卡型号。若不支持，请更换支持的扩展卡型号。

(2) 检查扩展卡是否安装牢固

若未安装牢固，请拆卸扩展卡后重新安装牢固，并查看设备是否能够获取扩展卡信息。若能够获取，表示扩展状态正常。

<sysname> display device manuinfo slot 1

Subslot 1:

DEVICE_NAME : LSWM2SP2PB

DEVICE_SERIAL_NUMBER : 210231A9UFM186A0000R

MANUFACTURING_DATE : 2018-06-19

VENDOR_NAME : H3C

…(略)

(3) 检查设备扩展卡接口是否故障

若设备存在多个扩展卡接口，将该扩展卡插入的其他接口上并查看扩展卡状态是否正常，

若正常，表示扩展卡接口故障，请联系H3C技术支持。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

3.5 单板故障

3.5.1 单板状态异常故障

1. 故障描述

· 单板状态异常（比如执行display device命令查看单板状态为Absent、Fault等）。

· 单板出现异常重启、无法启动或不断重启等。

2. 常见原因

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

· 单板安装不到位。

· 单板损坏。

· 单板面板的指示灯点亮异常。

· 电源模块故障。

· 电源模块输出功率不足。

· 主机软件版本不支持使用该单板。

· 主控板非正常工作状态。

· 业务板、备用主控板或网板与主用主控板的设备标识不一致。

· 业务板启动前网板不在位或网板状态异常。

3. 故障分析

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

图10 单板状态异常故障诊断流程图

4. 处理步骤

· 单板状态Absent

(1) 确认单板是否插稳，如检查单板与机框之间是否有空隙，也可以将单板拔出后重插入。重新插入前务必检查单板的连接器状态，看连接器是否变形、脏污。

(2) 将单板放到别的槽位，将框上别的正常的单板放到这个槽位，进一步确认是不是单板故障。

(3) 检查单板面板的指示灯是否点亮。

(4) 确认电源模块输出功率是否充足。比如增加电源模块，看该单板状态是否恢复正常。

(5) 确认主机软件版本是否支持该单板。

a. 通过display version命令查看主机软件版本；

b. 联系技术支持，确认当前主机软件版本是否支持该单板；

c. 如果当前软件版本不支持该单板，请升级到正确版本，版本升级前务必确认新版本可以兼容其它单板。

(6) 如果单板是主控板，连上Console口配置电缆后，使用尖细工具（如笔尖）按单板上的系统复位键（RESET）或通过reboot slot slotid force命令重启单板，查看配置终端上的显示的启动信息是否恢复正常（配置终端无显示或显示乱码均为异常情况），同时查看单板状态指示灯是否恢复正常。正常情况下，配置终端启动后会有类似如下显示信息输出：

此处仅为举例，实际输出的信息会随软件版本的不同而略有差别。

System is Starting....

Press Ctrl+D to access BASIC-BOOTWARE MENU

Press Ctrl+T to access BOOTWARE DIAG-TEST MENU

Booting Normal Extend BootWare

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

* *

* BootWare, Version 1.35 *

* *

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

Compiled Date : Dec 9 2021

Memory Type : DDR4 SDRAM

Memory Size : 16384MB

Memory Speed : 2133MHz

flash Size : 7296MB

CPLD 1 Version : 4.0

CPLD 2 Version : 1.0

CPLD 3 Version : 1.0

PCB 1 Version : Ver.A

PCB 2 Version : Ver.A

BootWare Validating...

Press Ctrl+B to access EXTENDED-BOOTWARE MENU...

Loading the main image files...

Loading file flash:/SYSTEM.bin..............................................

............................................................................

....................................Done.

Loading file flash:/BOOT.bin................................................

............................................................................

................Done.

Image file flash:/BOOT.bin is self-decompressing............................

............................................................................

.............................................Done.

System image is starting...

Cryptographic algorithms tests passed.

Line aux0 is available.

Press ENTER to get started.

(7) 如果单板是带有Console口的交换网板，连上Console口配置电缆后，通过执行reboot slot slotid force命令或拔出该单板重新插入设备来重启单板，查看配置终端上的显示信息是否恢复正常，同时查看单板状态指示灯是否恢复正常。

(8) 如果单板是业务板，请先确保主控板处于正常工作状态，确保子卡连接器没有变形、脏污。

(9) 如确认为单板故障，请更换单板，收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

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

· 单板状态Power-off。

(10) 确认设备环境是否存在过温下电，部分产品支持通过display power-supply命令查看是否存在环境温度过高，单板被下电的记录。比如单板的供电状态“Status”为“off”表示单板由于用户操作或过温保护等原因被主动下电。

如果确认是过温下电，请排查环境单板槽位是否插满，如果单板槽位已插满单板或者挡风板，请通过命令display fan确认风扇工作是否正常，风扇状态为Normal表示风扇正常工作，如不正常，或确认单板存在电源故障，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

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

· 单板状态Fault。

(11) 检查整机功耗，整机功耗不够时，单板会进入fault状态。

(12) 等待一段时间（大约10分钟左右）确认下单板是一直Fault还是Normal后又再次重启。如单板是Normal后又自动重启，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

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

(13) 如果单板是主控板、带串口网板，请连上串口线，查看配置终端上是否有单板正常启动的显示信息、或单板启动是否异常。如下述主控板启动时出现内存读写测试失败而不断重启，需要检查主控板内存条是否插稳。

readed value is 55555555 , expected value is aaaaaaaa

DRAM test fails at: 080ffff8

Fatal error! Please reboot the board.

(14) 将单板放到别的槽位，进一步确认是不是槽位故障。

(15) 如确认为单板故障，请更换单板，收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

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

· 单板重启异常

这里的单板重启是指单板出现过重启，而当前单板状态是Normal。

(16) 通过日志或运行时间分析重启的时间段，确认重启的时间点附近有无用户通过命令行reboot重启或进行单板上下电等操作。

(17) display version命令支持查询单板最近一次重启的原因。比如“Last reboot reason”表示单板最近一次重启原因是设备上电。

<Sysname> display version

H3C Comware Software, Version 7.1.075, Release 7751P01

H3C S12508X-AF uptime is 0 weeks, 0 days, 4 hours, 24 minutes

Last reboot reason : Cold reboot……

(18) 如果所有单板同时出现重启，请检查设备电源模块是否正常，确认外部电源是否出现过停电，电源进线是否插稳、是否出现松动。

(19) 确认日志中重启时有无出现类似“Warning: Standby board on slot 1 is not compatible with master board.”或“Warning: The LPU board on slot 1 is not compatible with MPU board.”提示信息，这种情况是业务板、备用主控板或网板与主用主控板的设备标识不一致，请联系技术支持人员更换。

(20) 如无法确认，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

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

5. 告警与日志

3.5.2 主控板无法启动

1. 故障描述

原有主控板或新加入设备的备用主控板无法启动。

2. 常见原因

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

· 主控板卡硬件故障导致无法上电。

· 主控板卡BootWare基本段损坏。

· 内存或CPU硬件故障导致BootWare无法运行。

· 启动文件丢失、校验失败、与硬件不匹配。

· 备用主控板和原主控板的型号不一致。

· 备用主控板和原主控板的软件版本不一致。

3. 故障分析

原主控板无法启动故障的诊断流程如图11所示。

图11 原主控板无法启动故障诊断流程图

新加入设备的备用主控板无法启动故障的诊断流程如图12所示。

图12 新加入设备的备用主控板无法启动故障诊断流程图

4. 处理步骤

· 原主控板无法启动故障的处理步骤如下：

(1) 查看主控板运行灯（RUN灯）是否点亮

BootWare基本段启动后，会立刻将运行灯置成快闪，所以这是判断系统能否启动的重要标志。

表2 主控板运行灯状态及含义

	主控板运行灯状态	指示灯含义
RUN	绿色常灭	表示单板故障或单板不在位
	绿色4Hz闪烁	表示软件加载下载过程中
	绿色0.5Hz闪烁	表示单板正常工作

分以下几种情况处理：

a. 情况1：运行灯快闪

如果设备上电后运行灯以4Hz频率快闪，说明基本段启动正常，则进行步骤2。

b. 情况2：运行灯不亮

若运行灯没有点亮，有两个可能：设备不能上电；BootWare基本段被破坏。

先判断设备是否上电。从主控入风口正面观察，主控板内部是否有绿色闪灯或者常亮灯，也可以经过一段时间后，拔出主控板，检验CPU上的散热片是否有热度。如果没有上电，则检查供电、电源模块，设备硬件故障也可能导致主板不能上电。

如果设备上电正常，则应该是BootWare基本段被破坏，需要返回研发处理。

· 这里所说的运行灯不亮，是指上电后从来没亮过，如果开始闪了一会儿（超过5秒）后续又灭的，则不算此情况。

· 一上电运行灯就常亮或慢闪（1Hz频率）是基本不可能的，若出现则为硬件故障。

· 此处指示灯状态仅表示大多数主控板的情况，具体各主控板的指示灯状态请参见其安装手册。

(2) 检查Bootware是否运行成功

a. 情况1：基本段运行成功

查看是否有如下信息，是则说明基本段运行成功，进入步骤3。

System is starting...

Booting Normal Extended BootWare

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

* *

* H3C S9850 BOOTROM, Version 061 *

* *

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

Compiled Date : Sep 17 2018 14:37:13

CPU Type : C2538

CPU Clock Speed : 1200MHz

Memory Type : DDR3 SDRAM

Memory Size : 16384MB

Memory Speed : 1333MHz

Flash Size : 8MB

CPLD Version : 1.0

PCB Version : Ver.B

BootWare Validating...

b. 情况2：没有任何输出信息

如果上电后打印类似下面信息，则可能是内存条有问题，可检查是否有插紧，或尝试更换内存条。也有可能是内存通道的硬件电路出现问题，请联系H3C技术支持。

readed value is 75555555 , expected value is 55555555

DRAM test fails at: 5ff80020

Fatal error! Please reboot the board.

以上信息是内存自检失败打印的。有时候系统因为异常发生热启动，内存控制器状态还未恢复，会出现自检失败的情况（极小概率），此时一般断电，再开电后就能恢复，和内存损坏的情况有区别。

(3) 查看加载启动文件是否正常

a. 情况1：启动文件加载、解压成功

显示如下信息，说明启动文件加载、解压成功，进行步骤4。

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

* *

* H3C S9850 BOOTROM, Version 061 *

* *

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

Compiled Date : Sep 17 2018 14:37:13

CPU Type : C2538

CPU Clock Speed : 2400MHz

Memory Type : DDR3 SDRAM

Memory Size : 8192MB

Memory Speed : 1333MHz

Flash Size : 3630MB

CPLD Version : 8.0

PCB Version : Ver.0

BootWare Validating...

Press Ctrl+B to access EXTENDED-BOOTWARE MENU...

Loading the main image files...

Loading file flash:/S12500R-CMW910-SYSTEM-D5202P14.bin......................

............................................................................

...................................Done.

Loading file flash:/S12500R-CMW910-BOOT-D5202P14.bin........................

............................................................................

........Done.

Image file flash:/S12500R-CMW910-BOOT-D5202P14.bin is self-decompressing....

............................................................................

.......................................................................

Done.

System image is starting...

Cryptographic algorithms tests passed.

b. 情况2：启动文件不存在

显示如下信息，表示启动文件不存在，需要重新下载启动文件。

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

* *

* H3C S9850 BOOTROM, Version 061 *

* *

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

Compiled Date : Sep 17 2018 14:37:13

CPU Type : C2538

CPU Clock Speed : 2400MHz

Memory Type : DDR3 SDRAM

Memory Size : 8192MB

Memory Speed : 1333MHz

Flash Size : 3630MB

CPLD Version : 8.0

PCB Version : Ver.0

BootWare Validating...

Application program does not exist.

Please input BootWare password:

c. 情况3：启动文件CRC错误

若显示如下信息，表示获取的启动文件发生校验错，请重新下载文件到flash。

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

* *

* H3C S9850 BOOTROM, Version 061 *

* *

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

Compiled Date : Sep 17 2018 14:37:13

CPU Type : C2538

CPU Clock Speed : 2400MHz

Memory Type : DDR3 SDRAM

Memory Size : 8192MB

Memory Speed : 1333MHz

Flash Size : 3630MB

CPLD Version : 8.0

PCB Version : Ver.0

BootWare Validating...

Press Ctrl+B to access EXTENDED-BOOTWARE MENU...

Loading the main image files...

Loading file flash:/S12500R-CMW910-SYSTEM-D5202P14.bin......................

............................................................................

Something wrong with the file.

(4) 检查启动文件启动过程

a. 情况1：没有System包，系统启动之后进入boot界面

Loading the main image files...

Loading file flash:/S12500R-CMW910-SYSTEM-D5202P14.bin......................

...................................Done.

<boot>

这种情况，需要重新下载软件版本

b. 情况2：System image is starting...，一直挂死

c. 情况3：System image is starting...，未进入命令行，反复重启

d. 情况4：提示Press ENTER to get started，但是无法进入命令行

e. 情况5：可以进入命令行，但是一段时间之后自动重启

对于b.c.d.e.情况，可能是硬件故障或者软件版本存在问题，请联系H3C技术服务支持。

· 新加入设备的备用主控板无法启动故障按如下步骤处理：

(5) 检查新加入主控板是否和原主控板型号一致

同一台设备中的两块主控板型号要求一致。检查两块主控板型号是否一致，如果不一致，更换一块型号一致的主控板插入。

(6) 收集诊断信息

检查主用主控板运行状态，收集诊断信息，寻求技术支持。

(7) 寻求技术支持

如果上述检查完成后故障仍无法排除，请联系H3C的技术支持工程师。

5. 告警与日志

3.5.3 主控板在使用中发生重启，无法正常启动

1. 故障描述

主控板在使用中发生重启，无法正常启动。

2. 常见原因

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

· 启动文件损坏。

· 主控板内存单元损坏。

· 单板未完全插入或损坏导致BootWare运行异常。

3. 故障分析

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

图13 故障诊断流程图

4. 处理步骤

(1) 检查主控板上的启动文件是否正常

通过Console口登录故障主控板，重新启动设备，如果BootWare提示CRC错误或者找不到启动文件，请重新加载启动文件，并确认Flash中文件大小与服务器上的文件是否一致，如不存在或不一致需重新加载启动文件。加载后请设置该文件为当前启动文件（在BootWare加载过程中，BootWare能自动将该文件设置为当前启动文件）。

(2) 测试主控板内存单元是否正常

如果确认加载的文件大小正确，且设置为当前启动文件也正常。请重新启动单板，同时立即按住CTRL+T，对内存单元进行检测。如果提示内存错误，请更换单板。

(3) 查看Bootware是否依旧提示错误

如果内存检查也正常，但BootWare启动过程中还有错误提示，则根据相关提示初步判断发生故障的器件。检查单板是否插牢。如已插牢则更换单板。

(4) 寻求技术支持

如果上述检查完成后故障仍无法排除，请联系H3C的技术支持工程师。

5. 告警与日志

3.5.4 主备倒换故障

1. 故障描述

本类故障常见如下三种情况：

· 用reboot命令重启主用主控板时，备用主控板也重启。

· 主、备倒换异常。

2. 常见原因

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

· 原备用主控板未启动完成的情况下，因重启主用主控而被动变成主用主控板。

· 备用主控板未收到主用主控板的报文而切换成主用主控板。

· 主用主控板自身异常导致重启。

· 主用主控板和备用主控板版本不一致。

3. 故障分析

用reboot命令重启主用主控板时，备用主控板也重启，此类故障的诊断流程如图14所示。

图14 故障诊断流程图

4. 处理步骤

· 对于用reboot命令重启主用主控板时备用主控板也重启，此类故障的处理步骤如下：

(1) 在原主用主控板启动完成后，使用ftp或tftp命令将存储介质中logfile目录下最新的logfile文件上传到文件服务器。

(2) 查看logfile中reboot命令日志（类似Command is reboot slot 0）到上次启动开始（类似SYSLOG_RESTART: System restarted）这段时间是否出现过类似Batch backup of standby board in slot 1 has finished字符串。

a. 如果没出现过，则表示是在原备用主控板未启动完成的情况下，因重启主用主控而被动变成主用主控板，这种情况下备用主控重启属于正常现象，无需处理。下次重启前注意确保备用主控板批量备份完成（即已经出现过类似Batch backup of standby board in slot 1 has finished日志），再用reboot slot命令重启主用主控板。

b. 如果出现过，请联系H3C技术支持人员。

· 对于主、备倒换异常，此类故障的处理步骤如下：

(3) 通过display system stable state命令收集主用主控、备用主控状态信息：

<H3C> display system stable state

System state : Stable

Redundancy state : Stable

Slot CPU Role State

0 0 Active Stable

1 0 Standby Stable

根据显示信息查看：

a. 双主控的Role是否为Active和Standby。

b. 主用主控、备用主控状态是否Stable。

(4) 通过display boot-loader命令收集主用主控、备用主控版本信息，查看主用主控、备用主控版本是否一致。

5. 告警与日志

3.5.5 业务板无法启动

1. 故障描述

业务板无法启动。

2. 常见原因

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

· 设备当前的工作模式不支持该业务板。

· 网板工作异常。

· 供电异常。

· 软件版本不支持该业务板。

· 业务板未安装到位。

· 业务板硬件故障。

· 机框槽位硬件故障。

3. 故障分析

本类故障的诊断流程如图15所示：

图15 故障诊断流程图

4. 处理步骤

(1) 使用display system-working-mode命令检查设备当前的工作模式，部分交换机处于不同工作模式下时支持的业务板有所不同，例如对于S12500G-AF S系列交换机：

¡ 标准模式所有单板均可启动；

¡ 高级模式下仅SE系列接口板可以启动；

¡ 专家模式下仅SF系列接口板可以启动。

有关启动限制和设备工作模式的详细介绍，请参见各系列交换机配置指导手册中的“设备管理”。

(2) 检查网板工作是否正常。

确保网板在位且状态为Normal，如果状态异常，请先排除网板故障。

(3) 检查业务板是否上电。

查看业务板RUN指示灯状态，如果指示灯不亮，说明业务板可能没有上电，请按如下子步骤进行定位处理。如果上电正常，请执行步骤(4)。

a. 查看电源模块指示灯，判断电源模块工作是否正常，如果指示灯异常，请参考“电源模块状态异常”章节进行定位处理。

b. 计算整机功耗情况，查看电源剩余功率是否足够，如果功率不足，请增加电源模块。

(4) 检查软件版本是否支持该业务板。

在任意视图下执行display version，查询设备的软件版本，然后确认当前软件版本是否支持该业务板。如果不支持，请升级到支持此业务板的正确版本。版本升级前请务必确认新版本兼容其它单板。

(5) 拔插业务板。

拉出业务板，检查连接器是否完好，将其重新插入，保证业务板安装到位。

(6) 将业务板安装到其它槽位测试能否启动。

如果更换到其它槽位也无法启动，则可能是业务板故障，请更换新的业务板进行测试。

如果更换到其它槽位可以正常启动，请将其它可以正常启动的业务板安装到原故障槽位，如果不能启动，则可能是机箱该槽位故障。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

3.5.6 业务板在使用中发生重启，无法正常启动

1. 故障描述

业务板运行过程中发生重启，重启后无法正常启动。

2. 常见原因

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

· 设备切换了工作模式。

· 供电异常。

· 主控板上的启动文件异常。

· 业务板硬件故障。

· 机框槽位硬件故障。

3. 故障分析

本类故障的诊断流程如图16所示：

图16 故障诊断流程图

4. 处理步骤

(1) 使用display system-working-mode命令检查设备当前的工作模式，部分交换机处于不同工作模式下时支持的业务板有所不同，例如对于S12500G-AF S系列交换机：

¡ 标准模式所有单板均可启动；

¡ 高级模式下仅SE系列接口板可以启动；

¡ 专家模式下仅SF系列接口板可以启动。

有关启动限制和设备工作模式的详细介绍，请参见各系列交换机配置指导手册中的“设备管理”。

(2) 检查电源模块工作是否正常。

查看电源模块指示灯是否正常，电源功率是否满足单板正常运行要求。如果有电源模块工作异常，请参考“电源模块故障处理”章节进行定位处理。

(3) 检查主控板上的启动文件是否正常。

在任意视图下执行display boot-loader命令，查看单板使用的下次启动软件包。在用户视图下执行dir命令，查看启动软件包是否存在，如果不存在或者损坏，请重新获取启动软件包或者设置其它软件包作为该单板的下次启动软件包。

<Sysname> display boot-loader

Software images on slot 16:

Current software images:

flash:/S12500-X-CMW710-BOOT-D1031.bin

flash:/S12500-X-CMW710-SYSTEM-D1031.bin

Main startup software images:

flash:/S12500-X-CMW710-BOOT-D1031.bin

flash:/S12500-X-CMW710-SYSTEM-D1031.bin

Backup startup software images:

None

<Sysname> dir

Directory of flash:

0 drw- - Sep 26 2013 16:18:06 core

1 drw- - Jun 30 2013 11:32:34 diagfile

2 -rw- 7122 Dec 23 2013 10:02:46 ifindex.dat

3 drw- - Dec 11 2013 19:00:37 license

4 drw- - Aug 30 2013 11:51:15 logfile

5 -rw- 20529152 Dec 22 2013 14:28:40 S12500-X-cmw710-boot-d1031.bin

6 -rw- 178325504 Dec 22 2013 14:39:02 S12500-X-cmw710-system-d1031.bin

7 drw- - Jun 30 2013 11:32:34 seclog

8 -rw- 17175 Dec 23 2013 10:02:48 startup.cfg

9 -rw- 276535 Dec 23 2013 10:02:48 startup.mdb

10 drw- - Nov 12 2013 11:11:54 versionInfo

503808 KB total (125896 KB free)

(4) 在业务板不能启动的槽位插入能够正常工作的业务板能否正常启动。

如果确认业务板加载的启动文件正常，在条件允许的情况下，在无法正常启动的业务板槽位插入其它能够正常工作的业务板做测试。

如果插入的其它能够正常工作的业务板能启动，则排除主控板和背板故障，请执行步骤(5)。

如果插入的其它能够正常工作的业务板也不能启动，请更换主控板。

(5) 检查是否有加载记录。

在任意视图下执行display logbuffer命令，检查设备的logbuffer中是否有对应槽位单板的加载记录。

<Sysname> display logbuffer

%May 3 13:27:17:086 2013 H3C DEVM/4/BOARD_LOADING: Board is loading file on Chassis 1 Slot 7.

%May 3 13:27:17:647 2013 H3C DEVM/5/LOAD_FINISHED: Board has finished loading file on Chassis 1 Slot 7.

如果logbuffer中有对应槽位单板的加载记录，请将业务板更换到其他槽位看能否正常启动。

如果logbuffer中没有对应槽位单板的加载记录，请执行步骤(6)。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

3.5.7 硬件转发故障

1. 故障描述

设备转发异常或不断打印Forwarding fault、Board fault等提示信息，如：

%Jun 26 09:51:53:207 2013 H3C DIAG/1/ALERT: -MDC=1-Chassis=2-Slot=4; Forwarding fault: chassis 2 slot 6 to chassis 2 slot 4

%Jun 26 09:51:57:621 2013 H3C DIAG/1/ALERT: -MDC=1; Board fault: chassis 2 slot 6,please check it

%Jun 26 09:51:59:251 2013 H3C DIAG/1/ALERT: -MDC=1-Chassis=2-Slot=6; Forwarding fault: chassis 2 slot 6 to chassis 2 slot 6

%Jun 26 09:52:05:621 2013 H3C DIAG/1/ALERT: -MDC=1; Board fault: chassis 2 slot 6,please check it

%Jun 26 09:52:12:621 2013 H3C DIAG/1/ALERT: -MDC=1; Board fault: chassis 2 slot 6,please check it

%Jun 26 09:52:22:621 2013 H3C DIAG/1/ALERT: -MDC=1; Board fault: chassis 2 slot 6,please check it

2. 常见原因

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

· 交换网板故障。

· 业务板故障。

3. 故障分析

本类故障的诊断流程如图17所示：

图17 故障诊断流程图

4. 处理步骤

在系统视图下执行switch-fabric isolate命令逐块隔离交换网板，（确保交换网板数量大于等于2，有冗余备份），观察交换网板隔离后故障是否消失。此处以S12508产品为例说明网板隔离步骤，其中10～18槽位为网板：

(1) 隔离10槽位网板，隔离后等待一段时间，观察故障是否消失。

(2) 执行undo switch-fabric isolate命令取消10槽位网板隔离，待网板重启Normal后，隔离11槽位网板并观察故障是否消失。

(3) 按照上面的方法，依次隔离12～13槽位网板，直到所有网板隔离确认一遍。

(4) 如果隔离某块交换网板后故障消失，说明该交换网板故障；如果所有交换网板隔离一遍后故障仍存在，那么应该为业务板故障导致。

(5) 建议将业务转移到其它业务板上后更换业务板，更换时注意检查槽位是否吸入异物，如果故障依然存在，请执行步骤7。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

3.6 端口故障

3.6.1 端口出现CRC错误

1. 故障描述

通过display interface查看到端口存在CRC错包。

<Sysname> display interface gigabitethernet3/0/1

GigabitEthernet3/0/1

Current state: DOWN

Line protocol state: DOWN

Description: GigabitEthernet3/0/1 Interface

Bandwidth: 1000000 kbps

Maximum transmission unit: 1500

Internet address: 2.1.1.2/24 (primary)

IP packet frame type: Ethernet II, hardware address: 0000-fc00-9276

IPv6 packet frame type: Ethernet II, hardware address: 0000-fc00-9276

Loopback is not set

Media type is twisted pair, port hardware type is 1000_BASE_T

Port priority: 0

1000Mbps-speed mode, full-duplex mode

Link speed type is autonegotiation, link duplex type is autonegotiation

Flow-control is not enabled

Maximum frame length: 9216

Last clearing of counters: Never

Peak input rate: 8 bytes/sec, at 2019-03-19 09:20:48

Peak output rate: 1 bytes/sec, at 2019-03-19 09:16:16

Last 300 second input: 0 packets/sec 0 bytes/sec -%

Last 300 second output: 0 packets/sec 0 bytes/sec -%

Input (total): 2892 packets, 236676 bytes

24 unicasts, 2 broadcasts, 2866 multicasts, 0 pauses

Input (normal): 2892 packets, - bytes

24 unicasts, 2 broadcasts, 2866 multicasts, 0 pauses

Input: 0 input errors, 0 runts, 0 giants, 0 throttles

3 CRC, 0 frame, - overruns, 0 aborts

- ignored, - parity errors

Output (total): 29 packets, 1856 bytes

24 unicasts, 5 broadcasts, 0 multicasts, 0 pauses

Output (normal): 29 packets, - bytes

24 unicasts, 5 broadcasts, 0 multicasts, 0 pauses

Output: 0 output errors, - underruns, - buffer failures

0 aborts, 0 deferred, 0 collisions, 0 late collisions

0 lost carrier, - no carrier

以上显示信息表明，入端口出现了CRC错包。

2. 常见原因

· 端口与电缆连接器物理连接有虚插现象。

· 端口异常。

· 电缆连接器损坏。

· 光模块、光纤有污染或连接不好。

· 光功率不足。

· 中间链路或设备故障。

· 设备或单板硬件故障。

3. 故障分析

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

图18 故障诊断流程图

4. 处理步骤

(1) 端口进行内部环回检查。

在端口下配置loopback internal命令开启内部环回功能，然后通过display interface查看端口CRC错包统计是否增长。如果增长，则可能是设备或单板硬件故障，请联系技术支持人员。如果不增长，则不是端口内部问题。

(2) 检查端口与电缆连接器是否有异常。

a. 检查端口和电缆连接器的物理连接是否有虚插。若有虚插，请正确连接端口和电缆连接器。

b. 检查端口是否异常，比如端口内存在异物，端口的PIN针有弯针，端口的外壳变形等异常。若有异常，需要更换其他正常端口或光模块。

c. 检查电缆连接器是否出现损坏现象。若有损坏现象，请更换电缆。

(3) 检查光模块是否有异常。

a. 使用光纤将该端口的光模块Tx端和Rx端连接，然后通过display interface查看端口CRC错包统计是否增长。如果增长，则可能是光模块的问题。如果不增长，则不是该光模块问题。

b. 通过display transceiver alarm命令查看光模块是否有Rx_Los或Tx_Fault告警信息，若有告警信息，需要清洁或更换光纤、光模块。

c. 通过display transceiver diagnosis命令查看光模块的接收功率和发送功率是否在规定的最大值和最小值的范围内，若有接收或发送的功率超出范围，需要清洁或更换光纤、光模块。

(4) 更换正常端口测试是否能恢复正常。

更换其他正常的端口测试，如果端口更换后错包消失，端口更换回来错包又再次出现，则为端口硬件故障，请更换端口并将故障信息发送技术支持人员分析；如更换到其他正常端口仍会出现错包，则中间传输链路故障的可能性较大。

(5) 检查中间传输链路是否正常。

使用仪器测试中间链路，链路质量差或者线路光信号衰减过大会导致报文在传输过程中出错。检查互连中间链路设备（光转，转接架，传输等设备）是否正常。若中间传输链路故障，请更换或恢复中间传输链路。

(6) 执行shutdown命令，再执行undo shutdown命令，查看端口是否能恢复正常。

(7) 检查端口是否收到大量流控帧

通过display interface命令，查看端口pauses帧计数，如果在不断增长，表明端口发出或者收到了大量的流控帧。检查下端口出入流量是否过大及对端设备的流量处理能力。

(8) 如果故障仍然未能排除，可能是设备或单板硬件故障，请收集信息，并联系技术支持人员。

5. 告警与日志

3.6.2 端口不接收报文

1. 故障描述

端口状态为UP，不接收报文或出现丢包。

使用display interface 命令查看本端入方向的接收报文统计增长数量小于对端出方向发送报文统计增长数量。

2. 常见原因

· 端口出现CRC错误。

· 端口上的配置影响报文的接收。

· 设备或单板硬件故障。

3. 故障分析

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

图19 故障诊断流程图

4. 处理步骤

(1) 查看端口是否出现CRC错误。

按“端口出现CRC错误”章节排查。

(2) 检查端口配置是否影响报文接收。

可通过以下步骤检查端口配置是否影响报文的接收：

· 通过display interface brief命令，查看端口配置是否有异常。其中包括两端的端口双工模式、端口类型以及VLAN等配置。若有异常，请更改端口属性的配置查看该故障端口是否能恢复正常。如果不能，请先执行shutdown命令后，再执行undo shutdown命令，再次查看端口是否能恢复正常。

· 对于二层口，如果配置了STP功能，通过display stp brief命令，查看端口是否为discarding状态。如果端口被STP设置为discarding状态，请根据STP的相关配置进一步排查。建议将连接终端设备的端口配置为边缘端口或关闭该端口的STP功能。

· 如果该端口加入了聚合组，通过display link-aggregation summary命令查看该端口是否为Selected选中状态。当该端口Status为Unselected状态时，该端口无法收发数据报文。请定位端口成为Unselected状态的原因，如聚合组内成员端口的属性类配置与参考端口不一致，进一步排查解决。

· 如果配置了ACL过滤，请根据ACL的相关配置进一步排查。

· 如果接口配置了PFC功能和流量控制功能，请关闭PFC功能和流量控制功能查看该故障端口是否能恢复正常。

· 如果接口上配置了广播/组播/未知单播风暴抑制功能，当接口上的广播/组播/未知单播流量超过用户设置的抑制阈值时，系统会丢弃超出流量限制的报文，查看接口是否配置了了广播/组播/未知单播风暴抑制功能，如果配置了，请关闭接口的风暴抑制功能查看该故障端口是否能恢复正常。

(3) 执行shutdown命令，再执行undo shutdown命令，查看端口是否能恢复正常。

(4) 如果故障仍然未能排除，可能是设备或单板硬件故障，请收集信息，并联系技术支持人员。

5. 告警与日志

3.6.3 端口不发送报文

1. 故障描述

端口状态为UP，但不发送报文。

使用display interface 命令查看本端出方向的发送报文统计不增长。

2. 常见原因

· 光模块异常。

· 端口上的配置影响报文的接收。

· 设备或单板硬件故障。

3. 故障分析

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

图20 故障诊断流程图

4. 处理步骤

(1) 端口进行内部环回检查。

在端口下配置loopback internal命令开启内部环回功能，然后通过display interface查看本端出方向的发送报文统计是否增长。如果增长，则可能是设备或单板硬件故障，请联系技术支持人员。如果不增长，则不是端口内部问题。

(2) 检查端口配置是否影响报文发送。

可通过以下步骤检查端口配置是否影响报文的发送：

· 如果配置了ACL过滤，请根据ACL的相关配置进一步排查。

· 如果接口配置了PFC功能和流量控制功能，请关闭PFC功能和流量控制功能查看该故障端口是否能恢复正常。

· 查看是否配置了接口出方向上阻断广播/未知组播/未知单播报文功能，某些协议（例如ARP、DHCP、RIP、IGMP等）在运行过程中会交互广播/未知组播/未知单播报文，如果配置该功能将导致这些协议报文不能通过该接口发送，请关闭该功能查看故障端口是否能恢复正常。

(3) 执行shutdown命令，再执行undo shutdown命令，查看端口是否能恢复正常。

(4) 如果故障仍然未能排除，可能是设备或单板硬件故障，请收集信息，并联系技术支持人员。

5. 告警与日志

3.6.4 40GE/100GE接口拆分、合并故障

1. 故障描述

支持40GE/100GE接口拆分的机型，40GE/100GE接口拆分或合并失败。

2. 常见原因

· 接口不支持拆分或合并功能。

· 未正确配置拆分或合并命令。

· 拆分或合并后，未保持配置重启设备或单板。

· 设备或单板硬件故障。

3. 故障分析

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

图21 故障诊断流程图

4. 处理步骤

(1) 确认接口是否支持拆分、合并功能。

接口拆分、合并功能的支持情况与设备实际情况有关，需要查看配置命令手册或规格，确认该接口是否支持拆分或合并。若不支持，则更换支持拆分、合并功能的接口。

(2) 查看是否正确配置拆分或合并命令

在接口下，通过display this命令查看是否已配置拆分或合并命令。若没有配置，请正确配置拆分或合并命令。

(3) 是否有重启单板或设备。

部分产品需要保存配置并重启单板或设备后，命令才能生效。

(4) 执行shutdown命令，再执行undo shutdown命令，查看端口是否能恢复正常。

(5) 如果故障仍然未能排除，可能是设备或单板硬件故障，请收集信息，并联系技术支持人员。

5. 告警与日志

3.6.5 电口无法UP

1. 故障描述

电口连接线缆后无法正常UP。

2. 常见原因

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

· 端口配置问题。

· 网线有问题。

· 本端或者对端端口有问题。

3. 故障分析

本类故障的诊断流程如图22所示：

图22 故障诊断流程图

4. 处理步骤

(1) 查看网线两端对接设备网口配置（端口速率，双工，协商模式等）是否一致。执行display interface brief命令，查看两端端口的速率、双工配置是否匹配。若不匹配，请通过speed命令和duplex命令配置端口的速率和双工模式。

需要注意的是：对于不支持半双工模式的交换机（例如S5850-54QS），当设备本端（速率双工为auto/auto模式）和对端（例如100M/FULL）协商后需要工作在half duplex，端口也不会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

GE1/0/1 DOWN DOWN --

Loop0 UP UP(s) 2.2.2.9

NULL0 UP UP(s) --

Vlan1 UP UP --

Vlan999 UP UP 192.168.1.42

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/2 DOWN auto A A 1 aaaaaaa

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

(2) 通过display interface命令查看端口状态Current state是否为Administratively DOWN状态，如果是，请使用undo shutdown命令激活相应的以太网端口。

<Sysname> display interface gigabitethernet 1/0/1

GigabitEthernet1/0/1

Current state: Administratively DOWN

Line protocol state: DOWN

Description: GigabitEthernet1/0/1 Interface

Bandwidth: 1000000 kbps

Maximum transmission unit: 1500

Allow jumbo frames to pass

Broadcast max-ratio: 100%

Multicast max-ratio: 100%

Unicast max-ratio: 100%

Internet protocol processing: Disabled

...

(3) 更换一根确认为好的网线，检查故障是否排除。

(4) 分别更换本端设备端口以及对端设备端口，检查故障是否排除。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

3.6.6 端口频繁UP/DOWN

1. 故障描述

板卡插入线缆或光模块后，端口频繁UP/DOWN。

2. 常见原因

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

· 光模块或线缆故障

· 电口自协商不稳定

3. 故障分析

本类故障的诊断流程如图23所示：

图23 故障诊断流程图

4. 处理步骤

(1) 对于光口，需要确认光模块是否异常。通过查看光模块alarm信息来排查两者光模块以及中间光纤问题。告警信息中如果存在接收有问题那一般是对端端口、光纤或中转传输设备导致；如果是发送有问题或者电流、电压异常那就需要排查本端端口。

<Sysname> display transceiver alarm interface gigabitethernet 1/0/1

GigabitEthernet1/0/1 transceiver current alarm information:

RX loss of signal

RX power low

(2) 检查光模块的接收、发送光功率是否正常（即在该光模块的光功率上下门限值之内）。如果发送光功率处于临界值，请更换光纤、光模块做交叉验证；如接收光功率处于临界值，请排查对端光模块及中间光纤链路。

<Sysname> display transceiver diagnosis interface gigabitethernet 1/0/1

GigabitEthernet1/0/1 transceiver diagnostic information:

Current diagnostic parameters:

Temp(°C) Voltage(V) Bias(mA) RX power(dBm) TX power(dBm)

36 3.31 6.13 -35.64 -5.19

Alarm thresholds:

Temp(°C) Voltage(V) Bias(mA) RX power(dBM) TX power(dBM)

High 50 3.55 1.44 -10.00 5.00

Low 30 3.01 1.01 -30.00 0.00

(3) 对于电口，一般在自协商情况下容易出现协商不稳定，这种情况请尝试设置强制速率双工。

(4) 如果故障依存在，请排查链路、对端设备、中间设备。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

3.6.7 OLT端口不支持光模块

1. 故障描述

支持EPON单板的机型，将光模块插入EPON单板的OLT端口后，设备打印如下日志信息：

%Aug 19 09:53:07:661 2016 HP OPTMOD/4/MODULE_IN: -MDC=1-Slot=3; Olt3/0/12: The transceiver is 1000_BASE_LX_SFP.

^Aug 19 09:53:07:915 2016 HP DRVMNT/2/ERRORCODE: -MDC=1-Slot=3; MdcId=1-ModuleId=0xf0b-Level=2; ErrCode = 1326120980, SYSM: ManuInfo Fail.

%Aug 19 09:53:08:111 2016 HP OPTMOD/3/CFG_ERR: -MDC=1-Slot=3; Olt3/0/12: Transceiver type and port configuration mismatched!

%Aug 19 09:53:08:344 2016 HP OPTMOD/3/TYPE_ERR: -MDC=1-Slot=3; Olt3/0/12: Transceiver type not supported!

2. 常见原因

插入了OLT端口不支持的光模块。

3. 处理步骤

(1) 更换光模块。

EPON单板的OLT端口仅支持1000_BASE_PX_SFP类型的光模块；其他类型的光模块插入时，设备提示插入的光模块类型和不支持的原因。

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

4. 告警与日志

3.6.8 OLT端口不up

1. 故障描述

支持EPON单板的机型，EPON单板的OLT端口下挂ONU设备，ONU设备可正确注册。EPON单板热重启或断电重启后OLT端口不up。

2. 常见原因

· 光模块未插牢固。

· 光模块故障。

3. 处理步骤

(1) 通过命令display transceiver diagnosis interface查询OLT端口的光模块诊断信息。命令行中Current diagnostic parameters下数据表示光模块当前的温度、电压、偏置电流、接收光功率、发送光功率，如果这些诊断信息未正常显示，则光模块硬件接触有问题，请重新拔插光模块。

<H3C>display transceiver diagnosis interface Olt2/0/12

Olt2/0/12 transceiver diagnostic information:

Current diagnostic parameters:

Temp.(°C) Voltage(V) Bias(mA) RX power(dBm) TX power(dBm)

-1 6.50 130.05 -40.00 8.13

Alarm thresholds:

Temp.(°C) Voltage(V) Bias(mA) RX power(dBm) TX power(dBm)

High N/A N/A N/A N/A N/A

Low N/A N/A N/A N/A N/A

(2) 如果反复拔插光模块后，OLT端口仍然不能up，请收集设备的运行信息，并联系H3C的技术支持工程师。

4. 告警与日志

3.6.9 OLT端口接收光功率超出阈值

1. 故障描述

通过display transceiver diagnosis interface命令查询OLT端口的光模块诊断信息，发现接收光功率（RX power）超出阈值（参见以下命令行的Alarm thresholds字段）。

<HP>dis transceiver diagnosis interface olt3/0/8

Olt3/0/8 transceiver diagnostic information:

Current diagnostic parameters:

Temp.(°C) Voltage(V) Bias(mA) RX power(dBm) TX power(dBm)

38 3.27 5.61 -40.00 4.53

Alarm thresholds:

Temp.(°C) Voltage(V) Bias(mA) RX power(dBm) TX power(dBm)

High 85 3.60 100.00 -4.00 8.00

Low -13 3.00 0.00 -32.10 1.00

2. 常见原因

· ONU未注册。

· ONU端口未使用过光模块诊断命令。

3. 处理步骤

(1) 检查该光模块对应的OLT端口是否已经存在up的ONU端口，如果没有ONU端口up，则OLT接收光功率超出阈值为正常现象。等ONU注册成功后，接收光功率会变为正常。

(2) 当有OLT下有ONU端口up，而OLT端口的接收光功率仍然超出阈值时，可以先通过display transceiver diagnosis interface命令查询该OLT下任意up的ONU端口的诊断信息，然后再次查询OLT端口的光模块诊断信息，此时OLT端口的光功率应该可以正常显示（因为OLT光模块的接收光功率显示需要依赖ONU端口的光模块诊断命令来触发）。

(3) 如果故障仍未排除，请收集设备运行信息并联系H3C的技术支持工程师。

4. 告警与日志

3.6.10 ONU端口不up

1. 故障描述

display interface命令显示ONU接口状态为down。

2. 常见原因

· ONU未正确绑定。

· 关闭了厂商兼容功能。

· 物理链路异常。

3. 故障分析

本类故障的诊断流程如图24所示：

图24 故障诊断流程图

4. 处理步骤

(1) 检查ONU绑定是否正确

如果ONU设备是通过bind onu-id命令手动绑定的，请通过display onu命令检查绑定的MAC地址，确保该地址与ONU设备的MAC地址一致。

如果ONU设备是通过onu bind batch或onu bind auto命令批量/自动绑定的，请再次执行onu bind batch或onu bind auto命令，以确认绑定是否生效。需要注意的是：一个OLT端口上可注册的ONU设备有限，具体数量限制请参见各产品的配置命令手册。

(2) 检查光模块

根据3.7.1 光口不UP故障的故障定位处理方法，定位是否是光模块故障。

(3) 检查兼容性

H3C OLT设备上厂商兼容功能缺省为开启状态，如果关闭了厂商兼容功能（undo vendor-compatible），则非H3C的ONU设备不能注册到该OLT，对应ONU端口down。

关闭厂商兼容功能后，如果使用bind onu-id命令在ONU端口上绑定了非H3C的ONU设备，那么再开启厂商兼容功能时（执行vendor-compatible），需要注销该ONU端口（执行deregister onu命令）或关闭再打开该ONU端口（执行shutdown、undo shutdown命令），才能使该ONU注册到OLT。

(4) 检查物理线路

插入EPON光模块，OLT端口UP，但是所有ONU无法注册，对端ONU设备PON灯不亮，说明ONU没有收到光，排查是否插入了不符合要求的光模块（参考“3.6.7 OLT端口不支持光模块”），分光器是否存在异常。

如果部分ONU无法注册，需要排查ONU设备是否正常，采用替换ONU的方式验证。另外需要排查光纤线路是否有问题：如果一个分光器下部分ONU能够正常注册UP，可以交换ONU设备的光纤查看效果。

(5) 如果执行上述步骤后故障无法排除，请联系H3C的技术支持工程师。

5. 告警与日志

3.6.11 EPON系统用户设备不能上网

1. 故障描述

ONU设备注册正常，下挂的用户设备通过ONU设备接入，但不能接入网络。

2. 常见原因

设备MAC地址配置错误。

3. 处理步骤

(1) 检查用户设备MAC地址。

如果MAC地址前两个字节的第7bit为1，为异常MAC地址，例如：02xx-xxxx-xxxx。符合此规则的异常源MAC地址报文在OLT设备会被丢弃。出现此种异常MAC地址，一般是由于用户修改MAC地址导致。

(2) 如果故障无法排除，请收集设备的运行信息，并联系H3C的技术支持工程师。

4. 告警与日志

3.7 光模块故障

3.7.1 光口不UP故障

1. 故障描述

光口不UP。

2. 常见原因

· 设备当前版本不支持该光模块。

· 光口有异物或光模块金手指被污染、损坏。

· 光模块与接口速率不匹配。

· 光口故障。

· 光模块或线缆故障。

· 光模块与光纤类型不匹配。

3. 故障分析

本类故障的诊断流程如3.6.1 3. 图18所示。

图25 故障诊断流程图

4. 处理步骤

(1) 检查设备当前版本是否支持该光模块。

可通过产品安装手册或软件版本说明书查看当前软件版本是否支持该光模块。如果有新版本支持该光模块，也可以升级软件版本。

(2) 检查光模块与端口/两端端口的速率、双工模式是否匹配。

执行display interface命令，查看端口与光模块/两端端口的速率、双工配置是否匹配。若不匹配，请通过speed命令和duplex命令配置端口的速率和双工模式。

(3) 检查是否满足了端口的特殊配置要求。

部分交换机存在一些特殊的配置，满足这些配置后，相应端口才能UP。例如：

¡ 对于25G、100G和400G端口，部分交换机的端口下提供port fec mode { auto | none | rs-fec }命令行，用于控制FEC的模式，以使不同型号设备之间能够对接。链路两端使用的FEC模式必须一致。

¡ 对于25G端口，部分交换机的端口下提供port training { disable | enable }命令行，用于控制链路补偿功能的开关状态，以使不同型号设备之间能够对接。链路两端的链路补偿功能开启状态必须一致。

¡ 部分交换机会将端口分组，同一组中的端口速率配置需要保持一致。当用户需要修改某个端口的速率时，该配置会在同一组中的所有端口上生效。当用户使用default命令恢复当前端口的缺省配置时，端口工作速率会重置为缺省值，且该配置会在同一组中的所有端口上生效。

有关各个产品的具体配置限制，请参见“二层技术—以太网交换配置指导”或“接口管理配置指导”中的“以太网接口”。

(4) 检查光接口是否故障。

在本设备上的相同速率的光口上用匹配的线缆（适用于短距离连接）直接互连，查看该端口是否能UP。如果能UP，则说明对端端口异常；如果不能UP，则说明本端端口异常。可通过更换本端与对端端口来检查故障是否解决。

(5) 检查光模块/线缆是否异常。

可通过如下步骤检查光模块/线缆是否异常：

a. 可通过display transceiver alarm interface命令，查看当前端口上的光模块的故障告警信息，若显示为“None”，则表示没有故障；若显示有告警信息，可通过查看光模块/线缆告警信息来确认是光模块问题还是光纤或者对端问题。比如出现RX signal loss和TX fault错误，可以查看光口、光模块是否存在异物，或者光模块金手指严重氧化。

b. 可通过display transceiver interface命令，检查两端的光模块类型、波长、传输距离等参数是否一致。

c. 可通过display transceiver diagnosis interface命令，检查光模块的数字诊断参数的当前测量值是否在正常范围内。参数异常常见问题及解决办法如下：

- 当光纤与光模块接触不良时，可通过将光线与光模块插牢解决。

- 当光纤质量不好或损坏，可通过更换光纤解决。

- 当传输路径增加了中间光衰设备，可根据实际使用，调整光衰设备解决。

- 当光模块适配传输距离与实际使用距离相差较大，更换为与实际传输距离适配的光模块解决。

d. 对怀疑故障的光模块进行交叉验证，如更换端口、与正常的光模块互换，确认是光模块本身故障还是相邻设备或中间链路故障。

(6) 检查光模块类型与光纤是匹配。

可通过《H3C光模块手册》，查看光模块类型与光纤类型是否匹配。若不匹配，可通过更换光纤解决。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

3.7.2 光模块上报非H3C合法光模块故障处理

1. 故障描述

通过display logbuffer命令查看系统日志时，发现存在上报非H3C合法光模块的相关信息。相关日志信息显示如下：

This transceiver is NOT sold by H3C. H3C therefore shall NOT guarantee the normal function of the device or assume the maintenance responsibility thereof!

2. 常见原因

光模块为第三方光模块或伪造的H3C光模块。

3. 故障分析

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

图26 故障诊断流程图

4. 处理步骤

(1) 检查光模块是否为H3C光模块。

a. 根据光模块上的标签判断是否为H3C认证光模块。

b. 通过命令display transceiver interface，查看Vendor Name是否是H3C。如果显示的是H3C，则可能是没有电子标签的H3C光模块，也可能不是H3C光模块，需要进一步确认。如果显示的是其它信息，则一定不是H3C光模块，可通过更换为H3C光模块来检查故障是否排除。

[Sysname] display transceiver interface twenty-fivegige 1/0/1

Twenty-FiveGigE1/0/1 transceiver information:

Transceiver Type : 40G_BASE_LR4_QSFP_PLUS

Connector Type : LC

Wavelength(nm) : 1301

Transfer Distance(km) : 10(SMF)

Digital Diagnostic Monitoring : YES

Vendor Name : H3C

Ordering Name : QSFP-40G-LR4-WDM1300

(2) 与H3C的技术支持工程师确认是否是H3C光模块。

通过Probe视图下的命令display hardware internal transceiver register interface和display transceiver information interface收集光模块信息。然后向H3C技术支持工程师反馈光模块上的条码，确认光模块的渠道来源，明确是否是H3C光模块。如果确认不是H3C光模块，可通过更换为H3C光模块来检查故障是否排除。

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

¡ 上述步骤的执行结果。

¡ 设备的日志信息、告警信息。

5. 告警与日志

3.7.3 光模块不支持数字诊断

1. 故障描述

通过display transceiver diagnosis interface命令查看光模块诊断信息时，系统提示光模块不支持数字诊断。显示如下：

<Sysname> display transceiver diagnosis interface Twenty-FiveGigE1/0/1

The transceiver does not support this function.

2. 常见原因

· 光模块为非H3C光模块。

· 光模块不支持数字诊断。

· 光模块故障。

· 设备/光口故障。

3. 故障分析

本类故障的诊断流程如3.6.2 3. 图19所示。

图27 故障诊断流程图

4. 处理步骤

(1) 判断是否为H3C光模块，具体步骤见3.7.2 光模块上报非H3C合法光模块故障处理。

(2) 通过display transceiver interface命令，查看Digital Diagnostic Monitoring字段是否是YES，如果是YES，表明支持数字诊断，反之亦然。

(3) 使用相同型号光模块插在本设备其他正常端口或者其他正常运行且支持该光模块的设备上，检查是否仍然提示不支持数字诊断。

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

¡ 上述步骤的执行结果。

¡ 设备的告警信息。

5. 告警与日志

3.7.4 光模块序列号丢失

1. 故障描述

使用display transceiver manuinfo interface命令查看光模块序列号丢失。

2. 常见原因

· 光模块未插紧。

· 光模块/设备故障。

3. 故障分析

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

图28 故障诊断流程图

4. 处理步骤

(1) 检查光模块是否完全插入光口。

可通过插紧光模块，或更换光口解决。

(2) 检查光模块是否故障。

可通过使用相同型号光模块插在本设备端口或者其他正常运行且支持该光模块的设备上来判断。

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

¡ 上述步骤的执行结果。

¡ 设备的告警信息。

5. 告警与日志

3.8 PoE供电故障

3.8.1 PoE供电异常

1. 故障描述

PoE供电功率不足或无法供电。

2. 常见原因

· 供电电源与设备不匹配或供电电源供电能力不足。

· PSE固件故障。

· 受电设备为非标准PD，PoE接口没有开启非标准PD检测功能。

3. 故障分析

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

图29 故障诊断流程图

4. 处理步骤

(1) 确定电源配备是否正确。

检查设备配备的电源模块对于PoE设备，必须按照电源配置方案配置电源。关于电源模块的适配情况，请参见对应产品的安装指导或硬件描述手册。

(2) 查看PSE固件运行是否正常。

执行display poe device命令查看显示PSE的工作状态。如果工作状态显示为faulty，则说明PSE故障。如下所示：

<Sysname> display poe device

Slot 1:

PSE ID Slot No. SSlot No. PortNum MaxPower(W) State Model

1 0 0 48 0 Faulty LSP1POEA

以上显示信息说明该PSE存在故障。

用户可联系H3C用服或设备供应商获取对应版本的PSE固件，然后使用poe update命令升级PSE固件。升级方法如下所示：

<Sysname> system-view

[Sysname] poe update full POE-168.bin pse 4

This command will refresh the PSE firmware. Continue? [Y/N]:y

……

以上显示信息说明PSE软件升级成功。再次执行display poe device命令查看显示PSE的工作状态。如果工作状态显示为on或off，则说明PSE故障已修复。如下所示：

[Sysname] display poe device

Slot 1:

PSE ID Slot No. SSlot No. PortNum MaxPower(W) State Model

1 0 0 48 0 on LSP1POEA

(3) 在任意视图中执行display poe pse命令查看显示PSE的信息。确认当前整机供电功率、平均功率、峰值功率是否正常、PSE检测非标准PD功能是否打开等。如下所示：

<Sysname> display poe pse

PSE ID : 1

Slot NO. : 0

PSE Model : LSBMPOEGV48TP

PSE Status : Enabled

PSE Preempted : No

Power Priority : Low

Current Power : 130 W

Average Power : 20 W

Peak Power : 240 W

Max Power : 200 W

Remaining Guaranteed Power : 120 W

PSE CPLD Version : 100

PSE Software Version : 200

PSE Hardware Version : 100

Legacy PD Detection : Disabled

Power Utilization Threshold : 80

PSE Power Policy : Disabled

PD Power Policy : Disabled

PD Disconnect-Detection Mode : DC

· 如果PSE当前供电功率、PSE平均功率、PSE峰值功率都达到或接近PSE最大供电功率，说明PoE电源模块供电不足，此时请选配更大供电功率的PoE电源模块。

· 如果PSE Legacy PD Detection字段显示为Disable，请执行poe legacy enable命令，开启非标准PD检测功能。

(4) 在任意视图中执行display poe interface命令查看显示PoE端口的相关信息。确认当前端口供电功率、平均功率、峰值功率是否正常，端口的电流、电压是否正常。如下所示：

<Sysname> display poe interface gigabitethernet 1/0/1

PoE Status : Enabled

Power Priority : Critical

Oper : On

IEEE Class : 1

Detection Status : Delivering power

Power Mode : Signal

Current Power : 11592 mW

Average Power : 11610 mW

Peak Power : 11684 mW

Max Power : 15400 mW

Electric Current : 244 mA

Voltage : 51.7 V

PD Description : IP Phone For Room 101

如果当前端口供电功率、平均功率、峰值功率都达到或接近端口最大供电功率，说明PoE端口供电不足，此时请执行poe max-power命令重新配置PoE端口的最大供电功率。

(5) 如果故障仍然未能排除：

¡ 当受电设备为标准PD时，请收集上述步骤的执行结果，并联系技术支持人员。

¡ 当受电设备为非标准PD时，请收集PD厂家、型号、所用网线和上述步骤的执行结果等信息，并联系技术支持人员。

5. 告警与日志

3.8.2 外置PoE电源异常断电

1. 故障描述

对于使用外置PoE电源进行PoE供电的款型，外置PoE电源异常断电，影响PoE功能的正常使用。

2. 常见原因

外部供电异常。

3. 故障分析

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

图30 故障诊断流程图

4. 处理步骤

(1) 不需重启设备时，等待30秒后给外置PoE重新上电，查看PoE功能是否恢复。

(2) 需要重启设备时，按如下方式处理：

如果由于外部原因（例如外置PoE电源和设备均断电）或误操作等原因导致在外置PoE电源断电时，需重启设备（包括设备重新上电和通过reboot命令重启），请按如下步骤恢复PoE功能：

a. 给外置PoE电源上电；

b. 给设备重新上电启动或通过reboot命令重启；

c. 设备启动完全后，如果PoE功能仍然无法正常工作，请删除设备上PoE的相关配置，然后在设备上重新完成PoE功能的配置。

(3) 收集信息并寻求技术支持

如果上述操作完成后PoE功能仍无法恢复正常，请收集设备运行信息，并联系H3C的技术支持工程师。

5. 告警与日志

4 转发类故障处理

4.1 转发类故障处理

4.1.1 二层流量转发丢包

1. 故障描述

设备二层转发丢包，即源端和目的端在同一二层网络的同一VLAN内，通信过程中有丢包。

2. 常见原因

· 端口下有错包

· 报文因ACL规则被丢弃

· 端口处于block状态

· 拥塞丢包

3. 故障分析

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

图31 二层流量转发丢包故障诊断流程图

4. 处理步骤

(1) 查看端口下是否有错包

使用display interface命令查看端口下是否有错包。如果有错包，请前往步骤2，如果没有错包，请前往步骤3进行后续步骤的检查。

<Sysname>display interface Twenty-FiveGigE1/0/17

Twenty-FiveGigE1/0/17 current state: UP

Line protocol state: UP

IP Packet Frame Type: PKTFMT_ETHNT_2, Hardware Address: aa11-2233-4496

……

Last 300 seconds input: 0 packets/sec 10 bytes/sec 0%

Last 300 seconds output: 0 packets/sec 10 bytes/sec 0%

Input (total): 1438 packets, 480292 bytes

0 unicasts, 0 broadcasts, 1438 multicasts, 0 pauses

Input (normal): 1438 packets, - bytes

0 unicasts, 0 broadcasts, 1438 multicasts, 0 pauses

Input: 0 input errors, 0 runts, 0 giants, 0 throttles

0 CRC, 0 frame, - overruns, 0 aborts

- ignored, - parity errors

Output (total): 1440 packets, 475200 bytes

0 unicasts, 0 broadcasts, 1440 multicasts, 0 pauses

Output (normal): 1440 packets, - bytes

0 unicasts, 0 broadcasts, 1440 multicasts, 0 pauses

Output: 0 output errors, - underruns, - buffer failures

0 aborts, 0 deferred, 0 collisions, 0 late collisions

0 lost carrier, - no carrier

(2) 端口下有错包

端口下有错包有以下几种可能的故障原因，可使用排除法定位：

¡ 端口本身硬件故障：通过将连接端口的线缆连接到配置相同且可正常工作的端口查看是否端口本身硬件故障。如果是端口本身硬件故障，请将线缆连接到可正常工作的端口。

¡ 链路上光模块、光纤或以太网双绞线故障：通过更换完好的光模块、光纤或以太网双绞线定位是否光纤或以太网双绞线故障。如果是光模块、光纤或以太网双绞线故障，请更换完好的光模块、光纤或以太网双绞线。

¡ 对端配置问题，查看对端速率、双工模式的配置是否和本端一致。如果对端速率和双工模式的配置与本端不一致，请更新配置保证本端和对端速率和双工模式的配置一致。

¡ 当通过上述方法无法解决错包问题需要联系技术支持时，请先通过如下方法收集信息，然后前往步骤7。

Probe视图下，使用debug port mapping命令确认面板端口对应的芯片端口。

[Sysname-probe]debug port mapping slot 1

[Interface] [Unit] [Port] [Name] [Combo?] [Active?] [IfIndex] [MID] [Link]

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

WGE1/0/1 0 9 xe8 no no 0x1 1 down

WGE1/0/2 0 10 xe9 no no 0x2 1 down

WGE1/0/3 0 11 xe10 no no 0x3 1 down

WGE1/0/4 0 12 xe11 no no 0x4 1 down

WGE1/0/5 0 13 xe12 no no 0x5 1 down

WGE1/0/6 0 14 xe13 no no 0x6 1 down

WGE1/0/7 0 15 xe14 no no 0x7 1 down

WGE1/0/8 0 16 xe15 no no 0x8 1 down

WGE1/0/9 0 17 xe16 no no 0x9 1 down

WGE1/0/10 0 18 xe17 no no 0xa 1 down

WGE1/0/11 0 19 xe18 no no 0xb 1 down

WGE1/0/12 0 20 xe19 no no 0xc 1 down

WGE1/0/13 0 21 xe20 no no 0xd 1 down

WGE1/0/14 0 22 xe21 no no 0xe 1 down

WGE1/0/15 0 23 xe22 no no 0xf 1 down

WGE1/0/16 0 24 xe23 no no 0x10 1 down

WGE1/0/17 0 25 xe24 no no 0x11 1 down

WGE1/0/18 0 26 xe25 no no 0x12 1 down

WGE1/0/19 0 27 xe26 no no 0x13 1 down

WGE1/0/20 0 28 xe27 no no 0x14 1 down

---- More ----

查到Twenty-FiveGigE1/0/17对应的芯片端口名字为xe24，然后执行下面命令两次或两次以上，查看是否有接收丢包统计(RDBGC)和发送丢包统计(TDBGC)计数。如果有将相关信息反馈技术支持。

[Sysname-probe]bcm slot 1 chip 0 show/c/xe24

RDBGC3.xe24 : 5 +5

RDBGC6.xe24 : 5 +5

R64.xe24 : 19 +19

R127.xe24 : 163 +163 1/s

R255.xe24 : 10 +10

R511.xe24 : 6 +6

RPKT.xe24 : 198 +198 2/s

RMCA.xe24 : 136 +136 1/s

RBCA.xe24 : 62 +62

RPOK.xe24 : 198 +198 2/s

RBYT.xe24 : 21,392 +21,392 315/s

[Sysname-probe]bcm slot 1 chip 0 show/c/xe24

R64.xe24 : 20 +1

R127.xe24 : 168 +5 2/s

RPKT.xe24 : 204 +6 2/s

RMCA.xe24 : 141 +5 2/s

RBCA.xe24 : 63 +1

RPOK.xe24 : 204 +6 2/s

RBYT.xe24 : 21,974 +582 261/s

(3) 报文因匹配ACL被过滤

a. 检查端口、VLAN以及全局下是否配置了ACL或QoS策略，如果配置了ACL或QoS策略，请检查端口进入的报文是否因匹配了ACL或QoS策略的流分类而被丢弃，包括端口下的packet-filter（使用display packet-filter查看）、qos policy（使用display qos policy查看），vlan policy（使用display qos vlan-policy查看）以及global policy（使用display qos policy global查看）。如果报文因匹配了ACL或QoS策略的流分类而被丢弃，请参考ACL或QoS的配置方法通过更新配置使报文不被丢弃。

b. 检查是否因匹配一些特性自动创建的的ACL而被过滤，在以太网接口视图下使用display this命令查看端口下是否配置了下面特性或使用特性相关的具体命令查看：

- 端口是否配置ip source binding或ip verify source，使用display ip source binding或display ipv6 source binding可以查看绑定表项信息。如果端口配置了ip source guard且通过上述 display命令发现没有匹配报文的表项，请根据您使用的绑定表项的生成方法进一步排查。

- 查看端口是否配置了Portal认证，如果配置了Portal认证，则没有通过Portal认证的用户，报文会被该端口丢弃。使用display portal interface可以显示指定VLAN接口的Portal配置信息。请用户根据实际情况确定是否可以取消Portal认证，在端口所属VLAN的对应VLAN虚接口下使用undo portal server server-name可以取消三层Portal认证。

- 使用display dot1x命令查看端口是否使能了EAD快速部署。如果使能了802.1X的EAD快速部署功能，那未认证成功的用户访问除Free IP以外的网段时就会丢包。请定位用户是否是未认证成功用户，且未认证成功用户访问的是否是Free IP以外的网段来进一步确认丢包原因。

- 端口所在VLAN是否配置了MFF，使用display mac-forced-forwarding vlan命令显示指定VLAN的MFF信息，如果显示信息中没有Gateway信息，请根据MFF运行的模式查看ARP Snooping是否正确配置。

(4) 端口被协议设置为block状态

¡ 使用display stp brief命令查看端口是否被STP设置为discarding状态。如果端口被STP设置为discarding状态，请根据STP的相关配置进一步排查。H3C建议您将连接终端设备的端口配置为边缘端口或关闭该端口的STP功能。

¡ 如果端口属于某个聚合组，使用display link-aggregation verbose命令查看聚合口的详细信息，当该端口Status为Unselected状态时，该端口无法收发数据报文。请定位端口成为Unselected状态的原因，如聚合组内成员端口的属性类配置与参考端口不一致，进一步排查解决。

¡ 查看端口是否被Smartlink阻塞：使用display smart-link group命令查看端口状态，当State为STANDBY或DOWN时端口不能转发数据。如果State为DOWN，请定位端口成为DOWN状态的原因，如上行链路上的设备配置了Monitor Link功能造成该端口DOWN，或该端口所在链路连接发生故障或端口被shutdown，进一步排查解决；如果State为STANDBY，请将该设备Smart Link组的主、从端口互换。

(5) 配置相关丢包

¡ 在以太网接口视图下使用display this命令查看端口是否在报文所属VLAN中。如果端口不在报文所属VLAN中，请将端口加入该VLAN。

¡ 使用display mac-address blackhole命令查看是否因为匹配了黑洞MAC地址表项被丢包。请根据实际情况确定是否可以取消该黑洞MAC。如果需要删除该黑洞MAC，请使用undo mac-address blackhole mac-address vlan vlan-id命令删除。

¡ 使用display qos lr interface查看是否有端口限速的配置。如果端口有限速的配置，请查看令牌生成速度和突发流量配置值是否合理，可以通过使用qos lr { inbound | outbound } cir committed-information-rate [ cbs committed-burst-size ]命令调整令牌生成速度和突发流量配置值定位解决。

¡ 在以太网接口视图下使用display this命令查看端口是否有风暴抑制相关配置，包括广播风暴抑制比（broadcast-suppression），组播风暴抑制比（multicast-suppression），未知单播风暴抑制比（unicast-suppression）。如果端口下配置了风暴抑制比，可以通过将风暴抑制比的数值调大定位解决。

(6) 拥塞丢包

通过display qos queue interface命令查看端口是否有拥塞丢包。请参考拥塞管理的相关内容定位解决拥塞问题。

(7) 寻求技术支持

如果上述检查完成后故障仍无法排除，请联系H3C的技术支持工程师。

5. 告警与日志

4.1.2 三层流量转发丢包

1. 故障描述

设备三层转发丢包，即发送端IP地址和目的端IP地址不在同一网段内，通信过程中有丢包。

2. 常见原因

· 端口出现故障

· ARP/路由表项不正确

3. 故障分析

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

图32 三层转发丢包故障诊断流程图

4. 处理步骤

(1) 检查端口是否有故障

根据4.1.1 二层流量转发丢包的故障定位处理方法，定位是否是设备端口故障（包括端口硬件故障和端口配置故障）：

¡ 如果是端口故障，请按照4.1.1 二层流量转发丢包的故障处理思路进行处理。

¡ 如果不是端口故障，则执行步骤2。

(2) 查看ARP表项是否正确（IPv4）

如果三层转发基于IPv4协议，使用display arp命令查看设备上是否学习到网关设备的ARP表项、学习到的ARP表项是否正确：

¡ 如果设备上未学习到ARP表项或学习到的表项错误，通过打开debugging arp packet查看设备ARP表项学习情况，来定位ARP问题的原因。对于未学习到ARP表项，可以使用arp static命令手工添加静态ARP表项。

¡ 使用display mac-address命令查看对应的MAC地址表项的出接口和ARP表项中的出接口是否一致，如果不一致，使用reset命令清除ARP表项，让设备重新学习表项。

¡ 如果设备上ARP表项学习正确，请执行步骤3。

(3) 查看ND表项是否正确（IPv6）

如果三层转发基于IPv6协议，使用display ipv6 neighbors命令查看设备上是否学习到网关设备的ND表项、学习到的ND表项是否正确：

¡ 如果设备上未学习到ND表项或学习到的表项错误，通过打开debugging ipv6 icmp查看设备ND表项学习情况，来定位ND问题的原因。同时，检查两端MAC地址是否相同,或者是否配置了组播MAC地址。如果都检查无误，对于未学习到ND表项，可以使用ipv6 neighbor命令手工添加静态ND表项。

¡ 使用display mac-address命令查看对应的MAC地址表项的出接口和ND表项中的与邻居相连接口是否一致，如果不一致，使用reset ipv6 neighbors命令清除ND表项，让设备重新学习表项。

¡ 如果设备上ND表项学习正确，请执行步骤4。

(4) 查看路由表项是否正确

使用display ip routing-table命令查看设备上学习的路由信息是否正确：

¡ 如果设备上学习到的路由信息不正确，请根据您使用的具体的路由协议进行进一步排查。

¡ 使用display fib命令查看对应的FIB表项的出接口和路由表项中的出接口是否一致，如果不一致，使用reset命令清除路由表项，让设备重新学习表项。

¡ 如果设备上的路由信息正确，请执行步骤4。

(5) 寻求技术支持

如果上述检查完成后故障仍无法排除，请联系H3C的技术支持工程师。

5. 告警与日志

4.1.3 因协议报文丢包导致的 协议震荡

1. 故障描述

协议震荡一般都是协议报文交互时不通导致的。

2. 常见原因

· 二三层转发丢包

· 软件收包发生丢包

3. 故障分析

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

图33 因协议报文丢包导致的协议震荡故障诊断流程图

4. 处理步骤

(1) 查看二层转发是否丢包

根据4.1.1 二层流量转发丢包一节的故障定位处理方法，定位是否是设备端口故障（包括端口硬件故障和端口配置故障）：

¡ 如果是端口故障，请按照4.1.1 二层流量转发丢包节的故障处理思路进行处理。

¡ 如果不是端口故障，则执行步骤2。

(2) 查看三层转发是否丢包

根据4.1.2 三层流量转发丢包一节的故障定位处理方法，定位是否为三层故障（包括ARP表项错误和路由表项错误）：

¡ 如果是三层故障，请按照4.1.2 三层流量转发丢包一节的故障处理思路进行处理。

¡ 如果不是三层故障，则执行步骤3。

(3) 查看软件收包是否丢包

部分机型Probe视图下支持debug rxtx softcar show命令，可以查看软件收包是否丢包。

<Sysname> system-view

[Sysname] probe

[Sysname-probe] debug rxtx softcar show slot 1

ID Type RcvPps Rcv_All DisPkt_All Pps Dyn Swi Hash ACLmax

0 ROOT 0 0 0 300 S On SMAC 0

1 ISIS 0 0 0 200 D On SMAC 8

2 ESIS 0 0 0 100 S On SMAC 8

3 CLNP 0 0 0 100 S On SMAC 8

4 VRRP 0 0 0 1024 S On SMAC 8

5 UNKNOWN_IPV4MC 0 0 0 100 S On SMAC 8

6 UNKNOWN_IPV6MC 0 0 0 100 S On SMAC 8

7 IPV4_MC_RIP 0 0 0 150 D On SMAC 8

8 IPV4_BC_RIP 0 0 0 150 D On SMAC 8

9 MCAST_NTP 0 0 0 100 S On SMAC 8

10 BCAST_NTP 0 0 0 100 S On SMAC 8

DisPkt_All为丢包计数，Rcv_All为收包总数，RcvPps为接收速率。如果发现有丢包发生，请收集信息，然后前往步骤4。

(4) 寻求技术支持

如果上述检查完成后故障仍无法排除，请联系H3C的技术支持工程师。

5. 告警与日志

4.1.4 报文不能进行ECMP转发

1. 故障描述

EVPN组网中，报文不能通过多条等价路由进行ECMP转发。

2. 常见原因

· 只有一条路由，无法形成ECMP

· BGP团体属性和扩展团体属性配置不同

· 路由中携带了default-gateway扩展团体属性

· 存在其他路由协议干扰

3. 故障分析

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

图34 故障处理流程图

4. 故障处理步骤

(1) 检查是否存在到达同一目的网络的多条路由

通过display bgp l2vpn evpn route-distinguisher route-type ip-prefix命令查看是都存在到达同一目的网络RD相同、下一跳不同的多条路由。如果只有一条路由，则无法进行ECMP；如果存在多条路由，则继续进行以下操作。

(2) 检查路由的团体属性和扩展团体属性是否一致

通过display bgp l2vpn evpn route-distinguisher route-distinguisher evpn-route route-length命令查看EVPN路由的详细信息。判断到达同一目的网络的多条路由携带的BGP团体属性和扩展团体属性是否相同。如果不同，则修改通过配置修改路由的BGP团体属性和扩展团体属性；否则，无法形成ECMP。

(3) 检查路由是否携带default-gateway属性

通过display bgp l2vpn evpn route-distinguisher route-distinguisher evpn-route route-length命令查看EVPN路由的详细信息，判断路由中是否携带default-gateway扩展团体属性。若携带该扩展团体属性，则路由之间不能形成ECMP。

(4) 检查是否存在其他路由协议的路由

通过display ip routing-table vpn-instance命令查看是否存在其他路由协议生成的到达该目的网络的路由。如果存在，请通过preference命令修改BGP路由的优先级，使得BGP路由优于其他路由协议生成的路由（优先级数值越小表明优先级越高）。

(5) 检查是否配置进行BGP负载分担的路由条数

通过display bgp routing-table ipv4 vpn-instance命令查看是否存在相同前缀的多条路由，如果存在多条，但是只有一条为最优路由（带有“>”标记），则执行display current-configuration configuration bgp命令检查BGP-VPN IPv4单播地址族视图下是否配置了balance命令。如果没有配置，则执行balance命令配置进行BGP负载分担的路由条数大于1。

5. 告警与日志

5 基础配置类故障处理

5.1 登录设备类故障处理

5.1.1 Console口密码遗忘

1. 故障描述

Console口采用Password认证或AAA本地认证的情况下，管理员通过Console口登录设备时，因密码不正确而无法成功登录。

2. 常见原因

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

· 管理员遗忘了Console口的登录密码或输入错误的密码。

· Console口的登录账户已过期。

3. 故障分析

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

图35 Console口密码遗忘故障诊断流程图

4. 处理步骤

(1) 确认是否能过通过Telnet/Stelnet方式登录设备。

如果管理员拥有Telnet/Stelnet账号，并且该账号拥有network-admin/level-15用户角色，则可以通过Telnet/Stelnet方式登录到设备后修改Console口登录相关配置。具体的处理步骤如下：

a. 使用Telnet/Stelnet账号登录设备，执行display line命令查看Console口所在用户线的认证方式。

<Sysname> display line

Idx Type Tx/Rx Modem Auth Int Location

0 CON 0 9600 - P - 0/0

+ 81 VTY 0 - N - 0/0

...

以上显示信息中，“Auth”字段取值为P表示采用密码认证方式，取值为A表示采用AAA认证方式。

b. 确认当前登录的Telnet/Stelnet用户是否具有network-admin/level-15用户角色。

对于采用none或者password认证方式登录的用户，可在当前登录的用户线视图下查看用户角色配置是否为network-admin/level-15；对于采用scheme认证方式登录的用户，用户角色由AAA授权，需要查看对应的本地账号或远程账号的授权用户角色属性。

<Sysname> system-view

[Sysname-line-vty0] display this

line con 0

authentication-mode password

user-role network-admin

line vty 0 63

authentication-mode none

user-role network-admin

return

如果用户角色不是network-admin/level-15，则当前登录的账户没有更改Console口相关配置的权限，请执行步骤（2）；如果用户角色为network-admin/level-15，请根据Console口的认证方式采用不同的处理步骤。

c. Console口采用密码认证方式的情况下，修改Console口认证密码。

进入Console口所在的用户线，设置新的密码（下例中为1234567890!）。同时，建议将用户角色设置为network-admin/level-15，避免Console口登录后用户权限过低。

[Sysname] line console 0

[Sysname-line-console0] set authentication password simple 1234567890!

[Sysname-line-console0] user-role network-admin

d. Console口采用AAA本地认证方式的情况下，修改Console口的本地用户密码。

进入Console口登录所使用账户的本地用户视图，修改本地用户的密码（下例中用户名为admin，用户密码为1234567890!）。同时，建议将用户角色设置为network-admin/level-15，避免Console口登录后用户权限过低。

[Sysname] local-user admin class manage

[Sysname-luser-manage-admin] password simple 1234567890!

[Sysname-luser-manage-admin] authorization-attribute user-role network-admin

e. Console口采用AAA远程认证方式的情况下，请联系AAA服务器管理员获取登录密码。

f. 为了防止重启后配置丢失，请执行save命令保存当前配置。

(2) 通过Console口连接设备后，断电重启设备，进入BootWare菜单。

· 进入到BootWare菜单需要重启设备，会导致业务中断，请视具体情况做好备份，并尽量选择业务量较少的时间操作。

· 对于分布式设备，请通过Console口分别连接主备板后整机重启。当分别进入到各自的BootWare扩展菜单后，按照下面的操作步骤首先完成主控板上的所有配置，然后再重启备板。

系统启动后，如果未及时选择进入基本段，则会直接运行BootWare扩展段程序。当显示信息出现“Press Ctrl+B to access EXTENDED-BOOTWARE MENU...”时，键入<Ctrl+B>，系统会首先给出密码恢复功能是否开启的提示信息：

Password recovery capability is enabled.

Password recovery capability is disabled.

¡ 密码恢复功能处于开启状态时，可以选择跳过Console口认证选项，或者跳过当前配置选项。具体操作过程请分别参见步骤（3）、（4）。

¡ 密码恢复功能处于关闭状态时，可以选择恢复出厂配置选项。具体操作过程请执行步骤（5）。

(3) 通过BootWare扩展段菜单跳过Console口认证，登录后修改Console口密码。

直接回车，进入BootWare扩展段主菜单（不同产品跳过Console口认证的菜单选项不同，请以实际情况为准，如下以S7500E系列交换机为例）

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

…

Enter your choice(0-9):

请按照系统提示，键入<8>，回车并重启设备后，系统将跳过设备上Console口认证密码。

Enter your choice(0-9): 8

Clear Image Password Success!

系统启动后，不需要管理员输入Console口密码，会正常完成所有配置的加载。

a. 启动后，请尽快根据Console口采用的认证方式修改密码。

- Console口采用密码认证方式的情况下，修改Console口认证密码。

进入Console口所在的用户线，设置新的密码（下例中为1234567890!）。同时，建议将用户角色设置为network-admin/level-15，避免Console口登录后用户权限过低。

<Sysname> system-view

[Sysname] line console 0

[Sysname-line-console0] set authentication password simple 1234567890!

[Sysname-line-console0] user-role network-admin

- Console口采用AAA本地认证方式的情况下，修改Console口的本地用户密码。

<Sysname> system-view

[Sysname] local-user admin class manage

[Sysname-luser-manage-admin] password simple 1234567890!

[Sysname-luser-manage-admin] authorization-attribute user-role network-admin

b. 为了防止重启后配置丢失，请执行save命令保存当前配置。

(4) 通过BootWare扩展段菜单跳过当前配置，登录后配置新的Console口密码。

直接回车，进入BootWare扩展段主菜单（不同产品跳过当前配置的菜单选项不同，请以实际情况为准，如下以S7500E系列交换机为例）

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

…

Enter your choice(0-9):

请按照系统提示，键入<6>，回车后并重启后设备后，系统将跳过当前配置。

Enter your choice(0-9): 6

Flag Set Success.

系统启动时，将忽略配置文件中的所有配置以空配置进行启动（该选项每次设置后仅生效一次）。系统启动后，不需要管理员输入Console口密码。

a. 启动后，请尽快将原配置文件导出。在此操作过程中不要对设备进行断电。

- 方式一：通过FTP/TFTP方式将原配置文件导出到本地。

- 方式二：在用户视图下执行more命令查看原配置文件内容，将显示的所有原配置文件内容直接复制粘贴到本地文件中。

b. 手动修改本地配置文件中关于Console口登录的配置，将修改后的配置文件上传至设备存储介质的根目录下。

c. 配置下次启动时的配置文件为修改后的配置文件（假设修改后的配置文件为startup.cfg）。

<Sysname> startup saved-configuration startup.cfg

d. 重启设备。

(5) 通过BootWare扩展段菜单恢复出厂配置，登录后配置新的Console口密码。

此操作下，系统启动时会自动删除下次启动配置文件和备份启动配置文件，再以出厂配置启动。请确保当前业务不会受到影响时执行本操作。

直接回车，进入BootWare扩展段主菜单（不同产品恢复出厂配置的菜单选项不同，请以实际情况为准，如下以S7500E系列交换机为例）

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

…

Enter your choice(0-9):

请按照系统提示，键入<5>，回车后，系统会恢复出厂设置并以空配置启动。不需要管理员输入Console口密码。

a. 启动后，请根据实际需要配置Console口的登录认证方式，以及相关的登录密码或登录账户。

- 认证方式为none

<Sysname> system-view

[Sysname] line console 0

[Sysname-line-console0] authentication-mode none

[Sysname-line-console0] user-role network-admin

该方式下，用户不需要输入用户名和密码，就可以使用该用户线登录设备，存在安全隐患，请谨慎配置。

- 认证方式为密码认证

<Sysname> system-view

[Sysname] line console 0

[Sysname-line-console0] authentication-mode password

[Sysname-line-console0] set authentication password simple 1234567890!

[Sysname-line-console0] user-role network-admin

- 认证方式为本地AAA认证

<Sysname> system-view

[Sysname] line console 0

[Sysname-line-console0] authentication-mode scheme

[Sysname-line-console0] quit

[Sysname] local-user admin class manage

[Sysname-luser-manage-admin] service-type terminal

[Sysname-luser-manage-admin] password simple 1234567890!

[Sysname-luser-manage-admin] authorization-attribute user-role network-admin

- 认证方式为远程AAA认证

<Sysname> system-view

[Sysname] line console 0

[Sysname-line-console0] authentication-mode scheme

[Sysname-line-console0] quit

除此之外，还需要配置Login用户的认证域，以及RADIUS、HWTACACS或LDAP方案。相关配置的详细介绍请参见“安全配置指导”中的“AAA”。

b. 为了防止重启后配置丢失，请执行save命令保存当前配置。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

5.1.2 Telnet登录密码遗忘

1. 故障描述

设备对Telnet登录用户采用Password认证或AAA本地认证的情况下，管理员遗忘Telnet账户密码无法登录设备。

2. 常见原因

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

· 管理员遗忘了Telnet口的登录密码或输入错误的密码。

· Telnet登录账户已过期。

3. 故障分析

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

图36 Telnet登录密码遗忘故障诊断流程图

4. 处理步骤

(1) 确认是否有其它方式可以登录设备。

如果Telnet登录密码丢失，可以通过其他方式（例如Console口）登录设备后重新进行配置。

a. 使用其它方式登录设备，执行display line命令查看VTY口所在用户线的认证方式。

<Sysname> display line

Idx Type Tx/Rx Modem Auth Int Location

+ 0 CON 0 9600 - P - 0/0

81 VTY 0 - P - 0/0

...

以上显示信息中，“Auth”字段取值为P表示采用密码认证方式，取值为A表示采用AAA认证方式。

b. 根据VTY口的认证方式，采用不同的处理步骤重新设置新的登录密码。

- 采用密码认证

设置VTY登录用户的认证方式为密码认证，假设登录密码为1234567890!，用户角色为network-admin。

<Sysname> system-view

[Sysname] line vty 0 63

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

[Sysname-line-vty0-63] set authentication password simple 1234567890!

[Sysname-line-vty0-63] user-role network-admin

- 采用AAA本地认证

设置VTY登录用户的认证方式为AAA认证，假设登录使用的本地账户名为admin，使用的本地密码为1234567890!，用户角色为network-admin。

<Sysname> system-view

[Sysname] line vty 0 63

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

[Sysname-line-vty0-63] quit

[Sysname] local-user admin class manage

[Sysname-luser-manage-admin] service-type telnet

[Sysname-luser-manage-admin] password simple 1234567890!

[Sysname-luser-manage-admin] authorization-attribute user-role network-admin

如果忘记原有登录账户名，可参考以上步骤创建新的本地账户。

- 采用AAA远程认证

该认证方式下，请联系AAA服务器管理员获取登录密码。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

5.1.3 Telnet登录失败

1. 故障描述

设备作为Telnet服务器时，用户通过Telnet客户端登录设备失败。

2. 常见原因

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

· Telnet客户端和设备间网络不畅通。

· Telnet客户端未启用Telnet相关功能。

· 设备未开启Telnet服务。

· VTY用户线下未配置支持Telnet协议。

· 登录用户名、密码不正确。

· 登录设备的用户数达到了上限。

· 设备上配置了对Telnet用户的访问控制，Telnet客户端不在所引用ACL的规则中permit的用户范围之内。

· 认证方式配置不正确。

· 当Telnet客户端和Telnet服务器均为我司设备时，用户未从Telnet客户端上指定的发送Telnet报文的源地址或源接口登录Telnet服务器。

3. 故障分析

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

图37 Telnet登录失败的故障诊断流程图

4. 处理步骤

(1) 检查客户端能否Ping通设备。

用户在Telnet客户端上执行ping命令查看Telnet客户端和设备之间网络连接情况。

如果不能Ping通设备的IP地址，表示Telnet客户端和设备无法建立Telnet连接，则Telnet客户端登录将失败。无法Ping通设备，也可能是终端设备禁Ping导致。请参见“Ping和Tracert故障处理手册”继续定位，确保Telnet客户端与设备之间的网络畅通。

(2) 检查客户端上是否启用Telnet相关功能。

通常，在PC机上新建Telnet连接前，需要在PC上的“打开或关闭Windows功能”中启用“Telnet客户端”功能。

移动端等其他类型的设备作为Telnet客户端时，开启Telnet相关功能的详细介绍和使用方法请参见该设备的使用指导。

(3) 检查设备侧是否开启Telnet服务。

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

(4) 查看VTY用户线支持的协议是否包含Telnet协议。

在VTY用户线或VTY用户线类视图下执行display this命令，

¡ 如果显示配置信息中不包含protocol inbound telnet或protocol inbound all，表示用户线下不支持Telnet协议。

¡ 非FIPS模式下，由于系统默认支持所有协议，如果显示配置信息中包含undo protocol inbound，或者不包含protocol inbound相关配置，表示系统支持所有协议。

若用户线下不支持Telnet协议，请配置protocol inbound telnet或protocol inbound all命令来允许Telnet协议类型的登录用户接入。

<Sysname> system-view

[Sysname] line vty 0 63

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

[Sysname-line-vty0-63] protocol inbound all

需要注意的是，修改protocol inbound的配置将在用户下次使用该用户线登录时生效。

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

当用户向设备发起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故障处理手册”重置密码。

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

从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连接。

(7) 查看设备上是否引用了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用户的访问限制。

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

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

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

¡ 如果使用命令authentication-mode scheme设置认证方式为AAA，则必须确保已经创建了AAA认证用户。具体请参见“AAA&PasswordControl故障处理手册”。

(9) 当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地址。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

5.2 硬件资源管理故障处理

5.2.1 CPU占用率高

1. 故障描述

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

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

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

<Sysname> display cpu-usage summary

Slot CPU Last 5 sec Last 1 min Last 5 min

1 0 5% 5% 4%

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

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

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

· SNMP网管上出现CPU占用率高的相关告警。

2. 常见原因

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

· 网络攻击。

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

· 网络环路。

· 设备上配置了流采样功能，需要处理的流量太大或者设备采样频率太高，导致采样功能占用大量CPU资源。

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

3. 故障分析

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

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

4. 处理步骤

(1) 确认设备是否受到网络攻击。

现网中，导致设备CPU占用率高最常见的原因是网络攻击。攻击者发起大量非正常网络交互对设备产生冲击，例如短时间内发送大量TCP连接建立请求报文或者ICMP请求报文，设备忙于处理这些攻击报文，导致CPU占用率高，从而影响设备正常业务的运行。

¡ 如果受到了网络攻击，则先解决网络攻击问题。

¡ 如果未受到网络攻击，则执行步骤(2)。

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

协议震荡会导致设备不断地处理协议报文、计算拓扑、更新表项，引起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路由问题。

- 如果路由没有震荡，则执行步骤(3)。

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

当以太网接口工作在二层模式并且链路存在环路时，可能出现广播风暴和网络振荡。大量的协议报文上送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命令配置流量控制功能。（broadcast-suppression、multicast-suppression、unicast-suppression和flow-control命令仅部分设备支持，如不支持这些命令请忽略此处理方式）

- 使用QoS策略针对组播、广播和未知单播报文进行限速。

¡ 如未出现环路，请执行步骤(4)或步骤（5）。

(4) 对于支持流统计和采样功能的设备：确认是否配置了流统计和采样功能，以及配置的参数是否合适。

当设备上配置了NetStream、sFlow等网络流量监控功能后，设备会对网络流量进行统计分析。如果网络流量较高，可能会导致CPU占用率偏高。此时，可进行以下处理：

¡ 配置过滤条件来精确匹配流量，仅统计分析用户关心的流量。

¡ 配置采样器，调整采样比例，使得NetStream、sFlow收集到的统计信息既能基本反映整个网络的状况，又能避免统计报文过多影响设备转发性能。

(5) 对于仅支持采样功能的设备：确认是否配置了采样功能，以及配置的参数是否合适。

当设备上配置了sFlow等网络流量监控功能后，设备会对网络流量进行统计分析。如果网络流量较高，可能会导致CPU占用率偏高。此时，可进行以下处理：配置采样器，调整采样比例，使得sFlow收集到的统计信息既能基本反映整个网络的状况，又能避免统计报文过多影响设备转发性能。

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

某些异常情况下，例如，设备受到攻击、运行中发生了错误、端口频繁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

Slot EMERG ALERT CRIT ERROR WARN NOTIF INFO DEBUG

1 0 0 2 9 24 12 128 0

5 0 0 0 41 72 8 2 0

97 0 0 42 11 14 7 40 0

<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命令开启重复日志抑制功能。

如果设备未生成海量日志，则执行步骤(6)。

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

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

# 在设备上执行display process cpu命令查看一段时间内占用CPU最多的任务。下面以slot 1上的操作为例。

<Sysname> display process cpu slot 1

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

JID 5Sec 1Min 5Min Name

1 0.0% 0.0% 0.0% scmd

2 5.5% 5.1% 5.0% [kthreadd]

3 0.0% 0.0% 0.0% [ksoftirqd/0]

...

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

# 在设备上执行monitor process dumbtty命令实时查看进程在指定CPU上的占用率。下面以slot 1 CPU 0为例。

<Sysname> system-view

[Sysname] monitor process dumbtty slot 1 cpu 0

206 processes; 342 threads; 5134 fds

Thread states: 4 running, 338 sleeping, 0 stopped, 0 zombie

CPU0: 99.04% idle, 0.00% user, 0.96% kernel, 0.00% interrupt, 0.00% steal

CPU1: 98.06% idle, 0.00% user, 1.94% kernel, 0.00% interrupt, 0.00% steal

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

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

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

Memory: 7940M total, 5273M available, page size 4K

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

322 322 115 R 0 0K 01:48:03 20.02% [kdrvfwdd2]

323 323 115 R 0 0K 01:48:03 20.02% [kdrvfwdd3]

324 324 115 R 0 0K 01:48:03 20.02% [kdrvfwdd4]

376 376 120 S 22 159288K 00:00:07 0.37% diagd

1 1 120 S 18 30836K 00:00:02 0.18% scmd

379 379 120 S 22 173492K 00:00:11 0.18% devd

2 2 120 S 0 0K 00:00:00 0.00% [kthreadd]

3 3 120 S 0 0K 00:00:02 0.00% [ksoftirqd/0]

…

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

如果display process job命令的显示信息中LAST_CPU字段的取值为控制核的编号（例如0～1），则说明该进程运行在CPU控制核上，则需要进一步定位；如果显示信息中LAST_CPU字段的取值为非控制核的编号，则说明该进程运行在CPU转发核上，无需关注，请执行步骤(7)。下面以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 slot 1 cpu 0

206 processes; 342 threads; 5134 fds

Thread states: 4 running, 338 sleeping, 0 stopped, 0 zombie

CPU0: 98.06% idle, 0.97% user, 0.97% kernel, 0.00% interrupt, 0.00% steal

CPU1: 97.12% idle, 0.96% user, 0.96% kernel, 0.96% interrupt, 0.00% steal

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

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

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

Memory: 7940M total, 5315M available, page size 4K

JID TID LAST_CPU PRI State HH:MM:SS MAX CPU Name

322 322 2 115 R 00:04:21 0 20.15% [kdrvfwdd2]

323 323 3 115 R 00:04:21 0 20.15% [kdrvfwdd3]

324 324 4 115 R 00:04:21 0 20.15% [kdrvfwdd4]

1 1 1 120 S 00:00:02 21 0.19% scmd

376 376 1 120 S 00:00:00 1 0.19% diagd

2 2 0 120 S 00:00:00 0 0.00% [kthreadd]

...

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

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

<Sysname> system-view

[Sysname] probe

[Sysname-probe] follow job 515 slot 1

Attaching to process 515 (pppd)

Iteration 1 of 5

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

Thread LWP 515:

Switches: 3205

User stack:

#0 0x00007fdc2a3aaa8c in epoll_wait+0x14/0x2e

#1 0x0000000000441745 in ppp_EpollSched+0x35/0x5c

#2 0x0000000000000004 in ??

Kernel stack:

[<ffffffff811f0573>] ep_poll+0x2f3/0x370

[<ffffffff811f06c0>] SyS_epoll_wait+0xd0/0xe0

[<ffffffff814aed79>] system_call_fastpath+0x16/0x1b

[<ffffffffffffffff>] 0xffffffffffffffff

Thread LWP 549:

Switches: 20

User stack:

#0 0x00007fdc2a3aaa8c in epoll_wait+0x14/0x2e

#1 0x00000000004435d4 in ppp_misc_EpollSched+0x44/0x6c

Kernel stack:

[<ffffffffffffffff>] 0xffffffffffffffff

...

c. 根据a和b步骤找到任务名称，再根据任务名称找到对应的业务模块，定位并处理业务模块的问题。例如，如果任务snmpd的CPU占用率较高，可能是因为设备受到了SNMP攻击，或者NMS对设备的访问太频繁。需要进一步定位SNMP业务模块的问题；如果任务nqad的CPU占用率较高，可能是因为NQA探测太频繁，需要进一步定位NQA业务模块的问题。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

5.3 软件升级故障处理

5.3.1 设备启动失败

1. 故障描述

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

2. 常见原因

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

· 启动文件所在存储体（SD卡、U盘）接触不良。

· 系统的BootWare版本与加载的软件包版本不匹配。

3. 故障分析

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

图39 设备启动失败故障处理诊断流程图

4. 处理步骤

如下处理步骤以S12500X-AF系列交换机为例，其它交换机的BootWare菜单可能存在差异，请以实际情况为准。

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

Booting Normal Extended BootWare

The Extended BootWare is self-decompressing.............Done.

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

* *

* BootWare, Version 1.39 *

* *

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

(2) 在出现“Press Ctrl+B to access EXTENDED-BOOTWARE MENU…”的3秒钟之内，键入<Ctrl+B>，系统将进入BootWare扩展段主菜单。在BootWare扩展段主菜单中，键入<4>，进入文件控制子菜单。

==========================<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): 4

(3) 在BootWare界面上输入4，进入文件控制子菜单。以设备的存储介质为SD卡情况为例，判断启动文件所在存储介质是否正常：：

¡ 如果在文件控制子菜单能看到“Note:the operating device is sda0”，且输入1后能看到SD卡内的文件信息，则说明不存在启动文件所在存储体接触不良的情况，请执行第(4)步。

¡ 如果在文件控制子菜单不能看到“Note:the operating device is sda0”，且输入1后不能看到SD卡内的文件信息，则说明存在启动文件所在存储体接触不良的情况，请在H3C技术支持工程师的指导下，排查存储介质故障问题。

===============================<File CONTROL>===============================

|Note:the operating device is sda0 |

|<1> Display All File(s) |

|<2> Set Image File type |

|<3> Set Bin File type |

|<4> Delete File |

|<0> Exit To Main Menu |

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

Enter your choice(0-4): 1

Display all file(s) in sda0:

'M' = MAIN 'B' = BACKUP 'N/A' = NOT ASSIGNED

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

|NO. Size(B) Time Type Name |

|1 539432 Nov/18/2021 21:11:56 N/A sda0:/info/info_3_0.bin |

|2 539432 Nov/18/2021 21:15:00 N/A sda0:/info/info_3_1.bin |

|3 539432 Aug/28/2021 19:05:42 N/A sda0:/info/info_2_0.bin |

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

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

¡ 如果系统的BootWare版本是最新版本，请执行第(10)步。

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

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

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

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

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

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

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

(8) 键入<4>，设置以太网口参数。然后执行第(9)步。

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

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

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

¡ 如果设备没有正常启动，请执行第(10)步。

(10) 请收集如下信息，并联系H3C技术支持工程师。

¡ 上述步骤的执行结果。

5. 告警与日志

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

1. 故障描述

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

2. 常见原因

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

3. 处理步骤

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

<Sysname> md5sum cfa0:/Comware-cmw710.ipe

MD5 digest:

f2054bc35cd13bf84038bd10fc7a3efd

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

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

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

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

(4) 请收集如下信息，并联系H3C技术支持工程师。

¡ 上述步骤的执行结果。

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

4. 告警与日志

6 虚拟化技术类故障处理

6.1 IRF故障处理

6.1.1 IRF组建失败

1. 故障描述

多台设备无法组建IRF，或者新设备无法加入现有的IRF。

2. 常见原因

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

· IRF成员设备数量超出了产品支持的规格，导致新设备无法加入现有的IRF。

· 配置不符合IRF要求，导致无法组建IRF，或者新设备无法加入现有的IRF。

· IRF物理端口、线缆和物理拓扑不符合IRF要求，导致IRF链路无法达到up状态。

3. 故障分析

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

图40 IRF组建失败故障诊断流程图

4. 处理步骤

本文仅列出组建IRF的常规要求，以供参考。组建IRF的完整要求请参见产品配套的《IRF配置指导》。

(1) 检查IRF成员数量是否已达到系统支持的最大值。

请使用display irf命令查看当前IRF中的成员设备数量。如果IRF成员数量已经达到系统支持的最大值，则不允许再加入成员设备。

同一IRF域内，不同型号的产品支持的IRF成员最大数量不同，请以设备的实际情况为准。

(2) 检查各成员设备使用的软件版本是否一致。

使用display version命令查看每台设备当前运行的软件版本，只有使用相同软件版本的设备才能组成IRF。

IRF系统启动文件自动加载功能（缺省为开启状态）可以自动将成员设备的软件版本与IRF中主设备进行同步，但是在成员设备与主设备的软件版本差异过大时，自动升级可能无法成功执行。此时，需要分别升级每台成员设备，使得所有成员设备的软件版本一致，之后再组建IRF。

如果成员设备使用双主控，请同时升级两块主控板，保证所有成员设备的所有主控板上运行的软件版本相同。

(3) 检查IRF的配置是否满足相关要求。

a. 确保设备运行在IRF模式。

部分产品出厂即为IRF模式，且不支持模式切换；部分产品出厂为独立运行模式，支持模式切换。如果设备当前支持display irf link或者display irf topology命令，则说明设备运行在IRF模式。否则，设备运行在独立运行模式，需要先在系统视图执行chassis convert mode irf命令将设备切换到IRF模式。

<Sysname> display irf ?

> Redirect it to a file

>> Redirect it to a file in append mode

configuration IRF configuration that will be valid after reboot

link Display link status

topology Topology information

| Matching output

<cr>

不支持模式切换的设备，请忽略此步骤。

b. 确保设备的成员编号在IRF中唯一。

请使用display irf命令查看IRF中各成员设备的成员编号。IRF中各成员设备必须使用不同的编号，编号相同的设备不能建立或加入IRF。设备缺省成员编号为1，在独立运行模式下可通过irf member命令修改，在IRF模式下可通过irf member renumber命令修改（不支持模式切换的产品，可通过irf member renumber命令修改成员编号）。修改后需要保存配置并重启该设备，新编号才能生效。

c. 确保各成员设备的出厂桥MAC地址不同

具有相同出厂桥MAC的成员设备之间不能组成IRF。通常情况下，设备出厂会携带全网唯一的桥MAC地址。如果IRF组建失败，且输出了日志信息“Failed to stack because of the same bridge MAC addresses.”，则表明两台设备的出厂桥MAC相同，可在其中一台设备上执行irf mac-address命令修改桥MAC。（不支持irf mac-address命令的设备，请忽略此步骤）

d. 确保同一IRF系统中所有成员设备的IRF域编号一致。

IRF域编号不影响IRF的组建和合并，但是会影响MAD检测。为了使MAD功能正常工作，请确保同一IRF系统中所有成员设备的IRF域编号一致。IRF域编号缺省值为0。在单台设备上执行display irf命令，可通过显示信息中的Domain ID字段查看IRF域编号。如果设备的IRF域编号和其它设备不同，可在该设备上执行irf domain命令修改。

(4) 检查IRF端口的状态，使其变成UP状态。

IRF端口是一种专用于IRF连接的逻辑接口，需要与物理端口绑定后才能生效。请通过display irf topology命令显示信息的Link字段来确认IRF端口的状态。

<Sysname> display irf topology

Topology Info

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

IRF-Port1 IRF-Port2

MemberID Link neighbor Link neighbor Belong To

2 DIS --- UP 1 5e40-08d9-0104

1 UP 2 DIS --- 5e40-08d9-0104

¡ 如果Link字段取值为UP，则表示IRF端口连接正常，无需处理。

¡ 如果Link字段取值为DIS，则表示该IRF端口还没有和任何IRF物理端口绑定。请根据组网需要在IRF端口视图下使用port group interface命令进行绑定。

¡ 如果Link字段取值为DOWN，请使用display irf link命令进一步检查IRF物理端口的状态是否为UP。

- 如果IRF物理端口的状态为UP，但IRF端口的状态为DOWN，原因可能是IRF端口的配置未激活。请在系统视图下执行irf-port-configuration active命令激活IRF端口。

- 如果IRF物理端口的状态不是UP，请参照步骤(5)定位IRF物理端口的问题。

¡ 如果Link字段取值为TIMEOUT，表明IRF Hello报文超时，IRF链路通信存在问题。可参照以下步骤先定位IRF报文超时问题。

- 确认是否因为对端IRF端口状态异常，导致IRF报文无法互通：登录IRF链路的对端设备，在对端设备上执行display irf topology和display irf link，根据显示的状态信息进行定位。

- 确认是否存在网络环路，导致IRF报文丢包：使用display counters rate inbound interface命令查看IRF物理端口的报文速率统计信息，确认IRF链路上是否存在报文风暴。如果存在报文风暴，请检查是否存在物理环路以及VLAN和STP配置是否正确等，先解决报文风暴问题。

- 使用display device命令检查网板状态是否正常。如果不正常，请先定位网板问题。

¡ 如果Link字段取值为ISOLATE，表明该成员设备处于隔离状态。执行display logbuffer | include “STM stackability check”，并根据显示结果处理：

- 如果显示信息中包含“STM stackability check: Product series is inconsistency”字样，则说明成员设备的型号不符合IRF要求，请参考步骤(7)处理。

- 如果显示信息中包含“STM stackability check: Product xxx is inconsistency”字样，xxx取值可能为system working mode等，则说明当前系统参数配置不符合IRF要求，请参考步骤(8)处理。

(5) 检查IRF物理端口的状态，使其变成UP状态。

请通过display irf link命令查看IRF物理端口的状态。如果显示信息中：

¡ Interface字段取值为disable，表示该IRF端口还没有和IRF物理端口绑定。

¡ Interface字段为物理接口的名称，请继续检查Status字段。Status字段的取值及含义如下：

- UP：链路up，无需处理

- DOWN：链路down，请检查IRF物理端口的光模块/光纤或者电缆是否工作正常。请使用符合产品要求的物理接口作为IRF物理端口，使用符合产品要求的线缆来连接IRF物理端口，并执行步骤(6)。

- ADM：表示该接口通过shutdown命令被关闭，即管理状态为关闭。您需要执行undo shutdown命令将其开启。

- ABSENT：接口不存在。请插入单板或接口模块扩展卡。

(6) 检查IRF物理连线是否符合要求。

可通过以下步骤来定位IRF物理连接问题：

a. 在每台成员设备上通过display irf configuration命令查看IRF端口与IRF物理端口的绑定关系。检查绑定的物理接口和实际连接的物理接口是否一致，如果不一致，请重新配置绑定关系或重新进行物理连接。

b. 检查IRF物理端口的连接状况，是否满足相邻设备的连接要求。连接两台相邻的成员设备时，一台设备上IRF-Port1绑定的IRF物理端口只能和邻居成员设备IRF-Port2绑定的IRF物理端口相连。且当两台成员设备组建IRF时，只能使用链型拓扑，不允许使用环形拓扑。

(7) 检查成员设备的硬件是否符合IRF的要求。

请使用符合产品要求的硬件组建IRF，例如设备型号、主控板、接口板、IRF物理接口的类型必须符合要求。可以通过如下方式查看当前设备的型号、主控板型号等，以判断设备硬件是否符合IRF要求。例如：S10500X-G系列交换机仅支持同一型号的交换机之间建立IRF且IRF中所有成员设备的主控板型号必须相同。

# 使用display version命令查看设备型号。

<Sysname> display version

H3C Comware Software, Version 7.1.070, ESS 7752P01

H3C S10506X-G uptime is 0 weeks, 0 days, 18 hours, 11 minutes

Last reboot reason : USER reboot

…

# 使用display device命令查看主控板的型号。

<Sysname> display device

Slot Type State Subslot Soft Ver Patch Ver

1/0 LSEM1SUPA0 Master 0 S10500XG-7752P01 None

1/1 NONE Absent 0 NONE None

1/2 NONE Absent 0 NONE None

1/3 LSEM1GT48TSSD0 Normal 0 S10500XG-7752P01 None

1/4 NONE Absent 0 NONE None

1/5 NONE Absent 0 NONE None

1/6 NONE Absent 0 NONE None

1/7 NONE Absent 0 NONE None

1/8 LSEM1SF06D0 Normal 0 S10500XG-7752P01 None

1/9 NONE Absent 0 NONE None

1/10 NONE Absent 0 NONE None

1/11 NONE Absent 0 NONE None

…

(8) 检查系统参数配置是否满足IRF的要求。

通常组成IRF的设备上要求某些系统参数或软件特性配置相同，例如：

¡ 在组成IRF的所有设备上，系统工作模式的配置（通过system-working-mode命令配置）必须相同，否则这些设备将无法组成IRF。

¡ 在组成IRF的所有设备上，硬件资源模式的配置（通过hardware-resource switch-mode命令配置）必须相同，否则这些设备将无法组成IRF。

¡ 请确保两个IRF上都配置或都取消IRF增强功能，否则，它们不能合并为一个IRF。

¡ 同时配置MDC和IRF MAD检测功能的情况下，请将IRF物理端口和MAD检测VLAN都配置在缺省MDC中，并请先为MDC分配物理接口再配置MAD功能。

¡ 在IRF分裂后，以及再次合并前，请确保各成员设备上MDC的相关配置以及IRF的相关配置和分裂前的保持一致。

¡ 使用undo mdc命令删除MDC时，建议先使用display irf link命令查看该MDC中是否有IRF物理端口，如果该MDC中有IRF物理端口，请先取消IRF物理端口与IRF端口的绑定关系并保存配置后再删除MDC。

¡ 在组成IRF的所有设备上，以下路由相关配置必须相同，否则这些设备将无法组成IRF。

- 最大等价路由条数（通过max-ecmp-num命令配置）。

- 等价路由模式（通过ecmp mode命令配置）。

- 前缀大于64位的IPv6路由功能（通过hardware-resource routing-mode ipv6-128命令配置）。

¡ 在组成IRF的所有设备上，ACL硬件模式的相关配置都必须相同，否则这些设备将无法组成IRF。

¡ 在组成IRF的所有设备上，VXLAN硬件资源模式的配置（通过hardware-resource vxlan命令配置）必须相同，否则这些设备将无法组成IRF。

以上仅例举典型产品的情况，不同产品的具体要求不同，请以设备的实际情况为准，具体可参见产品配套的配置指导。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

6.1.2 IRF成员设备异常重启

1. 故障描述

堆叠过程中发生了主设备或者备设备异常重启，导致堆叠分裂。

2. 常见原因

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

· 从设备自动重启来完成软件版本的升级。

· IRF合并，导致从设备重启。

· 设备软件或者硬件故障，导致设备异常重启，来尝试修复故障。

3. 故障分析

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

图41 IRF成员设备异常重启故障诊断流程图

4. 处理步骤

(1) 检查重启的设备是否为从设备。

¡ 如果是从设备，请执行步骤(2)。

¡ 如果不是从设备，是主设备，请执行步骤(4)。

(2) 检查从设备是否因为自动加载启动文件，升级导致的重启。

¡ 如果从设备是因为自动加载启动文件，升级导致的重启，则该重启为正常重启，无需处理。

¡ 如果从设备不是因为自动加载启动文件，升级导致的重启，请继续执行步骤(3)。

您可通过以下方式确认从设备的重启原因：IRF要求所有成员设备上运行的软件版本必须一致。当IRF开启了启动文件的自动加载功能，且有新设备加入IRF时，如果新设备的软件版本和主设备的软件版本不一致，则新设备会自动从主设备下载启动文件，然后使用新的启动文件重启并以从设备角色加入IRF。在Probe视图下，执行display system internal irf msg命令，如果显示信息中有“Version is different, and the sender CPU MAC is xxxx-xxxx-xxxx (chassis xx slot xx).”类似信息，表示CPU MAC为xxxx-xxxx-xxxx的从设备是因为自动加载启动文件，升级导致的重启。

(3) 检查是否因为IRF合并导致的从设备重启。

¡ 如果从设备重启原因为IRF合并，请追查IRF分裂、合并的原因，并排除安全隐患，以免再次因为同样的原因导致IRF分裂、合并。

¡ 如果从设备重启原因不是IRF合并，请继续执行步骤(4)。

您可通过以下方式确认从设备的重启原因是否为IRF合并：

¡ 设备重启后，在IRF中执行display kernel reboot命令查看设备的重启原因。如果Reason字段取值为0x7，则表示从设备重启原因为IRF合并，Slot表示触发重启事件的Slot的编号，Target Slot表示实际发生重启的Slot的编号。

<Sysname> display kernel reboot 1

--------------------- Reboot record 1 ---------------------

Recorded at : 2021-12-06 00:10:05.440616

Occurred at : 2021-12-06 00:10:05.440616

Reason : 0x7

Thread : STM_Main (TID: 232)

Context : thread context

Slot : 1

Target Slot : 2

Cpu : 0

VCPU ID : 2

Kernel module info : module name (system) module address (0xffffffffc0074000)

module name (addon) module address (0xffffffffc0008000)

¡ 在IRF的Probe视图下执行display system internal irf msg | include reboot命令，如果可以看到主设备发送了重启报文，则表示从设备重启原因为IRF合并。

19> Send reboot pkt, src_addr 5e40-08d9-0104 (chassis 1 slot 1), at 2022/1/5 15:42:48:386

(4) 检查是否有软件和硬件故障导致成员设备异常重启。

通过display version命令，可以查看成员设备/单板上次重启的原因，根据重启原因，以及表3所示的建议操作进行处理。

<Sysname> display version

…

Reboot Cause : ColdReboot

[SubSlot 0] 24GE+4SFP Plus+POE

表3 设备重启原因以及建议操作

Reboot Cause字段的取值	重启原因说明	建议操作
AutoUpdateReboot	自动更新版本后重启	正常，无需处理
BootwareBackupReboot	Bootware备份区重启	请收集日志、诊断日志，联系技术支持人员处理
ColdReboot	设备掉电	检查设备的供电环境，确保供电正常
CryptographicModuleSelftestsFailedReboot	算法库自检失败	请及时升级软件版本
CryptotestFailReboot	加密算法库自检失败	请及时升级软件版本
DeadLoopReboot	软件检测到死循环	请收集日志、诊断日志和重启slot的display kernel deadloop 20 verbose的显示信息，联系技术支持人员处理
DEVHandShakeReboot	主控板与所有接口板之间握手报文超时	使用display device命令查看主控板状态是否为Normal，如果不是Normal，表示主控板可能故障，请先解决主控板的问题
GoldMonReboot	GOLD（Generic OnLine Diagnostics，通用在线诊断）检测到异常	可通过以下操作确认重启原因： · display diagnostic content命令，通过Correct-action字段可看到GOLD检测到异常时的纠错动作是重启，测试发生的时间以及测试发现的问题 · display diagnostic event-log命令查看测试的详细执行信息根据以上显示信息找到具体的重启原因，并进行定位
IRFMergeReboot	IRF合并	IRF链路故障会导致IRF分裂，IRF链路恢复后，IRF会自动合并。请追查故障的IRF链路，并排除安全隐患，以免再次因为同样的原因导致IRF分裂、合并
KernelAbnormalReboot	CPU、主机内存或软件问题导致系统内核错误	请收集日志、诊断日志和诊断命令display kernel exception 10 verbose、display kernel reboot 20 verbose的信息，联系技术支持人员处理
KeyReboot	触碰了<RESET>键	避免误操作
LicenseTimeoutReboot	License过期	请及时安装正式版本的License
MasterLostReboot	在本板批量备份时，主用主控板重启	请收集日志、诊断日志，联系技术支持人员处理
MemoryexhaustReboot	内存消耗，低于门限值	ACL表项太多等原因会导致内存占用率高，确认内存占用率高的原因，解决内存占用率高故障
PdtReboot	产品驱动要求的重启	请收集日志、诊断日志，联系技术支持人员处理
SelfReboot	业务板本板复位	请收集日志、诊断日志，联系技术支持人员处理
StandbyCannotUpdateReboot	备用主控板不能升级为主用主控板，重启	请收集日志、诊断日志，联系技术支持人员处理
StandbySwitchReboot	主备倒换重启原主用主控板	系统软件升级等原因会导致主备倒换，确认系统主备倒换的原因，避免再次发生非预期的主备倒换
UserReboot	通过命令行、网管或Web页面等方式主动重启设备	正常，无需处理
WarmReboot	原因可能有多种，例如单板虚插针脚接触不良导致单板重启等	请收集日志、诊断日志，联系技术支持人员处理
WatchDogReboot	CPU、内存、软件或其它硬件故障，导致看门狗监测到系统异常，重启设备	根据display hardware-failure-detection命令显示的故障修复信息定位故障原因，消除安全隐患

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

¡ 假设slot 16为主用主控板，以备用主控板slot 17重启为例，请收集以下命令的显示信息。

- 请在任意视图下执行以下命令：

display version

display device

display diagnostic-information

display kernel deadloop 20 verbose slot 16

display kernel exception 10 verbose slot 16

display kernel reboot 20 verbose slot 16

- 请在Probe视图下执行以下命令来收集信息：

local logbuffer slot 17 display

local logbuffer slot 17 display from-highmemory

display reboot last-time slot 17

display system internal version

display diag-msg start-msg slot 17

以上命令的支持情况与设备的型号以及版本有关请以设备的实际情况为准。

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

5. 告警与日志

6.1.3 IRF分裂后BFD MAD无法生效

1. 故障描述

IRF分裂后，BFD MAD功能未生效，导致网络中存在配置相同的两台设备。

2. 常见原因

· 未配置BFD MAD检测链路。

· 用于BFD MAD检测的端口和VLAN配置不正确。

· 用于BFD MAD检测的IP地址不在同一网段。

· IRF链路down延迟上报时间配置过长。

3. 故障分析

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

图42 故障诊断流程图

4. 处理步骤

(1) 检查BFD MAD组网是否正确。

使用BFD MAD功能时，要求所有成员设备之间必须有一条BFD MAD检测链路，可以通过中间设备，也可以在成员设备之间使用全连接的组网。

(2) 检查BFD MAD所使用的物理端口状态。

您可以通过display interface命令查看BFD MAD所使用的物理端口的状态。

a. 如果物理端口状态为“DOWN ( Administratively )”，则表示该端口已经通过shutdown命令关闭，您需要执行undo shutdown命令将其开启。

b. 如果物理端口的状态为“DOWN”，您需要检查物理端口的连接是否正常。

(3) 检查BFD MAD所使用的VLAN和端口配置。

用于BFD MAD检测的物理端口上不能开启生成树协议，也不能开启其它任何功能。一个IRF内所有BFD MAD链路上的物理端口必须属于同一个VLAN，该VLAN为BFD MAD专用，如果使用中间设备的话，中间设备与成员设备相连的端口也必须加入该VLAN。建议用于BFD MAD检测的VLAN中只包含BFD MAD链路上的端口，不要将其它端口加入该VLAN。

(4) 检查BFD MAD所使用的VLAN接口。

使用display mad verbose命令查看用于BFD MAD检测的VLAN接口，该接口不能为VLAN1接口，并且该接口仅用于BFD MAD，即在该接口上不能配置其它任何二层或三层协议。

(5) 检查BFD MAD IP地址的配置。

使用display mad verbose命令查看用于BFD MAD检测的IP地址，各成员设备的MAD IP地址必须属于同一网段，同时不能为设备上已经存在的IP地址。通过display inteface查看用于BFD MAD的VLAN接口配置，该接口上不能配置其它IP地址（包括使用ip address命令配置的普通IP地址、VRRP虚拟IP地址等）。

(6) 当组网中存在多个IRF时，检查各IRF的BFD MAD VLAN。

如果网络中存在多个IRF，在配置BFD MAD时，请为每个IRF配置不同的VLAN用于BFD MAD检测。

(7) 检查IRF链路down延迟上报时间是否配置过长。

在IRF环境中使用RRPP、BFD或GR功能时，建议将IRF链路down延迟上报时间配置为0。

(8) 检查成员设备的日志信息。

请使用display trapbuffer命令或者通过查看日志主机存储的信息，查找在IRF分裂的时间点附近是否存在BFD MAD所使用物理端口down的日志。通过该日志判断端口故障的原因，并排除该故障。

(9) 收集信息并寻求技术支持。

如果完成上述检查后故障仍无法排除，请收集设备的运行信息，并联系H3C的技术支持工程师。

5. 告警与日志

6.1.4 IRF分裂后LACP MAD无法生效

1. 故障描述

IRF分裂后，LACP MAD功能未生效，导致网络中存在配置相同的两台设备。

2. 常见原因

· 中间设备不支持扩展LACP选项。

· 用于LACP MAD检测的聚合组不是动态聚合组。

· 端口或聚合组状态异常。

3. 故障分析

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

图43 故障诊断流程图

4. 处理步骤

(1) 检查LACP MAD组网是否正确。

使用LACP MAD功能时，要求必须使用一台中间设备，所有成员设备与中间设备之间必须均存在物理连接。

(2) 检查聚合组和物理端口的状态。

您可以通过display interface命令查看LACP MAD所使用的聚合组和物理端口的状态。

a. 如果物理端口状态为“DOWN ( Administratively )”，则表示该聚合组或物理端口已经通过shutdown命令关闭，您需要执行undo shutdown命令将其开启。

b. 如果聚合端口的状态为“DOWN”，则表示该聚合组内所有物理端口连接均有问题；如果物理端口的状态为“DOWN”，则表示该端口的物理连接存在问题。请检查物理连接并修复故障。

(3) 检查中间设备是否支持扩展LACP选项。

由于LACP MAD使用扩展LACP选项实现，因此中间设备必须为能够识别并透传带有扩展LACP选项的LACP报文的H3C设备。

(4) 检查聚合组的聚合方式。

LACP MAD功能通过LACP报文实现，因此仅有动态聚合组能够用于LACP MAD检测。您可以在聚合接口视图下使用link-aggregation mode dynamic命令将聚合组的工作模式配置为动态聚合。

(5) 当组网中存在多个IRF时，检查各IRF的域编号。

扩展LACP选项中会包含IRF的域编号，当组网中存在多个IRF时，如果各IRF的域编号相同，则LACP MAD检测功能将不能正常检测到IRF分裂。请确保组网中的每个IRF使用不同的域编号，您可以通过irf domain命令配置IRF的域编号。

(6) 检查成员设备的日志信息。

请使用display trapbuffer命令或者通过查看日志主机存储的信息，查找在IRF分裂的时间点附近是否存在LACP MAD所使用物理端口或聚合组down的日志。通过该日志判断端口故障的原因，并排除该故障。

(7) 收集信息并寻求技术支持。

如果完成上述检查后故障仍无法排除，请收集设备的运行信息，并联系H3C的技术支持工程师。

5. 告警与日志

6.2 MDC故障处理

6.2.1 Location业务板失败故障

1. 故障描述

MDC视图下location业务板，系统提示硬件资源不足或location失败的提示信息。

2. 常见原因

· 分配给MDC的资源不足。

· 业务板已属于其他MDC。

· 业务板上存在IRF物理端口。

3. 故障分析

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

图44 故障诊断流程图

4. 处理步骤

(1) 检查系统硬件资源信息。

通过display mdc resource命令行查看缺省MDC以及非缺省MDC的可用内存大小，CPU可用值以及Disk的可用大小，如果分配过小，可能会导致location业务板失败。

<H3C>dis mdc resource

Memory usage:

Slot 0 CPU 0:

Used 788.4MB, Free 15164.2MB, Total 15952.6MB

ID Name Quota(MB) Used(MB) Available(MB)

1 Admin 15952.6 788.4 15164.2

Slot 14 CPU 0:

Used 143.0MB, Free 7757.7MB, Total 7900.6MB

ID Name Quota(MB) Used(MB) Available(MB)

1 Admin 7900.6 143.0 7757.7

CPU usage:

Slot 0 CPU 0:

ID Name Weight Usage(%)

1 Admin 10 0

Slot 14 CPU 0:

ID Name Weight Usage(%)

1 Admin 10 10

重新分配资源后，若故障仍未排除，请执行步骤2。

(2) 检查业务板是否已分配给其他MDC。

部分机型一块业务板仅可分配给一个MDC，对于此类机型，需要检查当前业务板是否已属于其他MDC。可通过display current-configuration configuration mdc命令查看当前业务板的所属MDC。

[Sysname] display current-configuration configuration mdc

mdc Admin id 1

mdc mdcA id 2

location chassis 3 slot 3

mdc start

Return

上述显示信息表示所有业务板均属于缺省MDC且3号成员设备的3号槽位业务板属于mdcA。

在为其他非缺省MDC分配业务板时，需使用undo location命令取消已有MDC对该业务板的使用权限。重新配置后若故障仍未排除，请执行步骤3。

(3) 检查业务板上是否存在IRF物理端口。

部分机型支持IRF+MDC搭配使用，在IRF模式下undo location业务板时，业务板上不能存在IRF物理端口，否则会出现如下告警信息：

[Syaname-mdc-1-admin]undo location chassis 1 slot 0

Performing this command is equivalent to removing the card from the MDC. Continue? [Y/N]:y

Operation denied by IRF.

此时可先切换为IRF独立模式后再重新配置，或者undo location其他没有IRF物理端口的业务板。执行本步骤后若故障仍未排除，请执行步骤4。

(4) 收集信息并寻求技术支持。

若完成上述步骤后故障仍无法排除，请收集设备的运行信息，并联系H3C的技术支持工程师。

5. 告警与日志

6.2.2 Allocate接口失败故障

1. 故障描述

创建MDC后，执行allocate接口操作，无法在该MDC下找到预分配接口或提示失败。

2. 常见原因

· 待分配接口已属于其他MDC。

· 未按接口分组整组分配或删除。

3. 故障分析

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

图45 故障诊断流程图

4. 处理步骤

下面以一个举例来展示故障处理步骤，涉及的端口号请以实际组网需求为准。

假如需要将接口Ten-GigabitEthernet 1/3/0/1～Ten-GigabitEthernet 1/3/0/48分配给mdcB。但现在这些接口位于mdcA中。分配步骤如下：

(1) 使用display mdc interface命令查看待分配物理接口是否已被分配给其他非缺省MDC。

[Sysname] display mdc interface

MDC Admin's interface(s):

M-GigabitEthernet1/0/0/0

MDC mdcA's interface(s):

M-GigabitEthernet1/0/0/0 Ten-GigabitEthernet1/3/0/1

Ten-GigabitEthernet1/3/0/2 Ten-GigabitEthernet1/3/0/3

Ten-GigabitEthernet1/3/0/4 Ten-GigabitEthernet1/3/0/5

Ten-GigabitEthernet1/3/0/6 Ten-GigabitEthernet1/3/0/7

Ten-GigabitEthernet1/3/0/8 Ten-GigabitEthernet1/3/0/9

Ten-GigabitEthernet1/3/0/10 Ten-GigabitEthernet1/3/0/11

Ten-GigabitEthernet1/3/0/12 Ten-GigabitEthernet1/3/0/13

Ten-GigabitEthernet1/3/0/14 Ten-GigabitEthernet1/3/0/15

Ten-GigabitEthernet1/3/0/16 Ten-GigabitEthernet1/3/0/17

Ten-GigabitEthernet1/3/0/18 Ten-GigabitEthernet1/3/0/19

Ten-GigabitEthernet1/3/0/20 Ten-GigabitEthernet1/3/0/21

Ten-GigabitEthernet1/3/0/22 Ten-GigabitEthernet1/3/0/23

Ten-GigabitEthernet1/3/0/24 Ten-GigabitEthernet1/3/0/25

Ten-GigabitEthernet1/3/0/26 Ten-GigabitEthernet1/3/0/27

Ten-GigabitEthernet1/3/0/28 Ten-GigabitEthernet1/3/0/29

Ten-GigabitEthernet1/3/0/30 Ten-GigabitEthernet1/3/0/31

Ten-GigabitEthernet1/3/0/32 Ten-GigabitEthernet1/3/0/33

Ten-GigabitEthernet1/3/0/34 Ten-GigabitEthernet1/3/0/35

Ten-GigabitEthernet1/3/0/36 Ten-GigabitEthernet1/3/0/37

Ten-GigabitEthernet1/3/0/38 Ten-GigabitEthernet1/3/0/39

Ten-GigabitEthernet1/3/0/40 Ten-GigabitEthernet1/3/0/41

Ten-GigabitEthernet1/3/0/42 Ten-GigabitEthernet1/3/0/43

Ten-GigabitEthernet1/3/0/44 Ten-GigabitEthernet1/3/0/45

Ten-GigabitEthernet1/3/0/46 Ten-GigabitEthernet1/3/0/47

Ten-GigabitEthernet1/3/0/48

MDC mdcB's interface(s):

M-GigabitEthernet1/0/0/0

上述显示信息表示，接口Ten-GigabitEthernet 1/3/0/1～Ten-GigabitEthernet 1/3/0/48位于mdcA中。

(2) 使用display this命令查看mdcA下的配置。

[Sysname-mdc-2-mdcA] display this

mdc mdcA id 2

location chassis 1 slot 3

mdc start

allocate interface Ten-GigabitEthernet1/3/0/1 to Ten-GigabitEthernet1/3/0/48

return

上述显示信息表示，mdcA下分配了1号成员设备的3号槽位业务板。

(3) 将此业务板和接口从mdcA中删除。

[Sysname-mdc-2-mdcA] undo location chassis 1 slot 3

The configuration associated with the specified slot of MDC will be lost. Continue? [Y/N] :y

[Sysname-mdc-2-mdcA] undo allocate interface Ten-GigabitEthernet 1/3/0/1 to Ten-GigabitEthernet 1/3/0/48

Configuration of the interfaces will be lost. Continue? [Y/N] :y

(4) 为mdcB分配此业务板和物理接口。

[Sysname]mdc mdcB

[Sysname-mdc-3-mdcB] allocate interface Ten-GigabitEthernet 1/3/0/1 to Ten-GigabitEthernet 1/3/0/48

Configuration of the interfaces will be lost. Continue? [Y/N] :y

[Sysname-mdc-3-mdcB] quit

[Sysname-mdc-3-mdcB] location chassis 1 slot 3

(5) 若分配接口时提示失败，请按组划分接口。

同一业务板上的接口需要按组分配给不同的MDC，并且需要将该业务板也分配给这些MDC（需要注意的是，部分设备一块业务板仅能分配给一个MDC，即此类设备同一业务板上的接口只能属于一个MDC）。

不同型号业务板的分组规律不同，具体分组信息请参考配置手册或设备的提示信息。

若按组分配接口时仍提示失败，请执行步骤6。

(6) 收集信息并寻求技术支持。

若完成上述步骤后故障仍无法排除，请通收集设备的运行信息，并联系H3C的技术支持工程师。

5. 告警与日志

7 接口类故障处理

7.1 隧道接口故障处理

7.1.1 隧道接口工作不稳定

1. 故障描述

点对点类隧道（包括GRE、IPv4和IPv6隧道）配置完成后，Tunnel接口状态为up，且本端隧道接口IP地址可以Ping通对端隧道接口IP地址。但隧道接口工作状态不稳定，包括：

· 隧道接口震荡，反复的up/down。

· 隧道报文丢包率高，传输速率低。

本章节以GRE over IPv4隧道为例进行介绍。

2. 常见原因

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

· 到达隧道目的地址的路由震荡，导致隧道也发生震荡。

· 设备上配置了隧道A的源目的地址和隧道B的源目的地址相同，导致其中只有一条隧道可以up。

· GRE隧道接口下使能了保活探测报文功能，但设备无法正常收发GRE keepalive报文，导致设备将隧道置为down。

· 设备资源不足，隧道下发硬件处理失败，导致隧道在物理层down。

· 隧道口下的配置不合理，导致隧道报文丢包。

3. 故障分析

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

图46 隧道接口不稳定故障诊断流程图

4. 处理步骤

(1) 检查路由是否发生震荡。

通过debugging tunnel event命令打开隧道事件调试开关，如果持续出现路由刷新或删除消息，说明路由出现震荡，此时隧道也会震荡。示例如下：

<Sysname> debugging tunnel event

<Sysname> %Jun 16 12:49:55:497 2022 Sysname BGP/5/BGP_STATE_CHANGED: -MDC=1; BGP.: 4.4.4.4 state has changed from ESTABLISHED to IDLE for TCP_Connection_Failed event received.

// BGP邻居的IP地址为4.4.4.4，收到TCP连接失败事件，BGP会话状态从Established转换为Idle

%Jun 16 12:49:55:497 2022 Sysname BGP/5/BGP_STATE_CHANGED_REASON: -MDC=1; BGP.: 4.4.4.4 state has changed from ESTABLISHED to IDLE. (Reason: TCP connection failed(No route to host))

// BGP邻居的IP地址为4.4.4.4，BGP会话状态从Established转换为Idle，原因是TCP连接失败（没有到达主机的路由）

如果存在路由震荡，则需要根据路由刷新或删除消息进一步排查设备路由震荡原因。例如，本例中BGP会话无法稳定进入Established状态，可以参考BGP故障处理手册进行定位。

如果不存在路由震荡，请继续执行步骤(2)排查故障。

(2) 检查是否存在同源同目的隧道。

分别在两端设备的任意视图下执行display interface tunnel命令，查看是否存在隧道A的源目的地址和隧道B的源目的地址相同的情况。

<Sysname> display interface Tunnel

Tunnel0

Current state: UP

Line protocol state: UP

Description: Tunnel0 Interface

Bandwidth: 64 kbps

Maximum transmission unit: 1464

Internet protocol processing: Disabled

Output queue - Urgent queuing: Size/Length/Discards 0/100/0

Output queue - Protocol queuing: Size/Length/Discards 0/500/0

Output queue - FIFO queuing: Size/Length/Discards 0/75/0

Last clearing of counters: 15:20:18 Mon 06/13/2022

Tunnel source 1.1.1.1, destination 2.2.2.2

略…

如果存在同源同目的隧道，只允许其中一个up，可以通过undo interface tunnel命令删除不需要的隧道；如果不存在同源同目的隧道，则执行步骤(3)继续排查故障。

(3) 检查是否配置GRE保活探测报文功能，是否可以正常收发GRE keepalive报文。（仅部分机型支持GRE keepalive，如不支持请忽略本步骤）。

在任意视图下执行display current interface tunnel命令查看隧道接口的keepalive配置。

<Sysname> display current interface tunnel

interface Tunnel2 mode gre

ip address 10.1.1.2 255.255.255.0

source 12.1.1.4

destination 12.1.1.2

keepalive 3 3

在本端设备上通过debugging gre packet命令打开GRE报文调试开关，查看是否可以正常收发keepalive报文。

<Sysname> debugging gre packet

*Jun 16 12:46:50:350 2022 Sysname GRE/7/packet: -MDC=1;

Tunnel2 packet: Before encapsulation,

12.1.1.2->12.1.1.4 (length = 24)

*Jun 16 12:46:50:350 2022 Sysname GRE/7/packet: -MDC=1;

Tunnel2 packet: After encapsulation,

12.1.1.4->12.1.1.2 (length = 48)

*Jun 16 12:46:50:351 2022 Sysname GRE/7/packet: -MDC=1;

Tunnel2 packet: Before de-encapsulation according to fast-forwarding table,

12.1.1.2->12.1.1.4 (length = 24)

*Jun 16 12:46:50:351 2022 Sysname GRE/7/packet: -MDC=1;

Tunnel2 : Received a keepalive packet.

// Tunnel2收到keepalive报文

在对端设备上同样打开GRE报文调试开关，如果对端显示发出了keepalive报文，本端却未收到，则GRE报文可能未通过本端的校验和检查。无法收到keepalive报文会导致隧道接口down，可以尝试通过undo keepalive命令关闭keepalive功能来解决该问题。

如果能够正常收到keepalive报文，则执行步骤(4)继续排查故障。

(4) 检查隧道报文的hoplimit/TTL和隧道报文DF标志配置是否合理。

在任意视图下执行display current interface tunnel命令查看hoplimit/TTL和隧道报文DF标志的配置：

interface Tunnel2 mode gre

ip address 10.1.1.2 255.255.255.0

source 12.1.1.4

destination 12.1.1.2

keepalive 3 3

tunnel ttl 1

tunnel dfbit enable

hoplimit/TTL配置和DF（Don’t Fragment，不分片）标志的配置可能导致隧道报文被丢弃：

a. hoplimit/TTL配置过小会导致隧道报文在中间设备上因为TTL超时而被丢弃。解决方法为在隧道接口视图下执行tunnel ttl命令，依照实际组网配置合理的TTL值；

b. 设置封装后的隧道报文的DF标志后，中间设备可能会因为报文长度超出接口MTU值而丢弃报文。解决方法为配置转发路径上各个接口的MTU大于隧道报文长度。在无法保证转发路径上各个接口的MTU大于隧道报文长度时，请关闭隧道报文不分片功能。

执行以上操作后仍无法排除故障，则执行步骤(5)继续排查故障。

(5) 查看是否隧道下发硬件处理失败。

打开隧道事件调试信息开关，查看是否有隧道报文或事件下内核/驱动失败，调试信息的示例如下：

<Sysname>debugging tunnel all

*Jun 16 12:51:25:832 2022 Sysname TUNNEL/7/event: -MDC=1;

Tunnel2 notifies driver: Operation = 4.

TunnelIfIndex = 524, EvilinkIfIndex = 0

VRFIndex = 0, DstVRFIndex = 0

TunnelMode = IPv4 GRE, TransPro = 1

TunnelSrc = 12.1.1.4

TunnelDst = 12.1.1.2

TTL = 255, ToS = 0, DFBit = 0

MTU = 1476, IPv6Mtu = 1476

DrvContext[0] = 0xffffffffffffffff, DrvContext[1] = 0xffffffffffffffff

VNHandle = 0x20000040, ADJIndex = 0xfaf3889c

// 隧道接口Tunnel2通知驱动执行Operation 4

*Jun 16 12:51:25:832 2022 Sysname TUNNEL/7/event: -MDC=1;

Processing result of operation 4 for Tunnel2: failed.

// 隧道接口Tunnel2下发的Operation 4处理失败

%Jun 16 12:51:25:832 2022 Sysname IFNET/3/PHY_UPDOWN: -MDC=1; Physical state on the interface Tunnel2 changed to down.

%Jun 16 12:51:25:832 2022 Sysname IFNET/5/LINK_UPDOWN: -MDC=1; Line protocol state on the interface Tunnel2 changed to down.

// 隧道Tunnel2接口down

*Jun 16 12:51:27:350 2022 Sysname TUNNEL/7/event: -MDC=1;

Tunnel2 can't come up because there is not enough hardware resource

// 由于硬件资源不足，隧道Tunnel2不能up

当设备打印的如下的event或error信息时，表示硬件是故障导致隧道工作不稳定，此时请联系技术支持。

表4 硬件相关的debug信息描述表

字段	描述
Tunnelnum can't come up because reason.	隧道Tunnelnum不能up的原因为reason，reason的取值为there is not enough hardware resource：硬件资源不足
Failed to save 6RD prefix to DBM.	向DBM（Database in memory，内存数据库）保存6RD隧道的IPv6前缀失败
Failed to save IPv4 prefix/suffix for 6RD tunnel to DBM.	向DBM保存6RD隧道的IPv4前缀/后缀失败
Failed to save 6RD BR address to DBM.	向DBM保存6RD隧道的BR地址失败
Failed to send 6RD prefix to kernel.	向内核发送隧道的6RD前缀配置消息失败
Failed to send IPv4 prefix/suffix for 6RD tunnel to kernel.	向内核发送隧道的6RD IPv4配置消息失败
Failed to send 6RD BR address to kernel.	向内核发送隧道的6RD BR地址配置消息失败

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

8 二层技术-以太网交换类故障处理

8.1 M-LAG故障处理

8.1.1 peer-link接口无法UP

1. 故障描述

在图47的网络中，Device A和Device B组成M-LAG系统，配置完成后，发现peer-link链路无法UP。通过命令display m-lag summary发现peer-link接口的状态为DOWN。

图47 peer-link接口无法UP组网图

2. 常见原因

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

· peer-link口为聚合接口，聚合接口无法UP。

· peer-link口为Tunnel接口，Tunnel接口无法UP。

· M-LAG系统配置不符合要求。

3. 故障分析

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

(1) 确认peer-link接口的状态。

(2) 确认M-LAG系统配置是否符合配置要求。

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

图48 peer-link无法UP的故障诊断流程图

4. 处理步骤

(1) 查看peer-link接口的DOWN原因。

在Device A上执行display m-lag summary命令，根据字段Peer-link interface state (cause)查看peer-link接口DOWN的原因：

¡ 如果cause显示为Aggregate interface down或Tunnel interface down，则表示配置为peer-link接口的聚合接口或Tunnel接口状态为DOWN，请按照聚合接口无法UP或者Tunnel接口无法UP故障处理流程定位。

¡ 如果cause显示为No correct DRCPDUs received，则表示未收到DRCPDU，请执行步骤（2）。

(2) M-LAG系统配置是否符合配置要求。

M-LAG系统配置的要求为组成M-LAG系统的设备上，系统优先级和系统MAC地址必须相同，系统编号不能相同。在Device A或Device B上执行display m-lag system命令，查看系统编号、系统MAC地址和系统优先级配置是否符合配置要求：

<Sysname> display m-lag system

System information

Local system number: 1 Peer system number: 2

Local system MAC: 0001-0001-0001 Peer system MAC: 0001-0001-0001

Local system priority: 123 Peer system priority: 123

Local bridge MAC: 3cd4-3ce1-0200 Peer bridge MAC: 3cd4-437d-0300

Local effective role: Primary Peer effective role: Secondary

Health level: 0

Standalone mode on split: Enabled

In standalone mode: Yes

System timer information

Timer State Value (s) Remaining time (s)

Auto recovery Disabled - -

Restore delay Disabled 30 -

Consistency-check delay Disabled 15 -

Standalone delay Disabled - -

Role to None delay Disabled 60 -

¡ 如果M-LAG系统配置不符合配置要求，则在系统视图下执行m-lag system-mac、m-lag system-number或m-lag system-priority命令，使Device A和Device B上的M-LAG系统配置满足配置要求。

¡ 如果M-LAG系统配置符合要求，则执行步骤（3）。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

8.1.2 M-LAG接口无法UP

1. 故障描述

在图49的网络中，Device A和Device B组成M-LAG系统，配置完成后，通过命令display m-lag summary发现M-LAG接口无法UP。

图49 M-LAG接口无法UP组网图

2. 常见原因

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

· 配置为M-LAG接口的聚合接口状态为DOWN。

· 对端设备未配置相同M-LAG组ID的M-LAG接口。

· 配置一致性检查不通过。

3. 故障分析

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

(1) 确认配置为M-LAG接口的聚合接口状态。

(2) 确认对端设备是否配置了相同M-LAG组ID的M-LAG接口。

(3) 配置一致性检查是否通过。

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

图50 M-LAG接口无法UP的故障诊断流程图

4. 处理步骤

(1) 查看M-LAG接口DOWN的原因。

在Device A上执行display m-lag summary命令，根据Local state (cause)字段查看M-LAG接口DOWN的原因：

¡ 如果cause显示为A，则表示M-LAG接口对应的聚合接口状态变为DOWN，请按照聚合接口无法UP故障处理流程定位。

¡ 如果cause显示为B，则表示对端不存在对应M-LAG接口，请执行步骤（2）。

¡ 如果cause显示为C，则表示配置一致性检查失败，请执行步骤（3）。

(2) 检查M-LAG系统的两台设备上M-LAG接口的M-LAG组ID是否相同。

在Device A和Device B上执行display m-lag summary命令，查看M-LAG group字段，判断组成M-LAG系统的两台设备上M-LAG接口的M-LAG组ID是否相同：

<DeviceA> display m-lag summary

Flags: A -- Aggregate interface down, B -- No peer M-LAG interface configured

C -- Configuration consistency check failed

Peer-link interface: BAGG3

Peer-link interface state (cause): UP

Keepalive link state (cause): UP

M-LAG interface information

M-LAG IF M-LAG group Local state (cause) Peer state Remaining down time(s)

BAGG4 4 UP UP -

¡ 如果两台设备上M-LAG接口的M-LAG组ID不同，则在其中一台设备的聚合接口视图下执行port m-lag group命令，使得M-LAG接口的M-LAG组ID保持一致。

¡ 如果两台设备上M-LAG接口的M-LAG组ID相同，则执行步骤（3）。

(3) 配置一致性检查是否通过。

在Device A上执行display m-lag consistency命令，分别查看Type 1和Type 2的配置一致性信息，包括全局和M-LAG接口的配置一致性信息。M-LAG系统两端设备上的Type 1类型配置必须一致，Type 2类型配置建议一致。

# 显示全局的Type 1类型的配置一致性信息。

<Sysname> display m-lag consistency type1 global

Configuration Local Peer

Link type Access Trunk

PVID 10 20

Global STP Enabled Disabled

STP mode MSTP RSTP

…

# 显示全局的Type 2类型的配置一致性信息。

<Sysname> display m-lag consistency type2 global

Configuration Local Peer

VLANs 1,3,5,7,9 2,4,6,8,10

Vlan-int 10,12,14,17,22,33 11,19,23,27,47

Vlan-int(shutdown) 100,103,107,200,301 200,261,290,333,465

…

# 显示二层聚合接口1的Type 1类型的配置一致性信息。

<Sysname> display m-lag consistency type1 interface bridge-aggregation 1

Configuration Local Peer

LAGG mode Static Dynamic

Link type Access Trunk

PVID 10 20

# 显示二层聚合接口1的Type 2类型的配置一致性信息。

<Sysname> display m-lag consistency type2 interface bridge-aggregation 1

Configuration Local Peer

VLANs 1,3,5,7,9 2,4,6,8,10

LACP select speed Enabled Disabled

LAGG ignore speed Enabled Disabled

Root guard Enabled Disabled

…

¡ 如果Local和Peer的Type 1类型的配置一致性信息中存在不匹配的信息，则请修改相关业务模块的配置，使Local和Peer的Type 1类型配置匹配。

¡ 如果Local和Peer的Type 1类型的配置一致性信息匹配，则执行步骤（4）。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

8.1.3 Keepalive无法UP

1. 故障描述

在图51的网络中，Device A和Device B组成M-LAG系统，通过命令display m-lag summary命令发现Keepalive链路无法UP。

图51 Keepalive无法UP组网图

2. 常见原因

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

· M-LAG系统未建立。

· 接口上未配置Keepalive链路对应的IP地址。

· M-LAG设备间三层网络不通。

3. 故障分析

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

(1) 确认M-LAG系统处于初始化状态时peer-link口是否UP。

(2) 检查是否配置了Keepalive链路的IP地址。

(3) 检查Keepalive链路的源IP地址和目的IP地址能否ping通。

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

图52 Keepalive无法UP的故障诊断流程图

4. 处理步骤

(1) 查看Keepalive链路DOWN原因。

在Device A上执行display m-lag summary命令，根据Keepalive link state (cause)字段查看Keepalive链路DOWN的原因：

¡ 如果cause显示为M-LAG system init，则表示M-LAG系统初始化，请执行步骤（2）。

¡ 如果cause显示为Local IP not configured，则表示本端未配置IP地址，请执行步骤（3）。

¡ 如果cause显示为Local Tx failed、Local Rx timeout或Peer Rx timeout，则表示本端发送报文失败、本端接收报文超时或对端接收报文超时，请执行步骤（4）。

(2) 检查M-LAG系统处于初始化状态时peer-link接口是否UP。

执行display interface命令查看peer-link接口是否处于UP状态：

¡ 如果peer-link接口未处于UP状态，请按照peer-link接口无法UP故障处理流程定位。

¡ 如果peer-link接口处于UP状态，则执行步骤（3）。

(3) 检查Keepalive链路的IP地址是否为本地接口地址。

在Device A和Device B上执行display m-lag keepalive命令，查看Source IP address字段，即Keepalive链路的源IP地址，执行display ip interface brief或display ipv6 interface brief命令查看该地址是否为设备的接口地址。

<Sysname> display m-lag keepalive

Neighbor keepalive link status (cause): Up

Neighbor is alive for: 135642 s 501 ms

Keepalive packet transmission status:

Sent: Successful

Received: Successful

Last received keepalive packet information:

Source IP address: 10.0.0.2

Time: 2019/09/11 09:21:51

Action: Accept

M-LAG keepalive parameters:

Destination IP address: 10.0.0.2

Source IP address: 10.0.0.1

Keepalive UDP port : 6400

Keepalive VPN name : vpn1

Keepalive interval : 1000 ms

Keepalive timeout : 5 sec

Keepalive hold time: 3 sec

¡ 如果未将Keepalive链路的源IP地址配置为本地接口地址，则在Device A和Device B直连链路的接口视图下执行ip address或ipv6 address命令配置源IP地址。

¡ 如果已配置Keepalive链路的源IP地址，则执行步骤（4）。

(4) 检查Keepalive链路的源IP地址和目的IP地址能否ping通。

在Device A上执行ping命令，检查Keepalive链路的目的IP地址是否可达：

¡ 如果不能ping通，则按照Ping和Tracert故障处理流程，解决网络不可达问题。

¡ 如果能ping通，则执行步骤（5）。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

8.2 以太网链路聚合故障处理

8.2.1 聚合接口无法UP

1. 故障描述

当两台设备间通过链路聚合连接时，通过display interface命令查看聚合接口处于down状态。

2. 常见原因

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

· 聚合接口配置错误。

· 成员端口物理链路故障。

· LACP协议报文收发故障。

3. 故障分析

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

(1) 通过display link-aggregation verbose查看成员端口是否处于选中状态，如果处于非选中状态，则通过display interface命令查询成员端口物理状态是否UP，排除端口物理故障影响。

(2) 检查本端和对端聚合接口配置，排除配置问题。

(3) 使用debugging link-aggregation lacp packet命令查看动态聚合的成员端口LACP协议交互情况。

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

图53 聚合接口无法UP的故障诊断流程图

4. 处理步骤

(1) 排查物理连线是否准确。

根据聚合接口的组网规划进行线路检查，确认物理链接线路是否完全按照规划连接。

如果物理连线正确，则执行步骤(2)。

(2) 聚合接口是否被手工关闭。

执行display interface命令查看聚合接口的物理状态，如果显示为“Administratively DOWN”，则表示聚合接口被手工关闭，请执行undo shutdown命令开启聚合接口。如果聚合接口未被手工关闭，则执行步骤(3)。

(3) 聚合组中成员端口是否UP。

执行display interface命令查看聚合组中的成员端口是否处于UP状态，如果没有UP，请按照端口不UP故障流程处理。

如果端口处于UP状态，则执行步骤(4)。

以如下显示为例，二层聚合组1中成员端口GigabitEthernet1/0/1处于非选中状态。执行display interface命令查看GigabitEthernet1/0/1的物理状态时，物理状态显示为“DOWN”，使成员端口GigabitEthernet1/0/1处于非选中状态。

<Sysname> display link-aggregation verbose

Loadsharing Type: Shar -- Loadsharing, NonS -- Non-Loadsharing

Port Status: S -- Selected, U -- Unselected, I -- Individual

Port: A -- Auto port, M -- Management port, R -- Reference port

Flags: A -- LACP_Activity, B -- LACP_Timeout, C -- Aggregation,

D -- Synchronization, E -- Collecting, F -- Distributing,

G -- Defaulted, H -- Expired

Aggregate Interface: Bridge-Aggregation1

Aggregation Mode: Static

Loadsharing Type: Shar

Management VLANs: None

Port Status Priority Oper-Key

GE1/0/1 U 32768 1

<Sysname> display interface GigabitEthernet 1/0/1

GigabitEthernet1/0/1

Current state: DOWN

Line protocol state: DOWN

IP packet frame type: Ethernet II, hardware address: 2a41-21c1-0100

Description: GigabitEthernet1/0/1 Interface

Bandwidth: 1000000 kbps

Loopback is not set

Unknown-speed mode, full-duplex mode

Link speed type is autonegotiation, link duplex type is force link

Flow-control is not enabled

Maximum frame length: 9216

Allow jumbo frames to pass

Broadcast max-ratio: 100%

Multicast max-ratio: 100%

Unicast max-ratio: 100%

Known-unicast max-ratio: 100%

PVID: 1

MDI type: Automdix

Port link-type: Access

Tagged VLANs: None

Untagged VLANs: 1

Port priority: 2

Last link flapping: 0 hours 0 minutes 15 seconds

Last clearing of counters: Never

Current system time:2021-08-10 10:15:02

Last time when physical state changed to up:2021-08-09 18:31:43

Last time when physical state changed to down:2021-08-10 10:14:47

Peak input rate: 0 bytes/sec, at 00-00-00 00:00:00

Peak output rate: 0 bytes/sec, at 00-00-00 00:00:00

Last 300 seconds input: 5000 packets/sec 5000 bytes/sec -%

Last 300 seconds output: 5000 packets/sec 5000 bytes/sec -%

Input (total): 5000 packets, 5000 bytes

5000 unicasts, 5000 broadcasts, 5000 multicasts, 0 pauses

Input (normal): 0 packets, 0 bytes

0 unicasts, 0 broadcasts, 0 multicasts, 0 pauses

Input: 5000 input errors, 0 runts, 0 giants, 0 throttles

0 CRC, 0 frame, 0 overruns, 0 aborts

5000 ignored, 0 parity errors

Output (total): 5000 packets, 5000 bytes

5000 unicasts, 5000 broadcasts, 5000 multicasts, 0 pauses

Output (normal): 0 packets, 0 bytes

0 unicasts, 0 broadcasts, 0 multicasts, 0 pauses

Output: 5000 output errors, 0 underruns, 0 buffer failures

5000 aborts, 0 deferred, 0 collisions, 0 late collisions

0 lost carrier, 0 no carrier

(4) 判断聚合接口是否为动态聚合。

¡ 如果聚合接口为动态聚合，则检查对端聚合接口的配置是否正确，即对端聚合接口是否为动态聚合。在任意视图下执行display link-aggregation verbose命令，查看链路两端聚合接口的聚合模式，确保两端聚合模式相同。

以二层聚合接口为例，显示“Aggregation Mode: Dynamic”时，表示该聚合接口为动态聚合：

<Sysname> display link-aggregation verbose bridge-aggregation 10

Loadsharing Type: Shar -- Loadsharing, NonS -- Non-Loadsharing

Port Status: S -- Selected, U -- Unselected, I -- Individual

Port: A -- Auto port, M -- Management port, R -- Reference port

Flags: A -- LACP_Activity, B -- LACP_Timeout, C -- Aggregation,

D -- Synchronization, E -- Collecting, F -- Distributing,

G -- Defaulted, H -- Expired

Aggregate Interface: Bridge-Aggregation10

Creation Mode: Manual

Aggregation Mode: Dynamic

Loadsharing Type: Shar

Management VLANs: None

System ID: 0x8000, 000f-e267-6c6a

Local:

Port Status Priority Index Oper-Key Flag

GE1/0/1 S 32768 61 2 {ACDEF}

GE1/0/2 S 32768 62 2 {ACDEF}

GE1/0/3 S 32768 63 2 {ACDEF}

Remote:

Actor Priority Index Oper-Key SystemID Flag

GE1/0/1(R) 32768 111 2 0x8000, 000f-e267-57ad {ACDEF}

GE1/0/2 32768 112 2 0x8000, 000f-e267-57ad {ACDEF}

GE1/0/3 32768 113 2 0x8000, 000f-e267-57ad {ACDEF}

如果配置不正确，则修改对端聚合接口为动态聚合；如果配置正确，则执行debugging link-aggregation lacp packet命令确认LACP报文收发是否正确。

执行debugging link-aggregation lacp packet命令后，查看成员端口send信息中Actor信息和receive信息中Partner信息。如果sys-mac、key和port-index字段的显示不一致，则LACP协议报文收发不正常，请排除收发光纤错接问题；如果sys-mac、key和port-index字段的显示一致，则LACP协议报文收发正常，请执行步骤(5)。

打开聚合组成员端口GigabitEthernet1/0/1的LACP报文调试信息开关，查看该端口收发LACP协议报文的情况。

<Sysname> debugging link-aggregation lacp packet all interface gigabitethernet 1/0/1

*Nov 2 15:51:21:15 2007 Sysname LAGG/7/Packet: PACKET.GigabitEthernet1/0/1.send.

size=110, subtype =1, version=1

Actor: type=1, len=20, sys-pri=0x8000, sys-mac=00e0-fc02-0300, key=0x1, pri=0x8000, port-index=0x2, state=0xc5

Partner: type=2, len=20, sys-pri=0x0, sys-mac=0000-0000-0000, key=0x0, pri=0x0, port-index=0x0, state=0x32

Collector: type=3, len=16, col-max-delay=0x0

Terminator: type=0, len=0

*Nov 2 15:55:21:15 2007 Sysname LAGG/7/Packet: PACKET.GigabitEthernet1/0/1.receive.

size=110, subtype =1, version=1

Actor: type=1, len=20, sys-pri=0x8000, sys-mac=00e0-fc00-0000, key=0x1, pri=0x8000, port-index=0x6, state=0xd

Partner: type=2, len=20, sys-pri=0x8000, sys-mac=00e0-fc02-0300, key=0x1, pri=0x8000, port-index=0x2, state=0xc5

Collector: type=3, len=16, col-max-delay=0x0

Terminator: type=0, len=0

¡ 如果聚合接口为静态聚合，则执行步骤(5)。

(5) 查看聚合接口下最小选中端口的配置是否影响成员端口选中。

在聚合接口视图下执行display this命令，如果存在link-aggregation selected-port minimum的配置，请修改最小选中端口数值，使其满足最小选中要求。当聚合组内能够被选中的成员端口数增加至不小于配置值时，这些成员端口都将变为选中状态，对应聚合接口的链路状态也将变为UP。

如果聚合接口下最小选中端口的配置未影响成员端口选中，则执行步骤(6)。

以如下显示为例，二层聚合接口1下配置的最小选中端口数为2，而二层聚合接口1对应的聚合组的成员端口仅有一个，所以该成员端口处于非选中状态。

[Sysname-Bridge-Aggregation1] display this

interface Bridge-Aggregation1

link-aggregation selected-port minimum 2

return

[H3C-Bridge-Aggregation1] display link-aggregation verbose

Loadsharing Type: Shar -- Loadsharing, NonS -- Non-Loadsharing

Port Status: S -- Selected, U -- Unselected, I -- Individual

Port: A -- Auto port, M -- Management port, R -- Reference port

Flags: A -- LACP_Activity, B -- LACP_Timeout, C -- Aggregation,

D -- Synchronization, E -- Collecting, F -- Distributing,

G -- Defaulted, H -- Expired

Aggregate Interface: Bridge-Aggregation1

Aggregation Mode: Static

Loadsharing Type: Shar

Management VLANs: None

Port Status Priority Oper-Key

GE1/0/1 U 32768 1

(6) 聚合组内是否存在选中的成员端口。

如果聚合组内不存在选中的成员端口，则请参见“8.2.3 聚合成员端口无法选中”故障进行定位；如果聚合组内存在选中的成员端口，则执行步骤(7)。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

8.2.2 聚合接口流量负载分担不均

1. 故障描述

当两台设备通过链路聚合连接时，通过display counters rate命令查看聚合成员端口出方向流量速率，某些成员端口速率特别小或者根本没有。

2. 常见原因

本类故障的常见原因主要为聚合负载分担方式配置错误。

3. 故障分析

本类故障的诊断思路为确认聚合接口转发的报文的特征，并查看聚合负载分担类型是否和报文特性匹配。

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

图54 聚合接口流量负载分担不均的故障诊断流程图

4. 处理步骤

(1) 用户业务流量是否正常。

如果用户业务流量正常，则等待一段时间，再执行display counters rate命令查看聚合成员端口出方向流量速率，确认聚合成员端口流量是否恢复负载分担：

¡ 如果已恢复负载分担，则无需处理。

¡ 如果未恢复负载分担，则执行步骤(2)。

如果用户业务流量不正常，则执行步骤(2)。

(2) 查看聚合负载分担类型与报文特征是否匹配。

通过执行display link-aggregation load-sharing mode命令查看聚合负载分担类型，如果与报文特征不匹配，则通过以下命令调整聚合负载分担类型（部分设备不支持在聚合接口视图下执行link-aggregation load-sharing mode命令）：

¡ 在系统视图下执行link-aggregation global load-sharing mode命令调整全局的负载分担类型。

¡ 在聚合接口视图下执行link-aggregation load-sharing mode命令调整聚合接口的负载分担类型。

针对不同业务流量，不同产品缺省的负载分担类型不同，具体请参见各产品“二层技术—以太网交换配置指导”中的“以太网链路聚合”。

如果聚合负载分担类型与报文特征匹配，则执行步骤(3)。

(3) 检查是否部署跨板/跨框/跨成员设备聚合。

对于框式设备：在IRF环境下，如果部署跨板/跨框聚合，则在系统视图下使用undo link-aggregation load-sharing mode local-first命令关闭本地优先转发功能。如果关闭本地优先转发功能，则可能影响IRF系统稳定，请根据实际情况进行操作。

如果未部署跨板/跨框聚合或不支持undo link-aggregation load-sharing mode local-first命令，则执行步骤(4)。

对于盒式设备：在IRF环境下，如果部署跨成员设备聚合，则在系统视图下使用undo link-aggregation load-sharing mode local-first命令关闭本地优先转发功能。如果关闭本地优先转发功能，则可能影响IRF系统稳定，请根据实际情况进行操作。

如果未部署跨成员设备聚合或不支持undo link-aggregation load-sharing mode local-first命令，则执行步骤(4)。

需要注意，跨板/跨框/跨成员设备流量不能过大，否则可能影响IRF系统稳定。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

8.2.3 聚合成员端口无法选中

1. 故障描述

当两台设备通过链路聚合连接时，发现聚合组成员端口处于非选中状态，聚合失败。

2. 常见原因

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

· 链路连通性故障。

· 本端和对端的操作key、属性类配置不一致。

· 聚合成员端口数配置错误。

3. 故障分析

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

(1) 查看成员端口是否UP，排除端口物理故障影响。

(2) 使用debugging link-aggregation lacp packet命令查看动态聚合的成员端口LACP协议交互情况。

(3) 检查本端和对端聚合接口配置，排除配置影响。

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

图55 聚合成员端口无法选中的故障诊断流程图

4. 处理步骤

(1) 排查物理连线是否正确。

根据聚合接口的组网规划进行线路检查，确认物理链接线路是否完全按照规划连接。

如果物理连线正确，则执行步骤(2)。

(2) 聚合组中成员端口是否UP。

通过display interface命令查看聚合组中的成员端口是否处于UP状态，如果没有UP，请按照端口不UP故障流程处理。

如果端口处于UP状态，则执行步骤(3)。

(3) 本端成员端口的属性类配置与聚合接口是否相同。

a. 执行display link-aggregation verbose命令查看本端处于Unselected状态的成员端口。

以二层聚合接口为例，Status字段显示为“U”时，表示该成员处于Unselected状态：

<Sysname> display link-aggregation verbose

Loadsharing Type: Shar -- Loadsharing, NonS -- Non-Loadsharing

Port Status: S -- Selected, U -- Unselected, I -- Individual

Port: A -- Auto port, M -- Management port, R -- Reference port

Flags: A -- LACP_Activity, B -- LACP_Timeout, C -- Aggregation,

D -- Synchronization, E -- Collecting, F -- Distributing,

G -- Defaulted, H -- Expired

Aggregate Interface: Bridge-Aggregation1

Creation Mode: Manual

Aggregation Mode: Dynamic

Loadsharing Type: Shar

Management VLANs: None

System ID: 0x8000, 2a41-21c1-0100

Local:

Port Status Priority Index Oper-Key Flag

GE1/0/1(R) S 32768 1 1 {ACDEF}

GE1/0/2 S 32768 2 1 {ACDEF}

GE1/0/3 U 32768 3 2 {AC}

Remote:

Actor Priority Index Oper-Key SystemID Flag

GE1/0/1 32768 1 1 0x8000, 36f6-c0aa-0200 {ACDEF}

GE1/0/2 32768 2 1 0x8000, 36f6-c0aa-0200 {ACDEF}

GE1/0/3 32768 3 1 0x8000, 36f6-c0aa-0200 {AC}

b. 执行display current-configuration interface命令查看本端处于Unselected状态的成员端口的属性类配置（VLAN等配置）与聚合接口是否相同，如果不同，则将其配置相同。

以如下显示为例，处于Unselected状态的成员端口GigabitEthernet1/0/3与参考端口GigabitEthernet1/0/1的属性类配置不同，导致该成员端口无法选中，需要修改成员端口GigabitEthernet1/0/3的属性类配置。

<Sysname> display current-configuration interface gigabitethernet 1/0/1

interface GigabitEthernet1/0/1

port link-mode bridge

port link-type trunk

port trunk permit vlan 1 to 20

port link-aggregation group 1

return

<Sysname> display current-configuration interface gigabitethernet 1/0/3

interface GigabitEthernet1/0/3

port link-type trunk

port trunk permit vlan 1 to 100

port link-aggregation group 1

return

如果本端成员端口的属性类配置与聚合接口相同，则执行步骤(4)。

(4) 本端成员端口的操作key与参考端口是否相同。

a. 执行display link-aggregation verbose命令查看本端处于Unselected状态的成员端口。

以二层聚合接口为例，Status字段显示为“U”时，表示该成员处于Unselected状态：

<Sysname> display link-aggregation verbose

Loadsharing Type: Shar -- Loadsharing, NonS -- Non-Loadsharing

Port Status: S -- Selected, U -- Unselected, I -- Individual

Port: A -- Auto port, M -- Management port, R -- Reference port

Flags: A -- LACP_Activity, B -- LACP_Timeout, C -- Aggregation,

D -- Synchronization, E -- Collecting, F -- Distributing,

G -- Defaulted, H -- Expired

Aggregate Interface: Bridge-Aggregation11

Creation Mode: Manual

Aggregation Mode: Dynamic

Loadsharing Type: Shar

Management VLANs: None

System ID: 0x8000, 2a41-21c1-0100

Local:

Port Status Priority Index Oper-Key Flag

GE1/0/1(R) S 32768 1 1 {ACDEF}

GE1/0/2 S 32768 2 1 {ACDEF}

GE1/0/3 U 32768 3 2 {AC}

Remote:

Actor Priority Index Oper-Key SystemID Flag

GE1/0/1 32768 1 1 0x8000, 36f6-c0aa-0200 {ACDEF}

GE1/0/2 32768 2 1 0x8000, 36f6-c0aa-0200 {ACDEF}

GE1/0/3 32768 3 1 0x8000, 36f6-c0aa-0200 {AC}

b. 执行display current-configuration interface命令查看本端处于Unselected状态的成员端口的操作key（包括该端口的速率、双工模式等）与参考端口是否相同，如果不同，则将其配置相同。

以如下显示为例，处于Unselected状态的成员端口GigabitEthernet1/0/3与参考端口GigabitEthernet1/0/1的操作key不同，导致该成员端口无法选中，需要修改该端口速率配置。

<Sysname> display current-configuration interface gigabitethernet 1/0/1

interface GigabitEthernet1/0/1

port link-mode bridge

combo enable fiber

port link-aggregation group 11

return

<Sysname> display current-configuration interface gigabitethernet 1/0/3

interface GigabitEthernet1/0/3

port link-mode bridge

combo enable fiber

speed 100

port link-aggregation group 11

return

如果本端成员端口的操作key与参考端口相同，则执行步骤(5)。

(5) 本端聚合接口是否为动态聚合。

如果是动态聚合，则执行步骤(6)；如果是静态聚合，否则进行步骤(8)。

(6) LACP报文收发是否正确。

执行debugging link-aggregation lacp packet命令确认LACP报文收发是否正确。执行命该令后，查看成员端口send信息中Actor信息和receive信息中Partner信息。如果sys-mac、key和port-index字段的显示不一致，则LACP协议报文收发不正常，请排除收发光纤错接问题；如果sys-mac、key和port-index字段的显示一致，则LACP协议报文收发正常，请执行步骤(7)。

打开聚合组成员端口GigabitEthernet1/0/1的LACP报文调试信息开关，查看该端口收发LACP协议报文的情况。

<Sysname> debugging link-aggregation lacp packet all interface gigabitethernet 1/0/1

*Nov 2 15:51:21:15 2021 Sysname LAGG/7/Packet: PACKET.GigabitEthernet1/0/1.send.

size=110, subtype =1, version=1

Actor: type=1, len=20, sys-pri=0x8000, sys-mac=00e0-fc02-0300, key=0x1, pri=0x8000, port-index=0x2, state=0xc5

Partner: type=2, len=20, sys-pri=0x0, sys-mac=0000-0000-0000, key=0x0, pri=0x0, port-index=0x0, state=0x32

Collector: type=3, len=16, col-max-delay=0x0

Terminator: type=0, len=0

*Nov 2 15:55:21:15 2021 Sysname LAGG/7/Packet: PACKET.GigabitEthernet1/0/1.receive.

size=110, subtype =1, version=1

Actor: type=1, len=20, sys-pri=0x8000, sys-mac=00e0-fc00-0000, key=0x1, pri=0x8000, port-index=0x6, state=0xd

Partner: type=2, len=20, sys-pri=0x8000, sys-mac=00e0-fc02-0300, key=0x1, pri=0x8000, port-index=0x2, state=0xc5

Collector: type=3, len=16, col-max-delay=0x0

Terminator: type=0, len=0

(7) 本端成员端口的对端端口的操作key和属性类配置与参考端口的对端端口是否相同。

在本端Unselected端口的对端设备上执行display current-configuration interface命令查看对端Unselected端口的属操作key和属性类配置与参考端口的对端端口是否相同，如果不同，则将其配置相同。

如果本端成员端口的对端端口的操作key和属性类配置与参考端口的对端端口相同，则执行步骤(8)。

(8) 聚合成员端口数量是否达到阈值。

¡ 聚合成员端口数超过上限。

可在聚合接口视图下通过link-aggregation selected-port maximum命令配置聚合组中的最大选中端口数。通过display link-aggregation verbose命令查看聚合组中成员端口数是否超过上限，如果超过上限，则多出来的端口为Unselected状态，Selected端口按照端口编号从小到大排序。请在成员端口视图下使用undo port link-aggregation group命令将Selected端口中不适用的端口从聚合组中删除，以使必须使用的端口能够选中。

¡ 聚合成员端口数低于下限。

可在聚合接口视图下执行link-aggregation selected-port minimum命令配置聚合组中的最小选中端口数。通过display link-aggregation verbose命令查看聚合组中成员端口是否低于下限，如果低于下限，则所有成员端口为Unselected状态。请执行link-aggregation selected-port minimum命令修改最小选中端口数值或者为聚合组添加成员端口，使其满足最小选中要求。

如果聚合成员端口数量未达到聚合组的阈值，则执行步骤(9)。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

8.3 生成树故障处理

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

1. 故障描述

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

2. 常见原因

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

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

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

3. 故障分析

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

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

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

InLoop0 UP UP(s) --

MGE0/0/0 DOWN DOWN --

NULL0 UP UP(s) --

REG0 UP -- --

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

FGE1/0/53 UP 40G A A 1

FGE1/0/54 DOWN 40G A A 1

GE1/0/1 ADM auto A A 1

- 如果网络中接口的状态为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)表示接口的数据链路层被一个或者多个协议模块关闭。protocols为多个协议的任意组合，可能的协议如下：

- DLDP：由于DLDP模块检测到单通而关闭接口的数据链路层。

- OAM：由于以太网OAM模块检测到远端链路故障而关闭接口的数据链路层。

- LAGG：聚合接口中没有选中的成员端口而关闭接口的数据链路层。

- BFD：由于BFD模块检测到链路故障而关闭接口的数据链路层。

- MACSEC：由于MACSEC模块还未协商成功接口的通信加密参数而关闭接口的数据链路层。

- VBP：由于配置二层转发功能后而关闭接口的数据链路层。

如果接口的数据链路层被上述协议关闭，请检查并修改这些模块的配置，使得接口的数据链路层协议状态恢复为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

----[Port54(FortyGigE1/0/53)][DOWN]----

Port protocol : Enabled

Port role : Disabled Port

Port ID : 128.54

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

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

Port edged : Config=disabled, Active=disabled

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

Transmit limit : 10 packets/hello-time

TC-Restriction : Disabled

Role-Restriction : Disabled

Protection type : Config=none, Active=none

MST BPDU format : Config=auto, Active=802.1s

Port Config-

Digest-Snooping : Disabled

Rapid transition : False

Num of VLANs mapped : 1

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

BPDU sent : 0

TCN: 0, Config: 0, RST: 0, MST: 0

BPDU received : 0

TCN: 0, Config: 0, RST: 0, MST: 0

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

...

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

Port protocol : Disabled

...

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

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

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

1. 故障描述

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

2. 常见原因

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

3. 故障分析

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

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

4. 处理步骤

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

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

<Sysname> display stp

...

----[Port2(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命令，将该端口配置为边缘端口。

在接口下不能同时配置边缘端口和环路保护功能，执行stp edged-port命令时，如果设备打印如下错误提示信息，说明当前接口已经配置了环路保护功能。此时需要先执行undo stp loop-protection命令关闭环路保护功能，才能将该端口配置为边缘端口。

Failed to enable edged-port on GigabitEthernet1/0/1, because loop-protection is enabled.

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

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

1. 故障描述

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

2. 常见原因

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

3. 故障分析

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

本类故障的诊断流程如8.3.2 3. 图57所示。

图58 非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. 告警与日志

9 三层技术-IP业务类故障处理

9.1 ARP故障处理

9.1.1 无法学习到ARP表项

1. 故障描述

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

2. 常见原因

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

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

· 接口物理层未正常Up。

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

· ARP报文未上送到CPU。

· 单板存在故障。

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

3. 故障分析

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

图59 无法学习到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)步。

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

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

依次检查如下配置：

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

b. 通过display fib ip-address命令查看FIB表项的信息，ip-address为ARP表项的IP地址。如果不存在对应的FIB表项，则说明可能路由模块发生故障，关于路由模块的故障排查，请参见“三层技术-IP路由类故障处理”手册。如果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的错误调试信息开关，根据。表5中的内容确认设备无法成功发送或接收ARP报文的原因。

表5 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) 确认是否有单板发生故障。下面以slot1为例，通过display system internal arp statistics命令查看该单板的ARP统计信息。

<Sysname> system-view

[Sysname] probe

[Sysname-probe] display system internal arp statistics slot 1

Entry statistics:

Valid = 1 Dummy = 0

Long static = 0 Short resolved = 0

Multiport = 0 L3 short = 0

Packet = 1 OpenFlow = 0

Rule = 0 ARP input = 175

Resolved = 10

Static statistics:

Short static = 0 Long static = 0

Multiport = 0 Disabled = 0

Error statistics:

Memory = 0 Sync memory = 0

Packet = 10 Parameter = 0

IF = 0 Walk = 0

Add host route = 0 Del host route = 0

Local address = 0 Real time message = 0

Refresh rule = 0 Delete rule = 0

Smooth rule start = 0 Smooth rule end = 0

Running information:

Max ARP = 2048 Max multiport = 64

Default blackhole = 1 Max blackhole = 200

Timer queue = 0 Event queue = 0

Packet queue = 0 LIPC send queue = 0/0/0

a. 如果“ARP input”字段不为0，请执行第(5)步。如果“ARP input”字段为0，请排查相关单板的故障。

b. 收集“Error statistics”字段中的内容，发送给H3C技术支持工程师。

(5) 确认是否由于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，请执行第(6)步。

(6) 收集ARP进程的具体信息。执行display mdc命令显示MDC的相关信息，获取MDC的编号。通过display process命令查看MDC编号对应的ARP进程的进程编号，根据进程编号通过view命令显示ARP进程的具体信息，然后将具体信息发送给H3C技术支持工程师。

[Sysname-probe] display process name karp/1

Job ID: 224

PID: 224

Parent JID: 2

Parent PID: 2

Executable path: -

Instance: 0

Respawn: OFF

Respawn count: 1

Max. spawns per minute: 0

Last started: Mon Apr 18 15:09:58 2022

Process state: sleeping

Max. core: 0

ARGS: -

TID LAST_CPU Stack PRI State HH:MM:SS:MSEC Name

224 0 0K 115 S 0:5:25:380 [karp/1]

“karp/1”中的1表示MDC的编号为1，以上显示信息中的“PID”取值表示ARP进程的进程编号为224.。然后，请执行view命令显示224号ARP进程的具体信息。

[Sysname-probe]view /proc/224/stack

[<c04c9cd4>] kepoll_wait+0x274/0x3c0

[<e1fb1372>] arp_Thread+0x42/0xd0 [system]

[<c043f1b4>] kthread+0xd4/0xe0

[<c0401daf>] kernel_thread_helper+0x7/0x10

[<ffffffff>] 0xffffffff

(7) 请收集如下信息，并联系H3C技术支持工程师。

¡ 上述步骤的执行结果。

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

5. 告警与日志

9.1.2 不回应ARP请求报文

1. 故障描述

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

2. 常见原因

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

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

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

· 端设备发送的ARP请求报文触发了本端的ARP Detection功能。

3. 故障分析

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

图60 不回应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的错误调试信息开关，根据表6中的内容确认设备不回应ARP报文的原因。

表6 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) 查看对端设备是否触发了ARP Detection功能。以Slot 1为例，通过display arp detection statistics attack-source命令显示ARP Detection攻击源统计信息。

<Sysname> display arp detection statistics attack-source slot 1

Interface VLAN MAC address IP address Number Time

GE1/0/1 1 0005-0001-0001 10.1.1.14 24 17:09:56

03-27-2017

¡ 如果ARP Detection攻击报文中的源MAC地址为对端设备的MAC地址，请查看ARP Detection的相关配置，确认是否配置不合适导致对端报文错误地触发了ARP Detection功能。如果配置不合适，请修改ARP Detection配置。

¡ 如果不存在对端设备MAC地址对应的ARP Detection表项，请执行(4)。

(4) 通过display arp detection statistics packet-drop命令显示ARP Detection丢弃报文的统计信息，根据统计信息定位触发ARP Detection的原因。

<Sysname> display arp detection statistics packet-drop

State: U-Untrusted T-Trusted

ARP packets dropped by ARP inspect checking:

Interface/AC(State) IP Src-MAC Dst-MAC Inspect

GE1/0/1(U) 40 0 0 78

GE1/0/2(U) 0 0 0 0

GE1/0/3(T) 0 0 0 0

GE1/0/4(U) 0 0 30 0

GE1/0/5-srv1(U) 0 10 20 0

GE1/0/5-srv2(T) 10 0 20 22

表7 display arp detection statistics packet-drop命令显示信息描述表

字段	描述
State	接口状态： · U：ARP非信任接口/AC · T：ARP信任接口/AC
Interface/AC(State)	ARP报文入接口/AC，State表示该接口/AC的信任状态
IP	ARP报文源和目的IP地址检查不通过丢弃的报文计数
Src-MAC	ARP报文源MAC地址检查不通过丢弃的报文计数
Dst-MAC	ARP报文目的MAC地址检查不通过丢弃的报文计数
Inspect	ARP报文结合用户合法性检查不通过丢弃的报文计数

(5) 通过display system internal arp statistics命令显示各单板的ARP统计信息，收集“Error statistics”字段中的内容，发送给H3C技术支持工程师。

[Sysname-probe] display system internal arp statistics slot 1

Entry statistics:

Valid = 1 Dummy = 0

Long static = 0 Short resolved = 0

Multiport = 0 L3 short = 0

Packet = 1 OpenFlow = 0

Rule = 0 ARP input = 175

Resolved = 10

Static statistics:

Short static = 0 Long static = 0

Multiport = 0 Disabled = 0

Error statistics:

Memory = 0 Sync memory = 0

Packet = 10 Parameter = 0

IF = 0 Walk = 0

Add host route = 0 Del host route = 0

Local address = 0 Real time message = 0

Refresh rule = 0 Delete rule = 0

Smooth rule start = 0 Smooth rule end = 0

Running information:

Max ARP = 2048 Max multiport = 64

Default blackhole = 1 Max blackhole = 200

Timer queue = 0 Event queue = 0

Packet queue = 0 LIPC send queue = 0/0/0

(6) 通过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

表8 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：老化待删除状态

(7) 请收集如下信息，并联系H3C技术支持工程师。

¡ 上述步骤的执行结果。

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

5. 告警与日志

9.1.3 已有ARP表项但无法转发流量

1. 故障描述

设备已有ARP表项但无法正常转发流量。

2. 常见原因

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

· 学习到的ARP表项参数异常。

· 学习到的ARP表项没有成功下发驱动。

3. 故障分析

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

图61 已有ARP表项但无法转发流量故障诊断流程图

4. 处理步骤

(1) 检查ARP表项是否成功创建。通过display system internal adj4 entry命令查看ARP表项信息，以接口GigabitEthernet1/0/1、对端IP地址为1.1.1.2为例。

<Sysname> system-view

[Sysname] probe

[Sysname-probe] display system internal adj4 entry 1.1.1.2 interface gigabitethernet 1/0/1

ADJ4 entry:

Entry attribute : 0x0

Service type : Ethernet

Link media type : Broadcast

Action type : Forwarding

Entry flag : 0x0

Forward type : 0x0

Slot : 0

MTU : 1500

Driver flag : 2

Sequence No : 17

Physical interface : GE1/0/1

Logical interface : N/A

Virtual circuit information : 65535

ADJ index : 0xdc731e70

Peer address : 0.0.0.0

Reference count : 0

Reference Sequence : 9

MicroSegmentID : 0

Nexthop driver[0] : 0xffffffff

Nexthop driver[1] : 0xffffffff

Driver context[0] : 0xffffffff

Driver context[1] : 0xffffffff

Driver context[2] : 0xffffffff

Driver context[3] : 0xffffffff

Driver context[4] : 0xffffffff

Driver context[5] : 0xffffffff

Link head information(IP) : 68cb9c3f020668cb978f01060800

Link head information(MPLS) : 68cb9c3f020668cb978f01068847

¡ 如果“Action type”字段为“Forwarding”，则代表设备正常转发来自1.1.1.2的流量，设备无故障。

¡ 如果“Action type”字段为“Drop”，则表示没有成功创建ARP表项。

- 如果“Driver flag”字段为“4”，代表驱动资源不足，请检查驱动的使用情况。

- 如果“Driver flag”字段不为“4”，请继续执行第(2)步。

(2) 检查ARP表项是否成功下发到驱动。通过debugging system internal adj4命令并指定hardware参数打开IPv4邻接表下驱动调试功能。通过reset arp命令清除ARP表项，然后通过ping命令向对端设备发送报文来触发ARP表项的学习，查看ARP表项下发驱动的情况。

<Sysname> system-view

[Sysname] probe

[Sysname-probe] debugging system internal adj4 hardware

[Sysname-probe] ping 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.015 ms

*Apr 22 15:57:56:173 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

*Apr 22 15:57:56:173 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

*Apr 22 15:57:56:174 2022 Sysname ADJ4/7/ADJ4_ENTRY: -MDC=1;

-------------ADJ4 Entry------------

IP address : 1.1.1.2

Route interface : GE1/0/1

Service type : Ethernet

Action type : Forwarding

Link media type : Broadcast

Physical interface : GE1/0/1

Logical interface : N/A

VSI Index : 4294967295

VPN Index : 0

MicroSegmentID : 0

MicSegOrigin : 5

Virtual Circuit information : 0xffff

Sequence : 1

Sequence for aging : 1

Slot : 0

MTU : 1500

*Apr 22 15:57:56:174 2022 Sysname ADJ4/7/ADJ4_ENTRY: -MDC=1;

Add ADJ entry finished, Result : 0

*Apr 22 15:57:56:174 2022 Sysname ADJ4/7/ADJ4_HARDWARE: -MDC=1;

====Start ADJLINK Add====

*Apr 22 15:57:56:174 2022 Sysname ADJ4/7/ADJ4_HARDWARE: -MDC=1;

--------------- New Entry -------------

Service type : Ethernet

Link media type : Broadcast

Action type : Forwarding

EntryAttr : 0

IP address : 1.1.1.2

Route interface : GE1/0/1

Port interface : N/A

Slot : 0

MTU : 1500

VLAN ID : 65535

Second VLAN ID : 65535

Physical interface : GE1/0/1

Logical interface : N/A

VRF index : 0

VSI index : -1

VSI link ID : 65535

Usr ID : -1

MAC address : 68cb-9c3f-0206

Link head length(IP) : 14

Link head length(MPLS) : 14

Link head information(IP) : 68cb9c3f020668cb978f01060800

Link head information(MPLS) : 68cb9c3f020668cb978f01068847

*Apr 22 15:57:56:174 2022 Sysname ADJ4/7/ADJ4_HARDWARE: -MDC=1;

----------- New Entry DrvContext ---------

Nexthop driver

[0]: 0xffffffff [1]: 0xffffffff

Driver context

[0]: 0xffffffff [1]: 0xffffffff [2]: 0xffffffff [3]: 0xffffffff [4]: 0xffffffff [5]: 0xffffffff

TRILL VN driver context

[0]: 0xffffffffffffffff [1]: 0xffffffffffffffff

*Apr 22 15:57:56:174 2022 Sysname ADJ4/7/ADJ4_HARDWARE: -MDC=1;

====End ADJLINK Operate====

Result : 0x0, Reference flag : 0x0, Syn flag : 0x0

56 bytes from 1.1.1.2: icmp_seq=1 ttl=255 time=1.061 ms

56 bytes from 1.1.1.2: icmp_seq=2 ttl=255 time=0.908 ms

56 bytes from 1.1.1.2: icmp_seq=3 ttl=255 time=0.625 ms

56 bytes from 1.1.1.2: icmp_seq=4 ttl=255 time=0.580 ms

--- Ping statistics for 1.1.1.2 ---

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

round-trip min/avg/max/std-dev = 0.580/1.038/2.015/0.520 ms

[Sysname-probe]%Apr 22 15:57:56:986 2022 Sysname PING/6/PING_STATISTICS: -MDC=1; Ping statistics for 1.1.1.2: 5 packet(s) transmitted, 5 packet(s) received, 0.0% packet loss, round-trip min/avg/max/std-dev = 0.580/1.038/2.015/0.520 ms.

¡ 如果“Result”字段为“0x0”，则代表ARP表项成功下发到驱动，请继续执行第(3)步。

¡ 如果“Result”字段不为“0x0”，则代表ARP表项没有下发到驱动，请在H3C技术支持工程师的指导下检查硬件资源的使用情况。

(3) 请执行如下命令，并收集显示信息，发送给H3C技术支持工程师。

¡ 执行debugging system internal adj4命令并指定notify参数。

¡ 执行debugging system internal ipv4 fib prefix命令。

(4) 请收集如下信息，并联系H3C技术支持工程师。

¡ 上述步骤的执行结果。

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

9.2 ND故障处理

9.2.1 无法学习到ND表项

1. 故障描述

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

2. 常见原因

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

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

· 接口物理层未正常Up。

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

· ND报文未上送到CPU。

· 单板存在故障。

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

3. 故障分析

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

图62 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)步。

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

依次检查如下配置：

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

b. 通过display ipv6 fib ipv6-address命令查看IPv6 FIB表项的信息，ipv6-address为ND表项的IPv6地址。如果不存在对应的IPv6 FIB表项，则说明可能路由管理模块发生故障，关于路由模块的故障排查，请参见“三层技术-IP路由类故障处理”手册。如果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报文，请继续执行第(4)步。

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

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

表9 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) 确认是否有单板发生故障。下面以slot1为例，通过display system internal nd statistics命令查看该单板的ND统计信息。

<Sysname> system-view

[Sysname] probe

[Sysname-probe] display system internal nd statistics slot 1

Entry statistics:

Valid : 1 Dummy : 0

Packet : 1 OpenFlow : 0

Long static : 0 Short static : 0

Temp node : 0 Rule : 0

Static statistics:

Short : 0 Long interface : 0

Long port : 0

Process statistics:

Input : 7 Resolving : 11

Error statistics:

Memory : 0 Sync : 0

Packet : 0 Parameter : 0

Anchor : 0 Get address : 0

Refresh FIB : 0 Delete FIB : 0

Realtime Sync : 0 Temp node : 0

Exceed limit : 0 Refresh rule : 0

Delete rule : 0 Smooth rule start : 0

Smooth rule end : 0 RA : 0

Origin : 0 Final RA : 0

a. 如果“input”字段不为0，请执行第(5)步。如果“input”字段为0，请排查相关单板的故障。

b. 收集“Error statistics”字段中的内容，发送给H3C技术支持工程师。

(5) 确认是否由于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，请执行第(6)步。

(6) 收集ND进程的具体信息。执行display mdc命令显示MDC的相关信息，获取MDC的编号。通过display process命令查看MDC编号对应的ND进程的进程编号，根据进程编号通过view命令显示ND进程的具体信息，然后将具体信息发送给H3C技术支持工程师。

[Sysname-probe] display process name knd/1

Job ID: 55763

PID: 55763

Parent JID: 2

Parent PID: 2

Executable path: -

Instance: 0

Respawn: OFF

Respawn count: 1

Max. spawns per minute: 0

Last started: Tue Apr 26 11:32:31 2022

Process state: sleeping

Max. core: 0

ARGS: -

TID LAST_CPU Stack PRI State HH:MM:SS:MSEC Name

55763 0 0K 115 S 0:0:13:490 [kND/1]

“knd/1”中的1表示MDC的编号为1，以上显示信息中的“PID”取值表示ND进程的进程编号为55763。然后，请执行view命令显示55763号ND进程的具体信息。

[Sysname-probe] view /proc/55763/stack

[<c04c9cd4>] kepoll_wait+0x274/0x3c0

[<e2021612>] nd_Thread+0x62/0x100 [system]

[<c043f1b4>] kthread+0xd4/0xe0

[<c0401daf>] kernel_thread_helper+0x7/0x10

[<ffffffff>] 0xffffffff

(7) 请收集如下信息，并联系H3C技术支持工程师。

¡ 上述步骤的执行结果。

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

5. 告警与日志

9.2.2 不回应NS报文

1. 故障描述

设备收到对端设备发送到NS报文后，不回应NA报文。

2. 常见原因

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

· 接口收到的NS报文的目的IPv6地址不是本机IPv6地址。

· 对端设备触发了源MAC地址固定的ND攻击检测功能。

· 对端设备触发了ND Detection功能。

3. 故障分析

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

图63 不回应NS报文故障诊断流程图

4. 处理步骤

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

a. 先通过debugging ipv6 packet命令用来打开ND的报文调试信息开关，再使用对端设备向本端发送NS报文。

<Sysname> debugging ipv6 packet

*Apr 26 13:33:34:897 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.

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

¡ 如果“Dst”是本机IP，请执行b。

b. 通过debugging ipv6 error命令用来打开ND的错误调试信息开关，根据表10中的内容确认设备不回应ND报文的原因。

表10 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报文被管理禁止

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

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

Source MAC VLAN ID Interface Aging time (sec) Packets dropped

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

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

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

(3) 通过display ipv6 nd detection statistics命令显示ND Detection丢弃ND报文的统计信息，查看对端设备是否触发了ND Detection功能。

<Sysname> display ipv6 nd detection statistics

ND packets dropped by ND detection:

Interface Packets dropped

GE1/0/1 78

¡ 如果与对端设备相连的接口丢弃的报文不为0，请检查ND Detection相关配置。

¡ 如果与对端设备相连的接口丢弃的报文为0，请执行(4)。

(4) 通过display system internal arp statistics命令显示各单板的ARP统计信息，收集“Error statistics”字段中的内容，发送给H3C技术支持工程师。

(5) 以slot1为例，通过display system internal nd statistics命令显示各单板的ND统计信息，确认是否有单板发生故障。

[Sysname-probe] display system internal nd statistics slot 1

Entry statistics:

Valid : 1 Dummy : 0

Packet : 1 OpenFlow : 0

Long static : 0 Short static : 0

Temp node : 0 Rule : 0

Static statistics:

Short : 0 Long interface : 0

Long port : 0

Process statistics:

Input : 7 Resolving : 11

Error statistics:

Memory : 0 Sync : 0

Packet : 0 Parameter : 0

Anchor : 0 Get address : 0

Refresh FIB : 0 Delete FIB : 0

Realtime Sync : 0 Temp node : 0

Exceed limit : 0 Refresh rule : 0

Delete rule : 0 Smooth rule start : 0

Smooth rule end : 0 RA : 0

Origin : 0 Final RA : 0

¡ 通过“Input”字段查看单板是否正常的接收ND报文。

¡ 收集“Error statistics”字段中的内容，发送给H3C技术支持工程师。

(6) 请收集如下信息，并联系H3C技术支持工程师。

¡ 上述步骤的执行结果。

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

5. 告警与日志

9.2.3 已有ND表项但无法转发流量

1. 故障描述

设备已有ND表项但无法正常转发流量。

2. 常见原因

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

· 平台ND表项参数异常。

· 平台ND表项没有成功下发驱动。

3. 故障分析

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

图64 已有ND表项但无法转发流量故障诊断流程图

4. 处理步骤

(1) 通过display system internal adj6 entry命令查看ND表项是否成功建立。

[Sysname-probe]display system internal adj6 entry 1::2 interface gigabitethernet 1/0/1

ADJ6 entry:

Entry attribute : 0x0

Service type : Ethernet

Link media type : Broadcast

Action type : Forwarding

Entry flag : 0x4

Forward type : 0x0

Slot : 0

MTU : 1500

Driver flag : 2

Sequence No : 17

Physical interface : GE1/0/1

Logical interface : N/A

Virtual circuit information : 65535

ADJ index : 0xdc780c38

Peer address : ::

Reference count : 0

Reference Sequence : 3

MicroSegmentID : 0

Nexthop driver[0] : 0xffffffff

Nexthop driver[1] : 0xffffffff

Driver context[0] : 0xffffffff

Driver context[1] : 0xffffffff

Driver context[2] : 0xffffffff

Driver context[3] : 0xffffffff

Driver context[4] : 0xffffffff

Driver context[5] : 0xffffffff

Link head information(IPv6) : 68cb9c3f020668cb978f010686dd

Link head information(MPLS) : 68cb9c3f020668cb978f01068847

以接口GigabitEthernet1/0/1，对端IP地址为1.1.1.2为例：

¡ 如果“Action type”字段为“Forwarding”，则代表设备正常转发来自1.1.1.2的流量，设备无故障。

¡ 如果“Action type”字段为“Drop”，则代表没有成功建立ND表项。

- 如果“Driver flag”字段为“4”，代表驱动资源不足，请检查驱动的使用情况。

- 如果“Driver flag”字段不为“4”，请继续执行第(2)步。

(2) 通过debugging system internal adj6命令并指定hardware参数打开IPv4邻接表下驱动调试功能，然后通过ping ipv6命令触发ND表项的学习，查看ND表项是否成功下发到驱动。

[Sysname-probe] debugging system internal adj6 hardware

[Sysname-probe] ping ipv6 -c 1 1::2

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

56 bytes from 1::2, icmp_seq=0 hlim=64 time=2.868 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 = 2.868/2.868/2.868/0.000 ms

<Sysname>*Apr 26 16:06:42:412 2022 Sysname IP6PMTU/7/IP6PMTU_DBG: -MDC=1; Binding socket to PMTU succeeded

*Apr 26 16:06:42:412 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 16:06:42:412 2022 Sysname IP6FW/7/IP6FW_PACKET: -MDC=1;

Sending, interface = GigabitEthernet0/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 GigabitEthernet0/0/1.

*Apr 26 16:06:42:413 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 16:06:42:413 2022 Sysname IP6FW/7/IP6FW_PACKET: -MDC=1;

Sending, interface = GigabitEthernet0/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 GigabitEthernet0/0/1.

*Apr 26 16:06:42:414 2022 Sysname IP6FW/7/IP6FW_PACKET: -MDC=1;

Receiving, interface = GigabitEthernet0/0/1, version = 6, traffic class = 224,

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

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

prompt: Received an IPv6 packet.

*Apr 26 16:06:42:414 2022 Sysname ADJ6/7/ADJ6_HARDWARE: -MDC=1;

====Start ADJLINK Add====

*Apr 26 16:06:42:414 2022 Sysname ADJ6/7/ADJ6_HARDWARE: -MDC=1;

--------------New Entry-------------

Service type : Ethernet

Link media type : Broadcast

Action type : Forwarding

IPv6 address : 1::2

Route interface : GE0/0/1

Port interface : N/A

Slot : 0

MTU : 1500

VLAN id : 65535

Second VLAN id : 65535

Physical interface : GE0/0/1

Logical interface : N/A

Vrf index : 0

VSI index : -1

VSI link ID : 65535

Usr ID : -1

MAC address : 68cb-9c3f-0206

Link head length(IPv6) : 14

Link head length(MPLS) : 14

Link head information(IPv6) : 68cb9c3f020668cb978f010686dd

Link head information(MPLS) : 68cb9c3f020668cb978f01068847

Nexthop driver

[0]: 0xffffffff [1]: 0xffffffff

Driver context

[0]: 0xff

*Apr 26 16:06:42:414 2022 Sysname ADJ6/7/ADJ6_HARDWARE: -MDC=1;

====End ADJLINK Operate====

Result : 0x0, Reference flag : 0x0, Syn flag : 0x0

*Apr 26 16:06:42:415 2022 Sysname IP6FW/7/IP6FW_PACKET: -MDC=1;

Receiving, interface = GigabitEthernet0/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.

*Apr 26 16:06:42:415 2022 Sysname IP6FW/7/IP6FW_PACKET: -MDC=1;

Delivering, interface = GigabitEthernet0/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.

%Apr 26 16:06:42:416 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 = 2.868/2.868/2.868/0.000 ms.

*Apr 26 16:06:42:417 2022 Sysname IP6PMTU/7/IP6PMTU_DBG: -MDC=1; Unbinding PMTU from socket succeeded

¡ 如果“Result”字段为“0x0”，则代表ND表项成功下发到驱动，请继续执行第(3)步。

¡ 如果“Result”字段不为“0x0”，则代表ND表项没有下发到驱动，请检查硬件资源的使用情况。

(3) 请执行如下命令，并收集显示信息，发送给H3C技术支持工程师。

¡ 执行debugging system internal adj6命令并指定notify参数。

¡ 通过debugging system internal ipv6 fib prefix命令。

(4) 请收集如下信息，并联系H3C技术支持工程师。

¡ 上述步骤的执行结果。

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

10 三层技术-IP路由类故障处理

10.1 BGP故障处理

10.1.1 BGP会话无法进入Established状态

1. 故障描述

本地路由器与对等体/对等体组建立的BGP会话无法进入Established状态。

2. 常见原因

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

· BGP报文转发受阻。

· 建立/维持BGP TCP连接的报文被ACL过滤。

· 自治系统内，BGP邻居间的Router ID产生冲突。

· 指定了错误的对等体/对等体组的AS号。

· 指定对等体的地址为Loopback接口的IP地址时，对端未通过peer connect-interface命令将建立TCP连接所使用的源接口配置为Loopback接口，或者对端未通过peer source-address命令将建立TCP连接所使用的源地址配置为Loopback接口的地址。

· 建立BGP TCP连接时，BGP会话两端发送的TCP报文长度过大，在转发时被出接口MTU较小且无法对报文分片的中间节点丢弃，导致BGP TCP连接失败。

· 指定EBGP对等体的地址为Loopback接口的IP地址时，对端未配置peer ebgp-max-hop命令，以允许本地路由器同非直连邻居建立EBGP会话。

· BGP会话的两端未通过peer password命令配置相同的密钥，导致MD5认证失败。

· 配置peer ttl-security命令以开启指定对等体/对等体组的GTSM功能时，到达对等体/对等体组的最大跳数配置错误，导致对等体/对等体组无法通过GTSM检查。

· 对等体向本地路由器发送的BGP路由数量超过了peer route-limit命令设定的最大值，导致BGP会话断开。

· BGP路由器上配置了peer ignore、ignore all-peers或shutdown process命令，禁止建立BGP会话。

· 本地路由器与对端路由器没有在相同的地址族视图下使能路由信息交换能力。

3. 故障分析

本类故障的诊断流程如图65所示：

图65 BGP会话无法进入Established状态的故障诊断流程图

4. 处理步骤

(1) 检查与BGP邻居之间的通信链路是否正常。

a. 检查与邻居建立BGP会话的相关接口是否处于UP状态。

b. 通过ping命令方式检查与BGP邻居的连通性。如果Ping的结果为可达，则说明本地路由器与BGP邻居之间的通信链路正常，请执行步骤（2）。如果Ping的结果为不可达，请执行步骤c。

建议使用ping –a source-ip –s packet-size命令和ping ipv6 –a source-ipv6 –s packet-size命令来检测与BGP邻居的连通性。–a source-ip和–a source-ipv6参数指定了ICMP回显请求报文的源地址，方便用户同时检测两端的链路是否都正常；–s packet-size参数指定了发送的ICMP回显请求报文的长度，方便用户检测长报文在链路中的传输情况。Ping操作的源IP地址取用本端建立BGP会话使用的接口的IP地址，目的IP地址取用对端建立BGP会话使用的接口的IP地址。

c. 执行ping –a source-ip –s packet-size命令进行Ping操作，并逐步减小–s packet-size参数输入的值，当该参数减小到某个值时，Ping的结果变为可达，则表示建立BGP TCP连接时发送的TCP报文由于长度过长，在转发过程中被设备丢弃，导致了BGP会话无法进入Established状态。

- 此时可以重复执行ping –a source-ip –s packet-size命令，调整–s packet-size参数的取值，直至找到一个合适的取值（Ping的结果为可达的前提下，取尽量大的值，以提高转发效率），然后将该值设置为BGP报文转发出接口的MTU值。可通过在接口上执行ip/ipv6 mtu mtu-size或tcp mss value命令，或者在BGP实例视图/BGP-VPN实例视图下执行peer tcp-mss命令来设置出接口的MTU值；其中，ip/ipv6 mtu mtu-size命令配置的是MTU值，tcp mss value和peer tcp-mss命令配置的是TCP MSS值（TCP MSS＝MTU值－IP头部长度－TCP头部长度）。

- 也可以无需重复进行Ping操作，直接在系统视图下执行tcp path-mtu-discovery命令，开启TCP连接的Path MTU探测功能。之后，设备会根据探测机制自动获得建立TCP连接的路径上最小的MTU值，并计算得到MSS值，后续建立BGP TCP连接时，会使用计算得到的MSS值作为TCP报文的长度。

如果无论怎么调整–s packet-size参数的取值，Ping的结果均为不可达，请参见“三层技术-IP业务类故障处理”手册中的“Ping不通的定位思路”进行后续的检查。

d. 如果故障仍不能排除，请执行步骤（2）

(2) 检查BGP TCP连接是否建立。

执行display tcp命令，查看显示信息中是否存在地址为本地路由器地址以及BGP邻居的地址、对端端口号为179、TCP连接状态为ESTABLISHED的条目。例如：

<Sysname> display tcp

*: TCP connection with authentication

Local Addr:port Foreign Addr:port State PCB

0.0.0.0:179 12.1.1.2:0 LISTEN 0xffffffffffffff9d

12.1.1.1:28160 12.1.1.2:179 ESTABLISHED 0xffffffffffffff9e

如果存在，则执行步骤（3）；如果不存在，则进行以下检查：

¡ 执行display ip routing-table或display ipv6 routing-table命令，查看路由表中是否存在对端建立BGP会话使用的IPv4/IPv6地址的IGP路由，如果不存在，请检查IGP路由的配置。常见的IGP路由协议故障处理方法，请参见“三层技术-IP路由类故障处理”手册中的“OSPF故障处理”、“OSPFv3故障处理”或“IS-IS故障处理”。

¡ 执行display acl all命令，查看是否存在拒绝端口号为bgp的规则，例如：

<Sysname> display acl all

Advanced IPv4 ACL 3077, 2 rules,

ACL's step is 5

rule 1 deny tcp destination-port eq bgp

rule 2 deny tcp source-port eq bgp

如果存在这样的规则，请执行undo rule命令取消这些配置。

¡ 执行debugging tcp packet命令，根据Debug信息判断BGP建立TCP连接时是否存在安全认证失败，例如：

<Sysname> debugging tcp packet acl 3000

*Feb 5 20:03:39:289 2021 Sysname SOCKET/7/INET: -MDC=1;

TCP Input: Failed to check md5, drop the packet.

上述信息表明BGP建立TCP连接时MD5认证失败。请在建立BGP TCP连接的两端设备上均执行peer password命令配置相同的密钥。

<Sysname> debugging tcp packet acl 3000

*Feb 5 20:03:39:289 2021 Sysname SOCKET/7/INET: -MDC=1;

TCP Input: Failed to check keychain, drop the packet.

上述信息表明BGP建立TCP连接时keychain认证失败。请确保建立BGP TCP连接的两端设备上均通过执行peer keychain命令配置了keychain认证，并且同一时间内使用的key的标识符相同，以及相同标识符的key的认证算法和认证密钥一致。

<Sysname> debugging tcp packet acl 3000

*Feb 5 20:03:39:289 2021 Sysname SOCKET/7/INET: -MDC=1;

TCP Input: Failed to get IPSEC profile, index 500, name profile1(inpcb profile2), return 0x3fff.

上述信息表明BGP建立TCP连接时IPsec认证失败。请检查BGP会话两端设备的IPsec配置并确保在两端设备上均通过执行peer ipsec-profile命令应用了IPsec安全框架。

如果故障仍不能排除，请执行步骤（3）。

(3) 检查Router ID是否存在冲突，AS号是否配置错误。

a. 执行display bgp peer命令，根据显示信息中的“BGP local router ID”字段，判断是否存在Router ID配置冲突，如果存在冲突，请在需要建立BGP会话的BGP实例视图或BGP-VPN实例视图下执行router-id命令，修改BGP路由器的Router ID。例如：

<Sysname> display bgp peer ipv4 unicast

BGP local router ID: 12.1.1.1

Local AS number: 10

Total number of peers: 1 Peers in established state: 1

* - Dynamically created peer

Peer AS MsgRcvd MsgSent OutQ PrefRcv Up/Down State

12.1.1.2 20 3 3 0 0 00:00:25 Established

b. 执行display bgp peer命令，根据显示信息中的“AS”字段，判断是否为BGP对等体/对等体组指定了错误的AS号。如果AS号配置错误，则执行peer as-number命令为BGP对等体/对等体组指定正确的AS号。例如：

<Sysname> display bgp peer ipv4 unicast

BGP local router ID: 12.1.1.1

Local AS number: 10

Total number of peers: 1 Peers in established state: 1

* - Dynamically created peer

Peer AS MsgRcvd MsgSent OutQ PrefRcv Up/Down State

12.1.1.2 20 3 3 0 0 00:00:25 Established

c. 如果故障仍不能排除，请执行步骤（4）。

(4) 在BGP实例视图下执行display this命令，检查是否存在影响BGP会话的配置。

表11 影响BGP会话的配置检查项

检查项	描述
peer { group-name \| ipv4-address [ mask-length ] \| ipv6-address [ prefix-length ] } connect-interface interface-type interface-number	本端存在该配置时，BGP邻居也需要使用Loopback接口的地址建立BGP会话，可通过本命令或peer source-address命令配置
peer ipv4-address [ mask-length ] source-address source-ipv4-address peer ipv6-address [ prefix-length ] source-address source-ipv6-address	本端存在该配置时，BGP邻居也需要使用Loopback接口的地址建立BGP会话，可通过本命令或peer connect-interface命令配置
peer { group-name \| ipv4-address [ mask-length ] \| ipv6-address [ prefix-length ] } ebgp-max-hop [ hop-count ]	非直连网络上的邻居建立EBGP会话，或者直连网络设备使用Loopback接口建立EBGP会话时，BGP会话两端均需要配置本命令，为EBGP会话指定相应的最大跳数
peer { group-name \| ipv4-address [ mask-length ] \| ipv6-address [ prefix-length ] } ttl-security hops hop-count	存在该配置时，本地路由器从指定对等体收到的BGP报文中，TTL需要在255-“hop-count”+1到255之间，否则BGP报文将会被丢弃，如果本地路由器与对等体之间的跳数超过了hop-count，请通过本命令进行配置修改
peer { group-name \| ipv4-address [ mask-length ] \| ipv6-address [ prefix-length ] \| link-local-address interface interface-type interface-number } route-limit prefix-number [ reconnect reconnect-time \| percentage-value ] *	存在该配置时，表示如果本地路由器从指定对等体/对等体组接收的路由数量大于prefix-number值，路由器会自动断开与指定对等体/对等体组的会话。可通过降低对等体/对等体组发送的路由数量，或配置更大的prefix-number值，来避免BGP会话断开
peer { group-name \| ipv4-address [ mask-length ] \| ipv6-address [ prefix-length ] \| link-local-address interface interface-type interface-number } ignore [ graceful graceful-time { community { community-number \| aa:nn } \| local-preference preference \| med med } * ]	存在该配置时，BGP将不会与指定的对等体/对等体组建立BGP会话，此时可以通过执行undo peer ignore命令允许建立与对等体/对等体组的会话
ignore all-peers [ graceful graceful-time { community { community-number \| aa:nn } \| local-preference preference \| med med } * ]	存在该配置时，表明BGP禁止与所有对等体建立BGP会话。此时设备可能处于网络升级维护中，BGP进程暂时不可用，建议在网络升级维护完成后，执行undo peer ignore命令或undo ignore all-peers命令允许建立BGP会话
shutdown process	存在该配置时，表明BGP禁止与所有对等体建立BGP会话。此时设备可能处于网络升级维护中，BGP进程暂时不可用，建议在网络升级维护完成后，执行undo shutdown process命令允许建立BGP会话
地址族下的peer enable命令	建立BGP会话时，两端需要在同一个地址族下指定对端配置peer enable命令使能路由信息交互能力。存在该配置时，请检查对端是否也在相同地址族下配置了peer enable命令

如果故障仍不能排除，请执行步骤（5）。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

10.1.2 BGP会话Down

1. 故障描述

在设备上观察到BGP/5/BGP_STATE_CHANGED提示BGP会话状态变为Idle的日志打印信息，会话状态从Established变为Idle。

2. 常见原因

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

· Keepalive或Update消息收发超时。

· TCP连接建立失败。

· 设备达到内存门限。

· BGP报文解析发生错误。

3. 故障分析

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

图66 BGP会话Down的故障诊断流程图

4. 处理步骤

执行display bgp peer log-info命令，根据该命令的显示信息进一步确认BGP会话Down的原因。几种常见的BGP会话Down的原因如下：

· BGP定时器超时导致断开会话

如果log-info信息与下面的显示信息相似：

<Sysname> display bgp peer ipv4 3.3.3.3 log-info

Peer: 3.3.3.3

Date Time State Notification

Error/SubError

17-Jan-2022 14:48:34 Down Receive notification with error 4/0

Hold Timer Expired/ErrSubCode Unspecified

Keepalive last triggered time: 14:48:31-2022.1.17

Keepalive last sent time : 14:48:31-2022.1.17

Update last sent time : 14:48:24-2022.1.17

EPOLLOUT last occurred time : 14:48:30-2022.1.17

则表示BGP会话Down的原因是在会话保持时间时间内未能收到对等体发送的Keepalive或Update消息。在BGP会话保持定时器超时后，设备则会主动断开BGP会话，并向对端对等体发送Notification消息。

定时器超时的原因可能是设备正常发送了Keepalive或Update消息，但报文由于链路故障等原因无法到达对等体或对等体处理不及时，或者设备调度故障导致未能及时产生Keepalive或Update消息等。如需解决此问题，请在BGP会话的两端设备的Probe视图下，均执行display system internal bgp log命令，并收集该命令的显示信息，联系技术支持人员进行进一步分析。

· TCP连接错误导致BGP会话断开

如果log-info信息与下面的显示信息相似：

<Sysname> display bgp peer ipv4 1.1.1.1 log-info

Peer: 1.1.1.1

Date Time State Notification

Error/SubError

17-Jan-2022 14:42:01 Down Receive TCP_Connection_Failed event

则BGP会话Down的原因是TCP连接错误。BGP使用TCP作为其传输层协议，如果BGP会话两端设备间的TCP连接发生错误，BGP会话也会断开。如果用户观察到的显示信息与上述举例不相似，但是显示信息中包含了Notification消息错误码5/0，则也是由于TCP连接错误导致的BGP会话断开。

确认TCP连接发生错误后，请在BGP会话Down的两端设备的Probe视图中，均执行view /proc/tcp/tcp_log slot x命令（所有的单板/成员设备各执行一次），并收集该命令的显示信息，联系技术支持人员进行进一步分析。

· 内存不足导致BGP会话断开

如果log-info信息与下面的显示信息相似：

<Sysname> display bgp peer ipv4 1.1.1.1 log-info

Peer: 1.1.1.1

Date Time State Notification

Error/SubError

17-Jan-2022 15:38:53 Down Send notification with error 6/8

Entered severe memory state

17-Jan-2022 14:53:51 Down Send notification with error 6/8

No memory to process the attribute

表明设备没有足够内存处理BGP模块相关功能，导致BGP会话断开。此类错误原因对应log-info信息中的错误码6/8。

此时请在BGP会话Down的两端设备上，均执行display memory-threshold命令，获取内存告警门限相关信息，并记录display bgp peer log-info命令的显示信息，联系技术支持人员进行进一步分析。

· 报文解析错误导致BGP会话断开：

BGP会话两端的设备如果报文解析能力不同或版本不匹配，则BGP可能无法解析接收到的报文，导致BGP会话断开。此类错误原因对应log-info信息中的消息差错码1、2和3（即“Error/SubError”中的“Error”为1、2或3）。

请在BGP会话Down的两端设备上，均执行debugging bgp raw-packet、debugging bgp open以及debugging bgp update命令，并收集这些命令的显示信息以及display bgp peer log-info命令的显示信息，联系技术支持人员进行进一步分析。

· 如果display bgp peer log-info命令的显示信息中，提示的BGP会话Down的原因不属于以上任何一种常见的原因，请收集如下信息，并联系技术支持人员。

¡ display bgp peer log-info命令的显示信息。

¡ display system internal bgp log命令的显示信息。

¡ view /proc/tcp/tcp_log slot x命令的显示信息（所有的单板/成员设备各执行一次）。

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

作为参考，BGP会话断开的详细原因及其对应的错误码如表12所示。

表12 邻居断开的详细原因列表

差错码/差错子码	会话断开的详细原因	说明
1/1	connection not synchronized	连接不同步，目前实现为收到的报文的报文头前16字节不全为F
1/2	bad message length	报文长度无效
1/3	bad message type	报文的类型无效
3/1	the withdrawn length is too large	撤销信息长度过长
	the attribute length is too large	属性长度过长
	one attribute appears more than once	同一个属性在一个Update消息中出现了多次
	the attribute length is too small	属性长度字段不足2字节
	exntended length field is less than two octets	属性长度为可扩展长度，但长度字段不足2字节
	the length field is less than one octet	属性长度为正常长度，但长度字段不足1字节
	link-state attribute error	链路状态属性形式错误
3/2	unrecognized well-known attribute	不支持的公认属性
3/3	attribute-type attribute missed	attribute-type类型的属性丢失，attribute-type取值包括： · ORIGIN · AS_PATH · LOCAL_PREF · NEXT_HOP
3/4	attribute flags error	属性标记错误
3/5	attribute-type attribute length error	attribute-type类型的属性长度错误，attribute-type取值包括： · AS_PATH · AS4_PATH · CLUSTER_LIST · AGGREGATOR · AS4_AGGREGATOR · ORIGIN · NEXT_HOP · MED · LOCAL_PREF · ATOMIC_AGGREGATE · ORIGINATOR_ID · MP_REACH_NLRI · COMMUNITIES · extended communities
3/5	attribute length exceeds	属性长度越界
3/6	invalid ORIGIN attribute	ORIGIN属性无效
3/8	invalid NEXT_HOP attribute	下一跳属性无效
3/9	invalid nexthop length in MP_REACH_NLRI (address-family)	address-family地址族MP_REACH_NLRI属性的Nexthop长度错误，address-family的取值包括： · 4u：表示IPv4单播地址族 · IPv4 Flowspec：表示IPv4 Flowspec地址族 · MPLS：表示MPLS地址族 · VPNv4：表示VPNv4地址族 · 6u：表示IPv6单播地址族 · VPNv6：表示VPNv6地址族 · L2VPN：表示L2VPN地址族
	the length of MP_UNREACH_NLRI is too small	MP_UNREACH_NLRI的长度小于3字节
	the MP NLRI attribute length exceeds	MP_REACH_NLRI 或MP_UNREACH_NLRI属性长度越界
	erroneous MP NLRI attribute end position	可达或不可达前缀结束位置与报文属性结束位置不同
3/10	invalid network field	网络字段无效
3/11	malformed AS_PATH	AS路径形式不对
4/0	Keepalive last triggered time	最后一次触发发送Keepalive消息时间
	Keepalive last sent time	最后一次发送Keepalive消息时间
	Update last sent time	最后一次发送Update消息时间
	EPOLLOUT last occurred time	最后一次发生EPOLLOUT时间
	Keepalive last received time	最后一次接收Keepalive消息时间
	Update last received time	最后一次接收Update消息时间
	EPOLLIN last occurred time	最后一次发生EPOLLIN时间
5/0	connection retry timer expires	ConnectRetry定时器超时
	TCP_CR_Acked event received	收到了TCP_CR_Acked事件
	TCP_Connection_Confirmed event received	收到了TCP_Connection_Confirmed事件
5/3	open message received	收到open消息
6/0	manualstop event received	收到manualstop事件
	physical interface configuration changed	物理配置改变，比如接口变化
	session down event received from BFD	收到BFD会话down事件
6/1	maximum number of prefixes reached	前缀数超过peer route-limit所配置的数目
6/1	maximum number of address-family prefixes reached	address-family地址族的前缀数超过peer route-limit所配置的数目，address-family的取值包括： · IPv4 unicast：表示IPv4单播地址族 · IPv6 unicast：表示IPv6单播地址族 · VPNv4：表示VPNv4地址族 · VPNv6：表示VPNv6地址族
6/2	configuration of peer ignore changed	配置peer ignore命令
6/3	address family deleted	地址族被删除
6/3	peer disabled	关闭对等体
6/4	administrative reset	执行reset bgp命令或者配置改变导致BGP会话重启
6/5	connection rejected	连接被拒绝
6/6	other configuration change	其他配置变化
6/7	connection collision resolution	连接冲突
6/7	two connections exist and MD5 authentication is configured for the neighbor	存在两个连接，且其中一个配置了MD5认证
6/8	· no memory to process the attribute：解析属性时内存不够 · no memory for the route：生成路由或者标签块信息时，获取不到内存 · no memory to generate unreachable NLRI：封装unreachable NLRI时申请不到内存 · no memory to generate a message：封装报文时申请不到内存 · can’t get the VPN RD：解析前缀时获取不到RD · can’t get the VPN routing table：解析前缀时获取不到VPN路由表 · can’t get the attributes：解析前缀时获取不到属性 · entered severe memory state：进入二级门限告警 · entered critical memory state：进入三级门限告警

5. 告警与日志

10.1.3 跨AS域的数据中心互联场景BGP路由环路

1. 故障描述

在图67所示的网络中，两个数据中心通过BGP协议跨AS进行互联。RR 1从数据中心2内的Border 3和Border 4处学习到前缀相同的BGP路由（假设路由前缀为10.110.0.0/16），路由的下一跳分别为Border 3和Border 4的Loopback接口地址，RR 1优选了来自Border 3或Border 4的路由。Border 1和Border 2通过BGP协议向RR 1发送缺省路由，缺省路由的下一跳分别为RR 1与Border 1之间的直连IP地址、RR 1与Border 2之间的直连IP地址。Border 3或Border 4重启时，在重启期间，数据中心1内的设备无法访问10.110.0.0/16网段，目的地址属于该网段内的数据报文在RR 1与Border 1之间或RR 1与Border 2之间循环发送，形成环路。

图67 跨AS域的数据中心互联场景组网图

2. 常见原因

在Border 3或Border 4未重启前，RR 1的BGP路由表和IP路由表与下表类似：

<RR1> display bgp routing-table ipv4

Total number of routes: 4

BGP local router ID is 9.9.9.9

Status codes: * - valid, > - best, d - dampened, h - history,

s - suppressed, S - stale, i - internal, e - external

a - additional-path

Origin: i - IGP, e - EGP, ? - incomplete

Network NextHop MED LocPrf PrefVal Path/Ogn

* >i 0.0.0.0/0 19.1.1.1 100 0 i

* i 29.1.1.2 100 0 i

* >e 10.110.0.0/16 3.3.3.3 0 0 20i

* e 4.4.4.4 0 0 20i

<RR1> display ip routing-table

Destinations : 25 Routes : 25

Destination/Mask Proto Pre Cost NextHop Interface

0.0.0.0/0 BGP 255 0 19.1.1.1 GE1/0/1

0.0.0.0/32 Direct 0 0 127.0.0.1 InLoop0

1.1.1.1/32 O_INTRA 10 1 19.1.1.1 GE1/0/1

2.2.2.2/32 O_INTRA 10 1 29.1.1.2 GE1/0/2

3.3.3.3/32 O_INTRA 10 1 39.1.1.3 GE1/0/3

4.4.4.4/32 O_INTRA 10 1 49.1.1.4 GE1/0/4

9.9.9.9/32 Direct 0 0 127.0.0.1 InLoop0

10.10.10.10/32 BGP 255 0 1.1.1.1 GE1/0/1

19.1.1.0/24 Direct 0 0 19.1.1.9 GE1/0/1

19.1.1.0/32 Direct 0 0 19.1.1.9 GE1/0/1

19.1.1.9/32 Direct 0 0 127.0.0.1 InLoop0

19.1.1.255/32 Direct 0 0 19.1.1.9 GE1/0/1

10.110.0.0/16 BGP 255 0 3.3.3.3 GE1/0/3

29.1.1.0/24 Direct 0 0 29.1.1.9 GE1/0/2

29.1.1.0/32 Direct 0 0 29.1.1.9 GE1/0/2

29.1.1.9/32 Direct 0 0 127.0.0.1 InLoop0

29.1.1.255/32 Direct 0 0 29.1.1.9 GE1/0/2

39.1.1.0/24 Direct 0 0 39.1.1.9 GE1/0/3

39.1.1.0/32 Direct 0 0 39.1.1.9 GE1/0/3

39.1.1.9/32 Direct 0 0 127.0.0.1 InLoop0

39.1.1.255/32 Direct 0 0 39.1.1.9 GE1/0/3

49.1.1.0/24 Direct 0 0 29.1.1.9 GE1/0/2

49.1.1.0/32 Direct 0 0 29.1.1.9 GE1/0/2

49.1.1.9/32 Direct 0 0 127.0.0.1 InLoop0

49.1.1.255/32 Direct 0 0 29.1.1.9 GE1/0/2

127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0

127.0.0.0/32 Direct 0 0 127.0.0.1 InLoop0

127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0

127.255.255.255/32 Direct 0 0 127.0.0.1 InLoop0

255.255.255.255/32 Direct 0 0 127.0.0.1 InLoop0

在上表中，RR 1通过IGP协议学习到Border 3和Border 4的Loopback接口路由。BGP网段路由10.110.0.0/16迭代到通过IGP学习的Border 3和Border 4的Loopback接口路由上。

假设Border 4进行了设备重启，在Border 4重启后，会话保持时间内RR 1仍不会断开与Border 4的会话，RR 1的路由表中仍会保留从Border 4接收到的10.110.0.0/16网段路由。但是由于下一跳4.4.4.4的IGP路由已经失效，且RR 1上不存在包含地址4.4.4.4的其他网段路由，来自Border 4的10.110.0.0/16网段路由只能迭代到缺省路由0.0.0.0/0上。

此时RR 1的BGP路由表中，来自Border 3的10.110.0.0/16网段路由到达下一跳的IGP路由的Metric值为1（对应上表中的路由表项“3.3.3.3/32 O_INTRA 10 1 39.1.1.3 GE1/0/3”），而来自Border 4的10.110.0.0/16网段路由到达下一跳的IGP路由的Metric值为0（对应上表中的路由表项“0.0.0.0/0 BGP 255 0 19.1.1.1 GE1/0/1”）。按照BGP路由的优选规则，RR 1优选来自Border 4的10.110.0.0/16网段路由，在路由转发表中，网段10.110.0.0/16的下一跳变为GigabitEehternet1/0/1。在转发目的地址属于10.110.0.0/16网段的报文时，RR 1会把报文错误地发送给Border 1，并且由于Border 1上10.110.0.0/16网段的路由学习自RR 1，Border 1又会把报文转发回RR 1，如此往复造成环路。

3. 故障分析

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

图68 跨AS域的数据中心互联场景BGP路由环路的故障诊断流程图

4. 处理步骤

(1) 查看RR 1的BGP路由表和IP路由表。本步骤以图67的组网为例，来说明RR 1上的BGP路由表和IP路由表情况。

a. Border 4重启后，在RR 1与Border 4的会话断开前，在RR 1上执行display bgp routing-table ipv4命令可以看到来自Border 4的10.110.0.0/16网段路由仍然生效，并且被优选了。

<RR1> display bgp routing-table ipv4

Total number of routes: 5

BGP local router ID is 9.9.9.9

Status codes: * - valid, > - best, d - dampened, h - history,

s - suppressed, S - stale, i - internal, e - external

a - additional-path

Origin: i - IGP, e - EGP, ? - incomplete

Network NextHop MED LocPrf PrefVal Path/Ogn

* >i 0.0.0.0/0 19.1.1.1 100 0 i

* i 29.1.1.2 100 0 i

* >e 10.110.0.0/16 4.4.4.4 0 0 20i

* e 3.3.3.3 0 0 20i

b. 在RR 1上执行display ip routing-table verbose命令，可以看到10.110.0.0/16网段路由的出接口和真实下一跳变为了RR 1与Border 1之间的直连接口GigabitEehternet1/0/1以及直连IP地址19.1.1.1。

<RR1> display ip routing-table 10.110.0.0/16 verbose

Summary count : 1

Destination: 10.110.0.0/16

Protocol: BGP instance default

Process ID: 0

SubProtID: 0x6 Age: 00h00m19s

FlushedAge: 00h00m19s

Cost: 0 Preference: 255

IpPre: N/A QosLocalID: N/A

Tag: 0 State: Active Adv

OrigTblID: 0x0 OrigVrf: default-vrf

TableID: 0x2 OrigAs: 20

NibID: 0x16000002 LastAs: 20

AttrID: 0x2

BkAttrID: 0xffffffff Neighbor: 4.4.4.4

Flags: 0x10060 OrigNextHop: 4.4.4.4

Label: NULL RealNextHop: 19.1.1.1

BkLabel: NULL BkNextHop: N/A

SRLabel: NULL Interface: GigabitEthernet1/0/1

BkSRLabel: NULL BkInterface: N/A

Tunnel ID: Invalid IPInterface: GigabitEthernet1/0/1

BkTunnel ID: Invalid BkIPInterface: N/A

InLabel: NULL ColorInterface: N/A

SIDIndex: NULL BkColorInterface: N/A

FtnIndex: 0x0 TunnelInterface: N/A

TrafficIndex: N/A BkTunnelInterface: N/A

Connector: N/A PathID: 0x0

UserID: 0x0 SRTunnelID: Invalid

SID Type: N/A NID: Invalid

FlushNID: Invalid BkNID: Invalid

BkFlushNID: Invalid StatFlags: 0x0

SID: N/A

BkSID: N/A

CommBlockLen: 0 Priority: Low

MemberPort: N/A

c. 执行display ip routing-table命令，可以看到IP路由表中没有包含地址4.4.4.4的其他网段路由，缺省路由的下一跳出接口和下一跳IP也为GigabitEehternet1/0/1和19.1.1.1，由此可以判断出，来自Border 4的10.110.0.0/16网段路由迭代到了缺省路由上。

<RR1> display ip routing-table

Destinations : 25 Routes : 25

Destination/Mask Proto Pre Cost NextHop Interface

0.0.0.0/0 BGP 255 0 19.1.1.1 GE1/0/1

0.0.0.0/32 Direct 0 0 127.0.0.1 InLoop0

1.1.1.1/32 O_INTRA 10 1 19.1.1.1 GE1/0/1

2.2.2.2/32 O_INTRA 10 1 29.1.1.2 GE1/0/2

3.3.3.3/32 O_INTRA 10 1 39.1.1.3 GE1/0/3

9.9.9.9/32 Direct 0 0 127.0.0.1 InLoop0

10.10.10.10/32 BGP 255 0 1.1.1.1 GE1/0/1

19.1.1.0/24 Direct 0 0 19.1.1.9 GE1/0/1

19.1.1.0/32 Direct 0 0 19.1.1.9 GE1/0/1

19.1.1.9/32 Direct 0 0 127.0.0.1 InLoop0

19.1.1.255/32 Direct 0 0 19.1.1.9 GE1/0/1

10.110.0.0/16 BGP 255 0 4.4.4.4 GE1/0/1

29.1.1.0/24 Direct 0 0 29.1.1.9 GE1/0/2

29.1.1.0/32 Direct 0 0 29.1.1.9 GE1/0/2

29.1.1.9/32 Direct 0 0 127.0.0.1 InLoop0

29.1.1.255/32 Direct 0 0 29.1.1.9 GE1/0/2

39.1.1.0/24 Direct 0 0 39.1.1.9 GE1/0/3

39.1.1.0/32 Direct 0 0 39.1.1.9 GE1/0/3

39.1.1.9/32 Direct 0 0 127.0.0.1 InLoop0

39.1.1.255/32 Direct 0 0 39.1.1.9 GE1/0/3

49.1.1.0/24 Direct 0 0 29.1.1.9 GE1/0/2

49.1.1.0/32 Direct 0 0 29.1.1.9 GE1/0/2

49.1.1.9/32 Direct 0 0 127.0.0.1 InLoop0

49.1.1.255/32 Direct 0 0 29.1.1.9 GE1/0/2

127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0

127.0.0.0/32 Direct 0 0 127.0.0.1 InLoop0

127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0

127.255.255.255/32 Direct 0 0 127.0.0.1 InLoop0

255.255.255.255/32 Direct 0 0 127.0.0.1 InLoop0

如果查看路由表项的结果与上述情形不符，请联系技术支持人员获得帮助。

(2) 通过以下两种方式中的一种消除路由环路。

¡ 配置根据路由策略来过滤迭代到的下一跳路由。

在RIB IPv4地址族视图下配置protocol bgp nexthop recursive-lookup route-policy route-policy-name命令后，所有IPv4地址前缀的BGP路由的下一跳都只能迭代到通过路由策略route-policy-name过滤的路由上；在RIB IPv6地址族视图下配置protocol bgp4+ nexthop recursive-lookup route-policy route-policy-name命令后，所有IPv6地址前缀的BGP路由的下一跳都只能迭代到通过路由策略route-policy-name过滤的路由上。

在本故障诊断的场景下，可以在RR 1上创建一个缺省路由无法通过过滤的路由策略，并配置protocol bgp nexthop recursive-lookup route-policy route-policy-name或protocol bgp nexthop recursive-lookup route-policy route-policy-name命令指定该路由策略，使得BGP路由无法迭代到缺省路由上，从而消除BGP路由环路。

¡ 配置BGP与BFD联动功能。

开启BGP与BFD联动功能后，RR 1和Border 3、Border 4之间会使用BFD会话来检测链路，当Border 3或Border 4重启时，BFD可以快速检测到链路故障，RR 1会及时断开BGP会话，删除失效路由，即从Border 3或Border 4学习到的路由。BGP与BFD联动功能通过peer bfd命令进行配置，配置的详细指导以及注意事项请参见命令参考手册。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

10.1.4 Spine和Leaf设备跨AS连接场景BGP路由环路

1. 故障描述

在图69所示的网络中，Spine设备与Leaf设备处在不同的AS域中。Spine设备之间建立全互联的BGP连接，Spine 1和Spine 2与Leaf建立EBGP连接。Spine 2开启了负载分担功能，并且可以在EBGP和IBGP路由之间进行负载分担。Spine 1重启时，经过Spine 2到Leaf的流量有一半丢失。

图69 Spine和Leaf设备跨AS连接场景组网图

2. 常见原因

在Spine 1重启前，Spine 2的BGP路由表与下表类似：

<Spine2> display bgp routing-table ipv4

Total number of routes: 3

BGP local router ID is 2.2.2.2

Status codes: * - valid, > - best, d - dampened, h - history,

s - suppressed, S - stale, i - internal, e - external

a - additional-path

Origin: i - IGP, e - EGP, ? - incomplete

Network NextHop MED LocPrf PrefVal Path/Ogn

* >i 0.0.0.0/0 24.1.1.4 100 0 i

* >e 100.1.1.0/24 23.1.1.3 0 0 20i

* i 1.1.1.1 0 100 0 20i

Leaf 2分别从Leaf 1（23.1.1.3）和Spine 1（1.1.1.1）接收到100.1.1.0/24网段路由，从Spine 1接收到的100.1.1.0/24网段路由的下一跳为Spine 1的Loopback接口地址。

Spine 2的IP路由表与下表类似：

<Spine2> display ip routing-table

Destinations : 24 Routes : 25

Destination/Mask Proto Pre Cost NextHop Interface

0.0.0.0/0 BGP 255 0 24.1.1.4 GE1/0/1

0.0.0.0/32 Direct 0 0 127.0.0.1 InLoop0

1.1.1.1/32 O_INTRA 10 1 12.1.1.1 GE1/0/2

2.2.2.2/32 Direct 0 0 127.0.0.1 InLoop0

4.4.4.4/32 O_INTRA 10 1 24.1.1.4 GE1/0/1

12.1.1.0/24 Direct 0 0 12.1.1.2 GE1/0/2

12.1.1.0/32 Direct 0 0 12.1.1.2 GE1/0/2

12.1.1.2/32 Direct 0 0 127.0.0.1 InLoop0

12.1.1.255/32 Direct 0 0 12.1.1.2 GE1/0/2

14.1.1.0/24 O_INTRA 10 2 12.1.1.1 GE1/0/2

O_INTRA 10 2 24.1.1.4 GE1/0/1

23.1.1.0/24 Direct 0 0 23.1.1.2 GE1/0/3

23.1.1.0/32 Direct 0 0 23.1.1.2 GE1/0/3

23.1.1.2/32 Direct 0 0 127.0.0.1 InLoop0

23.1.1.255/32 Direct 0 0 23.1.1.2 GE1/0/3

24.1.1.0/24 Direct 0 0 24.1.1.2 GE1/0/1

24.1.1.0/32 Direct 0 0 24.1.1.2 GE1/0/1

24.1.1.2/32 Direct 0 0 127.0.0.1 InLoop0

24.1.1.255/32 Direct 0 0 24.1.1.2 GE1/0/1

100.1.1.0/24 BGP 255 0 23.1.1.3 GE1/0/3

127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0

127.0.0.0/32 Direct 0 0 127.0.0.1 InLoop0

127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0

127.255.255.255/32 Direct 0 0 127.0.0.1 InLoop0

255.255.255.255/32 Direct 0 0 127.0.0.1 InLoop0

对于来自Leaf的100.1.1.0/24网段路由，到达其下一跳的IGP路由为23.1.1.0/24，该IGP路由的Metric为0；对于来自Spine 1的100.1.1.0/24网段路由，到达其下一跳的IGP路由为1.1.1.1/32该IGP路由的Metric值为1。由于到达两条路由的下一跳的IGP路由的Metric值不相同，BGP路由表中两条100.1.1.0/24网段路由无法形成负载分担。这也是网络管理员需要的结果：到达Spine 2的目的地址属于100.1.1.0/24网段的流量，会被Spine 2全部直接转发给Leaf；而不是先发往Spine 1，再由Spine 1转发至Leaf。

Spine 3通过BGP协议向Spine 2发送了缺省路由，缺省路由的下一跳为Spine 3与Spine 2直连的接口IP地址。Spine 1重启后，在会话保持时间内，Spine 2仍不会断开与Spine 1的会话，Spine 2的路由表中仍会保留从Spine 1接收到的100.1.1.0/24网段路由。但是由于下一跳1.1.1.1的IGP路由已经失效，且Spine 2上不存在包含地址1.1.1.1的其他网段路由，来自Spine 1的100.1.1.0/24网段路由只能迭代到缺省路由0.0.0.0/0上。

此时Spine 2的BGP路由表中，来自Spine 1的100.1.1.0/24网段路由到达下一跳的IGP路由的Metric值变为0（对应上表中的路由表项“0.0.0.0/0 BGP 255 0 24.1.1.4 GE1/0/1”），与来自Leaf的100.1.1.0/24网段路由到达下一跳的IGP路由的Metric值相同。来自不同BGP对等体的两条100.1.1.0/24网段路由形成负载分担，导致经过Spine 2的目的地址属于100.1.1.0/24网段的流量有一半通过负载分担被发送给了Spine 3。而由于Spine 3上100.1.1.0/24的网段路由学习自Spine 1和Spine 2，Spine 3又会把流量转发回Spine 2，造成环路和路由丢失。

3. 故障分析

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

图70 Spine和Leaf设备跨AS连接场景BGP路由环路的诊断流程图

4. 处理步骤

(1) 查看Spine 2的BGP路由表和IP路由表。本步骤以图69的组网为例，来说明Spine 2上的BGP路由表和IP路由表情况。

a. Spnie 1重启后，在Spnie 1与Spnie 2的会话断开前，在Spnie 2上执行display bgp routing-table ipv4命令可以看到来自不同设备的两条100.1.1.0/24网段路由同时被优选。

<Spine2> display bgp routing-table ipv4

Total number of routes: 3

BGP local router ID is 2.2.2.2

Status codes: * - valid, > - best, d - dampened, h - history,

s - suppressed, S - stale, i - internal, e - external

a - additional-path

Origin: i - IGP, e - EGP, ? - incomplete

Network NextHop MED LocPrf PrefVal Path/Ogn

* >i 0.0.0.0/0 24.1.1.4 100 0 i

* >e 100.1.1.0/24 23.1.1.3 0 0 20i

* >i 1.1.1.1 0 100 0 20i

b. 在Spine 2上执行display ip routing-table verbose命令，可以看到100.1.1.0/24网段的两条路由形成了等价，并且其中一条路由的真实下一跳为Spine 3的接口IP地址24.1.1.4、出接口为Spine 2与Spine 3直连的接口。

<Spine2> display ip routing-table 100.1.1.0/24 verbose

Summary count : 2

Destination: 100.1.1.0/24

Protocol: BGP instance default

Process ID: 0

SubProtID: 0x5 Age: 00h00m13s

FlushedAge: 00h00m13s

Cost: 0 Preference: 255

IpPre: N/A QosLocalID: N/A

Tag: 0 State: Active Adv

OrigTblID: 0x0 OrigVrf: default-vrf

TableID: 0x2 OrigAs: 20

NibID: 0x16000002 LastAs: 10

AttrID: 0x2

BkAttrID: 0xffffffff Neighbor: 1.1.1.1

Flags: 0x10060 OrigNextHop: 1.1.1.1

Label: NULL RealNextHop: 24.1.1.4

BkLabel: NULL BkNextHop: N/A

SRLabel: NULL Interface: GigabitEthernet1/0/1

BkSRLabel: NULL BkInterface: N/A

Tunnel ID: Invalid IPInterface: GigabitEthernet1/0/1

BkTunnel ID: Invalid BkIPInterface: N/A

InLabel: NULL ColorInterface: N/A

SIDIndex: NULL BkColorInterface: N/A

FtnIndex: 0x0 TunnelInterface: N/A

TrafficIndex: N/A BkTunnelInterface: N/A

Connector: N/A PathID: 0x0

UserID: 0x0 SRTunnelID: Invalid

SID Type: N/A NID: Invalid

FlushNID: Invalid BkNID: Invalid

BkFlushNID: Invalid StatFlags: 0x0

SID: N/A

BkSID: N/A

CommBlockLen: 0 Priority: Low

MemberPort: N/A

Destination: 100.1.1.0/24

Protocol: BGP instance default

Process ID: 0

SubProtID: 0x6 Age: 01h18m22s

FlushedAge: 00h00m13s

Cost: 0 Preference: 255

IpPre: N/A QosLocalID: N/A

Tag: 0 State: Active Adv

OrigTblID: 0x0 OrigVrf: default-vrf

TableID: 0x2 OrigAs: 20

NibID: 0x16000000 LastAs: 20

AttrID: 0x0

BkAttrID: 0xffffffff Neighbor: 23.1.1.3

Flags: 0x10060 OrigNextHop: 23.1.1.3

Label: NULL RealNextHop: 23.1.1.3

BkLabel: NULL BkNextHop: N/A

SRLabel: NULL Interface: GigabitEthernet1/0/3

BkSRLabel: NULL BkInterface: N/A

Tunnel ID: Invalid IPInterface: GigabitEthernet1/0/3

BkTunnel ID: Invalid BkIPInterface: N/A

InLabel: NULL ColorInterface: N/A

SIDIndex: NULL BkColorInterface: N/A

FtnIndex: 0x0 TunnelInterface: N/A

TrafficIndex: N/A BkTunnelInterface: N/A

Connector: N/A PathID: 0x0

UserID: 0x0 SRTunnelID: Invalid

SID Type: N/A NID: Invalid

FlushNID: Invalid BkNID: Invalid

BkFlushNID: Invalid StatFlags: 0x0

SID: N/A

BkSID: N/A

CommBlockLen: 0 Priority: Low

MemberPort: N/A

c. 执行display ip routing-table命令，可以看到IP路由表中没有包含地址1.1.1.1的其他网段路由，缺省路由的下一跳出接口和下一跳IP也为GigabitEehternet1/0/1和24.1.1.4，由此可以判断出，来自Spine 1的100.1.1.0/24网段路由迭代到了缺省路由上。

<Spine2> display ip routing-table

Destinations : 23 Routes : 24

Destination/Mask Proto Pre Cost NextHop Interface

0.0.0.0/0 BGP 255 0 24.1.1.4 GE1/0/1

0.0.0.0/32 Direct 0 0 127.0.0.1 InLoop0

2.2.2.2/32 Direct 0 0 127.0.0.1 InLoop0

4.4.4.4/32 O_INTRA 10 1 24.1.1.4 GE1/0/1

12.1.1.0/24 Direct 0 0 12.1.1.2 GE1/0/2

12.1.1.0/32 Direct 0 0 12.1.1.2 GE1/0/2

12.1.1.2/32 Direct 0 0 127.0.0.1 InLoop0

12.1.1.255/32 Direct 0 0 12.1.1.2 GE1/0/2

14.1.1.0/24 O_INTRA 10 2 24.1.1.4 GE1/0/1

23.1.1.0/24 Direct 0 0 23.1.1.2 GE1/0/3

23.1.1.0/32 Direct 0 0 23.1.1.2 GE1/0/3

23.1.1.2/32 Direct 0 0 127.0.0.1 InLoop0

23.1.1.255/32 Direct 0 0 23.1.1.2 GE1/0/3

24.1.1.0/24 Direct 0 0 24.1.1.2 GE1/0/1

24.1.1.0/32 Direct 0 0 24.1.1.2 GE1/0/1

24.1.1.2/32 Direct 0 0 127.0.0.1 InLoop0

24.1.1.255/32 Direct 0 0 24.1.1.2 GE1/0/1

100.1.1.0/24 BGP 255 0 1.1.1.1 GE1/0/1

BGP 255 0 23.1.1.3 GE1/0/3

127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0

127.0.0.0/32 Direct 0 0 127.0.0.1 InLoop0

127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0

127.255.255.255/32 Direct 0 0 127.0.0.1 InLoop0

255.255.255.255/32 Direct 0 0 127.0.0.1 InLoop0

如果查看路由表项的结果与上述情形不符，请联系技术支持人员获得帮助。

(2) 通过以下三种方式中的一种来消除路由环路。

¡ 配置根据路由策略来过滤迭代到的下一跳路由。

在本故障诊断的场景下，可以在Spine 2上创建一个缺省路由无法通过过滤的路由策略，并配置protocol bgp nexthop recursive-lookup route-policy route-policy-name或protocol bgp nexthop recursive-lookup route-policy route-policy-name命令指定该路由策略，使得BGP路由无法迭代到缺省路由上，从而消除BGP路由环路。

¡ 配置BGP与BFD联动功能。

开启BGP与BFD联动功能后，Spine 1和Spine 2之间会使用BFD会话来检测链路，当Spine 1重启时，BFD可以快速检测到链路故障，Spine 2会及时断开BGP会话，删除失效路由，即从Spine 1学习到的路由。BGP与BFD联动功能通过peer bfd命令进行配置，配置的详细指导以及注意事项请参见命令参考手册。

¡ 配置BGP负载分担时，不允许设备在EBGP和IGBP路由之间进行负载分担。

本例中的两条100.1.1.0/24网段路由分别来自IBGP会话和EBGP会话，在BGP进程中配置balance命令时，只要不指定eibgp参数，设备就不会在EBGP和IBGP路由之间进行负载分担，Spine 2就能根据BGP的选路规则只优选来自Leaf的100.1.1.0/24网段路由，保证全部流量的正常转发。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

10.2 IS-IS故障处理

10.2.1 IS-IS邻居无法建立

1. 故障描述

· IS-IS邻居Down。

· IS-IS邻居关系震荡。

2. 常见原因

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

· 设备底层故障或者链路故障，导致IS-IS无法正常的收发Hello报文。

· 链路两端的设备配置的System ID相同。

· 链路两端接口的MTU设置不一致，或者接口的MTU小于发送的Hello报文的长度。

· 链路两端接口的IP地址不在同一网段。

· 链路两端的IS-IS接口认证方式不匹配。

· 链路两端的IS-IS Level不匹配。

· 建立IS-IS Level-1邻居时，链路两端设备的区域地址不匹配。

3. 故障分析

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

图71 IS-IS邻居无法建立的故障诊断流程图

4. 处理步骤

(1) 检查接口的物理层状态是否为Up。

请执行display interface [ interface-type [ interface-number | interface-number.subnumber ] ]命令查看IS-IS接口物理层状态，如果接口物理层状态为Down，请先处理接口故障问题。如果接口物理状态为Up，请执行步骤(2)。

(2) 检查链路是否故障。

请执行ping命令，检查设备链路是否故障（包括传输设备故障）。如果链路正常，请执行步骤(3)。

如果设备支持isis bfd session-restrict-adj 命令且IS-IS使用BFD检测设备间链路，可通过isis bfd session-restrict-adj命令开启BFD抑制IS-IS建立和保持邻接关系的功能后，接口发送的Hello报文中将会携带BFD-enabled TLV，当两端BFD-enabled TLV中的信息一致时，抑制IS-IS建立和保持邻居关系的功能生效。当BFD会话Down时，无法建立IS-IS邻居关系。

请执行display bfd session命令查看检测IS-IS两端链路的BFD会话的状态，如果“State”字段取值为“Down”，请排除链路故障。如果“State”字段取值为“Up”，请执行步骤(3)。

(3) 检查CPU或内存利用率是否过高。

请执行display cpu-usage命令检查故障设备的主控板和接口板的CPU利用率是否过高。如果CPU利用率过高，IS-IS将无法正常收发协议报文，从而导致邻居关系震荡。可通过关闭一些不必要的功能解决此问题。如果CPU利用率不高，则执行步骤(4)。

请执行display memory-threshold命令，查看显示信息中的Current free-memory state，即系统当前内存使用状态。如果Current free-memory state为Minor、Severe或Critical，表示剩余空闲内存较少，可能会导致设备无法收发IS-IS报文或处理IS-IS报文速度较慢，请关闭一些不必要的功能尝试解决此问题。如果系统当前内存使用状态为Normal，则执行步骤(4)。

(4) 检查接口在IS-IS协议下的状态是否正常。

请执行display isis interface命令，检查使能了IS-IS的接口的状态（“IPv4 state”或“IPv6 state”字段）是否为正常状态。

¡ 如果IS-IS接口状态为“Lnk:Up/IP:Dn”，说明IPv4或IPv6相邻节点的链路层可达、网络层不可达，请处理网络层故障问题。

¡ 如果IS-IS接口状态为“Up”，请执行步骤(5)。

(5) 检查两端IP地址是否在同一网段。

对于IPv4 IS-IS，请执行display interface brief命令查看两端接口的IPv4地址。

¡ 如果两端接口的IPv4地址不在同一网段，请在接口视图下执行ip address命令修改两端的IPv4地址，使其在同一网段。

¡ 如果两端接口的IPv4地址处于同一网段，请执行(6)。

对于IPv6 IS-IS，无需执行此检查。

(6) 检查各IS-IS接口的MTU是否一致。

请执行display interface [ interface-type [ interface-number | interface-number.subnumber ] ]命令命令查看接口MTU信息。

¡ 如果接口的MTU值配置不一致，请在接口视图下执行mtu size命令，将各个接口的MTU值修改为一致。

¡ 如果接口的MTU值一致，请执行(7)。

(7) 检查IS-IS能否接收到Hello报文。

请执行display isis packet hello by-interface verbose命令，检查IS-IS能否接收到Hello报文。如果设备无法接收Hello报文，请排除丢包问题。如果故障依然存在，请执行(12)。

如果设备能够接收Hello报文，请继续执行以下检查：

¡ 如果“Duplicate system ID”字段的统计计数随时间增长，说明System ID冲突。请执行步骤(8)。

¡ 如果“Mismatched level (LAN)”字段的统计计数随时间增长，说明Level不匹配。请执行步骤(9)。

¡ 如果“Bad area address TLV”字段的统计计数随时间增长，说明区域地地址不匹配。请执行步骤(10)。

¡ 如果其他字段的统计计数随时间增长，请执行步骤(12)。

(8) 检查链路两端的设备配置的System ID是否相同。

请执行display current-configuration isis命令检查链路两端的设备配置的System ID是否相同。

¡ 如果两端System ID相同，请修改配置，使两端的System ID不同。

¡ 如果两端System ID不相同，请执行步骤(9)。

(9) 检查链路两端的设备的IS-IS Level是否匹配。

请检查设备及IS-IS接口的Level级别：

¡ 请执行display current-configuration | include is-level命令，检查链路两端设备的Level级别。如果通过display current-configuration | include is-level命令无法查询到设备的Level级别的相关配置，表明设备的Level级别为缺省值为Level-1-2。

¡ 请执行display current-configuration interface interface-type interface-number | include circuit-level命令，检查接口的链路邻接关系类型。如果通过display current-configuration interface interface-type interface-number | include circuit-level命令无法查询到接口的链路邻接关系类型，说明接口的链路邻接关系类型为缺省值，这种情况下，该接口既可以建立Level-1的邻接关系，也可以建立Level-2的邻接关系。

需要保证链路两端的Level匹配才能建立IS-IS邻居关系，接口Level匹配的原则如下：

¡ 如果本端接口Level级别为Level-1，则对端接口Level级别必须为Level-1或Level-1-2。

¡ 如果本端接口Level级别为Level-2，则对端接口Level级别必须为Level-2或Level-1-2。

¡ 如果本端接口Level级别为Level-1-2，则对端接口Level级别可以为Level-1、Level-2或Level-1-2。

对于不同的情况，请选择不同的处理方式：

¡ 如果链路两端设备的IS-IS Level不匹配，请在IS-IS视图下使用is-level命令修改设备的IS-IS级别，或者在接口视图下使用isis circuit-level命令修改接口的Level级别。

¡ 如果链路两端设备的IS-IS Level匹配，请执行步骤(10)。

(10) 检查链路两端设备的区域地址是否匹配。

请执行display isis命令查看“Network entity”字段，检查链路两端设备的区域地址是否匹配。“Network entity”的格式为X…X.XXXX.XXXX.XXXX.00，前面的“X…X”是区域地址，中间的12个“X”是交换机的System ID，最后的“00”是SEL。

¡ 如果链路两端建立Level-1邻居，需要保证链路两端设备在同一个区域内。建立IS-IS Level-2邻居时，不需要判断区域地址是否匹配。

当建立Level-1邻居的两端设备区域地址不同时，请在IS-IS视图下使用network-entity命令修改设备的区域地址。

¡ 如果链路两端区域地址匹配，请执行步骤(11)。

(11) 检查链路两端设备的认证方式是否匹配。

请执行display current-configuration interface-type interface-number | include isis命令检查链路两端设备IS-IS接口的认证方式。

a. 如果两端认证类型不匹配，请在链路两端设备的IS-IS接口视图下执行isis authentication-mode命令，将两端设置为相同的认证类型。

b. 如果认证方式相同的情况下，IS-IS仍然无法建立邻居关系，请将两端设置为相同的认证密码。

如果故障依然存在，请执行步骤(12)。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

10.2.2 设备学习不到IS-IS路由

1. 故障描述

设备学习不到IS-IS路由。

2. 常见原因

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

· 其它路由协议也发布了相同的路由，并且路由协议优先级比IS-IS协议高。

· 引入的外部路由优先级低，没有被优选。

· 引入的外部路由类型不同，没有被优选。IS-IS开销值类型不匹配。

· IS-IS邻居没有正常建立。

· 两台设备的System ID配置相同。

· LSP报文认证不匹配。

· 设备底层故障或者链路故障，造成LSP报文丢失。

· LSP长度超过了设备可以接收的LSP的最大长度。

3. 故障分析

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

图72 设备学习不到IS-IS路由的故障诊断流程图

4. 处理步骤

(1) 检查IS-IS路由表是否正确。

请执行display isis route命令，查看IS-IS路由表。

¡ 如果IS-IS路由表中存在指定的路由，请执行display ip routing-table ip-address [ mask | mask-length ] verbose命令查看IP路由表中是否存在协议优先级比IS-IS高的路由。

- 如果存在，请根据网络规划调整配置。

- 如果不存在，请执行步骤(7)。

¡ 如果IS-IS路由表中不存在指定的路由，请执行步骤(2)。

(2) 检查指定的IS-IS路由是否发布。

在发布指定路由的设备上，执行display isis lsdb verbose local命令，查看本地产生的LSP报文中是否携带了指定路由。

¡ 如果LSP报文中没有携带指定的路由，请检查IS-IS配置是否正确，例如接口是否使能IS-IS。如果指定的路由是IS-IS引入的外部路由，请执行display ip routing-table protocol protocol verbose命令查看该路由的“State”字段，当“State”字段的取值中包含“Inactive”时，说明外部路由处于非激活状态，这种情况下，IS-IS不会将此路由发布出去。请检查外部路由的配置，使该路由的“State”取值包含“Active”和“Adv”。

¡ 如果LSP报文中携带了指定的路由，请执行步骤(7)。

(3) 检查指定的IS-IS路由的开销类型是否一致。

多台设备通过路由引入的方式发布到达同一目的地的路由，并希望这些外部路由形成等价路由的场景中，需要检查IS-IS引入路由的开销类型是否一致。不同的开销类型的路由开销值不同，具体如下：

¡ 如果开销类型为external，那么IS-IS通过LSP发布引入的外部路由时，该路由的开销值为原有开销值＋64。

¡ 如果开销类型为internal，那么IS-IS通过LSP发布引入的外部路由时，该路由的开销值为原有开销值。

缺省情况下，我司设备引入的外部路由的开销类型为external。如果其他厂商设备引入外部路由的开销类型与我司缺省情况不同，会导致到达同一目的地的路由开销不同。邻居设备会优选开销最小的路由。对于这种情况，请修改引入外部路由的开销类型，保证各厂商设备引入外部路由的开销类型相同。修改我司设备引入外部路由的开销类型的步骤如下：

a. 在发布指定路由的设备上，执行display current-configuration configuration isis命令检查IS-IS引入外部路由的配置。

b. 通过import-route命令修改引入外部路由的开销类型。

上述情况外的其他情况，请执行步骤(4)。

(4) 检查IS-IS的数据库是否同步。

在学习不到IS-IS路由的设备上，执行display isis lsdb命令，查看是否收到发布指定路由的设备的LSP报文。

¡ 如果LSDB数据库中不存在指定的LSP报文，请排查是否存在链路故障。如果不存在链路故障，请通过display isis命令查看“LSP length receive”字段的取值，判断指定的LSP报文长度是否超过了设备可以接收的LSP报文的最大长度。当“LSP length receive”字段的取值超过了设备可以接收的LSP报文的最大长度时，请在生成LSP的设备上通过lsp-length originate命令将生成LSP报文的最大长度配置为该区域内所有IS-IS接口MTU的最小值。

¡ 如果LSDB数据库中存在指定的LSP报文，但Seq Num与发布该LSP的设备上通过display isis lsdb local verbose命令显示的Seq Num不一致，并且Seq Num在不停地增长，则网络中存在其他设备与发布指定路由的设备的System ID配置相同，请排查并修改网络中设备的System ID配置。

¡ 如果LSDB数据库中存在指定的LSP报文，但Seq Num与发布该LSP的设备上通过display isis lsdb local verbose命令显示的Seq Num不一致，并且一直保持不变，可能是LSP报文在传输过程中被丢弃，请排查设备底层和中间链路是否存在故障。

¡ 如果LSDB数据库中存在指定的LSP报文，并且Seq Num与发布该LSP的设备上通过display isis lsdb local verbose命令显示的Seq Num一致，请执行步骤(7)。

(5) 检查IS-IS开销值类型是否匹配。

分别在发布路由的设备和学习不到路由的设备上，执行display isis命令，查看“Cost style”的取值，检查两端的IS-IS开销值类型是否匹配。只有开销值类型相同时，才能学到路由。

¡ 如果链路两端设备的IS-IS开销值类型不匹配，请在IS-IS视图下执行cost-style命令修改配置。

¡ 如果两端设备的IS-IS开销值类型匹配，请执行步骤(7)。

(6) 检查IS-IS邻居是否正常建立。

在路径上的每一台设备上执行display isis peer命令，查看IS-IS邻居是否都正常建立。

¡ 如果存在邻居没有正常建立的情况，请参见“IS-IS邻居无法建立”。

¡ 如果不存在邻居未能正常建立的情况，请执行步骤(7)。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

10.2.3 IS-IS路由震荡

1. 故障描述

IS-IS路由反复增删。

2. 常见原因

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

· IS-IS邻居震荡。

· MPLS LSP隧道震荡。

· 两台设备的IS-IS引入了相同的外部路由，并且外部路由的优先级比IS-IS协议的优先级低。

· 两台设备配置的System ID相同。

3. 故障分析

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

图73 IS-IS路由震荡的故障诊断流程图

4. 处理步骤

(1) 检查路由震荡的情况。

执行display ip routing-table ip-address verbose命令，查看路由震荡的具体情况，具体步骤如下：

¡ 如果路由震荡的前后，“TunnelID”字段发生了变化，请检查MPLS LSP隧道是否存在震荡。

执行display mpls lsp verbose命令，通过“Last Chg Time”字段查看LDP的LSP最近一次状态变化的时间。如果最近一次变化的时间距离执行display mpls lsp verbose命令的时间较近，说明MPLS LSP隧道存在震荡）。

对于这种情况，请参考LDP LSP震荡的定位思路或TE Tunnel由Up突然变Down的定位思路，排查LSP震荡问题。

¡ 如果路由的“Cost”或者“Interface”字段发生变化，请检查该路由路径上的IS-IS邻居是否在震荡。

¡ 如果路由在路由表中时有时无（Age字段在震荡），执行display isis lsdb verbose命令，找到携带该路由的LSP，并记录此LSP报文的LSPID。然后，执行display isis lsdb verbose lsp-id命令查看这条LSP的更新情况。

- 如果LSP中一直携带指定的路由，请检查该路由路径上是否存在IS-IS邻居震荡。

- 如果LSP的“Seq Num”字段的取值在不停的增加，并且LSP更新前后的内容差异很大，请检查网络中是否有两台设备配置了相同的System ID。

- 如果LSP的“Seq Num”字段的取值在不停的增加，并且LSP更新前后，指定的路由时有时无，请在产生该LSP的设备上执行步骤(2)。

¡ 如果路由的“Protocol”字段发生变化，请执行步骤(2)。

(2) 检查IS-IS引入外部路由的配置。

如果指定的路由是作为外部路由引入到IS-IS的，在引入该路由的设备上，执行display ip routing-table ip-address verbose命令，查看路由震荡的具体情况，具体步骤如下：

¡ 如果路由表中处于“Active”状态的路由是IS-IS路由，而不是IS-IS引入的外部路由，说明网络中其他IS-IS设备发布了相同的路由。请根据网络规划修改路由协议的优先级，或者，在引入外部路由的IS-IS设备上配置路由过滤策略，控制下发到IP路由表的路由。

¡ 对于其它情况，请执行步骤(3)。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

10.3 OSPFv3故障处理

10.3.1 OSPFv3邻居Down

1. 故障描述

· OSPFv3邻居Down

· OSPFv3邻居震荡

2. 常见原因

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

· BFD会话Down，即BFD检测到链路故障。

· 对端设备故障。

· CPU利用率或内存利用率过高。

· 链路故障。

· OSPFv3接口没有Up。

· 两端IP地址不在同一网段。

· 两端OSPFv3参数的配置不匹配：

¡ RouterID配置冲突。

¡ 两端区域类型配置不一致。

¡ 两端OSPFv3认证配置不匹配。

¡ 两端定时器参数配置不一致。

¡ OSPFv3接口的网络类型不匹配。

3. 故障分析

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

图74 OSPFv3邻居Down的故障诊断流程图

4. 处理步骤

(1) 通过命令行查看OSPFv3邻居状态变为Down的原因。

执行display ospfv3 event-log peer命令，显示信息中的Reason字段为邻居状态发生变化的原因，一般包含如下几种情况：

¡ DeadExpired

表示在邻居失效定时器超时前没有收到Hello报文，导致OSPFv3邻居状态变为Down。出现这种情况请执行步骤(2)。

¡ BFDDown

表示BFD会话Down导致OSPFv3邻居状态变为Down。出现这种情况请执行步骤(2)。

¡ 1-Way

表示对端OSPFv3状态首先变成Down，然后向本端发送1-way Hello报文，导致本端OSPFv3状态变为Init。出现这种情况请排查对端设备的故障。

¡ IntPhyChange

表示接口Down或者接口MTU改变导致邻居关系变为Down。此时，执行display interface [ interface-type [ interface-number | interface-number.subnumber ] ]命令查看接口的运行状态和相关信息，排查接口故障。其他情况请执行步骤(11)。

(2) 检查接口的物理层状态是否为Up。

执行display interface [ interface-type [ interface-number | interface-number.subnumber ] ]命令查看OSPFv3接口物理层状态，如果接口物理层状态为Down请先处理接口故障问题。如果接口物理状态为Up，则执行步骤(3)。

(3) 检查链路是否故障。

请执行ping命令，检查设备链路是否故障（包括传输设备故障）。如果链路正常，请执行步骤(4)。

(4) 检查CPU利用率是否过高。

请执行display cpu-usage命令检查故障设备的主控板和接口板的CPU利用率是否过高。CPU利用率过高会导致OSPFv3无法正常收发协议报文，继而导致邻居振荡。可通过关闭一些不必要的功能解决此问题。如果CPU利用率不高，则执行步骤(5)。

(5) 检查内存利用率是否超过了内存利用率阈值。

请执行display memory-threshold命令，查看显示信息中的Current free-memory state，即系统当前内存使用状态。如果Current free-memory state为Minor、Severe或Critical，表示剩余空闲内存较少，可能会导致设备无法收发OSPFv3报文或处理OSPFv3报文速度较慢，请关闭一些不必要的功能尝试解决此问题。如果系统当前内存使用状态为Normal，则执行步骤(6)。

(6) 检查接口在OSPFv3协议下的状态是否正常。

执行display ospfv3 interface查看接口在OSPFv3协议下状态是否为正常状态。

¡ 如果OSPFv3接口状态为Down，检查接口是否使能了OSPFv3功能。如果使能了OSPFv3功能，请处理网络层接口故障问题。

¡ 如果OSPFv3接口协议状态正常，即接口状态为DR、BDR、DROther或P-2-P时，请执行步骤(7)。

(7) 检查各OSPFv3接口的MTU是否一致。

如果接口下未配置ospfv3 mtu-ignore命令，则要求接口的MTU一致，否则无法建立OSPFv3邻居关系。请执行display interface [ interface-type [ interface-number | interface-number.subnumber ] ]命令查看接口MTU信息。

¡ 如果接口的MTU值配置不一致，请在接口视图下执行mtu size命令，将各个接口的MTU值修改为一致。

¡ 如果接口的MTU值一致，请(8)执行步骤。

(8) 检查各接口的DR优先级是否非零。

对于Broadcast和NBMA类型的网络，为了保证正确选举出DR，需要保证至少有一个OSPFv3接口的DR优先级是非零的，否则两边的邻居状态只能达到2-Way。请使用display ospfv3 interface命令查看OSPFv3接口信息，其中的Priority表示接口的DR优先级。

如果接口的DR优先级非零，请执行步骤(9)。

(9) 是否手工为NBMA网络或P2MP单播网络指定了邻居。

OSPFv3网络类型为NBMA或P2MP（unicast）时，必须通过ospfv3 peer命令手工指定邻居接口的链路本地地址。请在OSPFv3接口视图下使用display this命令查看接口的网络类型，如果接口的网络类型为NBMA或P2MP（unicast），请在OSPFv3接口视图下使用ospfv3 peer命令手工指定邻居接口的链路本地地址。

如果手工为NBMA网络或P2MP单播网络指定了邻居接口的链路本地地址，请执行步骤(10)。

(10) 检查两端OSPFv3的参数配置是否有错误。

a. 请使用display ospfv3命令检查两端OSPFv3 Router ID配置是否冲突。如果OSPFv3 Router ID配置冲突，请修改配置保证OSPFv3 Router ID不再冲突。如果OSPFv3 Router ID配置不冲突，请继续执行以下检查。

b. 请使用display ospfv3 interface命令检查两端OSPFv3 Area ID配置是否一致。如果OSPFv3 Area ID配置不一致，请修改配置保证OSPFv3 Area ID配置一致。如果OSPFv3 Area ID配置一致，请继续执行以下检查。

c. 请使用display ospfv3 interface命令检查两端接口的OSPFv3网络类型是否一致。如果OSPFv3网络类型不一致，请修改配置保证OSPFv3网络类型一致。需要说明的是，如果双方一端为PTP，另一端为Broadcast，那么邻居关系可以达到Full状态，但无法计算出路由信息。

如果接口的OSPFv3网络类型一致，请继续执行以下检查。

d. 请每隔10秒钟使用display ospfv3 statistics error命令检查一次OSPFv3的错误统计信息，并持续5分钟。需要查看的信息包括：

- 查看Authentication failure字段。如果这个字段对应的计数值一直增长，表示建立邻居的两台设备配置的OSPFv3认证类型不一致，需要在两端设备上配置相同类型的认证。

- 查看HELLO: Hello-time mismatch字段。如果这个字段对应的计数值一直在增长，表示接口上的Hello定时器的值不一致，需要将两端接口的Hello定时器的值设置为一致。

- 查看HELLO: Dead-time mismatch字段。如果这个字段对应的计数值一直在增长，表示接口上的Dead定时器的值不一致，需要将两端接口的Dead定时器的值设置为一致。

- 查看HELLO: Ebit option mismatch字段。如果这个字段对应的计数值一直在增长，表示区域类型配置不一致（一端配置为普通区域，另一端配置为Stub或NSSA区域），需要将两端的区域类型设置为一致。

如果故障依然存在，请执行步骤(11)。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

10.3.2 OSPFv3邻居无法达到FULL状态

1. 故障描述

OSPFv3的状态机包括Down、Init、2-way、Exstart、Exchange、Loading和Full。其中，稳定状态包括Down、2-way和Full：

· Down：表示未使能OSPFv3。

· 2-way：DRother之间的邻居关系。

· Full：形成邻接关系。

对于使用OSPFv3进行路由计算和路由转发的网络中，只有2-way和Full是正常的邻居状态。如果邻居状态既未处于2-way状态，也未处于Full状态，说明邻居关系不正常。

2. 常见原因

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

· 链路故障，OSPFv3报文被丢弃。

· 接口的DR优先级配置不合理。

· 两端配置的OSPFv3 MTU值不同。

3. 故障分析

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

图75 OSPFv3邻居Down的故障诊断流程图

4. 处理步骤

(1) 使用display ospfv3 peer命令查看OSPFv3邻居信息，并根据不同的邻居状态进行相应的处理。

¡ 没有邻居信息。

请检查是否在OSPFv3进程下设置了Router ID，如果未设置Router ID，则OSPFv3进程无法运行。如果设置了Router ID，则表示OSPFv3邻居Down或者邻居震荡，请参见“10.3.1 OSPFv3邻居Down”故障处理。

¡ 邻居状态一直为Init。

表示对端设备收不到本端发送的Hello报文，此时请排查链路和对端设备是否故障。

¡ 邻居状态一直为2-way。

执行命令display ospfv3 interface verbose命令查看设备在OSPFv3接口的DR优先级是否为0：

如果OSPFv3接口的DR优先级为0，那么邻居状态为2-way属于正常情况。

如果OSPFv3接口的DR优先级不为0，请执行步骤(2)。

¡ 邻居状态一直是Exstart。

表示设备一直在进行DD协商，但无法进行DD同步，出现该情况有两种可能性：

- 接口无法正常收发超大报文

可以通过多次执行命令ping -s packet-size neighbor-address查看超大报文收发情况，将packet-size设置为1500或更大数值。如果无法Ping通，请先解决链路问题。

- 两端OSPFv3 MTU配置值不一致

如果OSPFv3接口下配置了ospfv3 mtu-ignore命令，则无需检查两端的OSPFv3 MTU值是否相等；否则，需要检查两端的OSPFv3 MTU值是否相等，如果不相等则修改接口下的MTU值。

如果故障没有解决，请执行步骤(2)。

¡ 邻居状态一直是Exchange。

表示设备在进行DD交换，请参见邻居状态一直为Exstart状态的处理。

如果故障没有解决，请执行步骤(2)。

¡ 邻居状态一直是Loading。

如果使用display ospfv3 peer命令查看到邻居状态一直处于Loading，可以尝试执行reset ospfv3 [ process-id ] process命令重启OSPFv3进程。

如果故障没有解决，请执行步骤(2)。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

10.4 OSPF故障处理

10.4.1 OSPF邻居Down

1. 故障描述

· OSPF邻居Down

· OSPF邻居震荡

2. 常见原因

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

· BFD会话Down，即BFD检测到链路故障。

· 对端设备故障。

· CPU利用率过高。

· 链路故障。

· OSPF接口没有Up。

· 两端IP地址不在同一网段。

· OSPF两端参数的配置不匹配：

¡ Router ID配置冲突。

¡ 两端区域类型配置不一致。

¡ 两端OSPF验证配置不匹配。

¡ 两端定时器参数配置不一致。

¡ OSPF接口的网络类型不匹配。

3. 故障分析

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

图76 OSPF邻居Down的故障诊断流程图

4. 处理步骤

(1) 通过命令行或日志查看OSPF邻居状态变为Down的原因。

执行display ospf event-log peer命令，显示信息中的Reason字段为邻居状态发生变化的原因，一般包含如下几种情况：

¡ DeadExpired

表示在邻居失效定时器超时前没有收到Hello报文，导致OSPF邻居状态变为Down。出现这种情况请执行步骤(2)。

¡ BFDDown

表示BFD会话Down导致OSPF邻居状态变为Down。出现这种情况请执行步骤(2)。

¡ IntVliChange或virtual link was deleted or the route it relies on was deleted

表示虚连接删除或者其依赖的路由删除导致邻居关系变为Down。出现这种情况请执行步骤(2)。

¡ 1-Way

表示对端OSPF状态首先变成Down，然后向本端发送1-way Hello报文，导致本端OSPF状态变为Init。出现这种情况请排查对端设备的故障。

¡ IntPhyChange

接口Down或者接口MTU改变导致邻居关系变为Down。此时，执行display interface [ interface-type [ interface-number | interface-number.subnumber ] ]命令查看接口的运行状态和相关信息，排查接口故障。其他情况请执行步骤(11)。

(2) 检查链路是否故障。

请执行ping命令，检查设备链路是否故障（包括传输设备故障）。如果链路正常，请执行步骤(3)。

(3) 检查CPU利用率是否过高。

请执行display cpu-usage命令检查故障设备的主控板和接口板的CPU利用率是否过高。CPU利用率过高会导致OSPF无法正常收发协议报文从而导致邻居振荡。可通过关闭一些不必要的功能解决此问题。如果CPU利用率不高，则执行步骤(5)。

(4) 检查内存利用率是否超过了内存利用率阈值。

请执行display memory-threshold命令，查看显示信息中的Current free-memory state，即系统当前内存使用状态。如果Current free-memory state为Minor、Severe或Critical，表示剩余空闲内存较少，可能会导致设备无法收发OSPF报文或处理OSPF报文速度较慢，请关闭一些不必要的功能尝试解决此问题。如果系统当前内存使用状态为Normal，则执行步骤(5)。

(5) 检查接口状态是否为Up。

执行display interface [ interface-type [ interface-number | interface-number.subnumber ] ]命令查看接口物理层状态，如果接口物理层状态为Down请先处理接口故障问题。如果接口物理层状态是Up，请执行display ospf interface查看接口在OSPF协议下状态是否为正常状态：

¡ 如果OSPF接口状态为Down，检查OSPF进程下是否通过network命令通告了接口所属网段。如果OSPF未通告接口所属网段，则检查接口下是否使能了OSPF。如果接口使能了OSPF进程，请处理网络层接口故障问题。

¡ 如果OSPF下的接口协议状态正常，即接口状态为DR、BDR、DROther或PTP时，请执行步骤(6)。

(6) 检查两端IP地址是否在同一网段。

请执行display interface brief命令查看两端接口的IP地址：

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

¡ 如果两端接口的IP地址处于同一网段，请执行步骤(7)。

(7) 检查各OSPF接口的MTU是否一致。

如果在OSPF接口上通过ospf mtu-enable命令将该接口发送的DD报文中MTU域的值填充为接口的MTU值（缺省情况下接口发送的DD报文中MTU域的值为0），则要求各个OSPF接口发送的DD报文中MTU域的值一致。否则，OSPF邻居无法协商成功。请执行display interface [ interface-type [ interface-number | interface-number.subnumber ] ]命令查看接口MTU信息：

¡ 如果接口的MTU值配置不一致，请在接口视图下执行mtu size命令，将各个接口的MTU值修改为一致。

¡ 如果接口的MTU值一致，请执行步骤(8)。

(8) 检查各接口的DR优先级是否非零。

对于Broadcast和NBMA类型的网络，为了保证正确选举出DR，需要保证至少有一个OSPF接口的DR优先级是非零的，否则两边的邻居状态只能达到2-Way。请使用display ospf interface命令查看OSPF接口信息，其中的Pri表示接口的DR优先级。

如果接口的DR优先级非零，请执行步骤(9)。

(9) 是否手工为NBMA网络或P2MP单播网络指定了邻居。

OSPF网络类型为NBMA或P2MP（unicast）时，必须通过peer命令手工指定邻居的IP地址。请在OSPF接口视图下使用display this命令查看接口的网络类型，如果接口的网络类型为NBMA或P2MP（unicast），请在OSPF视图下使用peer命令手工指定邻居的IP地址。

如果手工为NBMA网络或P2MP单播网络指定了邻居的IP地址，请执行步骤(10)。

(10) 检查两端OSPF的参数配置是否有错误。

a. 请使用display ospf命令检查两端OSPF Router ID配置是否冲突。如果OSPF Router ID配置冲突，请修改配置保证OSPF Router ID不再冲突。如果OSPF Router ID配置不冲突，请继续执行以下检查。

b. 请使用display ospf interface命令检查两端OSPF Area ID配置是否一致。如果OSPF Area ID配置不一致，请修改配置保证OSPF Area ID配置一致。如果OSPF Area ID配置一致，请继续执行以下检查。

c. 请使用display ospf interface命令检查两端接口的OSPF网络类型是否一致。如果OSPF网络类型不一致，请修改配置保证OSPF网络类型一致。需要说明的是，如果双方一端为PTP，另一端为Broadcast，那么邻居关系可以达到Full状态，但无法计算出路由信息。

如果接口的OSPF网络类型一致，请继续执行以下检查。

d. 请每隔10秒钟使用display ospf statistics error命令检查一次OSPF的错误统计信息，并持续5分钟。需要查看的信息包括：

- 查看Bad authentication type字段。如果这个字段对应的计数值一直增长，表示建立邻居的两台设备配置的OSPF认证类型不一致，需要在两端设备上配置相同认证的类型。

- 查看Hello-time mismatch字段。如果这个字段对应的计数值一直在增长，表示接口上的Hello定时器的值不一致，需要将两端接口的Hello定时器的值设置为一致。

- 查看Dead-time mismatch字段。如果这个字段对应的计数值一直在增长，表示接口上的Dead定时器的值不一致，需要将两端接口的Dead定时器的值设置为一致。

- 查看Ebit option mismatch字段。如果这个字段对应的计数值一直在增长，表示区域类型配置不一致（一端配置为普通区域，另一端配置为Stub或NSSA区域），需要将两端的区域类型设置为一致。

如果故障依然存在，请执行步骤(11)。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

10.4.2 OSPF邻居无法达到FULL状态

1. 故障描述

OSPF的状态机包括Down、Init、2-way、Exstart、Exchange、Loading和Full。其中，稳定状态包括Down、2-way和Full：

· Down：表示未使能OSPF。

· 2-way：DRother之间的邻居关系。

· Full：形成邻接关系。

对于使用OSPF进行路由计算和路由转发的网络中，只有2-way和Full是正常的邻居状态。如果邻居状态既未处于2-way状态、也未处于Full状态，说明邻居关系不正常。

2. 常见原因

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

· 链路故障，OSPF报文被丢弃。

· 接口的DR优先级配置不合理。

· 两端配置的OSPF MTU值不同。

3. 故障分析

本类故障的诊断流程如图77所示：

图77 OSPF邻居无法达到FULL状态的故障诊断流程图

4. 处理步骤

(1) 使用display ospf peer命令查看OSPF邻居信息，并根据不同的邻居状态进行相应的处理。

¡ 没有邻居信息。

表示OSPF邻居Down或者邻居震荡，请参见“10.4.1 OSPF邻居Down”故障处理。

¡ 邻居状态一直为Init。

表示对端设备收不到本端发送的Hello报文，此时请排查链路和对端设备是否故障。

¡ 邻居状态一直为2-way。

执行命令display ospf interface verbose查看设备在OSPF接口的DR优先级是否为0：

- 如果OSPF接口的DR优先级为0，那么邻居状态为2-way属于正常情况。

- 如果OSPF接口的DR优先级不为0，请执行步骤(2)。

¡ 邻居状态一直是Exstart。

表示设备一直在进行DD协商，但无法进行DD同步，出现该情况有两种可能性：

- 接口无法正常收发超大报文。

可以通过多次执行命令ping -s packet-size neighbor-address查看超大报文收发情况，将packet-size设置为1500或更大数值。如果无法Ping通，请先解决链路问题。

- 两端OSPF MTU配置值不一致。

如果OSPF接口下配置了ospf mtu-enable命令，请检查两端的OSPF MTU值是否相等。如果不相等，则修改接口下的MTU值。

如果故障没有解决，请执行步骤(2)。

¡ 邻居状态一直是Exchange。

表示设备在进行DD交换，请参见邻居状态一直为Exstart状态的处理。

如果故障没有解决，请执行步骤(2)。

¡ 邻居状态一直是Loading。

如果使用display ospf peer命令查看邻居状态一直处于Loading，可以尝试执行reset ospf [ process-id ] process命令重启OSPF进程。

如果故障没有解决，请执行步骤(2)。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

10.4.3 设备学习不到部分OSPF路由

1. 故障描述

运行OSPF的设备学习不到部分OSPF路由。

2. 常见原因

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

· 双方一端的网络类型为P2P，另一端的网络类型为Broadcast，邻居关系达到Full状态，但是学习不到路由。

· OSPF进程下配置了filter-policy import命令。

· 本OSPF区域下配置了filter import命令。

· 其他OSPF区域下配置了filter export命令。

· 绑定了VPN实例的OSPF进程，该进程引入外部路由的Tag值与AS External LSA（Type-5）或NSSA External LSA（Type-7）中的Tag值一致。

· ABR设备不可达。

· 在ABR设备上，非骨干区的Summary LSA不参与路由计算。

· ASBR设备不可达。

· AS External LSA（Type-5）或NSSA External LSA（Type-7）的FA地址不可达。

· NSSA External LSA（Type-7）到达FA地址的路由与NSSA External LSA（Type-7）不在同一区域。

3. 故障分析

本类故障的诊断流程如图78、图79所示。

图78 设备学习不到OSPF路由故障诊断流程图一

图79 设备学习不到OSPF路由故障诊断流程图二

4. 处理步骤

(1) 检查建立邻居关系的双方是否一端的网络类型为P2P，另一端的网络类型为Broadcast。

如果一端的网络类型为P2P，另一端的网络类型为Broadcast，那么邻居关系可以达到Full状态，但无法计算出路由信息。

a. 请执行display ospf interface命令查看接口的网络类型。

<Sysname> display ospf interface

OSPF Process 1 with Router ID 5.5.5.5

Interfaces

Area: 0.0.0.1

IP Address Type State Cost Pri DR BDR

192.168.51.5 PTP P-2-P 1 1 0.0.0.0 0.0.0.0

b. 如果存在上述情况，请在OSPF接口视图下执行ospf network-type命令将本端设备与邻居设备的OSPF接口网络类型配置为一致。

如果不存在上述情况，请执行步骤(2)。

(2) 多次查看OSPF路由表，检查是否存在OSPF路由震荡的问题。

请执行display ip routing-table protocol ospf verbose命令，查看Age字段，确认是否存在震荡的OSPF路由。

¡ 如果某条或某些OSPF路由Age字段的数值一直很小，说明相应的OSPF路由发生震荡，请解决路由震荡问题。

¡ 如果不存在路由震荡的问题，请执行步骤(3)。

<Sysname> display ip routing-table protocol ospf verbose

Summary count : 3

Destination: 192.168.12.0/24

Protocol: O_INTER

Process ID: 1

SubProtID: 0x2 Age: 12h53m09s

Cost: 2 Preference: 10

IpPre: N/A QosLocalID: N/A

Tag: 0 State: Active Adv

OrigTblID: 0x0 OrigVrf: default-vrf

TableID: 0x2 OrigAs: 0

NibID: 0x13000003 LastAs: 0

AttrID: 0xffffffff Neighbor: 0.0.0.0

Flags: 0x10041 OrigNextHop: 192.168.51.1

Label: NULL RealNextHop: 192.168.51.1

BkLabel: NULL BkNextHop: N/A

SRLabel: NULL Interface: GigabitEthernet1/0/2

BkSRLabel: NULL BkInterface: N/A

SIDIndex: NULL InLabel: NULL

Tunnel ID: Invalid IPInterface: GigabitEthernet1/0/2

BkTunnel ID: Invalid BkIPInterface: N/A

FtnIndex: 0x0 ColorInterface: N/A

TrafficIndex: N/A BkColorInterface: N/A

Connector: 0.0.0.0 VpnPeerId: N/A

Dscp: N/A Exp: N/A

SRTunnelID: Invalid StatFlags: 0x0

SID Type: N/A SID: N/A

BkSID: N/A NID: Invalid

FlushNID: Invalid BkNID: Invalid

BkFlushNID: Invalid PathID: 0x0

CommBlockLen: 0

OrigLinkID: 0x0 RealLinkID: 0x0

Destination: 192.168.24.0/24

Protocol: O_INTER

Process ID: 1

SubProtID: 0x2 Age: 12h53m09s

Cost: 3 Preference: 10

IpPre: N/A QosLocalID: N/A

Tag: 0 State: Active Adv

OrigTblID: 0x0 OrigVrf: default-vrf

TableID: 0x2 OrigAs: 0

NibID: 0x13000003 LastAs: 0

AttrID: 0xffffffff Neighbor: 0.0.0.0

Flags: 0x10041 OrigNextHop: 192.168.51.1

Label: NULL RealNextHop: 192.168.51.1

BkLabel: NULL BkNextHop: N/A

SRLabel: NULL Interface: GigabitEthernet1/0/2

BkSRLabel: NULL BkInterface: N/A

SIDIndex: NULL InLabel: NULL

Tunnel ID: Invalid IPInterface: GigabitEthernet1/0/2

BkTunnel ID: Invalid BkIPInterface: N/A

FtnIndex: 0x0 ColorInterface: N/A

TrafficIndex: N/A BkColorInterface: N/A

Connector: 0.0.0.0 VpnPeerId: N/A

Dscp: N/A Exp: N/A

SRTunnelID: Invalid StatFlags: 0x0

SID Type: N/A SID: N/A

BkSID: N/A NID: Invalid

FlushNID: Invalid BkNID: Invalid

BkFlushNID: Invalid PathID: 0x0

CommBlockLen: 0

OrigLinkID: 0x0 RealLinkID: 0x0

Destination: 192.168.51.0/24

Protocol: O_INTRA

Process ID: 1

SubProtID: 0x1 Age: 12h54m07s

Cost: 1 Preference: 10

IpPre: N/A QosLocalID: N/A

Tag: 0 State: Inactive Adv

OrigTblID: 0x0 OrigVrf: default-vrf

TableID: 0x2 OrigAs: 0

NibID: 0x13000001 LastAs: 0

AttrID: 0xffffffff Neighbor: 0.0.0.0

Flags: 0x10c1 OrigNextHop: 0.0.0.0

Label: NULL RealNextHop: 0.0.0.0

BkLabel: NULL BkNextHop: N/A

SRLabel: NULL Interface: GigabitEthernet1/0/2

BkSRLabel: NULL BkInterface: N/A

SIDIndex: NULL InLabel: NULL

Tunnel ID: Invalid IPInterface: GigabitEthernet1/0/2

BkTunnel ID: Invalid BkIPInterface: N/A

FtnIndex: 0x0 ColorInterface: N/A

TrafficIndex: N/A BkColorInterface: N/A

Connector: 0.0.0.0 VpnPeerId: N/A

Dscp: N/A Exp: N/A

SRTunnelID: Invalid StatFlags: 0x0

SID Type: N/A SID: N/A

BkSID: N/A NID: Invalid

FlushNID: Invalid BkNID: Invalid

BkFlushNID: Invalid PathID: 0x0

CommBlockLen: 0

OrigLinkID: 0x0 RealLinkID: 0x0

(3) 检查OSPF进程下是否配置了filter-policy import命令。

某些场景下需要对路由信息进行过滤，实现业务隔离。请检查是否存在OSPF路由被错误过滤的情况。

a. 请在本端设备出现问题的OSPF进程下执行display this命令，查看该OSPF进程下是否配置了filter-policy import命令，导致OSPF路由被过滤。

[Sysname-ospf-1] display this

ospf 1

import-route direct

filter-policy 2000 import

area 0.0.0.1

network 192.168.51.0 0.0.0.255

nssa

return

b. 如果OSPF进程下配置了filter-policy import命令，请查看该命令引用的过滤规则的配置信息。

- 对于filter-policy import命令引用ACL规则进行路由过滤的情况，请执行display acl { acl-number | name acl-name }命令查看ACL的配置信息。

- 对于filter-policy import命令引用前缀列表进行路由过滤的情况，请执行display ip prefix-list命令查看地址前缀列表的配置信息。

- 对于filter-policy import命令引用路由策略进行路由过滤的情况，请执行display route-policy命令查看路由策略的配置信息。

如果路由被过滤规则拒绝，请结合组网及实际业务需求确认过滤规则的配置是否合理。如果不合理，请修改filter-policy import命令引用的过滤规则。

c. 如果该路由没有被拒绝，或者该OSPF进程并没有配置filter-policy import过滤策略，请执行步骤(4)。

(4) 检查OSPF进程的LSDB是否包含未学习到的OSPF路由的LSA。

请根据OSPF进程未学习到的路由信息的类型选择不同的故障处理方式。

o OSPF区域内路由

如果OSPF进程缺失区域内路由，请在用户视图下执行display ospf [ process-id ] lsdb router命令，检查LSDB是否包含该区域中所有的Router LSA信息。

<Sysname> display ospf 100 lsdb router

OSPF Process 100 with Router ID 5.5.5.5

Area: 0.0.0.1

Link State Database

Type : Router

LS ID : 5.5.5.5

Adv Rtr : 5.5.5.5

LS age : 7

Len : 36

Options : ASBR O NP

Seq# : 80000026

Checksum : 0x5f1f

Link Count: 1

Link ID: 192.168.51.1

Data : 192.168.51.5

Link Type: TransNet

Metric : 1

Type : Router

LS ID : 1.1.1.1

Adv Rtr : 1.1.1.1

LS age : 8

Len : 36

Options : ASBR ABR O NP

Seq# : 8000002a

Checksum : 0x534a

Link Count: 1

Link ID: 192.168.51.1

Data : 192.168.51.1

Link Type: TransNet

Metric : 1

- 如果OSPF进程的LSDB缺失Router LSA，请执行步骤(7)。

- 如果OSPF进程的LSDB包含完整的Router LSA，但是无法计算出路由信息，请执行步骤(7)。

o OSPF区域间路由

如果OSPF进程缺失区域间路由，请在用户视图下执行display ospf [ process-id ] lsdb summary命令，检查LSDB是否包含其他所有区域的Network Summary LSA。

<Sysname> display ospf lsdb summary

OSPF Process 1 with Router ID 5.5.5.5

Area: 0.0.0.1

Link State Database

Type : Sum-Net

LS ID : 192.168.24.0

Adv Rtr : 1.1.1.1

LS age : 576

Len : 28

Options : O NP

Seq# : 8000001f

Checksum : 0x4c25

Net Mask : 255.255.255.0

Tos 0 Metric: 2

Type : Sum-Net

LS ID : 192.168.12.0

Adv Rtr : 1.1.1.1

LS age : 576

Len : 28

Options : O NP

Seq# : 8000001f

Checksum : 0xc6b7

Net Mask : 255.255.255.0

Tos 0 Metric: 1

- 如果OSPF进程的LSDB缺失Network Summary LSA，检查本区域下是否配置了filter import命令，或者Network Summary LSA的发布者所在区域下是否配置了filter export命令。如果filter import命令或filter export命令引用的过滤规则错误地过滤掉了Network Summary LSA，请修改过滤规则相关配置。

filter import命令和filter export命令可以引用ACL、前缀列表、路由策略对Network Summary LSA进行过滤，请分别使用display acl { acl-number | name acl-name }命令、display ip prefix-list命令、display route-policy命令查看相应的配置信息。

- 如果OSPF进程的LSDB包含完整的Network Summary LSA，但是无法计算出路由信息，请执行步骤(7)。

o O_ASE路由或者O_NSSA路由

如果OSPF进程缺失O_ASE路由，请在用户视图下执行display ospf [ process-id ] lsdb ase命令。检查LSDB是否包含AS External LSA。

<Sysname> display ospf 100 lsdb ase

OSPF Process 100 with Router ID 1.1.1.1

Link State Database

Type : External

LS ID : 10.1.1.0

Adv Rtr : 1.1.1.1

LS age : 713

Len : 36

Options : O E

Seq# : 80000001

Checksum : 0x934b

Net Mask : 255.255.255.0

TOS 0 Metric: 1

E Type : 2

Forwarding Address : 192.168.51.5

Tag : 1

如果OSPF进程缺失O_NSSA路由，请在用户视图下执行display ospf [ process-id ] lsdb nssa命令，检查LSDB是否包含NSSA External LSA。

<Sysname> display ospf 100 lsdb nssa

OSPF Process 100 with Router ID 1.1.1.1

Area: 0.0.0.0

Link State Database

Area: 0.0.0.1

Link State Database

Type : NSSA

LS ID : 192.168.51.0

Adv Rtr : 5.5.5.5

LS age : 965

Len : 36

Options : O NP

Seq# : 8000001f

Checksum : 0x1dfa

Net Mask : 255.255.255.0

TOS 0 Metric: 1

E Type : 2

Forwarding Address : 192.168.51.5

Tag : 1

Type : NSSA

LS ID : 10.1.1.0

Adv Rtr : 5.5.5.5

LS age : 965

Len : 36

Options : O NP

Seq# : 8000001f

Checksum : 0x6840

Net Mask : 255.255.255.0

TOS 0 Metric: 1

E Type : 2

Forwarding Address : 192.168.51.5

Tag : 1

- 如果OSPF进程的LSDB缺失AS External LSA或NSSA External LSA，请执行步骤(7)。

- 如果OSPF进程的LSDB包含完整的AS External LSA或NSSA External LSA，但是无法学习到O_ASE路由或者O_NSSA路由的情况，请执行步骤(7)。

(5) 检查ABR设备是否可达。

区域间路由是ABR设备发布的，如果本端设备和ABR设备之间路由不可达，则会导致本端设备无法学习到区域间路由。

a. 请在本端设备执行display ospf [ process-id ] lsdb summary命令，查看Adv Rtr字段，该字段为通告Network Summary LSA的Router ID，即ABR的Router ID。

<Sysname> display ospf 100 lsdb summary

OSPF Process 100 with Router ID 5.5.5.5

Area: 0.0.0.1

Link State Database

Type : Sum-Net

LS ID : 192.168.12.0

Adv Rtr : 1.1.1.1

LS age : 913

Len : 28

Options : O E

Seq# : 80000001

Checksum : 0x5d45

Net Mask : 255.255.255.0

Tos 0 Metric: 1

b. 请在本端设备执行display ospf abr-asbr命令，查看Destination字段和RtType字段，RtType字段取值为ABR时，Destination字段为ABR的Router ID。查看到此类路由信息时，说明存在到达为ABR的路由。

<Sysname> display ospf 100 abr-asbr

OSPF Process 100 with Router ID 5.5.5.5

Routing Table to ABR and ASBR

Type Destination Area Cost Nexthop RtType

Intra 1.1.1.1 0.0.0.1 1 192.168.51.1 ABR

c. 如果abr-asbr信息中不包含到达通告Network Summary LSA的ABR的路由，请执行步骤(7)。

d. 如果abr-asbr信息中包含到达通告Network Summary LSA的ABR的路由，且本设备为ABR设备，请检查OSPF区域是否为骨干区域。

- 如果OSPF区域为非骨干区域（区域ID不为零），根据RFC 2328的规定，ABR设备不会对非骨干区的Network Summary LSA进行计算，没有区域间路由是正常现象。

- 如果OSPF区域为骨干区域（区域ID为零），但是没有学习到区域间路由，请执行步骤(7)。

e. 如果abr-asbr信息中包含到达通告Network Summary LSA的ABR的路由，且本OSPF进程绑定了VPN实例。请检查OSPF进程下是否配置了vpn-instance-capability simple命令。如果OSPF进程下配置了vpn-instance-capability simple命令，请执行步骤(7)。

如果OSPF进程下未配置vpn-instance-capability simple命令，故障处理方式如表13所示。

表13 OSPF进程下未配置vpn-instance-capability simple命令的故障处理方式

DN比特位是否置位	故障处理方式
未配置vpn-instance-capability simple命令，且Network Summary LSA的Option字段包含DN比特位（即DN比特位置位）	根据RFC 2328的规定，私网OSPF进程不会使用DN比特位置位的Network Summary LSA进行路由计算。没有对应的区域间路由是正常现象
未配置vpn-instance-capability simple命令，且Network Summary LSA的Option字段不包含DN比特位	请执行步骤(7)

(6) 检查ASBR设备是否可达，检查是否有防环检测。

O_ASE路由和O_NSSA路由是ASBR设备发布的，如果本端设备和ASBR设备之间路由不可达，则会导致本端设备无法学习到AS外部的路由。

a. 请执行display ospf [ process-id ] lsdb [ ase | nssa ]命令，查看Adv Rtr字段，该字段为通告AS External LSA（Type-5）或NSSA External LSA（Type-7）的Router ID，即ASBR的Router ID。

<Sysname> display ospf 100 lsdb ase

OSPF Process 100 with Router ID 1.1.1.1

Link State Database

Type : External

LS ID : 10.1.1.0

Adv Rtr : 1.1.1.1

LS age : 169

Len : 36

Options : O E

Seq# : 80000001

Checksum : 0x934b

Net Mask : 255.255.255.0

TOS 0 Metric: 1

E Type : 2

Forwarding Address : 192.168.51.5

Tag : 1

<Sysname> display ospf 100 lsdb nssa

OSPF Process 100 with Router ID 1.1.1.1

Area: 0.0.0.0

Link State Database

Area: 0.0.0.1

Link State Database

Type : NSSA

LS ID : 192.168.51.0

Adv Rtr : 5.5.5.5

LS age : 156

Len : 36

Options : O NP

Seq# : 80000001

Checksum : 0x59dc

Net Mask : 255.255.255.0

TOS 0 Metric: 1

E Type : 2

Forwarding Address : 192.168.51.5

Tag : 1

Type : NSSA

LS ID : 10.1.1.0

Adv Rtr : 5.5.5.5

LS age : 156

Len : 36

Options : O NP

Seq# : 80000001

Checksum : 0xa422

Net Mask : 255.255.255.0

TOS 0 Metric: 1

E Type : 2

Forwarding Address : 192.168.51.5

Tag : 1

b. 请执行display ospf abr-asbr命令，查看Destination字段和RtType字段，RtType字段取值为ASBR时，Destination字段为ASBR的Router ID。查看到此类路由信息时，说明存在到达为ASBR的路由。

<Sysname> display ospf 100 abr-asbr

OSPF Process 100 with Router ID 1.1.1.1

Routing Table to ABR and ASBR

Type Destination Area Cost Nexthop RtType

Intra 5.5.5.5 0.0.0.1 1 192.168.51.5 ASBR

c. 如果abr-asbr信息中不包含到达通告AS External LSA或NSSA External LSA的ASBR的路由，请执行步骤(7)。

d. 如果abr-asbr信息中包含到达通告AS External LSA或NSSA External LSA的ASBR的路由，且LSA的Forwarding Address字段不为零，需要检查Forwarding Address的可达性及路由类型。

请在用户视图下执行disply ospf arouting forwarding-address { mask-length | mask }命令查询是否存在到达Forwarding Address的路由。

<Sysname> display ospf 100 routing 192.168.51.5 24

OSPF Process 100 with Router ID 1.1.1.1

Routing Table

Routing for network

Destination Cost Type NextHop AdvRouter Area

192.168.51.0/24 1 Transit 0.0.0.0 5.5.5.5 0.0.0.1

Total nets: 1

Intra area: 1 Inter area: 0 ASE: 0 NSSA: 0

Forwarding Address的可达性及路由类型对OSPF是否能够学习到O_ASE路由或O_NSSA路由的影响如表14所示。

表14 Forwarding Address的可达性及路由类型对O_ASE路由或O_NSSA路由的影响

Forward Address是否可达	故障处理方式
不可达	如果通过display ospf routing forwarding-address { mask-length \| mask }命令无法查看到路由信息，说明Forwarding Address不可达，请执行步骤(7)
可达	如果外部路由是由NSSA External LSA（Type-7）通告的，根据RFC 3101的规定，要求到达Forwarding Address的路由所在区域与NSSA External LSA所在区域相同。如果Area字段标明的区域号与NSSA External LSA所在的区域不同，OSPF不使用此类NSSA External LSA进行路由计算。因此，没有对应的外部路由是正常现象
可达	通过display ospf routing forwarding-address { mask-length \| mask }命令查看到的路由的Type字段为Type1或者Type2，说明到达Forwarding Address的路由类型是外部路由。根据RFC 2328的规定，到达非零Forwarding Address的路由类型不允许是外部路由，OSPF不使用此类LSA进行路由计算。因此，没有对应的外部路由是正常现象

e. 如果abr-asbr信息中包含到达通告AS External LSA或NSSA External LSA的ASBR的路由，且本OSPF进程绑定了VPN实例。

请检查本OSPF进程下是否配置了vpn-instance-capability simple命令。如果OSPF进程下配置了vpn-instance-capability simple命令，请执行步骤(7)。

如果OSPF进程下未配置vpn-instance-capability simple命令，故障处理方式如表15所示。

表15 OSPF进程下未配置vpn-instance-capability simple命令的故障处理方式

DN比特位是否置位	故障处理方式
未配置vpn-instance-capability simple命令，且AS External LSA或者NSSA External LSA的Option字段包含DN比特位	根据RFC 2328的规定，私网OSPF进程不会使用DN比特位置位的AS External LSA或者NSSA External LSA进行路由计算。没有对应的外部路由是正常现象
未配置vpn-instance-capability simple命令，且AS External LSA或者NSSA External LSA的Option字段不包含DN比特位	请执行display ospf命令查看Default ASE parameters字段，确认AS External LSA或者NSSA External LSA的Tag值是否与私网OSPF进程的Tag值相同： · 对于Tag值相同的情况，根据RFC 2328的规定，私网OSPF进程不会使用此类LSA进行路由计算。因此，没有对应的外部路由是正常现象 · 对于Tag值不同的情况，请执行步骤(7)

DN比特位是否置位

故障处理方式

未配置vpn-instance-capability simple命令，且AS External LSA或者NSSA External LSA的Option字段包含DN比特位

根据RFC 2328的规定，私网OSPF进程不会使用DN比特位置位的AS External LSA或者NSSA External LSA进行路由计算。没有对应的外部路由是正常现象

未配置vpn-instance-capability simple命令，且AS External LSA或者NSSA External LSA的Option字段不包含DN比特位

请执行display ospf命令查看Default ASE parameters字段，确认AS External LSA或者NSSA External LSA的Tag值是否与私网OSPF进程的Tag值相同：

· 对于Tag值相同的情况，根据RFC 2328的规定，私网OSPF进程不会使用此类LSA进行路由计算。因此，没有对应的外部路由是正常现象

· 对于Tag值不同的情况，请执行步骤(7)

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

10.4.4 网络中IP地址冲突导致路由震荡

1. 故障描述

OSPF组网中不同设备上配置相同的接口IP地址，会导致OSPF路由震荡。出现此问题时，设备通常伴随如下现象：

· 执行命令display cpu-usage查看到设备CPU使用率较高。

· OSPF频繁地老化LSA、重新生成LSA。

· 设备路由频繁刷新、路由计算出错。

2. 处理步骤

以图80为示例说明此类故障的处理方式。其他组网与该组网处理此类故障的思路是相同的。

图80 网络中IP地址冲突导致路由震荡组网示例

(2) 在OSPF网络中的各个设备上每隔一秒执行一次display ospf [ process-id ] lsdb命令，查看每台设备的OSPF链路状态数据库（LSDB）信息。

(3) 检查是否存在LSA老化异常的情况。

同时满足如下条件时，说明LSA老化异常。

a. 在Device A上发现同一个AdvRouter通告的Network LSA（Type-2）的老化时间（Age）非自然增长，一直为最小值，且Sequence字段增加很快。例如在如下显示信息中，LinkStateID为172.168.0.1的Network LSA的Age非自然增长，短时间内Sequence从8000002D快速增长为8000002F。

<Sysname> display ospf 100 lsdb

OSPF Process 100 with Router ID 10.1.1.1

Link State Database

Area: 0.0.0.0

Type LinkState ID AdvRouter Age Len Sequence Metric

Router 3.3.3.3 3.3.3.3 797 48 80000009 0

Router 1.1.1.1 1.1.1.1 835 36 80000005 0

Router 4.4.4.4 4.4.4.4 798 36 80000004 0

Router 10.1.1.1 10.1.1.1 415 36 80000007 0

Router 2.2.2.2 2.2.2.2 415 48 80000015 0

Network 192.168.0.2 3.3.3.3 802 32 80000002 0

Network 172.168.0.3 4.4.4.4 791 32 80000002 0

Network 172.168.0.1 10.1.1.1 7 32 8000002D 0

<Sysname> display ospf 100 lsdb

OSPF Process 100 with Router ID 10.1.1.1

Link State Database

Area: 0.0.0.0

Type LinkState ID AdvRouter Age Len Sequence Metric

Router 3.3.3.3 3.3.3.3 810 48 80000009 0

Router 1.1.1.1 1.1.1.1 848 36 80000005 0

Router 4.4.4.4 4.4.4.4 811 36 80000004 0

Router 10.1.1.1 10.1.1.1 428 36 80000007 0

Router 2.2.2.2 2.2.2.2 428 48 80000015 0

Network 192.168.0.2 3.3.3.3 815 32 80000002 0

Network 172.168.0.3 4.4.4.4 804 32 80000002 0

Network 172.168.0.1 10.1.1.1 4 32 8000002F 0

b. 在Device B上相同Network LSA的Age不断在3600和其他较小值之间切换，而且Sequence字段增加很快。例如在如下显示信息中，LinkStateID为172.168.0.1的Network LSA的Age在3600和其他较小值之间切换，短时间内Sequence从80000023快速增长为80000041。

<Sysname> display ospf 100 lsdb

OSPF Process 100 with Router ID 2.2.2.2

Link State Database

Area: 0.0.0.0

Type LinkState ID AdvRouter Age Len Sequence Metric

Router 3.3.3.3 3.3.3.3 708 48 80000009 0

Router 1.1.1.1 1.1.1.1 746 36 80000005 0

Router 4.4.4.4 4.4.4.4 709 36 80000004 0

Router 10.1.1.1 10.1.1.1 329 36 80000007 0

Router 2.2.2.2 2.2.2.2 327 48 80000015 0

Network 172.168.0.3 4.4.4.4 702 32 80000002 0

Network 192.168.0.2 3.3.3.3 713 32 80000002 0

Network 172.168.0.1 10.1.1.1 3600 32 80000023 0

<Sysname> display ospf 100 lsdb

OSPF Process 100 with Router ID 2.2.2.2

Link State Database

Area: 0.0.0.0

Type LinkState ID AdvRouter Age Len Sequence Metric

Router 3.3.3.3 3.3.3.3 748 48 80000009 0

Router 1.1.1.1 1.1.1.1 786 36 80000005 0

Router 4.4.4.4 4.4.4.4 749 36 80000004 0

Router 10.1.1.1 10.1.1.1 369 36 80000007 0

Router 2.2.2.2 2.2.2.2 367 48 80000015 0

Network 172.168.0.3 4.4.4.4 742 32 80000002 0

Network 192.168.0.2 3.3.3.3 753 32 80000002 0

Network 172.168.0.1 10.1.1.1 7 32 80000041 0

c. 在Device C上，相同Network LSA的Age一直为3600，或者偶尔没有这条LSA，而且Sequence字段增加很快。例如在如下显示信息中，LinkStateID为172.168.0.1的Network LSA的Age为3600，或者偶尔没有这条LSA；存在这条LSA时，短时间内Sequence从80000309增长到80000346。

<Sysname> display ospf 100 lsdb

OSPF Process 100 with Router ID 3.3.3.3

Link State Database

Area: 0.0.0.0

Type LinkState ID AdvRouter Age Len Sequence Metric

Router 3.3.3.3 3.3.3.3 740 48 8000000D 0

Router 4.4.4.4 4.4.4.4 759 36 80000008 0

Router 10.1.1.1 10.1.1.1 364 36 8000000B 0

Router 2.2.2.2 2.2.2.2 366 48 80000019 0

Network 172.168.0.3 4.4.4.4 755 32 80000006 0

Network 192.168.0.2 3.3.3.3 744 32 80000006 0

Network 172.168.0.1 10.1.1.1 3600 32 80000309 0

<Sysname> display ospf 100 lsdb

OSPF Process 100 with Router ID 3.3.3.3

Link State Database

Area: 0.0.0.0

Type LinkState ID AdvRouter Age Len Sequence Metric

Router 3.3.3.3 3.3.3.3 745 48 8000000D 0

Router 4.4.4.4 4.4.4.4 764 36 80000008 0

Router 10.1.1.1 10.1.1.1 369 36 8000000B 0

Router 2.2.2.2 2.2.2.2 371 48 80000019 0

Network 172.168.0.3 4.4.4.4 760 32 80000006 0

Network 192.168.0.2 3.3.3.3 749 32 80000006 0

<Sysname> display ospf 100 lsdb

OSPF Process 100 with Router ID 3.3.3.3

Link State Database

Area: 0.0.0.0

Type LinkState ID AdvRouter Age Len Sequence Metric

Router 3.3.3.3 3.3.3.3 1302 48 8000000D 0

Router 4.4.4.4 4.4.4.4 1321 36 80000008 0

Router 10.1.1.1 10.1.1.1 926 36 8000000B 0

Router 2.2.2.2 2.2.2.2 928 48 80000019 0

Network 172.168.0.3 4.4.4.4 1317 32 80000006 0

Network 192.168.0.2 3.3.3.3 1306 32 80000006 0

Network 172.168.0.1 10.1.1.1 3600 32 80000346 0

(4) 检查是否存在OSPF路由震荡。

在Device B上每隔一秒执行一次display ospf [ process-id ] routing命令，查看路由是否震荡。

<Sysname> display ospf 100 routing

OSPF Process 100 with Router ID 2.2.2.2

Routing Table

Routing for network

Destination Cost Type NextHop AdvRouter Area

192.168.0.0/24 1 Transit 0.0.0.0 3.3.3.3 0.0.0.0

172.168.0.0/24 1 Transit 0.0.0.0 10.1.1.1 0.0.0.0

Total nets: 2

Intra area: 2 Inter area: 0 ASE: 0 NSSA: 0

<Sysname> display ospf 100 routing

OSPF Process 100 with Router ID 2.2.2.2

Routing Table

Routing for network

Destination Cost Type NextHop AdvRouter Area

192.168.0.0/24 1 Transit 0.0.0.0 3.3.3.3 0.0.0.0

172.168.0.0/24 2 Transit 192.168.0.2 4.4.4.4 0.0.0.0

Total nets: 2

Intra area: 2 Inter area: 0 ASE: 0 NSSA: 0

当OSPF路由发生震荡，且多次执行display ospf peer命令发现邻居关系没有发生震荡时，可以判断该OSPF组网中存在IP地址冲突。同时，由于Network LSA（Type-2）是由DR发布的，说明产生冲突的设备中有一台设备是DR。

如果任一台设备上出现两个LinkState ID相同的Network LSA，并且这两个Network LSA老化异常。说明产生冲突的设备均为DR。

<Sysname> display ospf 100 lsdb

OSPF Process 100 with Router ID 10.1.1.1

Link State Database

Area: 0.0.0.0

Type LinkState ID AdvRouter Age Len Sequence Metric

Router 3.3.3.3 3.3.3.3 367 48 80000021 0

Router 4.4.4.4 4.4.4.4 369 36 80000013 0

Router 10.1.1.1 10.1.1.1 477 36 80000012 0

Router 2.2.2.2 2.2.2.2 403 48 8000002B 0

Network 192.168.0.1 2.2.2.2 395 32 80000002 0

Network 172.168.0.1 3.3.3.3 3600 32 8000002B 0

Network 172.168.0.1 10.1.1.1 9 32 80000036 0

<Sysname> display ospf 100 lsdb

OSPF Process 100 with Router ID 10.1.1.1

Link State Database

Area: 0.0.0.0

Type LinkState ID AdvRouter Age Len Sequence Metric

Router 3.3.3.3 3.3.3.3 460 48 80000021 0

Router 4.4.4.4 4.4.4.4 462 36 80000013 0

Router 10.1.1.1 10.1.1.1 570 36 80000012 0

Router 2.2.2.2 2.2.2.2 496 48 8000002B 0

Network 192.168.0.1 2.2.2.2 488 32 80000002 0

Network 172.168.0.1 3.3.3.3 3600 32 80000034 0

Network 172.168.0.1 10.1.1.1 6 32 80000041 0

(5) 定位产生冲突的设备。

结合display ospf lsdb的显示信息，找到产生IP地址冲突的设备。

¡ 产生冲突的设备中，仅有一台设备为DR。

根据异常Network LSA的AdvRouter，可以找到产生该Network LSA的DR设备；然后根据Network LSA中的LinkState ID找到产生IP地址冲突的接口，确定该接口的IP地址。根据接口的IP地址以及网络IP地址规划，找到另外一台产生冲突的设备。

在本例中，可以判断Router ID为10.1.1.1的DR设备接口IP地址与其他设备接口IP地址冲突，产生冲突的IP地址是172.168.0.1。然后根据网络IP地址规划，找到与DR设备接口IP地址冲突的另外一台设备。

¡ 产生冲突的设备均为DR。

根据异常Network LSA的AdvRouter，可以找到产生该Network LSA的DR设备；然后根据Network LSA中的LinkState ID找到产生IP地址冲突的接口。

(6) 根据网络IP地址规划修改冲突一方的IP地址。

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

¡ 上述步骤的执行结果。

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

3. 告警与日志

11 组播类故障处理

11.1 MSDP故障处理

11.1.1 MSDP对等体无法正确建立（S，G）表项

1. 故障描述

配置组播网络后发现MSDP对等体无法正确建立（S，G）表项。

2. 常见原因

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

· MSDP对等体建立失败。

· SA报文缓存机制未开启。

· 没有收到源端对等体发出的SA报文。

· 创建SA报文的MSDP对等体没有部署在RP上。

· 配置问题（比如，export、import过滤策略、import-source策略配置不正确）。

3. 故障分析

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

图81 MSDP对等体无法正确建立（S，G）表项的故障诊断流程图

4. 处理步骤

(1) 检查MSDP对等体状态是否为Established。

在配置了MSDP对等体的设备上执行display msdp brief命令，通过显示信息中的State字段判断MSDP对等体状态是否为Established。

a. 如果不是，请检查MSDP对等体接口配置是否正确，以及MSDP对等体之间是否能够Ping通。如果Ping不通，请参见“Ping不通的定位思路”继续定位，确保MSDP对等体之间能够Ping通。

b. 如果是，请执行步骤(2)。

(2) 检查是否开启SA报文缓存机制。

在MSDP对等体的MSDP视图下执行display this命令，查看是否已通过cache-sa-enable命令开启了SA报文缓存机制。

¡ 如果未开启，请通过MSDP视图下的cache-sa-enable命令开启。

¡ 如果已开启，请执行步骤(3)。

(3) 检查是否有源端对等体发出的SA报文到达。

在MSDP对等体上执行display msdp sa-cache命令，查看本设备上SA缓存中（S，G）表项的信息。通过查看是否存在相应的表项信息，判断对等体是否收到源端对等体发送的SA报文。

¡ 如果未收到，请执行步骤(4)。

¡ 如果已收到，请执行步骤(8)。

(4) 检查源端MSDP对等体是否配置export过滤策略。

在源端MSDP对等体的MSDP视图下执行display this命令，查看设备上是否已通过peer peer-address sa-policy export命令配置export策略，即是否配置对转发给指定MSDP对等体的SA报文进行过滤。

¡ 如果已配置，根据是否通过acl命令配置过滤规则，分为如下两种情况处理：

- 如果未配置ACL过滤规则，则表示该MSDP对等体不转发SA报文，请执行undo peer peer-address sa-policy export命令删除该配置。

- 如果配置了ACL过滤规则，则表示该MSDP对等体只转发符合ACL规则的（S，G）表项的SA报文。请检查需要转发的（S，G）表项的SA报文能否通过已配置的ACL规则的过滤。如果不能，可以执行undo peer peer-address sa-policy export命令删除该配置或调整指定的ACL规则。

¡ 如果未配置，请执行步骤(5)。

(5) 检查接收端MSDP对等体是否配置了import策略。

在接收端MSDP对等体的MSDP视图下执行display this命令，查看设备上是否已通过peer peer-address sa-policy import命令配置import策略，即对来自指定MSDP对等体的SA报文进行过滤。

¡ 如果已配置，根据是否通过acl命令配置过滤规则，分为如下两种情况处理：

- 如果未配置ACL过滤规则，则表示该MSDP对等体不接收任何SA报文，请执行undo peer peer-address sa-policy import命令删除该配置。

- 如果配置了ACL过滤规则，则表示该MSDP对等体只接收符合ACL规则的（S，G）表项的SA报文。请检查需要接收的（S，G）表项的SA报文能否通过已配置的ACL规则的过滤。如果不能，可以执行undo peer peer-address sa-policy import命令删除该配置或调整指定的ACL规则。

¡ 如果未配置，请执行步骤(6)。

(6) 检查源端MSDP对等体是否为RP。

在源端MSDP对等体上执行display pim routing-table命令，通过查看显示信息中（S，G）对应的Flag字段取值是否为2MSDP，判断该MSDP对等体是否为RP。

¡ 如果不是，请调整PIM-SM网络中RP的配置或者远端MSDP对等体的配置，确保源端MSDP对等体为RP。

¡ 如果是，请执行步骤(7)。

(7) 检查源端MSDP对等体是否配置了import-source策略。

在源端MSDP对等体的MSDP视图下执行display this命令，查看设备上是否已通过import-source命令配置了SA报文的创建规则。

¡ 如果已配置，根据是否通过acl命令配置过滤规则，分为如下两种情况处理：

- 如果未配置ACL过滤规则，则表示该MSDP对等体在创建SA报文时，对所有的（S，G）表项不作通告，请执行undo import-source命令删除该配置。

- 如果配置了ACL过滤规则，则表示该MSDP对等体在创建SA报文时，只通告符合ACL规则的（S，G）表项。请检查需要通告的（S，G）表项能否通过已配置的ACL规则的过滤。如果不能，可以执行undo import-source命令删除该配置或调整指定的ACL规则。

¡ 如果未配置，请执行步骤(8)。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

11.2 PIM故障处理

11.2.1 PIM邻居Down

1. 故障描述

PIM邻居Down。

2. 常见原因

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

· 接口物理状态为Down。

· 接口上未配置主IP地址。

· 接口上PIM功能没有生效。

· 接口没有使能PIM。

· 接口上PIM相关配置不正确。

3. 故障分析

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

图82 PIM邻居Down的故障诊断流程图

4. 处理步骤

(1) 检查接口的物理状态是否为Up。

请在设备上执行display interface interface-type interface-number命令查看显示信息中的“Current state”字段，确认接口的物理状态是否为Up。

a. 如果为Up，请执行步骤(2)。

b. 如果为Down，请排查处理接口物理Down的问题。

(2) 检查接口上是否配置了主IP地址。

在设备直连用户主机网段接口的接口视图下执行display this命令，查看是否通过ip address命令配置了接口的主IP地址。

a. 如果没有配置，请在接口上通过ip address命令进行配置。

b. 如果已配置，请执行步骤(3)。

(3) 检查接口是否使能PIM。

在设备上执行display current-configuration interface命令，查看接口上是否使能PIM。

a. 如果没有使能，请在接口视图下执行pim dm或pim sm命令开启PIM功能。

b. 如果已使能，请执行步骤(4)。

(4) 检查接口PIM功能是否生效。

在设备上执行display pim interface命令，通过查看显示信息中是否存在该接口对应的PIM相关信息确认接口上PIM功能是否生效。

a. 如果没有生效，请在设备上执行display current-configuration | include multicast命令，查看是否开启IP组播路由功能。

- 如果没有开启，请在系统视图下执行multicast routing命令开启IP组播路由功能。

- 如果已开启，请执行步骤(5)。

b. 如果已生效，请执行步骤(5)。

(5) 检查接口上PIM相关配置是否正确。

在接口上因配置错误导致无法建立PIM邻居的常见原因如下：

¡ 直连接口的IP地址有没有配置在同一网段内，请将需要建立PIM邻居的设备直连口的IP地址配置在同一网段内。

¡ 接口上通过pim neighbor-policy命令配置了Hello报文过滤器，但PIM邻居IP地址不在ACL的permit规则中，接口发送的Hello报文被当作非法报文过滤掉，从而建立邻居失败。请确认是否需要配置Hello报文过滤器：

- 如果需要，请修改ACL配置，使得PIM邻居的IP地址在ACL的permit规则中。

- 如果不需要，请执行undo pim neighbor-policy命令删除对Hello报文的过滤规则。

¡ 接口上通过pim require-genid命令配置了拒绝无Generation ID的Hello报文功能，而PIM邻居发送的Hello报文中未携带Generation ID，导致PIM邻居无法建立。请确认是否需要配置拒绝无Generation ID的Hello报文功能：

- 如果需要，请执行步骤(6)。

- 如果不需要，请在设备上执行undo pim require-genid命令删除此配置。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

11.2.2 PIM域内三层组播流量不通

1. 故障描述

开启IP组播路由功能后，同一PIM域内三层组播流量不通。

2. 常见原因

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

· 需要转发组播数据的接口未使能PIM。

· 接口的PIM协议没有生效。

· PIM邻居未建立成功。

· 连接用户网段的接口未使能IGMP。

· 在PIM-SM或双向PIM网络中，没有配置RP或RP信息不正确。

· 不存在到达RP或组播源的RPF路由。

· 转发组播数据的接口上配置了组播边界。

· 在PIM-SM或双向PIM网络中，配置了错误的组播源过滤策略。

· 组播表项未生成。

3. 故障分析

支持双向PIM的设备本类故障的诊断流程如图83所示，不支持双向PIM的设备本类故障的诊断流程如图84所示。

图83 PIM域内三层组播流量不通的故障诊断流程图（支持双向PIM的设备）

图84 PIM域内三层组播流量不通的故障诊断流程图（不支持双向PIM的设备）

4. 处理步骤

(1) 检查需要转发组播数据的接口是否使能PIM。

在需要转发组播数据的接口视图下执行display this命令，检查是否存在pim sm或pim dm的配置。

¡ 如果不存在，表明接口下PIM功能未开启。

- 请在接口视图下通过pim sm或pim dm命令开启PIM功能。

- 若是双向PIM网络，在接口视图下配置了通过pim sm命令开启PIM功能后，还需在PIM视图下通过bidir-pim enable命令开启双向PIM功能。不支持双向PIM的设备，请忽略本步骤。

¡ 如果存在，请执行步骤(2)。

(2) 检查接口的PIM功能是否生效。

在设备上执行display pim interface命令，通过查看显示信息中是否存在该接口对应的PIM相关信息确认接口上PIM功能是否生效。

¡ 如果没有生效，请在设备上执行display interface interface-type interface-number命令查看显示信息中的“Current state”字段，确认接口的物理状态是否为Up。如果为Down，请排查处理接口物理Down的问题。

¡ 如果生效，请执行步骤(3)。

(3) 检查PIM邻居是否建立成功。

在设备上执行display pim neighbor命令，根据是否存在相应的PIM邻居信息，判断PIM邻居是否建立成功。

a. 如果未建立成功，请参见“PIM邻居Down”进行定位，确保PIM邻居建立成功。

b. 如果建立成功，请执行步骤(4)。

(4) 检查连接用户网段的接口上IGMP功能是否生效。

在设备上执行display igmp interface命令，根据是否存在显示信息确认接口IGMP功能是否生效。

¡ 如果没有生效，请检查接口下是否通过igmp enable命令开启了IGMP功能，确保IGMP功能已开启。

¡ 如果已生效，根据不同的网络类型执行如下操作：

- 若为PIM-SM或双向PIM网络，请执行步骤(5)。

- 若为PIM-DM网络，请执行步骤(7)。

(5) 对于PIM-SM或双向PIM网络，检查RP信息是否正确。

在设备上执行display pim rp-info命令，查看设备是否生成了为某组播组服务的RP信息表项，并检查PIM-SM或双向PIM域中其它所有设备上，为此组播组服务的RP信息是否配置一致。

¡ 如果不一致，且PIM-SM/双向PIM网络中使用静态RP，请在PIM-SM/双向PIM域的所有设备上的PIM视图下执行static-rp命令，将为某组播组服务的RP地址配置为相同的地址；如果PIM-SM/双向PIM网络中使用动态RP，请执行步骤(6)。

¡ 如果一致，请执行步骤(6)。

(6) 检查是否存在到达RP的RPF路由。

在设备上执行display multicast rpf-info命令，查看是否存在到达RP的RPF路由。

¡ 如果不存在，检查单播路由配置。请在当前设备和RP上分别执行ping命令，检查是否能够互相ping通。如果ping不通，请修改单播路由配置，直到ping通为止。

¡ 如果存在，通过执行display multicast rpf-info命令，查看显示信息中的Referenced route type字段，确认RPF为组播静态路由还是单播路由。

- 如果RPF路由为组播静态路由，请执行display multicast routing-table static命令查看组播静态路由配置是否合理。

- 如果RPF路由为单播路由，请执行display ip routing-table命令查看单播路由是否与RPF路由一致。

如果到达RP的RPF路由存在且配置合理，请执行步骤(8)。

(7) 检查是否存在到达组播源的RPF路由。

在设备上执行display multicast rpf-info命令，查看是否存在到达组播源的RPF路由。

¡ 如果不存在，检查单播路由配置。请在当前设备和组播源上分别执行ping命令，检查是否能够互相ping通。如果ping不通，请修改单播路由配置，直到Ping通为止。

¡ 如果存在，通过执行display multicast rpf-info命令，查看显示信息中的Referenced route type字段，确认RPF为组播静态路由还是单播路由。

- 如果Referenced route type字段显示为“multicast static”，表示RPF路由为组播静态路由，请执行display multicast routing-table static命令查看组播静态路由配置是否合理。

- 如果Referenced route type字段显示为“igp”、“egp”、“unicast (direct)”或“unicast”，表示RPF路由为单播路由，请执行display ip routing-table命令查看单播路由是否与RPF路由一致。

如果到达组播源的RPF路由存在且配置合理，请执行步骤(8)。

(8) 检查RPF接口和RPF邻居接口上是否配置组播转发边界。

在设备上执行display multicast boundary命令，查看接口上是否配置了组播转发边界。

¡ 如果已配置，建议在接口上执行undo multicast boundary命令删除对应配置或重新进行网络规划，确保RPF接口和RPF邻居接口没有配置组播边界。

¡ 如果未配置，请执行步骤(9)。

(9) 检查是否配置组播数据过滤器。

在PIM视图下执行display this命令，查看是否配置组播数据过滤器（通过PIM视图下的source-policy命令配置）。

¡ 如果已配置，继续确认接收到的组播数据是否在过滤器指定的允许范围之内。如果不在，建议根据实际组网需要执行undo source-policy命令删除该配置或重新配置ACL规则，确保用户需要的组播数据正常转发。

¡ 如果未配置，请执行步骤(10)。

(10) 检查组播表项是否生成。

在设备上分别查看组播表项是否生成：

¡ 如果存在相应的表项，流量仍然不通，请收集相关表项信息，并执行步骤(11)。

¡ 如果不存在，请执行步骤(11)。

需要查看的组播表项以及查看方式如下：

¡ 在设备上执行display pim routing-table命令，检查PIM协议路由表项是否生成。

¡ 在设备上执行display igmp group命令，检查IGMP协议是否有对应的组播组。

¡ 在设备上执行display multicast routing-table命令，检查组播路由表是否生成。

¡ 在设备上执行display multicast forwarding-table命令，检查组播转发表是否生成。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

11.2.3 PIM-SM网络中SPT无法正常转发数据

1. 故障描述

PIM-SM网络中SPT无法正常转发数据，组播流量不通。

2. 常见原因

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

· 组播设备连接下游设备的接口没有收到PIM加入报文。

· PIM-SM域内组播设备上的接口没有开启PIM-SM。

· PIM-SM域内组播设备到组播源的RPF路由不正确。

· 配置不正确（比如组播转发边界配置不正确、组播数据过滤器配置不正确等）。

3. 故障分析

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

图85 PIM-SM网络中SPT无法正常转发数据故障诊断流程图

4. 处理步骤

(1) 检查PIM路由表中是否存在正确的（S，G）表项。

在设备上执行display pim routing-table命令，查看PIM路由表中是否存在正确的（S，G）表项。如果PIM路由表中存在正确的（S，G）表项，查看下游接口列表中是否包含到达所有组成员的下游接口。

¡ 如果PIM路由表中的（S，G）表项存在且信息完全正确，请在设备上执行display multicast forwarding-table命令，通过显示信息中的“Matched packets”和“Forwarded packets”字段，确认（S，G）表项匹配的组播报文数量和已转发的组播报文是否保持增长。如果转发表中不存在（S，G）表项或（S，G）表项对应的“Matched packets”字段值是否停止增长，则表示上游设备转发给此设备的组播数据不正常。此时，需要判断当前设备是否为组播源侧DR：

- 如果不是，则表示当前设备没有收到组播数据，故障可能出在上游设备，请检查上游设备的PIM路由表中是否存在正确的（S，G）表项。如果上游设备的PIM路由表中存在正确的（S，G）表项，但是“Matched packets”统计的组播报文数量停止增长，请执行步骤(9)。

- 如果是，则表示SPT已成功建立，但由于某种原因导致组播源侧DR未沿着SPT转发组播数据，请执行步骤(9)。

¡ 如果PIM路由表中不存在正确的（S，G）表项，请执行步骤(2)。

(2) 检查连接下游设备的接口是否收到PIM加入报文。

联系技术支持，在专业人士的指导下使用抓包工具（例如Wireshark）在设备连接下游设备的接口上进行抓包，查看连接下游设备接口是否收到PIM加入/剪枝报文。

¡ 如果没有收到PIM加入/剪枝报文，则在下游设备连接本设备的接口上，使用抓包工具（例如Wireshark）进行抓包，查看是否发送PIM加入/剪枝报文给本设备。如果下游设备没有发送PIM加入/剪枝报文，则表示下游设备存在问题，请排查下游设备故障。如果下游设备已经发送PIM加入/剪枝报文，但是本设备没有收到，则表示与本设备之间PIM邻居通信有问题，请执行步骤(9)。

¡ 如果连接下游设备接口收到了PIM加入/剪枝报文，请执行步骤(3)。

(3) 检查接口是否开启PIM-SM。

在当前设备上执行display pim interface verbose命令，查看接口上的PIM信息。

a. 重点查看到达组播源的RPF邻居接口、到达组播源的RPF接口和直连用户主机网段的接口（接收者侧DR的下游接口）上的PIM相关配置信息。如果这些接口上没有开启PIM-SM，请通过pim sm命令开启。同时，检查确保设备上已使能IP组播路由（通过multicast routing命令配置）且PIM邻居建立成功（通过display pim neighbor命令查看）。

b. 如果设备上述重点查看的接口都开启了PIM-SM，但问题依然存在，请执行步骤(4)。

(4) 检查是否存在到达组播源的RPF路由。

在设备上执行display multicast rpf-info命令，查看是否存在到达组播源的RPF路由。

¡ 如果存在，通过执行display multicast rpf-info命令，查看显示信息中的Referenced route type字段，确认RPF为组播静态路由还是单播路由。

如果到达组播源的RPF路由存在且配置合理，请执行步骤(5)。

(5) 检查转发组播数据的接口对应的DR是否为接收者侧DR。

在设备上执行display pim interface命令，查看转发组播数据的接口对应的DR是否为接收者侧DR。判断方法为查看显示信息中DR-Address字段是否携带local标记，如果携带，则为接收者侧DR。

¡ 如果不是接收者侧DR，请根据显示信息中的DR地址找到对应的DR设备，并在该DR设备上执行步骤(6)。

¡ 如果是接收者侧DR，请在当前设备上执行步骤(6)。

(6) 检查RPF接口和RPF邻居接口上是否配置组播转发边界。

在设备上执行display multicast boundary命令，查看接口上是否配置了组播转发边界。

¡ 如果已配置，建议在接口上执行undo multicast boundary命令删除对应配置或重新进行网络规划，确保RPF接口和RPF邻居接口没有配置组播边界。

¡ 如果未配置，请执行步骤(7)。

(7) 检查是否配置组播数据过滤器。

在PIM视图下执行display this命令，查看是否配置组播数据过滤器（通过PIM视图下的source-policy命令配置）。

¡ 如果未配置，请执行步骤(8)。

(8) 再次检查PIM路由表是否存在正确的（S，G）表项。

在设备上再次执行display pim routing-table命令，查看PIM路由表中是否存在（S，G）表项。具体方法请参见步骤(1)。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

11.2.4 PIM-SM网络中RPT无法正常转发数据

1. 故障描述

PIM-SM网络中RPT无法正常转发数据，组播流量不通。

2. 常见原因

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

· PIM-SM域内组播设备到RP的单播路由不通。

· PIM-SM域内各组播设备上为某一组播组服务配置的RP地址不一致。

· PIM-SM域内组播设备的下游接口没有收到PIM加入报文。

· PIM-SM域内组播设备上的接口没有开启PIM-SM。

· PIM-SM域内组播设备到RP的RPF路由不正确。

· 配置不正确（比如组播转发边界配置不正确、组播数据过滤器配置不正确等）。

3. 故障分析

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

图86 PIM-SM网络中RPT无法正常转发数据故障诊断流程图

4. 处理步骤

(1) 检查PIM路由表中是否存在正确的（*，G）表项。

在设备上执行display pim routing-table命令，查看PIM路由表中是否存在正确的（*，G）表项。请检查下游接口列表中，是否包含到达所有连接（*，G）组成员的下游接口。

¡ 如果PIM路由表中的（*，G）表项存在且信息完全正确，则建议每隔15秒执行一次display multicast forwarding-table命令，查看组播转发表中是否存在与（*，G）表项相同组播组的（S，G）表项，同时查看（S，G）表项匹配的报文数量是否保持增长。如果转发表中不存在（S，G）表项或（S，G）表项匹配的报文数量停止增长，则表示上游设备转发给此设备的组播数据不正常。此时，需要判断当前设备是否为RP：

- 如果不是，则表示当前设备没有收到组播数据，故障可能出在上游设备，请检查上游设备的PIM路由表中是否存在正确的（S，G）表项。

- 如果是，则表示RPT已成功建立，但由于某种原因（例如源DR没有注册成功）导致RP未收到组播源发出的组播数据。此时，需要寻求技术支持排除故障。

¡ 如果PIM路由表中不存在正确的（*，G）表项，请执行步骤(2)。

(2) 检查连接下游设备的接口是否收到PIM加入报文。

¡ 如果连接下游设备接口收到了PIM加入/剪枝报文，请执行步骤(3)。

(3) 检查接口是否开启PIM-SM。

在当前设备上执行display pim interface verbose命令，查看接口上的PIM信息。

a. 重点查看到达RP的RPF邻居接口、到达RP的RPF接口和直连用户主机网段的接口（接收者侧DR的下游接口）上的PIM相关配置信息。如果这些接口上没有开启PIM-SM，请通过pim sm命令开启。同时，检查设备上是否使能IP组播路由（通过multicast routing命令配置）、PIM邻居是否建立成功（通过display pim neighbor命令查看）。

b. 如果设备上述重点查看的接口都开启了PIM-SM，请执行步骤(4)。

(4) 检查RP信息是否正确。

在设备上执行display pim rp-info命令，查看设备上是否生成了为某个组播组服务的RP信息表项，并检查PIM-SM域中其它所有设备上，为此组播组服务的RP信息是否配置一致。

¡ 如果不一致，且PIM-SM网络中使用静态RP，请在PIM-SM域的所有设备上的PIM视图下执行static-rp命令，将为某组播组服务的RP地址配置为相同的地址；如果PIM-SM网络中使用动态RP，请执行步骤(10)。

¡ 如果一致，请执行步骤11.2.2 4. (6)。

(5) 检查是否存在到达RP的RPF路由。

在设备上执行display multicast rpf-info命令，查看是否存在到达RP的RPF路由。

¡ 如果存在，通过执行display multicast rpf-info命令，查看显示信息中的Referenced route type字段，确认RPF为组播静态路由还是单播路由。

- 如果RPF路由为组播静态路由，请执行display multicast routing-table static命令查看组播静态路由配置是否合理。

- 如果RPF路由为单播路由，请执行display ip routing-table命令查看单播路由是否与RPF路由一致。

如果到达RP的RPF路由存在且配置合理，请执行步骤(6)。

(6) 检查转发组播数据的接口对应的DR是否为接收者侧DR。

¡ 如果不是接收者侧DR，请根据显示信息中的DR地址找到对应的DR设备，并在该DR设备上执行步骤(7)。

¡ 如果是接收者侧DR，请在当前设备上执行步骤(7)。

(7) 检查RPF接口和RPF邻居接口上是否配置组播转发边界。

在设备上执行display multicast boundary命令，查看接口上是否配置了组播转发边界。

¡ 如果已配置，建议在接口上执行undo multicast boundary命令删除对应配置或重新进行网络规划，确保RPF接口和RPF邻居接口没有配置组播边界。

¡ 如果未配置，请执行步骤(8)。

(8) 检查是否配置组播数据过滤器。

在PIM视图下执行display this命令，查看是否配置组播数据过滤器（通过PIM视图下的source-policy命令配置）。

¡ 如果未配置，请执行步骤(9)。

(9) 再次检查PIM路由表是否存在正确的（*，G）表项。

在设备上再次执行display pim routing-table命令，查看PIM路由表中是否存在（*，G）表项。具体方法请参见步骤(1)。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

11.3 三层组播故障处理

11.3.1 三层组播业务不通

1. 故障描述

三层组播业务不通主要表现在组播流量转发失败。

2. 常见原因

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

· 单播路由配置错误。

· 接口状态不正确。

· PIM路由表项未正确生成。

· 组播转发表项未正确生成。

3. 故障分析

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

图87 三层组播业务不通的故障诊断流程图

4. 处理步骤

(1) 检查是否存在到组播源的单播路由。

执行display ip routing-table ip-address命令，查看是否存在到达组播源的路由。其中，ip-address指定为组播源的地址。

¡ 如果不存在，请配置到达组播源的路由。

¡ 如果存在，请执行步骤(2)。

(2) 检查组播流量入、出接口的状态是否正常。

执行display interface命令查看接口物理层状态。

¡ 如果接口物理层状态为Down，请解决接口故障问题。

如果接口物理层状态为Up，请执行步骤(3)。

(3) 检查是否生成正确的PIM路由表项。

执行display pim routing-table命令，查看PIM路由表项是否生成，以及是否有对应的出接口。

¡ 如果没有，请联系技术支持人员。

¡ 如果有，请执行步骤(4)。

(4) 检查是否生成正确的组播转发表项。

执行display multicast forwarding-table命令，查看组播转发表项是否生成，以及是否有对应的出接口。

¡ 如果没有，请收集上述步骤的执行结果和设备的配置文件，并联系技术支持人员。

¡ 如果有，也请收集上述步骤的执行结果和设备的配置文件，并联系技术支持人员。

5. 告警与日志

11.3.2 无法正常建立IGMP或MLD表项

1. 故障描述

组播设备无法正常建立IGMP或者MLD表项。

2. 常见原因

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

· 设备上没有开启IP组播路由功能。

· 与用户主机网段直连的接口物理状态为Down。

· 与用户主机网段直连的接口未配置主IP地址。

· 与用户主机网段直连的接口上未开启IGMP或MLD功能。

· 组播组G属于SSM组地址范围，设备上配置的IGMP或MLD版本不正确。

· 设备上配置了SSM组地址过滤规则，但组播组G地址不在ACL定义的permit规则范围内。

· 设备上配置了IGMP或MLD组播组过滤器，但组播组G地址不在ACL定义的permit规则范围内。

3. 故障分析

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

图88 设备无法正常建立IGMP或MLD表项的故障诊断流程图

4. 处理步骤

(1) 检查设备上是否开启IP组播路由功能。

在直连用户主机网段的设备上执行display current-configuration | include multicast命令，查看是否开启IP组播路由功能。

¡ 如果未开启，请在系统视图下执行multicast routing或ipv6 multicast routing命令，开启IP组播路由功能。

¡ 如果已开启，请执行步骤(2)。

(2) 检查与用户主机网段直连接口的物理状态是否为Up。

在直连用户主机网段的设备上执行display interface interface-type interface-number命令查看显示信息中的“Current state”字段，确认与用户主机网段直连的接口的物理状态是否为Up。

a. 如果为Up，请执行步骤(3)。

b. 如果为Down，请排查处理接口物理Down的问题。

(3) 检查接口上是否配置了主IP地址。

在设备直连用户主机网段接口的接口视图下执行display this命令，查看是否通过ip address命令配置了接口的主IP地址。

a. 如果没有配置，请在接口上通过ip address命令进行配置。

b. 如果已配置，请执行步骤(4)。

(4) 检查与用户主机网段直连接口上是否开启IGMP或MLD功能。

在直连用户主机网段的设备上执行display current-configuration interface命令，查看与用户主机网段直连的接口上是否开启IGMP或MLD功能。

a. 如果没有开启，请在相应的接口上开启IGMP或MLD功能。

b. 如果已开启，请执行步骤(5)。

(5) 检查组播组G是否属于SSM组地址范围。

¡ 对于IGMP表项无法生成的情况：

请检查组播组G是否属于SSM组地址范围，SSM组播组地址的范围为232.0.0.0/8。

- 如果属于，请确保与用户主机网段直连的接口上的IGMP版本为IGMPv3，并确认IGMPv3的报文正确。如果故障仍未排除，请执行步骤(6)。

- 如果不属于，请执行步骤(7)。

¡ 对于MLD表项无法生成的情况：

请检查组播组G是否属于IPv6 SSM组地址范围，IPv6 SSM组播组的范围为FF3x::/32。

- 如果属于，请确保与用户主机网段直连的接口上的MLD版本为MLDv2。如果故障仍未排除，请执行步骤(6)。

- 如果不属于，请执行步骤(7)。

(6) 检查是否配置了SSM组播组过滤器。

在直连用户主机网段的设备上执行display current-configuration configuration pim或者display current-configuration configuration pim6命令，查看是否已通过ssm-policy命令配置SSM组播组的范围。

¡ 如果已配置，请检查组播组G是否在ACL规则允许的范围之内。

- 如果不在，建议根据实际组网在PIM视图下执行undo ssm-policy命令恢复缺省情况；重新配置ACL规则，使得组播组G地址在ACL的permit规则中。

- 如果在，请执行步骤(7)。

¡ 如果未配置，请执行步骤(7)。

(7) 检查接口上是否配置了IGMP或MLD组播组过滤器。

在直连用户主机网段的设备上执行display current-configuration命令，查看是否已通过igmp group-policy或mld group-policy命令配置了IGMP或MLD组播组过滤器。

¡ 如果已配置，请检查组播组G是否在ACL规则允许的范围之内。

- 如果不在，建议根据实际组网需要执行undo igmp group-policy或undo mld group-policy命令删除该组播组过滤器配置；重新配置ACL规则，使得组播组G地址在ACL的permit规则中。

- 如果在，请执行步骤(8)。

¡ 如果未配置，请执行步骤(8)。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

11.4 二层组播故障处理

11.4.1 二层组播业务不通

1. 故障描述

二层组播业务不通主要表现在二层组播转发表项无法生成，导致组播流量无法正常转发。

2. 常见原因

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

· 设备没有收到二层组播协议报文。

· IGMP协议报文格式不正确。

· 二层组播转发表项未生成。

3. 故障分析

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

(1) 检查是否生成二层组播转发表项。

(2) 检查是否正常收到组播协议报文。

(3) 检查IGMP协议报文格式是否正确。

(4) 检查IGMP报文版本是否跟设备上配置的一致。

(5) 检查是否开启三层组播功能。

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

图89 二层组播业务不通的故障诊断流程图

4. 处理步骤

(1) 检查是否生成正确的二层组播转发表项。

执行display l2-multicast ip forwarding命令查看二层组播表项是否生成。

¡ 如果存在，请直接联系技术人员。

¡ 如果不存在，请执行步骤(2)。

(2) 检查设备是否正常收到IGMP成员关系报告报文。

执行debugging igmp-snooping packet命令，打开IGMP Snooping报文调试信息开关。如果设备上打印如下调试信息，表示可以正常收到成员关系报告报文。

*Sep 15 11:47:41:455 2011 Sysname MCS/7/PACKET: -MDC=1; Receive IGMPv2 report packet from port GE1/0/1 on VLAN 2. (G162625)

¡ 如果没有，检查下游设备和终端设备是否正常。

¡ 如果有，请执行步骤(3)。

(3) 检查IGMP协议报文交互过程是否正常，报文格式是否符合协议规范。

IGMP协议交互不正常时，通常会出现设备上转发表项无法生成的现象，导致组播数据流无法正常转发，造成组播业务中断。

在设备上配置镜像，并联系技术支持，在专业人士的指导下使用抓包工具（例如Wireshark）对镜像的IGMP协议报文进行分析。

¡ 如果不正常，请将IGMP协议报文修改为符合协议规范的报文。

¡ 如果正常，请执行步骤(4)。

(4) 检查收到的IGMP报文的版本是否与设备配置的IGMP Snooping版本一致。

执行display igmp-snooping命令查看显示信息中的Version字段确认设备使用的IGMP Snooping版本，检查是否与收到的IGMP报文的版本一致。

¡ 如果不一致，可以用如下两种方法处理：

- 修改上下游设备的IGMP版本，保证上下游设备的IGMP版本与本设备上配置的IGMP Snooping版本一致。

- 在本设备IGMP-Snooping视图下执行version命令或者在VLAN视图下执行igmp-snooping version命令，修改IGMP Snooping版本，保证本设备的IGMP Snooping版本与上下游设备的IGMP版本一致。

¡ 如果一致，请执行步骤(5)。

(5) 检查是否开启三层组播功能。

在开启了二层组播功能的VLAN所对应的VLAN接口上，若同时开启三层组播功能，会导致二层组播转发表项无法下发硬件，请关闭三层组播功能。

¡ 如果开启了三层组播功能，请删除三层组播配置。

¡ 如果未开启三层组播功能，请执行步骤(6)。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

12 MPLS类故障处理

12.1 LDP故障处理

12.1.1 LDP会话无法Up

1. 故障描述

LDP会话无法Up。

2. 常见原因

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

· 建立会话的接口处于Down状态

· LSR ID配置错误

· 不存在LDP会话的相关配置

· 传输地址配置错误

· LDP Hello-hold定时器超时

· LDP Keepalive-hold定时器超时

· 安全认证配置错误

3. 故障分析

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

图90 LDP会话Down的故障诊断流程图

4. 处理步骤

(1) 检查建立LDP会话的接口是否处于Up状态。

执行display interface命令查看接口是否处于UP状态：

¡ 如果没有UP，则排除接口物理链路故障，使接口处于UP状态。

¡ 如果接口处于UP状态，则执行步骤(2)。

(2) 检查LSR ID配置是否正确。

LSR ID包括Local LSR ID、LDP LSR ID和MPLS LSR ID。LSR ID优先级从高到底依次为Local LSR ID、LDP LSR ID、MPLS LSR ID。设备上至少配置其中的一种LSR ID，且该LSR ID必须路由可达。

执行display mpls ldp peer verbose命令检查是否配置了LSR ID：

<Sysname> display mpls ldp peer verbose

VPN instance: public instance

Peer LDP ID : 100.100.100.20:0

Local LDP ID : 100.100.100.17:0

TCP Connection : 100.100.100.20:47515 -> 100.100.100.17:646

…

如果执行display mpls ldp peer verbose命令时无显示，则通过以下方法配置LSR ID：

¡ 在系统视图下配置MPLS LSR ID。

请在系统视图下执行mpls lsr-id命令。

¡ 在LDP视图下配置LDP LSR ID。

请在LDP视图下执行lsr-id命令。

¡ 如果是直连会话，在接口视图下配置Local LSR ID。

请在接口视图下执行mpls ldp local-lsr-id命令。

¡ 如果是远程会话，在LDP对等体视图下配置Local LSR ID。

请在LDP对等体下执行mpls ldp local-lsr-id interface命令。

如果至少配置了一种LSR ID，则执行步骤(3)。

(3) 检查是否存在LDP会话的相关配置。

如果是直连会话，则在接口视图下执行display this命令，查看是否存在LDP会话的相关配置。

a. 如果配置信息中没有包含mpls enable命令、mpls ldp enable命令、mpls ldp ipv6 enable命令或mpls ldp transport-address命令，则部署对应的配置。

b. 如果存在LDP会话的相关配置，则执行步骤(4)。

如果是LDP远程会话，则在LDP视图下执行display this命令，查看是否存在LDP会话的相关配置。

c. 如果配置信息中没有包含targeted-peer或mpls ldp transport-address命令，则部署对应的配置。

d. 如果存在LDP会话的相关配置，则执行步骤(4)。

(4) 检查传输地址配置是否正确。

如果是LDP IPv4会话，请执行display mpls ldp discovery verbose命令检查传输地址配置是否正确：

<Sysname> display mpls ldp discovery verbose

VPN instance: public instance

Link Hellos:

Interface GigabitEthernet1/0/2

Local LDP ID : 100.100.100.17:0

Hello Interval : 5000 ms Hello Sent/Rcvd : 83/160

Transport Address: 100.100.100.17

Peer LDP ID : 100.100.100.18:0

Source Address : 202.118.224.18 Transport Address: 100.100.100.18

Hello Hold Time: 15 sec (Local: 15 sec, Peer: 15 sec)

Peer LDP ID : 100.100.100.20:0

Source Address : 202.118.224.20 Transport Address: 100.100.100.20

Hello Hold Time: 15 sec (Local: 15 sec, Peer: 15 sec)

Targeted Hellos:

100.100.100.17 -> 100.100.100.18 (Active, Passive)

Local LDP ID : 100.100.100.17:0

Hello Interval : 15000 ms Hello Sent/Rcvd : 23/20

Transport Address: 100.100.100.17

Session Setup : Config/Tunnel

Peer LDP ID : 100.100.100.18:0

Source Address : 100.100.100.18 Transport Address: 100.100.100.18

Hello Hold Time: 45 sec (Local: 45 sec, Peer: 45 sec)

如果是LDP IPv6会话，请执行display mpls ldp discovery ipv6 verbose命令检查传输地址配置是否正确：

<Sysname> display mpls ldp discovery ipv6 verbose

VPN instance: public instance

Link Hellos:

Interface GigabitEthernet1/0/2

Hello Interval : 5000 ms Hello Sent/Rcvd : 83/160

Transport Address: 2001::2

Peer LDP ID : 100.100.100.18:0

Source Address : FE80:130F:20C0:29FF:FEED:9E60:876A:130B

Transport Address: 2001::1

Hello Hold Time: 15 sec (Local: 15 sec, Peer: 15 sec)

Targeted Hellos:

2001:0000:130F::09C0:876A:130B ->

2005:130F::09C0:876A:130B(Active, Passive)

Hello Interval : 15000 ms Hello Sent/Rcvd : 23/22

Transport Address: 2001:0000:130F::09C0:876A:130B

Peer LDP ID : 100.100.100.18:0

Source Address : 2005:130F::09C0:876A:130B

Destination Address : 2001:0000:130F::09C0:876A:130B

Transport Address : 2005:130F::09C0:876A:130B

Hello Hold Time: 45 sec (Local: 45 sec, Peer: 45 sec)

如果传输地址配置不正确，则可以在接口视图或LDP对等体视图下执行mpls ldp transport-address命令配置传输地址。缺省情况下，传输地址为本LSR的LSR ID。

如果传输地址配置正确，则需要确认路由是否发布。执行display ip routing-table命令，查看是否存在到达会话对端的路由。

a. 如果不存在到达会话对端的路由，则请将传输地址配置成本机存在的IP地址，确保路由正确发布。

b. 如果存在到达会话对端的路由，则执行步骤(5)。

(5) 检查LDP Hello-hold定时器是否超时。

建议每5秒执行一次display mpls ldp discovery命令，查看收发Hello消息的计数，检查会话两端的Hello消息是否都正常发送。若连续几次执行命令后发现发送或接收的计数没有变化，则表示Hello消息收发异常，Hello-hold定时器超时。

¡ 如果Hello-hold定时器超时，请排除链路问题，并检查设备CPU利用率。如果CPU利用率过高，请关闭一些不必要功能；如果CPU利用率正常，则执行步骤(6)。

¡ 如果Hello-hold定时器没有超时，则执行步骤(6)。

(6) 检查LDP Keepalive-hold定时器是否超时。

建议每15秒执行一次display mpls ldp peer命令，查看收发的Keepalive消息的计数，检查会话两端的Keepalive消息是否都正常发送。若连续几次执行命令后发现发送或接收的计数没有变化，则表示Keepalive消息收发异常，Keepalive-hold定时器超时。

¡ 如果Keepalive-hold定时器超时，则排除报文转发问题。

¡ 如果Keepalive-hold定时器没有超时，则执行步骤(7)。

(7) 安全认证配置是否正确。

请执行display mpls ldp peer命令LDP会话之间的安全认证是否配置，以及配置的安全认证类型是否一致：

<Sysname> display mpls ldp peer

VPN instance: public instance

Total number of peers: 1

Peer LDP ID State Role GR Auth KA Sent/Rcvd

2.2.2.9:0 Operational Passive Off Keychain 39/39

¡ 如果LDP会话两端Auth字段显示不一致，则将LDP会话两端的安全认证修改为一致。

¡ 如果LDP会话两端Auth字段显示一致，则执行步骤(8)。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

12.1.2 LDP会话震荡

1. 故障描述

LDP会话状态频繁震荡。

2. 常见原因

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

· 接口震荡

· 路由震荡

· CPU利用率过高

3. 故障分析

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

图91 LDP会话震荡的故障诊断流程图

4. 处理步骤

(1) 检查接口是否震荡。

执行display interface brief命令，查看Physical和Protocol字段。Physical和Protocol字段均显示Up，则表示接口状态为Up，否则表示接口状态为Down。若接口一直在Up和Down两种状态间切换，则表示接口震荡。

¡ 如果接口震荡，则排除接口问题。

¡ 如果接口没有震荡，请执行步骤(2)。

(2) 检查路由是否震荡。

执行display ip routing-table命令，查看路由信息。如果路由信息一直在显示和不显示两种情况切换，则表示路由震荡。

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

¡ 如果路由没有震荡，则执行步骤(3)。

(3) TCP报文是否过大。

执行display tcp statistics命令，查看TCP连接的流量统计信息。通过Sent packets信息中data packets retransmitted（重发的数据报文数）字段的值，判断TCP报文是否过大：

¡ 如果重发的数据报文数不断增加，则表示TCP报文过大，请在报文出接口下执行tcp mss命令调整TCP MSS值。

¡ 如果重发的数据报文数未增加，则表示TCP报文大小正常，请执行步骤(4)。

(4) 检查CPU利用率是否过高。

执行display cpu-usage命令，查看CPU利用率的统计信息。

¡ 如果CPU利用率过高，则关闭一些不必要的功能，降低设备CPU利用率。

¡ 如果CPU利用率正常，则执行步骤(5)。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

12.1.3 LDP LSP无法Up

1. 故障描述

LDP网络中LDP LSP无法Up。

2. 常见原因

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

· 路由问题

· LDP会话Down

· 资源不足，如Label达到上限，内存不足等

· 配置了LSP触发策略、标签接受控制策略、标签通告控制策略或Label Mapping消息的发送策略

· 路由的出接口与LDP建立会话的接口不一致

3. 故障分析

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

(1) 检查路由是否存在。

(2) 检查LDP会话是否正常建立。

(3) 检查是否存在资源不足，入Label达到上限，内存不足的问题。

(4) 检查是否配置了LSP建立策略。

(5) 检查路由的出接口与LDP建立会话的接口是否一致。

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

图92 LDP LSP Down的故障诊断流程图

4. 处理步骤

(1) 检查路由是否存在。

执行display ip routing-table ip-address mask verbose命令，查看是否存在到达指定LSP目的地址的路由，并检查该路由是否处于激活状态（路由信息中的State字段为Active Adv，表示路由处于激活状态）。对于公网BGP路由，还需要检查路由是否带标签。如果Label字段非NULL，则表示BGP路由携带标签。路由存在时，会显示相关路由信息。路由不存在时，则不会显示相关路由信息。

<Sysname> display ip routing-table 1.1.1.1 32 verbose

Summary count : 1

Destination: 1.1.1.1/32

Protocol: O_INTRA

Process ID: 1

SubProtID: 0x1 Age: 00h00m16s

FlushedAge: 00h00m16s

Cost: 1 Preference: 10

IpPre: N/A QosLocalID: N/A

Tag: 0 State: Active Adv

OrigTblID: 0x0 OrigVrf: default-vrf

…

¡ 如果路由不存在、路由存在但未处于激活状态或者BGP路由未携带标签，则请排除路由故障。

¡ 如果路由存在且处于激活状态，对于BGP路由也带标签，则执行步骤(2)。

(2) 检查LDP会话是否正常建立。

执行display mpls ldp peer verbose命令，查看LDP会话是否成功建立：

<Sysname> display mpls ldp peer verbose

VPN instance: public instance

Peer LDP ID : 1.1.1.1:0

Local LDP ID : 2.2.2.2:0

TCP Connection : 2.2.2.2:14080 -> 1.1.1.1:646

Session State : Operational Session Role : Active

Session Up Time : 0000:00:14 (DD:HH:MM)

…

¡ 如果State字段显示不是Operational，则表示LDP会话没有正常建立，请参见“12.1.1 LDP会话无法Up”故障进行定位。

¡ 如果State字段的显示为Operational，则表示LDP会话已建立并处于Up状态，请执行步骤(3)。

(3) 检查是否配置了LSP策略。

¡ 在LDP视图下执行display this命令，如果存在以下命令，则需要检查IP前缀列表是否过滤了指定的LSP：

- lsp-trigger prefix-list

- accept-label peer prefix-list

- advertise-label prefix-list

- propagate mapping prefix-list

如果IP前缀列表过滤了指定的LSP，则请修改IP前缀列表，使其允许指定LSP目的地址通过；如果IP前缀列表没有过滤指定的LSP，则执行步骤(4)。

¡ 如果LDP视图下没有配置以上命令，则执行步骤(4)。

(4) 检查路由的出接口与LDP建立会话的接口是否一致。

执行display ip routing-table ip-address mask命令，查看指定路由的出接口信息：

<Sysname> display ip routing-table 1.1.1.1 32

Summary count : 1

Destination/Mask Proto Pre Cost NextHop Interface

1.1.1.1/32 O_INTRA 10 1 10.1.1.1 GE1/0/1

执行display mpls ldp peer peer-lsr-id verbose命令，查看指定LDP对等体的Discovery Sources信息：

<Sysname> display mpls ldp peer 1.1.1.1 verbose

VPN instance: public instance

Peer LDP ID : 1.1.1.1:0

Local LDP ID : 2.2.2.2:0

TCP Connection : 2.2.2.2:14080 -> 1.1.1.1:646

Session State : Operational Session Role : Active

Session Up Time : 0000:00:55 (DD:HH:MM)

Max PDU Length : 4096 bytes (Local: 4096 bytes, Peer: 4096 bytes)

Keepalive Time : 45 sec (Local: 45 sec, Peer: 45 sec)

Keepalive Interval : 15 sec

Msgs Sent/Rcvd : 229/228

KA Sent/Rcvd : 223/223

Label Adv Mode : DU Graceful Restart : Off

Reconnect Time : 0 sec Recovery Time : 0 sec

Loop Detection : Off Path Vector Limit: 0

mLDP P2MP : Off

Discovery Sources:

GigabitEthernet1/0/1

Hello Hold Time: 15 sec Hello Interval : 5000 ms

Addresses received from peer:

10.1.1.1 1.1.1.1

¡ 如果Discovery Sources信息的接口信息不包含指定路由的出接口，则检查指定路由的出接口上对应的LDP配置是否正确，及下游设备对应接口的LDP配置是否正确。如果不正确，则修改相应配置；如果正确，则执行步骤(5)

¡ 如果Discovery Sources信息的接口信息包含指定路由的出接口，则执行步骤(5)。

(5) 检查是否资源不足，如内存不足，LSP数量达到上限的问题。

¡ 检查系统内存是否不足

执行display memory-threshold命令，查看系统内存是否不足。如果存在内存不足，则删除不必要的LSP。

¡ 检查标签数量是否超出上限。

执行display mpls summary命令，查看LDP的标签段剩余标签数量是否为0，即Idle字段显示为0。如果LDP标签段剩余标签数量为0，则表示LDP的标签资源全部使用完，需要删除不必要的LSP。

<Sysname> display mpls summary

MPLS LSR ID : 2.2.2.2

Egress Label Type: Implicit-null

Entropy Label : Off

Labels:

Range Used/Idle/Total Owner

16-2047 0/2032/2032 StaticPW

Static

StaticCR

Static SR Adj

BSID

2048-599999 9129/588823/597952 LDP

RSVP

BGP

BGP SR EPE

OSPF SR Adj

ISIS SR Adj

¡ 如果不存在资源不足问题，请执行步骤(6)。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

12.1.4 LDP LSP震荡

1. 故障描述

LDP网络中LDP LSP频繁震荡。

2. 常见原因

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

· 路由震荡。

· LDP会话震荡。

3. 故障分析

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

(1) 检查路由是否震荡。

(2) 检查LDP会话是否震荡。

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

图93 LDP LSP震荡的故障诊断流程图

4. 处理步骤

(1) 检查路由是否震荡。

建议每1秒执行一次display ip routing-table命令，连续执行5～10次，查看到达LSP目的地址的路由信息。路由存在时，会显示相关路由信息。路由不存在时，则不会显示相关路由信息。如果相关路由信息一直在显示和不显示两种情况切换，则表示路由震荡。

查看路由信息后，请执行display mpls ldp fec命令查看LSP下游信息，即Downstream Info中的State字段，确保与下游对等体建立的LSP处于激活状态（Established）。

<Sysname> display mpls ldp fec

VPN instance: public instance

FEC: 1.1.1.1/32

Flags: 0x112

In Label: 2175

Upstream Info:

Peer: 1.1.1.1:0 State: Established

Downstream Info:

Peer: 1.1.1.1:0

Out Label: 3 State: Established

Next Hops: 10.1.1.1 GE1/0/1

RIB Info:

Protocol : OSPF BGP As Num : 0

Label Proto ID : 1 NextHopCount : 1

VN ID : 0x313000003

Tunnel ID : -

¡ 如果路由震荡，或者路由一直都不存在，则请排除路由问题。

¡ 如果路由没有震荡，则执行步骤(2)。

(2) 检查LDP会话是否震荡。

建议每1秒执行一次display mpls ldp peer命令，连续执行5～10次，查看显示信息的State字段。如果该字段的取值在Operational状态和其他非Operational状态之间切换，则表示LDP会话震荡。

<Sysname> display mpls ldp peer

VPN instance: public instance

Total number of peers: 1

Peer LDP ID State Role GR AUT KA Sent/Rcvd

1.1.1.1:0 Operational Active Off None 298/298

¡ 如果LDP会话震荡，则请参见“12.1.2 LDP会话震荡”故障进行定位。

¡ 如果LDP会话没有震荡，则执行步骤(3)。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

12.2 MPLS L2VPN/VPLS故障处理

12.2.1 PW ping不通

1. 故障描述

执行ping mpls pw命令检测PW连通性，发现ping不通对端。

2. 常见原因

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

· 检测的PW不存在。

· PW模板配置错误。

· PW故障。

· PW不存在有效的公网转发路径。

3. 故障分析

本类故障需要根据ping mpls pw命令的回显信息进行分析和定位，具体诊断思路如下：

· 回显信息为Unknown PW时，表示检测的PW不存在，需要修改配置来解决本类故障。

· 回显信息为No suitable control channel for the PW时，表示PW的VCCV控制通道类型配置错误，需要通过vccv cc命令修改PW模板中VCCV控制通道类型来解决本类故障。

· 回显信息为Please configure pseudowire control-word for control channel时，表示PW引用的PW模板中未开启控制字功能，需要通过control-word enable命令在PW模板下开启控制字功能来解决本类故障。（不支持control-word enable命令的产品请忽略此步骤）

· 回显信息为Request time out时，先排查本端PW是否Up，再通过tracert mpls pw命令来定位故障节点。

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

图94 PW ping不通的故障诊断流程图

4. 处理步骤

回显信息为Unknown PW时，本类故障的处理步骤为：修改配置确保检测的PW存在。

回显信息为No suitable control channel for the PW时，本类故障的处理步骤为：通过vccv cc命令将PW两端的VCCV控制通道类型配置一致。

回显信息为Please configure pseudowire control-word for control channel时，本类故障的处理步骤为：通过control-word enable命令在PW模板下开启控制字功能。（不支持control-word enable命令的产品请忽略此步骤）

回显信息为Request time out时，本类故障的处理步骤如下：

(1) 执行display l2vpn pw命令查看PW是否Up。

<Sysname> display l2vpn pw

Flags: M - main, B - backup, E - ecmp, BY - bypass, H - hub link, S - spoke link

N - no split horizon, A - administration, ABY - ac-bypass

PBY - pw-bypass

Total number of PWs: 2

2 up, 0 blocked, 0 down, 0 defect, 0 idle, 0 duplicate

Xconnect-group Name: ldp

Peer PWID/RmtSite/SrvID In/Out Label Proto Flag Link ID State

192.3.3.3 500 1299/1299 LDP M 0 Up

VSI Name: aaa

Peer PWID/RmtSite/SrvID In/Out Label Proto Flag Link ID State

2.2.2.9 2 1420/1419 BGP M 9 Up

¡ 若PW为Down状态，请通过display l2vpn pw verbose命令查看PW状态变为Down的原因，并根据故障原因进行故障处理。

<Sysname> display l2vpn pw verbose

VSI Name: aaa

Peer: 2.2.2.9 Remote Site: 2

Signaling Protocol : BGP

Link ID : 9 PW State : Down

In Label : 1420 Out Label: 1419

MTU : 1500

PW Attributes : Main

VCCV CC : -

VCCV BFD : -

Flow Label : Send

Control Word : Disabled

Tunnel Group ID : 0x800000960000000

Tunnel NHLFE IDs : 1038

Admin PW : -

E-Tree Mode : -

E-Tree Role : root

Root VLAN : -

Leaf VLAN : -

Down Reasons : Control word not match

常见的故障原因及处理方法如下：

- BFD session for PW down：用来检测PW的BFD会话状态为down，此类故障的处理方式为，通过display bfd session命令查看BFD状态为down的原因，检查并修改BFD配置或检查物理链路是否存在链路故障、链路质量问题。

- BGP RD was deleted：BGP的RD被删除，此类故障的处理方式为，在交叉连接组自动发现视图下配置route-distinguisher route-distinguisher命令。

- BGP RD was empty：未配置BGP的RD，此类故障的处理方式为，在交叉连接组自动发现视图下配置route-distinguisher route-distinguisher命令。

- Control word not match：PW两端控制字功能配置不一致，此类故障的处理方式为，将PW两端引用的PW模板下的控制字功能（通过control-word enable命令开启）配置一致。（不支持control-word enable命令的产品请忽略此步骤）

- Encapsulation not match：PW两端封装类型不一致，此类故障的处理方式为，将PW两端引用的PW模板下的PW数据封装类型（通过pw-type命令配置）配置一致。（不支持pw-type命令的产品请忽略此步骤）

- LDP interface parameter not match：PW两端接口LDP协商参数不一致，此类故障的处理方式为，将PW两端引用的PW模板下的VCCV控制通道类型（通过vccv cc命令配置）配置一致或将PW两端关联的电路仿真接口下引用的电路仿真类中的配置保持一致。

- Non-existent remote LDP PW：对端设备已删除LDP PW，此类故障的处理方式为，在对端设备上重新配置PW。

- Local AC Down：本地AC状态为down，此类故障的处理方式为，检查并修改AC接口上的配置或排除AC所在的接口的故障，保障接口为Up状态。

- Local AC was non-existent：未配置本地AC，此类故障的处理方式为，配置本地的AC并关联VSI。

- MTU not match：PW两端MTU不一致，此类故障的处理方式为，将PW两端的MTU配置一致或者通过mtu-negotiate disable命令关闭PW MTU协商功能。（不支持mtu-negotiate disable命令的产品请忽略此步骤）

- Remote AC Down：对端AC状态down，此类故障的处理方式为，检查并修改对端AC接口上的配置或排除AC所在的接口的故障，保障接口为Up状态。

¡ 若PW为Up状态，请继续执行第(2)步。

(2) 执行display l2vpn forwarding pw verbose命令，查看PW的转发信息中入标签（In Label）、出标签（Out Label）和承载PW的隧道对应的NHLFE表项索引值（Tunnel NHLFE IDs）是否为有效值。

<Sysname> display l2vpn forwarding pw verbose

Xconnect-group Name: xcg1

Connection Name: c1

Link ID: 0

PW Type : VLAN PW State : Up

In Label : 110126 Out Label: 130126

MTU : 1500

PW Attributes : Main

VCCV CC : Router-Alert

VCCV BFD : Fault Detection with BFD

Flow Label : -

Tunnel Group ID : 0x800000130000001

Tunnel NHLFE IDs : 3

VSI Name: aaa

Link ID: 8

PW Type : VLAN PW State : Up

In Label : 1272 Out Label: 1275

MTU : 1500

PW Attributes : Main

VCCV CC : -

VCCV BFD : Fault Detection with BFD

Flow Label : -

Tunnel Group ID : 0x960000000

Tunnel NHLFE IDs: 1034

¡ 若入、出标签取值为空或者为“-”。请先执行display l2vpn pw verbose命令查看PW使用的信令协议（Signaling Protocol），再修改建立PW的信令协议相关配置是否正确：

- 若信令协议为BGP，则需要检查并修改BGP相关配置；

- 若信令协议为LDP，则需要检查并修改LDP相关配置；

- 若信令协议为Static，则需要检查并修改静态PW配置。

有关PW信令协议相关配置的详细介绍，请参见产品手册的“MPLS配置指导”中的“MPLS L2VPN”和“VPLS”。

¡ 若Tunnel NHLFE IDs取值为空，请继续执行第(3)步。。

¡ 若PW的转发信息正常，请继续执行第(4)步。

(3) 执行display mpls lsp命令，查看是否存在承载PW的隧道，即是否存在FEC为PW对端IP地址的LSP，若不存在，则需要先完成承载PW的隧道的建立。

<Sysname> display mpls lsp

FEC Proto In/Out Label Out Inter/NHLFE/LSINDEX

100.100.100.100/24 LDP -/1049 GE1/0/1

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

¡ 上述步骤的执行结果。

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

¡ 使用display diagnostic-information命令收集诊断信息。

5. 告警与日志

相关告警

无。

相关日志

· L2VPN/2/L2VPN_PWSTATE_CHANGE

· L2VPN/4/L2VPN_BGPVC_CONFLICT_LOCAL

· L2VPN/4/L2VPN_BGPVC_CONFLICT_REMOTE

· L2VPN/4/L2VPN_HARD_RESOURCE_NOENOUGH

· L2VPN/2/L2VPN_HARD_RESOURCE_RESTORE

· L2VPN/4/L2VPN_LABEL_DUPLICATE

12.3 MPLS L3VPN故障处理

12.3.1 L3VPN流量中断

1. 故障描述

经过MPLS L3VPN网络转发的私网流量中断。

2. 常见原因

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

· 私网路由下一跳不可达。

· 路由策略配置不当导致路由无法发布和接收。

· 标签超限导致私网路由无法发布。

· 私网路由迭代不到隧道。

· Export RT和Import RT不匹配导致路由无法学习到私网路由表中。

· 路由超限导致收到的路由被丢弃。

3. 故障分析

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

图95 L3VPN流量中断故障诊断流程图

4. 处理步骤

(1) 检查路由是否为最优路由。

执行命令display bgp routing-table vpnv4或display bgp routing-table vpnv6命令，查看BGP VPNv4/VPNv6路由表中到达VPNv4/VPNv6邻居的BGP路由是否最优。

以路由100.1.2.0/24为例，路由信息中存在标记“>”，则表示该路由为最优路由。

<Sysname> display bgp routing-table vpnv4

BGP local router ID is 1.1.1.9

Status codes: * - valid, > - best, d - dampened, h - history,

s - suppressed, S - stale, i - internal, e - external

a – additional-path

Origin: i - IGP, e - EGP, ? - incomplete

Total number of VPN routes: 8

Total number of routes from all PEs: 8

Route distinguisher: 100:1(vpn1)

Total number of routes: 6

Network NextHop MED LocPrf PrefVal Path/Ogn

* > 1.1.1.0/24 1.1.1.1 0 32768 ?

* 1.1.1.2/32 1.1.1.1 0 32768 ?

* > 100.1.2.0/24 100.1.1.1 0 100 0 400i

根据以上显示信息进行判断：

¡ 如果不是最优路由，则执行display mpls lsp命令，查看是否存在指定路由的MPLS转发表项。如果不存在，则请在连接远端PE的公网接口下执行mpls enable和mpls ldp enable命令，开启MPLS功能和LDP功能，保证VPNv4路由可以迭代到公网LSP；如果存在，则执行步骤(2)。

¡ 如果是最优路由，则执行步骤(2)。

(2) 检查私网路由下一跳是否可达。

在路由的发送端（本端PE）执行display bgp routing-table vpnv4 ipv4-address [ mask | mask-length ]命令查看私网路由信息（ipv4-address表示私网路由前缀），确认路由是否存在。

¡ 如果路由不存在，请确认CE路由是否发布到PE。在远端PE上执行display bgp routing-table vpnv4 peer advertised-routes或display bgp routing-table vpnv6 peer advertised-routes命令，查看远端PE是否将私网路由信息发布给本端PE，例如：

<Sysname> display bgp routing-table vpnv4 peer 22.22.22.22 advertised-routes

Total number of routes: 6

BGP local router ID is 11.11.11.11

Status codes: * - valid, > - best, d - dampened, h - history,

s - suppressed, S - stale, i - internal, e - external

a - additional-path

Origin: i - IGP, e - EGP, ? - incomplete

Route distinguisher: 1:1

Total number of routes: 3

Network NextHop MED LocPrf Path/Ogn

* >e 1.1.1.1/32 10.1.1.2 0 100 20i

* >e 7.7.7.7/32 10.1.1.2 0 100 20?

* >e 10.1.1.0/24 10.1.1.2 0 100 20?

如果不存在以上显示信息，则执行步骤(3)。

¡ 如果路由存在，请确认私网路由下一跳是否可达，且私网路由是否活跃。

查看State字段，如果取值包括valid，则表示该路由是活跃的。查看Original nexthop字段，如果存在下一跳信息，则表示私网路由下一跳可达。

- 如果私网路由不活跃，则执行display ip routing-table vpn-instance vpn-instance-name ip-address命令查看IP路由表中是否存在到BGP下一跳（Original nexthop）的路由。如果不存在，则说明私网路由下一跳不可达，请检查PE之间的公网路由配置；如果存在，则说明BGP路由下一跳可达，请执行步骤(3)。

- 如果私网路由活跃，则执行步骤(3)。

<sysname> display bgp routing-table vpnv4 6.0.0.9 32

BGP local router ID: 4.0.0.9

Local AS number: 200

Route distinguisher: 103:1

Total number of routes: 1

Paths: 1 available, 1 best

BGP routing table information of 6.0.0.9/32:

From : 3.0.0.9 (3.0.0.9)

Rely nexthop : 20.0.2.1

Original nexthop: 3.0.0.9

OutLabel : 24128

Ext-Community : <RT: 100:1>

RxPathID : 0x0

TxPathID : 0x0

AS-path : 300 103

Origin : igp

Attribute value : pref-val 0

State : valid, external, best

IP precedence : N/A

QoS local ID : N/A

Traffic index : N/A

Tunnel policy : tp1

Rely tunnel IDs : 2

(3) 检查路由策略是否正确。

在路由的发送端和接收端执行display current-configuration configuration bgp命令查看BGP配置，确认是否配置邻居的出方向和入方向策略。

<sysname> display current-configuration configuration bgp

bgp 100

peer 1.1.1.1 as-number 100

peer 3.3.3.3 as-number 100

peer 3.3.3.3 connect-interface LoopBack1

address-family vpnv4

peer 3.3.3.3 enable

peer 3.3.3.3 route-policy in import

peer 3.3.3.3 route-policy out export

return

如果两端配置了出方向和入方向策略，则需要确认这些策略是否会把私网路由过滤掉，导致该路由无法正常收发。

如果两端没有配置相应的出方向和入方向策略，或者路由策略没有过滤掉私网路由，则执行步骤(4)。

(4) 检查路由是否能迭代到隧道。

在路由的接收端（远端PE）执行display bgp routing-table vpnv4 ipv4-address [ mask | mask-length ]命令查看VPNv4路由，确认VPNv4路由是否可以迭代到隧道。

如果显示信息中存在Rely tunnel IDs字段，则表示该路由可以迭代到隧道。

¡ 如果迭代不到隧道，则请参见“LDP LSP无法Up”故障进行定位。

¡ 如果迭代到隧道，则执行步骤(5)。

<sysname> display bgp routing-table vpnv4 6.0.0.9 32

BGP local router ID: 4.0.0.9

Local AS number: 200

Route distinguisher: 103:1

Total number of routes: 1

Paths: 1 available, 1 best

BGP routing table information of 6.0.0.9/32:

From : 3.0.0.9 (3.0.0.9)

Rely nexthop : 20.0.2.1

Original nexthop: 3.0.0.9

OutLabel : 24128

Ext-Community : <RT: 100:1>

RxPathID : 0x0

TxPathID : 0x0

AS-path : 300 103

Origin : igp

Attribute value : pref-val 0

State : valid, external, best

IP precedence : N/A

QoS local ID : N/A

Traffic index : N/A

Tunnel policy : tp1

Rely tunnel IDs : 2

(5) 检查是否Export RT和Import RT不匹配导致路由无法学习到私网路由表中。

在路由的发送端（本端PE）和接收端（远端PE）执行display bgp routing-table vpnv4和display current-configuration configuration vpn-instance命令，查看是否本端VPN实例的Export RT与远端VPN实例的Import RT不匹配，导致路由发送到远端PE后无法学习到远端VPN实例中。

在本端PE上执行display bgp routing-table vpnv4和display ip extcommunity-list命令查看本端VPN实例的ERT是否被过滤，导致路由无法发布。

¡ 如果Export RT和Import RT不匹配，则请在VPN实例下执行vpn-target命令配置匹配的RT值。

¡ 如果Export RT被路由策略过滤，则请在路由策略视图下执行apply extcommunity rt命令修改路由策略，取消过滤指定的RT属性。

¡ 如果Export RT和Import RT匹配，或者Export RT未被路由策略过滤，则执行步骤(6)。

查看路由携带的ERT：

<sysname> display bgp routing-table vpnv4 6.0.0.9 32

BGP local router ID: 4.0.0.9

Local AS number: 200

Route distinguisher: 103:1

Total number of routes: 1

Paths: 1 available, 1 best

BGP routing table information of 6.0.0.9/32:

From : 3.0.0.9 (3.0.0.9)

Rely nexthop : 20.0.2.1

Original nexthop: 3.0.0.9

OutLabel : 24128

Ext-Community : <RT: 100:1>

RxPathID : 0x0

TxPathID : 0x0

AS-path : 300 103

Origin : igp

Attribute value : pref-val 0

State : valid, external, best

IP precedence : N/A

QoS local ID : N/A

Traffic index : N/A

Tunnel policy : tp1

Rely tunnel IDs : 2

查看BGP扩展团体属性列表信息：

<sysname> display ip extcommunity-list 1

Extended Community List Number 10

Deny rt: 100:1

Extended Community List Number 20

Permit rt: 200:1

查看本地配置的IRT：

<sysname> display current-configuration configuration vpn-instance

ip vpn-instance vpn1

route-distinguisher 1:1

vpn-target 100:1 import-extcommunity

vpn-target 100:1 export-extcommunity

(6) 检查MPLS标签数量是否超限。

在路由发送端（本端PE）执行display mpls interface命令确认与远端PE相连的公网接口是否开启了MPLS功能。

¡ 如果显示信息中存在与远端PE相连的公网接口，则表示与远端PE相连的公网接口开启了MPLS功能。

¡ 如果显示信息中不存在与远端PE相连的公网接口，则在与远端PE相连的公网接口视图下执行mpls enable命令，开启MPLS功能。

<Sysname> display mpls interface

Interface Status MPLS MTU

GE1/0/1 Up 1500

GE1/0/2 Up 1500

使用display bgp routing-table vpnv4 advertise-info命令查看路由发送时是否申请标签。

¡ 如果显示信息中Inlabel字段无取值，则可能是由于标签资源不足，导致无法为该路由申请标签。如果是标签不足，则可以通过以下方法减少标签的使用量：

- 在VPN实例视图下执行apply-label per-instance命令配置每实例每标签。

- 通过路由聚合来减少路由数量。

- 在系统视图下执行mpls max-label命令增加设备可分配的标签数量。

¡ 如果显示信息中Inlabel字段有合理值，则表示标签资源充足，已经为该路由申请标签，请执行步骤(7)。

<Sysname> display bgp routing-table vpnv4 10.1.1.0 24 advertise-info

BGP local router ID: 1.1.1.9

Local AS number: 100

Route distinguisher: 100:1

Total number of routes: 1

Paths: 1 best

BGP routing table information of 10.1.1.0/24(TxPathID:0):

Advertised to VPN peers (1 in total):

3.3.3.9

Inlabel : 1279

(7) 检查路由数量是否超限。

执行display bgp peer vpnv4 log-info命令，查看指定对等体的日志信息。如果显示Cease/maximum number of VPNv4 prefixes reached，则表示路由数量超规格。

<Sysname> display bgp peer vpnv4 1.1.1.1 log-info

Peer : 1.1.1.1

Date Time State Notification

Error/SubError

06-Feb-2013 22:54:42 Down Send notification with error 6/1

Cease/maximum number of VPNv4 prefixes reached

如果设备上打印如下日志信息，则表示路由数量超规格。

BGP/4/BGP_EXCEED_ROUTE_LIMIT: BGP default.vpn1: The number of routes (101) from peer 1.1.1.1 (IPv4-UNC) exceeds the limit 100.

BGP/4/BGP_REACHED_THRESHOLD: BGP default.vpn1: The ratio of the number of routes (3) received from peer 1.1.1.1 (IPv4-UNC) to the number of allowed routes (2) has reached the threshold (75%).

¡ 如果路由数量超规格，则在路由接收端的VPNv4地址族视图或者VPNv6地址族视图下执行peer route-limit命令调大允许从对等体接收路由的最大数目。

¡ 如果路由数量未超规格，则执行步骤(8)。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

12.3.2 L3VPN私网路由频繁震荡

1. 故障描述

远端PE发布的私网路由在本端PE上频繁震荡。

2. 常见原因

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

· 公网路由震荡

· LDP LSP震荡

· 接口震荡

3. 故障分析

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

图96 L3VPN私网路由频繁震荡故障诊断流程图

4. 处理步骤

(1) 检查公网路由是否震荡。

a. 确认路由类型。

执行display ip routing-table命令查看路由类型。

以如下显示为例，Proto字段显示为IS_L1，表示路由类型为IS-IS；Interface字段显示为Tun1，表示部署了LDP over MPLS TE。

<Sysname> display ip routing-table 1.1.1.1

Summary count : 1

Destination/Mask Proto Pre Cost NextHop Interface

1.1.1.1/32 IS_L1 15 10 1.1.1.1 Tun1

b. 查看路由是否震荡。

根据路由类型，判断路由是否震荡。以IS-IS为例，执行display ip routing-table protocol isis命令，查看路由信息。如果路由信息一直在显示和不显示两种情况切换，则表示路由震荡。

- 如果路由震荡，请按照路由类型，参见“OSPF邻居Down”、“OSPFv3邻居Down”或“IS-IS路由震荡”故障处理，排除路由问题。

- 如果路由没有震荡，请执行步骤(2)。

(2) 检查LDP LSP是否震荡。

建议每1秒执行一次display mpls ldp peer命令，连续执行5～10次，查看显示信息的State字段。如果该字段的取值在Operational状态和其他状态之间切换，则表示LDP会话震荡，导致LDP LSP震荡。

¡ 如果LDP LSP震荡，则请参见“LDP LSP震荡”故障进行定位。

¡ 如果LDP LSP没有震荡，则执行步骤(3)。

<Sysname> display mpls ldp peer

VPN instance: public instance

Total number of peers: 1

Peer LDP ID State Role GR AUT KA Sent/Rcvd

1.1.1.1:0 Operational Active Off None 298/298

(3) 检查接口是否震荡。

执行display interface brief命令，查看Link和Protocol字段。Link和Protocol字段均显示Up，则表示接口状态为Up，否则表示接口状态为Down。若接口一直在Up和Down两种状态间切换，则表示接口震荡。

¡ 如果接口震荡，则请参见“接口不UP”故障进行定位。

¡ 如果接口没有震荡，请执行步骤(4)。

<Sysname> display interface gigabitethernet 1/0/1 brief

Brief information on interfaces in route mode:

Link: ADM - administratively down; Stby - standby

Protocol: (s) – spoofing

Interface Link Protocol Primary IP Description

GE1/0/1 UP UP --

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

12.3.3 PE间无法交换VPN路由

1. 故障描述

PE间无法交换VPNv4或VPNv6路由。

2. 常见原因

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

· 公网IGP路由未发布

· 公网LSP不存在

· BGP对等体未建立

· 未学习到VPNv4或VPNv6路由

3. 故障分析

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

图97 PE间无法交换私网路由故障诊断流程图

4. 处理步骤

(1) 检查IGP路由是否存在。

执行display ip routing-table命令，查看是否存在到达对端PE的Loopback接口的网段路由：

<Sysname> display ip routing-table 1.1.1.1

Summary count : 1

Destination/Mask Proto Pre Cost NextHop Interface

1.1.1.2/32 IS_L1 15 10 1.1.1.1 LoopBack1

¡ 如果不存在，则在Loopback接口和公网接口下使能IGP协议，确保发布对应网段路由。

¡ 如果存在，则执行步骤(2)。

(2) 检查公网LSP是否存在。

执行display mpls lsp命令，查看是否存在到达远端PE的Loopback接口的公网LSP：

¡ 如果不存在，则在公网接口下使能MPLS功能和MPLS LDP功能，确保建立公网LSP。

¡ 如果存在，则执行步骤(3)。

<Sysname> display mpls lsp

FEC Proto In/Out Label Out Inter/NHLFE/LSINDEX

1.1.1.2/32 LDP -/1049 GE1/0/1

<Sysname> display mpls lsp

FEC Proto In/Out Label Out Inter/NHLFE/LSINDEX

1.1.1.1/24 LDP -/1051 GE1/0/1

执行display mpls ldp peer verbose命令，查看LDP会话是否成功建立：

¡ 如果State字段显示不是Operational，则表示LDP会话没有正常建立，请参见“LDP会话无法Up”故障进行定位。

¡ 如果State字段的显示为Operational，则表示LDP会话已建立并处于Up状态，请执行步骤(3)。

<Sysname> display mpls ldp peer verbose

VPN instance: public instance

Peer LDP ID : 1.1.1.1:0

Local LDP ID : 2.2.2.2:0

TCP Connection : 2.2.2.2:14080 -> 1.1.1.1:646

Session State : Operational Session Role : Active

Session Up Time : 0000:00:14 (DD:HH:MM)

…

(3) 检查BGP对等体关系是否建立。

执行display bgp peer vpnv4命令，查看PE之间BGP VPNv4对等体关系，并执行display bgp peer ipv4 vpn-instance命令，查看PE与CE之间BGP对等体关系：

¡ 如果不存在BGP对等体关系，或者State字段显示不是Established，则表示未建立BGP对等体关系，请参见“BGP邻居无法建立”故障进行定位。

¡ 如果State字段的显示为Established，则表示已建立BGP对等体关系，请执行步骤(4)。

<Sysname> display bgp peer vpnv4

BGP local router ID: 192.168.100.1

Local AS number: 100

Total number of peers: 1 Peers in established state: 1

* - Dynamically created peer

Peer AS MsgRcvd MsgSent OutQ PrefRcv Up/Down State

1.1.1.2 200 13 16 0 0 00:10:34 Established

<Sysname> display bgp peer ipv4 vpn-instance vpn1

BGP local router ID: 1.1.1.1

Local AS number: 100

Total number of peers: 1 Peers in established state: 1

* - Dynamically created peer

Peer AS MsgRcvd MsgSent OutQ PrefRcv Up/Down State

10.1.1.1 65410 5 4 0 1 00:01:19 Established

(4) 检查私网路由是否正常。

执行display ip routing-table vpn-instance命令，查看私网路由：

¡ 如果私网路由的掩码不是32位，且发现该路由的协议不是BGP协议，则表示两端PE的Loopback接口的IP地址在同一网段，设备将优选直连路由，而不是私网路由。请修改PE上的Loopback接口的IP地址，将掩码修改为为32位。

¡ 如果私网路由的掩码是32位，且发现该路由的协议是BGP协议，则私网路由正常，请执行步骤(5)。

<Sysname> display ip routing-table vpn-instance vpn1

Summary count : 1

Destination/Mask Proto Pre Cost NextHop Interface

1.1.1.0/24 Direct 0 0 1.1.1.1 LoopBack1

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

12.3.4 配置相同RT的不同VPN之间不能互通

1. 故障描述

在图98的网络中，配置MPLS L3VPN业务，CE 1与CE 3属于VPN 1，CE 2属于VPN 2。由于业务的需求，在VPN 1和VPN 2上配置了相同的Route Target，以实现不同VPN间互通。

配置完成后，发现CE 1可以Ping通相同VPN的CE 3（IP地址为3.3.3.3），但CE 2无法Ping通不同VPN的3.3.3.3。

图98 MPLS L3VPN组网图

2. 常见原因

本场景中，CE 1可以Ping通相同VPN的CE 3，说明MPLS骨干网中进行标签转发的公网隧道正常，本类故障的常见原因仅包括：PE设备上不同的VPN实例绑定的IP地址存在冲突。

3. 故障分析

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

图99 配置相同RT的不同VPN之间不能互通的故障诊断流程图

4. 处理步骤

(1) 检查PE的接口IP是否存在冲突。

在PE 1上执行display ip interface brief命令查看接口的IP地址，例如：

<Sysname> display ip interface brief

*down: administratively down

(s): spoofing (l): loopback

Interface Physical Protocol IP Address/Mask VPN instance Description

...

GE1/0/1 up up 10.1.1.1/24 vpn1 --

GE1/0/2 up up 10.1.1.1/24 vpn2 --

...

如果不同VPN实例的接口IP地址不相同，请执行步骤（2）。

如果不同VPN实例的接口IP相同，则修改其中一个VPN实例中PE上的接口以及与其相连的CE上的接口的IP地址，并重新配置PE设备与CE设备间的路由交换。

由于BGP会将RT匹配的路由在VPN实例间进行互引，为不同VPN的接口设置相同IP地址时，同一目的地址的路由在BGP路由表中将会出现两条，而BGP只会优选其中一条，例如：

<Sysname> display bgp routing-table vpnv4

BGP local router ID is 11.11.11.11

Status codes: * - valid, > - best, d - dampened, h - history,

s - suppressed, S - stale, i - internal, e - external

a - additional-path

Origin: i - IGP, e - EGP, ? - incomplete

Total number of VPN routes: 11

Total number of routes from all PEs: 2

Route distinguisher: 1:1(vpn1)

Total number of routes: 6

Network NextHop MED LocPrf PrefVal Path/Ogn

* >e 1.1.1.1/32 10.1.1.2 0 0 20i

* >e 2.2.2.2/32 10.1.1.2 0 0 30i

* >i 3.3.3.3/32 22.22.22.22 0 100 0 40i

* >e 10.1.1.0/24 10.1.1.2 0 0 20?

* >i 30.1.1.0/24 22.22.22.22 0 100 0 40?

Route distinguisher: 2:2(vpn2)

Total number of routes: 5

Network NextHop MED LocPrf PrefVal Path/Ogn

* >e 1.1.1.1/32 10.1.1.2 0 0 20i

* >e 2.2.2.2/32 10.1.1.2 0 0 30i

* >i 3.3.3.3/32 22.22.22.22 0 100 0 40i

* >e 10.1.1.0/24 10.1.1.2 0 0 20?

* e 10.1.1.2 0 0 30?

* >i 30.1.1.0/24 22.22.22.22 0 100 0 40?

如上所示，在RD为2:2的VPN实例（即VPN 2）BGP路由表中，优选的10.1.1.0网段的路由来自VPN 1（根据AS_PATH属性判断），VPN 2发布的路由未被优选，所以从VPN 1去往VPN 2的流量不会被PE 1从GigabitEthernet1/0/2接口发送给VPN 2，而是从GigabitEthernet1/0/1接口发送给VPN 1，导致跨VPN通信失败。

所以，将关联了VPN实例的接口以及与其相连的CE上的接口修改为不同的IP地址，可以解决这类问题。以PE-CE间通过EBGP会话交互路由为例，PE 1的处理步骤如下：

a. 在系统视图下，执行interface命令进入关联了VPN实例的接口视图。

b. 执行ip address命令修改接口的IP地址。

c. 在系统视图下，执行bgp命令进入BGP实例视图。

d. 执行ip vpn-instance命令进入BGP-VPN实例视图。

e. 执行undo peer命令删除用原冲突IP地址建立的BGP对等体。

f. 执行peer as-number命令，指定使用新IP地址的CE设备为EBGP对等体。

g. 执行address-family ipv4 unicast命令，进入BGP IPv4单播地址族视图。

h. 执行peer enable命令，使能与CE设备交互BGP IPv4单播路由信息的能力。

假设仅修改了VPN 2的IP地址，则CE 2的处理步骤如下：

a. 在系统视图下，执行interface命令进入与PE 1直连的接口视图。

b. 执行ip address命令修改接口的IP地址。

c. 在系统视图下，执行bgp命令进入BGP实例视图。

d. 执行undo peer命令删除用原冲突IP地址建立的BGP对等体。

e. 执行peer as-number命令，指定使用新IP地址的PE设备为EBGP对等体。

f. 执行address-family ipv4 unicast命令，进入BGP IPv4单播地址族视图。

g. 执行peer enable命令，使能与PE设备交互BGP IPv4单播路由信息的能力。

h. 执行import-route命令或network命令，发布VPN实例的路由信息。

如果故障仍然未能排除，请执行步骤（2）。

(2) 请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

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

5. 告警与日志

12.3.5 路由反射器进行VPN-Target过滤导致PE无法学习到路由

1. 故障描述

PE设备发布的MVPN路由、VPNv4/VPNv6路由、BGP L2VPN信息、VPN Flowspec路由以及EVPN路由无法通过路由反射器反射给远端PE。

2. 常见原因

路由反射器缺省会对MVPN路由、VPNv4/VPNv6路由、BGP L2VPN信息、VPN Flowspec路由以及EVPN路由进行VPN-Target过滤，即只将Export Route Target属性与本地Import Route Target属性匹配的路由信息加入到路由表。路由反射器上不存在与接收路由匹配的Route Target时，接收到的路由将被丢弃，导致无法转发该路由信息给远端PE。

3. 故障分析

关闭路由反射器的VPN-Target过滤功能，可以解决本类故障，本故障的处理流程如图100所示。

图100 路由反射器进行VPN-Target过滤导致PE无法学习到路由故障处理流程

4. 处理步骤

(2) 检查对应地址族配置，确保配置了undo policy vpn-target命令：

a. 在BGP实例视图下，执行display this命令，查看在各地址族视图下是否存在undo policy vpn-target配置。如果不存在，请执行步骤b；如果存在，请执行步骤（2）。

b. 进入相应的地址族视图，通过undo policy vpn-target命令关闭VPN-Target过滤，使得路由反射器可以转发RT不匹配的路由信息。如果故障仍不能排除，请执行步骤（2）。

(3) 请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

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

5. 告警与日志

12.3.6 PE的私网IP路由表中没有远端PE发布的路由

1. 故障描述

在MPLS L3VPN/IPv6 MPLS L3VPN网络中，PE的VPN实例IP路由表中没有远端PE用户站点的私网路由，导致CE间无法互通。

2. 常见原因

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

· 与远端PE的BGP会话未进入Established状态。

· 远端PE未发送私网路由。

· 公网隧道未建立。

· 远端PE发送的私网路由被本端丢弃。

· 远端PE发送的私网路由在本端的BGP路由表中，但未被添加到VPN实例的IP路由表中。

3. 故障分析

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

图101 PE的私网IP路由表中没有远端PE发布的路由故障诊断流程图

4. 处理步骤

(1) 检查BGP邻居是否建立。

执行display bgp peer vpnv4或display bgp peer vpnv6命令，查看本端PE与远端PE是否建立起了处于Established状态的BGP会话，例如：

<Sysname> display bgp peer vpnv4

BGP local router ID: 11.11.11.11

Local AS number: 10

Total number of peers: 1 Peers in established state: 1

* - Dynamically created peer

Peer AS MsgRcvd MsgSent OutQ PrefRcv Up/Down State

22.22.22.22 10 82 69 0 2 01:01:28 Established

¡ 如果已经建立，请执行步骤（3）。

¡ 如果未建立，请参见“三层技术-IP路由类故障处理”手册中的“BGP会话无法进入Established状态”进行定位。BGP会话进入Established状态后，如果故障仍未能排除，请执行步骤（2）。

(2) 查看远端PE是否向本端发布了私网路由信息。

在远端PE上执行display bgp routing-table vpnv4 peer advertised-routes或display bgp routing-table vpnv6 peer advertised-routes命令，查看远端PE是否将私网路由信息发布给本端PE，例如：

<Sysname> display bgp routing-table vpnv4 peer 22.22.22.22 advertised-routes

Total number of routes: 6

BGP local router ID is 11.11.11.11

Status codes: * - valid, > - best, d - dampened, h - history,

s - suppressed, S - stale, i - internal, e - external

a - additional-path

Origin: i - IGP, e - EGP, ? - incomplete

Route distinguisher: 1:1

Total number of routes: 3

Network NextHop MED LocPrf Path/Ogn

* >e 1.1.1.1/32 10.1.1.2 0 100 20i

* >e 7.7.7.7/32 10.1.1.2 0 100 20?

* >e 10.1.1.0/24 10.1.1.2 0 100 20?

Route distinguisher: 2:2

Total number of routes: 3

Network NextHop MED LocPrf Path/Ogn

* >e 2.2.2.2/32 10.1.1.2 0 100 30i

* >e 7.7.7.7/32 10.1.1.2 0 100 30?

* >e 10.1.1.0/24 10.1.1.2 0 100 30?

如果存在这样的信息，请执行步骤（3），如果不存在，则进行如下检查：

a. 在远端PE上执行display bgp routing-table vpnv4或display bgp routing-table vpnv6命令，查看是否存在想要发布的私网路由。

- 如果存在，请执行步骤b。

- 如果不存在，则检查PE-CE间的配置。PE与CE间可以使用多种协议交互路由信息，包括静态路由、RIP、OSPF、OSPFv3、IS-IS、BGP等。关于BGP路由协议故障处理方法，请参见“三层技术-IP路由类故障处理手册”中的“BGP故障处理”；常见的IGP路由协议故障处理方法，请参见“三层技术-IP路由类故障处理”手册中的“OSPF故障处理”、“OSPFv3故障处理”或“IS-IS故障处理”。远端PE的BGP路由表获得了私网路由后，如果故障仍不能排除，请执行步骤b。

b. 在远端PE的BGP VPNv4地址族视图或者BGP VPNv6地址族视图下执行display this命令，查看是否存在发布策略过滤了私网路由信息导致无法发布，可能造成影响的配置命令有：

- peer prefix-list export

- peer filter-policy export

- peer as-path-acl export

- filter-policy export

- peer route-policy export

可以通过执行上述命令的undo形式命令来取消对私网路由信息发布的过滤，为了避免组网中的其他配置受到影响，请在技术支持人员的引导下修改私网路由信息发布的过滤策略。

如果故障仍不能排除，请执行步骤（3）。

(3) 查看公网隧道是否建立。

MPLS L3VPN的公网隧道可以是LSP隧道、MPLS TE隧道和GRE隧道。当公网隧道为LSP隧道或MPLS TE隧道时，公网标记为MPLS标签，称为公网标签；当公网隧道为GRE隧道时，公网标记为GRE封装。

常见的公网隧道建立方式是使用LDP标签分发协议自动建立标签转发路径，本故障处理流程以该方式为例，介绍建立公网隧道的故障排查方法。其他方式的公网隧道请参见相应的故障处理手册或寻求技术支持人员的帮助进行排查。

在私网路由发布的骨干网路径上，为所有设备执行display mpls ldp peer命令，查看是否与LDP对等体成功建立了会话，例如：

<Sysname> display mpls ldp peer

VPN instance: public instance

Total number of peers: 2

Peer LDP ID State Role GR AUT KA Sent/Rcvd

22.22.22.22:0 Operational Passive Off None 1816/1816

11.11.11.11:0 Operational Passive Off None 1816/1816

如果已经成功建立了会话，请执行步骤（4）。

如果未建立LDP会话，请参见“MPLS类故障处理手册”中的“LDP会话Down的定位思路”进行排查。

如果公网隧道建立后，故障仍不能排除，请执行步骤（4）。

(4) 检查本端PE的BGP路由表中是否存在对端PE发布的私网路由。

在本端PE上执行display bgp routing-table vpnv4或display bgp routing-table vpnv6命令，查看是否存在远端PE发布的私网路由。

如果不存在，则执行如下操作：

a. 在本端PE和远端PE上，均执行display ip vpn-instance instance-name命令，查看本端PE的VPN实例的Import VPN Targets与远端PE的Export VPN Targets是否一致，显示信息举例如下。

<Sysname> display ip vpn-instance instance-name vpn1

VPN-Instance Name and Index : vpn1, 1

Route Distinguisher : 1:1

Interfaces : GigabitEthernet1/0/1

TTL mode: pipe

Address-family IPv4:

Export VPN Targets :

1:1

Import VPN Targets :

1:1

- 如果不一致，则需要在本端或者远端PE的VPN实例视图下通过vpn-target命令，将RT修改为匹配的值。修改RT后，如果本端PE的BGP路由表中仍未存在对端PE发布的私网路由，请执行步骤b；如果本端PE的BGP路由表中已经存在对端PE发布的私网路由，但故障仍不能排除，请执行步骤（5）。

- 如果一致，请执行步骤b。

b. 通过在BGP实例视图下执行display this命令，查看是否存在接收策略过滤了私网路由信息导致无法接收，可能造成影响的配置命令有：

- peer prefix-list import

- peer filter-policy import

- peer as-path-acl import

- filter-policy import

- peer route-policy import

可以通过执行上述命令的undo形式命令来取消对私网路由信息接收的过滤，为了避免组网中的其他配置受到影响，请在技术支持人员的引导下修改私网路由信息接收的过滤策略。

如果故障仍不能排除，请执行步骤（5）。

(5) 检查BGP路由添加到VPN实例IP路由表的受阻原因。可能的原因有：

¡ 设备配置了undo policy vpn-target命令，与当前VPN实例Route Target属性不匹配的VPNv4/VPNv6路由可以添加到VPN实例的BGP路由表中，并能够在BGP路由表中被优选，但是这些路由无法添加到当前VPN实例的IP路由表中。在BGP实例视图下执行display this命令，查看配置了undo policy vpn-target命令的地址族，进入该地址族视图，并执行policy vpn-target命令，可以解决此问题。

¡ 设备配置了routing-table bgp-rib-only命令，,禁止BGP路由下发到IP路由表中。在BGP实例视图下执行display this命令，查看配置了routing-table bgp-rib-only命令的地址族，进入该地址族视图，并执行undo routing-table bgp-rib-only命令，可以解决此问题。

如果故障仍未能排除，请执行步骤（6）。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

12.3.7 私网间大包不通

1. 故障描述

MPLS L3VPN/IPv6 MPLS L3VPN网络中同时存在我司设备和其他厂商设备，用户访问跨站点的私网资源时，不能打开部分网站，也不能通过FTP下载文件。执行ping命令检验发现，在指定ICMP报文的净荷为1464字节以上时Ping不通，指定ICMP报文的净荷小于1464字节时，可以Ping通。

2. 常见原因

本类故障的常见原因主要为：流量转发路径上设备接口的MTU值过小。

3. 故障分析

本故障的处理流程如图102所示。

图102 私网间大包不通故障诊断流程图

4. 操作步骤

(1) 在流量转发路径上，将设备接口的MTU值修改为大于或等于1508字节。

¡ 在我司设备上，可通过display interface命令查看接口的MTU。例如：

<Sysname> display interface gigabitethernet 1/0/1

GigabitEthernet1/0/1

Current state: Administratively UP

Line protocol state: UP

Description: GigabitEthernet1/0/1 Interface

Bandwidth: 1000000 kbps

Maximum transmission unit: 1500

...

需要修改接口的MTU值时，请在该接口视图下执行ip mtu或ipv6 mtu命令。

¡ 其他厂商的设备配置请参考相关的资料。

如果故障仍未能排除，请执行步骤（2）。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

12.3.8 PE设备Ping不通远端CE网段

1. 故障描述

如图103所示，在IPv6 MPLS L3VPN网络中，PE 1上配置了多个接口关联同一个VPN实例VPN 1。在CE 1和CE 2上执行ping ipv6 2001:db8:3::1命令，均能Ping通远端的CE 3网段，但在PE 1上执行ping ipv6 –vpn-instance vpn1 2001:db8:3::1命令时，Ping不同CE 3网段。

图103 IPv6 MPLS L3VPN 组网图

2. 常见原因

本类故障的常见原因主要为：CE 3上没有到达PE 1所有私网IPv6地址的路由。私网IPv6地址的范围是，PE 1上与CE 3相同的VPN实例中，所有处于UP状态的接口的IPv6地址。

3. 故障分析

本故障的处理流程如图104所示。

图104 PE设备Ping不同远端CE网段故障诊断流程图

4. 操作步骤

(2) 检查CE 3上是否存在到达PE 1所有私网IPv6地址的路由。

PE 1在Ping远端CE网段时，会使用当前设备上指定VPN实例中所有处于UP状态的接口的IPv6地址中，最小的IPv6地址作为ICMPv6报文的源地址，如果CE 3没有该IPv6地址的路由信息，将会导致ICMPv6报文无法返回。

上述问题可以通过以下方法解决：

¡ 在PE 1上配置发布本设备的所有私网路由，例如，在BGP-VPN IPv6单播地址族视图下，配置import-route direct命令。

¡ 执行Ping操作时，指定ICMPv6回显请求报文中的源IPv6地址为CE 3的IPv6路由表中存在的地址，即执行ping ipv6 –a source-ipv6 -vpn-instance vpn-instance-name host命令。

如果故障仍不能排除，请执行步骤（2）。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

12.4 MPLS TE故障处理

12.4.1 MPLS TE隧道状态为Down

1. 故障描述

完成MPLS TE隧道创建后，通过display interface tunnel命令查看到MPLS TE隧道的当前状态为DOWN。

<Sysname> display interface tunnel 1

Tunnel1

Current state: DOWN

Line protocol state: DOWN

Description: Tunnel1 Interface

Bandwidth: 64kbps

Maximum transmission unit: 1496

Internet address: 7.1.1.1/24 (primary)

Tunnel source unknown, destination 4.4.4.9

Tunnel TTL 255

Tunnel protocol/transport CR_LSP

Last clearing of counters: Never

Last 300 seconds input rate: 0 bytes/sec, 0 bits/sec, 0 packets/sec

Last 300 seconds output rate: 6 bytes/sec, 48 bits/sec, 0 packets/sec

Input: 0 packets, 0 bytes, 0 drops

Output: 177 packets, 11428 bytes, 0 drops

2. 常见原因

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

· MPLS TE隧道所在的链路Down。

· MPLS TE配置错误。

· MPLS TE隧道的目的地址被静态路由引用。

3. 故障分析

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

图105 MPLS TE隧道状态为Down的故障诊断流程图

4. 处理步骤

(1) 查看MPLS TE隧道对应的接口是否为Up状态。

执行display interface命令，查看MPLS TE隧道对应的接口否为Up状态。

(2) 检查MPLS TE配置。

依次检查如下配置：

a. OSPF/IS-IS区域和MPLS TE隧道经过的接口下是否配置mpls te enable命令。

b. LSR ID、Router ID是否为同一LoopBack接口的地址。

c. 若使用RSVP-TE协议建立MPLS TE隧道，则需要检查设备和接口是否配置了rsvp、rsvp enable命令。

d. 若隧道接口下配置了mpls te bandwidth命令，检查设备出接口是否配置了mpls te max-link bandwidth以及mpls te max-reservable bandwidth命令。

e. 若隧道接口下配置了mpls te affinity-attribute命令，检查设备出接口是否配置合理的mpls te link-attribute命令。如果希望某条链路能够被隧道所用，则需要满足如下要求：

- 对于隧道亲和属性掩码为1的位，亲和属性为1的位中链路属性至少有1位也为1，亲和属性为0的位对应的链路属性位不能为1。

- 对于隧道亲和属性掩码为0的位，不对链路属性的相应位进行检查。

f. 若使用Segment Routing协议建立MPLS TE隧道，则需要检查设备IGP区域下是否配置了Segment-Routing相关功能。

g. 若使用mpls te path命令指定显式路径来建立MPLS TE隧道，则需要检查显式路径配置是否合理：使用strict方式时，需要逐跳指定入接口的IP地址；使用loose方式时，需要指定经过的设备的节点地址。

(3) 查看MPLS TE隧道的目的地址是否被静态引用。

执行display current-configuration | include destination命令，查看MPLS TE隧道的目的地址是否被静态引用。如果被静态路由引用，则需要根据用户的实际组网需求修改静态路由或者隧道的目的地址。

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

¡ 上述步骤的执行结果。

¡ 设备的配置文件。

¡ 使用display diagnostic-information命令收集诊断信息。

5. 告警与日志

12.4.2 MPLS TE隧道由UP状态变为Down状态

1. 故障描述

MPLS TE隧道由UP状态变为Down状态。

2. 常见原因

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

· MPLS TE隧道所在的链路Down。

· MPLS TE隧道的配置被删除或配置错误。

· RSVP消息超时或错误。

· 物理链路不满足MPLS TE隧道所需的带宽。

· MPLS TE隧道或隧道所在物理接口BFD down。

3. 故障分析

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

图106 MPLS TE隧道由UP状态突然变为Down状态的故障诊断流程图

4. 处理步骤

(1) 查看MPLS TE隧道对应的接口是否为Up状态。

执行display interface命令，查看MPLS TE隧道对应的接口否为Up状态。

(2) 检查MPLS TE配置。

依次检查如下配置：

a. OSPF/IS-IS区域和MPLS TE隧道经过的接口下是否配置mpls te enable命令。

b. LSR ID、Router ID是否为同一LoopBack接口的地址。

c. 若使用RSVP-TE协议建立MPLS TE隧道，则需要检查设备和接口是否配置了rsvp、rsvp enable命令。

d. 若隧道接口下配置了mpls te bandwidth命令，检查设备出接口是否配置了mpls te max-link bandwidth以及mpls te max-reservable bandwidth命令。

- 对于隧道亲和属性掩码为1的位，亲和属性为1的位中链路属性至少有1位也为1，亲和属性为0的位对应的链路属性位不能为1。

- 对于隧道亲和属性掩码为0的位，不对链路属性的相应位进行检查。

f. 若使用Segment Routing协议建立MPLS TE隧道，则需要检查设备IGP区域下是否配置了Segment-Routing相关功能。

(3) 检查是否存在RSVP消息超时或错误。

通过display rsvp statistics命令查看是否存在RSVP消息超时（即发送的Path消息和收到的Resv消息个数不一致、收到的Path消息和发送的Resv消息个数不一致）或RSVP消息错误（即收到PathError消息或ResvError消息）的问题。若存在RSVP消息超时或错误，请抓包查看PathError消息或ResvError报文携带的错误信息，并根据报文携带的错误码，参照RFC 2205和RFC 3209解决问题。

<Sysname> display rsvp statistics

P2P statistics:

Object Added Deleted

PSB 3 1

RSB 3 1

LSP 3 1

P2MP statistics:

Object Added Deleted

PSB 0 0

RSB 0 0

LSP 0 0

Packet Received Sent

Path 5 5

Resv 5 5

PathError 0 0

ResvError 0 0

PathTear 0 0

ResvTear 0 0

ResvConf 0 0

Bundle 0 0

Ack 0 0

Srefresh 0 0

Hello 0 0

Challenge 0 0

Response 0 0

Error 0 0

(4) 检查物理链路是否满足MPLS TE隧道所需的带宽。

当设备上建立了更高优先级的MPLS TE隧道时，该隧道可能会抢占低优先级MPLS TE隧道的带宽，导致低优先级MPLS TE隧道的状态变为down。通过display mpls te link-management bandwidth-allocation命令查看链路上各个优先级的剩余可用带宽，确保链路剩余可用带宽大于该优先级的隧道所需的带宽。如果链路上的剩余可用带宽不能满足MPLS TE隧道的需求，则需要修改配置，调整隧道路径，或为链路提供更大的带宽。

(5) 检查MPLS TE隧道或隧道所在物理接口是否BFD down。

通过display mpls bfd te tunnel tunnel-number命令查看MPLS TE隧道的BFD状态。若MPLS TE隧道的BFD状态为down，则需要通过display bfd session命令查看BFD状态为down的原因，检查并修改BFD配置或检查物理链路是否存在链路故障、链路质量问题。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

12.4.3 MPLS TE隧道存在环路

1. 故障描述

MPLS TE隧道的转发路径上存在环路，导致流量无法通过MPLS TE隧道转发到目的地址。

2. 常见原因

MPLS TE隧道经过的不同设备上存在相同的IP地址。

3. 处理步骤

(1) 请检查MPLS TE隧道经过的不同设备上是否配置了相同的IP地址。若存在相同的IP地址，则需要修改IP地址，保证MPLS TE隧道经过的不同设备上不存在相同的IP地址。

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

¡ 上述步骤的执行结果。

¡ 设备的配置文件。

¡ 使用display diagnostic-information命令收集诊断信息。

4. 告警与日志

12.4.4 Tunnel路径计算失败

1. 故障描述

MPLS TE隧道路径计算失败，导致隧道DOWN。

2. 常见原因

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

· 没有建立IGP邻居。

· 没有MPLS TEDB信息。

· MPLS TE配置错误。

3. 故障分析

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

图107 Tunnel路径计算失败的故障诊断流程图

4. 处理步骤

(1) 查看是否建立了IGP邻居。

执行display ospf peer和display isis peer命令，查看是否建立了IGP邻居。

¡ 若建立了IGP邻居，请继续执行第(2)步。

¡ 若没有建立了IGP邻居，请先完成OSPF或IS-IS配置，建立IGP邻居。OSPF的详细介绍，请参见“三层技术-IP路由”中的“OSPF”；IS-IS的详细介绍，请参见“三层技术-IP路由”中的“IS-IS”。。

(2) 执行display mpls te tedb命令，查看MPLS TEDB信息。

若存在MPLS TEDB信息，请继续执行第(3)步。

若不存在MPLS TEDB信息，请依次检查如下配置：

a. OSPF/IS-IS区域和MPLS TE隧道经过的接口下是否配置mpls enable、mpls te enable命令。

b. LSR ID、Router ID是否为同一LoopBack接口的地址。

(3) 检查MPLS TE配置。

a. 若使用RSVP-TE协议建立MPLS TE隧道，则需要检查设备和接口是否配置了rsvp、rsvp enable命令。

b. 若使用Segment Routing协议建立MPLS TE隧道，则需要检查设备IGP区域下是否配置了segment-routing mpls命令。

c. 若隧道接口下配置了mpls te bandwidth命令，检查设备出接口是否配置了mpls te max-link bandwidth以及mpls te max-reservable bandwidth命令。

d. 若隧道接口下配置了mpls te affinity-attribute命令，检查设备出接口是否配置合理的mpls te link-attribute命令。如果希望某条链路能够被隧道所用，则需要满足如下要求：

- 对于隧道亲和属性掩码为1的位，亲和属性为1的位中链路属性至少有1位也为1，亲和属性为0的位对应的链路属性位不能为1。

- 对于隧道亲和属性掩码为0的位，链路属性可以是任意值。

e. 若使用mpls te path命令指定显式路径来建立MPLS TE隧道，则需要检查显式路径配置是否合理：使用strict方式时，需要逐跳指定入接口的IP地址；使用loose方式时，需要指定经过的设备的节点地址。

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

¡ 上述步骤的执行结果。

¡ 设备的配置文件。

¡ 使用display diagnostic-information命令收集诊断信息。

5. 告警与日志

12.4.5 热备份CRLSP无法建立

1. 故障描述

MPLS TE隧道下配置mpls te backup hot-standby命令，但是无法建立备份CRLSP。

2. 常见原因

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

· 只存在一个与邻居相邻的接口。

· MPLS TE配置错误。

3. 故障分析

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

图108 热备份CRLSP无法建立的故障诊断流程图

4. 处理步骤

(1) 根据配置的IGP协议，执行display ospf peer或display isis peer命令，查看与同一邻居（同一System ID或同一Router ID）相连的接口信息（interface）。

# 显示IS-IS邻居的概要信息。

<Sysname> display isis peer

Peer information for IS-IS(1)

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

System ID: 0000.0000.0001

Interface: GE1/0/1 Circuit Id: 0000.0000.0001.01

State: Up HoldTime: 27s Type: L1(L1L2) PRI: 64

System ID: 0000.0000.0001

Interface: GE1/0/2 Circuit Id: 0000.0000.0001.01

State: Up HoldTime: 27s Type: L2(L1L2) PRI: 64

# 显示OSPF邻居概要信息。

<Sysname> display ospf peer

OSPF Process 1 with Router ID 1.1.1.1

Neighbor Brief Information

Area: 0.0.0.0

Router ID Address Pri Dead-Time State Interface

1.1.1.2 1.1.1.2 1 40 Full/DR GE1/0/1

¡ 若与邻居相连的接口数量≥2，请继续执行第(2)步。

¡ 若与邻居相连的接口数量＜2，请增加与邻居之间的物理链路，确保存在可以建立备份CRLSP的路径。

(2) 检查MPLS TE配置。

依次检查如下配置：

a. OSPF/IS-IS区域和MPLS TE隧道经过的接口下是否配置mpls te enable命令。

b. LSR ID、Router ID是否为同一LoopBack接口的地址。

c. 若使用RSVP-TE协议建立MPLS TE隧道，则需要检查设备和接口是否配置了rsvp、rsvp enable命令。

d. 若隧道接口下配置了mpls te bandwidth命令，检查设备出接口是否配置了mpls te max-link bandwidth以及mpls te max-reservable bandwidth命令。

- 对于隧道亲和属性掩码为1的位，亲和属性为1的位中链路属性至少有1位也为1，亲和属性为0的位对应的链路属性位不能为1。

- 对于隧道亲和属性掩码为0的位，链路属性可以是任意值。

f. 若使用Segment Routing协议建立MPLS TE隧道，则需要检查设备IGP区域下是否配置了segment-routing mpls命令。

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

¡ 上述步骤的执行结果。

¡ 设备的配置文件。

¡ 使用display diagnostic-information命令收集诊断信息。

5. 告警与日志

12.5 MPLS基础故障处理

12.5.1 报文通过LSP隧道转发不通

1. 故障描述

网络中主机的发送报文，通过LSP隧道转发不通。

2. 常见原因

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

· 路由不存在。

· LSP不存在。

· 路由未迭代到LSP隧道上。

· LSP隧道的转发状态非ACTIVE。

· BFD会话状态为Down。

· CPU利用率过高。

3. 故障分析

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

图109 报文通过LSP隧道转发不通的故障诊断流程图

4. 处理步骤

(1) 检查IGP路由是否存在。

执行display ip routing-table命令，查看是否存在到达目的节点的Loopback接口地址的网段路由：

<Sysname> display ip routing-table 1.1.1.1

Summary count : 1

Destination/Mask Proto Pre Cost NextHop Interface

1.1.1.2/32 IS_L1 15 10 1.1.1.1 LoopBack1

¡ 如果不存在，则在Loopback接口和公网接口下使能IGP协议，确保发布对应网段路由。

¡ 如果存在，则执行步骤(2)。

(2) 检查LSP是否存在。

执行display mpls lsp命令，查看是否存在到达目的节点的Loopback接口的LSP：

¡ 如果不存在，则确保建立指定类型的LSP：

- 对于LDP LSP，请在接口下使能MPLS功能和MPLS LDP功能。

- 对于SRLSP，请在IS-IS IPv4单播地址族视图、OSPF视图或BGP IPv4单播地址族视图下执行segment-routing mpls命令用来开启基于MPLS的SR功能。

- 对于SR-MPLS TE Policy，请在SR-TE视图下创建正确的SR-MPLS TE Policy。

¡ 如果存在，则执行步骤(3)。

<Sysname> display mpls lsp

FEC Proto In/Out Label Out Inter/NHLFE/LSINDEX

1.1.1.2/32 LDP -/1049 GE1/0/1

(3) 检查路由是否迭代到LSP隧道上。

执行display mpls tunnel all命令，查看所有隧道的信息。执行display fib命令，查看指定下一跳地址的FIB表项。对于FIB表项中Nexthop字段与隧道信息中Destination字段相同值的FIB表项，检查该FIB表项的LSP索引号（Token字段）与隧道的NHLFE ID是否相同。

¡ 如果不同，则表示未迭代到LSP隧道上，确认指定FEC的隧道类型（Type字段）与配置的隧道策略是否相同：

- 如果不同，则在隧道策略视图下修改隧道策略，使配置的隧道策略与指定FEC的隧道类型匹配。

- 如果相同，则执行步骤(7)。

<Sysname> display tunnel-policy

Tunnel policy name: abc

Select-Seq: LSP

Load balance number : 1

Strict : No

¡ 如果相同，则表示迭代到LSP隧道上，请执行步骤(4)。

<Sysname> display mpls tunnel all

Destination Type Tunnel/NHLFE VPN Instance

2.2.2.9 LSP NHLFE3 -

3.3.3.9 SRLSP NHLFE2 -

4.4.4.9 SRPolicy NHLFE23068673 -

<Sysname> display fib

Destination count: 1 FIB entry count: 1

Flag:

U:Usable G:Gateway H:Host B:Blackhole D:Dynamic S:Static

R:Relay F:FRR

Destination/Mask Nexthop Flag OutInterface/Token Label

55.55.55.55/32 2.2.2.9 UGHR 3 Null

…

(4) 检查LSP隧道的转发状态是否正常。

执行display mpls forwarding nhlfe命令，查看指定NHLFE表项信息。

¡ 如果转发标记中没有A标记，则表示该LSP隧道无法使用，请执行步骤(5)。

¡ 如果转发标记中有A标记，则表示该LSP隧道可以正常使用，请执行步骤(6)。

<Sysname> display mpls forwarding nhlfe 3

Flags: T - Forwarded through a tunnel

N - Forwarded through the outgoing interface to the nexthop IP address

B - Backup forwarding information

A - Active forwarding information

M - P2MP forwarding information

S - Secondary backup path

NID Tnl-Type Flag OutLabel Forwarding Info

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

3 LSP NA 1040127 GE1/0/3 10.0.3.2

(5) 检查BFD状态是否正常。

执行display mpls bfd命令或display mpls sbfd命令，查看LSP隧道的BFD/SBFD检测信息：

¡ 如果BFD/SBFD会话状态显示为Down，则在系统视图下执行mpls bfd enable命令开启MPLS与BFD/SBFD联动功能，确保检测LSP隧道的BFD/SBFD会话Up。

¡ 如果BFD/SBFD会话状态显示为Up，则执行步骤(6)。

<Sysname> display mpls bfd ipv4 22.22.2.2 32

Total number of sessions: 1, 1 up, 0 down, 0 init

FEC Type: LSP

FEC Info:

Destination: 22.22.2.2

Mask Length: 32

NHLFE ID: 1025

Local Discr: 513 Remote Discr: 513

Source IP: 11.11.1.1 Destination IP: 127.0.0.1

Session State: Up Session Role: Passive

Template Name: -

<Sysname> display mpls sbfd ipv4 22.22.2.2 32

Total number of sessions: 1, 1 up, 0 down, 0 init

FEC Type: LSP

FEC Info:

Destination: 22.22.2.2

Mask Length: 32

NHLFE ID: 1025

Local Discr: 513 Remote Discr: 513

Source IP: 11.11.1.1 Destination IP: 127.0.0.1

Session State: Up

Template Name: -

(6) 检查CPU状态是否正常。

执行display cpu-usage命令，查看CPU利用率的统计信息。

¡ 如果CPU利用率过高，则关闭一些不必要的功能，降低设备CPU利用率。

¡ 如果CPU利用率正常，则执行步骤(7)。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

12.6 VPLS故障处理

12.6.1 PW两端的PE设备中只有一个PE上的VSI处于Up状态

1. 故障描述

PW两端的PE设备中只有一个PE上的VSI处于Up状态。

2. 常见原因

VSI up的条件为：

· VSI下至少有一个PW Up和一个AC up。

· VSI下至少有两个AC Up。

因此本类故障的常见原因为：Up的VSI上虽然PW down，但是存在两个Up的AC；Down的VSI上PW down，且无两个Up的AC。

3. 故障分析

本类故障的诊断思路为：检查状态为Down的VSI下的AC和PW的状态。

4. 处理步骤

(1) 执行display l2vpn vsi命令，查看VSI下AC和PW的状态。

<Sysname> display l2vpn vsi verbose

VSI Name: vpls1

VSI Index : 0

VSI Description : vsi for vpls1

VSI State : Down

MTU : 1500

Bandwidth : -

Broadcast Restrain : -

Multicast Restrain : -

Unknown Unicast Restrain: -

MAC Learning : Enabled

MAC Table Limit : -

MAC Learning rate : -

Drop Unknown : -

PW Redundancy : Master

Flooding : Enabled

Statistics : Disabled

VXLAN ID : -

LDP PWs:

Peer PW ID Link ID State

192.3.3.3 1 8 Down

ACs:

AC Link ID State Type

GE1/0/3 srv1 1 Up Manual

(2) 执行display l2vpn pw verbose命令，查看PW状态变为Down的原因。

<Sysname> display l2vpn pw verbose

VSI Name: aaa

Peer: 2.2.2.9 Remote Site: 2

Signaling Protocol : BGP

Link ID : 9 PW State : Down

In Label : 1420 Out Label: 1419

MTU : 1500

PW Attributes : Main

VCCV CC : -

VCCV BFD : -

Flow Label : Send

Control Word : Disabled

Tunnel Group ID : 0x800000960000000

Tunnel NHLFE IDs : 1038

Admin PW : -

E-Tree Mode : -

E-Tree Role : root

Root VLAN : -

Leaf VLAN : -

Down Reasons : Control word not match

常见的故障原因及处理方法如下：

¡ BFD session for PW down：用来检测PW的BFD会话状态为down，此类故障的处理方式为，通过display bfd session命令查看BFD状态为down的原因，检查并修改BFD配置或检查物理链路是否存在链路故障、链路质量问题。

¡ BGP RD was deleted：BGP的RD被删除，此类故障的处理方式为，在交叉连接组自动发现视图下配置route-distinguisher route-distinguisher命令。

¡ BGP RD was empty：未配置BGP的RD，此类故障的处理方式为，在交叉连接组自动发现视图下配置route-distinguisher route-distinguisher命令。

¡ Control word not match：PW两端控制字功能配置不一致，此类故障的处理方式为，将PW两端引用的PW模板下的控制字功能（通过control-word enable命令开启）配置一致。（不支持control-word enable命令的产品请忽略此步骤）

¡ Encapsulation not match：PW两端封装类型不一致，此类故障的处理方式为，将PW两端引用的PW模板下的PW数据封装类型（通过pw-type命令配置）配置一致。（不支持pw-type命令的产品请忽略此步骤）

¡ LDP interface parameter not match：PW两端接口LDP协商参数不一致，此类故障的处理方式为，将PW两端引用的PW模板下的VCCV控制通道类型（通过vccv cc命令配置）配置一致或将PW两端关联的电路仿真接口下引用的电路仿真类中的配置保持一致。

¡ Non-existent remote LDP PW：对端设备已删除LDP PW，此类故障的处理方式为，在对端设备上重新配置PW。

¡ Local AC Down：本地AC状态为down，此类故障的处理方式为，检查并修改AC接口上的配置或排除AC所在的接口的故障，保障接口为Up状态。

¡ Local AC was non-existent：未配置本地AC，此类故障的处理方式为，配置本地的AC并关联VSI。

¡ MTU not match：PW两端MTU不一致，此类故障的处理方式为，将PW两端的MTU配置一致或者通过mtu-negotiate disable命令关闭PW MTU协商功能。（不支持mtu-negotiate disable命令的产品请忽略此步骤）

¡ Remote AC Down：对端AC状态down，此类故障的处理方式为，检查并修改对端AC接口上的配置或排除AC所在的接口的故障，保障接口为Up状态。

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

¡ 上述步骤的执行结果。

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

¡ 使用display diagnostic-information命令收集诊断信息。

5. 告警与日志

12.6.2 VPLS业务不通

1. 故障描述

VPLS业务流量转发不通。

2. 常见原因

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

· AC没有Up

· PW没有Up。

· PW没有生成转发信息。

· PW没有可迭代的公网隧道。

· PW迭代的公网隧道异常。

3. 故障分析

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

(1) 查看VSI详细信息，确认VSI下至少关联了一个AC和一个PW。

(2) 检查AC状态是否Up。

(3) 检查PW状态是否Up。

(4) 检查PW转发信息。

(5) 检查PW迭代的公网隧道信息。

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

图110 VPLS业务不通的故障诊断流程图

4. 处理步骤

(1) 执行display l2vpn vsi命令，查看VSI关联的AC、PW的状态和数量。

<Sysname> display l2vpn vsi verbose

VSI Name: vpls1

VSI Index : 0

VSI Description : vsi for vpls1

VSI State : Up

MTU : 1500

Bandwidth : -

Broadcast Restrain : -

Multicast Restrain : -

Unknown Unicast Restrain: -

MAC Learning : Enabled

MAC Table Limit : -

MAC Learning rate : -

Drop Unknown : -

PW Redundancy : Master

Flooding : Enabled

Statistics : Disabled

VXLAN ID : -

LDP PWs:

Peer PW ID Link ID State

192.3.3.3 1 8 Down

ACs:

AC Link ID State Type

GE1/0/3 srv1 1 Up Manual

(2) 若AC的状态为Down，则检查AC配置是否正确和并检查AC所在的接口是否Up。如果AC配置不正确或AC所在的接口为Down状态，请修改AC配置或排查接口故障。

(3) 若PW的状态为Down，请通过display l2vpn pw verbose命令查看PW状态变为Down的原因。

<Sysname> display l2vpn pw verbose

VSI Name: aaa

Peer: 2.2.2.9 Remote Site: 2

Signaling Protocol : BGP

Link ID : 9 PW State : Down

In Label : 1420 Out Label: 1419

MTU : 1500

PW Attributes : Main

VCCV CC : -

VCCV BFD : -

Flow Label : Send

Control Word : Disabled

Tunnel Group ID : 0x800000960000000

Tunnel NHLFE IDs : 1038

Admin PW : -

E-Tree Mode : -

E-Tree Role : root

Root VLAN : -

Leaf VLAN : -

Down Reasons : Control word not match

常见的故障原因及处理方法如下：

¡ BGP RD was deleted：BGP的RD被删除，此类故障的处理方式为，在交叉连接组自动发现视图下配置route-distinguisher route-distinguisher命令。

¡ BGP RD was empty：未配置BGP的RD，此类故障的处理方式为，在交叉连接组自动发现视图下配置route-distinguisher route-distinguisher命令。

¡ Non-existent remote LDP PW：对端设备已删除LDP PW，此类故障的处理方式为，在对端设备上重新配置PW。

¡ Local AC Down：本地AC状态为down，此类故障的处理方式为，检查并修改AC接口上的配置或排除AC所在的接口的故障，保障接口为Up状态。

¡ Local AC was non-existent：未配置本地AC，此类故障的处理方式为，配置本地的AC并关联VSI。

¡ Remote AC Down：对端AC状态down，此类故障的处理方式为，检查并修改对端AC接口上的配置或排除AC所在的接口的故障，保障接口为Up状态。

(4) 若AC和PW均处于Up状态，请通过display l2vpn forwarding pw verbose命令查看PW是否存在转发信息，即承载PW的隧道对应的NHLFE表项索引列表（Tunnel NHLFE IDs）。

¡ 如果存在转发信息，请执行步骤(6)。

¡ 如果不存在转发信息，请执行步骤(5)。

<Sysname> display l2vpn forwarding pw verbose

VSI Name: aaa

Link ID: 8

PW Type : VLAN PW State : Up

In Label : 1272 Out Label: 1275

MTU : 1500

PW Attributes : Main

VCCV CC : Router-Alert

VCCV BFD : Fault Detection with BFD

Flow Label : Send

Tunnel Group ID : 0x960000000

Tunnel NHLFE IDs: 1034

MAC limit : maximum=2000 alarm=enabled action=discard

(5) 执行display mpls lsp命令，查看是否存在承载PW的隧道，即是否存在FEC为PW对端IP地址的LSP，若不存在，则需要先完成承载PW的隧道的建立。

<Sysname> display mpls lsp

FEC Proto In/Out Label Out Inter/NHLFE/LSINDEX

100.100.100.100/24 LDP -/1049 GE1/0/1

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

¡ 上述步骤的执行结果。

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

¡ 使用display diagnostic-information命令收集诊断信息。

5. 告警与日志

12.6.3 PW处于Up状态时两个PE间报文转发失败

1. 故障描述

PW处于Up状态时两个PE间报文转发失败。

2. 常见原因

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

· MAC地址表达到允许VSI学习到的最大MAC地址数，并且配置当VSI学习到的MAC地址数达到最大值后，禁止转发源MAC地址不在MAC地址表里的报文，即丢弃该报文。

· PW信息没有下发到转发模块。

3. 故障分析

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

图111 PW处于Up状态时两个PE间报文转发失败故障诊断流程图

4. 处理步骤

(1) 执行display l2vpn mac-address命令，查看是否存在相应的MAC地址表项和学习的MAC地址表项总数。可以通过指定具体的AC接口和PW信息，来显示从指定AC和PW上学习的MAC地址表项总数。

¡ 查看所有L2VPN MAC地址表项信息。

<Sysname> display l2vpn mac-address

* - The output interface is issued to another VSI

MAC Address State VSI Name Link ID/Name Aging

0000-0000-000a Dynamic vpn1 GE1/0/1 Aging

0000-0000-0009 Dynamic vpn1 GE1/0/1 Aging

--- 2 mac address(es) found ---

¡ # 显示L2VPN MAC地址表项总数。

<Sysname> display l2vpn mac-address count

2 mac address(es) found

(2) 查看是否配置了允许学习到的最大MAC地址数，及达到最大MAC地址数后的转发。

¡ 在VSI视图下执行display this命令，查看当前VSI下是否配置了mac-table limit命令和mac-table limit drop-unknown命令，如果配置了上述命令且当前已经学习到的MAC地址已经达到最大值，则需要将允许VSI学习到的最大MAC地址数调大或删除mac-table limit drop-unknown命令。（不支持mac-table limit和mac-table limit drop-unknown命令的产品请忽略此步骤）

¡ 在AC和PW视图下执行display this命令，查看当前视图下是否配置了mac-limit命令，如果配置了该述命令且当前已经学习到的MAC地址已经达到最大值，则需要将允许学习到的最大MAC地址数调大或删除action discard参数。（不支持mac-limit命令的产品请忽略此步骤）

(3) 执行display l2vpn forwarding pw verbose命令，查看PW是否存在转发信息，即承载PW的隧道对应的NHLFE表项索引列表（Tunnel NHLFE IDs）。

¡ 如果存在转发信息，请执行步骤(5)。

¡ 如果不存在转发信息，请执行步骤(4)。

<Sysname> display l2vpn forwarding pw verbose

VSI Name: aaa

Link ID: 8

PW Type : VLAN PW State : Up

In Label : 1272 Out Label: 1275

MTU : 1500

PW Attributes : Main

VCCV CC : Router-Alert

VCCV BFD : Fault Detection with BFD

Flow Label : Send

Tunnel Group ID : 0x960000000

Tunnel NHLFE IDs: 1034

MAC limit : maximum=2000 alarm=enabled action=discard

(4) 执行display mpls lsp命令，查看是否存在承载PW的隧道，即是否存在FEC为PW对端IP地址的LSP，若不存在，则需要先完成承载PW的隧道的建立。

<Sysname> display mpls lsp

FEC Proto In/Out Label Out Inter/NHLFE/LSINDEX

100.100.100.100/24 LDP -/1049 GE1/0/1

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

¡ 上述步骤的执行结果。

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

¡ 使用display diagnostic-information命令收集诊断信息。

5. 告警与日志

12.6.4 LDP PW不能Up

1. 故障描述

在VPLS网络中，LDP PW不能Up。

2. 常见原因

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

· PW两端封装类型不一致。

· PW两端MTU值不一致。

· LDP session状态没有Up。

· PW没有可用的公网隧道。

· AC接口没有Up。

3. 故障分析

本类故障的诊断思路为：执行display l2vpn pw verbose命令查看PW状态变为Down的原因，根据具体原因对故障进行排查。

4. 处理步骤

(1) 通过display l2vpn pw verbose命令查看PW对端的IP地址（Peer）和PW状态变为Down的原因（Down Reasons）。

<Sysname> display l2vpn pw verbose

VSI Name: aaa

Peer: 2.2.2.9 VPLS ID: 100:100

Signaling Protocol : LDP

Link ID : 8 PW State : Down

In Label : 1553 Out Label: 1553

MTU : 1500

PW Attributes : Main

VCCV CC : -

VCCV BFD : -

Flow Label : -

Tunnel Group ID : 0x800000960000000

Tunnel NHLFE IDs : 1038

Admin PW : -

E-Tree Mode : -

E-Tree Role : root

Root VLAN : -

Leaf VLAN : -

Down Reasons : Control word not match

(2) 如表16所示，常见的故障原因及处理方法如下。

表16 常见的故障原因及处理方法

Down Reasons	故障描述	故障处理方法
BFD session for PW down	用来检测PW的BFD会话状态为down	通过display bfd session命令查看BFD状态为down的原因，检查并修改BFD配置或检查物理链路是否存在链路故障、链路质量问题
Control word not match	PW两端控制字功能配置不一致	将PW两端引用的PW模板下的控制字功能（通过control-word enable命令开启）配置一致（不支持control-word enable命令的产品请忽略此步骤）
Encapsulation not match	PW两端封装类型不一致	将PW两端引用的PW模板下的PW数据封装类型（通过pw-type命令配置）配置一致（不支持pw-type命令的产品请忽略此步骤）
LDP interface parameter not match	PW两端接口LDP协商参数不一致	将PW两端引用的PW模板下的VCCV控制通道类型（通过vccv cc命令配置）配置一致或将PW两端关联的电路仿真接口下引用的电路仿真类配置一致
Non-existent remote LDP PW	对端设备已删除LDP PW	在对端设备上重新配置PW
Local AC Down	本地AC状态为down	检查并修改AC接口上的配置或排除AC所在的接口的故障，保证口为Up状态
Local AC was non-existent	未配置本地AC	配置本地的AC并关联VSI
MTU not match	PW两端MTU不一致	将PW两端的MTU配置一致或者通过mtu-negotiate disable命令关闭PW MTU协商功能（不支持mtu-negotiate disable命令的产品请忽略此步骤）
Remote AC Down	对端AC状态down	检查并修改对端AC接口上的配置或排除AC所在的接口的故障，保证接口为Up状态
Label not allocated	标签未分配	请联系技术支持人员处理
Local VSI Down	本地VSI状态为down	请参见VPLS故障处理中的“PW两端的PE设备中只有一个PE上的VSI处于Up状态”
Local and remote LDP PWs have different AII	本端携带的SAII与对端携带的TAII不同	请参见LDP故障处理中的“LDP会话无法Up”
Local LDP PW was not sent mapping message	本端未发送LDP mapping消息	请参见LDP故障处理中的“LDP会话无法Up”
Local LDP PW Virtual Nexthop defect	本地LDP PW存在虚拟下一跳缺陷	请参见步骤(3)(4)
Remote LDP PW Virtual Nexthop defect	远端LDP PW存在虚拟下一跳缺陷	请参见步骤(3)(4)
Tunnel Down	承载PW的隧道down	此类故障处理方法请参见步骤(4)

(3) 请通过display l2vpn forwarding pw verbose命令查看PW是否存在转发信息，即承载PW的隧道对应的NHLFE表项索引列表（Tunnel NHLFE IDs）。

¡ 如果存在转发信息，请执行步骤(5)。

¡ 如果不存在转发信息，请执行步骤(4)。

<Sysname> display l2vpn forwarding pw verbose

VSI Name: aaa

Link ID: 8

PW Type : VLAN PW State : Up

In Label : 1272 Out Label: 1275

MTU : 1500

PW Attributes : Main

VCCV CC : Router-Alert

VCCV BFD : Fault Detection with BFD

Flow Label : Send

Tunnel Group ID : 0x960000000

Tunnel NHLFE IDs: 1034

MAC limit : maximum=2000 alarm=enabled action=discard

(4) 执行display mpls lsp命令，查看是否存在承载PW的隧道，即是否存在FEC为步骤(1)中Peer地址的LSP，若不存在，则需要先完成承载PW的隧道的建立。目前支持的公网隧道类型有LSP、MPLS TE、GRE隧道等，LSP类型的公网隧道创建，请参见“MPLS”中的“静态LSP”和“LDP”；MPLS TE类型的公网隧道创建，请参见“MPLS TE”；GRE类型的公网隧道创建，请参见“三层技术-IP业务”中的“GRE”。

<Sysname> display mpls lsp

FEC Proto In/Out Label Out Inter/NHLFE/LSINDEX

100.100.100.100/24 LDP -/1049 GE1/0/1

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

¡ 上述步骤的执行结果。

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

¡ 使用display diagnostic-information命令收集诊断信息。

5. 告警与日志

12.6.5 VPLS使用LDP信令协议，VSI不能Up

1. 故障描述

VPLS使用LDP信令协议，VSI不能Up。

2. 常见原因

满足如下任一条件，VSI即为Up状态：

· VSI下至少有一个PW Up和一个AC Up。

· VSI下至少有两个AC Up。

· VSI下至少有两个PW Up（多段PW组网）。

因此本类故障的常见原因为：

· VSI下Up的AC和PW的总数小于2。

· VSI下执行了shutdown命令。

3. 故障分析

本类故障的诊断思路为：

(1) 检查VSI下是否执行了shutdown命令

(2) 查看VSI下的AC、PW的状态和数量。

4. 处理步骤

(1) 在VSI视图下执行display this命令，查看当前视图是否配置了shutdown命令。

¡ 如果配置shutdown命令，请执行undo shutdown命令。

¡ 如果未配置shutdown命令，请执行步骤(2)。

(2) 执行display l2vpn vsi命令，查看VSI关联的AC、PW的状态和数量。

<Sysname> display l2vpn vsi verbose

VSI Name: vpls1

VSI Index : 0

VSI Description : vsi for vpls1

VSI State : Up

MTU : 1500

Bandwidth : -

Broadcast Restrain : -

Multicast Restrain : -

Unknown Unicast Restrain: -

MAC Learning : Enabled

MAC Table Limit : -

MAC Learning rate : -

Drop Unknown : -

PW Redundancy : Master

Flooding : Enabled

Statistics : Disabled

VXLAN ID : -

LDP PWs:

Peer PW ID Link ID State

192.3.3.3 1 8 Down

ACs:

AC Link ID State Type

GE1/0/3 srv1 1 Up Manual

¡ 若VSI下关联的AC和PW的数量小于2，请先创建AC和PW。

¡ 若AC的状态为Down，则检查AC配置是否正确，并检查AC所在的接口是否Up。如果AC配置不正确或AC所在的接口为Down状态，请修改AC配置或排查接口故障。

¡ 若PW的状态为Down，请参见12.6.4 LDP PW不能Up对故障进行处理。

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

¡ 上述步骤的执行结果。

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

¡ 使用display diagnostic-information命令收集诊断信息。

5. 告警与日志

13 Segment Routing故障处理

13.1 EVPN L3VPN over SRv6故障处理

13.1.1 EVPN L3VPN over SRv6 BE流量转发不通

1. 故障描述

在EVPN L3VPN over SRv6组网中，采用SRv6 BE方式转发流量时，流量转发不通。

2. 常见原因

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

· BGP EVPN邻居未成功建立。

· EVPN L3VPN over SRv6配置缺失。

· SRv6 SID路由不可达。

3. 故障分析

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

图112 EVPN L3VPN over SRv6 BE流量转发不通的故障诊断流程图

4. 处理步骤

(1) 在本端PE设备上执行display bgp peer l2vpn evpn命令查看BGP EVPN邻居是否成功建立：

¡ 若显示信息中的State字段取值为Established，则表示PE之间成功建立BGP EVPN邻居，请继续执行步骤(2)。

¡ 否则，请解决BGP EVPN邻居无法成功建立问题，解决方法请参见“BGP邻居无法建立的定位思路”。

<Sysname> display bgp peer l2vpn evpn

BGP local router ID: 1.1.1.1

Local AS number: 100

Total number of peers: 1 Peers in established state: 1

* - Dynamically created peer

Peer AS MsgRcvd MsgSent OutQ PrefRcv Up/Down State

2::2 100 13 10 0 2 00:00:05 Established

(2) 检查两端PE设备上EVPN L3VPN over SRv6的配置是否完整。若不完整，请补充缺失的配置；若完整，请继续执行步骤(3)。

在两端PE上执行display current-configuration命令，检查是否存在以下配置。若不存在，则需要参见《EVPN L3VPN over SRv6配置指导》手册，补充相关配置。

isis 1

cost-style wide-compatible

address-family ipv6 unicast

segment-routing ipv6 locator aaa // 配置通过IS-IS通告Locator网段路由

bgp 100

peer 3::3 as-number 100

address-family l2vpn evpn

peer 3::3 enable

peer 3::3 advertise encap-type srv6 // 配置向对等体/对等体组发布SRv6封装的EVPN路由

ip vpn-instance vpn1

address-family ipv4 unicast

segment-routing ipv6 best-effort evpn // 配置路由迭代到SRv6 BE隧道

segment-routing ipv6 locator aaa evpn // 配置BGP引用Locator段，以便在引用的Locator段内为指定VPN实例的私网路由申请SRv6 SID

segment-routing ipv6

encapsulation source-address 11::11 // 配置SRv6 VPN封装的IPv6报文头的源地址

locator aaa ipv6-prefix 1:1:: 96 static 8 // 创建Locator段

(3) 在两端PE设备上分别检查是否存在到达对端的SRv6 SID的路由。

a. 执行display bgp l2vpn evpn命令，查看PrefixSID字段。该字段中的IPv6地址为对端PE分配的SRv6 SID。

<Sysname> display bgp l2vpn evpn [5][0][64][4::]/176

BGP local router ID: 1.1.1.1

Local AS number: 100

Route distinguisher: 1:1

Total number of routes: 1

Paths: 1 available, 1 best

BGP routing table information of [5][0][64][4::]/176:

From : 2::2 (2.2.2.2)

Rely nexthop : FE80::8A1B:6FFF:FEDB:708

Original nexthop: 2::2

Out interface : GigabitEthernet2/0/3

Route age : 00h06m33s

OutLabel : 3

Ext-Community : <RT: 1:1>

RxPathID : 0x0

TxPathID : 0x0

PrefixSID : End.DT6 SID <9::8000:2>

AS-path : 65420

Origin : incomplete

Attribute value : MED 0, localpref 100, pref-val 0

State : valid, internal, best

Source type : local

IP precedence : N/A

QoS local ID : N/A

Traffic index : N/A

EVPN route type : IP prefix advertisement route

ESI : 0000.0000.0000.0000.0000

Ethernet tag ID : 0

IP prefix : 4::/64

Gateway address : ::

MPLS label : 3

Tunnel policy : NULL

Rely tunnel IDs : N/A

Re-orignination : Disable

b. 执行display ipv6 routing-table ipv6-address命令，查看是否存在到达SRv6 SID的路由。

<Sysname> display ipv6 routing-table 9::8000:2

Summary count : 1

Destination: 9::/64 Protocol : IS_L1

NextHop : FE80::8A1B:6FFF:FEDB:708 Preference: 15

Interface : GE1/0/3 Cost : 20

若存在到达对端SRv6 SID的路由，则继续执行步骤(4)；否则，请解决无法通过IGP学习到路由的问题，解决方法请参见“IP路由类故障处理手册”。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

13.1.2 EVPN L3VPN over SRv6 TE流量转发不通

1. 故障描述

在EVPN L3VPN over SRv6组网中，采用SRv6 TE方式通过SRv6 TE Policy转发流量时，流量转发不通。

2. 常见原因

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

· BGP EVPN邻居未成功建立。

· SRv6 SID路由不可达。

· BGP-VPN IPv4单播地址族视图或BGP-VPN IPv6单播地址族视图下，未配置采用SRv6 TE方式进行路由迭代。

· EVPN路由迭代到的SRv6 TE Policy没有生效。

3. 故障分析

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

图113 EVPN L3VPN over SRv6 TE流量转发不通的诊断流程图

4. 处理步骤

(1) 在本端PE设备上执行display bgp peer l2vpn evpn命令查看BGP EVPN邻居是否成功建立：

¡ 若显示信息中的State字段取值为Established，则表示PE之间成功建立BGP EVPN邻居，请继续执行步骤(2)。

¡ 否则，请解决BGP EVPN邻居无法成功建立问题，解决方法请参见“BGP邻居无法建立的定位思路”。

<Sysname> display bgp peer l2vpn evpn

BGP local router ID: 1.1.1.1

Local AS number: 100

Total number of peers: 1 Peers in established state: 1

* - Dynamically created peer

Peer AS MsgRcvd MsgSent OutQ PrefRcv Up/Down State

2::2 100 13 10 0 2 00:00:05 Established

(2) 在两端PE设备上分别检查是否存在到达对端的SRv6 SID的路由。

a. 执行display bgp l2vpn evpn命令，查看PrefixSID字段。该字段中的IPv6地址为对端PE分配的SRv6 SID。

<Sysname> display bgp l2vpn evpn [5][0][64][4::]/176

BGP local router ID: 1.1.1.1

Local AS number: 100

Route distinguisher: 1:1

Total number of routes: 1

Paths: 1 available, 1 best

BGP routing table information of [5][0][64][4::]/176:

From : 2::2 (2.2.2.2)

Rely nexthop : FE80::8A1B:6FFF:FEDB:708

Original nexthop: 2::2

Out interface : GigabitEthernet2/0/3

Route age : 00h06m33s

OutLabel : 3

Ext-Community : <RT: 1:1>

RxPathID : 0x0

TxPathID : 0x0

PrefixSID : End.DT6 SID <9::8000:2>

AS-path : 65420

Origin : incomplete

Attribute value : MED 0, localpref 100, pref-val 0

State : valid, internal, best

Source type : local

IP precedence : N/A

QoS local ID : N/A

Traffic index : N/A

EVPN route type : IP prefix advertisement route

ESI : 0000.0000.0000.0000.0000

Ethernet tag ID : 0

IP prefix : 4::/64

Gateway address : ::

MPLS label : 3

Tunnel policy : NULL

Rely tunnel IDs : 2150629378

Re-orignination : Disable

b. 执行display ipv6 routing-table ipv6-address命令，查看是否存在到达SRv6 SID的路由。

<Sysname> display ipv6 routing-table 9::8000:2

Summary count : 1

Destination: 9::/64 Protocol : IS_L1

NextHop : FE80::8A1B:6FFF:FEDB:708 Preference: 15

Interface : GE1/0/3 Cost : 20

c. 若存在到达对端SRv6 SID的路由，则继续执行步骤(3)；否则，请解决无法通过IGP学习到路由的问题，解决方法请参见“IP路由类故障处理手册”。

(3) 在BGP-VPN IPv4单播地址族视图或BGP-VPN IPv6单播地址族视图下，执行display this命令，查看当前配置中是否存在segment-routing ipv6 traffic-engineering evpn或者segment-routing ipv6 traffic-engineering best-effort evpn命令。若不存在上述命令，请补充配置该命令；否则，请继续执行步骤(4)。

<Sysname> system-view

[Sysname] bgp 100

[Sysname-bgp-default] ip vpn-instance vpn1

[Sysname-bgp-default-vpn1] address-family ipv4 unicast

[Sysname-bgp-default-ipv4-vpn1] display this

segment-routing ipv6 locator aaa evpn

segment-routing ipv6 traffic-engineering evpn

(4) 在两端PE设备上判断EVPN路由迭代到的SRv6 TE Policy是否有效。

a. 在两端PE设备上执行display bgp l2vpn evpn命令，查看到达对端私网地址的EVPN路由的Rely tunnel IDs字段取值。该值为EVPN路由迭代到的SRv6 TE Policy的隧道索引值。

<Sysname> display bgp l2vpn evpn [5][0][64][4::]/176

BGP local router ID: 1.1.1.1

Local AS number: 100

Route distinguisher: 1:1

Total number of routes: 1

Paths: 1 available, 1 best

BGP routing table information of [5][0][64][4::]/176:

From : 2::2 (2.2.2.2)

Rely nexthop : FE80::8A1B:6FFF:FEDB:708

Original nexthop: 2::2

Out interface : GigabitEthernet2/0/3

Route age : 00h06m33s

OutLabel : 3

Ext-Community : <RT: 1:1>

RxPathID : 0x0

TxPathID : 0x0

PrefixSID : End.DT6 SID <9::8000:2>

AS-path : 65420

Origin : incomplete

Attribute value : MED 0, localpref 100, pref-val 0

State : valid, internal, best

Source type : local

IP precedence : N/A

QoS local ID : N/A

Traffic index : N/A

EVPN route type : IP prefix advertisement route

ESI : 0000.0000.0000.0000.0000

Ethernet tag ID : 0

IP prefix : 4::/64

Gateway address : ::

MPLS label : 3

Tunnel policy : NULL

Rely tunnel IDs : 2150629378

Re-orignination : Disable

b. 在两端PE设备上执行display segment-routing ipv6 te policy命令，检查Forwarding index字段取值与Rely tunnel IDs字段取值相同的SRv6 TE Policy是否有效，即查看Status是否为Down。若为Down，则表示SRv6 TE Policy未生效，请参考“SRv6 TE Policy无法生效的定位思路”解决该问题。

<Sysname> display segment-routing ipv6 te policy

Name/ID: p1/0

Color: 10

Endpoint: 1000::1

Name from BGP:

BSID:

Mode: Dynamic Type: Type 2 Request state: Succeeded

Current BSID: 8000::1 Explicit BSID: - Dynamic BSID: 8000::1

Reference counts: 3

Flags: A/BS/NC

Status: Up

AdminStatus: Up

Up time: 2020-03-09 16:09:40

Down time: 2020-03-09 16:09:13

Hot backup: Enabled

Statistics: Enabled

Statistics by service class: Enabled

Path verification: Enabled

Drop-upon-invalid: Enabled

BFD trigger path-down: Enabled

SBFD: Enabled

Remote: 1000

SBFD template name: abc

SBFD backup template name: -

OAM SID: -

BFD Echo: Disabled

Forwarding index: 2150629378

Association ID: 1

Service-class: -

Rate-limit: 15000 kbps

PCE delegation: Disabled

PCE delegate report-only: Disabled

Encapsulation mode: -

Candidate paths state: Configured

Candidate paths statistics:

CLI paths: 1 BGP paths: 0 PCEP paths: 0 ODN paths: 0

Candidate paths:

Preference : 20

CpathName:

ProtoOrigin: CLI Discriminator: 10

Instance ID: 0 Node address: 0.0.0.0

Originator: 0, ::

Optimal: Y Flags: V/A

Dynamic: Not configured

PCEP: Not configured

Explicit SID list:

ID: 1 Name: Sl1

Weight: 1 Forwarding index: 2149580801

State: Up State(Echo BFD): Down

Verification State: -

Path MTU: 1500 Path MTU Reserved: 0

Local BSID: -

Reverse BSID: -

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

13.2 SR-MPLS故障处理

13.2.1 SR-MPLS-BE方式的SRLSP无法建立

1. 故障描述

采用SR-BE方式建立SRLSP时，依次在SRLSP经过的各个节点上使用display mpls lsp命令检查SRLSP的标签交换信息，发现某个节点没有去往SRLSP的Egress节点的出标签（Out Label）或者该出标签并非SR-MPLS分配。例如，Egress节点FEC为5.5.5.5/32，如下显示表示该节点上不存在去往5.5.5.5/32的SR-MPLS出标签，即不存在去往5.5.5.5/32的SRLSP。

<Sysname> display mpls lsp

FEC Proto In/Out Label Out Inter/NHLFE/LSINDEX

12.1.1.2 Local -/- GE0/0/1

Tunnel1 Local -/- NHLFE2

Tunnel10 Local -/- NHLFE1

1.1.1.1/32 ISIS 16010/- -

2.2.2.2/32 ISIS 16020/3 GE0/0/1

2.2.2.2/32 ISIS -/3 GE0/0/1

3.3.3.3/32 ISIS 16030/16030 GE0/0/1

3.3.3.3/32 ISIS -/16030 GE0/0/1

4.4.4.4/32 ISIS 16040/16040 GE0/0/1

4.4.4.4/32 ISIS -/16040 GE0/0/1

1.1.1.1/1/4122 SR-TE -/16030 GE0/0/1

16040

2. 常见原因

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

· 物理链路故障。

· IGP或BGP邻居关系未正常建立导致SR-MPLS标签发布失败。

· SR-MPLS配置缺少或错误。

采用SR-BE方式建立SRLSP完全依赖于IGP或BGP路由的发布，在IGP或BGP邻居之间通告路由信息时，需要携带SR-MPLS标签信息以建立SRLSP。因此，IGP或BGP邻居关系是否正常建立、IGP路由是否正常发布是本类故障最重要的原因。

3. 故障分析

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

图114 采用SR-BE方式无法建立SRLSP的故障诊断流程图

4. 处理步骤

(1) 在SRLSP经过的各个节点上通过命令display interface brief检查物理链路状态，确保SRLSP转发路径上各接口的物理状态和数据链路层协议状态均为UP。如果链路正常，或链路恢复后问题仍未解决，请继续执行以下操作。

(2) 在SRLSP经过的各个节点上检查IGP/BGP邻居关系是否正常建立，IGP/BGP配置是否正确。SR-MPLS采用不同的路由协议发布标签时，故障处理方法有所不同：

¡ 如果使用OSPF作为IGP来通告路由信息并发布SR-MPLS标签：

- 通过display ospf命令来判断OSPF是否使能Opaque LSA发布接收能力。如果display ospf命令显示信息中存在Opaque capable字段，表示Opaque LSA发布接收能力处于开启状态。若未使能该功能，则需要在OSPF视图下执行opaque-capability enable命令。

- 执行display ospf peer命令确认OSPF邻接关系是否正常。如果显示信息中邻居状态字段State显示为Full，表示OSPF邻居关系正常。否则，请参见OSPF故障处理手册中“OSPF邻居无法达到FULL状态”的处理过程。

- 执行display mpls lsp命令检查是否存在OSPF协议发布的SR Prefix方式的LSP信息。各节点的SR Prefix SID是管理员为Loopback地址手工指定的SID。如果没有SR Prefix方式的LSP信息，请在各节点的Loopback接口视图下检查是否使用ospf area命令使能OSPF或在OSPF视图下是否使用network命令引入Loopback接口网段地址。

<Sysname> display mpls lsp

FEC Proto In/Out Label Out Inter/NHLFE/LSINDEX

1.1.1.9/32 OSPF 16010/- -

1.1.1.9/32 ISIS 16010/- -

2.2.2.9/32 OSPF 16020/17020 RAGG1.4

- 如果display mpls lsp命令的显示信息中不仅存在OSPF协议发布的SRLSP信息，同时也存在BGP协议发布的相同Prefix的SRLSP信息，则可能因Prefix SID冲突导致SRLSP生成失败。此时请通过peer route-policy命令过滤掉从BGP对等体学习的该路由信息。

¡ 如果使用IS-IS作为IGP来通告路由信息并发布SR-MPLS标签：

- 通过display isis命令的显示信息中Cost style字段来判断IS-IS开销值的类型是否为wide、compatible或wide-compatible。如果Cost style字段的开销值类型不是以上三种，请执行cost-style命令来修改IS-IS开销值的类型。

- 执行display isis peer命令确认IS-IS邻居关系是否正常。如果display isis peer命令邻居状态字段State显示为Up，表示IS-IS邻居关系正常。否则，请参见IS-IS故障处理手册中“IS-IS邻居无法建立”的处理过程。

- 执行display mpls lsp命令检查是否存在IS-IS协议发布的SR Prefix方式的LSP信息。各节点的SR Prefix SID是管理员为Loopback地址手工指定的SID。如果没有SR Prefix方式的LSP信息，请在各节点的Loopback接口视图下检查是否使用isis enable命令使能IS-IS功能。

<Sysname> display mpls lsp

FEC Proto In/Out Label Out Inter/NHLFE/LSINDEX

1.1.1.9/32 OSPF 16010/- -

1.1.1.9/32 ISIS 16010/- -

2.2.2.9/32 ISIS 16020/17020 RAGG1.4

- 如果display mpls lsp命令的显示信息中不仅存在IS-IS协议发布的SRLSP信息，同时也存在BGP协议发布的相同Prefix的SRLSP信息，则可能因Prefix SID冲突导致SRLSP生成失败。此时请通过peer route-policy命令过滤掉从BGP对等体学习的该路由信息。

¡ 如果使用BGP来通告路由信息并发布SR-MPLS标签：

- 执行display bgp peer命令检查BGP对等体或对等体组的邻居关系是否正常。如果display bgp peer命令BGP会话的状态字段State显示为Established，表示BGP对等体或对等体组邻居关系正常。否则，请参见BGP故障处理手册中“BGP 邻居无法建立”的处理过程。

- 执行display mpls lsp命令检查是否存在BGP协议发布的SR Prefix方式的LSP信息。如果没有，请检查BGP的指定对等体/对等体组配置了peer label-route-capability命令来使能交换带标签路由的能力，并且通过路由策略为引入BGP的Loopback地址配置了标签索引值。

<Sysname> display mpls lsp

FEC Proto In/Out Label Out Inter/NHLFE/LSINDEX

1.1.1.9/32 OSPF 16010/- -

1.1.1.9/32 ISIS 16010/- -

2.2.2.9/32 BGP 16020/17020 RAGG1.4

如果执行以上操作后，问题仍未解决，则请继续执行以下操作。

(3) 在SRLSP经过的各个节点上检查SR-MPLS配置。

a. 在IS-IS视图、OSPF视图或BGP视图下检查是否开启支持SR-MPLS功能。如果未开启支持SR-MPLS功能，则在IS-IS视图、OSPF视图或BGP视图下执行segment-routing mpls命令开启该功能。

b. SR-BE LSP使用前缀SID方式建立SRLSP转发路径，请在LoopBack接口视图下检查是否配置前缀SID。如果未配置，则在OSPF视图下执行ospf prefix-sid命令或在IS-IS视图下执行isis prefix-sid命令配置前缀SID。

c. 执行display segment-routing label-block命令检查LoopBack接口下配置的前缀SID是否在SRGB标签段范围内。如果前缀SID未在SRGB范围内，则请修改配置的前缀SID，否则该SID不会生效。

d. 如果执行以上操作后，问题仍未解决，则请继续执行以下操作。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

13.2.2 SR-MPLS-TE Tunnel状态为Down

1. 故障描述

在Ingress上执行display mpls te tunnel-interface命令检查SR-MPLS-TE Tunnel的状态为Down。

<Sysname> display mpls te tunnel-interface

Tunnel Name : Tunnel 1

Tunnel Signalled Name : tunnel1

Tunnel State : Down (Main CRLSP Down. Backup CRLSP Down.)

...

2. 常见原因

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

· 构成SR-MPLS-TE Tunnel的SRLSP所经过的路径上存在物理链路故障。

· 用于检测SR-MPLS-TE Tunnel的BFD会话状态为down，使得SR-MPLS-TE Tunnel状态为Down。

· SR-MPLS配置缺少或错误。

· SR TE Tunnel配置错误。

3. 故障分析

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

图115 SR-MPLS TE Tunnel Down的故障诊断流程图

4. 处理步骤

(2) 检查是否由BFD会话Down导致SR TE Tunnel Down。

a. 在SR-MPLS-TE隧道接口下使用display this命令检查是否配置了mpls bfd、mpls sbfd、mpls tunnel-bfd或mpls tunnel-sbfd命令中的任一条。如果配置了，则执行b。

b. 使用display mpls bfd或display mpls sbfd命令检查BFD/SBFD会话的状态。如果BFD/SBFD会话的状态为Down，则执行c。

c. 可能是由于BFD联动导致SR-TE隧道Down，请执行undo mpls bfd、undo mpls sbfd、undo mpls tunnel-bfd或undo mpls tunnel-sbfd命令删除BFD/SBFD检测相关命令。如果BFD/SBFD会话正常或者不存在BFD/SBFD会话，问题仍未解决请执行(3)。

(3) 检查SR-MPLS配置（不支持通过IGP协议动态分配SID的产品请忽略此步骤）。

a. 在IS-IS视图或OSPF视图下检查是否开启支持SR-MPLS功能，同时需要检查以下配置，否则SR-MPLS功能不会生效：

- 当IGP协议为IS-IS时，通过display isis命令的显示信息中Cost style字段来判断IS-IS开销值的类型是否为wide、compatible或wide-compatible。如果Cost style字段的开销值类型不是以上三种，请执行cost-style命令来修改IS-IS开销值的类型。

- 当IGP协议为OSPF时，通过display ospf命令来判断OSPF是否使能Opaque LSA发布接收能力。如果display ospf命令显示信息中存在Opaque capable字段，表示Opaque LSA发布接收能力处于开启状态。若未使能该功能，则需要在OSPF视图下执行opaque-capability enable命令。

b. 若使用前缀SID方式建立SRLSP转发路径，请在LoopBack接口视图下检查是否配置了前缀SID。如果未配置，则在OSPF视图下执行ospf prefix-sid命令或在IS-IS视图下执行isis prefix-sid命令配置前缀SID；若使用Adjacency SID方式建立SRLSP转发路径，请在OSPF视图或IS-IS视图下开启邻接标签分配功能或者在SRLSP转发路径的接口上检查是否配置了Adjacency SID。如果未配置，则在OSPF视图或IS-IS视图下执行segment-routing adjacency enable命令开启邻接标签分配功能。也可以在接口视图下执行isis adjacency-sid命令或ospf adjacency-sid命令配置Adjacency SID。

c. 执行display segment-routing label-block命令检查LoopBack接口下配置的前缀SID是否在SRGB标签段范围内，并检查接口下配置的Adjacency SID是否在SRLB标签段范围内。如果前缀SID未在SRGB范围内或者Adjacency SID未在SRLB标签段范围内，则请修改配置的Adjacency SID，否则该SID不会生效。

d. 如果执行以上操作后，问题仍未解决，则请继续执行以下操作。

(4) 检查TE隧道配置。MPLS TE采用不同方式生成SRLSP时，故障定位方式有所不同：

¡ MPLS TE隧道采用静态指定标签生成SRLSP：在SRLSP的Ingress上执行display mpls static-sr-mpls命令查看静态SRLSP信息或静态配置的邻接段信息，保证出标签栈字段Out-Label表示的标签序列依次和SRLSP路径上各节点配置的静态标签值一一对应。如果Ingress上出标签栈中的标签序列与SRLSP路径上各节点配置的静态标签值不对应，请执行static-sr-mpls lsp命令修改Ingress上出标签栈中的标签序列。

¡ 若MPLS TE隧道采用显式路径算路生成SRLSP（不支持显式路径SRLSP的产品请忽略此步骤）：在SRLSP的Ingress上执行display explicit-path命令检查显式路径上节点的IP地址或者SID与SRLSP路径上各节点的IP地址或者本地SID一一对应，并保证Ingress上显式路径视图下通过nexthop命令指定的SID类型与SRLSP路径上各节点的接口视图下配置的前缀SID或Adjacency SID类型保持一致，即接口下配置了前缀SID，nexthop命令指定的SID也必须是前缀SID。如果存在问题，请通过nexthop命令修改显式路径上的IP地址或者SID。

¡ 若MPLS TE隧道采用PCE托管方式由控制器算路生成SRLSP（不支持PCE计算建立SRLSP的产品请忽略此步骤）：请检查SR-TE Tunnel接口下是否执行了mpls te delegation命令开启了SRLSP托管功能，并执行命令display mpls te pce peer检查PCC与PCE是否建立了PCEP会话。通过抓包确认控制器（PCE）是否进行了路径更新以及路径是否正确。在抓取报文中请确保由PCE下发的Adjacency SID或下一跳地址使用strict方式，前缀SID或者节点地址使用loose方式。如果PCC与PCE未正常建立了PCEP会话，且抓取报文未满足上述要求，请检查控制器上的配置。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

13.3 SRv6 TE Policy故障处理

13.3.1 SRv6 TE Policy无法生效的定位思路

1. 故障描述

执行ping srv6-te policy命令检查指定SRv6 TE Policy的连通性时，发现报文无法通过SRv6 TE Policy正常转发。例如：

<Sysname> ping srv6-te policy policy-name p1

The SRv6-TE policy does not reference a SID list or the referenced SID list is down.

2. 常见原因

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

· SRv6 TE Policy状态为Shutdown。

· SRv6 TE Policy的BSID配置错误或者冲突。

· SRv6 TE Policy下配置缺失。

· SRv6 TE Policy的资源超限。

· Segment List中SID数量超限。

· SRv6 TE Policy的SID列表与报文转发路径的规划不同。

· SRv6 TE Policy报文转发路径上的物理链路故障。

3. 故障诊断流程

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

图116 SRv6 TE Policy无法生效的故障诊断流程图

4. 故障处理步骤

(1) 在SRv6 TE Policy的头节点执行display segment-routing ipv6 te policy status命令初步查看SRv6 TE Policy不生效的原因。

<Sysname> display segment-routing ipv6 te policy status

Name/ID: p1/0

Status: Down

Check admin status : Failed

Check for endpoint & color : Passed

Check for segment list : Passed

Check valid candidate paths : Failed

Check for BSIDs : -

如果Check admin status字段显示为Failed，说明SRv6 TE Policy处于管理关闭状态。请进入指定SRv6 TE Policy视图下执行undo shutdown命令，设置SRv6 TE Policy为开启状态。

开启指定SRv6 TE Policy后，再次执行display segment-routing ipv6 te policy status命令，如果存在其他校验字段显示为Failed或“-”，例如Check for segment List字段显示为Failed，请继续执行以下操作。

(2) 检查SRv6 TE Policy的BSID是否存在冲突。

在SRv6 TE Policy的头节点执行display segment-routing ipv6 te policy命令。显示信息中Request state字段取值为Failed表示BSID申请失败。静态指定的BSID可能不在Locator段范围内或者与已存在的SRv6 TE Policy的BSID出现重复，从而导致SRv6 TE Policy失效。建议在失效的SRv6 TE Policy下执行undo binding-sid命令删除静态手工指定BSID，由系统自动申请BSID，以避免错误和冲突。

<Sysname> display segment-routing ipv6 te policy

Name/ID: p1/0

Color: 10

Endpoint: 1000::1

Name from BGP:

BSID:

Mode: Dynamic Type: Type 2 Request state: Succeeded

Current BSID: 8000::1 Explicit BSID: - Dynamic BSID: 8000::1

Reference counts: 3

Flags: A/BS/NC

如果BSID申请成功以后，问题仍未解决，则请继续执行以下操作。

(3) 检查SRv6 TE Policy的配置是否完整。

以IS-IS作为IGP通告SID为例，在SRv6 TE Policy的头节点上执行命令display current-configuration，查看配置是否与以下实例中的一致。如果缺少任意一项，则说明遗漏了部分配置。

isis 1

address-family ipv6 unicast

segment-routing ipv6 locator a

segment-routing ipv6

locator a ipv6-prefix 1000:0:0:1:: 64 static 16

traffic-engineering

srv6-policy locator a

segment-list sl1

index 10 ipv6 1000::2:0:0:1:0

index 20 ipv6 1000::2:0:0:1:3

policy p1

color 100 end-point ipv6 4::4

candidate-paths

preference 100

explicit segment-list sl1

SRv6 TE Policy报文转发路径的各节点上，也需要在IGP视图下配置segment-routing ipv6 locator命令，以正常发布Locator段。例如：

isis 1

address-family ipv6 unicast

segment-routing ipv6 locator b

如果配置不完整，请补充缺失配置。配置补充完整后，如果问题仍未解决，请继续执行以下操作。

(4) 检查当前SRv6 TE Policy数量和Segment List数量是否超限。

在SRv6 TE Policy头节点执行display segment-routing ipv6 te policy statistics命令，查看SRv6 TE Policy的使用数量是否达到上限。

<Sysname> display segment-routing ipv6 te policy statistics

IPv6 TE Policy Database Statistics

…

SRv6-TE policy resource information:

Max resources: 1024

Used resources: 1

Upper threshold: 512 (50%)

Lower threshold: 102 (10%)

SID list resource information:

Max resources: 4096

Used resources: 1

Upper threshold: 3277 (80%)

Lower threshold: 1638 (40%)

…

¡ 如果SRv6-TE policy resource information下的Used resources字段的值等于Max resources字段的值，则表示SRv6 TE Policy数量可能超限，此时请删除不需要的SRv6 TE Policy。

¡ 如果SID list resource information下的Used resources字段的值等于Max resources字段的值，则表示Segment List数量可能超限，请删除不需要的Segment List。

¡ 如果SRv6 TE Policy数量和Segment List数量均没有超限，请继续执行以下操作。

(5) 检查Segment List中SID数量是否超限。

在SRv6 TE Policy头节点上进入probe视图，并执行display system internal segment-routing ipv6 te policy status命令，显示信息中MaxSIDs表示Segment List中SID的数量上限。

[Sysname-probe] display system internal segment-routing ipv6 te policy status

…

MaxGroupNidNum: 1024 MaxPolicyNidNum: 1024

MaxSeglistNidNum: 4096 MaxNexthopNidNum: 65535

MaxOutNum: 32 MaxEcmpNum: 16

MaxSIDs: 10

…

执行display segment-routing ipv6 te segment-list命令，显示信息中的Nodes字段表示该指定Segment List中配置的SID节点数量。

<Sysname> display segment-routing ipv6 te segment-list

Total Segment lists: 1

Name/ID: A/1

Origin: CLI

Status: Up

Verification State: Down

Nodes: 11

…

如果配置的SID节点数量超过SID的数量上限，请删除Segment List中不必要的SID值。如果配置的SID节点数量未超过上限，请继续执行以下操作。

(6) 检查SID列表的配置与规划是否一致。

在SRv6 TE Policy头节点执行display segment-routing ipv6 te segment-list命令，显示SID列表信息，其中自上而下依次排列的SID值表示转发路径上距离SRv6 TE Policy头节点由近到远的各节点或链路。如果Status字段为Down，表示未正常学习到该SID所属的Locator段。请参考OSPFv3故障处理手册或IS-IS故障处理手册处理。

[Sysname] display segment-routing ipv6 te segment-list

Total Segment lists: 1

Name/ID: s1/1

Origin: CLI

Status: Down

Verification State: Down

Nodes : 3

Index : 10 SID: 1::1

Status : UP TopoStatus: Nonexistent

Type : Type_2 Flags: None

Coc Type : - Common prefix length: 0

Index : 20 SID: 1::2

Status : Down TopoStatus: Nonexistent

Type : Type_2 Flags: None

Coc Type : - Common prefix length: 0

Index : 30 SID: 1::3

Status : Down TopoStatus: Nonexistent

Type : Type_2 Flags: None

Coc Type : - Common prefix length: 0

在SRv6 TE Policy转发路径上的各个节点上依次执行display segment-routing ipv6 local-sid命令查看SID值是否与上述命令显示的SID列表中的SID值一致。SID类型通常为End SID或End.X SID。例如，对于End SID，查看SRv6 Local SID的信息。

[Sysname] display segment-routing ipv6 local-sid end

Local SID forwarding table (End)

Total SIDs: 2

SID : 1000::2:0:0:1:0/64

Function type : End Flavor : PSP

Locator name : b Allocation type: Dynamic

Owner : IS-IS-1 State : Active

Create Time : Sep 04 16:32:03.443 2021

如果SID列表与转发路径上各节点的SID值不一致，请执行undo index index-number命令删除错误的SID，再执行index index-number ipv6 ipv6-address命令重新配置正确的SID。如果SID列表与规划一致，请继续执行以下操作。

(7) 在SRv6 TE Policy转发路径上的各个节点上通过display interface brief命令检查物理链路状态，确保转发路径上各接口的物理状态和数据链路层协议状态均为UP。如果链路正常，或链路恢复后问题仍未解决，请继续执行以下操作。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

14 VXLAN类故障处理

14.1 VXLAN故障处理

14.1.1 Ping不通集中式VXLAN IP网关

仅支持集中式VXLAN IP网关特性的产品支持本故障处理流程。

1. 故障描述

如图117所示，VTEP与集中式VXLAN IP网关之间建立VXLAN隧道，集中式VXLAN IP网关上VSI虚接口作为网关接口。配置完成后，在VTEP连接的服务器上执行Ping操作，发现Ping不通集中式VXLAN IP网关。

图117 集中式VXLAN IP网关示意图

2. 常见原因

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

· VXLAN隧道状态为Down。

· VXLAN隧道的源IP或目的IP配置错误。

· VXLAN IP网关接口状态为Down。

· 设备上不存在ping命令对应的ARP表项。

3. 故障分析

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

图118 Ping不通集中式VXLAN IP网关的故障诊断流程图

4. 处理步骤

(1) 在连接服务器的VTEP上查看服务器所属的VXLAN网络的VXLAN隧道信息。

a. 执行display l2vpn vsi verbose命令查看服务器所属的VXLAN网络的VXLAN ID以及与VXLAN网络关联的VXLAN隧道的名称（Tunnel Name字段）。

<Sysname> display l2vpn vsi verbose

VSI Name: vpna

VSI Index : 0

VSI State : Up

MTU : 1500

Bandwidth : Unlimited

Broadcast Restrain : Unlimited

Multicast Restrain : Unlimited

Unknown Unicast Restrain: Unlimited

MAC Learning : Enabled

MAC Table Limit : -

MAC Learning rate : -

Drop Unknown : -

Flooding : Enabled

Statistics : Disabled

VXLAN ID : 10

Tunnels:

Tunnel Name Link ID State Type Flood proxy

Tunnel1 0x5000001 Up Manual Disabled

Tunnel2 0x5000002 Up Manual Disabled

ACs:

AC Link ID State Type

GE1/0/1 srv1000 0 Up Manual

b. 根据VXLAN隧道的名称执行display interface tunnel命令，查看服务器接入的VXLAN网络内VXLAN隧道的状态（Current state）、隧道的源IP地址（Tunnel source）和隧道的目的IP地址（destination）。

<Sysname> display interface tunnel 2

Tunnel2

Current state: UP

Line protocol state: UP

Description: Tunnel2 Interface

Bandwidth: 64 kbps

Maximum transmission unit: 1464

Internet protocol processing: Disabled

Last clearing of counters: Never

Tunnel source 2.2.2.2, destination 1.1.1.1

Tunnel protocol/transport UDP_VXLAN/IP

Last 300 seconds input rate: 0 bytes/sec, 0 bits/sec, 0 packets/sec

Last 300 seconds output rate: 0 bytes/sec, 0 bits/sec, 0 packets/sec

Input: 0 packets, 0 bytes, 0 drops

Output: 0 packets, 0 bytes, 0 drops

- 若VXLAN隧道为Up状态，请继续执行第(3)步。

- 若VXLAN隧道为Down状态，请继续执行第(2)步。

(2) 在VTEP上查看VXLAN隧道的源IP地址是否为本端的IP地址、目的IP地址是否可达。

¡ 执行display ip interface brief命令，查看VXLAN隧道的源IP地址是否为本端的IP地址。若VXLAN隧道的源IP地址不是本端的IP地址，请通过source命令修改VXLAN隧道的源IP地址。

<Sysname> display ip interface brief

*down: administratively down

(s): spoofing (l): loopback

Interface Physical Protocol IP address VPN instance Description

Loop1 up up(s) 2.2.2.2 -- --

MGE0/0/0 up up 192.168.1.61 -- --

MGE0/0/1 down down -- -- --

MTunnel0 down down -- aaa --

Vlan1 *down down -- -- --

¡ 执行display fib命令，查看FIB表中是否存在到达VXLAN隧道的目的IP地址的表项。若不存在对应的表项，请修改路由配置，确保VXLAN隧道的目的IP地址路由可达。

<Sysname> display fib

Destination count: 4 FIB entry count: 4

Flag:

U:Useable G:Gateway H:Host B:Blackhole D:Dynamic S:Static

R:Relay F:FRR

Destination/Mask Nexthop Flag OutInterface/Token Label

0.0.0.0/32 127.0.0.1 UH InLoop0 Null

2.2.2.2/32 127.0.0.1 UH InLoop0 Null

1.1.1.1/32 127.0.0.1 UH InLoop0 Null

127.0.0.0/32 127.0.0.1 UH InLoop0 Null

(3) 在VXLAN IP网关上执行display interface vsi-interface brief命令，查看VXLAN IP网关接口信息，包括网关接口编号（Interface）、网关接口状态（Link Protocol）和网关IP地址（Primary IP）。

<Sysname> display interface Vsi-interface brief

Brief information on interfaces in route mode:

Link: ADM - administratively down; Stby - standby

Protocol: (s) - spoofing

Interface Link Protocol Primary IP Description

Vsi1 DOWN DOWN 192.168.1.1

¡ 若VXLAN IP网关接口为Down状态，请查看VSI虚接口下是否配置了shutdown命令或绑定VSI虚接口的VSI是否为Up状态。

- 若VSI虚接口下配置了shutdown命令，请执行undo shutdown命令。

- 若绑定VSI虚接口的VSI为Down状态，请执行display l2vpn vsi命令，查看VSI下AC的状态。若AC的状态为Down，则检查AC配置是否正确和AC所在的接口是否Up。如果AC配置不正确或AC所在的接口为Down状态，请修改AC配置或排查接口故障。

¡ 若VXLAN IP网关接口为Up状态，请执行display arp命令查看是否学习到了网关IP对应的ARP信息。

<Sysname> display arp

Type: S-Static D-Dynamic O-Openflow R-Rule M-Multiport I-Invalid

IP address MAC address VLAN/VSI Interface/Link ID Aging Type

10.1.1.1 0001-0001-0001 0 Tunnel2 17 D

10.1.1.11 0001-0001-0001 0 Tunnel2 20 D

20.1.1.1 0002-0002-0002 1 Tunnel3 17 D

20.1.1.12 0002-0002-0002 1 Tunnel3 20 D

- 若存在网关IP对应的ARP信息，请继续执行第(4)步。。

- 若不存在网关IP对应的ARP信息，请执行display arp count命令查看学习的表项数目是否达到了设备/接口配置的动态ARP表项的最大数目。如果达到动态ARP表项的最大数目，请执行arp max-learning-num或arp max-learning-number命令将允许学习的动态ARP表项的最大数目调大。

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

¡ 上述步骤的执行结果。

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

¡ 使用display diagnostic-information命令收集诊断信息。

5. 告警与日志

15 EVPN类故障处理

15.1 EVPN VXLAN故障处理

15.1.1 EVPN分布式网关场景，同一VXLAN内的VTEP之间隧道无法建立

1. 故障描述

EVPN分布式网关场景，同一VXLAN内的VTEP之间隧道无法建立。

2. 常见原因

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

· 未收到EVPN的2类路由（MAC/IP发布路由）、3类路由（IMET路由）。

· EVPN实例下的RT配置错误。

3. 故障分析

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

(1) 检查是否收到2类路由。

(2) 检查是否收到3类路由。

(3) 检查EVPN实例下的RT是否配置错误。

同一VXLAN内VTEP之间的VXLAN隧道无法建立的故障诊断流程如图119所示。

图119 同一VXLAN内VTEP之间的VXLAN隧道无法建立的故障诊断流程图

4. 处理步骤

同一VXLAN内VTEP之间的VXLAN隧道无法建立时，故障处理步骤如下：

(1) 在本端执行display bgp l2vpn evpn命令查看本端是否向对端发布了2类或3类路由。例如，下面的显示信息表示本端向4.4.4.4通告了2类和3类路由。如果组网中存在RR，则display bgp l2vpn evpn命令需要指定RR的地址；否则，需要指定对端的地址。

<Sysname> display bgp l2vpn evpn peer 4.4.4.4 advertised-routes

Total number of routes: 2

BGP local router ID is 1.1.1.1

Status codes: * - valid, > - best, d - dampened, h - history,

s - suppressed, S - stale, i - internal, e - external,

a - additional-path

Origin: i - IGP, e - EGP, ? - incomplete

Route distinguisher: 2:2

Total number of routes: 2

Network NextHop MED LocPrf Path/Ogn

* > [2][0][48][0e86-19b6-0308][0][0.0.0.0]/104

0.0.0.0 0 100 i

* > [3][0][32][1.1.1.1]/80

0.0.0.0 0 100 i

¡ 如果本端向对端发布了2类或3类路由，则执行第(2)步。

¡ 如果本端未向对端发布2类和3类路由，请检查EVPN功能中BGP的相关配置是否正确，具体配置参见“EVPN配置指导”中的“EVPN VXLAN”。

(2) 在对端执行display bgp l2vpn evpn命令查看对端是否向本端发布了2类或3类路由。例如，下面的显示信息表示对端向4.4.4.4通告了2类和3类路由。如果组网中存在RR，则display bgp l2vpn evpn命令需要指定RR的地址；否则，需要指定对端的地址。

<Sysname> display bgp l2vpn evpn peer 4.4.4.4 advertised-routes

Total number of routes: 2

BGP local router ID is 3.3.3.3

Status codes: * - valid, > - best, d - dampened, h - history,

s - suppressed, S - stale, i - internal, e - external,

a - additional-path

Origin: i - IGP, e - EGP, ? - incomplete

Route distinguisher: 1:1

Total number of routes: 2

Network NextHop MED LocPrf Path/Ogn

* > [2][0][48][0e86-23cf-0507][0][0.0.0.0]/104

0.0.0.0 0 100 i

* > [3][0][32][3.3.3.3]/80

0.0.0.0 0 100 i

¡ 如果对端向本端发布了2类或3类路由，则执行第(3)步。

¡ 如果对端未向本端发布2类和3类路由，请检查EVPN功能中BGP的相关配置是否正确，具体配置参见“EVPN配置指导”中的“EVPN VXLAN”。

(3) 在VSI视图下执行display this命令查看两端的Export target属性与Import target属性配置是否正确。

[Sysname-vsi-aaa] display this

vsi aaa

vxlan 10

evpn encapsulation vxlan

route-distinguisher 2:2

vpn-target 1:1 export-extcommunity

vpn-target 2:2 import-extcommunity

return

¡ 如果两端的RT属性不匹配，请在VSI视图下执行vpn-target命令修改Route Target属性配置。

¡ 如果两端的RT属性匹配，则执行第(4)步。

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

¡ 上述步骤的执行结果。

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

¡ 使用display diagnostic-information命令收集诊断信息。

5. 告警与日志

15.1.2 EVPN分布式网关场景，不同VXLAN内的VTEP之间隧道无法建立

1. 故障描述

EVPN分布式网关场景，不同VXLAN内的VTEP之间隧道无法建立。

2. 常见原因

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

· 未收到EVPN的2类路由、5类路由（IP前缀路由）。

· VPN实例下的RT配置错误。

3. 故障分析

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

(1) 检查是否收到2类路由。

(2) 检查是否收到5类路由

(3) 检查VPN实例下的RT是否配置错误。

不同VXLAN内VTEP之间的VXLAN隧道无法建立的故障诊断流程如图120所示。

图120 不同VXLAN内VTEP之间的VXLAN隧道无法建立的故障诊断流程图

4. 处理步骤

不同VXLAN内VTEP之间的VXLAN隧道无法建立时，故障处理步骤如下：

(1) 在本端执行display bgp l2vpn evpn命令查看本端是否向对端发布了2类或5类路由。例如，下面的显示信息表示本端向4.4.4.4通告了2类和5类路由。如果组网中存在RR，则display bgp l2vpn evpn命令需要指定RR的地址；否则，需要指定对端的地址。

<Sysname> display bgp l2vpn evpn peer 4.4.4.4 advertised-routes

Total number of routes: 3

BGP local router ID is 1.1.1.1

Status codes: * - valid, > - best, d - dampened, h - history,

s - suppressed, S - stale, i - internal, e - external,

a - additional-path

Origin: i - IGP, e - EGP, ? - incomplete

Route distinguisher: 1:1

Total number of routes: 1

Network NextHop MED LocPrf Path/Ogn

* > [5][0][24][10.1.1.0]/80

0.0.0.0 0 100 i

Route distinguisher: 2:2

Total number of routes: 2

Network NextHop MED LocPrf Path/Ogn

* > [2][0][48][0e86-19b6-0308][0][0.0.0.0]/104

0.0.0.0 0 100 i

* > [3][0][32][1.1.1.1]/80

0.0.0.0 0 100 i

¡ 如果本端向对端发布了2类或5类路由，则执行第(2)步。

¡ 如果本端未向对端发布2类和5类路由，请检查EVPN功能中BGP的相关配置是否正确，具体配置参见“EVPN配置指导”中的“EVPN VXLAN”。

(2) 在对端执行display bgp l2vpn evpn命令查看对端是否向本端发布了2类或5类路由。例如，下面的显示信息表示对端向4.4.4.4通告了2类和5类路由。如果组网中存在RR，则display bgp l2vpn evpn命令需要指定RR的地址；否则，需要指定对端的地址。

<Sysname> display bgp l2vpn evpn peer 4.4.4.4 advertised-routes

Total number of routes: 3

BGP local router ID is 3.3.3.3

Status codes: * - valid, > - best, d - dampened, h - history,

s - suppressed, S - stale, i - internal, e - external,

a - additional-path

Origin: i - IGP, e - EGP, ? - incomplete

Route distinguisher: 1:1

Total number of routes: 2

Network NextHop MED LocPrf Path/Ogn

* > [2][0][48][0e86-23cf-0507][0][0.0.0.0]/104

0.0.0.0 0 100 i

* > [3][0][32][3.3.3.3]/80

0.0.0.0 0 100 i

Route distinguisher: 3:3

Total number of routes: 2

Network NextHop MED LocPrf Path/Ogn

* > [5][0][24][10.1.1.0]/80

0.0.0.0 0 100 i

¡ 如果对端向本端发布了2类或5类路由，则执行第(3)步。

¡ 如果对端未向本端发布2类和5类路由，请检查EVPN功能中BGP的相关配置是否正确，具体配置参见“EVPN配置指导”中的“EVPN VXLAN”。

(3) 在关联L3VNI的VPN实例视图下执行display this命令查看两端的Export target属性与Import target属性配置是否正确。

[Sysname-vpn-instance-vpna] display this

ip vpn-instance vpna

route-distinguisher 1:1

address-family evpn

vpn-target 1:1 import-extcommunity

vpn-target 1:1 export-extcommunity

return

¡ 如果两端的RT属性不匹配，请执行vpn-target命令修改Route Target属性配置。

¡ 如果两端的RT属性匹配，则执行第(4)步。

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

¡ 上述步骤的执行结果。

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

¡ 使用display diagnostic-information命令收集诊断信息。

5. 告警与日志

15.1.3 VXLAN网络中，二层VXLAN业务流量不通

1. 故障描述

VXLAN网络中，二层VXLAN业务流量不通。

2. 常见原因

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

· AC或VXLAN隧道未建立。

· 未学习到MAC地址。

3. 故障分析

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

图121 二层VXLAN业务流量不通的故障诊断流程图

4. 处理步骤

二层VXLAN业务流量不通时，故障处理步骤如下：

(1) 通过display l2vpn vsi verbose命令查看VSI关联的VXLAN隧道和AC信息。

<Sysname> display l2vpn vsi verbose

VSI Name: vpna

VSI Index : 0

VSI State : Up

MTU : 1500

Bandwidth : Unlimited

Broadcast Restrain : Unlimited

Multicast Restrain : Unlimited

Unknown Unicast Restrain: Unlimited

MAC Learning : Enabled

MAC Table Limit : -

MAC Learning rate : -

Drop Unknown : -

Flooding : Enabled

Statistics : Disabled

VXLAN ID : 10

Tunnels:

Tunnel Name Link ID State Type Flood proxy

Tunnel1 0x5000001 Up Manual Disabled

ACs:

AC Link ID State Type

GE1/0/1 srv1000 0 Up Manual

¡ 若AC和VXLAN隧道均为Up状态，则执行第(2)步。

¡ 若AC为Down状态，请检查并修改AC配置。

¡ 若VXLAN隧道为Down状态，请根据“15.1.1 EVPN分布式网关场景，同一VXLAN内的VTEP之间隧道无法建立”故障处理步骤解决问题。

(2) 通过display l2vpn mac-address命令查看VSI的MAC地址表中是否存在被访问终端的MAC地址表项和学习的MAC地址表项总数。

<Sysname> display l2vpn mac-address

* - The output interface is issued to another VSI

MAC Address State VSI Name Link ID/Name Aging

0001-0001-0001 Static aaa Tunnel1 NotAging

52f6-bc1e-0d06 Dynamic vpna GE1/0/1 Aging

--- 3 mac address(es) found ---

¡ 若存在指定的MAC地址表项，则执行第(3)步。

¡ 若不存在指定的MAC地址表项，请在VSI视图下执行display this命令，查看当前VSI下是否配置了mac-table limit命令和mac-table limit drop-unknown命令，如果配置了上述命令且当前已经学习到的MAC地址已经达到最大值，则需要将允许VSI学习到的最大MAC地址数调大或删除mac-table limit drop-unknown命令。

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

¡ 上述步骤的执行结果。

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

¡ 使用display diagnostic-information命令收集诊断信息。

5. 告警与日志

15.1.4 VXLAN网络中，三层VXLAN业务流量不通

1. 故障描述

VXLAN网络中，三层VXLAN业务流量不通。

2. 常见原因

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

· AC或VXLAN隧道未建立。

· 设备的Route MAC配置错误。

3. 故障分析

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

图122 三层VXLAN业务流量不通的故障诊断流程图

4. 处理步骤

三层VXLAN业务流量不通时，故障处理步骤如下：

(1) 通过display l2vpn vsi verbose命令查看VSI关联的VXLAN隧道和AC信息。

<Sysname> display l2vpn vsi verbose

VSI Name: vpna

VSI Index : 0

VSI State : Up

MTU : 1500

Bandwidth : Unlimited

Broadcast Restrain : Unlimited

Multicast Restrain : Unlimited

Unknown Unicast Restrain: Unlimited

MAC Learning : Enabled

MAC Table Limit : -

MAC Learning rate : -

Drop Unknown : -

Flooding : Enabled

Statistics : Disabled

VXLAN ID : 10

Tunnels:

Tunnel Name Link ID State Type Flood proxy

Tunnel1 0x5000001 Up Manual Disabled

ACs:

AC Link ID State Type

GE1/0/1 srv1000 0 Up Manual

¡ 若AC和VXLAN隧道均为Up状态，则执行第(2)步。

¡ 若AC为Down状态，请检查并修改AC配置。

¡ 若VXLAN隧道为Down状态，请根据“15.1.2 EVPN分布式网关场景，不同VXLAN内的VTEP之间隧道无法建立”故障处理步骤解决问题。

(2) 通过display evpn routing-table命令查看L3VNI关联的VPN实例的路由表中目的IP地址（IP address）为被访问终端的IP地址的路由表项的下一跳地址（Nexthop）。

<Sysname> display evpn routing-table vpn-instance vpn1

Flags: E - with valid ESI A – A-D ready L - Local ES exists

VPN instance name: vpn1 Local L3VNI: 7

IP address Nexthop Outgoing interface NibID Flags

10.1.1.11 1.1.1.1 Vsi-interface3 0x18000000 EAL

(3) 通过display arp命令查看下一跳地址的ARP信息。

<Sysname> display arp

Type: S-Static D-Dynamic O-Openflow R-Rule M-Multiport I-Invalid

IP address MAC address VLAN/VSI name Interface Aging Type

1.1.1.1 00e0-fe50-6503 vsi1 Tunnel1 960 D

¡ 若下一跳地址对应的MAC地址为Router MAC，则执行第(4)步。通过display interface vsi-interface命令查看承载L3VNI的VSI虚接口的MAC地址，该地址就是Router MAC地址。

¡ 若下一跳地址对应的MAC地址不是Router MAC，则将设备上承载L3VNI的VSI虚接口的MAC地址配置一致或通过evpn global-mac命令配置EVPN的全局MAC地址。

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

¡ 上述步骤的执行结果。

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

¡ 使用display diagnostic-information命令收集诊断信息。

5. 告警与日志

15.1.5 EVPN网络中，VM迁移时间过长

1. 故障描述

EVPN网络中，VM迁移到新的VTEP后，VTEP没有立刻学习到VM的MAC地址或者ARP。

2. 常见原因

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

· 新的VTEP未学习到迁移VM的MAC地址表项和ARP表项。

· 新的VTEP未通过BGP EVPN路由同步学习到迁移VM的MAC地址和ARP。

· VTEP之间同步的BGP EVPN路由不是最优路由。

3. 故障分析

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

图123 VM迁移时间过长的故障诊断流程图

4. 处理步骤

(1) 在迁移后的VTEP设备上查看是否学习到迁移VM的MAC地址或ARP。

通过display l2vpn mac-address命令查看VSI的MAC地址表中是否存在迁移VM的MAC地址表项。

<Sysname> display l2vpn mac-address

* - The output interface is issued to another VSI

MAC Address State VSI Name Link ID/Name Aging

52f6-bc1e-0d06 EVPN aaa Tunnel10 NotAging

0001-0001-0001 Dynamic vpna GE1/0/1 Aging

--- 2 mac address(es) found ---

通过display arp命令查看VSI的ARP表项中是否包含VM的ARP表项。

<Sysname> display arp

Type: S-Static D-Dynamic O-Openflow R-Rule M-Multiport I-Invalid

IP address MAC address VLAN/VSI name Interface Aging Type

10.1.1.3 0001-0001-0001 vpna GE1/0/1 960 D

1.1.1.4 00e0-fe60-5000 vsi2 Tunnel1 -- M

¡ 若存在迁移VM的MAC地址或ARP表项，则执行第(2)步。

¡ 若不存在迁移VM的MAC地址和ARP表项，则表示本端未学习到迁移VM的MAC地址和ARP，需要VM在迁移后的VTEP上上线完成VM的MAC地址和ARP表项学习。

(2) 在迁移前的VTEP设备上查看是否通过BGP EVPN路由同步学习到迁移VM的MAC地址或ARP。

通过display evpn route mac命令查看是否通过BGP EVPN路由同步学习到迁移VM的MAC地址。Flags中的B表示存在通过BGP EVPN路由学习的MAC表项。

<Sysname> display evpn route mac

Flags: D - Dynamic B - BGP L - Local active

G - Gateway S - Static M - Mapping I - Invalid

VSI name: bbb

EVPN instance: -

MAC address Link ID/Name Flags Encap Next hop

0000-0000-000a 1 DL VXLAN -

0001-0001-0001 Tunnel1 B VXLAN 2.2.2.2

通过display evpn route arp命令查看是否通过BGP EVPN路由同步学习到迁移VM的ARP信息。Flags中的B表示存在通过BGP EVPN路由学习的ARP表项。

<Sysname> display evpn route arp

Flags: D - Dynamic B - BGP L - Local active

G - Gateway S - Static M - Mapping I - Invalid

VPN instance: vpn1 Interface: Vsi-interface1

IP address MAC address Router MAC VSI index Flags

10.1.1.1 0001-0001-0001 a0ce-7e40-0400 0 B

10.1.1.11 0001-0001-0002 a0ce-7e40-0400 0 DL

10.1.1.101 0001-0011-0101 a0ce-7e40-0400 0 SL

10.1.1.102 0001-0011-0102 0011-9999-0000 0 BS

¡ 若通过BGP EVPN路由同步学习到迁移VM的MAC地址或ARP，则执行第(3)步。

¡ 若未通过BGP EVPN路由同步学习到迁移VM的MAC地址和ARP，请通过vpn-target命令修改本端EVPN实例下的RT配置，保证本端和对端EVPN实例下的RT属性匹配。

(3) 通过display bgp l2vpn evpn命令查看VM的MAC地址和ARP信息的MAC/IP发布路由是否为最优路由，即检查显示信息的State字段取值是否包括best。如下举例中，路由通告的MAC地址为0001-0203-0405（MAC address），IP地址为5.5.5.5/32（IP address），且该路由为best路由（State）。

<Sysname> display bgp l2vpn evpn route-distinguisher 1.1.1.1:100 [2][5][48][0001-0203-0405][32][5.5.5.5] 136

BGP local router ID: 172.16.250.133

Local AS number: 100

Route distinguisher: 1.1.1.1:100

Total number of routes: 1

Paths: 1 available, 1 best

BGP routing table information of [2][5][48][0001-0203-0405][32][5.5.5.5]/136:

From : 10.1.1.2 (192.168.56.17)

Rely nexthop : 10.1.1.2

Original nexthop: 10.1.1.2

OutLabel : NULL

Ext-Community : <RT: 1:2>, <RT: 1:3>, <RT: 1:4>, <RT: 1:5>, <RT: 1:6>, <RT: 1:7

>, <Encapsulation Type: VXLAN>, <Router's Mac: 0006-0708-0910

>, <MAC Mobility: Flag 0, SeqNum 2>, <Default GateWay>

RxPathID : 0x0

TxPathID : 0x0

AS-path : 200

Origin : igp

Attribute value : MED 0, pref-val 0

State : valid, external, best

IP precedence : N/A

QoS local ID : N/A

Traffic index : N/A

EVPN route type : MAC/IP advertisement route

ESI : 0001.0203.0405.0607.0809

Ethernet tag ID : 5

MAC address : 0001-0001-0001

IP address : 10.1.1.1/32

MPLS label1 : 10

MPLS label2 : 100

Re-origination : Enable

¡ 若MAC/IP发布路由是最优路由，则执行第(4)步。

¡ 若MAC/IP发布路由不是最优路由，请修改路由配置，确保通告的MAC/IP发布路由为最优路由。

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

¡ 上述步骤的执行结果。

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

¡ 使用display diagnostic-information命令收集诊断信息。

5. 告警与日志

15.1.6 VTEP设备上存在MAC迁移，导致其他终端访问VM业务异常

1. 故障描述

VTEP设备上存在MAC迁移，导致其他终端访问VM业务异常。

2. 常见原因

本类故障的常见原因主要为：流量异常或者网络攻击导致学习到的VM的MAC地址表项出接口错误。

3. 故障分析

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

(1) 查看MAC地址迁移信息。

(2) 查看VM的MAC表项出接口是否正确。

4. 处理步骤

(1) 通过display evpn route mac-mobility命令查看MAC地址迁移信息。如下信息表示MAC地址1000-0000-0000从接口GE1/0/1迁移到本地。

<Sysname> display evpn route mac-mobility

Flags: S - Suppressed, N - Not suppressed

Suppression threshold: 5

Detection cycle : 180s

Suppression time : Permanent

VSI name : vsia

EVPN instance : -

MAC address Move count Moved from Flags Suppressed at

1000-0000-0000 10 GE1/0/1 S 15:30:30 2018/03/30

(2) 通过display l2vpn mac-address命令查看VM的MAC地址表项的出接口是否正确。Link ID/Name为学习到MAC地址的接口名称或隧道接口名称。

<Sysname> display l2vpn mac-address

* - The output interface is issued to another VSI

MAC Address State VSI Name Link ID/Name Aging

1000-0000-0000 EVPN aaa Tunnel10 NotAging

52f6-bc1e-0d06 Dynamic vpna GE1/0/1 Aging

--- 2 mac address(es) found ---

¡ 若出接口正确，则执行第(3)步。

¡ 若出接口不正确，则需要VM在迁移后的VTEP上重新上线，触发表项学习和更新。

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

¡ 上述步骤的执行结果。

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

¡ 使用display diagnostic-information命令收集诊断信息。

5. 告警与日志

15.1.7 VXLAN DCI隧道未成功建立

1. 故障描述

VXLAN DCI隧道未成功建立。

2. 常见原因

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

· ED之间互联的接口上未配置dci enable命令。

· 与ED对等体之间配置的peer router-mac-local命令未指定dci参数。

3. 故障分析

本类故障的诊断思路为：检查ED间互连的三层接口上是否开启DCI功能或与ED对等体之间配置的peer router-mac-local命令是否指定了dci参数。以上两个功能只需开启一个就可以在ED之间建立VXLAN DCI隧道。

4. 处理步骤

(1) 检查设备上是否开启了如下任何一个功能：

¡ 检查ED间互连的三层接口（三层以太网接口及其子接口、三层以太网聚合接口及其子接口、VLAN接口）上是否配置了dci enable命令。若未配置，则执行dci enable命令，开启接口的DCI功能。

¡ 检查ED对等体之间配置的peer router-mac-local命令是否指定了dci参数。若未指定，则需要重新配置本命令并指定dci参数。

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

¡ 上述步骤的执行结果。

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

¡ 使用display diagnostic-information命令收集诊断信息。

5. 告警与日志

16 ACL和QoS故障处理

16.1 ACL故障处理

16.1.1 ACL下发失败故障

1. 故障描述

用户下发ACL失败，具体分两种失败情况：

· 执行下发命令后设备提示资源不足。

· 执行下发命令后设备无任何错误提示，但ACL不起作用。

2. 常见原因

· 系统硬件资源不足

· packet-filter或QoS策略配置不正确

3. 故障分析

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

图124 ACL下发失败故障诊断流程图

4. 处理步骤

(1) 查看下发时是否报硬件资源不足

下发ACL配置时如果界面打印出“Reason: Not enough hardware resource”字样，则表明ACL下发失败是由硬件资源不足导致。通过display qos-acl resource命令可以进一步确认ACL硬件资源使用情况。

[Sysname] display qos-acl resource

Interfaces: XGE2/1/0/1 to XGE2/1/0/21, XGE2/1/0/22

XGE2/1/0/23 to XGE2/1/0/24

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

Type Total Reserved Configured Remaining Usage

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

VFP ACL 1024 768 0 256 75%

IFP ACL 2048 1792 1 255 87%

IFP Meter 1024 896 0 128 87%

IFP Counter 1024 896 0 128 87%

EFP ACL 1024 0 0 1024 0%

EFP Meter 512 0 0 512 0%

EFP Counter 512 0 0 512 0%

Interfaces: XGE2/1/0/25 to XGE2/1/0/48

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

Type Total Reserved Configured Remaining Usage

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

VFP ACL 1024 768 0 256 75%

IFP ACL 2048 1536 1 511 75%

IFP Meter 1024 768 0 256 75%

IFP Counter 1024 768 0 256 75%

EFP ACL 1024 0 0 1024 0%

EFP Meter 512 0 0 512 0%

EFP Counter 512 0 0 512 0%

如果显示信息中Remaining条目为0了，则表示ACL硬件资源已用尽，设备无法再下发ACL。如果下发时没有报“Reason: Not enough hardware resource”字样，则根据下发方式进行步骤选择：

¡ 通过MQC（QoS策略）方式下发，请进行步骤2；

¡ 通过包过滤（packet-filter）方式下发，请进行步骤3。

(2) 检查QoS策略配置是否正确

通过下面命令分别检查不同使用情况下QoS策略的配置情况（不同设备对于下述命令支持情况存在差异，请以设备实际情况为准）：

¡ 显示以太网服务实例QoS 策略配置信息，display qos policy l2vpn-ac

¡ 显示端口上QoS策略配置信息，display qos policy interface；

¡ 显示VLAN上QoS策略配置信息，display qos vlan-policy；

¡ 显示全局QoS策略配置信息，display qos policy global；

¡ 显示控制平面上QoS策略配置信息，display qos policy control-plane

如果QoS策略中缺少流分类和流行为关联的配置，则补充相应配置。否则可通过以下两个命令分别检查下QoS策略中的类和流行为是否配置正确。

¡ 显示配置的类信息，display traffic classifier user-defined；

¡ 显示配置的流行为信息，display traffic behavior user-defined；

如果没有正确配置，则进行正确配置，否则进行步骤4。

(3) 检查packet-filter配置是否正确

可以通过display packet-filter命令检查packet-filter配置是否正确，如果不正确，则进行正确配置，否则进行步骤4。

(4) 检查ACL配置是否正确

可以通过display acl命令检查ACL是否配置正确，包括各条规则的内容、规则的匹配顺序等。确认规则的内容与报文是否匹配，是否因匹配顺序的原因导致报文没有被匹配上。如果不正确，则进行正确配置，否则进行步骤5。

例1：

ACL number 3100

rule 0 permit ip source 2.2.2.2 0.0.255.255

rule 1 deny ip destination 3.3.3.3 0.0.255.255

如果有报文目的IP是3.3.3.3，源IP 地址是2.2.2.2，则只能匹配rule 0，不能匹配rule 1，如果期望达到rule 1的效果，则此ACL未生效。

例2：

ACL number 3100

rule 0 permit ip source 2.2.2.2 0.0.255.255

ACL number 3009

rule 0 permit ip source 2.2.2.2 0.0.0.255

当流量的源IP地址为2.2.2.2时，就会同时符合ACL number 3100与 ACL number 3009的匹配要求，即发生重叠匹配现象。

ACL的规则匹配顺序请参考“ACL和QoS配置指导”中的“ACL”。

(5) 寻求技术支持

如果上述检查完成后故障仍无法排除，请联系H3C的技术支持工程师。

5. 告警与日志

16.2 QoS故障处理

16.2.1 拥塞丢包故障的定位思路

1. 故障描述

在设备上每隔60秒执行display packet-drop命令查看指定接口丢弃的报文的信息，观察到“Packets dropped due to full GBP or insufficient bandwidth”取值不断增长。

<Sysname> display packet-drop interface gigabitethernet 1/0/1

GigabitEthernet1/0/1:

Packets dropped due to full GBP or insufficient bandwidth: 301

Packets dropped due to Fast Filter Processor (FFP): 261

Packets dropped due to STP non-forwarding state: 321

Packets dropped due to rate-limit: 143

Packets dropped due to broadcast-suppression: 301

Packets dropped due to unicast-suppression: 215

Packets dropped due to multicast-suppression: 241

Packets dropped due to Tx packet aging: 246

基于以上现象判断设备的接口上可能产生拥塞丢包故障。

2. 常见原因

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

· 接口数据缓冲区设置不足，数据缓冲区占满后报文被丢弃。

· 接收到的报文速率超过接口的处理带宽。

3. 故障诊断流程

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

图125 拥塞丢包故障诊断流程图

4. 故障处理步骤

(1) 检查接收数据缓冲区是否存在不足。

对于不支持配置数据缓冲区的产品，请跳过该步骤执行下一步。

在设备上接口视图或系统视图下执行flow-interval命令修改接口统计报文信息的时间间隔为30秒，然后每隔60秒执行一次display interface命令查看指定接口的相关信息中ignored字段，ignored字段表示接收缓冲区不足而产生丢包的数量。

<Sysname> display interface gigabitethernet 1/0/1

GigabitEthernet1/0/1

…

Input (total): 0 packets, 0 bytes

0 unicasts, 0 broadcasts, 0 multicasts, - pauses

Input (normal): 0 packets, 0 bytes

0 unicasts, 0 broadcasts, 0 multicasts, 0 pauses

Input: 0 input errors, 0 runts, 0 giants, 0 throttles

0 CRC, 0 frame, 2048 overruns, - aborts

1024 ignored, - parity errors

Output (total): 0 packets, 0 bytes

0 unicasts, 0 broadcasts, 0 multicasts, - pauses

Output (normal): 0 packets, 0 bytes

0 unicasts, 0 broadcasts, 0 multicasts, 0 pauses

Output: 0 output errors, - underruns, - buffer failures

0 aborts, 0 deferred, 0 collisions, 0 late collisions

- lost carrier, - no carrier

…

如果该显示信息不断增长，则表示接收数据缓冲区不足，产生了拥塞丢包。这种情况下，请执行burst-mode enable命令用来开启数据缓冲区自动分配功能，开启本功能后可以在一定程度上提高报文缓存功能，降低报文丢包率。

一段时间后，再次执行display interface命令或display packet-drop命令查看指定接口丢弃的报文的信息，如果问题仍未解决，则请继续执行以下操作。

(2) 检测发送端接口是否流量过大

然后每隔60秒执行一次display interface命令查看指定接口的相关信息中overruns字段，如果overruns字段标识的数字不断增长，则表示接口的接收速率超出接口队列处理能力。可以开启设备接口下队列的拥塞通知功能，使得设备不再丢弃拥塞报文，并使用拥塞通知机制通知报文发送端降低发包速率，从而达到降速减少丢包的目的。需要注意的是，该措施需要报文发送端和接收端均支持拥塞通知机制才能实现（对于不支持拥塞通知的产品，请跳过该步骤执行下一步）。

可以通过以下方式开启队列的拥塞通知功能：

¡ 在系统视图下执行qos wred queue table命令创建WRED表，在WRED表视图下执行queue ecn命令用来开启指定队列的拥塞通知功能，并执行qos wred apply命令将WRED表应用到接口下。

[Sysname] qos wred queue table aaa

[Sysname-wred-table-aaa]queue 2 ecn

[Sysname-wred-table-aaa]quit

[Sysname-GigabitEthernet1/0/1]qos wred apply aaa

¡ 部分设备，可在接口视图下执行qos wred queue ecn命令开启指定队列的拥塞通知功能。

¡ 部分设备，可在系统视图下执行qos wred ecn enable命令用来开启全局拥塞通知功能。

开启队列的拥塞通知功能一段时间后，再次执行display interface命令或display packet-drop命令查看指定接口丢弃的报文的信息，如果问题仍未解决，则请继续执行以下操作。

(3) QoS拥塞避免的目的仅仅是在现网条件下降低拥塞发生的概率，要从根本上解决拥塞丢包故障需要优化网络，提升链路带宽，合理规划网络流量。例如，采用以太网链路聚合将多条物理链路捆绑在一起形成一条聚合链路来提升链路带宽；合理规划ECMP等价路由，将流量合理分担到不同链路上。如果优化网络后问题仍未解决，则请继续执行以下操作。

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

¡ 上述步骤的执行结果。

¡ 设备的配置文件。

5. 告警与日志

17 IP隧道及安全VPN类故障处理

17.1 IP隧道故障处理

17.1.1 点对点类隧道无法Ping通对端Tunnel接口IP地址

1. 故障描述

点对点类隧道（包括GRE、IPv4和IPv6隧道）配置完成后，本端Tunnel接口IP地址无法Ping通对端Tunnel接口IP地址。

本章以GRE over IPv4隧道为例进行说明。

本节描述的故障处理方法不适用于Ds-Lite、GRE-P2MP等点对多点隧道。

2. 常见原因

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

· 配置错误：比如两端隧道模式不一致、未配置源地址或者是目的地址、两端源和目的不满足互为源、目的的关系等。

· 物理链路不通：Tunnel的源和目的地址之间不存在路由，导致Tunnel接口不能UP，或者Tunnel依赖的物理链路路由不通，导致Tunnel口虽然能UP但是中间设备丢包。

3. 故障分析

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

图126 无法Ping通对端Tunnel接口IP地址故障诊断流程图

4. 处理步骤

(1) 检查隧道两端接口配置的完整性。

在两端设备分别执行display current interface tunnel命令，查看隧道接口配置，请确保隧道接口的源地址、目的地址和隧道接口IP地址均已配置。

<Sysname> display current interface tunnel

interface Tunnel1 mode gre

ip address 10.1.1.1 255.255.255.0

source 1.1.1.1

destination 1.1.1.2

如果隧道接口的配置不完整，请参考如下示例补充缺失的配置。

<Sysname> system-view

[Sysname] interface tunnel 1 mode gre

[Sysname-Tunnel1] ip address 10.1.1.1 255.255.255.0

[Sysname-Tunnel1] source 1.1.1.1

[Sysname-Tunnel1] destination 1.1.1.2

(2) 检查隧道两端封装模式是否一致。

在两端设备上分别执行display current interface tunnel命令，查看隧道接口的封装模式。

<Sysname> display current interface tunnel

interface Tunnel1 mode gre

ip address 10.1.1.1 255.255.255.0

source 1.1.1.1

destination 1.1.1.2

如果两端封装模式不一致，则需要先通过undo interface tunnel命令删除模式配置错误的隧道，再通过interface tunnel命令重新配置隧道接口。隧道删除后，隧道口下的配置也同时被删除，还需要重新配置源地址、目的地址和接口IP地址。

(3) 检查两端隧道源、目的地址是否匹配。

在两端设备分别执行display current interface tunnel命令，查看隧道接口配置，请确保本端隧道的源地址等于对端隧道的目的地址，本端隧道的目的地址等于对端隧道的源地址，且源地址必须是本机地址。

本端设备：

<Sysname> display current interface tunnel

interface Tunnel1 mode gre

ip address 10.1.1.1 255.255.255.0

source 1.1.1.1

destination 1.1.1.2

对端设备：

<Sysname> display current interface tunnel

interface Tunnel1 mode gre

ip address 10.1.1.2 255.255.255.0

source 1.1.1.2

destination 1.1.1.1

如果两端隧道源、目的地址配置有误，则在隧道接口视图下执行source命令或destination命令重新配置源、目的地址。

(4) 检查两端隧道接口状态是否已经UP

通过display interface tunnel可以查看隧道接口状态，如果经过步骤(1)和步骤(2)的检查之后，隧道口状态依旧为Down，则可以参考故障处理手册中的Tunnel接口工作不稳定中的内容继续定位。

<Sysname> display interface tunnel 1

Tunnel1

Current state: UP

Line protocol state: UP

Description: Tunnel1 Interface

Bandwidth: 64kbps

Maximum transmission unit: 1476

Internet address: 10.1.2.1/24 (primary)

Tunnel source 2002::1:1 (Vlan-interface10), destination 2001::2:1

Tunnel TOS 0xC8, Tunnel TTL 255

Tunnel protocol/transport GRE/IPv6

…

(5) 检查隧道的源、目的地址间是否路由可达

检查隧道的源、目的IP地址之间是否存在路由。通过display current interface tunnel检查两端隧道接口IP是否在同一网段，如果在同一网段，默认会生成网段路由，不存在物理链路不通的问题；如果不在同一网段，则通过display fib命令检查隧道源、目的IP地址之间是否路由可达，如果不存在路由，则需要配置相应的静态或者动态路由，使隧道的源、目的IP地址间路由可达。如果仍无法解决故障，则继续执行步骤(6)。

<Sysname> display fib

Route destination count: 4

Directly-connected host count: 0

Flag:

U:Useable G:Gateway H:Host B:Blackhole D:Dynamic S:Static

R:Relay F:FRR

Destination/Mask Nexthop Flag OutInterface/Token Label

0.0.0.0/32 127.0.0.1 UH InLoop0 Null

1.1.1.2/24 192.168.126.1 USGF M-GE0/0/0 Null

127.0.0.0/8 127.0.0.1 U InLoop0 Null

127.0.0.0/32 127.0.0.1 UH InLoop0 Null

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

¡ 上述步骤的执行结果。

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

¡ 下表中Debug命令输出的调试信息。

表17 Debug命令列表

命令	描述
debugging tunnel	开启Tunnel模块的调试信息开关
debugging gre	开启GRE的调试信息开关
debugging ip packet [ acl acl-number ]	开启IP报文调试信息开关
debugging ipv6 packet [ acl acl-number ]	开启IPv6报文调试信息开关
debugging ip error	开启IP转发错误调试信息开关
debugging ip info [ acl acl-number ]	开启IP转发调试信息开关
debugging ipv6 info [ acl acl-number ]	开启IPv6转发调试信息开关

5. 告警与日志

18 用户接入与认证故障处理

18.1 802.1X故障处理

18.1.1 802.1X用户认证失败

1. 故障描述

802.1X用户认证失败或认证异常。

2. 常见原因

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

· 全局或接口802.1X功能未开启。

· 802.1X客户端不能正常发送或接收认证报文。

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

· 802.1X用户使用的认证域及相关配置错误。

· RADIUS服务器无回应。

· RADIUS服务器认证拒绝。

· 授权属性下发失败。

· 802.1X认证用户的MAC地址被其它端口绑定。

· 802.1X用户处于静默状态。

· 802.1X在线用户数达到最大值。

3. 故障分析

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

图127 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) 检查下线原因是否为认证拒绝。

a. 执行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请求测试，定位故障问题后，调整服务器、设备及客户端配置。

b. 执行display aaa online-fail-record命令，通过显示信息里的Online failure reason字段确认认证失败原因。

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

a. 执行debugging dot1x event打开802.1X认证事件调试开关。如果系统打印调试信息“Authorization failure.”，则表示授权失败。

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

c. 如果配置了授权失败用户下线功能，执行dot1x access-user log enable failed-login命令打开802.1X接入用户上线失败日志功能，通过“DOT1X_LOGIN_FAILURE”日志确认授权失败的属性（例如授权ACL、VLAN）。

d. 检查服务器上的授权属性（例如授权ACL、VLAN）设置是否正确，确保服务器下发的授权属性内容准确。

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

(8) 检查802.1X用户的MAC地址是否绑定失败。

a. 执行debugging dot1x event命令打开802.1X事件调试信息开关。如果系统打印调试信息“MAC binding processing failure.”，则表示802.1X用户的MAC地址绑定处理失败。

b. 执行dot1x access-user log enable failed-login命令打开802.1X接入用户上线失败日志功能，通过“DOT1X_MACBINDING_EXIST”日志确认用户上线失败的原因为用户MAC地址绑定了其他端口。

c. 在设备上通过undo dot1x mac-binding命令取消用户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) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

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

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

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

5. 告警与日志

18.1.2 802.1X用户掉线

1. 故障描述

802.1X用户认证成功上线后，异常掉线。

2. 常见原因

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

· 设备上802.1X认证的相关配置变化。

· 在线用户握手失败。

· 实时计费失败。

· 802.1X用户重认证失败

· 服务器强制用户下线。

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

· 用户会话超时。

3. 故障分析

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

图128 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. 执行dot1x access-user log enable abnormal-logoff命令开启802.1X接入用户异常下线日志功能，通过“DOT1X_LOGOFF_ABNORMAL”日志确认用户异常掉线的原因为重认证失败。

c. 参考“18.1.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) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

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

¡ 执行display aaa abnormal-offline-record或display aaa normal-offline-record命令显示的下线原因。

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

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

5. 告警与日志

18.2 AAA故障处理

18.2.1 登录设备后无法执行部分命令行

1. 故障描述

管理员登录设备后没有部分命令行的执行权限，系统打印提示信息 “Permission denied.”。

2. 常见原因

本类故障的主要原因为，给用户授权的用户角色权限过小。

3. 故障分析

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

图129 登录后无法执行部分命令行的故障诊断流程图

4. 处理步骤

(1) 检查用户角色否为自定义用户角色。

请以超级管理员身份（即具有network-admin、mdc-admin、context-admin或者level-15用户角色）登录设备，执行display line命令查看登录用户线的认证方式，并根据不同的认证方式，采取不同的处理步骤：

<Sysname> display line

Idx Type Tx/Rx Modem Auth Int Location

0 CON 0 9600 - N - 0/0

+ 81 VTY 0 - N - 0/0

+ 82 VTY 1 - P - 0/0

+ 83 VTY 2 - A - 0/0

...

¡ 对于none和password认证方式（Auth字段：N、P），检查对应用户线视图下的用户角色是否为自定义用户角色。如果不是自定义用户角色，则通过user-role role-name命令设置权限更高的系统预定义角色。

¡ 对于scheme认证方式（Auth字段：A），首先查看登录用户认证域下配置的认证方法：

- 如果采用了Local认证方法，则通过display local-user命令查看用户角色是否为自定义用户角色。如果不是自定义用户角色，则通过authorization-attribute user-role role-name命令设置权限更高的系统预定义角色（下例为network-admin）。

<Sysname> system-view

[Sysname] local-user test class manage

[Sysname-luser-manage-test] authorization-attribute user-role network-admin

- 如果采用了远程认证方法，则联系远程认证服务器管理员，为用户授权权限更高的系统预定义角色。

(2) 检查不允许执行的命令行是否在自定义用户角色允许的权限范围内。

a. 执行命令display role name role-name，查看用户的自定义角色拥有的命令行权限规则。

b. 如果用户所执行的命令行不在所属用户角色拥有的命令行权限范围之内，则为其更换权限较高的系统域定义用户角色，或者通过命令rule为用户的自定义角色增加对应的命令行权限规则。需要注意的是，自定义用户角色即使配置了较高的权限规则，仍然有部分无法支持的命令行，这些命令行的明细请查看“基础配置指导”中的“RBAC”手册。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

18.2.2 登录设备后无法创建或修改本地用户

1. 故障描述

管理员登录设备后无法创建或修改本地用户，系统打印提示信息“Insufficient right to perform the operation.”。

2. 常见原因

本类故障的主要原因为，给用户授权的用户角色权限不具备修改目标本地用户配置的权限。

3. 故障分析

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

图130 登录后无法创建或修改本地用户的故障诊断流程图

4. 处理步骤

(1) 检查登录用户的角色是否为预定义的超级管理员角色，即为network-admin、level-15、mdc-admin、context-admin之一。

只有上述预定义用户角色才拥有创建本地用户的权限，其它用户角色只有进入自身本地用户视图的权限。如果登录用户不拥有如上预定义用户角色，则为其授权其中之一。如果重新授权后，故障仍未排除，请继续定位。

此步骤仅适用于无权限创建本地用户，若无权限修改本地用户，请执行步骤（2）。

(2) 比较登录用户和目标用户的权限范围。

执行命令display role name role-name，分别查看登录用户和目标用户的角色权限，并比较两者的权限大小。如果操作者权限较小，则为其更换拥有更高权限的用户角色。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

18.2.3 管理员未被授权用户角色

1. 故障描述

管理员无法成功登录设备，设备也没有提供三次登录尝试机会。例如，使用Telnet登录时，用户输入用户名和密码后，设备登录界面上既未打印提示信息“AAA authentication failed”，也未再次提示用户输入用户名和密码。

2. 常见原因

本类故障的主要原因为，没有为用户授权用户角色。

3. 故障分析

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

图131 管理员未被授权用户角色的故障诊断流程图

4. 处理步骤

(1) 检查是否为用户授权了用户角色。

<Sysname> display line

Idx Type Tx/Rx Modem Auth Int Location

0 CON 0 9600 - N - 0/0

+ 81 VTY 0 - N - 0/0

+ 82 VTY 1 - P - 0/0

+ 83 VTY 2 - A - 0/0

...

¡ 对于none和password认证方式（Auth字段：N、P），检查对应用户线视图下是否存在用户角色配置。如果不存在，则通过user-role role-name命令设置用户角色（下例中为abc）。

<Sysname> system-view

[Sysname] line vty 0 63

[Sysname-line-vty0-63] user-role abc

¡ 对于scheme认证方式（Auth字段：A），首先查看登录用户认证域下配置的认证方法：

- 如果采用了Local认证方法，则执行display local-user命令查看该用户的授权用户角色情况，如果显示信息中的“User role list：”字段为空，则表示该用户没有被授权任何用户角色。

<Sysname> display local-user user-name test class manage

Total 1 local users matched.

Device management user test:

State: Active

Service type: Telnet

User group: system

Bind attributes:

Authorization attributes:

Work directory: flash:

User role list:

...

此时，需要进入该本地用户视图，执行authorization-attribute user-role命令为用户授权角色（下例中为abc）。

<Sysname> system-view

[Sysname] local-user test class manage

[Sysname-luser-manage-test] authorization-attribute user-role abc

- 如果采用了远程认证方法，则联系远程认证服务器管理员确认是否为该用户授权了用户角色，若无，请为该用户添加用户角色属性。以Free RADIUS服务器为例，如果需要在users文件中添加用户角色network-admin，则需要编辑的脚本如下：

user Cleartext-Password := "123456"

H3C-User-Roles ="shell:roles=\"network-admin\""

其它RADIUS服务器上的用户角色添加方式请以实际情况为准。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

18.2.4 登录用户名含有非法字符

1. 故障描述

管理员登录设备失败，系统打印如下形式的日志信息：

Sysname LOGIN/5/LOGIN_INVALID_USERNAME_PWD: -MDC=1; Invalid username or password from xx.xx.xx.xx.

2. 常见原因

本类故障的主要原因为，用户输入的用户名中含有非法字符。

3. 故障分析

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

图132 登录用户名含有非法字符的故障诊断流程图

4. 处理步骤

本处理步骤仅适用于SSH及Telnet登录用户。

(1) 检查用户输入的用户名是否含有非法字符。

用户登录设备时，系统会检查用户输入的纯用户名以及域名的有效性，如果纯用户名中包含了非法字符“\”、“|”、“/”、“:”、“*”、“?”、“<”、“>”和“@”，域名中包含“@”，则不允许登录。此时，建议用户再次尝试登录，并输入正确的用户名。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

18.2.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. 故障分析

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

图133 本地用户名或密码错误的故障诊断流程图

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. 告警与日志

18.2.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. 故障分析

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

图134 本地用户服务类型不匹配的故障诊断流程图

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. 告警与日志

18.2.7 登录失败固定次数后，被禁止在指定的时间内再次登录

1. 故障描述

管理员登录设备失败指定的次数后，在一定时间内被禁止再次登录设备。

2. 常见原因

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

· 设备上开启了Login用户攻击防范功能。开启该功能后，会导致Login用户登录失败指定的次数后，若用户的IP地址被加入黑名单，则设备将会丢弃来自该IP地址的报文，使得该用户不能在指定的阻断时长内进行登录操作。

· 用户采用本地认证方式登录设备，且设备上开启了Password Control功能。用户登录认证失败后，系统会将该用户加入密码管理的黑名单，并根据配置的处理措施对其之后的登录行为进行相应的限制。当用户登录失败次数超过指定值后，系统禁止该用户登录，经过一段时间后，再允许该用户重新登录。

3. 故障分析

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

图135 指定时间内被阻断登录的故障诊断流程图

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

¡ 如果该用户被阻断后，根本无法向设备发起登录连接，则执行步骤（3）。

(3) 检查是否开启了Login用户攻击防范功能。

如果当前配置中存在attack-defense login开头的相关命令，则可以根据需要关闭Login用户攻击防范功能，或者改变Login用户登录连续失败的最大次数以及登录失败后的阻断时长。

¡ 通过执行undo attack-defense login enable命令关闭Login用户攻击防范功能，并通过执行undo blacklist global enable命令关闭与之配合的全局黑名单过滤功能。

<Sysname> system-view

[Sysname] undo attack-defense login enable

[Sysname] undo blacklist global enable

¡ 通过执行attack-defense login max-attempt命令增加连续登录失败的最大次数，增大用户登录的尝试机会（下例为5次）。

<Sysname> system-view

[Sysname] attack-defense login max-attempt 5

¡ 通过执行attack-defense login block-timeout命令减小阻断时长（下例为1分钟），让用户尽快重新登录。

<Sysname> system-view

[Sysname] attack-defense login block-timeout 1

执行以上操作可能会减弱设备防范Login用户DoS攻击的力度，请慎重执行。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

18.2.8 登录失败后需要等待一定时长再进行重认证

1. 故障描述

管理员登录设备失败后，控制台无响应一定的时间，期间用户无法执行任何操作。

2. 常见原因

本类故障的主要原因主要为，设备上配置了Login延时认证功能。开启本功能后，用户登录失败后，系统将会延迟一定的时长之后再允许用户进行认证。

3. 故障分析

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

图136 登录失败后等待重认证的故障诊断流程图

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. 告警与日志

18.2.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. 故障分析

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

图137 使用相同用户名的上线用户数达上限后的故障诊断流程图

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. 告警与日志

18.2.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. 故障分析

本类故障的诊断流程如图138所示：

图138 使用相同登录方式接入用户数达到上限后的故障诊断流程图

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. 告警与日志

18.2.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. 故障分析

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

图139 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方案视图下配置的源IP地址（仅部分机型支持通过source-ip命令配置，如不支持请忽略本步骤）。

b. 系统视图下的配置的源IP地址（仅部分机型支持通过radius source-ip命令配置，如不支持请忽略本步骤）。

c. RADIUS方案视图下配置的NAS-IP地址（通过nas-ip命令）。

d. 系统视图下的配置的源NAS-IP地址（通过radius nas-ip命令）。

e. 发送RADIUS报文的出接口的IP地址。

(3) 检查设备和服务器之间的网络是否存在问题。

首先使用ping等手段排除设备与服务器之间的网络可达性，然后排查该网络中是否存在防火墙等设备。通常，如果网络中存在防火墙设备且不允许目的UDP端口号为RADIUS服务器端口号的报文通过（缺省的RADIUS认证端口号为1812，缺省的RADIUS计费端口号为1813），RADIUS报文将被丢弃。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

18.2.12 HWTACACS服务器无响应

1. 故障描述

使用HWTACACS认证服务器认证/授权/计费失败。如果同时在设备上执行debugging hwtacacs event命令打开HWTACACS事件调试信息开关，系统打印的事件调试信息中将出现“Connection timed out.”。

2. 常见原因

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

· HWTACACS服务器上配置的共享密钥与接入设备上配置的共享密钥不一致。

· HWTACACS服务器上没有添加接入设备的IP地址或者添加的IP地址不正确。

· HWTACACS服务器与接入设备之间的网络存在问题，例如中间网络存在防火墙时，防火墙阻止了HWTACACS服务器提供AAA服务的端口号（缺省认证/授权/计费端口号为49）。

3. 故障分析

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

图140 HWTACACS服务器无响应的故障诊断流程图

4. 处理步骤

(1) 检查HWTACACS服务器上配置的共享密钥与接入设备上配置的是否一致。

¡ 如果共享密钥配置不一致，则：

- 在接入设备上，需要在HWTACACS方案视图下执行key authentication、key authorization、key accounting命令重新配置认证、授权、计费共享密钥（下例中认证和授权密钥为123、计费密钥为456）。

<Sysname> system-view

[Sysname] hwtacacs scheme hwt1

[Sysname-hwtacacs-hwt1] key authentication simple 123

[Sysname-hwtacacs-hwt1] key authorization simple 123

[Sysname-hwtacacs-hwt1] key accounting simple 456

- 在HWTACACS服务器上，重新配置与接入设备交互HWTACACS报文的共享密钥，保证与接入设备上配置的一致。

¡ 如果共享密钥配置一致，则执行步骤（2）。

(2) 检查HWTACACS服务器上是否添加了接入设备的IP地址或者添加的IP地址是否正确。

HWTACACS服务器上添加的设备IP地址必须是接入设备发送HWTACACS报文的源IP地址。接入设备发送HWTACACS报文使用的源IP地址可以通过相关命令设置。

接入设备按照以下顺序选择发送HWTACACS报文使用的源IP地址：

a. HWTACACS方案视图下配置的源IP地址（通过nas-ip命令）。

b. 系统视图下的配置的源IP地址（通过hwtacacs nas-ip命令）。

c. 发送HWTACACS报文的出接口的IP地址。

(3) 检查设备和服务器之间的网络是否存在问题。

首先使用ping等手段排除设备与服务器之间的网络可达性，然后排查该网络中是否存在防火墙等设备。通常，如果网络中存在防火墙设备且不允许目的TCP端口号为HWTACACS服务器端口号的报文通过（缺省的HWTACACS认证/授权/计费端口号为49），HWTACACS报文将被丢弃。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

18.2.13 用户接入类型与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. 故障分析

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

图141 用户接入类型与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. 告警与日志

18.2.14 本地认证登录失败

1. 故障描述

管理员采用本地认证登录设备失败。

2. 常见原因

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

· 用户线下的认证方式配置错误。

· VTY用户线下支持的协议类型不正确。

· ISP域下配置的认证、授权、计费方案错误。

· 本地用户不存在、用户密码错误，或服务类型错误。

· 本地用户接入数量达到上限。

· 登录设备的用户数量到达上限。

· 全局密码管理功能开启的情况下，设备本地的lauth.dat文件异常。

3. 故障分析

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

图142 本地认证登录失败的故障诊断流程图

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命令查看用户认证域下的access-limit配置。

¡ 如果显示信息中的“Access limit:”字段为具体的数值，则执行display domain name isp-name access-user statistics命令查看“Online user count”字段取值是否达到Access limit数值。如果达到上，则根据需要采取以下措施之一：

- 在ISP域视图下执行access-limit命令扩大用户数上限（本例中为20）。

<Sysname> system-view

[Sysname] domain name test

[Sysname-isp-test] access-limit 20

- 在用户视图下执行free命令强制其它在线用户下线（本例中为强制释放VTY1上建立的所有连接）。

<Sysname> free line vty 1

Are you sure to free line vty1? [Y/N]:y

[OK]

¡ 如果“Access limit:”字段取值为“Not configured”，或者用户数未达到上限值，则继续定位。

部分设备不支持查看用户认证域下的access-limit配置，请跳过本步骤。

(4) 检查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。

(5) 检查用户名和密码是否正确。

执行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]

(6) 检查使用该本地用户名接入的用户数是否达到上限。

在本地用户视图下执行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配置不存在，或者用户数未达到上限值，则继续定位。

(7) 检查指定登录类型的在线用户数是否到达上限。

a. 在系统视图下执行display this命令查看是否存在aaa session-limit的配置，若无此配置，则说明采用了缺省值32。

aaa session-limit ftp 33

domain default enable system

b. 执行display users查看当前用户线的用户登录情况，确认是否已到用户数上限。

c. 如果在线用户数到达上限，则根据需要采取以下措施之一：

- 在系统视图下执行aaa session-limit命令扩大用户数上限。

- 在用户视图下执行free命令强制其它在线用户下线。

(8) 检查本地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

¡ 若未开启，则忽略此步骤。

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

¡ 上述步骤的执行结果。

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

¡ 打开Local-Server调试信息开关（通过debugging local-server all命令），收集设备的调试信息。

5. 告警与日志

18.2.15 RADIUS认证登录失败

1. 故障描述

管理员采用RADIUS认证登录设备失败。

2. 常见原因

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

· 用户线下的认证方式配置错误。

· VTY用户线下支持的协议类型不正确。

· ISP域下配置的认证、授权、计费方案错误。

· 与RADIUS服务器交互失败。

· RADIUS服务器下发的Login-Service属性值不正确。

· RADIUS服务器未下发用户角色权限。

3. 故障分析

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

图143 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] domain name test（不支持的设备请跳过本步骤）

[Sysname-isp-test] authentication login radius-scheme rd1

[Sysname-isp-test] authorization login radius-scheme rd1

[Sysname-isp-test] accounting login radius-scheme rd1

(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属性情况，并采用“18.2.13 用户接入类型与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. 告警与日志

18.2.16 HWTACACS认证登录失败

1. 故障描述

管理员采用HWTACACS认证登录设备失败。

2. 常见原因

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

· 用户线下的认证方式配置错误。

· VTY用户线下支持的协议类型不正确。

· ISP域下配置的认证、授权、计费方案错误。

· 与HWTACACS服务器交互失败。

· HWTACACS服务器未下发用户角色权限。

3. 故障分析

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

图144 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] domain name 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. 告警与日志

18.2.17 LDAP认证登录失败

1. 故障描述

管理员采用LDAP认证登录设备失败。

2. 常见原因

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

· 用户线下的认证方式配置错误。

· VTY用户线下支持的协议类型不正确。

· ISP域下配置的认证、授权、计费方案错误。

· 与LDAP服务器交互失败。

3. 故障分析

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

图145 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] domain name 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. 告警与日志

18.2.18 RADIUS认证服务器下发的动态VLAN不生效

1. 故障描述

802.1X或MAC地址认证用户在线的情况下，RADIUS认证服务器为其动态下发的VLAN授权属性不生效。

2. 常见原因

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

· 未开启RADIUS DAE服务。

· RADIUS下发的授权属性内容不正确。

· 接入用户未获取到动态VLAN。

· 动态授权的VLAN所属接口类型配置错误。

· 动态授权的VLAN不存在。

3. 故障分析

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

图146 RADIUS认证服务器下发动态VLAN不生效故障诊断流程图

4. 处理步骤

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

¡ 上述步骤的执行结果。

¡ 设备的配置文件、调试信息、诊断信息。

5. 告警与日志

18.2.19 RADIUS认证服务器下发的Filter-Id属性不生效或只有部分生效

1. 故障描述

RADIUS认证服务器通过Filter-Id属性向用户下发ACL，用户认证登录后无法正常访问网络资源。

2. 常见原因

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

· RADIUS下发的授权属性内容不正确。

· 接入用户未获取到ACL。

· 授权的ACL不存在。

3. 故障分析

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

图147 认证登录后无法正常访问授权ACL网络资源故障诊断流程图

4. 处理步骤

(1) 检查RADIUS服务器下发的Filter-ID属性内容是否准确。

执行debugging radius packet命令打开RADIUS报文调试信息开关，同时让RADIUS服务器尝试再次下发Filter-ID属性，查看设备上打印的RADIUS报文调试信息：

¡ 如果下发的Filter-ID属性为纯数字，则表示下发了ACL编号。

*Aug 18 16:54:49:670 2021 Sysname RADIUS/7/PACKET: -MDC=1;

Received a RADIUS packet

Server IP : 128.11.3.48

NAS-IP : 128.11.30.69

VPN instance : --(public)

Server port : 54175

Type : COA request

Length : 32

Packet ID : 200

User-Name="user"

Filter-Id="2001"

¡ 如果下发的Filter-ID属性值不全为数字，且同时下发的下一个属性为H3c-ACL-Version（取值为整数1～4），则表示下发了ACL名称。

（部分设备上如果下发的Filter-ID属性值不全为数字，也不包含等号，且同时下发的下一个属性为H3c-ACL-Version（取值为整数1～4），则表示下发了ACL名称；部分设备上如果下发的Filter-ID属性值不全为数字，则表示下发了User Profile名称，请跳过本步骤）

*Aug 18 16:55:19:798 2021 Sysname RADIUS/7/PACKET: -MDC=1;

Received a RADIUS packet

Server IP : 128.11.3.48

NAS-IP : 128.11.30.69

VPN instance : --(public)

Server port : 54176

Type : COA request

Length : 48

Packet ID : 157

User-Name="user"

Filter-Id="aclname1"

H3c-ACL-Version=1

如果未下发预期取值的Filter-ID属性，或者下发的ACL类型为设备不支持的类型，请联系RADIUS服务器管理员修改授权ACL配置并尝试重新下发Filter-ID，否则继续定位。

(2) 检查用户是否成功获得下发的ACL信息。

执行display dot1x connection或display mac-authentication connection命令，查看相关在线用户信息中是否存在授权的ACL信息：

¡ 如果存在授权ACL信息，说明ACL下发成功。

¡ 如果不存在授权ACL信息，说明ACL没有下发成功。此时，建议在技术支持人员的指导下，结合RADIUS调试信息继续定位故障发生的原因。

(3) 检查设备上对应的ACL是否已创建。

执行display acl all命令查看下发的ACL是否存在：

¡ 如果未创建，请在系统视图下执行acl number acl-number [ name acl-name ]命令创建相应的ACL。

¡ 如果已创建，请确认ACL配置是否正确。

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

¡ 上述步骤的执行结果。

¡ 设备的配置文件、调试信息、诊断信息。

5. 告警与日志

18.2.20 802.1X、MAC地址认证、Web认证用户进行RADIUS认证时逃生失败

1. 故障描述

802.1X、MAC地址认证、Web认证用户认证时，RADIUS服务器不可达情况下的逃生功能失效。包括：

· 未逃生，新用户无法上线。

· 已逃生，但不能访问配置的逃生资源。

· 已逃生，但又被强制下线。

2. 常见原因

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

· 接口上配置了端口安全的Free VLAN，指定VLAN的用户流量不进行认证。

· 未按照实际需要配置相应的逃生策略。

· 采用RADIUS认证方案进行认证时，并非该方案下的所有RADIUS服务器均不可达，实际上存在可达的RADIUS服务器，且是其它原因造成用户认证失败。

· 为用户配置RADIUS认证方法的同时指定了备选认证方法（Local或None），导致RADIUS认证服务器不可达后，转为进行本地认证或不认证。

· 对于802.1X认证、MAC地址认证用户，采用接口上的逃生策略时，接口上配置的逃生资源不存在。

· 接口上开启了802.1X认证或MAC认证下线检测功能的情况下，未开启对应的在线用户逃生功能，使得设备因为在一个下线检测定时器间隔内没有检测到用户的流量而强制用户下线。

3. 故障分析

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

图148 RADIUS认证时逃生失效故障诊断流程图

4. 处理步骤

(1) 检查端口上是否配置了端口安全Free VLAN。

如果用户接入的端口上配置了端口安全Free VLAN，那么指定VLAN内的802.1X认证、MAC地址认证用户的流量将不会触发认证，而是直接转发，因此这些用户也不会触发逃生功能。端口安全Free VLAN的配置示例如下：

<Sysname> system-view

[Sysname] interface gigabitethernet 1/0/1

[Sysname-GigabitEthernet1/0/1] port-security free-vlan 2 3

如果不希望指定VLAN内的用户流量直接转发，请取消相关Free VLAN的配置。

(2) 检查配置的逃生策略是否准确。

设备上支持两种逃生策略，请按需配置：

¡ 基于ISP域逃生（802.1X认证、MAC地址认证和Web认证用户）：设备进入逃生状态时，认证域内新接入的用户从当前域中“逃离”，无需认证，直接切换到绑定的“逃生域”内。逃生域的配置示例如下：

# 在ISP域test下，指定用户认证过程中，RADIUS服务器不可达时的逃生域为dm1。

<Sysname> system-view

[Sysname] domain abc（不支持的设备请跳过本步骤）

[Sysname] domain name abc（不支持的设备请跳过本步骤）

[Sysname-isp-abc] authen-radius-unavailable online domain dm2

¡ 基于端口逃生（802.1X认证、MAC地址认证用户）：设备进入逃生状态时，端口上新接入的用户无需认证，直接访问当前端口上绑定的某类Critical资源（Critical VLAN、Critical VSI、Critical 微分段、Critical Profile内的Critical资源）。端口下的逃生资源配置示例如下：

# 配置端口GigabitEthernet1/0/1的Critical VLAN为VLAN 100。

<Sysname> system-view

[Sysname] interface gigabitethernet 1/0/1

[Sysname-GigabitEthernet1/0/1] dot1x critical vlan 100

需要注意的是，如果设备上同时部属了两种逃生策略，则逃生域的优先级更高。也就是说，如果RADIUS服务器不可达，新用户会直接进入认证域绑定的逃生域且在该域上线，但不能访问端口上配置的Critical资源。

可以执行display domain命令检查用户认证的ISP域下是否配置了逃生域。在如下示例的显示信息中，“Authen-radius-unavailable”字段取值表示配置的逃生域为dm2。

<Sysname> display domain abc

Domain: abc

State: Active

LAN access authentication scheme: RADIUS=bbb

LAN access accounting scheme: RADIUS=bbb

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 policy: Offline

Service type: HSI

Session time: Exclude idle time

Dual-stack accounting method: Merge

Authorization attributes:

Idle cut: Disabled

IGMP access limit: 4

MLD access limit: 4

Authen-fail action: Offline

Authen-radius-unavailable: Online domain dm2

Authen-radius-recover: Not configured

（部分设备上命令为display domain name abc，且显示信息略有不同）

(3) 检查是否为用户配置了RADIUS认证方案。

执行display domain检查用户认证域下是否为lan-access接入用户配置了RADIUS认证方案。在如下示例的显示信息中，“LAN access authentication scheme”字段取值表示配置了LDAP认证方案，并未配置RADIUS认证方案。

<Sysname> display domain abc

Domain: abc

State: Active

LAN access authentication scheme: LDAP=ldp

LAN access authorization scheme : Local

LAN access accounting scheme: Local

Default authentication scheme: Local

Default authorization scheme: Local

Default accounting scheme: Local

Accounting start failure action: Online

Accounting update failure action: Online

Accounting quota out policy: Offline

Service type: HSI

Session time: Exclude idle time

Dual-stack accounting method: Merge

Authorization attributes:

Idle cut: Disabled

IGMP access limit: 4

MLD access limit: 4

Authen-fail action: Offline

Authen-radius-unavailable: Online domain dm2

Authen-radius-recover: Not configured

（部分设备上命令为display domain name abc，且显示信息略有不同）

如果lan-access接入用户的认证域中未配置RADIUS认证方案，请参考如下示例重新配置。

# 在ISP域abc下，配置lan-access用户使用RADIUS认证方案rd。

[Sysname] domain abc（不支持的设备请跳过本步骤）

[Sysname] domain name abc（不支持的设备请跳过本步骤）

[Sysname-isp-abc] authentication lan-access radius-scheme rd

(4) 检查用户认证使用的RADIUS认证方案下，是否所有的RADIUS服务器均不可达。

仅当用户认证使用的RADIUS方案下的所有RADIUS服务器均处于Block状态时，才会触发设备进入逃生状态。可以通过执行display radius scheme命令查看RADIUS方案下的认证服务器的状态。在如下示例的显示信息中，所有RADIUS认证服务器的“State”字段均为Active，说明对应的服务器状态均可达，因此并不会触发用户进行逃生。

<Sysname> display radius scheme rd

RADIUS scheme name: rad1

Index: 0

Primary authentication server:

Host name: Not Configured

IP : 128.11.3.33 Port: 1812

VPN : Not configured

State: Active (duration: 0 weeks, 0 days, 0 hours, 43 minutes, 22 seconds)

Most recent state changes:

2022/03/30 15:15:59 Changed to active state

2022/03/30 15:11:05 Changed to blocked state

2022/03/30 15:09:55 Changed to active state

2022/03/30 15:05:01 Changed to blocked state

2022/03/30 08:58:59 Changed to active state

Test profile: Not configured

Weight: 0

Primary accounting server:

Host name: Not Configured

IP : 128.11.3.33 Port: 1813

VPN : Not configured

State: Blocked (mandatory)

Most recent state changes:

2022/03/30 08:59:11 Changed to blocked state

2022/03/29 19:15:04 Changed to active state

2022/03/29 19:10:06 Changed to blocked state

2022/03/29 19:03:08 Changed to active state

2022/03/29 18:58:15 Changed to blocked state

Weight: 0

Second authentication server:

Host name: Not Configured

IP : 1.12.3.4 Port: 1812

VPN : Not configured

State: Active (duration: 0 weeks, 0 days, 0 hours, 0 minutes, 10 seconds)

Most recent state changes:

2022/03/30 15:59:11 Changed to active state

Test profile: Not configured

Weight: 0

Accounting-On function : Disabled

extended function : Disabled

retransmission times : 50

retransmission interval(seconds) : 3

Timeout Interval(seconds) : 3

Retransmission Times : 3

Retransmission Times for Accounting Update : 5

Server Quiet Period(minutes) : 5

Realtime Accounting Interval(seconds) : 720

Stop-accounting packets buffering : Enabled

Retransmission times : 500

NAS IP Address : Not configured

Local NAS IP Address : Not configured

（部分设备上显示信息略有不同）

(5) 检查RADIUS方案是否配置为最终采用的认证方式。

如果为用户配置RADIUS认证方法的同时指定了备选认证方法（Local或None），那么RADIUS认证服务器不可达后，将转为进行本地认证或不认证，而不会触发设备进入逃生状态。

执行display domain命令，查看用户认证域下为lan-access接入用户配置的认证方法。在如下示例的显示信息中，“LAN access authentication scheme”字段取值表示优先使用RADIUS认证方案rd，其次采用本地认证方案（Local）。

<Sysname> display domain abc

Domain: abc

State: Active

LAN access authentication scheme: RADIUS=rd, Local

LAN access authorization scheme: RADIUS=rd, Local

LAN access accounting scheme: RADIUS=rd, Local

Default authentication scheme: Local

Default authorization scheme: Local

Default accounting scheme: Local

Accounting start failure action: Online

Accounting update failure action: Online

Accounting quota out policy: Offline

Service type: HSI

Session time: Exclude idle time

Dual-stack accounting method: Merge

Authorization attributes:

Idle cut: Disabled

IGMP access limit: 4

MLD access limit: 4

Authen-fail action: Offline

Authen-radius-unavailable: Online domain dm2

Authen-radius-recover: Not configured

（部分设备上命令为display domain name abc，且显示信息略有不同）

这种情况下，如果希望RADIUS服务器不可达后用户逃生，则应该删除配置的备用认证方法，使得RADIUS认证方案为用户认证时采用的最后一种认证方法。

(6) 检查端口上配置的逃生资源是否存在。

¡ 对于进入到逃生域的802.1X、MAC地址认证、Web认证用户，能够访问的逃生资源为逃生域下配置的授权资源。可以首先通过执行display domain命令查看逃生域下的授权属性（Authorization attributes字段），然后在设备上创建对应的授权资源。

¡ 对于基于端口逃生的802.1X、MAC地址认证用户，能够访问的逃生资源为端口上配置的Critical资源。可以首先查看用户认证接口下的Critical配置，然后在设备上创建对应的授权资源。

[Sysname-GigabitEthernet1/0/24] display this

interface GigabitEthernet1/0/24

port link-mode bridge

dot1x critical vlan 24

(7) 检查用户接入的端口上是否开启了下线检测功能。

如果设备上开启了在线认证下线检测功能，缺省情况下，当认证域下所有RADIUS认证服务器均不可达时，设备会将一个下线检测定时器间隔内没有流量的用户强制下线。

在如下例的显示信息中，可以看到MAC地址认证用户的接入端口下开启了在线探测功能。

<Sysname> display mac-authentication

Global MAC authentication parameters:

MAC authentication : Enabled

Authentication method : PAP

DR member configuration conflict : Unknown

Username format : MAC address in lowercase(xxxxxxxxxxxx)

Username : mac

Password : Not configured

MAC range accounts : 2

MAC address Mask Username

2222-0000-0000 ffff-0000-0000 user1

4444-0000-0000 ffff-0000-0000 user1

Offline detect period : 300 s

Quiet period : 60 s

Server timeout : 100 s

Reauth period : 3600 s

User aging period for critical VLAN : 1000 s

User aging period for critical VSI : 1000 s

User aging period for guest VLAN : 1000 s

User aging period for guest VSI : 1000 s

User aging period for critical microsegment: 1000 s

Temporary user aging period : 60 s

Authentication domain : Not configured, use default domain

HTTP proxy port list : Total 10 ports

1-3, 5, 7, 9, 11-13, 15

HTTPS proxy port list : Not configured

Max number of silent MACs : 31236 (per slot)

Online MAC-auth wired users : 1

Online MAC-auth wireless users : 2

Silent MAC users:

MAC address VLAN ID From port Port index

0001-0000-0001 100 GE1/0/2 21

GigabitEthernet1/0/1 is link-up

MAC authentication : Enabled

Carry User-IP : Disabled

Authentication domain : Not configured

Auth-delay timer : Enabled

Auth-delay period : 60 s

Periodic reauth : Enabled

Reauth period : 120 s

Re-auth server-unreachable : Logoff

Guest VLAN : 100

Guest VLAN reauthentication : Enabled

Guest VLAN auth-period : 150 s

Critical VLAN : Not configured

Critical voice VLAN : Disabled

Host mode : Single VLAN

Offline detection : Enabled

Authentication order : Parallel

User aging : Enabled

Server-recovery online-user-sync : Enabled

...略...

当RADIUS认证服务器可达时，如果既需要使用用户下线检测功能，同时又希望RADIUS认证服务器均不可达时，能够保持用户在线状态，请在设备上开启在线用户逃生功能。

以MAC地址认证用户为例，在接口上开启在线用户逃生功能的配置方法如下：

<Sysname> system-view

[Sysname] interface gigabitethernet 1/0/1

[Sysname-GigabitEthernet1/0/1] mac-authentication auth-server-unavailable escape

部分设备不支持配置在线认证下线检测功能，请跳过本步骤。

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

¡ 上述步骤的执行结果。

¡ 设备的配置文件、调试信息、诊断信息。

5. 告警与日志

18.3 MAC地址认证故障处理

18.3.1 MAC地址认证失败

1. 故障描述

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

2. 常见原因

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

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

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

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

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

· RADIUS服务器无回应。

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

· 授权属性下发失败。

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

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

3. 故障分析

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

图149 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) 检查下线原因是否为认证拒绝。

a. 执行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请求测试，定位故障问题后，调整服务器、设备及客户端配置。

b. 执行display aaa online-fail-record命令，通过显示信息里的Online failure reason字段确认认证失败原因，具体请参见《AAA故障处理》。

(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. 告警和日志

18.3.2 MAC认证用户掉线

1. 故障描述

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

2. 常见原因

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

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

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

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

· 服务器强制用户下线。

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

· 用户会话超时。

3. 故障分析

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

图150 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. 参考“18.3.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) 如果故障仍然未能排除，请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

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

¡ 执行display aaa abnormal-offline-record或display aaa normal-offline-record命令显示的下线原因。

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

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

5. 告警与日志

18.4 Password Control故障处理

18.4.1 管理员登录时系统要求修改密码

1. 故障描述

管理员采用本地认证方式登录设备时，系统判断密码强度不符合要求，提示用户修改当前的登录密码。

2. 常见原因

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

· 本地用户视图下配置的Password Control密码检查强度高。

· 本地用户组视图下配置的Password Control密码检查强度高。

· 系统视图下配置的Password Control密码检查强度高。

3. 故障分析

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

图151 管理员登录时要求修改密码故障诊断流程图

4. 处理步骤

(1) 判断是否降低当前密码检查强度。

开启全局密码管理功能后，通过Telnet、SSH、HTTP、HTTPS方式登录的设备管理类用户，输入登录密码时，系统会根据当前设定的Password control密码组合检测策略、密码最小长度限制以及密码复杂度检查策略检查对用户的登录密码进行检查，若不符合以上密码检查策略要求，则视为弱密码。

部分设备上：系统缺省的密码检查策略请查看“安全配置指导”中的“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. 告警与日志

18.4.2 创建本地用户或配置用户密码失败

1. 故障描述

创建本地用户失败，系统打印提示信息“Add user failed.”。

配置本地用户密码失败，系统打印提示信息“Operation failed.”。

2. 常见原因

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

· 设备的内存使用率达到指定门限。

· 设备的本地文件系统存储空间不足。

· 设备本地的lauth.dat文件异常。

3. 故障分析

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

图152 创建本地用户或配置密码失败故障诊断流程图

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

Early-warning: 144M

Secure: 160M

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. 告警与日志

18.4.3 管理员因闲置超时无法登录

1. 故障描述

管理员采用本地认证方式登录设备时，因账户闲置超时无法成功登录，系统打印提示信息“Failed to login because the idle timer expired.”。

2. 常见原因

本类故障的主要原因为，用户自从最后一次成功登录之后，在配置的闲置时间内再未成功登录过，那么该闲置时间到达之后此用户账号立即失效，系统不再允许使用该账号的用户登录。

3. 故障分析

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

图153 管理员因闲置超时无法登录故障诊断流程图

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. 告警与日志

18.5 Portal故障处理

18.5.1 Portal认证页面无法弹出

1. 故障描述

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

2. 常见原因

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

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

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

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

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

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

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

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

· Portal服务器配置错误。

3. 故障分析

本类故障的诊断流程如图154所示：

图154 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重定向功能是否开启。

a. 确认用户是否访问HTTPS网站。若是，由于Portal需要对用户的HTTPS请求进行重定向，因此就必须在设备上配置对HTTPS报文进行重定向的内部侦听端口号（缺省情况下，对HTTPS报文进行重定向的内部侦听端口号为6654，也可以通过http-redirect https-port命令配置，多次执行本命令，最后一次执行的命令生效）。在配置内部侦听端口号之前，需确保该端口号没有被其他服务占用，请先通过display tcp命令查看已被占用的TCP端口号。

b. 检查HTTPS重定向服务器关联的SSL服务器端策略是否存在，若不存在，请完善相关配置。

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

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

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

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

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

<Sysname> system-view

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

部分设备不支持配置Portal Web服务器URL中不转义的特殊字符，请跳过本步骤。

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

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

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

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

¡ 上述步骤的执行结果。

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

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

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

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

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

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

5. 告警与日志

18.5.2 Portal认证失败

1. 故障描述

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

2. 常见原因

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

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

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

· Portal报文非法。

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

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

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

· RADIUS服务器认证拒绝。

· RADIUS服务器无响应。

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

3. 故障分析

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

图155 Portal认证失败的故障诊断流程图

4. 处理步骤

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

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

图156 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认证服务器地址列表中。如果不在，则认为认证报文是非法报文，会将它丢弃。

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

图157 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命令查看认证接口上是否引用了认证域。

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

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

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

图158 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服务器上配置的一致。

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

图159 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. 告警与日志

18.5.3 Portal认证用户掉线

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

1. 常见原因

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

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

· 用户闲置切断。

· 计费更新失败。

· 用户流量达到阈值。

· 服务器强制用户下线。

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

· 用户上线的接口down。

2. 故障分析

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

图160 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. 告警与日志

19 安全类故障处理

19.1 SSH故障处理

19.1.1 SSH客户端登录设备失败

1. 故障描述

设备作为SSH服务器，用户使用SSH客户端登录设备失败。

2. 常见原因

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

· SSH客户端与设备之间路由不通，无法建立TCP连接。

· 设备未开启SSH服务器功能。

· 设备上配置了对SSH客户端的访问控制，且客户端的IP地址不在ACL定义的permit规则范围内。

· 客户端指定的服务端口号与服务器端不一致。

· 设备上的SSH版本与客户端不兼容。

· 设备上未生成本地密钥对。

· 服务器主机密钥与设备上缓存的密钥不匹配。

· 用户线的认证方式或接入协议配置不正确。

· 设备上的本地用户视图下未配置SSH服务。

· SSH用户的服务类型或认证方式配置不正确。

· 设备上SSH2协议使用的算法与客户端不匹配。

· 设备上VTY用户线资源不足。

· 设备上SSH登录用户数达到上限。

3. 故障分析

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

图161 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 1.2.3.4(vpn1) request was denied according to ACL rules.

- 如果不在，请修改ACL配置，使得客户端的IP地址在ACL的permit规则中。如果对所有SSH客户端都不需要进行访问控制，请删除对客户端的访问控制。

- 如果在，请执行步骤(4)。

¡ 如果未设置，请执行步骤(4)。

(4) 检查客户端指定的服务端口号是否与服务器端一致。

如果服务器端修改了SSH服务端口号，客户端仍然使用缺省端口号登录时，会出现登录失败。

以我司设备作为客户端为例，会出现如下错误提示信息：Failed to connect to host 10.1.1.1 port 100.

¡ 如果客户端登录时指定的端口号与服务器端不一致，请在服务器端设备上执行display current-configuration | inc 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!

如果不一致：

¡ 若设备支持delete ssh client server-public-key命令，建议执行该命令删除客户端保存的旧的服务端主机密钥。

¡ 若设备不支持delete ssh client server-public-key命令，请执行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 ssh命令强制释放已建立的部分SSH连接或者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 current number of SSH sessions is 10. The maximum number allowed is 10.

¡ 如果SSH会话数已达到上限，可通过执行aaa session-limit ssh命令调大上限；当配置的最大用户连接数已为可配置的最大值时，如果产品支持free ssh命令，可以执行free ssh命令强制释放已建立的部分SSH连接或者客户端下线空闲的SSH客户端，使得新的SSH用户能够上线。

¡ 如果未达上限，请执行步骤(14)。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

19.1.2 设备作为SSH服务器，用户使用password认证方式登录失败

1. 故障描述

设备作为SSH服务器，用户使用密码认证登录设备失败。

2. 常见原因

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

· SSH客户端与设备之间路由不通，无法建立TCP连接。

· SSH客户端登录密码不正确。

· 设备未开启SSH服务器功能。

· SSH服务器上不存在该SSH登录用户。

· 设备上配置了对SSH客户端的访问控制，且客户端的IP地址不在ACL定义的permit规则范围内。

· 设备上SSH登录用户数达到上限。

· 设备上的SSH版本与客户端不兼容。

· SSH用户的服务类型或认证方式配置不正确。

· 设备上未生成本地密钥对。

· SCP/SFTP工作目录不正确。

3. 故障分析

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

图162 SSH客户端使用password认证方式登录服务器失败（设备作为服务器）故障诊断流程图

4. 处理步骤

(1) 检查客户端能否Ping通设备。

使用ping命令查看网络连接情况。

¡ 如果Ping不通，请参见“Ping不通的定位思路”继续定位，确保SSH客户端能Ping通服务器端。

¡ 如果可以Ping通，请执行步骤(2)。

(2) 检查登录密码是否正确。

a. 如果服务器采用本地认证，请确认当前用户登录的密码是否与设备上设备管理类本地用户视图下配置的密码一致：

- 如果不一致，请重新输入正确的密码。若忘记密码，可以进入设备管理类本地用户视图（用户名为当前登录的用户）下，执行password命令重新配置新的密码，确保登录密码与配置的密码一致。

- 如果一致，请执行步骤19.1.1 4. (2)。

b. 如果服务器采用远程认证，请确认当前用户登录的密码是否与认证服务器上配置的一致：

- 如果不一致，请重新输入正确的密码。若忘记密码，可以在服务器上为登录用户重新设置密码，确保登录密码与认证服务器上配置的一致。

- 如果一致，请执行步骤19.1.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.

¡ 如果客户端登录时指定的端口号与服务器端不一致，请在服务器端设备上执行display current-configuration | include ssh命令查看服务器端配置的端口号，将客户端登录时指定的端口修改为与服务器端一致。

¡ 如果客户端登录时指定的端口号与服务器端一致，请执行步骤(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 1.2.3.4(vpn1) request was denied according to ACL rules.

- 如果不在，请修改ACL配置，使得客户端的IP地址在ACL的permit规则中。如果对所有SSH客户端都不需要进行访问控制，请删除对客户端的访问控制。

- 如果在，请执行步骤19.1.1 4. (5)。

¡ 如果未设置，请执行步骤19.1.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版本的客户端，请执行步骤19.1.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。

¡ 如果均配置正确，请执行步骤19.1.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用户线资源不足，可将空闲且非scheme认证方式的VTY类型用户线认证方式修改为scheme认证方式；若所有VTY类型用户线都已是scheme认证方式且均处于active状态，可执行free ssh命令（仅部分设备支持）强制释放已建立的部分SSH连接或者free line vty命令强制释放VTY用户线，使得新的SSH用户能够上线。

¡ 如果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 current number of SSH sessions is 10. The maximum number allowed is 10.

¡ 如果未达上限，请执行步骤(10)。

(10) 检查服务器上是否生成了本地密钥对。

为了防止“伪服务器欺骗”，客户端验证服务器身份时，首先判断服务器发送的公钥与本地保存的服务器公钥是否一致，确认服务器公钥正确后，再使用该公钥对服务器发送的数字签名进行验证。如果客户端没有保存服务器的公钥或保存的服务器公钥不正确，则服务器身份验证将会失败，从而导致客户端无法登录服务器。因此，客户端登录服务器之前，需要先在服务器端创建密钥对，并将正确的服务器公钥保存在客户端。

虽然一个客户端只会采用DSA、ECDSA或RSA公钥算法中的一种来认证服务器，但是由于不同客户端支持的公钥算法不同，为了确保客户端能够成功登录服务器，建议在服务器上生成DSA、ECDSA和RSA三种密钥对。

在设备上执行display public-key local public命令查看当前设备上的密钥对信息。

¡ 如果DSA、ECDSA和RSA三种密钥对都不存在，请执行public-key local create命令依次进行配置，并确保将服务器上生成的公钥保存到客户端。

¡ 如果已配置，请执行步骤19.1.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. 告警与日志

19.1.3 设备作为SSH服务器，用户使用publickey认证方式登录失败

1. 故障描述

设备作为SSH服务器，用户使用公钥认证登录失败。

2. 常见原因

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

· SSH客户端与设备之间路由不通，无法建立TCP连接。

· 服务器端配置的用户公钥不正确。

· 设备未开启SSH服务器功能。

· SSH服务器上不存在该SSH登录用户。

· 设备上配置了对SSH客户端的访问控制，且客户端的IP地址不在ACL定义的permit规则范围内。

· 设备上SSH登录用户数达到上限。

· 设备上的SSH版本与客户端不兼容。

· SSH用户的服务类型或认证方式配置不正确。

· 设备上未生成本地密钥对。

· SCP/SFTP工作目录不正确。

3. 故障分析

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

图163 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 1.2.3.4(vpn1) request was denied according to ACL rules.

- 如果不在，请修改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 current number of SSH sessions is 10. The maximum number allowed is 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. 告警与日志

19.1.4 设备作为SSH客户端，用户使用password认证方式登录失败

1. 故障描述

设备作为SSH客户端，用户使用password认证方式登录SSH服务器失败。

2. 常见原因

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

· SSH客户端与服务器端之间路由不通，无法建立TCP连接。

· SSH客户端登录密码不正确。

· 服务器上未生成本地密钥对。

· 服务器主机密钥与SSH客户端上缓存的密钥不匹配。

· 客户端的SSH版本与服务器端不兼容。

3. 故障分析

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

图164 设备作为客户端采用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服务器为例，当设备作为客户端登录时，若出现如下提示信息，则表示服务器主机密钥与客户端上本地缓存的密钥不一致。

如果不一致：

¡ 若设备支持delete ssh client server-public-key命令，建议执行该命令删除客户端保存的旧的服务端主机密钥。

¡ 若设备不支持delete ssh client server-public-key命令，请执行undo public-key peer命令，删除客户端保存的旧的服务端主机密钥。

¡ 如果一致，请执行步骤(6)。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

19.1.5 设备作为SSH客户端，用户使用publickey认证方式登录失败

1. 故障描述

设备作为SSH客户端，用户使用publickey认证方式登录SSH服务器失败。

2. 常见原因

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

· SSH客户端与服务器端之间路由不通，无法建立TCP连接。

· 服务器上未生成本地密钥对。

· 服务器端配置的用户公钥不正确。

· 服务器主机密钥与SSH客户端上缓存的密钥不匹配。

· 客户端的SSH版本与服务器端不兼容。

3. 故障分析

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

图165 设备作为客户端使用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服务器为例，当设备作为客户端登录时，若出现如下提示信息，则表示服务器主机密钥与客户端上本地缓存的密钥不一致。

如果不一致：

¡ 若设备支持delete ssh client server-public-key命令，建议执行该命令删除客户端保存的旧的服务端主机密钥。

¡ 若设备不支持delete ssh client server-public-key命令，请执行undo public-key peer命令，删除客户端保存的旧的服务端主机密钥。

¡ 如果一致，请执行步骤(6)。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

20 可靠性类故障处理

20.1 BFD故障处理

20.1.1 BFD会话无法建立

1. 故障描述

在设备上执行display bfd session命令，查看不到会话信息，或者显示信息中“State”值不是“Up”，即BFD会话无法Up。

2. 常见原因

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

· 路由表中不存在BFD会话目的地址的路由。

· BFD检测的链路存在故障，导致BFD报文无法正常交互。

3. 故障分析

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

图166 BFD会话无法建立的故障诊断流程图

4. 处理步骤

BFD在两台网络设备上建立会话，用来检测网络设备间的双向转发路径，为上层应用服务。BFD本身并没有发现机制，而是靠被服务的上层协议通知来建立会话。上层协议在建立新的邻居关系后，将邻居的参数及检测参数（包括目的地址和源地址等）通告给BFD；BFD根据收到的参数建立BFD会话。会话建立后会周期性地快速发送BFD报文，如果在检测时间内没有收到BFD报文，则认为该双向转发路径发生了故障，并将故障信息通知给该会话所服务的上层应用，由上层应用采取相应的措施。因此，在排除BFD会话无法建立的故障前，请保证上层协议工作正常，否则无法准确定位BFD会话故障原因。

(1) 使用display bfd session命令查看是否存在BFD会话信息。

¡ 如果不存在BFD会话信息，请执行步骤(2)和步骤(3)。

¡ 如果存在BFD会话信息，但“State”显示为“Down”，请执行步骤(4)。

(2) 检查是否存在上层协议联动BFD的配置。

执行display current-configuration命令查看是否存在上层协议联动BFD的配置。例如，OSPF联动BFD的配置如下所示：

interface GigabitEthernet1/0/1

ospf bfd enable

¡ 如果存在上层协议联动BFD的配置，则执行步骤(3)。

¡ 如果不存在上层协议联动BFD的配置，请配置上层协议联动BFD的命令，并确保配置正确。

(3) 检查BFD会话的数量是否超过了设备的BFD会话规格。

执行display bfd session命令，查看“Total sessions”的取值。如果“Total sessions”的取值已达到设备规格，则无法创建新的BFD会话。可通过取消上层协议联动BFD的配置删除一些不必要的BFD会话解决此问题。

如果BFD会话的数量未超规格，请执行步骤(4)。

(4) 检查BFD路由、隧道信息是否正常。

使用BFD检测IP路径的连通性时，请执行如下步骤检查路由信息。

a. 请执行display bfd session命令，查看“DestAddr”对应的IPv4地址或IPv6地址。

b. 请执行display ip routing-table命令或display ipv6 routing-table命令，查看是否存在目的地为“DestAddr”的路由信息。

c. 如果不存在路由信息，请参考“三层技术-IP路由类故障处理”，排除路由故障。

如果存在路由信息，但BFD会话无法Up，请执行步骤(5)。

使用BFD检测LSP、PW、VXLAN隧道、MPLS TE隧道、SRLSP、SRv6 TE Policy时，请参考各模块的故障处理手册，检查隧道状态是否正常。如果隧道状态不正常，请排除隧道故障。如果隧道状态正常，但BFD会话无法UP，请执行步骤(5)。

(5) 检查BFD发包是否正常。

反复执行display bfd session verbose命令，查看“Tx count”取值的变化。“Tx count”字段表示发送的报文数，如果该字段的取值一直为0，说明BFD发包不正常。请执行如下步骤检查BFD发包情况。

a. 请执行display current-configuration configuration bfd-static-session命令检查静态BFD会话监视的接口。例如，如下显示信息中track-interface后面的接口即为静态BFD会话监视的接口。

<Sysname> display current-configuration configuration bfd-static-session

bfd static chris peer-ipv6 1::2 source-ipv6 1::1 discriminator local 1000 remote 1010 track-interface GigabitEthernet1/0/2

b. 请执行display interface interface-type interface-number命令查看接口的运行状态。如果“Current”或“Line protocol state”字段的取值不是UP，请排除接口故障。如果接口的运行状态正常，请执行步骤c。

c. 请执行display bfd session命令，查看“Init mode”的取值。“Init mode”字段表示BFD的运行模式，当“Init mode”取值为“Passive”时，表示BFD运行模式为被动模式；当“Init mode”取值为“Active”时，表示BFD运行模式为主动模式。对于工作在被动（Passive）模式的节点，只有收到工作在主动（Active）模式的节点发送过来的BFD控制报文后，才会发送BFD报文。

如果工作在主动（Active）模式的节点的“Tx count”字段取值一直在增长，说明该节点可以正常发送BFD报文。这种情况下，请执行步骤(6)，检查工作在被动（Passive）模式的节点能否正常收到BFD报文。

d. 上述情况外的其他情况导致的BFD发包不正常，请执行步骤(8)。

(6) 检查BFD收包是否正常。

在BFD会话的一端反复执行display bfd session verbose命令，查看“Rx count”字段的取值，即查看接收的报文数。

¡ “Rx count”计数一直为0，请检查BFD会话对端发包是否正常。如果BFD会话对端发包不正常，请排除对端发包故障。

如果BFD会话对端发包正常，请在本端执行display system internal bfd packet statistics命令查看“The detailed discarded packet statistics”中是否存在丢包数据。如果存在丢包，请根据具体的丢包原因排除故障。如果无法排除故障或不存在丢包，请执行步骤(8)。

¡ “Rx count”计数有增加，且BFD会话状态能够变为Init，说明本端能够收到BFD报文。此时，请在BFD会话的对端反复执行display bfd session verbose命令，查看“Rx count”字段的取值。

- BFD会话对端的“Rx count”计数一直为0，但本端发包正常，说明BFD会话的另一端收包不正常，这种情况会导致BFD会话的对端一直发送状态为Down的BFD控制报文，导致本端BFD会话无法Up。请在BFD会话对端执行display system internal bfd packet statistics命令查看“The detailed discarded packet statistics”中是否存在丢包数据。如果存在丢包，请根据具体的丢包原因排除故障。如果无法排除故障或不存在丢包，请执行步骤(8)。

- 对于本端发包不正常导致BFD会话对端的“Rx count”计数一直为0的情况，请排除本端发包故障。

对于两端发包正常，但一端无法收到报文的情况，请执行步骤(7)。

(7) 检查转发是否正常。

使用ping工具检查BFD会话之间的链路是否能够正常转发报文。对于不同的链路类型，需要使用不同的ping工具，具体如表18所示。

表18 不同的链路类型使用的ping工具

链路类型	Ping工具
IP链路	IP Ping工具。即执行ping ip命令或行ping ipv6命令检查指定IPv4地址或IPv6地址是否可达
LSP隧道	MPLS Ping工具。即执行ping mpls ipv4命令检测LSP隧道的连通性
MPLS TE隧道	MPLS Ping工具。即执行ping mpls te命令检测MPLS TE隧道的连通性
PW	MPLS Ping工具。即执行ping mpls pw命令检测PW隧道的连通性
SRv6 TE Policy	SRv6 TE Policy Ping工具。即执行ping srv6-te policy命令检测SRv6转发路径的连通性

¡ 如果ping不通，请参见“Ping和Tracert—Ping不通”故障手册、“MPLS类”故障处理手册和“Segment Routing类故障处理”排除隧道故障。

¡ 如果能ping通，请执行步骤(8)。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

20.1.2 BFD会话震荡

1. 故障描述

当链路不稳定时，命令行界面可能会频繁输出BFD会话DOWN的日志信息。例如：

%Jul 28 16:03:50:856 2022 H3C BFD/4/BFD_CHANGE_FSM: Sess[192.168.24.4/192.168.24.2, LD/RD:33793/33793, Interface:GE1/0/1, SessType:Ctrl, LinkType:INET], Ver:1, Sta: UP->DOWN, Diag: 7 (Administratively Down)

2. 常见原因

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

· 物理链路故障。

· 上层协议故障。

· 硬件故障。

3. 故障分析

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

(1) 根据具体打印的BFD日志，初步判断问题故障原因。

(2) 现场检查单板硬件、物理链路、上层协议状态、路由是否可达、隧道是否正确建立等问题。

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

图167 BFD会话震荡的故障诊断流程图

4. 处理步骤

· 过多的调试信息的输出会影响系统的运行效率，建议仅在进行网络故障诊断时根据需要打开某个功能模块的调试开关，不要在系统正常运行时打开多个功能模块的调试开关，以免导致设备CPU利用率上升，影响设备正常运行。

· 请及时保存以下步骤的执行结果，以便在故障暂时无法解决时，可快速地将历史信息及时反馈给技术支持人员。

BFD在两台网络设备上建立会话，用来检测网络设备间的双向转发路径，为上层应用服务。BFD本身并没有发现机制，而是靠被服务的上层协议通知来建立会话。上层协议在建立新的邻居关系后，将邻居的参数及检测参数（包括目的地址和源地址等）通告给BFD；BFD根据收到的参数建立BFD会话。会话建立后会周期性地快速发送BFD报文，如果在检测时间内没有收到BFD报文，则认为该双向转发路径发生了故障，并将故障信息通知给该会话所服务的上层应用，由上层应用采取相应的措施。因此，在排除BFD会话震荡的故障前，请保证上层协议工作正常，否则无法准确定位BFD会话故障原因。

(1) 确认BFD会话状态是否从Init变为Down。

如果命令行界面输出如下日志信息，说明BFD会话状态从Init变为Down。

BFD/4/BFD_CHANGE_FSM: Sess[20.0.4.2/20.0.4.1,LD/RD:533/532, Interface:Vlan204, SessType:Ctrl, LinkType:INET], Ver.1, Sta: INIT->DOWN, Diag: 1 (Control Detection Time Expired).

a. 检查BFD会话检测的链路是否能够正常转发报文。

使用ping工具检查BFD会话之间的链路是否能够正常转发报文。对于不同的链路类型，需要使用不同的ping工具，具体如表19所示。

表19 不同的链路类型使用的ping工具

链路类型	Ping工具
IP链路	IP Ping工具。即执行ping ip命令或行ping ipv6命令检查指定IPv4地址或IPv6地址是否可达
LSP隧道	MPLS Ping工具。即执行ping mpls ipv4命令检测LSP隧道的连通性
MPLS TE隧道	MPLS Ping工具。即执行ping mpls te命令检测MPLS TE隧道的连通性
PW	MPLS Ping工具。即执行ping mpls pw命令检测PW隧道的连通性
SRv6 TE Policy	SRv6 TE Policy Ping工具。即执行ping srv6-te policy命令检测SRv6转发路径的连通性

- 如果ping不通，请参见“Ping和Tracert—Ping不通”故障手册、“MPLS类”故障处理手册和“Segment Routing类故障处理”排除隧道故障。

- 如果能ping通，请执行步骤b。

b. 检查本端接收BFD报文的情况。

执行debugging bfd packet receive命令打开BFD接收报文的调试信息开关。

- 如果调试信息中“Sta”字段取值为1，或者未打印调试信息，则说明本端收到状态为Down的报文或者收不到BFD报文。对于这种情况，请执行步骤c。

- 如果调试信息中“Sta”字段取值为2或3，则说明本端收到状态为Init或者Up的报文，但本端BFD会话无法UP。对于这种情况，请执行步骤(4)。

c. 请参考“BFD会话无法建立故障处理”检查对端接收BFD报文的情况。

- 如果收不到BFD报文，请参考“BFD会话无法建立故障处理”排除BFD报文接收故障。

- 如果能收到BFD报文，请执行display system internal bfd packet statistics命令查看“The detailed discarded packet statistics”中显示的丢包原因，并根据具体的丢包原因排除故障。如果无法排除故障或不存在丢包，请执行步骤(4)。

(2) 确认BFD会话状态是否从Up变为Down。

命令行界面输出如下日志信息，说明BFD会话状态从Up变为Down。

BFD/4/BFD_CHANGE_FSM: Sess[20.0.4.2/20.0.4.1,LD/RD:533/532, Interface:Vlan204, SessType:Ctrl, LinkType:INET], Ver.1, Sta: UP->DOWN, Diag: 1 (Control Detection Time Expired).

BFD会话状态从Up变为Down的常见原因为会话协商阶段出现问题。此时可以根据BFD系统日志信息中“Diag”字段的取值辅助判断故障原因。

表20 “Diag”字段的不同取值对应的诊断信息

“Diag”字段取值	诊断信息
1 (Control Detection Time Expired)	表示Ctrl会话本端检测时间超时，即在检测时间内未收到对端发送过来的报文
2 (Echo Function Failed)	表示Echo会话检测时间超时，即在检测时间内未收到对端报文
3 (Neighbor Signaled Session Down)	对端通知本端BFD会话DOWN

“Diag”字段取值为1的处理步骤如下：

a. 首先删除上层协议联动BFD的配置，然后根据链路类型选择合适的工具检测链路连通性。

- 如果链路震荡，请排除链路震荡问题。

- 如果链路正常，且重新配置上层协议联动BFD的命令后，BFD会话仍然震荡，请执行步骤(4)。

b. 检查本端接收BFD报文的情况。

请参考“BFD会话无法建立故障处理”检查本端接收BFD报文的情况。

- 如果本端能够收到报文，但是存在丢包情况，请执行display system internal bfd packet statistics命令查看“The detailed discarded packet statistics”中显示的丢包原因，并根据具体的丢包原因排除故障。如果无法排除故障或不存在丢包，请执行步骤(4)。

- 如果本端无法收到报文，请执行步骤(4)。

“Diag”字段取值为2的处理步骤如下：

¡ 如果使用BFD检测单跳IP链路，请在对端ping本端echo会话的源地址。

- 如果ping不通，说明链路故障，请排除链路故障。

- 如果能ping通，请执行步骤(4)。

¡ 如果使用BFD检测MPLS隧道，由于本端通过MPLS隧道发送BFD echo报文，对端通过IP链路转发收到的BFD echo报文。这种情况下，请检查本端MPLS隧道和对端转发BFD echo报文的IP链路的连通性。

- 如果MPLS隧道或IP链路故障，请排除隧道故障或IP链路故障。

- 如果MPLS隧道以及IP链路正常，请执行步骤(4)。

¡ 如果使用BFD检测SRv6隧道，由于本地通过SRv6隧道发送BFD echo报文，对端通过IP链路转发收到的BFD echo报文。这种情况下，请检查本端SRv6隧道和对端转发BFD echo报文的IP链路的连通性。

- 如果SRv6隧道或IP链路故障，请排除隧道故障或IP链路故障。

- 如果SRv6隧道以及IP链路正常，请执行步骤(4)。

¡ 如果设备配置了uRPF功能，会将对端转发回来的echo报文丢弃。这种情况下，请执行display ip urpf命令检查uRPF是否引用了允许源IP为echo会话源地址通过的ACL规则。此配置用于抑制uRPF丢弃匹配ACL规则的报文。

- 如果uRPF未引用允许源IP为echo会话源地址通过的ACL规则，请通过ip urpf命令修改配置。

- 如果uRPF引用了允许源IP为echo会话源地址通过的ACL规则，请执行步骤(4)。

“Diag”字段取值为3的处理步骤与“Diag”字段取值为1的处理步骤相同。

(3) 确认BFD会话状态是否变为Administratively Down。

命令行界面输出如下日志信息，说明BFD会话状态变为Administratively Down。

BFD/5/BFD_CHANGE_SESS: Sess[17.1.1.2/17.1.1.1, LD/RD:1537/1537, Interface:GE1/0/1, SessType:Ctrl, LinkType:INET], Ver:1, Sta: Deleted, Diag: 7 (Administratively Down)

此情况一般是上层协议故障，间接导致BFD震荡。首先删除上层协议创建BFD会话的配置，观察上层协议是否稳定。如果上层协议震荡，请参考“三层技术-IP路由类故障处理”、“MPLS类故障处理”、“Segment Routing类故障处理”排除上层协议故障。

如果上层协议稳定，但是BFD会话无法UP，请执行步骤(4)。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

21 网络管理和监控类故障处理

21.1 NETCONF故障处理

21.1.1 SOAP方式登录失败

1. 故障描述

设备作为NETCONF服务器，用户使用NETCONF over SOAP客户端登录设备失败。

2. 常见原因

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

· SOAP客户端与设备之间路由不通，无法建立TCP连接。

· 设备未开启NETCONF over SOAP服务器功能。

· 服务器上配置了对客户端的访问控制，但客户端的IP地址不在访问控制的permit规则内。

· 本地用户未配置授权HTTP/HTTPS服务。

· 本地用户认证方式配置不正确。

· HTTP/HTTPS登录用户数达到允许用户数的上限。

3. 故障分析

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

图168 SOAP方式登录失败的故障诊断流程图

4. 处理步骤

(1) 检查物理链路是否存在故障。

可以通过Telnet登录设备（用户角色名为network-admin），在设备上尝试能否ping通NETCONF客户端的IP地址。如果不能ping通，在设备上执行display ip routing-table命令或者display route-static routing-table命令查看去往客户端的路由出接口，再执行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命令打开关闭的接口。如果Current state显示为DOWN，则检查接口的物理连线是否正确。

b. 如果设备和客户端之间存在其他设备，按上述方法逐跳检查和修复各设备连接的物理接口状态。

(2) 通过display netconf service命令检查NETCONF over SOAP功能是否开启。

<Sysname> display netconf service

NETCONF over SOAP over HTTP: Disabled (port 80)

NETCONF over SOAP over HTTPS: Disabled (port 832)

NETCONF over SSH: Disabled (port 830)

NETCONF over Telnet: Enabled

NETCONF over Console: Enabled

...

当NETCONF over SOAP over HTTP或NETCONF over SOAP over HTTPS字段值为Disabled时，请在系统视图下执行netconf soap http enable、netconf soap https enable命令开启基于HTTP/HTTPS的NETCONF over SOAP功能。

(3) 检查是否设置了对客户端IP地址的ACL访问控制。

<Sysname> display current-configuration | begin netconf

netconf soap http enable

netconf soap https enable

netconf soap http acl 2000

[Sysname] acl basic 2000

[Sysname-acl-ipv4-basic-2000] display this

acl basic 2000

rule 5 permit source 192.168.4.10 0

rule 10 permit source 192.168.4.15 0

...

如果存在netconf soap { http | https } acl命令配置，请按需选择执行以下操作：

¡ 确保客户端的IP地址在相关ACL的rule命令允许的IP地址列表中。

¡ 通过执行undo netconf soap { http | https } acl，使NETCONF over SOAP不再关联ACL。

(4) 使用本地认证时，检查客户端对应的本地用户是否可以使用HTTP/HTTPS服务。

进入本地用户视图，执行display this命令，确保配置了service-type http https。

<Sysname> system-view

[Sysname] local-user test

[Sysname-luser-manage-test] display this

local-user test class manage

service-type http https

authorization-attribute user-role network-operator

(5) 使用本地认证时，通过display domain命令检查用户认证域下的认证、授权、计费配置。

<Sysname> display domain

Total 12 domains

Domain: system

Current state: Active

State configuration: Active

Default authentication scheme: Local

Default authorization scheme: Local

Default accounting scheme: Local

...

例如，用户认证域为system时，如果缺省的Authentication、Authorization、Accounting方案不为Local，请执行以下命令，将login用户的认证、授权、计费方案配置为Local。

<Sysname> system-view

[Sysname] domain system

[Sysname-isp-system] authentication login local

[Sysname-isp-system] authorization login local

[Sysname-isp-system] accounting login local

(6) 检查登录到设备的用户数是否达到允许用户数的上限。

在设备上使用display netconf service命令查看Active Sessions字段（当前活跃的NETCONF会话数量），如果该字段值已达到aaa session-limit命令配置的HTTP/HTTPS类型的最大用户连接数，请选择以下一种方式进行调整：

¡ 通过aaa session-limit { http | https } max-sessions命令，配置更大的HTTP/HTTPS用户的连接数上限。

¡ 使用<kill-session>操作，强制释放已建立的部分SOAP类型的NETCONF会话，使新的用户能够上线。

# 查看NETCONF会话信息的命令如下：

<Sysname> display netconf session

Session ID: 1 Session type : SOAP

Username : yy

...

# <kill-session>操作的XML报文示例如下：

<kill-session>

<session-id>1</session-id>

</kill-session>

</rpc>

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

21.1.2 SSH方式登录失败

1. 故障描述

配置工具通过SSH登录设备失败。

2. 处理步骤

请参见“安全类故障处理/SSH客户端登录设备失败”进行定位。

21.2 NTP故障处理

21.2.1 NTP时钟未同步故障处理

1. 故障描述

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

2. 常见原因

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

· NTP配置错误。

· NTP时间同步链路不通。

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

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

3. 故障分析

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

图169 NTP时钟不同步的故障诊断流程图

4. 处理步骤

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

· 客户端/服务器模式

· 对等体模式

· 广播模式

· 组播模式

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

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

a. 查看source字段的取值是否为预期的NTP服务器端的IP地址。如果不是，请执行步骤（2）修改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. 告警与日志

21.3 Ping和Tracert故障处理

21.3.1 Ping不通

1. 故障描述

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

2. 常见原因

存在三种故障情形：

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

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

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

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

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

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

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

· 存在防攻击配置。

· 硬件故障。

3. 故障分析

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

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

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

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

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

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

图170 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报文到达目的端未被分片时，请在目的端执行带slot参数的display icmp statistics命令来查看ICMP报文统计信息，slot为目的端接收该ICMP报文的接口所在的Slot。

· 当目的端是框式设备或者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. 告警与日志

21.3.2 Tracert不通

1. 故障描述

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

2. 常见原因

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

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

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

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

3. 故障分析

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

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

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

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

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

图171 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. 告警与日志

21.4 RMON故障处理

21.4.1 网管无法接收RMON告警信息

1. 故障描述

网管无法接收RMON告警信息。

2. 常见原因。

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

· 设备与网管之间路由不可达。

· SNMP告警功能配置错误。

· RMON统计表未创建。

· RMON事件表未创建。

· RMON告警表未创建。

· 告警变量配置错误。

3. 故障分析

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

图172 网管无法接收RMON告警的故障诊断流程图

4. 处理步骤

(1) 执行ping命令，检查设备和网管之间是否路由可达。

¡ 如果可以Ping通，说明设备和网管之间路由可达，请执行步骤（2）。

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

(2) 检查SNMP告警功能配置是否正确。

RMON是SNMP功能的扩展，它基于SNMP告警通道发送RMON告警信息。所以，要想收到RMON告警信息，需要先在设备上配置SNMP告警功能，并确保网管可以正常接收SNMP告警信息。

如果在网管侧能收到以下任一SNMP告警信息，请执行步骤（3）；如果网管侧未能收到以下告警信息，请参见“网络管理和监控类故障处理”中的“网管无法收到设备发送的Trap”先定位解决问题。

¡ SNMP周期保活告警信息（如果产品不支持SNMP周期保活告警信息功能，请忽略此步骤）。在设备上开启SNMP功能后，缺省情况下，设备会以60秒为周期生成形如“Notification hh3cPeriodicalTrap(1.3.6.1.4.1.25506.2.38.1.6.3.0.1).”的保活告警信息。

SNMP周期保活告警信息发送参数可通过snmp-agent trap periodical-interval命令配置。

¡ Login、Logout告警信息。您可以通过Telnet登录或者退出登录设备，触发设备自动生成对应的Login、Logout告警信息，来验证网管能否正常收到设备生成的告警信息。

Login告警信息形如：

Notification hh3cLogIn(1.3.6.1.4.1.25506.2.2.1.1.3.0.1) with hh3cTerminalUserName(1.3.6.1.4.1.25506.2.2.1.1.2.1.0)=;hh3cTerminalSource(1.3.6.1.4.1.25506.2.2.1.1.2.2.0)=VTY.

Logout告警信息形如：

Notification hh3cLogOut(1.3.6.1.4.1.25506.2.2.1.1.3.0.2) with hh3cTerminalUserName(1.3.6.1.4.1.25506.2.2.1.1.2.1.0)=;hh3cTerminalSource(1.3.6.1.4.1.25506.2.2.1.1.2.2.0)=VTY.

¡ linkUP、linkDown告警信息。您可以通过在物理状态为UP的接口上执行shutdown、undo shutdown命令，触发设备自动生成对应的linkDown、linkUP告警信息，来验证网管能否正常收到设备生成的告警信息。

linkUP告警信息形如：

Notification linkUp(1.3.6.1.6.3.1.1.5.4) with ifIndex(1.3.6.1.2.1.2.2.1.1.961)=961;ifAdminStatus(1.3.6.1.2.1.2.2.1.7.961)=1;ifOperStatus(1.3.6.1.2.1.2.2.1.8.961)=1.

linkDown告警信息形如：

Notification linkDown(1.3.6.1.6.3.1.1.5.3) with ifIndex(1.3.6.1.2.1.2.2.1.1.961)=961;ifAdminStatus(1.3.6.1.2.1.2.2.1.7.961)=2;ifOperStatus(1.3.6.1.2.1.2.2.1.8.961)=2.

¡ 检查RMON事件表的配置是否正确。

在设备端执行命令display rmon event查看是否配置了RMON事件表。如果事件表为空，请使用命令rmon event创建事件表表项，表项对应的动作中需要包含生成告警信息。

(3) 检查RMON告警表或者RMON扩展告警表的配置是否正确。

在设备端执行命令display rmon alarm查看是否配置了RMON告警表以及监控的变量、触发条件是否与网络规划一致。如果告警表为空，或者监控的变量、触发条件和网络规划不一致（例如，监控变量不存在、监控变量配置错误，或者告警触发条件不可能达到），请在系统视图下使用命令rmon alarm创建、修改告警表表项。

在设备端执行命令display rmon prialarm查看是否配置了RMON扩展告警表以及监控的变量、触发条件是否与网络规划一致。如果告警表为空，或者监控的变量、触发条件和网络规划不一致（例如，监控变量不存在、监控变量配置错误，或者告警触发条件不可能达到），请使用命令rmon prialarm创建、修改扩展告警表表项。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

21.5 SNMP故障处理

21.5.1 SNMP连接失败

1. 故障描述

网管（NMS）通过SNMP协议无法成功连接设备。

2. 常见原因

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

· 网络异常导致报文不可达。

· 配置错误导致认证失败。

· 设备受到SNMP报文攻击，进入SNMP静默模式（仅在设备支持SNMP静默模式的情况下）。

· 网管被列入了SNMP黑名单（仅在设备支持SNMP黑名单的情况下）。

3. 故障分析

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

图173 SNMP无法连接的故障诊断流程图

4. 处理步骤

(1) 执行ping命令，检查设备和网管之间是否路由可达。

¡ 如果可以Ping通，说明设备和网管之间路由可达，请执行步骤（2）。

¡ 如果无法Ping通，请参见“IP故障处理”中的“Ping不通”先解决网络不通问题。待设备和网管之间可以Ping通后，重新建立SNMP连接。如果重新建立SNMP连接后，SNMP连接仍不能成功建立，请执行步骤（2）。

(2) 检查SNMP配置是否正确。

a. 执行display snmp-agent sys-info version命令，查看设备当前使用的SNMP版本号。设备和网管使用的SNMP版本号必须相同。如果不同，需使用snmp-agent sys-info version命令修改配置。

b. 如果当前使用的是SNMPv1或SNMPv2c版本，则执行display snmp-agent community命令查看设备上配置的团体信息（包括团体名和使用的ACL等信息）。设备和网管使用的团体名必须相同，且设备上配置的ACL必须允许网管访问设备。否则，需使用snmp-agent community和acl命令修改配置。

c. 如果当前使用的是SNMPv3版本，则执行display snmp-agent usm-user命令查看SNMPv3用户信息（包括用户名和使用的ACL等信息），并执行display snmp-agent group命令查看SNMP组信息（包括认证/加密模式和使用的ACL等信息）。设备和网管使用的用户名必须相同，认证/加密参数必须一致，且设备上配置的ACL必须允许网管访问设备。否则，需使用snmp-agent group、snmp-agent usm-user v3和acl命令修改配置。

(3) 检查设备是否进入SNMP静默状态。

如果1个统计周期内（时长为1分钟）设备收到的SNMP认证失败报文的个数大于等于100，则设备认为受到了SNMP攻击，SNMP模块会进入静默状态（设备会打印日志SNMP agent is now silent），设备将在4～5分钟内不再响应收到的任何SNMP报文。可使用以下方式来解决静默状态下无法建立SNMP连接的问题：

¡ 请等待SNMP静默状态解除后，重新建立SNMP连接。

¡ 如果设备支持关闭SNMP静默功能，可以暂时关闭SNMP静默功能，重新建立SNMP连接。连接建立后，再开启SNMP静默功能。

(4) 检查网管是否被列入SNMP黑名单。

设备上开启SNMP黑名单功能后，如果网管和设备建立SNMP连接失败，则设备会将网管加入SNMP黑名单，第一次、第二次、第三次、第四次连接连续建立失败，网管会依次被锁定8秒、16秒、32秒和5分钟，黑名单中的网管在锁定期内不允许和设备建立SNMP连接。可使用以下方式来解决网管被锁定状态下无法建立SNMP连接的问题：

¡ 请等待网管被解锁后，重新建立SNMP连接。

¡ 暂时关闭SNMP黑名单功能，重新建立SNMP连接。连接建立后，再开启SNMP黑名单功能。

当设备上输出以下任意一种类似的日志时，表示网管被锁定了：

· SNMP_IPLOCK: The source IP was locked for 8 seconds because of the failure of login through SNMP.(SourceIP=192.168.1.0, VPN=0).

· SNMP_IPLOCKSTAT: In the last 5 minutes,2 IP addresses were locked.(IPList=(IP=192.168.73.43),( IP=192.168.73.44)).

当设备上输出以下任意一种类似的日志时，表示网管被解锁了：

· SNMP_IPUNLOCK: The source IP was unlocked(SourceIP=192.168.1.0, VPN=0).

· SNMP_IPUNLOCKSTAT: In the last 5 minutes,2 IP addresses were unlocked.(IPList=(IP=192.168.73.43),( IP=192.168.73.44)).

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

21.5.2 SNMP操作超时

1. 故障描述

网管（NMS）对设备执行SNMP Get和Set操作，网管侧提示操作超时，导致操作失败。

2. 常见原因

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

· SNMP连接中断，导致网管无法访问设备。

· 网络丢包，导致设备没有收到SNMP请求。

· 设备存储介质上的存储空间不足，导致设备无法处理SNMP请求。

· 设备繁忙，正在处理其它业务，导致无法处理SNMP请求。

· SNMP（作为SNMP agent）进程忙，正在处理其它SNMP请求，导致无法对当前SNMP请求做出应答。

· SNMP进程处理当前SNMP请求时发生异常。

3. 故障分析

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

图174 SNMP操作超时的故障诊断流程图

4. 处理步骤

(1) 定位并处理SNMP连接问题。

在网管上查看SNMP连接，如果显示连接超时或者失败，请参照“SNMP连接失败”故障处理章节先定位并处理SNMP连接问题。

(2) 检查网络是否存在丢包。

在网管设备上使用ping –c count host命令，例如将conut参数设置为100，host参数取值为设备的IP地址，查看ping命令执行结果中的packet loss字段取值，判断网络是否存在丢包。

¡ 如果无丢包，请参照步骤（3）继续定位；

¡ 如果有丢包，请参见“IP故障处理”中的“Ping不通”先解决网络不通问题。

-c count：指定ICMP回显请求报文的发送次数，取值范围为1～4294967295，缺省值为5。

(3) 定位并处理设备存储介质上的存储空间不足问题。

在任意视图下执行display memory-threshold命令，如果显示信息中的“Current free-memory state”字段取值中包含Normal字样，表示设备存储介质上的存储空间充足，否则，表示设备存储介质上的存储空间不足，请使用以下方法清理内存。

¡ 使用reset recycle-bin命令清除回收站中的文件。（回收站中的文件也会占用存储介质上的存储空间。）

¡ 使用delete /unreserved file命令一次性彻底删除文件。如果未使用/unreserved参数，删除的文件会保存在回收站中。

设备支持的存储介质可能为Flash等。

(4) 定位并处理设备繁忙问题。

a. 在任意视图下多次重复执行display cpu-usage命令，查看设备CPU利用率是否持续在较高水平。

b. 在任意视图下执行monitor process命令，检查是否存在占用较多CPU的进程。如果某个业务进程占用CPU较多，可以根据业务需要以及设备支持情况，通过重启服务来降低CPU利用率。

(5) 定位SNMP进程问题。

在系统视图下执行probe命令，进入Probe视图，然后多次重复执行display system internal snmp-agent operation in-progress命令查看设备正在处理的SNMP操作的相关信息。

¡ 如果显示信息中的Request ID取值一直在变化，则说明SNMP进程一直在处理不同的请求，当前SNMP进程业务较忙。请降低网管对设备的SNMP操作频率。

¡ 如果显示信息中的Request ID取值一直不变，则说明SNMP进程一直在处理同一请求，SNMP进程处理该请求时超时。可通过以下方法排除故障：

- 依次执行undo snmp-agent命令和snmp-agent命令重启SNMP进程，来尝试排除故障。

- 执行display system internal snmp-agent operation timed-out和display system internal snmp-agent packet timed-out命令确认耗时较多的SNMP操作以及该操作涉及的MIB节点，减少或不要执行类似操作。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

21.5.3 网管无法管理设备

1. 故障描述

网管对设备执行SNMP Set或Get等操作，设备无响应或者提示操作失败。

2. 常见原因

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

· 网管通过SNMP协议无法成功连接设备。

· 网管使用的SNMP版本和MIB节点不匹配。

· 网管没有访问设备的权限。

· 设备上的SNMP进程忙，无法对当前SNMP请求做出应答。

3. 故障分析

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

图175 网管无法管理设备的故障诊断流程图

4. 处理步骤

(1) 检查网管是否可以通过SNMP协议连接设备。

如果网管通过SNMP协议无法成功连接设备，请参照SNMP连接失败故障处理流程进行处理。

(2) 检查网管当前使用的SNMP协议版本是否支持访问该MIB节点。

例如snmpUsmMIB只支持通过SNMPv3协议访问；Integer32、Unsigned32和Counter64数据类型仅SNMPv2c和SNMPv3版本支持。如果网管使用SNMPv1版本和设备相连，网管将无法访问Integer32、Unsigned32和Counter64数据类型的MIB节点。MIB节点的数据类型可通过MIB文件中节点的SYNTAX字段查看。

hh3cDhcpServer2BadNum OBJECT-TYPE

SYNTAX Counter64

MAX-ACCESS read-only

STATUS current

DESCRIPTION

"The total number of the bad packets received."

::= { hh3cDhcpServer2StatGroup 1 }

如果因为版本原因导致网管无法访问MIB节点，请将网管切换到SNMPv2c或SNMPv3版本后，与设备重新建立连接，再执行Get和Set操作。

(3) 检查MIB节点是否支持当前的访问操作。

请根据MIB节点支持的操作类型来访问设备。MIB节点支持的操作类型可通过MIB文件中节点的MAX-ACCESS字段查看。

hh3cDhcpServer2BadNum OBJECT-TYPE

SYNTAX Counter64

MAX-ACCESS read-only

STATUS current

DESCRIPTION

"The total number of the bad packets received."

::= { hh3cDhcpServer2StatGroup 1 }

(4) 检查网管的访问权限。如果访问权限不够，请在设备上修改对应配置，给网管授权。

SNMP支持的访问控制方式包括：

¡ VACM（View-based Access Control Model，基于视图的访问控制模型）：将团体名/用户名与指定的MIB视图进行绑定，可以限制NMS能够访问哪些MIB对象，以及对MIB对象不同的操作权限。通过display current-configuration | include view命令可查看MIB视图相关配置，通过display snmp-agent mib-view命令可查看MIB视图的详细信息。如果配置错误，请修改MIB的相关配置。

设备支持三种MIB视图：

- Read-view：网管只能读取该视图中节点的值。

- Write-view：网管可读和写该视图中节点的值。

- Notify-view：当该视图中包含的Trap节点到达触发条件，网管会收到对应的Trap/Inform报文。

¡ RBAC（Role Based Access Control，基于角色的访问控制）：我司设备通过RBAC进行用户访问权限控制。RBAC的基本思想就是给用户指定角色，这些角色中定义了允许用户操作哪些系统功能以及资源对象。创建SNMPv3用户名时，可以绑定对应的用户角色，通过用户角色下制定的规则，来限制NMS能够访问哪些MIB对象，以及对MIB对象不同的操作权限。如果RBAC权限配置错误，可以通过role name命令进入用户角色视图修改用户角色的规则。

- 拥有network-admin、mdc-admin或level-15用户角色的SNMP团体/用户，可以对所有的MIB对象进行读写操作；

- 拥有network-operator或mdc-operator用户角色的SNMP团体/用户，可以对所有的MIB对象进行读操作；

- 拥有自定义用户角色的SNMP团体/用户，可以对角色规则中指定的MIB对象进行操作。

为了安全起见，只有具有network-admin、mdc-admin或者level-15用户角色的用户登录设备后才能配置SNMP团体、用户或组。请确保登录用户具有network-admin、mdc-admin或者level-15用户角色，以免配置失败。

(5) 检查SNMP进程是否繁忙。

网管对设备执行SNMP Set或Get等操作，设备无响应或者提示操作失败，还可能因为SNMP进程忙，无法对当前SNMP请求做出应答，请参照SNMP操作超时故障处理流程进行处理。

(6) 其它建议

建议网管通过业务接口访问设备，因为业务接口的报文处理能力优于网管口，以便SNMP报文能尽快得到处理。

当有多个NMS同时访问设备，且设备反应缓慢时，建议降低访问频率来减轻设备分担，例如将访问频率设置成大于等于5分钟。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

21.5.4 网管无法收到设备发送的Trap

1. 故障描述

网管无法收到设备发送的Trap报文。

2. 常见原因

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

· 设备和网管之间路由不可达，或者SNMP功能异常，导致无法建立SNMP连接。

· 设备侧和网管侧配置错误，导致网管无法收到设备发送的告警。

· 设备侧业务模块没有产生告警。

· 告警报文丢失，导致网管未收到设备发送的告警。

· SNMP Trap报文过大，超过SNMP模块对Trap报文大小的限制。

3. 故障分析

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

图176 网管无法收到设备发送的Trap的故障诊断流程图

4. 处理步骤

(1) 在系统视图下通过snmp-agent trap log命令开启SNMP告警日志功能。当设备向网管发送告警时，会同时在设备上生成一条日志来记录该Trap。

(2) 通过display logbuffer | include SNMP_NOTIFY命令可以查看设备上是否生成Trap以及生成的Trap详情。

¡ 如果有显示信息，说明设备有Trap生成。请执行步骤(3)。

¡ 如果没有显示信息，说明SNMP模块未向外发送Trap。请执行步骤(4)。

(3) 如果设备生成了Trap，但网管未收到Trap，请参照以下步骤定位。

a. 检查设备是否可以和网管建立SNMP连接。如果连接建立失败，请参见SNMP连接失败故障处理流程解决SNMP连接建立失败问题。

b. 通过display current-configuration | include snmp命令查看snmp-agent target-host trap命令配置是否正确。如果不正确，请修改配置，保证指定的IP地址（VPN参数）和端口号与网管用来接收Trap报文的IP地址（网管所属VPN）和端口号一致，以及设备和网管使用的SNMP协议、安全字一致。

- 如果使用SNMPv1或SNMPv2c版本，则安全字为团体名，请在设备上使用snmp-agent community命令创建SNMP团体。

- 如果使用SNMPv3版本，则安全字为用户名，且设备和网管使用的认证和加密级别必须相同。您需要在设备上使用snmp-agent group和snmp-agent usm-user v3命令创建SNMPv3用户，创建用户时配置的认证和加密模式、认证密码和加密密码（如果用到）必须和网管侧一致，且创建用户时配置的认证和加密级别必须比snmp-agent target-host trap命令中指定的认证和加密级别高。安全级别分为：不认证不加密、认证不加密和认证加密，安全级别依次升高。

- 团体名和用户名可访问的MIB view必须包含对应的MIB告警节点，否则，会因为权限问题导致备不会将Trap报文发送给网管。

c. 执行debugging udp packet命令打开UDP报文的调试信息开关，查看设备发送的Trap报文是否过大。如果业务模块封装的数据较多，可能会导致Trap报文大于设备能发送的SNMP报文的最大长度，这样的Trap报文会被丢弃。此时可结合网络的MTU值以及是否支持分片情况，通过snmp-agent packet max-size命令修改设备能发送的SNMP报文的最大长度。

*Dec 27 22:35:41:203 2021 Sysname SOCKET/7/UDP: -MDC=1;

UDP Output:

UDP Packet: vrf = 0, src = 192.168.56.121/30912, dst = 192.168.56.1/162

len = 79, checksum = 0xd98f

d. 检查网络中是否存在防火墙过滤Trap报文。

如果网络中设置了防火墙，可采用以下措施来解决问题：

- 如果防火墙对报文的源IP进行了过滤，可使用snmp-agent trap source命令修改Trap报文的源IP地址。

- 修改防火墙的规则，放行Trap报文。

e. 检查网络是否不稳定，存在丢包。

如果网络中存在丢包，可采用以下措施来解决问题：

- 检查网络，解决网络丢包问题。

- 配置使用Inform报文发送告警信息。Inform有确认机制，比Trap更可靠。Inform仅SNMPv2c和SNMPv3支持。

(4) SNMP模块未向外发送Trap，请参照以下步骤定位。

a. 通过display snmp-agent trap-list查看业务模块的告警功能是否开启。如未开启，可通过snmp-agent trap enable命令开启。

b. 检查是否达到告警条件。例如接口状态告警会在接口状态发生变化时产生，CPU和内存告警会在CPU、内存的利用率超过阈值时产生等。

- 如未达到告警条件，未产生Trap，属正常现象，无需处理。

- 如果达到告警条件，设备未向外发送Trap，请执行步骤(c)。

c. 使用display snmp-agent trap queue命令查看Trap缓冲区是否被占满。如果Message number大于Queue size，表示Trap缓冲区可能被占满，新生成的Trap报文可能被丢弃。此时，可在系统视图下使用snmp-agent trap queue-size和snmp-agent trap life命令来调整Trap缓冲区性能参数。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

21.6 镜像故障处理

21.6.1 配置流镜像后监控设备收不到镜像报文

1. 故障描述

配置流镜像后，监控设备收不到镜像报文。

2. 常见原因

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

· 目的接口与被监控网络间链路存在故障。

· QoS策略未被应用或者报文未匹配QoS策略。

· 配置流行为时，指定的流镜像接口错误。

3. 故障分析

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

图177 配置流镜像后监控设备收不到镜像报文的故障诊断流程图

4. 处理步骤

(1) 检查镜像源端口能否成功收发报文。

在源设备上执行display interface interface-type interface-number命令，通过显示信息中的“Input(total)”、“Output(total)”字段查看端口收发报文的统计值。

¡ 如果镜像源端口收发的报文的统计信息为0或者不变化，此时设备与被监控的网络之间可能存在链路故障（比如端口Down等），请排查解决。

¡ 如果镜像源端口收发的报文的统计信息不为0且不断变化，请执行步骤(2)。

(2) 检查QoS策略是否被正确应用。

排查匹配待镜像报文的QoS策略是否被应用以及应用的QoS策略是否正确。

在源设备上执行display qos policy interface命令检查镜像源端口上是否应用QoS策略。

¡ 如果未应用，请根据实际组网需要，在镜像源端口上应用QoS策略。

¡ 如果已应用，继续检查QoS策略配置是否正确。在设备上执行display qos policy命令检查QoS策略的配置信息。显示信息中Classifier字段和Behavior字段分别对应配置的流分类和流行为。

- 如果引用的错误，则在系统视图下执行qos policy命令进入对应的QoS策略视图，执行classifier behavior命令来修改QoS策略引用的流分类和流行为。QoS策略的具体的定位修改，请参见“MQC方式配置的QoS策略未生效”。

- 如果引用正确，请执行步骤(3)。

(3) 检查目的端口是否有报文发出。

在目的设备上执行display interface interface-type interface-number命令，通过显示信息中的“Output(total)”字段查看端口发送的报文的统计值。

¡ 如果目的端口发出的报文的统计信息为0或者不变化。在设备上执行display interface interface-type interface-number命令查看显示信息中的“Current state”字段，确认接口的物理状态是否为Up。

- 如果为Up，请执行步骤。

- 如果为Down，请排查处理接口物理Down的问题。

¡ 如果目的端口发出的报文的统计信息不为0且不断变化，请执行步骤(5)。

(4) 检查在目的端口上应用的QoS策略中，流行为视图下配置的流镜像接口（通过mirror-to interface命令配置）是否为目的端口。

¡ 如果不是，请通过mirror-to interface命令将流镜像接口重新配置为正确的接口。

¡ 如果是，请执行步骤(5)。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

21.6.2 配置端口镜像后监控设备收不到镜像报文

1. 故障描述

配置流镜像后，监控设备收不到镜像报文。

2. 常见原因

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

· 镜像源接口与被监控网络间链路存在故障。

· 镜像源端口或镜像目的端口配置错误。

3. 故障分析

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

图178 端口镜像后监控设备收不到镜像报文的故障诊断流程图

4. 处理步骤

(1) 检查镜像源端口能否成功收发报文。

在源设备上执行display interface interface-type interface-number命令，通过显示信息中的“Input(total)”、“Output(total)”字段查看端口收发报文的统计值。

¡ 如果镜像源端口收发的报文的统计信息为0或者不变化，此时设备与被监控的网络之间可能存在链路故障（比如端口Down等），请排查解决。

¡ 如果镜像源端口收发的报文的统计信息不为0且不断变化，请执行步骤(2)。

(2) 检查端口镜像配置是否正确。

在源设备上执行display mirroring-group命令检查端口镜像的配置信息，确认配置的镜像源端口和镜像目的端口是否正确。其中，显示信息中“Mirroring port”字段为镜像源端口、 “Monitor port”字段为镜像目的端口。

¡ 如果正确，请执行步骤(3)。

¡ 如果不正确，请在系统视图下分别执行mirroring-group mirroring-port和mirroring-group monitor-port命令重新将镜像源端口和镜像目的端口配置正确。

(3) 检查目的端口是否有报文发出。

在目的设备上执行display interface interface-type interface-number命令，查看显示信息中的“Output(total)”字段查看端口发送的报文的统计值。

- 如果为Up，请执行步骤。

- 如果为Down，请排查处理接口物理Down的问题。

¡ 如果目的端口发出的报文的统计信息不为0且不断变化，请执行步骤(4)。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

无

22 Telemetry类故障处理

22.1 gRPC故障处理

22.1.1 gRPC采样周期不准确

1. 故障描述

gRPC Dial-out模式向采集器上送的订阅报文中，某些数据源的采样周期与用户配置的采样周期不一致。

2. 常见原因

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

· 部分采样路径无法达到配置的采样周期精度，以自身的最小采样周期进行采样。

· 设备CPU繁忙。

· 数据源对应的采样路径为ifmgr/interfaces、路由类或统计类路径，由于采样数据量庞大，需要使用多个采样周期。

例如route/ipv4routes，当路由表项达到100k时，采样数据量大，设备无法在一个较小的采样周期完成采集工作。

3. 故障分析

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

图179 gRPC采样周期不准确的故障诊断流程图

4. 处理步骤

(1) 通过Probe命令display system internal telemetry查看采样路径是否有最小采样周期。

例如，以下显示结果中，采样路径route/ipv4routes配置的采样周期（Sampling interval，100毫秒）小于生效的采样周期（Effective sampling interval，5秒），说明该采样路径存在最小采样周期（5秒），此时最小采样周期生效。

<Sysname> system-view

[Sysname] probe

[Sysname-probe] display system internal telemetry

Current-time: 2021-12-25T15:51:45.530

--------------------Subscription s----------------------

Subscription mode: non-gNMI

DSCP value: 0

Source address or interface: Not configured

Telemetry data model: 2-layer

Encoding: JSON

Protocol: GRPC

Sensor group: s

Sampling interval: 100 milliseconds

Sampling type Effective sampling interval Sensor path

Periodic 5 seconds route/ipv4routes

Destination group: d

...

[Sysname-probe] quit

(2) 确认设备是否处于CPU繁忙状态。

通过display cpu-usage命令查看CPU利用率。

[Sysname] display cpu-usage

Slot 0 CPU 0 CPU usage:

70% in last 5 seconds

62% in last 1 minute

60% in last 5 minutes

...

如果主设备/全局主用主控板的CPU利用率超过60%，将会影响Telemetry功能的采样效率，导致设备不能在配置的采样周期内完成数据采样。用户可以选择：

¡ 等待CPU利用率降到60%以下。

¡ 减少配置的采样路径数量，以降低CPU利用率。

(3) 确认是否订阅了ifmgr/interfaces、路由类或统计类采样路径。

进入Telemetry视图，通过display this命令查看配置。

[Sysname] telemetry

[Sysname-telemetry] display this

telemetry

sensor-group s

sensor path route/ipv4routes

destination-group d

ipv4-address 192.168.79.155 port 50051

subscription s

sensor-group s sample-interval 5

destination-group d

· 统计类采样路径通常会包含statistics节点，例如ifmgr/statistics。

· 路由类采样路径通常会包含route节点，例如route/ipv4routes。

当存在ifmgr/interfaces、路由类或统计类采样路径时，在网管侧查看设备上送给采集器的相邻的两个订阅报文之间的时间差是否为命令行配置的采样周期的整数倍。

假设，设备上为采样路径route/ipv4routes配置的采样周期为5秒，上送给采集器的两个订阅报文之间的时间差为两个Timestamp（单位为毫秒）字段的差 = ( 1641482427751 – 1641482417751 ) / 1000 = 10秒，是5秒的整数倍。

这就说明，该采样路径的采集数据量过大，需要使用多个配置的采样周期才能上送数据。

Producer-Name: H3C

...

Sensor-Path: route/ipv4routes

Json-Data: {"Notification":{"Timestamp":"1641482417751",...

Producer-Name: H3C

...

Sensor-Path: route/ipv4routes

Json-Data: {"Notification":{"Timestamp":"1641482427751",...

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

¡ 上述步骤的执行结果。

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

热门推荐

热门推荐

H3C服务器

HPE服务器

热门推荐

H3C存储

HPE存储

热门推荐

商用台式机

商用笔记本

商用显示器

配件

热门推荐

热门推荐

智能终端

百业灵犀

技术解决方案

热门推荐

热门推荐

热门推荐

热门推荐

热门推荐

热门推荐

热门推荐

专业安全服务

安全运营服务

热门推荐

热门推荐

热门推荐

热门推荐

热门推荐

热门推荐

热门推荐

热门推荐

热门推荐

热门推荐

热门推荐

热门推荐

热门推荐

热门推荐

热门推荐

热门推荐

热门推荐

热门推荐

公司刊物

加入我们

国家/地区

H3C 交换机通用故障处理手册-6W100

目录

1.2 收集设备运行信息

1.3 故障处理求助方式

3 硬件类故障处理

1. 故障描述

2. 常见原因

3. 故障分析

4. 处理步骤

5. 告警与日志

相关告警

相关日志

1. 故障描述

2. 常见原因

3. 故障分析

4. 处理步骤

5. 告警与日志

相关告警

相关日志

1. 故障描述

2. 常见原因

3. 故障分析

4. 处理步骤

5. 告警与日志

相关告警

相关日志

1. 故障描述

2. 常见原因

3. 故障分析

4. 处理步骤

5. 告警与日志

相关告警

相关日志