H3C MSR系列路由器

故障处理手册

资料版本：6W101-20221102

非经本公司书面许可，任何单位和个人不得擅自摘抄、复制本文档内容的部分或全部，并不得以任何形式传播。

除新华三技术有限公司的商标外，本手册中出现的其它公司的商标、产品标识及商品名称，由各自权利人拥有。

本文档中的信息可能变动，恕不另行通知。

3 3G/4G/5G链路故障处理··· 55

7 二层技术-以太网交换类故障处理··· 86

7.1 生成树故障处理·· 86

7.2 以太网链路聚合故障处理·· 93

8 二层技术-广域网接入类故障处理··· 107

8.1 PPP故障处理·· 107

8.2 PPPoE故障处理·· 112

9 三层技术-IP路由类故障处理··· 114

11.2 MPLS L2VPN/VPLS故障处理·· 204

11.3 MPLS L3VPN故障处理·· 208

11.4 MPLS TE故障处理·· 233

11.5 MPLS基础故障处理·· 243

11.6 VPLS故障处理·· 248

12 Segment Routing故障处理··· 257

12.1 EVPN L3VPN over SRv6故障处理·· 257

12.2 SR-MPLS故障处理·· 262

12.3 SRv6 TE Policy故障处理·· 269

13 VXLAN类故障处理··· 274

13.1 VXLAN故障处理·· 274

14 EVPN类故障处理··· 278

14.1 EVPN VXLAN故障处理·· 278

15 ACL和QoS故障处理··· 292

15.1 QoS故障处理·· 292

16 用户接入与认证故障处理··· 296

16.1 802.1X故障处理·· 296

16.2 AAA故障处理·· 303

16.3 MAC地址认证故障处理·· 340

16.4 Password Control故障处理·· 347

16.5 Portal故障处理·· 353

17 安全类故障处理··· 369

17.1 SSH故障处理·· 369

17.2 SSL VPN故障处理·· 376

17.3 IPsec故障处理·· 383

18 系统管理类故障处理··· 388

18.1 NETCONF故障处理·· 388

19 网络管理和监控类故障处理··· 392

19.1 Ping和Tracert故障处理·· 392

1 简介

本文档介绍MSR路由器软、硬件常见故障的诊断及处理措施。

1.1 故障处理注意事项

设备正常运行时，建议您在完成重要功能的配置后，及时保存并备份当前配置，以免设备出现故障后配置丢失。建议您定期将配置文件备份至远程服务器上，以便故障发生后能够迅速恢复配置。

在进行故障诊断和处理时，请注意以下事项：

· 设备出现故障时，请尽可能全面、详细地记录现场信息（包括但不限于以下内容），收集信息越全面、越详细，越有利于故障的快速定位。

¡ 记录具体的故障现象、故障时间、配置信息。

¡ 记录完整的网络拓扑，包括组网图、端口连接关系、故障位置。

¡ 收集设备的日志信息和诊断信息（收集方法见1.2 收集设备运行信息）。

¡ 记录设备故障时单板、电源、风扇指示灯的状态，或给现场设备拍照记录。

¡ 记录现场采取的故障处理措施（比如配置操作、插拔线缆、手工重启设备）及实施后的现象效果。

¡ 记录故障处理过程中配置的所有命令行显示信息。

· 更换和维护设备部件时，请佩戴防静电手腕，以确保您和设备的安全。

· 故障处理过程中如需更换硬件部件，请参考与软件版本对应的版本说明书，确保新硬件部件和软件版本的兼容性。

1.2 收集设备运行信息

为方便故障快速定位，请使用命令info-center enable开启信息中心。缺省情况下信息中心处于开启状态。

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

表1 设备运行信息介绍

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

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

1.2.2 logfile日志

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

<Sysname> logfile save

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

(2) 查看日志文件的数目和名称。

· 查看设备的logfile日志：（集中式设备）

<Sysname> dir cfa0:/logfile/

Directory of cfa0:/logfile

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

1021104 KB total (421552 KB free)

· 查看主设备的logfile日志：（集中式IRF设备）

<Sysname> dir flash:/logfile/

Directory of flash:/logfile

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

1021104 KB total (421552 KB free)

· 查看成员设备的logfile日志：（集中式IRF设备）

<Sysname> dir slot2#flash:/logfile/

Directory of slot2#flash:/logfile

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

1021104 KB total (421552 KB free)

· 查看设备主用主控板的logfile日志：（分布式设备－独立运行模式）

<Sysname> dir cfa0:/logfile/

Directory of cfa0:/logfile

0 -rw- 21863 Jul 11 2013 16:00:37 logfile8.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 logfile8.log

1021104 KB total (421552 KB free)

· 查看主设备主用主控板的logfile日志：（分布式设备－IRF模式）

<Sysname> dir cfa0:/logfile/

Directory of cfa0:/logfile

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

1021104 KB total (421552 KB free)

· 查看主设备备用主控板的logfile日志：（分布式设备－IRF模式）

<Sysname> dir slot1#cfa0:/logfile/

Directory of slot1#cfa0:/logfile

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

1021104 KB total (421552 KB free)

· 查看成员设备主控板的logfile日志，如果备设备有两块主控板，则两块都需要检查：（分布式设备－IRF模式）

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

Directory of chassis2#slot0#cfa0:/logfile

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

1021104 KB total (421552 KB free)

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

1.2.3 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/diagfile18.log

(2) 查看诊断日志文件的数目和名称。

· 查看设备的diagfile日志：（集中式设备）

<Sysname> dir cfa0:/diagfile/

Directory of cfa0:/diagfile

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

1021104 KB total (421416 KB free)

· 查看主设备的diagfile日志：（集中式IRF设备）

<Sysname> dir flash:/diagfile/

Directory of flash:/diagfile

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

1021104 KB total (421416 KB free)

· 查看成员设备的diagfile日志：（集中式IRF设备）

<Sysname> dir slot2#flash:/diagfile/

Directory of slot2#flash:/diagfile

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

1021104 KB total (421416 KB free)

· 查看设备主用主控板的diagfile日志：（分布式设备－独立运行模式）

<Sysname> dir cfa0:/diagfile/

Directory of cfa0:/diagfile

0 -rw- 161321 Jul 11 2013 16:16:00 diagfile18.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 diagfile18.log

1021104 KB total (421416 KB free)

· 查看主设备主用主控板的diagfile日志：（分布式设备－IRF模式）

<Sysname> dir cfa0:/diagfile/

Directory of cfa0:/diagfile

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

1021104 KB total (421416 KB free)

· 查看主设备备用主控板的diagfile日志：（分布式设备－IRF模式）

<Sysname> dir slot1#cfa0:/diagfile/

Directory of slot1#cfa0:/diagfile

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

1021104 KB total (421416 KB free)

· 查看成员设备主控板的diagfile日志，如果成员设备有两块主控板，则两块都需要检查：（分布式设备－IRF模式）

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

Directory of chassis2#slot0#cfa0:/diagfile

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

1021104 KB total (421416 KB free)

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

1.2.4 诊断信息

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

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

通过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:/MSR-CMW710-BOOT-R7328_mrpnc.bin

cfa0:/MSR-CMW710-SYSTEM-R7328_mrpnc.bin

Main startup software images:

cfa0:/MSR-CMW710-BOOT-R7328_mrpnc.bin

cfa0:/MSR-CMW710-SYSTEM-R7328_mrpnc.bin

Backup startup software images:

None

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

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

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

BAGG1 0 0 0 0

GE4/0/1 0 0 0 0

GE4/0/2 2 2 0 0

GE4/0/3 0 0 0 0

GE4/0/4 0 0 0 0

GE4/0/5 0 0 0 0

GE4/0/6 0 0 0 0

GE4/0/7 0 0 0 0

GE4/0/8 0 0 0 0

GE4/0/9 0 0 0 0

GE4/0/10 0 0 0 0

……

1.3 故障处理求助方式

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

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

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

2 硬件类故障处理

2.1 系统类故障

2.1.1 终端无显示或显示乱码

1. 故障描述

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

2. 常见原因

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

· 电源工作异常。

· 主控板工作异常。

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

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

· 配置电缆故障。

3. 故障分析

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

图1 故障诊断流程图

4. 处理步骤

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

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

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

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

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

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

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

(5) 更换配置电缆。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

2.1.2 设备异常重启

1. 故障描述

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

2. 常见原因

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

3. 故障分析

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

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

4. 处理步骤

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

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

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

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

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

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

2.1.3 温度异常告警

1. 故障描述

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

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

2. 常见原因

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

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

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

· 设备防尘网积灰过多。

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

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

3. 故障分析

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

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

4. 处理步骤

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

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

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

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

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

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

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

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

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

2.1.4 电压异常告警

1. 故障描述

系统打印电压异常告警信息，例如：

DEV/4/VOLTAGE_HIGH: Voltage is greater than the high-voltage alarm threshold on chasiss 1 slot 16 voltage sensor 1.

DEV/4/VOLTAGE_LOW: Voltage is less than the low-voltage alarm threshold on chasiss 1 slot 16 voltage sensor 24.

2. 常见原因

本类故障的常见原因一般为硬件出现故障。

3. 故障分析

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

图4 电压异常故障诊断流程图

4. 处理步骤

使用display voltage命令查看设备上电压传感器的电压信息，如果存在异常，请联系技术支持人员。

5. 告警与日志

2.1.5 内存异常告警

1. 故障描述

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

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

2. 常见原因

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

3. 故障分析

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

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

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.6 CPU占用率高

1. 故障描述

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

<Sysname> display cpu-usage

Slot 1 CPU 0 CPU usage:

80% in last 5 seconds

80% in last 1 minute

80% in last 5 minutes

2. 常见原因

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

· 路由振荡

· 报文攻击

· 链路环路

3. 故障分析

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

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

4. 处理步骤

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

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

首次查看路由表：

[Sysname] display ip routing-table

Destinations : 9 Routes : 9

Destination/Mask Proto Pre Cost NextHop Interface

0.0.0.0/32 Direct 0 0 127.0.0.1 InLoop0

10.1.1.0/24 OSPF 150 1 11.2.1.1 Vlan100

127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0

127.0.0.0/32 Direct 0 0 127.0.0.1 InLoop0

127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0

127.255.255.255/32 Direct 0 0 127.0.0.1 InLoop0

224.0.0.0/4 Direct 0 0 0.0.0.0 NULL0

224.0.0.0/24 Direct 0 0 0.0.0.0 NULL0

255.255.255.255/32 Direct 0 0 127.0.0.1 InLoop0

再次查看路由表：

[Sysname] display ip routing-table

Destinations : 8 Routes : 8

Destination/Mask Proto Pre Cost NextHop Interface

0.0.0.0/32 Direct 0 0 127.0.0.1 InLoop0

127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0

127.0.0.0/32 Direct 0 0 127.0.0.1 InLoop0

127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0

127.255.255.255/32 Direct 0 0 127.0.0.1 InLoop0

224.0.0.0/4 Direct 0 0 0.0.0.0 NULL0

224.0.0.0/24 Direct 0 0 0.0.0.0 NULL0

255.255.255.255/32 Direct 0 0 127.0.0.1 InLoop0

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

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

(3) 检查是否存在链路

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

<Sysname> display interface gigabitethernet3/0/1

GigabitEthernet3/0/1

Current state: UP

Line protocol state: UP

Description: GigabitEthernet3/0/1 Interface

Bandwidth: 1000000 kbps

Maximum transmission unit: 1500

Internet address: 2.1.1.2/24 (primary)

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

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

Loopback is not set

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

Port priority: 0

1000Mbps-speed mode, full-duplex mode

Link speed type is autonegotiation, link duplex type is autonegotiation

Flow-control is not enabled

Maximum frame length: 9216

Last clearing of counters: Never

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

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

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

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

……

如链路出现环路：

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

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

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

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

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

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

<Sysname> display process cpu slot 1

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

JID 5Sec 1Min 5Min Name

1 0.0% 0.0% 0.0% scmd

2 0.0% 0.0% 0.0% [kthreadd]

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

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

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

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

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

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

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

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

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

……

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

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

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

<Sysname> system-view

[Sysname] probe

[Sysname-probe] follow job 145 slot 1

Attaching to process 145 ([dGDB])

Iteration 1 of 5

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

Kernel stack:

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

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

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

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

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

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

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

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

Iteration 2 of 5

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

Kernel stack:

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

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

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

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

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

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

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

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

Iteration 3 of 5

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

Kernel stack:

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

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

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

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

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

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

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

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

Iteration 4 of 5

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

Kernel stack:

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

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

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

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

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

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

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

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

Iteration 5 of 5

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

Kernel stack:

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

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

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

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

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

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

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

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

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

2.2 电源类故障

2.2.1 电源模块状态异常

1. 故障描述

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

2. 常见原因

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

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

· 电源模块安装不到位。

· 电源线缆没有插牢。

· 电源模块温度过高。

· 电源模块故障。

3. 故障分析

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

图7 故障诊断流程图

4. 处理步骤

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

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

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

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

<Sysname> display power

Index Status

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

PWR1 normal

PWR2 Absent

也可以使用display alarm命令查看电源模块告警信息。

<Sysname> display alarm

Slot CPU Level Info

- - INFO Power 1 is absent.

- - INFO Power 2 is absent.

- - INFO Power 3 is absent.

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

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

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

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

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

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

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

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

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

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

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

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

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

2.3 单板故障

2.3.1 单板状态异常故障

1. 故障描述

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

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

2. 常见原因

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

· 单板安装不到位。

· 单板损坏。

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

· 电源模块故障。

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

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

3. 故障分析

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

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

4. 处理步骤

· 单板状态Absent

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

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

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

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

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

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

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

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

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

¡ 上述步骤的执行结果。

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

· 单板状态Power-off。

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

<Sysname> display power-supply verbose

Index Status Type Description

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

PWR1 normal 10W DC Power

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

¡ 上述步骤的执行结果。

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

· 单板状态Fault。

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

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

¡ 上述步骤的执行结果。

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

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

readed value is 55555555 , expected value is aaaaaaaa

DRAM test fails at: 080ffff8

Fatal error! Please reboot the board.

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

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

¡ 上述步骤的执行结果。

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

· 单板重启异常

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

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

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

<Sysname> display version

H3C Comware Software, Version 7.1.064, Release 6728P17

H3C MSR810 uptime is 0 weeks, 1 day, 19 hours, 11 minutes

Last reboot reason : User reboot

Boot image: flash:/msr810s-cmw710-boot-r6728p17.bin

Boot image version: 7.1.064P80, Release 6728P17

Compiled Mar 23 2022 15:00:00

System image: flash:/msr810s-cmw710-system-r6728p17.bin

System image version: 7.1.064, Release 6728P17

Compiled Mar 23 2022 15:00:00

Feature image(s) list:

flash:/msr810s-cmw710-devkit-r6728p17.bin, version: 7.1.064

Compiled Mar 23 2022 15:00:00

flash:/msr810s-cmw710-data-r6728p17.bin, version: 7.1.064

Compiled Mar 23 2022 15:00:00

CPU ID: 0xa

512M bytes DDR3 SDRAM Memory

256M bytes Flash Memory

PCB Version: 2.0

CPLD Version: 0.0

Basic BootWare Version: 1.11

Extended BootWare Version: 1.11

[SLOT 0]CON (Hardware)2.0, (Driver)1.0, (CPLD)0.0

[SLOT 0]4FSW (Hardware)2.0, (Driver)1.0, (CPLD)0.0

[SLOT 0]CELLULAR0/0 (Hardware)2.0, (Driver)1.0, (CPLD)0.0

[SLOT 1]CELLULAR (Hardware)1.0, (Driver)1.0, (CPLD)0.0

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

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

2.4 端口故障

2.4.1 端口出现CRC错误

1. 故障描述

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

<Sysname> display interface gigabitethernet1/0/1

GigabitEthernet1/0/1

Current state: DOWN

Line protocol state: DOWN

Description: GigabitEthernet1/0/1 Interface

Bandwidth: 1000000 kbps

Maximum transmission unit: 1500

Internet address: 2.1.1.2/24 (primary)

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

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

Loopback is not set

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

Port priority: 0

1000Mbps-speed mode, full-duplex mode

Link speed type is autonegotiation, link duplex type is autonegotiation

Flow-control is not enabled

Maximum frame length: 9216

Last clearing of counters: Never

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

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

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

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

Input (total): 2892 packets, 236676 bytes

24 unicasts, 2 broadcasts, 2866 multicasts, 0 pauses

Input (normal): 2892 packets, - bytes

24 unicasts, 2 broadcasts, 2866 multicasts, 0 pauses

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

3 CRC, 0 frame, - overruns, 0 aborts

- ignored, - parity errors

Output (total): 29 packets, 1856 bytes

24 unicasts, 5 broadcasts, 0 multicasts, 0 pauses

Output (normal): 29 packets, - bytes

24 unicasts, 5 broadcasts, 0 multicasts, 0 pauses

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

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

0 lost carrier, - no carrier

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

2. 常见原因

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

· 端口异常。

· 电缆连接器损坏。

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

· 光功率不足。

· 中间链路或设备故障。

· 设备或单板硬件故障。

3. 故障分析

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

图9 故障诊断流程图

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.4.2 端口不接收报文

1. 故障描述

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

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

2. 常见原因

· 端口出现CRC错误。

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

· 设备或单板硬件故障。

3. 故障分析

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

图10 故障诊断流程图

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.4.3 端口不发送报文

1. 故障描述

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

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

2. 常见原因

· 光模块异常。

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

· 设备或单板硬件故障。

3. 故障分析

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

图11 故障诊断流程图

4. 处理步骤

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

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

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

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

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

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

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

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

5. 告警与日志

2.4.4 电口无法UP

1. 故障描述

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

2. 常见原因

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

· 端口配置问题。

· 网线有问题。

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

3. 故障分析

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

图12 故障诊断流程图

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

GE1/0/1 DOWN DOWN --

Loop0 UP UP(s) 2.2.2.9

NULL0 UP UP(s) --

Vlan1 UP UP --

Vlan999 UP UP 192.168.1.42

Brief information on interfaces in bridge mode:

Link: ADM - administratively down; Stby - standby

Speed: (a) - auto

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

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

Interface Link Speed Duplex Type PVID Description

GE1/0/2 DOWN auto A A 1 aaaaaaa

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

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

<Sysname> display interface gigabitethernet 1/0/1

GigabitEthernet1/0/1

Current state: Administratively DOWN

Line protocol state: DOWN

Description: GigabitEthernet1/0/1 Interface

Bandwidth: 1000000 kbps

Maximum transmission unit: 1500

Allow jumbo frames to pass

Broadcast max-ratio: 100%

Multicast max-ratio: 100%

Unicast max-ratio: 100%

Internet protocol processing: Disabled

...

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

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

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

2.4.5 端口频繁UP/DOWN

1. 故障描述

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

2. 常见原因

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

· 光模块或线缆故障

· 电口自协商不稳定

3. 故障分析

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

图13 故障诊断流程图

4. 处理步骤

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

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

GigabitEthernet1/0/1 transceiver current alarm information:

RX loss of signal

RX power low

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

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

GigabitEthernet1/0/1 transceiver diagnostic information:

Current diagnostic parameters:

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

36 3.31 6.13 -35.64 -5.19

Alarm thresholds:

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

High 50 3.55 1.44 -10.00 5.00

Low 30 3.01 1.01 -30.00 0.00

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

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

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

2.5 光模块故障

2.5.1 光口不UP故障

1. 故障描述

光口不UP。

2. 常见原因

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

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

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

· 光口故障。

· 光模块或线缆故障。

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

3. 故障分析

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

图14 故障诊断流程图

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

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

图15 故障诊断流程图

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.5.3 光模块不支持数字诊断

1. 故障描述

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

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

The transceiver does not support this function.

2. 常见原因

· 光模块为非H3C光模块。

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

· 光模块故障。

· 设备/光口故障。

3. 故障分析

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

图16 故障诊断流程图

4. 处理步骤

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

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

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

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

¡ 上述步骤的执行结果。

¡ 设备的告警信息。

5. 告警与日志

2.5.4 光模块序列号丢失

1. 故障描述

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

2. 常见原因

· 光模块未插紧。

· 光模块/设备故障。

3. 故障分析

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

图17 故障诊断流程图

4. 处理步骤

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

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

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

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

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

¡ 上述步骤的执行结果。

¡ 设备的告警信息。

5. 告警与日志

2.6 PoE供电故障

2.6.1 PoE供电异常

1. 故障描述

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

2. 常见原因

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

· PSE固件故障。

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

3. 故障分析

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

图18 故障诊断流程图

4. 处理步骤

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

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

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

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

<Sysname> display poe device

Slot 1:

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

1 0 0 48 0 Faulty LSP1POEA

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

b. 联系H3C技术支持人员或设备供应商获取对应版本的PSE固件，然后执行poe update命令升级PSE固件。升级方法如下所示：

<Sysname> system-view

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

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

……

以上显示信息说明PSE软件升级成功。

c. 再次执行display poe device命令查看PSE的工作状态。如果工作状态显示为on或off，则说明PSE故障已修复。如下所示：

[Sysname] display poe device

Slot 1:

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

1 0 0 48 0 on LSP1POEA

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

<Sysname> display poe pse

PSE ID : 1

Slot NO. : 0

PSE Model : LSBMPOEGV48TP

PSE Status : Enabled

PSE Preempted : No

Power Priority : Low

Current Power : 130 W

Average Power : 20 W

Peak Power : 240 W

Max Power : 200 W

Remaining Guaranteed Power : 120 W

PSE CPLD Version : 100

PSE Software Version : 200

PSE Hardware Version : 100

Legacy PD Detection : Disabled

Power Utilization Threshold : 80

PSE Power Policy : Disabled

PD Power Policy : Disabled

PD Disconnect-Detection Mode : DC

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

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

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

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

PoE Status : Enabled

Power Priority : Critical

Oper : On

IEEE Class : 1

Detection Status : Delivering power

Power Mode : Signal

Current Power : 11592 mW

Average Power : 11610 mW

Peak Power : 11684 mW

Max Power : 15400 mW

Electric Current : 244 mA

Voltage : 51.7 V

PD Description : IP Phone For Room 101

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

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

2.7 E1&T1接口故障处理

2.7.1 E1&T1常见排查方法

E1/T1常见排查方法有：

· 硬件排查。

· 线缆排查。

· 配置排查。

· 时钟排查。

· 接地排查。

· 打环排查。

1. 硬件排查方法

(1) 确认外接电源连接：

对问题主机进行独立供电测试以排除电源问题。

(2) 本地自环测试：

在E1/T1接口下配置loopback local命令或在E1-F/T1-F接口视图下配置fe1 loopback local/ft1 loopback local命令观察接口物理是否up，并观察逻辑串口上的收发是否正确环回，如果正常可以初步排除板卡硬件问题。

a. 如果接口本地自环失败，并且在更换槽位后本地自环成功，可以定位为硬件问题，将问题主机走分析件流程。

b. 更换单板测试，如果接口本地自环失败，并且在更换单板后本地自环成功，可以定位为硬件问题，将问题单板走分析件流程。

c. 更换主机测试，如果接口本地自环失败，并且在更换主机后本地自环成功，可以定位为硬件问题，将问题主机走分析件流程。

2. 线缆排查方法

(1) 线缆质量排查

¡ 确保线缆为我司标准线缆。

¡ 更换电缆。

¡ 将电缆收发短接，查看接口是否能成功自环。若自环成功，可排除线缆问题。如何查看自环请参见2.7.1 6. 打环排查方法。

(2) 排查线缆阻抗与接口阻抗是否匹配

¡ 通过display controller或display fe1获取接口阻抗（例文中蓝色字体）：

<Sysname> display controller E1 1/0/0

E1 1/0/0 current state :DOWN

Description : E1 1/0/0 Interface

Basic Configuration:

Work mode is E1 framed, Cable type is 120 Ohm balanced.

¡ 通过更换线缆或调整接口卡拨码开关（HMIM-8E1T1板卡使用硬件跳线和cable-type命令确认板卡阻抗类型）来保证线缆阻抗和接口阻抗的一致性。

接口类型：E1接口

相应命令：cable-type { 75 | 120 }

参数说明：75：匹配75欧的传输线路；120：匹配120欧的传输线路。

(3) 排查线缆长度与配置是否匹配

E1/T1接口对其使用的电缆长度有一定的限制，通常最大长度不能超过500米，当线缆越长，信号衰减越大，此时需对信号进行补偿或外接CSU设备，路由器提供了cable命令用来设置接口匹配的传输线路的衰减或长度，本命令作用是配置发送时的信号波形，以适应不同传输需要。实际使用中，可根据接收端收到的信号质量的好坏，来决定是否使用此命令。如果信号质量较好，可以使用缺省设置。

接口类型：E1接口

相应命令：cable { long | short }

参数说明：long：匹配655英尺以上的传输线路；short：匹配655英尺以下的传输线路。

接口类型：T1/T1-F接口

相应命令：cable { long decibel | short length }

参数说明：

long decibel：匹配655英尺以上的传输线路。参数decibel的值可以为0db、-7.5db、-15db、-22.5db，用户可根据接收端信号质量选择不同的衰减参数。当线路质量越差时，信号衰减越大，需要用户对这种衰减进行相应补偿，此时，不需要外接CSU。

short length：匹配655英尺以下的传输线路。参数length的值可以为133ft、266ft、399ft、533ft、655ft，用户可根据传输线路的长度，选择相应的长度参数。

3. 配置排查方法

(1) 通信两端配置要保持一致：

包括工作模式（成帧或非成帧）、帧格式、CRC校验方式、编码格式、线路空闲码、帧间填充符。

CISCO E1接口默认帧格式为CRC4，我司E1接口默认帧格式为NO-CRC4，两者互联时请使之保持一致。

(2) 用配置解决AIS告警误检问题：

如果线路上正常传输的数据为全1码流，空闲码为FF，当没有业务数据传输时，线路上传输的数据为全1的空闲码，即表现为AIS告警。

两种解决方案：

¡ 在路由器上配置undo detect-ais 命令，即不检测AIS命令。

¡ 把帧间填充改为7E。

4. 时钟排查方法

(1) 标准时钟方案

根据传输网络是否提供时钟，E1有两类时钟方案：

¡ 当传输网络提供时钟时，即传输为主时钟，E1对接双方都为从时钟。

图19 传输提供时钟时E1时钟配置方案

¡ 当传输网络不提供时钟时，即传输只进行透传，此时E1对接双方应一端配置主时钟，另一端配置从时钟。

图20 传输不提供时钟时E1时钟配置方案

(2) 频偏测量

如果时钟配置有误，会导致线路上时钟产生频偏。E1接口正常的频偏范围为正负50ppm，如果频偏超过这个范围，则不能保证数据收发正常。频偏有积累效应，即频偏会随着时间推移持续变大，表现为E1接口由正常到出现错包，直至到不可用状态。可通过shutdown/undo shutdown命令使频偏回到初时值，恢复接口使用。

通常，可以使用ETEN表来测量线路的频偏，方法为将ETEN串接在E1的接收或发送线路上，分别测试线路的收发频偏。

5. 接地排查方法

