• 产品与解决方案
  • 行业解决方案
  • 服务
  • 支持
  • 合作伙伴
  • 新华三人才研学中心
  • 关于我们

01-产品故障处理

01-产品通用故障处理手册

本章节下载  (3.90 MB)

docurl=/cn/Service/Document_Software/Document_Center/Routers/Catalog/SR_Router/SR8800-X/Maintenance/Maintenance_Treasure/H3C_SR8800_X_R8260PXX-3767/01/202205/1613471_30005_0.htm

01-产品通用故障处理手册

  录

1 简介

1.1 故障处理注意事项

1.2 收集设备运行信息

1.2.1 logfile日志

1.2.2 diagfile日志

1.2.3 诊断信息

1.2.4 单板启动信息

1.3 故障处理求助方式

2 硬件类故障处理

2.1 系统故障

2.1.1 终端无显示或显示乱码

2.1.2 设备异常重启

2.1.3 温度异常告警

2.1.4 电压异常告警

2.1.5 内存异常告警

2.1.6 CPU占用率高

2.1.7 资源不足

2.2 电源故障

2.2.1 电源模块状态异常

2.3 风扇故障

2.3.1 风扇模块状态异常

2.4 单板故障

2.4.1 单板状态异常

2.4.2 主控板无法启动

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

2.4.4 主控板启动慢

2.4.5 主备倒换故障

2.4.6 业务板无法启动

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

2.5 端口故障

2.5.1 端口出现CRC错误

2.5.2 端口不接收报文

2.5.3 端口不发送报文

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

2.5.5 电口无法UP

2.5.6 端口频繁UP/DOWN

2.6 光模块故障

2.6.1 光口不UP故障

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

2.6.3 光模块不支持数字诊断

2.6.4 光模块序列号丢失

2.7 硬件转发故障

2.7.1 HG故障

2.7.2 FMEA故障

2.8 故障诊断命令

3 基础配置类故障处理

3.1 登录设备类故障处理

3.1.1 Console口密码遗忘

3.1.2 Telnet登录密码遗忘

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

3.2.1 使用配置文件恢复配置

4 虚拟化技术类故障处理

4.1 IRF组建失败

4.1.1 故障描述

4.1.2 常见原因

4.1.3 故障分析

4.1.4 SR8800-X故障处理步骤

4.1.5 SR8800-X-S故障处理步骤

4.1.6 告警与日志

4.2 IRF成员设备异常重启

4.2.1 故障描述

4.2.2 常见原因

4.2.3 处理步骤

4.2.4 告警与日志

4.3 IRF出现分裂

4.3.1 故障描述

4.3.2 SR8800-X故障处理步骤

4.3.3 SR8800-X-S设备故障处理步骤

4.4 故障诊断命令

5 接口管理类故障处理

5.1 聚合口故障

5.1.1 故障描述

5.1.2 故障处理步骤

5.2 端口错包

5.2.1 故障描述

5.2.2 故障处理步骤

5.3 端口无法up

5.3.1 故障描述

5.3.2 故障处理步骤

5.4 端口由up变成down

5.4.1 故障描述

5.4.2 故障处理步骤

5.5 端口频繁up/down

5.5.1 故障描述

5.5.2 故障处理步骤

5.6 光模块故障

5.6.1 故障描述

5.6.2 故障处理步骤

5.7 端口不可见

5.7.1 故障描述

5.7.2 故障处理步骤

5.8 WAN口协议不up

5.8.1 故障描述

5.8.2 故障处理步骤

5.9 WAN口物理不up

5.9.1 故障描述

5.9.2 故障处理步骤

5.10 WAN口打印告警信息

5.10.1 故障描述

5.10.2 故障处理步骤

5.11 故障诊断命令

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

6.1 MAC地址学习故障

6.1.1 故障描述

6.1.2 故障处理步骤

6.2 以太网链路聚合故障处理

6.2.1 聚合接口无法UP

6.2.2 聚合接口流量负载分担不均

6.2.3 聚合成员端口无法选中

6.3 VLAN转发故障

6.3.1 故障描述

6.3.2 故障处理步骤

6.4 生成树故障处理

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

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

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

7 三层技术-IP业务故障处理

7.1 ARP故障

7.1.1 故障描述

7.1.2 故障处理步骤

7.2 IP基础转发故障处理

7.2.1 链路异常,使用Ping/Tracert出现丢包或不通

7.3 DHCP中继故障处理

7.3.1 故障描述

7.3.2 故障处理步骤

7.4 ND故障处理

7.4.1 故障描述

7.4.2 故障处理步骤

7.5 IP性能优化故障处理

7.5.1 不同厂商的设备对接后,链路卡顿或不通

8 三层技术-IP路由类故障处理

8.1 BGP故障处理

8.1.1 BGP会话无法进入Established状态

8.1.2 BGP会话Down

8.2 IS-IS故障处理

8.2.1 IS-IS邻居无法建立

8.2.2 设备学习不到IS-IS路由

8.2.3 IS-IS路由震荡

8.3 OSPFv3故障处理

8.3.1 OSPFv3邻居Down

8.3.2 OSPFv3邻居无法达到FULL状态

8.4 OSPF故障处理

8.4.1 OSPF邻居Down

8.4.2 OSPF邻居无法达到FULL状态

8.4.3 设备学习不到部分OSPF路由

8.4.4 网络中IP地址冲突导致路由震荡

9 IP组播故障处理

9.1 二层组播故障处理

9.1.1 二层组播业务不通

9.2 三层组播故障处理

9.2.1 三层组播业务不通

9.2.2 无法正常建立IGMP或MLD表项

9.3 MSDP故障处理

9.3.1 MSDP对等体无法正确建立(S,G)表项

9.4 PIM故障处理

9.4.1 PIM邻居Down

9.4.2 PIM域内三层组播流量不通

9.4.3 PIM-SM网络中SPT无法正常转发数据

9.4.4 PIM-SM网络中RPT无法正常转发数据

10 MPLS故障处理

10.1 MPLS基础类故障处理

10.1.1 报文通过LSP隧道转发不通

10.1.2 MPLS VPN转发故障

10.2 LDP故障处理

10.2.1 LDP会话震荡

10.2.2 LDP会话无法Up

10.2.3 LDP LSP震荡

10.2.4 LDP LSP无法Up

10.3 MPLS L2VPN/VPLS通用故障处理

10.3.1 PW ping不通

10.4 VPLS故障处理

10.4.1 VPLS的VSI不能up

10.4.2 PW两端的PE设备中只有一个PE上的VSI处于Up状态

10.4.3 VPLS业务不通

10.4.4 PW处于Up状态时两个PE间报文转发失败

10.5 MPLS L3VPN故障处理

10.5.1 缺少去往对端VPN实例的路由

10.5.2 VPN实例下的FIB表项异常

10.5.3 L3VPN流量中断

10.5.4 L3VPN私网路由频繁震荡

10.5.5 PE间无法交换VPN路由

10.5.6 配置相同RT的不同VPN之间不能互通

10.5.7 路由反射器进行VPN-Target过滤导致PE无法学习到路由

10.5.8 PE的私网IP路由表中没有远端PE发布的路由

10.5.9 私网间大包不通

10.5.10 PE设备Ping不通远端CE网段

10.6 MPLS业务丢包故障处理

10.6.1 故障描述

10.6.2 L3VPN丢包故障处理步骤

10.6.3 L2VPN丢包故障处理步骤

10.6.4 VPLS丢包故障处理步骤

10.6.5 MPLS丢包问题定位实例

10.7 MPLS TE故障处理

10.7.1 MPLS TE隧道状态为Down

10.7.2 MPLS TE隧道由UP状态变为Down状态

10.7.3 MPLS TE隧道存在环路

10.7.4 Tunnel路径计算失败

10.7.5 热备份CRLSP无法建立

11 Segment Routing类故障处理

11.1 SR-MPLS故障处理

11.1.1 SR-MPLS-BE方式的SRLSP无法建立

11.1.2 SR-MPLS-TE Tunnel状态为Down

11.2 SRv6 TE Policy故障处理

11.2.1 SRv6 TE Policy无法生效的定位思路

11.3 MPLS L3VPN over SRv6故障处理

11.3.1 MPLS L3VPN over SRv6故障处理

11.4 EVPN VPLS over SRv6故障处理

11.4.1 VPLS的VSI不能up

11.5 EVPN VPWS over SRv6故障处理

11.5.1 VPWS的xconnect-group不能up

11.6 MPLS L3VPN over SR故障处理

11.6.1 MPLS L3VPN over SR故障处理

11.7 EVPN L3VPN over SRv6故障处理

11.7.1 EVPN L3VPN over SRv6 BE流量转发不通

11.7.2 EVPN L3VPN over SRv6 TE流量转发不通

12 ACL和QoS故障处理

12.1 QoS故障处理

12.1.1 QACL业务故障

12.1.2 802.1p优先级映射故障

12.1.3 MQC方式配置的QoS策略未生效

12.1.4 接口下CBQ队列调度策略未生效

12.1.5 QoS队列拥塞丢包

13 可靠性故障处理

13.1 CFD故障

13.1.1 二层VPN组网的CFD故障

13.2 BFD转发故障

13.2.1 故障描述

13.2.2 故障诊断流程

13.2.3 故障处理步骤

14 用户接入与认证类故障处理

14.1 Password Control故障处理

14.1.1 管理员登录时系统要求修改密码

14.1.2 创建本地用户或配置用户密码失败

14.1.3 管理员因闲置超时无法登录

14.2 AAA故障处理

14.2.1 登录设备后无法执行部分命令行

14.2.2 登录设备后无法创建或修改本地用户

14.2.3 管理员未被授权用户角色

14.2.4 登录用户名含有非法字符

14.2.5 本地用户名或密码错误

14.2.6 本地用户的服务类型不匹配

14.2.7 登录失败固定次数后,被禁止在指定的时间内再次登录

14.2.8 登录失败后需要等待一定时长再进行重认证

14.2.9 使用相同用户名接入设备的用户数达到上限

14.2.10 相同接入类型的在线用户数达到上限

14.2.11 RADIUS服务器无响应

14.2.12 HWTACACS服务器无响应

14.2.13 用户接入类型与RADIUS服务器下发的Login-Service属性值不匹配

14.2.14 本地认证登录失败

14.2.15 RADIUS认证登录失败

14.2.16 HWTACACS认证登录失败

14.2.17 LDAP认证登录失败

14.2.18 RADIUS认证服务器下发的动态VLAN不生效

14.2.19 RADIUS认证服务器下发的Filter-Id属性不生效或只有部分生效

14.2.20 RADIUS服务器与设备交互失败

14.3 Portal故障

14.3.1 Portal认证页面无法弹出

14.3.2 Portal认证失败

14.3.3 Portal认证用户掉线

15 安全类故障处理

15.1 SSH故障处理

15.1.1 SSH客户端登录设备失败

16 网络管理和监控类故障处理

16.1 Ping和Tracert故障处理

16.1.1 Ping不通

16.1.2 Tracert不通

16.2 SNMP故障处理

16.2.1 SNMP连接失败

16.2.2 SNMP操作超时

16.2.3 网管无法管理设备

16.2.4 网管无法收到设备发送的Trap

16.3 PTP故障

16.3.1 故障描述

16.3.2 故障处理步骤

16.4 镜像故障处理

16.4.1 配置流镜像后监控设备收不到镜像报文

16.4.2 配置端口镜像后监控设备收不到镜像报文

16.5 NetStream故障处理

16.5.1 常见原因

16.5.2 故障诊断流程

16.5.3 故障处理步骤

16.6 NQA TWAMP-light测试故障

16.6.1 故障描述

16.6.2 故障处理步骤

16.7 NQA TWAMP server端测试故障

16.7.1 故障描述

16.7.2 故障处理步骤

16.8 路径服务质量测试故障

16.8.1 故障描述

16.8.2 故障处理步骤

16.9 UDP-jitter测试故障

16.9.1 故障描述

16.9.2 故障处理步骤

16.10 Y.1564测试故障

16.10.1 故障描述

16.10.2 故障处理步骤

16.11 iFIT测试故障

16.11.1 故障描述

16.11.2 故障处理步骤

16.12 NETCONF故障处理

16.12.1 SOAP方式登录失败

16.12.2 SSH方式登录失败

17 VXLAN类故障处理

17.1 VXLAN故障处理

17.1.1 VXLAN转发不通

17.1.2 Ping不通集中式VXLAN IP网关

18 EVPN类故障处理

18.1 EVPN VXLAN故障处理

18.1.1 EVPN分布式网关场景,同一VXLAN内的VTEP之间隧道无法建立

18.1.2 EVPN分布式网关场景,不同VXLAN内的VTEP之间隧道无法建立

18.1.3 VXLAN网络中,二层VXLAN业务流量不通

18.1.4 VXLAN网络中,三层VXLAN业务流量不通

18.1.5 EVPN网络中,VM迁移时间过长

18.1.6 VTEP设备上存在MAC迁移,导致其他终端访问VM业务异常

18.1.7 VXLAN DCI隧道未成功建立

19 NAT故障处理

19.1 NAT故障处理

19.1.1 NAT地址转换失败

19.1.2 CGN功能失效

 

 


1 简介

本文档介绍SR8800-X产品软、硬件常见故障的诊断及处理措施。

本文档适用于Release SR8800-CMW710-R8260PXXSR8800FS-CMW710-R8260PXX

1.1  故障处理注意事项

注意

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

 

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

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

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

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

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

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

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

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

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

·     故障处理过程中如需更换硬件部件,请参考与软件版本对应的版本说明书,确保新硬件部件和软件版本的兼容性。例如:带有微动开关的网板,只要出现过弹开又合上的情况,一定要重新拔插一下网板。

1.2  收集设备运行信息

说明

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

 

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

表1     设备运行信息介绍

分类

文件名

内容

logfile日志

logfileX.log

命令行记录、设备运行中产生的记录信息

diagfile日志

diagfileX.log

设备运行中产生的诊断日志信息,如系统运行到错误流程时的参数值、单板无法启动时的信息、主控板与接口板通信异常时的握手信息。

诊断信息

XXX.gz

系统当前多个功能模块运行的统计信息,包括设备状态、CPU状态、内存状态、配置情况、软件表项、硬件表项等

 

说明

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

 

1.2.1  logfile日志

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

<Sysname> logfile save

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

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

·     主用主控板logfile日志:

<Sysname> dir cfa0:/logfile/

Directory of cfa0:/logfile

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

 

1021104 KB total (421552 KB free)

 

·     备用主控板logfile日志:

<Sysname> dir slot1#cfa0:/logfile/

Directory of slot1#cfa0:/logfile

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

 

1021104 KB total (421552 KB free)

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

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

Directory of chassis2#slot0#cfa0:/logfile

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

 

1021104 KB total (421552 KB free)

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

1.2.2  diagfile日志

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

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

<Sysname> diagnostic-logfile save

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

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

·     主用主控板diagfile日志:

<Sysname> dir cfa0:/diagfile/

Directory of cfa0:/diagfile

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

 

1021104 KB total (421416 KB free)

 

·     备用主控板diagfile日志:

<Sysname> dir slot1#cfa0:/diagfile/

Directory of slot1#cfa0:/diagfile

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

 

1021104 KB total (421416 KB free)

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

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

Directory of chassis2#slot0#cfa0:/diagfile

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

 

1021104 KB total (421416 KB free)

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

1.2.3  诊断信息

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

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

说明

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

 

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

<Sysname> screen-length disable

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

<Sysname> display diagnostic-information

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

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

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

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

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

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

Please wait...

Save successfully.

<Sysname> dir cfa0:/

Directory of cfa0:

……

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

……

 

1021808 KB total (259072 KB free)

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

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

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

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

No alarm information.

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

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

Software images on slot 0:

Current software images:

  cfa0:/BOOT-RXXXX.bin

  cfa0:/SYSTEM-RXXXX.bin

Main startup software images:

  cfa0:/BOOT-RXXXX.bin

  cfa0:/SYSTEM-RXXXX.bin

Backup startup software images:

  None

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

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

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

BAGG1                        0                  0                  0           0

GE3/1/1                      0                  0                  0           0

GE3/1/2                      2                  2                  0           0

GE3/1/3                      0                  0                  0           0

GE3/1/4                      0                  0                  0           0

GE3/1/5                      0                  0                  0           0

GE3/1/6                      0                  0                  0           0

GE3/1/7                      0                  0                  0           0

GE3/1/8                      0                  0                  0           0

GE3/1/9                      0                  0                  0           0

GE4/0/10                     0                  0                  0           0

1.2.4  单板启动信息

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

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

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

<Sysname>cd cfa0:/info/

<Sysname>dir

Directory of cfa0:/info

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

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

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

<Sysname> system-view

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

[Sysname] probe

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

 

Slot 0, CPU 0

 Total number of boot info in reserved memory: 32

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

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

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

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

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

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

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

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

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

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

1.3  故障处理求助方式

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

用户支持邮箱:[email protected]

技术支持热线电话:400-810-0504(手机、固话均可拨打)

 


2 硬件类故障处理

说明

关于设备各部件指示灯的详细情况,请参见《H3C SR8800-X路由器安装指导》和《H3C SR8800-X-S路由器安装指导》。

 

2.1  系统故障

2.1.1  终端无显示或显示乱码

1. 故障描述

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

2. 常见原因

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

·     电源工作异常。

·     主控板工作异常。

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

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

·     配置电缆故障。

3. 故障分析

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

图2-1 故障诊断流程图

 

4. 处理步骤

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

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

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

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

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

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

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

(5)     更换配置电缆。

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

¡     上述步骤的执行结果。

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

5. 告警与日志

相关告警

相关日志

2.1.2  设备异常重启

1. 故障描述

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

2. 常见原因

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

3. 故障分析

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

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

 

4. 处理步骤

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

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

说明

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

 

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

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

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

¡     上述步骤的执行结果。

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

5. 告警与日志

相关告警

无。

相关日志

无。

2.1.3  温度异常告警

1. 故障描述

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

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

2. 常见原因

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

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

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

·     设备防尘网积灰过多。

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

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

3. 故障分析

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

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

 

4. 处理步骤

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

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

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

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

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

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

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

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

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

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

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

¡     上述步骤的执行结果。

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

5. 告警与日志

相关告警

无。

相关日志

·     TEMP_HIGH

·     TEMP_LOW

·     TEMP_NORMAL

·     TEMPERATURE_ALARM

·     TEMPERATURE_LOW

·     TEMPERATURE_NORMAL

·     TEMPERATURE_POWEROFF

·     TEMPERATURE_SHUTDOWN

·     TEMPERATURE_WARNING

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

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

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

 

4. 处理步骤

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

5. 告警与日志

相关告警

无。

相关日志

·     VOLT_HIGH

·     VOLT_LOW

·     VOLT_NORMAL

2.1.5  内存异常告警

1. 故障描述

系统打印内存异常告警信息,例如:

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

2. 常见原因

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

3. 故障分析

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

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

相关告警

无。

相关日志

·     MEM_ALERT

·     MEM_EXCEED_THRESHOLD

·     MEM_BELOW_THRESHOLD

2.1.6  CPU占用率高

1. 故障描述

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

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

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

<Sysname> display cpu-usage summary

Slot CPU        Last 5 sec        Last 1 min        Last 5 min

1    0          5%                5%                4%

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

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

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

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

2. 常见原因

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

·     网络攻击。

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

·     网络环路。

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

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

3. 故障分析

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

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

 

4. 处理步骤

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

<Sysname> reset counters interface

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

<Sysname> display counters rate inbound interface

Usage: Bandwidth utilization in percentage

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

ast(pps)

GE3/1/5                                0.00              0              0

       0

GE3/1/6                                0.00              0              0

       0

GE3/1/7                                0.00              0              0

       0

MGE0/0/0                               0.01             15             --

      --

XGE3/1/1                               0.00              0              0

       0

XGE3/1/2                               0.00              0              0

       0

XGE3/1/3                               0.00              0              0

       0

XGE3/1/4                               0.00              0              0

       0

Vlan1                                    --              0             --

      --

 

 Overflow: More than 14 digits.

       --: Not supported.

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

<Sysname> display counters inbound interface

Interface                            Total(pkt) Broadcast(pkt) Multicast(pkt) Er

r(pkt)

GE3/1/5                                   10659              0          10659

     0

GE3/1/6                                   10659              0          10659

     0

GE3/1/7                                   10659              0          10659

     0

MGE0/0/0                                3084773        1298212        1736440

     0

RAGG1                                         0              0              0

     0

RAGG10                                        0              0              0

     0

RAGG121                                       0              0              0

     0

XGE3/1/1                                      0              0              0

     0

XGE3/1/2                                      0              0              0

     0

XGE3/1/3                                      0              0              0

     0

XGE3/1/4                                      0              0              0

     0

Vlan1                                     21318             --             --

    --

 

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

       --: Not supported.

¡     如链路出现环路,可进行如下处理:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

<Sysname> terminal monitor

The current terminal is enabled to display logs.

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

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

<Sysname> display logbuffer summary

Slot  CPU EMERG ALERT  CRIT ERROR  WARN NOTIF  INFO DEBUG

     0    0     0     0     0    70    73    69   300     0

<Sysname> display logbuffer reverse

Log buffer: Enabled

Max buffer size: 1024

Actual buffer size: 512

Dropped messages: 0

Overwritten messages: 0

Current messages: 410

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

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

...

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

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

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

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

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

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

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

# 在设备上执行display process cpu命令查看一段时间内占用CPU最多的任务。下面以slot 1上的操作为例。

<Sysname> display process cpu slot 1

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

    JID      5Sec      1Min      5Min    Name

      1      0.0%      0.0%      0.0%    scmd

      2      5.5%      5.1%      5.0%    [kthreadd]

      3      0.0%      0.0%      0.0%    [ksoftirqd/0]

...

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

# 在设备上执行monitor process dumbtty命令实时查看进程在指定CPU上的占用率。下面以slot 1 CPU 0为例。

<Sysname> system-view

[Sysname] monitor process dumbtty slot 1 cpu 0

206 processes; 342 threads; 5134 fds

Thread states: 4 running, 338 sleeping, 0 stopped, 0 zombie

CPU0: 99.04% idle, 0.00% user, 0.96% kernel, 0.00% interrupt, 0.00% steal

CPU1: 98.06% idle, 0.00% user, 1.94% kernel, 0.00% interrupt, 0.00% steal

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

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

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

Memory: 7940M total, 5273M available, page size 4K

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

        322        322  115   R     0       0K  01:48:03  20.02%  [kdrvfwdd2]

        323        323  115   R     0       0K  01:48:03  20.02%  [kdrvfwdd3]

        324        324  115   R     0       0K  01:48:03  20.02%  [kdrvfwdd4]

        376        376  120   S    22  159288K  00:00:07   0.37%  diagd

          1          1  120   S    18   30836K  00:00:02   0.18%  scmd

        379        379  120   S    22  173492K  00:00:11   0.18%  devd

          2          2  120   S     0       0K  00:00:00   0.00%  [kthreadd]

          3          3  120   S     0       0K  00:00:02   0.00%  [ksoftirqd/0]

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

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

   <Sysname> display process name pppd

                                Job ID: 515

                                   PID: 515

                            Parent JID: 1

                            Parent PID: 1

                       Executable path: /sbin/pppd

                              Instance: 0

                               Respawn: ON

                         Respawn count: 1

                Max. spawns per minute: 12

                          Last started: Wed Nov  3 09:52:00 2021

                         Process state: sleeping

                             Max. core: 1

                                  ARGS: --MaxTotalLimit=2000000 --MaxIfLimit=65534 --CmdOption=0x01047fbf --bSaveRunDb --pppoechastenflag=1 --pppoechastennum=6 --pppoechastenperiod=60 --pppoechastenblocktime=300 --pppchastenflag=1 --pppchastennum=6 --pppchastenperiod=60 --pppchastenblocktime=300 --PppoeKChasten --bSoftRateLimit --RateLimitToken=2048

       TID  LAST_CPU    Stack      PRI    State   HH:MM:SS:MSEC  Name

       515      0        136K      115      S     0:0:0:90       pppd

       549      0        136K      115      S     0:0:0:0        ppp_misc

       557      0        136K      115      S     0:0:0:10       ppp_chasten

       610      0        136K      115      S     0:0:0:0        ppp_work0

       611      1        136K      115      S     0:0:0:0        ppp_work1

       612      1        136K      115      S     0:0:0:0        ppp_work2

       613      1        136K      115      S     0:0:0:0        mp_main

       618      1        136K      115      S     0:0:0:110      pppoes_main

       619      1        136K      115      S     0:0:0:100      pppoes_mesh

       620      1        136K      115      S     0:0:0:120      l2tp_mesh

       621      1        136K      115      S     0:0:0:20       l2tp_main

-     对于运行在控制核、CPU占用率超过5%的进程,查看进程的Name字段的取值来确定该进程是否为用户态进程。

如果Process的Name取值中包含“[ ]”,表示它是内核线程,无需执行monitor thread dumbtty命令;如果Process的Name取值中未包含“[ ]”,表示它是用户态进程,它可能包含多个线程。对于多线程的用户态进程,还需要对该用户态进程执行monitor thread dumbtty命令,如果显示信息中某线程LAST_CPU字段的取值为CPU控制核的编号,且CPU字段取值大于5%,则该线程可能为导致CPU控制核占用率高的线程,需要进一步定位。

   <Sysname> monitor thread dumbtty slot 1 cpu 0

   206 processes; 342 threads; 5134 fds

   Thread states: 4 running, 338 sleeping, 0 stopped, 0 zombie

   CPU0: 98.06% idle, 0.97% user, 0.97% kernel, 0.00% interrupt, 0.00% steal

   CPU1: 97.12% idle, 0.96% user, 0.96% kernel, 0.96% interrupt, 0.00% steal

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

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

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

   Memory: 7940M total, 5315M available, page size 4K

           JID      TID  LAST_CPU  PRI  State  HH:MM:SS MAX   CPU     Name

           322       322      2      115    R    00:04:21    0  20.15%   [kdrvfwdd2]

           323       323      3      115    R    00:04:21    0  20.15%   [kdrvfwdd3]

           324       324      4      115    R    00:04:21    0  20.15%   [kdrvfwdd4]

             1         1     1     120    S   00:00:02   21   0.19%   scmd

           376       376     1     120    S   00:00:00    1   0.19%   diagd

             2         2     0     120    S   00:00:00    0   0.00%   [kthreadd]

   ...

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

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

<Sysname> system-view

[Sysname] probe

[Sysname-probe] follow job 515 slot 1

Attaching to process 515 (pppd)

Iteration 1 of 5

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

Thread LWP 515:

Switches: 3205

User stack:

#0  0x00007fdc2a3aaa8c in epoll_wait+0x14/0x2e

#1  0x0000000000441745 in ppp_EpollSched+0x35/0x5c

#2  0x0000000000000004 in ??

Kernel stack:

[<ffffffff811f0573>] ep_poll+0x2f3/0x370

[<ffffffff811f06c0>] SyS_epoll_wait+0xd0/0xe0

[<ffffffff814aed79>] system_call_fastpath+0x16/0x1b

[<ffffffffffffffff>] 0xffffffffffffffff

Thread LWP 549:

Switches: 20

User stack:

#0  0x00007fdc2a3aaa8c in epoll_wait+0x14/0x2e

#1  0x00000000004435d4 in ppp_misc_EpollSched+0x44/0x6c

Kernel stack:

[<ffffffffffffffff>] 0xffffffffffffffff

...

c.     根据a和b步骤找到任务名称,再根据任务名称找到对应的业务模块,定位并处理业务模块的问题。例如,如果任务snmpd的CPU占用率较高,可能是因为设备受到了SNMP攻击,或者NMS对设备的访问太频繁。需要进一步定位SNMP业务模块的问题;如果任务nqad的CPU占用率较高,可能是因为NQA探测太频繁,需要进一步定位NQA业务模块的问题。

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

¡     上述步骤的执行结果。

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

5. 告警与日志

相关告警

·     hh3cEntityExtCpuUsageThresholdNotfication

·     hh3cEntityExtCpuUsageThresholdRecover

·     hh3cCpuUsageSevereNotification

·     hh3cCpuUsageSevereRecoverNotification

·     hh3cCpuUsageMinorNotification

·     hh3cCpuUsageMinorRecoverNotification

相关日志

·     DIAG/5/CPU_MINOR_RECOVERY

·     DIAG/4/CPU_MINOR_THRESHOLD

·     DIAG/5/CPU_SEVERE_RECOVERY

·     DIAG/3/CPU_SEVERE_THRESHOLD

2.1.7  资源不足

1. 故障描述

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

The resources are insufficient.

No enough resource!

Not enough resources are available to complete the operation.

典型的系统资源包括:

·     ACL

·     FIB

·     MAC

·     MPLS LSP

·     组播

·     ARP

2. 故障处理步骤

# ACL资源不足。

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

·     QoS策略

·     Packet filter

·     策略路由

·     IPoE

·     Portal

·     URPF

·     DHCP Snooping

·     LLDP

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

<Sysname> display qos-acl resource slot 3

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

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

 Type             Total      Reserved   Configured Remaining  Usage

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

 IPv4Acl          65536      0          2          65534      0%

 IPv6Acl          16384      0          0          16384      0%

 Car&Cnt          32768      0          1          32767      0%

 InBRASCar        65536      0          0          65536      0%

 OutBRASCar       65536      0          0          65536      0%

 TCPCar           16384      0          0          16384      0%

 CarProf          220        0          2          218        0%

 Sampler          32768      0          0          32768      0%

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

# FIB资源不足。

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

·     MPE-1104SPC单板:

[Sysname-probe] debug ipv4-drv show statistics slot 2

 

 

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

- IPv4 Statistics        Slot 2

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

- ROUTE TOTAL COUNT:             40

- ECMP COUNT:                    0

- ARP NH COUNT:                  8

- IPV4 NH CHANGE NUM:            16

- ARP Prefix ADD NUM:            12

- ARP Prefix MODIFY NUM:         2

- ARP Prefix DEL NUM:            0

- ARP Prefix AddSuccessed NUM:   0

- ARP Prefix ModSuccessed NUM:   0

- ARP Prefix DelSuccessed NUM:   0

- IPV6 NH CHANGE NUM:            0

- IPV4 Plat ARP Demand NUM:      16

- IPV4 ARP Successed NUM:        16

- IPV4 Plat Route Demand NUM:    47

- IPV4 Route Successed NUM:      47

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

- IPv4Uc_Sm Owner:               -1

- IPv4Uc_Sm Count:               0

- L3UcPbr_Sm Owner:              -1

- L3UcPbr_Sm Count:              0

……略

[Sysname-probe] debug ipv4-drv show config slot 2

 

 

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

- IPv4 Config    Slot 2

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

- ARP SIZE:              16384

- ArpCanNotSetToHW:      NO

- IPV4 ROUTE SIZE:       65536

- ECMP SIZE:             8

- ND SIZE:               8192

- IPV6 ROUTE SIZE:       8192

- IPV6 LongPrefRT:       128

- VLAN INTF MODE:        2

- NH SIZE:               16384

- ECMPGP SIZE:           256

- L3INTF SIZE:           4096

- VLAN INTF SIZE:        4096

- SUBVLAN SIZE:          3072

- MC INTF SIZE:          4005

- MPLS INTF SIZE:        4000

- TUNNEL INTF SIZE:      511

- VMAC SIZE:             256

- VMAC PER INTF SIZE:    16

- VLAN MAPPING SIZE:     4094

- ARP SET TO DEFIP:      1

- HG PROXY FLAG:         0

- BOARD TYPE:            0

- Is Set CPUPktPri:      1

- L3uc Opt:              NO

- NetMFw FLAG:           Fw_Hw

 

- RESERVED EGRESS:

- CPU EGRESS:            100001

- BLACKHOLE EGRESS:      100002

- HG PROXY EGRESS:

- UINT:0

          0: Egress:100003  Mod:63  port:27

          1: Egress:100004  Mod:63  port:27

 

- L3VPN SPECS:

- GLOBAL VRF NUM:        2048

 

- UPRF SPECS:

- URPF GLOBAL SUPPORT:   YES

- URPF INTF SUPPORT:     NO

- DEFAULT ROUTE DENY:    NO

- IPv4 MaxRoute:         65536

- IPv6 MaxRoute:         4096

- CHIP SUPPORT TYPE:     TRIUMPHV4EXT

……略

ROUTE TOTAL COUNT表示实际占用的IPv4表项资源,IPv4 MaxRoute表示IPv4表项总的资源。

·     CSPC-GE16XP4L-E、CSPC-GE24L-E、CSPC-GP24GE8XP2L-E、CSPEX-1104-E和SPEX-1204单板:

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

 

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

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

 PID:        PES Table ID

 PTY:        PES Table type

 KAL:        PES Key Align len

 RAL:        PES Result Align Len

 SID:        SDK TABLE ID

 TableName:  SDK Table name

 STY:        SDK Table type

 LOCA:       SDK Location

 MaxEntry:   SDK Max Entries

 ES:         SDK Entry_size

 MID:        SDK Moudle ID

 CID:        SDK DDR CTRL ID

 CNAME:      SDK DDR CTRL NAME

 KSZ:        SDK Key Size

 RSZ:        SDK Result Size

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

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

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

 CNAME  KSZ RSZ

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

 NULL   0   16

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

 DDR7   0   16

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

 NULL   0   1

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

 NULL   0   1

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

 NULL   0   1

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

 NULL   0   1

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

 DDR2   6   32

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

 DDR2   0   32

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

 DDR6_0 8   16

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

 DDR6_0 0   16

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

 NULL   0   32

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

 DDR0_0 4   3

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

 DDR7   6   3

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

 NULL   0   32

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

 NULL   0   8

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

 DDR0_0 0   16

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

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

 

 There are 16 entries!

·     CSPEX类单板(CSPEX-1104-E、CSPEX-1304X、CSPEX-1404X除外)、SPE类单板和CEPC类单板:

TCAM模式:

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

 

Database name:           IPV4

Database capacity:       4194304

Current entry count:     148052

Start index:             0x0

End index:               0x5fffff

Key width Type:          0

Key real size in bytes:  6

Key size defined by NPS: 8

Res size defined by NPS: 32

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

·     CSPEX-1304X、CSPEX-1404X单板:

Fast_IP模式:

[System-probe] display hardware internal np table all slot 5 chip 0

 

 TblID Name                    StruNum StruID Type       KeyLen ResLen MaxEntry

 0     IPCT                    255     0      PORT       1      16     192

 1     REMOTE_IPCT             66      48     TABLE      2      16     65536

 2     VRRP_MAC                86      62     HASH       7      8      32768

 7     RPR_MAC                 89      64     HASH       6      20     131072

 8     RPR_NODE_MAC            69      51     HASH       8      8      1024

 9     INLIF                   28      16     TABLE      3      32     1048576

 10    REMOTE_INLIF            67      49     HASH       4      32     65536

 12    QINQ_INLIF              65      47     HASH       6      32     65536

 14    VE_INLIF                42      28     HASH       5      32     16384

 19    ILM                     27      15     TABLE      3      32     1048576

 20    ILM_ALIAS               88      15     TABLE      3      32     1048576

 21    TUNNEL_ILM              71      53     HASH       6      24     65536

 22    MAC                     4       0      HASH       8      16     1048576

 23    MAC_SMAC                45      0      HASH       8      16     1048576

 24    MAC_SMAC_INNER          46      0      HASH       8      16     1048576

 26    MINM_TUNNEL_END         48      31     HASH       13     8      65536

 27    PROTOCOL_MAC            62      44     HASH       12     8      65536

 28    RRPP_FILTER             93      67     TREE       12     4      65536

 29    RRPP_FILTER_RESULT      95      68     TABLE      3      8      65536

 30    PPPOE_USER              61      43     HASH       15     32     65536

 31    V4IPOE_USER             34      22     HASH       11     32     65536

 32    V4IPOE_SEGMENT_USER     36      24     TREE       7      4      4096

 33    V4IPOE_SEGMENT_USER_RES 40      26     TABLE      2      32     8192

 34    V6IPOE_USER             35      23     HASH       23     32     65536

 35    V6IPOE_SEGMENT_USER     38      25     TREE       18     4      4096

 36    V6IPOE_SEGMENT_USER_RES 40      26     TABLE      2      32     8192

 37    L2TP_USER               41      27     HASH       16     32     131072

 38    PPPOE_FILTER            60      42     HASH       5      8      262144

 39    TCP_STREAM              70      52     HASH       39     32     917504

 40    MLL                     49      32     TABLE      3      16     8388608

 41    OUTLIF                  6       2      TABLE      3      32     2097152

 42    OUTLIF_NOACL            44      2      TABLE      3      32     2097152

 43    OUTLIF_TUNNEL           96      2      TABLE      3      32     2097152

 44    OUTLIF_MLOG             98      2      TABLE      3      32     2097152

 45    UDP_TUNNEL_START        13      7      TABLE      3      32     131072

 46    IPV6_TUNNEL_START       80      59     TABLE      3      32     131072

 47    USER                    73      55     TABLE      2      16     65536

 48    ARP                     7       3      TABLE      3      32     1048576

 49    RPR_ARP                 90      65     TABLE      2      32     8192

 50    NS_ARP                  51      34     TABLE      3      32     1048576

 51    FTN                     21      13     FASTIP     6      4      4194304

……略

DDR内存中IPv4表项总的资源为3000000条。使用display np table all命令查找FTN对应的表项的TblID,再使用display np table TblID entrycount slot命令可以查看该表项在DDR内存中实际占用的IPv4表项资源。

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

# MAC资源不足。

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

<Sysname> display mac-address count

 49 mac address(es) found

建议:

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

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

# MPLS LSP资源不足。

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

<Sysname> display mpls lsp statistics

LSP Type      Ingress/Transit/Egress  Active

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

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

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

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

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

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

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

Total         0/0/1                   0/0/1

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

# 其他系统资源不足。

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

2.2  电源故障

2.2.1  电源模块状态异常

1. 故障描述

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

2. 常见原因

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

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

·     电源模块安装不到位。

·     电源线缆没有插牢。

·     电源模块温度过高。

·     电源模块故障。

3. 故障分析

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

图2-7 故障诊断流程图

 

4. 处理步骤

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

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

(3)     通过电源模块上的指示灯初步判断电源模块是否存在输出短路、输出过流、输出过压、输入欠压、温度过热等问题。当电源模块的输入指示灯灭时,说明该电源模块的输入电压过低;当电源模块的输出指示灯为红色常亮时,说明该电源模块可能存在输出短路、输出过流、输出过压、输入欠压;当电源模块的输出指示灯为橙色常亮时,说明该电源模块可能存在电源温度过高。SR8800-X-S不同主机电源指示灯状态有所差异,具体请参见相应主机的硬件手册。

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

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

<Sysname> display power

 Power        0 State: Normal

 Power        1 State: Absent

 Power        2 State: Absent

 Power        3 State: 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

¡     上述步骤的执行结果。

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

5. 告警与日志

相关告警

相关日志

·     DEV/2/POWER_FAILED

·     DEV/3/POWER_ABSENT

2.3  风扇故障

2.3.1  风扇模块状态异常

1. 故障描述

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

2. 常见原因

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

·     风扇未插紧。

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

·     风扇硬件故障。

3. 故障分析

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

图2-8 故障诊断流程图

 

4. 处理步骤

(1)     查看风扇模块指示灯状态是否正常,部分设备风扇框本身也提供有风扇框状态指示灯,如果风扇框的OK指示灯灭、FAIL指示灯亮或者OK/FAIL状态指示灯为红色常亮时,说明风扇系统存在故障。不同主机风扇指示灯状态有所差异,具体请参见相应主机的硬件手册。如果所有指示灯都为灭,请确认电源模块是否正常工作,或整机开关接线是否开路,具体请参见2.2.1  电源模块状态异常

(2)     查看风扇框状态。

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

<Sysname> display fan

Fan Frame 0  State: Normal

也可以使用display alarm命令查看风扇框告警信息。

<Sysname> display alarm

Chassis Slot   CPU   Level   Info

2       -      -     INFO    fan 1 is absent.

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

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

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

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

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

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

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

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

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

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

¡     上述步骤的执行结果。

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

5. 告警与日志

相关告警

相关日志

·     DEV/2/FAN_FAILED

·     DEV/3/FAN_ABSENT

2.4  单板故障

2.4.1  单板状态异常

1. 故障描述

说明

假如设备上出现Forwarding faultBoard fault: chassis X slot Y, please check it等日志信息,请参考“2.7  硬件转发故障”。

 

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

¡     对于SR05SRP1L1SR05SRP1L3SR07SRPUB1SR07SRPUC1SR07SRPUD3SR05SRP1P3CSR05SRP1P1CSR05SRP1R3主控板,单板状态指示灯RUNALM灯同时闪烁或者常亮。

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

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

¡     对于SR8800-X路由器,SFC-08E1SFC-16ET类交换网板启动完成后RUN指示灯灯灭;其他交换网板上的RUN指示灯灭或闪烁,且ALM灯常亮。

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

¡     SR8800-X

<Sysname> display device

Slot No. Brd Type         Brd Status   Software Version

 0       SR05SRP1L3       Master       SR8800-CMW710-RXXXX

 1       SR05SRP1L3       Standby      NONE

 2       SPC-XP8LB        Normal       SR8800-CMW710-RXXXX

 3       MPE-1104         Normal       SR8800-CMW710-RXXXX

   Sub1  MIC-SP4L         Normal

   Sub2  MIC-SP4L         Normal

   Sub3  MIC-CLP2L        Normal

   Sub4  MIC-GP4L         Normal

 4       SPC-XP8LB        Normal       SR8800-CMW710-RXXXX

 5       NONE             Absent       NONE

 6       SFC-04D          Normal       SR8800-CMW710-RXXXX

 7       NONE             Absent       NONE

 8       NONE             Absent       NONE

 9       NONE             Absent       NONE

¡     SR8800-X-S

<Sysname> display device

Slot No. Brd Type         Brd Status   Software Version

 0       SR07SRPUA1       Standby      SR8800FS-CMW710-RXXXX

 1       SR07SRPUA1       Master       SR8800FS-CMW710-RXXXX

 2       SPC-XP8LB        Normal       SR8800FS-CMW710-RXXXX

 3       NONE             Absent       NONE

 4       NONE             Absent       NONE

 5       NONE             Absent       NONE

 6       NONE             Absent       NONE

 7       MPE-1104         Normal       SR8800FS-CMW710-RXXXX

   Sub1  MIC-GP8L         Normal

   Sub2  MIC-SP4L         Normal

   Sub3  NONE             Absent

   Sub4  MIC-GP4L         Normal

·     单板重启异常

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

2. 常见原因

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

·     单板安装不到位。

·     单板损坏。

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

·     电源模块故障。

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

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

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

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

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

3. 故障分析

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

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

 

4. 故障处理步骤

·     单板状态Absent

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

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

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

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

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

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

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

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

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

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

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

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

·     单板状态Power-off

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

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

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

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

¡     上述步骤的执行结果。

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

·     单板状态Fault

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

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

readed value is 55555555 , expected value is aaaaaaaa

DRAM test fails at: 080ffff8

DRAM test fails at: 080ffff8

Fatal error! Please reboot the board.

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

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

·     单板重启异常

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

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

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

<Sysname> display version

H3C Comware Software, Version 7.1.075, Release XXXX

Copyright (c) 2004-2017 New H3C Technologies Co. Ltd. All rights reserved.

H3C SR8804-X uptime is 0 weeks, 0 days, 4 hours, 24 minutes

Last reboot reason : Cold reboot……

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

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

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

¡     上述步骤的执行结果。

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

5. 告警与日志

相关告警

无。

相关日志

无。

2.4.2  主控板无法启动

1. 故障描述

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

2. 常见原因

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

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

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

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

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

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

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

3. 故障分析

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

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

 

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

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

 

4. 处理步骤

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

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

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

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

 

主控板运行灯状态

指示灯含义

RUN

绿色常灭

表示单板故障或单板不在位

绿色4Hz闪烁

表示软件加载下载过程中

绿色0.5Hz闪烁

表示单板正常工作

 

分以下几种情况处理:

a.     情况1:运行灯快闪

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

b.     情况2:运行灯不亮

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

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

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

说明

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

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

 

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

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

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

System is starting...                                                          

Booting Normal Extended BootWare                                               

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

                                                                               

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

*                                                                          *   

*                         BootWare, Version 1.50                           *   

*                                                                          *   

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

Compiled Date         : May 11 2021                                            

CPU Type              : XLP308                                                 

CPU Clock Speed       : 1200MHz                                                 

Memory Type           : DDR3 SDRAM                                             

Memory Size           : 4096MB                                                 

Memory Speed          : 667MHz                                                  

BootWare Size         : 1536KB                                                 

Flash Size            : 500MB                                                  

cfa0 Size             : 4002MB                                                  

BASIC CPLD Version    : 1.0                                                    

EXTENDED CPLD Version : 1.0                                                    

PCB Version           : Ver.A                                                   

                                                                               

                                                                               

BootWare Validating...

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

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

RAM initialization failed

Fatal error! Please reboot the board.

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

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

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

readed value is 75555555 , expected value is 55555555

DRAM test fails at: 5ff80020

Fatal error! Please reboot the board.

说明

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

 

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

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

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

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

*                                                                          *   

*                         BootWare, Version 1.50                           *   

*                                                                          *   

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

Compiled Date         : May 11 2021                                            

CPU Type              : XLP308                                                  

CPU Clock Speed       : 1200MHz                                                

Memory Type           : DDR3 SDRAM                                             

Memory Size           : 4096MB                                                  

Memory Speed          : 667MHz                                                 

BootWare Size         : 1536KB                                                 

Flash Size            : 500MB                                                  

cfa0 Size             : 4002MB                                                 

BASIC CPLD Version    : 1.0                                                    

EXTENDED CPLD Version : 1.0                                                    

PCB Version           : Ver.A                                                  

                                                                               

                                                                                

BootWare Validating...                                                         

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

Loading the main image files...                                                 

Loading file cfa0:/SR8800-CMW710-SYSTEM-R8261P26.bin........................   

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

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

Loading file cfa0:/SR8800-CMW710-DEVKIT-R8261P26.bin.....Done.                 

Loading file cfa0:/SR8800-CMW710-PACKET-CAPTURE-R8261P26.bin................   

..Done.                                                                         

Loading file cfa0:/SR8800-CMW710-BOOT-R8261P26.bin..........Done.              

                                                                               

Image file cfa0:/SR8800-CMW710-BOOT-R8261P26.bin is self-decompressing......    

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

System image is starting...

b.     情况2:APP不存在

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

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

*                                                                          *   

*                         BootWare, Version 1.50                           *   

*                                                                          *   

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

Compiled Date         : May 11 2021                                            

CPU Type              : XLP308                                                 

CPU Clock Speed       : 1200MHz                                                

Memory Type           : DDR3 SDRAM                                             

Memory Size           : 4096MB                                                 

Memory Speed          : 667MHz                                                 

BootWare Size         : 1536KB                                                 

Flash Size            : 500MB                                                  

cfa0 Size             : 4002MB                                                 

BASIC CPLD Version    : 1.0                                                    

EXTENDED CPLD Version : 1.0                                                    

PCB Version           : Ver.A                                                   

                                                                               

                                                                               

BootWare Validating...

Application program does not exist.

Please input BootWare password:

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

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

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

*                                                                          *   

*                         BootWare, Version 1.50                           *   

*                                                                          *   

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

Compiled Date         : May 11 2021                                            

CPU Type              : XLP308                                                 

CPU Clock Speed       : 1200MHz                                                

Memory Type           : DDR3 SDRAM                                             

Memory Size           : 4096MB                                                 

Memory Speed          : 667MHz                                                 

BootWare Size         : 1536KB                                                 

Flash Size            : 500MB                                                  

cfa0 Size             : 4002MB                                                 

BASIC CPLD Version    : 1.0                                                    

EXTENDED CPLD Version : 1.0                                                    

PCB Version           : Ver.A                                                  

                                                                                

                                                                               

BootWare Validating...                                                         

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

Loading the main image files...                                                

Loading file cfa0:/SR8800-CMW710-SYSTEM-R8261P26.bin........................   

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

Something wrong with the file.

(4)     检查APP启动过程

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

Loading the main image files...

Loading file cfa0:/SR8800-CMW710-BOOT-R8261P26.bin....................

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

  <boot>

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

b.     情况2:System image is starting...,一直挂死

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

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

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

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

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

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

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

(6)     收集诊断信息

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

(7)     寻求技术支持

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

5. 告警与日志

相关告警

无。

相关日志

无。

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

1. 故障描述

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

2. 常见原因

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

·     启动文件损坏。

·     主控板内存单元损坏。

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

3. 故障分析

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

图2-12 故障诊断流程图

 

4. 处理步骤

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

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

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

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

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

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

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

¡     上述步骤的执行结果。

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

5. 告警与日志

相关告警

相关日志

2.4.4  主控板启动慢

1. 故障描述

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

2. 故障处理步骤

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

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

(2)     查看BootWare版本

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

System is starting...

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

Press Ctrl+T to start memory test

Booting Normal Extended BootWare

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

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

*                                                                          *

*                         BootWare, Version 1.45                           *

*                                                                          *

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

Compiled Date         : Jun 20 2018

CPU Type              : XLP316

CPU Clock Speed       : 1200MHz

Memory Type           : DDR3 SDRAM

Memory Size           : 8192MB

Memory Speed          : 667MHz

BootWare Size         : 1536KB

Flash Size            : 500MB

cfa0 Size             : 4002MB

BASIC CPLD Version    : 1.0

EXTENDED CPLD Version : 1.0

PCB Version           : Ver.A

BootWare Validating...

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

Loading the main image files...

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

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

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

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

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

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

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

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

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

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

.Done.

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

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

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

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

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

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

BootWare updated,System is rebooting now.

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

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

Press Ctrl+T to start memory test

Booting Normal Extended BootWare

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

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

*                                                                          *

*                         BootWare, Version 1.46                           *

*                                                                          *

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

Compiled Date         : Oct 19 2018

CPU Type              : XLP316

CPU Clock Speed       : 1200MHz

Memory Type           : DDR3 SDRAM

Memory Size           : 8192MB

Memory Speed          : 667MHz

BootWare Size         : 1536KB

Flash Size            : 500MB

cfa0 Size             : 4002MB

BASIC CPLD Version    : 1.0

EXTENDED CPLD Version : 1.0

PCB Version           : Ver.A

BootWare Validating...

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

Loading the main image files...

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

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

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

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

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

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

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

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

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

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

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

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

System image is starting...

Line con1 is available.

2.4.5  主备倒换故障

1. 故障描述

本类故障常见如下情况:

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

·     主、备倒换异常。

2. 常见原因

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

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

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

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

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

3. 处理步骤

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

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

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

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

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

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

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

<H3C> display system stable state                                                

System state     : Stable                                                        

Redundancy state : Stable                                                        

  Slot    CPU    Role       State                                                

  0       0      Active     Stable                                               

  1       0      Standby    Stable                                               

根据显示信息确认:

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

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

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

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

¡     上述步骤的执行结果。

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

4. 告警与日志

相关告警

相关日志

·     SYSLOG/6/SYSLOG_RESTART

·     DEV/5/BOARD_REBOOT

·     HA/5/HA_BATCHBACKUP_FINISHED

2.4.6  业务板无法启动

1. 故障描述

业务板无法启动。

2. 常见原因

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

·     网板工作异常。

·     供电异常。

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

·     业务板未安装到位。

·     业务板硬件故障。

·     机框槽位硬件故障。

3. 故障分析

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

图2-13 故障诊断流程图

 

 

4. 处理步骤

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

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

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

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

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

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

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

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

(4)     拔插业务板。

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

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

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

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

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

¡     上述步骤的执行结果。

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

5. 告警与日志

相关告警

相关日志

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

1. 故障描述

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

2. 常见原因

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

·     供电异常。

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

·     业务板硬件故障。

·     机框槽位硬件故障。

3. 故障分析

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

图2-14 故障诊断流程图

 

4. 处理步骤

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

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

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

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

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

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

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

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

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

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

<Sysname> display logbuffer

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

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

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

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

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

¡     上述步骤的执行结果。

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

5. 告警与日志

相关告警

相关日志

·     DEV/4/BOARD_LOADING

·     DEV/5/LOAD_FINISHED

2.5  端口故障

2.5.1  端口出现CRC错误

1. 故障描述

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

<Sysname> display interface gigabitethernet3/1/1

GigabitEthernet3/1/1

Current state: DOWN

Line protocol state: DOWN

Description: GigabitEthernet3/1/1 Interface

Bandwidth: 1000000 kbps

Flow-control is not enabled

Maximum transmission unit: 1500

Allow jumbo frames to pass

Broadcast max-ratio: 100%

Multicast max-ratio: 100%

Unicast max-ratio: 100%

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

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

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

Port priority: 0

Loopback is not set

1000Mbps-speed mode, full-duplex mode

Link speed type is autonegotiation, link duplex type is autonegotiation

The maximum frame length is 9216

Last link flapping: Never

Last clearing of counters: Never

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

Last time when physical state changed to up:-

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

Traffic statistic: Not include Inter-frame Gaps and Preambles

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

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

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

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

 Input (total):  2892 packets, 236676 bytes

          24 unicasts, 2 broadcasts, 2866 multicasts, 0 pauses

 Input (normal):  2892 packets, - bytes

          24 unicasts, 2 broadcasts, 2866 multicasts, 0 pauses

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

          3 CRC, 0 frame, - overruns, 0 aborts

          - ignored, - parity errors

 Output (total): 29 packets, 1856 bytes

          24 unicasts, 5 broadcasts, 0 multicasts, 0 pauses

 Output (normal): 29 packets, - bytes

          24 unicasts, 5 broadcasts, 0 multicasts, 0 pauses

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

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

          0 lost carrier, - no carrier

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

2. 常见原因

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

·     端口异常。

·     电缆连接器损坏。

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

·     光功率不足。

·     中间链路或设备故障。

·     设备或单板硬件故障。

3. 故障分析

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

图2-15 故障诊断流程图

 

4. 处理步骤

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5. 告警与日志

相关告警

相关日志

2.5.2  端口不接收报文

1. 故障描述

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

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

2. 常见原因

·     端口出现CRC错误。

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

·     设备或单板硬件故障。

3. 故障分析

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

图2-16 故障诊断流程图

 

4. 处理步骤

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

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

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

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

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

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

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

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

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

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

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

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

5. 告警与日志

相关告警

相关日志

2.5.3  端口不发送报文

1. 故障描述

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

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

2. 常见原因

·     光模块异常。

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

·     设备或单板硬件故障。

3. 故障分析

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

图2-17 故障诊断流程图

 

4. 处理步骤

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

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

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

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

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

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

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

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

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

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

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

5. 告警与日志

相关告警

相关日志

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

1. 故障描述

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

2. 常见原因

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

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

·     设备或单板硬件故障。

3. 故障分析

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

图2-18 故障诊断流程图

 

4. 处理步骤

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

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

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

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

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

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

5. 告警与日志

相关告警

相关日志

2.5.5  电口无法UP

1. 故障描述

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

2. 常见原因

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

·     端口配置问题。

·     网线有问题。

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

3. 故障分析

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

图2-19 故障诊断流程图

 

4. 处理步骤

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

<Sysname> display interface brief

Brief information on interfaces in route mode:

Link: ADM - administratively down; Stby - standby

Protocol: (s) – spoofing

 

Interface            Link Protocol Primary IP      Description

GE3/1/1              DOWN DOWN     --

Loop0                UP   UP(s)    2.2.2.9

NULL0                UP   UP(s)    --

Vlan1                UP   UP       --

Vlan999              UP   UP       192.168.1.42

 

Brief information on interfaces in bridge mode:

Link: ADM - administratively down; Stby - standby

Speed: (a) - auto

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

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

Interface         Link    Speed   Duplex   Type   PVID  Description

GE3/1/2           DOWN    auto     A        A      1    aaaaaaa

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

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

<Sysname> display interface gigabitethernet 3/1/1

GigabitEthernet3/1/1

Current state: Administratively DOWN

Line protocol state: DOWN

Description: GigabitEthernet3/1/1 Interface

Bandwidth: 1000000 kbps

Flow-control is not enabled

Maximum transmission unit: 1500

Allow jumbo frames to pass

Broadcast max-ratio: 100%

Multicast max-ratio: 100%

Unicast max-ratio: 100%

Internet protocol processing: Disabled

...

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

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

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

¡     上述步骤的执行结果。

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

5. 告警与日志

相关告警

相关日志

2.5.6  端口频繁UP/DOWN

1. 故障描述

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

2. 常见原因

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

·     光模块或线缆故障

·     电口自协商不稳定

·     WAN口两端时钟配置问题

3. 故障分析

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

图2-20 故障诊断流程图

 

 

4. 处理步骤

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

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

GigabitEthernet3/1/1 transceiver current alarm information:

  RX loss of signal

  RX power low

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

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

GigabitEthernet3/1/1 transceiver diagnostic information:

  Current diagnostic parameters:

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

    36        3.31        6.13      -35.64          -5.19

  Alarm thresholds:

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

    High   50         3.55        1.44      -10.00         5.00

    Low    30         3.01        1.01      -30.00         0.00

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

(4)     对于WAN口,请检查两端时钟是否配置,需在主控板有时钟扣板的一端配置为Master,另一端配置为Slave

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

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

¡     上述步骤的执行结果。

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

5. 告警与日志

相关告警

相关日志

2.6  光模块故障

2.6.1  光口不UP故障

1. 故障描述

光口不UP。

2. 常见原因

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

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

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

·     光口故障。

·     光模块或线缆故障。

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

3. 故障分析

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

图2-21 故障诊断流程图

 

4. 处理步骤

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

¡     上述步骤的执行结果。

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

5. 告警与日志

相关告警

无。

相关日志

OPTMOD/3/CFG_ERR

OPTMOD/5/CHKSUM_ERR

OPTMOD/5/IO_ERR

OPTMOD/4/FIBER_SFPMODULE_INVALID

OPTMOD/4/FIBER_SFPMODULE_NOWINVALID

OPTMOD/5/MOD_ALM_ON

OPTMOD/5/RX_ALM_ON

OPTMOD/5/RX_POW_HIGH

OPTMOD/5/RX_POW_LOW

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

1. 故障描述

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

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

2. 常见原因

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

3. 故障分析

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

图2-22 故障诊断流程图

 

4. 处理步骤

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

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

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

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

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

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

¡     上述步骤的执行结果。

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

5. 告警与日志

相关告警

无。

相关日志

OPTMOD/4/PHONY_MODULE

2.6.3  光模块不支持数字诊断

1. 故障描述

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

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

The transceiver does not support this function.

2. 常见原因

·     光模块为非H3C光模块。

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

·     光模块故障。

·     设备/光口故障。

3. 故障分析

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

图2-23 故障诊断流程图

 

4. 处理步骤

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

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

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

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

¡     上述步骤的执行结果。

¡     设备的告警信息。

5. 告警与日志

相关告警

无。

相关日志

无。

2.6.4  光模块序列号丢失

1. 故障描述

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

2. 常见原因

·     光模块未插紧。

·     光模块/设备故障。

3. 故障分析

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

图2-24 故障诊断流程图

 

4. 处理步骤

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

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

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

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

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

¡     上述步骤的执行结果。

¡     设备的告警信息。

5. 告警与日志

相关告警

无。

相关日志

无。

2.7  硬件转发故障

2.7.1  HG故障

1. 故障描述

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

·     对于CEPC类单板、MPE-1104单板和SPC单板可以通过display hardware internal hgmonitor info命令用来显示指定槽位单板的指定芯片的转发通道检测记录。

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

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

  Link status change notice event:

  Unit    Port    Link    Clock                         Number

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

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

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

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

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

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

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

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

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

……

5 HG

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

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

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

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

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

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

 OUT

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

 OUT

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

 OUT

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

 OUT

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

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

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

 IN

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

 IN

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

 IN

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

 IN

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

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

……

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

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

SERDES  STATUS  NP_PORT  IF_NUM  PEER_SLOT  IF_TYPE

20      UP      106      10      23         40GE(UP)

21      UP      106      10      23         40GE(UP)

22      UP      106      10      23         40GE(UP)

23      UP      106      10      23         40GE(UP)

8       DOWN    104      8       23         40GE(DOWN)

9       DOWN    104      8       23         40GE(DOWN)

10      DOWN    104      8       23         40GE(DOWN)

11      DOWN    104      8       23         40GE(DOWN)

 Hg port tuning Record:

 Port     Event         Clock

  10 Tuning_start    09:41:03:039327

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

  10 Switch_Route    09:41:24:705325

   8 Tuning_start    09:41:04:118068

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

   8 Switch_Route    09:41:24:705327

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

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

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

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

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

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

上述信息表示转发链路可能存在故障,上报综合诊断模块进行修复。(仅适用于CSPEX类单板(CSPEX-1104-E和CSPEX-1802X除外)、SPE类单板和CEPC类单板)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. 常见原因

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

·     交换网板故障。

·     业务板故障。

3. 故障分析

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

图2-25 故障诊断流程图

 

4. 处理步骤

对于SR8800-X路由器,由于主控板和交换网板分离,交换网板负责业务流量转发,流量在多块交换网板之间负载分担,而主控板仅负责控制管理,不参与业务流量转发。

(1)     SR8804-X路由器上使用的是交换网板型号为SFC-04-1、SFC-04-2、SFC-04-3和SFC-04-4,请直接联系技术支持人员;

(2)     如果流量的入端口和出端口在同一SPC单板或MPE-1104单板上,请直接联系技术支持人员;

(3)     如果流量的入端口和出端口在同一SPEX类单板、CSPEX类单板、CEPC类单板上或者流量的入端口和出端口不在同一单板上,请在系统视图下执行switch-fabric isolate命令逐块隔离交换网板(确保交换网板数量大于等于1,且不能只剩余第二块交换网板),观察交换网板隔离后故障是否消失。以SR8808-X为例说明网板隔离步骤,其中1013槽位为交换网板:

a.     隔离10号槽位交换网板,隔离后等待一段时间(大约等待1分钟),观察故障是否消失。

b.     执行undo switch-fabric isolate命令取消10号槽位交换网板隔离,待网板重启Normal后,再等待一段时间(大约等待3分钟以上),隔离11槽位网板并观察故障是否消失。

c.     按照上面的方法,依次隔离12~13槽位网板,直到所有网板隔离确认一遍。

(4)     如果隔离某块交换网板后故障消失,说明该交换网板故障;如果所有交换网板隔离一遍后故障仍存在,那么应该为接口板故障导致,建议将该接口板上的业务转移到其他接口板之后再通过单板隔离或更换接口板的方式进一步确认。

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

¡     上述步骤的执行结果。

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

对于SR8800-X-S路由器,由于没有单独的交换网板,不支持网板隔离命令,请直接联系技术支持人员。

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

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

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

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

¡     上述步骤的执行结果。

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

5. 告警与日志

相关告警

相关日志

2.7.2  FMEA故障

1. 故障描述

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

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

2. 故障处理步骤

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

 

2.8  故障诊断命令

命令

说明

display device

显示设备信息,检查各单板的状态是否正常

display environment

显示路由器的温度信息,检查环境温度是否正常(是否超出温度告警阈值)

display fan

显示设备内置风扇的工作状态

display fan-speed

显示设备当前风扇转速

display power

显示设备内置电源的工作状态

display version

显示系统版本信息、单板的运行时间以及最后一次重启的原因

save

将当前配置保存到指定文件

temperature-limit

设置设备的温度告警门限

 


3 基础配置类故障处理

3.1  登录设备类故障处理

3.1.1  Console口密码遗忘

1. 故障描述

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

2. 常见原因

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

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

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

3. 故障分析

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

图3-1 Console口密码遗忘故障诊断流程图

 

4. 处理步骤

(1)     确认是否能过通过Telnet/Stelnet方式登录设备。

如果管理员拥有Telnet/Stelnet账号,并且该账号拥有network-admin/level-15用户角色,则可以通过Telnet/Stelnet方式登录到设备后修改Console口登录相关配置。具体的处理步骤如下:

a.     使用Telnett/Stelnet账号登录设备,执行display line命令查看Console口所在用户线的认证方式。

<Sysname> display line

  Idx  Type     Tx/Rx      Modem Auth  Int          Location

  0    CON 0    9600       -     P     -            0/0

+ 81   VTY 0               -     N     -            0/0

...

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

b.     确认当前登录的Telnet/Stelnet用户是否具有network-admin/level-15用户角色。

对于采用none或者password认证方式登录的用户,可在当前登录的用户线视图下查看用户角色配置是否为network-admin/level-15;对于采用scheme认证方式登录的用户,用户角色由AAA授权,需要查看对应的本地账号或远程账号的授权用户角色属性。

<Sysname> system-view

[Sysname-line-vty0] display this

#

line con 0

 authentication-mode password

 user-role network-admin

#

line vty 0 63

 authentication-mode none

 user-role network-admin

#

return

如果用户角色不是network-admin/level-15,则当前登录的账户没有更改Console口相关配置的权限,请执行步骤(2);如果用户角色为network-admin/level-15,请根据Console口的认证方式采用不同的处理步骤。

c.     Console口采用密码认证方式的情况下,修改Console口认证密码。

进入Console口所在的用户线,设置新的密码(下例中为1234567890!)。同时,建议将用户角色设置为network-admin/level-15,避免Console口登录后用户权限过低。

[Sysname] line console 0

[Sysname-line-console0] set authentication password simple 1234567890!

[Sysname-line-console0] user-role network-admin

d.     Console口采用AAA本地认证方式的情况下,修改Console口的本地用户密码。

进入Console口登录所使用账户的本地用户视图,修改本地用户的密码(下例中用户名为admin,用户密码为1234567890!)。同时,建议将用户角色设置为network-admin/level-15,避免Console口登录后用户权限过低。

[Sysname] local-user admin class manage

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

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

e.     Console口采用AAA远程认证方式的情况下,请联系AAA服务器管理员获取登录密码。

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

(2)     通过Console口连接设备后,断电重启设备,进入BootWare菜单。

说明

·     进入到BootWare菜单需要重启设备,会导致业务中断,请视具体情况做好备份,并尽量选择业务量较少的时间操作。

·     对于分布式设备,请通过Console口分别连接主备板后整机重启。当分别进入到各自的BootWare扩展菜单后,按照下面的操作步骤首先完成主控板上的所有配置,然后再重启备板。

 

系统启动后,如果未及时选择进入基本段,则会直接运行BootWare扩展段程序。当显示信息出现“Press Ctrl+B to access EXTENDED-BOOTWARE MENU...”时,键入<Ctrl+B>,系统会首先给出密码恢复功能是否开启的提示信息:

Password recovery capability is enabled.

Password recovery capability is disabled.

¡     密码恢复功能处于开启状态时,可以选择跳过Console口认证选项,或者跳过当前配置选项。具体操作过程请分别参见步骤(3)、(4)。

¡     密码恢复功能处于关闭状态时,可以选择恢复出厂配置选项。具体操作过程请执行步骤(5)。

(3)     通过BootWare扩展段菜单跳过Console口认证,登录后修改Console口密码。

直接回车,进入BootWare扩展段主菜单后,请按照系统提示选择相应的菜单选项跳过Console口认证(不同产品跳过Console口认证的菜单选项不同,请以实际情况为准)。系统启动后,不需要管理员输入Console口密码,会正常完成所有配置的加载。

a.     启动后,请尽快根据Console口采用的认证方式修改密码。

-     Console口采用密码认证方式的情况下,修改Console口认证密码。

进入Console口所在的用户线,设置新的密码(下例中为1234567890!)。同时,建议将用户角色设置为network-admin/level-15,避免Console口登录后用户权限过低。

<Sysname> system-view

[Sysname] line console 0

[Sysname-line-console0] set authentication password simple 1234567890!

[Sysname-line-console0] user-role network-admin

-     Console口采用AAA本地认证方式的情况下,修改Console口的本地用户密码。

进入Console口登录所使用账户的本地用户视图,修改本地用户的密码(下例中用户名为admin,用户密码为1234567890!)。同时,建议将用户角色设置为network-admin/level-15,避免Console口登录后用户权限过低。

<Sysname> system-view

[Sysname] local-user admin class manage

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

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

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

(4)     通过BootWare扩展段菜单跳过当前配置,登录后配置新的Console口密码。

直接回车,进入BootWare扩展段主菜单后,请按照系统提示选择相应的菜单选项跳过当前配置(不同产品跳过当前配置的菜单选项不同,请以实际情况为准)。系统启动时,将忽略配置文件中的所有配置以空配置进行启动(该选项每次设置后仅生效一次)。系统启动后,不需要管理员输入Console口密码。

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

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

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

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

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

<Sysname> startup saved-configuration startup.cfg

d.     重启设备。

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

说明

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

 

直接回车,进入BootWare扩展段主菜单后,请按照系统提示选择相应的子菜单恢复出厂配置(不同产品恢复出厂配置的菜单选项不同,请以实际情况为准)。系统启动后,不需要管理员输入Console口密码。

a.     启动后,请根据实际需要配置Console口的登录认证方式,以及相关的登录密码或登录账户。

-     认证方式为none

<Sysname> system-view

[Sysname] line console 0

[Sysname-line-console0] authentication-mode none

[Sysname-line-console0] user-role network-admin

该方式下,用户不需要输入用户名和密码,就可以使用该用户线登录设备,存在安全隐患,请谨慎配置。

-     认证方式为密码认证

<Sysname> system-view

[Sysname] line console 0

[Sysname-line-console0] authentication-mode password

[Sysname-line-console0] set authentication password simple 1234567890!

[Sysname-line-console0] user-role network-admin

-     认证方式为本地AAA认证

<Sysname> system-view

[Sysname] line console 0

[Sysname-line-console0] authentication-mode scheme

[Sysname-line-console0] quit

[Sysname] local-user admin class manage

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

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

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

-     认证方式为远程AAA认证

<Sysname> system-view

[Sysname] line console 0

[Sysname-line-console0] authentication-mode scheme

[Sysname-line-console0] quit

除此之外,还需要配置Login用户的认证域,以及RADIUS、HWTACACS或LDAP方案。相关配置的详细介绍请参见“BRAS业务配置指导”中的“AAA”。

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

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

¡     上述步骤的执行结果。

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

5. 告警与日志

相关告警

相关日志

3.1.2  Telnet登录密码遗忘

1. 故障描述

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

2. 常见原因

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

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

·     Telnet登录账户已过期。

3. 故障分析

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

图3-2 Console口密码遗忘故障诊断流程图

 

4. 处理步骤

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

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

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

<Sysname> display line

  Idx  Type     Tx/Rx      Modem Auth  Int          Location

+ 0    CON 0    9600       -     P     -            0/0

  81   VTY 0               -     P     -            0/0

...

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

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

-     采用密码认证

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

<Sysname> system-view

[Sysname] line vty 0 63

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

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

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

-     采用AAA本地认证

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

<Sysname> system-view

[Sysname] line vty 0 63

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

[Sysname-line-vty0-63] quit

[Sysname] local-user admin class manage

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

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

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

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

-     采用AAA远程认证

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

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

¡     上述步骤的执行结果。

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

5. 告警与日志

相关告警

相关日志

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

3.2.1  使用配置文件恢复配置

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

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

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

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

<Sysname> ftp 192.168.33.13

Press CTRL+C to abort.

Connected to 192.168.33.13 (192.168.33.13).

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

User (192.168.33.13:(none)): 1

331 Give me your password, please

Password:

230 Logged in successfully

Remote system type is MSDOS.

ftp> binary

200 TYPE is now 8-bit binary

ftp> get config.cfg

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

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

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

226 Transfer finished successfully.

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

ftp> quit

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

221 Logout.

# 将主用主控板的config.cfg配置文件拷贝到备用主控板。

<Sysname> copy config.cfg slot1#cfa0:/config.cfg

Copy cfa0:/config.cfg to slot1#cfa0:/config.cfg? [Y/N]:y

Copying file cfa0:/config.cfg to slot1#cfa0:/config.cfg...Done.

(2)     设置下次启动时使用的配置文件,以便下次启动后设备恢复到此配置。

<Sysname> startup saved-configuration config.cfg

需要注意的是,如果用于恢复的配置文件名为config.cfg(和设备缺省启动的配置文件名相同),则本步骤可选;如果不是config.cfg,则本步骤必选。

(3)     重启设备,重启完成后设备会以上面设置的配置文件恢复配置。

说明

上述步骤的操作过程中,不能进行save命令的操作,否则设备将以当前保存的配置启动。

 


4 虚拟化技术类故障处理

4.1  IRF组建失败

4.1.1  故障描述

多台设备无法组建IRF,或者新设备无法加入现有的IRF。

4.1.2  常见原因

本类故障的常见原因主要包括:

·     IRF成员设备数量超出了产品支持的规格,导致新设备无法加入现有的IRF。

·     配置不符合IRF要求,导致无法组建IRF,或者新设备无法加入现有的IRF。

·     IRF物理端口、线缆和物理拓扑不符合IRF要求,导致IRF链路无法达到up状态。

4.1.3  故障分析

本类故障的诊断流程如图4-1所示。

图4-1 IRF组建失败故障诊断流程图

 

4.1.4  SR8800-X故障处理步骤

注意

本文仅列出组建IRF的常规要求,以供参考。组建IRF的完整要求请参见产品配套的《IRF配置指导》。

 

(1)     检查IRF成员数量是否已达到系统支持的最大值。

请使用display irf命令查看当前IRF中的成员设备数量。如果IRF成员数量已经达到系统支持的最大值,则不允许再加入成员设备。

同一IRF域内,允许加入的成员设备最多为2台。

(2)     检查各成员设备使用的软件版本是否一致。

使用display version命令查看每台设备当前运行的软件版本,只有使用相同软件版本的设备才能组成IRF。

IRF系统启动文件自动加载功能(缺省为开启状态)可以自动将成员设备的软件版本与IRF中主设备进行同步,但是在成员设备与主设备的软件版本差异过大时,自动升级可能无法成功执行。此时,需要分别升级每台成员设备,使得所有成员设备的软件版本一致,之后再组建IRF。

如果成员设备使用双主控,请同时升级两块主控板,保证所有成员设备的所有主控板上运行的软件版本相同。

(3)     检查IRF的配置是否满足相关要求。

a.     确保设备运行在IRF模式。

部分产品出厂即为IRF模式,且不支持模式切换;部分产品出厂为独立运行模式,支持模式切换。如果设备当前支持display irf link或者display irf topology命令,则说明设备运行在IRF模式。否则,设备运行在独立运行模式,需要先在系统视图执行chassis convert mode irf命令将设备切换到IRF模式。

<Sysname> display irf ?

  >              Redirect it to a file

  >>             Redirect it to a file in append mode

  configuration  IRF configuration that will be valid after reboot

  link           Display link status

  topology       Topology information

  |              Matching output

  <cr>

b.     确保设备的成员编号在IRF中唯一。

请使用display irf命令查看IRF中各成员设备的成员编号。IRF中各成员设备必须使用不同的编号,编号相同的设备不能建立或加入IRF。设备缺省成员编号为1,在独立运行模式下可通过irf member命令修改,在IRF模式下可通过irf member renumber命令修改。修改后需要保存配置并重启该设备,新编号才能生效。

c.     确保各成员设备的出厂桥MAC地址不同

具有相同出厂桥MAC的成员设备之间不能组成IRF。通常情况下,设备出厂会携带全网唯一的桥MAC地址。如果IRF组建失败,且输出了日志信息“Failed to stack because of the same bridge MAC addresses.”,则表明两台设备的出厂桥MAC相同,可在其中一台设备上执行irf mac-address命令修改桥MAC。

d.     确保同一IRF系统中所有成员设备的IRF域编号一致。

IRF域编号不影响IRF的组建和合并,但是会影响MAD检测。为了使MAD功能正常工作,请确保同一IRF系统中所有成员设备的IRF域编号一致。IRF域编号缺省值为0。在单台设备上执行display irf命令,可通过显示信息中的Domain ID字段查看IRF域编号。如果设备的IRF域编号和其它设备不同,可在该设备上执行irf domain命令修改。

(4)     检查IRF端口的状态,使其变成UP状态。

IRF端口是一种专用于IRF连接的逻辑接口,需要与物理端口绑定后才能生效。请通过display irf topology命令显示信息的Link字段来确认IRF端口的状态。

<Sysname> display irf topology

                              Topology Info

 -------------------------------------------------------------------------

               IRF-Port1                IRF-Port2

 MemberID    Link       neighbor      Link       neighbor    Belong To

 2           DIS        ---           UP         1           5e40-08d9-0104

 1           UP         2             DIS        ---         5e40-08d9-0104

¡     如果Link字段取值为UP,则表示IRF端口连接正常,无需处理。

¡     如果Link字段取值为DIS,则表示该IRF端口还没有和任何IRF物理端口绑定。请根据组网需要在IRF端口视图下使用port group interface命令进行绑定。

¡     如果Link字段取值为DOWN,请使用display irf link命令进一步检查IRF物理端口的状态是否为UP。

-     如果IRF物理端口的状态为UP,但IRF端口的状态为DOWN,原因可能是IRF端口的配置未激活。请在系统视图下执行irf-port-configuration active命令激活IRF端口。

-     如果IRF物理端口的状态不是UP,请参照步骤(5)定位IRF物理端口的问题。

¡     如果Link字段取值为TIMEOUT,表明IRF Hello报文超时,IRF链路通信存在问题。可参照以下步骤先定位IRF报文超时问题。

-     确认是否因为对端IRF端口状态异常,导致IRF报文无法互通:登录IRF链路的对端设备,在对端设备上执行display irf topologydisplay irf link,根据显示的状态信息进行定位。

-     确认是否存在网络环路,导致IRF报文丢包:使用display counters rate inbound interface命令查看IRF物理端口的报文速率统计信息,确认IRF链路上是否存在报文风暴。如果存在报文风暴,请检查是否存在物理环路以及VLAN和STP配置是否正确等,先解决报文风暴问题。

-     使用display device命令检查网板状态是否正常。如果不正常,请先定位网板问题。

¡     如果Link字段取值为ISOLATE,表明该成员设备处于隔离状态。执行display logbuffer | include “STM stackability check”,并根据显示结果处理:

-     如果显示信息中包含“STM stackability check: Product series is inconsistency”字样,则说明成员设备的型号不符合IRF要求,请参考步骤(7)处理。

-     如果显示信息中包含“STM stackability check: Product xxx is inconsistency”字样,xxx取值可能为system working mode等,则说明当前系统参数配置不符合IRF要求,请参考步骤(8)处理。

(5)     检查IRF物理端口的状态,使其变成UP状态。

请通过display irf link命令查看IRF物理端口的状态。如果显示信息中:

¡     Interface字段取值为disable,表示该IRF端口还没有和IRF物理端口绑定。

¡     Interface字段为物理接口的名称,请继续检查Status字段。Status字段的取值及含义如下:

-     UP:链路up,无需处理

-     DOWN:链路down,请检查IRF物理端口的光模块/光纤或者电缆是否工作正常。请使用符合产品要求的物理接口作为IRF物理端口,使用符合产品要求的线缆来连接IRF物理端口,并执行步骤(6)。

-     ADM:表示该接口通过shutdown命令被关闭,即管理状态为关闭。您需要执行undo shutdown命令将其开启。

-     ABSENT:接口不存在。请插入单板或接口模块扩展卡。

(6)     检查IRF物理连线是否符合要求。

可通过以下步骤来定位IRF物理连接问题:

a.     在每台成员设备上通过display irf configuration命令查看IRF端口与IRF物理端口的绑定关系。检查绑定的物理接口和实际连接的物理接口是否一致,如果不一致,请重新配置绑定关系或重新进行物理连接。

b.     检查IRF物理端口的连接状况,是否满足相邻设备的连接要求。连接两台相邻的成员设备时,一台设备上IRF-Port1绑定的IRF物理端口只能和邻居成员设备IRF-Port2绑定的IRF物理端口相连。且当两台成员设备组建IRF时,只能使用链型拓扑,不允许使用环形拓扑。

(7)     检查成员设备的硬件是否符合IRF的要求。

a.     仅SR8804-X、SR8808-X或SR8812-X路由器之间,SR8808H-X和SR8808H-X路由器之间,SR8816-X和SR8816-X路由器之间可以建立IRF,其他路由器暂不支持建立IRF。

# 使用display version命令查看设备型号。

<Sysname> display version

H3C Comware Software, Version 7.1.075, ESS 8309

Copyright (c) 2004-2022 New H3C Technologies Co., Ltd. All rights reserved.

H3C CR16006-F uptime is 0 weeks, 3 days, 3 hours, 11 minutes

b.     确认成员设备的软件版本、主控板类型、OEM Flag是否一致,确认组成IRF的两台设备上均配置为A类交换网板或丝印完全相同的其他类型交换网板。

# 使用display device命令查看主控板、接口板的型号。

<Sysname-1> display device

Chassis   Slot No. Brd Type         Brd Status   Software Version

1         0        NONE             Absent       NONE

1         1        SR05SRP1L3       Master       SR8800-CMW710-RXXXX

1         2        NONE             Absent       NONE

1         3        NONE             Absent       NONE

1         4        SPC-XP8LB        Normal       SR8800-CMW710-RXXXX

1         5        SPC-XP8LB        Normal       SR8800-CMW710-RXXXX

1         6        SFC-04D          Normal       SR8800-CMW710-RXXXX

1         7        NONE             Absent       NONE

1         8        NONE             Absent       NONE

1         9        NONE             Absent       NONE

<Sysname-2> display device

Chassis   Slot No. Brd Type         Brd Status   Software Version

2         0        NONE             Absent       NONE

2         1        SPC-CP1LCX       Normal       SR8800-CMW710-RXXXX

2         2        NONE             Absent       NONE

2         3        NONE             Absent       NONE

2         4        SR05SRP1L3       Standby      SR8800-CMW710-RXXXX

2         5        SR05SRP1L3       Standby      SR8800-CMW710-RXXXX

2         6        NONE             Absent       NONE

2         7        SPC-XP8LB        Normal       SR8800-CMW710-RXXXX

2         8        NONE             Absent       NONE

2         9        NONE             Absent       NONE

2         10       SFC-08B          Normal       SR8800-CMW710-RXXXX

2         11       NONE             Absent       NONE

2         12       NONE             Absent       NONE

2         13       NONE             Absent       NONE

# 使用display hardware internal sysm eeprom命令用来读取EEPROM的信息。

[H3C-probe]display hardware internal sysm eeprom 380 4 5

0x380:  0xa5 0x8 0x59 0x2

(8)     检查系统参数配置是否满足IRF的要求。

部分产品会要求设备的系统工作模式以及MAC数目的配置相同,否则无法组建IRF。(不同产品的具体要求不同,请以设备的实际情况为准)

¡     使用display system-working-mode命令可查看设备的系统工作模式,使用system-working-mode命令可将设备的系统工作模式修改为相同值。修改系统工作模式后请重启该设备,使修改的工作模式生效。

¡     使用display hardware internal lif interface-mac slot命令行查看MAC数目。

[Sysname-probe] display hardware internal lif interface-mac slot 1

 System Total MAC Number: 512

---------------------- MAC Information ------------------------

 Total MAC Number      :  512

  MDCID                :  1

  Bridge MAC           :  1234-5678-9000

  M-Ethernet MAC       :  1234-5678-9001

  Global Interface MAC :  1234-5678-9002 (VLAN RAGG RPR VE-VPN)

  Router Intf Base MAC :  1234-5678-9036 (NP Router interface)

4.1.5  SR8800-X-S故障处理步骤

注意

本文仅列出组建IRF的常规要求,以供参考。组建IRF的完整要求请参见产品配套的《IRF配置指导》。

 

(1)     检查IRF成员数量是否已达到系统支持的最大值。

请使用display irf命令查看当前IRF中的成员设备数量。如果IRF成员数量已经达到系统支持的最大值,则不允许再加入成员设备。

同一IRF域内,允许加入的成员设备最多为2台。

(2)     检查各成员设备使用的软件版本是否一致。

使用display version命令查看每台设备当前运行的软件版本,只有使用相同软件版本的设备才能组成IRF。

IRF系统启动文件自动加载功能(缺省为开启状态)可以自动将成员设备的软件版本与IRF中主设备进行同步,但是在成员设备与主设备的软件版本差异过大时,自动升级可能无法成功执行。此时,需要分别升级每台成员设备,使得所有成员设备的软件版本一致,之后再组建IRF。

如果成员设备使用双主控,请同时升级两块主控板,保证所有成员设备的所有主控板上运行的软件版本相同。

(3)     检查IRF的配置是否满足相关要求。

a.     确保设备运行在IRF模式。

部分产品出厂即为IRF模式,且不支持模式切换;部分产品出厂为独立运行模式,支持模式切换。如果设备当前支持display irf link或者display irf topology命令,则说明设备运行在IRF模式。否则,设备运行在独立运行模式,需要先在系统视图执行chassis convert mode irf命令将设备切换到IRF模式。

<Sysname> display irf ?

  >              Redirect it to a file

  >>             Redirect it to a file in append mode

  configuration  IRF configuration that will be valid after reboot

  link           Display link status

  topology       Topology information

  |              Matching output

  <cr>

b.     确保设备的成员编号在IRF中唯一。

请使用display irf命令查看IRF中各成员设备的成员编号。IRF中各成员设备必须使用不同的编号,编号相同的设备不能建立或加入IRF。设备缺省成员编号为1,在独立运行模式下可通过irf member命令修改,在IRF模式下可通过irf member renumber命令修改。修改后需要保存配置并重启该设备,新编号才能生效。

c.     确保各成员设备的出厂桥MAC地址不同

具有相同出厂桥MAC的成员设备之间不能组成IRF。通常情况下,设备出厂会携带全网唯一的桥MAC地址。如果IRF组建失败,且输出了日志信息“Failed to stack because of the same bridge MAC addresses.”,则表明两台设备的出厂桥MAC相同,可在其中一台设备上执行irf mac-address命令修改桥MAC。

d.     确保同一IRF系统中所有成员设备的IRF域编号一致。

IRF域编号不影响IRF的组建和合并,但是会影响MAD检测。为了使MAD功能正常工作,请确保同一IRF系统中所有成员设备的IRF域编号一致。IRF域编号缺省值为0。在单台设备上执行display irf命令,可通过显示信息中的Domain ID字段查看IRF域编号。如果设备的IRF域编号和其它设备不同,可在该设备上执行irf domain命令修改。

(4)     检查IRF端口的状态,使其变成UP状态。

IRF端口是一种专用于IRF连接的逻辑接口,需要与物理端口绑定后才能生效。请通过display irf topology命令显示信息的Link字段来确认IRF端口的状态。

<Sysname> display irf topology

                              Topology Info

 -------------------------------------------------------------------------

               IRF-Port1                IRF-Port2

 MemberID    Link       neighbor      Link       neighbor    Belong To

 2           DIS        ---           UP         1           5e40-08d9-0104

 1           UP         2             DIS        ---         5e40-08d9-0104

¡     如果Link字段取值为UP,则表示IRF端口连接正常,无需处理。

¡     如果Link字段取值为DIS,则表示该IRF端口还没有和任何IRF物理端口绑定。请根据组网需要在IRF端口视图下使用port group interface命令进行绑定。

¡     如果Link字段取值为DOWN,请使用display irf link命令进一步检查IRF物理端口的状态是否为UP。

-     如果IRF物理端口的状态为UP,但IRF端口的状态为DOWN,原因可能是IRF端口的配置未激活。请在系统视图下执行irf-port-configuration active命令激活IRF端口。

-     如果IRF物理端口的状态不是UP,请参照步骤(5)定位IRF物理端口的问题。

¡     如果Link字段取值为TIMEOUT,表明IRF Hello报文超时,IRF链路通信存在问题。可参照以下步骤先定位IRF报文超时问题。

-     确认是否因为对端IRF端口状态异常,导致IRF报文无法互通:登录IRF链路的对端设备,在对端设备上执行display irf topologydisplay irf link,根据显示的状态信息进行定位。

-     确认是否存在网络环路,导致IRF报文丢包:使用display counters rate inbound interface命令查看IRF物理端口的报文速率统计信息,确认IRF链路上是否存在报文风暴。如果存在报文风暴,请检查是否存在物理环路以及VLAN和STP配置是否正确等,先解决报文风暴问题。

-     使用display device命令检查网板状态是否正常。如果不正常,请先定位网板问题。

¡     如果Link字段取值为ISOLATE,表明该成员设备处于隔离状态。执行display logbuffer | include “STM stackability check”,并根据显示结果处理:

-     如果显示信息中包含“STM stackability check: Product series is inconsistency”字样,则说明成员设备的型号不符合IRF要求,请参考步骤(7)处理。

-     如果显示信息中包含“STM stackability check: Product xxx is inconsistency”字样,xxx取值可能为system working mode等,则说明当前系统参数配置不符合IRF要求,请参考步骤(8)处理。

(5)     检查IRF物理端口的状态,使其变成UP状态。

请通过display irf link命令查看IRF物理端口的状态。如果显示信息中:

¡     Interface字段取值为disable,表示该IRF端口还没有和IRF物理端口绑定。

¡     Interface字段为物理接口的名称,请继续检查Status字段。Status字段的取值及含义如下:

-     UP:链路up,无需处理

-     DOWN:链路down,请检查IRF物理端口的光模块/光纤或者电缆是否工作正常。请使用符合产品要求的物理接口作为IRF物理端口,使用符合产品要求的线缆来连接IRF物理端口,并执行步骤(6)。

-     ADM:表示该接口通过shutdown命令被关闭,即管理状态为关闭。您需要执行undo shutdown命令将其开启。

-     ABSENT:接口不存在。请插入单板或接口模块扩展卡。

(6)     检查IRF物理连线是否符合要求。

可通过以下步骤来定位IRF物理连接问题:

a.     在每台成员设备上通过display irf configuration命令查看IRF端口与IRF物理端口的绑定关系。检查绑定的物理接口和实际连接的物理接口是否一致,如果不一致,请重新配置绑定关系或重新进行物理连接。

b.     检查IRF物理端口的连接状况,是否满足相邻设备的连接要求。连接两台相邻的成员设备时,一台设备上IRF-Port1绑定的IRF物理端口只能和邻居成员设备IRF-Port2绑定的IRF物理端口相连。且当两台成员设备组建IRF时,只能使用链型拓扑,不允许使用环形拓扑。

(7)     检查成员设备的硬件是否符合IRF的要求。

a.     SR8802-X-S路由器不支持组建IRF。SR8803-X-S、SR8806-X-S或SR8810-X-S路由器之间可以建立IRF,但不能与其他系列的路由器建立IRF。并且 SR8803-X-S、SR8806-X-S或SR8810-X-S路由器上组建IRF必须使用主控板上的MCC 10GE口作为IRF物理端口。

# 使用display version命令查看设备型号。

<Sysname> display version

H3C Comware Software, Version 7.1.075, ESS 8309

Copyright (c) 2004-2022 New H3C Technologies Co., Ltd. All rights reserved.

H3C SR8803-X-S uptime is 0 weeks, 3 days, 3 hours, 11 minutes

b.     确认成员设备的软件版本、主控板类型、OEM Flag是否一致,确认组成IRF的两台设备上均配置为A类交换网板或丝印完全相同的其他类型交换网板。

# 使用display device命令查看主控板、接口板的型号。

<Sysname> display device

Chassis   Slot No. Brd Type         Brd Status   Software Version

1         0        NONE             Absent       NONE

1         1        NONE             Absent       NONE

1         2        NONE             Absent       NONE

1         3        NONE             Absent       NONE

1         4        NONE             Absent       NONE

1         5        NONE             Absent       NONE

1         6        SR07SRPUD3       Master       SR8800-CMW710-RXXXX

1         7        NONE             Absent       NONE

1         8        NONE             Absent       NONE

1         9        NONE             Absent       NONE

1         10       NONE             Absent       NONE

1         11       NONE             Absent       NONE

# 使用display hardware internal sysm eeprom命令用来读取EEPROM的信息。

[H3C-probe]display hardware internal sysm eeprom 380 4 5

0x380:  0xa5 0x8 0x59 0x2

(8)     检查系统参数配置是否满足IRF的要求。

部分产品会要求设备的系统工作模式以及MAC数目的配置相同,否则无法组建IRF。(不同产品的具体要求不同,请以设备的实际情况为准)

¡     使用display system-working-mode命令可查看设备的系统工作模式,使用system-working-mode命令可将设备的系统工作模式修改为相同值。修改系统工作模式后请重启该设备,使修改的工作模式生效。

¡     使用display hardware internal lif interface-mac slot命令行查看MAC数目。

[Sysname-probe] display hardware internal lif interface-mac slot 1

 System Total MAC Number: 512

---------------------- MAC Information ------------------------

 Total MAC Number      :  512

  MDCID                :  1

  Bridge MAC           :  1234-5678-9000

  M-Ethernet MAC       :  1234-5678-9001

  Global Interface MAC :  1234-5678-9002 (VLAN RAGG RPR VE-VPN)

  Router Intf Base MAC :  1234-5678-9036 (NP Router interface)

4.1.6  告警与日志

相关告警

模块名:HH3C-STACK-MIB

·     hh3cStackPhysicalIntfLinkDown(1.3.6.1.4.1.25506.2.91.6.0.8)

·     hh3cStackPhysicalIntfRxTimeout (1.3.6.1.4.1.25506.2.91.6.0.9)

相关日志

·     STM/3/STM_LINK_DOWN

·     STM/2/STM_LINK_TIMEOUT

·     STM/6/STM_LINK_UP

·     STM/4/STM_SAMEMAC

·     STM/3/STM_SOMER_CHECK

4.2  IRF成员设备异常重启

4.2.1  故障描述

堆叠过程中发生了主设备或者备设备异常重启,导致堆叠分裂。

4.2.2  常见原因

本类故障的常见原因主要包括:

·     从设备自动重启来完成软件版本的升级。

·     IRF合并,导致从设备重启。

·     设备软件或者硬件故障,导致设备异常重启,来尝试修复故障。

4.2.3  处理步骤

(1)     检查重启的设备是否为从设备。

¡     如果是从设备,请执行步骤(2)。

¡     如果不是从设备,是主设备,请执行步骤(4)。

(2)     检查从设备是否因为自动加载启动文件,升级导致的重启

¡     如果从设备是因为自动加载启动文件,升级导致的重启,则该重启为正常重启,无需处理。

¡     如果从设备不是因为自动加载启动文件,升级导致的重启,请继续执行步骤(3)。

您可通过以下方式确认从设备的重启原因:IRF要求所有成员设备上运行的软件版本必须一致。当IRF开启了启动文件的自动加载功能,且有新设备加入IRF时,如果新设备的软件版本和主设备的软件版本不一致,则新设备会自动从主设备下载启动文件,然后使用新的启动文件重启并以从设备角色加入IRF。Probe视图下,执行display system internal irf msg命令,如果显示信息中有“Version is different, and the sender CPU MAC is xxxx-xxxx-xxxx (chassis xx slot xx).”类似信息,表示CPU MAC为xxxx-xxxx-xxxx的从设备是因为自动加载启动文件,升级导致的重启。

(3)     检查是否因为IRF合并导致的从设备重启。

¡     如果从设备重启原因为IRF合并,请追查IRF分裂、合并的原因,并排除安全隐患,以免再次因为同样的原因导致IRF分裂、合并。

¡     如果从设备重启原因不是IRF合并,请继续执行步骤(4)。

您可通过以下方式确认从设备的重启原因是否为IRF合并:

¡     设备重启后,在IRF中执行display kernel reboot命令查看设备的重启原因。如果Reason字段取值为0x7,则表示从设备重启原因为IRF合并,Slot表示触发重启事件的Slot的编号,Target Slot表示实际发生重启的Slot的编号。

<Sysname> display kernel reboot 1

--------------------- Reboot record 1 ---------------------

Recorded at           : 2021-12-06  00:10:05.440616

Occurred at           : 2021-12-06  00:10:05.440616

Reason                : 0x7

Thread                : STM_Main (TID: 232)

Context               : thread context

Slot                  : 1

Target Slot           : 2

Cpu                   : 0

VCPU ID               : 2

Kernel module info    : module name (system) module address (0xffffffffc0074000)

                        module name (addon) module address (0xffffffffc0008000)

¡     在IRF的Probe视图下执行display system internal irf msg | include reboot命令,如果可以看到主设备发送了重启报文,则表示从设备重启原因为IRF合并。

19> Send reboot pkt, src_addr 5e40-08d9-0104 (chassis 1 slot 1), at 2022/1/5 15:42:48:386

(4)     检查是否有软件和硬件故障导致成员设备异常重启。

通过display version命令,可以查看成员设备/单板上次重启的原因,根据重启原因,以及下表所示的建议操作进行处理。

<Sysname> display version

Reboot Cause  :     ColdReboot

[SubSlot 0] 24GE+4SFP Plus+POE

Reboot Cause字段的取值

重启原因说明

建议操作

AutoUpdateReboot

自动更新版本后重启

正常,无需处理

BootwareBackupReboot

Bootware备份区重启

请收集日志、诊断日志,联系技术支持人员处理

ColdReboot

设备掉电

检查设备的供电环境,确保供电正常

CryptographicModuleSelftestsFailedReboot

算法库自检失败

请及时升级软件版本

CryptotestFailReboot

加密算法库自检失败

请及时升级软件版本

DeadLoopReboot

软件检测到死循环

请收集日志、诊断日志和重启slot的display kernel deadloop 20 verbose的显示信息,联系技术支持人员处理

DEVHandShakeReboot

主控板与所有接口板之间握手报文超时

使用display device命令查看主控板状态是否为Normal,如果不是Normal,表示主控板可能故障,请先解决主控板的问题

IRFMergeReboot

IRF合并

IRF链路故障会导致IRF分裂,IRF链路恢复后,IRF会自动合并。请追查故障的IRF链路,并排除安全隐患,以免再次因为同样的原因导致IRF分裂、合并

KernelAbnormalReboot

CPU、主机内存或软件问题导致系统内核错误

请收集日志、诊断日志和诊断命令display kernel exception 10 verbosedisplay kernel reboot 20 verbose的信息,联系技术支持人员处理

KeyReboot

触碰了<RESET>

避免误操作

LicenseTimeoutReboot

License过期

请及时安装正式版本的License

MasterLostReboot

在本板批量备份时,主用主控板重启

请收集日志、诊断日志,联系技术支持人员处理

MemoryexhaustReboot

内存消耗,低于门限值

ACL表项太多等原因会导致内存占用率高,确认内存占用率高的原因,解决内存占用率高故障

PdtReboot

产品驱动要求的重启

请收集日志、诊断日志,联系技术支持人员处理

SelfReboot

业务板本板复位

请收集日志、诊断日志,联系技术支持人员处理

StandbyCannotUpdateReboot

备用主控板不能升级为主用主控板,重启

请收集日志、诊断日志,联系技术支持人员处理

StandbySwitchReboot

主备倒换重启原主用主控板

系统软件升级等原因会导致主备倒换,确认系统主备倒换的原因,避免再次发生非预期的主备倒换

UserReboot

通过命令行、网管主动重启设备

正常,无需处理

WarmReboot

原因可能有多种,例如单板虚插针脚接触不良导致单板重启

请收集日志、诊断日志,联系技术支持人员处理

WatchDogReboot

CPU、内存、软件或其它硬件故障,导致看门狗监测到系统异常,重启设备

根据display hardware-failure-detection命令显示的故障修复信息定位故障原因,消除安全隐患

 

(5)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     假设slot 16为主用主控板,以备用主控板slot 17重启为例,请收集以下命令的显示信息。

-     请在任意视图下执行以下命令:

display version

display device

display diagnostic-information

display kernel deadloop 20 verbose slot 16

display kernel exception 10 verbose slot 16

display kernel reboot 20 verbose slot 16

-     请在Probe视图下执行以下命令来收集信息:

local logbuffer slot 17 display

local logbuffer slot 17 display from-highmemory

display reboot last-time slot 17

display system internal version

display diag-msg start-msg slot 17

说明

以上命令的支持情况与设备的型号以及版本有关请以设备的实际情况为准。

 

¡     设备的配置文件、日志信息、告警信息。

4.2.4  告警与日志

相关告警

相关日志

·     DEV/1/AUTO_SWITCH_FAULT_REBOOT

·     DEV/5/BOARD_REBOOT

·     DEV/1/BOARD_RUNNING_FAULT_REBOOT

·     DEV/5/CHASSIS_REBOOT

·     DEV/5/SUBCARD_REBOOT

·     DEV/5/SYSTEM_REBOOT

·     STM/4/STM_MERGE

4.3  IRF出现分裂

4.3.1  故障描述

IRF运行过程中出现分裂。

4.3.2  SR8800-X故障处理步骤

(1)     IRF分裂时会打印IRF端口down,可以确定IRF分裂的时间。

%Jun 26 10:13:46:233 2014 H3C STM/2/STM_LINK_STATUS_TIMEOUT: IRF port 1 is down because heartbeat timed out.

%Jun 26 10:13:46:436 2014 H3C STM/3/STM_LINK_STATUS_DOWN: -MDC=1; IRF port 2 is down.

(2)     IRF物理端口所在接口板的状态是否正常,若不正常,请参照2.1.7  资源不足排查是否单板故障。

(3)     检查各个IRF物理端口的状态是否正常。若端口状态不正常,请确认故障原因。

<Sysname> display interface Ten-GigabitEthernet 2/7/0/1

Ten-GigabitEthernet2/7/0/1

Current state: UP

IP Packet Frame Type: PKTFMT_ETHNT_2, Hardware Address: 80f6-5665-4302

Description: Ten-GigabitEthernet2/7/0/1 Interface

Bandwidth: 10000000kbps

Loopback is not set

Media type is optical fiber,Port hardware type is 10G_BASE_SR_SFP

……

(4)     通过设备运行时间或日志检查IRF中各个成员设备及IRF物理端口所在的接口板在IRF分裂时是否重启过,并参照2.2  电源故障确认是否为电源故障导致。

<Sysname> display version

H3C Comware Software, Version 7.1.075, Release XXXX

Copyright (c) 2004-2017 New H3C Technologies Co., Ltd. All rights reserved.

H3C SR8804-X uptime is 0 weeks, 0 days, 4 hours, 49 minutes

Last reboot reason : USER reboot

 

Boot image: cfa0:/BOOT-RXXXX.bin

Boot image version: 7.1.075, Release XXXX

  Compiled Nov 11 2014 08:49:26

System image: cfa0:/SYSTEM-RXXXX.bin

System image version: 7.1.075, Release XXXX

  Compiled Nov 11 2014 08:49:26

Feature image(s) list:

 

MPU(M) Chassis 1 Slot 1:

Uptime is 0 weeks,0 days,5 hours,2 minutes

BOARD TYPE:         SR05SRP1L3

DRAM:               8192M bytes

CFCARD:             4002M bytes

FLASH:              500M bytes

NVRAM:              1M bytes

PCB 1 Version:      VER.A

Bootrom Version:    116

CPLD 1 Version:     001

CPLD 2 Version:     001

CPLD 3 Version:     001

Release Version:    H3C SR8804-X-XXXX

Patch Version  :    None

Reboot Cause  :     UserReboot

Clock card:

  Type        : SR07CK3C

  PCB         : Ver.A

  FPGA version: 100

 

LPU Chassis 1 Slot 4:

Uptime is 0 weeks,0 days,2 hours,32 minutes

BOARD TYPE:         SPC-GP44XP4LCX

DRAM:               4096M bytes

PCB 1 Version:      VER.A

Bootrom Version:    116

CPLD 1 Version:     002

Release Version:    H3C SR8804-X-XXXX

Patch Version  :    None

Reboot Cause  :     ColdReboot

 Number of Exist Subcards: 0

 

 

LPU Chassis 1 Slot 5:

Uptime is 0 weeks,0 days,4 hours,56 minutes

BOARD TYPE:         SPC-XP12LAX

DRAM:               4096M bytes

PCB 1 Version:      VER.A

Bootrom Version:    116

CPLD 1 Version:     001

Release Version:    H3C SR8804-X-XXXX

Patch Version  :    None

Reboot Cause  :     UserReboot

 Number of Exist Subcards: 0

 

 

NPU Chassis 1 Slot 6:

Uptime is 0 weeks,0 days,4 hours,56 minutes

BOARD TYPE:         SFC-04D

DRAM:               1024M bytes

PCB 1 Version:      VER.B

Bootrom Version:    512

CPLD 1 Version:     002

Release Version:    H3C SR8804-X-XXXX

Patch Version  :    None

Reboot Cause  :     UserReboot

 

LPU Chassis 2 Slot 1:

Uptime is 0 weeks,0 days,4 hours,38 minutes

BOARD TYPE:         SPC-CP1LCX

DRAM:               4096M bytes

PCB 1 Version:      VER.A

Bootrom Version:    116

CPLD 1 Version:     001

Release Version:    H3C SR8804-X-XXXX

Patch Version  :    None

Reboot Cause  :     UserReboot

 Number of Exist Subcards: 0

 

 

MPU(S) Chassis 2 Slot 4:

Uptime is 0 weeks,0 days,3 hours,56 minutes

BOARD TYPE:         SR05SRP1L3

DRAM:               8192M bytes

CFCARD:             4002M bytes

FLASH:              500M bytes

NVRAM:              1M bytes

PCB 1 Version:      VER.A

Bootrom Version:    116

CPLD 1 Version:     001

CPLD 2 Version:     001

CPLD 3 Version:     001

Release Version:    H3C SR8808-X-XXXX

Patch Version  :    None

Reboot Cause  :     UserReboot

Clock card:

  Type        : SR07CK3C

  PCB         : Ver.A

  FPGA version: 100

 

MPU(S) Chassis 2 Slot 5:

Uptime is 0 weeks,0 days,5 hours,2 minutes

BOARD TYPE:         SR05SRP1L3

DRAM:               8192M bytes

CFCARD:             4002M bytes

FLASH:              500M bytes

NVRAM:              1M bytes

PCB 1 Version:      VER.A

Bootrom Version:    116

CPLD 1 Version:     001

CPLD 2 Version:     001

CPLD 3 Version:     001

Release Version:    H3C SR8808-X-XXXX

Patch Version  :    None

Reboot Cause  :     UserReboot

Clock card:

  Type        : SR07CK3C

  PCB         : Ver.A

  FPGA version: 100

 

LPU Chassis 2 Slot 7:

Uptime is 0 weeks,0 days,4 hours,55 minutes

BOARD TYPE:         SPC-XP24LCX

DRAM:               4096M bytes

PCB 1 Version:      VER.A

Bootrom Version:    116

CPLD 1 Version:     001

Release Version:    H3C SR8804-X-XXXX

Patch Version  :    None

Reboot Cause  :     UserReboot

 Number of Exist Subcards: 0

 

 

NPU Chassis 2 Slot 10:

Uptime is 0 weeks,0 days,4 hours,56 minutes

BOARD TYPE:         SFC-08B

DRAM:               1024M bytes

PCB 1 Version:      VER.B

Bootrom Version:    514

CPLD 1 Version:     005

Release Version:    H3C SR8804-X-XXXX

Patch Version  :    None

Reboot Cause  :     UserReboot

(5)     如故障确认,可以通过如更换光模块、更换单板的方式使设备重新形成IRF;如故障无法确认,请搜集各个成员设备的信息,并将信息发送给技术支持人员协助分析。

4.3.3  SR8800-X-S设备故障处理步骤

(1)     IRF分裂时会打印IRF端口down,可以确定IRF分裂的时间。

%Jun 26 10:13:46:233 2014 H3C STM/2/STM_LINK_STATUS_TIMEOUT: IRF port 1 is down because heartbeat timed out.

%Jun 26 10:13:46:436 2014 H3C STM/3/STM_LINK_STATUS_DOWN: -MDC=1; IRF port 2 is down.

(2)     IRF物理端口所在主控板的状态是否正常,若不正常,请参照2.1.7  资源不足排查是否主控板故障。

(3)     检查各个IRF物理端口的状态是否正常。若端口状态不正常,请按照确认故障原因。

<Sysname> display interface Ten-GigabitEthernet 1/6/0/1

Ten-GigabitEthernet1/6/0/1

Current state: UP

IP Packet Frame Type: PKTFMT_ETHNT_2, Hardware Address: 0000-5c55-4446

Description: Ten-GigabitEthernet1/6/0/1 Interface

Bandwidth: 10000000kbps

Loopback is not set

Media type is stack wire,Port hardware type is STACK_SFP_PLUS

10Gbps-speed mode, full-duplex mode

Link speed type is force link, link duplex type is force link

The Maximum Frame Length is 9216

Mdi type: automdix

Last clearing of counters: Never

 Peak value of input: 21374 bytes/sec, at 2015-05-23 16:19:10

 Peak value of output: 77798 bytes/sec, at 2015-05-23 16:19:10

 Last 5 seconds input:  39 packets/sec 12420 bytes/sec 0%

 Last 5 seconds output:  85 packets/sec 43207 bytes/sec 0%

 Input (total):  24470 packets, 7974732 bytes

          17950 unicasts, 0 broadcasts, 6445 multicasts, 0 pauses

 Input (normal):  24395 packets, - bytes

          17950 unicasts, 0 broadcasts, 6445 multicasts, 0 pauses

 Input:  0 input errors, 0 runts, 0 giants, 0 throttles

          0 CRC, 0 frame, - overruns, 0 aborts

          - ignored, - parity errors

 Output (total): 54633 packets, 30848497 bytes

          30440 unicasts, 0 broadcasts, 24118 multicasts, 0 pauses

 Output (normal): 54558 packets, - bytes

          30440 unicasts, 0 broadcasts, 24118 multicasts, 0 pauses

 Output: 0 output errors, - underruns, - buffer failures

          0 aborts, 0 deferred, 0 collisions, 0 late collisions

          0 lost carrier, - no carrier

(4)     通过设备运行时间或日志检查IRF中各个成员设备及IRF物理端口所在的主控板在IRF分裂时是否重启过,并参照2.2  电源故障确认是否为电源故障导致。

<Sysname> display version

H3C Comware Software, Version 7.1.075, Release XXXX

Copyright (c) 2004-2017 New H3C Technologies Co., Ltd. All rights reserved.

H3C SR8810-X-S uptime is 0 weeks, 2 days, 2 hours, 42 minutes

Last reboot reason : Cold reboot

 

Boot image: cfa0:/BOOT-RXXXX.bin

Boot image version: 7.1.075, Release XXXX

  Compiled May 13 2015 19:22:53

System image: cfa0:/SYSTEM-RXXXX.bin

System image version: 7.1.075, Release XXXX

  Compiled May 13 2015 19:22:53

Feature image(s) list:

 

MPU(M) Chassis 1 Slot 6:

Uptime is 0 weeks,2 days,2 hours,46 minutes

BOARD TYPE:         SR07SRPUD3

DRAM:               8192M bytes

CFCARD:             4002M bytes

FLASH:              500M bytes

NVRAM:              1M bytes

PCB 1 Version:      VER.A

Bootrom Version:    135

CPLD 1 Version:     001

CPLD 2 Version:     003

Release Version:    H3C SR8810-X-S-XXXX

Patch Version  :    None

Reboot Cause  :     ColdReboot

Clock card:

  Type        : SR07CK3C

  PCB         : Ver.A

  FPGA version: 100

 Number of Exist Subcards: 0

 

 

MPU(S) Chassis 4 Slot 0:

Uptime is 0 weeks,1 day,0 hours,10 minutes

BOARD TYPE:         SR07SRPUD3

DRAM:               8192M bytes

CFCARD:             4002M bytes

FLASH:              500M bytes

NVRAM:              1M bytes

PCB 1 Version:      VER.A

Bootrom Version:    135

CPLD 1 Version:     001

CPLD 2 Version:     002

Release Version:    H3C SR8806-X-S-XXXX

Patch Version  :    None

Reboot Cause  :     UserReboot

Clock card:

  Type        : SR07CK3C

  PCB         : Ver.A

  FPGA version: 100

 Number of Exist Subcards: 0

 

 

MPU(S) Chassis 4 Slot 1:

Uptime is 0 weeks,2 days,2 hours,45 minutes

BOARD TYPE:         SR07SRPUD3

DRAM:               8192M bytes

CFCARD:             4002M bytes

FLASH:              500M bytes

NVRAM:              1M bytes

PCB 1 Version:      VER.A

Bootrom Version:    135

CPLD 1 Version:     001

CPLD 2 Version:     003

Release Version:    H3C SR8806-X-S-XXXX

Patch Version  :    None

Reboot Cause  :     UserReboot

Clock card:

  Type        : SR07CK3C

  PCB         : Ver.A

  FPGA version: 100

 Number of Exist Subcards: 0

 

 

LPU Chassis 4 Slot 2:

Uptime is 0 weeks,2 days,2 hours,28 minutes

BOARD TYPE:         SPC-GP44XP4LA

DRAM:               4096M bytes

PCB 1 Version:      VER.A

Bootrom Version:    120

CPLD 1 Version:     001

Release Version:    H3C SR8810-X-S-XXXX

Patch Version  :    None

Reboot Cause  :     UserReboot

 Number of Exist Subcards: 0

 

 

LPU Chassis 4 Slot 3:

Uptime is 0 weeks,2 days,2 hours,28 minutes

BOARD TYPE:         SPC-XP12LC

DRAM:               4096M bytes

PCB 1 Version:      VER.A

Bootrom Version:    120

CPLD 1 Version:     001

Release Version:    H3C SR8810-X-S-XXXX

Patch Version  :    None

Reboot Cause  :     UserReboot

 Number of Exist Subcards: 0

 

 

LPU Chassis 4 Slot 4:

Uptime is 0 weeks,2 days,2 hours,28 minutes

BOARD TYPE:         SPC-GP44XP4LC

DRAM:               4096M bytes

PCB 1 Version:      VER.A

Bootrom Version:    120

CPLD 1 Version:     001

Release Version:    H3C SR8810-X-S-XXXX

Patch Version  :    None

Reboot Cause  :     UserReboot

 Number of Exist Subcards: 0

(5)     如故障确认,可以通过如更换光模块、更换单板的方式使设备重新形成IRF;如故障无法确认,请搜集各个成员设备的信息,并将信息发送给技术支持人员协助分析。

4.4  故障诊断命令

命令

说明

debug ipv4-drv show config

显示当前IPv4配置信息

display device

显示设备信息。用于检查各成员设备的软件版本、主控板类型是否一致

display install active

显示当前系统中处于激活状态的软件包的相关信息

display interface

显示指定接口的相关信息。用于检查IRF物理端口状态是否UP

display irf configuration

显示所有成员设备的IRF配置信息。用于检查IRF端口连接是否异常,一台设备的IRF-Port1口只能与另一台设备的IRF-Port2口连接

display system-vlan-mode

显示系统当前运行的VLAN模式和下次启动后运行的VLAN模式

display version

显示系统版本信息、单板的运行时间。通过设备运行时间确认IRF中各个成员设备是否重启过,主控板及IRF端口所在接口板是否发生重启

display irf topology

查看当前拓扑信息。显示IRF拓扑状态

 


5 接口管理类故障处理

5.1  聚合口故障

5.1.1  故障描述

故障现象通常为二层聚合口、三层聚合口业务异常,例如聚合成员口无法选中、聚合负载分担业务异常。

5.1.2  故障处理步骤

1. 聚合成员端口无法选中

(1)     通过display link-aggregation verbose命令查看聚合接口对应聚合组的详细信息。

[Sysname] display link-aggregation verbose Route-Aggregation 12

Loadsharing Type: Shar -- Loadsharing, NonS -- Non-Loadsharing

Port Status: S -- Selected, U -- Unselected, I -- Individual

Port: A -- Auto

Flags:  A -- LACP_Activity, B -- LACP_Timeout, C -- Aggregation,

        D -- Synchronization, E -- Collecting, F -- Distributing,

        G -- Defaulted, H -- Expired

 

Aggregate Interface: Route-Aggregation12

Aggregation Mode: Static

Loadsharing Type: Shar

  Port             Status  Priority Oper-Key

  GE3/1/1         U       32768    2

  GE3/1/2         U       32768    2

(2)     检查聚合口下的成员口物理状态是否UP,如果是DOWN状态,请检查连线。

[Sysname]display interface GigabitEthernet 3/1/1

GigabitEthernet3/1/1

Current state: DOWN

Line protocol state: DOWN(LAGG)

Description: GigabitEthernet3/1/1 Interface

Bandwidth: 1000000 kbps Flow-control is not enabled

(3)     检查聚合口下的配置和成员口的配置是否一致,如果不一致,会出现成员端口无法选中的现象。

(4)     检查聚合口下各成员口的速率配置是否一致,如果不一致,可以通过link-aggregation ignore speed命令用来配置聚合组选择选中端口时忽略端口速率。如果聚合组两端本命令配置不一致,动态聚合组可以通过LACP协议协商状态,使链路两端端口状态一致;静态聚合组无法协商状态,为了防止报文丢失,所以要求静态聚合组两端本命令配置一致。配置本命令后,如果聚合组中选中端口速率不同,聚合组中流量负载分担时,速率较小的选中端口可能存在丢包现象,请按需配置本功能。开启和关闭本功能后,操作Key会发生变化,导致聚合接口震荡,请按需配置本功能。

(5)     如果聚合口下的配置和成员口的配置相同,聚合成员口还是无法选中,则联系技术支持。

2. 聚合负载分担业务异常。

请联系技术支持。

5.2  端口错包

5.2.1  故障描述

使用display interface命令查询端口的入、出方向流量统计信息,发现错包统计计数不为0

<Sysname> display interface gigabitethernet3/1/1

GigabitEthernet3/1/1

Current state: UP

Line protocol state: UP

Description: GigabitEthernet3/1/1 Interface

Bandwidth: 1000000kbps

Flow-control is not enabled

Maximum transmission unit: 1500

Allow jumbo frames to pass

Broadcast max-ratio: 100%

Multicast max-ratio: 100%

Unicast max-ratio: 100%

Internet protocol processing: Disabled

IP packet frame type: Ethernet II, hardware address: 9c06-1b04-31fe

IPv6 packet frame type: Ethernet II, hardware address: 9c06-1b04-31fe

Media type is not sure, port hardware type is No connector

Port priority: 0

Loopback is not set

unknown-speed mode, unknown-duplex mode

Link speed type is autonegotiation, link duplex type is autonegotiation

The maximum frame length is 10240

Last link flapping: Never

Last clearing of counters: Never

Current system time:2020-04-28 11:42:09

Last time when physical state changed to up:-

Last time when physical state changed to down:2020-04-28 11:40:45

 Peak input rate: 0 bytes/sec, at 2020-04-28 11:42:08

 Peak output rate: 0 bytes/sec, at 2020-04-28 11:42:08

 Last 5 seconds input: 0 packets/sec 0 bytes/sec 0 bits/sec -%

 Last 5 seconds output: 0 packets/sec 0 bytes/sec 0 bits/sec -%

 Input (total):  0 packets, 0 bytes

          0 unicasts, 0 broadcasts, 0 multicasts, - pauses

 Input (normal):  0 packets, - bytes

          - unicasts, - broadcasts, - multicasts, 0 pauses

 Input:  0 input errors, 0 runts, 0 giants, 0 throttles

          0 CRC, 0 frame, 0 overruns, - aborts

          0 ignored, - parity errors

 Output (total): 0 packets, 0 bytes

          0 unicasts, 0 broadcasts, 0 multicasts, - pauses

 Output (normal): 0 packets, 0 bytes

          - unicasts, - broadcasts, - multicasts, 0 pauses

 Output: 0 output errors, - underruns, - buffer failures

          0 aborts, 0 deferred, - collisions, 0 late collisions

          - lost carrier, - no carrier

1. 端口入方向报文计数错误字段解释

·     input errors:端口接收的错误报文的统计值。

·     runts:表示接收到的超小帧个数。超小帧即超小帧是指长度小于64字节、格式正确且包含有效的CRC字段的帧。

·     giants:接收到的超大帧的数量。超大帧即有效长度大于端口允许通过最大报文长度的帧。

·     CRC:接收到的CRC校验错误、长度正常的帧的数量。

·     frame:接收到的CRC校验错误、且长度不是整字节数的帧的数量。

·     throttles:超小而且CRC错误的帧的数量。

2. 端口出方向报文计数错误字段解释

·     output errors:各种发送错误的报文总数。

·     aborts:表示发送失败的报文总数。

·     deferred:表示延迟报文的总数。报文延迟是指因延迟过长的周期而导致发送失败的报文,而这些报文由于发送媒质繁忙而等待了超过2倍的最大报文发送时间。

·     collisions:表示冲突帧总数,即在发送过程中检测到冲突而停止发送的报文。

·     late collisions:表示延迟冲突帧,即发送过程中发生延迟冲突超过512bit时间的帧。

5.2.2  故障处理步骤

1. 端口入方向出现CRC、frame、throttles错包且计数持续增加

(1)     使用仪器测试链路,链路质量差或者线路光信号衰减过大会导致报文在传输过程中出错。如链路故障请更换网线或光纤。

(2)     如端口使用光模块,参照5.6  光模块故障确认是否光模块故障导致。

(3)     与别的正常的端口更换网线或光纤光模块,如端口更换后错包消失,端口更换回来错包又再次出现端口相关,应为单板端口故障,请更换端口并将故障信息发送技术支持人员分析;如更换到其他正常端口仍会出现错包,则对端设备、中间传输链路故障的可能性较大,请排查。

(4)     排查对端设备或者中间的传输设备。

(5)     如故障无法确认,请将故障信息发送技术支持人员分析。

2. 端口入方向出现Overrun错包且计数持续增加

Overrun计数是由于端口输入速率超出本端口处理能力,导致丢包。

(1)     如果只有某一个端口收发包异常,或者某一个端口下挂设备的业务不通,同时这个单板上的其他端口都是正常的,可以多次查询display interface命令,如果input errors有增加,且等于overruns的增加,那么可以怀疑是单板内部拥塞或堵死,请将故障信息发送技术支持人员分析。

(2)     如果仍然无法确认,请将故障信息发送技术支持人员分析。

3. 端口入方向出现giants错包且计数持续增加

(1)     检查两端的jumbo配置是否一致,如jumbo是否使能,端口默认的最大报文长度是否一致,允许最大报文长度是否一致,可以通过display interface命令查到,即The maximum frame length显示的数值

(2)     如果仍然无法确认,请将故障信息发送技术支持人员分析。

4. 端口出方向出现错包且计数持续增加

(1)     检查端口是否配置为半双工模式,如为半双工,请更改为全双工模式。

(2)     如果仍然无法确认,请将故障信息发送技术支持人员分析。

5.3  端口无法up

5.3.1  故障描述

端口无法正常up。

5.3.2  故障处理步骤

1. 端口无法up

(1)     测试端口之间网线、光纤链路是否正常,光纤两端的发送/接收端是否错连;更换端口之间的网线、光纤或将网线、光纤放到别的正常端口,以确认是否中间传输链路故障。

(2)     通过display interface命令查看端口状态Current state是否为Administratively DOWN状态,如果不是,请使用undo shutdown命令激活相应的以太网端口。

(3)     检查本端、对端端口配置是否正确,如端口是否shutdown,速率、双工的协商模式、MDI是否正确。

[Sysname] display current-configuration interface ten-gigabitethernet 3/1/1

#

interface Ten-GigabitEthernet3/1/1

 port link-mode bridge

 port link-type trunk

 port trunk permit vlan 1 3102

 port link-aggregation group 1

#

return

说明

·     光类型接口和位于SPEX/CSPEX类单板、CEPC类单板上的接口子卡的电口不支持duplex half命令

·     位于SPEX-1204单板上的MIC接口子卡的接口仅支持配置接口速率为1000Mbps和auto

·     当PIC-GP10L子卡的光口与MIC接口子卡或千兆以太网 SPC单板(如SPC-GP48LB)的光口直连时,如果使用本命令配置一端接口速率为1000,另一端的速率请配置为auto

 

(4)     如端口使用光模块,请检查两端光模块类型是否一致,如速率、波长、单模多模状态等;由于部分子卡一个端口支持两种速率,请使用和端口实际速率一致的光模块;与正常的光模块交叉更换,并参照5.6  光模块故障排除是否为光模块故障导致。

[Sysname] display transceiver interface Ten-gigabitethernet 3/1/1

Ten-GigabitEthernet3/1/1 transceiver information:

  Transceiver Type              : 10G_BASE_SR_SFP

  Connector Type                : LC

  Wavelength(nm)                : 850

  Transfer Distance(km)         : 80(50um),20(62.5um),300(om3)

  Digital Diagnostic Monitoring : YES

  Vendor Name                   : H3C

  Ordering Name                 : SFP-XG-SX-MM850-A

(5)     如端口为WAN口。请检查WAN口的速率是否与光模块匹配,如果不匹配,请更换。

(6)     如果是使用100G QSFP28光模块的接口,要检查两端的FEC配置是否一致,如不匹配,请更换。

(7)     如确认为光模块故障,请更换光模块,并将故障信息发送技术支持人员分析。

5.4  端口由up变成down

5.4.1  故障描述

端口状态由up变成down。

5.4.2  故障处理步骤

(1)     查看本设备及对端设备日志,确认有无端口shutdown操作。

(2)     查看两端端口状态,确认是否为协议异常或在线诊断模块检测到异常将端口shutdown。如这里的GE3/1/1端口出现“Protect DOWN”,是由于hardware-failure-detection配置为isolate级别,当设备在线诊断模块检测到端口故障时,将端口shutdown隔离,以便流量切换到备份链路。请将故障信息发送技术支持人员分析。

[Sysname] display interface gigabitethernet3/1/1

GigabitEthernet3/1/1

current state: Protect DOWN

Line protocol current state: DOWN

IP Packet Frame Type: PKTFMT_ETHNT_2, Hardware Address: 0000-e80d-c000

Description: GigabitEthernet3/1/1 Interface

Loopback is not set

Media type is optical fiber, Port hardware type is 1000_BASE_SX_SFP

Unknown-speed mode, unknown-duplex mode

Link speed type is autonegotiation, link duplex type is autonegotiation

Flow-control is not enabled

The Maximum Frame Length is 9216

 ……

(3)     参照5.3  端口无法up,排查两端端口配置,网线、光模块、光纤等链路是否正常。

(4)     如仍无法确认,请搜集本端、对端设备信息,并将信息发送技术支持人员分析。

5.5  端口频繁up/down

5.5.1  故障描述

端口频繁up/down。

5.5.2  故障处理步骤

(1)     对于光口,请参照5.6  光模块故障确认光模块是否异常。查看光模块alarm信息来排查两端光模块以及中间光纤问题;对于支持诊断功能的光模块可以通过查看diagnosis信息确认光模块的光功率是否处于上下门限临界值。如发送光功率处于临界值,请更换光模块做交叉验证;如接收光功率处于临界值,请排查对端光模块及中间光纤链路。

(2)     对于电口,一般在自协商情况下容易出现协商不稳定,这种情况请尝试设置强制速率和双工模式。

(3)     对于WAN口,请检查两端时钟是否配置,需在主控板有时钟扣板的一端配置为Master,另一端配置为slave

(4)     如果故障依然存在,请排查链路、对端设备、中间设备。

(5)     如仍无法确认,请将故障信息发送技术支持人员分析。

5.6  光模块故障

5.6.1  故障描述

安装光模块的接口不能正常工作。

5.6.2  故障处理步骤

(1)     检查光模块Alarm告警信息。告警信息中如果存在接收有问题那一般是对端端口、光纤或中转传输设备导致;如果是发送有问题或者电流、电压异常那就需要排查本端端口。

<Sysname> display transceiver alarm interface GigabitEthernet 3/1/1

GigabitEthernet3/1/1 transceiver current alarm information:

  TX fault

  RX power high

表5-1 光模块告警信息说明

字段

描述

SFP/SFP+/CFP/QSFP+

RX loss of signal

接收信号丢失

RX power high

接收光功率高告警

RX power low

接收光功率低告警

TX fault

发送错误

TX bias high

偏置电流高告警

TX bias low

偏置电流低告警

TX power high

发送光功率高告警

TX power low

发送光功率低告警

Temp high

温度高告警

Temp low

温度低告警

Voltage high

电压高告警

Voltage low

电压低告警

Transceiver info I/O error

模块信息读写错误

Transceiver info checksum error

模块信息校验和错误

Transceiver type and port configuration mismatch

模块类型和端口配置不匹配

Transceiver type not supported by port hardware

端口不支持该模块类型

XFP

RX loss of signal

接收信号丢失

RX not ready

接收状态未就绪

RX CDR loss of lock

RX CDR时钟失锁

RX power high

接收光功率高告警

RX power low

接收光功率低告警

TX not ready

发送状态未就绪

TX fault

发送错误

TX CDR loss of lock

TX CDR时钟失锁

TX bias high

偏置电流高告警

TX bias low

偏置电流低告警

TX power high

发送光功率高告警

TX power low

发送光功率低告警

Module not ready

模块状态未就绪

APD supply fault

APD(Avalanche Photo Diode,雪崩光电二极管)错误

TEC fault

TEC(Thermoelectric Cooler,热电冷却器)错误

Wavelength unlocked

光信号波长失锁

Temp high

温度高告警

Temp low

温度低告警

Voltage high

电压高告警

Voltage low

电压低告警

Transceiver info I/O error

模块信息读写错误

Transceiver info checksum error

模块信息校验错误

Transceiver type and port configuration mismatch

模块类型和端口配置不匹配

Transceiver type not supported by port hardware

端口不支持该模块类型

 

(2)     检查光模块的接收、发送光功率是否正常(即在该光模块的光功率上下门限值之内)。

对于H3C定制且支持诊断功能的光模块,可以通过命令行查询光模块的接收、发送光功率是否超出其上下门限值;其他光模块可以使用同样命令尝试查询,但有可能查询不到。

a.     查看光模块的电子标签信息,Verdor Name显示为H3C表示是H3C定制光模块。

<Sysname> display transceiver manuinfo interface Ten-gigabitethernet 3/1/1

Ten-GigabitEthernet3/1/1 transceiver manufacture information:

  Manu. Serial Number : 213410A0000054000251

  Manufacturing Date  : 2012-10-26

  Vendor Name         : H3C

b.     通过下述命令确认光模块是否支持诊断功能,Digital Diagnostic MonitoringYES表示支持诊断功能。

<Sysname> display transceiver interface

Ten-GigabitEthernet3/1/1 transceiver information:

  Transceiver Type              : 10G_BASE_LR_XFP

  Connector Type                : LC

  Wavelength(nm)                : 1310

  Transfer Distance(km)         : 10(SMF)

  Digital Diagnostic Monitoring : YES

  Vendor Name                   : H3C.

c.     通过命令display transceiver diagnosis interface查询光模块的实时接收、发送光功率。

<Sysname> display transceiver diagnosis interface

Ten-GigabitEthernet3/1/1 transceiver diagnostic information:

  Current diagnostic parameters:

    Temp.(°C) Voltage(V)  Bias(mA)  RX power(dBM)  TX power(dBM)

    41         3.26        42.43     -40.00         -2.20

d.     通过display transceiver interfacedisplay transceiver diagnosis interface命令查询光模块的接收发送光功率的上下门限值。

有可能出现通过这两个命令行都可以查询、且查询出来的接收发送光功率上下门限值存在差异的情况,此时请以范围最小的上下门限值为准。

display transceiver diagnosis interface命令还可以查询实时的接收发送光功率、温度及其上下门限值、电压及其上下门限值、偏置电流及其上下门限值,命令行中Current diagnostic parameters下数据表示光模块当前的温度、电压、偏置电流、接收光功率、发送光功率,Alarm thresholdsHighLow数据表示温度、电压、偏置电流、接收光功率、发送光功率的上下门限值。

<Sysname> display transceiver interface ten-GigabitEthernet 3/1/1

Ten-GigabitEthernet3/1/1 transceiver information:

  Transceiver Type              : 10G_BASE_SR_SFP

  Connector Type                : LC

  Wavelength(nm)                : 850

  Transfer Distance(km)         : 80(50um),20(62.5um),300(om3)

  Digital Diagnostic Monitoring : YES

  Vendor Name                   : H3C

  Ordering Name                 : SFP-XG-SX-MM850-A

<Sysname> display transceiver diagnosis interface ten-GigabitEthernet 3/1/1

Ten-GigabitEthernet3/1/1 transceiver diagnostic information:

  Current diagnostic parameters:

    Temp.(°C) Voltage(V)  Bias(mA)  RX power(dBM)  TX power(dBM

    43         3.35        46.33     -3.60          -2.38

  Alarm thresholds:

          Temp.(°C) Voltage(V)  Bias(mA)  RX power(dBM)  TX power(dBM

    High  73         3.80        92.40     2.50           3.50

    Low   -3         2.81        1.00      -16.40         -11.20

  Parameters when first used on N/A:

    Temp.(°C) Voltage(V)  Bias(mA)  RX power(dBm)  TX power(dBm)

    N/A        N/A         N/A       N/A            N/A

  Total account of alarms: 0

  Latest occurrence of different alarms:

    Type       Date           Description

    Temp.      N/A            N/A

    Voltage    N/A            N/A

    Bias       N/A            N/A

    RX power   N/A            N/A

    TX power   N/A            N/A

    TX         N/A            N/A

    RX         N/A            N/A

    Others     N/A            N/A

  Latest three alarms:

    Date           Description

    N/A            N/A

    N/A            N/A

    N/A            N/A

(3)     对怀疑故障的光模块进行交叉验证,如更换端口、与正常的光模块互换,确认是光模块本身故障还是相邻设备或中间链路故障。

(4)     如仍无法确认,请将故障信息发送技术支持人员分析。

建议尽量使用H3C定制光模块。可通过display transceiver manuinfo命令来查询光模块的定制厂商信息,如果Vendor Name为H3C,说明是H3C定制光模块。

5.7  端口不可见

5.7.1  故障描述

端口不可见。

5.7.2  故障处理步骤

(1)     通过display device查看所在单板或子卡的状态,有可能是单板或子卡还处于启动状态,需保证单板和子卡状态为NORMAL。

·     SR8800-X

<Sysname> display device

Slot No. Brd Type         Brd Status   Software Version

 0       SR05SRP1L3       Master       SR8800-CMW710-RXXXX

 1       SR05SRP1L3       Standby      NONE

 2       SPC-XP8LB        Normal       SR8800-CMW710-RXXXX

 3       MPE-1104         Normal       SR8800-CMW710-RXXXX

   Sub1  MIC-SP4L         Normal

   Sub2  MIC-SP4L         Normal

   Sub3  MIC-CLP2L        Normal

   Sub4  MIC-GP4L         Normal

 4       SPC-XP8LB        Normal       SR8800-CMW710-RXXXX

 5       NONE             Absent       NONE

 6       SFC-04D          Normal       SR8800-CMW710-RXXXX

 7       NONE             Absent       NONE

 8       NONE             Absent       NONE

 9       NONE             Absent       NONE

·     SR8800-X-S

<Sysname> display device

Slot No. Brd Type         Brd Status   Software Version

 0       SR07SRPUA1       Standby      SR8800FS-CMW710-RXXXX

 1       SR07SRPUA1       Master       SR8800FS-CMW710-RXXXX

 2       SPC-XP8LB        Normal       SR8800FS-CMW710-RXXXX

 3       NONE             Absent       NONE

 4       NONE             Absent       NONE

 5       NONE             Absent       NONE

 6       NONE             Absent       NONE

 7       MPE-1104         Normal       SR8800FS-CMW710-RXXXX

   Sub1  MIC-GP8L         Normal

   Sub2  MIC-SP4L         Normal

   Sub3  NONE             Absent

   Sub4  MIC-GP4L         Normal

(2)     如果单板或子卡已经恢复配置,再查看当前的接口信息中是否有目标端口。

<Sysname> display interface brief

Brief information on interface(s) under route mode:

Link: ADM - administratively down; Stby - standby

Protocol: (s) - spoofing

Interface            Link Protocol Main IP         Description

GE5/1/1              DOWN DOWN     --

GE5/1/1.1            DOWN DOWN     110.0.1.1

GE5/1/1.2            DOWN DOWN     110.0.2.1

GE5/1/1.3            DOWN DOWN     110.0.3.1

GE5/1/1.4            DOWN DOWN     110.0.4.1

GE5/1/1.5            DOWN DOWN     110.0.5.1

GE5/1/1.6            DOWN DOWN     110.0.6.1

GE5/1/1.7            DOWN DOWN     110.0.7.1

GE5/1/1.8            DOWN DOWN     110.0.8.1

GE5/1/1.9            DOWN DOWN     110.0.9.1

GE5/1/1.10           DOWN DOWN     110.0.10.1

GE5/1/1.11           DOWN DOWN     110.0.11.1

GE5/1/1.12           DOWN DOWN     110.0.12.1

GE5/1/1.13           DOWN DOWN     110.0.13.1

(3)     有的子卡支持类型切换,接口类型不匹配时,需要手工切换。如:1602单板插的是GP20L子卡,子卡更换为XP20L后,端口类型是GE的,非10GE,想用10GE接口需要命令行切换。

(4)     如查不到端口,有可能是还在配置恢复过程中,需耐心等待一段时间,如过了较长时间后问题仍没有消除,请将故障信息发送技术支持人员分析。

5.8  WAN口协议不up

5.8.1  故障描述

WAN口物理链路能up,但协议不up

5.8.2  故障处理步骤

(1)     检查WAN口两端配置协议是否一致。如果不一致,需配置成相同的协议。

(2)     通过display interface查看两端端口上是否有错包,两端端口配置是否一致。如果有错包计数,请检查下光模块是否和该端口匹配,检查光纤和光模块是否良好。如果两端端口的配置不一致,请配置成一致。

(3)     如仍无法解决,请将故障信息发送技术支持人员分析。

5.9  WAN口物理不up

5.9.1  故障描述

WAN口物理链路不up

通过display interface pos命令查看接口的信息,Alarm字段出现告警。

<Sysname> display interface pos 2/2/1

Pos2/2/1

Current state: DOWN

Line protocol state: DOWN

Description: pos-interface

Bandwidth: 155520 kbps

Maximum transmission unit: 1500

Hold timer: 10 seconds, retry times: 5

Dampening enabled:

 Penalty: 0 (not suppressed)

 Ceiling: 6000

 Reuse: 750

 Suppress: 2000

 Half-life: 54 seconds

 Max-suppress-time: 162 seconds

 Flap count: 0

Internet protocol processing: Disabled

Link layer protocol: PPP

LCP: initial

Port priority: 0

Last link flapping: Never

Last clearing of counters: Never

Current system time:2017-12-15 17:18:19

Last time when physical state changed to up:-

Last time when physical state changed to down:2017-12-11 09:57:36

Port connector type is No connector

Physical layer is packet over SDH

Port speed type: STM-1

Loopback is not set

FCS: 32-bit CRC

Clock source: Slave

Clock grade: Quality unknown(existing synchronization network)

SPE scrambling: Enable

BER thresholds:

    SD: 10e-6    SF: 10e-4

Regenerator section layer:

    J0(TX): "SR8800"

            53 52 38 38 30 30 00 00 00 00 00 00 00 00 00 00

    J0(RX): ""

            00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

    Alarm: LOS

    Error: 0 BIP(B1)

Multiplex section layer:

    Alarm: None

    Error: 0 BIP(B2), 0 REI(M1)

Higher order path layer:

    C2(TX): 0x16    C2(RX): 0xef

    J1(TX): "SR8800"

            53 52 38 38 30 30 00 00 00 00 00 00 00 00 00 00

    J1(RX): ""

            00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

    Alarm: None

    Error: 0 BIP(B3), 0 REI(G1)

           0 PJE, 0 NJE

Port statistic:start time: 2017-12-11 09:57:46

UP time: 0 H 0 M 0 S

Section: ES        0   SES        0   SEFS        0

Line   : ES        0   SES        0   UAS         0   FE-ES        0

Input speed in last 300 seconds: 0 packets/s, 0 bytes/s

Output speed in last 300 seconds: 0 packets/s, 0 bytes/s

Input: 0 packets,  0 bytes(good), 0 bytes(all)

        0 FCS errors,  0 Aborts,  0 FIFO overflow

        0 Runts,  0 Giants

Output: 0 packets,  0 bytes(good), 0 bytes(all)

        0 FIFO underflow,  0 Aborts,  0 Runts

Peak value of input: 0 bytes/sec, at 2017-12-15 00:01:34

Peak value of output: 0 bytes/sec, at 2017-12-15 00:01:34

5.9.2  故障处理步骤

1. Alarm字段出现LOF(loss of framer)告警

出现LOF告警表示出现了帧丢失问题,表明传输的信号质量较差。

(1)     查看两端POS接口速率是否一致。若两端POS接口速率不一致,请重新配置两端POS接口速率,保持一致。

(2)     查看光模块类型与POS接口速率是否匹配,低速率光模块不能用于高速率POS接口,若光模块类型与POS接口速率不匹配,请更换及时光模块。

(3)     查看光纤是否损坏,若光纤出现损坏,请及时更换光纤。

(4)     如仍无法解决,请将故障信息发送技术支持人员分析。

2. Alarm字段出现LOS(loss of single)告警

如果POS接口收不到光信号或者连续收到LOF告警,就会产生LOS告警。

(1)     查看POS接口光模块是否安插正常。若未安插光模块或者光模块接触不良,请保证光模块安插正常。

(2)     查看POS接口光纤是否安装插正常。若未插光纤或者收发光纤插反,请保证光纤安插正常。

(3)     查看光纤是否损坏。若光纤出现损坏,请及时更换光纤。

(4)     查看两端POS接口速率是否一致。若两端POS接口速率不一致,请重新配置两端POS接口速率,保持一致。

(5)     查看光模块类型与POS接口速率是否匹配。低速率光模块不能用于高速率POS接口,若光模块类型与POS接口速率不匹配,请更换及时光模块。

(6)     查看对端POS接口是否关闭。若对端POS接口已关闭,请开启的对端POS接口。

(7)     查看对端POS接口是否使能了内部环回功能。若使能了内部环回功能,则需要去使能内部环回功能。

(8)     查看光纤与光模块是否匹配,若不匹配,请更换光纤或者光模块。

(9)     如仍无法解决,请将故障信息发送技术支持人员分析。

5.10  WAN口打印告警信息

5.10.1  故障描述

WAN口打印告警信息,如:

H3C WAN/4/ALARM: -MDC=1-Slot=2;

 Cpos2/2/1 : Path 1 Alarm AIS report! Start Time : 2021-04-04 11:40:53:533!

H3C WAN/4/ALARM: -MDC=1-Slot=2;

 Cpos2/2/1 : Path 1 Alarm AIS recover! Start Time : 2021-04-04 11:41:09:769!

5.10.2  故障处理步骤

通过display interface pos命令查看接口的Alarm字段的告警信息。各告警标志的处理方法请参见5-2

表5-2 告警标志处理方法

告警标志

说明

处理方法

LOF

表示出现了帧丢失问题,表明传输的信号质量较差

参见5.9.2  1.

LOS

POS接口收不到光信号或者连续收到LOF告警

参见5.9.2  2.

PSLM

本端和对端的信号标记字节C2配置不一致

重新配置本端和对端的信号标记字节C2,使其保持一致

PTIM

本端和对端的SONET/SDH帧的通道踪迹字节J1配置不一致

重新配置本端和对端的SONET/SDH帧的通道踪迹字节J1,使其保持一致

PRDI

本端和对端的信号标记字节C2配置不一致或者SONET/SDH帧的通道踪迹字节J1配置不一致

重新配置本端和对端的信号标记字节C2或者SONET/SDH帧的通道踪迹字节J1,使其保持一致

 

如果上述检查完成后故障仍无法排除,可通过display diagnostic-information命令收集设备的diagnostic-information,联系H3C的技术支持工程师。

<H3C> display diagnostic-information

Save or display diagnostic information (Y=save, N=display)? [Y/N] :Y

5.11  故障诊断命令

命令

说明

display current-configuration

显示设备当前生效的配置,指定interface可以显示指定接口当前生效的配置

display interface

查询端口的入、出方向流量统计信息、端口状态。可查看是否存在错包及错包统计信息。

display transceiver alarm interface

显示可插拔接口模块的当前故障告警信息

display transceiver diagnosis

显示可插拔光模块的数字诊断参数的当前测量值,包括温度、电压、偏置电流、接收光功率、发送光功率

display transceiver interface

显示指定接口可插拔接口模块的主要特征参数。检查两端光模块类型是否一致,如速率、波长、单模多模状态等

display transceiver manuinfo

显示可插拔接口模块的电子标签信息。可用来查询光模块的定制厂商。

 


6 二层技术-以太网交换类故障处理

6.1  MAC地址学习故障

6.1.1  故障描述

故障现象通常为端口没有学习到报文的源MAC地址。

6.1.2  故障处理步骤

1. 检查源MAC地址的正确性

通过display mac-addressdisplay l2vpn mac-address命令检查源MAC地址。

源MAC地址学习仅支持单播MAC地址,不支持组播MAC地址、不支持全0的MAC地址。MAC地址的第一个字节最低为0是单播MAC地址,如00-00-00-00-00-01,组播MAC地址为01-00-00-00-00-01。

2. 检查源MAC老化时间的正确性

使用display mac-address aging-time命令查看MAC地址的老化时间,如果配置的老化时间过低,MAC地址的数量很大,会出现MAC地址被快速老化删除的情况。

[Sysname] display mac-address aging-time

MAC address aging time: 10s.

[Sysname] display l2vpn mac-address count

875613 mac address(es) found.

3. 检查端口状态

端口状态为down时,不会学习MAC地址。使用display interface命令查看端口的状态。

[Sysname] display interface GigabitEthernet 3/1/1

GigabitEthernet3/1/1

Current state: DOWN

Line protocol state: DOWN

...

4. 检查端口是否有流量进入

端口没有流量进入时,不会学习MAC地址。使用display counters inbound命令查看端口是否有流量进入

<Sysname> display counters inbound interface GigabitEthernet 3/1/1

Interface                   Total(pkt) Broadcast(pkt) Multicast(pkt) Err(pkt)

GE3/1/1                              0              0              0        0

 

 Overflow: More than 14 digits (7 digits for column "Err").

       --: Not supported.

5. 检查设备是否出现迁移流量

迁移流量指两条源MAC地址相同的流量进入不同的端口时,MAC地址会在两个端口之前来回迁移。如果配置了聚合接口并且按报文的目的IP地址进行聚合负载分担(destination-ip),当源MAC地址相同但目的IP地址不同的报文进入该聚合接口时,可能会出现迁移流量,导致其中一个成员端口学习到的MAC地址迁移到另一个成员端口。

使用display link-aggregation load-sharing mode命令查看全局采用的聚合负载分担类型,如果为destination-ip类型,请联系技术支持。

6.2  以太网链路聚合故障处理

6.2.1  聚合接口无法UP

1. 故障描述

当两台设备间通过链路聚合连接时,通过display interface命令查看聚合接口处于down状态。

2. 常见原因

本类故障的常见原因主要包括:

·     聚合接口配置错误。

·     成员端口物理链路故障。

·     LACP协议报文收发故障。

3. 故障分析

本类故障的诊断思路如下:

(1)     通过display link-aggregation verbose查看成员端口是否处于选中状态,如果处于非选中状态,则通过display interface命令查询成员端口物理状态是否UP,排除端口物理故障影响。

(2)     检查本端和对端聚合接口配置,排除配置问题。

(3)     使用debugging link-aggregation lacp packet命令查看动态聚合的成员端口LACP协议交互情况。

本类故障的诊断流程如图6-1所示。

图6-1 聚合接口无法UP的故障诊断流程图

 

4. 处理步骤

(1)     排查物理连线是否准确。

根据聚合接口的组网规划进行线路检查,确认物理链接线路是否完全按照规划连接。

如果物理连线正确,则执行步骤(2)。

(2)     聚合接口是否被手工关闭。

执行display interface命令查看聚合接口的物理状态,如果显示为“Administratively DOWN”,则表示聚合接口被手工关闭,请执行undo shutdown命令开启聚合接口。如果聚合接口未被手工关闭,则执行步骤(3)。

(3)     聚合组中成员端口是否UP。

执行display interface命令查看聚合组中的成员端口是否处于UP状态,如果没有UP,请按照端口不UP故障流程处理。

如果端口处于UP状态,则执行步骤(4)。

以如下显示为例,二层聚合组1中成员端口GigabitEthernet3/1/1处于非选中状态。执行display interface命令查看GigabitEthernet3/1/1的物理状态时,物理状态显示为“DOWN”,使成员端口GigabitEthernet3/1/1处于非选中状态。

<Sysname> display link-aggregation verbose

Loadsharing Type: Shar -- Loadsharing, NonS -- Non-Loadsharing

Port Status: S -- Selected, U -- Unselected, I -- Individual

Port: A -- Auto port, M -- Management port, R -- Reference port

Flags:  A -- LACP_Activity, B -- LACP_Timeout, C -- Aggregation,

        D -- Synchronization, E -- Collecting, F -- Distributing,

        G -- Defaulted, H -- Expired

 

Aggregate Interface: Bridge-Aggregation1

Aggregation Mode: Static

Loadsharing Type: Shar

Management VLANs: None

  Port             Status  Priority Oper-Key

  GE3/1/1          U       32768    1

<Sysname> display interface gigabitethernet 3/1/2

GigabitEthernet3/1/2

Current state: DOWN

Line protocol state: DOWN

IP packet frame type: Ethernet II, hardware address: 2a41-21c1-0100

Description: GigabitEthernet3/1/2 Interface

Bandwidth: 1000000 kbps

Loopback is not set

Unknown-speed mode, full-duplex mode

Link speed type is autonegotiation, link duplex type is force link

Flow-control is not enabled

Maximum frame length: 9216

Allow jumbo frames to pass

Broadcast max-ratio: 100%

Multicast max-ratio: 100%

Unicast max-ratio: 100%

Known-unicast max-ratio: 100%

PVID: 1

MDI type: Automdix

Port link-type: Access

 Tagged VLANs:   None

 Untagged VLANs: 1

Port priority: 2

Last link flapping: 0 hours 0 minutes 15 seconds

Last clearing of counters: Never

Current system time:2021-08-10 10:15:02

Last time when physical state changed to up:2021-08-09 18:31:43

Last time when physical state changed to down:2021-08-10 10:14:47

 Peak input rate: 0 bytes/sec, at 00-00-00 00:00:00

 Peak output rate: 0 bytes/sec, at 00-00-00 00:00:00

 Last 300 seconds input: 5000 packets/sec 5000 bytes/sec -%

 Last 300 seconds output: 5000 packets/sec 5000 bytes/sec -%

 Input (total):  5000 packets, 5000 bytes

         5000 unicasts, 5000 broadcasts, 5000 multicasts, 0 pauses

 Input (normal):  0 packets, 0 bytes

         0 unicasts, 0 broadcasts, 0 multicasts, 0 pauses

 Input:  5000 input errors, 0 runts, 0 giants, 0 throttles

         0 CRC, 0 frame, 0 overruns, 0 aborts

         5000 ignored, 0 parity errors

 Output (total): 5000 packets, 5000 bytes

         5000 unicasts, 5000 broadcasts, 5000 multicasts, 0 pauses

 Output (normal): 0 packets, 0 bytes

         0 unicasts, 0 broadcasts, 0 multicasts, 0 pauses

 Output: 5000 output errors, 0 underruns, 0 buffer failures

         5000 aborts, 0 deferred, 0 collisions, 0 late collisions

         0 lost carrier, 0 no carrier

(4)     判断聚合接口是否为动态聚合。

¡     如果聚合接口为动态聚合,则检查对端聚合接口的配置是否正确,即对端聚合接口是否为动态聚合。在任意视图下执行display link-aggregation verbose命令,查看链路两端聚合接口的聚合模式,确保两端聚合模式相同。

以二层聚合接口为例,显示“Aggregation Mode: Dynamic”时,表示该聚合接口为动态聚合:

<Sysname> display link-aggregation verbose bridge-aggregation 10

Loadsharing Type: Shar -- Loadsharing, NonS -- Non-Loadsharing

Port Status: S -- Selected, U -- Unselected, I -- Individual

Port: A -- Auto port, M -- Management port, R -- Reference port

Flags:  A -- LACP_Activity, B -- LACP_Timeout, C -- Aggregation,

        D -- Synchronization, E -- Collecting, F -- Distributing,

        G -- Defaulted, H -- Expired

 

Aggregate Interface: Bridge-Aggregation10

Creation Mode: Manual

Aggregation Mode: Dynamic

Loadsharing Type: Shar

Management VLANs: None

System ID: 0x8000, 000f-e267-6c6a

Local:

  Port                Status   Priority Index    Oper-Key               Flag

  GE3/1/1             S        32768    61       2                      {ACDEF}

  GE3/1/2             S        32768    62       2                      {ACDEF}

  GE3/1/3             S        32768    63       2                      {ACDEF}

Remote:

  Actor               Priority Index    Oper-Key SystemID               Flag

  GE3/1/1(R)          32768    111      2        0x8000, 000f-e267-57ad {ACDEF}

  GE3/1/2             32768    112      2        0x8000, 000f-e267-57ad {ACDEF}

  GE3/1/3             32768    113      2        0x8000, 000f-e267-57ad {ACDEF}

如果配置不正确,则修改对端聚合接口为动态聚合;如果配置正确,则执行debugging link-aggregation lacp packet命令确认LACP报文收发是否正确。

执行debugging link-aggregation lacp packet命令后,查看成员端口send信息中Actor信息和receive信息中Partner信息。如果sys-mac、key和port-index字段的显示不一致,则LACP协议报文收发不正常,请排除收发光纤错接问题;如果sys-mac、key和port-index字段的显示一致,则LACP协议报文收发正常,请执行步骤(5)。

打开聚合组成员端口GigabitEthernet3/1/1的LACP报文调试信息开关,查看该端口收发LACP协议报文的情况。

<Sysname> debugging link-aggregation lacp packet all interface gigabitethernet 3/1/1

*Nov  2 15:51:21:15 2007 Sysname LAGG/7/Packet: PACKET.GigabitEthernet3/1/1.send.

 size=110, subtype =1, version=1

 Actor: type=1, len=20, sys-pri=0x8000, sys-mac=00e0-fc02-0300, key=0x1, pri=0x8000, port-index=0x2, state=0xc5

 Partner: type=2, len=20, sys-pri=0x0, sys-mac=0000-0000-0000, key=0x0, pri=0x0, port-index=0x0, state=0x32

 Collector: type=3, len=16, col-max-delay=0x0

 Terminator: type=0, len=0

*Nov  2 15:55:21:15 2007 Sysname LAGG/7/Packet: PACKET.GigabitEthernet3/1/1.receive.

size=110, subtype =1, version=1

 Actor: type=1, len=20, sys-pri=0x8000, sys-mac=00e0-fc00-0000, key=0x1, pri=0x8000, port-index=0x6, state=0xd

 Partner: type=2, len=20, sys-pri=0x8000, sys-mac=00e0-fc02-0300, key=0x1, pri=0x8000, port-index=0x2, state=0xc5

 Collector: type=3, len=16, col-max-delay=0x0

 Terminator: type=0, len=0

¡     如果聚合接口为静态聚合,则执行步骤(5)。

(5)     查看聚合接口下最小选中端口的配置是否影响成员端口选中。

在聚合接口视图下执行display this命令,如果存在link-aggregation selected-port minimum的配置,请修改最小选中端口数值,使其满足最小选中要求。当聚合组内能够被选中的成员端口数增加至不小于配置值时,这些成员端口都将变为选中状态,对应聚合接口的链路状态也将变为UP。

如果聚合接口下最小选中端口的配置未影响成员端口选中,则执行步骤(6)。

以如下显示为例,二层聚合接口1下配置的最小选中端口数为2,而二层聚合接口1对应的聚合组的成员端口仅有一个,所以该成员端口处于非选中状态。

[Sysname-Bridge-Aggregation1] display this

#

interface Bridge-Aggregation1

 link-aggregation selected-port minimum 2

#

return

[H3C-Bridge-Aggregation1] display link-aggregation verbose

Loadsharing Type: Shar -- Loadsharing, NonS -- Non-Loadsharing

Port Status: S -- Selected, U -- Unselected, I -- Individual

Port: A -- Auto port, M -- Management port, R -- Reference port

Flags:  A -- LACP_Activity, B -- LACP_Timeout, C -- Aggregation,

        D -- Synchronization, E -- Collecting, F -- Distributing,

        G -- Defaulted, H -- Expired

 

Aggregate Interface: Bridge-Aggregation1

Aggregation Mode: Static

Loadsharing Type: Shar

Management VLANs: None

  Port             Status  Priority Oper-Key

  GE3/1/        U       32768    1

(6)     聚合组内是否存在选中的成员端口。

如果聚合组内不存在选中的成员端口,则请参见“6.2.3  聚合成员端口无法选中”故障进行定位;如果聚合组内存在选中的成员端口,则执行步骤(7)。

(7)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

5. 告警与日志

相关告警

相关日志

6.2.2  聚合接口流量负载分担不均

1. 故障描述

当两台设备通过链路聚合连接时,通过display counters rate命令查看聚合成员端口出方向流量速率,某些成员端口速率特别小或者根本没有

2. 常见原因

本类故障的常见原因主要为聚合负载分担方式配置错误。

3. 故障分析

本类故障的诊断思路为确认聚合口转发的报文的特征,并查看聚合负载分担类型是否和报文特性匹配。

本类故障的诊断流程如图6-2所示。

图6-2 聚合接口流量负载分担不均的故障诊断流程图

 

4. 处理步骤

(1)     查看聚合负载分担类型与报文特征是否匹配。

通过执行display link-aggregation load-sharing mode命令查看聚合负载分担类型,如果与报文特征不匹配,则通过在系统视图下执行link-aggregation global load-sharing mode命令调整全局的负载分担类型。

针对不同业务流量,不同产品调整的负载分担类型不同,请以设备实际情况为准。

如果聚合负载分担类型与报文特征匹配,则执行步骤(2)。

(2)     检查是否部署跨板/跨框聚合。

在IRF环境下,如果部署跨板/跨框聚合,则在系统视图下使用undo link-aggregation load-sharing mode local-first命令关闭本地优先转发功能。如果关闭本地优先转发功能,则可能导致跨板/跨框流量不能过大,影响IRF系统稳定,请根据实际情况进行操作。

如果未部署跨板/跨框聚合,则执行步骤(3)。

需要注意,跨板/跨框流量不能过大,否则可能影响IRF系统稳定。

(3)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

5. 告警与日志

相关告警

相关日志

6.2.3  聚合成员端口无法选中

1. 故障描述

当两台设备通过链路聚合连接时,发现聚合组成员端口处于非选中状态,聚合失败。

2. 常见原因

本类故障的常见原因主要包括:

·     链路连通性故障。

·     本端和对端的操作key、属性类配置不一致。

·     聚合成员端口数配置错误。

3. 故障分析

本类故障的诊断思路如下:

(1)     查看成员端口是否UP,排除端口物理故障影响。

(2)     使用debugging link-aggregation lacp packet命令查看动态聚合的成员端口LACP协议交互情况。

(3)     检查本端和对端聚合接口配置,排除配置影响。

本类故障的诊断流程如图6-3所示。

图6-3 聚合成员端口无法选中的故障诊断流程图

 

4. 处理步骤

(1)     排查物理连线是否正确。

根据聚合接口的组网规划进行线路检查,确认物理链接线路是否完全按照规划连接。

如果物理连线正确,则执行步骤(2)。

(2)     聚合组中成员端口是否UP

通过display interface命令查看聚合组中的成员端口是否处于UP状态,如果没有UP按照端口不UP故障流程处理。

如果端口处于UP状态,则执行步骤(3)。

(3)     本端成员端口的属性类配置与聚合接口是否相同。

a.     执行display link-aggregation verbose命令查看本端处于Unselected状态的成员端口。

以二层聚合接口为例,Status字段显示为“U”时,表示该成员处于Unselected状态:

<Sysname> display link-aggregation verbose

Loadsharing Type: Shar -- Loadsharing, NonS -- Non-Loadsharing

Port Status: S -- Selected, U -- Unselected, I -- Individual

Port: A -- Auto port, M -- Management port, R -- Reference port

Flags:  A -- LACP_Activity, B -- LACP_Timeout, C -- Aggregation,

        D -- Synchronization, E -- Collecting, F -- Distributing,

        G -- Defaulted, H -- Expired

 

Aggregate Interface: Bridge-Aggregation1

Creation Mode: Manual

Aggregation Mode: Dynamic

Loadsharing Type: Shar

Management VLANs: None

System ID: 0x8000, 2a41-21c1-0100

Local:

  Port                Status   Priority Index    Oper-Key               Flag

  GE3/1/1(R)          S        32768    1        1                      {ACDEF}

  GE3/1/2             S        32768    2        1                      {ACDEF}

  GE3/1/3             U        32768    3        2                      {AC}

Remote:

  Actor               Priority Index    Oper-Key SystemID               Flag

  GE3/1/1             32768    1        1        0x8000, 36f6-c0aa-0200 {ACDEF}

  GE3/1/2             32768    2        1        0x8000, 36f6-c0aa-0200 {ACDEF}

  GE3/1/3             32768    3        1        0x8000, 36f6-c0aa-0200 {AC}

b.     执行display current-configuration interface命令查看本端处于Unselected状态的成员端口的属性类配置(VLAN等配置)与聚合接口是否相同,如果不同,则将其配置相同。

以如下显示为例,处于Unselected状态的成员端口GigabitEthernet3/1/3与参考端口GigabitEthernet3/1/1的属性类配置不同,导致该成员端口无法选中,需要修改成员端口GigabitEthernet3/1/3的属性类配置。

<Sysname> display current-configuration interface gigabitethernet 3/1/1

#

interface GigabitEthernet3/1/1

 port link-mode bridge

 port link-type trunk

 port trunk permit vlan 1 to 20

 port link-aggregation group 1

#

return

<Sysname> display current-configuration interface bridge-aggregation 1

#

interface Bridge-Aggregation1

 port link-type trunk

 port trunk permit vlan 1 to 100

 link-aggregation mode dynamic

#

return

如果本端成员端口的属性类配置与聚合接口相同,则执行步骤(4)。

(4)     本端成员端口的操作key与参考端口是否相同。

a.     执行display link-aggregation verbose命令查看本端处于Unselected状态的成员端口。

以二层聚合接口为例,Status字段显示为“U”时,表示该成员处于Unselected状态:

<Sysname> display link-aggregation verbose

Loadsharing Type: Shar -- Loadsharing, NonS -- Non-Loadsharing

Port Status: S -- Selected, U -- Unselected, I -- Individual

Port: A -- Auto port, M -- Management port, R -- Reference port

Flags:  A -- LACP_Activity, B -- LACP_Timeout, C -- Aggregation,

        D -- Synchronization, E -- Collecting, F -- Distributing,

        G -- Defaulted, H -- Expired

 

Aggregate Interface: Bridge-Aggregation11

Creation Mode: Manual

Aggregation Mode: Dynamic

Loadsharing Type: Shar

Management VLANs: None

System ID: 0x8000, 2a41-21c1-0100

Local:

  Port                Status   Priority Index    Oper-Key               Flag

  GE3/1/1(R)          S        32768    1        1                      {ACDEF}

  GE3/1/2             S        32768    2        1                      {ACDEF}

  GE3/1/3             U        32768    3        2                      {AC}

Remote:

  Actor               Priority Index    Oper-Key SystemID               Flag

  GE3/1/1             32768    1        1        0x8000, 36f6-c0aa-0200 {ACDEF}

  GE3/1/2             32768    2        1        0x8000, 36f6-c0aa-0200 {ACDEF}

  GE3/1/3             32768    3        1        0x8000, 36f6-c0aa-0200 {AC}

b.     执行display current-configuration interface命令查看本端处于Unselected状态的成员端口的操作key(包括该端口的速率、双工模式等)与参考端口是否相同,如果不同,则将其配置相同。

以如下显示为例,处于Unselected状态的成员端口GigabitEthernet3/1/3与参考端口GigabitEthernet3/1/1的操作key不同,导致该成员端口无法选中,需要修改该端口速率配置。

<Sysname> display current-configuration interface gigabitethernet 3/1/1

#

interface GigabitEthernet3/1/1

 port link-mode bridge

 combo enable fiber

 port link-aggregation group 11

#

return

<Sysname> display current-configuration interface gigabitethernet 3/1/3

#

interface GigabitEthernet3/1/3

 port link-mode bridge

 combo enable fiber

 speed 100

 port link-aggregation group 11

#

return

如果本端成员端口的操作key与参考端口相同,则执行步骤(5)。

(5)     本端聚合接口是否为动态聚合。

如果是动态聚合,则执行步骤(6);如果是静态聚合,否则进行步骤(8)

(6)     LACP报文收发是否正确。

执行debugging link-aggregation lacp packet命令确认LACP报文收发是否正确。执行命该令后,查看成员端口send信息中Actor信息和receive信息中Partner信息。如果sys-mac、key和port-index字段的显示不一致,则LACP协议报文收发不正常,请排除收发光纤错接问题;如果sys-mac、key和port-index字段的显示一致,则LACP协议报文收发正常,请执行步骤(7)。

打开聚合组成员端口GigabitEthernet3/1/1的LACP报文调试信息开关,查看该端口收发LACP协议报文的情况。

<Sysname> debugging link-aggregation lacp packet all interface gigabitethernet 3/1/1

*Nov  2 15:51:21:15 2021 Sysname LAGG/7/Packet: PACKET.GigabitEthernet3/1/1.send.

 size=110, subtype =1, version=1

 Actor: type=1, len=20, sys-pri=0x8000, sys-mac=00e0-fc02-0300, key=0x1, pri=0x8000, port-index=0x2, state=0xc5

 Partner: type=2, len=20, sys-pri=0x0, sys-mac=0000-0000-0000, key=0x0, pri=0x0, port-index=0x0, state=0x32

 Collector: type=3, len=16, col-max-delay=0x0

 Terminator: type=0, len=0

*Nov  2 15:55:21:15 2021 Sysname LAGG/7/Packet: PACKET.-GigabitEthernet3/1/1.receive.

size=110, subtype =1, version=1

 Actor: type=1, len=20, sys-pri=0x8000, sys-mac=00e0-fc00-0000, key=0x1, pri=0x8000, port-index=0x6, state=0xd

 Partner: type=2, len=20, sys-pri=0x8000, sys-mac=00e0-fc02-0300, key=0x1, pri=0x8000, port-index=0x2, state=0xc5

 Collector: type=3, len=16, col-max-delay=0x0

 Terminator: type=0, len=0

(7)     本端成员端口的对端端口的操作key和属性类配置与参考端口的对端端口是否相同。

在本端Unselected端口的对端设备上执行display current-configuration interface命令查看对端Unselected端口的属操作key和属性类配置与参考端口的对端端口是否相同,如果不同,则将其配置相同。

如果本端成员端口的对端端口的操作key和属性类配置与参考端口的对端端口相同,则执行步骤(8)。

(8)     聚合成员端口数量是否达到阈值。

¡     聚合成员端口数超过上限。

可在聚合接口视图下通过link-aggregation selected-port maximum命令配置聚合组中的最大选中端口数。通过display link-aggregation verbose命令查看聚合组中成员端口数是否超过上限,如果超过上限,则多出来的端口为Unselected状态,Selected端口按照端口编号从小到大排序。请在成员端口视图下使用undo port link-aggregation group命令将Selected端口中不适用的端口从聚合组中删除,以使必须使用的端口能够选中。

¡     聚合成员端口数低于下限。

可在聚合接口视图下执行link-aggregation selected-port minimum命令配置聚合组中的最小选中端口数。通过display link-aggregation verbose命令查看聚合组中成员端口是否低于下限,如果低于下限,则所有成员端口为Unselected状态。请执行link-aggregation selected-port minimum命令修改最小选中端口数值或者为聚合组添加成员端口,使其满足最小选中要求。

如果聚合成员端口数量未达到聚合组的阈值,则执行步骤(9)。

(9)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

5. 告警与日志

相关告警

相关日志

6.3  VLAN转发故障

6.3.1  故障描述

故障现象通常有二层VLAN单播、广播业务异常。

6.3.2  故障处理步骤

1. 检查生成树协议的状态

使用display stp brief命令查看设备上是否开启了生成树协议。

[Sysname] display stp brief

 MST ID   Port                                Role  STP State   Protection

 0        Bridge-Aggregation1                 DESI  FORWARDING  NONE

 0        GigabitEthernet3/1/1                DESI  LEARNING    NONE

如果因为开启了生成树协议导致二层VLAN流量不通,可以使用undo stp global enable命令全局关闭生成树协议。

2. 检查VLAN配置的正确性

(1)     通过display interface命令检查端口是否允许打入流量的VLAN通过。如果端口未允许打入流量的VLAN通过,则需要在端口下配置允许该VLAN通过。

(2)     使用命令display vlan 4094命令查看VLAN 4094是否被创建。

[Sysname] display vlan 4094

 VLAN ID: 4094

 VLAN type: Static

 Route interface: Not configured

 Description: VLAN 4094

 Name: VLAN 4094

 Tagged ports:   None

 Untagged ports: None

·     以下单板的端口不支持VLAN 4094。请不要将这些端口加入VLAN 4094。

¡     SPC类单板

¡     MPE-1104单板

3. 检查QinQ配置的正确性

使用display qinq命令检查端口是否使能了QinQ。

当端口上配置了QinQ功能后,不论从该端口收到的报文是否带有VLAN Tag,设备都会为该报文添加本端口PVID的Tag。注意此时该端口打入流量的实际生效VLAN是QinQ功能封装的VLAN。

6.4  生成树故障处理

6.4.1  设备连接成环时业务中断

1. 故障描述

多台设备通过物理链路连接成环时,业务流量中断。

2. 常见原因

本类故障的常见原因包括:

·     设备接口的物理状态为DOWN。

·     设备的生成树功能处于关闭状态。

3. 故障分析

本类故障的诊断流程如图6-4所示。

图6-4 设备连接成环时业务中断的故障诊断流程图

 

4. 处理步骤

(1)     检查承载业务流量的接口状态是否为UP。

a.     检查接口的物理状态是否为UP。

执行display interface brief命令,通过“Link”字段查看网络中的接口物理状态是否为UP,例如:

<Sysname> display interface brief

Brief information on interfaces in route mode:

Link: ADM - administratively down; Stby - standby

Protocol: (s) - spoofing

Interface                         Link Protocol Primary IP      Description

InLoop0                           UP   UP(s)    --

MGE0/0/0                          DOWN DOWN     --

NULL0                             UP   UP(s)    --

REG0                              UP   --       --

 

Brief information on interfaces in bridge mode:

Link: ADM - administratively down; Stby - standby

Speed: (a) - auto

Duplex: (a)/A - auto; H - half; F - full

Type: A - access; T - trunk; H - hybrid

Interface                         Link Speed   Duplex Type PVID Description

GE3/1/1                           UP    auto    A      A    1

GE3/1/2                           DOWN  auto    A      A    1

GE3/1/3                           ADM   auto    A      A    1

-     如果网络中接口的状态为UP,请执行步骤b。

-     如果网络中接口的状态为ADM,请在接口视图下执行undo shutdown命令开启该接口。如果接口的状态仍为DOWN,请进行接口链路以及相关配置的排查;如果此时接口的状态为UP,但是故障仍未解决,请执行步骤b。

-     如果网络中接口的状态为DOWN,请进行接口链路以及相关配置的排查。接口状态恢复UP后,如果故障仍未解决,请执行步骤b。

b.     检查接口的数据链路层协议状态是否为UP。接口的数据链路层协议为DOWN的接口无法参与生成树拓扑的计算。

执行display interface命令,通过“Line protocol state”字段查看网络中的接口数据链路层协议状态是否为UP,例如:

<Sysname> display interface gigabitethernet 3/1/2

GigabitEthernet3/1/2

Current state: UP

Line protocol state: DOWN(LAGG)

...

DOWN(protocols)表示接口的数据链路层被一个或者多个协议模块关闭。protocols为多个协议的任意组合,可能的协议如下:

-     DLDP:由于DLDP模块检测到单通而关闭接口的数据链路层。

-     OAM:由于以太网OAM模块检测到远端链路故障而关闭接口的数据链路层。

-     LAGG:聚合接口中没有选中的成员端口而关闭接口的数据链路层。

-     BFD:由于BFD模块检测到链路故障而关闭接口的数据链路层。

-     VBP:由于配置二层转发功能后而关闭接口的数据链路层。

如果接口的数据链路层被上述协议关闭,请检查并修改这些模块的配置,使得接口的数据链路层协议状态恢复为UP。如果接口的数据链路层协议状态恢复为UP后,故障仍未解决,请执行步骤(2)。

(2)     检查设备的生成树功能是否开启。

a.     检查设备上全局生成树功能是否开启。

执行display stp命令:

-     如果出现如下显示信息,则表示全局的生成树协议未开启:

<Sysname> display stp

 Protocol status    : Disabled

 Protocol Std.      : IEEE 802.1s

 Version            : 3

 Bridge-Prio.       : 32768

 MAC address        : 2eae-3769-0200

 Max age(s)         : 20

 Forward delay(s)   : 15

 Hello time(s)      : 2

 Max hops           : 20

 TC Snooping        : Disabled

 

<Sysname> display stp

STP is not configured.

请在系统视图下执行stp global enable命令开启全局的生成树功能。

-     如果出现生成树的状态和统计信息(如下所示),则说明全局的生成树功能已经开启,请继续执行步骤b。

<Sysname> display stp

-------[CIST Global Info][Mode MSTP]-------

 Bridge ID           : 32768.2eae-3769-0200

 Bridge times        : Hello 2s MaxAge 20s FwdDelay 15s MaxHops 20

 Root ID/ERPC        : 32768.2eae-3769-0200, 0

 RegRoot ID/IRPC     : 32768.2eae-3769-0200, 0

 RootPort ID         : 0.0

 BPDU-Protection     : Disabled

 Bridge Config-

 Digest-Snooping     : Disabled

 TC or TCN received  : 0

 Time since last TC  : 0 days 2h:49m:11s

 

----[Port1(GigabitEthernet3/1/1)][DOWN]----

 Port protocol       : Enabled

 Port role           : Disabled Port

 Port ID             : 128.54

 Port cost(Legacy)   : Config=auto, Active=200000

 Desg.bridge/port    : 32768.2eae-3769-0200, 128.54

 Port edged          : Config=disabled, Active=disabled

 Point-to-Point      : Config=auto, Active=false

 Transmit limit      : 10 packets/hello-time

 TC-Restriction      : Disabled

 Role-Restriction    : Disabled

 Protection type     : Config=none, Active=none

 MST BPDU format     : Config=auto, Active=802.1s

 Port Config-

 Digest-Snooping     : Disabled

 Rapid transition    : False

 Num of VLANs mapped : 1

 Port times          : Hello 2s MaxAge 20s FwdDelay 15s MsgAge 0s RemHops 20

 BPDU sent           : 0

          TCN: 0, Config: 0, RST: 0, MST: 0

 BPDU received       : 0

          TCN: 0, Config: 0, RST: 0, MST: 0

b.     (仅生成树模式为PVST时适用,非PVST模式请继续执行步骤c)检查VLAN的生成树功能是否开启。

在系统视图下,执行display this命令,查看是否存在undo stp vlan enable命令的配置,例如:

[Sysname] display this

...

#

 undo stp vlan 2 enable

 stp mode pvst

 stp global enable

#

...

如果存在上述配置且网络中需要开启对应VLAN的生成树功能,请在系统视图下执行stp vlan enable命令,开启VLAN的生成树功能。

c.     检查接口的生成树功能是否开启。

执行display stp命令,查看是否存在生成树功能未开启的接口,例如:

<Sysname> display stp

...

----[Port2(GigabitEthernet3/1/2)][DISABLED]----

 Port protocol       : Disabled

...

请在需要参与生成树计算的接口视图下执行stp enable命令,开启接口的生成树功能。

(3)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

5. 告警与日志

相关告警

相关日志

6.4.2  接入生成树网络的用户终端设备发生掉线

1. 故障描述

用户终端设备接入生成树网络时,连接终端设备的接口发生闪断,业务长时间丢包,造成终端设备掉线。

2. 常见原因

本类故障的常见原因为:连接用户终端设备的接口未被配置为边缘端口。

3. 故障分析

本类故障的诊断流程如图6-5所示。

图6-5 接入生成树网络的用户终端设备发生掉线的故障诊断流程图

 

4. 处理步骤

(1)     检查生成树网络中与用户终端设备直连的接口是否为边缘端口。

在与用户终端设备直连的生成树网络设备上执行display stp命令,查看与用户终端设备直连的接口是否为边缘端口,例如:

<Sysname> display stp

...

----[Port2(GigabitEthernet3/1/1)][FORWARDING]----

 Port protocol       : Enabled

 Port role           : Designated Port

 Port ID             : 128.2

 Port cost(Legacy)   : Config=auto, Active=20

 Desg.bridge/port    : 32768.2eae-3769-0200, 128.2

 Port edged          : Config=enabled, Active=enabled

 Point-to-Point      : Config=auto, Active=true

 Transmit limit      : 10 packets/hello-time

 Protection type     : Config=none, Active=none

 Rapid transition    : True

 Port times          : Hello 2s MaxAge 20s FwdDelay 15s MsgAge 0s

...

¡     如果与用户终端设备直连的接口是边缘端口,请执行步骤(2)。

¡     如果与用户终端设备直连的接口不是边缘端口,请进入该接口视图,并执行stp edged-port命令,将该端口配置为边缘端口。

说明

在接口下不能同时配置边缘端口和环路保护功能,执行stp edged-port命令时,如果设备打印如下错误提示信息,说明当前接口已经配置了环路保护功能。此时需要先执行undo stp loop-protection命令关闭环路保护功能,才能将该端口配置为边缘端口。

 

Failed to enable edged-port on GigabitEthernet3/1/1, because loop-protection is enabled.

(2)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

5. 告警与日志

相关告警

相关日志

·     STP/6/STP_DETECTED_TC

6.4.3  非0实例端口状态为主端口且无法调整

1. 故障描述

在MSTP网络中,设备上除了MSTI 0之外的其他实例,本不应该是主端口角色的端口被计算为了主端口,且端口角色无法通过调整优先级、开销值等参数来改变。

2. 常见原因

本类故障的常见原因为:同一MST域内,不同设备对MST域的配置不一致。

3. 故障分析

如果两台设备对MST域的配置不一致,则设备会认为对端设备与本端设备不在同一个MST域中,导致与域内设备相连的端口也被计算为了主端口。所以本类故障的诊断思路为:检查同一MST域内设备的MST域配置信息,确保各个设备的配置保持一致。

本类故障的诊断流程如图6-6所示。

图6-6 非0实例端口状态为主端口且无法调整的故障处理流程图

 

4. 处理步骤

(1)     检查同一MST域内的设备对于MST域的域名、修订级别以及VLAN映射表配置是否相同,并确保这些参数的配置一致。

执行display stp region-configuration命令,显示设备生效的MST域配置信息。例如:

<Sysname> display stp region-configuration

 Oper Configuration

   Format selector      : 0

   Region name          : hello

   Revision level       : 0

   Configuration digest : 0x5f762d9a46311effb7a488a3267fca9f

 

   Instance   VLANs Mapped

   0          21 to 4094

   1          1 to 10

   2          11 to 20

¡     Region name:MST域的域名,在系统视图下执行stp region-configuration命令进入MST域视图后,通过region-name命令进行配置。

¡     Revision level:MST域的修订级别,在系统视图下执行stp region-configuration命令进入MST域视图后,通过revision-level命令进行配置。

¡     Instance   VLANs Mapped:MST域的VLAN映射关系,在系统视图下执行stp region-configuration命令进入MST域视图后,可以通过instance命令或vlan-mapping modulo命令进行配置。

如果同一MST域内不同设备的上述参数配置不相同,请执行上述操作将参数的配置修改为一致配置完MST域的相关参数后,必须在MST域视图下执行active region-configuration命令,用户对MST域的配置才能激活并生效,否则MST域仍会按照之前的配置生效。

(2)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

5. 告警与日志

相关告警

相关日志


7 三层技术-IP业务故障处理

7.1  ARP故障

7.1.1  故障描述

无法学习到对端设备的ARP表项。

7.1.2  故障处理步骤

1. 查看ARP调试信息

使用debugging arp packet命令打开ARP调试信息开关,当对端ping本设备时,可以看到下列调试信息。如果未显示ARP请求报文信息,则说明未接收到请求报文;如果未显示ARP应答报文,则说明本设备未应答ARP请求。

<Sysname> *Sep 24 19:15:52:655 2019 H3C ARP/7/ARP_RCV: -MDC=1-Slot=5; Received an ARP message, operation: 1, sender MAC: 1cab-343a-6145,sender IP: 222.3.1.2, target MAC: 0000-0000-0000, target IP: 222.3.1.1

// 接收ARP请求报文

*Sep 24 19:15:52:656 2019 H3C ARP/7/ARP_SEND: -MDC=1-Slot=5; Sent an ARP message, operation: 2, sender MAC: 70f9-6da7-5074, sender IP: 222.3.1.1, target MAC: 1cab-343a-6145, target IP: 222.3.1.2

// 发送ARP应答报文

2. 报文计数分析

·     如果设备未收到Ping报文,请排查上游的相邻设备;如果设备收到Ping报文,分析ARP报文在本端是否上送给平台。

·     对端ping本设备,本端设备使用display hardware internal rxpkt-in slot slotid cpu cpuid命令查看报文收发模块收到的上送报文:

[Sysname-probe] display hardware internal rxtx rxpkt-in slot 2 cpu 0

[H3C-probe] %Aug 11 08:34:36:459 2022 H3C IFNET/3/PHY_UPDOWN: -MDC=1; GigabitEthernet2/2/1 link status is up.

%Aug 11 08:34:36:459 2022 H3C IFNET/5/LINK_UPDOWN: -MDC=1; Line protocol on the interface GigabitEthernet2/2/1 is up.

*Aug 11 08:34:41:006 2022 H3C RXTX/7/DBG: -MDC=1-Slot=2;

 Time on LPU: 2022-08-11  08:34:41  5ms

Receive packet from chip :

 DevNum = 9, PhyPortNo = 33, PacketLen = 60, CpuCode = 17, Left = 14

0000: ff ff ff ff ff ff 00 00 2e 3b f4 03 08 06 00 01

0010: 08 00 06 04 00 01 00 00 2e 3b f4 03 16 01 00 02

0020: 00 00 00 00 00 00 16 01 00 02 00 00 00 00 00 00

0030: 00 00 00 00 00 00 00 00 00 00 00 00 33 d4 92 9c

 

*Aug 11 08:34:41:007 2022 H3C RXTX/7/DBG: -MDC=1-Slot=2;

 Time on LPU: 2022-08-11  08:34:41  7ms

Receive packet from chip :

 DevNum = 9, PhyPortNo = 33, PacketLen = 60, CpuCode = 17, Left = 13

0000: ff ff ff ff ff ff 00 00 2e 3b f4 03 08 06 00 01

0010: 08 00 06 04 00 01 00 00 2e 3b f4 03 16 01 00 02

0020: 00 00 00 00 00 00 16 01 00 02 00 00 00 00 00 00

0030: 00 00 00 00 00 00 00 00 00 00 00 00 33 d4 92 9c

 

本端设备使用display hardware internal rxtx packet statistic slot slotid cpu cpuid clear命令查看报文收发模块上送CPU计数,

[Sysname-probe] display hardware internal rxtx packet statistic slot 2 cpu 0 clear

Net port packet loss count:

 code       counter

Rx packets statistic:

                     counter     success        rate

 NET  -> RXTX   :           6           6           0 pps

 

Cpu code input list:

 code       counter       success

   17             2             2

   30             4             4

 

Callback function packets statistic:

            total(r)   success(r)     total(c)   success(c)

  MACL:            0            0            0            0

  NATL:            0            0            0            0

   BFD:            0            0            0            0

 

Task input pkt statistics:

 Task name           total       success

 Main Task :             6             6

 Icmp Task :             0             0

 

3. 查看本机路由和Inlif表项

若报文收发模块没有收到报文,请查看本机路由和InLif表是否下发正确。

(1)     检查本机路由下发是否正确,如果上送标记Th没有置位,请联系技术支持人员分析。

[H3C-probe] display hardware internal l3 np fib 22.1.0.1 32 slot 2 chip 0

 

 The FTN/FIB table Handle<0x10> ECMPNum<0/1> !

 ChipID is 0

 LPM:

 LPM KEY: VPNID = 0  IP_Prefix = 22.1.0.1/4294967295

 LPM RESULT:

   00001017 0fffff00

 Ipv4-route tag:

 Valid = 1     Parity = 1    Local = 1

 Drop = 0      ToHost = 1    Ecmp = 0

 Dft_Sys = 0   Dft_User = 0  NextHopIdxOrEcmpPtr = 16

 LifId = 1048575     EcmpNum = 0

 FWD-FTN:

 FWD-FTN KEY: NextHopIdx = 0x10

 FWD-FTN RESULT:

 ECMP = 0  Th = 1  Normal = 0 Drop = 0

 OutlifId/ToHostId = 76

 Dft_User = 0  Dft_Sys = 0

 Es = 0  Ts = 0  DhcpH = 0

 Local = 1  Parity = 1  V = 1 TTL = 255

 StackEnd = 0  Label_v = 0  Label = 0  Label_bak = 0

 Rd = 0  Rq = 0  Dscp = 0  QosLocalId = 0

(2)     查看Inlif表项,L3,IPv4,ArpProxy是否置位,如果没置位,请联系技术支持人员分析。

[Sysname-probe] display hardware internal lif np inlif slot 2 GigabitEthernet 2/2/1

 

 Inlif Table : KEY(vlan=4095,port=32)

               RESULT(08060001, 0030d001, 00008000, 00000000, 00000000, 00000000, 00000000, 00000000)

 RES:

 un0.gen.uiSa:1 = 0

 un0.gen.uiV4m:1 = 0

 un0.gen.uiBlock:1 = 0

 un0.gen.uiDs:1 = 0

 un0.gen.uiV4Acl:1 = 1

 un0.gen.uiV4Rpf:1 = 0

 un0.gen.uiV4Qppb:1 = 0

 un0.gen.uiV4Sq:1 = 0

 un0.gen.uiMldv2:1 = 0

 un0.gen.ui8021ag:1 = 0

 un0.gen.uiRsvp:1 = 0

 un0.gen.uiMpls:1 = 0

 un0.gen.uiIf:1 = 0

 un0.gen.uiIpv4:1 = 1

 un0.gen.uiL3:1 = 1

 un0.gen.uiL3Vpn:1 = 0

 un0.gen.uiPppoe:1 = 0

…..

 un2.gen.uiV6RpfL:1 = 0

 un2.gen.uiV6RpfAcl:1 = 0

 un2.gen.uiArpProxy:1 = 1

 un2.gen.uiFrIsis:1 = 0

 un2.gen.uiFrTh:1 = 0

 un2.gen.uiV42Acl:1 = 0

7.2  IP基础转发故障处理

7.2.1  链路异常,使用Ping/Tracert出现丢包或不通

1. 故障描述

故障现象通常有三层业务异常、ping/tracert丢包/不通。

2. 故障处理步骤

(1)     报文目的MAC检查

报文在路由器上进行三层转发的条件是报文的目的MAC为路由器本身的MAC。通过镜像或抓包确认这个条件是否满足,“镜像”的详细介绍,请参见“网络管理和监控配置指导”中的“镜像”。如下图,报文的目的MAC为路由器接口的MAC,说明报文目的MAC正确。

图7-1 报文目的MAC

 

 

<Sysname> display interface GigabitEthernet 3/2/2

GigabitEthernet3/2/2

Current state: UP

Line protocol state: UP

Description: GigabitEthernet3/2/2 Interface

Bandwidth: 1000000kbps

Maximum Transmit Unit: 1500

Internet Address is 10.0.0.1/24 Primary

IP Packet Frame Type:PKTFMT_ETHNT_2, Hardware Address: 7425-8a02-4d00

IPv6 Packet Frame Type:PKTFMT_ETHNT_2, Hardware Address: 7425-8a02-4d00

Media type is not sure, Port hardware type is 10G_BASE_SR_SFP

Port priority: 0

Last clearing of counters: Never

 Last 300 seconds input:  20 packets/sec 2565 bytes/sec  0%

 Last 300 seconds output: 0 packets/sec 30 bytes/sec  0%

 Input  (total): 219479 packets, 28092544 bytes

          219476 broadcasts, 0 multicasts, - pauses

 Input  (normal): 219479 packets, 28092544 bytes

          - broadcasts, - multicasts, 0 pauses

 Input: 0 input errors, 0 runts, 0 giants, 0 throttles

          0 CRC, 0 frame, 0 overruns, - aborts

          0 ignored, - parity errors

 Output  (total): 4608 packets, 316764 bytes

          3378 broadcasts, 1154 multicasts, - pauses

(2)     路由表检查

检查设备到某一目的IP网段的路由是否存在,如路由不存在,请检查路由协议配置、状态是否正确。

<Sysname> display ip routing-table 1.1.1.0

Summary Count : 1

Destination/Mask    Proto  Pre  Cost         NextHop         Interface

1.1.1.0/24          Static 60   0            10.0.0.2        GE3/2/2

需要注意的是,当32位掩码的主机路由与ARP表项的出接口不一致时,以主机路由的出接口为准。

(3)     FIB表检查

检查设备到某一目的IP网段的FIB表项是否存在,如路由存在、FIB表项异常,请将故障信息发送技术支持人员分析。

<Sysname> display fib 1.1.1.0

Destination count: 1 FIB entry count: 1

Flag:

  U:Useable   G:Gateway   H:Host   B:Blackhole   D:Dynamic   S:Static

  R:Relay     F:FRR

Destination/Mask   Nexthop         Flag     OutInterface/Token       Label

1.1.1.0/24         10.0.0.2        USG      GE3/2/2                   Null

(4)     ARP检查

检查设备ARP学习的接口是否正确,如学习接口不正确,请通过reset arp命令重新学习ARP,必要时可以使用arp static命令配置静态ARP。如ARP学习的接口一直不正确,请将故障信息发送技术支持人员分析。

<Sysname> display arp 10.0.0.2

Type: S-Static    D-Dynamic    M-Multiport    I-Invalid

IP address      MAC address    VLAN     Interface                Aging Type

10.0.0.2        0000-0000-0001 N/A       GE3/2/2                  N/A   S

7.3  DHCP中继故障处理

7.3.1  故障描述

客户端无法通过DHCP中继获取IP地址。

7.3.2  故障处理步骤

客户端无法通过DHCP中继获取IP地址一般是由以下的原因造成的:

·     中继和服务器间的路由错误

·     中继没有指定服务器的地址

·     DHCP中继功能未使能

1. 查看中继代理与DHCP服务器间的路由是否存在

DHCP中继代理和DHCP服务器上执行display ip routing-table命令来查看到对方的路由表项是否存在,如不存在请配置静态路由后查看故障是否排除,如依然存在请执行步骤2

2. 查看DHCP中继是否指定了DHCP服务器地址

DHCP中继上指定DHCP服务器的地址dhcp relay server-address ip-address,查看故障是否排除,如依然存在请执行步骤3

3. 查看DHCP中继功能是否使能

配置接口工作在DHCP中继模式dhcp select relay查看故障是否排除,如依然存在请联系技术支持人员分析。

7.4  ND故障处理

7.4.1  故障描述

无法学习到对端设备的ND表项。

7.4.2  故障处理步骤

1. 查看ND调试信息

使用debugging ipv6 nd packet命令打开ND调试信息开关,当对端ping本设备时,可以看到下列调试信息。如果未显示NS请求报文信息,则说明未接收到请求报文;如果未显示NA应答报文,则说明本设备未应答邻居请求。

<Sysname> *Sep 24 19:44:59:161 2019 H3C ND/7/ND_PACKET: -MDC=1-Slot=5;

 Sent NS packet:

 Interface: XGE5/4/3          First VLAN ID: 0   Second VLAN ID: 0

 SrcEthMAC: 70f9-6da7-5074    SrcIP: 2004::1

 DstEthMAC: 0000-0000-0000    DstIP: ff02::1:ff00:2

 LinkId: 0xffff    VsiIndex: 0xffffffff

// 接收NS请求报文

*Sep 24 19:44:59:163 2019 H3C ND/7/ND_PACKET: -MDC=1-Slot=5;

 Received NA packet:

 Interface: XGE5/4/3          First VLAN ID: 0   Second VLAN ID: 0

 SrcEthMAC: 1cab-343a-6145    SrcIP: 2004::2

 DstEthMAC: 70f9-6da7-5074    DstIP: 2004::1

 LinkId: 0xffff    VsiIndex: 0xffffffff

// 发送NA应答报文

2. 报文计数分析

如果设备未收到Ping报文,请排查上游的相邻设备;如果设备收到Ping报文,分析NS报文在本端是否上送给平台。具体步骤请参照7.1  ARP故障

7.5  IP性能优化故障处理

7.5.1  不同厂商的设备对接后,链路卡顿或不通

1. 故障描述

在网络中,由于不同厂商,甚至同一厂商不同型号的设备,对MTU的定义和MTU分片机制不尽相同,常出现MTU引起的网络问题,常表现为游戏卡、部分网站或链接打不开,Email无法发送附件,部分网页或对话框无法打开等。遇到此类问题时,建议先检查是否接口MTU不匹配导致。

此外,OSPFIS-ISL2VPNVPLS等协议邻居关系无法建立,也可能是链路两端MTU值不一致导致。

2. 故障处理步骤

对于MTU值问题处理,需要分析数据包传递的全路径上的MTU值设置。通用处理步骤如下:

(1)     分析数据转发路径。

(2)     检查数据包传递的全路径上各设备的出接口MTU值、站点间传输设备的MTU值。

(3)     逐段ping大包测试。大包长度分别为大于、小于、等于接口MTU值。

(4)     如果ping长度大于接口MTU时不通,小于等于接口MTU时能通,可初步认为是MTU问题。

(5)     分析报文头格式。

(6)     根据出问题的报文的最大长度修改MTU。在修改MTU值时,需要注意不同厂商设备MTU值的定义。

设备MTU下发情况可以通过查询Outlif表项查看:

[Sysname-probe] display hardware internal l3 np fib 22.1.0.2 32 slot 2 chip 0

 

 The FTN/FIB table Handle<0x14> ECMPNum<0/1> !

 ChipID is 0

 LPM:

 LPM KEY: VPNID = 0  IP_Prefix = 22.1.0.2/4294967295

 LPM RESULT:

   00001403 0030d000

 Ipv4-route tag:

 Valid = 1     Parity = 1    Local = 0

 Drop = 0      ToHost = 0    Ecmp = 0

 Dft_Sys = 0   Dft_User = 0  NextHopIdxOrEcmpPtr = 20

 LifId = 12496     EcmpNum = 0

 FWD-FTN:

 FWD-FTN KEY: NextHopIdx = 0x14

 FWD-FTN RESULT:

 ECMP = 0  Th = 0  Normal = 1 Drop = 0

 OutlifId/ToHostId = 67607

 Dft_User = 0  Dft_Sys = 0

 Es = 0  Ts = 0  DhcpH = 0

 Local = 0  Parity = 1  V = 1 TTL = 255

 StackEnd = 0  Label_v = 0  Label = 0  Label_bak = 0

 Rd = 0  Rq = 0  Dscp = 0  QosLocalId = 0

 Outlif Table : KEY(outlifid = 67607) RESULT(00008201, 10030901, 00000000, 00000000, 00000000, 00000000, 05dc0000, fff10817)

 RES:

 un0.tunnel.uiReserve1:1 = 0

 un0.tunnel.uiBak:1 = 0

 un0.tunnel.uiBcm:1 = 0

 un0.tunnel.uiReserve2:1 = 0

 un0.tunnel.uiFwd:1 = 0

 un0.tunnel.uiEs:1 = 0

 un0.tunnel.uiTs:1 = 0

 un0.tunnel.uiReserve3:1 = 0

 un0.tunnel.uiMct:1 = 0

 un0.tunnel.uiGre:1 = 0

 un0.tunnel.uiIpt:1 = 0

 un0.tunnel.uiUdp:1 = 0

 un0.tunnel.uiReserve4:1 = 0

 un0.tunnel.ui6to4:1 = 0

 un0.tunnel.uiAuto:1 = 0

 un0.tunnel.uiMacInMac:1 = 0

 un0.tunnel.uiL3Port:1 = 1

……

 un5.v4ipt.uiIdentIndex:16 = 0

 un5.v4ipt.uiTos:8 = 0

 un5.v4ipt.uiTtl:8 = 0

 un5.v6ipt.uiV6Dip:32 = 0

 un5.minm.uiIsid:32 = 0

 un6.gen.uiMtu:16 = 1500

再次ping大包测试。

 


8 三层技术-IP路由类故障处理

8.1  BGP故障处理

8.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 ignoreignore all-peersshutdown process命令,禁止建立BGP会话。

·     本地路由器与对端路由器没有在相同的地址族视图下使能路由信息交换能力。

3. 故障分析

本类故障的诊断流程如图8-1所示:

图8-1 BGP会话无法进入Established状态的故障诊断流程图

 

4. 处理步骤

(1)     检查与BGP邻居之间的通信链路是否正常。

a.     检查与邻居建立BGP会话的相关接口是否处于UP状态。

b.     通过ping命令方式检查与BGP邻居的连通性。如果Ping的结果为可达,则说明本地路由器与BGP邻居之间的通信链路正常,请执行步骤(2)。如果Ping的结果为不可达,请执行步骤c。

说明

建议使用ping –a source-ip –s packet-size命令和ping ipv6 –a source-ipv6 –s packet-size命令来检测与BGP邻居的连通性。–a source-ip–a source-ipv6参数指定了ICMP回显请求报文的源地址,方便用户同时检测两端的链路是否都正常;–s packet-size参数指定了发送的ICMP回显请求报文的长度,方便用户检测长报文在链路中的传输情况。Ping操作的源IP地址取用本端建立BGP会话使用的接口的IP地址,目的IP地址取用对端建立BGP会话使用的接口的IP地址。

 

c.     执行ping –a source-ip –s packet-size命令进行Ping操作,并逐步减小–s packet-size参数输入的值,当该参数减小到某个值时,Ping的结果变为可达,则表示建立BGP TCP连接时发送的TCP报文由于长度过长,在转发过程中被设备丢弃,导致了BGP会话无法进入Established状态。

-     此时可以重复执行ping –a source-ip –s packet-size命令,调整–s packet-size参数的取值,直至找到一个合适的取值(Ping的结果为可达的前提下,取尽量大的值,以提高转发效率),然后将该值设置为BGP报文转发出接口的MTU值。可通过在接口上执行ip/ipv6 mtu mtu-sizetcp mss value命令,或者在BGP实例视图/BGP-VPN实例视图下执行peer tcp-mss命令来设置出接口的MTU值;其中,ip/ipv6 mtu mtu-size命令配置的是MTU值,tcp mss valuepeer 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-tabledisplay 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会话的配置。

表8-1 影响BGP会话的配置检查项

检查项

描述

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } connect-interface interface-type interface-number

本端存在该配置时,BGP邻居也需要使用Loopback接口的地址建立BGP会话,可通过本命令或peer source-address命令配置

peer ipv4-address [ mask-length ] source-address source-ipv4-address

peer ipv6-address [ prefix-length ] source-address source-ipv6-address

本端存在该配置时,BGP邻居也需要使用Loopback接口的地址建立BGP会话,可通过本命令或peer connect-interface命令配置

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } ebgp-max-hop [ hop-count ]

非直连网络上的邻居建立EBGP会话,或者直连网络设备使用Loopback接口建立EBGP会话时,BGP会话两端均需要配置本命令,为EBGP会话指定相应的最大跳数

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } ttl-security hops hop-count

存在该配置时,本地路由器从指定对等体收到的BGP报文中,TTL需要在255-“hop-count”+1到255之间,否则BGP报文将会被丢弃,如果本地路由器与对等体之间的跳数超过了hop-count,请通过本命令进行配置修改

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] | link-local-address interface interface-type interface-number } route-limit prefix-number [ reconnect reconnect-time | percentage-value ] *

存在该配置时,表示如果本地路由器从指定对等体/对等体组接收的路由数量大于prefix-number值,路由器会自动断开与指定对等体/对等体组的会话。可通过降低对等体/对等体组发送的路由数量,或配置更大的prefix-number值,来避免BGP会话断开

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] | link-local-address interface interface-type interface-number } ignore [ graceful graceful-time { community { community-number | aa:nn } | local-preference preference | med med } * ]

存在该配置时,BGP将不会与指定的对等体/对等体组建立BGP会话,此时可以通过执行undo peer ignore命令允许建立与对等体/对等体组的会话

ignore all-peers [ graceful graceful-time { community { community-number | aa:nn } | local-preference preference | med med } * ]

存在该配置时,表明BGP禁止与所有对等体建立BGP会话。此时设备可能处于网络升级维护中,BGP进程暂时不可用,建议在网络升级维护完成后,执行undo peer ignore命令或undo ignore all-peers命令允许建立BGP会话

shutdown process

存在该配置时,表明BGP禁止与所有对等体建立BGP会话。此时设备可能处于网络升级维护中,BGP进程暂时不可用,建议在网络升级维护完成后,执行undo shutdown process命令允许建立BGP会话

地址族下的peer enable命令

建立BGP会话时,两端需要在同一个地址族下指定对端配置peer enable命令使能路由信息交互能力。存在该配置时,请检查对端是否也在相同地址族下配置了peer enable命令

 

如果故障仍不能排除,请执行步骤(5)。

(5)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

5. 告警与日志

相关告警

在系统视图下执行snmp-agent trap enable bgp命令后,BGP会话的状态机发生变化时会产生如下告警信息。

模块名:BGP4-MIB

·     bgpBackwardTransition (1.3.6.1.2.1.15.7.2)

相关日志

8.1.2  BGP会话Down

1. 故障描述

在设备上观察到BGP/5/BGP_STATE_CHANGED提示BGP会话状态变为Idle的日志打印信息,会话状态从Established变为Idle。

2. 常见原因

本类故障的常见原因主要包括:

·     Keepalive或Update消息收发超时。

·     TCP连接建立失败。

·     设备达到内存门限。

·     BGP报文解析发生错误。

3. 故障分析

本类故障的诊断流程如图8-2所示。

图8-2 BGP会话Down的故障诊断流程图

 

4. 处理步骤

执行display bgp peer log-info命令,根据该命令的显示信息进一步确认BGP会话Down的原因。几种常见的BGP会话Down的原因如下:

·     BGP定时器超时导致断开会话

如果log-info信息与下面的显示信息相似:

<Sysname> display bgp peer ipv4 3.3.3.3 log-info

 

 Peer: 3.3.3.3

 

     Date      Time    State Notification

                             Error/SubError

 

  17-Jan-2022 14:48:34 Down  Receive notification with error 4/0

                             Hold Timer Expired/ErrSubCode Unspecified

                             Keepalive last triggered time: 14:48:31-2022.1.17

                             Keepalive last sent time     : 14:48:31-2022.1.17

                             Update last sent time        : 14:48:24-2022.1.17

                             EPOLLOUT last occurred time  : 14:48:30-2022.1.17

则表示BGP会话Down的原因是在会话保持时间时间内未能收到对等体发送的Keepalive或Update消息。在BGP会话保持定时器超时后,设备则会主动断开BGP会话,并向对端对等体发送Notification消息。

定时器超时的原因可能是设备正常发送了Keepalive或Update消息,但报文由于链路故障等原因无法到达对等体或对等体处理不及时,或者设备调度故障导致未能及时产生Keepalive或Update消息等。如需解决此问题,请在BGP会话的两端设备的Probe视图下,均执行display system internal bgp log命令,并收集该命令的显示信息,联系技术支持人员进行进一步分析。

·     TCP连接错误导致BGP会话断开

如果log-info信息与下面的显示信息相似:

<Sysname> display bgp peer ipv4 1.1.1.1 log-info

 

 Peer: 1.1.1.1

 

     Date      Time    State Notification

                             Error/SubError

 

  17-Jan-2022 14:42:01 Down  Receive TCP_Connection_Failed event

则BGP会话Down的原因是TCP连接错误。BGP使用TCP作为其传输层协议,如果BGP会话两端设备间的TCP连接发生错误,BGP会话也会断开。如果用户观察到的显示信息与上述举例不相似,但是显示信息中包含了Notification消息错误码5/0,则也是由于TCP连接错误导致的BGP会话断开。

确认TCP连接发生错误后,请在BGP会话Down的两端设备的Probe视图中,均执行view /proc/tcp/tcp_log slot x命令(所有的单板/成员设备各执行一次),并收集该命令的显示信息,联系技术支持人员进行进一步分析。

·     内存不足导致BGP会话断开

如果log-info信息与下面的显示信息相似:

<Sysname> display bgp peer ipv4 1.1.1.1 log-info

 Peer: 1.1.1.1

     Date      Time    State Notification

                             Error/SubError

 

  17-Jan-2022 15:38:53 Down  Send notification with error 6/8

                             Entered severe memory state

  17-Jan-2022 14:53:51 Down  Send notification with error 6/8

                             No memory to process the attribute

表明设备没有足够内存处理BGP模块相关功能,导致BGP会话断开。此类错误原因对应log-info信息中的错误码6/8。

此时请在BGP会话Down的两端设备上,均执行display memory-threshold命令,获取内存告警门限相关信息,并记录display bgp peer log-info命令的显示信息,联系技术支持人员进行进一步分析。

·     报文解析错误导致BGP会话断开:

BGP会话两端的设备如果报文解析能力不同或版本不匹配,则BGP可能无法解析接收到的报文,导致BGP会话断开。此类错误原因对应log-info信息中的消息差错码1、2和3(即“Error/SubError”中的“Error”为1、2或3)。

请在BGP会话Down的两端设备上,均执行debugging bgp raw-packetdebugging bgp open以及debugging bgp update命令,并收集这些命令的显示信息以及display bgp peer log-info命令的显示信息,联系技术支持人员进行进一步分析。

·     如果display bgp peer log-info命令的显示信息中,提示的BGP会话Down的原因不属于以上任何一种常见的原因,请收集如下信息,并联系技术支持人员。

¡     display bgp peer log-info命令的显示信息。

¡     display system internal bgp log命令的显示信息。

¡     view /proc/tcp/tcp_log slot x命令的显示信息(所有的单板/成员设备各执行一次)。

¡     设备的配置文件、日志信息、告警信息。

5. 告警与日志

相关告警

相关日志

·     BGP/5/BGP_STATE_CHANGED

8.2  IS-IS故障处理

8.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. 故障分析

本类故障的诊断流程如图8-3所示。

图8-3 IS-IS邻居无法建立的故障诊断流程图

 

4. 处理步骤

(1)     检查接口的物理层状态是否为Up。

请执行display interface [ interface-type [ interface-number | interface-number.subnumber ] ]命令查看IS-IS接口物理层状态,如果接口物理层状态为Down,请先处理接口故障问题。如果接口物理状态为Up,请执行步骤(2)

(2)     检查链路是否故障

请执行ping命令,检查设备链路是否故障(包括传输设备故障)。如果链路正常,请执行步骤(3)

如果IS-IS使用BFD检测设备间链路,通过isis bfd session-restrict-adj命令开启BFD抑制IS-IS建立和保持邻接关系的功能后,接口发送的Hello报文中将会携带BFD-enabled TLV,当两端BFD-enabled TLV中的信息一致时,抑制IS-IS建立和保持邻居关系的功能生效。当BFD会话Down时,无法建立IS-IS邻居关系。

请执行display bfd session命令查看检测IS-IS两端链路的BFD会话的状态,如果“State”字段取值为“Down”,请排除链路故障。如果“State”字段取值为“Up”,请执行步骤(3)

(3)     检查CPU或内存利用率是否过高。

请执行display cpu-usage命令检查故障设备的主控板和接口板的CPU利用率是否过高。如果CPU利用率过高,IS-IS将无法正常收发协议报文,从而导致邻居关系震荡。可通过关闭一些不必要的功能解决此问题。如果CPU利用率不高,则执行步骤(4)

请执行display memory-threshold命令,查看显示信息中的Current free-memory state,即系统当前内存使用状态。如果Current free-memory state为Minor、Severe或Critical,表示剩余空闲内存较少,可能会导致设备无法收发IS-IS报文或处理IS-IS报文速度较慢,请关闭一些不必要的功能尝试解决此问题。如果系统当前内存使用状态为Normal,则执行步骤(4)

(4)     检查接口在IS-IS协议下的状态是否正常。

请执行display isis interface命令,检查使能了IS-IS的接口的状态(“IPv4 state”或“IPv6 state”字段)是否为正常状态。

¡     如果IS-IS接口状态为“Lnk:Up/IP:Dn”,说明IPv4或IPv6相邻节点的链路层可达、网络层不可达,请处理网络层故障问题。

¡     如果IS-IS接口状态为“Up”,请执行步骤(5)

(5)     检查两端IP地址是否在同一网段。

对于IPv4 IS-IS,请执行display interface brief命令查看两端接口的IPv4地址。

¡     如果两端接口的IPv4地址不在同一网段,请在接口视图下执行ip address命令修改两端的IPv4地址,使其在同一网段。

¡     如果两端接口的IPv4地址处于同一网段,请执行(6)

对于IPv6 IS-IS,无需执行此检查。

(6)     检查各IS-IS接口的MTU是否一致。

请执行display interface [ interface-type [ interface-number | interface-number.subnumber ] ]命令查看接口MTU信息。

¡     如果接口的MTU值配置不一致,请在接口视图下执行mtu size命令,将各个接口的MTU值修改为一致。

¡     如果接口的MTU值一致,请执行(7)

(7)     检查IS-IS能否接收到Hello报文。

请执行display isis packet hello by-interface verbose命令,检查IS-IS能否接收到Hello报文。如果设备无法接收Hello报文,请排除丢包问题。如果故障依然存在,请执行(12)

如果设备能够接收Hello报文,请继续执行以下检查:

¡     如果“Duplicate system ID”字段的统计计数随时间增长,说明System ID冲突。请执行步骤(8)

¡     如果“Mismatched level (LAN)”字段的统计计数随时间增长,说明Level不匹配。请执行步骤(9)

¡     如果“Bad area address TLV”字段的统计计数随时间增长,说明区域地地址不匹配。请执行步骤(10)

¡     如果其他字段的统计计数随时间增长,请执行步骤(12)

(8)     检查链路两端的设备配置的System ID是否相同。

请执行display current-configuration isis命令检查链路两端的设备配置的System ID是否相同。

¡     如果两端System ID相同,请修改配置,使两端的System ID不同。

¡     如果两端System ID不相同,请执行步骤(9)

(9)     检查链路两端的设备的IS-IS Level是否匹配。

请检查设备及IS-IS接口的Level级别:

¡     请执行display current-configuration | include is-level命令,检查链路两端设备的Level级别。如果通过display current-configuration | include is-level命令无法查询到设备的Level级别的相关配置,表明设备的Level级别为缺省值为Level-1-2。

¡     请执行display current-configuration interface interface-type interface-number | include circuit-level命令,检查接口的链路邻接关系类型。如果通过display current-configuration interface interface-type interface-number | include circuit-level命令无法查询到接口的链路邻接关系类型,说明接口的链路邻接关系类型为缺省值,这种情况下,该接口既可以建立Level-1的邻接关系,也可以建立Level-2的邻接关系。

需要保证链路两端的Level匹配才能建立IS-IS邻居关系,接口Level匹配的原则如下:

¡     如果本端接口Level级别为Level-1,则对端接口Level级别必须为Level-1或Level-1-2。

¡     如果本端接口Level级别为Level-2,则对端接口Level级别必须为Level-2或Level-1-2。

¡     如果本端接口Level级别为Level-1-2,则对端接口Level级别可以为Level-1、Level-2或Level-1-2。

对于不同的情况,请选择不同的处理方式:

¡     如果链路两端设备的IS-IS Level不匹配,请在IS-IS视图下使用is-level命令修改设备的IS-IS级别,或者在接口视图下使用isis circuit-level命令修改接口的Level级别。

¡     如果链路两端设备的IS-IS Level匹配请执行步骤(10)

(10)     检查链路两端设备的区域地址是否匹配。

请执行display isis命令查看“Network entity”字段,检查链路两端设备的区域地址是否匹配。“Network entity”的格式为X…X.XXXX.XXXX.XXXX.00,前面的“X…X”是区域地址,中间的12个“X”是交换机的System ID,最后的“00”是SEL。

¡     如果链路两端建立Level-1邻居,需要保证链路两端设备在同一个区域内。建立IS-IS Level-2邻居时,不需要判断区域地址是否匹配。

当建立Level-1邻居的两端设备区域地址不同时,请在IS-IS视图下使用network-entity命令修改设备的区域地址。

¡     如果链路两端区域地址匹配,请执行步骤(11)

(11)     检查链路两端设备的认证方式是否匹配。

请执行display current-configuration interface-type interface-number | include isis命令检查链路两端设备IS-IS接口的认证方式。

a.     如果两端认证类型不匹配,请在链路两端设备的IS-IS接口视图下执行isis authentication-mode命令,将两端设置为相同的认证类型。

b.     如果认证方式相同的情况下,IS-IS仍然无法建立邻居关系,请将两端设置为相同的认证密码。

如果故障依然存在,请执行步骤(12)

(12)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

5. 告警与日志

相关告警

模块名:ISIS-MIB

·     isisAdjacencyChange (1.3.6.1.2.1.138.0.17)

相关日志

·     ISIS/3/ISIS_NBR_CHG

8.2.2  设备学习不到IS-IS路由

1. 故障描述

设备学习不到IS-IS路由。

2. 常见原因

本类故障的常见原因主要包括:

·     其它路由协议也发布了相同的路由,并且路由协议优先级比IS-IS协议高。

·     引入的外部路由优先级低,没有被优选。

·     IS-IS开销值类型不匹配。

·     IS-IS邻居没有正常建立。

·     两台设备的System ID配置相同。

·     LSP报文认证不匹配。

·     设备底层故障或者链路故障,造成LSP报文丢失。

·     LSP长度超过了设备可以接收的LSP的最大长度。

3. 故障分析

本类故障的诊断流程如图8-4所示。

图8-4 设备学习不到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路由表中不存在指定的路由,请执行步骤(6)

(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邻居是否都正常建立。

¡     如果存在邻居没有正常建立的情况,请参见“8.2.1  IS-IS邻居无法建立

¡     如果不存在邻居未能正常建立的情况,请执行步骤(6)

(6)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

5. 告警与日志

相关告警

相关日志

8.2.3  IS-IS路由震荡

1. 故障描述

IS-IS路由反复增删。

2. 常见原因

本类故障的常见原因主要包括:

·     IS-IS邻居震荡。

·     MPLS LSP隧道震荡。

·     两台设备的IS-IS引入了相同的外部路由,并且外部路由的优先级比IS-IS协议的优先级低。

·     两台设备配置的System ID相同。

3. 故障分析

本类故障的诊断流程如图8-5所示。

图8-5 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的设备上执行步骤8.2.1  4. (12)

¡     如果路由的“Protocol”字段发生变化,请执行步骤8.2.1  4. (12)

(2)     检查IS-IS引入外部路由的配置。

如果指定的路由是作为外部路由引入到IS-IS的,在引入该路由的设备上,执行display ip routing-table ip-address verbose命令,查看路由震荡的具体情况,具体步骤如下:

¡     如果路由表中处于“Active”状态的路由是IS-IS路由,而不是IS-IS引入的外部路由,说明网络中其他IS-IS设备发布了相同的路由。请根据网络规划修改路由协议的优先级,或者,在引入外部路由的IS-IS设备上配置路由过滤策略,控制下发到IP路由表的路由。

¡     对于其它情况,请执行步骤8.2.1  4. (12)

(3)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

5. 告警与日志

相关告警

相关日志

8.3  OSPFv3故障处理

8.3.1  OSPFv3邻居Down

1. 故障描述

·     OSPFv3邻居Down

·     OSPFv3邻居震荡

2. 常见原因

本类故障的常见原因主要包括:

·     BFD会话Down,即BFD检测到链路故障。

·     对端设备故障。

·     CPU利用率或内存利用率过高。

·     链路故障。

·     OSPFv3接口没有Up。

·     两端IP地址不在同一网段。

·     两端OSPFv3参数的配置不匹配:

¡     RouterID配置冲突。

¡     两端区域类型配置不一致。

¡     两端OSPFv3认证配置不匹配。

¡     两端定时器参数配置不一致。

¡     OSPFv3接口的网络类型不匹配。

3. 故障分析

本类故障的诊断流程如图8-6所示。

图8-6 OSPFv3邻居Down的故障诊断流程图

 

4. 处理步骤

(1)     通过命令行查看OSPFv3邻居状态变为Down的原因。

执行display ospfv3 event-log peer命令,显示信息中的Reason字段为邻居状态发生变化的原因,一般包含如下几种情况:

¡     DeadExpired

表示在邻居失效定时器超时前没有收到Hello报文,导致OSPFv3邻居状态变为Down。出现这种情况请执行步骤(2)

¡     BFDDown

表示BFD会话Down导致OSPFv3邻居状态变为Down。出现这种情况请执行步骤(2)

¡     1-Way

表示对端OSPFv3状态首先变成Down,然后向本端发送1-way Hello报文,导致本端OSPFv3状态变为Init。出现这种情况请排查对端设备的故障。

¡     IntPhyChange

表示接口Down或者接口MTU改变导致邻居关系变为Down。此时,执行display interface [ interface-type [ interface-number | interface-number.subnumber ] ]命令查看接口的运行状态和相关信息,排查接口故障。其他情况请执行步骤(11)

(2)     检查接口的物理层状态是否为Up。

执行display interface [ interface-type [ interface-number | interface-number.subnumber ] ]命令查看OSPFv3接口物理层状态,如果接口物理层状态为Down请先处理接口故障问题。如果接口物理状态为Up,则执行步骤(3)

(3)     检查链路是否故障

请执行ping命令,检查设备链路是否故障(包括传输设备故障)。如果链路正常,请执行步骤(4)

(4)     检查CPU利用率是否过高。

请执行display cpu-usage命令检查故障设备的主控板和接口板的CPU利用率是否过高。CPU利用率过高会导致OSPFv3无法正常收发协议报文,继而导致邻居振荡。可通过关闭一些不必要的功能解决此问题。如果CPU利用率不高,则执行步骤(5)

(5)     检查内存利用率是否超过了内存利用率阈值。

请执行display memory-threshold命令,查看显示信息中的Current free-memory state,即系统当前内存使用状态。如果Current free-memory state为Minor、Severe或Critical,表示剩余空闲内存较少,可能会导致设备无法收发OSPFv3报文或处理OSPFv3报文速度较慢,请关闭一些不必要的功能尝试解决此问题。如果系统当前内存使用状态为Normal,则执行步骤(6)

(6)     检查接口在OSPFv3协议下的状态是否正常。

执行display ospfv3 interface查看接口在OSPFv3协议下状态是否为正常状态。

¡     如果OSPFv3接口状态为Down,检查接口是否使能了OSPFv3功能。如果使能了OSPFv3功能,请处理网络层接口故障问题。

¡     如果OSPFv3接口协议状态正常,即接口状态为DR、BDR、DROther或P-2-P时,请执行步骤(7)

(7)     检查各OSPFv3接口的MTU是否一致。

如果接口下未配置ospfv3 mtu-ignore命令,则要求接口的MTU一致,否则无法建立OSPFv3邻居关系。请执行display interface [ interface-type [ interface-number | interface-number.subnumber ] ]命令查看接口MTU信息。

¡     如果接口的MTU值配置不一致,请在接口视图下执行mtu size命令,将各个接口的MTU值修改为一致。

¡     如果接口的MTU值一致,请执行步骤(8)

(8)     检查各接口的DR优先级是否非零。

对于Broadcast和NBMA类型的网络,为了保证正确选举出DR,需要保证至少有一个OSPFv3接口的DR优先级是非零的,否则两边的邻居状态只能达到2-Way。请使用display ospfv3 interface命令查看OSPFv3接口信息,其中的Priority表示接口的DR优先级。

如果接口的DR优先级非零,请执行步骤(9)

(9)     是否手工为NBMA网络或P2MP单播网络指定了邻居。

OSPFv3网络类型为NBMA或P2MP(unicast)时,必须通过ospfv3 peer命令手工指定邻居接口的链路本地地址。请在OSPFv3接口视图下使用display this命令查看接口的网络类型,如果接口的网络类型为NBMA或P2MP(unicast),请在OSPFv3接口视图下使用ospfv3 peer命令手工指定邻居接口的链路本地地址。

如果手工为NBMA网络或P2MP单播网络指定了邻居接口的链路本地地址,请执行步骤(10)

(10)     检查两端OSPFv3的参数配置是否有错误。

a.     请使用display ospfv3命令检查两端OSPFv3 Router ID配置是否冲突。如果OSPFv3 Router ID配置冲突,请修改配置保证OSPFv3 Router ID不再冲突。如果OSPFv3 Router ID配置不冲突,请继续执行以下检查。

b.     请使用display ospfv3 interface命令检查两端OSPFv3 Area ID配置是否一致。如果OSPFv3 Area ID配置不一致,请修改配置保证OSPFv3 Area ID配置一致。如果OSPFv3 Area ID配置一致,请继续执行以下检查。

c.     请使用display ospfv3 interface命令检查两端接口的OSPFv3网络类型是否一致。如果OSPFv3网络类型不一致,请修改配置保证OSPFv3网络类型一致。需要说明的是,如果双方一端为PTP,另一端为Broadcast,那么邻居关系可以达到Full状态,但无法计算出路由信息。

如果接口的OSPFv3网络类型一致,请继续执行以下检查。

d.     请每隔10秒钟使用display ospfv3 statistics error命令检查一次OSPFv3的错误统计信息,并持续5分钟。需要查看的信息包括:

-     查看Authentication failure字段。如果这个字段对应的计数值一直增长,表示建立邻居的两台设备配置的OSPFv3认证类型不一致,需要在两端设备上配置相同类型的认证。

-     查看HELLO: Hello-time mismatch字段。如果这个字段对应的计数值一直在增长,表示接口上的Hello定时器的值不一致,需要将两端接口的Hello定时器的值设置为一致。

-     查看HELLO: Dead-time mismatch字段。如果这个字段对应的计数值一直在增长,表示接口上的Dead定时器的值不一致,需要将两端接口的Dead定时器的值设置为一致。

-     查看HELLO: Ebit option mismatch字段。如果这个字段对应的计数值一直在增长,表示区域类型配置不一致(一端配置为普通区域,另一端配置为Stub或NSSA区域),需要将两端的区域类型设置为一致。

如果故障依然存在,请执行步骤(11)

(11)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

5. 告警与日志

相关告警

模块名:OSPFV3-MIB

·     ospfv3VirtIfStateChange (1.3.6.1.2.1.191.0.1)

·     ospfv3NbrStateChange (1.3.6.1.2.1.191.0.2)

·     ospfv3VirtNbrStateChange (1.3.6.1.2.1.191.0.3)

相关日志

·     OSPFV3/6/OSPFV3_LAST_NBR_DOWN

·     OSPFV3/5/OSPFV3_NBR_CHG

8.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. 故障分析

本类故障的诊断流程如图8-7所示。

图8-7 OSPFv3邻居Down的故障诊断流程图

 

4. 处理步骤

(1)     使用display ospfv3 peer命令查看OSPFv3邻居信息,并根据不同的邻居状态进行相应的处理。

¡     没有邻居信息。

请检查是否在OSPFv3进程下设置了Router ID,如果未设置Router ID,则OSPFv3进程无法运行。如果设置了Router ID,则表示OSPFv3邻居Down或者邻居震荡,请参见“8.3.1  OSPFv3邻居Down”故障处理。

¡     邻居状态一直为Init。

表示对端设备收不到本端发送的Hello报文,此时请排查链路和对端设备是否故障。

¡     邻居状态一直为2-way。

执行命令display ospfv3 interface verbose命令查看设备在OSPFv3接口的DR优先级是否为0:

如果OSPFv3接口的DR优先级为0,那么邻居状态为2-way属于正常情况。

如果OSPFv3接口的DR优先级不为0,请执行步骤(2)

¡     邻居状态一直是Exstart。

表示设备一直在进行DD协商,但无法进行DD同步,出现该情况有两种可能性:

-     接口无法正常收发超大报文

可以通过多次执行命令ping -s packet-size neighbor-address查看超大报文收发情况,将packet-size设置为1500或更大数值。如果无法Ping通,请先解决链路问题。

-     两端OSPFv3 MTU配置值不一致

如果OSPFv3接口下配置了ospfv3 mtu-ignore命令,则无需检查两端的OSPFv3 MTU值是否相等;否则,需要检查两端的OSPFv3 MTU值是否相等,如果不相等则修改接口下的MTU值。

如果故障没有解决,请执行步骤(2)

¡     邻居状态一直是Exchange。

表示设备在进行DD交换,请参见邻居状态一直为Exstart状态的处理。

如果故障没有解决,请执行步骤(2)

¡     邻居状态一直是Loading。

如果使用display ospfv3 peer命令查看到邻居状态一直处于Loading,可以尝试执行reset ospfv3 [ process-id ] process命令重启OSPFv3进程。

如果故障没有解决,请执行步骤(2)

(2)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

5. 告警与日志

相关告警

相关日志

8.4  OSPF故障处理

8.4.1  OSPF邻居Down

1. 故障描述

·     OSPF邻居Down

·     OSPF邻居震荡

2. 常见原因

本类故障的常见原因主要包括:

·     BFD会话Down,即BFD检测到链路故障。

·     对端设备故障。

·     CPU利用率过高。

·     链路故障。

·     OSPF接口没有Up。

·     两端IP地址不在同一网段。

·     OSPF两端参数的配置不匹配:

¡     Router ID配置冲突。

¡     两端区域类型配置不一致。

¡     两端OSPF验证配置不匹配。

¡     两端定时器参数配置不一致。

¡     OSPF接口的网络类型不匹配。

3. 故障分析

本类故障的诊断流程如图8-8所示。

图8-8 OSPF邻居Down的故障诊断流程图

 

4. 处理步骤

(1)     通过命令行或日志查看OSPF邻居状态变为Down的原因。

执行display ospf event-log peer命令,显示信息中的Reason字段为邻居状态发生变化的原因,一般包含如下几种情况:

¡     DeadExpired

表示在邻居失效定时器超时前没有收到Hello报文,导致OSPF邻居状态变为Down。出现这种情况请执行步骤(2)

¡     BFDDown

表示BFD会话Down导致OSPF邻居状态变为Down。出现这种情况请执行步骤(2)

¡     IntVliChange或virtual link was deleted or the route it relies on was deleted

表示虚连接删除或者其依赖的路由删除导致邻居关系变为Down。出现这种情况请执行步骤(2)

¡     1-Way

表示对端OSPF状态首先变成Down,然后向本端发送1-way Hello报文,导致本端OSPF状态变为Init。出现这种情况请排查对端设备的故障。

¡     IntPhyChange

接口Down或者接口MTU改变导致邻居关系变为Down。此时,执行display interface [ interface-type [ interface-number | interface-number.subnumber ] ]命令查看接口的运行状态和相关信息,排查接口故障。其他情况请执行步骤(11)

(2)     检查链路是否故障

请执行ping命令,检查设备链路是否故障(包括传输设备故障)。如果链路正常,请执行步骤(3)

(3)     检查CPU利用率是否过高。

请执行display cpu-usage命令检查故障设备的主控板和接口板的CPU利用率是否过高。CPU利用率过高会导致OSPF无法正常收发协议报文从而导致邻居振荡。可通过关闭一些不必要的功能解决此问题。如果CPU利用率不高,则执行步骤(5)

(4)     检查内存利用率是否超过了内存利用率阈值。

请执行display memory-threshold命令,查看显示信息中的Current free-memory state,即系统当前内存使用状态。如果Current free-memory state为Minor、Severe或Critical,表示剩余空闲内存较少,可能会导致设备无法收发OSPF报文或处理OSPF报文速度较慢,请关闭一些不必要的功能尝试解决此问题。如果系统当前内存使用状态为Normal,则执行步骤(5)

(5)     检查接口状态是否为Up。

执行display interface [ interface-type [ interface-number | interface-number.subnumber ] ]命令查看接口物理层状态,如果接口物理层状态为Down请先处理接口故障问题。如果接口物理层状态是Up,请执行display ospf interface查看接口在OSPF协议下状态是否为正常状态:

¡     如果OSPF接口状态为Down,检查OSPF进程下是否通过network命令通告了接口所属网段。如果OSPF未通告接口所属网段,则检查接口下是否使能了OSPF。如果接口使能了OSPF进程,请处理网络层接口故障问题。

¡     如果OSPF下的接口协议状态正常,即接口状态为DR、BDR、DROther或PTP时,请执行步骤(6)

(6)     检查两端IP地址是否在同一网段。

请执行display interface brief命令查看两端接口的IP地址:

¡     如果两端接口的IP地址不在同一网段,请在接口视图下执行ip address命令修改两端的IP地址,使其在同一网段。

¡     如果两端接口的IP地址处于同一网段,请执行步骤(7)

(7)     检查各OSPF接口的MTU是否一致。

如果在OSPF接口上通过ospf mtu-enable命令将该接口发送的DD报文中MTU域的值填充为接口的MTU值(缺省情况下接口发送的DD报文中MTU域的值为0),则要求各个OSPF接口发送的DD报文中MTU域的值一致。否则,OSPF邻居无法协商成功。请执行display interface [ interface-type [ interface-number | interface-number.subnumber ] ]命令查看接口MTU信息:

¡     如果接口的MTU值配置不一致,请在接口视图下执行mtu size命令,将各个接口的MTU值修改为一致。

¡     如果接口的MTU值一致,请执行步骤(8)

(8)     检查各接口的DR优先级是否非零。

对于Broadcast和NBMA类型的网络,为了保证正确选举出DR,需要保证至少有一个OSPF接口的DR优先级是非零的,否则两边的邻居状态只能达到2-Way。请使用display ospf interface命令查看OSPF接口信息,其中的Pri表示接口的DR优先级。

如果接口的DR优先级非零,请执行步骤(9)

(9)     是否手工为NBMA网络或P2MP单播网络指定了邻居。

OSPF网络类型为NBMA或P2MP(unicast)时,必须通过peer命令手工指定邻居的IP地址。请在OSPF接口视图下使用display this命令查看接口的网络类型,如果接口的网络类型为NBMA或P2MP(unicast),请在OSPF视图下使用peer命令手工指定邻居的IP地址。

如果手工为NBMA网络或P2MP单播网络指定了邻居的IP地址,请执行步骤(10)

(10)     检查两端OSPF的参数配置是否有错误。

a.     请使用display ospf命令检查两端OSPF Router ID配置是否冲突。如果OSPF Router ID配置冲突,请修改配置保证OSPF Router ID不再冲突。如果OSPF Router ID配置不冲突,请继续执行以下检查。

b.     请使用display ospf interface命令检查两端OSPF Area ID配置是否一致。如果OSPF Area ID配置不一致,请修改配置保证OSPF Area ID配置一致。如果OSPF Area ID配置一致,请继续执行以下检查。

c.     请使用display ospf interface命令检查两端接口的OSPF网络类型是否一致。如果OSPF网络类型不一致,请修改配置保证OSPF网络类型一致。需要说明的是,如果双方一端为PTP,另一端为Broadcast,那么邻居关系可以达到Full状态,但无法计算出路由信息。

如果接口的OSPF网络类型一致,请继续执行以下检查。

d.     请每隔10秒钟使用display ospf statistics error命令检查一次OSPF的错误统计信息,并持续5分钟。需要查看的信息包括:

-     查看Bad authentication type字段。如果这个字段对应的计数值一直增长,表示建立邻居的两台设备配置的OSPF认证类型不一致,需要在两端设备上配置相同认证的类型。

-     查看Hello-time mismatch字段。如果这个字段对应的计数值一直在增长,表示接口上的Hello定时器的值不一致,需要将两端接口的Hello定时器的值设置为一致。

-     查看Dead-time mismatch字段。如果这个字段对应的计数值一直在增长,表示接口上的Dead定时器的值不一致,需要将两端接口的Dead定时器的值设置为一致。

-     查看Ebit option mismatch字段。如果这个字段对应的计数值一直在增长,表示区域类型配置不一致(一端配置为普通区域,另一端配置为Stub或NSSA区域),需要将两端的区域类型设置为一致。

如果故障依然存在,请执行步骤(11)

(11)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

5. 告警与日志

相关告警

模块名:OSPF-TRAP-MIB

·     ospfVirtIfStateChange (1.3.6.1.2.1.14.16.2.1)

·     ospfNbrStateChange (1.3.6.1.2.1.14.16.2.2)

·     ospfVirtNbrStateChange (1.3.6.1.2.1.14.16.2.3)

相关日志

·     OSPF/5/OSPF_NBR_CHG

·     OSPF/5/OSPF_NBR_CHG_REASON

8.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. 故障分析

本类故障的诊断流程如图8-9所示:

图8-9 OSPF邻居无法达到FULL状态的故障诊断流程图

 

4. 处理步骤

(1)     使用display ospf peer命令查看OSPF邻居信息,并根据不同的邻居状态进行相应的处理。

¡     没有邻居信息。

表示OSPF邻居Down或者邻居震荡,请参见“8.4.1  OSPF邻居Down”故障处理。

¡     邻居状态一直为Init。

表示对端设备收不到本端发送的Hello报文,此时请排查链路和对端设备是否故障。

¡     邻居状态一直为2-way。

执行命令display ospf interface verbose查看设备在OSPF接口的DR优先级是否为0:

-     如果OSPF接口的DR优先级为0,那么邻居状态为2-way属于正常情况。

-     如果OSPF接口的DR优先级不为0,请执行步骤(2)

¡     邻居状态一直是Exstart。

表示设备一直在进行DD协商,但无法进行DD同步,出现该情况有两种可能性:

-     接口无法正常收发超大报文。

可以通过多次执行命令ping -s packet-size neighbor-address查看超大报文收发情况,将packet-size设置为1500或更大数值。如果无法Ping通,请先解决链路问题。

-     两端OSPF MTU配置值不一致。

如果OSPF接口下配置了ospf mtu-enable命令,请检查两端的OSPF MTU值是否相等。如果不相等,则修改接口下的MTU值。

如果故障没有解决,请执行步骤(2)

¡     邻居状态一直是Exchange。

表示设备在进行DD交换,请参见邻居状态一直为Exstart状态的处理。

如果故障没有解决,请执行步骤(2)

¡     邻居状态一直是Loading。

如果使用display ospf peer命令查看邻居状态一直处于Loading,可以尝试执行reset ospf [ process-id ] process命令重启OSPF进程。

如果故障没有解决,请执行步骤(2)

(2)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

5. 告警与日志

相关告警

相关日志

8.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. 故障分析

本类故障的诊断流程如图8-10图8-11所示。

图8-10 设备学习不到OSPF路由故障诊断流程图一

 

图8-11 设备学习不到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: GigabitEthernet3/1/2

   BkSRLabel: NULL              BkInterface: N/A

    SIDIndex: NULL                  InLabel: NULL

   Tunnel ID: Invalid           IPInterface: GigabitEthernet3/1/2

 BkTunnel ID: Invalid         BkIPInterface: N/A

    FtnIndex: 0x0            ColorInterface: N/A

TrafficIndex: N/A          BkColorInterface: N/A

   Connector: 0.0.0.0             VpnPeerId: N/A

        Dscp: N/A                       Exp: N/A

  SRTunnelID: Invalid             StatFlags: 0x0

    SID Type: N/A                       SID: N/A

       BkSID: N/A                       NID: Invalid

    FlushNID: Invalid                 BkNID: Invalid

  BkFlushNID: Invalid                PathID: 0x0

CommBlockLen: 0

  OrigLinkID: 0x0                RealLinkID: 0x0

 

 Destination: 192.168.24.0/24

    Protocol: O_INTER

  Process ID: 1

   SubProtID: 0x2                       Age: 12h53m09s

        Cost: 3                  Preference: 10

       IpPre: N/A                QosLocalID: N/A

         Tag: 0                       State: Active Adv

   OrigTblID: 0x0                   OrigVrf: default-vrf

     TableID: 0x2                    OrigAs: 0

       NibID: 0x13000003             LastAs: 0

      AttrID: 0xffffffff           Neighbor: 0.0.0.0

       Flags: 0x10041           OrigNextHop: 192.168.51.1

       Label: NULL              RealNextHop: 192.168.51.1

     BkLabel: NULL                BkNextHop: N/A

     SRLabel: NULL                Interface: GigabitEthernet3/1/2

   BkSRLabel: NULL              BkInterface: N/A

    SIDIndex: NULL                  InLabel: NULL

   Tunnel ID: Invalid           IPInterface: GigabitEthernet3/1/2

 BkTunnel ID: Invalid         BkIPInterface: N/A

    FtnIndex: 0x0            ColorInterface: N/A

TrafficIndex: N/A          BkColorInterface: N/A

   Connector: 0.0.0.0             VpnPeerId: N/A

        Dscp: N/A                       Exp: N/A

  SRTunnelID: Invalid             StatFlags: 0x0

    SID Type: N/A                       SID: N/A

       BkSID: N/A                       NID: Invalid

    FlushNID: Invalid                 BkNID: Invalid

  BkFlushNID: Invalid                PathID: 0x0

CommBlockLen: 0

  OrigLinkID: 0x0                RealLinkID: 0x0

 

 Destination: 192.168.51.0/24

    Protocol: O_INTRA

  Process ID: 1

   SubProtID: 0x1                       Age: 12h54m07s

        Cost: 1                  Preference: 10

       IpPre: N/A                QosLocalID: N/A

         Tag: 0                       State: Inactive Adv

   OrigTblID: 0x0                   OrigVrf: default-vrf

     TableID: 0x2                    OrigAs: 0

       NibID: 0x13000001             LastAs: 0

      AttrID: 0xffffffff           Neighbor: 0.0.0.0

       Flags: 0x10c1            OrigNextHop: 0.0.0.0

       Label: NULL              RealNextHop: 0.0.0.0

     BkLabel: NULL                BkNextHop: N/A

     SRLabel: NULL                Interface: GigabitEthernet3/1/2

   BkSRLabel: NULL              BkInterface: N/A

    SIDIndex: NULL                  InLabel: NULL

   Tunnel ID: Invalid           IPInterface: GigabitEthernet3/1/2

 BkTunnel ID: Invalid         BkIPInterface: N/A

    FtnIndex: 0x0            ColorInterface: N/A

TrafficIndex: N/A          BkColorInterface: N/A

   Connector: 0.0.0.0             VpnPeerId: N/A

        Dscp: N/A                       Exp: N/A

  SRTunnelID: Invalid             StatFlags: 0x0

    SID Type: N/A                       SID: N/A

       BkSID: N/A                       NID: Invalid

    FlushNID: Invalid                 BkNID: Invalid

  BkFlushNID: Invalid                PathID: 0x0

CommBlockLen: 0

  OrigLinkID: 0x0                RealLinkID: 0x0

(3)     检查OSPF进程下是否配置了filter-policy import命令。

某些场景下需要对路由信息进行过滤,实现业务隔离。请检查是否存在OSPF路由被错误过滤的情况。

a.     请在本端设备出现问题的OSPF进程下执行display this命令,查看该OSPF进程下是否配置了filter-policy import命令,导致OSPF路由被过滤。

[Sysname-ospf-1] display this

#

ospf 1

 import-route direct

 filter-policy 2000 import

 area 0.0.0.1

  network 192.168.51.0 0.0.0.255

  nssa

#

return

b.     如果OSPF进程下配置了filter-policy import命令,请查看该命令引用的过滤规则的配置信息。

-     对于filter-policy import命令引用ACL规则进行路由过滤的情况,请执行display acl { acl-number | name acl-name }命令查看ACL的配置信息。

-     对于filter-policy import命令引用前缀列表进行路由过滤的情况,请执行display ip prefix-list命令查看地址前缀列表的配置信息。

-     对于filter-policy import命令引用路由策略进行路由过滤的情况,请执行display route-policy命令查看路由策略的配置信息。

如果路由被过滤规则拒绝,请结合组网及实际业务需求确认过滤规则的配置是否合理。如果不合理,请修改filter-policy import命令引用的过滤规则。

c.     如果该路由没有被拒绝,或者该OSPF进程并没有配置filter-policy import过滤策略,请执行步骤(4)

(4)     检查OSPF进程的LSDB是否包含未学习到的OSPF路由的LSA。

请根据OSPF进程未学习到的路由信息的类型选择不同的故障处理方式。

o     OSPF区域内路由

如果OSPF进程缺失区域内路由,请在用户视图下执行display ospf [ process-id ] lsdb router命令,检查LSDB是否包含该区域中所有的Router LSA信息。

<Sysname> display ospf 100 lsdb router

 

         OSPF Process 100 with Router ID 5.5.5.5

                         Area: 0.0.0.1

                 Link State Database

 

 

    Type      : Router

    LS ID     : 5.5.5.5

    Adv Rtr   : 5.5.5.5

    LS age    : 7

    Len       : 36

    Options   : ASBR O NP

    Seq#      : 80000026

    Checksum  : 0x5f1f

    Link Count: 1

       Link ID: 192.168.51.1

       Data   : 192.168.51.5

       Link Type: TransNet

       Metric : 1

 

    Type      : Router

    LS ID     : 1.1.1.1

    Adv Rtr   : 1.1.1.1

    LS age    : 8

    Len       : 36

    Options   : ASBR ABR O NP

    Seq#      : 8000002a

    Checksum  : 0x534a

    Link Count: 1

       Link ID: 192.168.51.1

       Data   : 192.168.51.1

       Link Type: TransNet

       Metric : 1

-     如果OSPF进程的LSDB缺失Router LSA,请执行步骤(7)

-     如果OSPF进程的LSDB包含完整的Router LSA,但是无法计算出路由信息,请执行步骤(7)

o     OSPF区域间路由

如果OSPF进程缺失区域间路由,请在用户视图下执行display ospf [ process-id ] lsdb summary命令,检查LSDB是否包含其他所有区域的Network Summary LSA。

<Sysname> display ospf lsdb summary

 

         OSPF Process 1 with Router ID 5.5.5.5

                         Area: 0.0.0.1

                 Link State Database

 

    Type      : Sum-Net

    LS ID     : 192.168.24.0

    Adv Rtr   : 1.1.1.1

    LS age    : 576

    Len       : 28

    Options   : O NP

    Seq#      : 8000001f

    Checksum  : 0x4c25

    Net Mask  : 255.255.255.0

    Tos 0  Metric: 2

 

    Type      : Sum-Net

    LS ID     : 192.168.12.0

    Adv Rtr   : 1.1.1.1

    LS age    : 576

    Len       : 28

    Options   : O NP

    Seq#      : 8000001f

    Checksum  : 0xc6b7

    Net Mask  : 255.255.255.0

    Tos 0  Metric: 1

-     如果OSPF进程的LSDB缺失Network Summary LSA,检查本区域下是否配置了filter import命令,或者Network Summary LSA的发布者所在区域下是否配置了filter export命令。如果filter import命令或filter export命令引用的过滤规则错误地过滤掉了Network Summary LSA,请修改过滤规则相关配置。

filter import命令和filter export命令可以引用ACL、前缀列表、路由策略对Network Summary LSA进行过滤,请分别使用display acl { acl-number | name acl-name }命令、display ip prefix-list命令、display route-policy命令查看相应的配置信息。

-     如果OSPF进程的LSDB包含完整的Network Summary LSA,但是无法计算出路由信息,请执行步骤(7)

o     O_ASE路由或者O_NSSA路由

如果OSPF进程缺失O_ASE路由,请在用户视图下执行display ospf [ process-id ] lsdb ase命令。检查LSDB是否包含AS External LSA。

<Sysname> display ospf 100 lsdb ase

 

         OSPF Process 100 with Router ID 1.1.1.1

                 Link State Database

 

 

    Type      : External

    LS ID     : 10.1.1.0

    Adv Rtr   : 1.1.1.1

    LS age    : 713

    Len       : 36

    Options   : O E

    Seq#      : 80000001

    Checksum  : 0x934b

    Net Mask  : 255.255.255.0

    TOS 0  Metric: 1

    E Type    : 2

    Forwarding Address : 192.168.51.5

    Tag       : 1

如果OSPF进程缺失O_NSSA路由,请在用户视图下执行display ospf [ process-id ] lsdb nssa命令,检查LSDB是否包含NSSA External LSA。

<Sysname> display ospf 100 lsdb nssa

 

         OSPF Process 100 with Router ID 1.1.1.1

                         Area: 0.0.0.0

                 Link State Database

 

                         Area: 0.0.0.1

                 Link State Database

 

 

    Type      : NSSA

    LS ID     : 192.168.51.0

    Adv Rtr   : 5.5.5.5

    LS age    : 965

    Len       : 36

    Options   : O NP

    Seq#      : 8000001f

    Checksum  : 0x1dfa

    Net Mask  : 255.255.255.0

    TOS 0  Metric: 1

    E Type    : 2

    Forwarding Address : 192.168.51.5

    Tag       : 1

 

    Type      : NSSA

    LS ID     : 10.1.1.0

    Adv Rtr   : 5.5.5.5

    LS age    : 965

    Len       : 36

    Options   : O NP

    Seq#      : 8000001f

    Checksum  : 0x6840

    Net Mask  : 255.255.255.0

    TOS 0  Metric: 1

    E Type    : 2

    Forwarding Address : 192.168.51.5

    Tag       : 1

-     如果OSPF进程的LSDB缺失AS External LSA或NSSA External LSA,请执行步骤(7)

-     如果OSPF进程的LSDB包含完整的AS External LSA或NSSA External LSA,但是无法学习到O_ASE路由或者O_NSSA路由的情况,请执行步骤(7)

(5)     检查ABR设备是否可达。

区域间路由是ABR设备发布的,如果本端设备和ABR设备之间路由不可达,则会导致本端设备无法学习到区域间路由。

a.     请在本端设备执行display ospf [ process-id ] lsdb summary命令,查看Adv Rtr字段,该字段为通告Network Summary LSA的Router ID,即ABR的Router ID。

<Sysname> display ospf 100 lsdb summary

 

         OSPF Process 100 with Router ID 5.5.5.5

                         Area: 0.0.0.1

                 Link State Database

 

 

    Type      : Sum-Net

    LS ID     : 192.168.12.0

    Adv Rtr   : 1.1.1.1

    LS age    : 913

    Len       : 28

    Options   : O E

    Seq#      : 80000001

    Checksum  : 0x5d45

    Net Mask  : 255.255.255.0

    Tos 0  Metric: 1

b.     请在本端设备执行display ospf abr-asbr命令,查看Destination字段和RtType字段,RtType字段取值为ABR时,Destination字段为ABR的Router ID。查看到此类路由信息时,说明存在到达为ABR的路由。

<Sysname> display ospf 100 abr-asbr

 

         OSPF Process 100 with Router ID 5.5.5.5

                 Routing Table to ABR and ASBR

 

 Type    Destination     Area            Cost     Nexthop         RtType

 Intra   1.1.1.1         0.0.0.1         1        192.168.51.1    ABR

c.     如果abr-asbr信息中不包含到达通告Network Summary LSA的ABR的路由,请执行步骤(7)

d.     如果abr-asbr信息中包含到达通告Network Summary LSA的ABR的路由,且本设备为ABR设备,请检查OSPF区域是否为骨干区域。

-     如果OSPF区域为非骨干区域(区域ID不为零),根据RFC 2328的规定,ABR设备不会对非骨干区的Network Summary LSA进行计算,没有区域间路由是正常现象。

-     如果OSPF区域为骨干区域(区域ID为零),但是没有学习到区域间路由,请执行步骤(7)

e.     如果abr-asbr信息中包含到达通告Network Summary LSA的ABR的路由,且本OSPF进程绑定了VPN实例。请检查OSPF进程下是否配置了vpn-instance-capability simple命令。如果OSPF进程下配置了vpn-instance-capability simple命令,请执行步骤(7)

如果OSPF进程下未配置vpn-instance-capability simple命令,故障处理方式如表8-2所示。

表8-2 OSPF进程下未配置vpn-instance-capability simple命令的故障处理方式

DN比特位是否置位

故障处理方式

未配置vpn-instance-capability simple命令,且Network Summary LSA的Option字段包含DN比特位(即DN比特位置位)

根据RFC 2328的规定,私网OSPF进程不会使用DN比特位置位的Network Summary LSA进行路由计算。没有对应的区域间路由是正常现象

未配置vpn-instance-capability simple命令,且Network Summary LSA的Option字段不包含DN比特位

请执行步骤(7)

 

(6)     检查ASBR设备是否可达,检查是否有防环检测。

O_ASE路由和O_NSSA路由是ASBR设备发布的,如果本端设备和ASBR设备之间路由不可达,则会导致本端设备无法学习到AS外部的路由。

a.     请执行display ospf [ process-id ] lsdb [ ase | nssa ]命令,查看Adv Rtr字段,该字段为通告AS External LSA(Type-5)或NSSA External LSA(Type-7)的Router ID,即ASBR的Router ID。

<Sysname> display ospf 100 lsdb ase

 

         OSPF Process 100 with Router ID 1.1.1.1

                 Link State Database

 

 

    Type      : External

    LS ID     : 10.1.1.0

    Adv Rtr   : 1.1.1.1

    LS age    : 169

    Len       : 36

    Options   : O E

    Seq#      : 80000001

    Checksum  : 0x934b

    Net Mask  : 255.255.255.0

    TOS 0  Metric: 1

    E Type    : 2

    Forwarding Address : 192.168.51.5

    Tag       : 1

<Sysname> display ospf 100 lsdb nssa

 

         OSPF Process 100 with Router ID 1.1.1.1

                         Area: 0.0.0.0

                 Link State Database

 

                         Area: 0.0.0.1

                 Link State Database

 

 

    Type      : NSSA

    LS ID     : 192.168.51.0

    Adv Rtr   : 5.5.5.5

    LS age    : 156

    Len       : 36

    Options   : O NP

    Seq#      : 80000001

    Checksum  : 0x59dc

    Net Mask  : 255.255.255.0

    TOS 0  Metric: 1

    E Type    : 2

    Forwarding Address : 192.168.51.5

    Tag       : 1

 

    Type      : NSSA

    LS ID     : 10.1.1.0

    Adv Rtr   : 5.5.5.5

    LS age    : 156

    Len       : 36

    Options   : O NP

    Seq#      : 80000001

    Checksum  : 0xa422

    Net Mask  : 255.255.255.0

    TOS 0  Metric: 1

    E Type    : 2

    Forwarding Address : 192.168.51.5

    Tag       : 1

b.     请执行display ospf abr-asbr命令,查看Destination字段和RtType字段,RtType字段取值为ASBR时,Destination字段为ASBR的Router ID。查看到此类路由信息时,说明存在到达为ASBR的路由。

<Sysname> display ospf 100 abr-asbr

 

         OSPF Process 100 with Router ID 1.1.1.1

                 Routing Table to ABR and ASBR

 

 Type    Destination     Area            Cost     Nexthop         RtType

 Intra   5.5.5.5         0.0.0.1         1        192.168.51.5    ASBR

c.     如果abr-asbr信息中不包含到达通告AS External LSA或NSSA External LSA的ASBR的路由,请执行步骤(7)

d.     如果abr-asbr信息中包含到达通告AS External LSA或NSSA External LSA的ASBR的路由,且LSA的Forwarding Address字段不为零,需要检查Forwarding Address的可达性及路由类型。

请在用户视图下执行disply ospf arouting forwarding-address { mask-length | mask }命令查询是否存在到达Forwarding Address的路由。

<Sysname> display ospf 100 routing 192.168.51.5 24

 

         OSPF Process 100 with Router ID 1.1.1.1

                  Routing Table

 

 Routing for network

 Destination        Cost     Type    NextHop         AdvRouter       Area

 192.168.51.0/24    1        Transit 0.0.0.0         5.5.5.5         0.0.0.1

 

 Total nets: 1

 Intra area: 1  Inter area: 0  ASE: 0  NSSA: 0

Forwarding Address的可达性及路由类型对OSPF是否能够学习到O_ASE路由或O_NSSA路由的影响如表8-3所示。

表8-3 Forwarding Address的可达性及路由类型对O_ASE路由或O_NSSA路由的影响

Forward Address是否可达

故障处理方式

不可达

如果通过display ospf routing forwarding-address { mask-length | mask }命令无法查看到路由信息,说明Forwarding Address不可达,请执行步骤(7)

可达

如果外部路由是由NSSA External LSA(Type-7)通告的,根据RFC 3101的规定,要求到达Forwarding Address的路由所在区域与NSSA External LSA所在区域相同。如果Area字段标明的区域号与NSSA External LSA所在的区域不同,OSPF不使用此类NSSA External LSA进行路由计算。因此,没有对应的外部路由是正常现象

通过display ospf routing forwarding-address { mask-length | mask }命令查看到的路由的Type字段为Type1或者Type2,说明到达Forwarding Address的路由类型是外部路由。根据RFC 2328的规定,到达非零Forwarding Address的路由类型不允许是外部路由,OSPF不使用此类LSA进行路由计算。因此,没有对应的外部路由是正常现象

 

e.     如果abr-asbr信息中包含到达通告AS External LSA或NSSA External LSA的ASBR的路由,且本OSPF进程绑定了VPN实例。

请检查本OSPF进程下是否配置了vpn-instance-capability simple命令。如果OSPF进程下配置了vpn-instance-capability simple命令,请执行步骤(7)

如果OSPF进程下未配置vpn-instance-capability simple命令,故障处理方式如表8-4所示。

表8-4 OSPF进程下未配置vpn-instance-capability simple命令的故障处理方式

DN比特位是否置位

故障处理方式

未配置vpn-instance-capability simple命令,且AS External LSA或者NSSA External LSA的Option字段包含DN比特位

根据RFC 2328的规定,私网OSPF进程不会使用DN比特位置位的AS External LSA或者NSSA External LSA进行路由计算。没有对应的外部路由是正常现象

未配置vpn-instance-capability simple命令,且AS External LSA或者NSSA External LSA的Option字段不包含DN比特位

请执行display ospf命令查看Default ASE parameters字段,确认AS External LSA或者NSSA External LSA的Tag值是否与私网OSPF进程的Tag值相同:

·     对于Tag值相同的情况,根据RFC 2328的规定,私网OSPF进程不会使用此类LSA进行路由计算。因此,没有对应的外部路由是正常现象

·     对于Tag值不同的情况,请执行步骤(7)

 

(7)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

5. 告警与日志

相关告警

相关日志

8.4.4  网络中IP地址冲突导致路由震荡

1. 故障描述

OSPF组网中不同设备上配置相同的接口IP地址,会导致OSPF路由震荡。出现此问题时,设备通常伴随如下现象:

·     执行命令display cpu-usage查看到设备CPU使用率较高。

·     OSPF频繁地老化LSA、重新生成LSA。

·     设备路由频繁刷新、路由计算出错。

2. 处理步骤

图8-12为示例说明此类故障的处理方式。其他组网与该组网处理此类故障的思路是相同的。

图8-12 网络中IP地址冲突导致路由震荡组网示例

 

(2)     在OSPF网络中的各个设备上每隔一秒执行一次display ospf [ process-id ] lsdb命令,查看每台设备的OSPF链路状态数据库(LSDB)信息。

(3)     检查是否存在LSA老化异常的情况。

同时满足如下条件时,说明LSA老化异常。

a.     在Device A上发现同一个AdvRouter通告的Network LSA(Type-2)的老化时间(Age)非自然增长,一直为最小值,且Sequence字段增加很快。例如在如下显示信息中,LinkStateID为172.168.0.1的Network LSA的Age非自然增长,短时间内Sequence从8000002D快速增长为8000002F。

<Sysname> display ospf 100 lsdb

 

         OSPF Process 100 with Router ID 10.1.1.1

                 Link State Database

 

                         Area: 0.0.0.0

 Type      LinkState ID    AdvRouter       Age  Len   Sequence  Metric

 Router    3.3.3.3         3.3.3.3         797  48    80000009  0

 Router    1.1.1.1         1.1.1.1         835  36    80000005  0

 Router    4.4.4.4         4.4.4.4         798  36    80000004  0

 Router    10.1.1.1        10.1.1.1        415  36    80000007  0

 Router    2.2.2.2         2.2.2.2         415  48    80000015  0

 Network   192.168.0.2     3.3.3.3         802  32    80000002  0

 Network   172.168.0.3     4.4.4.4         791  32    80000002  0

 Network   172.168.0.1     10.1.1.1        7    32    8000002D  0

<Sysname> display ospf 100 lsdb

 

         OSPF Process 100 with Router ID 10.1.1.1

                 Link State Database

 

                         Area: 0.0.0.0

 Type      LinkState ID    AdvRouter       Age  Len   Sequence  Metric

 Router    3.3.3.3         3.3.3.3         810  48    80000009  0

 Router    1.1.1.1         1.1.1.1         848  36    80000005  0

 Router    4.4.4.4         4.4.4.4         811  36    80000004  0

 Router    10.1.1.1        10.1.1.1        428  36    80000007  0

 Router    2.2.2.2         2.2.2.2         428  48    80000015  0

 Network   192.168.0.2     3.3.3.3         815  32    80000002  0

 Network   172.168.0.3     4.4.4.4         804  32    80000002  0

 Network   172.168.0.1     10.1.1.1        4    32    8000002F  0

b.     在Device B上相同Network LSA的Age不断在3600和其他较小值之间切换,而且Sequence字段增加很快。例如在如下显示信息中,LinkStateID为172.168.0.1的Network LSA的Age在3600和其他较小值之间切换,短时间内Sequence从80000023快速增长为80000041。

<Sysname> display ospf 100 lsdb

 

         OSPF Process 100 with Router ID 2.2.2.2

                 Link State Database

 

                         Area: 0.0.0.0

 Type      LinkState ID    AdvRouter       Age  Len   Sequence  Metric

 Router    3.3.3.3         3.3.3.3         708  48    80000009  0

 Router    1.1.1.1         1.1.1.1         746  36    80000005  0

 Router    4.4.4.4         4.4.4.4         709  36    80000004  0

 Router    10.1.1.1        10.1.1.1        329  36    80000007  0

 Router    2.2.2.2         2.2.2.2         327  48    80000015  0

 Network   172.168.0.3     4.4.4.4         702  32    80000002  0

 Network   192.168.0.2     3.3.3.3         713  32    80000002  0

 Network   172.168.0.1     10.1.1.1        3600 32    80000023  0

<Sysname> display ospf 100 lsdb

 

         OSPF Process 100 with Router ID 2.2.2.2

                 Link State Database

 

                         Area: 0.0.0.0

 Type      LinkState ID    AdvRouter       Age  Len   Sequence  Metric

 Router    3.3.3.3         3.3.3.3         748  48    80000009  0

 Router    1.1.1.1         1.1.1.1         786  36    80000005  0

 Router    4.4.4.4         4.4.4.4         749  36    80000004  0

 Router    10.1.1.1        10.1.1.1        369  36    80000007  0

 Router    2.2.2.2         2.2.2.2         367  48    80000015  0

 Network   172.168.0.3     4.4.4.4         742  32    80000002  0

 Network   192.168.0.2     3.3.3.3         753  32    80000002  0

 Network   172.168.0.1     10.1.1.1        7    32    80000041  0

c.     在Device C上,相同Network LSA的Age一直为3600,或者偶尔没有这条LSA,而且Sequence字段增加很快。例如在如下显示信息中,LinkStateID为172.168.0.1的Network LSA的Age为3600,或者偶尔没有这条LSA;存在这条LSA时,短时间内Sequence从80000309增长到80000346。

<Sysname> display ospf 100 lsdb

 

         OSPF Process 100 with Router ID 3.3.3.3

                 Link State Database

 

                         Area: 0.0.0.0

 Type      LinkState ID    AdvRouter       Age  Len   Sequence  Metric

 Router    3.3.3.3         3.3.3.3         740  48    8000000D  0

 Router    4.4.4.4         4.4.4.4         759  36    80000008  0

 Router    10.1.1.1        10.1.1.1        364  36    8000000B  0

 Router    2.2.2.2         2.2.2.2         366  48    80000019  0

 Network   172.168.0.3     4.4.4.4         755  32    80000006  0

 Network   192.168.0.2     3.3.3.3         744  32    80000006  0

 Network   172.168.0.1     10.1.1.1        3600 32    80000309  0

<Sysname> display ospf 100 lsdb

 

         OSPF Process 100 with Router ID 3.3.3.3

                 Link State Database

 

                         Area: 0.0.0.0

 Type      LinkState ID    AdvRouter       Age  Len   Sequence  Metric

 Router    3.3.3.3         3.3.3.3         745  48    8000000D  0

 Router    4.4.4.4         4.4.4.4         764  36    80000008  0

 Router    10.1.1.1        10.1.1.1        369  36    8000000B  0

 Router    2.2.2.2         2.2.2.2         371  48    80000019  0

 Network   172.168.0.3     4.4.4.4         760  32    80000006  0

 Network   192.168.0.2     3.3.3.3         749  32    80000006  0

<Sysname> display ospf 100 lsdb

 

         OSPF Process 100 with Router ID 3.3.3.3

                 Link State Database

 

                         Area: 0.0.0.0

 Type      LinkState ID    AdvRouter       Age  Len   Sequence  Metric

 Router    3.3.3.3         3.3.3.3         1302 48    8000000D  0

 Router    4.4.4.4         4.4.4.4         1321 36    80000008  0

 Router    10.1.1.1        10.1.1.1        926  36    8000000B  0

 Router    2.2.2.2         2.2.2.2         928  48    80000019  0

 Network   172.168.0.3     4.4.4.4         1317 32    80000006  0

 Network   192.168.0.2     3.3.3.3         1306 32    80000006  0

 Network   172.168.0.1     10.1.1.1        3600 32    80000346  0

(4)     检查是否存在OSPF路由震荡。

在Device B上每隔一秒执行一次display ospf [ process-id ] routing命令,查看路由是否震荡。

<Sysname> display ospf 100 routing

 

         OSPF Process 100 with Router ID 2.2.2.2

                  Routing Table

 

 Routing for network

 Destination        Cost     Type    NextHop         AdvRouter       Area

 192.168.0.0/24     1        Transit 0.0.0.0         3.3.3.3         0.0.0.0

 172.168.0.0/24     1        Transit 0.0.0.0         10.1.1.1        0.0.0.0

 

 Total nets: 2

 Intra area: 2  Inter area: 0  ASE: 0  NSSA: 0

<Sysname> display ospf 100 routing

 

         OSPF Process 100 with Router ID 2.2.2.2

                  Routing Table

 

 Routing for network

 Destination        Cost     Type    NextHop         AdvRouter       Area

 192.168.0.0/24     1        Transit 0.0.0.0         3.3.3.3         0.0.0.0

 172.168.0.0/24     2        Transit 192.168.0.2     4.4.4.4         0.0.0.0

 

 Total nets: 2

 Intra area: 2  Inter area: 0  ASE: 0  NSSA: 0

当OSPF路由发生震荡,且多次执行display ospf peer命令发现邻居关系没有发生震荡时,可以判断该OSPF组网中存在IP地址冲突。同时,由于Network LSA(Type-2)是由DR发布的,说明产生冲突的设备中有一台设备是DR。

如果任一台设备上出现两个LinkState ID相同的Network LSA,并且这两个Network LSA老化异常。说明产生冲突的设备均为DR。

<Sysname> display ospf 100 lsdb

 

         OSPF Process 100 with Router ID 10.1.1.1

                 Link State Database

 

                         Area: 0.0.0.0

 Type      LinkState ID    AdvRouter       Age  Len   Sequence  Metric

 Router    3.3.3.3         3.3.3.3         367  48    80000021  0

 Router    4.4.4.4         4.4.4.4         369  36    80000013  0

 Router    10.1.1.1        10.1.1.1        477  36    80000012  0

 Router    2.2.2.2         2.2.2.2         403  48    8000002B  0

 Network   192.168.0.1     2.2.2.2         395  32    80000002  0

 Network   172.168.0.1     3.3.3.3         3600 32    8000002B  0

 Network   172.168.0.1     10.1.1.1        9    32    80000036  0

<Sysname> display ospf 100 lsdb

 

         OSPF Process 100 with Router ID 10.1.1.1

                 Link State Database

 

                         Area: 0.0.0.0

 Type      LinkState ID    AdvRouter       Age  Len   Sequence  Metric

 Router    3.3.3.3         3.3.3.3         460  48    80000021  0

 Router    4.4.4.4         4.4.4.4         462  36    80000013  0

 Router    10.1.1.1        10.1.1.1        570  36    80000012  0

 Router    2.2.2.2         2.2.2.2         496  48    8000002B  0

 Network   192.168.0.1     2.2.2.2         488  32    80000002  0

 Network   172.168.0.1     3.3.3.3         3600 32    80000034  0

 Network   172.168.0.1     10.1.1.1        6    32    80000041  0

(5)     定位产生冲突的设备。

结合display ospf lsdb的显示信息,找到产生IP地址冲突的设备。

¡     产生冲突的设备中,仅有一台设备为DR。

根据异常Network LSA的AdvRouter,可以找到产生该Network LSA的DR设备;然后根据Network LSA中的LinkState ID找到产生IP地址冲突的接口,确定该接口的IP地址。根据接口的IP地址以及网络IP地址规划,找到另外一台产生冲突的设备。

在本例中,可以判断Router ID为10.1.1.1的DR设备接口IP地址与其他设备接口IP地址冲突,产生冲突的IP地址是172.168.0.1。然后根据网络IP地址规划,找到与DR设备接口IP地址冲突的另外一台设备。

¡     产生冲突的设备均为DR。

根据异常Network LSA的AdvRouter,可以找到产生该Network LSA的DR设备;然后根据Network LSA中的LinkState ID找到产生IP地址冲突的接口。

(6)     根据网络IP地址规划修改冲突一方的IP地址。

(7)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

3. 告警与日志

相关告警

相关日志


9 IP组播故障处理

9.1  二层组播故障处理

9.1.1  二层组播业务不通

1. 故障描述

二层组播业务不通主要表现在二层组播转发表项无法生成,导致组播流量无法正常转发。

2. 常见原因

本类故障的常见原因主要包括:

·     设备没有收到二层组播协议报文。

·     IGMP协议报文格式不正确。

·     二层组播转发表项未生成。

3. 故障分析

本类故障的诊断思路如下:

(1)     检查是否生成二层组播转发表项。

(2)     检查是否正常收到组播协议报文。

(3)     检查IGMP协议报文格式是否正确。

(4)     检查IGMP报文版本是否跟设备上配置的一致。

(5)     检查是否开启三层组播功能。

本类故障的诊断流程如图9-1所示。

图9-1 二层组播业务不通的故障诊断流程图

 

4. 处理步骤

(1)     检查是否生成正确的二层组播转发表项。

执行display l2-multicast ip forwarding命令查看二层组播表项是否生成。

¡     如果存在,请直接联系技术人员。

¡     如果不存在,请执行步骤(2)

(2)     检查设备是否正常收到IGMP成员关系报告报文。

执行debugging igmp-snooping packet命令,打开IGMP Snooping报文调试信息开关。如果设备上打印如下调试信息,表示可以正常收到成员关系报告报文。

*Sep 15 11:47:41:455 2011 Sysname MCS/7/PACKET: -MDC=1; Receive IGMPv2 report packet from port 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. 告警与日志

相关告警

相关日志

9.2  三层组播故障处理

9.2.1  三层组播业务不通

1. 故障描述

三层组播业务不通主要表现在组播流量转发失败。

2. 常见原因

本类故障的常见原因主要包括:

·     单播路由配置错误。

·     接口状态不正确。

·     PIM路由表项未正确生成。

·     组播转发表项未正确生成。

3. 故障分析

本类故障的诊断流程如图9-2所示。

图9-2 三层组播业务不通的故障诊断流程图

 

4. 处理步骤

(1)     检查是否存在到组播源的单播路由。

执行display ip routing-table ip-address命令,查看是否存在到达组播源的路由。其中,ip-address指定为组播源的地址。

¡     如果不存在,请配置到达组播源的路由。

¡     如果存在,请执行步骤(2)

(2)     检查组播流量入、出接口的状态是否正常。

执行display interface命令查看接口物理层状态。

¡     如果接口物理层状态为Down,请解决接口故障问题。

如果接口物理层状态为Up,请执行步骤(3)

(3)     检查是否生成正确的PIM路由表项。

执行display pim routing-table命令,查看PIM路由表项是否生成,以及是否有对应的出接口。

¡     如果没有,请联系技术支持人员。

¡     如果有,请执行步骤(4)

(4)     检查是否生成正确的组播转发表项。

执行display multicast forwarding-table命令,查看组播转发表项是否生成,以及是否有对应的出接口。

¡     如果没有,请收集上述步骤的执行结果和设备的配置文件,并联系技术支持人员。

¡     如果有,也请收集上述步骤的执行结果和设备的配置文件,并联系技术支持人员。

5. 告警与日志

相关告警

相关日志

9.2.2  无法正常建立IGMP或MLD表项

1. 故障描述

组播设备无法正常建立IGMP或者MLD表项。

2. 常见原因

本类故障的常见原因主要包括:

·     设备上没有开启IP组播路由功能。

·     与用户主机网段直连的接口物理状态为Down。

·     与用户主机网段直连的接口未配置主IP地址。

·     与用户主机网段直连的接口上未开启IGMP或MLD功能。

·     组播组G属于SSM组地址范围,设备上配置的IGMP或MLD版本不正确。

·     设备上配置了SSM组地址过滤规则,但组播组G地址不在ACL定义的permit规则范围内。

·     设备上配置了IGMP或MLD组播组过滤器,但组播组G地址不在ACL定义的permit规则范围内。

3. 故障分析

本类故障的诊断流程如图9-3所示。

图9-3 设备无法正常建立IGMP或MLD表项的故障诊断流程图

 

4. 处理步骤

(1)     检查设备上是否开启IP组播路由功能。

在直连用户主机网段的设备上执行display current-configuration | include multicast命令,查看是否开启IP组播路由功能。

¡     如果未开启,请在系统视图下执行multicast routingipv6 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-policymld group-policy命令配置了IGMP或MLD组播组过滤器。

¡     如果已配置,请检查组播组G是否在ACL规则允许的范围之内。

-     如果不在,建议根据实际组网需要执行undo igmp group-policyundo mld group-policy命令删除该组播组过滤器配置;重新配置ACL规则,使得组播组G地址在ACL的permit规则中。

-     如果在,请执行步骤(8)

¡     如果未配置,请执行步骤(8)

(8)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

5. 告警与日志

相关告警

相关日志

9.3  MSDP故障处理

9.3.1  MSDP对等体无法正确建立(S,G)表项

1. 故障描述

配置组播网络后发现MSDP对等体无法正确建立(S,G)表项。

2. 常见原因

本类故障的常见原因主要包括:

·     MSDP对等体建立失败。

·     SA报文缓存机制未开启。

·     没有收到源端对等体发出的SA报文。

·     创建SA报文的MSDP对等体没有部署在RP上。

·     配置问题(比如,export、import过滤策略、import-source策略配置不正确)。

3. 故障分析

本类故障的诊断流程如图9-4所示。

图9-4 MSDP对等体无法正确建立(S,G)表项的故障诊断流程图

 

4. 处理步骤

(1)     检查MSDP对等体状态是否为Established。

在配置了MSDP对等体的设备上执行display msdp brief命令,通过显示信息中的State字段判断MSDP对等体状态是否为Established。

a.     如果不是,请检查MSDP对等体接口配置是否正确,以及MSDP对等体之间是否能够Ping通。如果Ping不通,请参见“Ping不通的定位思路”继续定位,确保MSDP对等体之间能够Ping通。

b.     如果是,请执行步骤(2)

(2)     检查是否开启SA报文缓存机制。

在MSDP对等体的MSDP视图下执行display this命令,查看是否已通过cache-sa-enable命令开启了SA报文缓存机制。

¡     如果未开启,请通过MSDP视图下的cache-sa-enable命令开启。

¡     如果已开启,请执行步骤(3)

(3)     检查是否有源端对等体发出的SA报文到达。

在MSDP对等体上执行display msdp sa-cache命令,查看本设备上SA缓存中(S,G)表项的信息。通过查看是否存在相应的表项信息,判断对等体是否收到源端对等体发送的SA报文。

¡     如果未收到,请执行步骤(4)

¡     如果已收到,请执行步骤(8)

(4)     检查源端MSDP对等体是否配置export过滤策略。

在源端MSDP对等体的MSDP视图下执行display this命令,查看设备上是否已通过peer peer-address sa-policy export命令配置export策略,即是否配置对转发给指定MSDP对等体的SA报文进行过滤。

¡     如果已配置,根据是否通过acl命令配置过滤规则,分为如下两种情况处理:

-     如果未配置ACL过滤规则,则表示该MSDP对等体不转发SA报文,请执行undo peer peer-address sa-policy export命令删除该配置。

-     如果配置了ACL过滤规则,则表示该MSDP对等体只转发符合ACL规则的(S,G)表项的SA报文。请检查需要转发的(S,G)表项的SA报文能否通过已配置的ACL规则的过滤。如果不能,可以执行undo peer peer-address sa-policy export命令删除该配置或调整指定的ACL规则。

¡     如果未配置,请执行步骤(5)

(5)     检查接收端MSDP对等体是否配置了import策略。

在接收端MSDP对等体的MSDP视图下执行display this命令,查看设备上是否已通过peer peer-address sa-policy import命令配置import策略,即对来自指定MSDP对等体的SA报文进行过滤。

¡     如果已配置,根据是否通过acl命令配置过滤规则,分为如下两种情况处理:

-     如果未配置ACL过滤规则,则表示该MSDP对等体不接收任何SA报文,请执行undo peer peer-address sa-policy import命令删除该配置。

-     如果配置了ACL过滤规则,则表示该MSDP对等体只接收符合ACL规则的(S,G)表项的SA报文。请检查需要接收的(S,G)表项的SA报文能否通过已配置的ACL规则的过滤。如果不能,可以执行undo peer peer-address sa-policy import命令删除该配置或调整指定的ACL规则。

¡     如果未配置,请执行步骤(6)

(6)     检查源端MSDP对等体是否为RP。

在源端MSDP对等体上执行display pim routing-table命令,通过查看显示信息中(S,G)对应的Flag字段取值是否为2MSDP,判断该MSDP对等体是否为RP。

¡     如果不是,请调整PIM-SM网络中RP的配置或者远端MSDP对等体的配置,确保源端MSDP对等体为RP。

¡     如果是,请执行步骤(7)

(7)     检查源端MSDP对等体是否配置了import-source策略。

在源端MSDP对等体的MSDP视图下执行display this命令,查看设备上是否已通过import-source命令配置了SA报文的创建规则。

¡     如果已配置,根据是否通过acl命令配置过滤规则,分为如下两种情况处理:

-     如果未配置ACL过滤规则,则表示该MSDP对等体在创建SA报文时,对所有的(S,G)表项不作通告,请执行undo import-source命令删除该配置。

-     如果配置了ACL过滤规则,则表示该MSDP对等体在创建SA报文时,只通告符合ACL规则的(S,G)表项。请检查需要通告的(S,G)表项能否通过已配置的ACL规则的过滤。如果不能,可以执行undo import-source命令删除该配置或调整指定的ACL规则。

¡     如果未配置,请执行步骤(8)

(8)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

5. 告警与日志

相关告警

相关日志

9.4  PIM故障处理

9.4.1  PIM邻居Down

1. 故障描述

PIM邻居Down。

2. 常见原因

本类故障的常见原因主要包括:

·     接口物理状态为Down。

·     接口上未配置主IP地址。

·     接口上PIM功能没有生效。

·     接口没有使能PIM。

·     接口上PIM相关配置不正确。

3. 故障分析

本类故障的诊断流程如图9-5所示。

图9-5 PIM邻居Down的故障诊断流程图

 

4. 处理步骤

(1)     检查接口的物理状态是否为Up。

请在设备上执行display interface interface-type interface-number命令查看显示信息中的“Current state”字段,确认接口的物理状态是否为Up。

a.     如果为Up,请执行步骤(2)

b.     如果为Down,请排查处理接口物理Down的问题。

(2)     检查接口上是否配置了主IP地址。

在设备直连用户主机网段接口的接口视图下执行display this命令,查看是否通过ip address命令配置了接口的主IP地址。

a.     如果没有配置,请在接口上通过ip address命令进行配置。

b.     如果已配置,请执行步骤(3)

(3)     检查接口是否使能PIM。

在设备上执行display current-configuration interface命令,查看接口上是否使能PIM。

a.     如果没有使能,请在接口视图下执行pim dmpim 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. 告警与日志

相关告警

相关日志

9.4.2  PIM域内三层组播流量不通

1. 故障描述

开启IP组播路由功能后,同一PIM域内三层组播流量不通。

2. 常见原因

本类故障的常见原因主要包括:

·     需要转发组播数据的接口未使能PIM。

·     接口的PIM协议没有生效。

·     PIM邻居未建立成功。

·     连接用户网段的接口未使能IGMP。

·     在PIM-SM网络中,没有配置RP或RP信息不正确。

·     不存在到达RP或组播源的RPF路由。

·     转发组播数据的接口上配置了组播边界。

·     在PIM-SM网络中,配置了错误的组播源过滤策略。

·     组播表项未生成。

3. 故障分析

本类故障的诊断流程如图9-6所示。

图9-6 PIM域内三层组播流量不通的故障诊断流程图

 

4. 处理步骤

(1)     检查需要转发组播数据的接口是否使能PIM。

在需要转发组播数据的接口视图下执行display this命令,检查是否存在pim smpim dm的配置。

¡     如果不存在,表明接口下PIM功能未开启。请在接口视图下通过pim smpim dm命令开启PIM功能。

¡     如果存在,请执行步骤(2)

(2)     检查接口的PIM功能是否生效。

在设备上执行display pim interface命令,通过查看显示信息中是否存在该接口对应的PIM相关信息确认接口上PIM功能是否生效。

¡     如果没有生效,请在设备上执行display interface interface-type interface-number命令查看显示信息中的“Current state”字段,确认接口的物理状态是否为Up。如果为Down,请排查处理接口物理Down的问题。

¡     如果生效,请执行步骤(3)

(3)     检查PIM邻居是否建立成功。

在设备上执行display pim neighbor命令,根据是否存在相应的PIM邻居信息,判断PIM邻居是否建立成功。

a.     如果未建立成功,请参见“PIM邻居Down”进行定位,确保PIM邻居建立成功。

b.     如果建立成功,请执行步骤(4)

(4)     检查连接用户网段的接口上IGMP功能是否生效。

在设备上执行display igmp interface命令,根据是否存在显示信息确认接口IGMP功能是否生效。

¡     如果没有生效,请检查接口下是否通过igmp enable命令开启了IGMP功能,确保IGMP功能已开启

¡     如果已生效,根据不同的网络类型执行如下操作:

-     若为PIM-SM网络,请执行步骤(5)

-     若为PIM-DM网络,请执行步骤(7)

(5)     对于PIM-SM网络,检查RP信息是否正确。

在设备上执行display pim rp-info命令,查看设备是否生成了为某组播组服务的RP信息表项,并检查PIM-SM域中其它所有设备上,为此组播组服务的RP信息是否配置一致。

¡     如果不一致,且PIM-SM网络中使用静态RP,请在PIM-SM域的所有设备上的PIM视图下执行static-rp命令,将为某组播组服务的RP地址配置为相同的地址;如果PIM-SM网络中使用动态RP,请执行步骤(6)

¡     如果一致,请执行步骤(6)

(6)     检查是否存在到达RP的RPF路由。

在设备上执行display multicast rpf-info命令,查看是否存在到达RP的RPF路由。

¡     如果不存在,检查单播路由配置。请在当前设备和RP上分别执行ping命令,检查是否能够互相ping通。如果ping不通,请修改单播路由配置,直到ping通为止。

¡     如果存在,通过执行display multicast rpf-info命令,查看显示信息中的Referenced route type字段,确认RPF为组播静态路由还是单播路由。

-     如果RPF路由为组播静态路由,请执行display multicast routing-table static命令查看组播静态路由配置是否合理。

-     如果RPF路由为单播路由,请执行display ip routing-table命令查看单播路由是否与RPF路由一致。

如果到达RP的RPF路由存在且配置合理,请执行步骤(8)

(7)     检查是否存在到达组播源的RPF路由。

在设备上执行display multicast rpf-info命令,查看是否存在到达组播源的RPF路由。

¡     如果不存在,检查单播路由配置。请在当前设备和组播源上分别执行ping命令,检查是否能够互相ping通。如果ping不通,请修改单播路由配置,直到Ping通为止。

¡     如果存在,通过执行display multicast rpf-info命令,查看显示信息中的Referenced route type字段,确认RPF为组播静态路由还是单播路由。

-     如果Referenced route type字段显示为“multicast static”,表示RPF路由为组播静态路由,请执行display multicast routing-table static命令查看组播静态路由配置是否合理。

-     如果Referenced route type字段显示为“igp”、“egp”、“unicast (direct)”或“unicast”,表示RPF路由为单播路由,请执行display ip routing-table命令查看单播路由是否与RPF路由一致。

如果到达组播源的RPF路由存在且配置合理,请执行步骤(8)

(8)     检查RPF接口和RPF邻居接口上是否配置组播转发边界。

在设备上执行display multicast boundary命令,查看接口上是否配置了组播转发边界。

¡     如果已配置,建议在接口上执行undo multicast boundary命令删除对应配置或重新进行网络规划,确保RPF接口和RPF邻居接口没有配置组播边界。

¡     如果未配置,请执行步骤(9)

(9)     检查是否配置组播数据过滤器。

在PIM视图下执行display this命令,查看是否配置组播数据过滤器(通过PIM视图下的source-policy命令配置)。

¡     如果已配置,继续确认接收到的组播数据是否在过滤器指定的允许范围之内。如果不在,建议根据实际组网需要执行undo source-policy命令删除该配置或重新配置ACL规则,确保用户需要的组播数据正常转发。

¡     如果未配置,请执行步骤(10)

(10)     检查组播表项是否生成。

在设备上分别查看组播表项是否生成:

¡     如果存在相应的表项,流量仍然不通,请收集相关表项信息,并执行步骤(11)

¡     如果不存在,请执行步骤(11)

需要查看的组播表项以及查看方式如下:

¡     在设备上执行display pim routing-table命令,检查PIM协议路由表项是否生成。

¡     在设备上执行display igmp group命令,检查IGMP协议是否有对应的组播组。

¡     在设备上执行display multicast routing-table命令,检查组播路由表是否生成。

¡     在设备上执行display multicast forwarding-table命令,检查组播转发表是否生成。

(11)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

5. 告警与日志

相关告警

相关日志

9.4.3  PIM-SM网络中SPT无法正常转发数据

1. 故障描述

PIM-SM网络中SPT无法正常转发数据,组播流量不通。

2. 常见原因

本类故障的常见原因主要包括:

·     组播设备连接下游设备的接口没有收到PIM加入报文。

·     PIM-SM域内组播设备上的接口没有开启PIM-SM。

·     PIM-SM域内组播设备到组播源的RPF路由不正确。

·     配置不正确(比如组播转发边界配置不正确、组播数据过滤器配置不正确等)。

3. 故障分析

本类故障的诊断流程如图9-7所示。

图9-7 PIM-SM网络中SPT无法正常转发数据故障诊断流程图

 

4. 处理步骤

(1)     检查PIM路由表中是否存在正确的(S,G)表项。

在设备上执行display pim routing-table命令,查看PIM路由表中是否存在正确的(S,G)表项。如果PIM路由表中存在正确的(S,G)表项,查看下游接口列表中是否包含到达所有组成员的下游接口。

¡     如果PIM路由表中的(S,G)表项存在且信息完全正确,请在设备上执行display multicast forwarding-table命令,通过显示信息中的“Matched packets”和“Forwarded packets”字段,确认(S,G)表项匹配的组播报文数量和已转发的组播报文是否保持增长。如果转发表中不存在(S,G)表项或(S,G)表项对应的“Matched packets”字段值是否停止增长,则表示上游设备转发给此设备的组播数据不正常。此时,需要判断当前设备是否为组播源侧DR:

-     如果不是,则表示当前设备没有收到组播数据,故障可能出在上游设备,请检查上游设备的PIM路由表中是否存在正确的(S,G)表项。如果上游设备的PIM路由表中存在正确的(S,G)表项,但是“Matched packets”统计的组播报文数量停止增长,请执行步骤(9)

-     如果是,则表示SPT已成功建立,但由于某种原因导致组播源侧DR未沿着SPT转发组播数据,请执行步骤(9)

¡     如果PIM路由表中不存在正确的(S,G)表项,请执行步骤(2)

(2)     检查连接下游设备的接口是否收到PIM加入报文。

联系技术支持,在专业人士的指导下使用抓包工具(例如Wireshark)在设备连接下游设备的接口上进行抓包,查看连接下游设备接口是否收到PIM加入/剪枝报文。

¡     如果没有收到PIM加入/剪枝报文,则在下游设备连接本设备的接口上,使用抓包工具(例如Wireshark)进行抓包,查看是否发送PIM加入/剪枝报文给本设备。如果下游设备没有发送PIM加入/剪枝报文,则表示下游设备存在问题,请排查下游设备故障。如果下游设备已经发送PIM加入/剪枝报文,但是本设备没有收到,则表示与本设备之间PIM邻居通信有问题,请执行步骤(9)

¡     如果连接下游设备接口收到了PIM加入/剪枝报文,请执行步骤(3)

(3)     检查接口是否开启PIM-SM。

在当前设备上执行display pim interface verbose命令,查看接口上的PIM信息。

a.     重点查看到达组播源的RPF邻居接口、到达组播源的RPF接口和直连用户主机网段的接口(接收者侧DR的下游接口)上的PIM相关配置信息。如果这些接口上没有开启PIM-SM,请通过pim sm命令开启。同时,检查确保设备上已使能IP组播路由(通过multicast routing命令配置)且PIM邻居建立成功(通过display pim neighbor命令查看)。

b.     如果设备上述重点查看的接口都开启了PIM-SM,但问题依然存在,请执行步骤(4)

(4)     检查是否存在到达组播源的RPF路由。

在设备上执行display multicast rpf-info命令,查看是否存在到达组播源的RPF路由。

¡     如果不存在,检查单播路由配置。请在当前设备和组播源上分别执行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路由存在且配置合理,请执行步骤(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命令配置)。

¡     如果已配置,继续确认接收到的组播数据是否在过滤器指定的允许范围之内。如果不在,建议根据实际组网需要执行undo source-policy命令删除该配置或重新配置ACL规则,确保用户需要的组播数据正常转发。

¡     如果未配置,请执行步骤(8)

(8)     再次检查PIM路由表是否存在正确的(S,G)表项。

在设备上再次执行display pim routing-table命令,查看PIM路由表中是否存在(S,G)表项。具体方法请参见步骤(1)

(9)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

5. 告警与日志

相关告警

相关日志

9.4.4  PIM-SM网络中RPT无法正常转发数据

1. 故障描述

PIM-SM网络中RPT无法正常转发数据,组播流量不通。

2. 常见原因

本类故障的常见原因主要包括:

·     PIM-SM域内组播设备到RP的单播路由不通。

·     PIM-SM域内各组播设备上为某一组播组服务配置的RP地址不一致。

·     PIM-SM域内组播设备的下游接口没有收到PIM加入报文。

·     PIM-SM域内组播设备上的接口没有开启PIM-SM。

·     PIM-SM域内组播设备到RP的RPF路由不正确。

·     配置不正确(比如组播转发边界配置不正确、组播数据过滤器配置不正确等)。

3. 故障分析

本类故障的诊断流程如图9-8所示。

图9-8 PIM-SM网络中RPT无法正常转发数据故障诊断流程图

 

4. 处理步骤

(1)     检查PIM路由表中是否存在正确的(*,G)表项。

在设备上执行display pim routing-table命令,查看PIM路由表中是否存在正确的(*,G)表项。请检查下游接口列表中,是否包含到达所有连接(*,G)组成员的下游接口。

¡     如果PIM路由表中的(*,G)表项存在且信息完全正确,则建议每隔15秒执行一次display multicast forwarding-table命令,查看组播转发表中是否存在与(*,G)表项相同组播组的(S,G)表项,同时查看(S,G)表项匹配的报文数量是否保持增长。如果转发表中不存在(S,G)表项或(S,G)表项匹配的报文数量停止增长,则表示上游设备转发给此设备的组播数据不正常。此时,需要判断当前设备是否为RP:

-     如果不是,则表示当前设备没有收到组播数据,故障可能出在上游设备,请检查上游设备的PIM路由表中是否存在正确的(S,G)表项。

-     如果是,则表示RPT已成功建立,但由于某种原因(例如源DR没有注册成功)导致RP未收到组播源发出的组播数据。此时,需要寻求技术支持排除故障。

¡     如果PIM路由表中不存在正确的(*,G)表项,请执行步骤(2)

(2)     检查连接下游设备的接口是否收到PIM加入报文。

联系技术支持,在专业人士的指导下使用抓包工具(例如Wireshark)在设备连接下游设备的接口上进行抓包,查看连接下游设备接口是否收到PIM加入/剪枝报文。

¡     如果没有收到PIM加入/剪枝报文,则在下游设备连接本设备的接口上,使用抓包工具(例如Wireshark)进行抓包,查看是否发送PIM加入/剪枝报文给本设备。如果下游设备没有发送PIM加入/剪枝报文,则表示下游设备存在问题,请排查下游设备故障。如果下游设备已经发送PIM加入/剪枝报文,但是本设备没有收到,则表示与本设备之间PIM邻居通信有问题,请执行步骤(10)

¡     如果连接下游设备接口收到了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)

¡     如果一致,请执行步骤9.4.2  4. (6)

(5)     检查是否存在到达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路由存在且配置合理,请执行步骤(6)

(6)     检查转发组播数据的接口对应的DR是否为接收者侧DR。

在设备上执行display pim interface命令,查看转发组播数据的接口对应的DR是否为接收者侧DR。判断方法为查看显示信息中DR-Address字段是否携带local标记,如果携带,则为接收者侧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命令配置)。

¡     如果已配置,继续确认接收到的组播数据是否在过滤器指定的允许范围之内。如果不在,建议根据实际组网需要执行undo source-policy命令删除该配置或重新配置ACL规则,确保用户需要的组播数据正常转发。

¡     如果未配置,请执行步骤(9)

(9)     再次检查PIM路由表是否存在正确的(*,G)表项。

在设备上再次执行display pim routing-table命令,查看PIM路由表中是否存在(*,G)表项。具体方法请参见步骤(1)

(10)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

5. 告警与日志

相关告警

相关日志


10 MPLS故障处理

10.1  MPLS基础类故障处理

10.1.1  报文通过LSP隧道转发不通

1. 故障描述

网络中主机的发送报文,通过LSP隧道转发不通。

2. 常见原因

本类故障的常见原因主要包括:

·     路由不存在。

·     LSP不存在。

·     路由未迭代到LSP隧道上。

·     LSP隧道的转发状态非ACTIVE。

·     BFD会话状态为Down。

·     CPU利用率过高。

3. 故障分析

本类故障的诊断流程如图10-1示。

图10-1 报文通过LSP隧道转发不通的故障诊断流程图

 

4. 处理步骤

(1)     检查IGP路由是否存在。

执行display ip routing-table命令,查看是否存在到达目的节点的Loopback接口地址的网段路由:

<Sysname> display ip routing-table 1.1.1.1

 

Summary count : 1

 

Destination/Mask   Proto   Pre Cost        NextHop         Interface

1.1.1.2/32         IS_L1   15  10          1.1.1.1         LoopBack1

¡     如果不存在,则在Loopback接口和公网接口下使能IGP协议,确保发布对应网段路由。

¡     如果存在,则执行步骤(2)。

(2)     检查LSP是否存在。

执行display mpls lsp命令,查看是否存在到达目的节点的Loopback接口的LSP

¡     如果不存在,则确保建立指定类型的LSP

-     对于LDP LSP,请在接口下使能MPLS功能和MPLS LDP功能。

-     对于SRLSP,请在IS-IS IPv4单播地址族视图、OSPF视图或BGP IPv4单播地址族视图下执行segment-routing mpls命令用来开启基于MPLSSR功能。

-     对于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. 告警与日志

相关告警

相关日志

10.1.2  MPLS VPN转发故障

1. 故障描述

MPLS常见的组网如图10-2所示。MPLS VPN转发故障时,CE1与CE2之间报文发送接收错误。

图10-2 MPLS组网图

 

2. 故障处理步骤

L2VPN、VPLS、L3VPN是基于LSP建立的。在LSP入节点(图10-2中的PE1)上通过下列方式来检查、确认MPLS网络中哪台设备存在配置错误。

(1)     检查配置的LSP是否存在,如不存在,请检查MPLS LSP配置是否正确。

[PE1] display mpls lsp

FEC                         Proto    In/Out Label    Interface/Out NHLFE

100.100.100.100/32          LDP      3/-             -

4.4.4.4/32                  LDP      NULL/3          GE3/0/1

90.0.0.0/24                 LDP      NULL/3          GE3/0/1

1.1.1.1/32                  LDP      3/NULL          InLoop0

50.0.0.0/24                 LDP      NULL/3          GE3/0/1

70.0.0.0/24                 LDP      NULL/3          GE3/0/1

3.3.3.3/32                  LDP      NULL/1025       GE3/0/1

(2)     检查MPLS LDP会话,如果状态不是Operational,说明会话存在错误,请转步骤(3)、(4);如果MPLS LDP会话正常,请转步骤(5)。

[PE1] display mpls ldp peer

Total number of peers: 1

Peer LDP ID             State         Role     GR   MD5  KA Sent/Rcvd

4.4.4.4:0               Operational   Passive  Off  Off  39/39

 

(3)     通过display mpls ldp interface命令查看LDP接口的相关信息。如配置信息不正确,请检查MPLS LDP配置。

[PE1] display mpls ldp interface

Interface                 MPLS         LDP             Auto-config

Vlan103                   Enabled      Configured      -

GE3/0/2                   Enabled      Configured      -

XGE2/0/6                  Enabled      Configured      -

(4)     检查接口下是否使能MPLS、MPLS LDP。如未使能,请使能MPLS和MPLS LDP。建立LSP的所有接口上均需要使能MPLS和MPLS LDP。

[PE1] interface gigabitethernet 3/0/1

[PE1-GigabitEthernet3/0/1] display this

#

interface GigabitEthernet3/0/1

 ip address 1.1.1.2 255.255.255.0

 mpls enable

 mpls ldp enable

#

return

(5)     检查配置的mpls lsr-id是不是等于Loopback接口IP地址。推荐使用设备上某个Loopback接口的地址作为LSR ID。

<PE1> display current-configuration | include lsr-id

 mpls lsr-id 2.2.2.2

<PE1> display ip interface brief

*down: administratively down

(s): spoofing

Interface                    Physical Protocol IP Address      Description

Loop0                        up       up(s)    100.100.100.100 LoopBack0..

Loop2                        up       up(s)    100.100.100.102 LoopBack2..

M-E0/0/0                     up       up       192.168.147.7   M-Etherne..

<PE1> system-view

[PE1] mpls lsr-id 100.100.100.100

(6)     检查路由表中PE1、P、PE2的环回口IP及远端VLAN接口的IP表项是否存在,如不存在,请检查路由协议配置。

[PE1] display ip routing-table

         Destinations : 10       Routes : 10

 

Destination/Mask    Proto  Pre  Cost         NextHop         Interface

 

1.1.1.1/32          Direct  0    0            127.0.0.1       InLoop0

3.3.3.3/32          O_INTER 10   2            103.0.0.4       GE3/0/1

4.4.4.4/32          O_INTER 10   1            103.0.0.4       GE3/0/1

50.0.0.0/24         O_INTER 10   2            103.0.0.4       GE3/0/1

70.0.0.0/24         O_INTER 10   2            103.0.0.4       GE3/0/1

90.0.0.0/24         O_INTER 10   2            103.0.0.4       GE3/0/1

103.0.0.0/24        Direct  0    0            103.0.0.1       GE3/0/1

103.0.0.1/32        Direct  0    0            127.0.0.1       InLoop0

127.0.0.0/8         Direct  0    0            127.0.0.1       InLoop0

127.0.0.1/32        Direct  0    0            127.0.0.1       InLoop0

(7)     检查路由协议状态是否正常(下面以查看OSPF协议状态为例),如不正常,请检查路由协议配置。

[PE1] display ospf peer

 

                   OSPF Process 1 with Router ID 1.1.1.1

                        Neighbor Brief Information

 

 Area: 0.0.0.0

 Router ID       Address         Pri Dead-Time Interface       State

 4.4.4.4         103.0.0.4       1   37        Vlan103         Full/BDR

(8)     检查协议中环回口、VLAN接口的路由是否被通告,如不正确,请添加配置。

[PE1-ospf-1] display this

#

ospf 1

 area 0.0.0.0

  network 103.0.0.0 0.0.0.255

  network 1.1.1.1 0.0.0.0

#

return

(9)     如仍不正常,请检查本端、对端设备的路由协议配置。

(10)     如仍无法确认,请将故障信息发送技术支持人员分析。

10.2  LDP故障处理

10.2.1  LDP会话震荡

1. 故障描述

LDP会话状态频繁震荡。

2. 常见原因

本类故障的常见原因主要包括:

·     接口震荡

·     路由震荡

·     CPU利用率过高

3. 故障分析

本类故障的诊断流程如图10-3所示。

图10-3 LDP会话震荡的故障诊断流程图

 

4. 处理步骤

(1)     检查接口是否震荡。

执行display interface brief命令,查看Physical和Protocol字段。Physical和Protocol字段均显示Up,则表示接口状态为Up,否则表示接口状态为Down。若接口一直在Up和Down两种状态间切换,则表示接口震荡。

¡     如果接口震荡,则排除接口问题。

¡     如果接口没有震荡,请执行步骤(2)。

(2)     检查路由是否震荡。

执行display ip routing-table命令,查看路由信息。如果路由信息一直在显示和不显示两种情况切换,则表示路由震荡。

¡     如果路由震荡,或者路由一直不存在,则排除链路问题和排除IGP路由问题。

¡     如果路由没有震荡,则执行步骤(3)。

(3)     TCP报文是否过大。

执行display tcp statistics命令,查看TCP连接的流量统计信息。通过Sent packets信息中data packets retransmitted(重发的数据报文数)字段的值,判断TCP报文是否过大:

¡     如果重发的数据报文数不断增加,则表示TCP报文过大,请在报文出接口下执行tcp mss命令调整TCP MSS值。

¡     如果重发的数据报文数未增加,则表示TCP报文大小正常,请执行步骤(4)。

(4)     检查CPU利用率是否过高。

执行display cpu-usage命令,查看CPU利用率的统计信息。

¡     如果CPU利用率过高,则关闭一些不必要的功能,降低设备CPU利用率。

¡     如果CPU利用率正常,则执行步骤(5)。

(5)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

5. 告警与日志

相关告警

模块名:MPLS-LDP-STD-MIB

·     mplsLdpSessionDown (1.3.6.1.2.1.10.166.4.0.4)

相关日志

·     LDP/4/LDP_SESSION_CHG

10.2.2  LDP会话无法Up

1. 故障描述

LDP会话无法Up。

2. 常见原因

本类故障的常见原因主要包括:

·     建立会话的接口处于Down状态

·     LSR ID配置错误

·     不存在LDP会话的相关配置

·     传输地址配置错误

·     LDP Hello-hold定时器超时

·     LDP Keepalive-hold定时器超时

·     安全认证配置错误

3. 故障分析

本类故障的诊断流程如图10-4示。

图10-4 LDP会话Down的故障诊断流程图

 

4. 处理步骤

(1)     检查建立LDP会话的接口是否处于Up状态。

执行display interface命令查看接口是否处于UP状态:

¡     如果没有UP,则排除接口物理链路故障,使接口处于UP状态。

¡     如果接口处于UP状态,则执行步骤(2)。

(2)     检查LSR ID配置是否正确。

LSR ID包括Local LSR ID、LDP LSR ID和MPLS LSR ID。LSR ID优先级从高到底依次为Local LSR ID、LDP LSR ID、MPLS LSR ID。设备上至少配置其中的一种LSR ID,且该LSR ID必须路由可达。

执行display mpls ldp peer verbose命令检查是否配置了LSR ID:

<Sysname> display mpls ldp peer verbose

VPN instance: public instance

 Peer LDP ID      : 100.100.100.20:0

 Local LDP ID     : 100.100.100.17:0

 TCP Connection   : 100.100.100.20:47515 -> 100.100.100.17:646

如果执行display mpls ldp peer verbose命令时无显示,则通过以下方法配置LSR ID:

¡     在系统视图下配置MPLS LSR ID。

请在系统视图下执行mpls lsr-id命令。

¡     在LDP视图下配置LDP LSR ID。

请在LDP视图下执行lsr-id命令。

¡     如果是直连会话,在接口视图下配置Local LSR ID。

请在接口视图下执行mpls ldp local-lsr-id命令。

¡     如果是远程会话,在LDP对等体视图下配置Local LSR ID。

请在LDP对等体下执行mpls ldp local-lsr-id interface命令。

如果至少配置了一种LSR ID,则执行步骤(3)。

(3)     检查是否存在LDP会话的相关配置。

如果是直连会话,则在接口视图下执行display this命令,查看是否存在LDP会话的相关配置。

a.     如果配置信息中没有包含mpls enable命令、mpls ldp enable命令、mpls ldp ipv6 enable命令或mpls ldp transport-address命令,则部署对应的配置。

b.     如果存在LDP会话的相关配置,则执行步骤(4)。

如果是LDP远程会话,则在LDP视图下执行display this命令,查看是否存在LDP会话的相关配置。

c.     如果配置信息中没有包含targeted-peermpls 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. 告警与日志

相关告警

模块名:MPLS-LDP-STD-MIB

·     mplsLdpSessionDown (1.3.6.1.2.1.10.166.4.0.4)

相关日志

·     LDP/4/LDP_SESSION_CHG

10.2.3  LDP LSP震荡

1. 故障描述

LDP网络中LDP LSP频繁震荡。

2. 常见原因

本类故障的常见原因主要包括:

·     路由震荡。

·     LDP会话震荡。

3. 故障分析

本类故障的诊断思路如下:

(1)     检查路由是否震荡。

(2)     检查LDP会话是否震荡。

本类故障的诊断流程如图10-5所示。

图10-5 LDP LSP震荡的故障诊断流程图

 

4. 处理步骤

(1)     检查路由是否震荡。

建议每1秒执行一次display ip routing-table命令,连续执行5~10次,查看到达LSP目的地址的路由信息。路由存在时,会显示相关路由信息。路由不存在时,则不会显示相关路由信息。如果相关路由信息一直在显示和不显示两种情况切换,则表示路由震荡。

查看路由信息后,请执行display mpls ldp fec命令查看LSP下游信息,即Downstream Info中的State字段,确保与下游对等体建立的LSP处于激活状态(Established)。

<Sysname> display mpls ldp fec

VPN instance: public instance

 FEC: 1.1.1.1/32

   Flags: 0x112

   In Label: 2175

   Upstream Info:

     Peer: 1.1.1.1:0               State: Established

   Downstream Info:

     Peer: 1.1.1.1:0

       Out Label: 3                State: Established

       Next Hops: 10.1.1.1                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会话震荡,则请参见“10.2.1  LDP会话震荡”故障进行定位。

¡     如果LDP会话没有震荡,则执行步骤(3)。

(3)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

5. 告警与日志

相关告警

模块名:MPLS-LSR-STD-MIB

·     节点名称 (OID) mplsXCDown (1.3.6.1.2.1.10.166.2.0.2)

相关日志

10.2.4  LDP LSP无法Up

1. 故障描述

LDP网络中LDP LSP无法Up。

2. 常见原因

本类故障的常见原因主要包括:

·     路由问题

·     LDP会话Down

·     资源不足,如Label达到上限,内存不足等

·     配置了LSP触发策略、标签接受控制策略、标签通告控制策略或Label Mapping消息的发送策略

·     路由的出接口与LDP建立会话的接口不一致

3. 故障分析

本类故障的诊断思路如下:

(1)     检查路由是否存在。

(2)     检查LDP会话是否正常建立。

(3)     检查是否存在资源不足,入Label达到上限,内存不足的问题。

(4)     检查是否配置了LSP建立策略。

(5)     检查路由的出接口与LDP建立会话的接口是否一致。

本类故障的诊断流程如图10-6所示。

图10-6 LDP LSP Down的故障诊断流程图

 

4. 处理步骤

(1)     检查路由是否存在。

执行display ip routing-table ip-address mask verbose命令,查看是否存在到达指定LSP目的地址的路由,并检查该路由是否处于激活状态(路由信息中的State字段为Active Adv,表示路由处于激活状态)。对于公网BGP路由,还需要检查路由是否带标签。如果Label字段非NULL,则表示BGP路由携带标签。路由存在时,会显示相关路由信息。路由不存在时,则不会显示相关路由信息。

<Sysname> display ip routing-table 1.1.1.1 32 verbose

 

Summary count : 1

 

 Destination: 1.1.1.1/32

    Protocol: O_INTRA

  Process ID: 1

   SubProtID: 0x1                       Age: 00h00m16s

  FlushedAge: 00h00m16s

        Cost: 1                  Preference: 10

       IpPre: N/A                QosLocalID: N/A

         Tag: 0                       State: Active Adv

   OrigTblID: 0x0                   OrigVrf: default-vrf

¡     如果路由不存在、路由存在但未处于激活状态或者BGP路由未携带标签,则请排除路由故障。

¡     如果路由存在且处于激活状态,对于BGP路由也带标签,则执行步骤(2)。

(2)     检查LDP会话是否正常建立。

执行display mpls ldp peer verbose命令,查看LDP会话是否成功建立:

<Sysname> display mpls ldp peer verbose

VPN instance: public instance

 Peer LDP ID      : 1.1.1.1:0

 Local LDP ID     : 2.2.2.2:0

 TCP Connection   : 2.2.2.2:14080 -> 1.1.1.1:646

 Session State    : Operational        Session Role     : Active

 Session Up Time  : 0000:00:14 (DD:HH:MM)

¡     如果State字段显示不是Operational,则表示LDP会话没有正常建立,请参见“10.2.2  LDP会话无法Up”故障进行定位。

¡     如果State字段的显示为Operational,则表示LDP会话已建立并处于Up状态,请执行步骤(3)。

(3)     检查是否配置了LSP策略。

¡     在LDP视图下执行display this命令,如果存在以下命令,则需要检查IP前缀列表是否过滤了指定的LSP:

-     lsp-trigger prefix-list

-     accept-label peer prefix-list

-     advertise-label prefix-list

-     propagate mapping prefix-list

如果IP前缀列表过滤了指定的LSP,则请修改IP前缀列表,使其允许指定LSP目的地址通过;如果IP前缀列表没有过滤指定的LSP,则执行步骤(4)。

¡     如果LDP视图下没有配置以上命令,则执行步骤(4)。

(4)     检查路由的出接口与LDP建立会话的接口是否一致。

执行display ip routing-table ip-address mask命令,查看指定路由的出接口信息:

<Sysname> display ip routing-table 1.1.1.1 32

 

Summary count : 1

 

Destination/Mask   Proto   Pre Cost        NextHop         Interface

1.1.1.1/32         O_INTRA 10  1           10.1.1.1        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. 告警与日志

相关告警

模块名:MPLS-LSR-STD-MIB

·     节点名称 (OID) mplsXCDown (1.3.6.1.2.1.10.166.2.0.2)

相关日志

 

10.3  MPLS L2VPN/VPLS通用故障处理

10.3.1  PW ping不通

1. 故障描述

执行ping mpls pw命令检测PW连通性,发现ping不通对端。

2. 常见原因

本类故障的常见原因主要包括:

·     检测的PW不存在。

·     PW模板配置错误。

·     PW故障。

·     PW不存在有效的公网转发路径。

3. 故障分析

本类故障需要根据ping mpls pw命令的回显信息进行分析和定位,具体诊断思路如下:

·     回显信息为Unknown PW时,表示检测的PW不存在,需要修改配置来解决本类故障。

·     回显信息为No suitable control channel for the PW时,表示PW的VCCV控制通道类型配置错误,需要通过vccv cc命令修改PW模板中VCCV控制通道类型来解决本类故障。

·     回显信息为Please configure pseudowire control-word for control channel时,表示PW引用的PW模板中未开启控制字功能,需要通过control-word enable命令在PW模板下开启控制字功能来解决本类故障。

·     回显信息为Request time out时,先排查本端PW是否Up,再通过tracert mpls pw命令来定位故障节点。

本类故障的诊断流程如图10-7所示。

图10-7 PW ping不通的故障诊断流程图

 

4. 处理步骤

回显信息为Unknown PW时,本类故障的处理步骤为:修改配置确保检测的PW存在。

回显信息为No suitable control channel for the PW时,本类故障的处理步骤为:通过vccv cc命令将PW两端的VCCV控制通道类型配置一致。

回显信息为Please configure pseudowire control-word for control channel时,本类故障的处理步骤为:通过control-word enable命令在PW模板下开启控制字功能。

回显信息为Request time out时,本类故障的处理步骤如下:

(1)     执行display l2vpn pw命令查看PW是否Up。

<Sysname> display l2vpn pw

Flags: M - main, B - backup, E - ecmp, BY - bypass, H - hub link, S - spoke link

       N - no split horizon, A - administration, ABY - ac-bypass

       PBY - pw-bypass

Total number of PWs: 2

2 up, 0 blocked, 0 down, 0 defect, 0 idle, 0 duplicate

 

Xconnect-group Name: ldp

Peer            PWID/RmtSite/SrvID In/Out Label   Proto  Flag Link ID  State

192.3.3.3       500                1299/1299      LDP    M    0        Up

 

VSI Name: aaa

Peer            PWID/RmtSite/SrvID In/Out Label   Proto  Flag Link ID  State

2.2.2.9         2                  1420/1419      BGP    M    9        Up

¡     若PW为Down状态,请通过display l2vpn pw verbose命令查看PW状态变为Down的原因,并根据故障原因进行故障处理。

<Sysname> display l2vpn pw verbose

VSI Name: aaa

  Peer: 2.2.2.9          Remote Site: 2

    Signaling Protocol  : BGP

    Link ID             : 9          PW State : Down

    In Label            : 1420       Out Label: 1419

    MTU                 : 1500

    PW Attributes       : Main

    VCCV CC             : -

    VCCV BFD            : -

    Flow Label          : Send

    Control Word        : Disabled

    Tunnel Group ID     : 0x800000960000000

    Tunnel NHLFE IDs    : 1038

    Admin PW            : -

    E-Tree Mode         : -

    E-Tree Role         : root

    Root VLAN           : -

    Leaf VLAN           : -

    Down Reasons        : Control word not match

常见的故障原因及处理方法如下:

-     BFD session for PW down:用来检测PW的BFD会话状态为down,此类故障的处理方式为,通过display bfd session命令查看BFD状态为down的原因,检查并修改BFD配置或检查物理链路是否存在链路故障、链路质量问题。

-     BGP RD was deleted:BGP的RD被删除,此类故障的处理方式为,在交叉连接组自动发现视图下配置route-distinguisher route-distinguisher命令。

-     BGP RD was empty:未配置BGP的RD,此类故障的处理方式为,在交叉连接组自动发现视图下配置route-distinguisher route-distinguisher命令。

-     Control word not match:PW两端控制字功能配置不一致,此类故障的处理方式为,将PW两端引用的PW模板下的控制字功能(通过control-word enable命令开启)配置一致。

-     Encapsulation not match:PW两端封装类型不一致,此类故障的处理方式为,将PW两端引用的PW模板下的PW数据封装类型(通过pw-type命令配置)配置一致。

-     LDP interface parameter not match:PW两端接口LDP协商参数不一致,此类故障的处理方式为,将PW两端引用的PW模板下的VCCV控制通道类型(通过vccv cc命令配置)配置一致或将PW两端关联的电路仿真接口下引用的电路仿真类中的配置保持一致。

-     Non-existent remote LDP PW:对端设备已删除LDP PW,此类故障的处理方式为,在对端设备上重新配置PW。

-     Local AC Down:本地AC状态为down,此类故障的处理方式为,检查并修改AC接口上的配置或排除AC所在的接口的故障,保障接口为Up状态。

-     Local AC was non-existent:未配置本地AC,此类故障的处理方式为,配置本地的AC并关联VSI。

-     MTU not match:PW两端MTU不一致,此类故障的处理方式为,将PW两端的MTU配置一致或者通过mtu-negotiate disable命令关闭PW MTU协商功能。

-     Remote AC Down:对端AC状态down,此类故障的处理方式为,检查并修改对端AC接口上的配置或排除AC所在的接口的故障,保障接口为Up状态。

¡     若PW为Up状态,请继续执行第(2)步。

(2)     执行display l2vpn forwarding pw verbose命令,查看PW的转发信息中入标签(In Label)、出标签(Out Label)和承载PW的隧道对应的NHLFE表项索引值(Tunnel NHLFE IDs)是否为有效值。

<Sysname> display l2vpn forwarding pw verbose

Xconnect-group Name: xcg1

 Connection Name: c1

  Link ID: 0

    PW Type           : VLAN                  PW State : Up

    In Label          : 110126                Out Label: 130126

    MTU               : 1500

    PW Attributes     : Main

    VCCV CC           : Router-Alert

    VCCV BFD          : Fault Detection with BFD

    Flow Label        : -

    Tunnel Group ID   : 0x800000130000001

    Tunnel NHLFE IDs  : 3

VSI Name: aaa

  Link ID: 8

    PW Type         : VLAN                  PW State : Up

    In Label        : 1272                  Out Label: 1275

    MTU             : 1500

    PW Attributes   : Main

    VCCV CC         : -

    VCCV BFD        : Fault Detection with BFD

    Flow Label      : -

    Tunnel Group ID : 0x960000000

    Tunnel NHLFE IDs: 1034

¡     若入、出标签取值为空或者为“-”。请先执行display l2vpn pw verbose命令查看PW使用的信令协议(Signaling Protocol),再修改建立PW的信令协议相关配置是否正确:

-     若信令协议为BGP,则需要检查并修改BGP相关配置;

-     若信令协议为LDP,则需要检查并修改LDP相关配置;

-     若信令协议为Static,则需要检查并修改静态PW配置。

有关PW信令协议相关配置的详细介绍,请参见产品手册的“MPLS配置指导”中的“MPLS L2VPN”和“VPLS”。

¡     若Tunnel NHLFE IDs取值为空,请继续执行第(3)步。

¡     若PW的转发信息正常,请继续执行第(4)步。

(3)     执行display mpls lsp命令,查看是否存在承载PW的隧道,即是否存在FEC为PW对端IP地址的LSP,若不存在,则需要先完成承载PW的隧道的建立。

<Sysname> display mpls lsp

FEC                         Proto    In/Out Label    Out Inter/NHLFE/LSINDEX

100.100.100.100/24          LDP      -/1049          GE3/1/1

(4)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

¡     使用display diagnostic-information命令收集诊断信息。

5. 告警与日志

相关告警

无。

相关日志

·     L2VPN/2/L2VPN_PWSTATE_CHANGE

·     L2VPN/4/L2VPN_BGPVC_CONFLICT_LOCAL

·     L2VPN/4/L2VPN_BGPVC_CONFLICT_REMOTE

·     L2VPN/4/L2VPN_HARD_RESOURCE_NOENOUGH

·     L2VPN/2/L2VPN_HARD_RESOURCE_RESTORE

·     L2VPN/4/L2VPN_LABEL_DUPLICATE

10.4  VPLS故障处理

10.4.1  VPLS的VSI不能up

1. 故障描述

执行display l2vpn vsi verbose命令,查看对应VSI的状态不是up的状态。

<Sysname> display l2vpn vsi verbose

VSI Name: vpls1

  VSI Index               : 0

  VSI Description         : vsi for vpls1

  VSI State               : Up

  MTU                     : 1500

  Diffserv Mode           : -

  Bandwidth               : Unlimited

  Broadcast Restrain      : 5120 kbps

  Multicast Restrain      : 5120 kbps

  Unknown Unicast Restrain: 5120 kbps

  MAC Learning            : Enabled

  MAC Table Limit         : Unlimited

  MAC Learning rate       : Unlimited

  Drop Unknown            : Disabled

  PW Redundancy Mode      : Independent

  Flooding                : Enabled

  Statistics              : Disabled

  VXLAN ID                : -

  LDP PWs:

    Peer            PW ID            Link ID    State

    192.3.3.3       1                8          Up

    192.3.3.3       1001             8          Blocked

  BGP PWs:

    Peer            Remote Site      Link ID    State

    192.4.4.4       1                9          Up

  ACs:

    AC                               Link ID    State

    GE3/1/1                          1          Up

2. 故障诊断流程

图10-8 故障诊断流程图

 

3. 故障处理步骤

(1)     检查两端的封装类型/MTU是否一致

执行display l2vpn ldp verbose命令,查看两端的封装类型/MTU是否一致。

¡     如果两端的封装类型不一致,在PW模板视图下,配置pw-type命令修改其中一端的封装类型,使两端的封装类型一致。

¡     如果两端的MTU不一致,在VSI视图下,配置mtu命令修改其中一端的MTU,使两端的MTU一致。

<Sysname> display l2vpn ldp verbose

Peer: 2.2.2.9          PW ID: 500

  VSI Name: ccc

  PW State: Up

  PW Status Communication: Notification method

  PW Preferential Forwarding Status Bit: Process

  PW ID FEC (Local/Remote):

    PW Type     : VLAN/VLAN

    Group ID    : 0/0

    Label       : 1552/1552

    Control Word: Disabled/Disabled

    VCCV CV Type: -/-

    VCCV CC Type: -/-

    Flow Label  : Send/Recv

    MTU         : 1500/1500

    PW Status   : PW forwarding/PW forwarding

(2)     检查两端的PW-ID是否一致

如果两端的PW-ID不一致,在VSI LDP信令视图下,配置peer命令修改pw-id参数,使两端一致。

(3)     隧道策略选取是否正确

查看隧道策略配置,确认隧道策略选取的隧道类型,并通过display mpls forwarding nhlfe命令查看该类型的隧道是否存在且up,若不存在,请建立该类型的隧道。

(4)     检查两端的AC接口状态是否Up

执行display interface brief命令,查看接口信息,确保接口状态为up。

(5)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

10.4.2  PW两端的PE设备中只有一个PE上的VSI处于Up状态

1. 故障描述

PW两端的PE设备中只有一个PE上的VSI处于Up状态。

2. 常见原因

VSI up的条件为:

·     VSI下至少有一个PW Up和一个AC up。

·     VSI下至少有两个AC Up。

因此本类故障的常见原因为:Up的VSI上虽然PW down,但是存在两个Up的AC;Down的VSI上PW down,且无两个Up的AC。

3. 故障分析

本类故障的诊断思路为:检查状态为Down的VSI下的AC和PW的状态。

4. 处理步骤

(1)     执行display l2vpn vsi命令,查看VSI下AC和PW的状态。

<Sysname> display l2vpn vsi verbose

VSI Name: vpls1

  VSI Index               : 0

  VSI Description         : vsi for vpls1

  VSI State               : Down

  MTU                     : 1500

  Bandwidth               : -

  Broadcast Restrain      : -

  Multicast Restrain      : -

  Unknown Unicast Restrain: -

  MAC Learning            : Enabled

  MAC Table Limit         : -

  MAC Learning rate       : -

  Drop Unknown            : -

  PW Redundancy           : Master

  Flooding                : Enabled

  Statistics              : Disabled

  VXLAN ID                : -

  LDP PWs:

    Peer            PW ID            Link ID    State

    192.3.3.3       1                8          Down

  ACs:

    AC                               Link ID    State       Type

    GE3/1/3 srv1                     1          Up          Manual

(2)     执行display l2vpn pw verbose命令,查看PW状态变为Down的原因。

<Sysname> display l2vpn pw verbose

VSI Name: aaa

  Peer: 2.2.2.9          Remote Site: 2

    Signaling Protocol  : BGP

    Link ID             : 9          PW State : Down

    In Label            : 1420       Out Label: 1419

    MTU                 : 1500

    PW Attributes       : Main

    VCCV CC             : -

    VCCV BFD            : -

    Flow Label          : Send

    Control Word        : Disabled

    Tunnel Group ID     : 0x800000960000000

    Tunnel NHLFE IDs    : 1038

    Admin PW            : -

    E-Tree Mode         : -

    E-Tree Role         : root

    Root VLAN           : -

    Leaf VLAN           : -

    Down Reasons        : Control word not match

常见的故障原因及处理方法如下:

¡     BFD session for PW down:用来检测PW的BFD会话状态为down,此类故障的处理方式为,通过display bfd session命令查看BFD状态为down的原因,检查并修改BFD配置或检查物理链路是否存在链路故障、链路质量问题。

¡     BGP RD was deleted:BGP的RD被删除,此类故障的处理方式为,在交叉连接组自动发现视图下配置route-distinguisher route-distinguisher命令。

¡     BGP RD was empty:未配置BGP的RD,此类故障的处理方式为,在交叉连接组自动发现视图下配置route-distinguisher route-distinguisher命令。

¡     Control word not match:PW两端控制字功能配置不一致,此类故障的处理方式为,将PW两端引用的PW模板下的控制字功能(通过control-word enable命令开启)配置一致。

¡     Encapsulation not match:PW两端封装类型不一致,此类故障的处理方式为,将PW两端引用的PW模板下的PW数据封装类型(通过pw-type命令配置)配置一致。

¡     LDP interface parameter not match:PW两端接口LDP协商参数不一致,此类故障的处理方式为,将PW两端引用的PW模板下的VCCV控制通道类型(通过vccv cc命令配置)配置一致或将PW两端关联的电路仿真接口下引用的电路仿真类中的配置保持一致。

¡     Non-existent remote LDP PW:对端设备已删除LDP PW,此类故障的处理方式为,在对端设备上重新配置PW。

¡     Local AC Down:本地AC状态为down,此类故障的处理方式为,检查并修改AC接口上的配置或排除AC所在的接口的故障,保障接口为Up状态。

¡     Local AC was non-existent:未配置本地AC,此类故障的处理方式为,配置本地的AC并关联VSI。

¡     MTU not match:PW两端MTU不一致,此类故障的处理方式为,将PW两端的MTU配置一致或者通过mtu-negotiate disable命令关闭PW MTU协商功能。

¡     Remote AC Down:对端AC状态down,此类故障的处理方式为,检查并修改对端AC接口上的配置或排除AC所在的接口的故障,保障接口为Up状态。

(3)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

¡     使用display diagnostic-information命令收集诊断信息。

5. 告警与日志

相关告警

相关日志

·     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

10.4.3  VPLS业务不通

1. 故障描述

VPLS业务流量转发不通。

2. 常见原因

本类故障的常见原因主要包括:

·     AC没有Up

·     PW没有Up。

·     PW没有生成转发信息。

·     PW没有可迭代的公网隧道。

·     PW迭代的公网隧道异常。

3. 故障分析

本类故障的诊断思路如下:

(1)     查看VSI详细信息,确认VSI下至少关联了一个AC和一个PW

(2)     检查AC状态是否Up。

(3)     检查PW状态是否Up。

(4)     检查PW转发信息。

(5)     检查PW迭代的公网隧道信息。

本类故障的诊断流程如图10-9所示。

图10-9 VPLS业务不通的故障诊断流程图

 

4. 处理步骤

(1)     执行display l2vpn vsi命令,查看VSI关联的AC、PW的状态和数量。

<Sysname> display l2vpn vsi verbose

VSI Name: vpls1

  VSI Index               : 0

  VSI Description         : vsi for vpls1

  VSI State               : Up

  MTU                     : 1500

  Bandwidth               : -

  Broadcast Restrain      : -

  Multicast Restrain      : -

  Unknown Unicast Restrain: -

  MAC Learning            : Enabled

  MAC Table Limit         : -

  MAC Learning rate       : -

  Drop Unknown            : -

  PW Redundancy           : Master

  Flooding                : Enabled

  Statistics              : Disabled

  VXLAN ID                : -

  LDP PWs:

    Peer            PW ID            Link ID    State

    192.3.3.3       1                8          Down

  ACs:

    AC                               Link ID    State       Type

    GE3/1/3 srv1                     1          Up          Manual

(2)     若AC的状态为Down,则检查AC配置是否正确和并检查AC所在的接口是否Up。如果AC配置不正确或AC所在的接口为Down状态,请修改AC配置或排查接口故障。

(3)     若PW的状态为Down,请通过display l2vpn pw verbose命令查看PW状态变为Down的原因。

<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状态。

(4)     若AC和PW均处于Up状态,请通过display l2vpn forwarding pw verbose命令查看PW是否存在转发信息,即承载PW的隧道对应的NHLFE表项索引列表(Tunnel NHLFE IDs)。

¡     如果存在转发信息,请执行步骤(6)。

¡     如果不存在转发信息,请执行步骤(5)。

<Sysname> display l2vpn forwarding pw verbose

VSI Name: aaa

  Link ID: 8

    PW Type         : VLAN                  PW State : Up

    In Label        : 1272                  Out Label: 1275

    MTU             : 1500

    PW Attributes   : Main

    VCCV CC         : Router-Alert

    VCCV BFD        : Fault Detection with BFD

    Flow Label      : Send

    Tunnel Group ID : 0x960000000

    Tunnel NHLFE IDs: 1034

    MAC limit       : maximum=2000   alarm=enabled   action=discard

(5)     执行display mpls lsp命令,查看是否存在承载PW的隧道,即是否存在FEC为PW对端IP地址的LSP,若不存在,则需要先完成承载PW的隧道的建立。

<Sysname> display mpls lsp

FEC                         Proto    In/Out Label    Out Inter/NHLFE/LSINDEX

100.100.100.100/24          LDP      -/1049          GE3/1/1

(6)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

¡     使用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

10.4.4  PW处于Up状态时两个PE间报文转发失败

1. 故障描述

PW处于Up状态时两个PE间报文转发失败。

2. 常见原因

本类故障的常见原因主要包括:

·     MAC地址表达到允许VSI学习到的最大MAC地址数,并且配置当VSI学习到的MAC地址数达到最大值后,禁止转发源MAC地址不在MAC地址表里的报文,即丢弃该报文。

·     PW信息没有下发到转发模块。

3. 故障分析

本类故障的诊断流程如图10-10所示。

图10-10 PW处于Up状态时两个PE间报文转发失败故障诊断流程图

 

4. 处理步骤

(1)     执行display l2vpn mac-address命令,查看是否存在相应的MAC地址表项和学习的MAC地址表项总数。可以通过指定具体的AC接口和PW信息,来显示从指定AC和PW上学习的MAC地址表项总数。

¡     查看所有L2VPN MAC地址表项信息。

<Sysname> display l2vpn mac-address

* - The output interface is issued to another VSI

MAC Address    State     VSI Name                        Link ID/Name   Aging

0000-0000-000a Dynamic   vpn1                            GE3/1/1        Aging

0000-0000-0009 Dynamic   vpn1                            GE3/1/1        Aging

--- 2 mac address(es) found  ---

¡     # 显示L2VPN MAC地址表项总数。

<Sysname> display l2vpn mac-address count

2 mac address(es) found

(2)     查看是否配置了允许学习到的最大MAC地址数,及达到最大MAC地址数后的转发。

¡     在VSI视图下执行display this命令,查看当前VSI下是否配置了mac-table limit命令和mac-table limit drop-unknown命令,如果配置了上述命令且当前已经学习到的MAC地址已经达到最大值,则需要将允许VSI学习到的最大MAC地址数调大或删除mac-table limit drop-unknown命令。

¡     在AC和PW视图下执行display this命令,查看当前视图下是否配置了mac limit命令,如果配置了该述命令且当前已经学习到的MAC地址已经达到最大值,则需要将允许学习到的最大MAC地址数调大或删除action discard参数。

(3)     执行display l2vpn forwarding pw verbose命令,查看PW是否存在转发信息,即承载PW的隧道对应的NHLFE表项索引列表(Tunnel NHLFE IDs)。

¡     如果存在转发信息,请执行步骤(5)。

¡     如果不存在转发信息,请执行步骤(4)。

<Sysname> display l2vpn forwarding pw verbose

VSI Name: aaa

  Link ID: 8

    PW Type         : VLAN                  PW State : Up

    In Label        : 1272                  Out Label: 1275

    MTU             : 1500

    PW Attributes   : Main

    VCCV CC         : Router-Alert

    VCCV BFD        : Fault Detection with BFD

    Flow Label      : Send

    Tunnel Group ID : 0x960000000

    Tunnel NHLFE IDs: 1034

    MAC limit       : maximum=2000   alarm=enabled   action=discard

(4)     执行display mpls lsp命令,查看是否存在承载PW的隧道,即是否存在FEC为PW对端IP地址的LSP,若不存在,则需要先完成承载PW的隧道的建立。

<Sysname> display mpls lsp

FEC                         Proto    In/Out Label    Out Inter/NHLFE/LSINDEX

100.100.100.100/24          LDP      -/1049          GE3/1/1

(5)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

¡     使用display diagnostic-information命令收集诊断信息。

5. 告警与日志

相关告警

相关日志

·     L2VPN/4/L2VPN_MACLIMIT_MAX_AC

·     L2VPN/4/L2VPN_MACLIMIT_MAX_PW

·     L2VPN/4/L2VPN_MACLIMIT_MAX_VSI

10.5  MPLS L3VPN故障处理

10.5.1  缺少去往对端VPN实例的路由

1. 故障描述

执行display bgp peer vpnv4命令,查看BGP VPNv4对等体信息,不是Established状态或者不存在对等体信息。

<Sysname> display bgp peer vpnv4

 

 BGP local router ID: 111.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

 

  113.1.1.1              100        3        4    0       0 00:00:52 Established

2. 故障诊断流程

导致缺少去往对端VPN实例的路由常见的原因有以下几种:

·     BGP邻居没有建立。

·     VPN Target是否一致。

·     组网的配置是否有问题。

·     确认路由是否发送或被接受。

图10-11 故障诊断流程图

 

3. 故障处理步骤

(1)     BGP邻居没有建立

执行display bgp peer vpnv4命令,查看BGP VPNv4对等体信息,确保BGP配置正确。

<Sysname> display bgp peer vpnv4

 

 BGP local router ID: 111.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

 

  113.1.1.1              100        3        4    0       0 00:00:52 Established

(2)     VPN Target配置不一致

执行display current-configuration vpn-instance命令分别查看本地和对端的VPN Target,确保一端的import Target与另一端的export Target一致。

<Sysname> display current-configuration vpn-instance

#

ip vpn-instance vpn1

 route-distinguisher 100:1

 vpn-target 111:1 import-extcommunity

 vpn-target 111:1 export-extcommunity

#

(3)     组网中的配置有问题

若在B类跨域组网下,反射器设备没有关闭VPN-Target过滤功能,请关闭VPN-Target过滤功能。检查在跨域的部分设备是否配置了mpls enable命令,注意不需要配置mpls ldp enable命令。

(4)     确认路由是否发送或被接受

发送方执行display bgp routing-table vpnv4 advertise-info命令,接收方执行display bgp routing-table vpnv4命令,确认路由是否发送或被接受。

¡     查看发送方

<Sysname> display bgp routing-table vpnv4 3.3.3.3 32 advertise-info

……

 BGP routing table information of 3.3.3.3/32(TxPathID:0):

 Advertised to VPN peers (1 in total):

    113.1.1.1

 Inlabel              : 1151

¡     查看接收方

<Sysname> display bgp routing-table vpnv4 3.3.3.3 32

……

 BGP routing table information of 3.3.3.3/32:

 From            : 111.1.1.1 (111.1.1.1)

……

(5)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

10.5.2  VPN实例下的FIB表项异常

1. 故障描述

VPN实例下的FIB表项中的路由不存在或Token值不存在。

2. 故障诊断流程

图10-12 故障诊断流程图

 

3. 故障处理步骤

(1)     FIB表项中的路由不存在

执行display ip routing-table vpn-instance命令,查看VPN实例下的路由表,查看路由是否存在,若不存在,请检查BGP配置 是否正确。

(2)     Token值不存在

a.     执行display mpls ldp lsp命令,查看到LSP,若LSP未正确生成,请确保公网隧道配置正确,且BGP配置了peer connect-interface命令。

b.     查看配置的隧道策略是否正确。

(3)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

10.5.3  L3VPN流量中断

1. 故障描述

经过MPLS L3VPN网络转发的私网流量中断。

2. 常见原因

本类故障的常见原因主要包括:

·     私网路由下一跳不可达。

·     路由策略配置不当导致路由无法发布和接收。

·     标签超限导致私网路由无法发布。

·     私网路由迭代不到隧道。

·     Export RT和Import RT不匹配导致路由无法学习到私网路由表中。

·     路由超限导致收到的路由被丢弃。

3. 故障分析

本类故障的诊断流程如图10-13所示。

图10-13 L3VPN流量中断故障诊断流程图

 

4. 处理步骤

(1)     检查路由是否为最优路由。

执行命令display bgp routing-table vpnv4display 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 enablempls 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-routesdisplay 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 vpnv4display current-configuration configuration vpn-instance命令,查看是否本端VPN实例的Export RT与远端VPN实例的Import RT不匹配,导致路由发送到远端PE后无法学习到远端VPN实例中。

在本端PE上执行display bgp routing-table vpnv4display 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

GE3/1/1                 Up           1500

GE3/1/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. 告警与日志

相关告警

模块名:BGP4-MIB

·     bgpBackwardTransition (1.3.6.1.2.1.15.7.2)

相关日志

·     BGP_EXCEED_ROUTE_LIMIT

·     BGP_REACHED_THRESHOLD

10.5.4  L3VPN私网路由频繁震荡

1. 故障描述

远端PE发布的私网路由在本端PE上频繁震荡。

2. 常见原因

本类故障的常见原因主要包括:

·     公网路由震荡

·     LDP LSP震荡

·     接口震荡

3. 故障分析

本类故障的诊断流程如图10-14所示。

图10-14 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 3/1/1 brief

Brief information on interfaces in route mode:

Link: ADM - administratively down; Stby - standby

Protocol: (s) – spoofing

 

Interface                         Link Protocol Primary IP      Description

GE3/1/1                           UP   UP       --

(4)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

5. 告警与日志

相关告警

相关日志

10.5.5  PE间无法交换VPN路由

1. 故障描述

PE间无法交换VPNv4或VPNv6路由。

2. 常见原因

本类故障的常见原因主要包括:

·     公网IGP路由未发布

·     公网LSP不存在

·     BGP对等体未建立

·     未学习到VPNv4或VPNv6路由

3. 故障分析

本类故障的诊断流程如图10-15所示。

图10-15 PE间无法交换私网路由故障诊断流程图

 

4. 处理步骤

(1)     检查IGP路由是否存在。

执行display ip routing-table命令,查看是否存在到达对端PELoopback接口的网段路由:

<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命令,查看是否存在到达远端PELoopback接口的公网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          GE3/1/1

<Sysname> display mpls lsp

FEC                         Proto    In/Out Label    Out Inter/NHLFE/LSINDEX

1.1.1.1/24                  LDP      -/1051          GE3/1/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命令,查看PECE之间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. 告警与日志

相关告警

相关日志

10.5.6  配置相同RT的不同VPN之间不能互通

1. 故障描述

图10-16的网络中,配置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。

图10-16 MPLS L3VPN组网图

 

2. 常见原因

本场景中,CE 1可以Ping通相同VPN的CE 3,说明MPLS骨干网中进行标签转发的公网隧道正常,本类故障的常见原因仅包括:PE设备上不同的VPN实例绑定的IP地址存在冲突。

3. 故障分析

本类故障的诊断流程如图10-17所示。

图10-17 配置相同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

...

GE3/1/1            up       up       10.1.1.1/24        vpn1         --

GE3/1/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从GigabitEthernet3/1/2接口发送给VPN 2,而是从GigabitEthernet3/1/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. 告警与日志

相关告警

相关日志

10.5.7  路由反射器进行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过滤功能,可以解决本类故障,本故障的处理流程如图10-18所示。

图10-18 路由反射器进行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. 告警与日志

相关告警

相关日志

10.5.8  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. 故障分析

本类故障的诊断流程如图10-19所示。

图10-19 PE的私网IP路由表中没有远端PE发布的路由故障诊断流程图

 

4. 处理步骤

(1)     检查BGP邻居是否建立。

执行display bgp peer vpnv4display 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-routesdisplay 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 vpnv4display 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 vpnv4display 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 : GigabitEthernet3/1/1

  TTL mode: pipe

  Address-family IPv4:

   Export VPN Targets :

       1:1

   Import VPN Targets :

       1:1

-     如果不一致,则需要在本端或者远端PE的VPN实例视图下通过vpn-target命令,将RT修改为匹配的值。修改RT后,如果本端PEBGP路由表中仍未存在对端PE发布的私网路由,请执行步骤b;如果本端PEBGP路由表中已经存在对端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. 告警与日志

相关告警

相关日志

10.5.9  私网间大包不通

1. 故障描述

MPLS L3VPN/IPv6 MPLS L3VPN网络中同时存在我司设备和其他厂商设备,用户访问跨站点的私网资源时,不能打开部分网站,也不能通过FTP下载文件。执行ping命令检验发现,在指定ICMP报文的净荷为1464字节以上时Ping不通,指定ICMP报文的净荷小于1464字节时,可以Ping通。

2. 常见原因

本类故障的常见原因主要为:流量转发路径上设备接口的MTU值过小。

3. 故障分析

本故障的处理流程如图10-20所示。

图10-20 私网间大包不通故障诊断流程图

 

4. 操作步骤

(1)     在流量转发路径上,将设备接口的MTU值修改为大于或等于1508字节。

¡     在我司设备上,可通过display interface命令查看接口的MTU。例如:

<Sysname> display interface gigabitethernet 3/1/1

GigabitEthernet3/1/1

Current state: Administratively UP

Line protocol state: UP

Description: GigabitEthernet3/1/1 Interface

Bandwidth: 1000000 kbps

Maximum transmission unit: 1500

...

需要修改接口的MTU值时,请在该接口视图下执行ip mtuipv6 mtu命令。

¡     其他厂商的设备配置请参考相关的资料。

如果故障仍未能排除,请执行步骤(2)。

(2)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

5. 告警与日志

相关告警

相关日志

10.5.10  PE设备Ping不通远端CE网段

1. 故障描述

图10-21所示,在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网段。

图10-21 IPv6 MPLS L3VPN 组网图

 

2. 常见原因

本类故障的常见原因主要为:CE 3上没有到达PE 1所有私网IPv6地址的路由。私网IPv6地址的范围是,PE 1上与CE 3相同的VPN实例中,所有处于UP状态的接口的IPv6地址。

3. 故障分析

本故障的处理流程如图10-22所示。

图10-22 PE设备Ping不同远端CE网段故障诊断流程图

 

 

4. 操作步骤

(2)     检查CE 3上是否存在到达PE 1所有私网IPv6地址的路由。

PE 1在Ping远端CE网段时,会使用当前设备上指定VPN实例中所有处于UP状态的接口的IPv6地址中,最小的IPv6地址作为ICMPv6报文的源地址,如果CE 3没有该IPv6地址的路由信息,将会导致ICMPv6报文无法返回。

上述问题可以通过以下方法解决:

¡     在PE 1上配置发布本设备的所有私网路由,例如,在BGP-VPN IPv6单播地址族视图下,配置import-route direct命令。

¡     执行Ping操作时,指定ICMPv6回显请求报文中的源IPv6地址为CE 3IPv6路由表中存在的地址,即执行ping ipv6 –a source-ipv6 -vpn-instance vpn-instance-name host命令。

如果故障仍不能排除,请执行步骤(2)。

(3)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

5. 告警与日志

相关告警

相关日志

10.6  MPLS业务丢包故障处理

10.6.1  故障描述

MPLS常见的组网如图10-23所示。MPLS相关业务正常,CE1与CE2之间发现存在丢包情况。

图10-23 MPLS组网图

 

10.6.2  L3VPN丢包故障处理步骤

1. Ingress节点丢包定位

(1)     查看FIB表,确定NID值

执行display fib命令。查看CE2为目的地址的FIB表项,找到其Token值,Token值即NID值。若Token值不存在,请参考“VPN实例下的FIB表项异常”章节。

[PE1] display fib vpn-instance vpn1 88.1.2.2 24

 

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

88.1.2.0/24        116.1.1.1       UGR      3081                     3029

(2)     根据NID值查找出接口和公网标签

根据NID值,执行display mpls forwarding nhlfe命令,确认出接口和公网标签。

[PE1] display mpls forwarding nhlfe 3081

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

 

NID        Tnl-Type   Flag OutLabel Forwarding Info

--------------------------------------------------------------------------------

3081       LSP        NA   3082     XGE3/1/2                 10.0.0.2

(3)     根据接口报文出入的统计,确定是否丢包

执行display counters inbound命令,查看输入报文的流量统计,执行display counters outbound命令,查看输出报文的流量统计,若出入报文的统计计数不相等,则可以判断为在ingress节点丢包。

2. P节点丢包定位

(1)     确认入标签

通过display mpls ldp lsp命令查找P节点的入标签是否与ingerss节点的出标签一致。

(2)     查找出接口和公网标签

根据ingress节点查到的出标签,执行display mpls forwarding ilm命令,查找P节点的出标签值。

[P] display mpls forwarding ilm 3082

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

 

InLabel Oper    VRF   Flag SwapLabel Forwarding Info

--------------------------------------------------------------------------------

3082    SWAP    0     NA   3083      XGE3/1/2                   12.11.2.1

(3)     根据接口报文出入的统计,确定是否丢包

执行display counters inbound命令,查看输入报文的流量统计,执行display counters outbound命令,查看输出报文的流量统计,若出入报文的统计计数不相等,则可以判断为在P节点丢包。

3. egress节点丢包定位

根据接口报文出入的统计,确定是否丢包。

执行display counters inbound命令,查看输入报文的流量统计,执行display counters outbound命令,查看输出报文的流量统计,若出入报文的统计计数不相等,则可以判断为在egress节点丢包。

4. 联系技术支持工程师

收集上述信息,并联系技术支持工程师。

10.6.3  L2VPN丢包故障处理步骤

1. Ingress节点丢包定位

(1)     确定PW对应的NID值

执行display l2vpn forwarding pw命令。查看指定PW的NID值。

<PE1> display l2vpn forwarding pw xconnect-group aaa

Total number of cross-connections: 1

Total number of PWs: 1, 1 up, 0 blocked, 0 down

 

Xconnect-group Name             In/Out Label    NID        Link ID    State

aaa                             1279/1046       3081       64         Up

(2)     根据NID值查找出接口和公网标签

根据NID值,执行display mpls forwarding nhlfe命令,确认出接口和公网标签。

[PE1] display mpls forwarding nhlfe 3081

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

 

NID        Tnl-Type   Flag OutLabel Forwarding Info

--------------------------------------------------------------------------------

3081       LSP        NA   3082     XGE3/1/2                 10.0.0.2

(3)     根据接口报文出入的统计,确定是否丢包

执行display counters inbound命令,查看输入报文的流量统计,执行display counters outbound命令,查看输出报文的流量统计,若出入报文的统计计数不相等,则可以判断为在ingress节点丢包。

2. P节点丢包定位

(1)     确认入标签

通过display mpls ldp lsp命令查找P节点的入标签是否与ingerss节点的出标签一致。

(2)     查找出接口和公网标签

根据ingress节点查到的出标签,执行display mpls forwarding ilm命令,查找P节点的出标签值。

[P] display mpls forwarding ilm 3082

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

 

InLabel Oper    VRF   Flag SwapLabel Forwarding Info

--------------------------------------------------------------------------------

3082    SWAP    0     NA   3083      XGE3/1/2                   12.11.2.1

(3)     根据接口报文出入的统计,确定是否丢

执行display counters inbound命令,查看输入报文的流量统计,执行display counters outbound命令,查看输出报文的流量统计,若出入报文的统计计数不相等,则可以判断为在P节点丢包。

3. egress节点丢包定位

根据接口报文出入的统计,确定是否丢包。

执行display counters inbound命令,查看输入报文的流量统计,执行display counters outbound命令,查看输出报文的流量统计,若出入报文的统计计数不相等,则可以判断为在egress节点丢包。

若实际组网环境不能通过接口流量定位可参见“MPLS丢包问题定位实例”章节。

4. 联系技术支持工程师

收集上述信息,并联系技术支持工程师。

10.6.4  VPLS丢包故障处理步骤

1. Ingress节点丢包定位

(1)     确定PW对应的NID值

执行display l2vpn forwarding pw命令。查看指定VSI内PW的NID值。

<PE1> display l2vpn forwarding pw vsi aaa

Total number of VSIs: 1

Total number of PWs: 2, 2 up, 0 blocked, 0 down

 

VSI Name                        In/Out Label    NID        Link ID    State

aaa                             1279/1046       3081       64         Up

(2)     根据NID值查找出接口和公网标签

根据NID值,执行display mpls forwarding nhlfe命令,确认出接口和公网标签。

[PE1] dis mpls forwarding nhlfe 3081

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

 

NID        Tnl-Type   Flag OutLabel Forwarding Info

--------------------------------------------------------------------------------

3081       LSP        NA   3082     XGE3/1/2                 10.0.0.2

(3)     根据接口报文出入的统计,确定是否丢包

执行display counters inbound命令,查看输入报文的流量统计,执行display counters outbound命令,查看输出报文的流量统计,若出入报文的统计计数不相等,则可以判断为在ingress节点丢包。

若实际组网环境不能通过接口流量定位可参见“MPLS丢包问题定位实例”章节。

2. P节点丢包定位

(1)     确认入标签

通过display mpls ldp lsp命令查找P节点的入标签是否与ingerss节点的出标签一致。

(2)     查找出接口和公网标签

根据ingress节点查到的出标签,执行display mpls forwarding ilm命令,查找P节点的出标签值。

[P] display mpls forwarding ilm 3082

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

 

InLabel Oper    VRF   Flag SwapLabel Forwarding Info

--------------------------------------------------------------------------------

3082    SWAP    0     NA   3083      XGE3/1/2                   12.11.2.1

(3)     根据接口报文出入的统计,确定是否丢包

执行display counters inbound命令,查看输入报文的流量统计,执行display counters outbound命令,查看输出报文的流量统计,若出入报文的统计计数不相等,则可以判断为在P节点丢包。

若实际组网环境不能通过接口流量定位可参见“MPLS丢包问题定位实例”章节。

3. egress节点丢包定位

根据接口报文出入的统计,确定是否丢包。

执行display counters inbound命令,查看输入报文的流量统计,执行display counters outbound命令,查看输出报文的流量统计,若出入报文的统计计数不相等,则可以判断为在egress节点丢包。

4. 联系技术支持工程师

收集上述信息,并联系技术支持工程师。

10.6.5  MPLS丢包问题定位实例

1. 组网环境

图10-24 组网环境图

 

2. 使用QoS策略定位丢包设备

·     配置步骤

(1)     配置PE1设备

# 配置QoS策略。

[PE1] traffic classifier 1 operator and

[PE1-classifier-1] if-match dscp cs4

[PE1-classifier-1] quit

[PE1] traffic behavior 1

[PE1-behavior-1] remark mpls-exp 1

[PE1-behavior-1] quit

[PE1] qos policy 1

[PE1-qospolicy-1] classifier 1 behavior

# 接口应用QoS策略。

[PE1] interface gigabitethernet 3/1/1

[PE1-GigabitEthernet3/1/1] qos apply policy 1

# 在接口上配置端口优先级信任模式为auto。

[PE1-GigabitEthernet3/1/1] qos trust auto

[PE1-GigabitEthernet3/1/1] quit

[PE1] interface gigabitethernet 3/1/2

[PE1-GigabitEthernet3/1/2] qos trust auto

[PE1-GigabitEthernet3/1/2] quit

(2)     配置P设备

# 配置QoS策略。

[P] traffic classifier 1 operator and

[P-classifier-1] if-match dscp cs4

[P-classifier-1] quit

[P] traffic behavior 1

[P-behavior-1] remark mpls-exp 1

[P-behavior-1] quit

[P] qos policy 1

[P-qospolicy-1] classifier 1 behavior

# 接口应用QoS策略。

[P] interface gigabitethernet 3/1/1

[P-GigabitEthernet3/1/1] qos apply policy 1

[P-GigabitEthernet3/1/1] quit

[P] interface gigabitethernet 3/1/2

[P-GigabitEthernet3/1/2] qos apply policy 1

[P-GigabitEthernet3/1/2] quit

# 在接口上配置端口优先级信任模式为auto。

[P-GigabitEthernet3/1/1] qos trust auto

[P-GigabitEthernet3/1/1] quit

[P] interface gigabitethernet 3/1/2

[P-GigabitEthernet3/1/2] qos trust auto

[P-GigabitEthernet3/1/2] quit

(3)     配置PE2设备

# 配置QoS策略。

[PE2] traffic classifier 1 operator and

[PE2-classifier-1] if-match dscp cs4

[PE2-classifier-1] quit

[PE2] traffic behavior 1

[PE2-behavior-1] remark mpls-exp 1

[PE2-behavior-1] quit

[PE2] qos policy 1

[PE2-qospolicy-1] classifier 1 behavior

# 接口应用QoS策略。

[PE2] interface gigabitethernet 3/1/1

[PE2-GigabitEthernet3/1/1] qos apply policy 1

# 在接口上配置端口优先级信任模式为auto。

[PE2-GigabitEthernet3/1/1] qos trust auto

[PE2-GigabitEthernet3/1/1] quit

[PE2] interface gigabitethernet 3/1/2

[PE2-GigabitEthernet3/1/2] qos trust auto

[PE2-GigabitEthernet3/1/2] quit

·     操作流程

完成以上配置后,进行以下操作:

(1)     清除设备的端口计数。

(2)     在设备上配置debugging ip icmp命令打开ICMP调试信息开关。

(3)     在CE1带tos字段去ping,如ping -a 1.1.1.1 -tos 96 -s 1000 –m 1 –t 0 -c 10 2.2.2.2。通过display qos queue-statistics interface outbound命令查看沿途设备的接口的哪个队列没有报文,ping的时候的tos字段就用哪个队列。

(4)     查看ping操作后的ICMP报文的打印情况。通过display qos queue-statistics interface outbound查看经过各设备端口的报文数量是否一致,若不一致,则发生丢包。

(5)     进行CE2带tos字段去ping,操作方法与上述操作类似。

3. 使用diffserver定位丢包设备

·     配置步骤

(1)     配置PE1设备的diffserver

通过display qos queue-statistics interface outbound命令查看沿途设备的接口的哪个队列没有报文,diffserver设置为相关值。

¡     在MPLS L3VPN组网中。

[PE1] ip vpn-instance vpn

[PE1-vpn-instance-vpn] diffserv-mode pipe cs6

¡     在MPLS L2VPN组网中。

[PE1] xconnect-group vpn

[PE1-xcg-vpn] connection 1

[PE1-xcg-vpn-1] diffserv-mode pipe cs6

¡     在VPLS组网中。

[PE1] vsi vpn

[PE1-vsi-vpn] diffserv-mode pipe cs6

(2)     配置PE2设备的diffserver

与PE1配置类似,请参考PE1的配置。

(3)     配置P设备

# 配置QoS策略。

[P] traffic classifier 1 operator and

[P-classifier-1] if-match dscp cs4

[P-classifier-1] quit

[P] traffic behavior 1

[P-behavior-1] remark mpls-exp 1

[P-behavior-1] quit

[P] qos policy 1

[P-qospolicy-1] classifier 1 behavior

# 接口应用QoS策略。

[P] interface gigabitethernet 3/1/1

[P-GigabitEthernet3/1/1] qos apply policy 1

[P-GigabitEthernet3/1/1] quit

[P] interface gigabitethernet 3/1/2

[P-GigabitEthernet3/1/2] qos apply policy 1

[P-GigabitEthernet3/1/2] quit

# 在接口上配置端口优先级信任模式为auto。

[P-GigabitEthernet3/1/1] qos trust auto

[P-GigabitEthernet3/1/1] quit

[P] interface gigabitethernet 3/1/2

[P-GigabitEthernet3/1/2] qos trust auto

[P-GigabitEthernet3/1/2] quit

·     操作流程

完成以上配置后,进行以下操作:

(4)     清除设备的端口计数。

(5)     在CE1带tos字段去ping,如ping -a 1.1.1.1 -tos 96 -s 1000 –m 1 –t 0 -c 10 2.2.2.2。通过display qos queue-statistics interface outbound命令查看沿途设备的接口的哪个队列没有报文,ping的时候的tos字段就用哪个队列。

(6)     通过display qos queue-statistics interface outbound查看经过各设备端口的报文数量是否一致,若不一致,则发生丢包。

(7)     进行CE2带tos字段去ping,操作方法与上述操作类似。

10.7  MPLS TE故障处理

10.7.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. 故障分析

本类故障的诊断流程如图10-25所示。

图10-25 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隧道,则需要检查设备和接口是否配置了rsvprsvp 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. 告警与日志

相关告警

相关日志

10.7.2  MPLS TE隧道由UP状态变为Down状态

1. 故障描述

MPLS TE隧道由UP状态变为Down状态。

2. 常见原因

本类故障的常见原因主要包括:

·     MPLS TE隧道所在的链路Down。

·     MPLS TE隧道的配置被删除或配置错误。

·     RSVP消息超时或错误。

·     物理链路不满足MPLS TE隧道所需的带宽。

·     MPLS TE隧道或隧道所在物理接口BFD down。

3. 故障分析

本类故障的诊断流程如图10-26所示。

图10-26 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隧道,则需要检查设备和接口是否配置了rsvprsvp 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)     检查是否存在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. 告警与日志

相关告警

模块名:MPLS-TE-STD-MIB

·     mplsTunnelUp (1.3.6.1.2.1.10.166.3.0.1)

·     mplsTunnelDown (11.3.6.1.2.1.10.166.3.0.2)

相关日志

·     IFNET/5/LINK_UPDOWN

·     IFNET/3/PHY_UPDOWN

10.7.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. 告警与日志

相关告警

相关日志

10.7.4  Tunnel路径计算失败

1. 故障描述

MPLS TE隧道路径计算失败,导致隧道DOWN。

2. 常见原因

本类故障的常见原因主要包括:

·     没有建立IGP邻居。

·     没有MPLS TEDB信息。

·     MPLS TE配置错误。

3. 故障分析

本类故障的诊断流程如图10-27所示。

图10-27 Tunnel路径计算失败的故障诊断流程图

 

4. 处理步骤

(1)     查看是否建立了IGP邻居。

执行display ospf peerdisplay 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 enablempls te enable命令。

b.     LSR ID、Router ID是否为同一LoopBack接口的地址。

(3)     检查MPLS TE配置。

a.     若使用RSVP-TE协议建立MPLS TE隧道,则需要检查设备和接口是否配置了rsvprsvp 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. 告警与日志

相关告警

相关日志

10.7.5  热备份CRLSP无法建立

1. 故障描述

MPLS TE隧道下配置mpls te backup hot-standby命令,但是无法建立备份CRLSP

2. 常见原因

本类故障的常见原因主要包括:

·     只存在一个与邻居相邻的接口。

·     MPLS TE配置错误。

3. 故障分析

本类故障的诊断流程如图10-28所示。

图10-28 热备份CRLSP无法建立的故障诊断流程图

 

4. 处理步骤

(1)     根据配置的IGP协议,执行display ospf peerdisplay 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隧道,则需要检查设备和接口是否配置了rsvprsvp 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 mpls命令。

g.     若使用mpls te path命令指定显式路径来建立MPLS TE隧道,则需要检查显式路径配置是否合理使用strict方式时,需要逐跳指定入接口的IP地址;使用loose方式时,需要指定经过的设备的节点地址

(3)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件。

¡     使用display diagnostic-information命令收集诊断信息。

5. 告警与日志

相关告警

相关日志

·     TE/5/TE_BACKUP_SWITCH


11 Segment Routing类故障处理

11.1  SR-MPLS故障处理

11.1.1  SR-MPLS-BE方式的SRLSP无法建立

1. 故障描述

采用SR-BE方式建立SRLSP时,依次在SRLSP经过的各个节点上使用display mpls lsp命令检查SRLSP的标签交换信息,发现某个节点没有去往SRLSP的Egress节点的出标签(Out Label)或者该出标签并非SR-MPLS分配。例如,Egress节点FEC为5.5.5.5/32,如下显示表示该节点上不存在去往5.5.5.5/32的SR-MPLS出标签,即不存在去往5.5.5.5/32的SRLSP。

<Sysname> display mpls lsp

FEC                         Proto       In/Out Label    Out Inter/NHLFE/LSINDEX

12.1.1.2                    Local       -/-             GE0/0/1

Tunnel1                     Local       -/-             NHLFE2

Tunnel10                    Local       -/-             NHLFE1

1.1.1.1/32                  ISIS        16010/-         -

2.2.2.2/32                  ISIS        16020/3         GE0/0/1

2.2.2.2/32                  ISIS        -/3             GE0/0/1

3.3.3.3/32                  ISIS        16030/16030     GE0/0/1

3.3.3.3/32                  ISIS        -/16030         GE0/0/1

4.4.4.4/32                  ISIS        16040/16040     GE0/0/1

4.4.4.4/32                  ISIS        -/16040         GE0/0/1

1.1.1.1/1/4122              SR-TE       -/16030         GE0/0/1

                                        16040

2. 常见原因

本类故障的常见原因主要包括:

·     物理链路故障。

·     IGP或BGP邻居关系未正常建立导致SR-MPLS标签发布失败。

·     SR-MPLS配置缺少或错误。

采用SR-BE方式建立SRLSP完全依赖于IGP或BGP路由的发布,在IGP或BGP邻居之间通告路由信息时,需要携带SR-MPLS标签信息以建立SRLSP。因此,IGP或BGP邻居关系是否正常建立、IGP路由是否正常发布是本类故障最重要的原因。

3. 故障分析

本类故障的诊断流程如图11-1所示。

图11-1 采用SR-BE方式无法建立SRLSP的故障诊断流程图

 

4. 处理步骤

(1)     在SRLSP经过的各个节点上通过命令display interface brief检查物理链路状态,确保SRLSP转发路径上各接口的物理状态和数据链路层协议状态均为UP。如果链路正常,或链路恢复后问题仍未解决,请继续执行以下操作。

(2)     在SRLSP经过的各个节点上检查IGP/BGP邻居关系是否正常建立,IGP/BGP配置是否正确。SR-MPLS采用不同的路由协议发布标签时,故障处理方法有所不同:

¡     如果使用OSPF作为IGP来通告路由信息并发布SR-MPLS标签:

-     通过display ospf命令来判断OSPF是否使能Opaque LSA发布接收能力。如果display ospf命令显示信息中存在Opaque capable字段,表示Opaque LSA发布接收能力处于开启状态。若未使能该功能,则需要在OSPF视图下执行opaque-capability enable命令。

-     执行display ospf peer命令确认OSPF邻接关系是否正常。如果显示信息中邻居状态字段State显示为Full,表示OSPF邻居关系正常。否则,请参见OSPF故障处理手册中“OSPF邻居无法达到FULL状态”的处理过程。

-     执行display mpls lsp命令检查是否存在OSPF协议发布的SR Prefix方式的LSP信息。各节点的SR Prefix SID是管理员为Loopback地址手工指定的SID。如果没有SR Prefix方式的LSP信息,请在各节点的Loopback接口视图下检查是否使用ospf area命令使能OSPF或在OSPF视图下是否使用network命令引入Loopback接口网段地址。

<Sysname> display mpls lsp

FEC                         Proto       In/Out Label    Out Inter/NHLFE/LSINDEX

1.1.1.9/32                  OSPF        16010/-         -

1.1.1.9/32                  ISIS        16010/-         -

2.2.2.9/32                  OSPF        16020/17020     RAGG1.4

-     如果display mpls lsp命令的显示信息中不仅存在OSPF协议发布的SRLSP信息,同时也存在BGP协议发布的相同Prefix的SRLSP信息,则可能因Prefix SID冲突导致SRLSP生成失败。此时请通过peer route-policy命令过滤掉从BGP对等体学习的该路由信息。

¡     如果使用IS-IS作为IGP来通告路由信息并发布SR-MPLS标签:

-     通过display isis命令的显示信息中Cost style字段来判断IS-IS开销值的类型是否为wide、compatible或wide-compatible。如果Cost style字段的开销值类型不是以上三种,请执行cost-style命令来修改IS-IS开销值的类型。

-     执行display isis peer命令确认IS-IS邻居关系是否正常。如果display isis peer命令邻居状态字段State显示为Up,表示IS-IS邻居关系正常。否则,请参见IS-IS故障处理手册中“IS-IS邻居无法建立”的处理过程。

-     执行display mpls lsp命令检查是否存在IS-IS协议发布的SR Prefix方式的LSP信息。各节点的SR Prefix SID是管理员为Loopback地址手工指定的SID。如果没有SR Prefix方式的LSP信息,请在各节点的Loopback接口视图下检查是否使用isis enable命令使能IS-IS功能。

<Sysname> display mpls lsp

FEC                         Proto       In/Out Label    Out Inter/NHLFE/LSINDEX

1.1.1.9/32                  OSPF        16010/-         -

1.1.1.9/32                  ISIS        16010/-         -

2.2.2.9/32                  ISIS        16020/17020     RAGG1.4

-     如果display mpls lsp命令的显示信息中不仅存在IS-IS协议发布的SRLSP信息,同时也存在BGP协议发布的相同Prefix的SRLSP信息,则可能因Prefix SID冲突导致SRLSP生成失败。此时请通过peer route-policy命令过滤掉从BGP对等体学习的该路由信息。

¡     如果使用BGP来通告路由信息并发布SR-MPLS标签:

-     执行display bgp peer命令检查BGP对等体或对等体组的邻居关系是否正常。如果display bgp peer命令BGP会话的状态字段State显示为Established,表示BGP对等体或对等体组邻居关系正常。否则,请参见BGP故障处理手册中“BGP 邻居无法建立”的处理过程。

-     执行display mpls lsp命令检查是否存在BGP协议发布的SR Prefix方式的LSP信息。如果没有,请检查BGP的指定对等体/对等体组配置了peer label-route-capability命令来使能交换带标签路由的能力,并且通过路由策略为引入BGP的Loopback地址配置了标签索引值。

<Sysname> display mpls lsp

FEC                         Proto       In/Out Label    Out Inter/NHLFE/LSINDEX

1.1.1.9/32                  OSPF        16010/-         -

1.1.1.9/32                  ISIS        16010/-         -

2.2.2.9/32                  BGP         16020/17020     RAGG1.4

如果执行以上操作后,问题仍未解决,则请继续执行以下操作。

(3)     SRLSP经过的各个节点上检查SR-MPLS配置。

a.     在IS-IS视图、OSPF视图或BGP视图下检查是否开启支持SR-MPLS功能。如果未开启支持SR-MPLS功能,则在IS-IS视图、OSPF视图或BGP视图下执行segment-routing mpls命令开启该功能。

b.     SR-BE LSP使用前缀SID方式建立SRLSP转发路径,请在LoopBack接口视图下检查是否配置前缀SID。如果未配置,则在OSPF视图下执行ospf prefix-sid命令或在IS-IS视图下执行isis prefix-sid命令配置前缀SID。

c.     执行display segment-routing label-block命令检查LoopBack接口下配置的前缀SID是否在SRGB标签段范围内。如果前缀SID未在SRGB范围内,则请修改配置的前缀SID,否则该SID不会生效。

d.     如果执行以上操作后,问题仍未解决,则请继续执行以下操作。

(4)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

5. 告警与日志

相关告警

相关日志

11.1.2  SR-MPLS-TE Tunnel状态为Down

1. 故障描述

在Ingress上执行display mpls te tunnel-interface命令检查SR-MPLS-TE Tunnel的状态为Down。

<Sysname> display mpls te tunnel-interface

Tunnel Name            : Tunnel 1

Tunnel Signalled Name  : tunnel1

Tunnel State           : Down (Main CRLSP Down. Backup CRLSP Down.)

...

2. 常见原因

本类故障的常见原因主要包括:

·     构成SR-MPLS-TE Tunnel的SRLSP所经过的路径上存在物理链路故障。

·     用于检测SR-MPLS-TE Tunnel的BFD会话状态为down,使得SR-MPLS-TE Tunnel状态为Down。

·     SR-MPLS配置缺少或错误。

·     SR TE Tunnel配置错误。

3. 故障分析

本类故障的诊断流程如图11-2所示。

图11-2 SR-MPLS TE Tunnel Down的故障诊断流程图

 

4. 处理步骤

(1)     在SRLSP经过的各个节点上通过命令display interface brief检查物理链路状态,确保SRLSP转发路径上各接口的物理状态和数据链路层协议状态均为UP。如果链路正常,或链路恢复后问题仍未解决,请继续执行以下操作。

(2)     检查是否由BFD会话Down导致SR TE Tunnel Down。

a.     在SR-MPLS-TE隧道接口下使用display this命令检查是否配置了mpls bfdmpls sbfdmpls tunnel-bfdmpls tunnel-sbfd命令中的任一条。如果配置了,则执行b

b.     使用display mpls bfddisplay mpls sbfd命令检查BFD/SBFD会话的状态。如果BFD/SBFD会话的状态为Down,则执行c

c.     可能是由于BFD联动导致SR-TE隧道Down,请执行undo mpls bfdundo mpls sbfdundo mpls tunnel-bfdundo mpls tunnel-sbfd命令删除BFD/SBFD检测相关命令。如果BFD/SBFD会话正常或者不存在BFD/SBFD会话,问题仍未解决请执行(3)

(3)     检查SR-MPLS配置。

a.     在IS-IS视图或OSPF视图下检查是否开启支持SR-MPLS功能,同时需要检查以下配置,否则SR-MPLS功能不会生效:

-     当IGP协议为IS-IS时,通过display isis命令的显示信息中Cost style字段来判断IS-IS开销值的类型是否为wide、compatible或wide-compatible。如果Cost style字段的开销值类型不是以上三种,请执行cost-style命令来修改IS-IS开销值的类型。

-     当IGP协议为OSPF时,通过display ospf命令来判断OSPF是否使能Opaque LSA发布接收能力。如果display ospf命令显示信息中存在Opaque capable字段,表示Opaque LSA发布接收能力处于开启状态。若未使能该功能,则需要在OSPF视图下执行opaque-capability enable命令。

b.     若使用前缀SID方式建立SRLSP转发路径,请在LoopBack接口视图下检查是否配置了前缀SID。如果未配置,则在OSPF视图下执行ospf prefix-sid命令或在IS-IS视图下执行isis prefix-sid命令配置前缀SID;若使用Adjacency SID方式建立SRLSP转发路径,请在OSPF视图或IS-IS视图下开启邻接标签分配功能或者在SRLSP转发路径的接口上检查是否配置了Adjacency SID。如果未配置,则在OSPF视图或IS-IS视图下执行segment-routing adjacency enable命令开启邻接标签分配功能。也可以在接口视图下执行isis adjacency-sid命令或ospf adjacency-sid命令配置Adjacency SID。

c.     执行display segment-routing label-block命令检查LoopBack接口下配置的前缀SID是否在SRGB标签段范围内,并检查接口下配置的Adjacency SID是否在SRLB标签段范围内。如果前缀SID未在SRGB范围内或者Adjacency SID未在SRLB标签段范围内,则请修改配置的Adjacency SID,否则该SID不会生效。

d.     如果执行以上操作后,问题仍未解决,则请继续执行以下操作。

(4)     检查TE隧道配置。MPLS TE采用不同方式生成SRLSP时,故障定位方式有所不同:

¡     MPLS TE隧道采用静态指定标签生成SRLSP:在SRLSP的Ingress上执行display mpls static-sr-mpls命令查看静态SRLSP信息或静态配置的邻接段信息,保证出标签栈字段Out-Label表示的标签序列依次和SRLSP路径上各节点配置的静态标签值一一对应。如果Ingress上出标签栈中的标签序列与SRLSP路径上各节点配置的静态标签值不对应,请执行static-sr-mpls lsp命令修改Ingress上出标签栈中的标签序列。

¡     若MPLS TE隧道采用显式路径算路生成SRLSP:在SRLSP的Ingress上执行display explicit-path命令检查显式路径上节点的IP地址或者SID与SRLSP路径上各节点的IP地址或者本地SID一一对应,并保证Ingress上显式路径视图下通过nexthop命令指定的SID类型与SRLSP路径上各节点的接口视图下配置的前缀SID或Adjacency SID类型保持一致,即接口下配置了前缀SID,nexthop命令指定的SID也必须是前缀SID。如果存在问题,请通过nexthop命令修改显式路径上的IP地址或者SID。

¡     若MPLS TE隧道采用PCE托管方式由控制器算路生成SRLSP,请检查SR-TE Tunnel接口下是否执行了mpls te delegation命令开启了SRLSP托管功能,并执行命令display mpls te pce peer检查PCC与PCE是否建立了PCEP会话。通过抓包确认控制器(PCE)是否进行了路径更新以及路径是否正确。在抓取报文中请确保由PCE下发的Adjacency SID或下一跳地址使用strict方式,前缀SID或者节点地址使用loose方式。如果PCC与PCE未正常建立了PCEP会话,且抓取报文未满足上述要求,请检查控制器上的配置。

(5)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

5. 告警与日志

相关告警

相关日志

·     TE/5/TE_BACKUP_SWITCH

11.2  SRv6 TE Policy故障处理

11.2.1  SRv6 TE Policy无法生效的定位思路

1. 故障描述

执行ping srv6-te policy命令检查指定SRv6 TE Policy的连通性时,发现报文无法通过SRv6 TE Policy正常转发。例如:

<Sysname> ping srv6-te policy policy-name p1

The SRv6-TE policy does not reference a SID list or the referenced SID list is down.

2. 常见原因

本类故障的常见原因主要包括:

·     SRv6 TE Policy状态为Shutdown。

·     SRv6 TE Policy的BSID配置错误或者冲突。

·     SRv6 TE Policy下配置缺失。

·     SRv6 TE Policy的资源超限。

·     Segment List中SID数量超限。

·     SRv6 TE Policy的SID列表与报文转发路径的规划不同。

·     SRv6 TE Policy报文转发路径上的物理链路故障。

3. 故障诊断流程

本类故障的诊断流程如图11-3所示。

图11-3 SRv6 TE Policy无法生效的故障诊断流程图

 

 

4. 故障处理步骤

(1)     在SRv6 TE Policy的头节点执行display segment-routing ipv6 te policy status命令初步查看SRv6 TE Policy不生效的原因。

<Sysname> display segment-routing ipv6 te policy status

Name/ID: p1/0

Status: Down

  Check admin status                  : Failed

  Check for endpoint & color          : Passed

  Check for segment list              : Passed

  Check valid candidate paths         : Failed

  Check for BSIDs                     : -

如果Check admin status字段显示为Failed,说明SRv6 TE Policy处于管理关闭状态。请进入指定SRv6 TE Policy视图下执行undo shutdown命令,设置SRv6 TE Policy为开启状态。

开启指定SRv6 TE Policy后,再次执行display segment-routing ipv6 te policy status命令,如果存在其他校验字段显示为Failed或“-”,例如Check for segment List字段显示为Failed,请继续执行以下操作。

(2)     检查SRv6 TE Policy的BSID是否存在冲突。

在SRv6 TE Policy的头节点执行display segment-routing ipv6 te policy命令。显示信息中Request state字段取值为Failed表示BSID申请失败。静态指定的BSID可能不在Locator段范围内或者与已存在的SRv6 TE Policy的BSID出现重复,从而导致SRv6 TE Policy失效。建议在失效的SRv6 TE Policy下执行undo binding-sid命令删除静态手工指定BSID,由系统自动申请BSID,以避免错误和冲突。

<Sysname> display segment-routing ipv6 te policy

 

Name/ID: p1/0

 Color: 10

 Endpoint: 1000::1

 Name from BGP:

 BSID:

  Mode: Dynamic              Type: Type 2              Request state: Succeeded

  Current BSID: 8000::1      Explicit BSID: -          Dynamic BSID: 8000::1

 Reference counts: 3

 Flags: A/BS/NC

如果BSID申请成功以后,问题仍未解决,则请继续执行以下操作。

(3)     检查SRv6 TE Policy的配置是否完整。

以IS-IS作为IGP通告SID为例,在SRv6 TE Policy的头节点上执行命令display current-configuration,查看配置是否与以下实例中的一致。如果缺少任意一项,则说明遗漏了部分配置。

isis 1

address-family ipv6 unicast

  segment-routing ipv6 locator a

 

segment-routing ipv6

locator a ipv6-prefix 1000:0:0:1:: 64 static 16

traffic-engineering

  srv6-policy locator a

  segment-list sl1

   index 10 ipv6 1000::2:0:0:1:0

   index 20 ipv6 1000::2:0:0:1:3

  policy p1

   color 100 end-point ipv6 4::4

   candidate-paths

    preference 100

     explicit segment-list sl1

SRv6 TE Policy报文转发路径的各节点上,也需要在IGP视图下配置segment-routing ipv6 locator命令,以正常发布Locator段。例如:

isis 1

address-family ipv6 unicast

  segment-routing ipv6 locator b

如果配置不完整,请补充缺失配置。配置补充完整后,如果问题仍未解决,请继续执行以下操作。

(4)     检查当前SRv6 TE Policy数量和Segment List数量是否超限。

在SRv6 TE Policy头节点执行display segment-routing ipv6 te policy statistics命令,查看SRv6 TE Policy的使用数量是否达到上限。

<Sysname> display segment-routing ipv6 te policy statistics

 

         IPv6 TE Policy Database Statistics

SRv6-TE policy resource information:

  Max resources: 1024

  Used resources: 1

  Upper threshold: 512 (50%)

  Lower threshold: 102 (10%)

SID list resource information:

  Max resources: 4096

  Used resources: 1

  Upper threshold: 3277 (80%)

  Lower threshold: 1638 (40%)

¡     如果SRv6-TE policy resource information下的Used resources字段的值等于Max resources字段的值,则表示SRv6 TE Policy数量可能超限,此时请删除不需要的SRv6 TE Policy。

¡     如果SID list resource information下的Used resources字段的值等于Max resources字段的值,则表示Segment List数量可能超限,请删除不需要的Segment List。

¡     如果SRv6 TE Policy数量和Segment List数量均没有超限,请继续执行以下操作。

(5)     检查Segment List中SID数量是否超限。

在SRv6 TE Policy头节点上进入probe视图,并执行display system internal segment-routing ipv6 te policy status命令,显示信息中MaxSIDs表示Segment List中SID的数量上限。

[Sysname-probe] display system internal segment-routing ipv6 te policy status

   MaxGroupNidNum: 1024           MaxPolicyNidNum: 1024

 MaxSeglistNidNum: 4096          MaxNexthopNidNum: 65535

        MaxOutNum: 32                  MaxEcmpNum: 16

          MaxSIDs: 10

执行display segment-routing ipv6 te segment-list命令,显示信息中的Nodes字段表示该指定Segment List中配置的SID节点数量。

<Sysname> display segment-routing ipv6 te segment-list

 

Total Segment lists: 1

 

Name/ID: A/1

 Origin: CLI

 Status: Up

 Verification State: Down

 Nodes: 11

如果配置的SID节点数量超过SID的数量上限,请删除Segment List中不必要的SID值。如果配置的SID节点数量未超过上限,庆继续执行以下操作。

(6)     检查SID列表的配置与规划是否一致。

在SRv6 TE Policy头节点执行display segment-routing ipv6 te segment-list命令,显示SID列表信息,其中自上而下依次排列的SID值表示转发路径上距离SRv6 TE Policy头节点由近到远的各节点或链路。如果Status字段为Down,表示未正常学习到该SID所属的Locator段。请参考OSPFv3故障处理手册或IS-IS故障处理手册处理。

[Sysname] display segment-routing ipv6 te segment-list

 

Total Segment lists: 1

 

Name/ID: s1/1

 Origin: CLI

 Status: Down

 Verification State: Down

 Nodes : 3

 

  Index    : 10                           SID: 1::1

  Status   : UP                    TopoStatus: Nonexistent

  Type     : Type_2                     Flags: None

  Coc Type : -           Common prefix length: 0

 

  Index    : 20                           SID: 1::2

  Status   : Down                  TopoStatus: Nonexistent

  Type     : Type_2                     Flags: None

  Coc Type : -           Common prefix length: 0

 

  Index    : 30                           SID: 1::3

  Status   : Down                  TopoStatus: Nonexistent

  Type     : Type_2                     Flags: None

  Coc Type : -           Common prefix length: 0

在SRv6 TE Policy转发路径上的各个节点上依次执行display segment-routing ipv6 local-sid命令查看SID值是否与上述命令显示的SID列表中的SID值一致。SID类型通常为End SID或End.X SID。例如,对于End SID,查看SRv6 Local SID的信息。

[Sysname] display segment-routing  ipv6  local-sid end

                    Local SID forwarding table (End)

Total SIDs: 2

 

SID           : 1000::2:0:0:1:0/64

Function type : End                             Flavor         : PSP

Locator name  : b                               Allocation type: Dynamic

Owner         : IS-IS-1                         State          : Active

Create Time   : Sep 04 16:32:03.443 2021

如果SID列表与转发路径上各节点的SID值不一致,请执行undo index index-number命令删除错误的SID,再执行index index-number ipv6 ipv6-address命令重新配置正确的SID。如果SID列表与规划一致,请继续执行以下操作。

(7)     在SRv6 TE Policy转发路径上的各个节点上通过display interface brief命令检查物理链路状态,确保转发路径上各接口的物理状态和数据链路层协议状态均为UP。如果链路正常,或链路恢复后问题仍未解决,请继续执行以下操作。

(8)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

5. 告警与日志

相关告警

相关日志

·     SRPV6/2/SRPV6_BSID_CONFLICT

·     SRPV6/2/SRPV6_BSID_CONFLICT_CLEAR

·     SRPV6/5/SRPV6_PATH_STATE_DOWN

·     SRPV6/4/SRPV6_POLICY_STATUS_CHG

·     SRPV6/4/SRPV6_RESOURCE_EXDCEED

·     SRPV6/4/SRPV6_RESOURCE_EXCEED_CLEAR

·     SRPV6/5/SRPV6_SEGLIST_STATE_DOWN

·     SRPV6/5/SRPV6_SEGLIST_STATE_DOWN

·     SRPV6/2/SRPV6_STATE_DOWN

·     SRPV6/2/SRPV6_STATE_DOWN_CLEAR

11.3  MPLS L3VPN over SRv6故障处理

11.3.1  MPLS L3VPN over SRv6故障处理

1. 故障描述

在MPLS L3VPN over SRv6组网(如下图)中,CE1与CE2之间业务不通。

图11-4 MPLS L3VPN over SRv6组网图

 

2. 故障处理步骤

(1)     查看isis\ospfv3路由

在PE设备上执行display isis peer命令查看邻居状态是否达到UP,执行display isis route ipv6查看是否学习到对方的Loopback接口的路由,否则检查接口配置\状态、ISIS配置。

<H3C> dis isis peer

                         Peer information for IS-IS(1)

                         -----------------------------

System ID: this

 Interface: GE6/1/3                 Circuit Id:  this.03

 State: Up     HoldTime: 10s        Type: L1(L1L2)     PRI: 64

System ID: this

 Interface: GE6/1/3                 Circuit Id:  this.03

 State: Up     HoldTime: 8s         Type: L2(L1L2)     PRI: 64

(2)     查看PE之间的对等体关系

在PE设备上执行display bgp peer vpnv4命令,查看PE之间的BGP对等体关系,如果不是Established状态,请检查BGP相关配置。

<H3C> dis bgp peer vpnv4

BGP local router ID: 8.8.8.8

 Local AS number: 100

 Total number of peers: 3                  Peers in established state: 1

* - Dynamically created peer

 Peer                   AS       MsgRcvd  MsgSent OutQ  PrefRcv Up/Down   State

1::237                 100      279      264     0     4       03:32:39  Established

 7::7                   100      0        0       0     0       02:24:30  Connect

 61::1                  100      0        0       0     0       02:24:06  Connect

(3)     查看私网路由

在PE设备上执行display ip routing-table vpn-instance命令,查看去往对端CE的路由,并且路由下一跳值为路由携带的End.DT4 SID,否则检查BGP vpnv4及vpn视图配置。

[PE1] display ip routing-table vpn-instance vpn1

 

Destinations : 11       Routes : 11

 

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        Direct  0   0           10.1.1.1        Vlan12

10.1.1.0/32        Direct  0   0           10.1.1.1        Vlan12

10.1.1.1/32        Direct  0   0           127.0.0.1       InLoop0

10.1.1.255/32      Direct  0   0           10.1.1.1        Vlan12

10.2.1.0/24        BGP     255 0           6:5::101        Vlan13

127.0.0.0/8        Direct  0   0           127.0.0.1       InLoop0

127.0.0.0/32       Direct  0   0           127.0.0.1       InLoop0

127.0.0.1/32       Direct  0   0           127.0.0.1       InLoop0

127.255.255.255/32 Direct  0   0           127.0.0.1       InLoop0

255.255.255.255/32 Direct  0   0           127.0.0.1       InLoop0

(4)     联系技术支持工程师

如果上述信息无误,请收集上述信息,并联系技术支持工程师。

11.4  EVPN VPLS over SRv6故障处理

11.4.1  VPLS的VSI不能up

1. 故障描述

执行display l2vpn vsi evpn-srv6 verbose命令,查看对应VSI的状态不是up的状态。

<Sysname> dis l2vpn vsi evpn-srv6 verbose

VSI Name: vsi1

  VSI Index               : 0

  VSI State               : Up

  MTU                     : 1500

  Diffserv Mode           : -

  Bandwidth               : Unlimited

  Broadcast Restrain      : 5120 kbps

  Multicast Restrain      : 5120 kbps

  Unknown Unicast Restrain: 5120 kbps

  MAC Learning            : Enabled

  MAC Table Limit         : Unlimited

  MAC Learning rate       : -

  Local MAC aging time    : NotAging

  Remote MAC aging time   : NotAging

  Drop Unknown            : Disabled

  PW Redundancy Mode      : Slave

  DSCP                    : -

  Service Class           : -

  Flooding                : Enabled

  VXLAN ID                : -

  SRv6 tunnels:

   Peer        : 119::1

   Link ID     : 0x9000000

   State       : Up

  ACs:

    AC                                 Link ID    State

    XGE4/2/1.1                         0x0        Up

    Statistics: Disabled

2. 故障处理步骤

(1)     检查两端的route-distinguisher及vpn-target是否一致

进入VSI视图,查看两端的route-distinguisher及vpn-target是否一致,如果不一致请配置一致。

[Sysname] vsi vsi1

 evpn encapsulation srv6

  route-distinguisher 630:1

  vpn-target 600:1 630:1 export-extcommunity

  vpn-target 600:1 630:1 import-extcommunity

  tunnel-policy p2

  segment-routing ipv6 locator sxc

  segment-routing ipv6 traffic-engineering

(2)     隧道策略选取是否正确

查看隧道策略配置,确认隧道策略选取的隧道类型为SRv6-TE Policy,并通过display segment-routing ipv6 forwarding命令查看该类型的隧道是否存在且up,不存在则建立该类型隧道。同时在对端设备通过display segment-routing ipv6 local-sid end查看分配的SID,并与本端设备配置的SID对比(本端设备通过display segment-routing ipv6 forwarding查看),不一致请进入segment-routing ipv6视图修改。

(3)     检查两端的AC接口状态是否Up

执行display interface brief命令,查看接口信息,确保接口状态为up。

(4)     请收集如下信息,并联系技术支持工程师

上述步骤的执行结果。

11.5  EVPN VPWS over SRv6故障处理

11.5.1  VPWS的xconnect-group不能up

1. 故障描述

执行display l2vpn xconnect-group evpn-srv6 verbose命令,查看对应xconnect-group的状态不是up的状态。

<Sysname> display l2vpn xconnect-group evpn-srv6 verbose

Xconnect-group Name: wlmwlm1

 Connection Name        : 1

  Connection ID         : 2

  State                 : Up

  MTU                   : 1500

  PW Redundancy Mode    : Slave

  Diffserv Mode         : -

  SRv6 tunnels:

   Peer        : 119::1

   Link ID     : 0x1

   State       : Up

  ACs:

    AC                                 Link ID    State

    XGE4/2/1.1001                      0x0        Up

    Statistics: Disabled

2. 故障处理步骤

(1)     检查两端的route-distinguisher、vpn-target、local-service-id及remote-service-id是否正确

进入xconnect-group视图,查看两端的route-distinguisher及vpn-target是否一致,同时检查local-service-id及remote-service-id,remote-service-id为对端设备的local-service-id。

[Sysname] xconnect-group xc1

 evpn encapsulation srv6

  route-distinguisher 54:1

  vpn-target 54:1 export-extcommunity

  vpn-target 54:1 import-extcommunity

  segment-routing ipv6 traffic-engineering

 connection 1

  segment-routing ipv6 locator sxc

  evpn local-service-id 17001 remote-service-id 16001 tunnel-policy p2

  ac interface Ten-GigabitEthernet4/2/1.1001

(2)     隧道策略选取是否正确

查看隧道策略配置,确认隧道策略选取的隧道类型为SRv6-TE Policy,并通过display segment-routing ipv6 forwarding命令查看该类型的隧道是否存在且up,不存在则建立该类型隧道。同时在对端设备通过display segment-routing ipv6 local-sid end查看分配的SID,并与本端设备配置的SID对比(本端设备通过display segment-routing ipv6 forwarding查看),不一致请进入segment-routing ipv6视图修改。

(3)     检查两端的AC接口状态是否Up

执行display interface brief命令,查看接口信息,确保接口状态为up。

(4)     请收集如下信息,并联系技术支持工程师

上述步骤的执行结果

11.6  MPLS L3VPN over SR故障处理

11.6.1  MPLS L3VPN over SR故障处理

1. 故障描述

如下图,在MPLS L3VPN over SR组网中,CE1与CE2之间业务不通,需要从控制层面和转发层面进行故障排查。

图11-5 MPLS L3VPN over SR组网图

 

2. 故障诊断流程

(1)     路由排查诊断流程

路由排查的思路为排查各个设备上是否有目标地址的路由。

图11-6 故障诊断流程图

 

 

(2)     隧道排查诊断流程

隧道排查的思路为排查隧道是否UP和隧道的连通性。

图11-7 故障诊断流程图

 

(3)     转发层面排查

转发层面排查的思路为排查目标地址路由的转发表、出接口和标签。

3. L3VPN故障控制层面处理步骤

(1)     在PE1和PE2上分别查看VPN实例的RT配置,确认PE1的Export Target与PE2的Import Target是否一致,PE2的Export Target与PE1的Import Target是否一致。

(2)     在CE2上通过display bgp routing-table ipv4命令查看是否存在目标地址的路由。

 

(3)     在CE2上通过display bgp routing-table ipv4 advertise-info命令查看是否将目标地址的路由通告给了PE2。

 

(4)     在PE2上通过display bgp routing-table vpnv4命令查看VPNv4路由表中是否有目标地址的路由。

 

(5)     在PE2上通过display bgp routing-table ipv4 vpn-instance命令查看VPN实例中是否有目标地址的路由,如果没有,则需要检查PE2与CE2的BGP邻居建立是否正常。

 

(6)     在PE2上通过display bgp peer ipv4 vpn-instance命令查看PE2与CE2的 BGP邻居建立是否正常,如果没有正常建立则进行BGP常规排错。

 

(7)     在RR上通过display bgp routing-table vpnv4命令查看是否从PE2上收到目标地址的路由,如果没有收到目标地址的路由,检查RR上是否配置了不进行vpn-target过滤undo policy vpn-target命令,如果没有则需要进行配置。

 

(8)     在RR上通过display bgp routing-table vpnv4 advertise-info命令查看是否将目标地址的路由通告给了PE1。

 

(9)     在PE1上通过display bgp routing-table vpnv4 peer命令查看设备是否从RR反射器收到目标地址的路由。

 

(10)     在PE1上通过display bgp routing-table vpnv4命令查看VPNv4路由表中是否有目标地址的路由,如果没有学习到目标地址的路由,则需检查BGP VPNv4邻居关系。

 

(11)     在PE1通过display bgp peer vpnv4命令查看BGP VPNv4邻居关系是否正常建立,如果没有正常建立则进行BGP常规排错。

 

(12)     在CE1上通过display bgp routing-table ipv4命令查看私网中是否有目标地址的路由。

 

(13)     在PE1上通过display interface tunnel brief命令查看隧道是否UP。

 

(14)     在PE1上通过ping mpls te tunnel命令或tracert mpls te tunnel命令检测MPLS TE隧道的连通性,如果隧道不可达则需要检查全局路由表。

(15)     在PE1上通过display explicit-path命令或display mpls te segment-routing tunnel path命令查看MPLS TE隧道的显式路径信息是否正确。

 

 

4. L3VPN故障转发层面处理步骤

(1)     在CE1上通过display fib vpn-instance命令查看目的地址的FIB转发表,确认对应的出接口。

 

(2)     在PE1上通过display fib vpn-instance命令查看目的地址的FIB转发表,确认对应隧道下一跳地址、出接口以及私网标签。如果OutInterface字段是个物理口,说明路由没有迭代到TE隧道上,需要排查TE隧道的状态。

 

(3)     在PE1上通过display mpls lsp命令查看隧道下一跳地址的LSP路径,确认NHLFE表对应的值。

 

(4)     在PE1上通过display mpls forwarding nhlfe命令查看隧道下一跳地址的NHLFE表项信息,确认对应的公网标签和出接口。

 

(5)     在P节点上通过display mpls forwording ilm命令查看ilm表项,确认公网标签的交换映射信息。

 

(6)     在PE2上通过display mpls forwording ilm命令查看ilm表项,确认私网标签的交换映射信息,并确认报文被转发至的VPN实例的VRF ID。

 

(7)     在PE2上通过display ip vpn-instance命令确定VPN实例的VRF ID,确认报文被转发至哪个VPN实例。

 

(8)     在PE2上通过display fib vpn-instance命令查看目的地址的FIB转发表,找到对应的出接口。

 

11.7  EVPN L3VPN over SRv6故障处理

11.7.1  EVPN L3VPN over SRv6 BE流量转发不通

1. 故障描述

在EVPN L3VPN over SRv6组网中,采用SRv6 BE方式转发流量时,流量转发不通。

2. 常见原因

本类故障的常见原因主要包括:

·     BGP EVPN邻居未成功建立。

·     EVPN L3VPN over SRv6配置缺失。

·     SRv6 SID路由不可达。

3. 故障分析

本类故障的诊断流程如图11-8所示。

图11-8 EVPN L3VPN over SRv6 BE流量转发不通的故障诊断流程图

 

4. 处理步骤

(1)     在本端PE设备上执行display bgp peer l2vpn evpn命令查看BGP EVPN邻居是否成功建立:

¡     若显示信息中的State字段取值为Established,则表示PE之间成功建立BGP EVPN邻居,请继续执行步骤(2)

¡     否则,请解决BGP EVPN邻居无法成功建立问题,解决方法请参见“BGP邻居无法建立的定位思路”。

<Sysname> display bgp peer l2vpn evpn

 

 BGP local router ID: 1.1.1.1

 Local AS number: 100

 Total number of peers: 1                 Peers in established state: 1

 

 * - Dynamically created peer

 Peer                    AS  MsgRcvd  MsgSent OutQ  PrefRcv Up/Down  State

 

 2::2                   100       13       10    0        2 00:00:05 Established

(2)     检查两端PE设备上EVPN L3VPN over SRv6的配置是否完整。若不完整,请补充缺失的配置;若完整,请继续执行步骤(3)

在两端PE上执行display current-configuration命令,检查是否存在以下配置。若不存在,则需要参见《EVPN L3VPN over SRv6配置指导》手册,补充相关配置。

#

isis 1

 cost-style wide-compatible

 #

 address-family ipv6 unicast

  segment-routing ipv6 locator aaa        // 配置通过IS-IS通告Locator网段路由

#

#

bgp 100

 peer 3::3 as-number 100

 #

 address-family l2vpn evpn

  peer 3::3 enable

  peer 3::3 advertise encap-type srv6     // 配置向对等体/对等体组发布SRv6封装的EVPN路由

 #

 ip vpn-instance vpn1

  #

  address-family ipv4 unicast

   segment-routing ipv6 best-effort evpn  // 配置路由迭代到SRv6 BE隧道

   segment-routing ipv6 locator aaa evpn  // 配置BGP引用Locator段,以便在引用的Locator段内为指定VPN实例的私网路由申请SRv6 SID

#

segment-routing ipv6

 encapsulation source-address 11::11      // 配置SRv6 VPN封装的IPv6报文头的源地址

 locator aaa ipv6-prefix 1:1:: 96 static 8  // 创建Locator段

#

(3)     在两端PE设备上分别检查是否存在到达对端的SRv6 SID的路由。

a.     执行display bgp l2vpn evpn命令,查看PrefixSID字段。该字段中的IPv6地址为对端PE分配的SRv6 SID。

<Sysname> display bgp l2vpn evpn [5][0][64][4::]/176

 

 BGP local router ID: 1.1.1.1

 Local AS number: 100

 

 

 Route distinguisher: 1:1

 Total number of routes: 1

 Paths:   1 available, 1 best

 

 BGP routing table information of [5][0][64][4::]/176:

 From            : 2::2 (2.2.2.2)

 Rely nexthop    : FE80::8A1B:6FFF:FEDB:708

 Original nexthop: 2::2

 Out interface   : GigabitEthernet2/0/3

 Route age       : 00h06m33s

 OutLabel        : 3

 Ext-Community   : <RT: 1:1>

 RxPathID        : 0x0

 TxPathID        : 0x0

 PrefixSID       : End.DT6 SID <9::8000:2>

 AS-path         : 65420

 Origin          : incomplete

 Attribute value : MED 0, localpref 100, pref-val 0

 State           : valid, internal, best

 Source type     : local

 IP precedence   : N/A

 QoS local ID    : N/A

 Traffic index   : N/A

 EVPN route type : IP prefix advertisement route

 ESI             : 0000.0000.0000.0000.0000

 Ethernet tag ID : 0

 IP prefix       : 4::/64

 Gateway address : ::

 MPLS label      : 3

 Tunnel policy   : NULL

 Rely tunnel IDs : N/A

 Re-orignination : Disable

b.     执行display ipv6 routing-table ipv6-address命令,查看是否存在到达SRv6 SID的路由。

<Sysname> display ipv6 routing-table 9::8000:2

 

Summary count : 1

 

Destination: 9::/64                                      Protocol  : IS_L1

NextHop    : FE80::8A1B:6FFF:FEDB:708                    Preference: 15

Interface  : GE1/0/3                                     Cost      : 20

若存在到达对端SRv6 SID的路由,则继续执行步骤(4);否则,请解决无法通过IGP学习到路由的问题,解决方法请参见“IP路由类故障处理手册”。

(4)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

5. 告警与日志

相关告警

相关日志

11.7.2  EVPN L3VPN over SRv6 TE流量转发不通

1. 故障描述

在EVPN L3VPN over SRv6组网中,采用SRv6 TE方式通过SRv6 TE Policy转发流量时,流量转发不通。

2. 常见原因

本类故障的常见原因主要包括:

·     BGP EVPN邻居未成功建立。

·     SRv6 SID路由不可达。

·     BGP-VPN IPv4单播地址族视图或BGP-VPN IPv6单播地址族视图下,未配置采用SRv6 TE方式进行路由迭代

·     EVPN路由迭代到的SRv6 TE Policy没有生效。

3. 故障分析

本类故障的诊断流程如图11-9所示。

图11-9 EVPN L3VPN over SRv6 TE流量转发不通的诊断流程图

 

4. 处理步骤

(1)     在本端PE设备上执行display bgp peer l2vpn evpn命令查看BGP EVPN邻居是否成功建立:

¡     若显示信息中的State字段取值为Established,则表示PE之间成功建立BGP EVPN邻居,请继续执行步骤(2)

¡     否则,请解决BGP EVPN邻居无法成功建立问题,解决方法请参见“BGP邻居无法建立的定位思路”。

<Sysname> display bgp peer  l2vpn evpn

 

 BGP local router ID: 1.1.1.1

 Local AS number: 100

 Total number of peers: 1                 Peers in established state: 1

 

 * - Dynamically created peer

 Peer                    AS  MsgRcvd  MsgSent OutQ  PrefRcv Up/Down  State

 2::2                   100       13       10    0        2 00:00:05 Established

(2)     在两端PE设备上分别检查是否存在到达对端的SRv6 SID的路由。

a.     执行display bgp l2vpn evpn命令,查看PrefixSID字段。该字段中的IPv6地址为对端PE分配的SRv6 SID。

<Sysname> display bgp l2vpn evpn [5][0][64][4::]/176

 

 BGP local router ID: 1.1.1.1

 Local AS number: 100

 

 

 Route distinguisher: 1:1

 Total number of routes: 1

 Paths:   1 available, 1 best

 

 BGP routing table information of [5][0][64][4::]/176:

 From            : 2::2 (2.2.2.2)

 Rely nexthop    : FE80::8A1B:6FFF:FEDB:708

 Original nexthop: 2::2

 Out interface   : GigabitEthernet2/0/3

 Route age       : 00h06m33s

 OutLabel        : 3

 Ext-Community   : <RT: 1:1>

 RxPathID        : 0x0

 TxPathID        : 0x0

 PrefixSID       : End.DT6 SID <9::8000:2>

 AS-path         : 65420

 Origin          : incomplete

 Attribute value : MED 0, localpref 100, pref-val 0

 State           : valid, internal, best

 Source type     : local

 IP precedence   : N/A

 QoS local ID    : N/A

 Traffic index   : N/A

 EVPN route type : IP prefix advertisement route

 ESI             : 0000.0000.0000.0000.0000

 Ethernet tag ID : 0

 IP prefix       : 4::/64

 Gateway address : ::

 MPLS label      : 3

 Tunnel policy   : NULL

 Rely tunnel IDs : 2150629378

 Re-orignination : Disable

b.     执行display ipv6 routing-table ipv6-address命令,查看是否存在到达SRv6 SID的路由。

<Sysname> display ipv6 routing-table 9::8000:2

 

Summary count : 1

 

Destination: 9::/64                                      Protocol  : IS_L1

NextHop    : FE80::8A1B:6FFF:FEDB:708                    Preference: 15

Interface  : GE1/0/3                                     Cost      : 20

c.     若存在到达对端SRv6 SID的路由,则继续执行步骤(3);否则,请解决无法通过IGP学习到路由的问题,解决方法请参见“IP路由类故障处理手册”。

(3)     在BGP-VPN IPv4单播地址族视图或BGP-VPN IPv6单播地址族视图下,执行display this命令,查看当前配置中是否存在segment-routing ipv6 traffic-engineering evpn或者segment-routing ipv6 traffic-engineering best-effort evpn命令。若不存在上述命令,请补充配置该命令;否则,请继续执行步骤(4)

<Sysname> system-view

[Sysname] bgp 100

[Sysname-bgp-default] ip vpn-instance vpn1

[Sysname-bgp-default-vpn1] address-family ipv4 unicast

[Sysname-bgp-default-ipv4-vpn1] display this

#

 segment-routing ipv6 locator aaa evpn

 segment-routing ipv6 traffic-engineering evpn

#

(4)     在两端PE设备上判断EVPN路由迭代到的SRv6 TE Policy是否有效。

a.     在两端PE设备上执行display bgp l2vpn evpn命令,查看到达对端私网地址的EVPN路由的Rely tunnel IDs字段取值。该值为EVPN路由迭代到的SRv6 TE Policy的隧道索引值。

<Sysname> display bgp l2vpn evpn [5][0][64][4::]/176

 

 BGP local router ID: 1.1.1.1

 Local AS number: 100

 

 

 Route distinguisher: 1:1

 Total number of routes: 1

 Paths:   1 available, 1 best

 

 BGP routing table information of [5][0][64][4::]/176:

 From            : 2::2 (2.2.2.2)

 Rely nexthop    : FE80::8A1B:6FFF:FEDB:708

 Original nexthop: 2::2

 Out interface   : GigabitEthernet2/0/3

 Route age       : 00h06m33s

 OutLabel        : 3

 Ext-Community   : <RT: 1:1>

 RxPathID        : 0x0

 TxPathID        : 0x0

 PrefixSID       : End.DT6 SID <9::8000:2>

 AS-path         : 65420

 Origin          : incomplete

 Attribute value : MED 0, localpref 100, pref-val 0

 State           : valid, internal, best

 Source type     : local

 IP precedence   : N/A

 QoS local ID    : N/A

 Traffic index   : N/A

 EVPN route type : IP prefix advertisement route

 ESI             : 0000.0000.0000.0000.0000

 Ethernet tag ID : 0

 IP prefix       : 4::/64

 Gateway address : ::

 MPLS label      : 3

 Tunnel policy   : NULL

 Rely tunnel IDs : 2150629378

 Re-orignination : Disable

b.     在两端PE设备上执行display segment-routing ipv6 te policy命令,检查Forwarding index字段取值与Rely tunnel IDs字段取值相同的SRv6 TE Policy是否有效,即查看Status是否为Down。若为Down,则表示SRv6 TE Policy未生效,请参考“SRv6 TE Policy无法生效的定位思路”解决该问题。

<Sysname> display segment-routing ipv6 te policy

 

Name/ID: p1/0

 Color: 10

 Endpoint: 1000::1

 Name from BGP:

 BSID:

  Mode: Dynamic              Type: Type 2              Request state: Succeeded

  Current BSID: 8000::1      Explicit BSID: -          Dynamic BSID: 8000::1

 Reference counts: 3

 Flags: A/BS/NC

 Status: Up

 AdminStatus: Up

 Up time: 2020-03-09 16:09:40

 Down time: 2020-03-09 16:09:13

 Hot backup: Enabled

 Statistics: Enabled

  Statistics by service class: Enabled

 Path verification: Enabled

 Drop-upon-invalid: Enabled

 BFD trigger path-down: Enabled

 SBFD: Enabled

  Remote: 1000

  SBFD template name: abc

  SBFD backup template name: -

  OAM SID: -

 BFD Echo: Disabled

 Forwarding index: 2150629378

 Association ID: 1

 Service-class: -

 Rate-limit: 15000 kbps

 PCE delegation: Disabled

 PCE delegate report-only: Disabled

 Encapsulation mode: -

 Candidate paths state: Configured

 Candidate paths statistics:

  CLI paths: 1       BGP paths: 0       PCEP paths: 0       ODN paths: 0

 Candidate paths:

  Preference : 20

   CpathName:

   ProtoOrigin: CLI        Discriminator: 10

   Instance ID: 0          Node address: 0.0.0.0

   Originator:  0, ::

   Optimal: Y              Flags: V/A

   Dynamic: Not configured

     PCEP: Not configured

   Explicit SID list:

    ID: 1                     Name: Sl1

    Weight: 1                 Forwarding index: 2149580801

    State: Up                 State(Echo BFD): Down

    Verification State: -

    Path MTU: 1500               Path MTU Reserved: 0

    Local BSID: -

    Reverse BSID: -

(5)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

5. 告警与日志

相关告警

相关日志


12 ACL和QoS故障处理

12.1  QoS故障处理

12.1.1  QACL业务故障

本节中描述的“QACL业务”是指通过预先配置的规则、对匹配规则的报文进行过滤的各种业务的统称,包括:报文过滤、策略路由、QoS策略、DHCP Snooping、Portal。

1. 故障描述

用户配置的QACL业务功能没有达到预期的配置效果。

2. 故障处理步骤

当QACL业务出现故障时,请按如下步骤处理。

(1)     检查报文是否被高优先级的QACL业务误匹配

路由器支持将多种QACL业务,不同QACL业务的优先级不同,优先级顺序依次为:uRPF > 全局应用的报文过滤 > 接口应用的报文过滤 > VLAN应用的报文过滤 > 全局上送cpu的规则 > 端口上送cpu的规则 > vlan上送cpu的规则 > dhcp snooping >控制平面应用的QoS策略 > 动态白名单ACL规则 > Portal免认证规则 > 接口应用的策略路由 > VLAN应用的策略路由 > 全局应用的QoS策略 > 接口应用的QoS策略 > VLAN应用的QoS策略 > portal其它规则。

如果某类报文同时匹配了多个不同优先级的QACL业务规则,只有优先级最高的QACL业务规则匹配成功。因此,如果QACL业务下发后,实际功能没有生效,需要排查其他更高优先级的QACL业务规则中是否已匹配了该类报文。对于此类问题,请结合实际需求,修改相关QACL业务的规则,达到预期的匹配效果。

(2)     检查QoS策略的配置是否已正确应用

在QoS策略的配置中,有很多配置不支持或配置之间存在冲突。如果在配置过程中,路由器上未开启terminal debuggingterminal monitor功能,即使有冲突的配置下发了,路由器也不会有提示。此时,您可以通过以下两种方法进行排查:

¡     在设备上开启terminal debuggingterminal monitor功能,并重新应用QoS策略(重新应用之前请先执行undo命令取消之前的QoS策略应用),查看路由器是否打印配置冲突或配置不支持的提示信息。

¡     通过display命令查看QoS策略应用是否成功。

常见的QoS策略的配置未正确下发的提示信息分为以下几类:

a.     and类型的类中,定义的规则存在冲突。

<Sysname> terminal debugging

<Sysname> terminal monitor

[Sysname] system-view

[Sysname] undo qos apply policy p1 global inbound

[Sysname] qos apply policy p1 global inbound

[Sysname] %Mar 19 15:44:53:648 2014 Sysname QOS/4/QOS_POLICY_APPLYGLOBAL_CBFAIL:-MDC=1-Slot=6; Failed to apply classifier-behavior c1 in policy p1 to the inbound direction globally. In a classifier with AND operator, you cannot configure multiple ACL match rules.

上例中的提示信息说明and类型的类c1不支持定义多条ACL规则。此时也可以通过display命令也可以查看到当前QoS策略应用失败:

[Sysname] display qos policy global slot 3 inbound

 

  Direction: Inbound

 

  Policy: p1

   Classifier: c1 (Failed)

     Operator: AND

     Rule(s) :

      If-match acl 3000

      If-match acl 3001

     Behavior: b1

      Filter enable: Deny

对于此类问题,应该重新定义该类,并指定该类下的规则之间的逻辑为or。

b.     类中定义的某条规则不支持。

<Sysname> terminal debugging

<Sysname> terminal monitor

[Sysname] system-view

[Sysname] undo qos apply policy p1 global inbound

[Sysname] qos apply policy p1 global inbound

[Sysname] %Oct 14 03:07:56:955 2022 Sysname QOS/4/QOS_POLICY_APPLYGLOBAL_CBFAIL: -MDC=1-Slot=3; Failed to apply classifier-behavior c1 in policy p1 to the inbound direction globally. Customer-dot1p match rule is not supported.

上例中的提示信息说明不支持在全局QoS策略的入方向匹配customer-dot1p。此时也可以通过display命令也可以查看到当前QoS策略应用失败:

[Sysname] display qos policy global slot 3

 

  Direction: Inbound

 

  Policy: p1

   Classifier: c1 (Failed)

     Operator: AND

     Rule(s) :

      If-match customer-dot1p 3

      If-match acl 3000

     Behavior: b1

      Marking:

        Remark dscp 3

对于此类问题,应该删除类中不支持的规则。

c.     流行为中的动作冲突。

<Sysname> terminal debugging

<Sysname> terminal monitor

[Sysname] system-view

[Sysname] interface gigabitethernet6/0/12

[Sysname-GigabitEthernet6/0/12] undo qos apply policy p1 inbound

[Sysname-GigabitEthernet6/0/12] qos apply policy p1 inbound

[Sysname-GigabitEthernet6/0/12] %Mar 19 16:58:41:624 2014 Sysname QOS/4/QOS_POLICY_APPLYIF_CBFAIL: -MDC=1-Slot=6; Failed to apply classifier-behavior c1 in policy p1 to the inbound direction of interface GigabitEthernet6/0/12.Filter deny conflicts with redirect to CPU.

上例中的提示信息说明流行为中的filter  deny动作和redirect to cpu动作冲突。此时也可以通过display命令也可以查看到当前QoS策略应用失败:

[Sysname] display qos policy interface inbound

 

Interface: GigabitEthernet6/0/12

 

  Direction: Inbound

 

  Policy: p1

   Classifier: c1 (Failed)

     Operator: AND

     Rule(s) :

      If-match acl 3000

     Behavior: b1

      Filter enable: Deny

      Redirecting:

        Redirect to the CPU

对于此类问题,应该删除流行为中冲突的动作。

(3)     检查规则中的时间段

用户可以通过设置time-range字段来设定规则生效的时间范围。如果发现表项功能不生效,并且表项中带time-range字段,需要检查time-range配置的时间范围是否正确,检查方法介绍如下:

[Sysname] display time-range t1

Current time is 09:59:37 8/14/2013 Wednesday

Time-range: t1 (Inactive)

 09:25 to 09:30 working-day

此时发现时间段t1的状态是Inactive,说明系统当前时间在所设置的时间内未生效,需要修改时间段的时间范围。

(4)     检查QoS和ACL资源的使用情况

通过检查QoS和ACL资源的使用情况可以用来判断当前功能失效的原因是否是由于资源不足,下面介绍下资源检查的方法:

[Sysname] display qos-acl resource slot 3

Interfaces: GE3/3/1 to GE3/3/8, Pos3/4/1 to Pos3/4/4

---------------------------------------------------------------------

 Type             Total      Reserved   Configured Remaining  Usage

---------------------------------------------------------------------

 IPv4Acl          102400     0          70         102330     0%

 IPv6Acl          32768      0          7          32761      0%

 CAR&Cnt          131072     0          1          131071     0%

 InBRAS Stat      65534      0          0          65534      0%

 InL2TP Stat      65535      0          0          65535      0%

 EgBRAS Stat      65534      0          0          65534      0%

 EgL2TP Stat      65535      0          0          65535      0%

 IngSubIf Stat    65536      0          0          63536      3%

 EgSubIf Stat     65536      0          0          63536      3%

 CAR Prof         500        0          1          499        0%

 BRAS Prof        336        0          0          336        0%

 Sampler          131072     1          0          131071     0%

 INQPPB           32768      0          0          32768      0%

显示信息中Type表示资源类型,Total表示总的资源数,Configured表示使用资源数,Remaining表示剩余的资源数,Usage表示使用的百分比。

当剩余的资源数为0或者使用的百分比达到100%时,表示该类表项的资源不足。对于此类故障,请直接联系技术支持。

(5)     如仍还无法排查,请把故障信息发送给技术支持人员分析

12.1.2  802.1p优先级映射故障

1. 故障描述

在转发过程中,报文在设备上进行优先级映射后所携带的802.1p值与优先级映射表的配置不同。

图12-1所示的组网场景中,从Device A的GigabitEthernet3/1/1发出DSCP优先级为11的数据报文(源IP为A,目的IP为C),Device B的入接口GigabitEthernet3/1/1接收到该数据报文后,按照接口上应用的优先级映射关系将报文DSCP优先级映射为本地优先级。设备再根据本地优先级对报文进行队列调度,并从出接口GigabitEthernet3/1/2.10转发报文,在出接口上设备根据优先级映射关系,将本地优先级映射为报文的802.1p优先级3。最终在Device C上抓包发现接收到(源IP为A,目的IP为C)报文的802.1p优先级不为3,与Device B上优先级映射表配置不同。

图12-1 802.1p优先级映射故障示意图

 

2. 常见原因

本类故障的常见原因主要包括:

·     转发设备Device B上的报文出接口或者目的设备Device C的入接口不是三层子接口。

·     转发设备Device B上的报文入接口没有配置优先级信任模式为dscp或者auto。

·     转发设备Device B上的报文入接口的映射关系不正确。

·     转发设备Device B上的报文出接口的映射关系不正确。

3. 故障诊断流程

本类故障的诊断流程如图12-2所示。

图12-2 802.1p优先级映射的故障诊断流程图

 

4. 故障处理步骤

(1)     如图12-1所示的组网中,检查转发设备Device B上报文出接口及目的设备Device C的报文入接口是否为三层子接口。

在Device B和Device C上执行display interface brief命令检查转发设备Device B上出接口及目的设备Device C的入接口是否为三层子接口,如果Device B与Device C互联的主接口无对应的子接口,则需要在设备上执行interface interface-type interface-number.subnumber命令创建子接口。

<Sysname> display interface brief

Brief information on interfaces in route mode:

Link: ADM - administratively down; Stby - standby

Protocol: (s) - spoofing

Interface                         Link Protocol Primary IP      Description

GE3/1/1                           UP   UP(s)    --

GE3/1/2                           UP   UP(s)    --

GE3/1/2.100                       UP   UP(s)    --

GE3/1/3                           DOWN DOWN     --

GE3/1/4                           DOWN DOWN     --

InLoop0                           UP   UP(s)    --

MGE0/0/0                          DOWN DOWN     --

NULL0                             UP   UP(s)    --

在Device B和Device C上执行display subinterface命令检查上述子接口的VLAN终结信息。如果Device B和Device C对接的子接口未配置VLAN终结或者终结的VLAN ID范围不重叠,则在三层以太网子接口视图下执行vlan-type dot1q vid命令配置子接口VLAN终结功能,并指定相同的终结VLAN ID。例如:

<DeviceB> system-view

[DeviceB] interface gigabitethernet 3/1/2.100

[DeviceB-GigabitEthernet3/1/2.100] vlan-type dot1q vid 100

<DeviceC> system-view

[DeviceC] interface gigabitethernet 3/1/2.100

[DeviceC-GigabitEthernet3/1/2.100] vlan-type dot1q vid 100

如果子接口创建成功且子接口终结的VLAN ID相同,问题仍未解决,则请继续执行以下操作。

(2)     检查转发设备Device B上报文入接口GigabitEthernet3/1/1的优先级信任模式。

在Device B上执行display qos trust interface命令检查入接口GigabitEthernet3/1/1的优先级信任模式信息。Port priority trust type字段为dscp或auto时,则端口优先级信任模式正常。否则,在接口GigabitEthernet3/1/1下执行qos trust命令修改优先级的信任模式为dscp或auto。

<Sysname> display qos trust interface gigabitethernet 3/1/1

Interface: GigabitEthernet3/1/1

Port priority trust information

  Port priority:4

  Port priority trust type: dscp,  Override: enable

注意

如果在报文入接口直接使用dscp-dot1p映射方式进行优先级调度,且希望优先级映射后修改报文的dot1p优先级时,执行qos trust命令时需要指定override参数。

 

如果端口的优先级的信任模式正确,问题仍未解决,则请继续执行以下操作。

(3)     检查转发设备Device B上的入接口的优先级映射关系配置情况。

在DeviceB上执行display qos map-table interface命令检查报文入接口GE3/1/1上是否应用了灵活优先级映射表。接口上如果配置了灵活优先级映射表,则灵活优先级映射关系优先于全局优先级映射表生效。

<Sysname> display qos map-table interface gigabitethernet 3/1/1

Interface: GigabitEthernet3/1/1

  Direction: Inbound

  Map table name: aaa

¡     如果Direction字段显示为Inbound,且Map table name字段显示了灵活优先级映射表名称,则表示报文入接口的入方向上配置了用户定义的灵活优先级映射表aaa,请继续执行display qos map-table name命令检查入接口上应用的灵活优先级映射表中优先级映射关系。例如在如下显示信息中,可以看到dscp-lp类型的优先级映射关系为:dscp 11-> lp 1,表示入接口接收到dscp为11的报文被映射到本地优先级为1的队列中。记录上述dscp-lp的映射关系。并继续执行操作步骤(4)

<Sysname> display qos map-table name aaa

Map table name: aaa   Item: 4

Type         Import     Import Color     Export     Export Color

dscp-lp      10         None             2          None

dscp-lp      11         None             1          None

dot1p-lp     1          Red              0          None

dscp-dp      2          None             1          Yellow

¡     如果报文入接口未配置灵活优先级映射表或者入接口上仅存在出方向的灵活优先级映射表,即Direction字段显示为Outbound,则执行display qos map-table命令或display qos map-table color命令检查系统全局入方向应用的优先级映射关系。

<Sysname> display qos map-table inbound dscp-lp

MAP-TABLE NAME: dscp-lp   TYPE: pre-define   DIRECTION: inbound

IMPORT  :  EXPORT

   6    :    0

   7    :    0

   8    :    1

   9    :    1

  10    :    1

  11    :    1

  12    :    1

  13    :    1

在以上示例的显示信息中可以看到,全局dscp-lp类型的优先级映射关系为:dscp 11-> lp 1,表示入接口接收到dscp为11的报文被映射到本地优先级为1的队列中。记录上述dscp-lp的映射关系。并继续执行操作步骤(4)

(4)     检查转发设备Device B上的出接口的优先级映射关系配置情况。

在Device B上执行display qos map-table interface命令检查报文出接口GE3/1/2.10上是否应用了灵活优先级映射表。仅以下单板支持在接口出方向应用灵活优先级映射表。

CSPEX类单板(CSPEX-1104-E除外)、SPE类单板和CEPC类单板。

<Sysname> display qos map-table interface gigabitethernet 3/1/2.10

Interface: GigabitEthernet3/1/1.10

  Direction: Outbound

  Map table name: bbb

¡     如果Direction字段显示为Outbound,且Map table name字段显示了灵活优先级映射表名称,则表示报文出接口的出方向上配置了用户定义的灵活优先级映射表bbb,请继续执行display qos map-table name命令检查入接口上应用的灵活优先级映射表中优先级映射关系。然后根据上一步记录的dscp-lp的映射关系中Export字段为1,在如下显示信息中找到lp-dot1p类型的优先级映射关系Import字段为1的表项,发现对应的Export字段为3,表示出接口发送报文时,将本地优先级为1的队列中报文的dot1p值改为3。

<Sysname> display qos map-table name bbb

Map table name: bbb   Item: 2

Type         Import     Import Color     Export     Export Color

lp-dot1p     1          Green            3          None

lp-dot1p     2          Green            4          None

如果Export字段不为3,则在系统视图下执行qos map-table name命令进入该灵活优先级映射表视图,然后执行import命令修改lp-dot1p类型的优先级映射关系。

如果上述出接口的优先级映射关系配置正常,问题仍未解决,请继续执行以下操作。

(5)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件。

5. 告警与日志

相关告警

相关日志

12.1.3  MQC方式配置的QoS策略未生效

1. 故障描述

MQC方式配置的应用在接口的QoS策略未生效。

图12-3所示的组网场景中,从Device A的GE3/1/1.10发出的报文(源IP为A,目的IP为C)携带了VLAN Tag,报文外层VLAN中的dot1p优先级为3,Device B的入接口GE3/1/1.10接收到该数据报文后,按照接口上应用的QoS策略将丢弃外层VLAN中的dot1p优先级为3的报文,Device B出接口抓包发现报文未被丢弃,接口上应用的QoS策略不生效。

图12-3 MQC方式配置的QoS策略不生效组网示意图

 

2. 常见原因

本类故障的常见原因主要包括:

·     QoS策略中的流分类配置错误。

·     QoS策略中的流行为配置错误。

·     QoS策略应用不正确或应用失败。

·     QoS策略中的应用的多条流行为间互相冲突。

·     流分类中ACL规则匹配的流量执行了更高优先的策略。

3. 故障诊断流程

本类故障的诊断流程如图12-4所示。

图12-4 MQC方式配置的QoS策略不生效的故障诊断流程图

 

4. 故障处理步骤

(1)     在Device B上QoS策略的流行为中执行accounting命令来配置流量统计动作,执行display qos policy interface命令检查指定接口上流量是否匹配到QoS策略中的流分类规则。如下显示信息指定的流分类中Accounting enable字段表示接口上符合流分类规则的数据包数目,如果多次重复执行display qos policy interface命令Accounting enable字段不断变化,表示流量匹配到流分类规则,流分类规则配置正确,请继续执行步骤(3)。如果Accounting enable字段显示始终为0,则表示流量未匹配到流分类规则,QoS策略中的流分类配置可能存在错误,请继续执行步骤(2)

<Sysname> display qos policy interface gigabitethernet 3/1/1 inbound

Interface: GigabitEthernet3/1/1

  Direction: Inbound

  Policy: 1

   Classifier: 1

     Operator: AND

     Rule(s) :

      If-match acl 3000

     Behavior: 1

      Accounting enable:

        0 (Bytes)

        0 (bps)

      Marking:

        Remark dscp 3

(2)     如图12-3所示的组网中,检查Device B上QoS策略中的流分类配置。

在Device B上执行display traffic classifier命令检查流分类的配置信息,显示字段Rule(s)中流分类规则为If-match service-dot1p 3,表示匹配外层VLAN中dot1p为3的报文。如果流分类的配置错误,则执行traffic classifier命令进入该流分类视图,并执行if-match命令修改流分类的匹配规则。

请确认Operator字段显示的各规则之间的逻辑关系是否准确。AND表示该流分类下的规则之间是逻辑与的关系,即数据包必须匹配全部规则才属于该类。OR表示该流分类下的规则之间是逻辑或的关系,即数据包匹配任一规则均属于该类。本例中,如果Rule(s)中流分类规则不止一条,且Operator显示字段为AND,则表示数据包必须匹配全部规则才属于该类。此时,请执行traffic classifier命令指定operator参数为or

<Sysname> display traffic classifier user-defined

 

  User-defined classifier information:

 

   Classifier: aaa (ID 103)

     Operator: AND

     Rule(s) :

      If-match service-dot1p 3

如果QoS策略中的流分类配置正确,问题仍未解决,则请继续执行以下操作。

(3)     检查Device B上QoS策略中的流行为的配置。

在Device B上执行display traffic behavior命令检查流行为的配置信息。显示信息中为Filter enable: Deny,表示对符合流分类规则的报文进行丢弃。如果流行为的配置错误,则执行traffic behavior命令进入该流行为视图,并执行filter命令修改流行为的转发动作。

<Sysname> display traffic behavior user-defined aaa

 

  User-defined behavior information:

 

    Behavior: aaa (ID 104)

      Filter enable: Deny

 

如果QoS策略中的流行为配置正确,问题仍未解决,则请继续执行以下操作。

(4)     检查Device B上的QoS策略的配置正确。

a.     在DeviceB上执行display qos policy命令检查QoS策略的配置信息。显示信息中Classifier字段和Behavior字段分别对应上述步骤中配置的正确的流分类和流行为,如果引用错误,则执行qos policy命令进入对应的QoS策略视图,执行classifier behavior命令来修改QoS策略引用的流分类和流行为。如果配置信息正确,请继续执行步骤b

<Sysname> display qos policy user-defined aaa

 

  User-defined QoS policy information:

 

  Policy: aaa (ID 104)

   Classifier: aaa (ID 0)

     Behavior: aaa

      Filter enable: Deny

b.     在DeviceB上执行display qos policy interface命令检查接口下应用的QoS策略的配置信息。如果接口上应用了错误的QoS策略,请在入接口GigabitEthernet3/1/1.10上执行undo qos apply policy命令删除错误配置,再执行qos apply policy命令应用正确的QoS策略。

<Sysname> display qos policy interface gigabitethernet 3/1/1.10 inbound

Interface: GigabitEthernet3/1/1.10

  Direction: Inbound

  Policy: aaa

   Classifier: aaa

     Operator: AND

     Rule(s) :

      If-match service-dot1p 3

     Behavior: aaa

      Filter enable: Deny

如果接口上未应用QoS策略,请执行display qos policy global命令检查全局入方向的QoS策略配置信息。如果全局应用了错误的QoS策略,执行undo qos apply policy global命令删除错误配置,再执行qos apply policy global命令应用正确的QoS策略。全局应用的QoS策略比接口下应用的QoS策略优先生效。

<Sysname> display qos policy global inbound

  Direction: Inbound

  Policy: aaa

   Classifier: aaa

     Operator: AND

     Rule(s) :

      If-match service-dot1p 3

     Behavior: aaa

      Filter enable: Deny

如果配置信息正确,请继续执行步骤c

c.     在DeviceB上执行display qos policy interface命令或display qos policy global命令检查QoS策略是否成功应用。请检查Classifier字段是否显示为Failed,如果显示为Failed,则表示QoS策略应用失败。

<Sysname> display qos policy interface gigabitethernet 3/1/1.10 inbound

Interface: GigabitEthernet3/1/1.10

  Direction: Inbound

  Policy: aaa

   Classifier: aaa (Failed)

     Operator: AND

     Rule(s) :

      If-match service-dot1p 3

     Behavior: aaa

      Filter enable: Deny

QoS策略应用失败可能是驱动不支持或资源不足等原因导致,此时请在系统视图下执行info-center enable命令打开信息中心,同时在系统视图下执行terminal monitor命令允许日志信息输出到控制台,收集系统提示和日志信息。同时也可以执行display qos-acl resource命令查看QoS和ACL资源的使用情况,如果Usage字段显示的预留的资源数与已配置的资源数之和占资源总数的百分比接近或等于100%,则表示QoS和ACL资源不足,请删除部分未应用的或无效的QoS策略和ACL规则。

<Sysname> display qos-acl resource

Interfaces: GE3/1/1 to GE3/1/2

---------------------------------------------------------------------

 Type             Total      Reserved   Configured Remaining  Usage

---------------------------------------------------------------------

 IPv4 ACL         2048       512        0          1536       25%

 IPv6 ACL         8192       1536       6656       0          100%

如果上述QoS策略的配置正确且QoS策略成功应用,问题仍未解决,请继续执行以下操作。

(5)     在DeviceB上执行display qos policy interface命令或display qos policy global命令检查应用的QoS策略中的流行为是否存在冲突。如果在同一接口或全局下为相同流量应用了多种不同的流行为时,一些的流行为之间存在冲突,从而导致QoS策略不生效。请根据以下冲突关系,执行对应的undo命令删除冲突流行为,再重新在接口或全局应用QoS策略使之生效。

本例中,如果filter deny动作同时应用在出方向和入方向,与filter deny动作存在冲突的常见流行为如下:

¡     任意方向流行为视图下存在以下流行为或命令之一:remark dscpremark ip-precedenceremark dot1premark drop-precedenceremark local-precedenceremark mpls-expredirect cpucar、CBQ基于类的队列命令。

¡     在入方向存在以下流行为或命令之一:remark tunnel-dscpredirect failover-groupredirect http-to-cpuredirect https-to-cpu

¡     在出方向存在以下流行为或命令之一:redirect next-hopredirect vpn-instance

在一些其他场景中,如果配置了CBQ基于类的队列命令同时应用在出方向和入方向时,与CBQ存在冲突的常见流行为有:

任意方向流行为视图下存在以下流行为或命令之一:filter denyremark local-precedenceremark dscpremark dot1premark mpls-expremark drop-precedenceremark ip-precedenceredirect cpucarredirect next-hopredirect vpn-instance

如果配置了redirect next-hop命令同时应用在出方向时,与重定向到下一跳存在冲突的常见流行为有:

在出方向流行为视图下存在以下流行为或命令之一:filter denyredirect cpuredirect vpn-instanceremark local-precedenceremark ip-precedenceremark mpls-expremark drop-precedence

流行为之间互相冲突情况较复杂,此处仅列举部分常见情况,如果上述QoS策略中不存在冲突流行为,问题仍未解决,请继续执行以下操作。

(6)     当流分类中引用ACL规则进行流量报文匹配时,也可能由于该ACL规则匹配到的流量报文执行了其他更高优先的策略行为导致MQC方式配置的QoS策略未生效,不同策略行为的优先顺序为:

全局应用报文过滤>入方向聚合口下应用报文过滤>入方向物理接口应用报文过滤>控制平面应用QoS策略>入方向聚合口下应用策略路由PBR>入方向物理接口应用策略路由PBR>入方向全局应用MQC方式配置的QoS策略>入方向物理接口应用MQC方式配置的QoS策略>出方向全局应用MQC方式的QoS策略>出方向聚合口应用MQC方式的QoS策略>出方向物理接口应用MQC方式的QoS策略>出方向全局应用报文过滤>出方向聚合口下应用报文过滤> 出方向端口应用报文过滤。

请执行display current-configuration命令检查当前生效的配置中是否存在上述更高优先级的策略行为相关配置。如果不存在相关配置,问题仍未解决,请继续执行以下操作。

(7)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、相关日志。

5. 告警与日志

相关告警

相关日志

·     QOS_POLICY_APPLYIF_CBFAIL

·     QOS_POLICY_APPLYIF_FAIL

·     QOS_POLICY_APPLYGLOBAL_CBFAIL

·     QOS_POLICY_APPLYGLOBAL_FAIL

12.1.4  接口下CBQ队列调度策略未生效

1. 故障描述

CBQ队列调度应用到接口下,不同队列实际分配的带宽未按照配置的调度策略生效。

图12-5所示的组网场景中,从Device A的三层聚合口Route-Aggregation1发出的数据报文中,IP头部DSCP取值为ef的报文(以下简称ef报文)流量速率为600Mbps,IP头部DSCP取值为af21的报文(以下简称af21报文)流量速率为400Mbps,IP头部DSCP取值为af11的报文(以下简称af11报文)流量速率为300Mbps。Device B接收到报文,并按照CBQ队列调度上述三类报文流量:

·     ef报文流量采用EF队列调度,保证带宽为600Mbps,WFQ调度权重为2;

·     af21报文流量采用AF队列调度,保证带宽为100Mbps,WFQ调度权重为1;

·     af11报文流量采用AF队列调度,保证带宽为100Mbps,WFQ调度权重为1。

Device B将报文从接口GE3/1/1转发到Device C时,出接口的带宽仅有1000Mbps,在出接口上会发生拥塞。按照CBQ队列相关配置调度结果是ef报文全部通过,速率为600Mbps,af21报文速率仅为200Mbps,af11报文速率仅为200Mbps。实际分析流量速率时,与配置的调度结果不同,CBQ队列调度策略未正常生效。

图12-5 接口下CBQ队列调度策略未生效组网示意图

 

2. 常见原因

本类故障的常见原因主要包括:

·     报文转发出接口下配置的最大预留带宽占可用带宽的百分比不正确。

·     报文转发出接口下应用的CBQ队列策略中的流分类配置错误。

·     报文转发出接口下应用的CBQ队列策略中保证带宽配置错误。

·     报文转发出接口下应用的CBQ队列策略中队列调度权重配置错误。

·     因其他配置或者流行为冲突导致CBQ队列策略应用失败。

3. 故障诊断流程

本类故障的诊断流程如图12-6所示。

图12-6 接口下CBQ队列调度策略未生效的故障诊断流程图

 

4. 故障处理步骤

(1)     检查Device B上报文转发出接口下配置的最大预留带宽占可用带宽的百分比。

在Device B的报文转发出接口上执行display this命令检查接口的配置信息。如果不存在qos reserved-bandwidth pct 100配置,则表示接口下最大可用的带宽为接口物理带宽×最大预留带宽占可用带宽的百分比。缺省情况下,接口的最大预留带宽占可用带宽的百分比为80。在图12-5所示的组网中,要求出接口上GE3/1/1最大可用带宽等于接口物理带宽,即最大预留带宽占可用带宽的百分比为100。如果不存在该配置或者配置错误,则在接口视图下执行qos reserved-bandwidth pct命令修改配置。

如果报文转发出接口下的最大预留带宽占可用带宽的百分比配置正确,问题仍未解决,则请继续执行以下操作。

(2)     检查Device B上报文转发出接口下应用的CBQ队列策略中的流分类配置。

在Device B上执行display traffic classifier user-defined命令检查用户定义的流分类的配置信息,在图12-5所示的组网中,需要定义三种流分类:

¡     匹配dscp为ef的报文的流分类,对应的流分类显示字段Rule(s)中流分类规则为If-match dscp ef;

¡     匹配dscp为af21的报文的流分类,对应的流分类显示字段Rule(s)中流分类规则为If-match dscp af21;

¡     匹配dscp为af11的报文的流分类,对应的流分类显示字段Rule(s)中流分类规则为If-match dscp af11;

如果流分类的配置错误,则执行traffic classifier命令进入该流分类视图,并执行if-match命令修改流分类的匹配规则。

请确认Operator字段显示的各规则之间的逻辑关系是否准确。AND表示该流分类下的规则之间是逻辑与的关系,即数据包必须匹配全部规则才属于该类。OR表示该流分类下的规则之间是逻辑或的关系,即数据包匹配任一规则均属于该类。本例中,如果Rule(s)中流分类规则不止一条,且Operator显示字段为AND,则表示数据包必须匹配全部规则才属于该类。此时,请执行traffic classifier命令指定operator参数为or

<Sysname> display traffic classifier user-defined

 

  User-defined classifier information:

 

   Classifier: ef (ID 101)

     Operator: AND

     Rule(s) :

      If-match dscp ef

 

   Classifier: af21 (ID 102)

     Operator: AND

     Rule(s) :

      If-match dscp af21

 

   Classifier: af11 (ID 103)

     Operator: AND

     Rule(s) :

      If-match dscp af11

 

如果QoS策略中的流分类配置正确,问题仍未解决,则请继续执行以下操作。

(3)     检查Device B上报文转发出接口下应用的CBQ队列策略中保证带宽配置和队列调度的权重配置。

在Device B上执行display traffic behavior命令检查流行为中的CBQ队列策略中保证带宽和队列调度的权重配置信息。在图12-5所示的组网中,需要定义三种队列的保证带宽和队列调度的权重:

¡     对于ef报文流量采用EF队列调度,保证带宽为600Mbps,队列调度权重为2,对应的流行为显示信息为Expedited Forwarding,Bandwidth值为600000 kbps,Queue weight显示为2;

¡     对于af21报文流量采用AF队列调度,保证带宽为100Mbps,队列调度权重为1,对应的流行为显示信息为Assured Forwarding,Bandwidth值为100000 kbps,Queue weight显示为1;

¡     对于af11报文流量采用AF队列调度,保证带宽为100Mbps,队列调度权重为1,对应的流行为显示信息为Assured Forwarding,Bandwidth值为100000 kbps,Queue weight显示为1;

如果流行为的配置错误,则执行traffic behavior命令进入配置错误的流行为视图,根据错误的调度规则执行以下操作:

¡     如果ef报文流量采用EF队列调度的保证带宽配置错误,则执行queue ef命令修改EF队列调度的保证带宽;

¡     如果af21报文流量或af11报文流量采用AF队列调度的保证带宽配置错误,则执行queue af命令修改AF队列调度的保证带宽;

¡     如果队列调度权重配置错误,则执行weight命令修改队列调度权重。

<Sysname> display traffic behavior user-defined

 

  User-defined behavior information:

 

    Behavior: ef (ID 108)

      Expedited Forwarding:

        Bandwidth 600000 (kbps) CBS 15000000 (Bytes)

        Discard Method: Tail drop

        Queue weight: 2

 

    Behavior: af21 (ID 109)

      Assured Forwarding:

        Bandwidth 100000 (kbps)

        Discard Method: Tail drop

        Queue weight: 1

 

    Behavior: af11 (ID 110)

      Assured Forwarding:

        Bandwidth 100000 (kbps)

        Discard Method: Tail drop

        Queue weight: 1

 

如果CBQ队列策略中保证带宽配置和队列调度的权重配置正确,问题仍未解决,则请继续执行以下操作。

(4)     检查Device B上报文转发出接口下应用CBQ队列调度策略是否正确,详细操作方式请参见“MQC方式配置的QoS策略未生效”的处理步骤。

本例中,接口下如果同时存在qmprofile队列调度策略配置和CBQ队列调度策略,对于同一类流量,两者之间调度策略可能存在冲突进而导致CBQ队列调度策略应用失败,此时可参见“MQC方式配置的QoS策略未生效”中QoS策略应用失败和流行为应用冲突的处理步骤处理。

请在Device B上执行display qos queue-statistics interface outbound命令收集并记录端口队列出方向各队列的统计信息。

Device B上报文转发出接口下应用CBQ队列调度策略正确且成功应用后,问题仍未解决,则请继续执行以下操作。

(5)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息。

5. 告警与日志

相关告警

相关日志

·     QOS_NOT_ENOUGH_BANDWIDTH

·     QOS_POLICY_APPLYIF_CBFAIL

·     QOS_POLICY_APPLYIF_FAIL

12.1.5  QoS队列拥塞丢包

1. 故障描述

QoS常见故障现象为队列拥塞/丢包。

2. 故障处理步骤

(1)      检查缓存是否达到队列缓存门限

通过display qos queue-statistics interface outbound命令查询队列的统计计数信息,确认队列深度是否达到队列缓存门限。

(2)      检查队列或者端口是否有限速相关配置。

<Sysname> display qos lr interface

Interface: GigabitEthernet3/1/1

 Direction: Outbound

  CIR 10000 (kbps), CBS 625000 (Bytes)

<Sysname> display qos gts interface

Interface: GigabitEthernet3/1/1

 Rule: If-match queue 1

  CIR 10000 (kbps), CBS 625000 (Bytes)

(3)      检查端口是否有应用User Profile相关配置。

<Sysname> display user-profile interface gigabitethernet 3/1/1

Interface: GigabitEthernet3/1/1

  User Profile: test

    Direction: Inbound

      Committed Access Rate(active):

        CIR 112 (kbps), CBS 5120 (Bytes), EBS 512 (Bytes)

        Green action  : pass

        Yellow action : pass

        Red action    : discard

        Green packets : 0 (Packets) 0 (Bytes)

        Yellow packets: 0 (Packets) 0 (Bytes)

        Red packets   : 0 (Packets) 0 (Bytes)

      Policy(inactive): p

      User queue:

        Limit Rate(inactive):

          CIR 3000 (kbps), CBS 187500 (Bytes), EBS 0 (Bytes), PIR 40000 (kbps)

        QMProfile(inactive):

          a

    Direction: Outbound

      Committed Access Rate(active):

        CIR 112 (kbps), CBS 5120 (Bytes), EBS 512 (Bytes)

        Green action  : pass

        Yellow action : pass

        Red action    : discard

        Green packets : 0 (Packets) 0 (Bytes)

        Yellow packets: 0 (Packets) 0 (Bytes)

        Red packets   : 0 (Packets) 0 (Bytes)

      Policy(inactive): p

      User queue:

        Limit Rate(active):

          CIR 3000 (kbps), CBS 187500 (Bytes), EBS 0 (Bytes), PIR 40000 (kbps)

          Queue length: 3000 (Packets)

        QMProfile(active):

          a

        User group profile(inactive): gg

      Qos Weight(inactive): 2

      Queue Name(inactive): af3

    IGMP access policy:

      3000

    MLD access policy:

      3000

    Authentication-free rule:

      acl 3000

(4)     如仍还无法排查,请把故障信息发送给技术支持人员分析


13 可靠性故障处理

13.1  CFD故障

13.1.1  二层VPN组网的CFD故障

1. 故障描述

·     连通性检测不通。

·     单向丢包或者双向丢包统计不准。

·     单向时延或双向时延测试不准

2. 故障处理步骤

(1)     检查L2VPN组网是否正常

CFD功能基于二层VPN组网配置的,CFD功能故障时,先排查对应的L2VPN组网是否正常,如AC/PW状态是否都UP。

(2)     检查不同PE的CFD配置是否对应

a.     检查CFD配置是否对应

不同PE之间配置的CFD,要求MD/MA名称和层级、关联的L2VPN业务、检测的方向、检测的时间间隔、MEP列表完全相同,本地配置的MEP应该就是远端配置的RMEP,可以通过display cfd service-instance命令行查询:

<Sysname> display cfd service-instance 1

Service instance 1:

Maintenance domain: y1

Maintenance domain index: 1

Maintenance association: y1

Maintenance association index: 1

Vsi: y1

Level: 6        MIP rule: NONE    CCM interval: 1s

Direction: Inbound

MEP ID: 2001 Interface: Ten-GigabitEthernet8/2/3.20

b.     检查源MEP和目标MEP上配置的报文统计模式是否一致

c.     单向时延不准时需要检查设备间是否配置了PTP功能使时间同步

(7)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

13.2  BFD转发故障

13.2.1  故障描述

·     BFD会话没有创建。

·     BFD会话一直显示状态为DOWN。

·     BFD会话震荡。

13.2.2  故障诊断流程

 

13.2.3  故障处理步骤

BFD配置配在两台设备或两个节点上,首先要保证两个节点在物理链路上可达,检查两节点之间的连接是否正确。

1. 协议配置

(1)     首先检查各个节点之间的可达性,如不可达,请检查物理连接或接口上的配置。

<Sysname> ping 50.1.1.2

Ping 50.1.1.2 (50.1.1.2): 56 data bytes, press CTRL_C to break

56 bytes from 50.1.1.2: icmp_seq=0 ttl=255 time=1.722 ms

56 bytes from 50.1.1.2: icmp_seq=1 ttl=255 time=5.531 ms

56 bytes from 50.1.1.2: icmp_seq=2 ttl=255 time=1.553 ms

56 bytes from 50.1.1.2: icmp_seq=3 ttl=255 time=1.646 ms

56 bytes from 50.1.1.2: icmp_seq=4 ttl=255 time=1.561 ms

 

--- Ping statistics for 50.1.1.2 ---

5 packet(s) transmitted, 5 packet(s) received, 0.0% packet loss

round-trip min/avg/max/std-dev = 1.553/2.403/5.531/1.565 ms

(2)     查看BFD服务的上层协议是否UP,如果没有UP,请检查相关协议的配置。

如果配置和路由协议联动的BFD,请检查路由协议的状态,如下(此处以OSPF为例):

<Sysname> display ospf peer

 

          OSPF Process 1 with Router ID 43.43.43.43

               Neighbor Brief Information

 

 Area: 0.0.0.0

 Router ID       Address         Pri Dead-Time  State             Interface

 15.15.15.22     50.1.1.2        1   36         Full/BDR          GE3/1/4

 

如果是和隧道进行联动,请查看隧道的状态,如下(此处以TE隧道为例):

<Sysname> display interface Tunnel brief

Brief information on interfaces in route mode:

Link: ADM - administratively down; Stby - standby

Protocol: (s) - spoofing

Interface            Link Protocol Primary IP         Description

Tun22                UP   UP       --

2. BFD配置

(1)     检查是否配置了BFD会话的使能配置。(以TE BFD为例)。

对于BFD会话,和不同的上层协议联动,BFD使能的配置不一样,配置的视图也不一样,如TE BFD会话的使能配置是在系统视图下和tunnel接口视图下,如下:

[Sysname] mpls bfd enable

[Sysname] interface tunnel 22 mode mpls-te

[Sysname-Tunnel22] mpls bfd

(2)     其它的配置对BFD会话的影响。

URPF配置:当echo报文源IP地址不是本设备上的IP地址时,不能配置uRPF功能。

Easy IP:配置BFD功能的接口不能开启Easy IP 功能,否则可能导致BFD功能不能正常使用。

QinQ终结:配置BFD功能的三层以太网子接口、三层聚合子接口不能配置QinQ终结功能。

QoS配置:BFD会话建立后,需要在CSPC类单板、CSPEX-1812X单板、CSPEX-1104-E单板、CEPC类单板、CSPEX-1602X单板、CSPEX-1404S、CSPEX-1404X单板、CSPEX-1504S、CSPEX-1504X单板或SPEX1204单板上查询转发表项,此时在该单板上的接口配置QoS策略如使用qos lr命令配置限速,会导致对端收到BFD报文有延时而出现BFD出现震荡的现象。

VLAN配置:对于VLAN接口上的BFD会话,某些STP配置(如配置STP的接口不允许配置BFD会话的接口所在VLAN的报文通过)也会导致BFD报文在设备内部进行转发时出现丢弃。

如果链路一端配置了ECHO BFD会话,建议在对端接口上使用qos trust命令配置优先级信任模式。否则,当对端接口上出现拥塞时,ECHO BFD报文在对端可能会因为优先级较低而出现丢包的现象。

与华为设备对接建立多跳BFD会话,华为设备上,在BFD视图下配置peer-ip的TTL参数为255即可。命令如下:peer-ip ip-address mask-length ttl multi-hop 255 。


14 用户接入与认证类故障处理

14.1  Password Control故障处理

14.1.1  管理员登录时系统要求修改密码

1. 故障描述

管理员采用本地认证方式登录设备时,系统判断密码强度不符合要求,提示用户修改当前的登录密码。

2. 常见原因

本类故障的常见原因主要包括:

·     本地用户视图下配置的Password Control密码检查强度高。

·     本地用户组视图下配置的Password Control密码检查强度高。

·     系统视图下配置的Password Control密码检查强度高。

3. 故障分析

本类故障的诊断流程如图14-1所示。

图14-1 管理员登录时要求修改密码故障诊断流程图

 

4. 处理步骤

(1)     判断是否降低当前密码检查强度。

开启全局密码管理功能后,通过Telnet、SSH方式登录的设备管理类用户,输入登录密码时,系统会根据当前设定的Password control密码组合检测策略、密码最小长度限制以及密码复杂度检查策略检查对用户的登录密码进行检查,若不符合以上密码检查策略要求,则视为弱密码。系统缺省的密码检查策略请查看“安全配置指导”中的“Password Control”。

缺省情况下,用户使用弱密码登录设备时,系统会打印弱密码提示信息。如果当前的密码检查强度高于实际登录控制需求,请在确定修改范围(指定的本地用户、指定的用户组、所有本地用户)之后,按照如下步骤降低相应视图下的密码检查强度。

(2)     降低本地用户的Password Control密码检查强度。

执行local-user命令,进入本地用户视图:

¡     通过password-control composition命令配置密码组合策略(下例中密码元素的最少组合类型为4种,至少要包含每种元素的个数为5个

¡     通过password-control length命令配置密码最小长度(下例中密码最小长度为16个字符

¡     通过password-control complexity命令配置密码复杂度检查策略(下例中为检查密码中是否包含用户名)。

<Sysname> system-view

[Sysname] local-user test class manage

[Sysname-luser-manage-test] password-control composition type-number 4 type-length 5

[Sysname-luser-manage-test] password-control length 16

[Sysname-luser-manage-test] password-control complexity user-name check

(3)     降低用户组的Password Control密码检查强度。

执行user-group命令,进入本地用户视图:

¡     通过password-control composition命令配置密码组合策略

¡     通过password-control length命令配置密码最小长度

¡     通过password-control complexity命令配置密码复杂度检查策略。

(4)     降低所有本地用户的Password Control密码检查强度。

在系统视图下:

¡     通过password-control composition命令配置密码组合策略

¡     通过password-control length命令配置密码最小长度

¡     通过password-control complexity命令配置密码复杂度检查策略。

(5)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、诊断信息、提示信息。

5. 告警与日志

相关告警

相关日志

14.1.2  创建本地用户或配置用户密码失败

1. 故障描述

创建本地用户失败,系统打印提示信息“Add user failed.”。

配置本地用户密码失败,系统打印提示信息“Operation failed.”。

2. 常见原因

本类故障的常见原因主要包括:

·     设备的内存使用率达到指定门限。

·     设备的本地文件系统存储空间不足。

·     设备本地的lauth.dat文件异常。

3. 故障分析

本类故障的诊断流程如图14-2所示。

图14-2 创建本地用户或配置密码失败故障诊断流程图

 

4. 处理步骤

(1)     检查设备剩余空闲内存值是否进入指定的内存门限。

如果是修改本地用户密码失败,则无需关注内存门限问题,直接进入步骤(2)。

执行display memory-threshold命令查看显示内存告警门限相关信息,通过“Current free-memory state:”字段查看当前内存使用状态。系统内存进入一级(Minor)、二级(Severe)、三级(Critical)告警门限状态期间,不允许创建本地用户。

<Sysname> display memory-threshold

Memory usage threshold: 100%

Free-memory thresholds:

    Minor: 96M

    Severe: 64M

    Critical: 48M

    Normal: 128M

    Early-warning: 144M

    Secure: 160M

 

Current free-memory state: Normal (secure)

...

可在任意视图下通过执行monitor process命令查看进程统计信息,输入“m”后按照显示的内存排序定位占用内存资源过多的进程,按需进行内存清理。等待内存门限解除后,再次尝试创建本地用户。

(2)     检查设备的本地文件系统存储空间是否不足。

如果设备上输出如下任意一类日志信息,则表示文件系统异常导致此问题:

¡     PWDCTL/3/PWDCTL_FAILED_TO_OPENFILE: Failed to create or open the password file.

¡     PWDCTL/3/PWDCTL_FAILED_TO_WRITEPWD: Failed to write the password records to file.

¡     PWDCTL/3/PWDCTL_NOENOUGHSPACE: Not enough free space on the storage media where the file is located.

请在用户视图下执行dir命令查看本地存储介质(例如flash)的剩余容量信息,如果剩余空间不足,则需要删除无用的文件。

(3)     检查本地lauth.dat文件是否正常。

开启全局密码管理功能后,设备会自动生成lauth.dat文件记录本地用户的认证、登录信息。如果手工删除或修改该文件,会造成本地认证异常。请在用户视图下执行dir命令查看本地存储介质中(例如flash)的lauth.dat文件存在情况。

<Sysname> dir

Directory of flash: (EXT4)

   0 drw-           - Aug 16 2021 11:45:37   core

   1 drw-           - Aug 16 2021 11:45:42   diagfile

   2 drw-           - Aug 16 2021 11:45:57   dlp

   3 -rw-         713 Aug 16 2021 11:49:41   ifindex.dat

   4 -rw-         12  Sep 01 2021 02:40:01   lauth.dat

...

如果该文件不存在、大小为0或者很小(若小于20B,则大概率发生了异常),请优先联系技术支持人员协助处理,若当前配置需求紧迫,可尝试重新开启全局密码管理功能来解决此问题。

<Sysname> system-view

[Sysname] undo password-control enable

[Sysname] password-control enable

以上问题解决后,请尝试重新创建本地用户或配置用户密码。

(4)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、诊断信息、提示信息。

5. 告警与日志

相关告警

相关日志

·     PWDCTL/3/PWDCTL_FAILED_TO_WRITEPWD

·     PWDCTL/3/PWDCTL_FAILED_TO_OPENFILE

·     PWDCTL/3/PWDCTL_NOENOUGHSPACE

14.1.3  管理员因闲置超时无法登录

1. 故障描述

管理员采用本地认证方式登录设备时,因账户闲置超时无法成功登录,系统打印提示信息“Failed to login because the idle timer expired.”。

2. 常见原因

本类故障的主要原因为,用户自从最后一次成功登录之后,在配置的闲置时间内再未成功登录过,那么该闲置时间到达之后此用户账号立即失效,系统不再允许使用该账号的用户登录。

3. 故障分析

本类故障的诊断流程如图14-3所示。

图14-3 管理员因闲置超时无法登录故障诊断流程图

 

4. 处理步骤

(1)     确认是否有其它管理员或其它途径可以登录设备。

¡     如果有其它管理员或其它途径(例如Console口)可以登录设备,则表示仅该用户被禁止登录,因此可以由其它管理员登录后删除该本地用户后重新创建此用户,或修改用户账号的闲置时间(通过password-control login idle-time命令)。若将闲置时间修改为0,则会立即关闭闲置超时检查。

¡     如果无其它管理员或其它途径可以登录设备,则执行步骤(2)。

(2)     确认设备是否开启了SNMP功能。

尝试是否可以通过NMS(Network Management System,网络管理系统)登录设备:

¡     若开启了SNMP功能,则可以使用MIB修改系统时间,将系统时间修改为闲置超时之前的某个时间点,再使用此管理员帐号登录设备。修改系统时间对应的MIB节点为HH3C-SYS-MAN-MIB中的hh3cSysLocalClock (1.3.6.1.4.1.25506.2.3.1.1.1)。

管理员再次成功登录后,需要第一时间将系统时间恢复,并关闭用户账号闲置超时检查。

¡     若未开启SNMP功能,则无法使用MIB。可尝试重启设备,并按提示进入BootWare扩展段菜单后,选择跳过console口认证或者跳过配置文件选项来进入系统。建议在技术支持人员指导下执行此步骤。

(3)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、诊断信息、提示信息。

5. 告警与日志

相关告警

相关日志

14.2  AAA故障处理

14.2.1  登录设备后无法执行部分命令行

1. 故障描述

管理员登录设备后没有部分命令行的执行权限,系统打印提示信息 “Permission denied.”。

2. 常见原因

本类故障的主要原因为,给用户授权的用户角色权限过小。

3. 故障分析

本类故障的诊断流程如图14-4所示。

图14-4 登录后无法执行部分命令行的故障诊断流程图

 

4. 处理步骤

(1)     检查用户角色否为自定义用户角色。

请以超级管理员身份(即具有network-admin、或者level-15用户角色)登录设备,执行display line命令查看登录用户线的认证方式,并根据不同的认证方式,采取不同的处理步骤:

<Sysname> display line

  Idx  Type     Tx/Rx      Modem Auth  Int          Location

  0    CON 0    9600       -     N     -            0/0

+ 81   VTY 0               -     N     -            0/0

+ 82   VTY 1               -     P     -            0/0

+ 83   VTY 2               -     A     -            0/0

...

¡     对于nonepassword认证方式(Auth字段:NP),检查对应用户线视图下的用户角色是否为自定义用户角色。如果不是自定义用户角色,则通过user-role role-name命令设置权限更高的系统预定义角色。

¡     对于scheme认证方式(Auth字段:A),首先查看登录用户认证域下配置的认证方法:

-     如果采用了Local认证方法,则通过display local-user命令查看用户角色是否为自定义用户角色。如果不是自定义用户角色,则通过authorization-attribute user-role role-name命令设置权限更高的系统预定义角色(下例为network-admin)。

<Sysname> system-view

[Sysname] local-user test class manage

[Sysname-luser-manage-test] authorization-attribute user-role network-admin

-     如果采用了远程认证方法,则联系远程认证服务器管理员,为用户授权权限更高的系统预定义角色。

(2)     检查不允许执行的命令行是否在自定义用户角色允许的权限范围内。

a.     执行命令display role name role-name,查看用户的自定义角色拥有的命令行权限规则。

b.     如果用户所执行的命令行不在所属用户角色拥有的命令行权限范围之内,则为其更换权限较高的系统域定义用户角色,或者通过命令rule为用户的自定义角色增加对应的命令行权限规则。需要注意的是,自定义用户角色即使配置了较高的权限规则,仍然有部分无法支持的命令行,这些命令行的明细请查看“基础配置指导”中的“RBAC”手册。

(3)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

5. 告警与日志

相关告警

相关日志

14.2.2  登录设备后无法创建或修改本地用户

1. 故障描述

管理员登录设备后无法创建或修改本地用户,系统打印提示信息“Insufficient right to perform the operation.”。

2. 常见原因

本类故障的主要原因为,给用户授权的用户角色权限不具备修改目标本地用户配置的权限。

3. 故障分析

本类故障的诊断流程如图14-5所示。

图14-5 登录后无法创建或修改本地用户的故障诊断流程图

 

4. 处理步骤

(1)     检查登录用户的角色是否为预定义的超级管理员角色,即为network-admin、level-15之一。

只有上述预定义用户角色才拥有创建本地用户的权限,其它用户角色只有进入自身本地用户视图的权限。如果登录用户不拥有如上预定义用户角色,则为其授权其中之一。如果重新授权后,故障仍未排除,请继续定位。

此步骤仅适用于无权限创建本地用户,若无权限修改本地用户,请执行步骤(2)。

(2)     比较登录用户和目标用户的权限范围。

执行命令display role name role-name,分别查看登录用户和目标用户的角色权限,并比较两者的权限大小。如果操作者权限较小,则为其更换拥有更高权限的用户角色。

(3)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

5. 告警与日志

相关告警

相关日志

·     LOCAL/5/LOCAL_CMDDENY

14.2.3  管理员未被授权用户角色

1. 故障描述

管理员无法成功登录设备,设备也没有提供三次登录尝试机会。例如,使用Telnet登录时,用户输入用户名和密码后,设备登录界面上既未打印提示信息“AAA authentication failed”,也未再次提示用户输入用户名和密码。

2. 常见原因

本类故障的主要原因为,没有为用户授权用户角色。

3. 故障分析

本类故障的诊断流程如图14-6所示。

图14-6 管理员未被授权用户角色的故障诊断流程图

 

4. 处理步骤

(1)     检查是否为用户授权了用户角色。

请以超级管理员身份(即具有network-admin或者level-15用户角色)登录设备,执行display line命令查看登录用户线的认证方式,并根据不同的认证方式,采取不同的处理步骤:

<Sysname> display line

  Idx  Type     Tx/Rx      Modem Auth  Int          Location

  0    CON 0    9600       -     N     -            0/0

+ 81   VTY 0               -     N     -            0/0

+ 82   VTY 1               -     P     -            0/0

+ 83   VTY 2               -     A     -            0/0

...

¡     对于nonepassword认证方式Auth字段:NP),检查对应用户线视图下是否存在用户角色配置。如果不存在,则通过user-role role-name命令设置用户角色(下例中为abc)。

<Sysname> system-view

[Sysname] line vty 0 63

[Sysname-line-vty0-63] user-role abc

¡     对于scheme认证方式(Auth字段:A),首先查看登录用户认证域下配置的认证方法:

-     如果采用了Local认证方法,则执行display local-user命令查看该用户的授权用户角色情况,如果显示信息中的“User role list:”字段为空,则表示该用户没有被授权任何用户角色。

<Sysname> display local-user user-name test class manage

Total 1 local users matched.

 

Device management user test:

  State:                     Active

  Service type:              Telnet

  User group:                system

  Bind attributes:

  Authorization attributes:

    Work directory:          flash:

    User role list:

...

此时,需要进入该本地用户视图,执行authorization-attribute user-role命令为用户授权角色(下例中为abc)。

<Sysname> system-view

[Sysname] local-user test class manage

[Sysname-luser-manage-test] authorization-attribute user-role abc

-     如果采用了远程认证方法,则联系远程认证服务器管理员确认是否为该用户授权了用户角色,若无,请为该用户添加用户角色属性。以Free RADIUS服务器为例,如果需要在users文件中添加用户角色network-admin,则需要编辑的脚本如下:

user  Cleartext-Password := "123456"

      H3C-User-Roles ="shell:roles=\"network-admin\""

其它RADIUS服务器上的用户角色添加方式请以实际情况为准。

(2)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

5. 告警与日志

相关告警

相关日志

14.2.4  登录用户名含有非法字符

1. 故障描述

管理员登录设备失败,系统打印如下形式的日志信息:

Sysname LOGIN/5/LOGIN_INVALID_USERNAME_PWD: -MDC=1; Invalid username or password from xx.xx.xx.xx.

2. 常见原因

本类故障的主要原因为,用户输入的用户名中含有非法字符。

3. 故障分析

本类故障的诊断流程如图14-7所示。

图14-7 登录用户名含有非法字符的故障诊断流程图

 

4. 处理步骤

说明

本处理步骤仅适用于SSH及Telnet登录用户。

 

(1)     检查用户输入的用户名是否含有非法字符。

用户登录设备时,系统会检查用户输入的纯用户名以及域名的有效性,如果纯用户名中包含了非法字符“\”、“|”、“/”、“:”、“*”、“?”、“<”、“>”和“@”,域名中包含“@”,则不允许登录。此时,建议用户再次尝试登录,并输入正确的用户名。

(2)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

5. 告警与日志

相关告警

相关日志

·     LOGIN_INVALID_USERNAME_PWD

14.2.5  本地用户名或密码错误

1. 故障描述

管理员采用本地认证方式登录设备失败。如果设备上同时打开了Local-Server的事件调试信息开关(通过执行debugging local-server event命令),系统会打印如下形式的调试信息:

*Aug 18 10:36:58:514 2021 Sysname LOCALSER/7/EVENT: -MDC=1;

 Authentication failed, user password is wrong.

或者

*Aug 18 10:37:24:962 2021 Sysname LOCALSER/7/EVENT: -MDC=1;

 Authentication failed, user "t4" doesn't exist.

2. 常见原因

本类故障的常见原因主要包括:

·     用户输入的密码错误。

·     本地用户名不存在。

3. 故障分析

本类故障的诊断流程如图14-8所示。

图14-8 本地用户名或密码错误的故障诊断流程图

 

4. 处理步骤

(1)     检查本地用户名是否存在。

执行display local-user命令查看是否存在与登录用户名相同的设备管理类本地用户。

¡     如果不存在该本地用户,则需要使用local-user命令创建设备管理类本地用户(下例中用户名为test),并通知该用户再次尝试登录设备。

<Sysname> system-view

[Sysname] local-user test class manage

[Sysname-luser-manage-test]

¡     如果存在该本地用户,请执行步骤(2)。

(2)     确认本地用户密码是否正确。

如果用户登录时系统提示密码错误,则进入对应的本地用户视图后,执行password命令重置密码(下例中为123456TESTplat&!),并通知该用户再次尝试登录设备。

<Sysname> system-view

[Sysname] local-user test class manage

[Sysname-luser-manage-test] password simple 123456TESTplat&!

(3)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息、调试信息。

5. 告警与日志

相关告警

相关日志

14.2.6  本地用户的服务类型不匹配

1. 故障描述

管理员采用本地认证方式登录设备失败。如果设备上同时打开了Local-Server的事件调试信息开关(通过执行debugging local-server event命令),系统会打印如下形式的调试信息::

*Aug  7 17:18:07:098 2021 Sysname LOCALSER/7/EVENT: -MDC=1;  Authentication failed, unexpected user service type 64 (expected = 3072).

2. 常见原因

本类故障的主要原因为,用户的接入类型与设备上配置的本地用户服务类型不匹配,即用户的接入类型不在配置的服务类型范围之内。

3. 故障分析

本类故障的诊断流程如图14-9所示。

图14-9 本地用户服务类型不匹配的故障诊断流程图

 

4. 处理步骤

(1)     检查用户接入类型是否在本地用户配置的服务类型范围之内。

a.     执行display local-user命令查看本地用户的配置信息,用户服务类型由“Service type:”字段标识。

<Sysname> display local-user user-name test class manage

Total 1 local users matched.

 

Device management user test:

  State:                     Active

  Service type:              Telnet

  User group:                system

  Bind attributes:

  Authorization attributes:

    Work directory:          flash:

    User role list:

...

b.     在该用户的本地用户视图下,通过执行service-type type命令修改用户的服务类型为实际使用的接入类型(下例中为SSH)。

<Sysname> system-view

[Sysname] local-user test class manage

[Sysname-luser-manage-test] service-type ssh

(2)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息、调试信息。

5. 告警与日志

相关告警

相关日志

14.2.7  登录失败固定次数后,被禁止在指定的时间内再次登录

1. 故障描述

管理员登录设备失败指定的次数后,在一定时间内被禁止再次登录设备。

2. 常见原因

本类故障的常见原因主要包括:

·     设备上开启了Login用户攻击防范功能。开启该功能后,会导致Login用户登录失败指定的次数后,若用户的IP地址被加入黑名单,则设备将会丢弃来自该IP地址的报文,使得该用户不能在指定的阻断时长内进行登录操作。

·     用户采用本地认证方式登录设备,且设备上开启了Password Control功能。用户登录认证失败后,系统会将该用户加入密码管理的黑名单,并根据配置的处理措施对其之后的登录行为进行相应的限制。当用户登录失败次数超过指定值后,系统禁止该用户登录,经过一段时间后,再允许该用户重新登录。

3. 故障分析

本类故障的诊断流程如图14-10所示。

图14-10 指定时间内被阻断登录的故障诊断流程图

 

4. 处理步骤

(1)     等待一定时间后,尝试重新登录。

如果因为偶尔密码输入有误导致的禁止登录,属于正常现象,建议等待一定的时间后再次尝试重新登录。如果再次使用正确的用户名和密码登录设备遇到同样的问题,请更换其它可登录设备的管理员账号继续下面的处理步骤。

(2)     确认用户被阻断后能否发起登录连接。

¡     如果该用户被阻断后,仍然可以向设备发起登录连接,但无法认证成功,则在任意视图下执行display password-control blacklist命令查看该用户是否被加入了黑名单。如果该用户在黑名单中,且显示信息中的Lock flag为lock,则表示用户被锁定了。

<Sysname> display password-control blacklist

 Per-user blacklist limit: 100.

 Blacklist items matched: 1.

 Username                 IP address           Login failures   Lock flag

 test                      3.3.3.3              4                   lock

对于加入黑名单的用户,有两种处理方式:

-     在系统视图下执行undo password-control enable命令关闭全局密码管理功能。

<Sysname> system-view

[Sysname] undo password-control enable

-     在用户视图下执行reset password-control blacklist命令清除密码管理黑名单中的用户(下例中为用户test)。

<Sysname> reset password-control blacklist user-name test

¡     如果该用户被阻断后,根本无法向设备发起登录连接,则执行步骤(3)。

(3)     检查是否开启了Login用户攻击防范功能。

如果当前配置中存在attack-defense login开头的相关命令,则可以根据需要关闭Login用户攻击防范功能,或者改变Login用户登录连续失败的最大次数以及登录失败后的阻断时长。

¡     通过执行undo attack-defense login enable命令关闭Login用户攻击防范功能,并通过执行undo blacklist global enable命令关闭与之配合的全局黑名单过滤功能。

<Sysname> system-view

[Sysname] undo attack-defense login enable

[Sysname] undo blacklist global enable

¡     通过执行attack-defense login max-attempt命令增加连续登录失败的最大次数,增大用户登录的尝试机会(下例为5次)。

<Sysname> system-view

[Sysname] attack-defense login max-attempt 5

¡     通过执行attack-defense login block-timeout命令减小阻断时长(下例为1分钟),让用户尽快重新登录。

<Sysname> system-view

[Sysname] attack-defense login block-timeout 1

执行以上操作可能会减弱设备防范Login用户DoS攻击的力度,请慎重执行。

(4)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

5. 告警与日志

相关告警

相关日志

14.2.8  登录失败后需要等待一定时长再进行重认证

1. 故障描述

管理员登录设备失败后,控制台无响应一定的时间,期间用户无法执行任何操作。

2. 常见原因

本类故障的主要原因主要为,设备上配置了Login延时认证功能。开启本功能后,用户登录失败后,系统将会延迟一定的时长之后再允许用户进行认证。

3. 故障分析

本类故障的诊断流程如图图14-11所示。

图14-11 登录失败后等待重认证的故障诊断流程图

 

4. 处理步骤

(1)     检查是否开启了Login延时认证功能。

如果当前配置中存在attack-defense login reauthentication-delay命令,则可以根据需要关闭Login延时认证功能,或修改重认证等待时长。

¡     通过执行undo attack-defense login reauthentication-delay命令关闭延时认证功能。

<Sysname> system-view

[Sysname] undo attack-defense login reauthentication-delay

¡     通过执行attack-defense login reauthentication-delay seconds命令减小用户登录失败后重新进行认证的等待时长(下例中为10秒)。

<Sysname> system-view

[Sysname] attack-defense login reauthentication-delay 10

执行以上操作可能会减弱设备防范Login用户字典序攻击的力度,请慎重执行。

(2)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

5. 告警与日志

相关告警

相关日志

14.2.9  使用相同用户名接入设备的用户数达到上限

1. 故障描述

使用同一用户名接入设备的本地认证用户达到一定数量后,后续使用该用户名登录设备失败。

如果设备上同时打开了Local-Server的事件调试信息开关(通过执行debugging local-server event命令),系统会打印如下形式的调试信息:

*Aug 18 10:52:56:664 2021 Sysname LOCALSER/7/EVENT: -MDC=1;

 Authentication failed, the maximum number of concurrent logins already reached for the local user.

2. 常见原因

本类故障的主要原因为,设备上设置了使用当前本地用户名接入设备的最大用户数。

3. 故障分析

本类故障的诊断流程如图14-12所示。

图14-12 使用相同用户名的上线用户数达上限后的故障诊断流程图

 

4. 处理步骤

(1)     检查是否设置了使用当前本地用户名接入设备的最大用户数。

执行display local-user命令,查看该用户名的本地用户配置信息。如果其中的“Access limit:”字段取值为Enabled,则表示设置了使用当前本地用户名接入设备的最大用户数(下例中为2)。

<Sysname> display local-user user-name test class manage

Total 1 local users matched.

 

Device management user test:

  Service type:              SSH/Telnet

  Access limit:              Enabled           Max access number: 2

  Service type:              Telnet

  User group:                system

  Bind attributes:

  Authorization attributes:

    Work directory:          flash:

    User role list:          test

...

可以根据需要在本地用户视图下取消或者改变使用当前本地用户名接入设备的最大用户数。

¡     通过执行undo access-limit命令取消使用当前本地用户名接入的用户数限制。

<Sysname> system-view

[Sysname] local-user test class manage

[Sysname-luser-manage-test] undo access-limit

¡     通过执行access-limit max-user-number命令增加最大用户数(下例中为10)。

<Sysname> system-view

[Sysname] local-user test class manage

[Sysname-luser-manage-test] access-limit 10

(2)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

5. 告警与日志

相关告警

相关日志

14.2.10  相同接入类型的在线用户数达到上限

1. 故障描述

使用同一登录方式接入设备的用户达到一定数量后,后续该类用户登录设备失败。

如果设备上同时打开了相关接入模块的事件调试信息开关,系统会打印如下形式的调试信息:

%Aug 18 10:57:52:596 2021 Sysname TELNETD/6/TELNETD_REACH_SESSION_LIMIT: -MDC=1; Telnet client 1.1.1.1 failed to log in. The current number of Telnet sessions is 5. The maximum number allowed is (5).

2. 常见原因

本类故障的主要常见原因为,设备上设置了采用指定登录方式登录设备并同时在线的用户数。

3. 故障分析

本类故障的诊断流程如图14-13所示:

图14-13 使用相同登录方式接入用户数达到上限后的故障诊断流程图

 

4. 处理步骤

(1)     检查是否设置了采用指定登录方式登录设备并同时在线的用户数。

如果当前配置中存在aaa session-limit命令,则可以根据需要在系统视图下通过aaa session-limit { ftp | http | https | ssh | telnet } max-sessions命令改变使用当前登录方式接入设备的最大用户数(下例中为32)。

<Sysname> system-view

[Sysname] aaa session-limit telnet 32

(2)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

5. 告警与日志

相关告警

相关日志

14.2.11  RADIUS服务器无响应

1. 故障描述

因为服务器无响应导致使用RADIUS认证服务器认证/授权/计费失败。如果设备上同时打开了RADIUS的事件调试信息开关(通过执行debugging radius event命令),系统会打印如下形式的调试信息:

*Aug  8 17:49:06:143 2021 Sysname RADIUS/7/EVENT: -MDC=1; Reached the maximum retries

2. 常见原因

本类故障的常见原因主要包括:

·     RADIUS服务器上配置的共享密钥与接入设备上配置的共享密钥不一致。

·     RADIUS服务器上没有添加接入设备的IP地址或者添加的IP地址不正确。

·     RADIUS服务器与接入设备之间的网络存在问题,例如中间网络存在防火墙时,防火墙阻止了RADIUS服务器提供AAA服务的端口号(缺省认证端口号:1812,缺省计费端口号:1813)。

3. 故障分析

本类故障的诊断流程如图14-14所示。

图14-14 RADIUS服务器无响应的故障诊断流程图

 

4. 处理步骤

(1)     检查RADIUS服务器上配置的共享密钥与接入设备上配置的是否一致。

¡     如果共享密钥配置不一致,则:

-     在接入设备上,需要在RADIUS方案视图下执行key authenticationkey accounting命令分别重新配置认证、计费共享密钥(下例中认证密钥为123、计费密钥为456)。

<Sysname> system-view

[Sysname] radius scheme radius1

[Sysname-radius-radius1] key authentication simple 123

[Sysname-radius-radius1] key accounting simple 456

-     在RADIUS服务器上,重新配置与接入设备交互RADIUS报文的共享密钥,保证与接入设备上配置的一致。

¡     如果共享密钥配置一致,则执行步骤(2)。

(2)     检查RADIUS服务器上是否添加了接入设备的IP地址或者添加的IP地址是否正确。

RADIUS服务器上添加的设备IP地址必须是接入设备发送RADIUS报文的源IP地址。接入设备发送RADIUS报文使用的源IP地址可以通过相关命令设置。

接入设备按照以下顺序选择发送RADIUS报文使用的源IP地址:

a.     RADIUS方案视图下配置的源IP地址(通过source-ip命令)。

b.     系统视图下的配置的源IP地址(通过radius source-ip命令)。

c.     RADIUS方案视图下配置的NAS-IP地址(通过nas-ip命令)。

d.     系统视图下的配置的源NAS-IP地址(通过radius nas-ip命令)。

e.     发送RADIUS报文的出接口的IP地址。

(3)     检查设备和服务器之间的网络是否存在问题。

首先使用ping等手段排除设备与服务器之间的网络可达性,然后排查该网络中是否存在防火墙等设备。通常,如果网络中存在防火墙设备且不允许目的UDP端口号为RADIUS服务器端口号的报文通过(缺省的RADIUS认证端口号为1812,缺省的RADIUS计费端口号为1813),RADIUS报文将被丢弃。

(4)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息、调试信息。

5. 告警与日志

相关告警

相关日志

14.2.12  HWTACACS服务器无响应

1. 故障描述

使用HWTACACS认证服务器认证/授权/计费失败。如果同时在设备上执行debugging hwtacacs event命令打开HWTACACS事件调试信息开关,系统打印的事件调试信息中将出现“Connection timed out.”。

2. 常见原因

本类故障的常见原因主要包括:

·     HWTACACS服务器上配置的共享密钥与接入设备上配置的共享密钥不一致。

·     HWTACACS服务器上没有添加接入设备的IP地址或者添加的IP地址不正确。

·     HWTACACS服务器与接入设备之间的网络存在问题,例如中间网络存在防火墙时,防火墙阻止了HWTACACS服务器提供AAA服务的端口号(缺省认证/授权/计费端口号为49)。

3. 故障分析

本类故障的诊断流程如图14-15所示。

图14-15 HWTACACS服务器无响应的故障诊断流程图

 

4. 处理步骤

(1)     检查HWTACACS服务器上配置的共享密钥与接入设备上配置的是否一致。

¡     如果共享密钥配置不一致,则:

-     在接入设备上,需要在HWTACACS方案视图下执行key authenticationkey authorizationkey accounting命令重新配置认证、授权、计费共享密钥(下例中认证和授权密钥为123、计费密钥为456)。

<Sysname> system-view

[Sysname] hwtacacs scheme hwt1

[Sysname-hwtacacs-hwt1] key authentication simple 123

[Sysname-hwtacacs-hwt1] key authorization simple 123

[Sysname-hwtacacs-hwt1] key accounting simple 456

-     在HWTACACS服务器上,重新配置与接入设备交互HWTACACS报文的共享密钥,保证与接入设备上配置的一致。

¡     如果共享密钥配置一致,则执行步骤(2)。

(2)     检查HWTACACS服务器上是否添加了接入设备的IP地址或者添加的IP地址是否正确。

HWTACACS服务器上添加的设备IP地址必须是接入设备发送HWTACACS报文的源IP地址。接入设备发送HWTACACS报文使用的源IP地址可以通过相关命令设置。

接入设备按照以下顺序选择发送HWTACACS报文使用的源IP地址:

a.     HWTACACS方案视图下配置的源IP地址(通过nas-ip命令)。

b.     系统视图下的配置的源IP地址(通过hwtacacs nas-ip命令)。

c.     发送HWTACACS报文的出接口的IP地址。

(3)     检查设备和服务器之间的网络是否存在问题。

首先使用ping等手段排除设备与服务器之间的网络可达性,然后排查该网络中是否存在防火墙等设备。通常,如果网络中存在防火墙设备且不允许目的TCP端口号为HWTACACS服务器端口号的报文通过(缺省的HWTACACS认证/授权/计费端口号为49),HWTACACS报文将被丢弃。

(4)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息、调试信息。

5. 告警与日志

相关告警

相关日志

14.2.13  用户接入类型与RADIUS服务器下发的Login-Service属性值不匹配

1. 故障描述

由于设备不支持RADIUS服务器下发的Login-Service属性值,导致用户认证失败。

打开设备上RADIUS的报文调试信息开关(通过执行debugging radius packet命令),在如下形式的调试信息中查看到服务器下发的Login-Service属性类型为设备不支持的类型:

*Aug  3 02:33:18:707 2021 Sysname RADIUS/7/PACKET:

    Service-Type=Framed-User

    Idle-Timeout=66666

    Session-Timeout=6000

    Login-Service=TCP-Clear

2. 常见原因

本类故障的主要原因为,用户登录的业务类型与服务器下发的Login-Service属性所指定的业务类型不一致。

Login-Service属性由RADIUS服务器下发给用户,标识认证用户的业务类型。当前设备支持的Login-Service属性取值如下:

·     0:Telnet(标准属性)

·     50:SSH(扩展属性)

·     51:FTP(扩展属性)

·     52:Terminal(扩展属性)

·     53:HTTP(扩展属性)

·     54:HTTPS(扩展属性)

可以通过命令行设置设备对Login-Service属性的检查方式,控制设备对用户进行业务类型一致性检查的方式。

3. 故障分析

本类故障的诊断流程如图14-16所示。

图14-16 用户接入类型与RADIUS服务器下发的Login-Service属性值不匹配的故障诊断流程图

 

4. 处理步骤

(1)     检查RADIUS服务器下发的Login-Service属性与接入类型是否匹配。

在接入设备上执行display radius scheme命令,查看RADIUS方案下的“Attribute 15 check-mode”字段取值:

¡     取值为Loose,表示采用松散检查方式,即使用Login-Service的标准属性值对用户业务类型进行检查。对于SSH、FTP、Terminal用户,在RADIUS服务器下发的Login-Service属性值为0(表示用户业务类型为Telnet)时才,这类用户才能够通过认证。

¡     取值为Strict,表示采用严格检查方式,即使用Login-Service的标准属性值以及扩展属性值对用户业务类型进行检查。对于SSH、FTP、Terminal用户,当RADIUS服务器下发的Login-Service属性值为对应的扩展取值时,这类用户才能够通过认。

如果RADIUS服务器下发给用户的Login-Service属性不属于设备支持的Login-Service属性范围,则可以选用如下方法之一解决:

¡     在RADIUS服务器上,设置服务器不下发Login-Service属性或者修改下发的属性值为接入设备支持的取值。

¡     在接入设备上,进入相应的RADIUS方案,通过执行attribute 15 check-mode命令修改对Login-Service属性的检查方式(下例中为松散检查方式)。

<Sysname> system-view

[Sysname] radius scheme radius1

[Sysname-radius-radius1] attribute 15 check-mode loose

(2)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、调试信息、告警信息。

5. 告警与日志

相关告警

相关日志

14.2.14  本地认证登录失败

1. 故障描述

管理员采用本地认证登录设备失败。

2. 常见原因

本类故障的常见原因主要包括:

·     用户线下的认证方式配置错误。

·     VTY用户线下支持的协议类型不正确。

·     ISP域下配置的认证、授权、计费方案错误。

·     本地用户不存在、用户密码错误,或服务类型错误。

·     本地用户接入数量达到上限。

·     登录设备的用户数量到达上限。

·     全局密码管理功能开启的情况下,设备本地的lauth.dat文件异常。

3. 故障分析

本类故障的诊断流程如图14-17所示。

图14-17 本地认证登录失败的故障诊断流程图

 

4. 处理步骤

说明

Web、NETCONF over SOAP、FTP类登录故障无需关心用户线(类)下的配置,其它排障步骤相同。

 

(1)     检查用户线下的配置。

执行line vty first-number [ last-number ]命令进入指定的VTY用户线视图,通过display this命令查看如下配置是否准确:

¡     authentication-mode是否配置为scheme

¡     对于Telnet登录:protocol inbound是否配置为telnet或为缺省情况。

¡     对于SSH登录:protocol inbound是否配置为ssh或为缺省情况。

(2)     检查用户线类下的配置。

用户线视图下的配置优先于用户线类视图下的配置。若用户线视图下未配置,则需要继续检查用户线类视图下的配置。

执行line class vty命令进入VTY用户线视图,通过display this命令查看如下配置是否准确:

¡     authentication-mode是否配置为scheme

¡     对于Telnet登录:protocol inbound是否配置为telnet或为缺省情况。

¡     对于SSH登录:protocol inbound是否配置为ssh或为缺省情况。

如果用户线和用户线类下的配置均不准确,请按照需要在指定的用户线或用户线类下设置认证方案为scheme,并设置用户登录支持的协议类型。

(3)     检查ISP域下的在线用户数是否达到上限。

执行display domain命令查看用户认证域下的access-limit配置。

¡     如果显示信息中的Access limit:”字段为具体的数值,则执行display domain name isp-name access-user statistics命令查看“Online user count”字段取值是否达到Access limit数值。如果达到上,则根据需要采取以下措施之一:

-     在ISP域视图下执行access-limit命令扩大用户数上限(本例中为20)。

<Sysname> system-view

[Sysname] domain name test

[Sysname-isp-test] access-limit 20

-     在用户视图下执行free命令强制其它在线用户下线(本例中为强制释放VTY1上建立的所有连接)。

<Sysname> free line vty 1

Are you sure to free line vty1? [Y/N]:y

 [OK]

¡     如果Access limit:”字段取值为“Not configured”,或者用户数未达到上限值,则继续定位。

(4)     检查ISP域下的认证、授权、计费方案配置是否准确。

执行display domain命令,查看显示信息

¡     如果用户的登录用户名中携带了域名(假设为test),则查看该域下的“Login   authentication scheme:”字段取值是否为Local。如果该域下无“Login   authentication scheme:”字段,再查看“Default authentication scheme:”字段取值是否为Local。

<Sysname> display domain test

 

Domain: test

  State: Active

  Login   authentication scheme:  Local

  Default authentication scheme:  Local

  Default authorization  scheme:  Local

  Default accounting     scheme:  Local

  Accounting start failure action: Online

  Accounting update failure action: Online

  Accounting quota out action: Offline

  Service type: HSI

  Session time: Exclude idle time

  NAS-ID: N/A

  DHCPv6-follow-IPv6CP timeout: 60 seconds

  Authorization attributes:

    Idle cut: Disabled

    Session timeout: Disabled

    IGMP access limit: 4

    MLD access limit: 4

¡     如果用户的登录用户名中未携带域名,则在系统视图下执行display this命令查看是否存在domain default enable isp-name配置。(下例中缺省域名为system)。

#

domain default enable system

#

-     如果存在该配置,则执行display domain命令查看isp-name域下的“Login   authentication scheme:”字段取值是否为“Local”。如果该域下无“Login   authentication scheme:”字段,再查看“Default authentication scheme:”字段取值是否为“Local”。

-     如果不存在该配置,则执行display domain命令查看system域下的“Login   authentication scheme:”字段取值是否为“Local”。如果system域下无“Login   authentication scheme:”字段,再查看“Default authentication scheme:”字段取值是否为“Local”。

授权、计费配置确认方式与认证类似,不再赘述。如果以上配置不准确,请在相关ISP下配置Login用户的认证/授权/计费方案均为Local。

(5)     检查用户名和密码是否正确。

执行display local-user命令查看是否存在对应的本地用户配置。

¡     如果本地用户存在,则执行local-user username class manage命令进入本地用户视图,然后通过display this命令查看该视图下是否配置了密码,以及service-type配置是否为所需的服务类型。

-     若需要用户密码,则尝试重置一次密码(下例中为123456TESTplat&!)。

<Sysname> system-view

[Sysname] local-user test class manage

[Sysname-luser-manage-test] password simple 123456TESTplat&!

-     若服务类型错误,则配置与登录方式匹配的服务类型(下例中为SSH)。

<Sysname> system-view

[Sysname] local-user test class manage

[Sysname-luser-manage-test] service-type ssh

¡     如果本地用户不存在,则执行local-user username class manage命令创建一个设备管理类本地用户(下例中用户名为test),并按需配置密码和服务类型。

<Sysname> system-view

[Sysname] local-user test class manage

[Sysname-luser-manage-test]

(6)     检查使用该本地用户名接入的用户数是否达到上限。

在本地用户视图下执行display this命令查看是否存在access-limit配置。

¡     如果access-limit配置存在,则执行display local-user username class manage命令查看“Current access number:”字段取值是否达到配置的上限值。如果达到上限值,则根据需要采取以下措施之一:

-     在该本地用户视图下执行access-limit命令扩大用户数上限(下例中为20)。

<Sysname> system-view

[Sysname] local-user test class manage

[Sysname-luser-manage-test] access-limit 20

-     在用户视图下执行free命令强制其它在线用户下线(下例中为强制释放VTY1上建立的所有连接)。

<Sysname> free line vty 1

Are you sure to free line vty1? [Y/N]:y

 [OK]

¡     如果access-limit配置不存在,或者用户数未达到上限值,则继续定位。

(7)     检查指定登录类型的在线用户数是否到达上限。

a.     在系统视图下执行display this命令查看是否存在aaa session-limit的配置,若无此配置,则说明采用了缺省值32。

#

 aaa session-limit ftp 33

 domain default enable system

#

b.     执行display users查看当前用户线的用户登录情况,确认是否已到用户数上限。

c.     如果在线用户数到达上限,则根据需要采取以下措施之一:

-     在系统视图下执行aaa session-limit命令扩大用户数上限。

-     在用户视图下执行free命令强制其它在线用户下线。

(8)     检查本地lauth.dat文件是否正常。

开启全局密码管理功能后,设备会自动生成lauth.dat文件记录本地用户的认证、登录信息。如果手工删除或修改该文件,会造成本地认证异常。因此,请首先执行display password-control命令查看设备上是否开启了全局密码管理功能。

¡     如果该文件不存在、大小为0或者很小(若小于20B,则大概率发生了异常),请优先联系技术支持人员协助处理,若当前配置需求紧迫,可尝试重新开启全局密码管理功能来解决此问题。

<Sysname> dir

Directory of flash: (EXT4)

   0 drw-           - Aug 16 2021 11:45:37   core

   1 drw-           - Aug 16 2021 11:45:42   diagfile

   2 drw-           - Aug 16 2021 11:45:57   dlp

   3 -rw-         713 Aug 16 2021 11:49:41   ifindex.dat

   4 -rw-         12  Sep 01 2021 02:40:01   lauth.dat

...

<Sysname> system-view

[Sysname] undo password-control enable

[Sysname] password-control enable

¡     若未开启,则忽略此步骤。

(9)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息、诊断信息。

¡     打开Local-Server调试信息开关(通过debugging local-server all命令),收集设备的调试信息。

5. 告警与日志

相关告警

模块名:HH3C-UI-MAN-MIB

·     hh3cLogInAuthenFailure (1.3.6.1.4.1.25506.2.2.1.1.3.0.3)

模块名:HH3C-SSH-MIB

·     hh3cSSHUserAuthFailure (1.3.6.1.4.1.25506.2.22.1.3.0.1)

相关日志

·     LOGIN/5/LOGIN_FAILED

·     SSHS/6/SSHS_AUTH_FAIL

14.2.15  RADIUS认证登录失败

1. 故障描述

管理员采用RADIUS认证登录设备失败。

2. 常见原因

本类故障的常见原因主要包括:

·     用户线下的认证方式配置错误。

·     VTY用户线下支持的协议类型不正确。

·     ISP域下配置的认证、授权、计费方案错误。

·     与RADIUS服务器交互失败。

·     RADIUS服务器下发的Login-Service属性值不正确。

·     RADIUS服务器未下发用户角色权限。

3. 故障分析

本类故障的诊断流程如图14-18所示。

图14-18 RADIUS认证登录失败的故障诊断流程图

 

4. 处理步骤

说明

Web、NETCONF over SOAP、FTP类登录故障无需关心用户线(类)下的配置,其它排障步骤相同。

 

(1)     检查用户线下的配置。

执行line vty first-number [ last-number ]命令进入指定的VTY用户线视图,通过display this命令查看如下配置是否准确:

¡     authentication-mode是否配置为scheme

¡     对于Telnet登录:protocol inbound是否配置为telnet或为缺省情况。

¡     对于SSH登录:protocol inbound是否配置为ssh或为缺省情况。

(2)     检查用户线类下的配置。

用户线视图下的配置优先于用户线类视图下的配置。若用户线视图下未配置,则需要继续检查用户线类视图下的配置。

执行line class vty命令进入VTY用户线视图,通过display this命令查看如下配置是否准确:

¡     authentication-mode是否配置为scheme

¡     对于Telnet登录:protocol inbound是否配置为telnet或为缺省情况。

¡     对于SSH登录:protocol inbound是否配置为ssh或为缺省情况。

如果用户线和用户线类下的配置均不准确,请按照需要,在指定的用户线或用户线类下设置认证方案为scheme,并设置用户登录支持的协议类型。

(3)     检查ISP域下的认证、授权、计费方案配置是否准确。

执行display domain命令,查看显示信息

¡     如果用户的登录用户名中携带了域名(假设为test),则查看该域下的“Login   authentication scheme:”字段取值是否为“RADIUS=xx”。如果该域下无“Login   authentication scheme:”字段,再查看“Default authentication scheme:”字段取值是否为“RADIUS=xx”。

<Sysname> display domain test

 

Domain: test

  State: Active

  Login   authentication scheme:  RADIUS=rds

  Default authentication scheme:  Local

  Default authorization  scheme:  Local

  Default accounting     scheme:  Local

  Accounting start failure action: Online

  Accounting update failure action: Online

  Accounting quota out action: Offline

  Service type: HSI

  Session time: Exclude idle time

  NAS-ID: N/A

  DHCPv6-follow-IPv6CP timeout: 60 seconds

  Authorization attributes:

    Idle cut: Disabled

    Session timeout: Disabled

    IGMP access limit: 4

    MLD access limit: 4

¡     如果用户的登录用户名中未携带域名,则在系统视图下执行display this命令查看是否存在domain default enable isp-name配置(下例中缺省域名为system)。

#

domain default enable system

#

-     如果存在该配置,则执行display domain命令查看isp-name域下的“Login   authentication scheme:”字段取值是否为“RADIUS=xx”。如果该域下无“Login   authentication scheme:”字段,再查看“Default authentication scheme:”字段取值是否为“RADIUS=xx”。

-     如果不存在该配置,则执行display domain命令查看system域下的“Login   authentication scheme:”字段取值是否为“RADIUS=xx”。如果system域下无“Login   authentication scheme:”字段,再查看“Default authentication scheme:”字段取值是否为“RADIUS=xx”。

授权、计费配置确认方式与认证类似,不再赘述。如果以上配置不准确,请在相关ISP域下配置Login用户采用RADIUS认证/授权/计费方案(下例中认证/授权/计费均采用RADIUS方案rd1)。

<Sysname> system-view

[Sysname] domain name test

[Sysname-isp-test] authentication login radius-scheme rd1

[Sysname-isp-test] authorization login radius-scheme rd1

[Sysname-isp-test] accounting login radius-scheme rd1

(4)     通过RADIUS的调试信息辅助排查如下故障。

¡     执行debugging radius packet命令打开RADIUS报文调试信息开关,如果系统打印Authentication reject类的报文调试信息,则表示用户的认证请求被服务器拒绝。因此,需要继续查看RADIUS服务器上记录的认证日志,并通过日志中描述的失败原因联系服务器管理员进行相应的处理。

¡     执行debugging radius error命令打开RADIUS错误调试信息开关,如果系统打印错误调试信息“Invalid packet authenticator.”,则表示设备与服务器的共享密钥不匹配,可以尝试在RADIUS方案下设置与服务器匹配的共享密钥。

¡     执行debugging radius event命令打开RADIUS事件调试信息开关,如果系统打印事件调试信息“Response timed out. ”,则表示设备与服务器之间不可达,可以尝试排查设备和服务器中间链路不通的问题。

(5)     检查RADIUS服务器下发的Login-Service属性值是否为设备支持的业务类型。

执行debugging radius packet命令打开RADIUS的报文调试信息开关后,查看RADIUS服务器下发的Login-Service属性情况,并采用“14.2.13  用户接入类型与RADIUS服务器下发的Login-Service属性值不匹配”介绍的方法解决故障。

(6)     检查RADIUS服务器是否下发了正确的用户角色权限。

执行debugging radius all命令打开所有RADIUS调试信息开关后,如果用户输入用户名和密码后连接直接断开,且没有异常的RADIUS事件调试信息以及RADIUS错误调试信息输出,则有可能是RADIUS服务器未给用户下发用户角色或下发的用户角色错误导致。此时,可以查看RADIUS报文调试信息中是否包含“shell:roles="xx"”或“Exec-Privilege=xx”字段。

¡     如果不包含,则表示RADIUS服务器未给用户下发用户角色权限,则可以选用如下方法之一解决:

-     在设备侧,可以通过执行role default-role enable rolename命令使能缺省用户角色授权功能,使得用户在没有被服务器授权任何角色的情况下,具有一个缺省的用户角色

<Sysname> system-view

[Sysname] role default-role enable

-     联系RADIUS服务器管理员,为用户下发合适的用户角色。

¡     如果包含,但指定的用户角色在设备上不存在,则需要联系RADIUS服务器管理员修改用户角色设置或者在设备上通过user-role role-name命令创建对应的用户角色。

(7)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息、诊断信息。

¡     打开RADIUS调试信息开关(通过debugging radius all命令),收集设备的调试信息。

5. 告警与日志

相关告警

模块名:HH3C-UI-MAN-MIB

·     hh3cLogInAuthenFailure (1.3.6.1.4.1.25506.2.2.1.1.3.0.3)

·     模块名:HH3C-SSH-MIB

·     hh3cSSHUserAuthFailure (1.3.6.1.4.1.25506.2.22.1.3.0.1)

相关日志

·     LOGIN/5/LOGIN_AUTHENTICATION_FAILED

·     LOGIN/5/LOGIN_FAILED

·     SSHS/6/SSHS_AUTH_FAIL

14.2.16  HWTACACS认证登录失败

1. 故障描述

管理员采用HWTACACS认证登录设备失败。

2. 常见原因

本类故障的常见原因主要包括:

·     用户线下的认证方式配置错误。

·     VTY用户线下支持的协议类型不正确。

·     ISP域下配置的认证、授权、计费方案错误。

·     与HWTACACS服务器交互失败。

·     HWTACACS服务器未下发用户角色权限。

3. 故障分析

本类故障的诊断流程如图14-19所示。

图14-19 HWTACACS认证登录失败的故障诊断流程图

 

4. 处理步骤

说明

Web、NETCONF over SOAP、FTP类登录故障无需关心用户线(类)下的配置,其它排障步骤相同。

 

(1)     检查用户线下的配置。

执行line vty first-number [ last-number ]命令进入指定的VTY用户线视图,通过display this命令查看如下配置是否准确:

¡     authentication-mode是否配置为scheme

¡     对于Telnet登录:protocol inbound是否配置为telnet或为缺省情况。

¡     对于SSH登录:protocol inbound是否配置为ssh或为缺省情况。

(2)     检查用户线类下的配置。

用户线视图下的配置优先于用户线类视图下的配置。若用户线视图下未配置,则需要继续检查用户线类视图下的配置。

执行line class vty命令进入VTY用户线视图,通过display this命令查看如下配置是否准确:

¡     authentication-mode是否配置为scheme

¡     对于Telnet登录:protocol inbound是否配置为telnet或为缺省情况。

¡     对于SSH登录:protocol inbound是否配置为ssh或为缺省情况。

¡     如果用户线和用户线类下的配置均不准确,请按照需要,在指定的用户线或用户线类下设置认证方案为scheme,并设置用户登录支持的协议类型。

(3)     检查ISP域下的认证、授权、计费方案配置是否准确。

执行display domain命令,查看显示信息

¡     如果用户的登录用户名中携带了域名(假设为test),则查看该域下的“Login   authentication scheme:”字段取值是否为“HWTACACS=xx”。如果该域下无“Login   authentication scheme:”字段,再查看“Default authentication scheme:”字段取值是否为“HWTACACS=xx”。

<Sysname> display domain test

 

Domain: test

  State: Active

  Login   authentication scheme:  HWTACACS=hwt1

  Default authentication scheme:  Local

  Default authorization  scheme:  Local

  Default accounting     scheme:  Local

  Accounting start failure action: Online

  Accounting update failure action: Online

  Accounting quota out action: Offline

  Service type: HSI

  Session time: Exclude idle time

  NAS-ID: N/A

  DHCPv6-follow-IPv6CP timeout: 60 seconds

  Authorization attributes:

    Idle cut: Disabled

    Session timeout: Disabled

    IGMP access limit: 4

    MLD access limit: 4

¡     如果用户的登录用户名中未携带域名,则在系统视图下执行display this命令查看是否存在domain default enable isp-name配置。(下例中缺省域名为system)。

#

domain default enable system

#

-     如果存在该配置,则执行display domain命令查看isp-name域下的“Login   authentication scheme:”字段取值是否为“HWTACACS=xx”。如果该域下无“Login   authentication scheme:”字段,再查看“Default authentication scheme:”字段取值是否为“HWTACACS=xx”。

-     如果不存在该配置,则执行display domain命令查看system域下的“Login   authentication scheme:”字段取值是否为“HWTACACS=xx”。如果system域下无“Login   authentication scheme:”字段,再查看“Default authentication scheme:”字段取值是否为“HWTACACS=xx”。

授权、计费配置确认方式与认证类似,不再赘述。如果以上配置不准确,请在相关ISP域下配置Login用户采用HWTACACS认证/授权/计费方案(下例中认证/授权/计费均采用HWTACACS方案hwt1)。

<Sysname> system-view

[Sysname] domain name test

[Sysname-isp-test] authentication login hwtacacs-scheme hwt1

[Sysname-isp-test] authorization login hwtacacs-scheme hwt1

[Sysname-isp-test] accounting login hwtacacs-scheme hwt1

(4)     通过HWTACACS的调试信息辅助排查如下故障。

¡     执行debugging hwtacacs send-packetdebugging hwtacacs receive-packet命令打开HWTACACS报文发送/接收调试信息,如果系统打印应答报文调试信息中包含“status: STATUS_FAIL”,则表示用户的认证请求被服务器拒绝。因此,需要继续查看HWTACACS服务器认证日志中描述的失败原因,并根据具体的失败原因继续定位。

¡     执行debugging hwtacacs error命令打开HWTACACS错误调试信息开关,如果系统打印错误调试信息“Failed to get available server.”,则通常表示设备与服务器的共享密钥不匹配,可以尝试在HWTACACS方案下设置与服务器匹配的共享密钥。

¡     执行debugging hwtacacs event命令打开HWTACACS事件调试信息开关,如果系统打印事件调试信息“Connection timed out.”,则表示设备与服务器之间不可达,可以尝试排查设备和服务器中间链路不通的问题。

(5)     检查HWTACACS服务器是否下发了正确的用户角色权限。

执行debugging hwtacacs all命令打开所有HWTACACS调试信息开关后,如果发现客户端登录时直接断开连接,且没有异常的HWTACACS事件调试信息以及HWTACACS错误调试信息输出,则有可能是HWTACACS服务器未给用户下发用户角色权限导致。此时,可以查看HWTACACS的接收报文调试信息是否包含“priv-lvl=xx”或“roles=xx”字段。

¡     如果不包含,则表示HWTACACS服务器未给用户下发用户角色权限,则可以选用如下方法之一解决:

-     在设备侧,可以通过执行role default-role enable rolename命令使能缺省用户角色授权功能,使得用户在没有被服务器授权任何角色的情况下,具有一个缺省的用户角色

<Sysname> system-view

[Sysname] role default-role enable

-     联系HWTACACS服务器管理员,为用户下发合适的用户角色。HWTACACS服务器上的授权角色配置必须满足格式:roles="name1 name2 namen",其中name1name2namen为要授权下发给用户的用户角色,可为多个,并使用空格分隔。

¡     如果包含,但指定的用户角色在设备上不存在,则需要联系RADIUS服务器管理员修改用户角色设置或者在设备上通过user-role role-name命令创建对应的用户角色。

(6)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息、诊断信息。

¡     打开HWTACACS调试信息开关(通过debugging hwtacacs all命令),收集设备的调试信息。

5. 告警与日志

相关告警

模块名:HH3C-UI-MAN-MIB

·     hh3cLogInAuthenFailure (1.3.6.1.4.1.25506.2.2.1.1.3.0.3)

·     模块名:HH3C-SSH-MIB

·     hh3cSSHUserAuthFailure (1.3.6.1.4.1.25506.2.22.1.3.0.1)

相关日志

·     LOGIN/5/LOGIN_AUTHENTICATION_FAILED

·     LOGIN/5/LOGIN_FAILED

·     SSHS/6/SSHS_AUTH_FAIL

14.2.17  LDAP认证登录失败

1. 故障描述

管理员采用LDAP认证登录设备失败。

2. 常见原因

本类故障的常见原因主要包括:

·     用户线下的认证方式配置错误。

·     VTY用户线下支持的协议类型不正确。

·     ISP域下配置的认证、授权、计费方案错误。

·     与LDAP服务器交互失败。

3. 故障分析

本类故障的诊断流程如图14-20所示。

图14-20 LDAP认证登录失败的故障诊断流程图

 

4. 处理步骤

说明

Web、NETCONF over SOAP、FTP类登录故障无需关心用户线(类)下的配置,其它排障步骤相同。

 

(1)     检查用户线下的配置。

执行line vty first-number [ last-number ]命令进入指定的VTY用户线视图,通过display this命令查看如下配置是否准确:

¡     authentication-mode是否配置为scheme

¡     对于Telnet登录:protocol inbound是否配置为telnet或为缺省情况。

¡     对于SSH登录:protocol inbound是否配置为ssh或为缺省情况。

(2)     检查用户线类下的配置。

用户线视图下的配置优先于用户线类视图下的配置。若用户线视图下未配置,则需要继续检查用户线类视图下的配置。

执行line class vty命令进入VTY用户线视图,通过display this命令查看如下配置是否准确:

¡     authentication-mode是否配置为scheme

¡     对于Telnet登录:protocol inbound是否配置为telnet或为缺省情况。

¡     对于SSH登录:protocol inbound是否配置为ssh或为缺省情况。

如果用户线和用户线类下的配置均不准确,请按照需要,在指定的用户线或用户线类下设置认证方案为scheme,并设置用户登录支持的协议类型。

(3)     检查ISP域下的认证、授权、计费方案配置是否准确。

执行display domain命令,查看显示信息

¡     如果用户的登录用户名中携带了域名(假设为test),则查看该域下的“Login   authentication scheme:”字段取值是否为“LDAP=xx”。如果该域下无“Login   authentication scheme:”字段,再查看“Default authentication scheme:”字段取值是否为“LDAP=xx”。

<Sysname> display domain test

 

Domain: test

  State: Active

  Login   authentication scheme:  LDAP=ldp

  Default authentication scheme:  Local

  Default authorization  scheme:  Local

  Default accounting     scheme:  Local

  Accounting start failure action: Online

  Accounting update failure action: Online

  Accounting quota out action: Offline

  Service type: HSI

  Session time: Exclude idle time

  NAS-ID: N/A

  DHCPv6-follow-IPv6CP timeout: 60 seconds

  Authorization attributes:

    Idle cut: Disabled

    Session timeout: Disabled

    IGMP access limit: 4

    MLD access limit: 4

¡     如果用户的登录用户名中未携带域名,则在系统视图下执行display this命令查看是否存在domain default enable isp-name配置(下例中缺省域名为system)。

#

domain default enable system

#

-     如果存在该配置,则执行display domain命令查看isp-name域下的“Login   authentication scheme:”字段取值是否为“LDAP=xx。如果该域下无“Login   authentication scheme:”字段,再查看“Default authentication scheme:”字段取值是否为“LDAP=xx”。

-     如果不存在该配置,则执行display domain命令查看system域下的“Login   authentication scheme:”字段取值是否为“LDAP=xx”。如果system域下无“Login   authentication scheme:”字段,再查看“Default authentication scheme:”字段取值是否为“LDAP=xx”。

如果以上配置不准确,请在相关ISP域下配置Login用户采用LDAP认证方案。LDAP服务器一般只作为认证服务器,授权和计费通常配置为其它方式,比如local、RADIUS或HWTACACS(下例中,认证采用LDAP方案ccc、授权和计费为local)。

<Sysname> system-view

[Sysname] domain name test

[Sysname-isp-test] authentication login ldap-scheme ccc

[Sysname-isp-test] authorization login local

[Sysname-isp-test] accounting login local

(4)     通过LDAP的调试信息辅助排查如下故障。

执行debugging ldap error命令打开LDAP错误调试信息开关,可根据系统打印的如下调试信息定位问题:

¡     “Failed to perform binding operation as administrator.“表示LDAP服务器视图下配置的管理员用户DN不存在或管理员密码不正确。针对此问题,可以进入LDAP服务器视图,执行login-dnlogin-password命令修改管理员用户DN和密码配置(下例中管理员权限的用户DN为cn=administrator,cn=users,dc=ld、管理员密码为admin!123456)。

<Sysname> system-view

[Sysname] ldap server ldap1

[Sysname-ldap-server-ldap1] login-dn cn=administrator,cn=users,dc=ld

[Sysname-ldap-server-ldap1] login-password simple admin!123456

¡     “Failed to get bind result.errno = 115”表示对端未开启LDAP服务或LDAP服务器异常。针对此问题,可以联系LDAP服务器管理员解决。

¡     “Bind operation failed.”表示设备与LDAP服务器之间不可达,可以尝试排查设备和服务器中间链路不通的问题。

¡     “Failed to perform binding operation as user.”表示LDAP用户密码错误。

¡     “Failed to bind user username for the result of searching DN is NULL.”表示LDAP用户不存在。针对此问题,可以联系LDAP服务器管理员解决。

(5)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息、诊断信息。

¡     打开LDAP调试信息开关(通过debugging ldap all命令),收集设备的调试信息。

5. 告警与日志

相关告警

模块名:HH3C-UI-MAN-MIB

·     hh3cLogInAuthenFailure (1.3.6.1.4.1.25506.2.2.1.1.3.0.3)

模块名:HH3C-SSH-MIB

·     hh3cSSHUserAuthFailure (1.3.6.1.4.1.25506.2.22.1.3.0.1)

相关日志

·     LOGIN/5/LOGIN_AUTHENTICATION_FAILED

·     LOGIN/5/LOGIN_FAILED

·     SSHS/6/SSHS_AUTH_FAIL

14.2.18  RADIUS认证服务器下发的动态VLAN不生效

1. 故障描述

MAC地址认证用户在线的情况下,RADIUS认证服务器为其动态下发的VLAN授权属性不生效。

2. 常见原因

本类故障的常见原因主要包括:

·     未开启RADIUS DAE服务。

·     RADIUS下发的授权属性内容不正确。

·     接入用户未获取到动态VLAN。

·     动态授权的VLAN所属接口类型配置错误。

·     动态授权的VLAN不存在。

3. 故障分析

本类故障的诊断流程如图14-21所示。

图14-21 RADIUS认证服务器下发动态VLAN不生效故障诊断流程图

 

4. 处理步骤

(1)     检查RADIUS DAE服务功能是否开启。

请在系统视图下执行display current-configuration | include radius命令查看radius dynamic-author server配置是否存在。

¡     如果该配置存在,则执行radius dynamic-author server命令进入RADIUS DAE服务器视图下检查RADIUS DAE客户端以及RADIUS DAE服务端口配置是否正确。

<Sysname> system-view

[Sysname] radius dynamic-author server

[Sysname-radius-da-server] display this

#

radius dynamic-author server

 port 3790

 client ip 3.3.3.3 key cipher $c$3$kiAORLht3S3rTCmFq0uWXPgV8PjI2Q==

#

¡     如果该配置不存在,则执行radius dynamic-author server命令开启RADIUS DAE服务,并进入RADIUS DAE服务器视图配置RADIUS DAE客户端以及RADIUS DAE服务端口(下例中客户端的IP地址为1.1.1.1、共享密钥为123456、服务端口号为3798)。

<Sysname> system-view

[Sysname] radius dynamic-author server

[Sysname-radius-da-server] client ip 1.1.1.1 key simple 123456

[Sysname-radius-da-server] port 3798

(2)     检查RADIUS服务器下发的VLAN属性内容是否准确。

执行debugging radius packet命令打开RADIUS报文调试信息开关,同时让RADIUS服务器尝试再次下发VLAN属性。

RADIUS服务器需要同时下发如下3个标准属性来下发VLAN信息:

¡     64号属性Tunnel-Type,Integer类型,取值固定为13(VLAN)

¡     65号属性Tunnel-Medium-Type,Integer类型,取值固定为6(IEEE 802)。

¡     81号属性Tunnel-Private-Group-Id,String类型,取值为具体的VLAN ID或VLAN名称。

查看打印的RADIUS报文调试信息,检查COA request报文信息中是否携带了上述三个标准属性,如下例所示。

*Aug  3 02:33:18:700 2021 Sysname RADIUS/7/PACKET:

    Received a RADIUS packet

    Server IP       : 128.11.3.48

    NAS-IP          : 128.11.30.69

    VPN instance    : --(public)

    Server port     : 55805

    Type            : COA request

    Length          : 41

    Packet ID       : 34

    User-Name="user"

    Tunnel-Type:0=VLAN

    Tunnel-Medium-Type:0=IEEE-802

    Tunnel-Private-Group-Id:0="2"

如果打印的授权属性不准确,请联系RADIUS服务器管理员修改授权VLAN配置并尝试重新下发VLAN,否则继续定位。

(3)     检查用户是否成功获得下发的VLAN信息。

执行display dot1x connectiondisplay mac-authentication connection命令,查看相关在线用户信息中是否存在服务器动态下发的授权VLAN信息:

¡     如果存在授权VLAN信息,说明VLAN下发成功。

¡     如果不存在授权VLAN信息,说明VLAN没有下发成功。此时,建议在技术支持人员的指导下,结合RADIUS调试信息继续定位故障发生的原因。

(4)     检查授权的VLAN是否存在。

执行display vlan brief命令查看动态下发的VLAN是否存在。如果该VLAN不存在,请在系统视图下执行vlan vlan-id命令创建。

(5)     检查VLAN所在接口类型是否正确。

不同类型的接口成功加入授权VLAN的要求有所不同,具体配置要求请参见“安全配置指导”中的“MAC地址认证”。

(6)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、调试信息、诊断信息。

5. 告警与日志

相关告警

相关日志

14.2.19  RADIUS认证服务器下发的Filter-Id属性不生效或只有部分生效

1. 故障描述

RADIUS认证服务器通过Filter-Id属性向用户下发ACL,用户认证登录后无法正常访问网络资源。

2. 常见原因

本类故障的常见原因主要包括:

·     RADIUS下发的授权属性内容不正确。

·     接入用户未获取到ACL。

·     授权的ACL不存在。

3. 故障分析

本类故障的诊断流程如图14-22所示。

图14-22 认证登录后无法正常访问授权ACL网络资源故障诊断流程图

 

4. 处理步骤

(1)     检查RADIUS服务器下发的Filter-ID属性内容是否准确。

执行debugging radius packet命令打开RADIUS报文调试信息开关,同时让RADIUS服务器尝试再次下发Filter-ID属性,查看设备上打印的RADIUS报文调试信息:

·     如果下发的Filter-ID属性为纯数字,则表示下发了ACL编号。

*Aug 18 16:54:49:670 2021 Sysname RADIUS/7/PACKET: -MDC=1;

    Received a RADIUS packet

    Server IP       : 128.11.3.48

    NAS-IP          : 128.11.30.69

    VPN instance    : --(public)

    Server port     : 54175

    Type            : COA request

    Length          : 32

    Packet ID       : 200

    User-Name="user"

Filter-Id="2001"

·     如果下发的Filter-ID属性值不全为数字,则表示下发了User Profile名称。

*Aug 18 16:55:19:798 2021 Sysname RADIUS/7/PACKET: -MDC=1;

    Received a RADIUS packet

    Server IP       : 128.11.3.48

    NAS-IP          : 128.11.30.69

    VPN instance    : --(public)

    Server port     : 54176

    Type            : COA request

    Length          : 48

    Packet ID       : 157

    User-Name="user"

    Filter-Id="aclname1"

    H3c-ACL-Version=1

如果未下发预期取值的Filter-ID属性,或者下发的ACL类型为设备不支持的类型,请联系RADIUS服务器管理员修改授权ACL配置并尝试重新下发Filter-ID,否则继续定位。

(2)     检查用户是否成功获得下发的ACL信息。

执行display dot1x connectiondisplay mac-authentication connection命令,查看相关在线用户信息中是否存在授权的ACL信息:

¡     如果存在授权ACL信息,说明ACL下发成功。

¡     如果不存在授权ACL信息,说明ACL没有下发成功。此时,建议在技术支持人员的指导下,结合RADIUS调试信息继续定位故障发生的原因。

(3)     检查设备上对应的ACL是否已创建。

执行display acl all命令查看下发的ACL是否存在:

¡     如果未创建,请在系统视图下执行acl number acl-number [ name acl-name ]命令创建相应的ACL。

¡     如果已创建,请确认ACL配置是否正确。

(4)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、调试信息、诊断信息。

5. 告警与日志

相关告警

相关日志

14.2.20  RADIUS服务器与设备交互失败

1. 故障描述

设备与RADIUS服务器交互故障。

2. 故障处理步骤

通过以下命令查看设备和所有RADIUS服务器交互的报文统计信息。

<Sysname> display radius statistics

Authentication packets:

  Requests                   : 8          Retransmissions        : 0

  Pending requests           : 0          Packet timeouts        : 0

  Request failures           : 0          Challenge packets      : 0

  Packets without responses  : 0          Packets with responses : 0

  Accept responses           : 8          Reject responses       : 0

  Unknown-type responses     : 0          Malformed responses    : 0

  Bad authenticators         : 0          Dropped responses      : 0

 

Accounting packets:

  Requests                   : 16         Retransmissions        : 0

  Start requests             : 8          Realtime requests      : 0

  Stop requests              : 8          Pending requests       : 0

  Packet timeouts            : 0          Request failures       : 0

  Packets without responses  : 0          Packets with responses : 0

  Unknown-type responses     : 0          Malformed responses    : 0

  Bad authenticators         : 0          Dropped responses      : 0

 

DAE packets:

  DM:

    Requests                 : 0          Request retransmissions: 0

    ACKs                     : 0          NAKs                   : 0

    Timeouts                 : 0          Malformed requests     : 0

    Bad authenticators       : 0          Dropped requests       : 0

  CoA:

    Requests                 : 0          Request retransmissions: 0

    ACKs                     : 0          NAKs                   : 0

    Timeouts                 : 0          Malformed requests     : 0

    Bad authenticators       : 0          Dropped requests       : 0

  Unknown-type requests      : 0

 

Session-control packets:

  Terminate:

    Requests                 : 0          Successes              : 0

    Failures                 : 0          Timeouts               : 0

  Set-policy:

    Requests                 : 0          Successes              : 0

    Failures                 : 0          Timeouts               : 0

  Unknown-type requests      : 0          Malformed requests     : 0

  Bad authenticators         : 0          Dropped requests       : 0

 

Authentication servers: 1

  IP:  1.1.1.1                            Port: 1812

  VPN:

  Authentication packets:

    Requests                  : 8         Retransmissions        : 0

    Pending requests          : 0         Packet timeouts        : 0

    Request failures          : 0         Challenge packets      : 0

    Accept responses          : 8         Reject responses       : 0

    Unknown-type responses    : 0         Malformed responses    : 0

    Bad authenticators        : 0         Dropped responses      : 0

 

Accounting servers: 1

  IP:  1.1.1.1                            Port: 1813

  VPN:

  Accounting packets:

    Requests                  : 16        Retransmissions        : 0

    Start requests            : 8         Realtime requests      : 0

    Stop requests             : 8         Pending requests       : 0

    Packet timeouts           : 0         Request failures       : 0

    Unknown-type responses    : 0         Malformed responses    : 0

    Bad authenticators        : 0         Dropped responses      : 0

14.3  Portal故障

14.3.1  Portal认证页面无法弹出

1. 故障描述

用户访问任意非Portal Web服务器网页,或者直接访问Portal Web服务器,无法推出Portal登录页面。

2. 常见原因

本类故障的常见原因主要包括:

·     主机、服务器和设备之间的路由不通。

·     浏览器开启了HTTP代理功能。

·     用户输入的网址内携带了非标准的TCP端口号。

·     中间网络或DNS服务器出现问题。

·     设备上的HTTPS重定向功能不能正常使用

·     用户访问的HTTPS协议的网站开启了HSTS(HTTP Strict Transport Security,HTTP严格传输安全协议)功能。

·     Portal服务器无法识别转义后的URL特殊字符。

·     Portal服务器配置错误。

3. 故障分析

本类故障的诊断流程如图14-23所示:

图14-23 Portal认证页面无法弹出的故障诊断流程图

 

4. 处理步骤

(1)     确认终端和Portal服务器上的路由配置是否正确。

在终端上关闭防火墙功能后,执行Ping操作检查Portal服务器是否可达,如果Ping不通,首先需要确认终端和Portal服务器上的路由配置是否正确,同时需要注意:

¡     Portal服务器到终端的回程路由是否配置正确。

¡     终端或者Portal服务器上是否存在有多个网卡。

在有多个网卡的情况下,终端和服务器之间的流量不一定全部经过配置有Portal认证的网络。以Windows终端为例,在cmd窗口上执行route print命令查看具体的路由信息,然后确定用户的Web访问流量是从哪个网卡出去。

最后,采取分段Ping的手段定位问题。首先从终端Ping网关(需要先取消认证,否则Ping不通),然后再从网关上Ping服务器。

(2)     终端的浏览器上是否开启了HTTP代理功能。

浏览器上开启了HTTP代理功能会导致用户无法访问Portal认证页面。以Windows IE浏览器为例,请打开IE浏览器,单击“工具”,选择“Internet选项>连接>局域网设置>代理服务器”中,关闭HTTP代理功能。

(3)     输入的网址是否使用非标准TCP端口

非标准TCP端口是指非80或非443端口。用户输入的网址中若包含非标准TCP端口,会导致Portal认证页面无法弹出,例如http://10.1.1.1:18008/。对于HTTP协议的网址,请使用80;对于HTTPS协议的网址,请使用443。

(4)     中间网络或DNS服务器出现问题。

a.     确认设备上是否将DNS服务器IP地址配置为允许访问的地址。

b.     检查中间网络连通性以及排查DNS服务器故障,在网关上进行流量统计(分别对连接终端下行接口和连接DNS服务器的上行接口)或镜像获取终端访问DNS服务器的报文,确认网关是否已将DNS请求发出,但却未收到回应报文。

(5)     HTTPS重定向功能是否开启。

a.     确认用户是否访问HTTPS网站。若是,由于Portal需要对用户的HTTPS请求进行重定向,因此就必须在设备上配置对HTTPS报文进行重定向的内部侦听端口号(通过http-redirect https-port命令)。缺省情况下,设备对HTTPS报文进行重定向的内部侦听端口号为6654。在配置内部侦听端口号之前,需确保该端口号没有被其他服务占用,请先通过display tcp命令查看已被占用的TCP端口号。

b.     检查HTTPS重定向服务器关联的SSL服务器端策略是否存在,若不存在,请完善相关配置。

(6)     HTTPS网站开启了HSTS功能。

HTTPS网站开启了HSTS功能后,要求浏览器必须使用HTTPS访问,而且证书必须要合法。设备对用户浏览器进行HTTPS重定向时,设备会使用自签名证书(设备没有目标网站的证书,只能使用自签名证书)伪装成目标网站和浏览器建立SSL连接,此时浏览器一旦检测到证书不受信任,将会导致HTTPS重定向失败,无法弹出Portal认证页面。这种情况依赖于具体网站配置的HSTS协议的强制要求,无法解决。此时,建议用户更换其他网站进行尝试。

(7)     Portal服务器配置是否正确。

¡     检查Portal服务器上是否配置了IP地址组,以及是否将设备与IP地址组关联。

¡     检查终端IP地址是否在Portal服务器上配置的IP地址组范围内。

(8)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息和告警信息。

¡     服务器上Portal相关配置截图。

¡     设备与服务器之间的抓包文件。

¡     在浏览器上对问题现象进行截图。

¡     在设备上通过display portal rule命令查看用于报文匹配的Portal过滤规则信息。

¡     出现问题时,在设备上通过debugging portaldebugging http-redirect alldebugging ip packet命令收集Debug信息。

5. 告警与日志

相关告警

相关日志

14.3.2  Portal认证失败

1. 故障描述

Portal用户认证失败或者认证异常。

2. 常见原因

本类故障的常见原因主要包括:

·     设备上Portal服务器视图下配置的共享密钥和Portal认证服务器上配置的不一致。

·     设备上Portal服务器视图下配置的Portal认证服务器地址不存在。

·     Portal报文非法。

·     Portal用户使用的认证域配置错误。

·     RADIUS视图下配置共享密钥与RADIUS服务器上配置的不一致。

·     获取用户物理信息失败。

·     RADIUS服务器认证拒绝。

·     RADIUS服务器无响应。

·     授权ACL或者User Profile下发失败。

3. 故障分析

本类故障的诊断流程如图14-24所示。

图14-24 Portal认证失败的故障诊断流程图

 

4. 处理步骤

(1)     检查设备上Portal服务器视图下配置的共享密钥与Portal认证服务器上配置的是否一致。

图14-25所示,以iMC服务器为例,当输入“用户名”和“账号密码”,点击“上线”后登录界面上出现“向设备发送请求超时”的提示,表示设备上Portal服务器视图下配置的共享密钥有可能与服务器上配置的不一致。

图14-25 Portal登录界面打印错误提示

 

此时,可以通过如下方法来检查:

¡     在设备上执行debugging portal error命令,打开Portal错误调试信息开关。如果设备上打印如下信息,则可以确认设备和Portal服务器配置的共享密钥不一致。

*Jul 28 17:51:20:774 2021 Sysname PORTAL/7/ERROR: -MDC=1; Packet validity check failed due to invalid key.

如果确认不一致,请修改设备上Portal服务器视图下配置的共享密钥或者Portal认证服务器上配置的共享密钥,使其两者保持一致。

(2)     检查设备上Portal服务器视图下配置的Portal认证服务器地址是否存在。

当设备收到Portal服务器发送的认证报文时,设备会校验报文的源IP地址是否在设备上已配置的Portal认证服务器地址列表中。如果不在,则认为认证报文是非法报文,会将它丢弃。

图14-26所示,以iMC服务器为例,当输入“用户名”和“账号密码”,点击“上线”后登录界面上出现“向设备发送请求超时”的提示,表示设备上Portal服务器视图下配置的Portal认证服务器地址可能不存在。

图14-26 Portal登录界面打印错误提示

 

此时,可以通过如下方法来检查:

¡     在设备上执行debugging portal error命令,打开Portal错误调试信息开关。如果设备上打印如下信息,则可以确认设备上配置的Portal认证服务器IP地址错误。

*Jul 28 19:15:10:665 2021 Sysname PORTAL/7/ERROR: -MDC=1;Packet source unknown. Server IP:192.168.161.188, VRF Index:0.

¡     如果确认不正确,请在设备的Portal服务器视图下,执行ip命令修改Portal服务器的IP地址。

(3)     检查Portal报文是否非法。

设备收到Portal服务器发送的Portal协议报文后,会对报文做合法性校验。如果报文长度不对、报文校验段错误,则该报文将被视为非法报文而丢弃。

可以通过如下方法来检查Portal协议报文是否非法:

¡     通过display portal packet statistics命令查看是否存在非法报文计数增长,如果存在,可通过在设备上执行debugging portal error命令,打开Portal错误调试信息开关排查具体原因。

如果Portal协议报文非法,请确认报文非法的原因并进行修改,使Portal协议报文成为合法报文。

(4)     检查Portal用户使用的认证域配置。

Portal用户将按照如下先后顺序选择认证域:接口上指定的Portal用户使用的ISP域-->用户名中携带的ISP域-->系统缺省的ISP域。如果根据以上原则决定的认证域在设备上不存在,且设备上为未知域名的用户指定了此不存在的ISP域,将会导致用户将无法认证。

通过display portal命令查看认证接口上是否引用了认证域。

¡     如果引用了认证域,确认设备上是否存在该认证域以及该域下的认证、授权、计费方案是否配置准确。

¡     如果没有引用认证域,请检查用户名中携带的域是否存在,如果不存在,请检查是否存在缺省认证域并确认缺省域下配置是否正确。

¡     如图14-27所示,以iMC为例,当输入“用户名”和“账号密码”,点击“上线”后登录界面上出现“设备拒绝请求”的提示,表示设备上认证域可能配置不正确。

图14-27 Portal登录界面打印错误提示

 

此时,可以通过如下方法来检查:

¡     在设备上执行debugging portal error命令,打开Portal错误调试信息开关。如果设备上打印如下信息,则可能是设备上认证域配置错误,需要进一步排查。

*Jul 28 19:49:12:725 2021 Sysname PORTAL/7/ERROR: -MDC=1; User-SM [21.0.0.21]: AAA processed authentication request and returned error.

如果认证域配置不正确,请执行相应的命令将Portal用户使用的认证域配置修改正确。

(5)     检查RADIUS视图下配置共享密钥是否与RADIUS服务器上配置的一致。

图14-28所示,以iMC服务器为例,当输入“用户名”和“账号密码”,点击“上线”后登录界面上出现“向设备发送请求超时”的提示,表示RADIUS视图下共享密钥和服务器上配置的不一致。

图14-28 Portal登录界面打印错误提示

 

在设备上执行debugging radius error命令,打开RADIUS错误调试信息开关。如果设备上打印如下信息,则可以确认设备上RADIUS视图下配置共享密钥和RADIUS服务器上配置的不一致。

*Jul 28 19:49:12:725 2021 Sysname RADIUS/7/ERROR: -MDC=1; The response packet has an invalid Response Authenticator value.

当设备向RADIUS服务器发起认证请求时,服务器会首先对请求报文使用共享密钥进行校验,如果校验失败,服务器会通知设备校验失败。如果共享密钥配置错误,请将RADIUS视图下共享密钥和服务器上配置的保持一致。

(6)     检查是否获取用户物理信息失败。

用户上线过程中Portal会查找用户物理信息,并根据对应的物理信息确定用户所在的接口等信息。如果查找物理信息失败,则用户会上线失败。

可通过如下方式进行检查:

¡     在设备上执行debugging portal event命令,打开Portal事件调试信息开关。如果设备上打印如下信息,表示获取用户物理信息失败。

*Jul 28 19:49:12:725 2021 Sysname PORTAL/7/ERROR: -MDC=1; User-SM [21.0.0.21]: Failed to find physical info for ack_info.

确认获取用户物理信息失败后,请排查设备是否存在该认证用户的表项,如果不存在,请进一步排查具体原因。

(7)     检查RADIUS服务器是否认证拒绝。

a.     RADIUS服务器回应认证拒绝有多种原因,最常见的有用户名密码错误、RADIUS服务器授权策略无法匹配等。这些问题,首先需要查看服务器端的认证日志或者在设备上通过debugging radius error命令打开RADIUS错误调试信息开关查看相关的Debug信息找到根本原因后,再调整服务器、终端或设备配置。

(8)     检查RADIUS服务器是否无响应。

¡     可通过如下三种方式来检查RADIUS服务器是否回应。

¡     执行display radius scheme命令,通过State字段查看服务器状态。如果为Blocked则表示服务器不可用。

¡     查看设备是否打印如下日志:

RADIUS/4/RADIUS_AUTH_SERVER_DOWN: -MDC=1; RADIUS authentication server was

blocked: server IP=192.168.161.188, port=1812, VPN instance=public.

¡     在设备上执行debugging radius event命令打开RADIUS事件调试信息开关,如果设备上打印如下信息,表示RADIUS服务器无回应。

*Jul 28 19:49:12:725 2021 Sysname RADIUS/7/evnet: -MDC=1; Reached the maximum retries.

¡     确认RADIUS服务器无响应后,可根据如下步骤进行处理:

a.     确认服务器是否添加了设备IP地址。

-     如果没有添加,请添加正确的设备IP地址。如果已经添加,那么需要确定服务器添加的设备IP地址与认证请求的源IP地址是否一致(设备默认出接口的IP地址作为向RADIUS服务器发送RADIUS报文时使用的源IP地址)。

-     如果已添加,则需确认服务器上添加的设备IP地址必须为认证请求的源IP地址。

b.     确认设备和服务器上同时获取报文确认中间链路是否存在问题,例如中间网络存在防火墙,防火墙未放通RADIUS(默认认证端口:1812)报文。如果出现大量用户无法认证,设备上的日志里出现RADIUS服务器Down记录,那么大概率是服务器或中间网络出现异常,需要逐一排查。

(9)     检查是否授权ACL或者UserProfile下发失败。

如果设备上开启了Portal的授权信息严格检查模式,当认证服务器下发的授权ACL、User Profile在设备上不存在或者设备下发User Profile失败时,设备将强制Portal用户下线。

a.     通过查看display portal命令的Strict checking字段确认设备上是否开启了严格检查,再根据用户需求判断是否需要开启。如果不需要,直接关闭。如果需要,请执行步骤b

b.     通过在设备上执行display acl或者display user-profile命令,确认AAA服务器是否授权了不存在的ACL或者User Profile。如果不存在,请确认服务器是否需要授权或者在设备上增加相应的ACL或User Profile配置。

(10)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

¡     收集信息

¡     Portal服务器上Portal相关配置截图。

¡     设备与AAA服务器间的抓包文件。

¡     在客户端浏览器上对问题现象截图。

¡     通过开启debugging portal命令收集调试信息。

5. 告警与日志

相关告警

相关日志

·     RADIUS/4/RADIUS_AUTH_SERVER_DOWN

14.3.3  Portal认证用户掉线

Portal用户上线一段时间后掉线。

1. 常见原因

本类故障的常见原因主要包括:

·     用户会话超时时间超时。

·     用户闲置切断。

·     计费更新失败。

·     用户流量达到阈值。

·     服务器强制用户下线。

·     用户在线探测失败下线。

·     用户上线的接口down。

2. 故障分析

本类故障的诊断流程如图14-29所示。

图14-29 Portal认证用户掉线的故障诊断流程图

 

3. 处理步骤

(1)     检查用户会话超时时间是否超时。

如果AAA服务器给Portal用户下发了会话时长,即用户单次在线时长。用户在线时长超过会话时长后,设备会触发用户下线。

可通过如下三种方法确认是否因会话超时导致Portal用户下线:

¡     查看AAA服务器上记录的用户下线记录。

¡     在设备上执行debugging portal error命令,打开Portal错误调试信息开关。如果设备上打印如下信息,则可以确认因用户会话超时导致Portal用户下线。

*Jul 28 17:51:20:774 2021 Sysname PORTAL/7/ERROR: -MDC=1; Session timer timed out and the user will be logged off.

用户会话超时触发的下线属于正常下线,用户重新上线即可。

(2)     检查是否为用户闲置切断。

如果设备或者AAA服务器授权了用户闲置切断时长,用户上线后,设备会周期性检测用户的流量,若某用户在指定的闲置检测时间内产生的流量小于指定的数据流量,则会被强制下线。

可通过如下三种方法确认是否因用户闲置切换功能导致Portal用户下线:

¡     查看AAA服务器上记录的用户下线记录。

¡     在设备上执行debugging portal error命令,打开Portal错误调试信息开关。如果设备上打印如下信息,则可以确认因用户会话超时导致Portal用户下线。

*Jul 28 17:51:20:774 2021 Sysname PORTAL/7/ERROR: -MDC=1; Idle-cut timer timed out and the user will be logged off.

¡     用户闲置切断触发的下线属于正常下线,用户重新上线即可。

(3)     检查是否为计费更新失败。

远程Portal认证用户上线,设备会定期向AAA服务器发送计费更新报文。当设备与AAA服务器链路不通或者服务器故障时,计费更新报文会发送失败。当达到最大重传次数后,如果计费更新报文还是发送失败并且设备上配置了用户计费更新失败策略(通过accounting update-fail offline命令配置),则触发用户下线。

可通过如下方法确认是否因计费更新失败导致用户下线:

¡     通过display interface查看设备上连接AAA服务器的端口是否发生过变化,检查AAA服务器否有异常记录等。或者通过display radius scheme命令显示的State字段查看服务器状态是否为Block,如果是,则可能是计费更新失败导致的下线。

¡     在设备上执行debugging portal error命令,打开Portal错误调试信息开关。如果设备上打印如下信息,则可以确认因用户会话超时导致Portal用户下线。

*Jul 28 17:51:20:774 2021 Sysname PORTAL/7/ERROR: -MDC=1; Processed accounting-update failed and user logout.

如果确认是计费更新失败导致的用户下线,请检查设备与服务器之间的链路状态,以及设备和AAA服务器的相关计费配置是否发生过更改。

(4)     检查是否为用户流量达到阈值。

用户上线时,如果AAA服务器下发了流量阈值,当用户的流量超过AAA服务器下发的流量阈值时,设备就会强制用户下线。

¡     可通过如下方法确认是否因用户流量达到阈值导致用户下线:

¡     查看AAA服务器上记录的用户下线记录。

¡ 用户流量达到阈值触发的下线属于正常下线,用户重新上线即可。

(5)     检查是否为AAA服务器主动踢用户下线。

设备上开启了RADIUS session control功能后,若收到AAA服务器的断开连接请求,则会立马强制对应的用户下线。首先查看设备上是否开启了(通过radius session-control enable命令配置)。如果开启了,则可以通过如下方法查看是否因AAA服务器强制用户下线导致用户下线:

¡     查看AAA服务器上记录的用户下线记录。

服务器为何强制用户下线,请联系服务器管理员进行确认。

(6)     检查是否为Portal用户在线探测失败导致用户下线。

如果设备上开启了Portal用户在线探测功能(通过portal user-detect命令配置),设备会定期向用户终端发送探测报文。若在指定探测次数内,设备未收到终端的回应,则强制用户下线。

确认设备上是否开启了Portal用户在线探测功能。如果开启了,则可以通过如下方法确认是否因用户在线探测失败导致用户下线:

¡     查看AAA服务器上记录的用户下线记录。

如果确认是因Portal用户在线探测导致用户下线,请检查终端和设备之间的链路状态,排查终端没有回应探测报文的原因。

(7)     检查Portal用户上线的接口是否down。

如果Portal用户上线的接口down了一段时间后,设备会强制从该接口接入的Portal用户全部下线。

¡     可通过如下方法确认是否因接口down导致用户下线:

¡     查看AAA服务器上的用户下线记录。

¡     通过display interface命令查看接口的状态是否发生过变化,如果发生变化的时间正好和用户下线的时间接近,则可能是接口down触发的用户下线。

如果确认是接口down导致的下线,请排查接口down的原因,如网线口松动等。

(8)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

¡     Portal服务器上Portal相关配置截图。

¡     AAA服务器上记录的用户下线记录。

¡     设备与服务器间的抓包文件。

¡     在客户端浏览器上对问题现象截图。

¡     通过开启debugging portal命令收集调试信息。

4. 告警与日志

相关告警

相关日志


15 安全类故障处理

15.1  SSH故障处理

15.1.1  SSH客户端登录设备失败

1. 故障描述

设备作为SSH服务器,用户使用SSH客户端登录设备失败。

2. 常见原因      

本类故障的常见原因主要包括:

·     SSH客户端与设备之间路由不通,无法建立TCP连接。

·     设备未开启SSH服务器功能。

·     设备上配置了对SSH客户端的访问控制,且客户端的IP地址不在ACL定义的permit规则范围内。

·     客户端指定的服务端口号与服务器端不一致。

·     设备上的SSH版本与客户端不兼容。

·     设备上未生成本地密钥对。

·     服务器主机密钥与设备上缓存的密钥不匹配。

·     用户线的认证方式或接入协议配置不正确。

·     设备上的本地用户视图下未配置SSH服务。

·     SSH用户的服务类型或认证方式配置不正确。

·     设备上SSH2协议使用的算法与客户端不匹配。

·     设备上VTY用户线资源不足。

·     设备上SSH登录用户数达到上限。

3. 故障分析

本类故障的诊断流程如图15-1所示。

图15-1 SSH登录失败故障诊断流程图

 

4. 处理步骤

(1)     检查客户端能否Ping通设备。

使用ping命令检查网络连接情况。

¡     如果Ping不通,请参见“Ping不通的定位思路”继续定位,确保SSH客户端能Ping通服务器端。

¡     如果可以Ping通,请执行步骤(2)

(2)     检查SSH服务器功能是否开启。

当设备上出现如下日志时,表示SSH服务器功能未开启。

SSHS/6/SSHS_SRV_UNAVAILABLE: The SCP server is disabled or the SCP service type is not supported.

可以在设备上执行display ssh server status命令,检查Stelnet服务器功能、SFTP服务器功能、NETCONF over SSH服务器功能和SCP服务器功能是否按需开启。

<Sysname> display ssh server status

 Stelnet server: Disable

 SSH version : 2.0

 SSH authentication-timeout : 60 second(s)

 SSH server key generating interval : 0 hour(s)

 SSH authentication retries : 3 time(s)

 SFTP server: Disable

 SFTP Server Idle-Timeout: 10 minute(s)

 NETCONF server: Disable

 SCP server: Disable

¡     如果未开启,请在设备上执行如下命令,开启相关的SSH服务器功能。

<Sysname> system-view

[Sysname] ssh server enable

[Sysname] sftp server enable

[Sysname] scp server enable

[Sysname] netconf ssh server enable

¡     如果已开启,请执行步骤(3)

(3)     检查是否设置了对客户端的访问控制。

首先检查设备上是否通过ssh server acl命令设置了对客户端的访问控制。

¡     如果已设置,请检查客户端的IP地址是否在ACL的permit规则中。

¡     当设备上出现如下日志时,表示客户端的IP地址不在ACL的permit规则中。

SSHS/5/SSH_ACL_DENY: The SSH connection request from 181.1.1.10 was denied by ACL rule (rule ID=20).

SSHS/5/SSH_ACL_DENY: The SSH connection request from 181.1.1.11 was denied by ACL rule (default rule).

-     如果不在,请修改ACL配置,使得客户端的IP地址在ACL的permit规则中。如果对所有SSH客户端都不需要进行访问控制,请删除对客户端的访问控制。

-     如果在,请执行步骤(4)

¡     如果未设置,请执行步骤(4)

(4)     检查客户端指定的服务端口号是否与服务器端一致。

如果服务器端修改了SSH服务端口号,客户端仍然使用缺省端口号登录时,会出现登录失败。

以我司设备作为客户端为例,会出现如下错误提示信息:Failed to connect to host 10.1.1.1 port 100.

¡     如果客户端登录时指定的端口号与服务器端不一致,请在服务器端设备上执行display current-configuration | inc ssh命令查看服务器端配置的端口号,将客户端登录时指定的端口修改为与服务器端一致。

¡     如果客户端登录时指定的端口号与服务器端一致,请执行步骤(5)

(5)     检查服务器的SSH版本与客户端版本是否兼容。

当设备上出现如下日志时,表示设备的SSH版本与客户端版本不兼容。

SSHS/6/SSHS_VERSION_MISMATCH: SSH client 192.168.30.117 failed to log in because of version mismatch.

如果使用SSH1版本的客户端登录设备,可以在设备上执行display ssh server status命令查看SSH version字段确认SSH版本。

¡     如果SSH version显示为1.99,则表示设备可以兼容SSH1版本的客户端,请执行步骤(6)

¡     如果SSH version显示为2.0,请在设备上执行ssh server compatible-ssh1x enable命令设置设备兼容SSH1版本的客户端。

(6)     检查服务器上是否生成了本地密钥对。

设备作为SSH服务器时,必须配置本地非对称密钥对。虽然一个客户端只会采用DSA、ECDSA或RSA公钥算法中的一种来认证服务器,但是由于不同客户端支持的公钥算法不同,为了确保客户端能够成功登录服务器,建议在服务器上生成DSA、ECDSA和RSA三种密钥对。

在设备上执行display public-key local public命令查看当前设备上的密钥对信息。

¡     如果DSA、ECDSA和RSA三种密钥对都不存在,请执行public-key local create命令依次进行配置。

¡     如果已配置,请执行步骤(7)

(7)     检查服务器主机密钥与客户端上缓存的服务器主机密钥对是否一致。

如果客户端首次登录服务器设备时选择保存了服务器端主机密钥,当服务器设备更新本地密钥对后,将会导致客户端认证服务端失败。

以我司设备作客户端为例,当客户端登录时,出现如下提示信息,则表示服务器主机密钥与客户端上本地缓存的密钥不一致。

The server's host key does not match the local cached key. Either the server administrator has changed the host key, or you connected to another server pretending to be this server. Please remove the local cached key, before logging in!

¡     如果不一致,请执行undo public-key peer命令,删除客户端保存的旧的服务端主机密钥。

¡     如果一致,请执行步骤(8)

(8)     查看VTY用户线下配置的认证方式及允许接入的协议是否正确。

当客户端为Stelnet客户端和NETCONF over SSH客户端时,需要在VTY用户线视图下,执行display this命令查看配置的认证方式是否为scheme、允许接入的协议是否包含SSH。

[Sysname] line vty 0 63

[Sysname-line-vty0-63] display this

#

line vty 0 63

 authentication-mode scheme

 user-role network-admin

 idle-timeout 0 0

#

¡     如果认证方式或者接入协议配置不正确,请将认证方式修改为scheme、将允许接入的协议修改为包含SSH。

¡     如果均配置正确,请执行步骤(9)

(9)     检查本地用户是否授权了SSH服务。(仅针对本地认证)

在本地用户视图下,执行display this命令查看用户可以使用的服务类型是否包含SSH。

[Sysname] local-user test

[Sysname-luser-manage-test] display this

#

local-user test class manage

 service-type ssh

 authorization-attribute user-role network-admin

 authorization-attribute user-role network-operator

#

¡     如果不包含,请在本地用户视图下通过service-type命令修改配置。

¡     如果包含,请执行步骤(10)

如果为远程认证方式,请参见“AAA故障处理”进行定位。

(10)     检查是否配置了SSH用户并指定正确的服务类型和认证方式。

SSH支持Stelnet、SFTP、NETCONF和SCP四种用户服务类型。

首先,根据服务器采用的认证类型,根据如下规则,查看设备上是否创建正确的SSH用户。

¡     如果服务器采用了publickey认证,则必须在设备上创建相应的SSH用户,以及同名的本地用户(用于下发授权属性:工作目录、用户角色)。

¡     如果服务器采用了password认证,则必须在设备上创建相应的本地用户(适用于本地认证),或在远程服务器(如RADIUS服务器,适用于远程认证)上创建相应的SSH用户。这种情况下,并不需要通过本配置创建相应的SSH用户,如果创建了SSH用户,则必须保证指定了正确的服务类型以及认证方式。

¡     如果服务器采用了keyboard-interactive、password-publickey或any认证,则必须在设备上创建相应的SSH用户,以及在设备上创建同名的本地用户(适用于本地认证)或者在远程认证服务器上创建同名的SSH用户(如RADIUS服务器,适用于远程认证)。

接着,根据检查的结果,进行如下操作:

¡     如果未创建且无需创建,请执行步骤(11);如果未创建但有需求创建,请通过ssh user命令进行配置。

¡     如果已创建,检查SSH用户的服务类型和认证方式。

-     SSH用户指定的服务类型必须与客户端类型(Stelnet客户端、SFTP客户端、SCP客户端和NETCONF over SSH客户端)相匹配,否则将会因为服务类型不匹配而登录失败。SSH用户服务类型是否正确,通过如下方式来检查:

以SCP客户端为例,如果设备上出现如下日志,表示服务类型不匹配。SSHS/6/SSHS_SRV_UNAVAILABLE: The SCP server is disabled or the SCP service type is not supported.

请在设备系统视图下执行ssh user命令,修改SSH用户的服务类型。

-     请在设备上执行display ssh user-information命令,查看SSH服务器采用的认证方式,根据具体的认证方式检查设备上SSH用户的配置是否正确。

(11)     检查设备上SSH2协议使用的算法列表是否与客户端匹配。

通过display ssh2 algorithm命令查看当前SSH2协议使用的算法列表,检查客户端支持的算法是否包含在算法列表中。比如,设备上配置了不使用CBC相关的加密算法,但SSH客户端仅支持CBC相关加密算法,将导致该客户端无法登录服务器。

当设备上出现如下日志信息时,表示设备上SSH2协议使用的算法列表是否与客户端不匹配。

SSHS/6/SSHS_ALGORITHM_MISMATCH: SSH client 192.168.30.117 failed to log in because of encryption algorithm mismatch.

¡     如果客户端使用的算法与设备上的算法不匹配,可通过如下两种方式进行修改:

-     设备可以通过执行ssh2 algorithm cipherssh2 algorithm key-exchangessh2 algorithm macssh2 algorithm public-key命令修改相关算法列表,增加客户端支持的算法。

-     在客户端添加服务端支持的相关算法。

¡     如果客户端使用的算法与设备上的算法能够匹配,请执行步骤(12)

(12)     检查设备上VTY用户数是否达到允许用户数的上限。

SSH用户与Telnet用户登录均使用VTY用户线,但是VTY用户线是有限资源。若VTY类型用户线都已被占用,则后续使用Stelnet及NETCONF over SSH服务的客户端将无法登录,使用SFTP及SCP服务的客户端不占用用户线资源,不受影响,仍可登录。

当设备上出现如下日志时,表示设备上VTY用户数已达到允许用户数的上限。

SSHS/6/SSHS_REACH_USER_LIMIT: SSH client 192.168.30.117 failed to log in, because the number of users reached the upper limit.

通过display line命令查看VTY用户线资源是否充足。

¡     如果VTY用户线资源不足,可将空闲且非scheme认证方式的VTY类型用户线认证方式修改为scheme认证方式;若所有VTY类型用户线都已是scheme认证方式且均处于active状态,可执行free line vty命令强制释放VTY用户线,使得新的SSH用户能够上线。

¡     如果VTY用户线资源充足,请执行步骤(13)

(13)     检查登录服务器的SSH用户数是否达到允许用户数的上限。

通过display ssh server session命令查看服务器的会话信息,以及查看通过aaa session-limit ssh命令配置的SSH最大用户连接数。

当设备上出现如下日志时,表示登录服务器的SSH用户数已达到允许用户数的上限。

SSHS/6/SSHS_REACH_SESSION_LIMIT: SSH client 192.168.30.117 failed to log in. The number of SSH sessions is 10, and exceeded the limit (10).

¡     如果SSH会话数已达到上限,可通过执行aaa session-limit ssh命令调大上限;如果配置的最大用户连接数已为可配置的最大值,可客户端下线空闲的SSH客户端,使得新的SSH用户能够上线。

¡     如果未达上限,请执行步骤(14)

(14)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

5. 告警与日志

相关告警

模块名:HH3C-SSH-MIB

·     hh3cSSHVersionNegotiationFailure (1.3.6.1.4.1.25506.2.22.1.3.0.2)

相关日志

·     SSHS/5/SSH_ACL_DENY

·     SSHS/6/SSHS_ALGORITHM_MISMATCH

·     SSHS/6/SSHS_REACH_SESSION_LIMIT

·     SSHS/6/SSHS_REACH_USER_LIMIT

·     SSHS/6/SSHS_SRV_UNAVAILABLE

·     SSHS/6/SSHS_VERSION_MISMATCH


16 网络管理和监控类故障处理

16.1  Ping和Tracert故障处理

16.1.1  Ping不通

1. 故障描述

在源端执行Ping操作,在一定时间范围内没有收到目的端对该请求的回应。

2. 常见原因

存在三种故障情形:

·     源端没有发出请求报文。

·     目的端没有发出应答报文。

·     中间设备丢包或传输时间长。

本类故障的常见原因主要包括:

·     链路传输时延较长。由于传输时延长,虽然源端接收到了目的端的回应报文,但已经超过等待时限而造成Ping不通的现象。

·     配置不当。例如,当Ping报文过大时,报文的出接口MTU值较小,且设置了不可分片的功能等。

·     FIB表或ARP表中缺少对应的表项。

·     存在防攻击配置。

·     硬件故障。

3. 故障分析

本类故障的诊断思路如下:

(1)     检查Ping操作是否得当,调整Ping操作参数。

(2)     查看Ping报文的统计信息,确认出问题的节点。

(3)     检查是否存在到达目的端的ARP以及FIB表项。

(4)     排查是否因为防攻击配置导致Ping报文被丢弃。

本类故障的诊断流程如图16-1所示。

图16-1 Ping不通故障诊断流程图

 

4. 处理步骤

(1)     检查Ping操作是否得当。

a.     检查是否因为实际链路传输时延较长导致Ping不通。

检查是否执行了ping -t timeout命令,如果执行了此操作,可通过增加-t参数的值(建议取值大于等于1000,达到秒级)或者去掉-t参数重新Ping。如果故障消除,则说明较大概率属于实际网络时延大导致的Ping不通;如果故障未消除,请继续定位。

说明

-t参数用来指定ICMP回显应答(ECHO-REPLY)报文的超时时间,单位为毫秒,缺省值为2000。如果源端在timeout时间内未收到目的端的ICMP回显应答(ECHO-REPLY)报文,则会认为目的端不可达。

 

b.     检查是否因为Ping报文过大而被丢弃。

检查是否执行了ping -f –s packet-size命令,如果执行了此操作,且报文转发路径上存在出接口的MTU小于报文长度packet-size的情况,则会导致报文因为超大且不允许被分片而被丢弃。可以通过减小报文长度或者取消-f参数来解决这个问题。

说明

·     -f参数表示将长度大于出接口MTU的报文直接丢弃,即不允许对发送的ICMP回显请求报文进行分片。

·     -s packet-size参数用来指定发送的ICMP回显请求报文的长度(不包括IP和ICMP报文头),单位为字节,缺省值为56。

 

以太网接口MTU的缺省值为1500字节,可以通过执行display interface命令来查看接口的MTU值:

<Sysname> display interface gigabitethernet 1/0/1

GigabitEthernet1/0/1

Current state: UP

Line protocol state: UP

Description: GigabitEthernet1/0/1 Interface

Bandwidth: 1000000 kbps

Maximum transmission unit: 1500

其它显示信息略……

c.     检查是否指定了错误的出接口。

检查是否执行了ping -i interface-type interface-number命令指定Ping报文的出接口。如果指定了出接口,请确保该接口和目的端之间的物理链路是否可达。否则,请换成其它接口或者去掉-i参数。

说明

-i interface-type interface-number参数用来指定发送ICMP回显请求报文的接口的类型和编号。不指定该参数时,将根据目的IP查找路由表或者转发表来确定发送ICMP回显请求报文的接口。

 

d.     检查是否指定了源地址。

检查是否执行了ping –a source-ip命令指定Ping报文的源地址。如果执行了该命令,请确保中间设备和目的端有到达源地址source-ip的路由。

说明

-a source-ip:指定ICMP回显请求(ECHO-REQUEST)报文的源IP地址。该地址必须是设备上已配置的IP地址。不指定该参数时,ICMP回显请求报文的源IP地址是该报文出接口的主IP地址。

 

e.     检查是否为目的端指定了准确的VPN。

根据网络规划和部署情况,确认目的端是否属于某个VPN。如果目的端属于某个VPN,则需要在执行ping命令时通过-vpn-instance参数指定目的端所属的VPN。

(2)     查看源端、目的端以及中间设备的收发包统计,确认Ping故障发生的方向。

¡     检查源端是否发出了ICMP回显请求报文,并收到了ICMP回显应答报文。

源端执行Ping操作后,在源端和目的端分别使用display icmp statistics命令查看ICMP报文收发情况。可以根据统计信息中Input和Output区段报文的数量来确定Ping出现问题的方向:

-     如果源端Output区段的echo值正常增加,但Input区段的echo replies值没有增加,则说明源端发出了请求但是没有收到回应;与此同时,如果目的端Input区段和Output区段的计数都没有变化,则说明目的端没有收到请求也没有给予回应。这样,就可以确定Ping报文是在从源端到目的端的方向上出现了转发故障。

-     如果源端Output区段的echo值正常增加,但Input区段的echo replies值没有增加,则说明源端发出了请求但是没有收到回应;与此同时,如果目的端Input区段和Output区段的计数都正常增加,则说明目的端收到了请求,同时发出了回应。这样,就可以确定Ping报文是在从目的端到源端的方向上出现了转发故障。

display icmp statistics命令显示信息示例如下:

<Sysname> display icmp statistics

  Input: bad formats   0          bad checksum            0

         echo          1          destination unreachable 0

         source quench 0          redirects               0

         echo replies  0          parameter problem       0

         timestamp     0          information requests    0

         mask requests 0          mask replies            0

         time exceeded 0          invalid type            0

         router advert 0          router solicit          0

         broadcast/multicast echo requests ignored        0

         broadcast/multicast timestamp requests ignored   0

 Output: echo          0                 destination unreachable 0

         source quench 0                 redirects               0

         echo replies  1                 parameter problem       0
         timestamp     0                 information replies     0

         mask requests 0                 mask replies            0

         time exceeded 0                 bad address             0

         packet error  0                 router advert           0

其它显示信息略……

提示

·     当目的端是框式设备或者IRF设备,且ICMP报文到达目的端未被分片时,请在目的端执行带slot参数的display icmp statistics命令来查看ICMP报文统计信息,slot为目的端接收该ICMP报文的接口所在的Slot。

·     当目的端是框式设备或者IRF设备,但ICMP报文到达目的端前被分片了,请在目的端执行display icmp statistics命令来查看ICMP报文统计信息即可。

 

(3)     确定出问题的节点。

确定了Ping故障的发生的方向后,请执行tracert命令确定该方向上报文丢失的位置。

¡     如果源端到目的端方向出现了问题,请从源端开始排查。

¡     如果目的端到源端方向出现问题,请从目的端开始排查。

如下例所示,可以通过tracert命令查看报文从源端到目的端(IP地址为1.1.3.2,属于vpn1)所经过的路径,并显示报文经过的私网中的三层设备的信息。

<Sysname> tracert –vpn-instance vpn1 –resolve-as vpn 1.1.3.2

traceroute to 1.1.3.2 (1.1.3.2), 30 hops at most, 40 bytes each packet, press CTRL+C to break

 1  1.1.1.2 (1.1.1.2) 673 ms 425 ms 30 ms

 2  1.1.2.2 (1.1.2.2) 580 ms 470 ms 80 ms

 3  * * *

由以上信息可判断,Ping报文在1.1.2.2的下一跳设备上(即显示为“3 * * *”的节点)出现转发故障。

(4)     检查是否存在到达目的端和源端的FIB表项与ARP表项。

请在问题节点上执行以下操作:

¡     执行display fib命令检查是否存在到达目的端和源端的路由。如果路由不存在,请检查OSPF、IS-IS、BGP等路由协议配置是否有误。

¡     如果路由存在并且报文所经链路是以太链路,请执行display arp命令查看是否存在所需的ARP表项。如果ARP表项不存在,请首先排查ARP故障。

(5)     检查问题节点上是否配置ICMP防攻击功能。

如果设备上配置了ICMP攻击相关的防范策略,且设备检测到ICMP攻击,设备会将ICMP报文直接丢弃,从而导致Ping不通。

¡     通过display attack-defense icmp-flood statistics ip命令查看统计信息的计数来判断设备是否受到了ICMP攻击。

¡     通过display current-configuration | include icmp-flooddisplay current-configuration | include signature detect查看当前是否配置攻击防范策略。

如果设备受到了ICMP攻击,请先定位并解除ICMP攻击。

(6)     根据收发包统计,确认丢包位置和丢包原因。

在Ping报文途径的设备上:

a.     配置QoS策略,使用ACL源地址和目的地址过滤Ping报文,然后在Ping报文途径接口的入方向和出方向应用QoS策略。

b.     通过display qos policy interface命令查看应用QoS策略的接口上QoS策略匹配成功的报文个数。如果报文个数有增长,则说明设备收到了Ping报文;如果报文个数无增长,则说明设备没有收到Ping报文,此时,可以使用debugging ip packet命令打开IP报文调试信息开关,进一步排查设备没有收到Ping报文的原因并解决问题。

(7)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

5. 告警与日志

相关告警

相关日志

16.1.2  Tracert不通

1. 故障描述

执行Tracert操作,显示信息中出现“* * *”行,说明某些节点之间路由不可达,Tracert不通。

2. 常见原因

本类故障的常见原因主要包括:

·     无对应的路由或者ARP表项。

·     中间设备未开启ICMP超时报文发送功能。

·     目的端未开启ICMP目的不可达报文发送功能。

3. 故障分析

本类故障的诊断思路如下:

(1)     检查中间设备是否开启了ICMP超时报文发送功能。

(2)     检查目的端是否开启了ICMP目的不可达报文发送功能。

(3)     检查是否存在达到目的端的ARP以及FIB表项。

本类故障的诊断流程如图16-2所示。

图16-2 Tracert不通故障诊断流程图

 

4. 处理步骤

(1)     检查中间设备是否开启了ICMP超时报文发送功能。

# 查看报文从源端到目的端所经过的路径(假设源端到目的端只有两跳,目的端的IP地址为1.1.2.2)。

<Sysname> tracert 1.1.2.2

traceroute to 1.1.2.2 (1.1.2.2), 30 hops at most, 40 bytes each packet, press CTRL+C to break

 1 * * *

 2 1.1.2.2 (1.1.2.2) [AS 100] 580 ms 470 ms 80 ms

出现以上显示信息时,请登录中间设备,在中间设备上执行ip ttl-expires enable命令开启ICMP超时报文发送功能。如果故障排除,则说明中间设备未开启ICMP超时报文发送功能导致Tracert不通;如果故障未排除,请继续执行下面的步骤。

(2)     检查目的端是否开启了ICMP目的不可达报文发送功能。

# 查看报文从源端到目的端所经过的路径(假设源端到目的端只有两跳,目的端的IP地址为1.1.2.2)。

<Sysname> tracert 1.1.2.2

traceroute to 1.1.2.2 (1.1.2.2), 30 hops at most, 40 bytes each packet, press CTRL+C to break

 1 1.1.1.2 (1.1.1.2) [AS 99] 560 ms 430 ms 50 ms

 2 * * *

出现以上显示信息时,请在目的端执行ip unreachables enable命令开启ICMP目的不可达报文发送功能。如果故障排除,则说明目的端未开启ICMP目的不可达报文发送功能;如果故障未排除,请继续执行下面的步骤。

(3)     在问题节点上检查是否存在对应的FIB表项和ARP表项。

在未回应ICMP差错报文的设备(tracert命令执行结果中显示为“* * *”的设备)上执行display fib命令,检查是否存在到目的地址的路由。

¡     如果路由不存在,请检查OSPF、IS-IS、BGP等路由协议配置是否有误。

¡     如果路由存在并且报文所经链路是以太链路,请执行display arp命令查看Tracert的下一跳地址对应的ARP表项是否存在。如果不存在,请检查ARP配置是否有误。

(4)     检查Tracert发起端是否收到ICMP差错报文。

发起Tracert后,在Tracert发起端上多次执行display icmp statistics命令查看发起端是否收到ICMP差错报文,显示信息示例如下:

<Sysname> display icmp statistics

  Input: bad formats   0                   bad checksum            0

         echo          0                   destination unreachable 9

         source quench 0                   redirects               0

         echo replies  7                   parameter problem       0

         timestamp     0                   information requests    0

         mask requests 0                   mask replies            0

         time exceeded 3                   invalid type            0

         router advert 0                   router solicit          0

         broadcast/multicast echo requests ignored            0

         broadcast/multicast timestamp requests ignored       0

其它显示信息略……

观察以上ICMP报文的统计信息的变化,判断Input区段内的time exceeded和destination unreachable值的增量是否与Tracert报文发送个数相等,如果不等则表明发起端未收到ICMP差错报文。

(5)     根据收发包统计,确认丢包位置和丢包原因。

在Tracert报文途径的设备上:

a.     配置QoS策略,使用ACL源地址和目的地址过滤Tracert报文,然后在Tracert报文途径接口的入方向和出方向应用QoS策略。

b.     通过display qos policy interface命令查看应用QoS策略的接口上QoS策略匹配成功的报文个数。如果报文个数有增长,则说明设备收到了Tracert报文;如果报文个数无增长,则说明设备没有收到Tracert报文,此时,可以使用debugging ip packet命令打开IP报文调试信息开关,进一步排查设备没有收到Tracert报文的原因并解决问题。

(6)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

5. 告警与日志

相关告警

相关日志

16.2  SNMP故障处理

16.2.1  SNMP连接失败

1. 故障描述

网管(NMS)通过SNMP协议无法成功连接设备。

2. 常见原因

本类故障的常见原因主要包括:

·     网络异常导致报文不可达。

·     配置错误导致认证失败。

·     设备受到SNMP报文攻击,进入SNMP静默模式。

·     网管被列入了SNMP黑名单。

3. 故障分析

本类故障的诊断流程如图16-3所示。

图16-3 SNMP无法连接的故障诊断流程图

 

4. 处理步骤

(1)     执行ping命令,检查设备和网管之间是否路由可达。

¡     如果可以Ping通,说明设备和网管之间路由可达,请执行步骤(2)。

¡     如果无法Ping通,请参见“Ping和Tracert故障处理”中的“Ping不通”先解决网络不通问题。待设备和网管之间可以Ping通后,重新建立SNMP连接。如果重新建立SNMP连接后,SNMP连接仍不能成功建立,请执行步骤(2)。

(2)     检查SNMP配置是否正确。

a.     执行display snmp-agent sys-info version命令,查看设备当前使用的SNMP版本号。设备和网管使用的SNMP版本号必须相同。如果不同,需使用snmp-agent sys-info version命令修改配置。

b.     如果当前使用的是SNMPv1或SNMPv2c版本,则执行display snmp-agent community命令查看设备上配置的团体信息(包括团体名和使用的ACL等信息)。设备和网管使用的团体名必须相同,且设备上配置的ACL必须允许网管访问设备。否则,需使用snmp-agent communityacl命令修改配置。

c.     如果当前使用的是SNMPv3版本,则执行display snmp-agent usm-user命令查看SNMPv3用户信息(包括用户名和使用的ACL等信息),并执行display snmp-agent group命令查看SNMP组信息(包括认证/加密模式和使用的ACL等信息)。设备和网管使用的用户名必须相同,认证/加密参数必须一致,且设备上配置的ACL必须允许网管访问设备。否则,需使用snmp-agent groupsnmp-agent usm-user v3acl命令修改配置。

(3)      检查设备是否进入SNMP静默状态。

如果1个统计周期内(时长为1分钟)设备收到的SNMP认证失败报文的个数大于等于100,则设备认为受到了SNMP攻击,SNMP模块会进入静默状态(设备会打印日志SNMP agent is now silent),设备将在4~5分钟内不再响应收到的任何SNMP报文。可使用以下方式来解决静默状态下无法建立SNMP连接的问题:

¡     请等待SNMP静默状态解除后,重新建立SNMP连接。

¡     暂时关闭SNMP静默功能,重新建立SNMP连接。连接建立后,再开启SNMP静默功能。

(4)     检查网管是否被列入SNMP黑名单。

设备上开启SNMP黑名单功能后,如果网管和设备建立SNMP连接失败,则设备会将网管加入SNMP黑名单,第一次、第二次、第三次、第四次连接连续建立失败,网管会依次被锁定8秒、16秒、32秒和5分钟,黑名单中的网管在锁定期内不允许和设备建立SNMP连接。可使用以下方式来解决网管被锁定状态下无法建立SNMP连接的问题:

¡     请等待网管被解锁后,重新建立SNMP连接。

¡     暂时关闭SNMP黑名单功能,重新建立SNMP连接。连接建立后,再开启SNMP黑名单功能。

(5)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

5. 告警与日志

相关告警

模块名:SNMPv2-MIB

·     authenticationFailure (1.3.6.1.6.3.1.1.5.5)

相关日志

·     SNMP/3/SNMP_ACL_RESTRICTION

·     SNMP/4/SNMP_AUTHENTICATION_FAILURE

16.2.2  SNMP操作超时

1. 故障描述

网管(NMS)对设备执行SNMP Get和Set操作,网管侧提示操作超时,导致操作失败。

2. 常见原因

本类故障的常见原因主要包括:

·     SNMP连接中断,导致网管无法访问设备。

·     网络丢包,导致设备没有收到SNMP请求。

·     设备存储介质上的存储空间不足,导致设备无法处理SNMP请求。

·     设备繁忙,正在处理其它业务,导致无法处理SNMP请求。

·     SNMP(作为SNMP agent)进程忙,正在处理其它SNMP请求,导致无法对当前SNMP请求做出应答。

·     SNMP进程处理当前SNMP请求时发生异常。

3. 故障分析

本类故障的诊断流程如图16-4所示。

图16-4 SNMP操作超时的故障诊断流程图

 

4. 处理步骤

(1)     定位并处理SNMP连接问题。

在网管上查看SNMP连接,如果显示连接超时或者失败,请参照“SNMP连接失败”故障处理章节先定位并处理SNMP连接问题。

(2)     检查网络是否存在丢包。

在网管设备上使用ping –c count host命令,例如将conut参数设置为100,host参数取值为设备的IP地址,查看ping命令执行结果中的packet loss字段取值,判断网络是否存在丢包。

¡     如果无丢包,请参照步骤(3)继续定位;

¡     如果有丢包,请参见“Ping和Tracert故障处理”中的“Ping不通”先解决网络不通问题。

说明

-c count:指定ICMP回显请求报文的发送次数,取值范围为14294967295,缺省值为5

 

(3)     定位并处理设备存储介质上的存储空间不足问题。

在任意视图下执行display memory-threshold命令,如果显示信息中的“Current free-memory state”字段取值中包含Normal字样,表示设备存储介质上的存储空间充足,否则,表示设备存储介质上的存储空间不足,请使用以下方法清理内存。

¡     使用reset recycle-bin命令清除回收站中的文件。(回收站中的文件也会占用存储介质上的存储空间。)

¡     使用delete /unreserved file命令一次性彻底删除文件。如果未使用/unreserved参数,删除的文件会保存在回收站中。

说明

根据设备型号不同,设备支持的存储介质可能为Flash、CF卡等。

 

(4)     定位并处理设备繁忙问题。

a.     在任意视图下多次重复执行display cpu-usage命令,查看设备CPU利用率是否持续在较高水平。

b.     在任意视图下执行monitor process命令,检查是否存在占用较多CPU的进程。如果某个业务进程占用CPU较多,可以根据业务需要以及设备支持情况,通过重启服务来降低CPU利用率。

(5)     定位SNMP进程问题。

在系统视图下执行probe命令,进入Probe视图,然后多次重复执行display system internal snmp-agent operation in-progress命令查看设备正在处理的SNMP操作的相关信息。

¡     如果显示信息中的Request ID取值一直在变化,则说明SNMP进程一直在处理不同的请求,当前SNMP进程业务较忙。请降低网管对设备的SNMP操作频率。

¡     如果显示信息中的Request ID取值一直不变,则说明SNMP进程一直在处理同一请求,SNMP进程处理该请求时超时。可通过以下方法排除故障:

-     依次执行undo snmp-agent命令和snmp-agent命令重启SNMP进程,来尝试排除故障。

-     执行display system internal snmp-agent operation timed-outdisplay system internal snmp-agent packet timed-out命令确认耗时较多的SNMP操作以及该操作涉及的MIB节点,减少或不要执行类似操作。

(6)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

5. 告警与日志

相关告警

相关日志

16.2.3  网管无法管理设备

1. 故障描述

网管对设备执行SNMP Set或Get等操作,设备无响应或者提示操作失败。

2. 常见原因

本类故障的常见原因主要包括:

·     网管通过SNMP协议无法成功连接设备。

·     网管使用的SNMP版本和MIB节点不匹配。

·     网管没有访问设备的权限。

·     设备上的SNMP进程忙,无法对当前SNMP请求做出应答。

3. 故障分析

本类故障的诊断流程如图16-5所示。

图16-5 网管无法管理设备的故障诊断流程图

 

4. 处理步骤

(1)     检查网管是否可以通过SNMP协议连接设备。

如果网管通过SNMP协议无法成功连接设备,请参照SNMP连接失败故障处理流程进行处理。

(2)     检查网管当前使用的SNMP协议版本是否支持访问该MIB节点。

例如snmpUsmMIB只支持通过SNMPv3协议访问;Integer32、Unsigned32和Counter64数据类型仅SNMPv2c和SNMPv3版本支持。如果网管使用SNMPv1版本和设备相连,网管将无法访问Integer32、Unsigned32和Counter64数据类型的MIB节点。MIB节点的数据类型可通过MIB文件中节点的SYNTAX字段查看。

hh3cDhcpServer2BadNum OBJECT-TYPE

    SYNTAX      Counter64

    MAX-ACCESS  read-only

    STATUS      current

    DESCRIPTION

        "The total number of the bad packets received."

    ::= { hh3cDhcpServer2StatGroup 1 }

如果因为版本原因导致网管无法访问MIB节点,请将网管切换到SNMPv2c或SNMPv3版本后,与设备重新建立连接,再执行Get和Set操作。

(3)     检查MIB节点是否支持当前的访问操作。

请根据MIB节点支持的操作类型来访问设备。MIB节点支持的操作类型可通过MIB文件中节点的MAX-ACCESS字段查看。

hh3cDhcpServer2BadNum OBJECT-TYPE

    SYNTAX      Counter64

    MAX-ACCESS  read-only

    STATUS      current

    DESCRIPTION

        "The total number of the bad packets received."

    ::= { hh3cDhcpServer2StatGroup 1 }

(4)      检查网管的访问权限。如果访问权限不够,请在设备上修改对应配置,给网管授权。

SNMP支持的访问控制方式包括:

¡     VACM(View-based Access Control Model,基于视图的访问控制模型):将团体名/用户名与指定的MIB视图进行绑定,可以限制NMS能够访问哪些MIB对象,以及对MIB对象不同的操作权限。通过display current-configuration | include view命令可查看MIB视图相关配置,通过display snmp-agent mib-view命令可查看MIB视图的详细信息。如果配置错误,请修改MIB的相关配置。

设备支持三种MIB视图:

-     Read-view:网管只能读取该视图中节点的值。

-     Write-view:网管可读和写该视图中节点的值。

-     Notify-view:当该视图中包含的Trap节点到达触发条件,网管会收到对应的Trap/Inform报文。

¡     RBAC(Role Based Access Control,基于角色的访问控制):我司设备通过RBAC进行用户访问权限控制。RBAC的基本思想就是给用户指定角色,这些角色中定义了允许用户操作哪些系统功能以及资源对象。创建SNMPv3用户名时,可以绑定对应的用户角色,通过用户角色下制定的规则,来限制NMS能够访问哪些MIB对象,以及对MIB对象不同的操作权限。如果RBAC权限配置错误,可以通过role name命令进入用户角色视图修改用户角色的规则。

-     拥有network-admin或level-15用户角色的SNMP团体/用户,可以对所有的MIB对象进行读写操作;

-     拥有network-operator用户角色的SNMP团体/用户,可以对所有的MIB对象进行读操作;

-     拥有自定义用户角色的SNMP团体/用户,可以对角色规则中指定的MIB对象进行操作。

说明

为了安全起见,只有具有network-admin或者level-15用户角色的用户登录设备后才能配置SNMP团体、用户或组。请确保登录用户具有network-admin或者level-15用户角色,以免配置失败。

 

(5)     检查SNMP进程是否繁忙。

网管对设备执行SNMP Set或Get等操作,设备无响应或者提示操作失败,还可能因为SNMP进程忙,无法对当前SNMP请求做出应答,请参照SNMP操作超时故障处理流程进行处理。

(6)     其它建议

建议网管通过业务接口访问设备,因为业务接口的报文处理能力优于网管口,以便SNMP报文能尽快得到处理。

当有多个NMS同时访问设备,且设备反应缓慢时,建议降低访问频率来减轻设备分担,例如将访问频率设置成大于等于5分钟。

(7)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

5. 告警与日志

相关告警

模块名:SNMPv2-MIB

·     authenticationFailure (1.3.6.1.6.3.1.1.5.5)

相关日志

·     SNMP/3/SNMP_ACL_RESTRICTION

·     SNMP/4/SNMP_AUTHENTICATION_FAILURE

16.2.4  网管无法收到设备发送的Trap

1. 故障描述

网管无法收到设备发送的Trap报文。

2. 常见原因

本类故障的常见原因主要包括:

·     设备和网管之间路由不可达,或者SNMP功能异常,导致无法建立SNMP连接。

·     设备侧和网管侧配置错误,导致网管无法收到设备发送的告警。

·     设备侧业务模块没有产生告警。

·     告警报文丢失,导致网管未收到设备发送的告警。

·     SNMP Trap报文过大,超过SNMP模块对Trap报文大小的限制。

3. 故障分析

本类故障的诊断流程如图16-6所示。

图16-6 网管无法收到设备发送的Trap的故障诊断流程图

 

4. 处理步骤

(1)     在系统视图下通过snmp-agent trap log命令开启SNMP告警日志功能。当设备向网管发送告警时,会同时在设备上生成一条日志来记录该Trap。

(2)     通过display logbuffer | include SNMP_NOTIFY命令可以查看设备上是否生成Trap以及生成的Trap详情。

¡     如果有显示信息,说明设备有Trap生成。请执行步骤(3)。

¡     如果没有显示信息,说明SNMP模块未向外发送Trap。请执行步骤(4)。

(3)     如果设备生成了Trap,但网管未收到Trap,请参照以下步骤定位。

a.     检查设备是否可以和网管建立SNMP连接。如果连接建立失败,请参见SNMP连接失败故障处理流程解决SNMP连接建立失败问题。

b.     通过display current-configuration | include snmp命令查看snmp-agent target-host trap命令配置是否正确。如果不正确,请修改配置,保证指定的IP地址(VPN参数)和端口号与网管用来接收Trap报文的IP地址(网管所属VPN)和端口号一致,以及设备和网管使用的SNMP协议、安全字一致。

-     如果使用SNMPv1或SNMPv2c版本,则安全字为团体名,请在设备上使用snmp-agent community命令创建SNMP团体。

-     如果使用SNMPv3版本,则安全字为用户名,且设备和网管使用的认证和加密级别必须相同。您需要在设备上使用snmp-agent groupsnmp-agent usm-user v3命令创建SNMPv3用户,创建用户时配置的认证和加密模式、认证密码和加密密码(如果用到)必须和网管侧一致,且创建用户时配置的认证和加密级别必须比snmp-agent target-host trap命令中指定的认证和加密级别高。安全级别分为:不认证不加密、认证不加密和认证加密,安全级别依次升高。

-     团体名和用户名可访问的MIB view必须包含对应的MIB告警节点,否则,会因为权限问题导致设备不会将Trap报文发送给网管。

c.     执行debugging udp packet命令打开UDP报文的调试信息开关,查看设备发送的Trap报文是否过大。如果业务模块封装的数据较多,可能会导致Trap报文大于设备能发送的SNMP报文的最大长度,这样的Trap报文会被丢弃。此时可结合网络的MTU值以及是否支持分片情况,通过snmp-agent packet max-size命令修改设备能发送的SNMP报文的最大长度。

*Dec 27 22:35:41:203 2021 Sysname SOCKET/7/UDP: -MDC=1;

UDP Output:

 UDP Packet: vrf = 0, src = 192.168.56.121/30912, dst = 192.168.56.1/162

             len = 79, checksum = 0xd98f

d.     检查网络中是否存在防火墙过滤Trap报文。

如果网络中设置了防火墙,可采用以下措施来解决问题:

-     如果防火墙对报文的源IP进行了过滤,可使用snmp-agent trap source命令修改Trap报文的源IP地址。

-     修改防火墙的规则,放行Trap报文。

e.     检查网络是否不稳定,存在丢包。

如果网络中存在丢包,可采用以下措施来解决问题:

-     检查网络,解决网络丢包问题。

-     配置使用Inform报文发送告警信息。Inform有确认机制,比Trap更可靠。Inform仅SNMPv2c和SNMPv3支持。

(4)     SNMP模块未向外发送Trap,请参照以下步骤定位。

a.     通过display snmp-agent trap-list查看业务模块的告警功能是否开启。如未开启,可通过snmp-agent trap enable命令开启。

b.     检查是否达到告警条件。例如接口状态告警会在接口状态发生变化时产生,CPU和内存告警会在CPU、内存的利用率超过阈值时产生等。

-     如未达到告警条件,未产生Trap,属正常现象,无需处理。

-     如果达到告警条件,设备未向外发送Trap,请执行步骤(c)。

c.     使用display snmp-agent trap queue命令查看Trap缓冲区是否被占满。如果Message number大于Queue size,表示Trap缓冲区可能被占满,新生成的Trap报文可能被丢弃。此时,可在系统视图下使用snmp-agent trap queue-sizesnmp-agent trap life命令来调整Trap缓冲区性能参数。

(5)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

5. 告警与日志

相关告警

相关日志

·     SNMP/6/SNMP_NOTIFY

·     SNMP/3/SNMP_INFORM_LOST

16.3  PTP故障

16.3.1  故障描述

PTP常见故障现象有:

·     PTP无法选举出Slave接口。

·     PTP时间同步精度异常和同步以太网功能异常。

16.3.2  故障处理步骤

1. 检查PTP配置正确性

(1)     使用display ptp clock命令查看设备的PTP时钟信息。

<Sysname> display ptp clock

PTP profile         : ITU-T G.8275.1

PTP mode            : T-BC

Slave only          : No

Holdover state      : No

Clock ID            : 1CAB34-FFFE-3B1000

Clock type          : Local

Clock domain        : 24

Number of PTP ports : 2

Priority1      : 128

Priority2      : 128

Local priority : 128

Clock quality :

 Class                 : 248

 Accuracy              : 254

 Offset (log variance) : 65535

Offset from master  : 21 (ns)

Mean path delay     : 572 (ns)

Steps removed       : 1

Local clock time    : Wed Sept 11 01:59:40 2019

Clock source info:

 Clock   LP   Pri2 Accuracy Class TimeSrc Direction In-Status Offset(log variance)

 -------------------------------------------------------------------

 Local   128  128  254      248   160     N/A       N/A       65535

 ToD0    128  128  32       6     32      N/A       Inactive  65535

 ToD1    128  128  32       6     32      N/A       Inactive  65535

¡     检查各设备上配置的PTP profile和Clock domain一致,PTP mode是否正常。

¡     检查配置的两个优先级Priority1和Priority2是否正常,该值越小优先级越高。

(2)     使用display ptp statistics命令查看PTP端口收发包信息。

<Sysname> display ptp statistics interface gigabitethernet 3/1/1

                     Received packets

--------------------------------------------------------------------------

Announce :81         Sync      :160        Signaling          :0

DelayReq :0          DelayResp :160        FollowUp           :160

PdelayReq:0          PdelayResp:0          PdelayRespFollowUp :0

 

                     Sent packets

--------------------------------------------------------------------------

Announce :0          Sync      :0          Signaling          :0

DelayReq :160        DelayResp :0          FollowUp           :0

PdelayReq:0          PdelayResp:0          PdelayRespFollowUp :0

 

                     Discarded packets

--------------------------------------------------------------------------

Announce :0          Sync      :0          Signaling          :0

DelayReq :0          DelayResp :0          FollowUp           :0

PdelayReq:0          PdelayResp:0          PdelayRespFollowUp :0

¡     查看端口Received和Sent报文是否正常,是否有Discarded的异常丢弃的报文计数。

¡     检查Sync和DelayReq的计数是否匹配。

(3)     使用display ptp interface brief命令查看PTP接口角色。

<Sysname> display ptp interface brief

Name             State         Delay mechanism  Clock step  Asymmetry correction

GE3/1/1         Slave         E2E              Two         0

¡     检查接口的State状态是Slave还是Master。

¡     检查接口配置,二层以太和三层UDP模式、端口强制状态是否匹配。

(4)     使用display ptp corrections命令查看PTP时间调节精度。

<Sysname> display ptp corrections

Slave port              Correction time        Corrections(s,ns)     Rate ratio

GE3/1/1                 Sep 11 02:07:50 2019  -0,4                   N/A

GE3/1/1                 Sep 11 02:07:50 2019   0,6                   N/A

GE3/1/1                 Sep 11 02:07:51 2019  -0,1                   N/A

Corrections项表示当前设备与Master的时间偏差。

2. 检查同步以太配置正确性

(1)     使用display network-clock source命令查看时钟监控的参考源状态。

<Sysname> display network-clock source

Traced reference: GE3/1/1

Reference   State   Priority  SSM level Force SSM Sa-Bit  LPU port  Frequency

BITS0       Lost    255       Unknown   ON        4       N/A       2 Mbps

BITS1       Lost    255       Unknown   ON        4       N/A       2 Mbps

PTP         N/A     255       Unknown   ON        N/A     N/A       N/A

GE6/1/1     Lost    18        Unknown   ON        N/A     Yes       N/A

GE3/1/1     Normal  18        Unknown   ON        N/A     Yes       N/A

¡     检查同步以太使能端口和优先级配置是否正确。LPU port项为Yes是表示端口下使能了同步以太,Priority项表示该端口的优先级,值越小优先级越高。

¡     如果开启了SSM等级控制选源,需要检查SSM等级相关信息。检查端口是否使能了ESMC,全局配置下是否关闭了SSM等级强制Force状态为OFF。

(2)     使用display network-clock status命令查看同步以太当前状态。

<Sysname> display network-clock status

Mode              : Auto

Reference         : N/A

Traced reference  : GE3/1/1

Lock mode         : Locked

SSM output level  : SSUB

SSM control enable: Off

SSM control enable表示当前选源是否由SSM等级控制选源。Lock mode表示当前是否有端口同步了上游时钟,即LOCKED状态。

16.4  镜像故障处理

16.4.1  配置流镜像后监控设备收不到镜像报文

1. 故障描述

配置流镜像后,监控设备收不到镜像报文。

2. 常见原因

本类故障的常见原因主要包括:

·     目的接口与被监控网络间链路存在故障。

·     QoS策略未被应用或者报文未匹配QoS策略。

·     配置流行为时,指定的流镜像接口错误。

3. 故障分析

本类故障的诊断流程如图16-7所示。

图16-7 配置流镜像后监控设备收不到镜像报文的故障诊断流程图

 

4. 处理步骤

(1)     检查镜像源端口能否成功收发报文。

在源设备上执行display interface interface-type interface-number命令,通过显示信息中的“Input(total)”、“Output(total)”字段查看端口收发报文的统计值。

¡     如果镜像源端口收发的报文的统计信息为0或者不变化,此时设备与被监控的网络之间可能存在链路故障(比如端口Down等),请排查解决。

¡     如果镜像源端口收发的报文的统计信息不为0且不断变化,请执行步骤(2)。

(2)     检查QoS策略是否被正确应用。

排查匹配待镜像报文的QoS策略是否被应用以及应用的QoS策略是否正确。

在源设备上执行display qos policy interface命令检查镜像源端口上是否应用QoS策略。

¡     如果未应用,请根据实际组网需要,在镜像源端口上应用QoS策略。

¡     如果已应用,继续检查QoS策略配置是否正确。在设备上执行display qos policy命令检查QoS策略的配置信息。显示信息中Classifier字段和Behavior字段分别对应配置的流分类和流行为。

-     如果引用的错误,则在系统视图下执行qos policy命令进入对应的QoS策略视图,执行classifier behavior命令来修改QoS策略引用的流分类和流行为。QoS策略的具体的定位修改,请参见“MQC方式配置的QoS策略未生效”。

-     如果引用正确,请执行步骤(3)。

(3)     检查目的端口是否有报文发出。

在目的设备上执行display interface interface-type interface-number命令,通过显示信息中的“Output(total)”字段查看端口发送的报文的统计值。

¡     如果目的端口发出的报文的统计信息为0或者不变化。在设备上执行display interface interface-type interface-number命令查看显示信息中的“Current state”字段,确认接口的物理状态是否为Up。

-     如果为Up,请执行步骤。

-     如果为Down,请排查处理接口物理Down的问题。

¡     如果目的端口发出的报文的统计信息不为0且不断变化,请执行步骤(8)。

(4)     检查在目的端口上应用的QoS策略中,流行为视图下配置的流镜像接口(通过mirror-to interface命令配置)是否为目的端口。

¡     如果不是,请通过mirror-to interface命令将流镜像接口重新配置为正确的接口。

¡     如果是,请执行步骤(8)。

(5)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

5. 告警与日志

相关告警

相关日志

·     QOS_POLICY_APPLYIF_CBFAIL

·     QOS_POLICY_APPLYIF_FAIL

·     QOS_POLICY_APPLYGLOBAL_CBFAIL

·     QOS_POLICY_APPLYGLOBAL_FAIL

16.4.2  配置端口镜像后监控设备收不到镜像报文

1. 故障描述

配置流镜像后,监控设备收不到镜像报文。

2. 常见原因

本类故障的常见原因主要包括:

·     镜像源接口与被监控网络间链路存在故障。

·     镜像源端口或镜像目的端口配置错误。

3. 故障分析

本类故障的诊断流程如图16-8所示。

图16-8 端口镜像后监控设备收不到镜像报文的故障诊断流程图

 

4. 处理步骤

(1)     检查镜像源端口能否成功收发报文。

在源设备上执行display interface interface-type interface-number命令,通过显示信息中的“Input(total)”、“Output(total)”字段查看端口收发报文的统计值。

¡     如果镜像源端口收发的报文的统计信息为0或者不变化,此时设备与被监控的网络之间可能存在链路故障(比如端口Down等),请排查解决。

¡     如果镜像源端口收发的报文的统计信息不为0且不断变化,请执行步骤(2)。

(2)     检查端口镜像配置是否正确。

在源设备上执行display mirroring-group命令检查端口镜像的配置信息,确认配置的镜像源端口和镜像目的端口是否正确。其中,显示信息中“Mirroring port”字段为镜像源端口、 “Monitor port”字段为镜像目的端口。

¡     如果正确,请执行步骤(3)。

¡     如果不正确,请在系统视图下分别执行mirroring-group mirroring-portmirroring-group monitor-port命令重新将镜像源端口和镜像目的端口配置正确。

(3)     检查目的端口是否有报文发出。

在目的设备上执行display interface interface-type interface-number命令,查看显示信息中的“Output(total)”字段查看端口发送的报文的统计值。

¡     如果目的端口发出的报文的统计信息为0或者不变化。在设备上执行display interface interface-type interface-number命令查看显示信息中的“Current state”字段,确认接口的物理状态是否为Up。

-     如果为Up,请执行步骤。

-     如果为Down,请排查处理接口物理Down的问题。

¡     如果目的端口发出的报文的统计信息不为0且不断变化,请执行步骤4

(4)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

5. 告警与日志

16.5  NetStream故障处理

介绍NetStream故障处理的流程和详细的故障处理步骤。

16.5.1  常见原因

·     NetStream配置错误,导致NetStream无法统计。

·     NetStream日志输出端不可达,导致无法解析统计输出的报文。

·     ACL配置错误导致部分流量无法匹配上做NetStream统计。

16.5.2  故障诊断流程

 

16.5.3  故障处理步骤

1. 检查设备上是否有流量统计信息

执行命令display ip netstream cache verbose slot slot-iddisplay ipv6 netstream cache verbose slot slot-id检查NetStream业务是否建立正确的会话信息。如果没有会话信息需要检查NetStream相关配置,详细参加NetStream配置手册。

<Sysname> display ip netstream cache verbose slot 3

IP NetStream cache information:

  Active flow timeout               : 1 min

  Inactive flow timeout             : 30 sec

  Max number of entries             : 409600

  IP active flow entries            : 1

  MPLS active flow entries          : 0

  L2 active flow entries            : 0

  IPL2 active flow entries          : 0

  IP flow entries counted           : 0

  MPLS flow entries counted         : 0

  L2 flow entries counted           : 0

  IPL2 flow entries counted         : 0

  Last statistics resetting time    : Never

 

IP packet size distribution (525266 packets in total):

 1-32   64   96  128  160  192  224  256  288  320  352  384  416  448  480

 .000 .000 .000 1.00 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000

 

  512  544  576 1024 1536 2048 2560 3072 3584 4096 4608 > 4608

 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000

 

 Protocol          Total   Packets     Flows   Packets  Active(sec)  Idle(sec)

                   Flows   /sec        /sec    /flow    /flow        /flow

------------------------------------------------------------------------------

 

Type DstIP(Port)         SrcIP(Port)         Pro ToS VNI   If(Direct)  Pkts

     DstMAC(VLAN)        SrcMAC(VLAN)

     TopLblType(IP/MASK) Lbl-Exp-S-List

------------------------------------------------------------------------------

IP   200.0.0.2(1024)     3.3.3.255(1024)     17  0   N/A   GE3/2/4(O)  526126

     TCPFlag:       0

     DstMask:      32       SrcMask:      26       NextHop:         200.0.0.2

     DstAS:         0       SrcAS:         0       BGPNextHop:        0.0.0.0

     OutVRF:      N/A

     Bgp-community1:0

     Bgp-community2:0

     Bgp-community3:0

     Bgp-community4:0

     SamplerMode: Fixed       SamplerInt:    1

     Active:       10       Bytes/Pkt:   128

     First packet arrived: 06/26/2019, 10:47:11

     Last packet arrived:  06/26/2019, 10:47:21

2. 检查设备是否有NetStream日志输出。

执行命令display ip netstream exportdisplay ipv6 netstream export检查NetStream业务是否有日志输出信息。如果没有会话信息需要检查NetStream相关配置,详细参加NetStream配置手册。

<Sysname> display ip netstream export

IP export information:

  Flow source interface                           : Not specified

  Flow destination VPN instance                   : Not specified

  Flow destination IP address (UDP)               : 100.0.0.2 (9020)

  Version  5 exported flow number                 : 0

  Version  5 exported UDP datagram number (failed): 0 (0)

  Version  9 exported flow number                 : 1

  Version  9 exported UDP datagram number (failed): 1 (0)

  Version 10 exported flow number                 : 0

  Version 10 exported UDP datagram number (failed): 0 (0)

 

MPLS export information:

  Flow source interface                           : Not specified

  Flow destination VPN instance                   : Not specified

  Flow destination IP address (UDP)               : 100.0.0.2 (9020)

  Version  9 exported flow number                 : 0

  Version  9 exported UDP datagram number (failed): 0 (0)

  Version 10 exported flow number                 : 0

  Version 10 exported UDP datagram number (failed): 0 (0)

 

IPL2 export information:

  Flow source interface                           : Not specified

  Flow destination VPN instance                   : Not specified

  Flow destination IP address (UDP)               : 100.0.0.2 (9020)

  Version  9 exported flow number                 : 0

  Version  9 exported UDP datagram number (failed): 0 (0)

  Version 10 exported flow number                 : 0

  Version 10 exported UDP datagram number (failed): 0 (0)

3. 检查日志服务器端是否可达。

执行命令ping确认设备和服务器端是否可达,如果ping不通目的主机,需要执行命令display ip routing-table查看当前的路由表信息,检查设备是否配置了到达的正确路由,同时检查IP地址是否和外网地址有冲突。

16.6  NQA TWAMP-light测试故障

16.6.1  故障描述

TWAMP-light探测结果为丢包100%

16.6.2  故障处理步骤

1. 检查TWAMP-light探测对应的真实数据流是否在链路上转发正常

通过ping等手段检查TWAMP-light探测的源地址和目的地址之间链路是否正常。

·     如果链路不正常,则基本可以排除TWAMP-light故障,TWAMP-light的探测结果只是反应了当前网络的真实情况;

·     如果链路是正常的,则怀疑TWAMP-light功能故障。

2. 检查会话是否是激活状态,如果不是激活状态则检查配置是否正确

<Sysname> display nqa twamp-light client test-session 1

Session ID                           : 1

  Status                                : Active

  Session type                      : Permanent

  Source interface                : -

  Service instance                : -

  Source IP                           : 1.1.1.1

  Source IPv6                       : -

  Destination IP                    : 1.1.1.2

  Destination IPv6                 : -

  Source port                        : 10001

  Destination port                  : 10002

  Source MAC                       : -

3. 检查client端和server端查看相关表项是否下发到硬件

[Sysname-probe] display hardware internal nqa software client all slot 5

========================ProbeID(0x2       )=======================

SessionType: TWAMP, RTCID:3       , VEInlifID:8195    , SamplePeriodID:7

SamplerPeriod = 2000    , TxPktCnt:0       ,TcamHandle:4294967295,AclIndex1:40

      ,AclIndex2:42      , StatisIndex:1       , CounterID:10241   , VsiIndex:42

94967295

[Sysname-probe] display hardware internal nqa software server twamp all slot 5

========================ReflectorId(0x1       )=======================

SessionType: Reflector, Ifindex:0       , SceneType:8

VEInlifID:8196    , VsiIndex:4294967295

AclIndexNum:1       , TcamHdlNum:0

==================================================================

AclIndex 0-0:44

AclIndex 0-1:46

4. 如果仍然无法排查,请把故障信息发送给技术支持人员分析

16.7  NQA TWAMP server端测试故障

16.7.1  故障描述

TWAMP探测失败,丢包率为100%,client端经排查无故障,探测报文已发出,但是没有收到server端的回应报文。

16.7.2  故障处理步骤

1. 检查server端会话是否正常(连接状态正常、会话状态正常、收包正常)

<Sysname> display nqa twamp server session

Control session 1:

  Client address      : 15.21.1.2

  Client port         : 61959

  Server address      : 15.21.1.1

  Server port         : 862

  VPN instance        : -

  Mode                : No Authentication

  Created at          : 2020-08-26 17:06:36.105

  Connection state    : Active

  Test session 1:

    Sender address        : 15.21.1.2

    Sender port           : 5450

    Reflector address     : 15.21.1.1

    Reflector port        : 5450

    DSCP                  : 0

    Padding length        : 128

    Created at            : 1970-01-01 20:10:44.1

    Session ID            : 15.21.1.1:3807450420-3474031542:89990019

    Sent probe packets    : 8292

    Received probe packets: 8292

    Session state         : Active

2. 检查探测对应的真实数据流是否在链路上转发正常

通过ping等手段检查路径服务质量探测的源地址和目的地址之间链路是否正常。

·     如果链路不正常,则基本可以排除TWAMP功能问题,探测结果只是反应了当前网络的真实情况;

·     如果链路是正常的,检测丢包100%,则怀疑TWAMP功能故障。

3. 检查客户端和服务端配置相关配置

检查客户端和服务端配置是否正确。如果配置正确,请联系技术支持工程师。

16.8  路径服务质量测试故障

16.8.1  故障描述

RFC2544探测(路径服务质量测试)失败,丢包率为100%。

16.8.2  故障处理步骤

1. 检查探测是否成功

<Sysname> display nqa result 2544 2544

NQA entry (admin 2544, tag 2544) test results:

  Basic results     :

    Initial speed(Kbps) : 100000

    Probe duration(s)   : 60

    Probe interval(s)   : 4

 

  Frame-loss results:

    Frame size(Byte): 1518

      Current speed(Kbps): 100000

      Frame-loss         : 0.0000000%

      Status             : Succeeded

      Time               : 2020-03-17 13:39:03.4

2. 检查探测对应的真实数据流是否在链路上转发正常

通过ping等手段检查路径服务质量探测的源地址和目的地址之间链路是否正常。

·     如果链路不正常,则基本可以排除路径服务质量故障,路径服务质量的探测结果只是反应了当前网络的真实情况;

·     如果链路是正常的,路径服务质量检测丢包100%,则怀疑路径服务质量功能故障。

3. 检查客户端和服务端配置相关配置

检查客户端和服务端配置是否正确。如果配置正确,请联系技术支持工程师。

16.9  UDP-jitter测试故障

16.9.1  故障描述

UDP-jitter探测失败。

16.9.2  故障处理步骤

1. 检查探测是否成功

<Sysname> display nqa result

NQA entry (admin 13, tag 13) test results:

    Send operation times: 10             Receive response times: 10

    Min/Max/Average round trip time: 1/1/1

    Square-Sum of round trip time: 10

    Last packet received time: 2020-04-16 19:12:18.4

  Extended results:

    Packet loss ratio: 0%

    Failures due to timeout: 0

    Failures due to internal error: 0

    Failures due to other errors: 0

    Packets out of sequence: 0

    Packets arrived late: 0

  UDP-jitter results:

   RTT number: 10

    Min positive SD: 1                     Min positive DS: 0

    Max positive SD: 1                     Max positive DS: 0

    Positive SD number: 1                  Positive DS number: 0

    Positive SD sum: 1                     Positive DS sum: 0

    Positive SD average: 1                 Positive DS average: 0

    Positive SD square-sum: 1              Positive DS square-sum: 0

    Min negative SD: 1                     Min negative DS: 0

    Max negative SD: 1                     Max negative DS: 0

    Negative SD number: 2                  Negative DS number: 0

    Negative SD sum: 2                     Negative DS sum: 0

    Negative SD average: 1                 Negative DS average: 0

    Negative SD square-sum: 2              Negative DS square-sum: 0

    SD average: 1                          DS average: 0

  One way results:

    Max SD delay: 0                        Max DS delay: 0

    Min SD delay: 0                        Min DS delay: 0

    Number of SD delay: 0                  Number of DS delay: 0

    Sum of SD delay: 0                     Sum of DS delay: 0

    Square-Sum of SD delay: 0              Square-Sum of DS delay: 0

    SD lost packets: 0                     DS lost packets: 0

    Lost packets for unknown reason: 0

2. 检测客户端和服务端之间是否路由可达

执行命令ping确认客户端和服务器端是否可达,如果ping不通目的主机,需要执行命令display ip routing-table查看当前的路由表信息,检查设备是否配置了正确路由。

3. 检查客户端和服务端配置

探测丢包率为100%时,需要检查客户端和服务端配置是否正确。如果配置正确,请联系技术支持工程师。

16.10  Y.1564测试故障

16.10.1  故障描述

Y.1564探测失败,丢包率为100%。

16.10.2  故障处理步骤

1. 检查探测是否成功

<Sysname> display nqa result 1564 1564

NQA entry (admin 1564, tag 1564) test results:

  Status                    : Unknown error

  Last test                 : Service performance test

  Estimated total time (s)  : 919

  Actual test time used (s) : 16

  Detailed test results:

    CIR test (with the step of 1):

      Start time                : 2020-03-17 12:28:49.1

      End time                  : 2020-03-17 12:28:57.1

      Status                    : Succeeded

      Min/Max/Average IR (kbps) : 68703/70000/69739

      Min/Max/Average FTD (us)  : 23/64/48

      Min/Max/Average FDV (us)  : 0/43/1

      FL count/FLR              : 0/0.000%

      Packets out of order      : 0

      Severely Err Secs/AVAIL   : 0/100.000%

    PIR test (color-blind):

      Start time                : 2020-03-17 12:28:57.1

      End time                  : 2020-03-17 12:29:05.1

      Status                    : Succeeded

      Min/Max/Average IR (kbps) : 138855/140000/139770

      Min/Max/Average FTD (us)  : 19/64/48

      Min/Max/Average FDV (us)  : 0/41/1

      FL count/FLR              : 0/0.000%

      Packets out of order      : 0

      Severely Err Secs/AVAIL   : 0/100.000%

    Service performance test:

      Start time                : 2020-03-17 12:29:05.1

      End time                  : 2020-03-17 12:29:05.2

      Status                    : Unknown error

      Min/Max/Average IR (kbps) : 0/0/0

      Min/Max/Average FTD (us)  : 0/0/0

      Min/Max/Average FDV (us)  : 0/0/0

      FL count/FLR              : 0/0.000%

      Packets out of order      : 0

      Severely Err Secs/AVAIL   : 0/0.000%

2. 检查探测对应的真实数据流是否在链路上转发正常

通过ping等手段检查Y.1564探测的源地址和目的地址之间链路是否正常。

·     如果链路不正常,则基本可以排除Y.1564故障,Y.1564的探测结果只是反应了当前网络的真实情况;

·     如果链路是正常的,Y.1564检测丢包100%,则怀疑Y.1564功能故障。

3. 检查客户端和服务端配置相关配置

检查客户端和服务端配置是否正确。如果配置正确,请联系技术支持工程师。

16.11  iFIT测试故障

16.11.1  故障描述

iFIT探测没有结果输出到分析器。

16.11.2  故障处理步骤

1. 检查会话是否是激活状态,如果不是激活状态则检查配置是否正确

[H3C] display ifit flow static instance 1

Instance name                    : 1              

Flow ID                          : 4097

Flow information:

  Flow type                      : Static

  Flow direction                 : Unidirection

  Source IP                      : Any

  Destination IP                 : Any

  VPN instance name              : 1

  Next hop configuration         : 5.5.5.5

Measurement information:

  Period                         : 10 sec

  Measurement mode               : e2e

  Loss measurement               : Enabled

  Delay measurement              : Enabled

  Measurement configuration      : Enabled

  Measurement status             : Active

Bound interfaces:

2. GigabitEthernet3/1/1检查client端和server端查看相关表项是否下发到硬件

[H3C-probe] display hardware internal ifit static flow 4097 slot 2

==============Static Flow=============

FlowID: 4097

FeatureMask: 645

SrcIp:0.0.0.0/0

DesIp:0.0.0.0/0

NexthoIp:

Protocol:256

SrcPort:65535

DstPort:65535

vrfIndex:1

ucDscp:255

Mode:0

TypeMask:3

Period:10

IngressStatisOffset:0

ifindex(0)<--->aclindex(31)

3. 如果仍然无法排查,请把故障信息发送给技术支持人员分析

16.12  NETCONF故障处理

16.12.1  SOAP方式登录失败

1. 故障描述

设备作为NETCONF服务器,用户使用NETCONF over SOAP客户端登录设备失败。

2. 常见原因

本类故障的常见原因主要包括:

·     SOAP客户端与设备之间路由不通,无法建立TCP连接。

·     设备未开启NETCONF over SOAP服务器功能。

·     服务器上配置了对客户端的访问控制,但客户端的IP地址不在访问控制的permit规则内。

·     本地用户未配置授权HTTP/HTTPS服务。

·     本地用户认证方式配置不正确。

·     HTTP/HTTPS登录用户数达到允许用户数的上限。

3. 故障分析

本类故障的诊断流程如图16-9所示。

图16-9 SOAP方式登录失败的故障诊断流程图

 

4. 处理步骤

(1)     检查物理链路是否存在故障。

可以通过Telnet登录设备(用户角色名为network-admin),在设备上尝试能否ping通NETCONF客户端的IP地址。如果不能ping通,在设备上执行display ip routing-table命令或者display route-static routing-table命令查看去往客户端的路由出接口,再执行display interface命令检查该接口状态:

<Sysname> display interface gigabitethernet 3/1/1

GigabitEthernet3/1/1

Interface index: 386

Current state: Administratively DOWN

Line protocol state: DOWN

...

a.     如果Current state显示为Administratively DOWN,则在接口下执行undo shutdown命令打开关闭的接口。如果Current state显示为DOWN,则检查接口的物理连线是否正确。

b.     如果设备和客户端之间存在其他设备,按上述方法逐跳检查和修复各设备连接的物理接口状态。

(2)     通过display netconf service命令检查NETCONF over SOAP功能是否开启。

<Sysname> display netconf service

NETCONF over SOAP over HTTP: Disabled (port 80)

NETCONF over SOAP over HTTPS: Disabled (port 832)

NETCONF over SSH: Disabled (port 830)

NETCONF over Telnet: Enabled

NETCONF over Console: Enabled

...

当NETCONF over SOAP over HTTP或NETCONF over SOAP over HTTPS字段值为Disabled时,请在系统视图下执行netconf soap http enablenetconf soap https enable命令开启基于HTTP/HTTPS的NETCONF over SOAP功能。

(3)     检查是否设置了对客户端IP地址的ACL访问控制。

<Sysname> display current-configuration | begin netconf

 netconf soap http enable

 netconf soap https enable

 netconf soap http acl 2000

#

[Sysname] acl basic 2000

[Sysname-acl-ipv4-basic-2000] display this

#

acl basic 2000

 rule 5 permit source 192.168.4.10 0

 rule 10 permit source 192.168.4.15 0

...

如果存在netconf soap { http | https } acl命令配置,请按需选择执行以下操作:

¡     确保客户端的IP地址在相关ACL的rule命令允许的IP地址列表中。

¡     通过执行undo netconf soap { http | https } acl,使NETCONF over SOAP不再关联ACL。

(4)     使用本地认证时,检查客户端对应的本地用户是否可以使用HTTP/HTTPS服务。

进入本地用户视图,执行display this命令,确保配置了service-type http https

<Sysname> system-view

[Sysname] local-user test

[Sysname-luser-manage-test] display this

#

local-user test class manage

 service-type http https

 authorization-attribute user-role network-operator

(5)     使用本地认证时,通过display domain命令检查用户认证域下的认证、授权、计费配置。

<Sysname> display domain

Total 12 domains

 

Domain: system

  Current state: Active

  State configuration: Active

  Default authentication scheme:  Local

  Default authorization  scheme:  Local

  Default accounting     scheme:  Local

...

例如,用户认证域为system时,如果缺省的Authentication、Authorization、Accounting方案不为Local,请执行以下命令,将login用户的认证、授权、计费方案配置为Local。

<Sysname> system-view

[Sysname] domain system

[Sysname-isp-system] authentication login local

[Sysname-isp-system] authorization login local

[Sysname-isp-system] accounting login local

(6)     检查登录到设备的用户数是否达到允许用户数的上限。

在设备上使用display netconf service命令查看Active Sessions字段(当前活跃的NETCONF会话数量),如果该字段值已达到aaa session-limit命令配置的HTTP/HTTPS类型的最大用户连接数,请选择以下一种方式进行调整:

¡     通过aaa session-limit { http | https } max-sessions命令,配置更大的HTTP/HTTPS用户的连接数上限。

¡     使用<kill-session>操作,强制释放已建立的部分SOAP类型的NETCONF会话,使新的用户能够上线。

# 查看NETCONF会话信息的命令如下:

<Sysname> display netconf session

Session ID: 1 Session type : SOAP

  Username : yy

...

# <kill-session>操作的XML报文示例如下:

<rpc message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

  <kill-session>

    <session-id>1</session-id>

  </kill-session>

</rpc>

(7)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

5. 告警与日志

相关告警

相关日志

·     NETCONF/6/SOAP_XML_LOGIN

16.12.2  SSH方式登录失败

1. 故障描述

配置工具通过SSH登录设备失败。

2. 处理步骤

请参见“安全类故障处理/SSH客户端登录设备失败”进行定位。


17 VXLAN类故障处理

17.1  VXLAN故障处理

17.1.1  VXLAN转发不通

1. 故障描述

VXLAN转发不通。

2. 故障处理步骤

(1)     VXLAN隧道检查

检查配置的用于转发的IPv4/IPv6 VXLAN隧道是否UP,如果不UP则查看两台设备间是否路由可达。

使用接口IPv4/IPv6地址时,需要保证物理链路UP且两端IPv4/IPv6地址配置正常。使用环回口IPv4/IPv6地址时,需要保证两台设备间环回口路由可达。

<Sysname> display interface Tunnel 1

Tunnel1

Current state: UP

Line protocol state: UP

Description: Tunnel1 Interface

Bandwidth: 64 kbps

Maximum transmission unit: 1500

Internet protocol processing: Disabled

Last clearing of counters: Never

Tunnel source 10.10.1.2, destination 10.10.1.1

Tunnel protocol/transport UDP_VXLAN/IP

Last 300 seconds input rate: 0 bytes/sec, 0 bits/sec, 0 packets/sec

Last 300 seconds output rate: 0 bytes/sec, 0 bits/sec, 0 packets/sec

Input: 0 packets, 0 bytes, 0 drops

Output: 0 packets, 0 bytes, 0 drops

 

<Sysname> display l2vpn vsi name 1 verbose

VSI Name: 1

  VSI Index               : 2

  VSI State               : Up

  MTU                     : 1500

  Bandwidth               : Unlimited

  Broadcast Restrain      : 5120 kbps

  Multicast Restrain      : 5120 kbps

  Unknown Unicast Restrain: 5120 kbps

  MAC Learning            : Enabled

  MAC Table Limit         : Unlimited

  MAC Learning rate       : -

  Drop Unknown            : -

  Flooding                : Enabled

  VXLAN ID                : 1

  Tunnels:

    Tunnel Name          Link ID    State    Type        Flood proxy

    Tunnel1              0x5000001  UP       Manual      Disabled

  ACs:

    AC                               Link ID    State

    GE3/1/3                          0          Up

(2)     UDP端口号检查

检查两台设备上配置的UDP端口号是否相同。可以用display current-configuration命令查看当前配置文件中是否配置了vxlan udp-port命令;未配置的情况下,VXLAN报文的目的UDP端口号为缺省值4789。

(3)     VXLAN ID检查

检查两台设备上VSI配置的VXLAN ID是否相同,如果不相同请修改为相同的VXLAN ID。

<Sysname> system-view

[Sysname] vsi 1

[Sysname-vsi-1] display this

#

vsi 1

 vxlan 1

  tunnel 1

#

return

(4)     检查是否配置了泛洪抑制

检查当前VSI下是否配置了泛洪抑制命令flooding disable all,如果配置了该命令,则只有单播流量可以转发到远端,其它流量均不会泛洪到远端。

[Sysname-vsi-1] display this

#

vsi 1

 flooding disable all

 vxlan 1

  tunnel 1

#

return

17.1.2  Ping不通集中式VXLAN IP网关

1. 故障描述

图17-1所示,VTEP与集中式VXLAN IP网关之间建立VXLAN隧道,集中式VXLAN IP网关上VSI虚接口作为网关接口。配置完成后,在VTEP连接的服务器上执行Ping操作,发现Ping不通集中式VXLAN IP网关。

图17-1 集中式VXLAN IP网关示意图

 

2. 常见原因

本类故障的常见原因主要包括:

·     VXLAN隧道状态为Down。

·     VXLAN隧道的源IP或目的IP配置错误。

·     VXLAN IP网关接口状态为Down。

·     设备上不存在ping命令对应的ARP表项。

3. 故障分析

本类故障的诊断流程如图17-2所示。

图17-2 Ping不通集中式VXLAN IP网关的故障诊断流程图

 

4. 处理步骤

(1)     在连接服务器的VTEP上查看服务器所属的VXLAN网络的VXLAN隧道信息。

a.     执行display l2vpn vsi verbose命令查看服务器所属的VXLAN网络的VXLAN ID以及与VXLAN网络关联的VXLAN隧道的名称(Tunnel Name字段)。

<Sysname> display l2vpn vsi verbose

VSI Name: vpna

  VSI Index               : 0

  VSI State               : Up

  MTU                     : 1500

  Bandwidth               : Unlimited

  Broadcast Restrain      : Unlimited

  Multicast Restrain      : Unlimited

  Unknown Unicast Restrain: Unlimited

  MAC Learning            : Enabled

  MAC Table Limit         : -

  MAC Learning rate       : -

  Drop Unknown            : -

  Flooding                : Enabled

  Statistics              : Disabled

  VXLAN ID                : 10

  Tunnels:

    Tunnel Name          Link ID    State  Type        Flood proxy

    Tunnel1              0x5000001  Up     Manual      Disabled

    Tunnel2              0x5000002  Up     Manual      Disabled

  ACs:

     AC                               Link ID    State    Type

     XGE3/1/1 srv1000                 0          Up       Manual

b.     根据VXLAN隧道的名称执行display interface tunnel命令,查看服务器接入的VXLAN网络内VXLAN隧道的状态(Current state)、隧道的源IP地址(Tunnel source)和隧道的目的IP地址(destination)。

<Sysname> display interface tunnel 2

Tunnel2

Current state: UP

Line protocol state: UP

Description: Tunnel2 Interface

Bandwidth: 64 kbps

Maximum transmission unit: 1464

Internet protocol processing: Disabled

Last clearing of counters: Never

Tunnel source 2.2.2.2, destination 1.1.1.1

Tunnel protocol/transport UDP_VXLAN/IP

Last 300 seconds input rate: 0 bytes/sec, 0 bits/sec, 0 packets/sec

Last 300 seconds output rate: 0 bytes/sec, 0 bits/sec, 0 packets/sec

Input: 0 packets, 0 bytes, 0 drops

Output: 0 packets, 0 bytes, 0 drops

-     若VXLAN隧道为Up状态,请继续执行第(3)步。

-     若VXLAN隧道为Down状态,请继续执行第(2)步。

(2)     在VTEP上查看VXLAN隧道的源IP地址是否为本端的IP地址、目的IP地址是否可达。

¡     执行display ip interface brief命令,查看VXLAN隧道的源IP地址是否为本端的IP地址。若VXLAN隧道的源IP地址不是本端的IP地址,请通过source命令修改VXLAN隧道的源IP地址。

<Sysname> display ip interface brief

*down: administratively down

(s): spoofing  (l): loopback

Interface           Physical Protocol IP address      VPN instance Description

Loop1               up       up(s)    2.2.2.2         --           --

MGE0/0/0            up       up       192.168.1.61    --           --

MGE0/0/1            down     down     --              --           --

MTunnel0            down     down     --              aaa          --

Vlan1               *down    down     --              --           --

¡     执行display fib命令,查看FIB表中是否存在到达VXLAN隧道的目的IP地址的表项。若不存在对应的表项,请修改路由配置,确保VXLAN隧道的目的IP地址路由可达。

<Sysname> display fib

 

Destination count: 4 FIB entry count: 4

 

Flag:

  U:Useable   G:Gateway   H:Host   B:Blackhole   D:Dynamic   S:Static

  R:Relay     F:FRR

 

Destination/Mask   Nexthop         Flag     OutInterface/Token       Label

0.0.0.0/32         127.0.0.1       UH       InLoop0                  Null

2.2.2.2/32         127.0.0.1       UH       InLoop0                  Null

1.1.1.1/32         127.0.0.1       UH       InLoop0                  Null

127.0.0.0/32       127.0.0.1       UH       InLoop0                  Null

(3)     在VXLAN IP网关上执行display interface vsi-interface brief命令,查看VXLAN IP网关接口信息,包括网关接口编号(Interface)、网关接口状态(Link Protocol)和网关IP地址(Primary IP)。

<Sysname> display interface Vsi-interface brief

Brief information on interfaces in route mode:

Link: ADM - administratively down; Stby - standby

Protocol: (s) - spoofing

Interface            Link Protocol Primary IP      Description

Vsi1                 DOWN DOWN     192.168.1.1

¡     若VXLAN IP网关接口为Down状态,请查看VSI虚接口下是否配置了shutdown令或绑定VSI虚接口的VSI是否Up状态。

-     若VSI虚接口下配置了shutdown令,请执行undo shutdown令。

-     若绑定VSI虚接口的VSIDown状态,请执行display l2vpn vsi命令,查看VSI下AC的状态。若AC的状态为Down,则检查AC配置是否正确和AC所在的接口是否Up。如果AC配置不正确或AC所在的接口为Down状态,请修改AC配置或排查接口故障。

¡     若VXLAN IP网关接口为Up状态,请执行display arp命令查看是否学习到了网关IP对应的ARP信息。

<Sysname> display arp

  Type: S-Static   D-Dynamic   O-Openflow   R-Rule   M-Multiport  I-Invalid

IP address       MAC address    VLAN/VSI  Interface/Link ID        Aging Type

10.1.1.1         0001-0001-0001 0         Tunnel2                  17    D

10.1.1.11        0001-0001-0001 0         Tunnel2                  20    D

20.1.1.1         0002-0002-0002 1         Tunnel3                  17    D

20.1.1.12        0002-0002-0002 1         Tunnel3                  20    D

-     若存在网关IP对应的ARP信息请继续执行第(4)步。

-     若不存在网关IP对应的ARP信息,请执行display arp count命令查看学习的表项数目是否达到了设备/接口配置的动态ARP表项的最大数目。如果达到动态ARP表项的最大数目,请执行arp max-learning-num/arp max-learning-number命令将允许学习的动态ARP表项的最大数目调大。

(4)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

¡     使用display diagnostic-information命令收集诊断信息。

5. 告警与日志

相关告警

相关日志


18 EVPN类故障处理

18.1  EVPN VXLAN故障处理

18.1.1  EVPN分布式网关场景,同一VXLAN内的VTEP之间隧道无法建立

1. 故障描述

EVPN分布式网关场景,同一VXLAN内的VTEP之间隧道无法建立。

2. 常见原因

本类故障的常见原因主要包括:

·     未收到EVPN的2类路由(MAC/IP发布路由)、3类路由(IMET路由)。

·     EVPN实例下的RT配置错误。

3. 故障分析

本类故障的诊断思路如下:

(1)     检查是否收到2类路由。

(2)     检查是否收到3类路由。

(3)     检查EVPN实例下的RT是否配置错误。

同一VXLAN内VTEP之间的VXLAN隧道无法建立的故障诊断流程如图18-1所示。

图18-1 同一VXLAN内VTEP之间的VXLAN隧道无法建立的故障诊断流程图

 

4. 处理步骤

同一VXLAN内VTEP之间的VXLAN隧道无法建立时,故障处理步骤如下:

(1)     在本端执行display bgp l2vpn evpn命令查看本端是否向对端发布了2类或3类路由。例如,下面的显示信息表示本端向4.4.4.4通告了2类和3类路由。如果组网中存在RR,则display bgp l2vpn evpn命令需要指定RR的地址;否则,需要指定对端的地址。

<Sysname> display bgp l2vpn evpn peer 4.4.4.4 advertised-routes

 

 Total number of routes: 2

 

 BGP local router ID is 1.1.1.1

 Status codes: * - valid, > - best, d - dampened, h - history,

               s - suppressed, S - stale, i - internal, e - external,

               a - additional-path

               Origin: i - IGP, e - EGP, ? - incomplete

 

 Route distinguisher: 2:2

 Total number of routes: 2

 

     Network            NextHop         MED        LocPrf             Path/Ogn

 

* >  [2][0][48][0e86-19b6-0308][0][0.0.0.0]/104

                        0.0.0.0         0          100                i

* >  [3][0][32][1.1.1.1]/80

                        0.0.0.0         0          100                i

¡     如果本端向对端发布了2类或3类路由,则执行第(2)步。

¡     如果本端未向对端发布2类和3类路由,请检查EVPN功能中BGP的相关配置是否正确,具体配置参见“EVPN配置指导”中的“EVPN VXLAN”。

(2)     在对端执行display bgp l2vpn evpn命令查看对端是否向本端发布了2类或3类路由。例如,下面的显示信息表示对端向4.4.4.4通告了2类和3类路由。如果组网中存在RR,则display bgp l2vpn evpn命令需要指定RR的地址;否则,需要指定对端的地址。

<Sysname> display bgp l2vpn evpn peer 4.4.4.4 advertised-routes

 

 Total number of routes: 2

 

 BGP local router ID is 3.3.3.3

 Status codes: * - valid, > - best, d - dampened, h - history,

               s - suppressed, S - stale, i - internal, e - external,

               a - additional-path

               Origin: i - IGP, e - EGP, ? - incomplete

 

 Route distinguisher: 1:1

 Total number of routes: 2

 

     Network            NextHop         MED        LocPrf             Path/Ogn

 

* >  [2][0][48][0e86-23cf-0507][0][0.0.0.0]/104

                        0.0.0.0         0          100                i

* >  [3][0][32][3.3.3.3]/80

                        0.0.0.0         0          100                i

¡     如果对端向本端发布了2类或3类路由,则执行第(3)步。

¡     如果对端未向本端发布2类和3类路由,请检查EVPN功能中BGP的相关配置是否正确,具体配置参见“EVPN配置指导”中的“EVPN VXLAN”。

(3)     在VSI视图下执行display this命令查看两端的Export target属性与Import target属性配置是否正确。

[Sysname-vsi-aaa] display this

#

vsi aaa

 vxlan 10

 evpn encapsulation vxlan

  route-distinguisher 2:2

  vpn-target 1:1 export-extcommunity

  vpn-target 2:2 import-extcommunity

#

return

¡     如果两端的RT属性不匹配,请在VSI视图下执行vpn-target命令修改Route Target属性配置。

¡     如果两端的RT属性匹配,则执行第(4)步。

(4)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

¡     使用display diagnostic-information命令收集诊断信息。

5. 告警与日志

相关告警

无。

相关日志

无。

18.1.2  EVPN分布式网关场景,不同VXLAN内的VTEP之间隧道无法建立

1. 故障描述

EVPN分布式网关场景,不同VXLAN内的VTEP之间隧道无法建立。

2. 常见原因

本类故障的常见原因主要包括:

·     未收到EVPN的2类路由、5类路由(IP前缀路由)。

·     VPN实例下的RT配置错误。

3. 故障分析

本类故障的诊断思路如下:

(1)     检查是否收到2类路由。

(2)     检查是否收到5类路由

(3)     检查VPN实例下的RT是否配置错误。

不同VXLAN内VTEP之间的VXLAN隧道无法建立的故障诊断流程如图18-2所示。

图18-2 不同VXLAN内VTEP之间的VXLAN隧道无法建立的故障诊断流程图

 

4. 处理步骤

不同VXLAN内VTEP之间的VXLAN隧道无法建立时,故障处理步骤如下:

(1)     在本端执行display bgp l2vpn evpn命令查看本端是否向对端发布了2类或5类路由。例如,下面的显示信息表示本端向4.4.4.4通告了2类和5类路由。如果组网中存在RR,则display bgp l2vpn evpn命令需要指定RR的地址;否则,需要指定对端的地址。

<Sysname> display bgp l2vpn evpn peer 4.4.4.4 advertised-routes

 

 Total number of routes: 3

 

 BGP local router ID is 1.1.1.1

 Status codes: * - valid, > - best, d - dampened, h - history,

               s - suppressed, S - stale, i - internal, e - external,

               a - additional-path

               Origin: i - IGP, e - EGP, ? - incomplete

 

 Route distinguisher: 1:1

 Total number of routes: 1

 

     Network            NextHop         MED        LocPrf             Path/Ogn

 

* >  [5][0][24][10.1.1.0]/80

                        0.0.0.0         0          100                i

 

 Route distinguisher: 2:2

 Total number of routes: 2

 

     Network            NextHop         MED        LocPrf             Path/Ogn

 

* >  [2][0][48][0e86-19b6-0308][0][0.0.0.0]/104

                        0.0.0.0         0          100                i

* >  [3][0][32][1.1.1.1]/80

                        0.0.0.0         0          100                i

¡     如果本端向对端发布了2类或5类路由,则执行第(2)步。

¡     如果本端未向对端发布2类和5类路由,请检查EVPN功能中BGP的相关配置是否正确,具体配置参见“EVPN配置指导”中的“EVPN VXLAN”。

(2)     在对端执行display bgp l2vpn evpn命令查看对端是否向本端发布了2类或5类路由。例如,下面的显示信息表示对端向4.4.4.4通告了2类和5类路由。如果组网中存在RR,则display bgp l2vpn evpn命令需要指定RR的地址;否则,需要指定对端的地址。

<Sysname> display bgp l2vpn evpn peer 4.4.4.4 advertised-routes

 

 Total number of routes: 3

 

 BGP local router ID is 3.3.3.3

 Status codes: * - valid, > - best, d - dampened, h - history,

               s - suppressed, S - stale, i - internal, e - external,

               a - additional-path

               Origin: i - IGP, e - EGP, ? - incomplete

 

 Route distinguisher: 1:1

 Total number of routes: 2

 

     Network            NextHop         MED        LocPrf             Path/Ogn

 

* >  [2][0][48][0e86-23cf-0507][0][0.0.0.0]/104

                        0.0.0.0         0          100                i

* >  [3][0][32][3.3.3.3]/80

                        0.0.0.0         0          100                i

 

 Route distinguisher: 3:3

 Total number of routes: 2

 

     Network            NextHop         MED        LocPrf             Path/Ogn

 

* >  [5][0][24][10.1.1.0]/80

                        0.0.0.0         0          100                i

¡     如果对端向本端发布了2类或5类路由,则执行第(3)步。

¡     如果对端未向本端发布2类和5类路由,请检查EVPN功能中BGP的相关配置是否正确,具体配置参见“EVPN配置指导”中的“EVPN VXLAN”。

(3)     在关联L3VNI的VPN实例视图下执行display this命令查看两端的Export target属性与Import target属性配置是否正确。

[Sysname-vpn-instance-vpna] display this

#

ip vpn-instance vpna

 route-distinguisher 1:1

 #

 address-family evpn

  vpn-target 1:1 import-extcommunity

  vpn-target 1:1 export-extcommunity

#

return

¡     如果两端的RT属性不匹配,请执行vpn-target命令修改Route Target属性配置。

¡     如果两端的RT属性匹配,则执行第(4)步。

(4)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

¡     使用display diagnostic-information命令收集诊断信息。

5. 告警与日志

相关告警

无。

相关日志

无。

18.1.3  VXLAN网络中,二层VXLAN业务流量不通

1. 故障描述

VXLAN网络中,二层VXLAN业务流量不通。

2. 常见原因

本类故障的常见原因主要包括:

·     AC或VXLAN隧道未建立。

·     未学习到MAC地址。

3. 故障分析

本类故障的诊断流程如图18-3所示。

图18-3 二层VXLAN业务流量不通的故障诊断流程图

 

4. 处理步骤

二层VXLAN业务流量不通时,故障处理步骤如下:

(1)     通过display l2vpn vsi verbose命令查看VSI关联的VXLAN隧道和AC信息。

<Sysname> display l2vpn vsi verbose

VSI Name: vpna

  VSI Index               : 0

  VSI State               : Up

  MTU                     : 1500

  Bandwidth               : Unlimited

  Broadcast Restrain      : Unlimited

  Multicast Restrain      : Unlimited

  Unknown Unicast Restrain: Unlimited

  MAC Learning            : Enabled

  MAC Table Limit         : -

  MAC Learning rate       : -

  Drop Unknown            : -

  Flooding                : Enabled

  Statistics              : Disabled

  VXLAN ID                : 10

  Tunnels:

    Tunnel Name          Link ID    State  Type      Flood proxy

    Tunnel1              0x5000001  Up     Manual    Disabled

  ACs:

    AC                               Link ID    State    Type

    XGE3/1/1 srv1000                 0          Up       Manual

¡     若AC和VXLAN隧道均为Up状态,则执行第(2)步。

¡     若AC为Down状态,请检查并修改AC配置。

¡     若VXLAN隧道为Down状态,请根据“18.1.1  EVPN分布式网关场景,同一VXLAN内的VTEP之间隧道无法建立”故障处理步骤解决问题。

(2)     通过display l2vpn mac-address命令查看VSI的MAC地址表中是否存在被访问终端的MAC地址表项和学习的MAC地址表项总数。

<Sysname> display l2vpn mac-address

* - The output interface is issued to another VSI

MAC Address    State     VSI Name                        Link ID/Name   Aging

0001-0001-0001 Static    aaa                             Tunnel1        NotAging

52f6-bc1e-0d06 Dynamic   vpna                            XGE3/1/1       Aging

--- 3 mac address(es) found  ---

¡     若存在指定的MAC地址表项,则执行第(3)步。

¡     若不存在指定的MAC地址表项,请在VSI视图下执行display this命令,查看当前VSI下是否配置了mac-table limit命令和mac-table limit drop-unknown命令,如果配置了上述命令且当前已经学习到的MAC地址已经达到最大值,则需要将允许VSI学习到的最大MAC地址数调大或删除mac-table limit drop-unknown命令。

(3)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

¡     使用display diagnostic-information命令收集诊断信息。

5. 告警与日志

相关告警

无。

相关日志

无。

18.1.4  VXLAN网络中,三层VXLAN业务流量不通

1. 故障描述

VXLAN网络中,三层VXLAN业务流量不通。

2. 常见原因

本类故障的常见原因主要包括:

·     AC或VXLAN隧道未建立。

·     设备的Route MAC配置错误。

3. 故障分析

本类故障的诊断流程如图18-4所示。

图18-4 三层VXLAN业务流量不通的故障诊断流程图

 

4. 处理步骤

三层VXLAN业务流量不通时,故障处理步骤如下:

(1)     通过display l2vpn vsi verbose命令查看VSI关联的VXLAN隧道和AC信息。

<Sysname> display l2vpn vsi verbose

VSI Name: vpna

  VSI Index               : 0

  VSI State               : Up

  MTU                     : 1500

  Bandwidth               : Unlimited

  Broadcast Restrain      : Unlimited

  Multicast Restrain      : Unlimited

  Unknown Unicast Restrain: Unlimited

  MAC Learning            : Enabled

  MAC Table Limit         : -

  MAC Learning rate       : -

  Drop Unknown            : -

  Flooding                : Enabled

  Statistics              : Disabled

  VXLAN ID                : 10

  Tunnels:

    Tunnel Name          Link ID    State  Type      Flood proxy

    Tunnel1              0x5000001  Up     Manual    Disabled

  ACs:

    AC                               Link ID    State    Type

    XGE3/1/1 srv1000                 0          Up       Manual

¡     若AC和VXLAN隧道均为Up状态,则执行第(2)步。

¡     若AC为Down状态,请检查并修改AC配置。

¡     若VXLAN隧道为Down状态,请根据“18.1.2  EVPN分布式网关场景,不同VXLAN内的VTEP之间隧道无法建立”故障处理步骤解决问题。

(2)     通过display evpn routing-table命令查看L3VNI关联的VPN实例的路由表中目的IP地址(IP address)为被访问终端的IP地址的路由表项的下一跳地址(Nexthop)。

<Sysname> display evpn routing-table vpn-instance vpn1

Flags: E - with valid ESI   A – A-D ready   L - Local ES exists

 

VPN instance name: vpn1                             Local L3VNI: 7

IP address       Nexthop          Outgoing interface    NibID       Flags

10.1.1.11        1.1.1.1          Vsi-interface3        0x18000000  EAL

(3)     通过display arp命令查看下一跳地址的ARP信息。

<Sysname> display arp

  Type: S-Static   D-Dynamic   O-Openflow   R-Rule   M-Multiport  I-Invalid

IP address      MAC address    VLAN/VSI name Interface                Aging Type

1.1.1.1         00e0-fe50-6503 vsi1          Tunnel1                  960   D

¡     若下一跳地址对应的MAC地址为Router MAC,则执行第(4)步。通过display interface vsi-interface命令查看承载L3VNI的VSI虚接口的MAC地址,该地址就是Router MAC地址。

¡     若下一跳地址对应的MAC地址不是Router MAC,则将设备上承载L3VNI的VSI虚接口的MAC地址配置一致或通过evpn global-mac命令配置EVPN的全局MAC地址。

(4)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

¡     使用display diagnostic-information命令收集诊断信息。

5. 告警与日志

相关告警

无。

相关日志

无。

18.1.5  EVPN网络中,VM迁移时间过长

1. 故障描述

EVPN网络中,VM迁移到新的VTEP后,VTEP没有立刻学习到VM的MAC地址或者ARP。

2. 常见原因

本类故障的常见原因主要包括:

·     新的VTEP未学习到迁移VM的MAC地址表项和ARP表项。

·     新的VTEP未通过BGP EVPN路由同步学习到迁移VM的MAC地址和ARP。

·     VTEP之间同步的BGP EVPN路由不是最优路由。

3. 故障分析

本类故障的诊断流程如图18-5所示。

图18-5 VM迁移时间过长的故障诊断流程图

 

4. 处理步骤

(1)     在迁移后的VTEP设备上查看是否学习到迁移VM的MAC地址或ARP。

通过display l2vpn mac-address命令查看VSI的MAC地址表中是否存在迁移VM的MAC地址表项。

<Sysname> display l2vpn mac-address

* - The output interface is issued to another VSI

MAC Address    State     VSI Name                        Link ID/Name   Aging

52f6-bc1e-0d06 EVPN      aaa                             Tunnel10       NotAging

0001-0001-0001 Dynamic   vpna                            XGE3/1/1       Aging

--- 2 mac address(es) found  ---

通过display arp命令查看VSI的ARP表项中是否包含VM的ARP表项。

<Sysname> display arp

  Type: S-Static   D-Dynamic   O-Openflow   R-Rule   M-Multiport  I-Invalid

IP address      MAC address    VLAN/VSI name Interface                Aging Type

10.1.1.3        0001-0001-0001 vpna          XGE3/1/1                 960   D

1.1.1.4         00e0-fe60-5000 vsi2          Tunnel1                  --    M

¡     若存在迁移VM的MAC地址或ARP表项,则执行第(2)步。

¡     若不存在迁移VM的MAC地址和ARP表项,则表示本端未学习到迁移VM的MAC地址和ARP,需要VM在迁移后的VTEP上上线完成VM的MAC地址和ARP表项学习。

(2)     在迁移前的VTEP设备上查看是否通过BGP EVPN路由同步学习到迁移VM的MAC地址或ARP。

通过display evpn route mac命令查看是否通过BGP EVPN路由同步学习到迁移VM的MAC地址。Flags中的B表示存在通过BGP EVPN路由学习的MAC表项。

<Sysname> display evpn route mac

Flags: D - Dynamic   B - BGP      L - Local active

       G - Gateway   S - Static   M - Mapping        I - Invalid

 

VSI name: bbb

EVPN instance: -

MAC address     Link ID/Name   Flags   Encap           Next hop

0000-0000-000a  1              DL      VXLAN           -

0001-0001-0001  Tunnel1        B       VXLAN           2.2.2.2

通过display evpn route arp命令查看是否通过BGP EVPN路由同步学习到迁移VM的ARP信息。Flags中的B表示存在通过BGP EVPN路由学习的ARP表项。

<Sysname> display evpn route arp

Flags: D - Dynamic   B - BGP      L - Local active

       G - Gateway   S - Static   M - Mapping        I - Invalid

 

VPN instance: vpn1                            Interface: Vsi-interface1

IP address      MAC address     Router MAC      VSI index   Flags

10.1.1.1        0001-0001-0001  a0ce-7e40-0400  0           B

10.1.1.11       0001-0001-0002  a0ce-7e40-0400  0           DL

10.1.1.101      0001-0011-0101  a0ce-7e40-0400  0           SL

10.1.1.102      0001-0011-0102  0011-9999-0000  0           BS

¡     若通过BGP EVPN路由同步学习到迁移VM的MAC地址或ARP,则执行第(3)步。

¡     若未通过BGP EVPN路由同步学习到迁移VM的MAC地址和ARP,请通过vpn-target命令修改本端EVPN实例下的RT配置,保证本端和对端EVPN实例下的RT属性匹配。

(3)     通过display bgp l2vpn evpn命令查看VM的MAC地址和ARP信息的MAC/IP发布路由是否为最优路由,即检查显示信息的State字段取值是否包括best。如下举例中,路由通告的MAC地址为0001-0203-0405(MAC address),IP地址为5.5.5.5/32(IP address),且该路由为best路由(State)。

<Sysname> display bgp l2vpn evpn route-distinguisher 1.1.1.1:100 [2][5][48][0001-0203-0405][32][5.5.5.5] 136

 

 BGP local router ID: 172.16.250.133

 Local AS number: 100

 

 

 Route distinguisher: 1.1.1.1:100

 Total number of routes: 1

 Paths:   1 available, 1 best

 

 BGP routing table information of [2][5][48][0001-0203-0405][32][5.5.5.5]/136:

 From            : 10.1.1.2 (192.168.56.17)

 Rely nexthop    : 10.1.1.2

 Original nexthop: 10.1.1.2

 OutLabel        : NULL

 Ext-Community   : <RT: 1:2>, <RT: 1:3>, <RT: 1:4>, <RT: 1:5>, <RT: 1:6>, <RT: 1:7

                   >, <Encapsulation Type: VXLAN>, <Router's Mac: 0006-0708-0910

                   >, <MAC Mobility: Flag 0, SeqNum 2>, <Default GateWay>

 RxPathID        : 0x0

 TxPathID        : 0x0

 AS-path         : 200

 Origin          : igp

 Attribute value : MED 0, pref-val 0

 State           : valid, external, best

 IP precedence   : N/A

 QoS local ID    : N/A

 Traffic index   : N/A

 EVPN route type : MAC/IP advertisement route

 ESI             : 0001.0203.0405.0607.0809

 Ethernet tag ID : 5

 MAC address     : 0001-0001-0001

 IP address      : 10.1.1.1/32

 MPLS label1     : 10

 MPLS label2     : 100

 Re-origination  : Enable

¡     若MAC/IP发布路由是最优路由,则执行第(4)步。

¡     若MAC/IP发布路由不是最优路由,请修改路由配置,确保通告的MAC/IP发布路由为最优路由。

(4)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

¡     使用display diagnostic-information命令收集诊断信息。

5. 告警与日志

相关告警

无。

相关日志

无。

18.1.6  VTEP设备上存在MAC迁移,导致其他终端访问VM业务异常

1. 故障描述

VTEP设备上存在MAC迁移,导致其他终端访问VM业务异常。

2. 常见原因

本类故障的常见原因主要为:流量异常或者网络攻击导致学习到的VM的MAC地址表项出接口错误。

3. 故障分析

本类故障的诊断思路如下:

(1)     查看MAC地址迁移信息。

(2)     查看VM的MAC表项出接口是否正确。

4. 处理步骤

(1)     通过display evpn route mac-mobility命令查看MAC地址迁移信息。如下信息表示MAC地址1000-0000-0000从接口XGE3/1/1迁移到本地。

<Sysname> display evpn route mac-mobility

Flags: S - Suppressed, N - Not suppressed

  Suppression threshold: 5

  Detection cycle      : 180s

  Suppression time     : Permanent

 

VSI name      : vsia

EVPN instance : -

  MAC address     Move count Moved from               Flags Suppressed at

  1000-0000-0000  10         XGE3/1/1                 S     15:30:30 2018/03/30

(2)     通过display l2vpn mac-address命令查看VM的MAC地址表项的出接口是否正确。Link ID/Name为学习到MAC地址的接口名称或隧道接口名称。

<Sysname> display l2vpn mac-address

* - The output interface is issued to another VSI

MAC Address    State     VSI Name                        Link ID/Name   Aging

1000-0000-0000 EVPN      aaa                             Tunnel10       NotAging

52f6-bc1e-0d06 Dynamic   vpna                            XGE3/1/1       Aging

--- 2 mac address(es) found  ---

¡     若出接口正确,则执行第(3)步。

¡     若出接口不正确,则需要VM在迁移后的VTEP上重新上线,触发表项学习和更新。

(3)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

¡     使用display diagnostic-information命令收集诊断信息。

5. 告警与日志

相关告警

无。

相关日志

无。

18.1.7  VXLAN DCI隧道未成功建立

1. 故障描述

VXLAN DCI隧道未成功建立。

2. 常见原因

本类故障的常见原因为:未开启接口的DCI功能。

3. 故障分析

本类故障的诊断思路为:检查ED间互连的三层接口上是否开启DCI功能。

4. 处理步骤

(1)     检查ED间互连的三层接口(三层以太网接口及其子接口、三层以太网聚合接口及其子接口、VLAN接口)上是否配置了dci enable命令。若未配置,则执行dci enable命令,开启接口的DCI功能。

(2)     如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。

¡     上述步骤的执行结果。

¡     设备的配置文件、日志信息、告警信息。

¡     使用display diagnostic-information命令收集诊断信息。

5. 告警与日志

相关告警

无。

相关日志

无。


19 NAT故障处理

19.1  NAT故障处理

19.1.1  NAT地址转换失败

1. 故障描述

NAT地址转换失败。

2. 故障处理步骤

NAT地址转换失败的常见原因如下:

·     NAT规则配置错误。

·     NAT网关与外部网络路由不可达。

·     ACL规则配置错误导致报文匹配失败。

·     内网用户主机到NAT网关路由不可达。

请按照下面步骤进行故障排查。(本章只涉及接口板做多核NAT业务)

(1)     检查NAT业务是否有正确的会话信息

检查NAT业务是否建立正确的会话信息。如果没有会话信息,请检查NAT相关配置是否正确。

<Sysname> display nat session slot 3 verbose

Slot 3:

Initiator:

  Source      IP/port: 192.168.1.18/1877

  Destination IP/port: 192.168.1.55/22

  DS-Lite tunnel peer: -

  VPN instance/VLAN ID/VLL ID: -/-/-

  Protocol: TCP(6)

  Inbound interface: GigabitEthernet3/1/1

Responder:

  Source      IP/port: 192.168.1.55/22

  Destination IP/port: 192.168.1.10/1877

  DS-Lite tunnel peer: -

  VPN instance/VLAN ID/VLL ID: -/-/-

  Protocol: TCP(6)

  Inbound interface: GigabitEthernet3/1/2

State: TCP_SYN_SENT

Application: SSH

Role: Standby

Failover group ID: 1

Start time: 2017-10-18 11:22:45

Initiator-> Responder:         1 packets         48 bytes

Responder-> Initiator:         0 packets          0 bytes

 

Total sessions found: 1

(2)     检查NAT设备到外网目的主机是否可达。

执行ping命令确认NAT设备和外网主机是否可达,如果ping外网目的主机不通,执行display ip routing-table命令查看路由表信息,检查设备是否配置了到达外网的正确路由,同时检查IP地址是否和外网地址有冲突。

(3)     检查内网主机的路由配置

执行display ip routing-table命令检查内网主机上配置的路由是否正确,是否能够将内网向外网发送的报文到达NAT转换设备。

如果上送排查检查通过,仍然无法恢复,请将故障信息发送技术支持人员分析。

19.1.2  CGN功能失效

1. 故障描述

CGN功能失效。

2. CGN故障处理步骤

CGN功能失效常见原因如下:

·     用户无法上线。

·     CGN配置错误。

请按照下面步骤进行故障排查。

(1)     检查用户是否上线

执行命令display access-user/display pppoe-server session summary检查IPOE/PPPOE用户是否正常上线。

<Sysname> display access-user interface gigabitethernet 3/1/2

UserID      Interface            IP address              MAC address     S-/C-VLAN

            Username             IPv6 address            Access type

0x5c        GE3/1/2              3.3.3.2                 000c-29a6-b656  -/-

            000c29a6b656         -                       L2 IPoE dynamic

<Sysname> display pppoe-server session summary slot 3

Total PPPoE sessions on slot 3: 2

Local PPPoE sessions on slot 3: 1

 

  Ethernet interface: GE3/1/2                  Session ID: 1

  PPP index: 0x140000105                       State: OPEN

  Remote MAC: 0000-0000-0005                   Local MAC: 0000-5e00-0101

  Service VLAN: N/A                            Customer VLAN: N/A

 

  Ethernet interface: RAGG1                    Session ID: 2

  PPP index: 0x150000105                       State: OPEN

  Remote MAC: 0050-56c0-0005                   Local MAC: 0000-5e00-0102

  Service VLAN: N/A                            Customer VLAN: N/A

 (2)     检查设备上是否有CGN相关会话信息、报文计数和CGN的用户信息等。如果没有,请检查CGN和用户引流等相关配置是否正确。

<Sysname> display nat statistics packet

slot 5:

  Bandwidth use ratio : 0%

  Input : 100 packets, 10000 bytes

  Output: 100 packets, 10000 bytes

  Last 3 seconds input rate : 100 packets/sec, 10000 bytes/sec

  Last 3 seconds output rate: 100 packets/sec, 10000 bytes/sec

  Peak bandwidth usage: 80%

  Peak time: 2021-04-13 10:14:41

<Sysname> display nat user-information slot 3

Slot 3:

User ID                                            : 0x382005a0

Local IP                                           : 1.1.8.192

VPN instance name/index                            : ---/0

Address group                                      : 9

NAT instance                                       : 1

Global IP                                          : 6.1.1.123

Start port                                         : 13003

Block size                                         : 1001

Port total                                         : 1001

Number of extended port block allocated            : 0

Number of ports used in the extended port block    : 0

First/Second/Third/Fourth/Fifth extend port start  : 0/0/0/0/0

Total/TCP/UDP/ICMP port limit                      : ---/---/---/---

TCP/UDP/ICMP port current                          : 0/0/0

Total/TCP/UDP/ICMP sessions                        : 0/0/0/0

 

User ID                                            : 0x38200443

Local IP                                           : 1.1.5.90

VPN instance name/index                            : ---/0

Address group                                      : 9

NAT instance                                       : 1

Global IP                                          : 6.1.1.237

Start port                                         : 13003

Block size                                         : 1001

Port total                                         : 1001

Number of extended port block allocated            : 0

Number of ports used in the extended port block    : 0

First/Second/Third/Fourth/Fifth extend port start  : 0/0/0/0/0

Total/TCP/UDP/ICMP port limit                      : ---/---/---/---

TCP/UDP/ICMP port current                          : 0/0/0

 

Total Users found: 2

<Sysname> display nat session slot 3 verbose

Slot 3:

Initiator:

  Source      IP/port: 192.168.1.18/1877

  Destination IP/port: 192.168.1.55/22

  DS-Lite tunnel peer: -

  VPN instance/VLAN ID/VLL ID: -/-/-

  Protocol: TCP(6)

  Inbound interface: GigabitEthernet3/1/1

Responder:

  Source      IP/port: 192.168.1.55/22

  Destination IP/port: 192.168.1.10/1877

  DS-Lite tunnel peer: -

  VPN instance/VLAN ID/VLL ID: -/-/-

  Protocol: TCP(6)

  Inbound interface: GigabitEthernet3/1/2

State: TCP_SYN_SENT

Application: SSH

Role: Standby

Failover group ID: 1

Start time: 2017-10-18 11:22:45

Initiator->Responder:         1 packets         48 bytes

Responder->Initiator:         0 packets          0 bytes

 

Total sessions found: 1

(2)     检查外网主机是否可达

执行display ip routing-table命令查看外网主机上配置的路由是否正确,是否能够将内网向外网发送的报文转发到CGN转换设备。

如果上送排查检查通过,仍然无法恢复,请将故障信息发送技术支持人员分析。

 

不同款型规格的资料略有差异, 详细信息请向具体销售和400咨询。H3C保留在没有任何通知或提示的情况下对资料内容进行修改的权利!

新华三官网
联系我们