CN116980952A

CN116980952A - 跨分段网络的故障检测方法、通信系统及相关装置

Info

Publication number: CN116980952A
Application number: CN202210657604.8A
Authority: CN
Inventors: 李大成; 生绪博; 曾海飞; 成名
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2022-04-15
Filing date: 2022-06-10
Publication date: 2023-10-31

Abstract

本申请实施例公开了一种跨分段网络的故障检测方法、通信系统及相关装置，属于通信技术领域。所述方法包括：第一转发节点获取BFD群组的状态，BFD群组包括第一转发节点在第二分段网络内对应的多条路径中每条路径的BFD会话，BFD会话用于检测相应路径的故障；第一转发节点基于BFD群组的状态向第二转发节点通告多条路径的故障情况。相对于单点故障检测方式，由于本申请实施例是基于BFD群组的状态向第二转发节点通告多条路径的故障情况，因此，本申请实施例提供了一种跨分段网络的多故障点检测方式，提高了故障检测的灵活性。

Description

跨分段网络的故障检测方法、通信系统及相关装置

本申请要求于2022年4月15日提交的申请号为202210400005.8、发明名称为“一种分段级联故障场景快速切换方法”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。

技术领域

本申请实施例涉及通信技术领域，特别涉及一种跨分段网络的故障检测方法、通信系统及相关装置。

背景技术

为了提高网络安全性和稳定性，通信网络可以被划分为多个分段网络。不同的分段网络用于承载不同的业务。比如相邻两个分段网络可以分别用于承载基于第六代网络协议的分段路由的策略(Segment Routing IPv6 Policy，SRv6 policy)业务和基于第六代网络协议的分段路由的最短路径(Segment Routing IPv6 Best Effort，SRv6 BE)业务，或者分别用于承载虚拟租用线(Virtual Leased Line，VLL)业务和虚拟私用线服务(VirtualPrivate Lan Service，VPLS)业务。其中，相邻分段网络之间部署有多个边缘转发节点，任一边缘转发节点用于将上一级分段网络中的报文流引流至下一级分段网络，从而实现报文流的跨分段网络传输。在跨分段网络传输报文流的场景中，如何进行跨分段网络的故障感知是当前研究的热点。

相关技术中，对于相邻的上一级分段网络与下一级分段网络之间的任一边缘转发节点，该边缘转发节点在下一级分段网络内可能对应有多条路径，这多条路径用于将从目标入接口接收的报文流在下一级分段网络内转发。这多条路径中每条路径配置有双向转发检测(bidirectional forwarding detection，BFD)会话。在任一条路径的BFD会话的状态为关闭(down)状态时，将触发目标入接口的状态更新为关闭状态。上一级分段网络中的转发节点在检测到目标入接口的状态为关闭状态时，则可确定下一级分段网络内存在故障。但是这种故障检测方式的灵活性较低。

发明内容

本申请实施例提供了一种跨分段网络的故障检测方法、通信系统及相关装置，可以提高跨分段网络的故障感知的灵活性。所述技术方案如下：

第一方面，提供了一种跨分段网络的故障检测方法，该方法应用于通信系统，该通信系统包括第一转发节点和第二转发节点，第一转发节点为第一分段网络和第二分段网络之间的边缘节点，第二转发节点位于第一分段网络内。

在该方法中，第一转发节点获取BFD群组的状态，BFD群组包括第一转发节点在第二分段网络内对应的多条路径中每条路径的BFD会话，BFD会话用于检测相应路径的故障；第一转发节点基于BFD群组的状态向第二转发节点通告多条路径的故障情况。

在本申请实施例中，第一转发节点基于BFD群组的状态向第二转发节点通告多条路径的故障情况。一方面，由于BFD群组包括多条路径的BFD会话，因此可以实现对第二分段网络内的多点故障检测，提高了故障检测灵活性。另一方面，由于BFD会话可以部署在物理链路、伪线(pseudo-wire)、隧道等任意形式的链路上，因此本申请实施例提供的故障检测方法可以实现对物理出接口和逻辑出接口对应的路径的故障检测，提高了故障检测的范围。

基于第一方面提供的方法，在一种可能的实现方式中，第一转发节点获取BFD群组的状态的实现过程可以为：在BFD群组中各个BFD会话均处于关闭状态的情况下，第一转发节点获取的BFD群组的状态为关闭状态；在BFD群组中至少一个BFD会话的状态为打开状态的情况下，第一转发节点获取的BFD群组的状态为打开状态。

基于上述BFD群组的状态和BFD群组中各个BFD会话的状态之间的关系，本申请实施例提供的BFD群组的状态能够指示BFD群组中是否存在BFD会话状态为关闭状态，或者说，能够指示BFD群组中的BFD会话是否全部是关闭状态。以便于后续能够基于BFD群组的状态向第二转发节点通告多条路径的故障情况。

基于第一方面提供的方法，在一种可能的实现方式中，第一转发节点基于BFD群组的状态向第二转发节点通告多条路径的故障情况的实现过程可以为：第一转发节点基于BFD群组的状态，处理上一级BFD会话的流程，上一级BFD会话用于检测第一转发节点与第二转发节点之间的路径的故障。

通过上述实现方式，第一转发节点能够基于BFD群组的状态联动上一级BFD会话通告多条路径的故障情况，一方面不会对现有组网造成太大改动，提高了本申请实施例的兼容性。另一方面，联动上一级BFD会话通告多条路径的故障情况可以实现第二转发节点快速感知故障，有利于第二转发节点快速换路。

基于第一方面提供的方法，在一种可能的实现方式中，第一转发节点基于BFD群组的状态，处理上一级BFD会话的流程的实现过程可以为：如果BFD群组的状态为关闭状态，第一转发节点则不向第二转发节点发送第一BFD报文。相应地，如果BFD群组的状态为打开状态，第一转发节点则向第二转发节点发送第一BFD报文。

BFD会话的双方周期性地发送BFD报文，以使对端基于接收BFD报文的情况来确定是否存在故障。因此，第一转发节点在周期性向第二转发节点发送BFD报文的过程中，如果检测到BFD群组的状态为关闭状态，则不再向第二转发节点发送BFD报文，如此第二转发节点将检测到该上一级BFD会话存在故障，也即检测到第一转发节点上存在故障，从而达到将多条路径的故障情况通过上一级BFD会话传递给第一转发节点，实现跨分段网络的故障检测。

基于第一方面提供的方法，在一种可能的实现方式中，第一转发节点基于BFD群组的状态，处理上一级BFD会话的流程的实现过程可以为：如果BFD群组的状态为关闭状态，第一转发节点则将上一级BFD会话的状态设置为关闭状态，并向第二转发节点发送状态通告消息，状态通告消息指示上一级BFD会话的状态为关闭状态。相应地，如果BFD群组的状态为打开状态，第一转发节点则不执行将上一级BFD会话状态设置为关闭状态的操作。

在BFD会话中，第一转发节点具有直接设置BFD会话状态为关闭状态并通告BFD会话状态的能力。因此，第一转发节点如果检测到BFD群组的状态为关闭状态，则直接将上一级BFD会话的状态设置为关闭状态，并向第二转发节点发送状态通告消息，如此第二转发节点将检测到该上一级BFD会话存在故障，也即检测到第一转发节点上存在故障，从而达到将多条路径的故障情况通过上一级BFD会话传递给第一转发节点，实现跨分段网络的故障检测。

基于第一方面提供的方法，在一种可能的实现方式中，第一转发节点基于BFD群组的状态，处理上一级BFD会话的流程的实现过程可以为：在接收到来自第二转发节点的第二BFD报文时，如果BFD群组的状态为关闭状态，第一转发节点则丢弃第二BFD报文，不执行基于第二BFD报文更新当前BFD检测周期内接收到的BFD报文数量的操作。相应地，如果BFD群组的状态为打开状态，第一转发节点则基于第二BFD报文更新当前BFD检测周期内接收到的BFD报文数量。

在异步模式下BFD会话中，如果第一转发节点在接收到第二转发节点发送的BFD报文时，并不更新当前BFD检测周期内接收到的BFD报文数量(也即丢弃接收到的BFD报文)，那么第一转发节点后续在当前检测周期达到时，统计的BFD报文数量将达不到要求数量，此时第一转发节点则确定出上一级BFD会话的状态为关闭状态，并向第二转发节点发送状态通告报文。如此第二转发节点将检测到该上一级BFD会话存在故障，也即检测到第一转发节点上存在故障，从而达到将多条路径的故障情况通过上一级BFD会话传递给第一转发节点，实现跨分段网络的故障检测。

基于第一方面提供的方法，在一种可能的实现方式中，第一转发节点基于BFD群组的状态，处理上一级BFD会话的流程的实现过程可以为：在接收到来自第二转发节点的第三BFD报文时，如果BFD群组的状态为关闭状态，第一转发节点则丢弃第三BFD报文，不执行将第三BFD报文返回至第二转发节点的操作。相应地，如果BFD群组的状态为打开状态，第一转发节点则将第三BFD报文返回至第二转发节点。

在查询模式下BFD会话或SBFD会话中，如果第一转发节点在接收到第二转发节点发送的BFD报文时，并不向第二转发节点返回该BFD报文，此时第二转发节点则无法接收到第一转发节点返回的BFD报文。如此第二转发节点将检测到该上一级BFD会话存在故障，也即检测到第一转发节点上存在故障，从而达到将多条路径的故障情况通过上一级BFD会话传递给第一转发节点，实现跨分段网络的故障检测。

