设备运行过程中会产生logfile、diagfile日志信息及记录设备运行状态的诊断信息。这些信息存储在主控板的Flash或CF卡中，可以通过FTP、TFTP、USB等方式导出。不同主控板中导出的logfile、diagfile、诊断信息文件请按照一定规则存放，避免不同主控板的运行信息相互混淆，以方便查询。

表1 设备运行信息介绍

分类	文件名	内容
logfile日志	logfileX.log	命令行记录、设备运行中产生的记录信息
diagfile日志	diagfileX.log	设备运行中产生的诊断日志信息，如系统运行到错误流程时的参数值、单板无法启动时的信息、主控板与接口板通信异常时的握手信息。
诊断信息	XXX.gz	系统当前多个功能模块运行的统计信息，包括设备状态、CPU状态、内存状态、配置情况、软件表项、硬件表项等

对于logfile日志和diagfile日志，当日志文件写满，产生新的日志文件时，设备会将旧的日志文件自动压缩成.gz文件。

1.2.1 logfile日志

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

<Sysname> logfile save

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

(2) 查看设备上主用主控板、备用主控板、IRF中主设备/从设备上各主用/备用主控板的日志文件数目和名称。

· 主用主控板logfile日志：

<Sysname> dir cfa0:/logfile/

Directory of cfa0:/logfile

0 -rw- 21863 Jul 11 2013 16:00:37 logfile1.log

1021104 KB total (421552 KB free)

· 备用主控板logfile日志：

<Sysname> dir slot1# cfa0:/logfile/

Directory of slot1# cfa0:/logfile

0 -rw- 21863 Jul 11 2013 16:00:37 logfile1.log

1021104 KB total (421552 KB free)

· IRF备框主控板logfile日志，如备框有两块主控板，则两块都需要检查：

<Sysname> dir chassis2#slot0#cfa0:/logfile/

Directory of chassis2#slot0#cfa0:/logfile

0 -rw- 21863 Jul 11 2013 16:00:37 logfile1.log

1021104 KB total (421552 KB free)

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

1.2.2 diagfile日志

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

· 在设备上收集对应的诊断日志文件。

<Sysname> diagnostic-logfile save

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

(2) 查看设备上主用主控板、备用主控板、IRF中主设备/从设备上各主用/备用主控板的诊断日志文件数目和名称。

· 主用主控板diagfile日志：

<Sysname> dir cfa0:/diagfile/

Directory of cfa0:/diagfile

0 -rw- 161321 Jul 11 2013 16:16:00 diagfile1.log

1021104 KB total (421416 KB free)

· 备用主控板diagfile日志：

<Sysname> dir slot1# cfa0:/diagfile/

Directory of slot1# cfa0:/diagfile

0 -rw- 161321 Jul 11 2013 16:16:00 diagfile1.log

1021104 KB total (421416 KB free)

· IRF各成员设备主控板diagfile日志，如果成员设备有两块主控板，则两块都需要检查：

<Sysname> dir chassis2#slot0#cfa0:/diagfile/

Directory of chassis2#slot0#cfa0:/diagfile

0 -rw- 161321 Jul 11 2013 16:16:00 diagfile1.log

1021104 KB total (421416 KB free)

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

1.2.3 诊断信息

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

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

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

(1) 执行screen-length disable命令，以避免屏幕输出被打断（如果是将诊断信息保存到文件中，则忽略此步骤）。

<Sysname> screen-length disable

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

<Sysname> display diagnostic-information

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

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

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

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

Please input the file name(*.tar.gz)[ cfa0:/diag.tar.gz] : cfa0:/diag.tar.gz

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

Please wait...

Save successfully.

<Sysname> dir cfa0:/

Directory of cfa0:

……

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

……

1021808 KB total (259072 KB free)

· 输入“N”，将诊断信息直接显示在屏幕上。

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

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

===============display alarm===============

No alarm information.

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

===============display boot-loader===============

Software images on slot 0:

Current software images:

cfa0:/BOOT-RXXXX.bin

cfa0:/SYSTEM-RXXXX.bin

Main startup software images:

cfa0:/BOOT-RXXXX.bin

cfa0:/SYSTEM-RXXXX.bin

Backup startup software images:

None

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

===============display counters inbound interface===============

Interface Total (pkts) Broadcast (pkts) Multicast (pkts) Err (pkts)

BAGG1 0 0 0 0

XGE3/1/1 0 0 0 0

XGE3/1/2 2 2 0 0

XGE3/1/3 0 0 0 0

1.2.4 单板启动信息

单板启动阶段的最后32条信息会记录到保留内存，不管单板能否启动，只要不下电就能查看。单板正常启动状态为normal后，在probe视图下，通过display hardware internal boot information current命令行查看。当接口板启动时发生重启且一直重启无法正常启动，就无法通过此命令行查看，此时，单板会在boot阶段将上一次启动前的信息上传到主控板并保存到CF卡的info目录下以供查看。

当接口板无限重启只会保存最开始的2个文件，之后的不再保存以节约空间。可以通过以下步骤进行查看单板启动信息：

(1) 进入CF卡下的info目录可以查看上传的文件。

<Sysname>cd cfa0:/info/

<Sysname>dir

Directory of cfa0:/info

0 -rw- 6952 Jul 07 2016 10:19:24 info_3_0.bin

以上显示信息中3为上传的接口板槽位号，0为序号，如果有多个文件就会依次排序。

(2) 在probe视图下通过命令行display drvplat boot-info-record file就可以查看该单板的启动信息。

<Sysname> system-view

System View: return to User View with Ctrl+Z.

[Sysname] probe

[Sysname-probe] display drvplat boot-info-record file cfa0:/info/info_3_0.bin

Slot 0, CPU 0

Total number of boot info in reserved memory: 32

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

2016/07/07, 09:19:07. NAT GMAC init end [OK]

2016/07/07, 09:18:48. IBC phase2 init end [OK]

2016/07/07, 09:18:48. Contorl channel count record init [OK]

2016/07/07, 09:18:45. BFD global data init [OK]

2016/07/07, 09:18:45. FWD phase2 init end [OK]

2016/07/07, 09:18:45. FWD init phase2 pe traffic enable pass, init phase2 end.

2016/07/07, 09:18:44. Get clock global config succeed. [OK]

2016/07/07, 09:18:44. BRAS task init [OK]

2016/07/07, 09:18:44. Mpls phase2 init [OK]

1.3 故障处理求助方式

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

用户支持邮箱：[email protected]

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

2 硬件类故障处理

关于设备各部件指示灯的详细情况，请参见《H3C SR8800-F路由器硬件描述》。

2.1 系统故障

2.1.1 终端无显示或显示乱码

1. 故障描述

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

2. 常见原因

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

· 电源工作异常。

· 主控板工作异常。

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

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

· 配置电缆故障。

3. 故障分析

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

图2-1 故障诊断流程图

4. 处理步骤

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

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

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

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

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

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

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

(5) 更换配置电缆。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

2.1.2 设备异常重启

1. 故障描述

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

2. 常见原因

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

3. 故障分析

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

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

4. 处理步骤

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

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

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

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

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

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

2.1.3 温度异常告警

1. 故障描述

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

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

2. 常见原因

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

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

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

· 设备防尘网积灰过多。

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

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

3. 故障分析

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

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

4. 处理步骤

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

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

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

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

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

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

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

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

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

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

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

2.1.4 内存异常告警

1. 故障描述

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

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

2. 常见原因

本类故障的常见原因主要是由于内存泄露。

3. 故障分析

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

图2-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. 告警与日志

2.1.5 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. 故障分析

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

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

4. 处理步骤

(1) 确认设备是否受到网络攻击。

现网中，导致设备CPU占用率高最常见的原因是网络攻击。攻击者发起大量非正常网络交互对设备产生冲击，例如短时间内发送大量TCP连接建立请求报文或者ICMP请求报文，设备忙于处理这些攻击报文，导致CPU占用率高，从而影响设备正常业务的运行。

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

¡ 如果受到了网络攻击，则先解决网络攻击问题。

¡ 如果未受到网络攻击，则执行步骤(2)。

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

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

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

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

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

STP/6/STP_NOTIFIED_TC: Instance 0's port Ten-GigabitEthernet3/1/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) Multic

ast(pps)

MGE0/0/0 0.01 15 --

XGE3/1/1 0.00 0 0

XGE3/1/2 0.00 0 0

XGE3/1/3 0.00 0 0

XGE3/1/4 0.00 0 0

Vlan1 -- 0 --

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) Er

r(pkt)

MGE0/0/0 3084773 1298212 1736440

RAGG1 0 0 0

RAGG10 0 0 0

RAGG121 0 0 0

XGE3/1/1 0 0 0

XGE3/1/2 0 0 0

XGE3/1/3 0 0 0

XGE3/1/4 0 0 0

Vlan1 21318 -- --

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命令配置流量控制功能。

- 使用QoS策略针对组播、广播和未知单播报文进行限速。

¡ 如未出现环，请执行步骤(4)。

(4) 确认是否配置了流统计和采样功能，以及配置的参数是否合适。

当设备上配置了NetStream等网络流量监控功能后，设备会对网络流量进行统计分析。如果网络流量较高，可能会导致CPU占用率偏高。此时，可进行以下处理：

¡ 配置过滤条件来精确匹配流量，仅统计分析用户关心的流量。

¡ 配置采样器，调整采样比例，使得NetStream收集到的统计信息既能基本反映整个网络的状况，又能避免统计报文过多影响设备转发性能。

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

某些异常情况下，例如，设备受到攻击、运行中发生了错误、端口频繁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 CPU EMERG ALERT CRIT ERROR WARN NOTIF INFO DEBUG

0 0 0 0 0 70 73 69 300 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)。

(6) 收集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业务模块的问题。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

2.1.6 资源不足

1. 故障描述

资源使用超规格时会打印包含以下内容的日志信息和告警信息：

The resources are insufficient.

No enough resource!

Not enough resources are available to complete the operation.

典型的系统资源包括：

· ACL

· FIB

· MAC

· MPLS LSP

· 组播

· ARP

2. 故障处理步骤

# ACL资源不足。

下列这些特性会占用ACL资源：

· QoS策略

· Packet filter

· 策略路由

· IPoE

· URPF

· DHCP Snooping

· LLDP

(1) 通过display qos-acl resource命令查看单板ACL资源使用情况，其中Total表示总的资源数，Configured表示使用资源数，Remaining表示剩余的资源数，Usage表示使用的百分比。

<Sysname> display qos-acl resource slot 3

Interfaces: XGE3/3/1 to XGE3/3/8, Pos3/4/1 to Pos3/4/4

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

Type Total Reserved Configured Remaining Usage

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

IPv4Acl 65536 0 2 65534 0%

IPv6Acl 16384 0 0 16384 0%

Car&Cnt 32768 0 1 32767 0%

InBRASCar 65536 0 0 65536 0%

OutBRASCar 65536 0 0 65536 0%

TCPCar 16384 0 0 16384 0%

CarProf 220 0 2 218 0%

Sampler 32768 0 0 32768 0%

(2) 如果ACL资源使用率超过95%，请根据具体情况进行优化，比如删除或合并ACL规则。如果无法优化，请将信息发送给技术支持人员协助分析。

# FIB资源不足。

(3) 使用以下命令行查看FIB表项资源使用情况。

· 对于CSPC-GE16XP4L-E、CSPC-GE24L-E、CSPC-GP24GE8XP2L-E、CSPEX-1104-E和CSPEX-1204单板：

[Sysname-probe] display hardware internal pe table all slot 3

=============================Table Instruction =================================

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

PID: PES Table ID

PTY: PES Table type

KAL: PES Key Align len

RAL: PES Result Align Len

SID: SDK TABLE ID

TableName: SDK Table name

STY: SDK Table type

LOCA: SDK Location

MaxEntry: SDK Max Entries

ES: SDK Entry_size

MID: SDK Moudle ID

CID: SDK DDR CTRL ID

CNAME: SDK DDR CTRL NAME

KSZ: SDK Key Size

RSZ: SDK Result Size

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

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

PID PTY KAL RAL SID TABLENAME STY LOCA MAXENTRY ES MID CID

CNAME KSZ RSZ

0 TAB 4 16 1 ipct TBL REG 256 16 0 255

NULL 0 16

1 TAB 4 16 2 remote-ipct TBL DDR 131072 16 72 18

DDR7 0 16

2 TAB 4 4 3 v4_vrrp BMP BRAM 32768 1 0 255

NULL 0 1

3 TAB 4 4 4 v6_vrrp BMP BRAM 32768 1 0 255

NULL 0 1

4 TAB 4 4 5 ipv4-vrrp-e BMP BRAM 524288 1 0 255

NULL 0 1

5 TAB 4 4 6 ipv6-vrrp-e BMP BRAM 524288 1 0 255

NULL 0 1

6 HAS 8 32 144 rpr-mac-hash DLH DDR 147456 32 99 30

DDR2 6 32

8 rpr-mac(Dhash Res) TBL DDR 131072 32 100 30

DDR2 0 32

7 HAS 8 8 145 rpr-node-mac-hash DSH DDR 131072 16 80 24

DDR6_0 8 16

9 rpr-node-mac(Dhash Res) TBL DDR 65536 16 81 24

DDR6_0 0 16

8 TAB 4 32 10 inlif TBL DDR 1048576 32 88 27

NULL 0 32

9 HAS 4 32 132 remote-inlif-hash SHA DDR 163840 32 66 16

DDR0_0 4 3

10 CSD 8 32 129 Ve-QinQ-inlif-hash SHA DDR 294912 32 72 18

DDR7 6 3

11 TAB 4 32 12 Ve-QinQ-inlif(CSD Res) TBL DDR 262144 32 88 27

NULL 0 32

12 LPM 8 8 118 ipv4-lpm LP4 CPU 0 8 0 255

NULL 0 8

13 TAB 4 16 119 ftn TBL DDR 4194304 16 64 16

DDR0_0 0 16

IPv4表项总的资源为3000000条。使用display hardware internal pe table命令查找ftn对应的表项的PID，再使用display hardware internal pe table entrycount命令可以查看该表项实际占用的IPv4表项资源。

[Sysname-probe] display hardware internal pe table 13 entrycount slot 3

There are 16 entries!

· 对于CSPEX-1304S、CSPEX-1404S、CSPEX-1504S单板：

TCAM模式：

[Sysname-probe] display hardware internal exttcam nfs db-info ipv4 slot 5 chip 0

Database name: IPV4

Database capacity: 4194304

Current entry count: 148052

Start index: 0x0

End index: 0x5fffff

Key width Type: 0

Key real size in bytes: 6

Key size defined by NPS: 8

Res size defined by NPS: 32

Current entry count表示TCAM芯片中实际占用的IPv4表项资源，Database capacity表示TCAM芯片中IPv4表项总的资源。

(4) 如果FIB资源使用率超过95%，请搜集信息并发送给技术支持人员协助分析。

# MAC资源不足。

MAC资源不足在大型二层网络中容易出现，MAC地址过多，老的MAC还没有老化，导致新的MAC地址学习不到。

<Sysname> display mac-address count

49 mac address(es) found

建议：

· 减小学习到的MAC的老化时间，便于MAC地址快速老化。

· 优化组网，根据不同的业务或部门等划分VLAN，不同VLAN间采用三层互联。

# MPLS LSP资源不足。

(5) 查看MPLS LSP资源使用情况。

<Sysname> display mpls lsp statistics

LSP Type Ingress/Transit/Egress Active

Static LSP 0/0/0 0/0/0

Static CRLSP 0/0/0 0/0/0

LDP LSP 0/0/1 0/0/1

RSVP CRLSP 0/0/0 0/0/0

BGP LSP 0/0/0 0/0/0

Local LSP 0/0/0 0/0/0

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

Total 0/0/1 0/0/1

(6) 如MPLS LSP资源使用过多导致资源不足，请搜集信息并发送给技术支持人员协助分析。

# 其他系统资源不足。

其他系统资源的使用情况需要专业技术支持人员进行分析，请联系技术支持处理。

2.2 电源故障

2.2.1 电源模块状态异常

1. 故障描述

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

2. 常见原因

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

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

· 电源模块安装不到位。

· 电源线缆没有插牢。

· 电源模块温度过高。

· 电源模块故障。

3. 故障分析

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

图2-6 故障诊断流程图

4. 处理步骤

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

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

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

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

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

<Sysname> display power

Power 0 State: Normal

Power 1 State: Absent

Power 2 State: Absent

Power 3 State: Absent

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

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

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

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

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

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

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

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

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

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

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

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

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

2.3 风扇故障

2.3.1 风扇模块状态异常

1. 故障描述

风扇模块状态指示灯异常或者风扇框运行中上报Fault。

2. 常见原因

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

· 风扇未插紧。

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

· 风扇硬件故障。

3. 故障分析

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

图2-7 故障诊断流程图

4. 处理步骤

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

(2) 查看风扇框状态。

使用display fan命令查看风扇框状态。

<Sysname> display fan

Fan Frame 0 State: Normal

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

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

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

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

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

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

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

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

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

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

2.4 单板故障

2.4.1 单板状态异常

1. 故障描述

· 单板状态指示灯出现如下情况，则有可能是单板异常：

¡ 对于CSR07SRPUB1、CSR07SRPUC1、CSR07SRPUD3主控板，单板状态指示灯RUN和ALM灯同时闪烁或者常亮。

¡ 对于CSR07SRPUA1主控板，单板状态指示灯RUN/ALM状态为红灯常亮或红灯闪烁。

¡ 对于CSR07MPUA1主控板，主控板状态指示灯RUN灯灭、业务板状态指示灯RUN和ALM灯同时常亮。

· 通过display device命令查看设备，如果发现单板状态出现Fault、Off、Offline、Illegal，或该槽位存在单板但状态却是Absent的，说明单板可能出现故障。

<Sysname> display device

Slot No. Brd Type Brd Status Software Version

0 CSR07SRPUA1 Standby SR8800FS-CMW710-RXXXX

1 CSR07SRPUA1 Master SR8800FS-CMW710-RXXXX

2 CSPC-XP8LB Normal SR8800FS-CMW710-RXXXX

3 NONE Absent NONE

4 NONE Absent NONE

5 NONE Absent NONE

6 NONE Absent NONE

7 CMPE-1104 Normal SR8800FS-CMW710-RXXXX

Sub1 MIC-GP8L Normal

Sub2 MIC-SP4L Normal

Sub3 NONE Absent

Sub4 MIC-GP4L Normal

· 单板重启异常

单板出现异常重启或不断重启等故障时，可以通过logfile日志、display version、display kernel reboot查看设备启动后运行时间来确认单板有没有出现过重启，出现过重启的单板运行时间会明显短于设备上其他单板。

2. 常见原因

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

· 单板安装不到位。

· 单板损坏。

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

· 电源模块故障。

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

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

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

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

3. 故障分析

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

图2-8 单板状态异常故障诊断流程图

4. 故障处理步骤

· 单板状态Absent

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

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

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

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

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

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

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

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

(6) 如果单板是主控板，连上Console口配置电缆后，使用尖细工具（如笔尖）按单板上的系统复位键（RESET）或通过reboot slot slotid force命令重启单板，查看配置终端上的显示信息是否恢复正常，同时查看单板状态指示灯是否恢复正常。

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

(8) 如果单板是业务板，请先确保主控板处于正常工作状态。

(9) 如确认为单板故障，请更换单板并将故障信息发送技术支持人员分析。

· 单板状态Power-off。

(10) 确认用户有无通过debug sysm power-down命令对单板执行下电操作。如果是用户操作导致，请通过debug sysm power-up命令对单板重新上电。

(11) 确认设备环境是否存在过温下电，通过Probe视图下命令display power-info查看是否存在环境温度过高，单板被下电的记录。

(12) 如果确认是过温下电，请排查环境单板槽位是否插满，如果单板槽位已插满单板或者挡风板，请通过命令display fan-speed确认风扇工作是否正常，如不正常，请将故障信息发送技术支持人员分析。

(13) 否则，单板存在电源故障，请更换单板，收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

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

· 单板状态Fault。

(14) 等待一段时间（大约10分钟左右）确认下单板是一直Fault还是Normal后又再次重启。如单板是Normal后又自动重启，请将故障信息发送技术支持人员分析。

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

readed value is 55555555 , expected value is aaaaaaaa

DRAM test fails at: 080ffff8

Fatal error! Please reboot the board.

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

(17) 如确认为单板故障，请更换单板并将故障信息发送技术支持人员分析。

· 单板重启异常

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

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

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

<Sysname> display version

H3C Comware Software, Version 7.1.075, Release XXXX

H3C SR8808-F uptime is 0 weeks, 0 days, 4 hours, 24 minutes

Last reboot reason : Cold reboot……

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

(21) 确认日志中重启时有无出现类似“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.”提示信息，这种情况是业务板、备用主控板与主用主控板的设备标识不一致，请联系技术支持人员更换。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

2.4.2 主控板无法启动

1. 故障描述

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

2. 常见原因

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

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

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

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

· APP软件版本丢失、校验失败、与硬件不匹配。

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

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

3. 故障分析

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

图2-9 原主控板无法启动故障诊断流程图

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

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

4. 处理步骤

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

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

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

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

	主控板运行灯状态	指示灯含义
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

The Extended BootWare is self-decompressing.............Done.

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

* *

* BootWare, Version 1.50 *

* *

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

Compiled Date : May 11 2021

CPU Type : XLP308

CPU Clock Speed : 1200MHz

Memory Type : DDR3 SDRAM

Memory Size : 4096MB

Memory Speed : 667MHz

BootWare Size : 1536KB

Flash Size : 500MB

cfa0 Size : 4002MB

BASIC CPLD Version : 1.0

EXTENDED CPLD Version : 1.0

PCB Version : Ver.A

BootWare Validating...

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

可能是内存或CPU本身有问题。对于mpuc，可以将内存拔掉，查看启动后是否有如下信息：

RAM initialization failed

Fatal error! Please reboot the board.

若没有则表示在初始化内存前已死掉，可能是CPU问题或焊接问题，请联系H3C技术服务支持。若有打印，则说明初始化内存时出现问题，可尝试更换内存条。

c. 情况3：没有任何输出信息

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

readed value is 75555555 , expected value is 55555555

DRAM test fails at: 5ff80020

Fatal error! Please reboot the board.

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

(3) 查看加载APP是否正常

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

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

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

* *

* BootWare, Version 1.50 *

* *

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

Compiled Date : May 11 2021

CPU Type : XLP308

CPU Clock Speed : 1200MHz

Memory Type : DDR3 SDRAM

Memory Size : 4096MB

Memory Speed : 667MHz

BootWare Size : 1536KB

Flash Size : 500MB

cfa0 Size : 4002MB

BASIC CPLD Version : 1.0

EXTENDED CPLD Version : 1.0

PCB Version : Ver.A

BootWare Validating...

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

Loading the main image files...

Loading file cfa0:/test-SYSTEM-RXXXX.bin........................

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

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

Loading file cfa0:/test-BOOT-RXXXX.bin..........Done.

Image file cfa0:/test-BOOT-RXXXX.bin is self-decompressing......

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

System image is starting...

b. 情况2：APP不存在

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

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

* *

* BootWare, Version 1.50 *

* *

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

Compiled Date : May 11 2021

CPU Type : XLP308

CPU Clock Speed : 1200MHz

Memory Type : DDR3 SDRAM

Memory Size : 4096MB

Memory Speed : 667MHz

BootWare Size : 1536KB

Flash Size : 500MB

cfa0 Size : 4002MB

BASIC CPLD Version : 1.0

EXTENDED CPLD Version : 1.0

PCB Version : Ver.A

BootWare Validating...

Application program does not exist.

Please input BootWare password:

c. 情况3：APP文件CRC错误

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

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

* *

* BootWare, Version 1.50 *

* *

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

Compiled Date : May 11 2021

CPU Type : XLP308

CPU Clock Speed : 1200MHz

Memory Type : DDR3 SDRAM

Memory Size : 4096MB

Memory Speed : 667MHz

BootWare Size : 1536KB

Flash Size : 500MB

cfa0 Size : 4002MB

BASIC CPLD Version : 1.0

EXTENDED CPLD Version : 1.0

PCB Version : Ver.A

BootWare Validating...

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

Loading the main image files...

Loading file cfa0:/ test-SYSTEM-RXXXX.bin........................

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

Something wrong with the file.

(4) 检查APP启动过程

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

Loading the main image files...

Loading file cfa0:/ test-BOOT-RXXXX.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. 告警与日志

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

1. 故障描述

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

2. 常见原因

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

· 启动文件损坏。

· 主控板内存单元损坏。

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

3. 故障分析

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

图2-11 故障诊断流程图

4. 处理步骤

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

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

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

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

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

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

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

2.4.4 主控板启动慢

1. 故障描述

主控板启动时加载较慢，Loading时间较长。

2. 故障处理步骤

(1) 查看存储介质剩余空间

通过dir命令查看设备的存储介质剩余空间大小。如果剩余空间较小，则会影响主控板的加载启动时间。

(2) 查看BootWare版本