(1) 常见的不良接地和共地

¡ 设备安装在19英寸机柜中，但并未将设备的地线接到机柜的接地线上。

¡ 设备与对接设备在同一机房，设备只接地，但并未共地。

(2) 不良共地的影响

共地不良会导致对接双方基准电压不同，数据的收发和各种信号的检测不在一个电压平台上。于是，会出现本端发送的数据与对端接收的数据不一致，收发出现错包，严重时会导致协议up/down，或者本端正常的发送信号，对方无法检测或错误检测，导致物理上出现告警，E1物理接口up/down。

(3) 接地要求

¡ 设备必须接地。

¡ 如果设备与对接设备在同一机房，设备不但要接地，还要与对接设备共地。

¡ 接地导线必须采用铜导线以降低高频阻抗，接地线尽量粗和短，接地线不得使用铝材。

¡ 接地线两端的连接点应确保电气接触良好，并做防腐、防锈处理。

¡ 不得利用其他设备作为接地线电气连通的组成部分。

¡ 接地引线不能与信号线平行走线或相互缠绕。

¡ 保护地线上严禁接头，严禁加装开关或熔断器。

¡ 保护地线应选用黄绿双色相间的塑料绝缘铜芯导线。

¡ 保护地线的长度不应超过30米，且尽量短，当超过30米时，应要求客户就近重新设置地排。

¡ 设备如果用UPS供电，那么UPS也必须接地。

可靠接地是设备具有良好的防雷、防电击和抗干扰性能的基本要求，是设备长期可靠、稳定运行的前提。

(4) 不同环境中设备接地方法

¡ 安装环境中提供接地排

当设备所处安装环境中有接地排时，在确认接地排的接地连接可靠的情况下，将设备黄绿双色的保护接地电缆一端接至接地排的接线柱上，拧紧固定螺母（如图3-11所示）。保护接地电缆截面积必须不小于4mm²，工程施工时该电缆尽量短，不能盘绕。

图21 机房有接地排时接地安装简图

对于安装在19英寸机柜上的设备，可将设备黄绿双色的保护接地电缆接到19英寸机柜的接地端子上，并确认19英寸机柜的接地端子与机房接地排可靠连接。

¡ 安装环境中无接地排，并且条件不允许埋设接地体

当设备所处安装环境中没有接地排，并且条件不允许埋设接地体时。

¡ 若设备采用220V交流电供电，可以通过交流电源的PE线进行接地（如图3-12所示）。确认交流电源的PE线在配电室或交流供电变压器侧是否良好接地，并保证设备的PE端子可靠的和交流电源的PE线连接，设备的电源电缆应采用带保护地线的三芯电缆。若交流电源的PE线在配电室或交流供电变压器侧没有接地，应及时向客户提出整改的要求。

图22 利用交流PE线接地时接地安装简图

¡ 若设备采用-48V（或+24V）直流电供电，可以通过直流电源的回流线RTN或PGND进行接地（如图3-13所示）。确认RTN或PGND在直流电源柜的直流输出口处是可靠接地的，若RTN或PGND在直流电源柜的直流输出口处没有接地，应及时向客户提出整改的要求。

图23 利用电源柜PGND接地时接地安装简图

安装环境中无接地排，附近可以埋设接地体

¡ 当设备所处安装环境中没有接地排，附近有泥地并且允许埋设接地体时，可采用长度不小于0.5m的角钢或钢管，直接打入地下。角钢截面应不小于L×W×H = 50×50 ×5mm，钢管壁厚应不小于3.5mm，材料采用镀锌钢材。设备黄绿双色的保护接地电缆应和角钢采用电焊连接，焊接点表面应涂敷防锈漆进行防锈处理。保护接地电缆截面积必须不小于4mm2，工程施工时该电缆尽量短，不能盘绕（如图3-14所示）。

图24 机房附近允许埋设接地体时接地安装简图

（3）的方法较简易，接地电阻可能会很高，若(1)和(2)的接地条件均不具备，才可采用此接地方式。

(5) 接地电阻值

设备接地连接的机房接地排，其接地电阻应按照机房环境的要求来确定。对于电信中心机房，接地电阻按照YDJ26-89标准要求执行（标准要求小于1W）；对于非电信中心机房，接地电阻应小于5W；对于打入地下的角钢，其接地电阻可适当放宽，应小于10W。对于土壤电阻率高的地方，宜在接地体泥土周围撒一些盐水或降阻剂等措施来降低土壤的电阻率。

(6) 设备共地方法

对接设备之间一定要共地，同时各对接设备也要可靠接地。

¡ 如果对接设备都安装在19英寸机柜中，那么分别把对接设备的地线直接接到机柜的接地线上共地。

¡ 如果对接设备之间放置在同一个机房内，且距离不太远，那么可以通过把对接设备的接地线直接连接在一起，然后再接地的方法来共地，如下图所示。

图25 设备共地示意图

¡ 如果对接设备没有安装在同一个机房，无法通过接地线共地，那么采用对接设备分别可靠接地的方法来共地。

(7) 共地是否可靠的测量方法

图26 共地是否可靠的测量方法

按上图用接地线将对接设备的接地点引出，用万用电表测量这两点的电压和电阻：

良好的接地：被测两点的电阻应迅速归零，而电压值小于1V。

不良的接地：被测两点之间电阻值非零，或虽为零但并未迅速归零，或两点电压值大于1V。

6. 打环排查方法

(1) 常用的打环点

图27 共地是否可靠的测量方法

¡ 1打环点：

打环方法：在路由器上E1接口上配置loopbace local，在FE1接口下配置FE1 loopbace local。

测试目的：排查路由器接口本身收发是否正常。

¡ 2、3打环点：

打环方法：将Router1与传输1之间的E1收发线缆短接或在传输上向左侧打环。

测试目的：排查Router1和传输1之间线路是否正常。

¡ 4打环点：

打环方法：在传输2上向左侧打环。

测试目的：排查传输网络是否正常。

¡ 5打环点：

打环方法：将Router1与传输1之间的E1收发线缆短接。

测试目的：排查Router1到Router2直接整个物理链接是否正常。

¡ 6打环点：

打环方法：在Router2上E1接口上配置loopbace remote/loopbace payload，在FE1接口下配置fe1 loopbace remote/fe1 loopbace payload。

测试目的：排查整个链路，包括Router2是否正常。

(2) 打环后如何进行线路排查：

¡ 通过路由器自环检测功能进行排查

将接口链路层协议配置为PPP，查看接口收发以12个包的步长匀速增长，在接口信息中显示loopback is detected，而且接口上没有错包增加，则表明链路正常，否则为异常。

<Sysname> display interface serial 1/0:0

Serial1/0:0

Current state: UP

Line protocol state: DOWN

Description: Serial1/0:0 Interface

Bandwidth: 64kbps

Maximum Transmit Unit: 1500

Hold timer: 10 seconds, retry times: 5

Derived from E1 1/0, Timeslot(s) Used: 1, Baudrate is 64000 bps

Internet protocol processing: disabled

Link layer protocol: PPP, Loopback: detected

LCP: closed

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: Never

Last 300 seconds input rate: 0.00 bytes/sec, 0 bits/sec, 0.00 packets/sec

Last 300 seconds output rate: 0.00 bytes/sec, 0 bits/sec, 0.00 packets/sec

Input:

12 packets, 156 bytes

0 broadcasts, 0 multicasts

0 errors, 0 runts, 0 giants

0 CRC, 0 align errors, 0 overruns

0 aborts, 0 no buffers, 0 frame errors

Output:

12 packets, 156 bytes

0 errors, 0 underruns, 0 collisions

0 deferred

¡ 通过误码仪进行排查

用线路误码仪取代路由器的位置，将接在路由器上的收发线缆接在误码仪的收发上，此时误码仪即能显示线路上是否有误码存在。

2.7.2 E1&T1常见问题定位

常见的E1/T1模块问题可以分为以下两类：

· 物理接口异常，表现为controller接口信息存在LOS、LFA、AIS或RAI告警，物理一直down或反复up/down。

· 物理接口UP，并且没有告警，但数据收发异常，表现为对接双方接口上有错包或链路层协议up/down。

1. 物理接口异常问题

· 故障描述

物理接口异常，表现为 controller接口信息存在LOS、LFA、AIS或RAI告警，物理一直down或反复up/down。

· 故障处理步骤

按如下顺序进行问题排查

(1) 用硬件排查方法排查硬件问题。

(2) 用线缆排查方法排查线缆问题。

(3) 用配置排查方法排查配置问题。

(4) 用时钟排查方法排查时钟问题。

(5) 用接地排查方法排查接地问题。

(6) 用打环排查方法排查线路问题。

2. 数据收发异常问题

· 故障描述

物理接口UP，并且没有告警，但数据收发异常，表现为对接双方接口上有错包或链路层协议up/down。

· 故障处理步骤

按如下顺序进行问题排查

(1) 用硬件排查方法排查硬件问题。

(2) 用线缆排查方法排查线缆问题。

(3) 用配置排查方法排查配置问题。

(4) 用时钟排查方法排查时钟问题。

(5) 用接地排查方法排查接地问题。

(6) 用打环排查方法排查线路问题。

3. 信息收集建议

如果上述步骤无法定位或排除故障，请收集如下信息，并联系H3C技术支持人员：

· display diagnostic-information

· display device verbose

· display controller、display fe1或display ft1

· display interface serial(如收发有错包增长，请有间隔的多次收集该信息)

2.8 以太接口故障处理

2.8.1 无法ping通直连设备 问题

1. 故障描述

无法ping通与以太网接口直连的设备。

2. 故障处理步骤

(1) 通过display interface命令收集指定接口信息，查看：

· 接口状态是否UP。

· 接口两端速率双工是否匹配。

· 接口收发包统计是否正常，有无错包和丢包统计，如果有错包统计，可以先排除线缆问题或接口故障。

· 如果接口是光口查看两端光模块是否匹配。

(2) 通过display arp all命令查看是否学到直连接口的ARP，如果没有，通过debugging arp packet命令打开两台设备上的ARP调试开关，查看ARP收发是否存在异常情况。

(3) 通过debugging ip packet命令打开两个设备上的IP调试开关，通过debugging ip icmp命令打开ICMP调试开关，查看ICMP收发是否存在异常情况。

(4) 如果上述步骤无法具体定位故障，请联系H3C技术支持人员。

2.8.2 转发不通问题

1. 故障描述

以太网接口所在路由器作为中间设备转发流量时，流量转发不通。

2. 故障处理步骤

(1) 在没有流量转发的情况下，确认以太网接口与直连设备是否可以ping通，如果不通，请参见2.8.1 无法ping通直连设备问题处理。

(2) 通过debugging ip packet命令打开设备上的IP调试开关，查看IP报文收发是否存在异常情况。

(3) 如果上述步骤无法具体定位故障，请联系开发人员。

2.8.3 转发丢包问题

1. 故障描述

以太网接口转发流量有丢包问题。

2. 故障处理步骤

(1) 通过display counters rate inbound interface命令查看入接口速率统计，通过display counters rate outbound interface命令查看出接口速率统计，初步确认丢包的设备。

(2) 通过display interface命令查看流量出接口统计，查看qos队列入方向是否有流量，是否有丢包。

(3) 如果上述步骤无法具体定位故障，请联系H3C技术支持人员。

3. 故障诊断命令

命令	说明
display interface	查看接口信息
display arp all	查看所有的ARP表项信息
display counters rate inbound interface	查看入接口速率统计
display counters rate outbound interface	查看出接口速率统计
debugging arp packet	打开ARP的报文调试信息开关
debugging ip packet	打开IP报文调试信息开关
debugging ip icmp	打开ICMP调试信息开关

3 3G/4G/5G链路故障处理

3.1 故障描述

MSR路由器使用3G/4G/5G接口模块接入Internet，局域网用户无法上网，3G/4G/5G接口模块WWAN指示灯异常。

3.2 常见原因

· 3G/4G/5G接口模块或者USB 3G/4G Modem型号和主机型号不匹配。

· 主机软件版本不支持使用该3G/4G/5G接口模块。

· 3G/4G/5G接口模块安装的槽位不正确。

· 3G/4G/5G接口模块未安装到位。

· 3G/4G/5G接口模块热插拔操作不当。

· 3G/4G/5G接口模块或者USB 3G/4G Modem故障。

· 3G/4G/5G Modem未识别。

· SIM卡状态异常。

· 3G/4G/5G网络不稳定。

· 3G/4G/5G接口配置不正确。

3.3 故障分析

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

图28 3G/4G/5G链路故障诊断流程图

3.4 处理步骤

3.4.1 检查3G/4G/5G接口模块或者USB 3G/4G Modem状态

(1) 检查3G/4G/5G接口模块上的指示灯，如果所有指示灯均熄灭，则执行display device和display device manuinfo命令，查看Slot和电子标签信息。

<Sysname> display device

Slot No. Board Type Status Max Ports

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

0 RPU Normal 30

1 Unknown Abnormal Unknown

<Sysname>display device manuinfo

...

Slot 1:

DEVICE_NAME : NONE

DEVICE_SERIAL_NUMBER : NONE

MAC_ADDRESS : NONE

MANUFACTURING_DATE : NONE

VENDOR_NAME : NONE

(2) 如果Slot状态显示为Unknown，电子标签等相关信息显示为NONE。确认接口模块的型号是否和主机型号匹配，以及接口模块安装在主机的槽位是否正确，具体请参见《H3C MSR系列路由器接口模块手册》；如果是USB 3G/4G Modem，请联系技术支持确认主机是否支持该Modem。

(3) 确认接口模块是否安装到位。若未安装好，请重新拔插一下接口模块。重新插入前务必检查接口模块的连接器状态，看连接器是否变形、脏污。

(4) 将接口模块放到别的槽位，或者将主机上别的正常的接口模块放到这个槽位，进一步确认是不是接口模块故障。

(5) 仅部分带有REMOVE按钮接口模块支持热插拔，但是需要通过操作REMOVE按钮后再拔出接口模块，操作不当会导致设备或接口模块异常。如果已经带电拔插过接口模块，请尝试给主机断电重启恢复。

(6) 确认主机软件版本是否支持该接口模块。

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

b. 联系技术支持，确认当前主机软件版本是否支持该接口模块；

c.如果当前软件版本不支持该接口模块，请升级到正确版本。

(7) 如果是USB 3G/4G Modem，请把Modem插到PC上，待识别后查看以下信息，看PC是否能正常识别该Modem。

3.4.2 检查3G/4G/5G Modem状态

(1) 如果3G/4G/5G接口模块的信息可以正常显示，但是无法显示3G/4G/5G Modem的信息。

执行display cellular命令，无法显示Cellular接口信息。

<Sysname> display cellular 1/0

% Wrong parameter found at '^' position.

(2) 确认MSR路由器的款型和槽位是否正确。若不正确，请在支持的路由器的正确槽位上使用接口模块，具体请参见《H3C MSR系列路由器接口模块手册》。

(3) 确认接口模块是否外观有损伤、槽位的针脚是否有损伤。

(4) 确认是否已经通过remove命令或者“REMOVE”按钮将接口模块remove掉。部分带有REMOVE按钮的接口模块，若REMOVE指示灯熄灭，请重新拔插接口模块或者在用户视图下执行reboot命令重启接口模块。

(5) 确认接口模块是否在重启，接口模块完成初始化需要一定时间，请等待1-2分钟。

(6) 确认设备的版本是否正确。路由器版本需要升级到支持该Modem版本。若不正确，请升级版本。

(7) 部分CDMA制式的3G Modem不插SIM卡无法识别，请插入SIM卡后再测试。这些3G Modem也不支持4G SIM卡，所以插入4G SIM卡也无法识别。

(8) 仅部分带有REMOVE按钮接口模块支持热插拔，但是需要通过操作REMOVE按钮后再拔出接口模块，操作不当会导致设备或接口模块异常。如果已经带电拔插过接口模块，请尝试给主机断电重启恢复。

3.4.3 检查SIM卡状态

(1) 3G/4G/5G接口模块和3G/4G/5G Modem的信息都可以正常显示，但无法拨号成功并获取IP地址。查看接口模块的WWAN指示灯，如果为常灭，表明无线广域网链路处于未连接状态。执行display ip interface brief，通道化以太网接口没有获取IP地址。

<Sysname> display ip interface brief

*down: administratively down

(s): spoofing (l): loopback

Interface Physical Protocol IP address/Mask VPN instance Description

E-Ch1/0:0 down down -- -- --

(2) 请确认SIM卡与Modem支持的制式是否匹配。比如WCDMA制式的Modem插中国电信（CDMA运营商）SIM卡就无法注册网络。

(3) 请确认SIM卡的状态是否正常，SIM卡有“OK、Not Inserted、Locked、Unknown、Network Reject”等状态，执行display cellular命令查看SIM卡状态。

<Sysname> display cellular 1/0

...

SIM Status: OK

...

¡ OK表示正常，无需处理。

¡ Not Inserted表示SIM安装异常，请检查SIM卡是否插好以及外观是否有损坏。

SIM卡的缺口方向一定要与卡槽的缺口方向对应上，SIM卡芯片面朝下，保证SIM卡接触良好；也可以再找一台设备或手机SIM卡，做SIM卡交叉测试；如果也没有问题，建议升级设备为最新的软件版本。

¡ Locked表示被锁定，请先解锁后再使用。若未完全锁定可以通过PUK码解锁，执行pin unlock命令进行解锁；若完全锁定则需要到营业厅解锁。

<Sysname> system-view

[Sysname] controller Cellular 1/0

[Sysname-Cellular1/0]pin unlock 87654321 1234

PIN will be unlocked and changed to “1234”. Continue? [Y/N]:y

PIN has been unlocked and changed successfully.

¡ Unknown表示状态未知。请尝试重新拔插SIM卡或执行modem reboot命令重启Modem。

<Sysname> system-view

[Sysname] controller cellular 1/0

[Sysname-Cellular1/0] modem reboot

¡ Network Reject表示SIM卡被拒绝接入网络。该状态处理方式同Locked和Unknown。

(4) 请确认SIM卡是否欠费。执行display cellular命令，查看Modem信息。如果“Current Service Status:Emergency”，打电话给营业厅确认。如果欠费再充值后，运营商开机了，重启一下Modem或者将该SIM卡插入手机看是否能上网。

<Sysname> display cellular 1/0

...

Network Information:

Current Service Status:Emergency

...

3.4.4 检查3G/4G/5G网络信号状态

(1) 如果3G/4G/5G接口模块和3G/4G/5G Modem的信息都可以正常显示，SIM卡状态也是正常，请查看当前3G/4G/5G网络信号状态。3G/4G/5G接口模块都提供有网络信号强度的指示灯，例如5G接口模块提供有5G指示灯，如果5G指示灯常灭，表示无信号；如果5G指示灯慢闪，表示5G信号弱。不同接口模块指示灯情况有差异，具体请参见《H3C MSR系列路由器接口模块手册》。

(2) 如果不方便查看指示灯状态，也可以通过执行display cellular命令查看当前网络的信号强度。

¡ 3G Modem可以使用RSSI表示信号强度，其值在-90dBm以下表示信号非常差，可能会影响业务正常使用。

<Sysname> display cellular 1/0

...

Radio Information:

Current Band: ANY

Current RSSI: -51 dBm

¡ 4G Modem除了查看RSSI外，还要查看RSRP，RSRP在-100dBm以下表示信号非常差。

<Sysname> display cellular 1/0

...

LTE related info:

Current RSSI: -79 dBm

Current RSRQ: -9 dB

Current RSRP: -106 dBm

Current SNR: 5 dB

¡ 5G Modem查看5G NR的信号强度，RSRP在-89dBm以下表示信号较弱，－100dB左右就可能无法驻入5G。

<Sysname> display cellular 1/0

...

Radio Information:

Technology Preference: No preference specified (AUTO)

Technology Selected: NR && LTE

Configured LTE Band = 1,2,3,4,5,7,8,12,13,14,17,18,19,20,25,26,28,29,30,32,34,38,39,40,41,42,43

5G availability under LTE system info:

Current PCI: 537

Endc Available: 1

Restrict Dcnr: 0

R15Availabe: 1

NR related info:

Current RSRQ: -12 dB

Current RSRP: -93 dBm

Current SNR: 14 dB

LTE related info:

Current RSSI: -65 dBm

Current RSRQ: -13 dB

Current RSRP: -103 dBm

Current SNR: -2 dB

Tx Power: 10 dBm

(3) 如果确认3G/4G/5G无信号，请先检查天线是否正常连接。

a. 设备内置模块和SIC卡必须安装外置天线，USB Modem不需要。另外，3G Modem可以只安装一根天线，但是天线必须安装到“MAIN”天线接口，不能接到“DIV”天线接口；4G Modem必须安装2根天线；5G Modem建议使用4根天线。

b. 如果天线连接正常，请继续确认周围是否有3G/4G/5G网络覆盖。可以使用手机或其他终端插SIM卡尝试，看是否能拨号成功。如果不行，请联系运营商解决。

(4) 如果确认3G/4G/5G信号比较弱，建议调整天线位置来增强无线信号。请注意，天线的方向一般要竖直向上，棒状天线之间可以呈八字状或剪刀状错开。在室内信号比较弱的地方，也可以通过增加天线延长线方式来增强无线信号。

3.4.5 检查3G/4G/5G接口的配置

(1) 如果3G/4G/5G接口模块的各项指示灯显示正常，但是3G/4G/5G链路仍然无法正常工作，此时，可以检查下3G/4G/5G Cellular接口的配置是否正确。3G/4G/5G Cellular接口的配置，请参见配套配置手册中“二层技术-广域网接入配置指导”内的“移动通信Modem管理配置”。一般建议配置永久在线模式，如果配置了按需拨号，需要流量才能触发拨号，ping几个包试试Eth-channel接口是否能够UP。

(2) 如果是USB 4G Modem，由于USB 4G Modem模块不支持通过配置命令来管理Modem模块，具体配置请参考对应主机的Web配置指导手册。

(3) 如果是连接VPDN网络，需要向运营商咨询正确的APN、用户名和密码。

¡ 对于3G Modem，可以通过profile create命令设置APN、用户名和密码。

<Sysname> system-view

[Sysname] controller cellular 1/0

[Sysname-Cellular1/0] profile create 1 static cmnet authentication-mode pap user abc password abc

¡ 对于4G/5G Modem，可以通过apn-profile命令设置APN、用户名和密码。

[Sysname] apn-profile test

[Sysname-apn-profile-test]apn static 3gnet

[Sysname-apn-profile-test]authentication-mode chap user card password simple card

(4) 请检查是否配置了当前运营商SIM卡不支持的band。band是用来配置模块工作的频段，各运营商SIM卡支持的band都不相同，一般缺省配置多个band来同时支持这些频段。如果该SIM卡支持的band不在这些缺省配置的band中或者配置限定到某些band，但是该SIM卡不支持，就会导致拨号失败。所以，如无必要，无需修改band配置，如果因为已配置了不支持的band而导致拨号失败，可以通过删除band配置来恢复。

(5) 如果Modem配置了IMSI绑定，但配置的IMSI号和实际使用的SIM卡IMSI不一致，会导致拨号失败。可以通过执行display cellular命令查看SIM卡的IMSI串号。

<sysname>display cellular 1/0

Cellular1/0:

Modem State:

Hardware Information:

Model: RM500QGL_VH

Manufacturer: QUALCOMM INCORPORATED

Modem Firmware Version: RM500QGLABR01A01M4G

International Mobile Equipment Identity (IMEI): 863305040121609

International Mobile Subscriber Identity (IMSI): 460028012255957

Hardware Version: 20000

Modem Status: Online

Modem Status: IPv4 Active.

...

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

¡ 上述步骤的执行结果。

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

3.5 告警与日志

4 基础配置类故障处理

4.1 登录设备类故障处理

4.1.1 Console口密码遗忘

1. 故障描述

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

2. 常见原因

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

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

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

3. 故障分析

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

图29 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菜单需要重启设备，会导致业务中断，请视具体情况做好备份，并尽量选择业务量较少的时间操作。

系统启动后，如果未及时选择进入基本段，则会直接运行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方案。相关配置的详细介绍请参见“安全配置指导”中的“AAA”。

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

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

4.1.2 Telnet登录密码遗忘

1. 故障描述

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

2. 常见原因

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

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

· Telnet登录账户已过期。

3. 故障分析

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

图30 Telnet登录密码遗忘故障诊断流程图

4. 处理步骤

(1) 确认是否有其它方式可以登录设备。

如果Telnet登录密码丢失，可以通过其他方式（例如Console口）登录设备后重新进行配置。

a. 使用其它方式登录设备，执行display line命令查看VTY口所在用户线的认证方式。

<Sysname> display line

Idx Type Tx/Rx Modem Auth Int Location

+ 0 CON 0 9600 - P - 0/0

81 VTY 0 - P - 0/0

...

以上显示信息中，“Auth”字段取值为P表示采用密码认证方式，取值为A表示采用AAA认证方式。

b. 根据VTY口的认证方式，采用不同的处理步骤重新设置新的登录密码。

- 采用密码认证

设置VTY登录用户的认证方式为密码认证，假设登录密码为1234567890!，用户角色为network-admin。

<Sysname> system-view

[Sysname] line vty 0 63

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

[Sysname-line-vty0-63] set authentication password simple 1234567890!

[Sysname-line-vty0-63] user-role network-admin

- 采用AAA本地认证

设置VTY登录用户的认证方式为AAA认证，假设登录使用的本地账户名为admin，使用的本地密码为1234567890!，用户角色为network-admin。

<Sysname> system-view

[Sysname] line vty 0 63

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

[Sysname-line-vty0-63] quit

[Sysname] local-user admin class manage

[Sysname-luser-manage-admin] service-type telnet

[Sysname-luser-manage-admin] password simple 1234567890!

[Sysname-luser-manage-admin] authorization-attribute user-role network-admin

如果忘记原有登录账户名，可参考以上步骤创建新的本地账户。

- 采用AAA远程认证

该认证方式下，请联系AAA服务器管理员获取登录密码。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

5 设备管理类故障处理

5.1 硬件资源管理故障处理

5.1.1 CPU占用率高

1. 故障描述

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

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

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

<Sysname> display cpu-usage summary

Slot CPU Last 5 sec Last 1 min Last 5 min

1 0 5% 5% 4%

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

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

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

· SNMP网管上出现CPU占用率高的相关告警。

2. 常见原因

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

· 网络攻击。

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

· 网络环路。

· 设备上配置了流采样功能，需要处理的流量太大或者设备采样频率太高，导致采样功能占用大量CPU资源。

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

3. 故障分析

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

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

4. 处理步骤

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

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

Probe视图下执行display system internal control-plane statistics命令，查看控制平面报文的统计信息，关注丢弃报文的数量。如果当前CPU占用率高，且Dropped字段取值较大，则设备大概率受到了报文攻击。

<Sysname> display system internal control-plane statistics slot 1

Control plane slot 1

Protocol: Default

Bandwidth: 15360 (pps)

Forwarded: 108926 (Packets), 29780155 (Bytes)

Dropped : 0 (Packets), 0 (Bytes)

Protocol: ARP