基于第一方面提供的方法，在一种可能的实现方式中，上一级BFD会话为异步模式下的BFD会话，查询模式下的BFD会话或无缝双向转发检测SBFD会话。

本申请实施例联动的上一级BFD会话包括各种标准协议中规定的BFD会话，提高了跨分段网络故障感知的灵活性。

基于第一方面提供的方法，在一种可能的实现方式中，在该方法中，第一转发节点还可以获取BFD群组；第一转发节点确定BFD群组与上一级BFD会话的对应关系。

为了能够实现将BFD群组的状态和上一级BFD会话进行联动，需要预先将上一级BFD会话与BFD群组绑定，以建立BFD群组与上一级BFD会话的对应关系，并基于BFD群组的状态处理上一级BFD会话的流程。

基于第一方面提供的方法，在一种可能的实现方式中，第一转发节点基于BFD群组的状态向第二转发节点通告多条路径的故障情况的实现过程可以为：第一转发节点向第二转发节点发送故障通告消息，故障通告消息用于向第二转发节点通告多条路径的故障情况

除了可以通过联动上一级BFD会话进行故障通告之外，还可以单独通过故障通告消息通告故障。提高了跨分段网络故障感知的灵活性。

基于第一方面提供的方法，在一种可能的实现方式中，该故障通告消息携带BFD群组的状态。

当故障通告消息携带BFD群组的状态时，第二转发节点基于该故障通告消息可快速确定多条路径的故障情况。

基于第一方面提供的方法，在一种可能的实现方式中，第一转发节点获取BFD群组的状态之前，第一转发节点还可以周期性获取多条路径中每条路径的BFD会话状态；第一转发节点基于多条路径中每条路径的BFD会话状态，周期性更新并存储BFD群组的状态。这种场景下，第一转发节点获取BFD群组的状态的实现过程可以为：第一转发节点获取存储的BFD群组的状态。

第一转发节点可以预先周期性确定并存储BFD群组的状态，这样可以实现第二转发节点快速感知故障，有利于第二转发节点快速换路。

基于第一方面提供的方法，在一种可能的实现方式中，第一转发节点获取BFD群组的状态的实现过程可以为：第一转发节点获取多条路径中每条路径的BFD会话状态；第一转发节点基于多条路径中每条路径的BFD会话状态，确定BFD群组的状态。

第一转发节点也可以临时确定BFD群组的状态。这种场景下，第一转发节点无需周期性更新并存储BFD群组的状态，节省了第一转发节点的存储压力和数据处理压力。

基于第一方面提供的方法，在一种可能的实现方式中，前述的多条路径用于转发来自第二转发节点的报文流。

基于本申请实施提供的方法，第二转发节点能够感知到本端发送的报文流在第二分段网络内可能使用的路径的故障情况，从而便于在检测到故障时进行换路，避免数据丢包。

基于第一方面提供的方法，在一种可能的实现方式中，第一分段网络和第二分段网络分别用于承载以下业务包括中的至少一项：SRv6 Policy业务、SRv6 BE业务、VLL业务、VPLS业务；第一分段网络承载的业务和第二分段网络承载的业务不同。

本申请实施例提供的跨分段网络故障检测方法可以应用在各种级联的分段网络场景中，提高了本申请实施例的灵活性。

基于第一方面提供的方法，在一种可能的实现方式中，第一转发节点获取BFD群组的状态的实现过程可以为：在第一转发节点的转发面上获取BFD群组的状态。

当在转发面上获取BFD群组的状态时，能够实现第二转发节点快速感知到本端发送的报文流在第二分段网络内可能使用的路径的故障情况，从而便于在检测到故障时进行换路，避免数据丢包。

基于第一方面提供的方法，在一种可能的实现方式中，第一转发节点基于BFD群组的状态向第二转发节点通告多条路径的故障情况的实现方式可以为：在第一转发节点的转发面上基于BFD群组的状态向第二转发节点通告多条路径的故障情况。

当在转发面上通告多条路径的故障情况时，能够实现第二转发节点快速感知到本端发送的报文流在第二分段网络内可能使用的路径的故障情况，从而便于在检测到故障时进行换路，避免数据丢包。

第二方面，提供了一种通信系统，该系统包括第一转发节点和第二转发节点，第一转发节点用于执行如第一方面提供的任一方法。

第三方面，提供了一种网络设备，该网络设备包括存储器和处理器；

存储器用于存储程序指令；

处理器被配置为调用所述存储器中存储的程序，以使得该网络设备执行如第一方面提供的任一种方法。

第四方面，提供了一种网络设备，该网络设备为通信系统中的第一转发节点，所述通信系统还包括第二转发节点，所述第一转发节点为第一分段网络和第二分段网络之间的边缘节点，所述第二转发节点位于所述第一分段网络内；所述第一转发节点包括收发模块和处理模块：

所述收发模块用于执行如第一方面提供的任一种方法中收发相关的操作；

所述处理模块用于执行如第一方面提供的任一种方法中除所述收发相关的操作之外的操作。

第五方面，提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当所述指令在处理器上运行时，实现第一方面提供的任一种方法。

第六方面，提供了一种计算机程序产品，所述计算机程序产品包含指令，所述指令在处理器上运行时，实现第一方面提供的任一种方法。

上述第二方面至第六方面所获得的技术效果与第一方面中对应的技术手段获得的技术效果近似，在这里不再赘述。

附图说明

图1是本申请实施例提供的一种通信系统的架构示意图；

图2是本申请实施例提供的一种跨分段网络的故障检测方法流程图；

图3是本申请实施例提供的另一种通信系统的架构示意图；

图4是本申请实施例提供的一种群组配置界面示意图；

图5是本申请实施例提供的另一种群组配置界面示意图；

图6是本申请实施例提供的一种网络设备的结构示意图；

图7是本申请实施例提供的一种设备的结构示意图；

图8是本申请实施例提供的另一种设备的结构示意图；

图9是本申请实施例提供的一种通信系统的架构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。

在对本申请实施例进行详细解释说明之前，先对本申请实施例的应用场景进行介绍。

目前，在网际互联协议(internet protocol，IP)网络部署中，大部分端到端网络都是通过分段网络级联而成。不同的分段网络用于承载不同的业务，从而实现端到端的报文流转发流程由不同的业务实现，以此提高IP网络的灵活性。这种转发报文流的方式也称为跨分段网络转发报文流。

为了后续便于说明，将分段网络上承载的业务称为分段业务。分段业务具体是指分段网络如何转发报文流的业务。示例地，分段业务可以包括SRv6 policy业务、SRv6 BE业务、VLL业务以及VPLS业务等。前述示例的业务的详细内容均可以参考相关标准协议，在此不再详细说明。此外，本申请实施例中的分段业务也不限于以上四种，任意用于实现报文流转发的业务均在本申请实施例中的分段业务的范围之内。

在跨分段网络转发报文流的场景中，对于相邻的上一级分段网络与下一级分段网络，当下一级分段网络内出现故障时，上一级分段网络需要快速感知到该故障，以便于上一级分段网络快速切换报文流的转发路径，从而避免端到端之间的报文流丢包。

在一些场景中，上一级分段网络可以通过协议收敛的方式(比如Hello报文)感知下一级分段网络内的故障。但是由于收敛速度较慢，导致这种故障检测方式的检测时长通常在秒(s)级。而报文流的传输速率级别为千兆比特每秒(GB/s)。如此在s级的检测时长内，将会发生大量的丢包事件，从而使得端到端之间的流量大量丢包。

基于此，本申请实施例提供了一种跨分段网络的故障检测方法，避免只能依赖协议硬收敛来检测故障进而导致报文流大量丢包。

下面对本申请实施例涉及的网络架构进行解释说明。

图1是本申请实施例提供的一种通信系统的架构示意图。如图1所示，该通信系统包括第一终端10和第二终端20，第一终端10和第二终端20之间部署有第一分段网络30和第二分段网络40。第一分段网络30为靠近第一终端10的分段网络，第二分段网络40为靠近第二终端20的分段网络。

需要说明的是，第一终端10和第二终端20之间可以部署有多个分段网络，图1是以两个分段网络为例进行说明，并不构成对本申请实施例提供的通信系统的限定。

为了后续便于说明，将第一分段网络30承载的业务称为第一分段业务，将第二分段网络40承载的业务称为第二分段业务，也即第一分段网络30内的转发节点基于第一分段业务转发报文流，第二分段网络40内的转发节点基于第二分段业务转发报文流。

其中，第一分段网络和第二分段网络分别用于承载以下业务包括中的至少一项：SRv6Policy业务、SRv6 BE业务、VLL业务、VPLS业务。且第一分段网络承载的业务和第二分段网络承载的业务不同。需要说明的是，第一分段业务和第二分段业务并不限于以上四种，任意用于实现报文流转发的业务均在第一分段业务和第二分段业务的范围之内。

在一些实施例中，如图1所示，通信系统中部署有第一转发节点R1、第二转发节点R2、第三转发节点R3、第四转发节点R4、第五转发节点R5、第六转发节点R6、第七转发节点R7。

其中，第一转发节点R1和第四转发节点R4为第一分段网络20与第二分段网络30之间的边缘转发节点。第二转发节点R2和第三转发节点R3位于第一分段网络20内。第五转发节点R5和第六转发节点R6位于第二分段网络30内。第七转发节点R7位于第二分段网络40和第二终端20之间。

如图1所示，第一终端10与第二转发节点R2连接，以通过第二转发节点R2将第一终端10向第二终端20发送的报文流转发至第一分段网络30内。