需要确认主控板Bootware版本是否已经升级，如果重启前后Bootware版本不一致，将导致启动过程耗时较长。

System is starting...

Press Ctrl+D to access BASIC-BOOTWARE MENU...

Press Ctrl+T to start memory test

Booting Normal Extended BootWare

The Extended BootWare is self-decompressing...........Done.

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

* *

* BootWare, Version 1.45 *

* *

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

Compiled Date : Jun 20 2018

CPU Type : XLP316

CPU Clock Speed : 1200MHz

Memory Type : DDR3 SDRAM

Memory Size : 8192MB

Memory Speed : 667MHz

BootWare Size : 1536KB

Flash Size : 500MB

cfa0 Size : 4002MB

BASIC CPLD Version : 1.0

EXTENDED CPLD Version : 1.0

PCB Version : Ver.A

BootWare Validating...

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

Loading the main image files...

Loading file cfa0:/SYSTEM-R8260P22.bin.......................

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

...........Done.---- 耗时累计7分14秒

Loading file cfa0:/DEVKIT-TEST.bin.......................

.Done.

Loading file cfa0:/BOOT-TEST.bin.........................

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

Extended BootWare Version is not equal,updating? [Y/N]

Updating Extended BootWare.........Done.

Basic BootWare Version is not equal,updating? [Y/N] -------- 这里升级bootware 1.45到1.46版本，然后bootware重启，重新开始加载；

Updating Basic BootWare.........Done.

BootWare updated,System is rebooting now.

System is starting...---- 耗时累计8分50秒

Press Ctrl+D to access BASIC-BOOTWARE MENU...

Press Ctrl+T to start memory test

Booting Normal Extended BootWare

The Extended BootWare is self-decompressing........Done.

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

* *

* BootWare, Version 1.46 *

* *

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

Compiled Date : Oct 19 2018

CPU Type : XLP316

CPU Clock Speed : 1200MHz

Memory Type : DDR3 SDRAM

Memory Size : 8192MB

Memory Speed : 667MHz

BootWare Size : 1536KB

Flash Size : 500MB

cfa0 Size : 4002MB

BASIC CPLD Version : 1.0

EXTENDED CPLD Version : 1.0

PCB Version : Ver.A

BootWare Validating...

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

Loading the main image files...

Loading file cfa0:/SYSTEM-TEST.bin.......................

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

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

Loading file cfa0:/DEVKIT-TEST.bin........................Done.

Loading file cfa0:/BOOT-TEST.bin........................................................Done.

Image file cfa0:/BOOT-TEST.bin is self-decompressing.............................................Done.

System image is starting...

Line con1 is available.

2.4.5 主备倒换故障

1. 故障描述

本类故障常见如下情况：

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

· 主、备倒换异常。

2. 常见原因

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

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

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

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

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

3. 处理步骤

· 对于用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. 如果出现过，请联系技术支持人员。

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

(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

根据显示信息确认：

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

¡ 主用主控板、备用主控板状态是否Stable。

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

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

¡ 上述步骤的执行结果。

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

4. 告警与日志

2.4.6 业务板无法启动

1. 故障描述

业务板无法启动。

2. 常见原因

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

· 供电异常。

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

· 业务板未安装到位。

· 业务板硬件故障。

· 机框槽位硬件故障。

3. 故障分析

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

图2-12 故障诊断流程图

4. 处理步骤

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

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

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

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

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

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

(3) 拔插业务板。

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

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

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

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

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

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

1. 故障描述

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

2. 常见原因

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

· 供电异常。

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

· 业务板硬件故障。

· 机框槽位硬件故障。

3. 故障分析

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

图2-13 故障诊断流程图

4. 处理步骤

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

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

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

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

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

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

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

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

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

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

<Sysname> display logbuffer

%Jan 12 19:13:49:513 2022 H3C DEV/4/BOARD_LOADING: Board in slot 13 is loading software images.

%Jan 12 19:14:01:718 2022 H3C DEV/5/LOAD_FINISHED: Board in slot 13 has finished loading software images.

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

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

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

2.5 端口故障

2.5.1 端口出现CRC错误

1. 故障描述

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

<Sysname> display interface ten-gigabitethernet3/1/1

Ten-GigabitEthernet3/1/1

Current state: DOWN

Line protocol state: DOWN

Description: Ten-GigabitEthernet3/1/1 Interface

Bandwidth: 10000000 kbps

Flow-control is not enabled

Maximum transmission unit: 1500

Allow jumbo frames to pass

Broadcast max-ratio: 100%

Multicast max-ratio: 100%

Unicast max-ratio: 100%

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

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

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

Port priority: 0

Loopback is not set

1000Mbps-speed mode, full-duplex mode

Link speed type is autonegotiation, link duplex type is autonegotiation

The maximum frame length is 9216

Last link flapping: Never

Last clearing of counters: Never

Current system time:2022-04-19 11:44:20

Last time when physical state changed to up:-

Last time when physical state changed to down:2022-04-19 09:25:24

Traffic statistic: Not include Inter-frame Gaps and Preambles

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. 故障分析

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

图2-14 故障诊断流程图

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) 如果故障仍然未能排除，可能是设备或单板硬件故障，请收集信息，并联系技术支持人员。

5. 告警与日志

2.5.2 端口不接收报文

1. 故障描述

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

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

2. 常见原因

· 端口出现CRC错误。

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

· 设备或单板硬件故障。

3. 故障分析

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

图2-15 故障诊断流程图

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的相关配置进一步排查。

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

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

5. 告警与日志

2.5.3 端口不发送报文

1. 故障描述

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

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

2. 常见原因

· 光模块异常。

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

· 设备或单板硬件故障。

3. 故障分析

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

图2-16 故障诊断流程图

4. 处理步骤

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

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

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

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

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

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

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

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

5. 告警与日志

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

1. 故障描述

40GE/100GE接口拆分或合并失败。

2. 常见原因

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

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

· 设备或单板硬件故障。

3. 故障分析

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

图2-17 故障诊断流程图

4. 处理步骤

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

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

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

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

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

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

5. 告警与日志

2.5.5 电口无法UP

1. 故障描述

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

2. 常见原因

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

· 端口配置问题。

· 网线有问题。

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

3. 故障分析

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

图2-18 故障诊断流程图

4. 处理步骤

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

<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

GE3/1/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

GE3/1/2 DOWN auto A A 1 aaaaaaa

GE3/1/3 UP 1G(a) F(a) A 1 aaaaaaa

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

<Sysname> display interface gigabitethernet 3/1/1

GigabitEthernet3/1/1

Current state: Administratively DOWN

Line protocol state: DOWN

Description: GigabitEthernet3/1/1 Interface

Bandwidth: 1000000 kbps

Flow-control is not enabled

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. 告警与日志

2.5.6 端口频繁UP/DOWN

1. 故障描述

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

2. 常见原因

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

· 光模块或线缆故障

· 电口自协商不稳定

· WAN口两端时钟配置问题

3. 故障分析

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

图2-19 故障诊断流程图

4. 处理步骤

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

<Sysname> display transceiver alarm interface ten-gigabitethernet 3/1/1

Ten-GigabitEthernet3/1/1 transceiver current alarm information:

RX loss of signal

RX power low

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

<Sysname> display transceiver diagnosis interface ten-gigabitethernet 3/1/1

Ten-GigabitEthernet3/1/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) 对于WAN口，请检查两端时钟是否配置，需在主控板有时钟扣板的一端配置为Master，另一端配置为Slave。

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

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

2.5.7 端口状态DOWN

1. 故障描述

当两台设备的物理接口连接完成后，发现接口无法UP，且在当前接口视图下使用display interface命令查看到接口的当前状态为DOWN。

2. 常见原因

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

· 接口配置错误，导致本端和对端接口配置不一致。

· 单板上的端口无法正常工作。

· 单板上的端口无法匹配光模块。

· 光模块未安装到位。

· 光模块或光纤存在损坏。

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

· 光纤连接异常。

3. 故障分析

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

(1) 使用命令行排查接口配置是否正确。

(2) 在问题端口进行本地环回测试，查看端口是否UP，排除单板或子卡本身的问题。

(3) 现场检查光纤、光模块等硬件问题。

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

图2-20 端口状态DOWN的故障诊断流程图

4. 处理步骤

(1) 在任意视图下执行display interface interface-type interface-number命令，查看端口状态是否UP（Current state和Line protocol state字段）：

¡ 如果端口状态均处于UP状态，则系统误报，无需处理。

¡ 如果端口状态处于DOWN状态，请在接口视图下执行undo shutdown命令，查看是否有恢复提示。

- 如果提示恢复，结束。

- 如果提示未恢复，请执行步骤(2)。

(2) 在任意视图下执行display interface interface-type interface-number命令，查看接口的运行状态和相关信息，保证端口配置正确，并且本端与对端的端口配置一致：

¡ 查看Current state字段，根据接口的物理状态，定位接口的物理DOWN的原因。

- DOWN：表示该接口的管理状态为开启，但物理状态为关闭，请检查物理连线或者线路。

- DOWN(Link-Aggregation interface down)：表示该接口所属的聚合接口已经通过shutdown命令被关闭，请在二层聚合接口视图/三层聚合接口视图下使用undo shutdown命令打开该聚合接口。

- IRF-link-down：接口所在成员设备上所有IRF链路状态为DOWN或ADM，接口被IRF链路检测功能关闭。请检查IRF配置。

- MAD ShutDown：当IRF分裂后，处于Recovery状态的IRF会将除了保留接口外的所有接口状态设置为MAD ShutDown。请检查IRF配置。

- STP DOWN：表示接口由于触发了STP BPDU保护而自动关闭。若关闭STP BPDU保护，请在系统视图下使用undo stp bpdu-protection命令。

- UP：该端口的管理状态和物理状态均为开启。

¡ 查看Line protocol state字段，根据接口的链路层协议状态，定位接口的链路层协议DOWN的原因。

- DOWN：表示数据链路层协议状态为关闭。请检查链路层协议及接口配置。

- DOWN(protocols)：表示接口的数据链路层被一个或者多个协议模块关闭，protocols为DLDP、OAM、LAGG和BFD的任意组合。请检查DLDP、以太网OAM、以太网链路聚合和BFD模块配置。

DLDP：表示由于DLDP模块检测到单通而关闭接口的数据链路层。

OAM：表示由于以太网OAM模块检测到远端链路故障而关闭接口的数据链路层。

LAGG：表示聚合接口中没有选中的成员端口而关闭接口的数据链路层。

BFD：表示由于BFD模块检测到链路故障而关闭接口的数据链路层。

- UP：表示数据链路层协议状态为开启。

- UP(spoofing)：表示该接口的数据链路层协议状态为开启，但实际可能没有对应的链路，或者所对应的链路不是永久存在而是按需建立。通常NULL、LoopBack等接口会具有该属性。

¡ 查看FEC mode字段，可以在25GE接口视图/100GE接口视图下使用port fec mode命令配置接口的FEC模式，保证链路本端和对端使用的FEC模式一致。

¡ 查看Port link-type字段，可以在二层以太网接口视图/二层聚合接口视图/虚拟二层以太网接口视图/虚拟二层聚合接口视图下使用port link-type命令配置端口的链路类型，保证链路类型配置正确。

¡ 查看接口工作在LAN模式或WAN模式，可以在Ten-GigabitEthernet接口视图下使用port-mode命令设置接口工作在LAN模式或WAN模式，保证本端与对端的接口工作模式相同。

¡ 查看双工模式，可以在以太网接口视图下使用duplex命令设置接口的双工模式，保证本端与对端的端口可以正常通信。

¡ 查看接口的速率，可以在以太网接口视图下使用speed命令设置接口的速率，保证光口与光模块进行速率匹配，本端与对端的端口可以正常通信。

如果故障仍不能排除，请执行步骤(3)。

(3) 检查单板上端口是否正常工作。

a. 在任意视图下使用display device命令，查看单板状态，若单板状态异常，请重启或更换单板。

b. 在异常端口下配置命令loopback internal，使能接口环回功能并配置以太网接口为内环回模式。

c. 完成接口的内环回功能配置后，在当前接口视图下使用命令display this interface查看接口状态：

- 如果接口状态为Down，则联系技术支持人员解决板卡问题。

- 如果接口状态为UP，则执行步骤(4)。

(4) 检查光模块或光纤是否安装到位。

¡ 光模块或光纤上均有卡扣，当插入光纤或光模块听到“咔嗒”声音时代表光纤或光模块已经正常插入。

¡ 重新插拔光模块或者光纤，保证光模块或者光纤安装到位。

如果故障仍不能排除，请执行步骤(5)。

(5) 检查单板上的端口是否可以匹配光模块。

a. 可通过“单板与光模块适配关系表”查看单板是否支持该光模块。

b. 若光模块为第三方光模块或伪造的H3C光模块，请更换为H3C光模块。鉴别光模块为第三方光模块或伪造的H3C光模块的方法，请参见“光模块上报非H3C合法光模块”故障处理步骤。

c. 如果故障仍不能排除，请执行步骤(6)。

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

¡ 请根据光模块的参数，选择匹配的光纤进行连接。

¡ 查看接收或发送光功率是否在正常范围内：

- 当发送光功率不在正常范围内时，请更换光模块。

- 当接收光功率小于接收灵敏度时，请调整链路或更换对端光模块。

如果故障仍不能排除，请执行步骤(7)。

(7) 检查光模块或光纤是否损坏。

a. 在任意视图下使用display transceiver alarm命令，查看当前端口上的光模块的故障告警信息，若显示为“None”，则表示没有故障；若显示有告警信息，可通过查看光模块/线缆告警信息来确认是光模块问题还是光纤或者对端问题。如果光模块或者光纤已损坏，请更换光模块或者光纤。

b. 如果故障仍不能排除，请执行步骤(8)。

(8) 检查光纤连接是否异常。

a. 将光纤拔出，调换光纤的接收和发送顺序后，重新插入光模块，如故障排除则可定位为光纤接收和发送顺序错误所致，如故障依旧则请将光纤恢复为原来的插入顺序。

b. 如果故障仍不能排除，请执行步骤(9)。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

2.6 光模块故障

2.6.1 光口不UP故障

1. 故障描述

光口不UP。

2. 常见原因

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

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

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

· 光口故障。

· 光模块或线缆故障。

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

3. 故障分析

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

图2-21 故障诊断流程图

4. 处理步骤

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

2.6.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. 故障分析

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

图2-22 故障诊断流程图

4. 处理步骤

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

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

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

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

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

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

2.6.3 光模块不支持数字诊断

1. 故障描述

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

<Sysname> display transceiver diagnosis interface ten-gigabitethernet 3/1/1

The transceiver does not support this function.

2. 常见原因

· 光模块为非H3C光模块。

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

· 光模块故障。

· 设备/光口故障。

3. 故障分析

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

图2-23 故障诊断流程图

4. 处理步骤

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

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

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

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

¡ 上述步骤的执行结果。

¡ 设备的告警信息。

5. 告警与日志

2.6.4 光模块序列号丢失

1. 故障描述

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

2. 常见原因

· 光模块未插紧。

· 光模块/设备故障。

3. 故障分析

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

图2-24 故障诊断流程图

4. 处理步骤

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

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

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

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

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

¡ 上述步骤的执行结果。

¡ 设备的告警信息。

5. 告警与日志

2.7 硬件转发故障

2.7.1 HG故障

1. 故障描述

在现网业务中，设备如果正常运行，转发通道是不会丢包的。但是如果某个时间，转发路径出现大量丢包或者直接不通的情况，需要排查内部转发通道是否出现故障。缺省情况下，路由器上已使能互连单板之间的转发通道检查功能，互连的单板之间会定时检测互连的转发通道是否正常。

· 对于CSPC-GE16XP4L-E、CSPC-GE24L-E和CSPC-GP24GE8XP2L-E单板可以通过display hardware internal hgmonitor info命令用来显示指定槽位单板的指定芯片的转发通道检测记录。

如设备转发链路异常，则显示信息中会有Link状态为down的记录，例如：

[Sysname-probe] display hardware internal hgmonitor info 4 0

Link status change notice event:

Unit Port Link Clock Number

0 hg0 up 08:08:03:755732 11/12/2014 1

0 hg0 down 09:22:23:977918 11/12/2014 2

0 hg1 up 08:12:19:398227 11/12/2014 1

0 hg2 up 08:08:05:465720 11/12/2014 1

0 hg3 up 08:12:21:391922 11/12/2014 1

可以通过查看Link状态为down的时间是否为发生故障的时间，如果时间一样则表示互连链路出现了故障。

· 对于CSPEX-1104-E、CSPEX-1204单板可以通过display hardware internal forward fpga counter命令用来显示CSPEX-1204单板的转发通道检测记录。

如设备转发链路异常，则显示信息中HG部分会有HG端口状态为down的状态，例如：

[Sysname-probe] display hardware internal forward fpga counter slot 3

……

5 HG

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

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

Value(HEX) Value(DEC) | Address | Description

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

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

0x0 0 | 0x005D0003 | SEND: HG_0 (DOWN)

OUT

0x0 0 | 0x00610003 | SEND: HG_1 (UP)

OUT

0x0 0 | 0x00650003 | SEND: HG_2 (DOWN)

OUT

0x0 0 | 0x00690003 | SEND: HG_3 (UP)

OUT

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

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

0x0 0 | 0x005D0005 | RECV: HG_0 (DOWN)

0x0 0 | 0x00610005 | RECV: HG_1 (UP)

0x0 0 | 0x00650005 | RECV: HG_2 (DOWN)

0xA27 2599 | 0x00690005 | RECV: HG_3 (UP)

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

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

……

· 对于CSPEX-1304S、CSPEX-1404S、CSPEX-1504S单板可以通过display hardware internal np serdes fabric status或display hardware internal nps interface fabric status命令用来显示单板的转发通道检测记录。如设备转发链路异常，则显示信息中HG部分会有HG端口状态为down的状态，例如：

[Sysname-probe] display hardware internal np serdes fabric status slot 18 chip 0

SERDES STATUS NP_PORT IF_NUM PEER_SLOT IF_TYPE

20 UP 106 10 23 40GE(UP)

21 UP 106 10 23 40GE(UP)

22 UP 106 10 23 40GE(UP)

23 UP 106 10 23 40GE(UP)

8 DOWN 104 8 23 40GE(DOWN)

9 DOWN 104 8 23 40GE(DOWN)

10 DOWN 104 8 23 40GE(DOWN)

11 DOWN 104 8 23 40GE(DOWN)

Hg port tuning Record:

Port Event Clock

10 Tuning_start 09:41:03:039327

10 Tuning_end(S) 09:41:04:118066

10 Switch_Route 09:41:24:705325

8 Tuning_start 09:41:04:118068

8 Tuning_end(S) 09:41:05:195958

8 Switch_Route 09:41:24:705327

· 转发链路检测失败，上报综合诊断模块，打印如下信息：

%@169696^Dec 21 16:04:06:987 2017 H3C SWFA/2/SWFA: -Chassis=1-Slot=15; 0x0F1E0000 [3060] :

HG Monitor check fail: (SrcSlot[15] .SrcChip[0] )-> (DstSlot[10] .DstChip[0] ))

上述信息表示转发链路可能存在故障，上报综合诊断模块进行分析。

%@169696^Dec 21 16:04:06:987 2017 H3C SWFA/2/SWFA: -Chassis=1-Slot=15; 0x0F1E0000 [3060] :

HG Monitor check Recover: (SrcSlot[15] .SrcChip[0] )-> (DstSlot[10] .DstChip[0] ))

上述信息表示转发链路可能存在故障，上报综合诊断模块进行修复。（仅适用于CSPEX-1304S、CSPEX-1404S、CSPEX-1504S单板）（

%@169696^Dec 21 16:04:06:987 2017 H3C SWFA/2/SWFA: -Chassis=1-Slot=15; 0x0F1E0000 [3060] :

HG Monitor check clear: (SrcSlot[15] .SrcChip[0] )-> (DstSlot[10] .DstChip[0] ))

上述信息表示转发链路故障已恢复，清除上报综合诊断模块的信息。

%@169694^Dec 21 16:04:06:927 2017 H3C SWFA/2/SWFA: -Chassis=1-Slot=15; 0x0F1E0000 [401] :

16:04:06:927390 12/21/2017: unit 0 port 23 is isolated by local.

%@169695^Dec 21 16:04:06:859 2017 H3C SWFA/2/FWD: -Chassis=1-Slot=10; 0x0FD93001 [377] :

16:04:06:859252 12/21/2017: unit 0 port 67 isolated by rpc.

上述信息表示转发链路可能存在故障，上报综合诊断模块对此条链路进行隔离。

%@169694^Dec 21 16:04:06:927 2017 H3C SWFA/2/SWFA: -Chassis=1-Slot=15; 0x0F1E0000 [401] :

16:04:06:927390 12/21/2017: unit 0 port 23 is fault, not isolated by local.

%@169695^Dec 21 16:04:06:859 2017 H3C SWFA/2/FWD: -Chassis=1-Slot=10; 0x0FD93001 [377] :

16:04:06:859252 12/21/2017: unit 0 port 67 is fault, not isolated by rpc.

上述信息表示转发链路可能存在故障，且无备份链路，上报综合诊断模块对此条链路进行隔离。

%Aug 13 15:58:18:186 2019 H3C DIAG/4/DIAG_AI: -MDC=1; Board fault: chassis 0 slot 8 or chassis 0 slot 12, please check them

上述输出信息表示多个槽位可能存在故障。

%Aug 13 15:58:18:186 2019 H3C DIAG/4/DIAG_AI: -MDC=1; Board fault: chassis 0 slot 8, please check it

上述输出信息表示单个槽位可能存在故障。

2. 常见原因

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

· 交换网板故障。

· 业务板故障。

3. 故障分析

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

图2-25 故障诊断流程图

4. 处理步骤

由于没有单独的交换网板，不支持网板隔离命令，请直接联系技术支持人员。

对于上报综合诊断模块，打印的信息的故障处理步骤如下：

(1) 通过display hardware-failure-detection命令查看设备的硬件故障检测和修复信息。

(2) 排查互连两端HG状态是否为正常Up，如果是有互连HG状态是Down，表明存在硬件故障。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

2.7.2 FMEA故障

1. 故障描述

FMEA是硬件器件失效检测，出现异常时logfile打印带有FMEA或Hardware error标记的诊断信息，如

%@3458327%Jan 2 23:16:42:223 2020 H3C DIAG/2/FMEA: -Chassis=2-Slot=3; Hardware error detected on chassis 2 slot 3.

2. 故障处理步骤

FMEA检测覆盖主控板、接口板和网板，检测到故障输出到诊断日志，默认配置下不会执行动作，仅做信息输出。如果诊断信息持续打印，请注意观察是否有其他业务异常，同时将故障信息发送给技术支持人员帮助分析。

2.8 故障诊断命令

命令	说明
display device	显示设备信息，检查各单板的状态是否正常
display environment	显示路由器的温度信息，检查环境温度是否正常（是否超出温度告警阈值）
display fan	显示设备内置风扇的工作状态
display fan-speed	显示设备当前风扇转速
display power	显示设备内置电源的工作状态
display version	显示系统版本信息、单板的运行时间以及最后一次重启的原因
save	将当前配置保存到指定文件
temperature-limit	设置设备的温度告警门限

3 基础配置类故障处理

3.1 登录设备类故障处理

3.1.1 Console口密码遗忘

1. 故障描述

Console口采用Password认证或AAA本地认证的情况下，管理员通过Console口登录设备时，因密码不正确而无法成功登录。

2. 常见原因

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

· 管理员遗忘了Console口的登录密码或输入错误的密码。

· Console口的登录账户已过期。

3. 故障分析

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

图3-1 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口认证（不同产品跳过Console口认证的菜单选项不同，请以实际情况为准）。系统启动后，不需要管理员输入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扩展段主菜单后，请按照系统提示选择相应的菜单选项跳过当前配置（不同产品跳过当前配置的菜单选项不同，请以实际情况为准）。系统启动时，将忽略配置文件中的所有配置以空配置进行启动（该选项每次设置后仅生效一次）。系统启动后，不需要管理员输入Console口密码。

a. 启动后，请尽快将原配置文件导出。在此操作过程中不要对设备进行断电。

- 方式一：通过FTP/TFTP方式将原配置文件导出到本地。

- 方式二：在用户视图下执行more命令查看原配置文件内容，将显示的所有原配置文件内容直接复制粘贴到本地文件中。

b. 手动修改本地配置文件中关于Console口登录的配置，将修改后的配置文件上传至设备存储介质的根目录下。

c. 配置下次启动时的配置文件为修改后的配置文件（假设修改后的配置文件为startup.cfg）。

<Sysname> startup saved-configuration startup.cfg

d. 重启设备。

(5) 通过BootWare扩展段菜单恢复出厂配置，登录后配置新的Console口密码。

此操作下，系统启动时会自动删除下次启动配置文件和备份启动配置文件，再以出厂配置启动。请确保当前业务不会受到影响时执行本操作。