Bandwidth: 512 (pps)

Forwarded: 1489284 (Packets), 55318920 (Bytes)

Dropped : 122114 (Packets), 491421 (Bytes)

...

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

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

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

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

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

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

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

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

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

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

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

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

- 如果路由没有震荡，则执行步骤(3)。

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

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

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

<Sysname> reset counters interface

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

<Sysname> display counters rate inbound interface

Usage: Bandwidth utilization in percentage

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

GE5/3/0 0.01 7 -- --

MGE0/31/0 0.01 1 -- --

MGE0/32/0 0.01 5 -- --

VMC1/1/0 0.05 60 -- --

VMC1/2/0 0.04 52 -- --

Overflow: More than 14 digits.

--: Not supported.

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

<Sysname> display counters inbound interface

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

GE5/3/0 141 27 111 0

MGE0/31/0 274866 47696 0 --

MGE0/32/0 1063034 684808 2 --

VMC1/1/0 11157797 7274558 50 0

VMC1/2/0 9653898 5619640 52 0

Overflow: More than 14 digits (7 digits for column "Err").

--: Not supported.

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

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

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

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

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

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

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

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

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

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

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

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

(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 EMERG ALERT CRIT ERROR WARN NOTIF INFO DEBUG

1 0 0 2 9 24 12 128 0

5 0 0 0 41 72 8 2 0

97 0 0 42 11 14 7 40 0

<Sysname> display logbuffer reverse

Log buffer: Enabled

Max buffer size: 1024

Actual buffer size: 512

Dropped messages: 0

Overwritten messages: 0

Current messages: 410

%Jan 15 08:17:24:259 2021 Sysname SHELL/6/SHELL_CMD: -Line=vty0-IPAddr=192.168.2.108-User=**; Command is display logbuffer

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

...

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

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

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

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

如果设备未生成海量日志，则执行步骤(6)。

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

6 虚拟化技术类故障处理

6.1 IRF

6.1.1 IRF组建失败

1. 故障描述

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

2. 常见原因

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

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

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

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

3. 故障分析

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

图32 IRF组建失败故障诊断流程图

4. 处理步骤

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

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

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

(2) 检查各成员设备使用的软件版本是否一致。

使用display version命令查看每台设备当前运行的软件版本，只有使用相同软件版本的设备才能组成IRF。

IRF系统启动文件自动加载功能（缺省为开启状态）可以自动将成员设备的软件版本与IRF中主设备进行同步，但是在成员设备与主设备的软件版本差异过大时，自动升级可能无法成功执行。此时，需要分别升级每台成员设备，使得所有成员设备的软件版本一致，之后再组建IRF。

(3) 检查IRF的配置是否满足相关要求。

a. 确保设备运行在IRF模式。

部分产品出厂即为IRF模式，且不支持模式切换；部分产品出厂为独立运行模式，支持模式切换。如果设备当前支持display irf link或者display irf topology命令，则说明设备运行在IRF模式。否则，设备运行在独立运行模式，需要先在系统视图执行chassis convert mode irf命令将设备切换到IRF模式。

<Sysname> display irf ?

> Redirect it to a file

>> Redirect it to a file in append mode

configuration IRF configuration that will be valid after reboot

link Display link status

topology Topology information

| Matching output

<cr>

b. 确保设备的成员编号在IRF中唯一。

请使用display irf命令查看IRF中各成员设备的成员编号。IRF中各成员设备必须使用不同的编号，编号相同的设备不能建立或加入IRF。设备缺省成员编号为1，在独立运行模式下可通过irf member命令修改，在IRF模式下可通过irf member renumber命令修改。修改后需要保存配置并重启该设备，新编号才能生效。

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

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

d. 确保同一IRF系统中所有成员设备的IRF域编号一致。

IRF域编号不影响IRF的组建和合并，但是会影响MAD检测。为了使MAD功能正常工作，请确保同一IRF系统中所有成员设备的IRF域编号一致。IRF域编号缺省值为0。在单台设备上执行display irf命令，可通过显示信息中的Domain ID字段查看IRF域编号。如果设备的IRF域编号和其它设备不同，可在该设备上执行irf domain命令修改。

(4) 检查IRF端口的状态，使其变成UP状态。

IRF端口是一种专用于IRF连接的逻辑接口，需要与物理端口绑定后才能生效。请通过display irf topology命令显示信息的Link字段来确认IRF端口的状态。

<Sysname> display irf topology

Topology Info

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

IRF-Port1 IRF-Port2

MemberID Link neighbor Link neighbor Belong To

2 DIS --- UP 1 5e40-08d9-0104

1 UP 2 DIS --- 5e40-08d9-0104

¡ 如果Link字段取值为UP，则表示IRF端口连接正常，无需处理。

¡ 如果Link字段取值为DIS，则表示该IRF端口还没有和任何IRF物理端口绑定。请根据组网需要在IRF端口视图下使用port group interface命令进行绑定。

¡ 如果Link字段取值为DOWN，请使用display irf link命令进一步检查IRF物理端口的状态是否为UP。

- 如果IRF物理端口的状态为UP，但IRF端口的状态为DOWN，原因可能是IRF端口的配置未激活。请在系统视图下执行irf-port-configuration active命令激活IRF端口。

- 如果IRF物理端口的状态不是UP，请参照步骤(5)定位IRF物理端口的问题。

¡ 如果Link字段取值为TIMEOUT，表明IRF Hello报文超时，IRF链路通信存在问题。可参照以下步骤先定位IRF报文超时问题。

- 确认是否因为对端IRF端口状态异常，导致IRF报文无法互通：登录IRF链路的对端设备，在对端设备上执行display irf topology和display irf link，根据显示的状态信息进行定位。

- 确认是否存在网络环路，导致IRF报文丢包：使用display counters rate inbound interface命令查看IRF物理端口的报文速率统计信息，确认IRF链路上是否存在报文风暴。如果存在报文风暴，请检查是否存在物理环路以及VLAN和STP配置是否正确等，先解决报文风暴问题。

- 使用display device命令检查网板状态是否正常。如果不正常，请先定位网板问题。

¡ 如果Link字段取值为ISOLATE，表明该成员设备处于隔离状态。执行display logbuffer | include “STM stackability check”，并根据显示结果处理：

- 如果显示信息中包含“STM stackability check: Product series is inconsistency”字样，则说明成员设备的型号不符合IRF要求，请参考步骤(7)处理。

- 如果显示信息中包含“STM stackability check: Product xxx is inconsistency”字样，xxx取值可能为system working mode等，则说明当前系统参数配置不符合IRF要求，请参考步骤(8)处理。

(5) 检查IRF物理端口的状态，使其变成UP状态。

请通过display irf link命令查看IRF物理端口的状态。如果显示信息中：

¡ Interface字段取值为disable，表示该IRF端口还没有和IRF物理端口绑定。

¡ Interface字段为物理接口的名称，请继续检查Status字段。Status字段的取值及含义如下：

- UP：链路up，无需处理

- DOWN：链路down，请检查IRF物理端口的光模块/光纤或者电缆是否工作正常。请使用符合产品要求的物理接口作为IRF物理端口，使用符合产品要求的线缆来连接IRF物理端口，并执行步骤(6)。

- ADM：表示该接口通过shutdown命令被关闭，即管理状态为关闭。您需要执行undo shutdown命令将其开启。

- ABSENT：接口不存在。请插入单板或接口模块扩展卡。

(6) 检查IRF物理连线是否符合要求。

可通过以下步骤来定位IRF物理连接问题：

a. 在每台成员设备上通过display irf configuration命令查看IRF端口与IRF物理端口的绑定关系。检查绑定的物理接口和实际连接的物理接口是否一致，如果不一致，请重新配置绑定关系或重新进行物理连接。

b. 检查IRF物理端口的连接状况，是否满足相邻设备的连接要求。连接两台相邻的成员设备时，一台设备上IRF-Port1绑定的IRF物理端口只能和邻居成员设备IRF-Port2绑定的IRF物理端口相连。且当两台成员设备组建IRF时，只能使用链型拓扑，不允许使用环形拓扑。

(7) 检查成员设备的硬件是否符合IRF的要求。

当设备的品牌和款型均相同时，支持组建IRF。

设备工作在IRF模式时，不支持如下类型接口模块：

语音模块

WLAN模块

POS终端接入接口模块

数字调制解调器接口模块

模拟Modem模块

对于如下类型的接口模块，必须满足以下条件，才支持工作在IRF模式：

网络数据加密模块：主从设备必须同时安装。

以太网交换模块：主从设备的以太网交换模块支持的VLAN数量必须相同。

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

部分产品会要求设备的VXLAN硬件资源工作模式、路由硬件资源工作模式、以及等价路由条数等系统参数的配置相同，否则无法组建IRF。（不同产品的具体要求不同，请以设备的实际情况为准）

¡ 使用display hardware-resource命令可查看设备的硬件资源工作模式，使用hardware-resource vxlan、hardware-resource routing-mode命令可将设备的硬件资源工作模式修改为相同值。修改硬件资源工作模式后请重启该设备，使修改的工作模式生效。

¡ 使用display max-ecmp-num、display ipv6 max-ecmp-num命令可查看系统支持的最大等价路由条数，使用max-ecmp-num、ipv6 max-ecmp-num命令可将系统支持的最大等价路由条数修改为相同值。修改系统支持的最大等价路由条数后请重启该设备，使修改的配置生效。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

6.1.2 IRF成员设备异常重启

1. 故障描述

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

2. 常见原因

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

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

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

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

3. 故障分析

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

图33 IRF成员设备异常重启故障诊断流程图

4. 处理步骤

(1) 检查重启的设备是否为从设备。

¡ 如果是从设备，请执行步骤(2)。

¡ 如果不是从设备，是主设备，请执行步骤(4)。

(2) 检查从设备是否因为自动加载启动文件，升级导致的重启。

¡ 如果从设备是因为自动加载启动文件，升级导致的重启，则该重启为正常重启，无需处理。

¡ 如果从设备不是因为自动加载启动文件，升级导致的重启，请继续执行步骤(3)。

您可通过以下方式确认从设备的重启原因：IRF要求所有成员设备上运行的软件版本必须一致。当IRF开启了启动文件的自动加载功能，且有新设备加入IRF时，如果新设备的软件版本和主设备的软件版本不一致，则新设备会自动从主设备下载启动文件，然后使用新的启动文件重启并以从设备角色加入IRF。在Probe视图下，执行display system internal irf msg命令，如果显示信息中有“Version is different, and the sender CPU MAC is xxxx-xxxx-xxxx (chassis xx slot xx).”类似信息，表示CPU MAC为xxxx-xxxx-xxxx的从设备是因为自动加载启动文件，升级导致的重启。

(3) 检查是否因为IRF合并导致的从设备重启。

¡ 如果从设备重启原因为IRF合并，请追查IRF分裂、合并的原因，并排除安全隐患，以免再次因为同样的原因导致IRF分裂、合并。

¡ 如果从设备重启原因不是IRF合并，请继续执行步骤(4)。

您可通过以下方式确认从设备的重启原因是否为IRF合并：

¡ 设备重启后，在IRF中执行display kernel reboot命令查看设备的重启原因。如果Reason字段取值为0x7，则表示从设备重启原因为IRF合并，Slot表示触发重启事件的Slot的编号，Target Slot表示实际发生重启的Slot的编号。

<Sysname> display kernel reboot 1

--------------------- Reboot record 1 ---------------------

Recorded at : 2021-12-06 00:10:05.440616

Occurred at : 2021-12-06 00:10:05.440616

Reason : 0x7

Thread : STM_Main (TID: 232)

Context : thread context

Slot : 1

Target Slot : 2

Cpu : 0

VCPU ID : 2

Kernel module info : module name (system) module address (0xffffffffc0074000)

module name (addon) module address (0xffffffffc0008000)

¡ 在IRF的Probe视图下执行display system internal irf msg | include reboot命令，如果可以看到主设备发送了重启报文，则表示从设备重启原因为IRF合并。

19> Send reboot pkt, src_addr 5e40-08d9-0104 (chassis 1 slot 1), at 2022/1/5 15:42:48:386

(4) 检查是否有软件和硬件故障导致成员设备异常重启。

通过display version命令，可以查看成员设备/单板上次重启的原因，根据重启原因，以及表2所示的建议操作进行处理。

<Sysname> display version

…

Reboot Cause : ColdReboot

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

表2 设备重启原因以及建议操作

Reboot Cause字段的取值	重启原因说明	建议操作
AutoUpdateReboot	自动更新版本后重启	正常，无需处理
BootwareBackupReboot	Bootware备份区重启	请收集日志、诊断日志，联系技术支持人员处理
ColdReboot	设备掉电	检查设备的供电环境，确保供电正常
CryptographicModuleSelftestsFailedReboot	算法库自检失败	请及时升级软件版本
CryptotestFailReboot	加密算法库自检失败	请及时升级软件版本
DeadLoopReboot	软件检测到死循环	请收集日志、诊断日志和重启slot的display kernel deadloop 20 verbose的显示信息，联系技术支持人员处理
GoldMonReboot	GOLD（Generic OnLine Diagnostics，通用在线诊断）检测到异常	可通过以下操作确认重启原因： · display diagnostic content命令，通过Correct-action字段可看到GOLD检测到异常时的纠错动作是重启，测试发生的时间以及测试发现的问题 · display diagnostic event-log命令查看测试的详细执行信息根据以上显示信息找到具体的重启原因，并进行定位
IRFMergeReboot	IRF合并	IRF链路故障会导致IRF分裂，IRF链路恢复后，IRF会自动合并。请追查故障的IRF链路，并排除安全隐患，以免再次因为同样的原因导致IRF分裂、合并
KernelAbnormalReboot	CPU、主机内存或软件问题导致系统内核错误	请收集日志、诊断日志和诊断命令display kernel exception 10 verbose、display kernel reboot 20 verbose的信息，联系技术支持人员处理
KeyReboot	触碰了<RESET>键	避免误操作
LicenseTimeoutReboot	License过期	请及时安装正式版本的License
MemoryexhaustReboot	内存消耗，低于门限值	ACL表项太多等原因会导致内存占用率高，确认内存占用率高的原因，解决内存占用率高故障
PdtReboot	产品驱动要求的重启	请收集日志、诊断日志，联系技术支持人员处理
UserReboot	通过命令行、网管或Web页面等方式主动重启设备	正常，无需处理
WarmReboot	原因可能有多种，例如单板虚插针脚接触不良导致单板重启等	请收集日志、诊断日志，联系技术支持人员处理
WatchDogReboot	CPU、内存、软件或其它硬件故障，导致看门狗监测到系统异常，重启设备	根据display hardware-failure-detection命令显示的故障修复信息定位故障原因，消除安全隐患

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

¡ 假设slot 16为主用主控板，以备用主控板slot 17重启为例，请收集以下命令的显示信息。

- 请在任意视图下执行以下命令：

display version

display device

display diagnostic-information

display kernel deadloop 20 verbose slot 16

display kernel exception 10 verbose slot 16

display kernel reboot 20 verbose slot 16

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

5. 告警与日志

7 二层技术-以太网交换类故障处理

7.1 生成树故障处理

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

1. 故障描述

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

2. 常见原因

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

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

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

3. 故障分析

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

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

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

GE1/0/1 ADM auto A A 1

GE1/0/2 UP auto A A 1

GE1/0/3 DOWN auto A A 1

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

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

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

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

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

<Sysname> display interface gigabitethernet 1/0/2

GigabitEthernet1/0/2

Current state: UP

Line protocol state: DOWN(LAGG)

...

DOWN(protocols)表示接口的数据链路层被一个或者多个协议模块关闭。protocols为多个协议的任意组合，可能的协议如下：

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

- 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

----[Port54(GigabitEthernet1/0/2)][DOWN]----

Port protocol : Enabled

Port role : Disabled Port

Port ID : 128.54

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

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

Port edged : Config=disabled, Active=disabled

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

Transmit limit : 10 packets/hello-time

TC-Restriction : Disabled

Role-Restriction : Disabled

Protection type : Config=none, Active=none

MST BPDU format : Config=auto, Active=802.1s

Port Config-

Digest-Snooping : Disabled

Rapid transition : False

Num of VLANs mapped : 1

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

BPDU sent : 0

TCN: 0, Config: 0, RST: 0, MST: 0

BPDU received : 0

TCN: 0, Config: 0, RST: 0, MST: 0

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

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

[Sysname] display this

...

undo stp vlan 2 enable

stp mode pvst

stp global enable

...

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

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

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

<Sysname> display stp

...

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

Port protocol : Disabled

...

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

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

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

1. 故障描述

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

2. 常见原因

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

3. 故障分析

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

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

4. 处理步骤

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

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

<Sysname> display stp

...

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

Port protocol : Enabled

Port role : Designated Port

Port ID : 128.2

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

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

Port edged : Config=enabled, Active=enabled

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

Transmit limit : 10 packets/hello-time

Protection type : Config=none, Active=none

Rapid transition : True

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

...

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

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

在接口下不能同时配置边缘端口和环路保护功能，执行stp edged-port命令时，如果设备打印如下错误提示信息，说明当前接口已经配置了环路保护功能。此时需要先执行undo stp loop-protection命令关闭环路保护功能，才能将该端口配置为边缘端口。

Failed to enable edged-port on GigabitEthernet1/0/1, because loop-protection is enabled.

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

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

1. 故障描述

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

2. 常见原因

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

3. 故障分析

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

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

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

7.2 以太网链路聚合故障处理

7.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协议交互情况。

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

图37 聚合接口无法UP的故障诊断流程图

4. 处理步骤

(1) 排查物理连线是否准确。

根据聚合接口的组网规划进行线路检查，确认物理链接线路是否完全按照规划连接。

如果物理连线正确，则执行步骤(2)。

(2) 聚合接口是否被手工关闭。

执行display interface命令查看聚合接口的物理状态，如果显示为“Administratively DOWN”，则表示聚合接口被手工关闭，请执行undo shutdown命令开启聚合接口。如果聚合接口未被手工关闭，则执行步骤(3)。

(3) 聚合组中成员端口是否UP。

执行display interface命令查看聚合组中的成员端口是否处于UP状态，如果没有UP，请按照端口不UP故障流程处理。

如果端口处于UP状态，则执行步骤(4)。

以如下显示为例，三层聚合组1中成员端口GigabitEthernet1/0/1处于非选中状态。执行display interface命令查看GigabitEthernet1/0/1的物理状态时，物理状态显示为“DOWN”，使成员端口GigabitEthernet1/0/1处于非选中状态。

<Sysname> display link-aggregation verbose

Loadsharing Type: Shar -- Loadsharing, NonS -- Non-Loadsharing

Port Status: S -- Selected, U -- Unselected, I -- Individual

Port: A -- Auto port

Flags: A -- LACP_Activity, B -- LACP_Timeout, C -- Aggregation,

D -- Synchronization, E -- Collecting, F -- Distributing,

G -- Defaulted, H -- Expired

Aggregate Interface: Route-Aggregation1

Aggregation Mode: Static

Loadsharing Type: Shar

Management VLANs: None

Port Status Priority Oper-Key

GE1/0/1 U 32768 1

<Sysname> display interface gigabitethernet 1/0/1

GigabitEthernet1/0/1

Current state: Administratively DOWN

Line protocol state: DOWN

Description: GigabitEthernet1/0/1 Interface

Bandwidth: 1000000 kbps

Maximum transmission unit: 1500

Allow jumbo frames to pass

Broadcast max-ratio: 100%

Multicast max-ratio: 100%

Unicast max-ratio: 100%

Internet protocol processing: Disabled

IP packet frame type: Ethernet II, hardware address: 3822-d666-bd0c

IPv6 packet frame type: Ethernet II, hardware address: 3822-d666-bd0c

loopback: not set, promiscuous mode: not set

1000Mb/s, Full-duplex, link type: autonegotiation,

flow-control: disabled

Output queue - Urgent queuing: Size/Length/Discards 0/1024/0

Output queue - Protocol queuing: Size/Length/Discards 0/500/0

Output queue - FIFO queuing: Size/Length/Discards 0/75/0

Last link flapping: 5 days 3 hours 6 minutes

Last clearing of counters: 09:59:36 Wed 12/26/2021

Current system time:2018-12-26 10:33:19

Last time when physical state changed to up:2021-12-21 07:27:13

Last time when physical state changed to down:2021-12-21 07:27:10

Last 200 second input: 6 packets/sec 1728 bytes/sec 0%

Last 200 second output: 0 packets/sec 22 bytes/sec 0%

Input (total): 10694 packets, 2944465 bytes

951 unicasts, 3337 broadcasts, 6406 multicasts, 0 pauses

Input (normal): 10694 packets, 2944465 bytes

951 unicasts, 3337 broadcasts, 6406 multicasts, 0 pauses

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

0 CRC, 0 frame, 0 overruns, 0 aborts

0 ignored, 0 parity errors

Output (total): 1325 packets, 83462 bytes

1321 unicasts, 4 broadcasts, 0 multicasts, 0 pauses

Output (normal): 1325 packets, 83462 bytes

1321 unicasts, 4 broadcasts, 0 multicasts, 0 pauses

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

0 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 route-aggregation 1

Loadsharing Type: Shar -- Loadsharing, NonS -- Non-Loadsharing

Port Status: S -- Selected, U -- Unselected, I -- Individual

Port: A -- Auto port

Flags: A -- LACP_Activity, B -- LACP_Timeout, C -- Aggregation,

D -- Synchronization, E -- Collecting, F -- Distributing,

G -- Defaulted, H -- Expired

Aggregate Interface: Route-Aggregation1

Creation Mode: Manual

Aggregation Mode: Dynamic

Loadsharing Type: Shar

System ID: 0x8000, 000f-e267-6c6a

Local:

Port Status Priority Index Oper-Key Flag

GE1/0/1 S 32768 61 2 {ACDEF}

GE1/0/2 S 32768 62 2 {ACDEF}

GE1/0/3 S 32768 63 2 {ACDEF}

Remote:

Actor Priority Index Oper-Key SystemID Flag

GE1/0/1 32768 111 2 0x8000, 000f-e267-57ad {ACDEF}

GE1/0/2 32768 112 2 0x8000, 000f-e267-57ad {ACDEF}

GE1/0/3 32768 113 2 0x8000, 000f-e267-57ad {ACDEF}

如果配置不正确，则修改对端聚合接口为动态聚合；如果配置正确，则执行debugging link-aggregation lacp packet命令确认LACP报文收发是否正确。

执行debugging link-aggregation lacp packet命令后，查看成员端口send信息中Actor信息和receive信息中Partner信息。如果sys-mac、key和port-index字段的显示不一致，则LACP协议报文收发不正常，请排除收发光纤错接问题；如果sys-mac、key和port-index字段的显示一致，则LACP协议报文收发正常，请执行步骤(5)。

打开聚合组成员端口GigabitEthernet1/0/1的LACP报文调试信息开关，查看该端口收发LACP协议报文的情况。

<Sysname> debugging link-aggregation lacp packet all interface gigabitethernet 1/0/1

*Nov 2 15:51:21:15 2007 Sysname LAGG/7/Packet: PACKET.GigabitEthernet1/0/1.send.

size=110, subtype =1, version=1

Actor: type=1, len=20, sys-pri=0x8000, sys-mac=00e0-fc02-0300, key=0x1, pri=0x8000, port-index=0x2, state=0xc5

Partner: type=2, len=20, sys-pri=0x0, sys-mac=0000-0000-0000, key=0x0, pri=0x0, port-index=0x0, state=0x32

Collector: type=3, len=16, col-max-delay=0x0

Terminator: type=0, len=0

*Nov 2 15:55:21:15 2007 Sysname LAGG/7/Packet: PACKET.GigabitEthernet1/0/1.receive.

size=110, subtype =1, version=1

Actor: type=1, len=20, sys-pri=0x8000, sys-mac=00e0-fc00-0000, key=0x1, pri=0x8000, port-index=0x6, state=0xd

Partner: type=2, len=20, sys-pri=0x8000, sys-mac=00e0-fc02-0300, key=0x1, pri=0x8000, port-index=0x2, state=0xc5

Collector: type=3, len=16, col-max-delay=0x0

Terminator: type=0, len=0

¡ 如果聚合接口为静态聚合，则执行步骤(5)。

(5) 查看聚合接口下最小选中端口的配置是否影响成员端口选中。

在聚合接口视图下执行display this命令，如果存在link-aggregation selected-port minimum的配置，请修改最小选中端口数值，使其满足最小选中要求。当聚合组内能够被选中的成员端口数增加至不小于配置值时，这些成员端口都将变为选中状态，对应聚合接口的链路状态也将变为UP。

如果聚合接口下最小选中端口的配置未影响成员端口选中，则执行步骤(6)。

以如下显示为例，三层聚合接口1下配置的最小选中端口数为2，而三层聚合接口1对应的聚合组的成员端口仅有一个，所以该成员端口处于非选中状态。

[Sysname-Route-Aggregation1] display this

interface Route-Aggregation1

link-aggregation selected-port minimum 2

return

[Sysname-Route-Aggregation1] display link-aggregation verbose

Loadsharing Type: Shar -- Loadsharing, NonS -- Non-Loadsharing

Port Status: S -- Selected, U -- Unselected, I -- Individual

Port: A -- Auto port

Flags: A -- LACP_Activity, B -- LACP_Timeout, C -- Aggregation,

D -- Synchronization, E -- Collecting, F -- Distributing,

G -- Defaulted, H -- Expired

Aggregate Interface: Route-Aggregation1

Aggregation Mode: Static

Loadsharing Type: Shar

Management VLANs: None

Port Status Priority Oper-Key

GE1/0/1 U 32768 1

(6) 聚合组内是否存在选中的成员端口。

如果聚合组内不存在选中的成员端口，则请参见“7.2.3 聚合成员端口无法选中”故障进行定位；如果聚合组内存在选中的成员端口，则执行步骤(7)。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

7.2.2 聚合接口流量负载分担不均

1. 故障描述

当两台设备通过链路聚合连接时，通过display counters rate命令查看聚合成员端口出方向流量速率，某些成员端口速率特别小或者根本没有。

2. 常见原因

本类故障的常见原因主要为聚合负载分担方式配置错误。

3. 故障分析

本类故障的诊断思路为确认聚合接口转发的报文的特征，并查看聚合负载分担类型是否和报文特性匹配。

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

图38 聚合接口流量负载分担不均的故障诊断流程图

4. 处理步骤

(1) 用户业务流量是否正常。

如果用户业务流量正常，则等待一段时间，再执行display counters rate命令查看聚合成员端口出方向流量速率，确认聚合成员端口流量是否恢复负载分担：

¡ 如果已恢复负载分担，则无需处理。

¡ 如果未恢复负载分担，则执行步骤(2)。

如果用户业务流量不正常，则执行步骤(2)。

(2) 查看聚合负载分担类型与报文特征是否匹配。

通过执行display link-aggregation load-sharing mode命令查看聚合负载分担类型，如果与报文特征不匹配，则通过以下命令调整聚合负载分担类型：

¡ 在系统视图下执行link-aggregation global load-sharing mode命令调整全局的负载分担类型。

¡ 在聚合接口视图下执行link-aggregation load-sharing mode命令调整聚合接口的负载分担类型。

针对不同业务流量，不同产品调整的负载分担类型不同，请参见命令参考手册。

如果聚合负载分担类型与报文特征匹配，则执行步骤(3)。

(3) 检查是否部署跨板/跨框聚合。

在IRF环境下，如果部署跨板/跨框聚合，则在系统视图下使用undo link-aggregation load-sharing mode local-first命令关闭本地优先转发功能。如果关闭本地优先转发功能，则可能导致跨板/跨框流量过大，影响IRF系统稳定，请根据实际情况进行操作。

如果未部署跨板/跨框聚合，则执行步骤(4)。

需要注意，跨板/跨框流量不能过大，否则可能影响IRF系统稳定。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

7.2.3 聚合成员端口无法选中

1. 故障描述

当两台设备通过链路聚合连接时，发现聚合组成员端口处于非选中状态，聚合失败。

2. 常见原因

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

· 链路连通性故障。

· 本端和对端的操作key、属性类配置不一致。

· 聚合成员端口数配置错误。

3. 故障分析

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

(1) 查看成员端口是否UP，排除端口物理故障影响。

(2) 使用debugging link-aggregation lacp packet命令查看动态聚合的成员端口LACP协议交互情况。

(3) 检查本端和对端聚合接口配置，排除配置影响。

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

图39 聚合成员端口无法选中的故障诊断流程图

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

Flags: A -- LACP_Activity, B -- LACP_Timeout, C -- Aggregation,

D -- Synchronization, E -- Collecting, F -- Distributing,

G -- Defaulted, H -- Expired

Aggregate Interface: Bridge-Aggregation1

Creation Mode: Manual

Aggregation Mode: Dynamic

Loadsharing Type: Shar

Management VLANs: None

System ID: 0x8000, 2a41-21c1-0100

Local:

Port Status Priority Index Oper-Key Flag

GE1/0/1 S 32768 1 1 {ACDEF}

GE1/0/2 S 32768 2 1 {ACDEF}

GE1/0/3 U 32768 3 2 {AC}

Remote:

Actor Priority Index Oper-Key SystemID Flag

GE1/0/1 32768 1 1 0x8000, 36f6-c0aa-0200 {ACDEF}

GE1/0/2 32768 2 1 0x8000, 36f6-c0aa-0200 {ACDEF}

GE1/0/3 32768 3 1 0x8000, 36f6-c0aa-0200 {AC}

b. 执行display current-configuration interface命令查看本端处于Unselected状态的成员端口的属性类配置（VLAN等配置）与聚合接口是否相同，如果不同，则将其配置相同。

以如下显示为例，处于Unselected状态的成员端口GigabitEthernet1/0/3与参考端口GigabitEthernet1/0/1的属性类配置不同，导致该成员端口无法选中，需要修改成员端口GigabitEthernet1/0/3的属性类配置。

<Sysname> display current-configuration interface gigabitethernet 1/0/1

interface GigabitEthernet1/0/1

port link-mode bridge

port link-type trunk

port trunk permit vlan 1 to 20

port link-aggregation group 1

return

<Sysname> display current-configuration interface 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

Flags: A -- LACP_Activity, B -- LACP_Timeout, C -- Aggregation,

D -- Synchronization, E -- Collecting, F -- Distributing,

G -- Defaulted, H -- Expired

Aggregate Interface: Route-Aggregation1

Creation Mode: Manual

Aggregation Mode: Dynamic

Loadsharing Type: Shar

System ID: 0x8000, 000f-e267-6c6a

Local:

Port Status Priority Index Oper-Key Flag

GE1/0/1 S 32768 1 1 {ACDEF}

GE1/0/2 S 32768 2 1 {ACDEF}

GE1/0/3 U 32768 3 2 {AC}

Remote:

Actor Priority Index Oper-Key SystemID Flag

GE1/0/1 32768 1 1 0x8000, 36f6-c0aa-0200 {ACDEF}

GE1/0/2 32768 2 1 0x8000, 36f6-c0aa-0200 {ACDEF}

GE1/0/3 32768 3 1 0x8000, 36f6-c0aa-0200 {AC}

b. 执行display current-configuration interface命令查看本端处于Unselected状态的成员端口的操作key（包括该端口的速率、双工模式等）与参考端口是否相同，如果不同，则将其配置相同。

以如下显示为例，处于Unselected状态的成员端口GigabitEthernet1/0/3与参考端口GigabitEthernet1/0/1的操作key不同，导致该成员端口无法选中，需要修改该端口速率配置。

<Sysname> display current-configuration interface gigabitethernet 1/0/1

interface GigabitEthernet1/0/1

port link-mode route

port link-aggregation group 11

return

<Sysname> display current-configuration interface gigabitethernet 1/0/3

interface GigabitEthernet1/0/3

port link-mode route

speed 100

port link-aggregation group 11

return

如果本端成员端口的操作key与参考端口相同，则执行步骤(5)。

(5) 本端聚合接口是否为动态聚合。

如果是动态聚合，则执行步骤(6)；如果是静态聚合，否则进行步骤(8)。

(6) LACP报文收发是否正确。

执行debugging link-aggregation lacp packet命令确认LACP报文收发是否正确。执行命该令后，查看成员端口send信息中Actor信息和receive信息中Partner信息。如果sys-mac、key和port-index字段的显示不一致，则LACP协议报文收发不正常，请排除收发光纤错接问题；如果sys-mac、key和port-index字段的显示一致，则LACP协议报文收发正常，请执行步骤(7)。

打开聚合组成员端口GigabitEthernet1/0/1的LACP报文调试信息开关，查看该端口收发LACP协议报文的情况。

<Sysname> debugging link-aggregation lacp packet all interface gigabitethernet 1/0/1

*Nov 2 15:51:21:15 2021 Sysname LAGG/7/Packet: PACKET.GigabitEthernet1/0/1.send.

size=110, subtype =1, version=1

Actor: type=1, len=20, sys-pri=0x8000, sys-mac=00e0-fc02-0300, key=0x1, pri=0x8000, port-index=0x2, state=0xc5

Partner: type=2, len=20, sys-pri=0x0, sys-mac=0000-0000-0000, key=0x0, pri=0x0, port-index=0x0, state=0x32

Collector: type=3, len=16, col-max-delay=0x0

Terminator: type=0, len=0

*Nov 2 15:55:21:15 2021 Sysname LAGG/7/Packet: PACKET.GigabitEthernet1/0/1.receive.

size=110, subtype =1, version=1

Actor: type=1, len=20, sys-pri=0x8000, sys-mac=00e0-fc00-0000, key=0x1, pri=0x8000, port-index=0x6, state=0xd

Partner: type=2, len=20, sys-pri=0x8000, sys-mac=00e0-fc02-0300, key=0x1, pri=0x8000, port-index=0x2, state=0xc5

Collector: type=3, len=16, col-max-delay=0x0

Terminator: type=0, len=0

(7) 本端成员端口的对端端口的操作key和属性类配置与参考端口的对端端口是否相同。

在本端Unselected端口的对端设备上执行display current-configuration interface命令查看对端Unselected端口的属操作key和属性类配置与参考端口的对端端口是否相同，如果不同，则将其配置相同。

如果本端成员端口的对端端口的操作key和属性类配置与参考端口的对端端口相同，则执行步骤(8)。

(8) 聚合成员端口数量是否达到阈值。

¡ 聚合成员端口数超过上限。

可在聚合接口视图下通过link-aggregation selected-port maximum命令配置聚合组中的最大选中端口数。通过display link-aggregation verbose命令查看聚合组中成员端口数是否超过上限，如果超过上限，则多出来的端口为Unselected状态，Selected端口按照端口编号从小到大排序。请在成员端口视图下使用undo port link-aggregation group命令将Selected端口中不适用的端口从聚合组中删除，以使必须使用的端口能够选中。

¡ 聚合成员端口数低于下限。

可在聚合接口视图下执行link-aggregation selected-port minimum命令配置聚合组中的最小选中端口数。通过display link-aggregation verbose命令查看聚合组中成员端口是否低于下限，如果低于下限，则所有成员端口为Unselected状态。请执行link-aggregation selected-port minimum命令修改最小选中端口数值或者为聚合组添加成员端口，使其满足最小选中要求。

如果聚合成员端口数量未达到聚合组的阈值，则执行步骤(9)。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

8 二层技术-广域网接入类故障处理

8.1 PPP故障处理

8.1.1 PPP接口协议DOWN

1. 故障描述

当两台设备的PPP物理接口连接完成后，接口的链路层协议状态显示为DOWN。

2. 常见原因

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

· 接口的物理层状态没有UP。

· 链路两端接口上的PPP相关配置错误。

· PPP协议报文被丢弃。

· 链路存在环路。

· 链路时延过大。

3. 故障分析

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

图40 PPP接口协议DOWN的故障诊断流程图

4. 处理步骤

(1) 检查接口物理状态是否UP。

在任意视图下执行display interface interface-type interface-number命令查看本端接口物理状态：

¡ 如果本端接口物理状态为Administratively DOWN，表示本端接口被shutdown命令关闭，请在本端接口视图下执行undo shutdown命令取消关闭。

¡ 如果本端接口物理状态为DOWN，请检查对端接口是否被shutdown命令关闭，如是，请在对端接口视图下执行undo shutdown命令取消关闭。

¡ 请检查两端光纤/光模块是否插好、光纤收/发是否插正确等，并解决接口物理状态DOWN问题。

¡ 如果接口状态为UP，请继续执行下一步。

(2) 检查链路两端的PPP配置是否正确。

在PPP协议DOWN的接口所在视图下执行display this命令查看当前接口的PPP相关配置。

[Sysname-Serial2/1/0] display this

interface Serial2/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 2

PPP packet statistics in slot 2:

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

-----------------------------------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=2;

PPP Packet:

Ser2/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=2;

PPP Packet:

Ser2/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=2;

PPP Packet:

Ser2/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=2;

PPP Packet:

Ser2/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.2 PPPoE故障处理

8.2.1 PPPoE拨号偶尔出现认证失败

1. 故障描述

标准的PPPoE的组网，MSR设备作为PPPoE Server，cams作为认证服务器。

使用过程中客户端认证失败。

携带了错误的用户名(系统中没有分配这样的用户名)：

· Host Len: 42 Name:a:2yZsyoBNb16F355VlFaYDJ6ZyNqx8cb::b052204

· Host Len: 9 Name:^^b052204

2. 故障处理步骤

(1) 排除MSR设备的处理问题

通过命令行debugging ppp all和debugging radius packet，查看调试信息：

*Oct 22 14:00:07:012 2014 3640 PPP/7/PAP_PACKET_0:

PPP Packet:

Virtual-Access0 Input PAP(c023) Packet, PktLen 32

State ServerListen, code Request(01), id 9, Len 28

0W'ZK5A9fd00001 16 Name:

Pwd Len: * Pwd :******

*Oct 22 14:00:07:012 2014 3640 PPP/7/PAP_EVENT_0:

PPP Event:

Virtual-Access0 PAP Receive Request Event

State ServerListen

*Oct 22 14:00:07:013 2014 3640 PPP/7/PAP_STATE_0:

PPP State Change:

Virtual-Access0 PAP: ServerListen --> WaitAAA

*Oct 22 14:00:07:013 2014 3640 RADIUS/7/PACKET:

User-Name="\r0W'ZK5A9fd00001"

User-Password=******

Service-Type=Framed-User

NAS-Identifier="3640"

NAS-Port=4096

NAS-Port-Type=Ethernet

Calling-Station-Id="8c21-0a7e-71c5"

Acct-Session-Id="00000005201410221400070000001e001 225"

NAS-Port-Id="slot=65535;subslot=0;port=0;vlanid=0"

H3c-Ip-Host-Addr="255.255.255.255 8c:21:0a:7e:71:c5"

NAS-IP-Address=60.191.123.92

H3c-Product-Id="H3C MSR36-40"

H3c-Nas-Startup-Timestamp=1413972953

….

*Oct 22 13:59:46:225 2014 3640 PPP/7/PAP_EVENT_0:

PPP Event:

Virtual-Access0 PAP Receive AAA Result Event

State WaitAAA

*Oct 22 13:59:46:225 2014 3640 PPP/7/AUTH_ERROR_0:

PPP Error:

Virtual-Access0 PAP: Receive AAA reject message, authentication failed!

如debug信息可以看出PPP收到的用户名已经是错误的，则排除MSR设备问题。

(2) 排查家用小型路由器拨号方式

家用小型路由器的拨号模式一般使用自动拨号模式，首先会以正常拨号模式进行拨号，在拨号失败后，会使用各种特殊拨号模式尝试拨号，而一般的认证服务器不支持特殊模式拨号，所以出现大量认证失败信息。因此，当出现类似的问题后，需要排查家用小型路由器首次拨号失败的原因。

家用小路由器使用特殊拨号模式会导致异常用户名，可不予关注。

3. 故障诊断命令

命令	说明
display pppoe-server session summary	显示PPPoE会话信息
debugging ppp lcp all	PPP LCP阶段调试信息开关
debugging ppp pap all	PPP PAP阶段调试信息开关
debugging ppp ipcp all	PPP IPCP阶段调试信息开关
debugging radius packet	Radius数据包调试信息开关

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

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

图41 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会话的配置。

表3 影响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 ] } ignore	存在该配置时，BGP将不会与指定的对等体/对等体组建立BGP会话，此时可以通过执行undo peer ignore命令允许建立与对等体/对等体组的会话
地址族下的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. 故障分析

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