第二转发节点R2还分别与第一转发节点R1和第三转发节点R3连接，第三转发节点R3还与第四转发节点R4连接。其中，第二转发节点R2与第一转发节点R1之间的路径可以称为主路径，第二转发节点R2、第三转发节点R3和第四转发节点R4组成的路径可以称为备路径。如此，第二转发节点R2在接收到来自第一终端10的报文流时，可以通过图1中的主路径或备路径分别发送至边缘转发节点R1或R4，以由边缘转发节点R1或R4将该报文流转发至第二分段网络40内。

第一转发节点R1还分别与第四转发节点R4、第五转发节点R5和第六转发节点R6连接。第四转发节点R4还分别与第五转发节点R5和第六转发节点R6连接，第五转发节点R5还与第六转发节点R6连接。第五转发节点R5和第六转发节点R6还分别与第七转发节点R7连接。第七转发节点R7还与第二终端20连接。

如此，当第一转发节点R1接收到来自第二转发节点R2的报文流时，第一转发节点R1可以通过图1中三个分段业务2对应的路径中的任一路径转发该报文流，以使报文流到达第二终端20。

为了后续便于说明，对于如下三条路径，第一转发节点R1与第六转发节点R6之间的路径、第一转发节点R1与第五转发节点R5之间的路径、第一转发节点R1与第四转发节点R4之间的路径，将这三条路径称为第一转发节点R1对应的三条路径。在本申请实施例中，第一转发节点R1对应的三条路径可以包括：位于第二分段网络40内、且是第一转发节点R1用于转发来自第二转发节点R2的报文流的路径。

同样地，当第四转发节点R4接收到来自第二转发节点R2的报文流时，第四转发节点R4同样可以通过对应的三条路径中的任一路径转发该报文流，以使报文流到达第二终端20。第四转发节点R4对应的三条路径可以参考第一转发节点R1对应的三条路径的相关说明，在此不再赘述。

在上述端到端的报文流的转发场景中，当第一转发节点R1对应的路径出现故障时，第一分段网络30内的第二转发节点R2需要感知到该故障，以便重新选路，以实现将来自第一终端10的报文流通过备路径转发。其中，第一分段网络30内的第二转发节点R2感知第一转发节点R1在第二分段网络40内对应的路径的故障情况，该过程可称为跨分段网络的故障检测。

为了缩短故障检测时间，可以基于BFD会话来实现跨分段网络的故障检测。为了便于理解，在此对BFD会话进行解释说明。

BFD提供了一个通用的、标准的，并且和介质、协议无关的单纯的快速故障检测协议。该协议的作用是为了检测部署BFD的中间链路的转发连通状态。BFD原理为：基于两个系统或设备之间的中间链路建立一个BFD会话通道，并且在该中间链路连续不断周期性的互相发送BFD报文(也称为BFD检测报文)，双方有一方在规定时间内没有接收到对端的指定数量的BFD报文就认为中间链路的某个部分出现了故障，就会将该BFD会话通道关闭，并执行删去路由、减少/增加路径优先级等操作，保障流量重新选路，进而实现流量的快速切换。

目前基于BFD会话实现跨分段网络的故障检测的技术主要是“BFD触发关闭(BFDtrigger if-down)”技术。

下面以图1中的第一转发节点R1为例对“BFD trigger if-down”技术进行解释说明。

在图1中第一转发节点R1在第二分段网络40内对应的三条路径中每条路径上部署BFD会话。每个BFD会话均和第一转发节点R1上的目标入接口联动，目标入接口为第一转发节点R1上用于接收来自第二转发节点R2的报文流的入接口。

在这三条路径上任一条路径BFD会话发生故障时，由于该路径上的BFD会话和目标入接口已经联动，因此将触发目标入接口关闭(down)掉，进而触发第二转发节点R2重新换路。

“BFD trigger if-down”技术有如下三个问题：

(1)第一转发节点R1在第二分段网络40内对应的三条路径中任一条路径故障时，都将触发第二转发节点R2感知到故障。因此这种故障检测方式只能检测到单点故障，单点故障可以理解为只能检测到其中一条路径上的故障。如果单点故障下就触发第二转发节点R2重新换路，很容易导致网络资源的浪费。

基于此，本申请实施例提供的故障检测方法能够实现多点故障检测，详细实现方式将在后续实施例中解释说明。

(2)每个BFD会话均和第一转发节点R1上的目标入接口联动，是指控制面上的联动。也即，在具体检测故障时，第一转发节点R1的控制面上先获取每条路径的BFD会话的故障情况，然后第一转发节点R1的控制面上基于每条路径的BFD会话的故障情况确定是否关闭目标入接口，如果第一转发节点R1的控制面确定关闭目标入接口，第一转发节点R1的控制面则向第一转发节点R1的转发面下发关闭指令，以使第一转发节点R1的转发面将目标入接口的状态更新为关闭状态。

这种控制面上的联动无法实现流量的快速切换。基于此，本申请实施例提供的故障检测方法能够实现转发面上的联动，从而提高故障情况下的流量切换速率。详细实现方式将在后续实施例中解释说明。

(3)由于目前“BFD trigger if-down”技术只能实现单点故障检测，为了覆盖更多的故障情况，需要基于第一转发节点R1在第二分段网络40内的各条路由部署BFD会话。

示例地，针对第一转发节点R1部署位于第二分段网络40内的一条路由，该路由包括三个出接口，三个出接口为R1分别与R4、R5和R6之间的出接口，这三个出接口之间形成负载分担。然后部署BFD会话检测该路由，如果该路由存在故障，该BFD会话的状态则更新为关闭状态，以实现“BFD trigger if-down”。

但是基于路由部署BFD会话的方式不够灵活。基于此，本申请实施例提供的故障检测方法能够在无需基于路由部署BFD会话的情况下实现多点故障检测。详细实现方式将在后续实施例中解释说明。

下面对本申请实施例提供的跨分段网络的故障检测方法进行详细解释说明。

图2是本申请实施例提供的一种跨分段网络的故障检测方法流程图。如图2所示，该方法包括如下步骤201和步骤202。

步骤201：第一转发节点获取双向转发检测BFD群组的状态，BFD群组包括第一转发节点在第二分段网络内对应的多条路径中每条路径的BFD会话，BFD会话用于检测相应路径的故障。

其中，这多条路径可以为用于转发来自第二转发节点的报文流的全部或部分路径。可选地，这多条路径可以为第一转发节点对应的第二分段网络内的全部或部分路径。

需要说明的是，由于每条路径均对应第一转发节点上的一个出接口，因此本申请实施例中的多条路径可以通过第一转发节点上的多个出接口来分别标识。

示例地，第一转发节点上用于向第二分段网络转发报文流的出接口总共有10个。这10个出接口中的5个出接口用于转发来自第二转发节点的报文流。每个出接口对应一条在第二分段网络内转发报文流的路径。这种场景下，步骤201中的多条路径可以为这5个出接口对应的5条路径，也可以为这5条路径中的至少2条路径。或者，步骤201中的多条路径可以为这10个出接口对应的10条路径，也可以为这10条路径中的大部分路径。

比如，对于图1所示的第一转发节点R1，步骤201中的多条路径可以为图1中标记有分段业务2对应的三条路径。也可以为这三条路径中的其中两条路径。

由于BFD群组包括这多条路径中每条路径的BFD会话，而多条路径可以有以上多种情况，因此BFD群组中的BFD会话可以基于实际需求灵活配置，提高了本申请实施例提供的方法的灵活性。

示例地，如图3所示，将R1至R6的路径的BFD会话称为BFD会话1，将R1至R5的路径的BFD会话称为BFD会话2，将R1至R4的路径的BFD会话称为BFD会话3。此时BFD群组可以包括BFD会话1、BFD会话2和BFD会话3。也可以包括BFD会话1、BFD会话2和BFD会话3中任意两者。

另外，在本申请实施例中，BFD群组中组员可以由开发人员来配置。在一些实施例中，管理员配置BFD群组中的组员的实现方式可以为：第一转发节点响应于组员添加操作，将多条路径中每条路径的BFD会话作为BFD群组中的BFD会话。

具体地，第一转发节点显示群组配置界面，该群组配置界面包括BFD会话配置选项；响应于开发人员在BFD会话配置选项上的触发操作，将多条路径中每条路径的BFD会话作为BFD群组中的BFD会话。

图4是本申请实施例提供的一种群组配置界面示意图。如图4所示，该群组配置界面显示有BFD群组名称选项、BFD会话配置选项等。

其中，BFD群组名称选项用于开发人员输入BFD群组的名称。BFD会话配置选项用于开发人员输入BFD群组的各个组员。

当第一转发节点检测到开发人员通过预设操作触发BFD会话配置选项时，第一转发节点可以显示图4中的组员输入表格，该组员输入表格用于开发人员输入BFD群组中的各个BFD会话。如图4所示，对于图3所示的第一转发节点R1，开发人员在该组员输入表格输入BFD会话1、BFD会话2以及BFD会话3，从而实现将BFD会话1、BFD会话2以及BFD会话3作为BFD群组的组员，进而实现BFD会话1、BFD会话2以及BFD会话3，这三个BFD会话与BFD群组(BFDgroup)之间的联动。

需要说明的是，上述配置过程是以开发人员在第一转发节点上进行配置为例进行说明。可选地，开发人员也可以在网络的控制节点上配置第一转发节点上的BFD群组，由控制节点将配置的BFD群组下发到第一转发节点。在此不再详细说明。

另外，BFD群组包括第一转发节点对应的多条路径中每条路径的BFD会话，因此，BFD群组的状态相应地和多条路径中每条路径的BFD会话的状态相关。下面对BFD群组的状态进行详细解释说明。

