1 高可靠性类故障处理

1.1  BFD故障处理

1.1.1  BFD会话无法建立

1. 故障描述

在设备上执行display bfd session命令，查看不到会话信息，或者显示信息中“State”值不是“Up”，即BFD会话无法Up。

2. 常见原因

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

·     路由表中不存在BFD会话目的地址的路由。

·     BFD检测的链路存在故障，导致BFD报文无法正常交互。

3. 故障分析

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

图1-1 BFD会话无法建立的故障诊断流程图

4. 处理步骤

BFD在两台网络设备上建立会话，用来检测网络设备间的双向转发路径，为上层应用服务。BFD本身并没有发现机制，而是靠被服务的上层协议通知来建立会话。上层协议在建立新的邻居关系后，将邻居的参数及检测参数（包括目的地址和源地址等）通告给BFD；BFD根据收到的参数建立BFD会话。会话建立后会周期性地快速发送BFD报文，如果在检测时间内没有收到BFD报文，则认为该双向转发路径发生了故障，并将故障信息通知给该会话所服务的上层应用，由上层应用采取相应的措施。因此，在排除BFD会话无法建立的故障前，请保证上层协议工作正常，否则无法准确定位BFD会话故障原因。

(1)     使用display bfd session命令查看是否存在BFD会话信息。

¡     如果不存在BFD会话信息，请执行步骤(2)和步骤(3)。

¡     如果存在BFD会话信息，但“State”显示为“Down”，请执行步骤(4)。

(2)     检查是否存在上层协议联动BFD的配置。

执行display current-configuration命令查看是否存在上层协议联动BFD的配置。例如，OSPF联动BFD的配置如下所示：

interface GigabitEthernet0/0/1

 ospf bfd enable

¡     如果存在上层协议联动BFD的配置，则执行步骤(3)。

¡     如果不存在上层协议联动BFD的配置，请配置上层协议联动BFD的命令，并确保配置正确。

(3)     检查BFD会话的数量是否超过了设备的BFD会话规格。

执行display bfd session命令，查看“Total sessions”的取值。如果“Total sessions”的取值已达到设备规格，则无法创建新的BFD会话。可通过取消上层协议联动BFD的配置删除一些不必要的BFD会话解决此问题。

如果BFD会话的数量未超规格，请执行步骤(4)。

(4)     检查BFD路由、隧道信息是否正常。

使用BFD检测IP路径的连通性时，请执行如下步骤检查路由信息。

a.     请执行display bfd session命令，查看“DestAddr”对应的IPv4地址或IPv6地址。

b.     请执行display ip routing-table命令或display ipv6 routing-table命令，查看是否存在目的地为“DestAddr”的路由信息。

c.     如果不存在路由信息，请参考“三层技术-IP路由类故障处理”，排除路由故障。

如果存在路由信息，但BFD会话无法Up，请执行步骤(5)。

使用BFD检测LSP、PW、VXLAN隧道、MPLS TE隧道、SRLSP、SRv6 TE Policy时，请参考各模块的故障处理手册，检查隧道状态是否正常。如果隧道状态不正常，请排除隧道故障。如果隧道状态正常，但BFD会话无法UP，请执行步骤(5)。

(5)     检查BFD发包是否正常。

反复执行display bfd session verbose命令，查看“Tx count”取值的变化。“Tx count”字段表示发送的报文数，如果该字段的取值一直为0，说明BFD发包不正常。请执行如下步骤检查BFD发包情况。

a.     请执行display current-configuration configuration bfd-static-session命令检查静态BFD会话监视的接口。例如，如下显示信息中track-interface后面的接口即为静态BFD会话监视的接口。

<Sysname> display current-configuration configuration bfd-static-session

#

bfd static chris peer-ipv6 1::2 source-ipv6 1::1 discriminator local 1000 remote 1010 track-interface GigabitEthernet0/0/2

#

b.     请执行display interface interface-type interface-number命令查看接口的运行状态。如果“Current state”或“Line protocol state”字段的取值不是UP，请排除接口故障。如果接口的运行状态正常，请执行步骤c。

c.     请执行display bfd session命令，查看“Init mode”的取值。“Init mode”字段表示BFD的运行模式，当“Init mode”取值为“Passive”时，表示BFD运行模式为被动模式；当“Init mode”取值为“Active”时，表示BFD运行模式为主动模式。对于工作在被动（Passive）模式的节点，只有收到工作在主动（Active）模式的节点发送过来的BFD控制报文后，才会发送BFD报文。

如果工作在主动（Active）模式的节点的“Tx count”字段取值一直在增长，说明该节点可以正常发送BFD报文。这种情况下，请执行步骤(6)，检查工作在被动（Passive）模式的节点能否正常收到BFD报文。

d.     上述情况外的其他情况导致的BFD发包不正常，请执行步骤(8)。

(6)     检查BFD收包是否正常。

在BFD会话的一端反复执行display bfd session verbose命令，查看“Rx count”字段的取值，即查看接收的报文数。