图42 BGP会话Down的故障诊断流程图

4. 处理步骤

执行display bgp peer log-info命令，根据该命令的显示信息进一步确认BGP会话Down的原因。几种常见的BGP会话Down的原因如下：

· BGP定时器超时导致断开会话

如果log-info信息与下面的显示信息相似：

<Sysname> display bgp peer ipv4 3.3.3.3 log-info

Peer: 3.3.3.3

Date Time State Notification

Error/SubError

17-Jan-2022 14:48:34 Down Receive notification with error 4/0

Hold Timer Expired/ErrSubCode Unspecified

Keepalive last triggered time: 14:48:31-2022.1.17

Keepalive last sent time : 14:48:31-2022.1.17

Update last sent time : 14:48:24-2022.1.17

EPOLLOUT last occurred time : 14:48:30-2022.1.17

则表示BGP会话Down的原因是在会话保持时间内未能收到对等体发送的Keepalive或Update消息。在BGP会话保持定时器超时后，设备则会主动断开BGP会话，并向对端对等体发送Notification消息。

定时器超时的原因可能是设备正常发送了Keepalive或Update消息，但报文由于链路故障等原因无法到达对等体或对等体处理不及时，或者设备调度故障导致未能及时产生Keepalive或Update消息等。如需解决此问题，请在BGP会话的两端设备的Probe视图下，均执行display system internal bgp log命令，并收集该命令的显示信息，联系技术支持人员进行进一步分析。

· TCP连接错误导致BGP会话断开

如果log-info信息与下面的显示信息相似：

<Sysname> display bgp peer ipv4 1.1.1.1 log-info

Peer: 1.1.1.1

Date Time State Notification

Error/SubError

17-Jan-2022 14:42:01 Down Receive TCP_Connection_Failed event

则BGP会话Down的原因是TCP连接错误。BGP使用TCP作为其传输层协议，如果BGP会话两端设备间的TCP连接发生错误，BGP会话也会断开。如果用户观察到的显示信息与上述举例不相似，但是显示信息中包含了Notification消息错误码5/0，则也是由于TCP连接错误导致的BGP会话断开。

确认TCP连接发生错误后，请在BGP会话Down的两端设备的Probe视图中，均执行view /proc/tcp/tcp_log slot x命令（所有的单板/成员设备各执行一次），并收集该命令的显示信息，联系技术支持人员进行进一步分析。

· 内存不足导致BGP会话断开

如果log-info信息与下面的显示信息相似：

<Sysname> display bgp peer ipv4 1.1.1.1 log-info

Peer: 1.1.1.1

Date Time State Notification

Error/SubError

17-Jan-2022 15:38:53 Down Send notification with error 6/8

Entered severe memory state

17-Jan-2022 14:53:51 Down Send notification with error 6/8

No memory to process the attribute

表明设备没有足够内存处理BGP模块相关功能，导致BGP会话断开。此类错误原因对应log-info信息中的错误码6/8。

此时请在BGP会话Down的两端设备上，均执行display memory-threshold命令，获取内存告警门限相关信息，并记录display bgp peer log-info命令的显示信息，联系技术支持人员进行进一步分析。

· 报文解析错误导致BGP会话断开：

BGP会话两端的设备如果报文解析能力不同或版本不匹配，则BGP可能无法解析接收到的报文，导致BGP会话断开。此类错误原因对应log-info信息中的消息差错码1、2和3（即“Error/SubError”中的“Error”为1、2或3）。

请在BGP会话Down的两端设备上，均执行debugging bgp raw-packet、debugging bgp open以及debugging bgp update命令，并收集这些命令的显示信息以及display bgp peer log-info命令的显示信息，联系技术支持人员进行进一步分析。

· 如果display bgp peer log-info命令的显示信息中，提示的BGP会话Down的原因不属于以上任何一种常见的原因，请收集如下信息，并联系技术支持人员。

¡ display bgp peer log-info命令的显示信息。

¡ display system internal bgp log命令的显示信息。

¡ view /proc/tcp/tcp_log slot x命令的显示信息（所有的单板/成员设备各执行一次）。

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

作为参考，BGP会话断开的详细原因及其对应的错误码如表4所示。

表4 邻居断开的详细原因列表

差错码/差错子码	会话断开的详细原因	说明
1/1	connection not synchronized	连接不同步，目前实现为收到的报文的报文头前16字节不全为F
1/2	bad message length	报文长度无效
1/3	bad message type	报文的类型无效
3/1	the withdrawn length is too large	撤销信息长度过长
	the attribute length is too large	属性长度过长
	one attribute appears more than once	同一个属性在一个Update消息中出现了多次
	the attribute length is too small	属性长度字段不足2字节
	exntended length field is less than two octets	属性长度为可扩展长度，但长度字段不足2字节
	the length field is less than one octet	属性长度为正常长度，但长度字段不足1字节
	link-state attribute error	链路状态属性形式错误
3/2	unrecognized well-known attribute	不支持的公认属性
3/3	attribute-type attribute missed	attribute-type类型的属性丢失，attribute-type取值包括： · ORIGIN · AS_PATH · LOCAL_PREF · NEXT_HOP
3/4	attribute flags error	属性标记错误
3/5	attribute-type attribute length error	attribute-type类型的属性长度错误，attribute-type取值包括： · AS_PATH · AS4_PATH · CLUSTER_LIST · AGGREGATOR · AS4_AGGREGATOR · ORIGIN · NEXT_HOP · MED · LOCAL_PREF · ATOMIC_AGGREGATE · ORIGINATOR_ID · MP_REACH_NLRI · COMMUNITIES · extended communities
3/5	attribute length exceeds	属性长度越界
3/6	invalid ORIGIN attribute	ORIGIN属性无效
3/8	invalid NEXT_HOP attribute	下一跳属性无效
3/9	invalid nexthop length in MP_REACH_NLRI (address-family)	address-family地址族MP_REACH_NLRI属性的Nexthop长度错误，address-family的取值包括： · 4u：表示IPv4单播地址族 · IPv4 Flowspec：表示IPv4 Flowspec地址族 · MPLS：表示MPLS地址族 · VPNv4：表示VPNv4地址族 · 6u：表示IPv6单播地址族 · VPNv6：表示VPNv6地址族 · L2VPN：表示L2VPN地址族
	the length of MP_UNREACH_NLRI is too small	MP_UNREACH_NLRI的长度小于3字节
	the MP NLRI attribute length exceeds	MP_REACH_NLRI 或MP_UNREACH_NLRI属性长度越界
	erroneous MP NLRI attribute end position	可达或不可达前缀结束位置与报文属性结束位置不同
3/10	invalid network field	网络字段无效
3/11	malformed AS_PATH	AS路径形式不对
4/0	Keepalive last triggered time	最后一次触发发送Keepalive消息时间
	Keepalive last sent time	最后一次发送Keepalive消息时间
	Update last sent time	最后一次发送Update消息时间
	EPOLLOUT last occurred time	最后一次发生EPOLLOUT时间
	Keepalive last received time	最后一次接收Keepalive消息时间
	Update last received time	最后一次接收Update消息时间
	EPOLLIN last occurred time	最后一次发生EPOLLIN时间
5/0	connection retry timer expires	ConnectRetry定时器超时
	TCP_CR_Acked event received	收到了TCP_CR_Acked事件
	TCP_Connection_Confirmed event received	收到了TCP_Connection_Confirmed事件
5/3	open message received	收到open消息
6/0	manualstop event received	收到manualstop事件
	physical interface configuration changed	物理配置改变，比如接口变化
	session down event received from BFD	收到BFD会话down事件
6/1	maximum number of prefixes reached	前缀数超过peer route-limit所配置的数目
6/1	maximum number of address-family prefixes reached	address-family地址族的前缀数超过peer route-limit所配置的数目，address-family的取值包括： · IPv4 unicast：表示IPv4单播地址族 · IPv6 unicast：表示IPv6单播地址族 · VPNv4：表示VPNv4地址族 · VPNv6：表示VPNv6地址族
6/2	configuration of peer ignore changed	配置peer ignore命令
6/3	address family deleted	地址族被删除
6/3	peer disabled	关闭对等体
6/4	administrative reset	执行reset bgp命令或者配置改变导致BGP会话重启
6/5	connection rejected	连接被拒绝
6/6	other configuration change	其他配置变化
6/7	connection collision resolution	连接冲突
6/7	two connections exist and MD5 authentication is configured for the neighbor	存在两个连接，且其中一个配置了MD5认证
6/8	· no memory to process the attribute：解析属性时内存不够 · no memory for the route：生成路由或者标签块信息时，获取不到内存 · no memory to generate unreachable NLRI：封装unreachable NLRI时申请不到内存 · no memory to generate a message：封装报文时申请不到内存 · can’t get the VPN RD：解析前缀时获取不到RD · can’t get the VPN routing table：解析前缀时获取不到VPN路由表 · can’t get the attributes：解析前缀时获取不到属性 · entered severe memory state：进入二级门限告警 · entered critical memory state：进入三级门限告警

5. 告警与日志

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

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

图43 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) 检查链路两端的设备配置的System ID是否相同。

请执行display current-configuration isis命令检查链路两端的设备配置的System ID是否相同。

¡ 如果两端System ID相同，请修改配置，使两端的System ID不同。

¡ 如果两端System ID不相同，请执行步骤(8)。

(8) 检查链路两端的设备的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匹配，请执行步骤(9)。

(9) 检查链路两端设备的区域地址是否匹配。

请执行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命令修改设备的区域地址。

¡ 如果链路两端区域地址匹配，请执行步骤(10)。

(10) 检查链路两端设备的认证方式是否匹配。

请执行display current-configuration interface-type interface-number | include isis命令检查链路两端设备IS-IS接口的认证方式。

a. 如果两端认证类型不匹配，请在链路两端设备的IS-IS接口视图下执行isis authentication-mode命令，将两端设置为相同的认证类型。

b. 如果认证方式相同的情况下，IS-IS仍然无法建立邻居关系，请将两端设置为相同的认证密码。

如果故障依然存在，请执行步骤(11)。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

9.2.2 设备学习不到IS-IS路由

1. 故障描述

设备学习不到IS-IS路由。

2. 常见原因

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

· 其它路由协议也发布了相同的路由，并且路由协议优先级比IS-IS协议高。

· 引入的外部路由优先级低，没有被优选。

· IS-IS开销值类型不匹配。

· IS-IS邻居没有正常建立。

· 两台设备的System ID配置相同。

· LSP报文认证不匹配。

· 设备底层故障或者链路故障，造成LSP报文丢失。

· LSP长度超过了设备可以接收的LSP的最大长度。

3. 故障分析

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

图44 设备学习不到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高的路由。

- 如果存在，请根据网络规划调整配置。

- 如果不存在，请执行步骤(6)。

¡ 如果IS-IS路由表中不存在指定的路由，请执行步骤(2)。

(2) 检查指定的IS-IS路由是否发布。

在发布指定路由的设备上，执行display isis lsdb verbose local命令，查看本地产生的LSP报文中是否携带了指定路由。

¡ 如果LSP报文中没有携带指定的路由，请检查IS-IS配置是否正确，例如接口是否使能IS-IS。如果指定的路由是IS-IS引入的外部路由，请执行display ip routing-table protocol protocol verbose命令查看该路由的“State”字段，当“State”字段的取值中包含“Inactive”时，说明外部路由处于非激活状态，这种情况下，IS-IS不会将此路由发布出去。请检查外部路由的配置，使该路由的“State”取值包含“Active”和“Adv”。

¡ 如果LSP报文中携带了指定的路由，请执行步骤(6)。

(3) 检查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一致，请执行步骤(6)。

(4) 检查IS-IS开销值类型是否匹配。

分别在发布路由的设备和学习不到路由的设备上，执行display isis命令，查看“Cost style”的取值，检查两端的IS-IS开销值类型是否匹配。只有开销值类型相同时，才能学到路由。

¡ 如果链路两端设备的IS-IS开销值类型不匹配，请在IS-IS视图下执行cost-style命令修改配置。

¡ 如果两端设备的IS-IS开销值类型匹配，请执行步骤(6)。

(5) 检查IS-IS邻居是否正常建立。

在路径上的每一台设备上执行display isis peer命令，查看IS-IS邻居是否都正常建立。

¡ 如果存在邻居没有正常建立的情况，请参见“9.2.1 IS-IS邻居无法建立”。

¡ 如果不存在邻居未能正常建立的情况，请执行步骤(6)。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

9.2.3 IS-IS路由震荡

1. 故障描述

IS-IS路由反复增删。

2. 常见原因

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

· IS-IS邻居震荡。

· MPLS LSP隧道震荡。

· 两台设备的IS-IS引入了相同的外部路由，并且外部路由的优先级比IS-IS协议的优先级低。

· 两台设备配置的System ID相同。

3. 故障分析

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

图45 IS-IS路由震荡的故障诊断流程图

4. 处理步骤

(1) 检查路由震荡的情况。

执行display ip routing-table ip-address verbose命令，查看路由震荡的具体情况，具体步骤如下：

¡ 如果路由震荡的前后，“TunnelID”字段发生了变化，请检查MPLS LSP隧道是否存在震荡。

执行display mpls lsp verbose命令，通过“Last Chg Time”字段查看LDP的LSP最近一次状态变化的时间。如果最近一次变化的时间距离执行display mpls lsp verbose命令的时间较近，说明MPLS LSP隧道存在震）。

对于这种情况，请参考LDP LSP震荡的定位思路或TE Tunnel由Up突然变Down的定位思路，排查LSP震荡问题。

¡ 如果路由的“Cost”或者“Interface”字段发生变化，请检查该路由路径上的IS-IS邻居是否在震荡。