在一些实施例中，BFD群组的状态能够指示BFD群组中是否存在BFD会话状态为关闭状态，或者说，能够指示BFD群组中的BFD会话是否全部是关闭状态。

这种场景下，BFD群组的状态和BFD群组中各个BFD会话的状态之间的关系可以为：在BFD群组中各个BFD会话均处于关闭状态的情况下，BFD群组的状态为关闭状态；在BFD群组中至少一个BFD会话的状态为打开状态的情况下，BFD群组的状态为打开状态。

比如，对于图1所示的第一转发节点R1，在步骤201中的多条路径为图1中标记有分段业务2对应的三条路径的情况下，如图3所示，将R1至R6的路径的BFD会话称为BFD会话1，将R1至R5的路径的BFD会话称为BFD会话2，将R1至R4的路径的BFD会话称为BFD会话3。也即，BFD群组包括BFD会话1、BFD会话2和BFD会话3。当BFD会话1、BFD会话2以及BFD会话3的状态全部为关闭状态的情况下，BFD群组的状态才会为关闭状态，在BFD会话1、BFD会话2以及BFD会话3中存在至少一个BFD会话的状态为打开状态的情况下，BFD群组的状态则为打开状态。

在另一些实施例中，BFD群组的状态能够指示BFD群组中是否存在大部分BFD会话状态为关闭状态，或者说，能够指示BFD群组中的大部分BFD会话是否全部是关闭状态。

这种场景下，BFD群组的状态和BFD群组中各个BFD会话的状态之间的关系可以为：预先设置数量阈值，在BFD群组中超过数量阈值个BFD会话均处于关闭状态的情况下，BFD群组的状态为关闭状态；在BFD群组中低于数量阈值个BFD的状态为关闭状态的情况下，BFD群组的状态为打开状态。

其中，数量阈值为小于或等于BFD群组组员数量的一个数值。数量阈值可以预先由管理员配置，本申请实施例对此不做限定。此外，本申请实施例中的“超过”可以理解为大于或大于等于，“低于”相应地可以分别理解为小于等于或小于，本申请实施例对此不做限定。

比如，如图2所示，BFD群组包括BFD会话1、BFD会话2和BFD会话3。当BFD会话1、BFD会话2以及BFD会话3中存在至少两个BRD的状态均为关闭状态的情况下，BFD群组的状态为关闭状态，在BFD会话1、BFD会话2以及BFD会话3中存在至少两个BFD会话的状态为打开状态的情况下，BFD群组的状态则为打开状态。

在本申请实施例中，在BFD群组的状态为前述实施例的情况下，第一转发节点可以预先确定并存储BFD群组的状态，也可以在执行步骤202时，基于BFD群组中各个BFD会话的状态来临时确定BFD群组的状态。下面对此进行解释说明。

在一些实施例中，第一转发节点预先更新并存储BFD群组的状态的实现过程可以为：第一转发节点获取多条路径中每条路径的BFD会话状态；第一转发节点基于多条路径中每条路径的BFD会话状态，更新并存储BFD群组的状态。这种场景下，步骤201中第一转发节点获取BFD群组的状态，可以理解为：第一转发节点获取存储的BFD群组的状态。

其中，第一转发节点基于多条路径中每条路径的BFD会话状态更新BFD群组的状态的详细实现方式，可以参考前述对BFD群组状态的相关解释，在此不再赘述。

此外，这种场景下，第一转发节点预先更新并存储BFD群组的状态的时机可以为：第一转发节点周期性地更新并存储BFD群组的状态。比如，第一转发节点每间隔10ms执行一次更新并存储BFD群组的状态。可选地，第一转发节点也可以在检测到BFD群组中任一BFD会话的状态发生变化时，更新并存储BFD群组的状态。

在另一些实施例中，如果第一转发节点是在执行步骤202时，基于BFD群组中各个BFD会话的状态来临时确定BFD群组的状态，则步骤201的实现过程可以为：第一转发节点获取多条路径中每条路径的BFD会话状态；第一转发节点基于多条路径中每条路径的BFD会话状态，确定BFD群组的状态。

其中，第一转发节点基于多条路径中每条路径的BFD会话状态确定BFD群组的状态的实现方式同样可以参考前述对BFD群组的状态的相关解释，在此不再赘述。

此外，步骤201可以由第一转发节点的控制面实现，也可以由第一转发节点的转发面实现。

需要说明的是，控制面和转发面是按照功能逻辑将第一转发节点上的各个硬件划分的两个面。其中，控制面通常包括主控板和中央处理器等，转发面通常包括执行转发的各个组件，比如转发表项存储器、物理接口卡和网络处理器等。

基于此，步骤201由第一转发节点的控制面实现具体是指：步骤201中的相关操作由第一转发节点的中央处理器(或主控板)来执行。步骤201由第一转发节点的转发面实现具体是指：步骤201中的相关操作由第一转发节点的网络处理器来执行。

由于报文流是由第一转发节点的转发面转发的，当步骤201由第一转发节点的转发面执行时，可以实现第二转发节点快速感知到这多条路径的故障情况，从而实现跨分段网络的快速故障检测。

当步骤201由第一转发节点的转发面实现时，步骤201可以理解为：在第一转发节点的转发面上获取BFD群组的状态。

另外需要说明的是，上述是以BFD群组的状态和BFD群组中各个BFD会话的状态为独立的概念为例进行说明。可选地，在另一些实施例中，BFD群组的状态可以直接为BFD群组中各个BFD会话的状态。这种情况下，第一转发节点获取BFD群组的状态，可以理解为获取BFD群组中各个BFD会话的状态。此时，第一转发节点上并没有基于BFD群组中各个BFD会话的状态确定BFD群组的状态的执行动作。

步骤202：第一转发节点基于BFD群组的状态向第二转发节点通告多条路径的故障情况。

在本申请实施例中，第一转发节点可以通过以下两种实现方式来通告多条路径的故障情况。下面对此进行分别解释说明。

第一种通告方式：联动上一级BFD会话进行通告。

其中，上一级BFD会话用于检测第一转发节点与第二转发节点之间的路径的故障。换句话说，上一级BFD会话为第一转发节点与第二转发节点之间的路径的BFD会话。具体可以理解为第一转发节点的出接口和第二转发节点的入接口之间的路径的BFD会话。

所谓的联动上一级BFD会话进行通告，也即第一转发节点基于BFD群组的状态，处理上一级BFD会话的流程，以使上一级BFD会话能够传递多条路径的故障情况。这种通告方式还可以称为“BFD会话track group”。

其中，BFD会话可以为请求评论(request for comments，RFC)5880里定义的BFD会话，或者为RFC7880中定义的无缝双向转发检测(Seamless Bidirectional ForwardingDetection，SBFD)会话。

RFC5880定义的BFD会话包括异步模式下的BFD会话和查询模式下的BFD会话。异步模式下的BFD会话可以理解为：双方均向对端发送BFD报文(或者BFD检测报文)，对端基于接收BFD报文的情况来确定双方之间的路径是否存在故障。查询模式下的BFD会话可以理解为：其中一端向对端发送BFD报文，对端仅负责返回BFD报文，发送BFD报文的这一段基于接收对端返回的BFD报文的情况来确定双方之间的路径是否存在故障。其中，查询模式下的BFD会话中，会话双方均可以作为发送BFD报文的一端，也即是会话双方都可以发起查询模式下的BFD会话。

需要说明的是，在RFC5880定义的BFD会话中，无论是异步模式下的BFD会话和查询模式下的BFD会话，会话双方都具备BFD会话状态，且BFD会话状态包括四种会话状态，分别是关闭(down)状态、初始(init)状态、打开(up)状态，管理型关闭(admin-down)状态。

RFC7880中定义的SBFD会话可以理解为：会话双方包括一个BFD发起端(initiator)和一个BFD反射端(reflector)。BFD发起端向BFD反射端发送BFD报文(BFD控制报文)，BFD反射端仅仅负责反射该BFD报文，BFD发起端基于接收BFD反射端返回的BFD报文的情况来确定双方之间的路径是否存在故障。

需要说明的是，在RFC7880中定义的SBFD会话，仅仅有BFD发起端有BFD会话状态，且只有关闭状态和打开状态两种状态。BFD反射端则没有针对该SBFD会话的会话状态。另外，SBFD会话中BFD发起端和BFD反射端是固定的，换句话，只能由一端作为BFD发起端，另一端作为BFD反射端，二者的角色并不能互换。

基于上述对BFD会话的相关说明，下面分两种情况对如何处理上一级BFD会话进行详细解释说明。

第一种情况：上一级BFD会话为异步模式下的BFD会话。

这种场景下，第一转发节点基于BFD群组的状态，处理上一级BFD会话的流程的实现过程可以为：第一转发节点基于BFD群组的状态，处理上一级BFD会话中向第二转发节点发送信息的流程，或者，处理上一级BFD会话中对来自第二转发节点的信息的处理流程，以使上一级BFD会话能够传递多条路径的故障情况。

下面对第一转发节点基于BFD群组的状态处理上一级BFD会话中向第二转发节点发送信息的流程进行解释说明。

在一些实施例中，第一转发节点基于BFD群组的状态，处理上一级BFD会话中向第二转发节点发送信息的流程的实现过程可以为：如果BFD群组的状态为关闭状态，第一转发节点则不向第二转发节点发送第一BFD报文。相应地，如果BFD群组的状态为打开状态，第一转发节点则向第二转发节点发送第一BFD报文。

