01-BFD故障处理手册
本章节下载: 01-BFD故障处理手册 (279.88 KB)
在设备上执行display bfd session命令,查看不到会话信息,或者显示信息中“State”值不是“Up”,即BFD会话无法Up。
本类故障的常见原因主要包括:
· 路由表中不存在BFD会话目的地址的路由。
· BFD检测的链路存在故障,导致BFD报文无法正常交互。
本类故障的诊断流程如图1-1所示。
图1-1 BFD会话无法建立的故障诊断流程图
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)。
使用ping工具检查BFD会话之间的链路是否能够正常转发报文。对于不同的链路类型,需要使用不同的ping工具,具体如表1-1所示。
链路类型 |
Ping工具 |
IP链路 |
IP Ping工具。即执行ping ip命令或行ping ipv6命令检查指定IPv4地址或IPv6地址是否可达 |
LSP隧道 |
MPLS Ping工具。即执行ping mpls ipv4命令检测LSP隧道的连通性 |
MPLS TE隧道 |
MPLS Ping工具。即执行ping mpls te命令检测MPLS TE隧道的连通性 |
PW |
MPLS Ping工具。即执行ping mpls pw命令检测PW隧道的连通性 |
SRv6 TE Policy |
SRv6 TE Policy Ping工具。即执行ping srv6-te policy命令检测SRv6转发路径的连通性 |
¡ 如果ping不通,请参见“Ping和Tracert—Ping不通”故障手册、“MPLS类”故障处理手册和“Segment Routing类故障处理”排除隧道故障。
¡ 如果能ping通,请执行步骤(8)。
(8) 如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
无
无
当链路不稳定时,命令行界面可能会频繁输出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)
本类故障的常见原因主要包括:
· 物理链路故障。
· 上层协议故障。
· 硬件故障。
本类故障的诊断思路如下:
(1) 根据具体打印的BFD日志,初步判断问题故障原因。
(2) 现场检查单板硬件、物理链路、上层协议状态、路由是否可达、隧道是否正确建立等问题。
本类故障的诊断流程如图1-2所示。
图1-2 BFD会话震荡的故障诊断流程图
· 过多的调试信息的输出会影响系统的运行效率,建议仅在进行网络故障诊断时根据需要打开某个功能模块的调试开关,不要在系统正常运行时打开多个功能模块的调试开关,以免导致设备CPU利用率上升,影响设备正常运行。
· 请及时保存以下步骤的执行结果,以便在故障暂时无法解决时,可快速地将历史信息及时反馈给技术支持人员。
BFD在两台网络设备上建立会话,用来检测网络设备间的双向转发路径,为上层应用服务。BFD本身并没有发现机制,而是靠被服务的上层协议通知来建立会话。上层协议在建立新的邻居关系后,将邻居的参数及检测参数(包括目的地址和源地址等)通告给BFD;BFD根据收到的参数建立BFD会话。会话建立后会周期性地快速发送BFD报文,如果在检测时间内没有收到BFD报文,则认为该双向转发路径发生了故障,并将故障信息通知给该会话所服务的上层应用,由上层应用采取相应的措施。因此,在排除BFD会话震荡的故障前,请保证上层协议工作正常,否则无法准确定位BFD会话故障原因。
(1) 确认BFD会话状态是否从Init变为Down。
如果命令行界面输出如下日志信息,说明BFD会话状态从Init变为Down。
BFD/4/BFD_CHANGE_FSM: Sess[20.0.4.2/20.0.4.1,LD/RD:533/532, Interface:Vlan204, SessType:Ctrl, LinkType:INET], Ver.1, Sta: INIT->DOWN, Diag: 1 (Control Detection Time Expired).
a. 检查BFD会话检测的链路是否能够正常转发报文。
使用ping工具检查BFD会话之间的链路是否能够正常转发报文。对于不同的链路类型,需要使用不同的ping工具,具体如表1-2所示。
链路类型 |
Ping工具 |
IP链路 |
IP Ping工具。即执行ping ip命令或行ping ipv6命令检查指定IPv4地址或IPv6地址是否可达 |
LSP隧道 |
MPLS Ping工具。即执行ping mpls ipv4命令检测LSP隧道的连通性 |
MPLS TE隧道 |
MPLS Ping工具。即执行ping mpls te命令检测MPLS TE隧道的连通性 |
PW |
MPLS Ping工具。即执行ping mpls pw命令检测PW隧道的连通性 |
SRv6 TE Policy |
SRv6 TE Policy Ping工具。即执行ping srv6-te policy命令检测SRv6转发路径的连通性 |
- 如果ping不通,请参见“Ping和Tracert—Ping不通”故障手册、“MPLS类”故障处理手册和“Segment Routing类故障处理”排除隧道故障。
- 如果能ping通,请执行步骤b。
b. 检查本端接收BFD报文的情况。
执行debugging bfd packet receive命令打开BFD接收报文的调试信息开关。
- 如果调试信息中“Sta”字段取值为1,或者未打印调试信息,则说明本端收到状态为Down的报文或者收不到BFD报文。对于这种情况,请执行步骤c。
- 如果调试信息中“Sta”字段取值为2或3,则说明本端收到状态为Init或者Up的报文,但本端BFD会话无法UP。对于这种情况,请执行步骤(4)。
c. 请参考“BFD会话无法建立故障处理”检查对端接收BFD报文的情况。
- 如果收不到BFD报文,请参考“BFD会话无法建立故障处理”排除BFD报文接收故障。
- 如果能收到BFD报文,请执行display system internal bfd packet statistics命令查看“The detailed discarded packet statistics”中显示的丢包原因,并根据具体的丢包原因排除故障。如果无法排除故障或不存在丢包,请执行步骤(4)。
(2) 确认BFD会话状态是否从Up变为Down。
命令行界面输出如下日志信息,说明BFD会话状态从Up变为Down。
BFD/4/BFD_CHANGE_FSM: Sess[20.0.4.2/20.0.4.1,LD/RD:533/532, Interface:Vlan204, SessType:Ctrl, LinkType:INET], Ver.1, Sta: UP->DOWN, Diag: 1 (Control Detection Time Expired).
BFD会话状态从Up变为Down的常见原因为会话协商阶段出现问题。此时可以根据BFD系统日志信息中“Diag”字段的取值辅助判断故障原因。
表1-3 “Diag”字段的不同取值对应的诊断信息
“Diag”字段取值 |
诊断信息 |
1 (Control Detection Time Expired) |
表示Ctrl会话本端检测时间超时,即在检测时间内未收到对端发送过来的报文 |
2 (Echo Function Failed) |
表示Echo会话检测时间超时,即在检测时间内未收到对端报文 |
3 (Neighbor Signaled Session Down) |
对端通知本端BFD会话DOWN |
“Diag”字段取值为1的处理步骤如下:
a. 首先删除上层协议联动BFD的配置,然后根据链路类型选择合适的工具检测链路连通性。
- 如果链路震荡,请排除链路震荡问题。
- 如果链路正常,且重新配置上层协议联动BFD的命令后,BFD会话仍然震荡,请执行步骤(4)。
b. 检查本端接收BFD报文的情况。
请参考“BFD会话无法建立故障处理”检查本端接收BFD报文的情况。
- 如果本端能够收到报文,但是存在丢包情况,请执行display system internal bfd packet statistics命令查看“The detailed discarded packet statistics”中显示的丢包原因,并根据具体的丢包原因排除故障。如果无法排除故障或不存在丢包,请执行步骤(4)。
- 如果本端无法收到报文,请执行步骤(4)。
“Diag”字段取值为2的处理步骤如下:
¡ 如果使用BFD检测单跳IP链路,请在对端ping本端echo会话的源地址。
- 如果ping不通,说明链路故障,请排除链路故障。
- 如果能ping通,请执行步骤(4)。
¡ 如果使用BFD检测MPLS隧道,由于本端通过MPLS隧道发送BFD echo报文,对端通过IP链路转发收到的BFD echo报文。这种情况下,请检查本端MPLS隧道和对端转发BFD echo报文的IP链路的连通性。
- 如果MPLS隧道或IP链路故障,请排除隧道故障或IP链路故障。
- 如果MPLS隧道以及IP链路正常,请执行步骤(4)。
¡ 如果使用BFD检测SRv6隧道,由于本地通过SRv6隧道发送BFD echo报文,对端通过IP链路转发收到的BFD echo报文。这种情况下,请检查本端SRv6隧道和对端转发BFD echo报文的IP链路的连通性。
- 如果SRv6隧道或IP链路故障,请排除隧道故障或IP链路故障。
- 如果SRv6隧道以及IP链路正常,请执行步骤(4)。
¡ 如果设备配置了uRPF功能,会将对端转发回来的echo报文丢弃。这种情况下,请执行display ip urpf命令检查uRPF是否引用了允许源IP为echo会话源地址通过的ACL规则。此配置用于抑制uRPF丢弃匹配ACL规则的报文。
- 如果uRPF未引用允许源IP为echo会话源地址通过的ACL规则,请通过ip urpf命令修改配置。
- 如果uRPF引用了允许源IP为echo会话源地址通过的ACL规则,请执行步骤(4)。
“Diag”字段取值为3的处理步骤与“Diag”字段取值为1的处理步骤相同。
(3) 确认BFD会话状态是否变为Administratively Down。
命令行界面输出如下日志信息,说明BFD会话状态变为Administratively Down。
BFD/5/BFD_CHANGE_SESS: Sess[17.1.1.2/17.1.1.1, LD/RD:1537/1537, Interface: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) 如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
· 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
不同款型规格的资料略有差异, 详细信息请向具体销售和400咨询。H3C保留在没有任何通知或提示的情况下对资料内容进行修改的权利!