直接回车，进入BootWare扩展段主菜单后，请按照系统提示选择相应的子菜单恢复出厂配置（不同产品恢复出厂配置的菜单选项不同，请以实际情况为准）。系统启动后，不需要管理员输入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方案。相关配置的详细介绍请参见“BRAS业务配置指导”中的“AAA”。

b. 为了防止重启后配置丢失，请执行save命令保存当前配置。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

3.1.2 Telnet登录密码遗忘

1. 故障描述

设备对Telnet登录用户采用Password认证或AAA本地认证的情况下，管理员遗忘Telnet账户密码无法登录设备。

2. 常见原因

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

· 管理员遗忘了Telnet口的登录密码或输入错误的密码。

· Telnet登录账户已过期。

3. 故障分析

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

图3-2 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. 告警与日志

3.1.3 Telnet登录失败

1. 故障描述

设备作为Telnet服务器时，用户通过Telnet客户端登录设备失败。

2. 常见原因

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

· Telnet客户端和设备间网络不畅通。

· Telnet客户端未启用Telnet相关功能。

· 设备未开启Telnet服务。

· VTY用户线下未配置支持Telnet协议。

· 登录用户名、密码不正确。

· 登录设备的用户数达到了上限。

· 设备上配置了对Telnet用户的访问控制，Telnet客户端不在所引用ACL的规则中permit的用户范围之内。

· 认证方式配置不正确。

· 当Telnet客户端和Telnet服务器均为我司设备时，用户未从Telnet客户端上指定的发送Telnet报文的源地址或源接口登录Telnet服务器。

3. 故障分析

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

图3-3 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. 告警与日志

3.2 配置文件管理类故障处理

3.2.1 使用配置文件恢复配置

缺省情况下，设备的启动配置文件为flash:/config.cfg。设备上电时，从缺省存储路径中读取config.cfg文件进行设备的初始化操作。如果缺省存储路径中没有配置文件，则设备采用缺省参数进行初始化配置。

如果想要将设备当前配置恢复成以前保存过的某个配置，可以通过下面的步骤完成。

(1) 通过FTP或TFTP方式将用于恢复的配置文件上传到设备的所有主控板上（以FTP方式举例，上传的配置文件名为 config.cfg）。

# 将用于恢复的配置文件上传到主用主控板。

<Sysname> ftp 192.168.33.13

Press CTRL+C to abort.

Connected to 192.168.33.13 (192.168.33.13).

220 WFTPD 2.0 service (by Texas Imperial Software) ready for new user

User (192.168.33.13:(none)): 1

331 Give me your password, please

Password:

230 Logged in successfully

Remote system type is MSDOS.

ftp> binary

200 TYPE is now 8-bit binary

ftp> get config.cfg

local: /mnt/slot1#sda0:/config.cfg remote: config.cfg

227 Entering Passive Mode (192,168,33,13,209,24)

150 "F:\config.cfg" file ready to send (18494 bytes) in IMAGE / Binary mode

226 Transfer finished successfully.

18494 bytes received in 0.0383 seconds (471.1 kbyte/s)

ftp> quit

221-Goodbye. You uploaded 0 and downloaded 0 kbytes.

221 Logout.

# 将主用主控板的config.cfg配置文件拷贝到备用主控板。

<Sysname> copy config.cfg slot1#cfa0:/config.cfg

Copy cfa0:/config.cfg to slot1#cfa0:/config.cfg? [Y/N]:y

Copying file cfa0:/config.cfg to slot1#cfa0:/config.cfg...Done.

(2) 设置下次启动时使用的配置文件，以便下次启动后设备恢复到此配置。

<Sysname> startup saved-configuration config.cfg

需要注意的是，如果用于恢复的配置文件名为config.cfg（和设备缺省启动的配置文件名相同），则本步骤可选；如果不是config.cfg，则本步骤必选。

(3) 重启设备，重启完成后设备会以上面设置的配置文件恢复配置。

上述步骤的操作过程中，不能进行save命令的操作，否则设备将以当前保存的配置启动。

3.3 软件升级故障处理

3.3.1 设备启动失败

1. 故障描述

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

2. 常见原因

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

· 启动文件所在存储体（SD卡、U盘）接触不良。

· 系统的BootWare版本与加载的软件包版本不匹配。

3. 故障分析

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

图3-4 设备启动失败故障处理诊断流程图

4. 处理步骤

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

Booting Normal Extended BootWare

The Extended BootWare is self-decompressing.............Done.

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

* *

* BootWare, Version 1.50 *

* *

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

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

|<5> Copy File |

|<0> Exit To Main Menu |

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

Enter your choice(0-5): 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. 告警与日志

3.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. 告警与日志

4 虚拟化技术类故障处理

4.1 IRF组建失败

4.1.1 故障描述

多台设备无法组建IRF，或者新设备无法加入现有的IRF。

4.1.2 常见原因

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

· IRF成员设备数量超出了产品支持的规格，导致新设备无法加入现有的IRF。

· 配置不符合IRF要求，导致无法组建IRF，或者新设备无法加入现有的IRF。

· IRF物理端口、线缆和物理拓扑不符合IRF要求，导致IRF链路无法达到up状态。

4.1.3 故障分析

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

图4-1 IRF组建失败故障诊断流程图

4.1.4 故障处理步骤

本文仅列出组建IRF的常规要求，以供参考。组建IRF的完整要求请参见产品配套的《IRF配置指导》。

(1) 检查IRF成员数量是否已达到系统支持的最大值。

请使用display irf命令查看当前IRF中的成员设备数量。如果IRF成员数量已经达到系统支持的最大值，则不允许再加入成员设备。

同一IRF域内，允许加入的成员设备最多为2台。