由于异步模式下BFD会话的双方周期性地发送BFD报文，以使对端基于接收BFD报文的情况来确定是否存在故障。因此，第一转发节点在周期性向第二转发节点发送BFD报文的过程中，如果检测到BFD群组的状态为关闭状态，则不再向第二转发节点发送BFD报文，如此第二转发节点将检测到该上一级BFD会话存在故障，也即检测到第一转发节点上存在故障，从而达到将多条路径的故障情况通过上一级BFD会话传递给第一转发节点，实现跨分段网络的故障检测。

可选地，可以设置第一延时时长，如此第一转发节点在周期性向第二转发节点发送BFD报文的过程中，在当前时间为向第二转发节点发送第一BFD报文的时刻时，如果检测到BFD群组的状态为关闭状态，则判断第一延时时长之后BFD群组的状态是否还为关闭状态，如果仍为关闭状态，第一转发节点则不向第二转发节点发送第一BFD报文。如果第一延时时长后，BFD群组的状态为打开状态，此时则向第二转发节点发送第一BFD报文。

通过这种方式可以避免由于BFD群组状态的误判而导致第一转发节点直接换路。

在另一些实施例中，第一转发节点基于BFD群组的状态，处理上一级BFD会话中向第二转发节点发送信息的流程的实现过程可以为：如果BFD群组的状态为关闭状态，第一转发节点则将上一级BFD会话的状态设置为关闭状态，并向第二转发节点发送状态通告消息，状态通告消息指示上一级BFD会话的状态为关闭状态。相应地，如果BFD群组的状态为打开状态，第一转发节点则不执行将上一级BFD会话状态设置为关闭状态的操作。

在异步模式下BFD会话中，第一转发节点具有直接设置BFD会话状态为关闭状态并通告BFD会话状态的能力。因此，第一转发节点如果检测到BFD群组的状态为关闭状态，则直接将上一级BFD会话的状态设置为关闭状态，并向第二转发节点发送状态通告消息，如此第二转发节点将检测到该上一级BFD会话存在故障，也即检测到第一转发节点上存在故障，从而达到将多条路径的故障情况通过上一级BFD会话传递给第一转发节点，实现跨分段网络的故障检测。

可选地，同样可以设置延时时长，以避免由于BFD群组状态的误判而导致第一转发节点直接换路。相关实现方式在此不再赘述。

需要说明的是，上述两个实施例是以基于BFD群组的状态处理上一级BFD会话中向第二转发节点发送信息的示例说明。任意处理上一级BFD会话中向第二转发节点发送信息的具体方式，只要满足如下条件，则均在本申请实施例的范围之内。该条件为：在BFD群组状态为关闭状态时，发送的信息能够实现第二转发节点确定上一级BFD会话存在故障。

下面对第一转发节点基于BFD群组的状态处理上一级BFD会话中对来自第二转发节点的信息的处理流程进行解释说明。

在一些实施例中，第一转发节点基于BFD群组的状态，处理上一级BFD会话中对来自第二转发节点的信息的处理流程的实现过程可以为：在接收到来自第二转发节点的第二BFD报文时，如果BFD群组的状态为关闭状态，第一转发节点则丢弃第二BFD报文，不执行基于第二BFD报文更新当前BFD检测周期内接收到的BFD报文数量的操作。相应地，如果BFD群组的状态为打开状态，第一转发节点则基于第二BFD报文更新当前BFD检测周期内接收到的BFD报文数量。

需要说明的是，上述实施例是以基于BFD群组的状态处理上一级BFD会话中对来自第二转发节点的信息的处理流程的示例说明。任意处理上一级BFD会话中对来自第二转发节点的信息的处理流程的具体方式，只要满足如下条件，则均在本申请实施例的范围之内。该条件为：在BFD群组状态为关闭状态时，对来自第二转发节点的信息的处理流程能够实现第一转发节点确定出上一级BFD会话的状态为关闭状态，并向第二转发节点发送状态通告报文。

第二种情况：上一级BFD会话为查询模式下的BFD会话或为无缝双向转发检测SBFD会话。

在上一级BFD会话为查询模式下的BFD会话或为SBFD会话的情况下，由于上一级BFD会话双方中有一方用来检测故障，另一方仅仅用于反射接收到的BFD报文，因此这种场景下，为了能够实现第二转发节点感知到跨分段网络的故障，第二转发节点作为发送BFD报文的一方，第一转发节点作为返回接收到的BFD报文的一方。

这种场景下，第一转发节点基于BFD群组的状态，处理上一级BFD会话的流程的实现方式可以为：第一转发节点基于BFD群组的状态，处理上一级BFD会话中对来自第二转发节点的BFD报文的处理流程，以使上一级BFD会话能够传递多条路径的故障情况。

具体地，在接收到来自第二转发节点的第三BFD报文时，如果BFD群组的状态为关闭状态，第一转发节点则丢弃第三BFD报文，不执行将第三BFD报文返回至第二转发节点的操作。相应地，如果BFD群组的状态为打开状态，第一转发节点则将第三BFD报文返回至第二转发节点。

上述是以RFC5880中定义的BFD会话以及RFC7880中定义的SBFD会话为例进行说明。需要说明的是，上述两种BFD会话协议场景下的“处理上一级BFD会话”的具体流程可以应用在其他可能的BFD会话协议中，本申请是实施例对此不做限定。

此外，在本申请实施例中，为了能够实现将BFD群组的状态和上一级BFD会话进行联动，还可以预先由开发人员进行配置。

在一些实施例中，开发人员配置BFD群组的状态和上一级BFD会话之间的联动的实现过程可以为：第一转发节点获取BFD群组，第一转发节点确定BFD群组与上一级BFD会话的对应关系。

具体地，第一转发节点显示群组配置界面，群组配置界面包括群组跟踪功能配置选项；响应于开发人员在群组跟踪功能配置选项上的触发操作，将上一级BFD会话与BFD群组绑定，以建立BFD群组与上一级BFD会话的对应关系，并基于BFD群组的状态处理上一级BFD会话的流程。

图5是本申请实施例提供的另一种群组配置界面示意图。如图5所示，该群组配置界面显示有BFD群组名称选项、BFD会话配置选项以及群组跟踪功能配置选项等。

其中，BFD群组名称选项和BFD会话配置选项前述已经说明，在此不再赘述。群组跟踪功能配置选项用于开发人员将BFD群组的状态和上一级BFD会话进行联动。

当第一转发节点检测到开发人员通过预设操作触发群组跟踪功能配置选项时，第一转发节点可以显示图5中的跟踪会话输入窗口，该跟踪会话输入窗口用于开发人员输入与BFD群组联动的上一级BFD会话。如图5所示，对于图2所示的第一转发节点R1，开发人员在该跟踪会话输入窗口输入上一级BFD会话的标识，从而实现包括BFD会话1、BFD会话2以及BFD会话3的BFD群组与上一级BFD会话之间联动。

需要说明的是，上述配置过程是以开发人员在第一转发节点上进行配置为例进行说明。可选地，开发人员也可以在网络的控制节点上配置与第一转发节点上的BFD群组联动的上一级BFD会话，由控制节点将BFD群组与上一个BFD之间的对应关系下发到第一转发节点。在此不再详细说明。

另外，在BFD群组的状态直接为BFD群组中各个BFD会话的状态的情况下，上述BFD群组的状态为关闭状态的具体内容，可以参考前述对BFD状态的相关解释。示例地，当BFD群组的状态指示BFD群组中全部组员的状态是否均为关闭状态的情况下，BFD群组状态为关闭状态，也即BFD群组中各个BFD会话的状态均为关闭状态。BFD群组状态为打开状态，也即BFD群组中存在至少一个BFD会话的状态为打开状态。

比如，在第一种情况和第二种情况中，第一转发节点在获取到BFD群组中各个BFD会话的状态时，如果判断出BFD群组中各个BFD会话的状态均为关闭状态，则在当前时间为向第二转发节点发送第一BFD报文的时刻时，第一转发节点不向第二转发节点发送第一BFD报文，或者，第一转发节点则将上一级BFD会话的状态设置为关闭状态，并向第二转发节点发送状态通告消息，或者，在接收到来自第二转发节点的第三BFD报文时，第一转发节点则丢弃第三BFD报文，不执行将第三BFD报文返回至第二转发节点的操作。具体实现方式可以参考前述内容，在此不再赘述。

另外，在第一种通告方式中，由于是联动上一级BFD会话进行通告，这样无需在第一转发节点和第二转发节点之间新增其他传输内容，该通告方式容易实现且节省网络资源。

此外，由于上一级BFD会话相关的报文是在第一转发节点的转发面进行转发的。因此，通过联动上一级BFD会话，能够实现整个故障检测流程在第一转发节点的转发面实现，从而提高了故障检测速率。

第二种通告方式：以通告消息方式通告。

其中，通告消息是指第一转发节点通过专门的一个报文来向第二转发节点通告BFD群组的状态。这种场景下，步骤202的实现过程为：第一转发节点向第二转发节点发送故障通告消息，该故障通告消息用于向第二转发节点通告多条路径的故障情况。

其中，该故障通告消息可以通过多种方式来通告多条路径的故障情况。在一些实施例中，该故障通告消息携带BFD群组的状态。可选地，该故障通告消息还可以携带其他指示信息，该其他指示信息能够标识多条路径的故障情况。

在本申请实施例中，该故障通告消息可以承载在业务流量中，也可以承载在专门的BGP通告报文中(也即通过BGP协议来通告)。具体实现方式本申请实施例对此不做详细说明。