¡     “Rx count”计数一直为0，请检查BFD会话对端发包是否正常。如果BFD会话对端发包不正常，请排除对端发包故障。

如果BFD会话对端发包正常，请在本端执行display system internal  bfd packet statistics命令查看“The detailed discarded packet statistics”中是否存在丢包数据。如果存在丢包，请根据具体的丢包原因排除故障。如果无法排除故障或不存在丢包，请执行步骤(8)。

¡     “Rx count”计数有增加，且BFD会话状态能够变为Init，说明本端能够收到BFD报文。此时，请在BFD会话的对端反复执行display bfd session verbose命令，查看“Rx count”字段的取值。

-     BFD会话对端的“Rx count”计数一直为0，但本端发包正常，说明BFD会话的另一端收包不正常，这种情况会导致BFD会话的对端一直发送状态为Down的BFD控制报文，导致本端BFD会话无法Up。请在BFD会话对端执行display system internal  bfd packet statistics命令查看“The detailed discarded packet statistics”中是否存在丢包数据。如果存在丢包，请根据具体的丢包原因排除故障。如果无法排除故障或不存在丢包，请执行步骤(8)。

-     对于本端发包不正常导致BFD会话对端的“Rx count”计数一直为0的情况，请排除本端发包故障。

对于两端发包正常，但一端无法收到报文的情况，请执行步骤(7)。

(7)     检查转发是否正常。

使用ping工具检查BFD会话之间的链路是否能够正常转发报文。对于不同的链路类型，需要使用不同的ping工具，具体如表1-1所示。

表1-1 不同的链路类型使用的ping工具

¡     如果ping不通，请参见“Ping和Tracert—Ping不通”故障手册、“MPLS类”故障处理手册和“Segment Routing类故障处理”排除隧道故障。

¡     如果能ping通，请执行步骤(8)。

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

¡     上述步骤的执行结果。

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

5. 告警与日志

相关告警

无

相关日志

无

1.1.2  BFD会话震荡

1. 故障描述

当链路不稳定时，命令行界面可能会频繁输出BFD会话DOWN的日志信息。例如：

%Jul 28 16:03:50:856 2022 H3C BFD/4/BFD_CHANGE_FSM: Sess[192.168.24.4/192.168.24.2, LD/RD:33793/33793, Interface:GE0/0/1, SessType:Ctrl, LinkType:INET], Ver:1, Sta: UP->DOWN, Diag: 7 (Administratively Down)

2. 常见原因

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

·     物理链路故障。

·     上层协议故障。

·     硬件故障。

3. 故障分析

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

(1)     ‍根据具体打印的BFD日志，初步判断问题故障原因。

(2)     现场检查单板硬件、物理链路、上层协议状态、路由是否可达、隧道是否正确建立等问题。

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

图1-2 BFD会话震荡的故障诊断流程图

4. 处理步骤

BFD在两台网络设备上建立会话，用来检测网络设备间的双向转发路径，为上层应用服务。BFD本身并没有发现机制，而是靠被服务的上层协议通知来建立会话。上层协议在建立新的邻居关系后，将邻居的参数及检测参数（包括目的地址和源地址等）通告给BFD；BFD根据收到的参数建立BFD会话。会话建立后会周期性地快速发送BFD报文，如果在检测时间内没有收到BFD报文，则认为该双向转发路径发生了故障，并将故障信息通知给该会话所服务的上层应用，由上层应用采取相应的措施。因此，在排除BFD会话震荡的故障前，请保证上层协议工作正常，否则无法准确定位BFD会话故障原因。

(1)     ‍确认BFD会话状态是否从Init变为Down。

如果命令行界面输出如下日志信息，说明BFD会话状态从Init变为Down。

BFD/4/BFD_CHANGE_FSM: Sess[20.0.4.2/20.0.4.1,LD/RD:533/532, Interface:Vlan204, SessType:Ctrl, LinkType:INET], Ver.1, Sta: INIT->DOWN, Diag: 1 (Control Detection Time Expired).

a.     ‍检查BFD会话检测的链路是否能够正常转发报文。

使用ping工具检查BFD会话之间的链路是否能够正常转发报文。对于不同的链路类型，需要使用不同的ping工具，具体如表1-2所示。

表1-2 不同的链路类型使用的ping工具

-     如果ping不通，请参见“Ping和Tracert—Ping不通”故障手册、“MPLS类”故障处理手册和“Segment Routing类故障处理”排除隧道故障。

-     如果能ping通，请执行步骤b。

b.     检查本端接收BFD报文的情况。

执行debugging bfd packet receive命令打开BFD接收报文的调试信息开关。

-     如果调试信息中“Sta”字段取值为1，或者未打印调试信息，则说明本端收到状态为Down的报文或者收不到BFD报文。对于这种情况，请执行步骤c。

-     如果调试信息中“Sta”字段取值为2或3，则说明本端收到状态为Init或者Up的报文，但本端BFD会话无法UP。对于这种情况，请执行步骤(4)。