(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命令修改。修改后需要保存配置并重启该设备，新编号才能生效。

c. 确保各成员设备的出厂桥MAC地址不同

具有相同出厂桥MAC的成员设备之间不能组成IRF。通常情况下，设备出厂会携带全网唯一的桥MAC地址。如果IRF组建失败，且输出了日志信息“Failed to stack because of the same bridge MAC addresses.”，则表明两台设备的出厂桥MAC相同，可在其中一台设备上执行irf mac-address命令修改桥MAC。

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的要求。

a. SR8803-F路由器不支持组建IRF。其他SR8800-F路由器之间可以建立IRF，但不能与不同系列的路由器产品建立IRF。并且 SR8800-F路由器上组建IRF必须使用主控板上的MCC 10GE口作为IRF物理端口。

# 使用display version命令查看设备型号。

<Sysname> display version

H3C Comware Software, Version 7.1.075, ESS 8309

H3C SR8803-X-S uptime is 0 weeks, 3 days, 3 hours, 11 minutes

…

b. 确认成员设备的软件版本、主控板类型、OEM Flag是否一致，确认组成IRF的两台设备上均配置为A类交换网板或丝印完全相同的其他类型交换网板。

# 使用display device命令查看主控板、接口板的型号。

<Sysname> display device

Chassis Slot No. Brd Type Brd Status Software Version

1 0 NONE Absent NONE

1 1 NONE Absent NONE

1 2 NONE Absent NONE

1 3 NONE Absent NONE

1 4 NONE Absent NONE

1 5 NONE Absent NONE

1 6 CSR07SRPUD3 Master SR8800FS-CMW710-RXXXX

1 7 NONE Absent NONE

1 8 NONE Absent NONE

1 9 NONE Absent NONE

1 10 NONE Absent NONE

1 11 NONE Absent NONE

# 使用display hardware internal sysm eeprom命令用来读取EEPROM的信息。

[H3C-probe]display hardware internal sysm eeprom 380 4 5

0x380: 0xa5 0x8 0x59 0x2

(8) 检查系统参数配置是否满足IRF的要求。

部分产品会要求设备的系统工作模式以及MAC数目的配置相同，否则无法组建IRF。（不同产品的具体要求不同，请以设备的实际情况为准）

¡ 使用display system-working-mode命令可查看设备的系统工作模式，使用system-working-mode命令可将设备的系统工作模式修改为相同值。修改系统工作模式后请重启该设备，使修改的工作模式生效。

¡ 使用display hardware internal lif interface-mac slot命令行查看MAC数目。

[Sysname-probe] display hardware internal lif interface-mac slot 1

System Total MAC Number: 512

---------------------- MAC Information ------------------------

Total MAC Number : 512

MDCID : 1

Bridge MAC : 1234-5678-9000

M-Ethernet MAC : 1234-5678-9001

Global Interface MAC : 1234-5678-9002 (VLAN RAGG RPR VE-VPN)

Router Intf Base MAC : 1234-5678-9036 (NP Router interface)

4.1.5 告警与日志

4.2 IRF成员设备异常重启

4.2.1 故障描述

堆叠过程中发生了主设备或者备设备异常重启，导致堆叠分裂。

4.2.2 常见原因

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

· 从设备自动重启来完成软件版本的升级。

· IRF合并，导致从设备重启。

· 设备软件或者硬件故障，导致设备异常重启，来尝试修复故障。

4.2.3 处理步骤

(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命令，可以查看成员设备/单板上次重启的原因，根据重启原因，以及下表所示的建议操作进行处理。

<Sysname> display version

…

Reboot Cause : ColdReboot

[SubSlot 0] 24GE+4SFP Plus+POE

Reboot Cause字段的取值	重启原因说明	建议操作
AutoUpdateReboot	自动更新版本后重启	正常，无需处理
BootwareBackupReboot	Bootware备份区重启	请收集日志、诊断日志，联系技术支持人员处理
ColdReboot	设备掉电	检查设备的供电环境，确保供电正常
CryptographicModuleSelftestsFailedReboot	算法库自检失败	请及时升级软件版本
CryptotestFailReboot	加密算法库自检失败	请及时升级软件版本
DeadLoopReboot	软件检测到死循环	请收集日志、诊断日志和重启slot的display kernel deadloop 20 verbose的显示信息，联系技术支持人员处理
DEVHandShakeReboot	主控板与所有接口板之间握手报文超时	使用display device命令查看主控板状态是否为Normal，如果不是Normal，表示主控板可能故障，请先解决主控板的问题
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	通过命令行、网管主动重启设备	正常，无需处理
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

以上命令的支持情况与设备的型号以及版本有关请以设备的实际情况为准。

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

4.2.4 告警与日志

4.3 IRF出现分裂

4.3.1 故障描述

IRF运行过程中出现分裂。

4.3.2 设备故障处理步骤

(1) IRF分裂时会打印IRF端口down，可以确定IRF分裂的时间。

%Jun 26 10:13:46:233 2014 H3C STM/2/STM_LINK_STATUS_TIMEOUT: IRF port 1 is down because heartbeat timed out.

%Jun 26 10:13:46:436 2014 H3C STM/3/STM_LINK_STATUS_DOWN: -MDC=1; IRF port 2 is down.

(2) IRF物理端口所在主控板的状态是否正常，若不正常，请参照2.1.6 资源不足排查是否主控板故障。

(3) 检查各个IRF物理端口的状态是否正常。若端口状态不正常，请按照确认故障原因。

<Sysname> display interface Ten-GigabitEthernet 1/6/0/1

Ten-GigabitEthernet1/6/0/1

Current state: UP

IP Packet Frame Type: PKTFMT_ETHNT_2, Hardware Address: 0000-5c55-4446

Description: Ten-GigabitEthernet1/6/0/1 Interface

Bandwidth: 10000000kbps

Loopback is not set

Media type is stack wire,Port hardware type is STACK_SFP_PLUS

10Gbps-speed mode, full-duplex mode

Link speed type is force link, link duplex type is force link

The Maximum Frame Length is 9216

Mdi type: automdix

Last clearing of counters: Never

Peak value of input: 21374 bytes/sec, at 2015-05-23 16:19:10

Peak value of output: 77798 bytes/sec, at 2015-05-23 16:19:10

Last 5 seconds input: 39 packets/sec 12420 bytes/sec 0%

Last 5 seconds output: 85 packets/sec 43207 bytes/sec 0%

Input (total): 24470 packets, 7974732 bytes

17950 unicasts, 0 broadcasts, 6445 multicasts, 0 pauses

Input (normal): 24395 packets, - bytes

17950 unicasts, 0 broadcasts, 6445 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): 54633 packets, 30848497 bytes

30440 unicasts, 0 broadcasts, 24118 multicasts, 0 pauses

Output (normal): 54558 packets, - bytes

30440 unicasts, 0 broadcasts, 24118 multicasts, 0 pauses

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

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

0 lost carrier, - no carrier

(4) 通过设备运行时间或日志检查IRF中各个成员设备及IRF物理端口所在的主控板在IRF分裂时是否重启过，并参照2.2 电源故障确认是否为电源故障导致。

<Sysname> display version

H3C Comware Software, Version 7.1.075, Release XXXX

H3C SR8812-F uptime is 0 weeks, 0 days, 0 hours, 43 minutes

Last reboot reason : USER reboot

Boot image: cfa0:/BOOT-RXXXX.bin

Boot image version: 7.1.075, Release XXXX

Compiled May 13 2015 19:22:53

System image: cfa0:/SYSTEM-RXXXX.bin

System image version: 7.1.075, Release XXXX

Compiled May 13 2015 19:22:53

Feature image(s) list:

MPU(M) Chassis 1 Slot 6:

Uptime is 0 weeks,0 days,0 hours,47 minutes

BOARD TYPE: CSR07SRPUD3

DRAM: 8192M bytes

CFCARD: 4002M bytes

FLASH: 500M bytes

NVRAM: 1M bytes

PCB 1 Version: VER.A

Bootrom Version: 135

CPLD 1 Version: 001

CPLD 2 Version: 003

Release Version: H3C SR8812-F-XXXX

Patch Version : None

Reboot Cause : UserReboot

Clock card:

Type : SR07CK3C

PCB : Ver.A

FPGA version: 100

Number of Exist Subcards: 0

MPU(S) Chassis 4 Slot 0:

Uptime is 0 weeks,0 days,0 hours,47 minutes

BOARD TYPE: CSR07SRPUD3

DRAM: 8192M bytes

CFCARD: 4002M bytes

FLASH: 500M bytes

NVRAM: 1M bytes

PCB 1 Version: VER.A

Bootrom Version: 135

CPLD 1 Version: 001

CPLD 2 Version: 002

Release Version: H3C SR8808-F-XXXX

Patch Version : None

Reboot Cause : UserReboot

Clock card:

Type : SR07CK3C

PCB : Ver.A

FPGA version: 100

Number of Exist Subcards: 0

MPU(S) Chassis 4 Slot 1:

Uptime is 0 weeks,0 days,0 hours,47 minutes

BOARD TYPE: CSR07SRPUD3

DRAM: 8192M bytes

CFCARD: 4002M bytes

FLASH: 500M bytes

NVRAM: 1M bytes

PCB 1 Version: VER.A

Bootrom Version: 135

CPLD 1 Version: 001

CPLD 2 Version: 003

Release Version: H3C SR8808-F-XXXX

Patch Version : None

Reboot Cause : UserReboot

Clock card:

Type : SR07CK3C

PCB : Ver.A

FPGA version: 100

Number of Exist Subcards: 0

LPU Chassis 4 Slot 2:

Uptime is 0 weeks,0 days,0 hours,28 minutes

BOARD TYPE: CSPEX-1304S

DRAM: 4096M bytes

PCB 1 Version: VER.A

Bootrom Version: 120

CPLD 1 Version: 001

Release Version: H3C SR8812-F-XXXX

Patch Version : None

Reboot Cause : UserReboot

Number of Exist Subcards: 0

LPU Chassis 4 Slot 3:

Uptime is 0 weeks,0 days,0 hours,13 minutes

BOARD TYPE: CSPEX-1304S

DRAM: 4096M bytes

PCB 1 Version: VER.A

Bootrom Version: 120

CPLD 1 Version: 001

Release Version: H3C SR8812-F-XXXX

Patch Version : None

Reboot Cause : UserReboot

Number of Exist Subcards: 0

LPU Chassis 4 Slot 4:

Uptime is 0 weeks,0 days,0 hours,28 minutes

BOARD TYPE: CSPEX-1304S

DRAM: 4096M bytes

PCB 1 Version: VER.A

Bootrom Version: 120

CPLD 1 Version: 001

Release Version: H3C SR8812-F-XXXX

Patch Version : None

Reboot Cause : UserReboot

Number of Exist Subcards: 0

(5) 如故障确认，可以通过如更换光模块、更换单板的方式使设备重新形成IRF；如故障无法确认，请搜集各个成员设备的信息，并将信息发送给技术支持人员协助分析。

4.4 故障诊断命令

命令	说明
debug ipv4-drv show config	显示当前IPv4配置信息
display device	显示设备信息。用于检查各成员设备的软件版本、主控板类型是否一致
display install active	显示当前系统中处于激活状态的软件包的相关信息
display interface	显示指定接口的相关信息。用于检查IRF物理端口状态是否UP
display irf configuration	显示所有成员设备的IRF配置信息。用于检查IRF端口连接是否异常，一台设备的IRF-Port1口只能与另一台设备的IRF-Port2口连接
display system-vlan-mode	显示系统当前运行的VLAN模式和下次启动后运行的VLAN模式
display version	显示系统版本信息、单板的运行时间。通过设备运行时间确认IRF中各个成员设备是否重启过，主控板及IRF端口所在接口板是否发生重启
display irf topology	查看当前拓扑信息。显示IRF拓扑状态

5 接口管理类故障处理

5.1 聚合口故障

5.1.1 故障描述

故障现象通常为二层聚合口、三层聚合口业务异常，例如聚合成员口无法选中、聚合负载分担业务异常。

5.1.2 故障处理步骤

1. 聚合成员端口无法选中

(1) 通过display link-aggregation verbose命令查看聚合接口对应聚合组的详细信息。

[Sysname] display link-aggregation verbose Route-Aggregation 12

Loadsharing Type: Shar -- Loadsharing, NonS -- Non-Loadsharing

Port Status: S -- Selected, U -- Unselected, I -- Individual

Port: A -- Auto

Flags: A -- LACP_Activity, B -- LACP_Timeout, C -- Aggregation,

D -- Synchronization, E -- Collecting, F -- Distributing,

G -- Defaulted, H -- Expired

Aggregate Interface: Route-Aggregation12

Aggregation Mode: Static

Loadsharing Type: Shar

Port Status Priority Oper-Key

XGE3/1/1 U 32768 2

XGE3/1/2 U 32768 2

(2) 检查聚合口下的成员口物理状态是否UP，如果是DOWN状态，请检查连线。

[Sysname]display interface ten-gigabitEthernet 3/1/1

Ten-GigabitEthernet3/1/1

Current state: DOWN

Line protocol state: DOWN(LAGG)

Description: Ten-GigabitEthernet3/1/1 Interface

Bandwidth: 10000000 kbps Flow-control is not enabled

(3) 检查聚合口下的配置和成员口的配置是否一致，如果不一致，会出现成员端口无法选中的现象。

(4) 检查聚合口下各成员口的速率配置是否一致，如果不一致，可以通过link-aggregation ignore speed命令用来配置聚合组选择选中端口时忽略端口速率。如果聚合组两端本命令配置不一致，动态聚合组可以通过LACP协议协商状态，使链路两端端口状态一致；静态聚合组无法协商状态，为了防止报文丢失，所以要求静态聚合组两端本命令配置一致。配置本命令后，如果聚合组中选中端口速率不同，聚合组中流量负载分担时，速率较小的选中端口可能存在丢包现象，请按需配置本功能。开启和关闭本功能后，操作Key会发生变化，导致聚合接口震荡，请按需配置本功能。

(5) 如果聚合口下的配置和成员口的配置相同，聚合成员口还是无法选中，则联系技术支持。

2. 聚合负载分担业务异常。

请联系技术支持。

5.2 端口错包

5.2.1 故障描述

使用display interface命令查询端口的入、出方向流量统计信息，发现错包统计计数不为0。

<Sysname> display interface ten-gigabitethernet3/1/1

Ten-GigabitEthernet3/1/1

Current state: UP

Line protocol state: UP

Description: Ten-GigabitEthernet3/1/1 Interface

Bandwidth: 10000000kbps

Flow-control is not enabled

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

IP packet frame type: Ethernet II, hardware address: 9c06-1b04-31fe

IPv6 packet frame type: Ethernet II, hardware address: 9c06-1b04-31fe

Media type is not sure, port hardware type is No connector

Port priority: 0

Loopback is not set

unknown-speed mode, unknown-duplex mode

Link speed type is autonegotiation, link duplex type is autonegotiation

The maximum frame length is 10240

Last link flapping: Never

Last clearing of counters: Never

Current system time:2020-04-28 11:42:09

Last time when physical state changed to up:-

Last time when physical state changed to down:2020-04-28 11:40:45

Peak input rate: 0 bytes/sec, at 2020-04-28 11:42:08

Peak output rate: 0 bytes/sec, at 2020-04-28 11:42:08

Last 5 seconds input: 0 packets/sec 0 bytes/sec 0 bits/sec -%

Last 5 seconds output: 0 packets/sec 0 bytes/sec 0 bits/sec -%

Input (total): 0 packets, 0 bytes

0 unicasts, 0 broadcasts, 0 multicasts, - pauses

Input (normal): 0 packets, - bytes

- unicasts, - broadcasts, - multicasts, 0 pauses

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

0 CRC, 0 frame, 0 overruns, - aborts

0 ignored, - parity errors

Output (total): 0 packets, 0 bytes

0 unicasts, 0 broadcasts, 0 multicasts, - pauses

Output (normal): 0 packets, 0 bytes

- unicasts, - broadcasts, - multicasts, 0 pauses

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

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

- lost carrier, - no carrier

1. 端口入方向报文计数错误字段解释

· input errors：端口接收的错误报文的统计值。

· runts：表示接收到的超小帧个数。超小帧即超小帧是指长度小于64字节、格式正确且包含有效的CRC字段的帧。

· giants：接收到的超大帧的数量。超大帧即有效长度大于端口允许通过最大报文长度的帧。

· CRC：接收到的CRC校验错误、长度正常的帧的数量。

· frame：接收到的CRC校验错误、且长度不是整字节数的帧的数量。

· throttles：超小而且CRC错误的帧的数量。

2. 端口出方向报文计数错误字段解释

· output errors：各种发送错误的报文总数。

· aborts：表示发送失败的报文总数。

· deferred：表示延迟报文的总数。报文延迟是指因延迟过长的周期而导致发送失败的报文，而这些报文由于发送媒质繁忙而等待了超过2倍的最大报文发送时间。

· collisions：表示冲突帧总数，即在发送过程中检测到冲突而停止发送的报文。

· late collisions：表示延迟冲突帧，即发送过程中发生延迟冲突超过512bit时间的帧。

5.2.2 故障处理步骤

1. 端口入方向出现CRC、frame、throttles错包且计数持续增加

(1) 使用仪器测试链路，链路质量差或者线路光信号衰减过大会导致报文在传输过程中出错。如链路故障请更换网线或光纤。

(2) 如端口使用光模块，参照5.6 光模块故障确认是否光模块故障导致。

(3) 与别的正常的端口更换网线或光纤光模块，如端口更换后错包消失，端口更换回来错包又再次出现端口相关，应为单板端口故障，请更换端口并将故障信息发送技术支持人员分析；如更换到其他正常端口仍会出现错包，则对端设备、中间传输链路故障的可能性较大，请排查。

(4) 排查对端设备或者中间的传输设备。

(5) 如故障无法确认，请将故障信息发送技术支持人员分析。

2. 端口入方向出现Overrun错包且计数持续增加

Overrun计数是由于端口输入速率超出本端口处理能力，导致丢包。

(1) 如果只有某一个端口收发包异常，或者某一个端口下挂设备的业务不通，同时这个单板上的其他端口都是正常的，可以多次查询display interface命令，如果input errors有增加，且等于overruns的增加，那么可以怀疑是单板内部拥塞或堵死，请将故障信息发送技术支持人员分析。

(2) 如果仍然无法确认，请将故障信息发送技术支持人员分析。

3. 端口入方向出现giants错包且计数持续增加

(1) 检查两端的jumbo配置是否一致，如jumbo是否使能，端口默认的最大报文长度是否一致，允许最大报文长度是否一致，可以通过display interface命令查到，即The maximum frame length所显示的数值。

(2) 如果仍然无法确认，请将故障信息发送技术支持人员分析。

4. 端口出方向出现错包且计数持续增加

(1) 检查端口是否配置为半双工模式，如为半双工，请更改为全双工模式。

(2) 如果仍然无法确认，请将故障信息发送技术支持人员分析。

5.3 端口无法up

5.3.1 故障描述

端口无法正常up。

5.3.2 故障处理步骤

1. 端口无法up

(1) 测试端口之间网线、光纤链路是否正常，光纤两端的发送/接收端是否错连；更换端口之间的网线、光纤或将网线、光纤放到别的正常端口，以确认是否中间传输链路故障。

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

(3) 检查本端、对端端口配置是否正确，如端口是否shutdown，速率、双工的协商模式、MDI是否正确。

[Sysname] display current-configuration interface ten-gigabitethernet 3/1/1

interface Ten-GigabitEthernet3/1/1

port link-mode bridge

port link-type trunk

port trunk permit vlan 1 3102

port link-aggregation group 1

return

(4) 如端口使用光模块，请检查两端光模块类型是否一致，如速率、波长、单模多模状态等；由于部分子卡一个端口支持两种速率，请使用和端口实际速率一致的光模块；与正常的光模块交叉更换，并参照5.6 光模块故障排除是否为光模块故障导致。

[Sysname] display transceiver interface Ten-gigabitethernet 3/1/1

Ten-GigabitEthernet3/1/1 transceiver information:

Transceiver Type : 10G_BASE_SR_SFP

Connector Type : LC

Wavelength(nm) : 850

Transfer Distance(km) : 80(50um),20(62.5um),300(om3)

Digital Diagnostic Monitoring : YES

Vendor Name : H3C

Ordering Name : SFP-XG-SX-MM850-A

(5) 如端口为WAN口。请检查WAN口的速率是否与光模块匹配，如果不匹配，请更换。

(6) 如果是使用100G QSFP28光模块的接口，要检查两端的FEC配置是否一致，如不匹配，请更换。

(7) 如确认为光模块故障，请更换光模块，并将故障信息发送技术支持人员分析。

5.4 端口由up变成down

5.4.1 故障描述

端口状态由up变成down。

5.4.2 故障处理步骤

(1) 查看本设备及对端设备日志，确认有无端口shutdown操作。

(2) 查看两端端口状态，确认是否为协议异常或在线诊断模块检测到异常将端口shutdown。如这里的XGE3/1/1端口出现“Protect DOWN”，是由于hardware-failure-detection配置为isolate级别，当设备在线诊断模块检测到端口故障时，将端口shutdown隔离，以便流量切换到备份链路。请将故障信息发送技术支持人员分析。

[Sysname] display interface ten-gigabitethernet3/1/1

Ten-GigabitEthernet3/1/1

current state: Protect DOWN

Line protocol current state: DOWN

IP Packet Frame Type: PKTFMT_ETHNT_2, Hardware Address: 0000-e80d-c000

Description: Ten-GigabitEthernet3/1/1 Interface

Loopback is not set

Media type is optical fiber, Port hardware type is 10000_BASE_SX_SFP

Unknown-speed mode, unknown-duplex mode

Link speed type is autonegotiation, link duplex type is autonegotiation

Flow-control is not enabled

The Maximum Frame Length is 9216

……

(3) 参照5.3 端口无法up，排查两端端口配置，网线、光模块、光纤等链路是否正常。

(4) 如仍无法确认，请搜集本端、对端设备信息，并将信息发送技术支持人员分析。

5.5 端口频繁up/down

5.5.1 故障描述

端口频繁up/down。

5.5.2 故障处理步骤

(1) 对于光口，请参照5.6 光模块故障确认光模块是否异常。查看光模块alarm信息来排查两端光模块以及中间光纤问题；对于支持诊断功能的光模块可以通过查看diagnosis信息确认光模块的光功率是否处于上下门限临界值。如发送光功率处于临界值，请更换光模块做交叉验证；如接收光功率处于临界值，请排查对端光模块及中间光纤链路。

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

(3) 对于WAN口，请检查两端时钟是否配置，需在主控板有时钟扣板的一端配置为Master，另一端配置为slave。

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

(5) 如仍无法确认，请将故障信息发送技术支持人员分析。

5.6 光模块故障

5.6.1 故障描述

安装光模块的接口不能正常工作。

5.6.2 故障处理步骤

(1) 检查光模块Alarm告警信息。告警信息中如果存在接收有问题那一般是对端端口、光纤或中转传输设备导致；如果是发送有问题或者电流、电压异常那就需要排查本端端口。

<Sysname> display transceiver alarm interface ten-GigabitEthernet 3/1/1

Ten-GigabitEthernet3/1/1 transceiver current alarm information:

TX fault

RX power high

表5-1 光模块告警信息说明

字段	描述
SFP/SFP+/CFP/QSFP+
RX loss of signal	接收信号丢失
RX power high	接收光功率高告警
RX power low	接收光功率低告警
TX fault	发送错误
TX bias high	偏置电流高告警
TX bias low	偏置电流低告警
TX power high	发送光功率高告警
TX power low	发送光功率低告警
Temp high	温度高告警
Temp low	温度低告警
Voltage high	电压高告警
Voltage low	电压低告警
Transceiver info I/O error	模块信息读写错误
Transceiver info checksum error	模块信息校验和错误
Transceiver type and port configuration mismatch	模块类型和端口配置不匹配
Transceiver type not supported by port hardware	端口不支持该模块类型
XFP
RX loss of signal	接收信号丢失
RX not ready	接收状态未就绪
RX CDR loss of lock	RX CDR时钟失锁
RX power high	接收光功率高告警
RX power low	接收光功率低告警
TX not ready	发送状态未就绪
TX fault	发送错误
TX CDR loss of lock	TX CDR时钟失锁
TX bias high	偏置电流高告警
TX bias low	偏置电流低告警
TX power high	发送光功率高告警
TX power low	发送光功率低告警
Module not ready	模块状态未就绪
APD supply fault	APD（Avalanche Photo Diode，雪崩光电二极管）错误
TEC fault	TEC（Thermoelectric Cooler，热电冷却器）错误
Wavelength unlocked	光信号波长失锁
Temp high	温度高告警
Temp low	温度低告警
Voltage high	电压高告警
Voltage low	电压低告警
Transceiver info I/O error	模块信息读写错误
Transceiver info checksum error	模块信息校验错误
Transceiver type and port configuration mismatch	模块类型和端口配置不匹配
Transceiver type not supported by port hardware	端口不支持该模块类型

(2) 检查光模块的接收、发送光功率是否正常（即在该光模块的光功率上下门限值之内）。

对于H3C定制且支持诊断功能的光模块，可以通过命令行查询光模块的接收、发送光功率是否超出其上下门限值；其他光模块可以使用同样命令尝试查询，但有可能查询不到。

a. 查看光模块的电子标签信息，Verdor Name显示为H3C表示是H3C定制光模块。

<Sysname> display transceiver manuinfo interface Ten-gigabitethernet 3/1/1

Ten-GigabitEthernet3/1/1 transceiver manufacture information:

Manu. Serial Number : 213410A0000054000251

Manufacturing Date : 2012-10-26

Vendor Name : H3C

b. 通过下述命令确认光模块是否支持诊断功能，Digital Diagnostic Monitoring为YES表示支持诊断功能。

<Sysname> display transceiver interface

Ten-GigabitEthernet3/1/1 transceiver information:

Transceiver Type : 10G_BASE_LR_XFP

Connector Type : LC

Wavelength(nm) : 1310

Transfer Distance(km) : 10(SMF)

Digital Diagnostic Monitoring : YES

Vendor Name : H3C.

c. 通过命令display transceiver diagnosis interface查询光模块的实时接收、发送光功率。

<Sysname> display transceiver diagnosis interface

Ten-GigabitEthernet3/1/1 transceiver diagnostic information:

Current diagnostic parameters:

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

41 3.26 42.43 -40.00 -2.20

d. 通过display transceiver interface或display transceiver diagnosis interface命令查询光模块的接收发送光功率的上下门限值。

有可能出现通过这两个命令行都可以查询、且查询出来的接收发送光功率上下门限值存在差异的情况，此时请以范围最小的上下门限值为准。

display transceiver diagnosis interface命令还可以查询实时的接收发送光功率、温度及其上下门限值、电压及其上下门限值、偏置电流及其上下门限值，命令行中Current diagnostic parameters下数据表示光模块当前的温度、电压、偏置电流、接收光功率、发送光功率，Alarm thresholds下High、Low数据表示温度、电压、偏置电流、接收光功率、发送光功率的上下门限值。

<Sysname> display transceiver interface ten-GigabitEthernet 3/1/1

Ten-GigabitEthernet3/1/1 transceiver information:

Transceiver Type : 10G_BASE_SR_SFP

Connector Type : LC

Wavelength(nm) : 850

Transfer Distance(km) : 80(50um),20(62.5um),300(om3)

Digital Diagnostic Monitoring : YES

Vendor Name : H3C

Ordering Name : SFP-XG-SX-MM850-A

<Sysname> display transceiver diagnosis interface ten-GigabitEthernet 3/1/1

Ten-GigabitEthernet3/1/1 transceiver diagnostic information:

Current diagnostic parameters:

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

43 3.35 46.33 -3.60 -2.38

Alarm thresholds:

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

High 73 3.80 92.40 2.50 3.50

Low -3 2.81 1.00 -16.40 -11.20

Parameters when first used on N/A:

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

N/A N/A N/A N/A N/A

Total account of alarms: 0

Latest occurrence of different alarms:

Type Date Description

Temp. N/A N/A

Voltage N/A N/A

Bias N/A N/A

RX power N/A N/A

TX power N/A N/A

TX N/A N/A

RX N/A N/A

Others N/A N/A

Latest three alarms:

Date Description

N/A N/A

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

(4) 如仍无法确认，请将故障信息发送技术支持人员分析。

建议尽量使用H3C定制光模块。可通过display transceiver manuinfo命令来查询光模块的定制厂商信息，如果Vendor Name为H3C，说明是H3C定制光模块。

5.7 端口不可见

5.7.1 故障描述

端口不可见。

5.7.2 故障处理步骤

(1) 通过display device查看所在单板或子卡的状态，有可能是单板或子卡还处于启动状态，需保证单板和子卡状态为NORMAL。

<Sysname> display device

Slot No. Brd Type Brd Status Software Version

0 CSR07SRPUA1 Standby SR8800FS-CMW710-RXXXX

1 CSR07SRPUA1 Master SR8800FS-CMW710-RXXXX

2 CSPC-XP8LB Normal SR8800FS-CMW710-RXXXX

3 NONE Absent NONE

4 NONE Absent NONE

5 NONE Absent NONE

6 NONE Absent NONE

7 CMPE-1104 Normal SR8800FS-CMW710-RXXXX

Sub1 MIC-GP8L Normal

Sub2 MIC-SP4L Normal

Sub3 NONE Absent

Sub4 MIC-GP4L Normal

(2) 如果单板或子卡已经恢复配置，再查看当前的接口信息中是否有目标端口。

<Sysname> display interface brief

Brief information on interface(s) under route mode:

Link: ADM - administratively down; Stby - standby

Protocol: (s) - spoofing

Interface Link Protocol Main IP Description

XGE3/1/1 DOWN DOWN --

XGE3/1/1.1 DOWN DOWN 110.0.1.1

XGE3/1/1.2 DOWN DOWN 110.0.2.1

XGE3/1/1.3 DOWN DOWN 110.0.3.1

XGE3/1/1.4 DOWN DOWN 110.0.4.1

XGE3/1/1.5 DOWN DOWN 110.0.5.1

XGE3/1/1.6 DOWN DOWN 110.0.6.1

XGE3/1/1.7 DOWN DOWN 110.0.7.1

XGE3/1/1.8 DOWN DOWN 110.0.8.1

XGE3/1/1.9 DOWN DOWN 110.0.9.1

XGE3/1/1.10 DOWN DOWN 110.0.10.1

XGE3/1/1.11 DOWN DOWN 110.0.11.1

XGE3/1/1.12 DOWN DOWN 110.0.12.1

XGE3/1/1.13 DOWN DOWN 110.0.13.1

(3) 有的子卡支持类型切换，接口类型不匹配时，需要手工切换。如：1602单板插的是GP20L子卡，子卡更换为XP20L后，端口类型是GE的，非10GE，想用10GE接口需要命令行切换。

(4) 如查不到端口，有可能是还在配置恢复过程中，需耐心等待一段时间，如过了较长时间后问题仍没有消除，请将故障信息发送技术支持人员分析。

5.8 WAN口协议不up

5.8.1 故障描述

WAN口物理链路能up，但协议不up。

5.8.2 故障处理步骤

(1) 检查WAN口两端配置协议是否一致。如果不一致，需配置成相同的协议。

(2) 通过display interface查看两端端口上是否有错包，两端端口配置是否一致。如果有错包计数，请检查下光模块是否和该端口匹配，检查光纤和光模块是否良好。如果两端端口的配置不一致，请配置成一致。

(3) 如仍无法解决，请将故障信息发送技术支持人员分析。

5.9 WAN口物理不up

5.9.1 故障描述

WAN口物理链路不up。

通过display interface pos命令查看接口的信息，Alarm字段出现告警。

<Sysname> display interface pos 3/1/1

Pos3/1/1

Current state: DOWN

Line protocol state: DOWN

Description: pos-interface

Bandwidth: 155520 kbps

Maximum transmission unit: 1500

Hold timer: 10 seconds, retry times: 5

Dampening enabled:

Penalty: 0 (not suppressed)

Ceiling: 6000

Reuse: 750

Suppress: 2000

Half-life: 54 seconds

Max-suppress-time: 162 seconds

Flap count: 0

Internet protocol processing: Disabled

Link layer protocol: PPP

LCP: initial

Port priority: 0

Last link flapping: Never

Last clearing of counters: Never

Current system time:2017-12-15 17:18:19

Last time when physical state changed to up:-

Last time when physical state changed to down:2017-12-11 09:57:36

Port connector type is No connector

Physical layer is packet over SDH

Port speed type: STM-1

Loopback is not set

FCS: 32-bit CRC

Clock source: Slave

Clock grade: Quality unknown(existing synchronization network)

SPE scrambling: Enable

BER thresholds:

SD: 10e-6 SF: 10e-4

Regenerator section layer:

J0(TX): "SR8800"

53 52 38 38 30 30 00 00 00 00 00 00 00 00 00 00

J0(RX): ""

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Alarm: LOS

Error: 0 BIP(B1)

Multiplex section layer:

Alarm: None

Error: 0 BIP(B2), 0 REI(M1)

Higher order path layer:

C2(TX): 0x16 C2(RX): 0xef

J1(TX): "SR8800"

53 52 38 38 30 30 00 00 00 00 00 00 00 00 00 00

J1(RX): ""

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Alarm: None

Error: 0 BIP(B3), 0 REI(G1)

0 PJE, 0 NJE

Port statistic:start time: 2017-12-11 09:57:46

UP time: 0 H 0 M 0 S

Section: ES 0 SES 0 SEFS 0

Line : ES 0 SES 0 UAS 0 FE-ES 0

Input speed in last 300 seconds: 0 packets/s, 0 bytes/s

Output speed in last 300 seconds: 0 packets/s, 0 bytes/s

Input: 0 packets, 0 bytes(good), 0 bytes(all)

0 FCS errors, 0 Aborts, 0 FIFO overflow

0 Runts, 0 Giants

Output: 0 packets, 0 bytes(good), 0 bytes(all)

0 FIFO underflow, 0 Aborts, 0 Runts

Peak value of input: 0 bytes/sec, at 2017-12-15 00:01:34

Peak value of output: 0 bytes/sec, at 2017-12-15 00:01:34

5.9.2 故障处理步骤

1. Alarm字段出现LOF（loss of framer）告警

出现LOF告警表示出现了帧丢失问题，表明传输的信号质量较差。

(1) 查看两端POS接口速率是否一致。若两端POS接口速率不一致，请重新配置两端POS接口速率，保持一致。

(2) 查看光模块类型与POS接口速率是否匹配，低速率光模块不能用于高速率POS接口，若光模块类型与POS接口速率不匹配，请更换及时光模块。

(3) 查看光纤是否损坏，若光纤出现损坏，请及时更换光纤。

(4) 如仍无法解决，请将故障信息发送技术支持人员分析。

2. Alarm字段出现LOS（loss of single）告警

如果POS接口收不到光信号或者连续收到LOF告警，就会产生LOS告警。

(1) 查看POS接口光模块是否安插正常。若未安插光模块或者光模块接触不良，请保证光模块安插正常。

(2) 查看POS接口光纤是否安装插正常。若未插光纤或者收发光纤插反，请保证光纤安插正常。

(3) 查看光纤是否损坏。若光纤出现损坏，请及时更换光纤。

(4) 查看两端POS接口速率是否一致。若两端POS接口速率不一致，请重新配置两端POS接口速率，保持一致。

(5) 查看光模块类型与POS接口速率是否匹配。低速率光模块不能用于高速率POS接口，若光模块类型与POS接口速率不匹配，请更换及时光模块。

(6) 查看对端POS接口是否关闭。若对端POS接口已关闭，请开启的对端POS接口。

(7) 查看对端POS接口是否使能了内部环回功能。若使能了内部环回功能，则需要去使能内部环回功能。

(8) 查看光纤与光模块是否匹配，若不匹配，请更换光纤或者光模块。

(9) 如仍无法解决，请将故障信息发送技术支持人员分析。

5.10 WAN口打印告警信息

5.10.1 故障描述

WAN口打印告警信息，如：

H3C WAN/4/ALARM: -Slot=3;

Cpos3/1/1 : Path 1 Alarm AIS report! Start Time : 2021-04-04 11:40:53:533!

H3C WAN/4/ALARM: -Slot=3;

Cpos3/1/1 : Path 1 Alarm AIS recover! Start Time : 2021-04-04 11:41:09:769!

5.10.2 故障处理步骤

通过display interface pos命令查看接口的Alarm字段的告警信息。各告警标志的处理方法请参见表5-2。

表5-2 告警标志处理方法

告警标志	说明	处理方法
LOF	表示出现了帧丢失问题，表明传输的信号质量较差	参见5.9.2 1.
LOS	POS接口收不到光信号或者连续收到LOF告警	参见5.9.2 2.
PSLM	本端和对端的信号标记字节C2配置不一致	重新配置本端和对端的信号标记字节C2，使其保持一致
PTIM	本端和对端的SONET/SDH帧的通道踪迹字节J1配置不一致	重新配置本端和对端的SONET/SDH帧的通道踪迹字节J1，使其保持一致
PRDI	本端和对端的信号标记字节C2配置不一致或者SONET/SDH帧的通道踪迹字节J1配置不一致	重新配置本端和对端的信号标记字节C2或者SONET/SDH帧的通道踪迹字节J1，使其保持一致

如果上述检查完成后故障仍无法排除，可通过display diagnostic-information命令收集设备的diagnostic-information，联系H3C的技术支持工程师。

<H3C> display diagnostic-information

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

5.11 隧道接口故障处理

5.11.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. 故障分析

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

图5-1 隧道接口不稳定故障诊断流程图

4. 处理步骤

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

通过debugging tunnel event命令打开隧道事件调试开关，如果持续出现路由刷新或删除消息，说明路由出现震荡，此时隧道也会震荡。示例如下：

<Sysname> debugging tunnel event

<Sysname> %Jun 16 12:49:55:497 2022 Sysname BGP/5/BGP_STATE_CHANGED: 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: 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报文。

在任意视图下执行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:

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:

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:

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:

Tunnel2 : Received a keepalive packet.

// Tunnel2收到keepalive报文

在对端设备上同样打开GRE报文调试开关，如果对端显示发出了keepalive报文，本端却未收到，则GRE报文可能未通过本端的校验和检查。无法收到keepalive报文会导致隧道接口down，可以尝试通过undo gre checksum命令关闭本端GRE报文的校验和功能或通过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:

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:

Processing result of operation 4 for Tunnel2: failed.

// 隧道接口Tunnel2下发的Operation 4处理失败

%Jun 16 12:51:25:832 2022 Sysname IFNET/3/PHY_UPDOWN: Physical state on the interface Tunnel2 changed to down.

%Jun 16 12:51:25:832 2022 Sysname IFNET/5/LINK_UPDOWN: Line protocol state on the interface Tunnel2 changed to down.

// 隧道Tunnel2接口down

*Jun 16 12:51:27:350 2022 Sysname TUNNEL/7/event:

Tunnel2 can't come up because there is not enough hardware resource

// 由于硬件资源不足，隧道Tunnel2不能up

当设备打印的如下的event或error信息时，表示硬件是故障导致隧道工作不稳定，此时请联系技术支持。

表5-3 硬件相关的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. 告警与日志

5.12 故障诊断命令

命令	说明
display current-configuration	显示设备当前生效的配置，指定interface可以显示指定接口当前生效的配置
display interface	查询端口的入、出方向流量统计信息、端口状态。可查看是否存在错包及错包统计信息。
display transceiver alarm interface	显示可插拔接口模块的当前故障告警信息
display transceiver diagnosis	显示可插拔光模块的数字诊断参数的当前测量值，包括温度、电压、偏置电流、接收光功率、发送光功率
display transceiver interface	显示指定接口可插拔接口模块的主要特征参数。检查两端光模块类型是否一致，如速率、波长、单模多模状态等
display transceiver manuinfo	显示可插拔接口模块的电子标签信息。可用来查询光模块的定制厂商。

6 二层技术-以太网交换类故障处理

6.1 MAC地址学习故障

6.1.1 故障描述

故障现象通常为端口没有学习到报文的源MAC地址。

6.1.2 故障处理步骤

1. 检查源MAC地址的正确性

通过display mac-address或display l2vpn mac-address命令检查源MAC地址。

源MAC地址学习仅支持单播MAC地址，不支持组播MAC地址、不支持全0的MAC地址。MAC地址的第一个字节最低为0是单播MAC地址，如00-00-00-00-00-01，组播MAC地址为01-00-00-00-00-01。

2. 检查源MAC老化时间的正确性

使用display mac-address aging-time命令查看MAC地址的老化时间，如果配置的老化时间过低，MAC地址的数量很大，会出现MAC地址被快速老化删除的情况。

[Sysname] display mac-address aging-time

MAC address aging time: 10s.

[Sysname] display l2vpn mac-address count

875613 mac address(es) found.

3. 检查端口状态

端口状态为down时，不会学习MAC地址。使用display interface命令查看端口的状态。

[Sysname] display interface ten-gigabitEthernet 3/1/1

Ten-GigabitEthernet3/1/1

Current state: DOWN

Line protocol state: DOWN

...

4. 检查端口是否有流量进入

端口没有流量进入时，不会学习MAC地址。使用display counters inbound命令查看端口是否有流量进入。

<Sysname> display counters inbound interface ten-gigabitEthernet 3/1/1

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

XGE3/1/1 0 0 0 0

Overflow: More than 14 digits (7 digits for column "Err").

--: Not supported.

5. 检查设备是否出现迁移流量

迁移流量指两条源MAC地址相同的流量进入不同的端口时，MAC地址会在两个端口之前来回迁移。如果配置了聚合接口并且按报文的目的IP地址进行聚合负载分担（destination-ip），当源MAC地址相同但目的IP地址不同的报文进入该聚合接口时，可能会出现迁移流量，导致其中一个成员端口学习到的MAC地址迁移到另一个成员端口。

使用display link-aggregation load-sharing mode命令查看全局采用的聚合负载分担类型，如果为destination-ip类型，请联系技术支持。

6.2 以太网链路聚合故障处理

6.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协议交互情况。

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

图6-1 聚合接口无法UP的故障诊断流程图

4. 处理步骤

(1) 排查物理连线是否准确。

根据聚合接口的组网规划进行线路检查，确认物理链接线路是否完全按照规划连接。

如果物理连线正确，则执行步骤(2)。

(2) 聚合接口是否被手工关闭。

执行display interface命令查看聚合接口的物理状态，如果显示为“Administratively DOWN”，则表示聚合接口被手工关闭，请执行undo shutdown命令开启聚合接口。如果聚合接口未被手工关闭，则执行步骤(3)。

(3) 聚合组中成员端口是否UP。

执行display interface命令查看聚合组中的成员端口是否处于UP状态，如果没有UP，请按照端口不UP故障流程处理。

如果端口处于UP状态，则执行步骤(4)。

以如下显示为例，二层聚合组1中成员端口Ten-GigabitEthernet3/1/1处于非选中状态。执行display interface命令查看Ten-GigabitEthernet3/1/1的物理状态时，物理状态显示为“DOWN”，使成员端口Ten-GigabitEthernet3/1/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

XGE3/1/1 U 32768 1

<Sysname> display interface ten-gigabitethernet 3/1/2

Ten-GigabitEthernet3/1/2

Current state: DOWN

Line protocol state: DOWN

IP packet frame type: Ethernet II, hardware address: 2a41-21c1-0100

Description: Ten-GigabitEthernet3/1/2 Interface

Bandwidth: 10000000 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

XGE3/1/1 S 32768 61 2 {ACDEF}

XGE3/1/2 S 32768 62 2 {ACDEF}

XGE3/1/3 S 32768 63 2 {ACDEF}

Remote:

Actor Priority Index Oper-Key SystemID Flag

XGE3/1/1(R) 32768 111 2 0x8000, 000f-e267-57ad {ACDEF}

XGE3/1/2 32768 112 2 0x8000, 000f-e267-57ad {ACDEF}

XGE3/1/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)。

打开聚合组成员端口Ten-GigabitEthernet3/1/1的LACP报文调试信息开关，查看该端口收发LACP协议报文的情况。

<Sysname> debugging link-aggregation lacp packet all interface ten-gigabitethernet 3/1/1

*Nov 2 15:51:21:15 2007 Sysname LAGG/7/Packet: PACKET.Ten-GigabitEthernet3/1/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.Ten-GigabitEthernet3/1/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