其中，当故障通告消息承载在业务流量时，步骤202可以理解为在第一转发节点的转发面上基于BFD群组的状态向第二转发节点通告多条路径的故障情况。

当故障通告消息承载在专门的BGP通告报文时，由于BGP通告报文可以在转发面实现也可以在控制面实现。因此，步骤202可以为：在第一转发节点的转发面上基于BFD群组的状态向第二转发节点通告多条路径的故障情况，或者，在第一转发节点的控制面上基于BFD群组的状态向第二转发节点通告多条路径的故障情况。

综上所述，本申请实施例提供的技术方案能够实现如下技术效果：

(1)提供了一种基于BFD群组来实现跨分段网络的多点故障检测方式。无需基于路由部署BFD会话来检测多点故障。提供了跨分段网络的多点故障检测的灵活性。

(2)将BFD群组与上一级BFD会话进行联动，基于BFD群组的状态快速触发上一级BFD down，以实现将基于BFD群组检测的故障传递给上一级分段网络，这样可以加速流量切换，减少丢包。

(3)整个故障感知过程可以在转发面实现，提高了故障感知速率。

下面以图3所示的通信系统为例，对图2所示的实施例再次进行解释说明。

基于图3所示的通信系统，跨分段网络的故障检测流程可以通过以下几个步骤实现。

步骤1：在分段级联网络中级联设备R1上部署检测分段业务的多个基础BFD会话(BFD会话1、BFD会话2、BFD会话3)。其中，BFD会话的会话类型包括所有BFD会话类型。

步骤2：在级联设备R1上创建group(也即BFD群组)，并在R1的转发面下发group状态；

步骤3：将级联设备R1上的多个基础BFD会话BFD会话1、BFD会话2、BFD会话3加入group；

步骤4：级联设备R1上部署上一级分段网络用于检测分段业务1的BFD trackgroup(也即RFC5880定义的BFD会话track group)或者SBFD反射端track group；

步骤5：根据基础BFD会话在转发面的状态刷新group状态，刷新规则如下：只要有一个基础BFD会话转发面状态为up，则group的状态为up，所有基础BFD会话转发面状态都为down，group状态才为down；

步骤6：步骤4中如果部署的是BFD track group，则在BFD会话报文发送或接收流程中判断group状态，如果group状态为down，则不发送或丢弃接收的BFD报文或者直接置BFD会话状态为down，触发远端(也即R2)检测down；

步骤7：步骤4中如果部署的是SBFD反射端track group，则在SBFD反射流程中判断group状态，如果group状态为down，则丢弃接收到的BFD报文，触发SBFD发起端也即R2)检测down；

步骤8：远端或SBFD发起端(也即R2)down后，触发业务切换。

图6是本申请实施例提供的一种网络设备的结构示意图，该网络设备为图1所示的通信系统中的第一转发节点，如图1所示，该通信系统还包括第二转发节点，第一转发节点为第一分段网络和第二分段网络之间的边缘节点，第二转发节点位于第一分段网络内。具体地，如图6所示，网络设备600包括收发模块601和处理模块602。

其中，收发模块602用于执行图2实施例中收发相关的操作；处理模块601用于执行图2实施例中除收发相关的操作之外的操作。

具体地，处理模块602，用于获取双向转发检测BFD群组的状态，BFD群组包括第一转发节点在第二分段网络内对应的多条路径中每条路径的BFD会话，BFD会话用于检测相应路径的故障。具体实现方式可以参考图2实施例中的步骤201。

收发模块601，用于基于BFD群组的状态向第二转发节点通告多条路径的故障情况。具体实现方式可以参考图2实施例中的步骤202。

可选地，在BFD群组中各个BFD会话均处于关闭状态的情况下，处理模块获取的BFD群组的状态为关闭状态；

在BFD群组中至少一个BFD会话的状态为打开状态的情况下，处理模块获取的BFD群组的状态为打开状态。

可选地，收发模块用于：

第一转发节点基于BFD群组的状态，处理上一级BFD会话的流程，上一级BFD会话用于检测第一转发节点与第二转发节点之间的路径的故障。

可选地，收发模块用于：

如果BFD群组的状态为关闭状态，第一转发节点则不向第二转发节点发送第一BFD报文。

可选地，收发模块用于：

如果BFD群组的状态为打开状态，第一转发节点则向第二转发节点发送第一BFD报文。

可选地，收发模块用于：

如果BFD群组的状态为关闭状态，第一转发节点则将上一级BFD会话的状态设置为关闭状态，并向第二转发节点发送状态通告消息，状态通告消息指示上一级BFD会话的状态为关闭状态。

可选地，收发模块用于：

如果BFD群组的状态为打开状态，第一转发节点则不执行将上一级BFD会话状态设置为关闭状态的操作。

可选地，收发模块用于：

在接收到来自第二转发节点的第二BFD报文时，如果BFD群组的状态为关闭状态，第一转发节点则丢弃第二BFD报文，不执行基于第二BFD报文更新当前BFD检测周期内接收到的BFD报文数量的操作。

可选地，收发模块用于：

如果BFD群组的状态为打开状态，第一转发节点则基于第二BFD报文更新当前BFD检测周期内接收到的BFD报文数量。

可选地，收发模块用于：

在接收到来自第二转发节点的第三BFD报文时，如果BFD群组的状态为关闭状态，第一转发节点则丢弃第三BFD报文，不执行将第三BFD报文返回至第二转发节点的操作。

可选地，收发模块用于：

如果BFD群组的状态为打开状态，第一转发节点则将第三BFD报文返回至第二转发节点。

可选地，上一级BFD会话为异步模式下的BFD会话，查询模式下的BFD会话或无缝双向转发检测SBFD会话。

可选地，处理模块还用于：

第一转发节点获取BFD群组；

第一转发节点确定BFD群组与上一级BFD会话的对应关系。

可选地，收发模块还用于：

第一转发节点向第二转发节点发送故障通告消息，故障通告消息用于向第二转发节点通告多条路径的故障情况。

可选地，故障通告消息携带BFD群组的状态。

可选地，处理模块还用于：

周期性获取多条路径中每条路径的BFD会话状态；

基于多条路径中每条路径的BFD会话状态，周期性更新并存储BFD群组的状态；

获取存储的BFD群组的状态。

可选地，处理模块用于：

获取多条路径中每条路径的BFD会话状态；

基于多条路径中每条路径的BFD会话状态，确定BFD群组的状态。

可选地，多条路径用于转发来自第二转发节点的报文流。

可选地，第一分段网络和第二分段网络分别用于承载以下业务包括中的至少一项：基于第六代网络协议的分段路由的策略SRv6 Policy业务、基于第六代网络协议的分段路由的最短路径SRv6 BE业务、虚拟租用线VLL业务、虚拟私用线服务VPLS业务；第一分段网络承载的业务和第二分段网络承载的业务不同。

可选地，处理模块用于：

在第一转发节点的转发面上获取BFD群组的状态。

可选地，收发模块用于：

在第一转发节点的转发面上基于BFD群组的状态向第二转发节点通告多条路径的故障情况。

综上所述，本申请实施例提供的网络设备能够实现如下技术效果：

下面对本申请实施例涉及的硬件结构进行介绍。

图7是本申请实施例提供的一种设备700的结构示意图。图8是本申请实施例提供的另一种设备800的结构示意图。下面对这两个设备的结构进行解释说明。

需要说明的是，以下介绍的设备700或设备800对应于上述方法实施例中的第一转发节点。设备700或设备800中的各硬件、模块和上述其他操作和/或功能分别为了实现方法实施例中第一转发节点所实施的各种步骤和方法，关于设备700或设备800如何处理报文的详细流程，具体细节可参见上述方法实施例，为了简洁，在此不再赘述。其中，上述方法实施例的各步骤通过设备700或设备800处理器中的硬件的集成逻辑电路或者软件形式的指令完成。结合本申请实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤，为避免重复，这里不再详细描述。

设备700对应于上述第一转发节点时，第一转发节点中的每个功能模块采用设备700的软件实现。换句话说，第一转发节点包括的功能模块为设备700的处理器读取存储器中存储的程序代码后生成的。

设备800对应于上述第一转发节点时，第一转发节点中的每个功能模块采用设备800的软件实现。换句话说，第一转发节点包括的功能模块为设备800的处理器读取存储器中存储的程序代码后生成的。

参见附图7，图7是本申请实施例提供的一种设备700的结构示意图。可选地，该设备700配置为图1所示的第一转发节点。换句话说，上述方法实施例中的第一转发节点可选地通过设备700实现。

该设备700例如是网络设备，比如说设备700是交换机、路由器等。或者，该设备700例如是计算设备，比如说设备700是主机、服务器或个人计算机等。该设备700可以由一般性的总线体系结构来实现。

设备700包括至少一个处理器701、通信总线702、存储器703以及至少一个通信接口704。

处理器701例如是通用中央处理器(central processing unit，CPU)、网络处理器(network processer，NP)、图形处理器(Graphics Processing Unit，GPU)、神经网络处理器(neural-network processing units，NPU)、数据处理单元(Data Processing Unit，DPU)、微处理器或者一个或多个用于实现本申请方案的集成电路。例如，处理器701包括专用集成电路(application-specific integrated circuit，ASIC)，可编程逻辑器件(programmable logic device，PLD)或其组合。PLD例如是复杂可编程逻辑器件(complexprogrammable logic device，CPLD)、现场可编程逻辑门阵列(field-programmable gatearray，FPGA)、通用阵列逻辑(generic array logic，GAL)或其任意组合。