¡ 如果路由在路由表中时有时无（Age字段在震荡），执行display isis lsdb verbose命令，找到携带该路由的LSP，并记录此LSP报文的LSPID。然后，执行display isis lsdb verbose lsp-id命令查看这条LSP的更新情况。

- 如果LSP中一直携带指定的路由，请检查该路由路径上是否存在IS-IS邻居震荡。

- 如果LSP的“Seq Num”字段的取值在不停的增加，并且LSP更新前后的内容差异很大，请检查网络中是否有两台设备配置了相同的System ID。

- 如果LSP的“Seq Num”字段的取值在不停的增加，并且LSP更新前后，指定的路由时有时无，请在产生该LSP的设备上执行步骤(2)。

¡ 如果路由的“Protocol”字段发生变化，请执行步骤(2)。

(2) 检查IS-IS引入外部路由的配置。

如果指定的路由是作为外部路由引入到IS-IS的，在引入该路由的设备上，执行display ip routing-table ip-address verbose命令，查看路由震荡的具体情况，具体步骤如下：

¡ 如果路由表中处于“Active”状态的路由是IS-IS路由，而不是IS-IS引入的外部路由，说明网络中其他IS-IS设备发布了相同的路由。请根据网络规划修改路由协议的优先级，或者，在引入外部路由的IS-IS设备上配置路由过滤策略，控制下发到IP路由表的路由。

¡ 对于其它情况，请执行步骤(3)。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

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

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