c.     请参考“BFD会话无法建立故障处理”检查对端接收BFD报文的情况。

-     如果收不到BFD报文，请参考“BFD会话无法建立故障处理”排除BFD报文接收故障。

-     如果能收到BFD报文，请执行display system internal bfd packet statistics命令查看“The detailed discarded packet statistics”中显示的丢包原因，并根据具体的丢包原因排除故障。如果无法排除故障或不存在丢包，请执行步骤(4)。

(2)     确认BFD会话状态是否从Up变为Down。

命令行界面输出如下日志信息，说明BFD会话状态从Up变为Down。

BFD/4/BFD_CHANGE_FSM: Sess[20.0.4.2/20.0.4.1,LD/RD:533/532, Interface:Vlan204, SessType:Ctrl, LinkType:INET], Ver.1, Sta: UP->DOWN, Diag: 1 (Control Detection Time Expired).

BFD会话状态从Up变为Down的常见原因为会话协商阶段出现问题。此时可以根据BFD系统日志信息中“Diag”字段的取值辅助判断故障原因。

表1-3 “Diag”字段的不同取值对应的诊断信息

“Diag”字段取值为1的处理步骤如下：

a.     ‍首先删除上层协议联动BFD的配置，然后根据链路类型选择合适的工具检测链路连通性。

-     如果链路震荡，请排除链路震荡问题。

-     如果链路正常，且重新配置上层协议联动BFD的命令后，BFD会话仍然震荡，请执行步骤(4)。

b.     检查本端接收BFD报文的情况。

请参考“BFD会话无法建立故障处理”检查本端接收BFD报文的情况。

-     如果本端能够收到报文，但是存在丢包情况，请执行display system internal bfd packet statistics命令查看“The detailed discarded packet statistics”中显示的丢包原因，并根据具体的丢包原因排除故障。如果无法排除故障或不存在丢包，请执行步骤(4)。

-     如果本端无法收到报文，请执行步骤(4)。

“Diag”字段取值为2的处理步骤如下：

¡     如果使用BFD检测单跳IP链路，请在对端ping本端echo会话的源地址。

-     如果ping不通，说明链路故障，请排除链路故障。

-     如果能ping通，请执行步骤(4)。

¡     如果使用BFD检测MPLS隧道，由于本端通过MPLS隧道发送BFD echo报文，对端通过IP链路转发收到的BFD echo报文。这种情况下，请检查本端MPLS隧道和对端转发BFD echo报文的IP链路的连通性。

-     如果MPLS隧道或IP链路故障，请排除隧道故障或IP链路故障。

-     如果MPLS隧道以及IP链路正常，请执行步骤(4)。

¡     如果使用BFD检测SRv6隧道，由于本地通过SRv6隧道发送BFD echo报文，对端通过IP链路转发收到的BFD echo报文。这种情况下，请检查本端SRv6隧道和对端转发BFD echo报文的IP链路的连通性。

-     如果SRv6隧道或IP链路故障，请排除隧道故障或IP链路故障。

-     如果SRv6隧道以及IP链路正常，请执行步骤(4)。

¡     如果设备配置了uRPF功能，会将对端转发回来的echo报文丢弃。这种情况下，请执行display ip urpf命令检查uRPF是否引用了允许源IP为echo会话源地址通过的ACL规则。此配置用于抑制uRPF丢弃匹配ACL规则的报文。

-     如果uRPF未引用允许源IP为echo会话源地址通过的ACL规则，请通过ip urpf命令修改配置。

-     如果uRPF引用了允许源IP为echo会话源地址通过的ACL规则，请执行步骤(4)。

“Diag”字段取值为3的处理步骤与“Diag”字段取值为1的处理步骤相同。

(3)     确认BFD会话状态是否变为Administratively Down。

命令行界面输出如下日志信息，说明BFD会话状态变为Administratively Down。

BFD/5/BFD_CHANGE_SESS: Sess[17.1.1.2/17.1.1.1, LD/RD:1537/1537, Interface:GE0/0/1, SessType:Ctrl, LinkType:INET], Ver:1, Sta: Deleted, Diag: 7 (Administratively Down)

此情况一般是上层协议故障，间接导致BFD震荡。首先删除上层协议创建BFD会话的配置，观察上层协议是否稳定。如果上层协议震荡，请参考“三层技术-IP路由类故障处理”、“MPLS类故障处理”、“Segment Routing类故障处理”排除上层协议故障。

如果上层协议稳定，但是BFD会话无法UP，请执行步骤(4)。

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

¡     上述步骤的执行结果。

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

5. 告警与日志

相关告警

模块名：HH3C-BFD-STD-MIB

·     hh3cBfdSessStateUp (1.3.6.1.4.1.25506.2.72.0.3)

·     hh3cBfdSessStateDown (1.3.6.1.4.1.25506.2.72.0.4)

相关日志

·     BFD/4/BFD_CHANGE_FSM

·     BFD/5/BFD_CHANGE_SESS