通信总线702用于在上述组件之间传送信息。通信总线702可以分为地址总线、数据总线、控制总线等。为便于表示，附图7中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

存储器703例如是只读存储器(read-only memory，ROM)或可存储静态信息和指令的其它类型的静态存储设备，又如是随机存取存储器(random access memory，RAM)或者可存储信息和指令的其它类型的动态存储设备，又如是电可擦可编程只读存储器(electrically erasable programmable read-only Memory，EEPROM)、只读光盘(compactdisc read-only memory，CD-ROM)或其它光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其它磁存储设备，或者是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其它介质，但不限于此。存储器703例如是独立存在，并通过通信总线702与处理器701相连接。存储器703也可以和处理器701集成在一起。

通信接口704使用任何收发器一类的装置，用于与其它设备或通信网络通信。通信接口704包括有线通信接口，还可以包括无线通信接口。其中，有线通信接口例如可以为以太网接口。以太网接口可以是光接口，电接口或其组合。无线通信接口可以为无线局域网(wireless local area networks，WLAN)接口，蜂窝网络通信接口或其组合等。

在具体实现中，作为一种实施例，处理器701可以包括一个或多个CPU，如附图7中所示的CPU0和CPU1。

在具体实现中，作为一种实施例，设备700可以包括多个处理器，如附图7中所示的处理器701和处理器705。这些处理器中的每一个可以是一个单核处理器(single-CPU)，也可以是一个多核处理器(multi-CPU)。这里的处理器可以指一个或多个设备、电路、和/或用于处理数据(如计算机程序指令)的处理核。

在具体实现中，作为一种实施例，设备700还可以包括输出设备和输入设备。输出设备和处理器701通信，可以以多种方式来显示信息。例如，输出设备可以是液晶显示器(liquid crystal display，LCD)、发光二级管(light emitting diode，LED)显示设备、阴极射线管(cathode ray tube，CRT)显示设备或投影仪(projector)等。输入设备和处理器701通信，可以以多种方式接收用户的输入。例如，输入设备可以是鼠标、键盘、触摸屏设备或传感设备等。

在一些实施例中，存储器703用于存储执行本申请方案的程序代码710，处理器701可以执行存储器703中存储的程序代码710。也即是，设备700可以通过处理器701以及存储器703中的程序代码710，来实现方法实施例提供的跨分段网络的故障检测方法。

本申请实施例的设备700可对应于上述各个方法实施例中的用户面网元或控制面网元，并且，该设备700中的处理器701、通信接口704等可以实现上述各个方法实施例中的第一转发节点所具有的功能和/或所实施的各种步骤和方法。为了简洁，在此不再赘述。

在跨分段网络的故障检测采用设备700实现的情况下，在一些实施例中，附图6所示的网络设备600中的收发模块以及处理模块为设备700中的程序代码710中的软件模块，设备700中的处理器701通过执行程序代码710来实现附图6中的网络设备600中的收发模块以及处理模块的功能。

参见附图8，附图8是本申请实施例提供的一种设备800的结构示意图，可选地，该设备800配置为图1所示的第一转发节点。换句话说，上述方法实施例中的第一转发节点可选地通过设备800实现。

该设备800例如是网络设备，比如说设备800是交换机、路由器等。设备800包括：主控板8010和接口板8030。

主控板也称为主处理单元(main processing unit，MPU)或路由处理卡(routeprocessor card)，主控板8010用于对设备800中各个组件的控制和管理，包括路由计算、设备管理、设备维护、协议处理功能。主控板8010包括：中央处理器8011和存储器8012。

接口板8030也称为线路接口单元卡(line processing unit，LPU)、线卡(linecard)或业务板。接口板8030用于提供各种业务接口并实现数据包的转发。业务接口包括而不限于以太网接口、POS(Packet over SONET/SDH)接口等，以太网接口例如是灵活以太网业务接口(Flexible Ethernet Clients，FlexE Clients)。接口板8030包括：中央处理器8031、网络处理器8032、转发表项存储器8034和物理接口卡(phsical interface card，PIC)8033。

接口板8030上的中央处理器8031用于对接口板8030进行控制管理并与主控板8010上的中央处理器8011进行通信。

网络处理器8032用于实现报文的转发处理。网络处理器8032的形态可以是转发芯片。具体而言，网络处理器8032用于基于转发表项存储器8034保存的转发表转发接收到的报文，如果报文的目的地址为设备800的地址，则将该报文上送至CPU(如中央处理器8011)处理；如果报文的目的地址不是设备800的地址，则根据该目的地址从转发表中查找到该目的地址对应的下一跳和出接口，将该报文转发到该目的地址对应的出接口。其中，上行报文的处理包括：报文入接口的处理，转发表查找；下行报文的处理：转发表查找等等。

物理接口卡8033用于实现物理层的对接功能，原始的流量由此进入接口板8030，以及处理后的报文从该物理接口卡8033发出。物理接口卡8033也称为子卡，可安装在接口板8030上，负责将光电信号转换为报文并对报文进行合法性检查后转发给网络处理器8032处理。在一些实施例中，中央处理器也可执行网络处理器8032的功能，比如基于通用CPU实现软件转发，从而物理接口卡8033中不需要网络处理器8032。

可选地，设备800包括多个接口板，例如设备800还包括接口板8040，接口板8040包括：中央处理器8041、网络处理器8042、转发表项存储器8044和物理接口卡8043。

可选地，设备800还包括交换网板8020。交换网板8020也可以称为交换网板单元(switch fabric unit，SFU)。在网络设备有多个接口板8030的情况下，交换网板8020用于完成各接口板之间的数据交换。例如，接口板8030和接口板8040之间可以通过交换网板8020通信。

主控板8010和接口板8030耦合。例如。主控板8010、接口板8030和接口板8040，以及交换网板8020之间通过系统总线与系统背板相连实现互通。在一种可能的实现方式中，主控板8010和接口板8030之间建立进程间通信协议(inter-process communication，IPC)通道，主控板8010和接口板8030之间通过IPC通道进行通信。

在逻辑上，设备800包括控制面和转发面，控制面包括主控板8010和中央处理器8031，转发面包括执行转发的各个组件，比如转发表项存储器8034、物理接口卡8033和网络处理器8032。控制面执行路由器、生成转发表、处理信令和协议报文、配置与维护设备的状态等功能，控制面将生成的转发表下发给转发面，在转发面，网络处理器8032基于控制面下发的转发表对物理接口卡8033收到的报文查表转发。控制面下发的转发表可以保存在转发表项存储器8034中。在有些实施例中，控制面和转发面可以完全分离，不在同一设备上。

在第一转发节点采用设备800实现的情况下，在一些实施例中，附图6所示的网络设备600中的收发模块相当于设备800中的物理接口卡8033；网络设备600的处理模块相当于网络处理器8032、中央处理器8031或中央处理器8011。

应理解，本申请实施例中接口板8040上的操作与接口板8030的操作一致，为了简洁，不再赘述。应理解，本实施例的设备800可对应于上述各个方法实施例中的第一转发节点，该设备800中的主控板8010、接口板8030和/或8040可以实现上述各个方法实施例中的第一转发节点所具有的功能和/或所实施的各种步骤，为了简洁，在此不再赘述。

值得说明的是，主控板可能有一块或多块，有多块的时候可以包括主用主控板和备用主控板。接口板可能有一块或多块，网络设备的数据处理能力越强，提供的接口板越多。接口板上的物理接口卡也可以有一块或多块。交换网板可能没有，也可能有一块或多块，有多块的时候可以共同实现负荷分担冗余备份。在集中式转发架构下，网络设备可以不需要交换网板，接口板承担整个系统的业务数据的处理功能。在分布式转发架构下，网络设备可以有至少一块交换网板，通过交换网板实现多块接口板之间的数据交换，提供大容量的数据交换和处理能力。所以，分布式架构的网络设备的数据接入和处理能力要大于集中式架构的设备。可选地，网络设备的形态也可以是只有一块板卡，即没有交换网板，接口板和主控板的功能集成在该一块板卡上，此时接口板上的中央处理器和主控板上的中央处理器在该一块板卡上可以合并为一个中央处理器，执行两者叠加后的功能，这种形态设备的数据交换和处理能力较低(例如，低端交换机或路由器等网络设备)。具体采用哪种架构，取决于具体的组网部署场景，此处不做任何限定。

在另一些实施例中，本申请实施例还提供了一种通信系统。如图9所示，该通信系统900包括第一转发节点901和第二转发节点902。

其中，第一转发节点901用于：获取双向转发检测BFD群组的状态，BFD群组包括第一转发节点在第二分段网络内对应的多条路径中每条路径的BFD会话，BFD会话用于检测相应路径的故障；基于BFD群组的状态向第二转发节点902通告多条路径的故障情况。

上述通信系统各个转发节点的详细功能可以参考图2所示的实施例，在此不再赘述。

本领域普通技术人员可以意识到，结合本文中所公开的实施例中描述的各方法步骤和模块，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各实施例的步骤及组成。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。本领域普通技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的系统、设备和模块的具体工作过程，可以参见前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统、设备和方法，可以通过其它的方式实现。例如，以上所描述的设备实施例仅仅是示意性的，例如，该模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个模块或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口、设备或模块的间接耦合或通信连接，也可以是电的，机械的或其它的形式连接。

该作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请实施例方案的目的。

另外，在本申请各个实施例中的各功能模块可以集成在一个处理模块中，也可以是各个模块单独物理存在，也可以是两个或两个以上模块集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。