XGE3/1/1 U 32768 1

(6) 聚合组内是否存在选中的成员端口。

如果聚合组内不存在选中的成员端口，则请参见“6.2.3 聚合成员端口无法选中”故障进行定位；如果聚合组内存在选中的成员端口，则执行步骤(7)。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

6.2.2 聚合接口流量负载分担不均

1. 故障描述

当两台设备通过链路聚合连接时，通过display counters rate命令查看聚合成员端口出方向流量速率，某些成员端口速率特别小或者根本没有。

2. 常见原因

本类故障的常见原因主要为聚合负载分担方式配置错误。

3. 故障分析

本类故障的诊断思路为确认聚合接口转发的报文的特征，并查看聚合负载分担类型是否和报文特性匹配。

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

图6-2 聚合接口流量负载分担不均的故障诊断流程图

4. 处理步骤

(1) 用户业务流量是否正常。

如果用户业务流量正常，则等待一段时间，再执行display counters rate命令查看聚合成员端口出方向流量速率，确认聚合成员端口流量是否恢复负载分担：

¡ 如果已恢复负载分担，则无需处理。

¡ 如果未恢复负载分担，则执行步骤(2)。

如果用户业务流量不正常，则执行步骤(2)。

(2) 查看聚合负载分担类型与报文特征是否匹配。

通过执行display link-aggregation load-sharing mode命令查看聚合负载分担类型，如果与报文特征不匹配，则通过在系统视图下执行link-aggregation global load-sharing mode命令调整全局的负载分担类型。

针对不同业务流量，不同产品调整的负载分担类型不同，请以设备实际情况为准。

如果聚合负载分担类型与报文特征匹配，则执行步骤(3)。

(3) 检查是否部署跨板/跨框聚合。

在IRF环境下，如果部署跨板/跨框聚合，则在系统视图下使用undo link-aggregation load-sharing mode local-first命令关闭本地优先转发功能。如果关闭本地优先转发功能，则可能导致跨板/跨框流量不能过大，影响IRF系统稳定，请根据实际情况进行操作。

如果未部署跨板/跨框聚合，则执行步骤(4)。

需要注意，跨板/跨框流量不能过大，否则可能影响IRF系统稳定。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

6.2.3 聚合成员端口无法选中

1. 故障描述

当两台设备通过链路聚合连接时，发现聚合组成员端口处于非选中状态，聚合失败。

2. 常见原因

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

· 链路连通性故障。

· 本端和对端的操作key、属性类配置不一致。

· 聚合成员端口数配置错误。

3. 故障分析

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

(1) 查看成员端口是否UP，排除端口物理故障影响。

(2) 使用debugging link-aggregation lacp packet命令查看动态聚合的成员端口LACP协议交互情况。

(3) 检查本端和对端聚合接口配置，排除配置影响。

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

图6-3 聚合成员端口无法选中的故障诊断流程图

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

XGE3/1/1(R) S 32768 1 1 {ACDEF}

XGE3/1/2 S 32768 2 1 {ACDEF}

XGE3/1/3 U 32768 3 2 {AC}

Remote:

Actor Priority Index Oper-Key SystemID Flag

XGE3/1/1 32768 1 1 0x8000, 36f6-c0aa-0200 {ACDEF}

XGE3/1/2 32768 2 1 0x8000, 36f6-c0aa-0200 {ACDEF}

XGE3/1/3 32768 3 1 0x8000, 36f6-c0aa-0200 {AC}

b. 执行display current-configuration interface命令查看本端处于Unselected状态的成员端口的属性类配置（VLAN等配置）与聚合接口是否相同，如果不同，则将其配置相同。

以如下显示为例，处于Unselected状态的成员端口Ten-GigabitEthernet3/1/3与参考端口Ten-GigabitEthernet3/1/1的属性类配置不同，导致该成员端口无法选中，需要修改成员端口Ten-GigabitEthernet3/1/3的属性类配置。

<Sysname> display current-configuration interface ten-gigabitethernet 3/1/1

interface Ten-GigabitEthernet3/1/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 bridge-aggregation 1

interface Bridge-Aggregation1

port link-type trunk

port trunk permit vlan 1 to 100

link-aggregation mode dynamic

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

XGE3/1/1(R) S 32768 1 1 {ACDEF}

XGE3/1/2 S 32768 2 1 {ACDEF}

XGE3/1/3 U 32768 3 2 {AC}

Remote:

Actor Priority Index Oper-Key SystemID Flag

XGE3/1/1 32768 1 1 0x8000, 36f6-c0aa-0200 {ACDEF}

XGE3/1/2 32768 2 1 0x8000, 36f6-c0aa-0200 {ACDEF}

XGE3/1/3 32768 3 1 0x8000, 36f6-c0aa-0200 {AC}

b. 执行display current-configuration interface命令查看本端处于Unselected状态的成员端口的操作key（包括该端口的速率、双工模式等）与参考端口是否相同，如果不同，则将其配置相同。

以如下显示为例，处于Unselected状态的成员端口Ten-GigabitEthernet3/1/3与参考端口Ten-GigabitEthernet3/1/1的操作key不同，导致该成员端口无法选中，需要修改该端口速率配置。

<Sysname> display current-configuration interface ten-gigabitethernet 3/1/1

interface Ten-GigabitEthernet3/1/1

port link-mode bridge

combo enable fiber

port link-aggregation group 11

return

<Sysname> display current-configuration interface ten-gigabitethernet 3/1/3

interface ten-GigabitEthernet3/1/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)。

打开聚合组成员端口Ten-GigabitEthernet3/1/1的LACP报文调试信息开关，查看该端口收发LACP协议报文的情况。

<Sysname> debugging link-aggregation lacp packet all interface ten-gigabitethernet 3/1/1

*Nov 2 15:51:21:15 2021 Sysname LAGG/7/Packet: PACKET.Ten-GigabitEthernet3/1/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.Ten--GigabitEthernet3/1/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. 告警与日志

6.3 VLAN转发故障

6.3.1 故障描述

故障现象通常有二层VLAN单播、广播业务异常。

6.3.2 故障处理步骤

1. 检查生成树协议的状态

使用display stp brief命令查看设备上是否开启了生成树协议。

[Sysname] display stp brief

MST ID Port Role STP State Protection

0 Bridge-Aggregation1 DESI FORWARDING NONE

0 Ten-GigabitEthernet3/1/1 DESI LEARNING NONE

如果因为开启了生成树协议导致二层VLAN流量不通，可以使用undo stp global enable命令全局关闭生成树协议。

2. 检查VLAN配置的正确性

通过display interface命令检查端口是否允许打入流量的VLAN通过。如果端口未允许打入流量的VLAN通过，则需要在端口下配置允许该VLAN通过。

3. 检查QinQ配置的正确性

使用display qinq命令检查端口是否使能了QinQ。

当端口上配置了QinQ功能后，不论从该端口收到的报文是否带有VLAN Tag，设备都会为该报文添加本端口PVID的Tag。注意此时该端口打入流量的实际生效VLAN是QinQ功能封装的VLAN。

6.4 生成树故障处理

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

1. 故障描述

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

2. 常见原因

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

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

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

3. 故障分析

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

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

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

XGE3/1/1 UP auto A A 1

XGE3/1/2 DOWN auto A A 1

XGE3/1/3 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 ten-gigabitethernet 3/1/2

Ten-GigabitEthernet3/1/2

Current state: UP

Line protocol state: DOWN(LAGG)

...

DOWN(protocols)表示接口的数据链路层被一个或者多个协议模块关闭。protocols为多个协议的任意组合，可能的协议如下：

- DLDP：由于DLDP模块检测到单通而关闭接口的数据链路层。

- OAM：由于以太网OAM模块检测到远端链路故障而关闭接口的数据链路层。

- LAGG：聚合接口中没有选中的成员端口而关闭接口的数据链路层。

- BFD：由于BFD模块检测到链路故障而关闭接口的数据链路层。

- 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

----[Port1(Ten-GigabitEthernet3/1/1)][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(Ten-GigabitEthernet3/1/2)][DISABLED]----

Port protocol : Disabled

...

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

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

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

1. 故障描述

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

2. 常见原因

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

3. 故障分析

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

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

4. 处理步骤

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

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

<Sysname> display stp

...

