CN101697626A - 基于双向转发检测协议的通信故障检测方法及系统 - Google Patents
基于双向转发检测协议的通信故障检测方法及系统 Download PDFInfo
- Publication number
- CN101697626A CN101697626A CN200910211384A CN200910211384A CN101697626A CN 101697626 A CN101697626 A CN 101697626A CN 200910211384 A CN200910211384 A CN 200910211384A CN 200910211384 A CN200910211384 A CN 200910211384A CN 101697626 A CN101697626 A CN 101697626A
- Authority
- CN
- China
- Prior art keywords
- message
- keep
- alive
- length
- terminal equipment
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Maintenance And Management Of Digital Transmission (AREA)
Abstract
本发明公开了一种基于双向转发检测协议的通信故障检测方法及系统,在上述方法中,预先配置BFD协议的相互通信的两端设备中的本端设备,向对端设备发送基于BFD协议的多种保活报文,其中,各种保活报文的报文长度不同且在预设长度范围内;对端设备在预先设定的超时时间内没有接收到来自本端设备的保活报文,则确定对端设备与本端设备之间的通信链路发生通信故障,并根据已经接收到的保活报文的报文长度,确定发生通信故障的报文长度范围。根据本发明提供的技术方案,解决了现有技术中,BFD检测机制无法检测报文长度不同于标准BFD保活报文长度的流量报文在转发过程中是否出现通信故障的问题。
Description
技术领域
本发明涉及移动通信技术领域,尤其涉及一种基于双向转发检测协议的通信故障检测方法及系统。
背景技术
在数据通信技术领域,为了具有电信级可靠性,要求网络在出现故障时快速自愈,保证业务不至中断,因此需要检测技术快速检测出网络故障,并迅速做出路由或者链路切换。
在现有技术中,通常采用发送HELLO(一种侦测链路的报文)报文的检测机制检测网络故障,但是采用HELLO报文的检测时间一般都大于1秒,对于一些特殊的应用检测时间过长,无法检测和发现在短时间内发生的链路状态,而且当路由协议不在运行状态的时候,HELLO报文机制也没有得到支持。为了解决上述问题,现有技术又提出了双向转发检测协议(Bidirectional Forwarding Detection简称BFD)。
BFD是一种通用高速Hello机制,能够为各种上层控制协议,例如开放式最短路径优先(Open Shortest Path First,简称OSPF)协议提供一种通用的低开销快速故障检测服务,它是从基础传输技术中经过逐步发展而来的。之所以称为双向,是因为BFD协议通过三次握手机制,能提供链路两个方向的连通性检测。BFD可以快速检测到转发路径上的接口和链路故障、节点的转发引擎故障等,并把故障通知上层协议,使上层协议能够快速收敛。BFD可用于检测任何形式的路径,包括直接相连的物理链路、虚电路、隧道、MPLS LSP乃至多跳的路由通道。甚至对于单向链路(如MPLS TE隧道),只要有回来的路径,都可以检测。BFD可以适用于任何传输介质和封装格式,可以方便的用软件或硬件来实现。BFD检测到的网络故障可以由转发平面恢复或由控制平面恢复。
BFD没有自己的邻居发现机制,要靠被服务的上层应用通知BDF相关的邻居信息。在获取邻居信息以后,两台配置BFD协议的设备上建立会话并快速发送BFD报文。如果在检测时间内没有收到BFD报文,则认为双向转发路径出现故障,通知上层应用进行处理。
BFD的工作机制可以分为两个阶段:第一个阶段是BFD会话的建立,包括状态机的切换和定时间隔的协商;第二个阶段是会话建立之后定时发送保活报文,并检测是否超时。
图1是根据现有技术的BFD会话建立的流程图,如图1所示,BFD会话建立采用三次握手方式来进行:
1、设备A和设备B接到上层应用通知后,处于DOWN状态,并发送状态为DOWN的BFD控制报文;
2、收到对端发送的BFD DOWN报文以后,本地会话的状态迁移到INIT状态,并发送状态为INIT的BFD控制报文;
3、当收到对端的BFD INIT报文以后状态切换到UP,并发送状态为UP的BFD控制报文。
BFD会话建立时会进行参数的协商,协商出发送间隔和超时间隔,之后双方协商的发送间隔发送保活(keepalive)报文。当一方收到对端的BFD keepalive报文以后重置本地检测定时器,保持本端设备的UP状态,这个过程称为保活。如果在超时时间内没有收到BFD keepalive报文,则将本端设备的状态迁移到DOWN,并做出相应的补救处理。
图2是根据现有技术的BFD故障检测的工作流程图,如图2所示,该流程包括以下步骤:
1、链路出现故障;
2、BFD检测到故障,BFD邻居撤消,如果BFD与快速重路由(Fast Reroute,简称FRR)绑定,通知FRR切换到备份链路;
3、BFD通知其支撑的路由协议OSPF邻居断链;
4、OSPF感知到邻居断链后重新计算路由。
在实际的应用网络中,由于流过检测路径的报文长度是不完全相等的,可能存在某种长度的报文能够正常转发而其它长度不能够正常转发的情况。例如,流量报文存在分片的情况下,可能存在分出的大包不能正常转发的分片故障。而传统的BFD检测机制并不能检测出上述问题,标准的BFD的keepalive报文(不带认证字段的情况下)IP层以上长度只有52个字节(MPLS报文因为IP层携带4个字节的ROUTER ALERT选项字段,共56个字节),无法满足针对其他报文长度的业务流量的检测需求。也就是说,如果业务流量的报文长度非52(或者56)字节时,即使出现转发故障,BFD也可能检测不出来。
发明内容
有鉴于此,本发明提供了一种基于双向转发检测协议的通信故障检测方案,用以解决现有技术中BFD检测机制无法检测报文长度不同于标准BFD keepalive报文长度的业务流量报文在转发时是否出现故障的问题。
根据本发明的一个方面,提供了一种基于双向转发检测BFD协议的通信故障检测方法。
根据本发明的基于双向转发检测BFD协议的通信故障检测方法包括:预先配置BFD协议的相互通信的两端设备中的本端设备,向对端设备发送基于BFD协议的多种保活报文,其中,各种保活报文的报文长度不同且在预设长度范围内;对端设备在预先设定的超时时间内没有接收到来自本端设备的保活报文,则确定对端设备与本端设备之间的通信链路发生通信故障,并根据已经接收到的保活报文的报文长度,确定发生通信故障的报文长度范围。
根据本发明的另一个方面,提供了一种基于BFD协议的通信故障检测系统。
根据本发明的基于BFD协议的通信故障检测系统包括:包括预先配置BFD协议的相互通信的两端设备,其中,本端设备,用于向对端设备发送基于BFD协议的多种保活报文,其中,各种保活报文的报文长度不同且在预设长度范围内;对端设备,用于在预先设定的超时间隔内没有接收到来自本端设备的保活报文的情况下,确定对端设备与本端设备之间的通信链路发生通信故障,并根据已经接收到的保活报文的报文长度,确定发生通信故障的报文长度范围。
通过本发明的上述至少一个方案,本端设备向对端设备发送报文长度不同的保活报文,以检测通信链路是否发生通信故障,并根据已经接收到的保活报文的报文长度,判断发生通信故障的流量报文的具体报文长度,从而解决现有技术中,BFD检测机制无法检测报文长度不同于标准BFD保活报文长度的流量报文在转发过程中是否出现通信故障的问题。
本发明的其它特征和优点将在随后的说明书中阐述,并且,部分地从说明书中变得显而易见,或者通过实施本发明而了解。本发明的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。
附图说明
附图用来提供对本发明的进一步理解,并且构成说明书的一部分,与本发明的实施例一起用于解释本发明,并不构成对本发明的限制。在附图中:
图1是根据现有技术的BFD会话建立的流程图;
图2是根据现有技术的BFD故障检测的工作流程图;
图3是根据本发明实施例的基于双向转发检测BFD协议的通信故障检测方法的流程图;
图4是根据本发明实施例的采用折半发送方式发送BFD变长报文的示意图;
图5是根据本发明实施例的采用电梯发送方式发送BFD变长报文的示意图;
图6是根据本发明实施例的采用单向反复发送方式发送BFD变长报文的示意图;
图7是根据本发明优选实施例的通信故障检测方法的网络实施图;
图8是根据本发明优选实施例的通信故障检测方法的流程图;
图9是根据本发明实施例的基于BFD协议的通信故障检测系统的结构示意图。
具体实施方式
功能概述
根据本发明实施例提供的技术方案,通信设备按照预先设定的发送周期、发送规则以及报文长度变化梯度,发送报文长度不同的保活报文,以检测通信链路是否发生通信故障,并根据已经接收到的保活报文的报文长度,判断发生通信故障的流量报文的具体报文长度,其中,发送的保活报文基于BFD协议定义,保活报文的长度不小于标准BFD协议控制报文的长度。
在不冲突的情况下,本申请中的实施例及实施例中的特征可以相互组合。
以下结合附图对本发明的优选实施例进行说明,应当理解,此处所描述的优选实施例仅用于说明和解释本发明,并不用于限定本发明。
根据本发明实施例,首先提供了一种基于双向转发检测BFD协议的通信故障检测方法。
图3是根据本发明实施例的基于双向转发检测BFD协议的通信故障检测方法的流程图,如图3所示,该方法包括以下步骤(步骤302-步骤304):
步骤302、预先配置BFD协议的相互通信的两端设备中的本端设备(可以是两端设备中的任意一个设备),向对端设备发送基于BFD协议的多种保活报文,其中,发送的各种保活报文的报文长度不同且在预设长度范围内;
在具体实施过程中,两端设备是对等的,都具有发送报文功能和接收报文功能,因此,在对本发明实施例提供的技术方案的描述中,为了区分两端设备在通信过程中的角色,将发送报文的设备称为本端设备,接收报文的设备称为对端设备,应当理解的是,本端设备并不限于发送报文,也具有接收报文的功能,对端设备也不限于接收报文,同样具有发送报文的功能。
步骤304、对端设备在预先设定的超时间隔内没有接收到来自上述本端设备的保活报文,则确定对端设备与本端设备之间的通信链路发生通信故障,并根据已经接收到的保活报文的报文长度,确定发生通信故障的报文长度范围。
下面分别描述上述各步骤的处理细节。
(一)步骤302
对于上述步骤302,在具体实施过程中,待发送的多种保活报文基于标准BFD协议保活(keepalive)报文设置,并且每种保活报文中携带的数据信息要完整,因此所有种类的保活报文的报文长度不能小于标准BFD保活报文的报文长度,为了得到长于标准FD保活报文的报文,可以在标准报文后面(BFD报文是一种UDP报文)增加PAD信息来实现。进一步地,可以在PAD字段中填充相应的数值来实现BFD两端设备的信息交流与协商,方便两端及时获取对方的状态及其它所需要的信息。例如,可以通告本端本次发送报文长度与下个报文的报文长度等待信息等。同时,可以根据实际业务的数据流量特点,设定保活报文的长度范围,从而使得测试更具针对性,并保证测试的实时性。
对于上述步骤302,在具体实施过程中,可以根据实际业务应用的特点选择合理的长度变化梯度对多种保活报文进行设置,一般说来,如果变化梯度太大可能无法检测出两个梯度之间的故障;如果梯度太小,测试到故障处需要的时间可能较长,影响BFD的检测实时性。
在执行上述步骤302之前,需要采用标准BFD协议报文进行BFD协议会话的建立,并在建立会话的过程中,两端设备协商参数,该参数至少包括:保活报文的发送周期、每种保活报文发送方式(例如,每种保活报文连续发送多少次)、各种长度不同的保活报文的发送规律(例如,不同长度的保活报文的发送顺序)、长度变化梯度、用于判断故障的超时时间以及检测倍数因子等,其中,超时时间为发送周期的整数倍,并且设置检测倍数因子为该整数倍。
在具体的实施过程中,本端设备在向对端设备发送某种长度的保活报文时,需要发送多条该种保活报文,原因是如果只发送一条该种保活报文,无论对端设备在协商的超时时间内是否接收到该条保活报文,都不足以判断两端设备之间的通信链路是否发生故障,本端设备根据上述协商的每种保活报文发送方式,向对端设备连续多个某种长度的保活报文,并且发送的个数要超过上述检测倍数因子。
对于步骤302,在具体实施过程中,本端设备向对端设备发送多种长度不同的保活报文,需要按照上述协商的发送规律进行发送,按照不同的报文长度变化规律,本端设备可以采用以下几种发送方式向对端设备发送多种长度不同的保活报文:
方式一、折半发送方式
图4是根据本发明实施例的采用折半发送方式发送BFD变长报文的示意图,结合图4,采用折半发送方式主要可以包括以下步骤(步骤402-步骤404):
步骤402、对于待发送的所有种类的保活报文,按照长度排列,首先发送长度为最大值与最小值的平均值的保活报文,同时,该平均值将所有保活报文分成两个区间,然后再按照上述方法发送两个区间的平均值,如此循环发送平均值并划分下级区间,直至所有长度的保活报文发送完成;
例如,发送的保活报文的长度区间为52字节-60字节,梯度为2字节,则首先发送长度为56字节的保活报文,然后以52字节-56字节以及56字节-60字节为两个子区间,再发送子区间52字节-56字节的中间值,即发送长度为54字节的保活报文,由于子区间52字节-54字节之间只有一个长度值(即52字节)没有发送,因此,接下来发送长度为52字节的保活报文;然后,发送子区间56字节-60字节的中间值,即发送长度为58字节的保活报文,同样,接下来发送长度为60字节的保活报文。
步骤404、在本端设备发送完最后一种保活报文之后,返回步骤402,如此反复。
在具体实施过程中,可以根据实际业务应用的特点,调整长度为各级区间折半值的保活报文的发送顺序,例如,可以发送最高级区间的折半值后,发送两个二级区间的折半值;也可以发送最高级区间的折半值后,发送下半区的折半值,直至下半区的子区间的折半值都完成发送后,再发送上半区的折半值。
方式二、电梯发送方式
图5是根据本发明实施例的采用电梯发送方式发送BFD变长报文的示意图,结合图5,采用电梯发送方式主要可以包括以下步骤(步骤502-步骤504):
步骤502、本端设备从报文长度最小的保活报文开始,按照协商的长度变化梯度,依次发送报文长度递增的保活报文,直至发送报文长度最大的保活报文;
步骤504、本端设备在发送报文长度最大的保活报文之后,按照协商的长度变化梯度,依次发送报文长度递减的保活报文,直至发送报文长度最小的保活报文,返回步骤502,如此反复。
在具体的实施过程中,本端设备也可以从报文长度最大的保活报文开始,按照上述电梯发送方式向对端设备发送多种不同长度的保活报文。
方式三、单向反复发送方式
图6是根据本发明实施例的采用单向反复发送方式发送BFD变长报文的示意图,结合图6,采用单向反复发送方式主要可以包括以下步骤(步骤602-步骤604):
步骤602、本端设备从报文长度最小的保活报文开始,按照协商的长度变化梯度,依次发送报文长度递增的保活报文,直至发送报文长度最大的保活报文;
步骤604、本端设备在发送报文长度最大的保活报文之后,返回步骤602。
在具体的实施过程中,本端设备也可以从报文长度最大的保活报文开始,按照上述单向反复发送方式向对端设备发送多种不同长度的保活报文。
方式四、随机发送方式
本端设备在预设报文长度范围内,随机发送任意长度的保活报文。
(二)步骤304
对于上述步骤304,在具体的实施过程中,对端设备接收主端设备发送的多种报文长度不同的保活报文,并记录当前接收到的保活报文的长度,如果在协商的超时时间内没有接收到任何保活报文,则确定两端设备间的通信链路发生通信故障,并根据已经接收到的保活报文的长度,判断出该通信故障这对具体哪种长度的业务流量报文的长度范围,例如,协商的保活报文的长度范围是52至62,长度变化梯度为2,对端设备已经接收到长度分别为52、54、60以及62的保活报文,但是在协商的超时时间内没有接收到报文,于是判断出发生通信故障的报文长度范围是56至58。
在执行上述步骤304之后,对端设备通知FRR进行备用链路切换,并将检测到的通信故障以及该通信故障对应的报文长度范围上报至上层路由协议,使得上层路由协议能够根据对端设备商报的故障信息快速自愈,还可以将通信故障的报文长度通知给用户,方便用户使用其他工具检测并修复通信故障。
下面结合具体的优选实施例对上述基于双向转发检测BFD协议的通信故障检测方法进行详细介绍。
本发明优选实施例的硬件部分由两台支持BFD功能的路由器或三层交换机组成一对BFD邻居,软件部分通过BFD与OSPF路由的IP FRR联动实现。
图7是根据本发明优选实施例的通信故障检测方法的网络实施图,如图7所示,本实施例的主要组成部分主要包括支持BFD功能的路由器设备A、B,以及备用链路转发路由器C,A-B作为主链路,A-C作为备链路,A设备同时支持配置路由与BFD联动功能、支持IP FRR功能,当主链路断时能够快速切换到备链路。在A与B设备间配置BFD会话,主链路正常情况下,由接入网访问远端设备的数据包经过A时,通过A-B进行转发,同时由BFD会话来保证A-B链路的可达性,一旦A-B的链路出现问题,由BFD来通知策略路由完成路由的FRR切换,数据包经过A时,则由A-C来进行转发。BFD变长保活报文检测的核心功能是在A-B之间,通过抑制BFD状态机的切换,避免链路在A-B与A-C之间频繁切换。
图8是根据本发明优选实施例的通信故障检测方法的流程图,如图8所示,具体检测的处理步骤如下(步骤801-步骤807):
步骤801、为了实现A-B设备之间通过OSPF路由配置的BFD检测,首先需要在设备侧配置OSPF路由,并配置IP FRR生成路由的主备关系,其中A-B为主,A-C为备;其次需要配置OSPF使用BFD来检测链路状态,并配置BFD与FRR绑定;
步骤802、BFD状态协商,连接的两端已正常建立了BFD会话,此时两端以10毫秒的时间间隔个子向对端发送检测报文,检测超时时间为30毫秒,检测倍数因子为3;
步骤803、配置开启BFD变长保活报文检测功能,必要时,可以根据业务流量的特点(如长度范围比较固定)设置变长报文的长度范围以及每种长度保活报文的连续发送次数(大于检测倍数因子3)。配置完成后即可开始检测,此步骤并不限于在此执行,也可以在步骤802之前执行;
步骤804、设备A和B按照电梯发送方式发送变长的keepalive报文,如图7所示,可以看到B先发送X长度的报文,再发送Y长度的报文,再发送Z长度的报文,其中,X、Y以及Z的值不小于标准BFD协议报文的长度值;
步骤805、设备A能够正常接收到报文长度分别为X和Y的keepalive报文,但却无法正常接收到Z报文,此时经过设定的超时检测间隔(本例中为30ms),A端依然无法收到keepalive报文,就检测超时;
步骤806、A端检测到BFD邻居中断后,及时进行FRR切换,切换到A-C链路,由于这个过程极短(30ms),一般不会造成业务的中断;
步骤807、A端还需要将邻居中断通知到它为之服务的上层协议,使协议能够快速自愈;还可以将BFD侦测断链时的报文长度Z通告给用户,方便使用其它工具检测修复故障。
需要说明的是上述步骤804至步骤807中进描述了设备A检测到通信故障的情况,由于设备B与设备A是对等的,因此在实施过程中,也可以通过上述步骤804至步骤807的方法,由设备A向设备发送变长的keepalive报文,发送方式不限于电梯发送方式,设备B检测到通信故障,并上报通信故障以及通信故障对应的报文长度范围。
根据本发明实施例,还提供了一种基于BFD协议的通信故障检测系统。
图9是根据本发明实施例的基于BFD协议的通信故障检测系统的结构示意图,如图9所示,根据本发明实施例的基于BFD协议的通信故障检测系统包括:预先配置BFD协议的相互通信的两端设备,其中,本端设备91,用于向对端设备92发送基于BFD协议的多种保活报文,其中,各种保活报文的报文长度不同且在预设长度范围内;对端设备92,用于在预先设定的超时间隔内没有接收到来自本端设备91的保活报文的情况下,确定对端设备92与本端设备91之间的通信链路发生通信故障,并根据已经接收到的保活报文的报文长度,确定发生通信故障的报文长度范围。
在具体实施过程中,上述预先配置BFD协议的相互通信的两端设备是对等的,都具有发送保活报文、接收保活报文、判断通信故障以及判断通信故障的报文长度的功能。
如上所述,借助本发明实施例提供的技术方案,既可检测出一般的通信链路中断或者因路由失效的引起的通信故障,也可以检测诸如分片异常等原因导致某种长度报文在通信链路中出现转发异常的故障,并及时采用保护措施,防止业务中断,从而扩充了BFD的应用范围,增强了BFD应用的灵活度。
以上所述仅为本发明的优选实施例而已,并不用于限制本发明,对于本领域的技术人员来说,本发明可以有各种更改和变化。凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。
Claims (11)
1.一种基于双向转发检测BFD协议的通信故障检测方法,其特征在于,包括:
预先配置BFD协议的相互通信的两端设备中的本端设备,向对端设备发送基于BFD协议的多种保活报文,其中,各种保活报文的报文长度不同且在预设长度范围内;
所述对端设备在预先设定的超时时间内没有接收到来自所述本端设备的保活报文,则确定所述对端设备与所述本端设备之间的通信链路发生通信故障,并根据已经接收到的保活报文的报文长度,确定所述发生通信故障的报文长度范围。
2.根据权利要求1所述的方法,其特征在于,对于所述多种保活报文中的每种保活报文,所述本端设备按照以下方式向所述对端设备发送:
所述本端设备按照预设的发送周期向所述对端设备连续发送多个该种保活报文。
3.根据权利要求2所述的方法,其特征在于,所述本端设备向所述对端设备发送多种保活报文包括:
步骤301、所述本端设备依次发送报文长度为各级区间的保活报文的报文长度最大值与报文长度最小值的平均值的保活报文,其中,每级区间包括:由该级区间的报文长度最大值、该级区间的报文长度平均值以及该级区间的报文长度最小值确定的两个下级区间;
步骤302、在所述本端设备发送完最后一种保活报文之后,返回步骤301。
4.根据权利要求2所述的方法,其特征在于,所述本端设备则向所述对端设备发送多种保活报文包括:
步骤401、所述本端设备从报文长度最小的保活报文开始,依次发送报文长度递增的保活报文,直至发送报文长度最大的保活报文;
步骤402、所述本端设备在发送报文长度最大的保活报文之后,依次发送报文长度递减的保活报文,直至发送报文长度最小的保活报文,返回步骤401。
5.根据权利要求2所述的方法,其特征在于,所述本端设备则向所述对端设备发送多种保活报文包括:
步骤501、所述本端设备从报文长度最大的保活报文开始,依次发送报文长度递减的保活报文,直至发送报文长度最小的保活报文;
步骤502、所述本端设备在发送报文长度最小的保活报文之后,依次发送报文长度递增的保活报文,直至发送报文长度最大的保活报文,返回步骤501。
6.根据权利要求2所述的方法,其特征在于,所述本端设备则向所述对端设备发送多种保活报文包括:
步骤601、所述本端设备从报文长度最小的保活报文开始,依次发送报文长度递增的保活报文,直至发送报文长度最大的保活报文;
步骤602、所述本端设备在发送报文长度最大的保活报文之后,返回步骤601。
7.根据权利要求2所述的方法,其特征在于,所述本端设备则向所述对端设备发送多种保活报文包括:
步骤701、所述本端设备从报文长度最大的保活报文开始,依次发送报文长度递减的保活报文,直至发送报文长度最小的保活报文;
步骤702、所述本端设备在发送报文长度最小的保活报文之后,返回步骤701。
8.根据权利要求2所述的方法,其特征在于,所述本端设备则向所述对端设备发送多种保活报文包括:
所述本端设备在所述预设长度范围内,随机发送任意长度的保活报文。
9.根据权利要求1至8任一项所述的方法,其特征在于,所述预设长度范围包括:保活报文的长度不小于标准BFD协议报文的长度。
10.根据权利要求9所述的方法,其特征在于,所述多种保活报文的报文长度根据标准BFD协议报文的长度,按照预先设定的长度变化梯度递增设置。
11.一种基于BFD协议的通信故障检测系统,其特征在于,包括预先配置BFD协议的相互通信的两端设备,其中,
本端设备,用于向对端设备发送基于BFD协议的多种保活报文,其中,各种保活报文的报文长度不同且在预设长度范围内;
所述对端设备,用于在预先设定的超时间隔内没有接收到来自所述本端设备的保活报文的情况下,确定所述对端设备与所述本端设备之间的通信链路发生通信故障,并根据已经接收到的保活报文的报文长度,确定所述发生通信故障的报文长度范围。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN200910211384A CN101697626A (zh) | 2009-10-30 | 2009-10-30 | 基于双向转发检测协议的通信故障检测方法及系统 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN200910211384A CN101697626A (zh) | 2009-10-30 | 2009-10-30 | 基于双向转发检测协议的通信故障检测方法及系统 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN101697626A true CN101697626A (zh) | 2010-04-21 |
Family
ID=42142683
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN200910211384A Pending CN101697626A (zh) | 2009-10-30 | 2009-10-30 | 基于双向转发检测协议的通信故障检测方法及系统 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN101697626A (zh) |
Cited By (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102316013A (zh) * | 2010-07-01 | 2012-01-11 | 杭州华三通信技术有限公司 | 调整最大报文长度的方法及装置 |
CN102347855A (zh) * | 2011-07-21 | 2012-02-08 | 福建星网锐捷网络有限公司 | 双向转发检测实现方法、装置及网络设备 |
CN102769573A (zh) * | 2012-08-01 | 2012-11-07 | 杭州华三通信技术有限公司 | 借助bfd报文实现bgp保活信息发送的方法及路由设备 |
CN102821024A (zh) * | 2011-06-07 | 2012-12-12 | 中兴通讯股份有限公司 | 一种实现数据链路安全的方法、设备和系统 |
CN105591768A (zh) * | 2014-10-21 | 2016-05-18 | 中兴通讯股份有限公司 | 故障检测方法及装置 |
CN105812336A (zh) * | 2014-12-31 | 2016-07-27 | 北京华为数字技术有限公司 | 一种单向链路的数据处理方法和装置 |
CN106301835A (zh) * | 2015-05-25 | 2017-01-04 | 中兴通讯股份有限公司 | 一种bfd建链的方法及其装置、路由器 |
CN106535237A (zh) * | 2016-10-18 | 2017-03-22 | 福建三元达网络技术有限公司 | Lte容灾方法及其系统 |
CN108924044A (zh) * | 2018-06-22 | 2018-11-30 | 迈普通信技术股份有限公司 | 链路维持方法、pe设备及可读存储介质 |
CN109873719A (zh) * | 2019-02-03 | 2019-06-11 | 华为技术有限公司 | 一种故障检测方法及装置 |
CN110971459A (zh) * | 2019-11-29 | 2020-04-07 | 新华三半导体技术有限公司 | 会话故障检测方法、装置、终端设备及可读存储介质 |
WO2021164370A1 (zh) * | 2020-02-20 | 2021-08-26 | 中兴通讯股份有限公司 | 双向转发检测报文长度切换的方法、装置及存储介质 |
CN114172798A (zh) * | 2021-11-08 | 2022-03-11 | 烽火通信科技股份有限公司 | Bier网络故障检测方法、装置、设备及可读存储介质 |
CN114363342A (zh) * | 2021-12-30 | 2022-04-15 | 科大讯飞股份有限公司 | 故障收敛方法及其相关装置和负载均衡集群 |
CN115086217A (zh) * | 2021-03-10 | 2022-09-20 | 中国移动通信集团四川有限公司 | 链路质量的动态检测方法及系统 |
CN115378844A (zh) * | 2022-07-11 | 2022-11-22 | 天翼云科技有限公司 | 一种网络链路的故障检测方法及装置 |
US12101251B2 (en) | 2020-02-20 | 2024-09-24 | Zte Corporation | Method and apparatus for switching length of bidirectional forwarding detection packet and storage medium |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101252476A (zh) * | 2008-03-18 | 2008-08-27 | 华为技术有限公司 | 一种故障检测的方法及装置 |
US20080225731A1 (en) * | 2007-03-14 | 2008-09-18 | Takuro Mori | Network system, node device and management server |
-
2009
- 2009-10-30 CN CN200910211384A patent/CN101697626A/zh active Pending
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080225731A1 (en) * | 2007-03-14 | 2008-09-18 | Takuro Mori | Network system, node device and management server |
CN101252476A (zh) * | 2008-03-18 | 2008-08-27 | 华为技术有限公司 | 一种故障检测的方法及装置 |
Cited By (28)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102316013A (zh) * | 2010-07-01 | 2012-01-11 | 杭州华三通信技术有限公司 | 调整最大报文长度的方法及装置 |
CN102821024A (zh) * | 2011-06-07 | 2012-12-12 | 中兴通讯股份有限公司 | 一种实现数据链路安全的方法、设备和系统 |
CN102821024B (zh) * | 2011-06-07 | 2017-05-10 | 中兴通讯股份有限公司 | 一种实现数据链路安全的方法、设备和系统 |
CN102347855A (zh) * | 2011-07-21 | 2012-02-08 | 福建星网锐捷网络有限公司 | 双向转发检测实现方法、装置及网络设备 |
CN102769573A (zh) * | 2012-08-01 | 2012-11-07 | 杭州华三通信技术有限公司 | 借助bfd报文实现bgp保活信息发送的方法及路由设备 |
CN102769573B (zh) * | 2012-08-01 | 2014-11-05 | 杭州华三通信技术有限公司 | 借助bfd报文实现bgp保活信息发送的方法及路由设备 |
CN105591768B (zh) * | 2014-10-21 | 2019-11-29 | 中兴通讯股份有限公司 | 故障检测方法及装置 |
CN105591768A (zh) * | 2014-10-21 | 2016-05-18 | 中兴通讯股份有限公司 | 故障检测方法及装置 |
CN105812336A (zh) * | 2014-12-31 | 2016-07-27 | 北京华为数字技术有限公司 | 一种单向链路的数据处理方法和装置 |
CN105812336B (zh) * | 2014-12-31 | 2019-01-25 | 北京华为数字技术有限公司 | 一种单向链路的数据处理方法和装置 |
CN106301835A (zh) * | 2015-05-25 | 2017-01-04 | 中兴通讯股份有限公司 | 一种bfd建链的方法及其装置、路由器 |
CN106301835B (zh) * | 2015-05-25 | 2020-03-13 | 中兴通讯股份有限公司 | 一种bfd建链的方法及其装置、路由器 |
CN106535237A (zh) * | 2016-10-18 | 2017-03-22 | 福建三元达网络技术有限公司 | Lte容灾方法及其系统 |
CN106535237B (zh) * | 2016-10-18 | 2020-03-27 | 安科讯(福建)科技有限公司 | Lte容灾方法及其系统 |
CN108924044B (zh) * | 2018-06-22 | 2020-12-11 | 迈普通信技术股份有限公司 | 链路维持方法、pe设备及可读存储介质 |
CN108924044A (zh) * | 2018-06-22 | 2018-11-30 | 迈普通信技术股份有限公司 | 链路维持方法、pe设备及可读存储介质 |
CN109873719B (zh) * | 2019-02-03 | 2019-12-31 | 华为技术有限公司 | 一种故障检测方法及装置 |
CN109873719A (zh) * | 2019-02-03 | 2019-06-11 | 华为技术有限公司 | 一种故障检测方法及装置 |
CN110971459A (zh) * | 2019-11-29 | 2020-04-07 | 新华三半导体技术有限公司 | 会话故障检测方法、装置、终端设备及可读存储介质 |
CN110971459B (zh) * | 2019-11-29 | 2020-07-14 | 新华三半导体技术有限公司 | 会话故障检测方法、装置、终端设备及可读存储介质 |
WO2021164370A1 (zh) * | 2020-02-20 | 2021-08-26 | 中兴通讯股份有限公司 | 双向转发检测报文长度切换的方法、装置及存储介质 |
US12101251B2 (en) | 2020-02-20 | 2024-09-24 | Zte Corporation | Method and apparatus for switching length of bidirectional forwarding detection packet and storage medium |
CN115086217A (zh) * | 2021-03-10 | 2022-09-20 | 中国移动通信集团四川有限公司 | 链路质量的动态检测方法及系统 |
CN114172798A (zh) * | 2021-11-08 | 2022-03-11 | 烽火通信科技股份有限公司 | Bier网络故障检测方法、装置、设备及可读存储介质 |
CN114172798B (zh) * | 2021-11-08 | 2023-10-24 | 烽火通信科技股份有限公司 | Bier网络故障检测方法、装置、设备及可读存储介质 |
CN114363342A (zh) * | 2021-12-30 | 2022-04-15 | 科大讯飞股份有限公司 | 故障收敛方法及其相关装置和负载均衡集群 |
CN115378844A (zh) * | 2022-07-11 | 2022-11-22 | 天翼云科技有限公司 | 一种网络链路的故障检测方法及装置 |
CN115378844B (zh) * | 2022-07-11 | 2023-06-23 | 天翼云科技有限公司 | 一种网络链路的故障检测方法及装置 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN101697626A (zh) | 基于双向转发检测协议的通信故障检测方法及系统 | |
CN100459601C (zh) | 网络中主备网关设备的实现方法 | |
CN102007729B (zh) | 连接性故障管理业务指示扩展 | |
CN101170459B (zh) | 基于双向转发链路进行故障检测与链路恢复的方法 | |
CN101483592B (zh) | 一种抑制双向转发检测链路振荡的方法及装置 | |
CN101427499B (zh) | 多节点aps控制协议信令的系统和方法 | |
CN103001799B (zh) | 基于链状网络的冗余实现方法及节点 | |
CN101652963B (zh) | 重配通信网络的方法 | |
CN101340380B (zh) | 一种实现主备倒换中双向转发检测包无中断转发的方法和装置 | |
WO2011100882A1 (zh) | 链路检测方法、装置和系统 | |
CN102780635B (zh) | 基于trill网络实现保护倒换的方法、tor交换机及系统 | |
CN101247270A (zh) | 一种实现双向转发检测的系统及方法 | |
CN101132320A (zh) | 检测接口故障的方法及网络节点设备 | |
WO2012068996A1 (zh) | 链路状态检测方法和装置 | |
CN101465859A (zh) | 一种触发主备用接口板倒换的方法及装置 | |
CN101197733A (zh) | 网络连通性的自动检测方法及装置 | |
CN102780615B (zh) | 一种链路备份方法和路由转发设备 | |
CN101800774A (zh) | 一种接入环保护方法及接入环保护网络 | |
CN102255757A (zh) | 一种链路切换方法及其装置 | |
CN101465782B (zh) | Rrpp环的优化链路切换方法、系统和网络节点 | |
WO2011095101A1 (zh) | 一种分组传送网络的线性1:n保护方法、装置和系统 | |
CN103490951A (zh) | 基于bfd的多跳链路中双向转发检测方法 | |
KR20120134466A (ko) | 메쉬 네트워크 노드 및 그의 데이터 전송 방법 | |
CN107968747A (zh) | 一种路径调整管理方法及装置、通信系统 | |
RU2304849C2 (ru) | Способ реализации передачи состояния линии связи в сети |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C12 | Rejection of a patent application after its publication | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20100421 |