图46 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 ] ]命令查看接口的运行状态和相关信息，排查接口故障。其他情况请执行步骤9.2.1 4. (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. 故障分析

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

图47 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，请执行步骤9.2.2 4. (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. 故障分析

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

图48 OSPF邻居Down的故障诊断流程图

4. 处理步骤

(1) 通过命令行或日志查看OSPF邻居状态变为Down的原因。

执行display ospf event-log peer命令，显示信息中的Reason字段为邻居状态发生变化的原因，一般包含如下几种情况：

¡ DeadExpired

表示在邻居失效定时器超时前没有收到Hello报文，导致OSPF邻居状态变为Down。出现这种情况请执行步骤9.2.1 4. (1)。

¡ BFDDown

表示BFD会话Down导致OSPF邻居状态变为Down。出现这种情况请执行步骤9.2.1 4. (1)。

¡ IntVliChange或virtual link was deleted or the route it relies on was deleted

表示虚连接删除或者其依赖的路由删除导致邻居关系变为Down。出现这种情况请执行步骤9.2.1 4. (1)。

¡ 1-Way

表示对端OSPF状态首先变成Down，然后向本端发送1-way Hello报文，导致本端OSPF状态变为Init。出现这种情况请排查对端设备的故障。

¡ IntPhyChange

接口Down或者接口MTU改变导致邻居关系变为Down。此时，执行display interface [ interface-type [ interface-number | interface-number.subnumber ] ]命令查看接口的运行状态和相关信息，排查接口故障。其他情况请执行步骤9.2.1 4. (11)。

(2) 检查链路是否故障。

请执行ping命令，检查设备链路是否故障（包括传输设备故障）。如果链路正常，请执行步骤(3)。

(3) 检查CPU利用率是否过高。

请执行display cpu-usage命令检查故障设备的主控板和接口板的CPU利用率是否过高。CPU利用率过高会导致OSPF无法正常收发协议报文从而导致邻居振荡。可通过关闭一些不必要的功能解决此问题。如果CPU利用率不高，则执行步骤(4)。

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

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

图49 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，请执行步骤9.2.2 4. (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. 故障分析

本类故障的诊断流程如图50、图51所示。

图50 设备学习不到OSPF路由故障诊断流程图一

图51 设备学习不到OSPF路由故障诊断流程图二

4. 处理步骤

(1) 检查建立邻居关系的双方是否一端的网络类型为P2P，另一端的网络类型为Broadcast。

如果一端的网络类型为P2P，另一端的网络类型为Broadcast，那么邻居关系可以达到Full状态，但无法计算出路由信息。

a. 请执行display ospf interface命令查看接口的网络类型。

<Sysname> display ospf interface

OSPF Process 1 with Router ID 5.5.5.5

Interfaces

Area: 0.0.0.1

IP Address Type State Cost Pri DR BDR

192.168.51.5 PTP P-2-P 1 1 0.0.0.0 0.0.0.0

b. 如果存在上述情况，请在OSPF接口视图下执行ospf network-type命令将本端设备与邻居设备的OSPF接口网络类型配置为一致。

如果不存在上述情况，请执行步骤(2)。

(2) 多次查看OSPF路由表，检查是否存在OSPF路由震荡的问题。

请执行display ip routing-table protocol ospf verbose命令，查看Age字段，确认是否存在震荡的OSPF路由。

¡ 如果某条或某些OSPF路由Age字段的数值一直很小，说明相应的OSPF路由发生震荡，请解决路由震荡问题。

¡ 如果不存在路由震荡的问题，请执行步骤(3)。

<Sysname> display ip routing-table protocol ospf verbose

Summary count : 3

Destination: 192.168.12.0/24

Protocol: O_INTER

Process ID: 1

SubProtID: 0x2 Age: 12h53m09s

Cost: 2 Preference: 10

IpPre: N/A QosLocalID: N/A

Tag: 0 State: Active Adv

OrigTblID: 0x0 OrigVrf: default-vrf

TableID: 0x2 OrigAs: 0

NibID: 0x13000003 LastAs: 0

AttrID: 0xffffffff Neighbor: 0.0.0.0

Flags: 0x10041 OrigNextHop: 192.168.51.1

Label: NULL RealNextHop: 192.168.51.1

BkLabel: NULL BkNextHop: N/A

SRLabel: NULL Interface: GigabitEthernet1/0/2

BkSRLabel: NULL BkInterface: N/A

SIDIndex: NULL InLabel: NULL

Tunnel ID: Invalid IPInterface: GigabitEthernet1/0/2

BkTunnel ID: Invalid BkIPInterface: N/A

FtnIndex: 0x0 ColorInterface: N/A

TrafficIndex: N/A BkColorInterface: N/A

Connector: 0.0.0.0 VpnPeerId: N/A

Dscp: N/A Exp: N/A

SRTunnelID: Invalid StatFlags: 0x0

SID Type: N/A SID: N/A

BkSID: N/A NID: Invalid

FlushNID: Invalid BkNID: Invalid

BkFlushNID: Invalid PathID: 0x0

CommBlockLen: 0

OrigLinkID: 0x0 RealLinkID: 0x0

Destination: 192.168.24.0/24

Protocol: O_INTER

Process ID: 1

SubProtID: 0x2 Age: 12h53m09s

Cost: 3 Preference: 10

IpPre: N/A QosLocalID: N/A

Tag: 0 State: Active Adv

OrigTblID: 0x0 OrigVrf: default-vrf

TableID: 0x2 OrigAs: 0

NibID: 0x13000003 LastAs: 0

AttrID: 0xffffffff Neighbor: 0.0.0.0

Flags: 0x10041 OrigNextHop: 192.168.51.1

Label: NULL RealNextHop: 192.168.51.1

BkLabel: NULL BkNextHop: N/A

SRLabel: NULL Interface: GigabitEthernet1/0/2

BkSRLabel: NULL BkInterface: N/A

SIDIndex: NULL InLabel: NULL

Tunnel ID: Invalid IPInterface: GigabitEthernet1/0/2

BkTunnel ID: Invalid BkIPInterface: N/A

FtnIndex: 0x0 ColorInterface: N/A

TrafficIndex: N/A BkColorInterface: N/A

Connector: 0.0.0.0 VpnPeerId: N/A

Dscp: N/A Exp: N/A

SRTunnelID: Invalid StatFlags: 0x0

SID Type: N/A SID: N/A

BkSID: N/A NID: Invalid

FlushNID: Invalid BkNID: Invalid

BkFlushNID: Invalid PathID: 0x0

CommBlockLen: 0

OrigLinkID: 0x0 RealLinkID: 0x0

Destination: 192.168.51.0/24

Protocol: O_INTRA

Process ID: 1

SubProtID: 0x1 Age: 12h54m07s

Cost: 1 Preference: 10

IpPre: N/A QosLocalID: N/A

Tag: 0 State: Inactive Adv

OrigTblID: 0x0 OrigVrf: default-vrf

TableID: 0x2 OrigAs: 0

NibID: 0x13000001 LastAs: 0

AttrID: 0xffffffff Neighbor: 0.0.0.0

Flags: 0x10c1 OrigNextHop: 0.0.0.0

Label: NULL RealNextHop: 0.0.0.0

BkLabel: NULL BkNextHop: N/A

SRLabel: NULL Interface: GigabitEthernet1/0/2

BkSRLabel: NULL BkInterface: N/A

SIDIndex: NULL InLabel: NULL

Tunnel ID: Invalid IPInterface: GigabitEthernet1/0/2

BkTunnel ID: Invalid BkIPInterface: N/A

FtnIndex: 0x0 ColorInterface: N/A

TrafficIndex: N/A BkColorInterface: N/A

Connector: 0.0.0.0 VpnPeerId: N/A

Dscp: N/A Exp: N/A

SRTunnelID: Invalid StatFlags: 0x0

SID Type: N/A SID: N/A

BkSID: N/A NID: Invalid

FlushNID: Invalid BkNID: Invalid

BkFlushNID: Invalid PathID: 0x0

CommBlockLen: 0

OrigLinkID: 0x0 RealLinkID: 0x0

(3) 检查OSPF进程下是否配置了filter-policy import命令。

某些场景下需要对路由信息进行过滤，实现业务隔离。请检查是否存在OSPF路由被错误过滤的情况。

a. 请在本端设备出现问题的OSPF进程下执行display this命令，查看该OSPF进程下是否配置了filter-policy import命令，导致OSPF路由被过滤。

[Sysname-ospf-1] display this

ospf 1

import-route direct

filter-policy 2000 import

area 0.0.0.1

network 192.168.51.0 0.0.0.255

nssa

return

b. 如果OSPF进程下配置了filter-policy import命令，请查看该命令引用的过滤规则的配置信息。

- 对于filter-policy import命令引用ACL规则进行路由过滤的情况，请执行display acl { acl-number | name acl-name }命令查看ACL的配置信息。

- 对于filter-policy import命令引用前缀列表进行路由过滤的情况，请执行display ip prefix-list命令查看地址前缀列表的配置信息。

- 对于filter-policy import命令引用路由策略进行路由过滤的情况，请执行display route-policy命令查看路由策略的配置信息。

如果路由被过滤规则拒绝，请结合组网及实际业务需求确认过滤规则的配置是否合理。如果不合理，请修改filter-policy import命令引用的过滤规则。

c. 如果该路由没有被拒绝，或者该OSPF进程并没有配置filter-policy import过滤策略，请执行步骤(4)。

(4) 检查OSPF进程的LSDB是否包含未学习到的OSPF路由的LSA。

请根据OSPF进程未学习到的路由信息的类型选择不同的故障处理方式。

o OSPF区域内路由

如果OSPF进程缺失区域内路由，请在用户视图下执行display ospf [ process-id ] lsdb router命令，检查LSDB是否包含该区域中所有的Router LSA信息。

<Sysname> display ospf 100 lsdb router

OSPF Process 100 with Router ID 5.5.5.5

Area: 0.0.0.1

Link State Database

Type : Router

LS ID : 5.5.5.5

Adv Rtr : 5.5.5.5

LS age : 7

Len : 36

Options : ASBR O NP

Seq# : 80000026

Checksum : 0x5f1f

Link Count: 1

Link ID: 192.168.51.1

Data : 192.168.51.5

Link Type: TransNet

Metric : 1

Type : Router

LS ID : 1.1.1.1

Adv Rtr : 1.1.1.1

LS age : 8

Len : 36

Options : ASBR ABR O NP

Seq# : 8000002a

Checksum : 0x534a

Link Count: 1

Link ID: 192.168.51.1

Data : 192.168.51.1

Link Type: TransNet

Metric : 1

- 如果OSPF进程的LSDB缺失Router LSA，请执行步骤(7)。

- 如果OSPF进程的LSDB包含完整的Router LSA，但是无法计算出路由信息，请执行步骤(7)。

o OSPF区域间路由

如果OSPF进程缺失区域间路由，请在用户视图下执行display ospf [ process-id ] lsdb summary命令，检查LSDB是否包含其他所有区域的Network Summary LSA。

<Sysname> display ospf lsdb summary

OSPF Process 1 with Router ID 5.5.5.5

Area: 0.0.0.1

Link State Database

Type : Sum-Net

LS ID : 192.168.24.0

Adv Rtr : 1.1.1.1

LS age : 576

Len : 28

Options : O NP

Seq# : 8000001f

Checksum : 0x4c25

Net Mask : 255.255.255.0

Tos 0 Metric: 2

Type : Sum-Net

LS ID : 192.168.12.0

Adv Rtr : 1.1.1.1

LS age : 576

Len : 28

Options : O NP

Seq# : 8000001f

Checksum : 0xc6b7

Net Mask : 255.255.255.0

Tos 0 Metric: 1

- 如果OSPF进程的LSDB缺失Network Summary LSA，检查本区域下是否配置了filter import命令，或者Network Summary LSA的发布者所在区域下是否配置了filter export命令。如果filter import命令或filter export命令引用的过滤规则错误地过滤掉了Network Summary LSA，请修改过滤规则相关配置。

filter import命令和filter export命令可以引用ACL、前缀列表、路由策略对Network Summary LSA进行过滤，请分别使用display acl { acl-number | name acl-name }命令、display ip prefix-list命令、display route-policy命令查看相应的配置信息。

- 如果OSPF进程的LSDB包含完整的Network Summary LSA，但是无法计算出路由信息，请执行步骤(7)。

o O_ASE路由或者O_NSSA路由

如果OSPF进程缺失O_ASE路由，请在用户视图下执行display ospf [ process-id ] lsdb ase命令。检查LSDB是否包含AS External LSA。

<Sysname> display ospf 100 lsdb ase

OSPF Process 100 with Router ID 1.1.1.1

Link State Database

Type : External

LS ID : 10.1.1.0

Adv Rtr : 1.1.1.1

LS age : 713

Len : 36

Options : O E

Seq# : 80000001

Checksum : 0x934b

Net Mask : 255.255.255.0

TOS 0 Metric: 1

E Type : 2

Forwarding Address : 192.168.51.5

Tag : 1

如果OSPF进程缺失O_NSSA路由，请在用户视图下执行display ospf [ process-id ] lsdb nssa命令，检查LSDB是否包含NSSA External LSA。

<Sysname> display ospf 100 lsdb nssa

OSPF Process 100 with Router ID 1.1.1.1

Area: 0.0.0.0

Link State Database

Area: 0.0.0.1

Link State Database

Type : NSSA

LS ID : 192.168.51.0

Adv Rtr : 5.5.5.5

LS age : 965

Len : 36

Options : O NP

Seq# : 8000001f

Checksum : 0x1dfa

Net Mask : 255.255.255.0

TOS 0 Metric: 1

E Type : 2

Forwarding Address : 192.168.51.5

Tag : 1

Type : NSSA

LS ID : 10.1.1.0

Adv Rtr : 5.5.5.5

LS age : 965

Len : 36

Options : O NP

Seq# : 8000001f

Checksum : 0x6840

Net Mask : 255.255.255.0

TOS 0 Metric: 1

E Type : 2

Forwarding Address : 192.168.51.5

Tag : 1

- 如果OSPF进程的LSDB缺失AS External LSA或NSSA External LSA，请执行步骤(7)。

- 如果OSPF进程的LSDB包含完整的AS External LSA或NSSA External LSA，但是无法学习到O_ASE路由或者O_NSSA路由的情况，请执行步骤(7)。

(5) 检查ABR设备是否可达。

区域间路由是ABR设备发布的，如果本端设备和ABR设备之间路由不可达，则会导致本端设备无法学习到区域间路由。

a. 请在本端设备执行display ospf [ process-id ] lsdb summary命令，查看Adv Rtr字段，该字段为通告Network Summary LSA的Router ID，即ABR的Router ID。

<Sysname> display ospf 100 lsdb summary

OSPF Process 100 with Router ID 5.5.5.5

Area: 0.0.0.1

Link State Database

Type : Sum-Net

LS ID : 192.168.12.0

Adv Rtr : 1.1.1.1

LS age : 913

Len : 28

Options : O E

Seq# : 80000001

Checksum : 0x5d45

Net Mask : 255.255.255.0

Tos 0 Metric: 1

b. 请在本端设备执行display ospf abr-asbr命令，查看Destination字段和RtType字段，RtType字段取值为ABR时，Destination字段为ABR的Router ID。查看到此类路由信息时，说明存在到达为ABR的路由。

<Sysname> display ospf 100 abr-asbr

OSPF Process 100 with Router ID 5.5.5.5

Routing Table to ABR and ASBR

Type Destination Area Cost Nexthop RtType

Intra 1.1.1.1 0.0.0.1 1 192.168.51.1 ABR

c. 如果abr-asbr信息中不包含到达通告Network Summary LSA的ABR的路由，请执行步骤(7)。

d. 如果abr-asbr信息中包含到达通告Network Summary LSA的ABR的路由，且本设备为ABR设备，请检查OSPF区域是否为骨干区域。

- 如果OSPF区域为非骨干区域（区域ID不为零），根据RFC 2328的规定，ABR设备不会对非骨干区的Network Summary LSA进行计算，没有区域间路由是正常现象。

- 如果OSPF区域为骨干区域（区域ID为零），但是没有学习到区域间路由，请执行步骤(7)。

e. 如果abr-asbr信息中包含到达通告Network Summary LSA的ABR的路由，且本OSPF进程绑定了VPN实例。请检查OSPF进程下是否配置了vpn-instance-capability simple命令。如果OSPF进程下配置了vpn-instance-capability simple命令，请执行步骤(7)。

如果OSPF进程下未配置vpn-instance-capability simple命令，故障处理方式如表5所示。

表5 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 routing 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路由的影响如表6所示。

表6 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命令，故障处理方式如表7所示。

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

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

9.4.4 网络中IP地址冲突导致路由震荡

1. 故障描述

OSPF组网中不同设备上配置相同的接口IP地址，会导致OSPF路由震荡。出现此问题时，设备通常伴随如下现象：

· 执行命令display cpu-usage查看到设备CPU使用率较高。

· OSPF频繁地老化LSA、重新生成LSA。

· 设备路由频繁刷新、路由计算出错。

2. 处理步骤

以图52为示例说明此类故障的处理方式。其他组网与该组网处理此类故障的思路是相同的。

图52 网络中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. 告警与日志

10 组播类故障处理

10.1 MSDP故障处理

10.1.1 MSDP对等体无法正确建立（S，G）表项

1. 故障描述

配置组播网络后发现MSDP对等体无法正确建立（S，G）表项。

2. 常见原因

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

· MSDP对等体建立失败。

· SA报文缓存机制未开启。

· 没有收到源端对等体发出的SA报文。

· 创建SA报文的MSDP对等体没有部署在RP上。

· 配置问题（比如，export、import过滤策略、import-source策略配置不正确）。

3. 故障分析

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

图53 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.2 PIM故障处理

10.2.1 PIM邻居Down

1. 故障描述

PIM邻居Down。

2. 常见原因

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

· 接口物理状态为Down。

· 接口上未配置主IP地址。

· 接口上PIM功能没有生效。

· 接口没有使能PIM。

· 接口上PIM相关配置不正确。

3. 故障分析

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

图54 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.2.2 PIM域内三层组播流量不通

1. 故障描述

开启IP组播路由功能后，同一PIM域内三层组播流量不通。

2. 常见原因

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

· 需要转发组播数据的接口未使能PIM。

· 接口的PIM协议没有生效。

· PIM邻居未建立成功。

· 连接用户网段的接口未使能IGMP。

· 在PIM-SM或双向PIM网络中，没有配置RP或RP信息不正确。

· 不存在到达RP或组播源的RPF路由。

· 转发组播数据的接口上配置了组播边界。

· 在PIM-SM或双向PIM网络中，配置了错误的组播源过滤策略。

· 组播表项未生成。

3. 故障分析

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

图55 PIM域内三层组播流量不通的故障诊断流程图

4. 处理步骤

(1) 检查需要转发组播数据的接口是否使能PIM。

在需要转发组播数据的接口视图下执行display this命令，检查是否存在pim sm或pim dm的配置。

¡ 如果不存在，表明接口下PIM功能未开启。请在接口视图下通过pim sm或pim dm命令开启PIM功能。若是双向PIM网络，在接口视图下配置了通过pim sm命令开启PIM功能后，还需在PIM视图下通过bidir-pim enable命令开启双向PIM功能。

¡ 如果存在，请执行步骤(2)。

(2) 检查接口的PIM功能是否生效。

在设备上执行display pim interface命令，通过查看显示信息中是否存在该接口对应的PIM相关信息确认接口上PIM功能是否生效。

¡ 如果没有生效，请在设备上执行display interface interface-type interface-number命令查看显示信息中的“Current state”字段，确认接口的物理状态是否为Up。如果为Down，请排查处理接口物理Down的问题。

¡ 如果生效，请执行步骤(3)。

(3) 检查PIM邻居是否建立成功。

在设备上执行display pim neighbor命令，根据是否存在相应的PIM邻居信息，判断PIM邻居是否建立成功。

a. 如果未建立成功，请参见“PIM邻居Down”进行定位，确保PIM邻居建立成功。

b. 如果建立成功，请执行步骤(4)。

(4) 检查连接用户网段的接口上IGMP功能是否生效。

在设备上执行display igmp interface命令，根据是否存在显示信息确认接口IGMP功能是否生效。

¡ 如果没有生效，请检查接口下是否通过igmp enable命令开启了IGMP功能，确保IGMP功能已开启。

¡ 如果已生效，根据不同的网络类型执行如下操作：

- 若为PIM-SM或双向PIM网络，请执行步骤(5)。

- 若为PIM-DM网络，请执行步骤(7)。

(5) 对于PIM-SM或双向PIM网络，检查RP信息是否正确。

在设备上执行display pim rp-info命令，查看设备是否生成了为某组播组服务的RP信息表项，并检查PIM-SM或双向PIM域中其它所有设备上，为此组播组服务的RP信息是否配置一致。

¡ 如果不一致，且PIM-SM/双向PIM网络中使用静态RP，请在PIM-SM/双向PIM域的所有设备上的PIM视图下执行static-rp命令，将为某组播组服务的RP地址配置为相同的地址；如果PIM-SM/双向PIM网络中使用动态RP，请执行步骤(6)。

¡ 如果一致，请执行步骤(6)。

(6) 检查是否存在到达RP的RPF路由。

在设备上执行display multicast rpf-info命令，查看是否存在到达RP的RPF路由。

¡ 如果不存在，检查单播路由配置。请在当前设备和RP上分别执行ping命令，检查是否能够互相ping通。如果ping不通，请修改单播路由配置，直到ping通为止。

¡ 如果存在，通过执行display multicast rpf-info命令，查看显示信息中的Referenced route type字段，确认RPF为组播静态路由还是单播路由。

- 如果RPF路由为组播静态路由，请执行display multicast routing-table static命令查看组播静态路由配置是否合理。

- 如果RPF路由为单播路由，请执行display ip routing-table命令查看单播路由是否与RPF路由一致。

如果到达RP的RPF路由存在且配置合理，请执行步骤(8)。

(7) 检查是否存在到达组播源的RPF路由。

在设备上执行display multicast rpf-info命令，查看是否存在到达组播源的RPF路由。

¡ 如果不存在，检查单播路由配置。请在当前设备和组播源上分别执行ping命令，检查是否能够互相ping通。如果ping不通，请修改单播路由配置，直到Ping通为止。

¡ 如果存在，通过执行display multicast rpf-info命令，查看显示信息中的Referenced route type字段，确认RPF为组播静态路由还是单播路由。

- 如果Referenced route type字段显示为“multicast static”，表示RPF路由为组播静态路由，请执行display multicast routing-table static命令查看组播静态路由配置是否合理。

- 如果Referenced route type字段显示为“igp”、“egp”、“unicast (direct)”或“unicast”，表示RPF路由为单播路由，请执行display ip routing-table命令查看单播路由是否与RPF路由一致。

如果到达组播源的RPF路由存在且配置合理，请执行步骤(8)。

(8) 检查RPF接口和RPF邻居接口上是否配置组播转发边界。

在设备上执行display multicast boundary命令，查看接口上是否配置了组播转发边界。

¡ 如果已配置，建议在接口上执行undo multicast boundary命令删除对应配置或重新进行网络规划，确保RPF接口和RPF邻居接口没有配置组播边界。

¡ 如果未配置，请执行步骤(9)。

(9) 检查是否配置组播数据过滤器。

在PIM视图下执行display this命令，查看是否配置组播数据过滤器（通过PIM视图下的source-policy命令配置）。

¡ 如果已配置，继续确认接收到的组播数据是否在过滤器指定的允许范围之内。如果不在，建议根据实际组网需要执行undo source-policy命令删除该配置或重新配置ACL规则，确保用户需要的组播数据正常转发。

¡ 如果未配置，请执行步骤(10)。

(10) 检查组播表项是否生成。

在设备上分别查看组播表项是否生成：

¡ 如果存在相应的表项，流量仍然不通，请收集相关表项信息，并执行步骤(11)。

¡ 如果不存在，请执行步骤(11)。

需要查看的组播表项以及查看方式如下：

¡ 在设备上执行display pim routing-table命令，检查PIM协议路由表项是否生成。

¡ 在设备上执行display igmp group命令，检查IGMP协议是否有对应的组播组。

¡ 在设备上执行display multicast routing-table命令，检查组播路由表是否生成。

¡ 在设备上执行display multicast forwarding-table命令，检查组播转发表是否生成。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

10.2.3 PIM-SM网络中SPT无法正常转发数据

1. 故障描述

PIM-SM网络中SPT无法正常转发数据，组播流量不通。

2. 常见原因

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

· 组播设备连接下游设备的接口没有收到PIM加入报文。

· PIM-SM域内组播设备上的接口没有开启PIM-SM。

· PIM-SM域内组播设备到组播源的RPF路由不正确。

· 配置不正确（比如组播转发边界配置不正确、组播数据过滤器配置不正确等）。

3. 故障分析

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

图56 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.2.4 PIM-SM网络中RPT无法正常转发数据

1. 故障描述

PIM-SM网络中RPT无法正常转发数据，组播流量不通。

2. 常见原因

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

· PIM-SM域内组播设备到RP的单播路由不通。

· PIM-SM域内各组播设备上为某一组播组服务配置的RP地址不一致。

· PIM-SM域内组播设备的下游接口没有收到PIM加入报文。

· PIM-SM域内组播设备上的接口没有开启PIM-SM。

· PIM-SM域内组播设备到RP的RPF路由不正确。

· 配置不正确（比如组播转发边界配置不正确、组播数据过滤器配置不正确等）。

3. 故障分析

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

图57 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.2.2 4. (6)。

(5) 检查是否存在到达RP的RPF路由。

在设备上执行display multicast rpf-info命令，查看是否存在到达RP的RPF路由。

¡ 如果存在，通过执行display multicast rpf-info命令，查看显示信息中的Referenced route type字段，确认RPF为组播静态路由还是单播路由。

- 如果RPF路由为组播静态路由，请执行display multicast routing-table static命令查看组播静态路由配置是否合理。

- 如果RPF路由为单播路由，请执行display ip routing-table命令查看单播路由是否与RPF路由一致。

如果到达RP的RPF路由存在且配置合理，请执行步骤(6)。

(6) 检查转发组播数据的接口对应的DR是否为接收者侧DR。

¡ 如果不是接收者侧DR，请根据显示信息中的DR地址找到对应的DR设备，并在该DR设备上执行步骤(7)。

¡ 如果是接收者侧DR，请在当前设备上执行步骤(7)。

(7) 检查RPF接口和RPF邻居接口上是否配置组播转发边界。

在设备上执行display multicast boundary命令，查看接口上是否配置了组播转发边界。

¡ 如果已配置，建议在接口上执行undo multicast boundary命令删除对应配置或重新进行网络规划，确保RPF接口和RPF邻居接口没有配置组播边界。

¡ 如果未配置，请执行步骤(8)。

(8) 检查是否配置组播数据过滤器。

在PIM视图下执行display this命令，查看是否配置组播数据过滤器（通过PIM视图下的source-policy命令配置）。

¡ 如果未配置，请执行步骤(9)。

(9) 再次检查PIM路由表是否存在正确的（*，G）表项。

在设备上再次执行display pim routing-table命令，查看PIM路由表中是否存在（*，G）表项。具体方法请参见步骤(1)。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

10.3 二层组播故障处理

10.3.1 二层组播业务不通

1. 故障描述

二层组播业务不通主要表现在二层组播转发表项无法生成，导致组播流量无法正常转发。

2. 常见原因

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

· 设备没有收到二层组播协议报文。

· IGMP协议报文格式不正确。

· 二层组播转发表项未生成。

3. 故障分析

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

(1) 检查是否生成二层组播转发表项。

(2) 检查是否正常收到组播协议报文。

(3) 检查IGMP协议报文格式是否正确。

(4) 检查IGMP报文版本是否跟设备上配置的一致。

(5) 检查是否开启三层组播功能。

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

图58 二层组播业务不通的故障诊断流程图

4. 处理步骤

(1) 检查是否生成正确的二层组播转发表项。

执行display l2-multicast ip forwarding命令查看二层组播表项是否生成。

¡ 如果存在，请直接联系技术人员。

¡ 如果不存在，请执行步骤(2)。

(2) 检查设备是否正常收到IGMP成员关系报告报文。

执行debugging igmp-snooping packet命令，打开IGMP Snooping报文调试信息开关。如果设备上打印如下调试信息，表示可以正常收到成员关系报告报文。

*Sep 15 11:47:41:455 2011 Sysname MCS/7/PACKET: -MDC=1; Receive IGMPv2 report packet from port GE1/0/1 on VLAN 2. (G162625)

¡ 如果没有，检查下游设备和终端设备是否正常。

¡ 如果有，请执行步骤(3)。

(3) 检查IGMP协议报文交互过程是否正常，报文格式是否符合协议规范。

IGMP协议交互不正常时，通常会出现设备上转发表项无法生成的现象，导致组播数据流无法正常转发，造成组播业务中断。

在设备上配置镜像，并联系技术支持，在专业人士的指导下使用抓包工具（例如Wireshark）对镜像的IGMP协议报文进行分析。

¡ 如果不正常，请将IGMP协议报文修改为符合协议规范的报文。

¡ 如果正常，请执行步骤(4)。

(4) 检查收到的IGMP报文的版本是否与设备配置的IGMP Snooping版本一致。

执行display igmp-snooping命令查看显示信息中的Version字段确认设备使用的IGMP Snooping版本，检查是否与收到的IGMP报文的版本一致。

¡ 如果不一致，可以用如下两种方法处理：

- 修改上下游设备的IGMP版本，保证上下游设备的IGMP版本与本设备上配置的IGMP Snooping版本一致。

- 在本设备IGMP-Snooping视图下执行version命令或者在VLAN视图下执行igmp-snooping version命令，修改IGMP Snooping版本，保证本设备的IGMP Snooping版本与上下游设备的IGMP版本一致。

¡ 如果一致，请执行步骤(5)。

(5) 检查是否开启三层组播功能。

在开启了二层组播功能的VLAN所对应的VLAN接口上，若同时开启三层组播功能，会导致二层组播转发表项无法下发硬件，请关闭三层组播功能。

¡ 如果开启了三层组播功能，请删除三层组播配置。

¡ 如果未开启三层组播功能，请执行步骤(6)。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

10.4 三层组播故障处理

10.4.1 三层组播业务不通

1. 故障描述

三层组播业务不通主要表现在组播流量转发失败。

2. 常见原因

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

· 单播路由配置错误。

· 接口状态不正确。

· PIM路由表项未正确生成。

· 组播转发表项未正确生成。

3. 故障分析

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

图59 三层组播业务不通的故障诊断流程图

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

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

图60 设备无法正常建立IGMP或MLD表项的故障诊断流程图

4. 处理步骤

(1) 检查设备上是否开启IP组播路由功能。

在直连用户主机网段的设备上执行display current-configuration | include multicast命令，查看是否开启IP组播路由功能。

¡ 如果未开启，请在系统视图下执行multicast routing或ipv6 multicast routing命令，开启IP组播路由功能。

¡ 如果已开启，请执行步骤(2)。

(2) 检查与用户主机网段直连接口的物理状态是否为Up。

在直连用户主机网段的设备上执行display interface interface-type interface-number命令查看显示信息中的“Current state”字段，确认与用户主机网段直连的接口的物理状态是否为Up。

a. 如果为Up，请执行步骤(3)。

b. 如果为Down，请排查处理接口物理Down的问题。

(3) 检查接口上是否配置了主IP地址。

在设备直连用户主机网段接口的接口视图下执行display this命令，查看是否通过ip address命令配置了接口的主IP地址。

a. 如果没有配置，请在接口上通过ip address命令进行配置。

b. 如果已配置，请执行步骤(4)。

(4) 检查与用户主机网段直连接口上是否开启IGMP或MLD功能。

在直连用户主机网段的设备上执行display current-configuration interface命令，查看与用户主机网段直连的接口上是否开启IGMP或MLD功能。

a. 如果没有开启，请在相应的接口上开启IGMP或MLD功能。

b. 如果已开启，请执行步骤(5)。

(5) 检查组播组G是否属于SSM组地址范围。

¡ 对于IGMP表项无法生成的情况：

请检查组播组G是否属于SSM组地址范围，SSM组播组地址的范围为232.0.0.0/8。

- 如果属于，请确保与用户主机网段直连的接口上的IGMP版本为IGMPv3，并确认IGMPv3的报文正确。如果故障仍未排除，请执行步骤(6)。

- 如果不属于，请执行步骤(7)。

¡ 对于MLD表项无法生成的情况：

请检查组播组G是否属于IPv6 SSM组地址范围，IPv6 SSM组播组的范围为FF3x::/32。

- 如果属于，请确保与用户主机网段直连的接口上的MLD版本为MLDv2。如果故障仍未排除，请执行步骤(6)。

- 如果不属于，请执行步骤(7)。

(6) 检查是否配置了SSM组播组过滤器。

在直连用户主机网段的设备上执行display current-configuration configuration pim或者display current-configuration configuration pim6命令，查看是否已通过ssm-policy命令配置SSM组播组的范围。

¡ 如果已配置，请检查组播组G是否在ACL规则允许的范围之内。

- 如果不在，建议根据实际组网在PIM视图下执行undo ssm-policy命令恢复缺省情况；重新配置ACL规则，使得组播组G地址在ACL的permit规则中。

- 如果在，请执行步骤(7)。

¡ 如果未配置，请执行步骤(7)。

(7) 检查接口上是否配置了IGMP或MLD组播组过滤器。

在直连用户主机网段的设备上执行display current-configuration命令，查看是否已通过igmp group-policy或mld group-policy命令配置了IGMP或MLD组播组过滤器。

¡ 如果已配置，请检查组播组G是否在ACL规则允许的范围之内。

- 如果不在，建议根据实际组网需要执行undo igmp group-policy或undo mld group-policy命令删除该组播组过滤器配置；重新配置ACL规则，使得组播组G地址在ACL的permit规则中。

- 如果在，请执行步骤(8)。

¡ 如果未配置，请执行步骤(8)。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

11 MPLS类故障处理

11.1 LDP故障处理

11.1.1 LDP会话无法Up

1. 故障描述

LDP会话无法Up。

2. 常见原因

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

· 建立会话的接口处于Down状态

· LSR ID配置错误

· 不存在LDP会话的相关配置

· 传输地址配置错误

· LDP Hello-hold定时器超时

· LDP Keepalive-hold定时器超时

· 安全认证配置错误

3. 故障分析

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

图61 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

…

如果至少配置了一种LSR ID，则执行步骤(3)。

(3) 检查是否存在LDP会话的相关配置。

如果是直连会话，则在接口视图下执行display this命令，查看是否存在LDP会话的相关配置。

a. 如果配置信息中没有包含mpls enable命令、mpls ldp enable命令、mpls ldp ipv6 enable命令或mpls ldp transport-address命令，则部署对应的配置。

b. 如果存在LDP会话的相关配置，则执行步骤(4)。

如果是LDP远程会话，则在LDP视图下执行display this命令，查看是否存在LDP会话的相关配置。

c. 如果配置信息中没有包含targeted-peer或mpls ldp transport-address命令，则部署对应的配置。

d. 如果存在LDP会话的相关配置，则执行步骤(4)。

(4) 检查传输地址配置是否正确。

如果是LDP IPv4会话，请执行display mpls ldp discovery verbose命令检查传输地址配置是否正确：

<Sysname> display mpls ldp discovery verbose

VPN instance: public instance

Link Hellos:

Interface GigabitEthernet1/0/2

Local LDP ID : 100.100.100.17:0

Hello Interval : 5000 ms Hello Sent/Rcvd : 83/160

Transport Address: 100.100.100.17

Peer LDP ID : 100.100.100.18:0

Source Address : 202.118.224.18 Transport Address: 100.100.100.18

Hello Hold Time: 15 sec (Local: 15 sec, Peer: 15 sec)

Peer LDP ID : 100.100.100.20:0

Source Address : 202.118.224.20 Transport Address: 100.100.100.20

Hello Hold Time: 15 sec (Local: 15 sec, Peer: 15 sec)

Targeted Hellos:

100.100.100.17 -> 100.100.100.18 (Active, Passive)

Local LDP ID : 100.100.100.17:0

Hello Interval : 15000 ms Hello Sent/Rcvd : 23/20

Transport Address: 100.100.100.17

Session Setup : Config/Tunnel

Peer LDP ID : 100.100.100.18:0

Source Address : 100.100.100.18 Transport Address: 100.100.100.18

Hello Hold Time: 45 sec (Local: 45 sec, Peer: 45 sec)

如果是LDP IPv6会话，请执行display mpls ldp discovery ipv6 verbose命令检查传输地址配置是否正确：

<Sysname> display mpls ldp discovery ipv6 verbose

VPN instance: public instance

Link Hellos:

Interface GigabitEthernet1/0/2

Hello Interval : 5000 ms Hello Sent/Rcvd : 83/160

Transport Address: 2001::2

Peer LDP ID : 100.100.100.18:0

Source Address : FE80:130F:20C0:29FF:FEED:9E60:876A:130B

Transport Address: 2001::1

Hello Hold Time: 15 sec (Local: 15 sec, Peer: 15 sec)

Targeted Hellos:

2001:0000:130F::09C0:876A:130B ->

2005:130F::09C0:876A:130B(Active, Passive)

Hello Interval : 15000 ms Hello Sent/Rcvd : 23/22

Transport Address: 2001:0000:130F::09C0:876A:130B

Peer LDP ID : 100.100.100.18:0

Source Address : 2005:130F::09C0:876A:130B

Destination Address : 2001:0000:130F::09C0:876A:130B

Transport Address : 2005:130F::09C0:876A:130B

Hello Hold Time: 45 sec (Local: 45 sec, Peer: 45 sec)

如果传输地址配置不正确，则可以在接口视图或LDP对等体视图下执行mpls ldp transport-address命令配置传输地址。缺省情况下，传输地址为本LSR的LSR ID。

如果传输地址配置正确，则需要确认路由是否发布。执行display ip routing-table命令，查看是否存在到达会话对端的路由。

a. 如果不存在到达会话对端的路由，则请将传输地址配置成本机存在的IP地址，确保路由正确发布。

b. 如果存在到达会话对端的路由，则执行步骤(5)。

(5) 检查LDP Hello-hold定时器是否超时。

建议每5秒执行一次display mpls ldp discovery命令，查看收发Hello消息的计数，检查会话两端的Hello消息是否都正常发送。若连续几次执行命令后发现发送或接收的计数没有变化，则表示Hello消息收发异常，Hello-hold定时器超时。

¡ 如果Hello-hold定时器超时，请排除链路问题，并检查设备CPU利用率。如果CPU利用率过高，请关闭一些不必要功能；如果CPU利用率正常，则执行步骤(6)。

¡ 如果Hello-hold定时器没有超时，则执行步骤(6)。

(6) 检查LDP Keepalive-hold定时器是否超时。

建议每15秒执行一次display mpls ldp peer命令，查看收发的Keepalive消息的计数，检查会话两端的Keepalive消息是否都正常发送。若连续几次执行命令后发现发送或接收的计数没有变化，则表示Keepalive消息收发异常，Keepalive-hold定时器超时。

¡ 如果Keepalive-hold定时器超时，则排除报文转发问题。

¡ 如果Keepalive-hold定时器没有超时，则执行步骤(7)。

(7) 安全认证配置是否正确。

请执行display mpls ldp peer命令LDP会话之间的安全认证是否配置，以及配置的安全认证类型是否一致：

<Sysname> display mpls ldp peer

VPN instance: public instance

Total number of peers: 1

Peer LDP ID State Role GR Auth KA Sent/Rcvd

2.2.2.9:0 Operational Passive Off Keychain 39/39

¡ 如果LDP会话两端Auth字段显示不一致，则将LDP会话两端的安全认证修改为一致。

¡ 如果LDP会话两端Auth字段显示一致，则执行步骤(8)。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

11.1.2 LDP会话震荡

1. 故障描述

LDP会话状态频繁震荡。

2. 常见原因

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

· 接口震荡

· 路由震荡

· CPU利用率过高

3. 故障分析

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

图62 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.1.3 LDP LSP无法Up

1. 故障描述

LDP网络中LDP LSP无法Up。

2. 常见原因

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

· 路由问题

· LDP会话Down

· 资源不足，如Label达到上限，内存不足等

· 配置了LSP触发策略、标签接受控制策略、标签通告控制策略或Label Mapping消息的发送策略

· 路由的出接口与LDP建立会话的接口不一致

3. 故障分析

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

(1) 检查路由是否存在。

(2) 检查LDP会话是否正常建立。

(3) 检查是否存在资源不足，入Label达到上限，内存不足的问题。

(4) 检查是否配置了LSP建立策略。

(5) 检查路由的出接口与LDP建立会话的接口是否一致。

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

图63 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.1.1 LDP会话无法Up”故障进行定位。

¡ 如果State字段的显示为Operational，则表示LDP会话已建立并处于Up状态，请执行步骤(3)。

(3) 检查是否配置了LSP策略。

¡ 在LDP视图下执行display this命令，如果存在以下命令，则需要检查IP前缀列表是否过滤了指定的LSP：

- lsp-trigger prefix-list

- accept-label peer prefix-list

- advertise-label prefix-list

- propagate mapping prefix-list

如果IP前缀列表过滤了指定的LSP，则请修改IP前缀列表，使其允许指定LSP目的地址通过；如果IP前缀列表没有过滤指定的LSP，则执行步骤(4)。

¡ 如果LDP视图下没有配置以上命令，则执行步骤(4)。

(4) 检查路由的出接口与LDP建立会话的接口是否一致。

执行display ip routing-table ip-address mask命令，查看指定路由的出接口信息：

<Sysname> display ip routing-table 1.1.1.1 32

Summary count : 1

Destination/Mask Proto Pre Cost NextHop Interface

1.1.1.1/32 O_INTRA 10 1 10.1.1.1 GE1/0/1

执行display mpls ldp peer peer-lsr-id verbose命令，查看指定LDP对等体的Discovery Sources信息：

<Sysname> display mpls ldp peer 1.1.1.1 verbose

VPN instance: public instance

Peer LDP ID : 1.1.1.1:0

Local LDP ID : 2.2.2.2:0

TCP Connection : 2.2.2.2:14080 -> 1.1.1.1:646

Session State : Operational Session Role : Active

Session Up Time : 0000:00:55 (DD:HH:MM)

Max PDU Length : 4096 bytes (Local: 4096 bytes, Peer: 4096 bytes)

Keepalive Time : 45 sec (Local: 45 sec, Peer: 45 sec)

Keepalive Interval : 15 sec

Msgs Sent/Rcvd : 229/228

KA Sent/Rcvd : 223/223

Label Adv Mode : DU Graceful Restart : Off

Reconnect Time : 0 sec Recovery Time : 0 sec

Loop Detection : Off Path Vector Limit: 0

mLDP P2MP : Off

Discovery Sources:

GigabitEthernet1/0/1

Hello Hold Time: 15 sec Hello Interval : 5000 ms

Addresses received from peer:

10.1.1.1 1.1.1.1

¡ 如果Discovery Sources信息的接口信息不包含指定路由的出接口，则检查指定路由的出接口上对应的LDP配置是否正确，及下游设备对应接口的LDP配置是否正确。如果不正确，则修改相应配置；如果正确，则执行步骤(5)

¡ 如果Discovery Sources信息的接口信息包含指定路由的出接口，则执行步骤(5)。

(5) 检查是否资源不足，如内存不足，LSP数量达到上限的问题。

¡ 检查系统内存是否不足

执行display memory-threshold命令，查看系统内存是否不足。如果存在内存不足，则删除不必要的LSP。

¡ 检查标签数量是否超出上限。

执行display mpls summary命令，查看LDP的标签段剩余标签数量是否为0，即Idle字段显示为0。如果LDP标签段剩余标签数量为0，则表示LDP的标签资源全部使用完，需要删除不必要的LSP。

<Sysname> display mpls summary

MPLS LSR ID : 2.2.2.2

Egress Label Type: Implicit-null

Entropy Label : Off

Labels:

Range Used/Idle/Total Owner

16-2047 0/2032/2032 StaticPW

Static

StaticCR

Static SR Adj

BSID

2048-599999 9129/588823/597952 LDP

RSVP

BGP

BGP SR EPE

OSPF SR Adj

ISIS SR Adj

¡ 如果不存在资源不足问题，请执行步骤(6)。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

11.1.4 LDP LSP震荡

1. 故障描述

LDP网络中LDP LSP频繁震荡。

2. 常见原因

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

· 路由震荡。

· LDP会话震荡。

3. 故障分析

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

(1) 检查路由是否震荡。

(2) 检查LDP会话是否震荡。

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

图64 LDP LSP震荡的故障诊断流程图

4. 处理步骤

(1) 检查路由是否震荡。

建议每1秒执行一次display ip routing-table命令，连续执行5～10次，查看到达LSP目的地址的路由信息。路由存在时，会显示相关路由信息。路由不存在时，则不会显示相关路由信息。如果相关路由信息一直在显示和不显示两种情况切换，则表示路由震荡。

查看路由信息后，请执行display mpls ldp fec命令查看LSP下游信息，即Downstream Info中的State字段，确保与下游对等体建立的LSP处于激活状态（Established）。

<Sysname> display mpls ldp fec

VPN instance: public instance

FEC: 1.1.1.1/32

Flags: 0x112

In Label: 2175

Upstream Info:

Peer: 1.1.1.1:0 State: Established

Downstream Info:

Peer: 1.1.1.1:0

Out Label: 3 State: Established

Next Hops: 10.1.1.1 GE1/0/1

RIB Info:

Protocol : OSPF BGP As Num : 0

Label Proto ID : 1 NextHopCount : 1

VN ID : 0x313000003

Tunnel ID : -

¡ 如果路由震荡，或者路由一直都不存在，则请排除路由问题。

¡ 如果路由没有震荡，则执行步骤(2)。

(2) 检查LDP会话是否震荡。

建议每1秒执行一次display mpls ldp peer命令，连续执行5～10次，查看显示信息的State字段。如果该字段的取值在Operational状态和其他非Operational状态之间切换，则表示LDP会话震荡。

<Sysname> display mpls ldp peer

VPN instance: public instance

Total number of peers: 1

Peer LDP ID State Role GR AUT KA Sent/Rcvd

1.1.1.1:0 Operational Active Off None 298/298

¡ 如果LDP会话震荡，则请参见“11.1.2 LDP会话震荡”故障进行定位。

¡ 如果LDP会话没有震荡，则执行步骤(3)。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

11.2 MPLS L2VPN/VPLS故障处理

11.2.1 PW ping不通

1. 故障描述

执行ping mpls pw命令检测PW连通性，发现ping不通对端。

2. 常见原因

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

· 检测的PW不存在。

· PW模板配置错误。

· PW故障。

· PW不存在有效的公网转发路径。

3. 故障分析

本类故障需要根据ping mpls pw命令的回显信息进行分析和定位，具体诊断思路如下：

· 回显信息为Unknown PW时，表示检测的PW不存在，需要修改配置来解决本类故障。

· 回显信息为No suitable control channel for the PW时，表示PW的VCCV控制通道类型配置错误，需要通过vccv cc命令修改PW模板中VCCV控制通道类型来解决本类故障。

· 回显信息为Please configure pseudowire control-word for control channel时，表示PW引用的PW模板中未开启控制字功能，需要通过control-word enable命令在PW模板下开启控制字功能来解决本类故障。

· 回显信息为Request time out时，先排查本端PW是否Up，再通过tracert mpls pw命令来定位故障节点。

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

图65 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 GE1/0/1

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

¡ 上述步骤的执行结果。

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

¡ 使用display diagnostic-information命令收集诊断信息。

5. 告警与日志

相关告警

无。

相关日志

· L2VPN/2/L2VPN_PWSTATE_CHANGE

· L2VPN/4/L2VPN_BGPVC_CONFLICT_LOCAL

· L2VPN/4/L2VPN_BGPVC_CONFLICT_REMOTE

· L2VPN/4/L2VPN_HARD_RESOURCE_NOENOUGH

· L2VPN/2/L2VPN_HARD_RESOURCE_RESTORE

· L2VPN/4/L2VPN_LABEL_DUPLICATE

11.3 MPLS L3VPN故障处理

11.3.1 L3VPN流量中断

1. 故障描述

经过MPLS L3VPN网络转发的私网流量中断。

2. 常见原因

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

· 私网路由下一跳不可达。

· 路由策略配置不当导致路由无法发布和接收。

· 标签超限导致私网路由无法发布。

· 私网路由迭代不到隧道。

· Export RT和Import RT不匹配导致路由无法学习到私网路由表中。

· 路由超限导致收到的路由被丢弃。

3. 故障分析

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

图66 L3VPN流量中断故障诊断流程图

4. 处理步骤

(1) 检查路由是否为最优路由。

执行命令display bgp routing-table vpnv4或display bgp routing-table vpnv6命令，查看BGP VPNv4/VPNv6路由表中到达VPNv4/VPNv6邻居的BGP路由是否最优。

以路由100.1.2.0/24为例，路由信息中存在标记“>”，则表示该路由为最优路由。

<Sysname> display bgp routing-table vpnv4

BGP local router ID is 1.1.1.9

Status codes: * - valid, > - best, d - dampened, h - history,

s - suppressed, S - stale, i - internal, e - external

a – additional-path

Origin: i - IGP, e - EGP, ? - incomplete

Total number of VPN routes: 8

Total number of routes from all PEs: 8

Route distinguisher: 100:1(vpn1)

Total number of routes: 6

Network NextHop MED LocPrf PrefVal Path/Ogn

* > 1.1.1.0/24 1.1.1.1 0 32768 ?

* 1.1.1.2/32 1.1.1.1 0 32768 ?

* > 100.1.2.0/24 100.1.1.1 0 100 0 400i

根据以上显示信息进行判断：

¡ 如果不是最优路由，则执行display mpls lsp命令，查看是否存在指定路由的MPLS转发表项。如果不存在，则请在连接远端PE的公网接口下执行mpls enable和mpls ldp enable命令，开启MPLS功能和LDP功能，保证VPNv4路由可以迭代到公网LSP；如果存在，则执行步骤(2)。

¡ 如果是最优路由，则执行步骤(2)。

(2) 检查私网路由下一跳是否可达。

在路由的发送端（本端PE）执行display bgp routing-table vpnv4 ipv4-address [ mask | mask-length ]命令查看私网路由信息（ipv4-address表示私网路由前缀），确认路由是否存在。

¡ 如果路由不存在，请确认CE路由是否发布到PE。在远端PE上执行display bgp routing-table vpnv4 peer advertised-routes或display bgp routing-table vpnv6 peer advertised-routes命令，查看远端PE是否将私网路由信息发布给本端PE，例如：

<Sysname> display bgp routing-table vpnv4 peer 22.22.22.22 advertised-routes

Total number of routes: 6

BGP local router ID is 11.11.11.11

Status codes: * - valid, > - best, d - dampened, h - history,

s - suppressed, S - stale, i - internal, e - external

a - additional-path

Origin: i - IGP, e - EGP, ? - incomplete

Route distinguisher: 1:1

Total number of routes: 3

Network NextHop MED LocPrf Path/Ogn

* >e 1.1.1.1/32 10.1.1.2 0 100 20i

* >e 7.7.7.7/32 10.1.1.2 0 100 20?

* >e 10.1.1.0/24 10.1.1.2 0 100 20?

如果不存在以上显示信息，则执行步骤(3)。

¡ 如果路由存在，请确认私网路由下一跳是否可达，且私网路由是否活跃。

查看State字段，如果取值包括valid，则表示该路由是活跃的。查看Original nexthop字段，如果存在下一跳信息，则表示私网路由下一跳可达。

- 如果私网路由不活跃，则执行display ip routing-table vpn-instance vpn-instance-name ip-address命令查看IP路由表中是否存在到BGP下一跳（Original nexthop）的路由。如果不存在，则说明私网路由下一跳不可达，请检查PE之间的公网路由配置；如果存在，则说明BGP路由下一跳可达，请执行步骤(3)。

- 如果私网路由活跃，则执行步骤(3)。

<sysname> display bgp routing-table vpnv4 6.0.0.9 32

BGP local router ID: 4.0.0.9

Local AS number: 200

Route distinguisher: 103:1

Total number of routes: 1

Paths: 1 available, 1 best

BGP routing table information of 6.0.0.9/32:

From : 3.0.0.9 (3.0.0.9)

Rely nexthop : 20.0.2.1

Original nexthop: 3.0.0.9

OutLabel : 24128

Ext-Community : <RT: 100:1>

RxPathID : 0x0

TxPathID : 0x0

AS-path : 300 103

Origin : igp

Attribute value : pref-val 0

State : valid, external, best

IP precedence : N/A

QoS local ID : N/A

Traffic index : N/A

Tunnel policy : tp1

Rely tunnel IDs : 2

(3) 检查路由策略是否正确。

在路由的发送端和接收端执行display current-configuration configuration bgp命令查看BGP配置，确认是否配置邻居的出方向和入方向策略。

<sysname> display current-configuration configuration bgp

bgp 100

peer 1.1.1.1 as-number 100

peer 3.3.3.3 as-number 100

peer 3.3.3.3 connect-interface LoopBack1

address-family vpnv4

peer 3.3.3.3 enable

peer 3.3.3.3 route-policy in import

peer 3.3.3.3 route-policy out export

return

如果两端配置了出方向和入方向策略，则需要确认这些策略是否会把私网路由过滤掉，导致该路由无法正常收发。

如果两端没有配置相应的出方向和入方向策略，或者路由策略没有过滤掉私网路由，则执行步骤(4)。

(4) 检查路由是否能迭代到隧道。

在路由的接收端（远端PE）执行display bgp routing-table vpnv4 ipv4-address [ mask | mask-length ]命令查看VPNv4路由，确认VPNv4路由是否可以迭代到隧道。

如果显示信息中存在Rely tunnel IDs字段，则表示该路由可以迭代到隧道。

¡ 如果迭代不到隧道，则请参见“LDP LSP无法Up”故障进行定位。

¡ 如果迭代到隧道，则执行步骤(5)。

<sysname> display bgp routing-table vpnv4 6.0.0.9 32

BGP local router ID: 4.0.0.9

Local AS number: 200

Route distinguisher: 103:1

Total number of routes: 1

Paths: 1 available, 1 best

BGP routing table information of 6.0.0.9/32:

From : 3.0.0.9 (3.0.0.9)

Rely nexthop : 20.0.2.1

Original nexthop: 3.0.0.9

OutLabel : 24128

Ext-Community : <RT: 100:1>

RxPathID : 0x0

TxPathID : 0x0

AS-path : 300 103

Origin : igp

Attribute value : pref-val 0

State : valid, external, best

IP precedence : N/A

QoS local ID : N/A

Traffic index : N/A

Tunnel policy : tp1

Rely tunnel IDs : 2

(5) 检查是否Export RT和Import RT不匹配导致路由无法学习到私网路由表中。

在路由的发送端（本端PE）和接收端（远端PE）执行display bgp routing-table vpnv4和display current-configuration configuration vpn-instance命令，查看是否本端VPN实例的Export RT与远端VPN实例的Import RT不匹配，导致路由发送到远端PE后无法学习到远端VPN实例中。

在本端PE上执行display bgp routing-table vpnv4和display ip extcommunity-list命令查看本端VPN实例的ERT是否被过滤，导致路由无法发布。

¡ 如果Export RT和Import RT不匹配，则请在VPN实例下执行vpn-target命令配置匹配的RT值。

¡ 如果Export RT被路由策略过滤，则请在路由策略视图下执行apply extcommunity rt命令修改路由策略，取消过滤指定的RT属性。

¡ 如果Export RT和Import RT匹配，或者Export RT未被路由策略过滤，则执行步骤(6)。

查看路由携带的ERT：

<sysname> display bgp routing-table vpnv4 6.0.0.9 32

BGP local router ID: 4.0.0.9

Local AS number: 200

Route distinguisher: 103:1

Total number of routes: 1

Paths: 1 available, 1 best

BGP routing table information of 6.0.0.9/32:

From : 3.0.0.9 (3.0.0.9)

Rely nexthop : 20.0.2.1

Original nexthop: 3.0.0.9

OutLabel : 24128

Ext-Community : <RT: 100:1>

RxPathID : 0x0

TxPathID : 0x0

AS-path : 300 103

Origin : igp

Attribute value : pref-val 0

State : valid, external, best

IP precedence : N/A

QoS local ID : N/A

Traffic index : N/A

Tunnel policy : tp1

Rely tunnel IDs : 2

查看BGP扩展团体属性列表信息：

<sysname> display ip extcommunity-list 1

Extended Community List Number 10

Deny rt: 100:1

Extended Community List Number 20

Permit rt: 200:1

查看本地配置的IRT：

<sysname> display current-configuration configuration vpn-instance

ip vpn-instance vpn1

route-distinguisher 1:1

vpn-target 100:1 import-extcommunity

vpn-target 100:1 export-extcommunity

(6) 检查MPLS标签数量是否超限。

在路由发送端（本端PE）执行display mpls interface命令确认与远端PE相连的公网接口是否开启了MPLS功能。

¡ 如果显示信息中存在与远端PE相连的公网接口，则表示与远端PE相连的公网接口开启了MPLS功能。

¡ 如果显示信息中不存在与远端PE相连的公网接口，则在与远端PE相连的公网接口视图下执行mpls enable命令，开启MPLS功能。

<Sysname> display mpls interface

Interface Status MPLS MTU

GE1/0/1 Up 1500

GE1/0/2 Up 1500

使用display bgp routing-table vpnv4 advertise-info命令查看路由发送时是否申请标签。

¡ 如果显示信息中Inlabel字段无取值，则可能是由于标签资源不足，导致无法为该路由申请标签。如果是标签不足，则可以通过以下方法减少标签的使用量：

- 在VPN实例视图下执行apply-label per-instance命令配置每实例每标签。

- 通过路由聚合来减少路由数量。

- 在系统视图下执行mpls max-label命令增加设备可分配的标签数量。

¡ 如果显示信息中Inlabel字段有合理值，则表示标签资源充足，已经为该路由申请标签，请执行步骤(7)。

<Sysname> display bgp routing-table vpnv4 10.1.1.0 24 advertise-info

BGP local router ID: 1.1.1.9

Local AS number: 100

Route distinguisher: 100:1

Total number of routes: 1

Paths: 1 best

BGP routing table information of 10.1.1.0/24(TxPathID:0):

Advertised to VPN peers (1 in total):

3.3.3.9

Inlabel : 1279

(7) 检查路由数量是否超限。

执行display bgp peer vpnv4 log-info命令，查看指定对等体的日志信息。如果显示Cease/maximum number of VPNv4 prefixes reached，则表示路由数量超规格。

<Sysname> display bgp peer vpnv4 1.1.1.1 log-info

Peer : 1.1.1.1

Date Time State Notification

Error/SubError

06-Feb-2013 22:54:42 Down Send notification with error 6/1

Cease/maximum number of VPNv4 prefixes reached

如果设备上打印如下日志信息，则表示路由数量超规格。

BGP/4/BGP_EXCEED_ROUTE_LIMIT: BGP default.vpn1: The number of routes (101) from peer 1.1.1.1 (IPv4-UNC) exceeds the limit 100.

BGP/4/BGP_REACHED_THRESHOLD: BGP default.vpn1: The ratio of the number of routes (3) received from peer 1.1.1.1 (IPv4-UNC) to the number of allowed routes (2) has reached the threshold (75%).

¡ 如果路由数量超规格，则在路由接收端的VPNv4地址族视图或者VPNv6地址族视图下执行peer route-limit命令调大允许从对等体接收路由的最大数目。

¡ 如果路由数量未超规格，则执行步骤(8)。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

11.3.2 L3VPN私网路由频繁震荡

1. 故障描述

远端PE发布的私网路由在本端PE上频繁震荡。

2. 常见原因

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

· 公网路由震荡

· LDP LSP震荡

· 接口震荡

3. 故障分析

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

图67 L3VPN私网路由频繁震荡故障诊断流程图

4. 处理步骤

(1) 检查公网路由是否震荡。

a. 确认路由类型。

执行display ip routing-table命令查看路由类型。

以如下显示为例，Proto字段显示为IS_L1，表示路由类型为IS-IS；Interface字段显示为Tun1，表示部署了LDP over MPLS TE。

<Sysname> display ip routing-table 1.1.1.1

Summary count : 1

Destination/Mask Proto Pre Cost NextHop Interface

1.1.1.1/32 IS_L1 15 10 1.1.1.1 Tun1

b. 查看路由是否震荡。

根据路由类型，判断路由是否震荡。以IS-IS为例，执行display ip routing-table protocol isis命令，查看路由信息。如果路由信息一直在显示和不显示两种情况切换，则表示路由震荡。

- 如果路由震荡，请按照路由类型，参见“OSPF邻居Down”、“OSPFv3邻居Down”或“IS-IS路由震荡”故障处理，排除路由问题。

- 如果路由没有震荡，请执行步骤(2)。

(2) 检查LDP LSP是否震荡。

建议每1秒执行一次display mpls ldp peer命令，连续执行5～10次，查看显示信息的State字段。如果该字段的取值在Operational状态和其他状态之间切换，则表示LDP会话震荡，导致LDP LSP震荡。

¡ 如果LDP LSP震荡，则请参见“LDP LSP震荡”故障进行定位。

¡ 如果LDP LSP没有震荡，则执行步骤(3)。

<Sysname> display mpls ldp peer

VPN instance: public instance

Total number of peers: 1

Peer LDP ID State Role GR AUT KA Sent/Rcvd

1.1.1.1:0 Operational Active Off None 298/298

(3) 检查接口是否震荡。

执行display interface brief命令，查看Link和Protocol字段。Link和Protocol字段均显示Up，则表示接口状态为Up，否则表示接口状态为Down。若接口一直在Up和Down两种状态间切换，则表示接口震荡。

¡ 如果接口震荡，则请参见“接口不UP”故障进行定位。

¡ 如果接口没有震荡，请执行步骤(4)。

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

Brief information on interfaces in route mode:

Link: ADM - administratively down; Stby - standby

Protocol: (s) – spoofing

Interface Link Protocol Primary IP Description

GE1/0/1 UP UP --

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

11.3.3 PE间无法交换VPN路由

1. 故障描述

PE间无法交换VPNv4或VPNv6路由。

2. 常见原因

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

· 公网IGP路由未发布

· 公网LSP不存在

· BGP对等体未建立

· 未学习到VPNv4或VPNv6路由

3. 故障分析

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

图68 PE间无法交换私网路由故障诊断流程图

4. 处理步骤

(1) 检查IGP路由是否存在。

执行display ip routing-table命令，查看是否存在到达对端PE的Loopback接口的网段路由：

<Sysname> display ip routing-table 1.1.1.1

Summary count : 1

Destination/Mask Proto Pre Cost NextHop Interface

1.1.1.2/32 IS_L1 15 10 1.1.1.1 LoopBack1

¡ 如果不存在，则在Loopback接口和公网接口下使能IGP协议，确保发布对应网段路由。

¡ 如果存在，则执行步骤(2)。

(2) 检查公网LSP是否存在。

执行display mpls lsp命令，查看是否存在到达远端PE的Loopback接口的公网LSP：

¡ 如果不存在，则在公网接口下使能MPLS功能和MPLS LDP功能，确保建立公网LSP。

¡ 如果存在，则执行步骤(3)。

<Sysname> display mpls lsp

FEC Proto In/Out Label Out Inter/NHLFE/LSINDEX

1.1.1.2/32 LDP -/1049 GE1/0/1

<Sysname> display mpls lsp

FEC Proto In/Out Label Out Inter/NHLFE/LSINDEX

1.1.1.1/24 LDP -/1051 GE1/0/1

执行display mpls ldp peer verbose命令，查看LDP会话是否成功建立：

¡ 如果State字段显示不是Operational，则表示LDP会话没有正常建立，请参见“LDP会话无法Up”故障进行定位。

¡ 如果State字段的显示为Operational，则表示LDP会话已建立并处于Up状态，请执行步骤(3)。

<Sysname> display mpls ldp peer verbose

VPN instance: public instance

Peer LDP ID : 1.1.1.1:0

Local LDP ID : 2.2.2.2:0

TCP Connection : 2.2.2.2:14080 -> 1.1.1.1:646

Session State : Operational Session Role : Active

Session Up Time : 0000:00:14 (DD:HH:MM)

…

(3) 检查BGP对等体关系是否建立。

执行display bgp peer vpnv4命令，查看PE之间BGP VPNv4对等体关系，并执行display bgp peer ipv4 vpn-instance命令，查看PE与CE之间BGP对等体关系：

¡ 如果不存在BGP对等体关系，或者State字段显示不是Established，则表示未建立BGP对等体关系，请参见“BGP邻居无法建立”故障进行定位。

¡ 如果State字段的显示为Established，则表示已建立BGP对等体关系，请执行步骤(4)。

<Sysname> display bgp peer vpnv4

BGP local router ID: 192.168.100.1

Local AS number: 100

Total number of peers: 1 Peers in established state: 1

* - Dynamically created peer

Peer AS MsgRcvd MsgSent OutQ PrefRcv Up/Down State

1.1.1.2 200 13 16 0 0 00:10:34 Established

<Sysname> display bgp peer ipv4 vpn-instance vpn1

BGP local router ID: 1.1.1.1

Local AS number: 100

Total number of peers: 1 Peers in established state: 1

* - Dynamically created peer

Peer AS MsgRcvd MsgSent OutQ PrefRcv Up/Down State

10.1.1.1 65410 5 4 0 1 00:01:19 Established

(4) 检查私网路由是否正常。

执行display ip routing-table vpn-instance命令，查看私网路由：

¡ 如果私网路由的掩码不是32位，且发现该路由的协议不是BGP协议，则表示两端PE的Loopback接口的IP地址在同一网段，设备将优选直连路由，而不是私网路由。请修改PE上的Loopback接口的IP地址，将掩码修改为为32位。

¡ 如果私网路由的掩码是32位，且发现该路由的协议是BGP协议，则私网路由正常，请执行步骤(5)。

<Sysname> display ip routing-table vpn-instance vpn1

Summary count : 1

Destination/Mask Proto Pre Cost NextHop Interface

1.1.1.0/24 Direct 0 0 1.1.1.1 LoopBack1

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

11.3.4 配置相同RT的不同VPN之间不能互通

1. 故障描述

在图69的网络中，配置MPLS L3VPN业务，CE 1与CE 3属于VPN 1，CE 2属于VPN 2。由于业务的需求，在VPN 1和VPN 2上配置了相同的Route Target，以实现不同VPN间互通。

配置完成后，发现CE 1可以Ping通相同VPN的CE 3（IP地址为3.3.3.3），但CE 2无法Ping通不同VPN的3.3.3.3。

图69 MPLS L3VPN组网图

2. 常见原因

本场景中，CE 1可以Ping通相同VPN的CE 3，说明MPLS骨干网中进行标签转发的公网隧道正常，本类故障的常见原因仅包括：PE设备上不同的VPN实例绑定的IP地址存在冲突。

3. 故障分析

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

图70 配置相同RT的不同VPN之间不能互通的故障诊断流程图

4. 处理步骤

(1) 检查PE的接口IP是否存在冲突。

在PE 1上执行display ip interface brief命令查看接口的IP地址，例如：

<Sysname> display ip interface brief

*down: administratively down

(s): spoofing (l): loopback

Interface Physical Protocol IP Address/Mask VPN instance Description

...

GE1/0/1 up up 10.1.1.1/24 vpn1 --

GE1/0/2 up up 10.1.1.1/24 vpn2 --

...

如果不同VPN实例的接口IP地址不相同，请执行步骤（2）。

如果不同VPN实例的接口IP相同，则修改其中一个VPN实例中PE上的接口以及与其相连的CE上的接口的IP地址，并重新配置PE设备与CE设备间的路由交换。

由于BGP会将RT匹配的路由在VPN实例间进行互引，为不同VPN的接口设置相同IP地址时，同一目的地址的路由在BGP路由表中将会出现两条，而BGP只会优选其中一条，例如：

<Sysname> display bgp routing-table vpnv4

BGP local router ID is 11.11.11.11

Status codes: * - valid, > - best, d - dampened, h - history,

s - suppressed, S - stale, i - internal, e - external

a - additional-path

Origin: i - IGP, e - EGP, ? - incomplete

Total number of VPN routes: 11

Total number of routes from all PEs: 2

Route distinguisher: 1:1(vpn1)

Total number of routes: 6

Network NextHop MED LocPrf PrefVal Path/Ogn

* >e 1.1.1.1/32 10.1.1.2 0 0 20i

* >e 2.2.2.2/32 10.1.1.2 0 0 30i

* >i 3.3.3.3/32 22.22.22.22 0 100 0 40i

* >e 10.1.1.0/24 10.1.1.2 0 0 20?

* >i 30.1.1.0/24 22.22.22.22 0 100 0 40?

Route distinguisher: 2:2(vpn2)

Total number of routes: 5

Network NextHop MED LocPrf PrefVal Path/Ogn

* >e 1.1.1.1/32 10.1.1.2 0 0 20i

* >e 2.2.2.2/32 10.1.1.2 0 0 30i

* >i 3.3.3.3/32 22.22.22.22 0 100 0 40i

* >e 10.1.1.0/24 10.1.1.2 0 0 20?

* e 10.1.1.2 0 0 30?

* >i 30.1.1.0/24 22.22.22.22 0 100 0 40?

如上所示，在RD为2:2的VPN实例（即VPN 2）BGP路由表中，优选的10.1.1.0网段的路由来自VPN 1（根据AS_PATH属性判断），VPN 2发布的路由未被优选，所以从VPN 1去往VPN 2的流量不会被PE 1从GigabitEthernet1/0/2接口发送给VPN 2，而是从GigabitEthernet1/0/1接口发送给VPN 1，导致跨VPN通信失败。

所以，将关联了VPN实例的接口以及与其相连的CE上的接口修改为不同的IP地址，可以解决这类问题。以PE-CE间通过EBGP会话交互路由为例，PE 1的处理步骤如下：

a. 在系统视图下，执行interface命令进入关联了VPN实例的接口视图。

b. 执行ip address命令修改接口的IP地址。

c. 在系统视图下，执行bgp命令进入BGP实例视图。

d. 执行ip vpn-instance命令进入BGP-VPN实例视图。

e. 执行undo peer命令删除用原冲突IP地址建立的BGP对等体。

f. 执行peer as-number命令，指定使用新IP地址的CE设备为EBGP对等体。

g. 执行address-family ipv4 unicast命令，进入BGP IPv4单播地址族视图。

h. 执行peer enable命令，使能与CE设备交互BGP IPv4单播路由信息的能力。

假设仅修改了VPN 2的IP地址，则CE 2的处理步骤如下：

a. 在系统视图下，执行interface命令进入与PE 1直连的接口视图。

b. 执行ip address命令修改接口的IP地址。

c. 在系统视图下，执行bgp命令进入BGP实例视图。

d. 执行undo peer命令删除用原冲突IP地址建立的BGP对等体。

e. 执行peer as-number命令，指定使用新IP地址的PE设备为EBGP对等体。

f. 执行address-family ipv4 unicast命令，进入BGP IPv4单播地址族视图。

g. 执行peer enable命令，使能与PE设备交互BGP IPv4单播路由信息的能力。

h. 执行import-route命令或network命令，发布VPN实例的路由信息。

如果故障仍然未能排除，请执行步骤（2）。

(2) 请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

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

5. 告警与日志

11.3.5 路由反射器进行VPN-Target过滤导致PE无法学习到路由

1. 故障描述

PE设备发布的MVPN路由、VPNv4/VPNv6路由、BGP L2VPN信息、VPN Flowspec路由以及EVPN路由无法通过路由反射器反射给远端PE。

2. 常见原因

路由反射器缺省会对MVPN路由、VPNv4/VPNv6路由、BGP L2VPN信息、VPN Flowspec路由以及EVPN路由进行VPN-Target过滤，即只将Export Route Target属性与本地Import Route Target属性匹配的路由信息加入到路由表。路由反射器上不存在与接收路由匹配的Route Target时，接收到的路由将被丢弃，导致无法转发该路由信息给远端PE。

3. 故障分析

关闭路由反射器的VPN-Target过滤功能，可以解决本类故障，本故障的处理流程如图71所示。

图71 路由反射器进行VPN-Target过滤导致PE无法学习到路由故障处理流程

4. 处理步骤

(1) 检查对应地址族配置，确保配置了undo policy vpn-target命令：

a. 在BGP实例视图下，执行display this命令，查看在各地址族视图下是否存在undo policy vpn-target配置。如果不存在，请执行步骤b；如果存在，请执行步骤（2）。

b. 进入相应的地址族视图，通过undo policy vpn-target命令关闭VPN-Target过滤，使得路由反射器可以转发RT不匹配的路由信息。如果故障仍不能排除，请执行步骤（2）。

(2) 请收集如下信息，并联系技术支持人员。

¡ 上述步骤的执行结果。

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

5. 告警与日志

11.3.6 PE的私网IP路由表中没有远端PE发布的路由

1. 故障描述

在MPLS L3VPN/IPv6 MPLS L3VPN网络中，PE的VPN实例IP路由表中没有远端PE用户站点的私网路由，导致CE间无法互通。

2. 常见原因

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

· 与远端PE的BGP会话未进入Established状态。

· 远端PE未发送私网路由。

· 公网隧道未建立。

· 远端PE发送的私网路由被本端丢弃。

· 远端PE发送的私网路由在本端的BGP路由表中，但未被添加到VPN实例的IP路由表中。

3. 故障分析

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

图72 PE的私网IP路由表中没有远端PE发布的路由故障诊断流程图

4. 处理步骤

(1) 检查BGP邻居是否建立。

执行display bgp peer vpnv4或display bgp peer vpnv6命令，查看本端PE与远端PE是否建立起了处于Established状态的BGP会话，例如：

<Sysname> display bgp peer vpnv4

BGP local router ID: 11.11.11.11

Local AS number: 10

Total number of peers: 1 Peers in established state: 1

* - Dynamically created peer

Peer AS MsgRcvd MsgSent OutQ PrefRcv Up/Down State

22.22.22.22 10 82 69 0 2 01:01:28 Established

¡ 如果已经建立，请执行步骤（3）。

¡ 如果未建立，请参见“三层技术-IP路由类故障处理”手册中的“BGP会话无法进入Established状态”进行定位。BGP会话进入Established状态后，如果故障仍未能排除，请执行步骤（2）。

(2) 查看远端PE是否向本端发布了私网路由信息。

在远端PE上执行display bgp routing-table vpnv4 peer advertised-routes或display bgp routing-table vpnv6 peer advertised-routes命令，查看远端PE是否将私网路由信息发布给本端PE，例如：

<Sysname> display bgp routing-table vpnv4 peer 22.22.22.22 advertised-routes

Total number of routes: 6

BGP local router ID is 11.11.11.11

Status codes: * - valid, > - best, d - dampened, h - history,

s - suppressed, S - stale, i - internal, e - external

a - additional-path

Origin: i - IGP, e - EGP, ? - incomplete

Route distinguisher: 1:1

Total number of routes: 3

Network NextHop MED LocPrf Path/Ogn

* >e 1.1.1.1/32 10.1.1.2 0 100 20i

* >e 7.7.7.7/32 10.1.1.2 0 100 20?

* >e 10.1.1.0/24 10.1.1.2 0 100 20?

Route distinguisher: 2:2

Total number of routes: 3

Network NextHop MED LocPrf Path/Ogn

* >e 2.2.2.2/32 10.1.1.2 0 100 30i

* >e 7.7.7.7/32 10.1.1.2 0 100 30?

* >e 10.1.1.0/24 10.1.1.2 0 100 30?

如果存在这样的信息，请执行步骤（3），如果不存在，则进行如下检查：

a. 在远端PE上执行display bgp routing-table vpnv4或display bgp routing-table vpnv6命令，查看是否存在想要发布的私网路由。

- 如果存在，请执行步骤b。

- 如果不存在，则检查PE-CE间的配置。PE与CE间可以使用多种协议交互路由信息，包括静态路由、RIP、OSPF、OSPFv3、IS-IS、BGP等。关于BGP路由协议故障处理方法，请参见“三层技术-IP路由类故障处理手册”中的“BGP故障处理”；常见的IGP路由协议故障处理方法，请参见“三层技术-IP路由类故障处理”手册中的“OSPF故障处理”、“OSPFv3故障处理”或“IS-IS故障处理”。远端PE的BGP路由表获得了私网路由后，如果故障仍不能排除，请执行步骤b。

b. 在远端PE的BGP VPNv4地址族视图或者BGP VPNv6地址族视图下执行display this命令，查看是否存在发布策略过滤了私网路由信息导致无法发布，可能造成影响的配置命令有：

- peer prefix-list export

- peer filter-policy export

- peer as-path-acl export

- filter-policy export

- peer route-policy export

可以通过执行上述命令的undo形式命令来取消对私网路由信息发布的过滤，为了避免组网中的其他配置受到影响，请在技术支持人员的引导下修改私网路由信息发布的过滤策略。

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

(3) 查看公网隧道是否建立。

MPLS L3VPN的公网隧道可以是LSP隧道、MPLS TE隧道和GRE隧道。当公网隧道为LSP隧道或MPLS TE隧道时，公网标记为MPLS标签，称为公网标签；当公网隧道为GRE隧道时，公网标记为GRE封装。

常见的公网隧道建立方式是使用LDP标签分发协议自动建立标签转发路径，本故障处理流程以该方式为例，介绍建立公网隧道的故障排查方法。其他方式的公网隧道请参见相应的故障处理手册或寻求技术支持人员的帮助进行排查。

在私网路由发布的骨干网路径上，为所有设备执行display mpls ldp peer命令，查看是否与LDP对等体成功建立了会话，例如：

<Sysname> display mpls ldp peer

VPN instance: public instance

Total number of peers: 2

Peer LDP ID State Role GR AUT KA Sent/Rcvd

22.22.22.22:0 Operational Passive Off None 1816/1816

11.11.11.11:0 Operational Passive Off None 1816/1816

如果已经成功建立了会话，请执行步骤（4）。

如果未建立LDP会话，请参见“MPLS类故障处理手册”中的“LDP会话Down的定位思路”进行排查。

如果公网隧道建立后，故障仍不能排除，请执行步骤（4）。

(4) 检查本端PE的BGP路由表中是否存在对端PE发布的私网路由。

在本端PE上执行display bgp routing-table vpnv4或display bgp routing-table vpnv6命令，查看是否存在远端PE发布的私网路由。

如果不存在，则执行如下操作：

a. 在本端PE和远端PE上，均执行display ip vpn-instance instance-name命令，查看本端PE的VPN实例的Import VPN Targets与远端PE的Export VPN Targets是否一致，显示信息举例如下。

<Sysname> display ip vpn-instance instance-name vpn1

VPN-Instance Name and Index : vpn1, 1

Route Distinguisher : 1:1

Interfaces : GigabitEthernet1/0/1

TTL mode: pipe

Address-family IPv4:

Export VPN Targets :

1:1

Import VPN Targets :

1:1

- 如果不一致，则需要在本端或者远端PE的VPN实例视图下通过vpn-target命令，将RT修改为匹配的值。修改RT后，如果本端PE的BGP路由表中仍未存在对端PE发布的私网路由，请执行步骤b；如果本端PE的BGP路由表中已经存在对端PE发布的私网路由，但故障仍不能排除，请执行步骤（5）。

- 如果一致，请执行步骤b。

b. 通过在BGP实例视图下执行display this命令，查看是否存在接收策略过滤了私网路由信息导致无法接收，可能造成影响的配置命令有：

- peer prefix-list import

- peer filter-policy import

- peer as-path-acl import

- filter-policy import

- peer route-policy import

可以通过执行上述命令的undo形式命令来取消对私网路由信息接收的过滤，为了避免组网中的其他配置受到影响，请在技术支持人员的引导下修改私网路由信息接收的过滤策略。

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

(5) 检查BGP路由添加到VPN实例IP路由表的受阻原因。可能的原因有：

¡ 设备配置了undo policy vpn-target命令，与当前VPN实例Route Target属性不匹配的VPNv4/VPNv6路由可以添加到VPN实例的BGP路由表中，并能够在BGP路由表中被优选，但是这些路由无法添加到当前VPN实例的IP路由表中。在BGP实例视图下执行display this命令，查看配置了undo policy vpn-target命令的地址族，进入该地址族视图，并执行policy vpn-target命令，可以解决此问题。

¡ 设备配置了routing-table bgp-rib-only命令，,禁止BGP路由下发到IP路由表中。在BGP实例视图下执行display this命令，查看配置了routing-table bgp-rib-only命令的地址族，进入该地址族视图，并执行undo routing-table bgp-rib-only命令，可以解决此问题。

如果故障仍未能排除，请执行步骤（6）。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

11.3.7 私网间大包不通

1. 故障描述

MPLS L3VPN/IPv6 MPLS L3VPN网络中同时存在我司设备和其他厂商设备，用户访问跨站点的私网资源时，不能打开部分网站，也不能通过FTP下载文件。执行ping命令检验发现，在指定ICMP报文的净荷为1464字节以上时Ping不通，指定ICMP报文的净荷小于1464字节时，可以Ping通。

2. 常见原因

本类故障的常见原因主要为：流量转发路径上设备接口的MTU值过小。

3. 故障分析

本故障的处理流程如图73所示。

图73 私网间大包不通故障诊断流程图

4. 操作步骤

(1) 在流量转发路径上，将设备接口的MTU值修改为大于或等于1508字节。

¡ 在我司设备上，可通过display interface命令查看接口的MTU。例如：

<Sysname> display interface gigabitethernet 1/0/1

GigabitEthernet1/0/1

Current state: Administratively UP

Line protocol state: UP

Description: GigabitEthernet1/0/1 Interface

Bandwidth: 1000000 kbps

Maximum transmission unit: 1500

...

需要修改接口的MTU值时，请在该接口视图下执行ip mtu或ipv6 mtu命令。

¡ 其他厂商的设备配置请参考相关的资料。

如果故障仍未能排除，请执行步骤（2）。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

11.3.8 PE设备Ping不通远端CE网段

1. 故障描述

如图74所示，在IPv6 MPLS L3VPN网络中，PE 1上配置了多个接口关联同一个VPN实例VPN 1。在CE 1和CE 2上执行ping ipv6 2001:db8:3::1命令，均能Ping通远端的CE 3网段，但在PE 1上执行ping ipv6 –vpn-instance vpn1 2001:db8:3::1命令时，Ping不同CE 3网段。

图74 IPv6 MPLS L3VPN 组网图

2. 常见原因

本类故障的常见原因主要为：CE 3上没有到达PE 1所有私网IPv6地址的路由。私网IPv6地址的范围是，PE 1上与CE 3相同的VPN实例中，所有处于UP状态的接口的IPv6地址。

3. 故障分析

本故障的处理流程如图75所示。

图75 PE设备Ping不同远端CE网段故障诊断流程图

4. 操作步骤

(1) 检查CE 3上是否存在到达PE 1所有私网IPv6地址的路由。

PE 1在Ping远端CE网段时，会使用当前设备上指定VPN实例中所有处于UP状态的接口的IPv6地址中，最小的IPv6地址作为ICMPv6报文的源地址，如果CE 3没有该IPv6地址的路由信息，将会导致ICMPv6报文无法返回。

上述问题可以通过以下方法解决：

¡ 在PE 1上配置发布本设备的所有私网路由，例如，在BGP-VPN IPv6单播地址族视图下，配置import-route direct命令。

¡ 执行Ping操作时，指定ICMPv6回显请求报文中的源IPv6地址为CE 3的IPv6路由表中存在的地址，即执行ping ipv6 –a source-ipv6 -vpn-instance vpn-instance-name host命令。

如果故障仍不能排除，请执行步骤（2）。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

11.4 MPLS TE故障处理

11.4.1 MPLS TE隧道状态为Down

1. 故障描述

完成MPLS TE隧道创建后，通过display interface tunnel命令查看到MPLS TE隧道的当前状态为DOWN。

<Sysname> display interface tunnel 1

Tunnel1

Current state: DOWN

Line protocol state: DOWN

Description: Tunnel1 Interface

Bandwidth: 64kbps

Maximum transmission unit: 1496

Internet address: 7.1.1.1/24 (primary)

Tunnel source unknown, destination 4.4.4.9

Tunnel TTL 255

Tunnel protocol/transport CR_LSP

Last clearing of counters: Never

Last 300 seconds input rate: 0 bytes/sec, 0 bits/sec, 0 packets/sec

Last 300 seconds output rate: 6 bytes/sec, 48 bits/sec, 0 packets/sec

Input: 0 packets, 0 bytes, 0 drops

Output: 177 packets, 11428 bytes, 0 drops

2. 常见原因

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

· MPLS TE隧道所在的链路Down。

· MPLS TE配置错误。

· MPLS TE隧道的目的地址被静态路由引用。

3. 故障分析

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

图76 MPLS TE隧道状态为Down的故障诊断流程图

4. 处理步骤

(1) 查看MPLS TE隧道对应的接口是否为Up状态。

执行display interface命令，查看MPLS TE隧道对应的接口否为Up状态。

(2) 检查MPLS TE配置。

依次检查如下配置：

a. OSPF/IS-IS区域和MPLS TE隧道经过的接口下是否配置mpls te enable命令。

b. LSR ID、Router ID是否为同一LoopBack接口的地址。

c. 若使用RSVP-TE协议建立MPLS TE隧道，则需要检查设备和接口是否配置了rsvp、rsvp enable命令。

d. 若隧道接口下配置了mpls te bandwidth命令，检查设备出接口是否配置了mpls te max-link-bandwidth以及mpls te max-reservable-bandwidth命令。

e. 若隧道接口下配置了mpls te affinity-attribute命令，检查设备出接口是否配置合理的mpls te link-attribute命令。如果希望某条链路能够被隧道所用，则需要满足如下要求：

- 对于隧道亲和属性掩码为1的位，亲和属性为1的位中链路属性至少有1位也为1，亲和属性为0的位对应的链路属性位不能为1。

- 对于隧道亲和属性掩码为0的位，不对链路属性的相应位进行检查。

f. 若使用Segment Routing协议建立MPLS TE隧道，则需要检查设备IGP区域下是否配置了Segment-Routing相关功能。

g. 若使用mpls te path命令指定显式路径来建立MPLS TE隧道，则需要检查显式路径配置是否合理：使用strict方式时，需要逐跳指定入接口的IP地址；使用loose方式时，需要指定经过的设备的节点地址。

(3) 查看MPLS TE隧道的目的地址是否被静态引用。

执行display current-configuration | include destination命令，查看MPLS TE隧道的目的地址是否被静态引用。如果被静态路由引用，则需要根据用户的实际组网需求修改静态路由或者隧道的目的地址。

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

¡ 上述步骤的执行结果。

¡ 设备的配置文件。

¡ 使用display diagnostic-information命令收集诊断信息。

5. 告警与日志

11.4.2 MPLS TE隧道由UP状态变为Down状态

1. 故障描述

MPLS TE隧道由UP状态变为Down状态。

2. 常见原因

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

· MPLS TE隧道所在的链路Down。

· MPLS TE隧道的配置被删除或配置错误。

· RSVP消息超时或错误。

· 物理链路不满足MPLS TE隧道所需的带宽。

· MPLS TE隧道或隧道所在物理接口BFD down。

3. 故障分析

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

图77 MPLS TE隧道由UP状态突然变为Down状态的故障诊断流程图

4. 处理步骤

(1) 查看MPLS TE隧道对应的接口是否为Up状态。

执行display interface命令，查看MPLS TE隧道对应的接口否为Up状态。

(2) 检查MPLS TE配置。

依次检查如下配置：

a. OSPF/IS-IS区域和MPLS TE隧道经过的接口下是否配置mpls te enable命令。

b. LSR ID、Router ID是否为同一LoopBack接口的地址。

c. 若使用RSVP-TE协议建立MPLS TE隧道，则需要检查设备和接口是否配置了rsvp、rsvp enable命令。

d. 若隧道接口下配置了mpls te bandwidth命令，检查设备出接口是否配置了mpls te max-link bandwidth以及mpls te max-reservable bandwidth命令。

- 对于隧道亲和属性掩码为1的位，亲和属性为1的位中链路属性至少有1位也为1，亲和属性为0的位对应的链路属性位不能为1。

- 对于隧道亲和属性掩码为0的位，不对链路属性的相应位进行检查。

f. 若使用Segment Routing协议建立MPLS TE隧道，则需要检查设备IGP区域下是否配置了Segment-Routing相关功能。

(3) 检查是否存在RSVP消息超时或错误。

通过display rsvp statistics命令查看是否存在RSVP消息超时（即发送的Path消息和收到的Resv消息个数不一致、收到的Path消息和发送的Resv消息个数不一致）或RSVP消息错误（即收到PathError消息或ResvError消息）的问题。若存在RSVP消息超时或错误，请抓包查看PathError消息或ResvError报文携带的错误信息，并根据报文携带的错误码，参照RFC 2205和RFC 3209解决问题。

<Sysname> display rsvp statistics

P2P statistics:

Object Added Deleted

PSB 3 1

RSB 3 1

LSP 3 1

P2MP statistics:

Object Added Deleted

PSB 0 0

RSB 0 0

LSP 0 0

Packet Received Sent

Path 5 5

Resv 5 5

PathError 0 0

ResvError 0 0

PathTear 0 0

ResvTear 0 0

ResvConf 0 0

Bundle 0 0

Ack 0 0

Srefresh 0 0

Hello 0 0

Challenge 0 0

Response 0 0

Error 0 0

(4) 检查物理链路是否满足MPLS TE隧道所需的带宽。

当设备上建立了更高优先级的MPLS TE隧道时，该隧道可能会抢占低优先级MPLS TE隧道的带宽，导致低优先级MPLS TE隧道的状态变为down。通过display mpls te link-management bandwidth-allocation命令查看链路上各个优先级的剩余可用带宽，确保链路剩余可用带宽大于该优先级的隧道所需的带宽。如果链路上的剩余可用带宽不能满足MPLS TE隧道的需求，则需要修改配置，调整隧道路径，或为链路提供更大的带宽。

(5) 检查MPLS TE隧道或隧道所在物理接口是否BFD down。

通过display mpls bfd te tunnel tunnel-number命令查看MPLS TE隧道的BFD状态。若MPLS TE隧道的BFD状态为down，则需要通过display bfd session命令查看BFD状态为down的原因，检查并修改BFD配置或检查物理链路是否存在链路故障、链路质量问题。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

11.4.3 MPLS TE隧道存在环路

1. 故障描述

MPLS TE隧道的转发路径上存在环路，导致流量无法通过MPLS TE隧道转发到目的地址。

2. 常见原因

MPLS TE隧道经过的不同设备上存在相同的IP地址。

3. 处理步骤

(1) 请检查MPLS TE隧道经过的不同设备上是否配置了相同的IP地址。若存在相同的IP地址，则需要修改IP地址，保证MPLS TE隧道经过的不同设备上不存在相同的IP地址。

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

¡ 上述步骤的执行结果。

¡ 设备的配置文件。

¡ 使用display diagnostic-information命令收集诊断信息。

4. 告警与日志

11.4.4 Tunnel路径计算失败

1. 故障描述

MPLS TE隧道路径计算失败，导致隧道DOWN。

2. 常见原因

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

· 没有建立IGP邻居。

· 没有MPLS TEDB信息。

· MPLS TE配置错误。

3. 故障分析

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

图78 Tunnel路径计算失败的故障诊断流程图

4. 处理步骤

(1) 查看是否建立了IGP邻居。

执行display ospf peer和display isis peer命令，查看是否建立了IGP邻居。

¡ 若建立了IGP邻居，请继续执行第(2)步。

¡ 若没有建立了IGP邻居，请先完成OSPF或IS-IS配置，建立IGP邻居。OSPF的详细介绍，请参见“三层技术-IP路由”中的“OSPF”；IS-IS的详细介绍，请参见“三层技术-IP路由”中的“IS-IS”。

(2) 执行display mpls te tedb命令，查看MPLS TEDB信息。

若存在MPLS TEDB信息，请继续执行第(3)步。

若不存在MPLS TEDB信息，请依次检查如下配置：

a. OSPF/IS-IS区域和MPLS TE隧道经过的接口下是否配置mpls enable、mpls te enable命令。

b. LSR ID、Router ID是否为同一LoopBack接口的地址。

(3) 检查MPLS TE配置。

a. 若使用RSVP-TE协议建立MPLS TE隧道，则需要检查设备和接口是否配置了rsvp、rsvp enable命令。

b. 若使用Segment Routing协议建立MPLS TE隧道，则需要检查设备IGP区域下是否配置了segment-routing mpls命令。

c. 若隧道接口下配置了mpls te bandwidth命令，检查设备出接口是否配置了mpls te max-link-bandwidth以及mpls te max-reservable-bandwidth命令。

d. 若隧道接口下配置了mpls te affinity-attribute命令，检查设备出接口是否配置合理的mpls te link-attribute命令。如果希望某条链路能够被隧道所用，则需要满足如下要求：

- 对于隧道亲和属性掩码为1的位，亲和属性为1的位中链路属性至少有1位也为1，亲和属性为0的位对应的链路属性位不能为1。

- 对于隧道亲和属性掩码为0的位，链路属性可以是任意值。

e. 若使用mpls te path命令指定显式路径来建立MPLS TE隧道，则需要检查显式路径配置是否合理：使用strict方式时，需要逐跳指定入接口的IP地址；使用loose方式时，需要指定经过的设备的节点地址。

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

¡ 上述步骤的执行结果。

¡ 设备的配置文件。

¡ 使用display diagnostic-information命令收集诊断信息。

5. 告警与日志

11.4.5 热备份CRLSP无法建立

1. 故障描述

MPLS TE隧道下配置mpls te backup hot-standby命令，但是无法建立备份CRLSP。

2. 常见原因

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

· 只存在一个与邻居相邻的接口。

· MPLS TE配置错误。

3. 故障分析

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

图79 热备份CRLSP无法建立的故障诊断流程图

4. 处理步骤

(1) 根据配置的IGP协议，执行display ospf peer或display isis peer命令，查看与同一邻居（同一System ID或同一Router ID）相连的接口信息（interface）。

# 显示IS-IS邻居的概要信息。

<Sysname> display isis peer

Peer information for IS-IS(1)

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

System ID: 0000.0000.0001

Interface: GE1/0/1 Circuit Id: 0000.0000.0001.01

State: Up HoldTime: 27s Type: L1(L1L2) PRI: 64

System ID: 0000.0000.0001

Interface: GE1/0/2 Circuit Id: 0000.0000.0001.01

State: Up HoldTime: 27s Type: L2(L1L2) PRI: 64

# 显示OSPF邻居概要信息。

<Sysname> display ospf peer

OSPF Process 1 with Router ID 1.1.1.1

Neighbor Brief Information

Area: 0.0.0.0

Router ID Address Pri Dead-Time State Interface

1.1.1.2 1.1.1.2 1 40 Full/DR GE1/0/1

¡ 若与邻居相连的接口数量≥2，请继续执行第(2)步。

¡ 若与邻居相连的接口数量＜2，请增加与邻居之间的物理链路，确保存在可以建立备份CRLSP的路径。

(2) 检查MPLS TE配置。

依次检查如下配置：

a. OSPF/IS-IS区域和MPLS TE隧道经过的接口下是否配置mpls te enable命令。

b. LSR ID、Router ID是否为同一LoopBack接口的地址。

c. 若使用RSVP-TE协议建立MPLS TE隧道，则需要检查设备和接口是否配置了rsvp、rsvp enable命令。

d. 若隧道接口下配置了mpls te bandwidth命令，检查设备出接口是否配置了mpls te max-link-bandwidth以及mpls te max-reservable-bandwidth命令。

- 对于隧道亲和属性掩码为1的位，亲和属性为1的位中链路属性至少有1位也为1，亲和属性为0的位对应的链路属性位不能为1。

- 对于隧道亲和属性掩码为0的位，链路属性可以是任意值。

f. 若使用Segment Routing协议建立MPLS TE隧道，则需要检查设备IGP区域下是否配置了segment-routing mpls命令。

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

¡ 上述步骤的执行结果。

¡ 设备的配置文件。

¡ 使用display diagnostic-information命令收集诊断信息。

5. 告警与日志

11.5 MPLS基础故障处理

11.5.1 报文通过LSP隧道转发不通

1. 故障描述

网络中主机的发送报文，通过LSP隧道转发不通。

2. 常见原因

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

· 路由不存在。

· LSP不存在。

· 路由未迭代到LSP隧道上。

· LSP隧道的转发状态非ACTIVE。

· BFD会话状态为Down。

· CPU利用率过高。

3. 故障分析

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

图80 报文通过LSP隧道转发不通的故障诊断流程图

4. 处理步骤

(1) 检查IGP路由是否存在。

执行display ip routing-table命令，查看是否存在到达目的节点的Loopback接口地址的网段路由：

<Sysname> display ip routing-table 1.1.1.1

Summary count : 1

Destination/Mask Proto Pre Cost NextHop Interface

1.1.1.2/32 IS_L1 15 10 1.1.1.1 LoopBack1

¡ 如果不存在，则在Loopback接口和公网接口下使能IGP协议，确保发布对应网段路由。

¡ 如果存在，则执行步骤(2)。

(2) 检查LSP是否存在。

执行display mpls lsp命令，查看是否存在到达目的节点的Loopback接口的LSP：

¡ 如果不存在，则确保建立指定类型的LSP：

- 对于LDP LSP，请在接口下使能MPLS功能和MPLS LDP功能。

- 对于SRLSP，请在IS-IS IPv4单播地址族视图、OSPF视图或BGP IPv4单播地址族视图下执行segment-routing mpls命令用来开启基于MPLS的SR功能。

- 对于SR-MPLS TE Policy，请在SR-TE视图下创建正确的SR-MPLS TE Policy。

¡ 如果存在，则执行步骤(3)。

<Sysname> display mpls lsp

FEC Proto In/Out Label Out Inter/NHLFE/LSINDEX

1.1.1.2/32 LDP -/1049 GE1/0/1

(3) 检查路由是否迭代到LSP隧道上。

执行display mpls tunnel all命令，查看所有隧道的信息。执行display fib命令，查看指定下一跳地址的FIB表项。对于FIB表项中Nexthop字段与隧道信息中Destination字段相同值的FIB表项，检查该FIB表项的LSP索引号（Token字段）与隧道的NHLFE ID是否相同。

¡ 如果不同，则表示未迭代到LSP隧道上，确认指定FEC的隧道类型（Type字段）与配置的隧道策略是否相同：

- 如果不同，则在隧道策略视图下修改隧道策略，使配置的隧道策略与指定FEC的隧道类型匹配。

- 如果相同，则执行步骤(7)。

<Sysname> display tunnel-policy

Tunnel policy name: abc

Select-Seq: LSP

Load balance number : 1

Strict : No

¡ 如果相同，则表示迭代到LSP隧道上，请执行步骤(4)。

<Sysname> display mpls tunnel all

Destination Type Tunnel/NHLFE VPN Instance

2.2.2.9 LSP NHLFE3 -

3.3.3.9 SRLSP NHLFE2 -

4.4.4.9 SRPolicy NHLFE23068673 -

<Sysname> display fib

Destination count: 1 FIB entry count: 1

Flag:

U:Usable G:Gateway H:Host B:Blackhole D:Dynamic S:Static

R:Relay F:FRR

Destination/Mask Nexthop Flag OutInterface/Token Label

55.55.55.55/32 2.2.2.9 UGHR 3 Null

…

(4) 检查LSP隧道的转发状态是否正常。

执行display mpls forwarding nhlfe命令，查看指定NHLFE表项信息。

¡ 如果转发标记中没有A标记，则表示该LSP隧道无法使用，请执行步骤(5)。

¡ 如果转发标记中有A标记，则表示该LSP隧道可以正常使用，请执行步骤(6)。

<Sysname> display mpls forwarding nhlfe 3

Flags: T - Forwarded through a tunnel

N - Forwarded through the outgoing interface to the nexthop IP address

B - Backup forwarding information

A - Active forwarding information

M - P2MP forwarding information

S - Secondary backup path

NID Tnl-Type Flag OutLabel Forwarding Info

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

3 LSP NA 1040127 GE1/0/3 10.0.3.2

(5) 检查BFD状态是否正常。

执行display mpls bfd命令或display mpls sbfd命令，查看LSP隧道的BFD/SBFD检测信息：

¡ 如果BFD/SBFD会话状态显示为Down，则在系统视图下执行mpls bfd enable命令开启MPLS与BFD/SBFD联动功能，确保检测LSP隧道的BFD/SBFD会话Up。

¡ 如果BFD/SBFD会话状态显示为Up，则执行步骤(6)。

<Sysname> display mpls bfd ipv4 22.22.2.2 32

Total number of sessions: 1, 1 up, 0 down, 0 init

FEC Type: LSP

FEC Info:

Destination: 22.22.2.2

Mask Length: 32

NHLFE ID: 1025

Local Discr: 513 Remote Discr: 513

Source IP: 11.11.1.1 Destination IP: 127.0.0.1

Session State: Up Session Role: Passive

Template Name: -

<Sysname> display mpls sbfd ipv4 22.22.2.2 32

Total number of sessions: 1, 1 up, 0 down, 0 init

FEC Type: LSP

FEC Info:

Destination: 22.22.2.2

Mask Length: 32

NHLFE ID: 1025

Local Discr: 513 Remote Discr: 513

Source IP: 11.11.1.1 Destination IP: 127.0.0.1

Session State: Up

Template Name: -

(6) 检查CPU状态是否正常。

执行display cpu-usage命令，查看CPU利用率的统计信息。

¡ 如果CPU利用率过高，则关闭一些不必要的功能，降低设备CPU利用率。

¡ 如果CPU利用率正常，则执行步骤(7)。

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

¡ 上述步骤的执行结果。

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

5. 告警与日志

11.6 VPLS故障处理

11.6.1 PW两端的PE设备中只有一个PE上的VSI处于Up状态

1. 故障描述

PW两端的PE设备中只有一个PE上的VSI处于Up状态。

2. 常见原因

VSI up的条件为：

· VSI下至少有一个PW Up和一个AC up。

· VSI下至少有两个AC Up。

因此本类故障的常见原因为：Up的VSI上虽然PW down，但是存在两个Up的AC；Down的VSI上PW down，且无两个Up的AC。

3. 故障分析

本类故障的诊断思路为：检查状态为Down的VSI下的AC和PW的状态。

4. 处理步骤

(1) 执行display l2vpn vsi命令，查看VSI下AC和PW的状态。

<Sysname> display l2vpn vsi verbose

VSI Name: vpls1

VSI Index : 0

VSI Description : vsi for vpls1

VSI State : Down

MTU : 1500

Bandwidth : -

Broadcast Restrain : -

Multicast Restrain : -

Unknown Unicast Restrain: -

MAC Learning : Enabled

MAC Table Limit : -

MAC Learning rate : -

Drop Unknown : -

PW Redundancy : Master

Flooding : Enabled

Statistics : Disabled

VXLAN ID : -

LDP PWs:

Peer PW ID Link ID State

192.3.3.3 1 8 Down

ACs:

AC Link ID State Type

GE1/0/3 srv1 1 Up Manual

(2) 执行display l2vpn pw verbose命令，查看PW状态变为Down的原因。

<Sysname> display l2vpn pw verbose

VSI Name: aaa

Peer: 2.2.2.9 Remote Site: 2

Signaling Protocol : BGP

Link ID : 9 PW State : Down

In Label : 1420 Out Label: 1419

MTU : 1500

PW Attributes : Main

VCCV CC : -

VCCV BFD : -

Flow Label : Send

Control Word : Disabled

Tunnel Group ID : 0x800000960000000

Tunnel NHLFE IDs : 1038

Admin PW : -

E-Tree Mode : -

E-Tree Role : root

Root VLAN : -

Leaf VLAN : -

Down Reasons : Control word not match

常见的故障原因及处理方法如下：

¡ BFD session for PW down：用来检测PW的BFD会话状态为down，此类故障的处理方式为，通过display bfd session命令查看BFD状态为down的原因，检查并修改BFD配置或检查物理链路是否存在链路故障、链路质量问题。

¡ BGP RD was deleted：BGP的RD被删除，此类故障的处理方式为，在交叉连接组自动发现视图下配置route-distinguisher route-distinguisher命令。

¡ BGP RD was empty：未配置BGP的RD，此类故障的处理方式为，在交叉连接组自动发现视图下配置route-distinguisher route-distinguisher命令。

¡ Control word not match：PW两端控制字功能配置不一致，此类故障的处理方式为，将PW两端引用的PW模板下的控制字功能（通过control-word enable命令开启）配置一致。

¡ 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.6.2 VPLS业务不通

1. 故障描述

VPLS业务流量转发不通。

2. 常见原因

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

· AC没有Up

· PW没有Up。

· PW没有生成转发信息。

· PW没有可迭代的公网隧道。

· PW迭代的公网隧道异常。

3. 故障分析

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

(1) 查看VSI详细信息，确认VSI下至少关联了一个AC和一个PW。

(2) 检查AC状态是否Up。

(3) 检查PW状态是否Up。

(4) 检查PW转发信息。

(5) 检查PW迭代的公网隧道信息。

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

图81 VPLS业务不通的故障诊断流程图

4. 处理步骤

(1) 执行display l2vpn vsi命令，查看VSI关联的AC、PW的状态和数量。

<Sysname> display l2vpn vsi verbose

VSI Name: vpls1

VSI Index : 0

VSI Description : vsi for vpls1

VSI State : Up

MTU : 1500

Bandwidth : -

Broadcast Restrain : -

Multicast Restrain : -

Unknown Unicast Restrain: -

MAC Learning : Enabled

MAC Table Limit : -

MAC Learning rate : -

Drop Unknown : -

PW Redundancy : Master

Flooding : Enabled

Statistics : Disabled

VXLAN ID : -

LDP PWs:

Peer PW ID Link ID State

192.3.3.3 1 8 Down

ACs:

AC Link ID State Type

GE1/0/3 srv1 1 Up Manual

(2) 若AC的状态为Down，则检查AC配置是否正确和并检查AC所在的接口是否Up。如果AC配置不正确或AC所在的接口为Down状态，请修改AC配置或排查接口故障。

(3) 若PW的状态为Down，请通过display l2vpn pw verbose命令查看PW状态变为Down的原因。