----[Port2(Ten-GigabitEthernet3/1/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 Ten-GigabitEthernet3/1/1, because loop-protection is enabled.

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

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

1. 故障描述

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

2. 常见原因

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

3. 故障分析

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

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

图6-6 非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. 告警与日志

6.4.4 生成树网络震荡

1. 故障描述

网络中设备的生成树根桥、端口角色及端口状态反复变化，无法保持稳定，导致网络拓扑不断变化。

2. 常见原因

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

· 链路震荡：网络上某个端口的链路属性，如端口状态、速率和双工模式等持续变化。

· 节点故障：网络中设备的CPU占用率较高，无法及时处理生成树报文；或设备反复重启，造成生成树不断重新计算。

· 网络故障，包括：

¡ 报文转发出现拥塞，导致BPDU丢失。

¡ 错误地收到了其他网络的BPDU，引发当前网络的生成树重新计算。

¡ 网络中设备配置的其他功能导致BPDU被错误地丢弃。

3. 故障分析

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

图6-7 生成树网络震荡的故障诊断流程图

4. 处理步骤

(1) 检查生成树网络中是否有设备发生CPU占用率过高、重启或接口链路的状态发生了变化。

根据网络的部署，请网络管理员自行通过控制器、设备管理平台、用户接口等方式查看是否存在设备发生重启、CPU占用率过高或物理链路状态的变化。

如果设备状态和链路状态均恢复稳定后，故障仍不能排除，请执行步骤（2）。

(2) 检查生成树网络的根桥是否发生了变化。

在生成树网络中的任意设备上执行display stp root命令，查看当前生成树网络中的根桥。例如：

<Sysname> display stp root

MST ID Root Bridge ID ExtPathCost IntPathCost Root Port

0 32768.14e3-19d3-0100 0 40 XGE3/1/2

10 0.14e3-19d3-0100 0 40 XGE3/1/2

20 0.14e3-1f59-0200 0 0

其中Root Bridge ID字段表示生成树网络中根桥的编号，根桥编号的组成形式为优先级.桥MAC地址，网络管理员可以根据该字段判断生成树网络中的根桥是否为需要的设备。如果网络中的根桥设备正确，但生成树网络仍然不断震荡，请执行步骤（3）；如果网络中的根桥设备不是网络管理员需要的设备，可以通过以下方式修改根桥：

¡ 修改设备的优先级。设备的优先级参与生成树计算，数值越小表示优先级越高，网络管理员可配置stp priority命令，将指定设备的优先级设置为0或较小的值，以达到指定设备成为生成树根桥的目的。

¡ 通过在设备上执行stp root primary命令，将该设备指定为生成树的根桥。

网络管理员将需要的设备配置为根桥后，可以通过以下功能维护根桥以及网络拓扑的稳定：

¡ 开启根保护功能

在接口视图下配置stp root-protection命令后，此接口在所有MSTI上的端口角色只能为指定端口。一旦该端口收到某MSTI优先级更高的BPDU，立即将该MSTI端口设置为侦听状态，不再转发报文（相当于将此端口相连的链路断开）。当在2倍的Forward Delay时间（缺省情况下Forward Delay时间为15秒）内没有收到更优的BPDU时，端口会恢复原来的正常状态。根保护功能可以避免错误配置或恶性攻击导致的生成树拓扑不合法的变动。

¡ 配置边缘端口和BPDU保护

对于接入层设备，接入端口一般直接与用户终端（如PC）或文件服务器相连，此时接入端口应被设置为边缘端口以实现这些端口的快速迁移。正常情况下，接入端口不应该与用户终端交互生成树协议的BPDU报文，如果收到BPDU报文可能会引起网络拓扑结构的变化，造成生成树网络震荡。

生成树协议提供了BPDU保护功能来解决这类问题：在全局视图下配置stp bpdu-protection命令后，如果边缘端口收到了BPDU，系统就将这些端口关闭，同时通知用户这些端口已被生成树协议关闭。被关闭的端口在经过一定时间间隔之后将被重新激活，这个时间间隔可通过shutdown-interval命令配置。

¡ 配置环路保护

下游设备依靠不断接收上游设备发送的BPDU来维持根端口和其他阻塞端口的状态。如果出现了链路拥塞或者单向链路故障，这些端口会收不到上游设备的BPDU，此时下游设备会重新选择端口角色，导致下游设备的根端口转变为指定端口，而阻塞端口会迁移到转发状态，交换网络中出现环路。

在下游设备的根端口和替换端口上通过stp loop-protection命令配置环路保护功能后，可以抑制上述环路的产生。在开启了环路保护功能的端口上，其所有MSTI的初始状态均为Discarding状态：如果该端口收到了BPDU，这些MSTI可以进行正常的状态迁移；否则，这些MSTI将一直处于Discarding状态以避免环路的产生。

需要注意的是，无需在与用户终端相连的端口上配置环路保护功能，否则该端口会因一直处于Discarding状态而无法正常转发用户报文。

¡ 配置防TC-BPDU攻击保护功能

在遭受到TC-BPDU恶意攻击行为时，设备会频繁地刷新转发地址表项。此类攻击给设备带来了很大负担，随时威胁着网络的稳定性。此时可以开启防TC-BPDU攻击保护功能，以避免频繁地刷新转发地址表项。在系统视图下执行stp tc-protection命令，可以开启防TC-BPDU攻击保护功能；在系统视图下执行stp tc-protection threshold number命令，可以配置在单位时间（固定为十秒）内，设备收到TC-BPDU后立即刷新转发地址表项的最高次数。

开启防TC-BPDU攻击保护功能后，如果设备在单位时间（固定为十秒）内收到TC-BPDU的次数大于number次，那么该设备在这段时间之内将只进行number次刷新转发地址表项的操作，而对于超出number次的那些TC-BPDU，设备会在这段时间过后再统一进行一次地址表项刷新的操作。

如果故障仍不能排除，请执行步骤（3）。

(3) 排查是否存在BPDU超时情况。

检查设备是否输出STP_BPDU_RECEIVE_EXPIRY日志，该日志描述设备在BPDU超时时间内没有收到任何BPDU报文，从而引发生成树重新计算。引发BPDU超时的原因可能是网络中BPDU报文转发出现了拥塞，或者设备中存在其他配置导致BPDU报文被错误丢弃。

为了更精确地定位故障，请执行步骤（4）。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

7 二层技术-广域网接入类故障处理

7.1 PPP故障处理

7.1.1 PPP接口协议DOWN

1. 故障描述

当两台设备的PPP物理接口连接完成后，接口的链路层协议状态显示为DOWN。

2. 常见原因

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

· 接口的物理层状态没有UP。

· 链路两端接口上的PPP相关配置错误。

· PPP协议报文被丢弃。

· 链路存在环路。

· 链路时延过大。

3. 故障分析

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

图7-1 PPP接口协议DOWN的故障诊断流程图

4. 处理步骤

(1) 检查接口物理状态是否UP。

在任意视图下执行display interface interface-type interface-number命令查看本端接口物理状态：

¡ 如果本端接口物理状态为Administratively DOWN，表示本端接口被shutdown命令关闭，请在本端接口视图下执行undo shutdown命令取消关闭。

¡ 如果本端接口物理状态为DOWN，请检查对端接口是否被shutdown命令关闭，如是，请在对端接口视图下执行undo shutdown命令取消关闭。

¡ 请检查两端光纤/光模块是否插好、光纤收/发是否插正确等，并解决接口物理状态DOWN问题。

¡ 对于通过CPOS、E1等接口的通道创建出来的串口，还需检查对应CPOS接口、E1接口等接口上配置是否正确。

¡ 如果接口状态为UP，请继续执行下一步。

(2) 检查链路两端的PPP配置是否正确。

在PPP协议DOWN的接口所在视图下执行display this命令查看当前接口的PPP相关配置。

[Sysname-Serial3/1/1:0] display this

interface Serial3/1/1:0

ip address 12.1.1.1 255.255.255.0

return

¡ 检查两端接口的链路层协议，确保两端接口配置的链路层协议都为PPP，具体为：分别在两端设备任意视图下执行display interface interface-type interface-number命令查看两端接口的显示信息中“Link layer protocol”字段取值是否为“PPP”，若不是PPP，请在相应接口视图下执行link-protocol ppp命令配置为PPP。

¡ 如果配置了PPP认证，检查认证方与被认证方的认证类型、认证用户名/密码是否相同，如果不同，请参考PPP配置指导修改。

¡ 如果两端接口加入了MP-group，请检查对应MP-group接口是否被shutdown命令关闭如是，请在MP-group接口视图下执行undo shutdown命令取消关闭。

¡ 如果一端接口配置了remote address命令，请确保另一端接口配置了ip address ppp-negotiate命令或通过ip address命令手工配置了对端remote address命令指定的IP地址。

如果PPP配置正确，但PPP接口协议仍为DOWN，请继续执行下一步。

(3) 检查接口的协议报文收发是否正常。

在任意视图下执行display ppp packet statistics命令查看PPP协议报文的统计信息，并确认报文收发是否正常。

<Sysname> display ppp packet statistics slot 3

PPP packet statistics in slot 3:

-----------------------------------LCP--------------------------------------

SEND_LCP_CON_REQ : 4 RECV_LCP_CON_REQ : 5

SEND_LCP_CON_NAK : 0 RECV_LCP_CON_NAK : 0

SEND_LCP_CON_REJ : 0 RECV_LCP_CON_REJ : 0

SEND_LCP_CON_ACK : 4 RECV_LCP_CON_ACK : 4

SEND_LCP_CODE_REJ : 0 RECV_LCP_CODE_REJ : 0

SEND_LCP_PROT_REJ : 0 RECV_LCP_PROT_REJ : 0

SEND_LCP_TERM_REQ : 2 RECV_LCP_TERM_REQ : 1

SEND_LCP_TERM_ACK : 1 RECV_LCP_TERM_ACK : 0

SEND_LCP_ECHO_REQ : 25 RECV_LCP_ECHO_REQ : 0

SEND_LCP_ECHO_REP : 0 RECV_LCP_ECHO_REP : 25

SEND_LCP_FAIL : 0 SEND_LCP_CON_REQ_RETRAN : 0

-----------------------------------IPCP-------------------------------------

SEND_IPCP_CON_REQ : 38 RECV_IPCP_CON_REQ : 2

SEND_IPCP_CON_NAK : 0 RECV_IPCP_CON_NAK : 0

SEND_IPCP_CON_REJ : 0 RECV_IPCP_CON_REJ : 0

SEND_IPCP_CON_ACK : 2 RECV_IPCP_CON_ACK : 2

SEND_IPCP_CODE_REJ : 0 RECV_IPCP_CODE_REJ : 0

SEND_IPCP_PROT_REJ : 0 RECV_IPCP_PROT_REJ : 0

SEND_IPCP_TERM_REQ : 0 RECV_IPCP_TERM_REQ : 0

SEND_IPCP_TERM_ACK : 0 RECV_IPCP_TERM_ACK : 0

SEND_IPCP_FAIL : 0

-----------------------------------IPV6CP-----------------------------------

SEND_IPV6CP_CON_REQ : 0 RECV_IPV6CP_CON_REQ : 0

SEND_IPV6CP_CON_NAK : 0 RECV_IPV6CP_CON_NAK : 0

SEND_IPV6CP_CON_REJ : 0 RECV_IPV6CP_CON_REJ : 0

SEND_IPV6CP_CON_ACK : 0 RECV_IPV6CP_CON_ACK : 0

SEND_IPV6CP_CODE_REJ : 0 RECV_IPV6CP_CODE_REJ : 0

SEND_IPV6CP_PROT_REJ : 0 RECV_IPV6CP_PROT_REJ : 0

SEND_IPV6CP_TERM_REQ : 0 RECV_IPV6CP_TERM_REQ : 0

SEND_IPV6CP_TERM_ACK : 0 RECV_IPV6CP_TERM_ACK : 0

SEND_IPV6CP_FAIL : 0

-----------------------------------OSICP------------------------------------

SEND_OSICP_CON_REQ : 0 RECV_OSICP_CON_REQ : 0

SEND_OSICP_CON_NAK : 0 RECV_OSICP_CON_NAK : 0

SEND_OSICP_CON_REJ : 0 RECV_OSICP_CON_REJ : 0

SEND_OSICP_CON_ACK : 0 RECV_OSICP_CON_ACK : 0

SEND_OSICP_CODE_REJ : 0 RECV_OSICP_CODE_REJ : 0

SEND_OSICP_PROT_REJ : 0 RECV_OSICP_PROT_REJ : 0

SEND_OSICP_TERM_REQ : 0 RECV_OSICP_TERM_REQ : 0

SEND_OSICP_TERM_ACK : 0 RECV_OSICP_TERM_ACK : 0

SEND_OSICP_FAIL : 0

-----------------------------------MPLSCP-----------------------------------

SEND_MPLSCP_CON_REQ : 0 RECV_MPLSCP_CON_REQ : 0

SEND_MPLSCP_CON_NAK : 0 RECV_MPLSCP_CON_NAK : 0

SEND_MPLSCP_CON_REJ : 0 RECV_MPLSCP_CON_REJ : 0

SEND_MPLSCP_CON_ACK : 0 RECV_MPLSCP_CON_ACK : 0

SEND_MPLSCP_CODE_REJ : 0 RECV_MPLSCP_CODE_REJ : 0

SEND_MPLSCP_PROT_REJ : 0 RECV_MPLSCP_PROT_REJ : 0

SEND_MPLSCP_TERM_REQ : 0 RECV_MPLSCP_TERM_REQ : 0

SEND_MPLSCP_TERM_ACK : 0 RECV_MPLSCP_TERM_ACK : 0

SEND_MPLSCP_FAIL : 0

-----------------------------------AUTH-------------------------------------

SEND_PAP_AUTH_REQ : 0 RECV_PAP_AUTH_REQ : 0

SEND_PAP_AUTH_ACK : 0 RECV_PAP_AUTH_ACK : 0

SEND_PAP_AUTH_NAK : 0 RECV_PAP_AUTH_NAK : 0

SEND_CHAP_AUTH_CHALLENGE: 0 RECV_CHAP_AUTH_CHALLENGE: 0

SEND_CHAP_AUTH_RESPONSE : 0 RECV_CHAP_AUTH_RESPONSE : 0

SEND_CHAP_AUTH_ACK : 0 RECV_CHAP_AUTH_ACK : 0

SEND_CHAP_AUTH_NAK : 0 RECV_CHAP_AUTH_NAK : 0

SEND_PAP_AUTH_FAIL : 0 SEND_CHAP_AUTH_FAIL : 0

¡ 如果接收或者发送的报文数量均为0，或者多次执行本命令发现显示的接收或者发送报文个数没有增长，说明协议报文在传输过程中发送丢包，请检查接口/光纤/光模块是否故障，解决报文丢失问题。如问题无法解决，请执行步骤（6）。

¡ 如果报文收发正常，请继续执行下一步。

(4) 检测链路是否存在环路。

在本端设备用户视图下执行debugging ppp all interface interface-type interface-number命令打开PPP的报文调试开关，查看本端是否存在报文内容完全（如报文类型、报文ID、MagicNumber取值等）相同的收发报文：

*Apr 7 19:38:04:384 2022 Sysname PPP/7/FSM_PACKET_0: -MDC=1-Slot=3;

PPP Packet:

Ser3/1/1:0(109) Output LCP(c021) Packet, PktLen 14

Current State reqsent, code ConfReq(01), id 0, len 10

MagicNumber(5), len 6, val c5 ae e7 03

*Apr 7 19:38:04:390 2022 Sysname PPP/7/FSM_PACKET_0: -MDC=1-Slot=3;

PPP Packet:

Ser3/1/1:0(109) Input LCP(c021) Packet, PktLen 14

Current State reqsent, code ConfReq(01), id 0, len 10

MagicNumber(5), len 6, val c5 ae e7 03

¡ 若存在，则表示链路有环路，请确认环路产生原因（例如光纤连接错误），并消除环路。如问题无法解决，请执行步骤（6）。

¡ 若不存在，则表示链路无环路，请继续执行下一步。

(5) 检查链路时延是否过大。

在本端设备用户视图下执行debugging ppp all interface interface-type interface-number命令打开PPP的报文调试开关，查看PPP协商报文的发送时间戳和接收时间戳之间的时间间隔来确定链路时延：

*Apr 7 19:38:04:384 2022 Sysname PPP/7/FSM_PACKET_0: -MDC=1-Slot=3;

PPP Packet:

Ser3/1/1:0(109) Output LCP(c021) Packet, PktLen 14

Current State reqsent, code ConfReq(01), id 0, len 10

MagicNumber(5), len 6, val c5 ae e7 03

*Apr 7 19:38:04:387 2022 Sysname PPP/7/FSM_PACKET_0: -MDC=1-Slot=3;

PPP Packet:

Ser3/1/1:0(109) Input LCP(c021) Packet, PktLen 14

Current State acksent, code ConfAck(02), id 0, len 10

MagicNumber(5), len 6, val c5 ae e7 03

确认链路的时延是否大于当前接口所配置的PPP协议报文的协商超时时间间隔（由接口视图下的ppp timer negotiate命令配置，缺省时间间隔为3秒）。

¡ 如果链路的时延过大，请执行ppp timer negotiate命令适当调大配置值，或者更换相应的设备/链路后重新检测链路的时延，直到链路的时延小于前接口的PPP协议报文协商超时值。

¡ 如果链路的时延不大，请继续执行下一步。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

8 三层技术-IP业务故障处理

8.1 ARP故障处理

8.1.1 无法学习到对端设备的ARP表项

1. 故障描述

无法学习到对端设备的ARP表项。

2. 故障处理步骤

(1) 查看ARP调试信息

使用debugging arp packet命令打开ARP调试信息开关，当对端ping本设备时，可以看到下列调试信息。如果未显示ARP请求报文信息，则说明未接收到请求报文；如果未显示ARP应答报文，则说明本设备未应答ARP请求。

<Sysname> *Sep 24 19:15:52:655 2019 H3C ARP/7/ARP_RCV: -MDC=1-Slot=5; Received an ARP message, operation: 1, sender MAC: 1cab-343a-6145,sender IP: 222.3.1.2, target MAC: 0000-0000-0000, target IP: 222.3.1.1

// 接收ARP请求报文

*Sep 24 19:15:52:656 2019 H3C ARP/7/ARP_SEND: -MDC=1-Slot=5; Sent an ARP message, operation: 2, sender MAC: 70f9-6da7-5074, sender IP: 222.3.1.1, target MAC: 1cab-343a-6145, target IP: 222.3.1.2

// 发送ARP应答报文

(2) 报文计数分析

· 如果设备未收到Ping报文，请排查上游的相邻设备；如果设备收到Ping报文，分析ARP报文在本端是否上送给平台。

· 对端ping本设备，本端设备使用display hardware internal rxpkt-in slot slotid cpu cpuid命令查看报文收发模块收到的上送报文：

[Sysname-probe] display hardware internal rxtx rxpkt-in slot 2 cpu 0

[H3C-probe] *Aug 11 08:34:41:006 2022 H3C RXTX/7/DBG: -MDC=1-Slot=2;

Time on LPU: 2022-08-11 08:34:41 5ms

Receive packet from chip :

DevNum = 9, PhyPortNo = 33, PacketLen = 60, CpuCode = 17, Left = 14

0000: ff ff ff ff ff ff 00 00 2e 3b f4 03 08 06 00 01

0010: 08 00 06 04 00 01 00 00 2e 3b f4 03 16 01 00 02

0020: 00 00 00 00 00 00 16 01 00 02 00 00 00 00 00 00

0030: 00 00 00 00 00 00 00 00 00 00 00 00 33 d4 92 9c

*Aug 11 08:34:41:007 2022 H3C RXTX/7/DBG: -MDC=1-Slot=2;

Time on LPU: 2022-08-11 08:34:41 7ms

Receive packet from chip :

DevNum = 9, PhyPortNo = 33, PacketLen = 60, CpuCode = 17, Left = 13

0000: ff ff ff ff ff ff 00 00 2e 3b f4 03 08 06 00 01

0010: 08 00 06 04 00 01 00 00 2e 3b f4 03 16 01 00 02

0020: 00 00 00 00 00 00 16 01 00 02 00 00 00 00 00 00

0030: 00 00 00 00 00 00 00 00 00 00 00 00 33 d4 92 9c

本端设备使用display hardware internal rxtx packet statistic slot slotid cpu cpuid命令查看报文收发模块上送CPU计数，

[Sysname-probe] display hardware internal rxtx packet statistic slot 2 cpu 0

Net port packet loss count:

code counter

Rx packets statistic:

counter success rate

NET -> RXTX : 6 6 0 pps

Cpu code input list:

code counter success

17 2 2

30 4 4

Callback function packets statistic:

total(r) success(r) total(c) success(c)

MACL: 0 0 0 0

NATL: 0 0 0 0

BFD: 0 0 0 0

Task input pkt statistics:

Task name total success

Main Task : 6 6

Icmp Task : 0 0

(3) 查看本机路由和Inlif表项

若报文收发模块没有收到报文，请查看本机路由和InLif表是否下发正确。

a. 检查本机路由下发是否正确，如果上送标记Th没有置位，请联系技术支持人员分析。

[H3C-probe] display hardware internal l3 np fib 22.1.0.1 32 slot 2 chip 0

The FTN/FIB table Handle<0xbb90> ECMPNum<0/1>!

ChipID is 0

FTN:

FTN KEY: VPNID = 0 IP_Prefix = 192.168.2.88/16777215

FTN RESULT:

00000411 000001ff 0103f240 00000000

Ipv4-route tag:

Valid = 1 M = 1 Local = 0

ECMP = 0 Th = 0 Normal = 1 Drop = 0

Dft_Sys = 0 Dft_User = 0

LifId = 1048575 OutlifID_ToHostID = 258624

Es = 0 Ts = 0 DhcpH = 0

TTL = 255 StackEnd1 = 1 StackEnd2 = 1

Label_v = 0 Label = 0 Label_bak = 0/Vni = 1

Rd = 0 Rq = 0 Dscp = 0 QosLocalId = 0

Mask = 0 BgpIdx = 0 SessionId = 0

OrgAs = 0 PeerAs = 0

GroupDscp = 0

SecLabelValid = 0

IsCbts = 0

BakOutlifValid = 0 BakOutlifId = 0

BakEcmpValid = 0 BakEcmpId = 0 BakEcmpSubId = 0 BakEcmpBasePoint = 0

RdVpnValid = 0 RdVpn = 0

Outlif Table : KEY(outlifid = 258624) RESULT(00001011, 004d0000, 00000000, 0000

b. 查看Inlif表项，L3，IPv4，ArpProxy是否置位，如果没置位，请联系技术支持人员分析。

[Sysname-probe] display hardware internal lif np inlif slot 2 GigabitEthernet 2/2/1

Inlif Table : KEY(vlan=4095,port=32)

RESULT(08060001, 0030d001, 00008000, 00000000, 00000000, 00000000, 00000000, 00000000)

RES:

un0.gen.uiSa:1 = 0

un0.gen.uiV4m:1 = 0

un0.gen.uiBlock:1 = 0

un0.gen.uiDs:1 = 0

un0.gen.uiV4Acl:1 = 1

un0.gen.uiV4Rpf:1 = 0

un0.gen.uiV4Qppb:1 = 0

un0.gen.uiV4Sq:1 = 0

un0.gen.uiMldv2:1 = 0

un0.gen.ui8021ag:1 = 0

un0.gen.uiRsvp:1 = 0

un0.gen.uiMpls:1 = 0

un0.gen.uiIf:1 = 0

un0.gen.uiIpv4:1 = 1

un0.gen.uiL3:1 = 1

un0.gen.uiL3Vpn:1 = 0

un0.gen.uiPppoe:1 = 0

…..

un2.gen.uiV6RpfL:1 = 0

un2.gen.uiV6RpfAcl:1 = 0

un2.gen.uiArpProxy:1 = 1

un2.gen.uiFrIsis:1 = 0

un2.gen.uiFrTh:1 = 0

un2.gen.uiV42Acl:1 = 0

8.1.2 无法学习到ARP表项

1. 故障描述

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

2. 常见原因

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

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

· 接口物理层未正常Up。

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

· ARP报文未上送到CPU。

· 单板存在故障。

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

3. 故障分析

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

图8-1 无法学习到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的错误调试信息开关，根据。表8-1中的内容确认设备无法成功发送或接收ARP报文的原因。

表8-1 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报文被丢弃。

(6) 请收集如下信息，并联系H3C技术支持工程师。

¡ 上述步骤的执行结果。

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

5. 告警与日志

8.1.3 不回应ARP请求报文

1. 故障描述

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

2. 常见原因

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

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

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

3. 故障分析

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

图8-2 不回应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的错误调试信息开关，根据表8-2中的内容确认设备不回应ARP报文的原因。

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

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

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

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

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

23f3-1122-3344 4094 XGE3/1/1 10

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

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

(3) 通过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

(4) 通过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-3 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：老化待删除状态

(5) 请收集如下信息，并联系H3C技术支持工程师。

¡ 上述步骤的执行结果。

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

5. 告警与日志

8.1.4 已有ARP表项但无法转发流量

1. 故障描述

设备已有ARP表项但无法正常转发流量。

2. 常见原因

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

· 学习到的ARP表项参数异常。

· 学习到的ARP表项没有成功下发驱动。

3. 故障分析

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

图8-3 已有ARP表项但无法转发流量故障诊断流程图

4. 处理步骤

(1) 检查ARP表项是否成功创建。通过display system internal adj4 entry命令查看ARP表项信息，以接口Ten-GigabitEthernet3/1/1、对端IP地址为1.1.1.2为例。

<Sysname> system-view

[Sysname] probe

[Sysname-probe] display system internal adj4 entry 1.1.1.2 interface ten-gigabitethernet 3/1/1 slot 0

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 : XGE3/1/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 : XGE3/1/1

Service type : Ethernet

Action type : Forwarding

Link media type : Broadcast

Physical interface : XGE3/1/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 : XGE3/1/1

Port interface : N/A

Slot : 0

MTU : 1500

VLAN ID : 65535

Second VLAN ID : 65535

Physical interface : XGE3/1/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技术支持工程师。

¡ 上述步骤的执行结果。

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

8.2 IP基础转发故障处理

8.2.1 链路异常，使用Ping/Tracert出现丢包或不通

1. 故障描述

故障现象通常有三层业务异常、ping/tracert丢包/不通。

2. 故障处理步骤

(1) 报文目的MAC检查

报文在路由器上进行三层转发的条件是报文的目的MAC为路由器本身的MAC。通过镜像或抓包确认这个条件是否满足，“镜像”的详细介绍，请参见“网络管理和监控配置指导”中的“镜像”。如下图，报文的目的MAC为路由器接口的MAC，说明报文目的MAC正确。

图8-4 报文目的MAC

<Sysname> display interface ten-gigabitethernet 3/1/2

Ten-GigabitEthernet3/1/2

Current state: UP

Line protocol state: UP

Description: Ten-GigabitEthernet3/1/2 Interface

Bandwidth: 1000000kbps

Maximum Transmit Unit: 1500

Internet Address is 10.0.0.1/24 Primary

IP Packet Frame Type:PKTFMT_ETHNT_2, Hardware Address: 7425-8a02-4d00

IPv6 Packet Frame Type:PKTFMT_ETHNT_2, Hardware Address: 7425-8a02-4d00

Media type is not sure, Port hardware type is 10G_BASE_SR_SFP

Port priority: 0

Last clearing of counters: Never

Last 300 seconds input: 20 packets/sec 2565 bytes/sec 0%

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

Input (total): 219479 packets, 28092544 bytes

219476 broadcasts, 0 multicasts, - pauses

Input (normal): 219479 packets, 28092544 bytes

- broadcasts, - multicasts, 0 pauses

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

0 CRC, 0 frame, 0 overruns, - aborts

0 ignored, - parity errors

Output (total): 4608 packets, 316764 bytes

3378 broadcasts, 1154 multicasts, - pauses

(2) 路由表检查

检查设备到某一目的IP网段的路由是否存在，如路由不存在，请检查路由协议配置、状态是否正确。

<Sysname> display ip routing-table 1.1.1.0

Summary Count : 1

Destination/Mask Proto Pre Cost NextHop Interface

1.1.1.0/24 Static 60 0 10.0.0.2 XGE3/1/2

需要注意的是，当32位掩码的主机路由与ARP表项的出接口不一致时，以主机路由的出接口为准。

(3) FIB表检查

检查设备到某一目的IP网段的FIB表项是否存在，如路由存在、FIB表项异常，请将故障信息发送技术支持人员分析。

<Sysname> display fib 1.1.1.0

Destination count: 1 FIB entry count: 1

Flag:

U:Useable G:Gateway H:Host B:Blackhole D:Dynamic S:Static

R:Relay F:FRR

Destination/Mask Nexthop Flag OutInterface/Token Label

1.1.1.0/24 10.0.0.2 USG XGE3/1/2 Null

(4) ARP检查

检查设备ARP学习的接口是否正确，如学习接口不正确，请通过reset arp命令重新学习ARP，必要时可以使用arp static命令配置静态ARP。如ARP学习的接口一直不正确，请将故障信息发送技术支持人员分析。

<Sysname> display arp 10.0.0.2

Type: S-Static D-Dynamic M-Multiport I-Invalid

IP address MAC address VLAN Interface Aging Type

10.0.0.2 0000-0000-0001 N/A XGE3/1/2 N/A S

8.3 DHCP中继故障处理

8.3.1 故障描述

客户端无法通过DHCP中继获取IP地址。

8.3.2 故障处理步骤

客户端无法通过DHCP中继获取IP地址一般是由以下的原因造成的：

· 中继和服务器间的路由错误

· 中继没有指定服务器的地址

· DHCP中继功能未使能

1. 查看中继代理与DHCP服务器间的路由是否存在

在DHCP中继代理和DHCP服务器上执行display ip routing-table命令来查看到对方的路由表项是否存在，如不存在请配置静态路由后查看故障是否排除，如依然存在请执行步骤2。

2. 查看DHCP中继是否指定了DHCP服务器地址

在DHCP中继上指定DHCP服务器的地址dhcp relay server-address ip-address，查看故障是否排除，如依然存在请执行步骤3。

3. 查看DHCP中继功能是否使能

配置接口工作在DHCP中继模式dhcp select relay，查看故障是否排除，如依然存在请联系技术支持人员分析。

8.4 ND故障处理

8.4.1 无法学习到对端设备的ND表项

1. 故障描述

无法学习到对端设备的ND表项。

2. 故障处理步骤

(1) 查看ND调试信息

使用debugging ipv6 nd packet命令打开ND调试信息开关，当对端ping本设备时，可以看到下列调试信息。如果未显示NS请求报文信息，则说明未接收到请求报文；如果未显示NA应答报文，则说明本设备未应答邻居请求。

<Sysname> *Sep 24 19:44:59:161 2019 H3C ND/7/ND_PACKET: -MDC=1-Slot=5;

Received NS packet:

Interface: XGE5/4/3 First VLAN ID: 0 Second VLAN ID: 0

SrcEthMAC: 70f9-6da7-5074 SrcIP: 2004::1

DstEthMAC: 0000-0000-0000 DstIP: ff02::1:ff00:2

LinkId: 0xffff VsiIndex: 0xffffffff

// 接收NS请求报文

*Sep 24 19:44:59:163 2019 H3C ND/7/ND_PACKET: -MDC=1-Slot=5;

Sent NA packet:

Interface: XGE5/4/3 First VLAN ID: 0 Second VLAN ID: 0

SrcEthMAC: 1cab-343a-6145 SrcIP: 2004::2

DstEthMAC: 70f9-6da7-5074 DstIP: 2004::1

LinkId: 0xffff VsiIndex: 0xffffffff

// 发送NA应答报文

(2) 报文计数分析

如果设备未收到Ping报文，请排查上游的相邻设备；如果设备收到Ping报文，分析NS报文在本端是否上送给平台。具体步骤请参照8.1.1 2. (2)报文计数分析。

8.4.2 无法学习到ND表项

1. 故障描述

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

2. 常见原因

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

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

· 接口物理层未正常Up。

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

· ND报文未上送到CPU。

· 单板存在故障。

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

3. 故障分析

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

图8-5 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 = Ten-GigabitEthernet3/1/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 Ten-GigabitEthernet3/1/1.

以上信息表示设备在接口Ten-GigabitEthernet3/1/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 = Ten-GigabitEthernet3/1/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 Ten-GigabitEthernet3/1/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 = Ten-GigabitEthernet3/1/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 = Ten-GigabitEthernet3/1/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报文的错误调试信息开关，根据表8-4中的内容确认设备无法成功发送或接收IPv6报文的原因。

表8-4 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”为队列中丢弃的ND报文的个数。

当“drops”不为0且“max”的值与“depth”相同时，说明因CPU繁忙导致ND报文被丢弃。

(6) 请收集如下信息，并联系H3C技术支持工程师。

¡ 上述步骤的执行结果。

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

5. 告警与日志

8.4.3 不回应NS报文

1. 故障描述

设备收到对端设备发送到NS报文后，不回应NA报文。

2. 常见原因

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

· 接口收到的NS报文的目的IPv6地址不是本机IPv6地址。

· 对端设备触发了源MAC地址固定的ND攻击检测功能。

3. 故障分析

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

图8-6 不回应NS报文故障诊断流程图

4. 处理步骤

(1) 查看ND报文信息，确认ND报文是否已上送。

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 = Ten-GigabitEthernet3/1/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的错误调试信息开关，根据表8-5中的内容确认设备不回应ND报文的原因。

表8-5 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) 以本端接口接口Ten-GigabitEthernet3/1/1为例，通过display ipv6 nd source-mac命令显示检测到的源MAC地址固定的ND攻击检测表项，查看对端设备的MAC是否被加入攻击表项中。

<Sysname> display ipv6 nd source-mac interface ten-gigabitethernet 3/1/1

Source MAC VLAN ID Interface Aging time (sec) Packets dropped

23f3-1122-3344 4094 XGE3/1/1 10 84467

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

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

(3) 通过display system internal ND statistics命令显示各单板的ND统计信息，收集“Error statistics”字段中的内容，发送给H3C技术支持工程师。

(4) 以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技术支持工程师。

(5) 请收集如下信息，并联系H3C技术支持工程师。

¡ 上述步骤的执行结果。

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

5. 告警与日志

8.4.4 已有ND表项但无法转发流量

1. 故障描述

设备已有ND表项但无法正常转发流量。

2. 常见原因

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

· 平台ND表项参数异常。

· 平台ND表项没有成功下发驱动。

3. 故障分析

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

图8-7 已有ND表项但无法转发流量故障诊断流程图

4. 处理步骤

(1) 通过display system internal adj6 entry命令查看ND表项是否成功建立。

[Sysname-probe]display system internal adj6 entry 1::2 interface ten-gigabitethernet 3/1/1 slot 0

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 : XGE3/1/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

以接口Ten-GigabitEthernet3/1/1，对端IPv6地址为1::2为例：

¡ 如果“Action type”字段为“Forwarding”，则代表设备正常转发来自1::2的流量，设备无故障。

¡ 如果“Action type”字段为“Drop”，则代表没有成功建立ND表项。

- 如果“Driver flag”字段为“4”，代表驱动资源不足，请检查驱动的使用情况。

- 如果“Driver flag”字段不为“4”，请继续执行第(2)步。

(2) 通过debugging system internal adj6命令并指定hardware参数打开IPv6邻接表下驱动调试功能，然后通过ping ipv6命令触发ND表项的学习，查看ND表项是否成功下发到驱动。

[Sysname-probe] debugging system internal adj6 hardware

*Dec 15 11:17:33:916 2022 31 ADJ6/7/ADJ6_HARDWARE: -MDC=1;

====Start ADJLINK Add====

*Dec 15 11:17:33:916 2022 31 ADJ6/7/ADJ6_HARDWARE: -MDC=1;

--------------New Entry-------------

Service type : Ethernet

Link media type : Broadcast

Action type : Forwarding

IPv6 address : 19::2

Route interface : XGE3/1/1

Port interface : N/A

Slot : 3

MTU : 1500

VLAN id : 65535

Second VLAN id : 65535

Physical interface : XGE3/1/1

Logical interface : N/A

Vrf index : 0

Usr ID : -1

Subscriber ID : 0

Leased ID : -1

MAC address : 307b-ac7e-30fa

Link head length(IPv6) : 14

Link head length(MPLS) : 14

Link head information(IPv6) : 307bac7e30fa8620002200d286dd

Link head information(MPLS) : 307bac7e30fa8620002200d28847

*Dec 15 11:17:33:916 2022 31 ADJ6/7/ADJ6_HARDWARE: -MDC=1;

--------------New Entry DrvContext-------------

Nexthop driver

[0]: 0xffffffff [1]: 0xffffffff

Driver context

[0]: 0x3affffbf [1]: 0xffffffff [2]: 0xffffff0c [3]: 0xffffffff [4]: 0xbfffffff [5]: 0xffffffff

*Dec 15 11:17:33:916 2022 31 ADJ6/7/ADJ6_HARDWARE: -MDC=1;

====End ADJLINK Operate====

Result : 0x0, Reference flag : 0x0, Syn flag : 0x0

*Dec 15 11:17:33:999 2022 31 ADJ6/7/ADJ6_HARDWARE: -MDC=1-Slot=3;

====Start ADJLINK Mod====

*Dec 15 11:17:33:999 2022 31 ADJ6/7/ADJ6_HARDWARE: -MDC=1-Slot=3;

--------------Old Entry-------------

Service type : Ethernet

Link media type : Broadcast

Action type : Forwarding

IPv6 address : 19::2

Route interface : XGE3/1/1

Port interface : N/A

Slot : 3

MTU : 1500

VLAN id : 65535

Second VLAN id : 65535

Physical interface : XGE3/1/1

Logical interface : N/A

Vrf index : 0

Usr ID : -1

Subscriber ID : 0

Leased ID : -1

MAC address : 307b-ac7e-30fa

Link head length(IPv6) : 14

Link head length(MPLS) : 14

Link head information(IPv6) : 307bac7e30fa8620002200d286dd

Link head information(MPLS) : 307bac7e30fa8620002200d28847

*Dec 15 11:17:33:999 2022 31 ADJ6/7/ADJ6_HARDWARE: -MDC=1-Slot=3;

--------------Old Entry DrvContext-------------

Nexthop driver

[0]: 0x56730400 [1]: 0xffffffff

Driver context

[0]: 0x3affffbf [1]: 0xffffffff [2]: 0xffffff0c [3]: 0xffffffff [4]: 0xbfffffff [5]: 0xffffffff

[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 = Ten-GigabitEthernet3/1/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 Ten-GigabitEthernet3/1/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 = Ten-GigabitEthernet3/1/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 Ten-GigabitEthernet3/1/1.

*Apr 26 16:06:42:414 2022 Sysname IP6FW/7/IP6FW_PACKET: -MDC=1;

Receiving, interface = Ten-GigabitEthernet3/1/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 : XGE3/1/1

Port interface : N/A

Slot : 0

MTU : 1500

VLAN id : 65535

Second VLAN id : 65535

Physical interface : XGE3/1/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 = Ten-GigabitEthernet3/1/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 = Ten-GigabitEthernet3/1/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技术支持工程师。

¡ 上述步骤的执行结果。

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

8.5 IP性能优化故障处理

8.5.1 不同厂商的设备对接后，链路卡顿或不通

1. 故障描述

在网络中，由于不同厂商，甚至同一厂商不同型号的设备，对MTU的定义和MTU分片机制不尽相同，常出现MTU引起的网络问题，常表现为游戏卡、部分网站或链接打不开，Email无法发送附件，部分网页或对话框无法打开等。遇到此类问题时，建议先检查是否接口MTU不匹配导致。

此外，OSPF、IS-IS、L2VPN、VPLS等协议邻居关系无法建立，也可能是链路两端MTU值不一致导致。

2. 故障处理步骤

对于MTU值问题处理，需要分析数据包传递的全路径上的MTU值设置。通用处理步骤如下：

(1) 分析数据转发路径。

(2) 检查数据包传递的全路径上各设备的出接口MTU值、站点间传输设备的MTU值。

(3) 逐段ping大包测试。大包长度分别为大于、小于、等于接口MTU值。

(4) 如果ping长度大于接口MTU时不通，小于等于接口MTU时能通，可初步认为是MTU问题。

(5) 分析报文头格式。

(6) 根据出问题的报文的最大长度修改MTU。在修改MTU值时，需要注意不同厂商设备MTU值的定义。

设备MTU下发情况可以通过查询Outlif表项查看：

[Sysname-probe] display hardware internal l3 np fib 22.1.0.2 32 slot 2 chip 0

The FTN/FIB table Handle<0x14> ECMPNum<0/1> !

ChipID is 0

LPM:

LPM KEY: VPNID = 0 IP_Prefix = 22.1.0.2/4294967295

LPM RESULT:

00001403 0030d000

Ipv4-route tag:

Valid = 1 Parity = 1 Local = 0

Drop = 0 ToHost = 0 Ecmp = 0

Dft_Sys = 0 Dft_User = 0 NextHopIdxOrEcmpPtr = 20

LifId = 12496 EcmpNum = 0

FWD-FTN:

FWD-FTN KEY: NextHopIdx = 0x14

FWD-FTN RESULT:

ECMP = 0 Th = 0 Normal = 1 Drop = 0

OutlifId/ToHostId = 67607

Dft_User = 0 Dft_Sys = 0

Es = 0 Ts = 0 DhcpH = 0

Local = 0 Parity = 1 V = 1 TTL = 255

StackEnd = 0 Label_v = 0 Label = 0 Label_bak = 0

Rd = 0 Rq = 0 Dscp = 0 QosLocalId = 0

Outlif Table : KEY(outlifid = 67607) RESULT(00008201, 10030901, 00000000, 00000000, 00000000, 00000000, 05dc0000, fff10817)

RES:

un0.tunnel.uiReserve1:1 = 0

un0.tunnel.uiBak:1 = 0

un0.tunnel.uiBcm:1 = 0

un0.tunnel.uiReserve2:1 = 0

un0.tunnel.uiFwd:1 = 0

un0.tunnel.uiEs:1 = 0

un0.tunnel.uiTs:1 = 0

un0.tunnel.uiReserve3:1 = 0

un0.tunnel.uiMct:1 = 0

un0.tunnel.uiGre:1 = 0

un0.tunnel.uiIpt:1 = 0

un0.tunnel.uiUdp:1 = 0

un0.tunnel.uiReserve4:1 = 0

un0.tunnel.ui6to4:1 = 0

un0.tunnel.uiAuto:1 = 0

un0.tunnel.uiMacInMac:1 = 0

un0.tunnel.uiL3Port:1 = 1

……

un5.v4ipt.uiIdentIndex:16 = 0

un5.v4ipt.uiTos:8 = 0

un5.v4ipt.uiTtl:8 = 0

un5.v6ipt.uiV6Dip:32 = 0

un5.minm.uiIsid:32 = 0

un6.gen.uiMtu:16 = 1500

再次ping大包测试。

8.6 ADVPN故障处理

8.6.1 ADVPN隧道震荡（使用IPsec保护场景）

1. 故障描述

使用IPsec安全框架保护ADVPN隧道报文的场景下，ADVPN隧道震荡，隧道状态在一直在Success和Dumb之间变化。

2. 常见原因

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

· 对VAM Server、VAM Client或者ADVPN隧道的配置进行了修改或删除。

· ADVPN隧道物理接口异常。

· VAM Server和VAM Client之间，或VAM Client之间路由震荡。

· ADVPN隧道两端的中间网络链路不稳定。

· IPsec业务故障，例如IKE DPD探测丢包、IPsec重协商失败。

3. 故障分析

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

图8-8 ADVPN隧道震荡（IPsec场景）故障诊断流程图

4. 处理步骤

(1) 检查ADVPN隧道两端之间是否有可达路由。

分别在ADVPN隧道两端执行命令display ip routing-table，查看是否含有到对端的路由信息。

¡ 如果ADVPN隧道两端之间没有可达路由，请检查路由配置。

¡ 如果ADVPN隧道两端之间有可达路由，请执行步骤（2）。

(2) 检查VAM Server的配置是否进行了修改或删除。

a. 检查指定ADVPN域的VAM Server功能是否被关闭。VAM Server关闭会导致该域中的ADVPN隧道被删除。

<Sysname> display vam server statistics advpn-domain 1

ADVPN domain name : 1

Server status : Enabled

Holding time : 0H 1M 47S

Registered spoke number: 98

Registered hub number : 2

...略...

如果以上显示信息中的Server status取值为Disabled，请在系统视图下执行命令vam server enable advpn-domain domain-name，重新开启指定ADVPN域的VAM Server功能。

b. 检查指定ADVPN隧道所属Hub的私网地址信息是否进行了修改。Hub的私网地址删除后，会触发与该Hub建立的ADVPN隧道被删除。

在指定的Hub组视图下，执行命令display this，检查包含的hub private-address配置是否符合预期。若不准确，请在Hub组视图下修改配置。

<Sysname> system-view

[Sysname] vam server advpn-domain 1

[Sysname-vam-server-domain-1] hub-group 1

[Sysname-vam-server-domain-1-hub-group-1] display this

hub-group 1

hub private-address 10.1.1.1 advpn-port 3333

c. 检查配置的监听端口号是否进行了修改。VAM Server的监听端口号与VAM Client上指定的VAM Server的端口号必须一致，否则VAM Client与VAM Server之间的协议报文将无法正常收发。如果VAM Client长时间未收到来自VAM Server的Keepalive响应报文，会主动将ADVPN隧道状态切换为Dumb。

在系统视图下执行命令display this，检查包含的vam server listen-port配置是否符合预期。若不准确，请在系统视图下执行vam server listen-port命令修改配置。

<Sysname> system-view

[Sysname] vam server listen-port 10000

d. 以上检查完成后，如果重新调整了配置，请执行命令reset vam server address-map，重新触发VAM Client上线。之后，如果故障仍未排除，请执行步骤（3）。

(3) 检查VAM Client的配置是否进行了修改或删除。

a. 检查指定的VAM Client功能是否被关闭。VAM Client功能关闭会导致已建立的ADVPN隧道被删除。

<Sysname> display vam client fsm

Client name : abc

Status : Enabled

ADVPN domain name: 1

Primary server: abc.com (28.1.1.23)

Private address: 10.0.0.12

...略...

如果以上显示信息中的Status取值为Disabled，请在系统视图下执行命令vam client enable name client-name，重新开启指定的VAM Client功能。

b. 检查主VAM Server的地址是否进行了修改或删除。VAM Client上的主VAM Server地址被删除后，该VAM Client上已经建立的ADVPN隧道也将会被删除，并触发VAM Client与新的VAM Server进行重新注册。

<Sysname> display vam client fsm

Client name : abc

Status : Enabled

ADVPN domain name: 1

Primary server: abc.com (28.1.1.23)

Private address: 10.0.0.12

...略...

如果以上显示信息中的Primary server地址不符合预期，请在VAM Client视图下执行命令server primary，重新配置主VAM Server的地址信息。

<Sysname> system-view

[Sysname] vam client name abc

[Sysname-vam-client-abc] server primary ip-address 1.1.1.1 port 2000

需要注意的是，VAM Client上指定的VAM Server的端口号，则必须和VAM Server上通过vam server listen-port命令配置的监听端口号一致。

以上检查完成后，如果重新调整了配置，请执行命令reset vam client fsm，重新触发VAM Client上线。之后，如果故障仍未排除，请执行步骤（4）。

(4) 检查ADVPN隧道配置是否进行了修改或删除。

a. 进入指定的ADVPN隧道接口视图，执行命令display this，检查隧道接口的私网地址、源端口地址、绑定的VAM Client是否符合预期。

<Sysname> system-view

[Sysname] interface tunnel 1 mode advpn udp

[Sysname-Tunnel1] display this

interface Tunnel2 mode advpn udp

ip address 10.1.1.1 255.255.255.0

advpn source-port 3333

vam client abc

b. 如果需要调整配置，请在该视图下完成相关配置，然后在用户视图下执行命令reset advpn session interface tunnel number，触发重新建立对应的ADVPN隧道。之后，如果故障仍未排除，请执行步骤（5）。

(5) 检查ADVPN隧道物理接口是否异常。

执行命令display ip interface brief，查看ADVPN隧道端点所在物理接口的Physical字段。如果Physical字段一直显示为down或者在up和down两种状态间切换，则表示物理接口异常，需要首先排除物理接口故障。如果隧道物理接口正常的情况下，故障仍存在，请执行步骤（6）。

(6) 检查VAM Server和VAM Client之间是否存在路由震荡。

分别在VAM Server和VAM Client上执行命令display ip routing-table，查看是否存在到达对端的路由信息。如果相关路由信息一直在显示和不显示之间切换，则表示路由震荡。

¡ 如果VAM Server和VAM Client之间没有可达路由，或者路由震荡，请检查路由配置，并参考相关协议的路由震荡故障手册确保路由正常。

¡ 如果VAM Server和VAM Client之间没有路由问题，请执行步骤（7）。

(7) 检查ADVPN隧道两端是否存在路由震荡。

分别在ADVPN隧道两端执行命令display ip routing-table，查看是否存在到达对端的路由信息。如果相关路由信息一直在显示和不显示之间切换，则表示路由震荡。

¡ 如果ADVPN隧道两端没有可达路由，或者路由震荡，请参考相关协议的路由震荡故障手册检查路由配置，并确保路由正常。

¡ 如果ADVPN隧道两端没有路由问题，请执行步骤（8）。

(8) 检查ADVPN隧道两端的中间网络链路是否稳定。

在本端执行命令display vam client statistics，观察Keepalive报文的收发统计数据是否一致。

<Sysname> display vam client statistics

Client name: abc

Status : Enabled

Primary server: abc.com

Packets sent:

Initialization request : 1

Initialization complete : 1

Authentication information : 1

Address resolution request : 9

Network registration request : 0

Update request : 0

Logout request : 0

Hub information response : 0

Data flow information response: 0

Keepalive : 35

Error notification : 0

Packets received:

Initialization response : 1

Initialization complete : 1

Authentication request : 1

Address resolution response : 9

Network registration response: 0

Update response : 0

Hub information request : 0

Data flow information request: 0

Logout response : 0

Keepalive : 35

Error notification : 0

Unknown : 0

...略...

如果Keepalive报文的收发统计数据均不为零且不一致，说明中间网络链路不稳定，请在技术人员的指导下逐跳排查中间网络的链路问题。如果Keepalive报文的收发统计数据一致，请执行步骤（9）。

(9) 检查是否成功协商IKE SA和IPsec SA。

分别在ADVPN隧道两端执行命令display ike sa和display ipsec sa，确认是哪一个阶段的SA未协商成功：

a. 如果执行display ike sa命令后，没有显示对应的IKE SA，或者IKE SA的状态为Unknown，则表示第一阶段的IKE SA未协商成功。请检查隧道两端应用的ipsec profile所引用的IKE profile配置是否匹配。如果IKE配置正确的情况下，仍不能排除故障，请执行步骤（10）。

b. 如果执行display ipsec sa命令后，没有显示可用的IPsec SA，则表示第二阶段的IPsec SA未协商成功。请检查隧道两端应用的ipsec profile所引用的IPsec安全提议配置是否正确：

- 引用的IPsec安全提议中应包含相同的安全协议、认证/加密算法和报文封装模式。

- 引用的IPsec安全提议所采用的封装模式必须为隧道模式。

如果IPsec安全提议配置正确的情况下，仍不能排除故障，请执行步骤（10）。

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

¡ 上述步骤的执行结果。

¡ 设备的配置文件。

¡ IKE、IPsec、VAM Server、VAM Client和ADVPN的事件和错误类调试信息。通常不建议打开报文类型的调试信息开关，以避免用户界面上输出的报文类调试信息过多干扰用户的正常业务操作和信息阅览。

5. 告警与日志

8.6.2 无法Ping通ADVPN隧道对端（使用IPsec保护场景）

1. 故障描述

使用IPsec安全框架保护ADVPN隧道报文的场景下，无法Ping通对端隧道接口的IP地址。

2. 常见原因

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

· ADVPN隧道两端之间路由不可达。

· ADVPN隧道创建失败。

· ADVPN隧道报文长度大于隧道接口的MTU。

· ADVPN隧道报文经过IPsec加解密失败。

· IPsec业务故障，例如IPsec隧道未成功建立、IPsec抗重放丢包。

3. 故障分析

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

图8-9 无法Ping通ADVPN隧道对端（IPsec场景）故障诊断流程图

4. 处理步骤

(1) 检查ADVPN隧道两端之间是否有可达路由。

分别在ADVPN隧道两端执行命令display ip routing-table，查看是否存在到达对端的路由信息。

¡ 如果没有到达对端的路由，请检查路由配置，并确保路由正常。

¡ 如果存在到达对端的路由，请执行步骤（2）。

(2) 检查ADVPN隧道是否创建成功。

分别在ADVPN隧道两端执行命令display advpn session，查看指定的ADVPN隧道是否存在。

<Sysname> display advpn session interface tunnel 1 private-address 10.0.1.3

Private address Public address Port Type State Holding time

10.0.0.3 192.168.180.136 1139 H-S Success 5H 38M 8S

¡ 如果到达对端私网地址的ADVPN隧道不存在，或者隧道状态为Dumb，则表示ADVPN隧道未成功建立，请依次检查VAM Server、VAM Client、ADVPN隧道的相关配置，并确保配置准确。

- 在VAM Server上执行display vam server address-map命令，如果没有查看到注册到VAM Server上的VAM Client的IPv4私网地址和公网地址映射信息，则需要检查VAM Server、VAM Client的配置是否准确。有关VAM Server、VAM Client的详细配置介绍请参考ADVPN配置手册。

- 在VAM Server上执行display vam server address-map命令，如果查看到注册到VAM Server上的VAM Client的IPv4私网地址和公网地址映射信息，则需要检查ADVPN隧道配置是否准确。有关ADVPN隧道的详细配置介绍请参考ADVPN配置手册。

¡ 如果到达对端私网地址的ADVPN隧道存在，请执行步骤（3）。

(3) 检查ADVPN隧道报文长度是否小于接口的MTU值。

分别在ADVPN隧道两端执行命令display interface tunnel，查看显示信息中的Maximum transmission unit字段取值。

<Sysname> display interface tunnel 1

Tunnel1

Current state: UP

Line protocol state: UP

Description: Tunnel1 Interface

Bandwidth: 64kbps

Maximum transmission unit: 1476

...略...

然后，执行ping –s packet-size –a local-address peer-address命令测试不同packet-size的Ping报文经过隧道接口发送结果，找到一个产生Ping不通现象的临界值，该临界值为传输链路能够允许的ADVPN隧道报文最大长度。

¡ 如果隧道接口的MTU值小于上述ADVPN隧道报文长度，请在隧道接口视图下执行命令mtu size调整隧道接口的MTU值。

¡ 如果隧道接口的MTU值大于上述ADVPN隧道报文长度，请执行步骤（6）。

(4) 检查是否成功协商IKE SA和IPsec SA。

分别在ADVPN隧道两端执行命令display ike sa和display ipsec sa，确认是哪一个阶段的SA未协商成功：

¡ 如果执行display ike sa命令后，没有显示对应的IKE SA，或者IKE SA的状态为Unknown，则表示第一阶段的IKE SA未协商成功。请检查隧道两端应用的ipsec profile所引用的IKE profile配置是否匹配。如果IKE配置正确的情况下，仍不能排除故障，请执行步骤（6）。

¡ 如果执行display ipsec sa命令后，没有显示可用的IPsec SA，则表示第二阶段的IPsec SA未协商成功。请检查隧道两端应用的ipsec profile所引用的IPsec安全提议配置是否正确：

- 引用的IPsec安全提议中应包含具有相同的安全协议、认证/加密算法和报文封装模式的IPsec安全提议。

- 要引用的IPsec安全提议所采用的封装模式必须为隧道模式。

如果IPsec安全提议配置正确的情况下，仍不能排除故障，请执行步骤（6）。

(5) 检查是否为IPsec处理导致丢包。

分别在ADVPN隧道两端执行命令display ipsec statistic，查看报文丢包原因。

¡ 如果IPsec处理的报文统计信息中有丢包，请根据丢包统计信息排查故障。

<Sysname> display ipsec statistics

IPsec packet statistics:

Received/sent packets: 47/64

Received/sent bytes: 3948/5208

Received/sent packet rate: 5/5 packets/sec

Received/sent byte rate: 290/290 bytes/sec

Dropped packets (received/sent): 0/45

Dropped packets statistics

No available SA: 0

Wrong SA: 0

Invalid length: 0

Authentication failure: 0

Encapsulation failure: 0

Decapsulation failure: 0

Replayed packets: 0

ACL check failure: 45

MTU check failure: 0

Loopback limit exceeded: 0

Crypto speed limit exceeded: 0

Responder only limitation: 0

¡ 如果IPsec处理的报文统计信息中没有丢包，请执行步骤（6）。

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

¡ 上述步骤的执行结果。

¡ 设备的配置文件。

5. 告警与日志

9 三层技术-IP路由类故障处理

9.1 BGP故障处理

9.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. 故障分析

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

图9-1 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会话的配置。

表9-1 影响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. 告警与日志

9.1.2 BGP会话Down

1. 故障描述

在设备上观察到BGP/5/BGP_STATE_CHANGED提示BGP会话状态变为Idle的日志打印信息，会话状态从Established变为Idle。

2. 常见原因

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

· Keepalive或Update消息收发超时。

· TCP连接建立失败。

· 设备达到内存门限。

· BGP报文解析发生错误。

3. 故障分析

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

图9-2 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命令的显示信息（所有的单板/成员设备各执行一次）。

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

5. 告警与日志

9.1.3 跨AS域的数据中心互联场景BGP路由环路

1. 故障描述

在图9-3所示的网络中，两个数据中心通过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之间循环发送，形成环路。

图9-3 跨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 XGE3/1/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 XGE3/1/1

2.2.2.2/32 O_INTRA 10 1 29.1.1.2 XGE3/1/2

3.3.3.3/32 O_INTRA 10 1 39.1.1.3 XGE3/1/3

4.4.4.4/32 O_INTRA 10 1 49.1.1.4 XGE3/1/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 XGE3/1/1

19.1.1.0/24 Direct 0 0 19.1.1.9 XGE3/1/1

19.1.1.0/32 Direct 0 0 19.1.1.9 XGE3/1/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 XGE3/1/1

10.110.0.0/16 BGP 255 0 3.3.3.3 XGE3/1/3

29.1.1.0/24 Direct 0 0 29.1.1.9 XGE3/1/2

29.1.1.0/32 Direct 0 0 29.1.1.9 XGE3/1/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 XGE3/1/2

39.1.1.0/24 Direct 0 0 39.1.1.9 XGE3/1/3

39.1.1.0/32 Direct 0 0 39.1.1.9 XGE3/1/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 XGE3/1/3

49.1.1.0/24 Direct 0 0 29.1.1.9 XGE3/1/2

49.1.1.0/32 Direct 0 0 29.1.1.9 XGE3/1/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 XGE3/1/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 XGE3/1/3”），而来自Border 4的10.110.0.0/16网段路由到达下一跳的IGP路由的Metric值为0（对应上表中的路由表项“0.0.0.0/0 BGP 255 0 19.1.1.1 XGE3/1/1”）。按照BGP路由的优选规则，RR 1优选来自Border 4的10.110.0.0/16网段路由，在路由转发表中，网段10.110.0.0/16的下一跳变为Ten-GigabitEehternet3/1/1。在转发目的地址属于10.110.0.0/16网段的报文时，RR 1会把报文错误地发送给Border 1，并且由于Border 1上10.110.0.0/16网段的路由学习自RR 1，Border 1又会把报文转发回RR 1，如此往复造成环路。

3. 故障分析

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

图9-4 跨AS域的数据中心互联场景BGP路由环路的故障诊断流程图

4. 处理步骤

(1) 查看RR 1的BGP路由表和IP路由表。本步骤以图9-3的组网为例，来说明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之间的直连接口Ten-GigabitEehternet3/1/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: Ten-GigabitEehternet3/1/1

BkSRLabel: NULL BkInterface: N/A

Tunnel ID: Invalid IPInterface: Ten-GigabitEehternet3/1/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也为Ten-GigabitEehternet3/1/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 XGE3/1/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 XGE3/1/1

2.2.2.2/32 O_INTRA 10 1 29.1.1.2 XGE3/1/2

3.3.3.3/32 O_INTRA 10 1 39.1.1.3 XGE3/1/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 XGE3/1/1

19.1.1.0/24 Direct 0 0 19.1.1.9 XGE3/1/1

19.1.1.0/32 Direct 0 0 19.1.1.9 XGE3/1/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 XGE3/1/1

10.110.0.0/16 BGP 255 0 4.4.4.4 XGE3/1/1

29.1.1.0/24 Direct 0 0 29.1.1.9 XGE3/1/2

29.1.1.0/32 Direct 0 0 29.1.1.9 XGE3/1/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 XGE3/1/2

39.1.1.0/24 Direct 0 0 39.1.1.9 XGE3/1/3

39.1.1.0/32 Direct 0 0 39.1.1.9 XGE3/1/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 XGE3/1/3

49.1.1.0/24 Direct 0 0 29.1.1.9 XGE3/1/2

49.1.1.0/32 Direct 0 0 29.1.1.9 XGE3/1/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 XGE3/1/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. 告警与日志

9.1.4 Spine和Leaf设备跨AS连接场景BGP路由环路

1. 故障描述

在图9-5所示的网络中，Spine设备与Leaf设备处在不同的AS域中。Spine设备之间建立全互联的BGP连接，Spine 1和Spine 2与Leaf建立EBGP连接。Spine 2开启了负载分担功能，并且可以在EBGP和IBGP路由之间进行负载分担。Spine 1重启时，经过Spine 2到Leaf的流量有一半丢失。

图9-5 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 XGE3/1/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 XGE3/1/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 XGE3/1/1

12.1.1.0/24 Direct 0 0 12.1.1.2 XGE3/1/2

12.1.1.0/32 Direct 0 0 12.1.1.2 XGE3/1/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 XGE3/1/2

14.1.1.0/24 O_INTRA 10 2 12.1.1.1 XGE3/1/2

O_INTRA 10 2 24.1.1.4 XGE3/1/1

23.1.1.0/24 Direct 0 0 23.1.1.2 XGE3/1/3

23.1.1.0/32 Direct 0 0 23.1.1.2 XGE3/1/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 XGE3/1/3

24.1.1.0/24 Direct 0 0 24.1.1.2 XGE3/1/1

24.1.1.0/32 Direct 0 0 24.1.1.2 XGE3/1/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 XGE3/1/1

100.1.1.0/24 BGP 255 0 23.1.1.3 XGE3/1/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 XGE3/1/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. 故障分析

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

图9-6 BGP路由环路情况二的故障诊断流程图

4. 处理步骤

(1) 查看Spine 2的BGP路由表和IP路由表。本步骤以图9-5的组网为例，来说明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: Ten-GigabitEehternet3/1/1

BkSRLabel: NULL BkInterface: N/A

Tunnel ID: Invalid IPInterface: Ten-GigabitEehternet3/1/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: Ten-GigabitEehternet3/1/3

BkSRLabel: NULL BkInterface: N/A

Tunnel ID: Invalid IPInterface: Ten-GigabitEehternet3/1/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也为Ten-GigabitEehternet3/1/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 XGE3/1/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 XGE3/1/1

12.1.1.0/24 Direct 0 0 12.1.1.2 XGE3/1/2

12.1.1.0/32 Direct 0 0 12.1.1.2 XGE3/1/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 XGE3/1/2

14.1.1.0/24 O_INTRA 10 2 24.1.1.4 XGE3/1/1

23.1.1.0/24 Direct 0 0 23.1.1.2 XGE3/1/3

23.1.1.0/32 Direct 0 0 23.1.1.2 XGE3/1/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 XGE3/1/3

24.1.1.0/24 Direct 0 0 24.1.1.2 XGE3/1/1

24.1.1.0/32 Direct 0 0 24.1.1.2 XGE3/1/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 XGE3/1/1

100.1.1.0/24 BGP 255 0 1.1.1.1 XGE3/1/1

BGP 255 0 23.1.1.3 XGE3/1/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. 告警与日志

9.2 IS-IS故障处理

9.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. 故障分析

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

图9-7 IS-IS邻居无法建立的故障诊断流程图

4. 处理步骤

(1) 检查接口的物理层状态是否为Up。

请执行display interface [ interface-type [ interface-number | interface-number.subnumber ] ]命令查看IS-IS接口物理层状态，如果接口物理层状态为Down，请先处理接口故障问题。如果接口物理状态为Up，请执行步骤(2)。

(2) 检查链路是否故障。

请执行ping命令，检查设备链路是否故障（包括传输设备故障）。如果链路正常，请执行步骤(3)。

如果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. 告警与日志

9.2.2 设备学习不到IS-IS路由

1. 故障描述

设备学习不到IS-IS路由。

2. 常见原因

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

· 其它路由协议也发布了相同的路由，并且路由协议优先级比IS-IS协议高。

· 引入的外部路由优先级低，没有被优选。

· 引入的外部路由类型不同，没有被优选。

· IS-IS开销值类型不匹配。

· IS-IS邻居没有正常建立。

· 两台设备的System ID配置相同。

· LSP报文认证不匹配。

· 设备底层故障或者链路故障，造成LSP报文丢失。

· LSP长度超过了设备可以接收的LSP的最大长度。

3. 故障分析

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

图9-8 设备学习不到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路由表中不存在指定的路由，请执行步骤(7)。

(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邻居是否都正常建立。

¡ 如果存在邻居没有正常建立的情况，请参见“9.2.1 IS-IS邻居无法建立”。

¡ 如果不存在邻居未能正常建立的情况，请执行步骤(7)。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

9.2.3 IS-IS路由震荡

1. 故障描述

IS-IS路由反复增删。

2. 常见原因

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

· IS-IS邻居震荡。

· MPLS LSP隧道震荡。

· 两台设备的IS-IS引入了相同的外部路由，并且外部路由的优先级比IS-IS协议的优先级低。

· 两台设备配置的System ID相同。

3. 故障分析

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

图9-9 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的设备上执行步骤9.2.1 4. (12)。

¡ 如果路由的“Protocol”字段发生变化，请执行步骤9.2.1 4. (12)。

(2) 检查IS-IS引入外部路由的配置。

如果指定的路由是作为外部路由引入到IS-IS的，在引入该路由的设备上，执行display ip routing-table ip-address verbose命令，查看路由震荡的具体情况，具体步骤如下：

¡ 如果路由表中处于“Active”状态的路由是IS-IS路由，而不是IS-IS引入的外部路由，说明网络中其他IS-IS设备发布了相同的路由。请根据网络规划修改路由协议的优先级，或者，在引入外部路由的IS-IS设备上配置路由过滤策略，控制下发到IP路由表的路由。

¡ 对于其它情况，请执行步骤9.2.1 4. (12)。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

9.3 OSPFv3故障处理

9.3.1 OSPFv3邻居Down

1. 故障描述

· OSPFv3邻居Down

· OSPFv3邻居震荡

2. 常见原因

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

· BFD会话Down，即BFD检测到链路故障。

· 对端设备故障。

· CPU利用率或内存利用率过高。

· 链路故障。

· OSPFv3接口没有Up。

· 两端IP地址不在同一网段。

· 两端OSPFv3参数的配置不匹配：

¡ RouterID配置冲突。

¡ 两端区域类型配置不一致。

¡ 两端OSPFv3认证配置不匹配。

¡ 两端定时器参数配置不一致。

¡ OSPFv3接口的网络类型不匹配。

3. 故障分析

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

图9-10 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. 告警与日志

9.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. 故障分析

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

图9-11 OSPFv3邻居Down的故障诊断流程图

4. 处理步骤

(1) 使用display ospfv3 peer命令查看OSPFv3邻居信息，并根据不同的邻居状态进行相应的处理。

¡ 没有邻居信息。

请检查是否在OSPFv3进程下设置了Router ID，如果未设置Router ID，则OSPFv3进程无法运行。如果设置了Router ID，则表示OSPFv3邻居Down或者邻居震荡，请参见“9.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. 告警与日志

9.4 OSPF故障处理

9.4.1 OSPF邻居Down

1. 故障描述

· OSPF邻居Down

· OSPF邻居震荡

2. 常见原因

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

· BFD会话Down，即BFD检测到链路故障。

· 对端设备故障。

· CPU利用率过高。

· 链路故障。

· OSPF接口没有Up。

· 两端IP地址不在同一网段。

· OSPF两端参数的配置不匹配：

¡ Router ID配置冲突。

¡ 两端区域类型配置不一致。

¡ 两端OSPF验证配置不匹配。

¡ 两端定时器参数配置不一致。

¡ OSPF接口的网络类型不匹配。

3. 故障分析

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

图9-12 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. 告警与日志

9.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. 故障分析

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

图9-13 OSPF邻居无法达到FULL状态的故障诊断流程图

4. 处理步骤

(1) 使用display ospf peer命令查看OSPF邻居信息，并根据不同的邻居状态进行相应的处理。

¡ 没有邻居信息。

表示OSPF邻居Down或者邻居震荡，请参见“9.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. 告警与日志

9.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. 故障分析

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

图9-14 设备学习不到OSPF路由故障诊断流程图一

图9-15 设备学习不到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: Ten-GigabitEthernet3/1/2

BkSRLabel: NULL BkInterface: N/A

SIDIndex: NULL InLabel: NULL

Tunnel ID: Invalid IPInterface: Ten-GigabitEthernet3/1/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: Ten-GigabitEthernet3/1/2

BkSRLabel: NULL BkInterface: N/A

SIDIndex: NULL InLabel: NULL

Tunnel ID: Invalid IPInterface: Ten-GigabitEthernet3/1/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: Ten-GigabitEthernet3/1/2

BkSRLabel: NULL BkInterface: N/A

SIDIndex: NULL InLabel: NULL

Tunnel ID: Invalid IPInterface: Ten-GigabitEthernet3/1/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命令，故障处理方式如表9-2所示。

表9-2 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路由的影响如表9-3所示。

表9-3 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命令，故障处理方式如表9-4所示。

表9-4 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. 告警与日志

9.4.4 网络中IP地址冲突导致路由震荡

1. 故障描述

OSPF组网中不同设备上配置相同的接口IP地址，会导致OSPF路由震荡。出现此问题时，设备通常伴随如下现象：

· 执行命令display cpu-usage查看到设备CPU使用率较高。

· OSPF频繁地老化LSA、重新生成LSA。

· 设备路由频繁刷新、路由计算出错。

2. 处理步骤

以图9-16为示例说明此类故障的处理方式。其他组网与该组网处理此类故障的思路是相同的。

图9-16 网络中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. 告警与日志

9.5 等价路由故障处理

9.5.1 流量在等价路由的下一跳上没有进行负载分担或负载分担不均匀

1. 故障描述

· 流量在等价路由的一个或多个下一跳上没有进行负载分担：执行display counters rate outbound interface命令查看接口报文发送速率时，观察到等价路由的一个或多个出接口的速率为0。

· 流量负载分担不均匀：执行display counters rate outbound interface命令查看接口报文发送速率时，观察到等价路由的一个或多个出接口的速率明显偏低。

2. 常见原因

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

· 下一跳数量超过设备支持的最大数量。

· 指定出接口的路由未配置或没有正常下发。

· 出接口物理连接或数据链路层协议状态没有UP。

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

· 下一跳ARP/ND表项不存在。

· 负载分担方式配置不合理。

· 硬件资源不足。

· 流量的上一跳设备配置了负载分担。

3. 故障分析

本类故障的诊断思路如图9-17所示。

图9-17 等价路由没有进行负载分担或者流量负载分担不均匀故障诊断流程图

4. 处理步骤

(1) 检查下一跳的数量是否超过设备支持的最大数量。

a. 执行display ip routing-table summary命令查看系统支持的最大IPv4等价路由条数，执行display ipv6 routing-table summary命令查看系统支持的最大IPv6等价路由条数。

b. 查看指定目的地址的等价路由数量：执行display ip routing-table ip-address longer-match命令查看指定目的地址的IPv4路由信息。执行display ipv6 routing-table ipv6-address longer-match命令查看指定目的地址的IPv6路由信息。显示信息中目的地址相同、下一跳不同的多条路由即为等价路由。根据显示信息中的Summary count字段，并排除掉掩码长度与指定目的IP地址不同的路由信息，即可得到指定目的地址的等价路由数量。

- 如果指定目的地址的等价路由下一跳数量达到了设备支持的最大等价路由数量，则之后再配置的下一跳不会下发给路由表。如果需要修改路由表中的等价路由下一跳，则需要先删除已有的等价路由配置，再配置新的等价路由下一跳。

- 如果路由下一跳的数量没有超过设备支持的最大数量，请执行步骤(2)。

(2) 检查路由是否正确下发。

请执行display ip routing-table [ vpn-instance vpn-instance-name ] ip-address [ mask-length | mask ] [ longer-match ] verbose或display ipv6 routing-table [ vpn-instance vpn-instance-name ] ipv6-address [ prefix-length ] [ longer-match ] [ verbose ]命令，查看指定目的地址的路由信息。如果路由表中没有指定下一跳和出接口的等价路由，则需要检查路由的配置。如果路由配置无问题，请执行步骤(3)。

(3) 检查出接口物理连接和数据链路层协议状态是否UP。

执行display interface [ interface-type [ interface-number | interface-number.subnumber ] ]或display ipv6 interface [ interface-type [ interface-number ] ] [ brief ]命令查看接口物理层状态，如果接口物理层或数据链路层协议状态不是UP，请先处理接口或链路故障问题。如果出接口物理连接和数据链路层协议状态是UP，请执行步骤(4)。

(4) 检查两端IP地址是否在同一网段。

分别本设备和下一跳设备上执行display interface brief或display ipv6 interface brief命令查看两端接口的IP地址：

¡ 如果两端接口的IP地址不在同一网段，请在接口视图下执行ip address/ipv6 address命令修改两端的IP地址，使其在同一网段。

¡ 如果两端接口的IP地址在同一网段，请执行步骤(5)。

(5) 检查下一跳ARP/ND表项是否存在。

执行display arp查看ARP表项，执行display ipv6 neighbors查看ND表项，若表项不存在，请处理ARP/ND表项问题。如果设备上存在该等价路由下一跳的ARP/ND表项，请执行步骤(6)。

(6) 检查负载分担方式的配置是否合理。

执行display ip load-sharing mode命令用来查看设备当前使用的负载分担方式。如果负载分担的方式是逐流，则设备会为相同负载分担因素（例如源IP地址、目的IP地址、源端口号等）的报文选择同一个下一跳，负载分担方式不合理会导致负载分担不均匀。合理的负载分担方式可以确保设备划分出足够多、足够均匀的数据流（数据流的数量不少于下一跳数量）。

¡ 如果负载分担方式不合理，请根据报文的实际情况选择合适的字段，并执行ip load-sharing mode命令修改负载分担方式。例如指定目的地址的报文携带了不同的源IP地址、IP协议号、目的端口号等字段，则可以把这些字段添加到负载分担方式中。如果将负载分担方式充分调整后故障仍然存在，请执行步骤(7)。

¡ 如果负载分担方式合理，请执行步骤(7)。

(7) 检查硬件资源是否不足。

对于交换机、路由器等存在硬件转发芯片的设备，请检查硬件资源是否不足。通过display system internal fib prefix [ vpn-instance vpn-instance-name] entry-status f命令查看下驱动失败的IPv4 FIB表项信息，或执行display system internal ipv6 fib prefix [ vpn-instance vpn-instance-name ] entry-status f命令查看下驱动失败的IPv6 FIB表项信息。只要存在表项信息，则此设备存在硬件资源不足的情况。请关闭不必要的功能来降低硬件使用率。如果故障依然存在，请执行步骤(8)。

(8) 检查流量的上一跳设备是否配置了负载分担。

如果某个配置了负载分担的设备向本设备发送了流量，则受到负载分担算法的影响，该流量在被发往下一跳设备时会出现负载分担不均匀的情况，此种情况无需处理。请检查其他未配置负载分担的设备发送过来的流量是否也有负载分担不均匀的情况，如果也有此种情况，请执行步骤(9)。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

10 IP组播故障处理

10.1 二层组播故障处理

10.1.1 二层组播业务不通

1. 故障描述

二层组播业务不通主要表现在二层组播转发表项无法生成，导致组播流量无法正常转发。

2. 常见原因

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

· 设备没有收到二层组播协议报文。

· IGMP协议报文格式不正确。

· 二层组播转发表项未生成。

3. 故障分析

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

(1) 检查是否生成二层组播转发表项。

(2) 检查是否正常收到组播协议报文。

(3) 检查IGMP协议报文格式是否正确。

(4) 检查IGMP报文版本是否跟设备上配置的一致。

(5) 检查是否开启三层组播功能。

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

图10-1 二层组播业务不通的故障诊断流程图

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 Ten-GigabitEthernet3/1/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. 告警与日志

10.2 三层组播故障处理

10.2.1 三层组播业务不通

1. 故障描述

三层组播业务不通主要表现在组播流量转发失败。

2. 常见原因

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

· 单播路由配置错误。

· 接口状态不正确。

· PIM路由表项未正确生成。

· 组播转发表项未正确生成。

3. 故障分析

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

图10-2 三层组播业务不通的故障诊断流程图

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. 告警与日志

10.2.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. 故障分析

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

图10-3 设备无法正常建立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. 告警与日志

10.3 MSDP故障处理

10.3.1 MSDP对等体无法正确建立（S，G）表项

1. 故障描述

配置组播网络后发现MSDP对等体无法正确建立（S，G）表项。

2. 常见原因

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

· MSDP对等体建立失败。

· SA报文缓存机制未开启。

· 没有收到源端对等体发出的SA报文。

· 创建SA报文的MSDP对等体没有部署在RP上。

· 配置问题（比如，export、import过滤策略、import-source策略配置不正确）。

3. 故障分析

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

图10-4 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. 告警与日志

10.4 PIM故障处理

10.4.1 PIM邻居Down

1. 故障描述

PIM邻居Down。

2. 常见原因

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

· 接口物理状态为Down。

· 接口上未配置主IP地址。

· 接口上PIM功能没有生效。

· 接口没有使能PIM。

· 接口上PIM相关配置不正确。

3. 故障分析

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

图10-5 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. 告警与日志

10.4.2 PIM域内三层组播流量不通

1. 故障描述

开启IP组播路由功能后，同一PIM域内三层组播流量不通。

2. 常见原因

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

· 需要转发组播数据的接口未使能PIM。

· 接口的PIM协议没有生效。

· PIM邻居未建立成功。

· 连接用户网段的接口未使能IGMP。

· 在PIM-SM网络中，没有配置RP或RP信息不正确。

· 不存在到达RP或组播源的RPF路由。

· 转发组播数据的接口上配置了组播边界。

· 在PIM-SM网络中，配置了错误的组播源过滤策略。

· 组播表项未生成。

3. 故障分析

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

图10-6 PIM域内三层组播流量不通的故障诊断流程图

4. 处理步骤

(1) 检查需要转发组播数据的接口是否使能PIM。

在需要转发组播数据的接口视图下执行display this命令，检查是否存在pim sm或pim dm的配置。

¡ 如果不存在，表明接口下PIM功能未开启。请在接口视图下通过pim sm或pim dm命令开启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网络，请执行步骤(5)。

- 若为PIM-DM网络，请执行步骤(7)。

(5) 对于PIM-SM网络，检查RP信息是否正确。

在设备上执行display pim rp-info命令，查看设备是否生成了为某组播组服务的RP信息表项，并检查PIM-SM域中其它所有设备上，为此组播组服务的RP信息是否配置一致。

¡ 如果不一致，且PIM-SM网络中使用静态RP，请在PIM-SM域的所有设备上的PIM视图下执行static-rp命令，将为某组播组服务的RP地址配置为相同的地址；如果PIM-SM网络中使用动态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. 告警与日志

10.4.3 PIM-SM网络中SPT无法正常转发数据

1. 故障描述

PIM-SM网络中SPT无法正常转发数据，组播流量不通。

2. 常见原因

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

· 组播设备连接下游设备的接口没有收到PIM加入报文。

· PIM-SM域内组播设备上的接口没有开启PIM-SM。

· PIM-SM域内组播设备到组播源的RPF路由不正确。

· 配置不正确（比如组播转发边界配置不正确、组播数据过滤器配置不正确等）。

3. 故障分析

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

图10-7 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. 告警与日志

10.4.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. 故障分析

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

图10-8 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)。

¡ 如果一致，请执行步骤10.4.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 MPLS故障处理

11.1 MPLS基础类故障处理

11.1.1 报文通过LSP隧道转发不通

1. 故障描述

网络中主机的发送报文，通过LSP隧道转发不通。

2. 常见原因

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

· 路由不存在。

· LSP不存在。

· 路由未迭代到LSP隧道上。

· LSP隧道的转发状态非ACTIVE。

· BFD会话状态为Down。

· CPU利用率过高。

3. 故障分析

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

图11-1 报文通过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 Ten-GigabitEthernet3/1/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 Ten-GigabitEthernet3/1/1 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. 告警与日志

11.1.2 MPLS VPN转发故障

1. 故障描述

MPLS常见的组网如图11-2所示。MPLS VPN转发故障时，CE1与CE2之间报文发送接收错误。

图11-2 MPLS组网图

2. 故障处理步骤

L2VPN、VPLS、L3VPN是基于LSP建立的。在LSP入节点（图11-2中的PE1）上通过下列方式来检查、确认MPLS网络中哪台设备存在配置错误。

(1) 检查配置的LSP是否存在，如不存在，请检查MPLS LSP配置是否正确。

[PE1] display mpls lsp

FEC Proto In/Out Label Interface/Out NHLFE

100.100.100.100/32 LDP 3/- -

4.4.4.4/32 LDP NULL/3 Ten-GigabitEthernet3/1/1

90.0.0.0/24 LDP NULL/3 Ten-GigabitEthernet3/1/1

1.1.1.1/32 LDP 3/NULL InLoop0

50.0.0.0/24 LDP NULL/3 Ten-GigabitEthernet3/1/1

70.0.0.0/24 LDP NULL/3 Ten-GigabitEthernet3/1/1

3.3.3.3/32 LDP NULL/1025 Ten-GigabitEthernet3/1/1

(2) 检查MPLS LDP会话，如果状态不是Operational，说明会话存在错误，请转步骤（3）、（4）；如果MPLS LDP会话正常，请转步骤（5）。

[PE1] display mpls ldp peer

Total number of peers: 1

Peer LDP ID State Role GR MD5 KA Sent/Rcvd

4.4.4.4:0 Operational Passive Off Off 39/39

(3) 通过display mpls ldp interface命令查看LDP接口的相关信息。如配置信息不正确，请检查MPLS LDP配置。

[PE1] display mpls ldp interface

Interface MPLS LDP Auto-config

Vlan103 Enabled Configured -

XGE3/1/2 Enabled Configured -

XGE3/1/6 Enabled Configured -

(4) 检查接口下是否使能MPLS、MPLS LDP。如未使能，请使能MPLS和MPLS LDP。建立LSP的所有接口上均需要使能MPLS和MPLS LDP。

[PE1] interface ten-gigabitethernet 3/1/1

[PE1-Ten-GigabitEthernet3/0/1] display this

interface Ten-GigabitEthernet3/1/1

ip address 1.1.1.2 255.255.255.0

mpls enable

mpls ldp enable

return

(5) 检查配置的mpls lsr-id是不是等于Loopback接口IP地址。推荐使用设备上某个Loopback接口的地址作为LSR ID。

<PE1> display current-configuration | include lsr-id

mpls lsr-id 2.2.2.2

<PE1> display ip interface brief

*down: administratively down

(s): spoofing

Interface Physical Protocol IP Address Description

Loop0 up up(s) 100.100.100.100 LoopBack0..

Loop2 up up(s) 100.100.100.102 LoopBack2..

Ten-GigabitEthernet3/1/0 up up 192.168.147.7 Ten-GigabitEthernet..

<PE1> system-view

[PE1] mpls lsr-id 100.100.100.100

(6) 检查路由表中PE1、P、PE2的环回口IP及远端VLAN接口的IP表项是否存在，如不存在，请检查路由协议配置。

[PE1] display ip routing-table

Destinations : 10 Routes : 10

Destination/Mask Proto Pre Cost NextHop Interface

1.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0

3.3.3.3/32 O_INTER 10 2 103.0.0.4 Ten-GigabitEthernet3/1/1

4.4.4.4/32 O_INTER 10 1 103.0.0.4 Ten-GigabitEthernet3/1/1

50.0.0.0/24 O_INTER 10 2 103.0.0.4 Ten-GigabitEthernet3/1/1

70.0.0.0/24 O_INTER 10 2 103.0.0.4 Ten-GigabitEthernet3/1/1

90.0.0.0/24 O_INTER 10 2 103.0.0.4 Ten-GigabitEthernet3/1/1

103.0.0.0/24 Direct 0 0 103.0.0.1 Ten-GigabitEthernet3/1/1

103.0.0.1/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.1/32 Direct 0 0 127.0.0.1 InLoop0

(7) 检查路由协议状态是否正常（下面以查看OSPF协议状态为例），如不正常，请检查路由协议配置。

[PE1] 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 Interface State

4.4.4.4 103.0.0.4 1 37 Vlan103 Full/BDR

(8) 检查协议中环回口、VLAN接口的路由是否被通告，如不正确，请添加配置。

[PE1-ospf-1] display this

ospf 1

area 0.0.0.0

network 103.0.0.0 0.0.0.255

network 1.1.1.1 0.0.0.0

return

(9) 如仍不正常，请检查本端、对端设备的路由协议配置。

(10) 如仍无法确认，请将故障信息发送技术支持人员分析。

11.2 LDP故障处理

11.2.1 LDP会话震荡

1. 故障描述

LDP会话状态频繁震荡。

2. 常见原因

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

· 接口震荡

· 路由震荡

· CPU利用率过高

3. 故障分析

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

图11-3 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. 告警与日志

11.2.2 LDP会话无法Up

1. 故障描述

LDP会话无法Up。

2. 常见原因

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

· 建立会话的接口处于Down状态

· LSR ID配置错误

· 不存在LDP会话的相关配置

· 传输地址配置错误

· LDP Hello-hold定时器超时

· LDP Keepalive-hold定时器超时

· 安全认证配置错误

3. 故障分析

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

图11-4 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 Ten-GigabitEthernet3/1/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 Ten-GigabitEthernet3/1/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. 告警与日志

11.2.3 LDP LSP震荡

1. 故障描述

LDP网络中LDP LSP频繁震荡。

2. 常见原因

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

· 路由震荡。

· LDP会话震荡。

3. 故障分析

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

(1) 检查路由是否震荡。

(2) 检查LDP会话是否震荡。

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

图11-5 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 Ten-GigabitEthernet3/1/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会话震荡，则请参见“11.2.1 LDP会话震荡”故障进行定位。

¡ 如果LDP会话没有震荡，则执行步骤(3)。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

11.2.4 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建立会话的接口是否一致。

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

图11-6 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会话没有正常建立，请参见“11.2.2 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 XGE1/0/13/1/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:

Ten-GigabitEthernet3/1/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. 告警与日志

11.3 MPLS L2VPN/VPLS通用故障处理

11.3.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模板下开启控制字功能来解决本类故障。

· 回显信息为Request time out时，先排查本端PW是否Up，再通过tracert mpls pw命令来定位故障节点。

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

图11-7 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模板下开启控制字功能。

回显信息为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命令开启）配置一致。

- Encapsulation not match：PW两端封装类型不一致，此类故障的处理方式为，将PW两端引用的PW模板下的PW数据封装类型（通过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协商功能。

- 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 XGE3/1/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

11.4 VPLS故障处理

11.4.1 VPLS的VSI不能up

1. 故障描述

执行display l2vpn vsi verbose命令，查看对应VSI的状态不是up的状态。

<Sysname> display l2vpn vsi verbose

VSI Name: vpls1

VSI Index : 0

VSI Description : vsi for vpls1

VSI State : Up

MTU : 1500

Diffserv Mode : -

Bandwidth : Unlimited

Broadcast Restrain : 5120 kbps

Multicast Restrain : 5120 kbps

Unknown Unicast Restrain: 5120 kbps

MAC Learning : Enabled

MAC Table Limit : Unlimited

MAC Learning rate : Unlimited

Drop Unknown : Disabled

PW Redundancy Mode : Independent

Flooding : Enabled

Statistics : Disabled

VXLAN ID : -

LDP PWs:

Peer PW ID Link ID State

192.3.3.3 1 8 Up

192.3.3.3 1001 8 Blocked

BGP PWs:

Peer Remote Site Link ID State

192.4.4.4 1 9 Up

ACs:

AC Link ID State

XGE3/1/1 1 Up

2. 故障诊断流程

图11-8 故障诊断流程图

3. 故障处理步骤

(1) 检查两端的封装类型/MTU是否一致

执行display l2vpn ldp verbose命令，查看两端的封装类型/MTU是否一致。

¡ 如果两端的封装类型不一致，在PW模板视图下，配置pw-type命令修改其中一端的封装类型，使两端的封装类型一致。

¡ 如果两端的MTU不一致，在VSI视图下，配置mtu命令修改其中一端的MTU，使两端的MTU一致。

<Sysname> display l2vpn ldp verbose

Peer: 2.2.2.9 PW ID: 500

VSI Name: ccc

PW State: Up

PW Status Communication: Notification method

PW Preferential Forwarding Status Bit: Process

PW ID FEC (Local/Remote):

PW Type : VLAN/VLAN

Group ID : 0/0

Label : 1552/1552

Control Word: Disabled/Disabled

VCCV CV Type: -/-

VCCV CC Type: -/-

Flow Label : Send/Recv

MTU : 1500/1500

PW Status : PW forwarding/PW forwarding

(2) 检查两端的PW-ID是否一致

如果两端的PW-ID不一致，在VSI LDP信令视图下，配置peer命令修改pw-id参数，使两端一致。

(3) 隧道策略选取是否正确

查看隧道策略配置，确认隧道策略选取的隧道类型，并通过display mpls forwarding nhlfe命令查看该类型的隧道是否存在且up，若不存在，请建立该类型的隧道。

(4) 检查两端的AC接口状态是否Up

执行display interface brief命令，查看接口信息，确保接口状态为up。

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

¡ 上述步骤的执行结果。

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

11.4.2 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

XGE3/1/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命令开启）配置一致。

¡ Encapsulation not match：PW两端封装类型不一致，此类故障的处理方式为，将PW两端引用的PW模板下的PW数据封装类型（通过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协商功能。

¡ Remote AC Down：对端AC状态down，此类故障的处理方式为，检查并修改对端AC接口上的配置或排除AC所在的接口的故障，保障接口为Up状态。

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

¡ 上述步骤的执行结果。

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

¡ 使用display diagnostic-information命令收集诊断信息。

5. 告警与日志

11.4.3 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迭代的公网隧道信息。

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

图11-9 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

XGE3/1/3 srv1 1 Up Manual

(2) 若AC的状态为Down，则检查AC配置是否正确和并检查AC所在的接口是否Up。如果AC配置不正确或AC所在的接口为Down状态，请修改AC配置或排查接口故障。

(3) 若PW的状态为Down，请通过display l2vpn pw verbose命令查看PW状态变为Down的原因。