该集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分，或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例中方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(read-only memory，ROM)、随机存取存储器(random access memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

本申请中术语“第一”“第二”等字样用于对作用和功能基本相同的相同项或相似项进行区分，应理解，“第一”、“第二”之间不具有逻辑或时序上的依赖关系，也不对数量和执行顺序进行限定。还应理解，尽管以下描述使用术语第一、第二等来描述各种元素，但这些元素不应受术语的限制。这些术语只是用于将一元素与另一元素区别分开。例如，在不脱离各种示例的范围的情况下，第一信息可以被称为第二信息，并且类似地，第二信息可以被称为第一信息。第一信息和第二信息都可以是信息，并且在某些情况下，可以是单独且不同的信息。

本申请中术语“至少一个”的含义是指一个或多个，本申请中术语“多个”的含义是指两个或两个以上。本文中术语“系统”和“网络”经常可互换使用。

还应理解，术语“若”可被解释为意指“当...时”(“when”或“upon”)或“响应于确定”或“响应于检测到”。类似地，根据上下文，短语“若确定...”或“若检测到[所陈述的条件或事件]”可被解释为意指“在确定...时”或“响应于确定...”或“在检测到[所陈述的条件或事件]时”或“响应于检测到[所陈述的条件或事件]”。

以上描述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。该计算机程序产品包括一个或多个计算机程序指令。在计算机上加载和执行该计算机程序指令时，全部或部分地产生按照本申请实施例中的流程或功能。该计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。该计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，该计算机程序指令可以从一个网站站点、计算机、服务器或数据中心通过有线或无线方式向另一个网站站点、计算机、服务器或数据中心进行传输。该计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。该可用介质可以是磁性介质(例如软盘、硬盘、磁带)、光介质(例如，数字视频光盘(digitalvideo disc，DVD)、或者半导体介质(例如固态硬盘)等。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，该程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

以上描述仅为本申请的可选实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims

1.一种跨分段网络的故障检测方法，其特征在于，所述方法应用于通信系统，所述通信系统包括第一转发节点和第二转发节点，所述第一转发节点为第一分段网络和第二分段网络之间的边缘节点，所述第二转发节点位于所述第一分段网络内；所述方法包括：

所述第一转发节点获取双向转发检测BFD群组的状态，所述BFD群组包括所述第一转发节点在所述第二分段网络内对应的多条路径中每条路径的BFD会话，所述BFD会话用于检测相应路径的故障；

所述第一转发节点基于所述BFD群组的状态向所述第二转发节点通告所述多条路径的故障情况。

2.如权利要求1所述的方法，其特征在于，所述第一转发节点获取BFD群组的状态，包括：

在所述BFD群组中各个BFD会话均处于关闭状态的情况下，所述第一转发节点获取的所述BFD群组的状态为关闭状态；

在所述BFD群组中至少一个BFD会话的状态为打开状态的情况下，所述第一转发节点获取的所述BFD群组的状态为打开状态。

3.如权利要求1或2所述的方法，其特征在于，所述第一转发节点基于所述BFD群组的状态向所述第二转发节点通告所述多条路径的故障情况，包括：

所述第一转发节点基于所述BFD群组的状态，处理上一级BFD会话的流程，所述上一级BFD会话用于检测所述第一转发节点与所述第二转发节点之间的路径的故障。

4.如权利要求3所述的方法，其特征在于，所述第一转发节点基于所述BFD群组的状态，处理上一级BFD会话的流程，包括：

如果所述BFD群组的状态为关闭状态，所述第一转发节点则不向所述第二转发节点发送所述第一BFD报文。

5.如权利要求4所述的方法，其特征在于，所述第一转发节点基于所述BFD群组的状态，处理上一级BFD会话的流程，包括：

如果所述BFD群组的状态为打开状态，所述第一转发节点则向所述第二转发节点发送所述第一BFD报文。

6.如权利要求3所述的方法，其特征在于，所述第一转发节点基于所述BFD群组的状态，处理上一级BFD会话的流程，包括：

如果所述BFD群组的状态为关闭状态，所述第一转发节点则将所述上一级BFD会话的状态设置为关闭状态，并向所述第二转发节点发送状态通告消息，所述状态通告消息指示所述上一级BFD会话的状态为关闭状态。

7.如权利要求6所述的方法，其特征在于，所述第一转发节点基于所述BFD群组的状态，处理上一级BFD会话的流程，包括：

如果所述BFD群组的状态为打开状态，所述第一转发节点则不执行将所述上一级BFD会话状态设置为关闭状态的操作。

8.如权利要求3所述的方法，其特征在于，所述第一转发节点基于所述BFD群组的状态，处理上一级BFD会话的流程，包括：

在接收到来自所述第二转发节点的第二BFD报文时，如果所述BFD群组的状态为关闭状态，所述第一转发节点则丢弃所述第二BFD报文，不执行基于所述第二BFD报文更新当前BFD检测周期内接收到的BFD报文数量的操作。

9.如权利要求8所述的方法，其特征在于，所述第一转发节点基于所述BFD群组的状态，处理上一级BFD会话的流程，包括：

如果所述BFD群组的状态为打开状态，所述第一转发节点则基于所述第二BFD报文更新当前BFD检测周期内接收到的BFD报文数量。

10.如权利要求3所述的方法，其特征在于，所述第一转发节点基于所述BFD群组的状态，处理上一级BFD会话的流程，包括：

在接收到来自所述第二转发节点的第三BFD报文时，如果所述BFD群组的状态为关闭状态，所述第一转发节点则丢弃所述第三BFD报文，不执行将所述第三BFD报文返回至所述第二转发节点的操作。

11.如权利要求10所述的方法，其特征在于，所述第一转发节点基于所述BFD群组的状态，处理上一级BFD会话的流程，包括：

如果所述BFD群组的状态为打开状态，所述第一转发节点则将所述第三BFD报文返回至所述第二转发节点。

12.如权利要求3-11任一所述的方法，其特征在于，所述上一级BFD会话为异步模式下的BFD会话，查询模式下的BFD会话或无缝双向转发检测SBFD会话。

13.如权利要求3-12任一所述的方法，其特征在于，所述方法还包括：

所述第一转发节点获取所述BFD群组；

所述第一转发节点确定所述BFD群组与所述上一级BFD会话的对应关系。

14.如权利要求1或2所述的方法，其特征在于，所述第一转发节点基于所述BFD群组的状态向所述第二转发节点通告所述多条路径的故障情况，包括：

所述第一转发节点向所述第二转发节点发送故障通告消息，所述故障通告消息用于向所述第二转发节点通告所述多条路径的故障情况。

15.如权利要求14所述的方法，其特征在于，所述故障通告消息携带所述BFD群组的状态。

16.如权利要求1-15任一所述的方法，其特征在于，所述第一转发节点获取BFD群组的状态之前，所述方法还包括：

所述第一转发节点周期性获取所述多条路径中每条路径的BFD会话状态；

所述第一转发节点基于所述多条路径中每条路径的BFD会话状态，周期性更新并存储所述BFD群组的状态；

所述第一转发节点获取BFD群组的状态，包括：

所述第一转发节点获取存储的所述BFD群组的状态。

17.如权利要求1-15任一所述的方法，其特征在于，所述第一转发节点获取BFD群组的状态，包括：

所述第一转发节点获取所述多条路径中每条路径的BFD会话状态；

所述第一转发节点基于所述多条路径中每条路径的BFD会话状态，确定所述BFD群组的状态。

18.如权利要求1-17任一所述的方法，其特征在于，所述多条路径用于转发来自所述第二转发节点的报文流。

19.如权利要求1-18任一所述的方法，其特征在于，所述第一分段网络和所述第二分段网络分别用于承载以下业务包括中的至少一项：基于第六代网络协议的分段路由的策略SRv6Policy业务、基于第六代网络协议的分段路由的最短路径SRv6 BE业务、虚拟租用线VLL业务、虚拟私用线服务VPLS业务；

所述第一分段网络承载的业务和所述第二分段网络承载的业务不同。

20.如权利要求1-19任一所述的方法，其特征在于，所述第一转发节点获取BFD群组的状态，包括：

在所述第一转发节点的转发面上获取所述BFD群组的状态。

21.如权利要求1-20任一所述的方法，其特征在于，所述第一转发节点基于所述BFD群组的状态向所述第二转发节点通告所述多条路径的故障情况，包括：

在所述第一转发节点的转发面上基于所述BFD群组的状态向所述第二转发节点通告所述多条路径的故障情况。

22.一种通信系统，所述系统包括第一转发节点和第二转发节点，所述第一转发节点用于执行如权利要求1-21任一项所述的方法。

23.一种网络设备，其特征在于，所述网络设备包括存储器和处理器；

所述存储器用于存储程序指令；

所述处理器被配置为调用所述存储器中存储的程序，以使得所述网络设备执行如权利要求1-21任一项所述的方法。

24.一种网络设备，其特征在于，所述网络设备为通信系统中的第一转发节点，所述通信系统还包括第二转发节点，所述第一转发节点为第一分段网络和第二分段网络之间的边缘节点，所述第二转发节点位于所述第一分段网络内；

所述网络设备包括收发模块和处理模块：

所述收发模块用于执行如权利要求1-21任一所述方法中收发相关的操作；

所述处理模块用于执行如权利要求1-21任一所述方法中除所述收发相关的操作之外的操作。

25.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有指令，当所述指令在处理器上运行时，实现权利要求1-21任一项所述的方法。

26.一种计算机程序产品，其特征在于，所述计算机程序产品包含指令，所述指令在处理器上运行时，实现权利要求1-21任一项所述的方法。