CN1815970A - 一种检测网络链路故障并定位故障的方法 - Google Patents
一种检测网络链路故障并定位故障的方法 Download PDFInfo
- Publication number
- CN1815970A CN1815970A CN 200510005219 CN200510005219A CN1815970A CN 1815970 A CN1815970 A CN 1815970A CN 200510005219 CN200510005219 CN 200510005219 CN 200510005219 A CN200510005219 A CN 200510005219A CN 1815970 A CN1815970 A CN 1815970A
- Authority
- CN
- China
- Prior art keywords
- bag
- node
- link
- detection
- detects
- 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.)
- Granted
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
在对网络链路检测时,在链路的源节点连续顺序发送携带序列号的检测包,检测包通过链路的中间节点转发到目的节点,所述各检测包的序列号符合预定顺序;链路的非源节点对所接收检测包的序列号进行顺序识别,以此判断接收检测包的状况,并对检测包的接收状况进行计数统计;链路上的节点向网管设备上报计数信息和对应链路的标识;网管设备根据各节点上报的计数信息判断节点接收检测包的状况,并以此判断对应的链路是否发生丢包故障,如果发生丢包,则进一步根据各个节点的计数信息的差别定位链路的故障点。
Description
技术领域
本发明涉及网络链路故障检测和定位技术,尤其涉及一种在下一代网络(NGN)中检测网络链路故障并定位故障的方法。
背景技术
随着通信技术的发展,下一代网络(NGN)技术正在蓬勃开展,语音、图像、视频、数据都通过IP来承载,已经成为一个大的趋势。但是在目前的NGN中,如何保障数据传送质量、在数据传送出现问题时,例如电话语音不清晰,如何快速地检测链路故障,并进行故障定位,成为了一个亟待解决的重要问题。
为了解决上述问题,当前提出了以下多种技术方案:
现有技术一:Ping和路由跟踪(Trace Route)技术。
ping是一种验证通道和设备是否正常的技术。图1为NGN中一种网络链路的示意图。以图1为例,假定节点A至节点E的IP地址分别为Ipa至IPe,检测节点A到节点E间链路故障时,要从节点A ping节点E,即从节点A发出一个因特网控制包协议(ICMP)包,到达节点E后,节点E会向回发送一个包。在节点B、C、D上仅仅对这种包进行转发。
Ping只能检测出某两个节点之间的链路是否有故障,但无法对故障的发生点进行定位。因此,业界通过Trace Route技术对故障进行定位。以图1为例,TraceRoute技术利用数据包中的生命周期TTL(Time to Live)字段对包进行跳数的控制。TTL的取值表示该包可以被发送的跳数。例如,对节点A到节点E之间的链路进行测试并定位故障,节点A发出的初始检测包中TTL取值为1,则该数据包发送到节点B时,节点B将该数据包丢弃,并返回一个ICMP超时包,如果节点A收到该超时包,则认为A和B之间的链路无故障;接着发送第二个数据包,其中的TTL取值为2,该数据包到达节点C时,节点C将该数据包丢弃,并向节点A返回一个ICMP超时包,如果节点A收到该ICMP超时包,则认为节点B到节点C之间的链路无故障;依次类推,直到节点A收到节点E返回的ICMP超时包,则节点A和节点E之间的链路无故障。一旦某段发生故障,例如节点C和节点D之间发生故障,则节点A能收到节点C返回的ICMP超时包,而不能收到节点D返回的包,由此可以判定节点A和节点E之间的链路产生故障,且将故障点定位在节点C和节点D之间。
在实际应用中,经常用Ping计数来判断链路通断,用Trace Route来定位故障点。
现有技术一存在如下缺点:
1、链路故障中,存在一种大流量但偶尔丢包的情况,即:链路中数据包的流量很大,但只丢失少量的数据包。要检测这种情况下的链路故障,需要快速地发送测试数据包,使链路中的数据包流量达到很大,由此才能检测出偶尔丢包的故障,但是由于ping包需通过控制平面发送,控制平面较低的处理速度导致ping包的发送速率不能太高;因此对于上述大流量但偶尔丢包的情况很难检测出来。
2、ping包检测的是双向链路,即要有来有回,当故障发生时,无法判断是去的链路故障,还是回来的链路故障;通过Trace Route来定位故障点时,也会有同样问题。对于一些应用,只有单向链路检测需求时,Ping无法完成这种检测,Trace Route也无法完成故障点定位。
3、Ping和Trace Route包容易造成误报,图2为Ping和Trace Route包的传输路径示意图。如图2所示,Ping和Trace Route包为点到点的检测包,该包对于设备都是由起始点,例如节点A的控制层面发起,再通过起始点的数据平面转发到对端,即终点,例如节点E的数据平面,然后再送给终点的控制平面。当控制平面出现问题时,虽然数据平面没有问题,也同样会导致Ping失败,从而报告故障。但是,对于实际的业务链路,仅仅走数据平面,和控制平面无关,因此会造成故障误报。
另外,Ping由于是控制平面发起,而控制平面一般有比较繁重的计算和管理任务在运行,所以不可能长时间的快速发送ping检测包。而且控制平面的通道带宽为了防止对设备的攻击,一般都进行了限制,大流量的Ping包会被丢弃一部分,造成检测不准确。
4、在被测链路中间有多条路可达时,如图3所示,两节点间的链路存在等值多路径(ECMP,Equal Cost Multi Path)时,Ping包只能走其中一条链路,存在检测的链路和实际数据走的链路不一致时,导致检测结果无效。
5、Trace Route的发包速度相对Ping的发包速度较慢,可能Ping检测出有偶尔丢包,但是Trace route无法检测出来,从而无法进行定位;
6、如果要使用快速的Trace Route,需要发送几倍的包才能检测到故障,对带宽耗费较大。
现有技术二:双向转发检测(BFD,Bidirectional Forwarding Detection)技术。
BFD是一种Hello包机制,此处仍以图1所示检测节点A和节点E之间链路说明BFD技术。
当需要检测节点A和节点E之间的链路状态时,A在一定时间段内给E发送一定数量的hello检测包,E在该段时间内接收该hello检测包,如果在该段时间内连续丢失一定数量的包,则认为节点A和节点E之间的链路故障。例如节点A向节点E发送1000个hello包,节点E连续50次没有收到包,则认为链路故障。如果节点支持,该种技术还可以从节点A发出hello包,节点E不进行检测,仅仅将这种包进行环回,再回送给节点A,由节点A来自己检测包是否丢失,来决定链路是否可用。另外,节点A和节点E之间可以通过协商,仅仅在需要时,对链路进行检测。
现有技术二存在以下缺点:
1、BFD是一种通过判断是否连续丢预定个数的数据包,进而判断链路是否可用的机制。但是对于链路为可用、只是偶尔间断丢包的情况,则无法实现检测和上报。
2、BFD是一种点到点检测的机制,无法实现对链路故障点的快速定位。
3、对于AE之间有多条路径时,检测包只能走其中一条,可能与实际数据包所走路径不同,因此产生误报。即没有解决存在ECMP时误报故障的问题。
现有技术三:国际电信联盟(ITU)提出的多协议标签交换(MPLS)可操作可维护性(OAM)技术。
此处仍以图1为例对MPLS OAM进行说明,由于MPLS的标签交换路径(LSP,Lable Switching Path)是一段接一段建立的,并且LSP可以嵌套,因此假定AB、BC、CD、DE、AE之间分别建立了外层隧道LSPab、LSPbc、LSPcd、LSPde,以及内层隧道LSPae,LSPae的隧道标签将嵌套在其它隧道的标签之内,即从A到E发送的包,内层标签为LSPae的标签,外层标签为各段外层隧道的标签,外层标签到每一段将更换为新的标签。
由于有标签嵌套机制,ITUT的方案中通过前向故障指示(FDI,ForwardDefect Indicator)机制检测定位故障。以图1所示为例,在AB、BC、CD、DE、AE的链路LSP上,都需要运行MPLS OAM机制的Hello包,ITUT中称这种包为连通性检测(CV,Connectivity Verification)包或者快速故障检测(FFD,FastFailure Detection)包。OAM技术也是通过两点之间发送Hello包的方式来检测链路的一种机制,与BFD类似,当某条外层隧道链路在一段时间内连续丢包达到预定数量后,则判定该链路不可用。假定LSPbc上的OAM发现BC之间的链路不可用,则节点B向网管设备上报故障报告,并自动向节点E发送一FDI包,用于报告链路LSPbc不可用,节点E判定所有承载在链路LSPbc上的内存LSP隧道链路都不可用。网管根据节点B上报的故障报告确定故障点为B、C之间。另外,FDI机制还可以用于防止告警风暴。
现有技术三存在以下缺点:
1、仅对MPLS网络有效,对IP网络无效。而NGN网络既包括MPLS网络又包括IP网络,因此对于IP网络上承载的NGN业务,无法实现故障检测。
2、与上述BFD的方案一样,也是一种通过判断连续丢包,进而判断链路是否可用的检测机制,对于单位时间内偶尔间隔丢包的情况,无法实现故障定位。
3、没有解决ECMP时误报故障的问题。
4、由于采用FDI机制,对于故障的定位依赖于外层LSP发送的FDI包,当外层LSP没有运行OAM机制时,则对链路中的节点无法进行故障定位。然而,如果需要对故障进行定位,则需要全网各个节点都运行该OAM机制,而OAM机制中的检测包为周期性发送,从使用该功能后一直在发送,这种包在LSP的每一层隧道中都要存在,所以包数量很多,要占用大量带宽。因此资源开销很大。
发明内容
本发明的主要目的是提供一种检测网络链路故障并定位故障的方法,可检测出网络链路偶尔丢包的故障,并对故障点进行高效、准确的定位。
为了实现上述发明目的,本发明的主要技术方案为:
一种检测网络链路故障并定位故障的方法,其特征在于,该方法在对网络链路检测时,包括:
A、在链路的源节点连续顺序发送携带序列号的检测包,检测包通过链路的中间节点转发到目的节点,所述各检测包的序列号符合预定顺序;
B、链路的非源节点对所接收检测包的序列号进行顺序识别,以此判断接收检测包的状况,并对检测包的接收状况进行计数统计;
C、链路上的节点向网管设备上报计数信息和对应链路的标识;
D、网管设备根据各节点上报的计数信息判断节点接收检测包的状况,并以此判断对应的链路是否发生丢包故障,如果发生丢包,则进一步根据各个节点的计数信息的差别定位链路的故障点。
优选的,所述被测链路存在等值多路径,所述检测包在转发过程中,等值多路径的起始节点对收到的检测包进行复制,并添加路径编号,再将复制的检测包分别发送到各条等值路径中。
优选的,所述检测包的格式符合节点数据平面的处理格式,所述节点利用自身的数据平面对检测包进行处理。
优选的,所述被测链路为纯IP网链路,所述检测包的格式为IP包格式,所述IP包格式中的标志字段用于存放所述序列号,协议字段用于标识检测包。
优选的,所述的链路标识至少包括源/目的地址。
优选的,所述被测链路包括IP网段和MPLS网段;
在步骤A至步骤D中,将MPLS网段整体作为被测链路的一跳进行检测并定位故障,且所述检测包的格式为IP包格式;
在步骤D之后,进一步包括:
E、判断故障点是否在MPLS网段,如果是,则执行步骤F;否则,结束流程;
F、利用携带序列号的、符合MPLS包格式的检测包分别逐级对所述MPLS网段的每一段隧道进行故障检测,根据检测结果定位故障点。
优选的,所述对MPLS网段隧道进行故障检测的具体过程为:
a、所述隧道的起始节点向终止节点连续顺序发送携带序列号的检测包,所述各检测包的序列号符合预定顺序;
b、隧道的终止节点对所接收检测包的序列号进行顺序识别,以此判断接收检测包的状况,并对检测包的接收状况进行计数统计;
c、隧道的起始节点和或终止节点向网管设备上报计数信息和对应的隧道标识;
d、网管设备根据节点上报的计数信息判断隧道终止节点接收检测包的状况,并以此判断对应的隧道否发生丢包故障。
优选的,所述隧道为标签交换路径LSP。
优选的,所述节点接收检测包的状况为:检测包的丢包状况;
且所述节点对所接收检测包的序列号进行识别、判断接收检测包的状况、并进行计数统计的具体包括:
判断接收的当前检测包序列号与前一个检测包序列号是否符合正确的相邻顺序,如果是,则判定没有丢包,记录当前检测包的序列号;否则,判定有丢包,并对丢包数进行计数统计。
优选的,所述步骤B中,如果当前检测包序列号与前一个检测包序列号不符合正确的相邻顺序,则进一步包括:
如果当前检测包序列号与所记录的前一个检测包序列号的顺序正确,但序列号不相邻,则判定有丢包,记录当前检测包的序列号,并依照当前接收的检测包序列号与前一检测包序列号的差值对丢包数进行计数统计;
如果当前检测包序列号与前一个检测包序列号的顺序不正确,则判定检测包乱序,将当前检测包丢弃。
优选的,所述节点接收检测包的状况为:节点接收正确的检测包的状态;
且所述节点对所接收检测包的序列号进行识别、判断接收检测包的状况、并进行计数统计的具体包括:
判断接收的当前检测包序列号与前一个检测包序列号是否符合正确的相邻顺序,如果是,则判定当前检测包为正确的检测包,对所接收的正确检测包的数目进行计数统计,记录当前检测包的序列号;否则,判定当前检测包为错误的检测包。
本发明的有益效果包括:
1、由于本发明在检测链路时,利用携带序列号的检测包进行检测,链路中的节点根据序列号的顺序判断是否发生丢包故障,并对丢包进行计数,因此既使偶尔丢包也可在计数中反映出来;而且,本发明不通过控制平面发送检测包,只通过数据平面发送或转发,而数据平面的发送速率很高,因此可使链路中数据包流量达到很大值,因此可以检测出大流量但偶尔丢包的情况。
2、由于本发明各节点将接收正确包和或丢包的计数情况上报给网管设备,因此网管设备可根据各节点上报的计数差异高效、准确地定位故障点。
3、对于存在ECMP的链路,本发明的检测包可以复制为多份,分别在ECMP的各个分路径中转发,因此可以检测出ECMP的故障。
4、由于本发明不通过控制平面发送检测包,只通过数据平面发送或转发,因此可避免由于控制平面故障而引起误报故障的问题。
5、由于本发明所述检测包的走向为单向,因此可以检测单向链路;对于双向链路,也可分别准确检测两个方向的链路故障。
6、由于本发明利用检测包的序列号进行乱序辨别,因此还可进一步检测出乱序丢包的故障类型。
7、本发明在IP网络中使用IP检测包,在MPLS网络中使用符合MPLS格式的MPLS检测包,并有分别对应相应的检测机制,因此可以实现对既包括MPLS网段又包括IP网段的NGN网络的故障检测定位。
8、对于MPLS网络,本发明首先可以通过IP包对隧道是否丢包进行检测,然后逐级对不同层LSP通过序列号进行检测。以定位出丢包的位置。因为是对特定的LSP进行检测,所以带宽开销比较小。
9、由于本发明的检测不是周期性进行,而是由网管设备发起,在根据序列号检测到丢包以后,不再使用FDI的类似机制向上层标签报警,而是由节点本地进行告警记录,主动定时上报网管设备或者由网管设备定时查询记录结果,所以本发明也可以避免ITUT MPLS OAM中的告警风暴问题。
附图说明
图1为NGN中一种网络链路的示意图;
图2为Ping和Trace Route包的传输路径示意图;
图3为网络链路中存在等值多路径时的示意图;
图4为本发明第一实施例所述检测故障并定位的方法流程图;
图5为现有RFC791公开的IP包的报头结构图;
图6为本发明第一实施例所述IP检测包的结构图;
图7为网络链路中存在多重等值多路径时的示意图;
图8为IP网络和MPLS网络混合时的一种组网示意图;
图9为本发明第三实施例检测故障并定位的方法流程图。
具体实施方式
下面结合附图和具体实施例进一步说明本发明的实施方法。
本发明的核心思想为:在对网络链路检测时,在链路的源节点连续顺序发送携带序列号的检测包,检测包通过链路的中间节点转发到目的节点,所述各检测包的序列号符合预定顺序;链路的非源节点对所接收检测包的序列号进行顺序识别,以此判断接收检测包的状况,并对检测包的接收状况进行计数统计;链路上的节点向网管设备上报计数信息和对应链路的标识;网管设备根据各节点上报的计数信息判断节点接收检测包的状况,并以此判断对应的链路是否发生丢包故障,如果发生丢包,则进一步根据各个节点的计数信息的差别定位链路的故障点。
由于NGN网络中主要为IP网络,因此本发明的第一实施例主要说明在纯IP网络检测故障并定位的方法,此处以检测图1所示节点A和节点E之间的链路为例进行说明。
图4为本发明第一实施例所述检测故障并定位的方法流程图,如图4所示,该方法包括:
步骤401、从节点A向节点E连续发送一系列的IP检测包,这些IP检测包中携带序列号和源/目的节点地址(Vip),此处的源地址为节点A的地址,目的地址为节点E的地址;所述连续的IP检测包的序列号也为连续的,即按照预定的顺序或规律编号,例如第一个检测包的序列号为1,第二个为2,第三个为3,依次类推。
节点A开始发送检测包后,记录所发送IP检测包的源/目的IP地址,并且对所发送的、与源/目的IP地址对应的IP检测包进行计数。例如,从节点A到节点E共发送了1000个IP检测包,则与节点A/节点E地址对应的计数为1000。
步骤402、当链路的中间节点和目的节点每收到IP包后,该节点的数据平面分析该IP包,判断该IP包是否为IP检测包,如果是,则执行步骤403;否则,利用现有的IP转发技术对该IP包进行转发或处理,并结束流程。
在检测链路的非源节点,即节点B、C、D、E中预先设置用于记录前一个IP检测包序列号的存储单元,在没有收到任何检测包之前该存储单元中的序列号为序列号的初始值,此处设为0。
步骤403、读取该IP检测包标志字段中的序列号和源/目的地址,根据源/目的地址可以确定所检测的是哪两个节点间的链路;对序列号进行顺序识别,即判断当前IP检测包序列号与所记录的前一个IP检测包序列号是否符合正确的相邻顺序,如果是,判定没有丢包,则该IP检测包为正确的IP检测包,更新所述存储单元中的记录为当前所接收的IP检测包的序列号;否则,当前检测包为错误的检测包,且判定有丢包,并按照当前检测包序列号与前一检测包序列号的差值对丢包数进行计数统计。所述正确IP检测包的计数和丢包的计数与IP检测包中的源/目的地址对应。
此处,所述当前IP检测包序列号与所记录的前一个IP检测包序列号是否符合正确的相邻顺序,有三种情况:
如果当前IP检测包序列号与所记录的前一个IP检测包序列号的顺序正确,且序列号相邻,例如:前一IP检测包序列号为2,当前IP检测包序列号为3,则符合正确的相邻顺序,此时该IP检测包为正确接收的IP检测包,更新所述存储单元中的记录为当前所接收的IP检测包的序列号;如果当前节点为中间节点,还要向下一跳节点转发该IP检测包。
如果当前IP检测包序列号与所记录的前一个IP检测包序列号的顺序正确,但序列号不相邻,例如:前一IP检测包序列号为2,当前IP检测包序列号为6,则不符合正确的相邻顺序,此种情况说明有丢包,且丢包的数目为3,即序列号为3、4、5的IP检测包丢失,此时需将丢包的计数加3。由于序列号的顺序正确,所以此时也需更新所述存储单元中的记录为当前所接收的IP检测包的序列号,如果当前节点为中间节点,还要向下一跳节点转发该IP检测包。
如果当前IP检测包序列号与所记录的前一个IP检测包序列号的顺序不正确,例如:前一IP检测包序列号为6,当前IP检测包序列号为3,则不符合正确的相邻顺序,此种情况说明IP检测包有乱序,鉴于发生乱序之前已经对丢包进行了计数,例如在收到序列号为6的IP检测包时,由于没有收到序列号为3的IP检测包,因此已经认为序列号为3的IP检测包丢失,并对该丢包进行了计数,所以收到序列号为3的检测包时,虽判定有丢包,但不再对丢包计数,并不需更新所述存储单元中记录的序列号,而是将当前IP检测包丢弃。另外,作为本发明的一种扩展,此种情况时,可对乱序进行计数,用于确定故障类型为乱序故障。或者,也可对于乱序的包不丢弃,中间节点可继续转发该乱序包。此时丢包数量在数值上应该大于或者等于乱序包的数量。因为对所有的乱序包,首先会被作为丢包计数,即根据收到的序列号得到丢包数量。节点每次要记录当前收到的最大的序列号,来保证对乱序包不多次计数。例如,某一时刻节点收到了序列号为100的IP检测包,下一个收到的是序列号为150的IP检测包,此时设备上的丢包数量会增加49,同时节点记录150这个序列号,后面如果再有101~149之间的序列号的包到来,就对乱序计数器计数,同时不能用新收到包的序列号作为当前设备中保存的序列号。直到有大于150序列号的包来到,再进行记录。
步骤404、检测链路上的各个节点向网管设备上报自身的计数信息和对应的链路标识。
步骤404中,检测链路上的各个节点可定时向网管设备上报计数信息和对应的链路标识,例如在开始检测后每5分钟上报一次;或者,网管设备主动向检测节点发送查询指令,收到查询指令的检测节点再向网管设备发送计数信息和对应的链路标识。
所述源节点A上报的计数信息包括:所发送的IP检测包数,对应的链路标识包括:所述IP检测包的源/目的地址(Vip)、发送所述IP检测包的接口号(Vout)、以及节点号。
所述中间节点和目的节点B、C、D、E上报的计数信息包括:丢包数(Vcd),如果对乱序进行了计数,则还可进一步包括乱序数(Vo),对应的链路标识包括:所述IP检测包的源/目的地址、接收所述IP检测包的接口号(Vin)、发送所述IP检测包的接口号(Vout)、以及节点号。
为了保证正确率,本第一实施例在源节点A停止发送IP检测包后,各节点才向上报计数信息和对应的链路标识。如果在发送IP检测包的过程中上报,由于各个节点上报的时间有差异,因而无法准确判断丢包数量和丢包点。
步骤405、网管设备根据各节点上报的计数信息和对应链路标识判断该链路是否故障,如果故障,并在该链路上定位故障点。
网管设备中预先保存被测网络的拓扑图,包括与各个接口的连接关系有关的数据库。当网管设备收到各个节点上报的计数和对应链路标识后,则建立一个表项,该表项是以Vip为索引的Hash表,该Hash表中记录各个节点对应Vip的相关计数信息、链路标识和节点号。网管设备根据保存的拓扑信息和节点上报的信息,可以得出IP检测包流量的先后关系,在流量停止发送后,可以根据丢包的结果,根据先后顺序可以定位出在哪一段链路有包丢失。
具体的判断过程可以为:如果上报与Vip对应的丢包数都为0,则判定当前测试的源节点A与目的节点E间的链路正常;如果上报的丢包数不都为0,则说明当前测试链路上存在丢包故障,并进一步判断下游节点的丢包数是否大于其上一跳节点的丢包数,如果是,则判定该下游节点与其上一跳节点间存丢包在故障,从而对故障进行准确的定位。进一步地,如果上报信息中包括乱序数,则网管设备还判断个节点的乱序数是否为0,如果某一节点的乱序数不为0,则判定该节点与其上一跳节点间存在乱序故障。
例如,与节点A/节点E地址对应的计数信息为:
节点A上报的计数信息为:发送的IP检测包为1000个;
节点B上报的计数信息为:丢包0个;乱序0;
节点C上报的计数信息为:丢包10个;乱序0;
节点D上报的计数信息为:丢包20个;乱序5;
节点E上报的计数信息为:丢包20个;乱序0。
网管设备根据网络拓扑结构和上述数据,可以自动判断出在节点B和节点C之间丢包10个,在节点C和节点D之间丢包10个,并且节点C和节点D之间发生乱序5次,其余网络没有丢包,因此可以定位故障链路区段。另外,根据上报的链路标识,还可进一步判断具体故障发生在节点中的哪个接口之间。
另外,在步骤403中,在计数过程中,所述非源节点也可以只对接收到的正确的IP检测包进行计数;并在步骤404中,各个非源节点只将收到的正确IP检测包数(Vcc)上报给网管设备,网管设备根据每个节点的Vcc的差值计算各个节点间丢包的数量,以此确定是否有丢包,并进一步对故障点进行定位。通过这种方式,同样可以达到检测定位故障的目的。
例如,与节点A/节点E地址对应的计数信息为:
节点A上报的计数信息为:发送的IP检测包为1000个;
节点B上报的计数信息为:收到正确的IP检测包1000个;
节点C上报的计数信息为:收到正确的IP检测包990个;
节点D上报的计数信息为:收到正确的IP检测包980个;
节点E上报的计数信息为:收到正确的IP检测包980个。
网管设备根据网络拓扑结构和上述数据,可以计算出节点B和节点C之间丢包10个,在节点C和节点D之间丢包10个,其余网络没有丢包,因此可以定位故障链路区段。另外,根据上报的链路标识,还可进一步判断具体故障发生在节点中的哪个接口之间。
另外,上述的检测过程可通过两种方式发起:
第一种是由网管设备发起,网管设备要对某两节点间的链路进行检测时,需通知源节点和目的节点启动检测,即:首先给链路中的所有非源节点发送启动命令,使这些节点处于准备接收检测包的状态;接着,再向源节点发送启动命令,源节点收到启动命令后,开始发送检测包。
第二种是通过待检测链路的源节点发起,此种方式下,非源节点都默认启动,处于准备接收检测包的状态,需要检测链路时,由源节点开始发送检测包。
为了避免转发平面对检测包的过多分析,导致影响其它正常业务的转发。因此本发明所用检测包的格式相对很简单,使得节点的数据平面,本第一实施例为IP层,既可完全对检测包分析处理,而不必需要高层控制平面的参与,从而提高处理效率。本第一实施例中,检测包采用IP包的格式进行组织。
图5为现有RFC791公开的IP包的报头结构图,如图3所示,在IP报头中有一个协议字段,协议字段的定义参见RFC790,主要用于定义使用IP层服务的较高层协议,不同的较高层协议对应该字段的不同取值,其中255为保留取值。
图6为本第一实施例所述IP检测包的结构图。如图6所示,该IP检测包的头部格式与IP包的头部相同,只是其中的标志(Indentification)字段的作用与IP报头不同,在IP报头中,标志字段用于存放IP包的序号,对于IP检测包,该标志字段用于存放IP检测包的序列号。IP检测包头部中的协议字段取值也与IP报头不同,在该IP检测包中该协议字段默认取值为255,表示该IP包为IP检测包。本实施例中采用该字段取值255来标识该IP包为检测包,当节点收到IP包后,判断IP包中的协议字段是否为255,如果是,则判定该IP包为IP检测包。在IP报头之后,还进一步包括一个OAM报文类型(OAM Type)域,占16比特(bits)的空间,用于表示IP检测包的种类,在本实施例中,该OAM Type域取值为0,表示当前IP检测包为链路质量检测包。另外,为了便于扩展,该OAM Type域还可用不同的取值来表示其他类型的检测包,例如:取值为1表示抖动检测包;取值为2表示时延检测包。所述IP检测包还包括一扩展域,用于IP检测包的扩展,对于本第一实施例的链路质量检测包,其扩展域可用于标识ECMP路径序号。对于IP包的其他字段,该IP检测包原样保留。
上述IP检测包依据IPV4的结构,IPV6网络中的检测包也效仿IPV4结构的IP检测包,通过定义特殊的协议号来进行构造,但是在检测机制上与上述方法类似。
上述的第一实施例为被测链路没有ECMP时,本发明所述方法的较佳实施例。当被测链路有ECMP时,本发明所述的解决方法如以下第二实施例所述。
本文以图3所示ECMP为例说明第二实施例。如图3所示,链路在A1节点处分为两支,一支为A1-B-C,另一支为A1-B1-B2-C。当对节点A和节点D之间的链路进行检测时,检测方法与上述第一实施例相似,即:由节点A向节点D发送携带序列号的IP检测包,链路中的各个节点根据序列号判断是否丢包,并对接收包或丢包情况进行计数,向网管设备上报计数信息,由网管设备根据计数信息判断该链路是否发生故障,并定位故障点。但是,与第一实施例不同之处在于,ECMP的起始节点A1将收到的IP检测包复制为两份,一份走链路A1-B-C,另一份走链路A-B1-B2-C。同时,在复制的IP检测包的包扩展域中,添加ECMP的路径编号,例如链路A1-B-C编号为1,链路A-B1-B2-C编号为2。在两条分链路中,各个节点的处理过程与第一实施例所述节点的处理过程相同。当节点C收到关于同一源/目的地址但走不同链路的IP检测包后,通过IP检测包中包扩展域的路径编号识别所走的链路,并分别判断这两条链路上IP检测包的丢包情况,对两条链路分别进行接收包或丢包计数。并且,对于所述两个复制的、但路径编号不同的IP检测包,节点C向下一跳节点D转发先收到的IP检测包,丢弃后收到的IP检测包。
如果在ECMP链路上又出现ECMP,如图7所示,在节点B1处又出现链路分支,则节点B1再次复制收到的IP检测包,并在包扩展域中路径编号的基础上继续增加分编号,例如对于走B1-B2-C-D的IP检测包的路径编号为21,走B1-B3-D的IP检测包的路径编号为22。在节点D处,分别对走B1-B2-C-D的IP检测包和走B1-B3-D的IP检测包进行计数。
由于NGN网络中不但包括IP网络,而且还包括MPLS网络。本发明所述的方法还可在检测包穿过MPLS隧道或者其它隧道时,以及有MPLS虚拟专用网(VPN)的情况下检测并定位故障。以下第三实施例为在IP网络和MPLS网络混合时本发明的处理方法。
在MPLS网络中,由于各个节点只通过识别包的标签对包进行转发动作,对包中的内容不作分析处理,只有包到达目的节点时,该目的节点才会对包内容进行分析。当前无法设定一个表示该包是检测包的标签,各中间节点也无法通过分析序列号获知是否有丢包和乱序的情况,因此对于MPLS网络,虽然也是利用序列号,但具体的检测机制与IP网络中的具体检测机制不同。
图8为IP网络和MPLS网络混合时的一种组网示意图。如图8所示,假定在N2~N6之间是MPLS网络段,在N1~N2,N6~N7之间是IP网络段。本第三实施例中,以检测图8所示N1与N7之间的链路为例进行说明:
图9为本发明第三实施例检测故障并定位的方法流程图,参见图9,该方法包括:
步骤901、将N2~N6之间的MPLS网络段整体作为一跳链路,依照第一实施例所述的方法,用带有序列号的IP检测包检测节点N1、N2、N6、N7之间的链路是否故障,并定位故障点。
步骤902、判断MPLS网络段,即N2~N6之间,是否有丢包,如果有,则继续执行下述步骤903;否则,结束流程。
步骤903、利用携带序列号的MPLS检测包对MPLS网络的内层隧道即LSP26进行检测,看是否有丢包,如果有丢包,则判定存在故障,执行步骤904;否则,结束流程。
具体的,步骤903中,从内存隧道的起始节点N2向终止节点N6顺序发送携带序列号的MPLS检测包,中间节点N3、N4、N5根据标签对该MPLS检测包进行转发,直到该检测包到达节点N6。N6根据MPLS检测包中携带的序列号对包的接收状况进行识别,判断是否正确接收包或者是否有丢包,并对正确接收包或丢包进行计数,N2发送完MPLS检测包后,N2和或N6将计数信息和链路标识上报给网管设备,所述的链路标识为N2和N6之间的LSP,网管设备根据上报的计数信息和链路标识判断节点N2和N6之间的LSP是否有故障。此处的判断方法与第一实施例中的判断方法相同,此处不再描述。
步骤904、利用携带序列号的MPLS检测包对节点N2~N6之间的链路故障进行定位,即为分别逐级对承载LSP26的外层隧道进行检测,此处假设外层隧道为LSP23、LSP34、LSP45和LSP56。即分别对外层隧道LSP23、LSP34、LSP45和LSP56进行故障检测。
其中对外层隧道的检测方法与上述步骤903所述检测内存隧道LSP26的方法相同。
如果网管设备检测出所述某一外层隧道有丢包现象,则将故障点定位在该外层隧道上。
在上述步骤903和步骤904中,由于N2~N6之间为MPLS网络,不能对IP检测包进行识别,用上述IP检测包的定位方法无法对N2~N6之间的故障点进行定位。因此需要可由MPLS网络数据平面识别的检测包。
MPLS检测包的数据结构如下表3所示:
字段名称 | 字段说明 | 字段大小 |
功能类型(FunctionType) | 采用ITU性能检测包的编号为04Hex | 1字节 |
包类型(Packet Type) | 用于表示检测包的种类 | 1字节 |
包序列号(Sequencenumber) | 用于记录检测包的序列号 | 2字节 |
LSP路径源节点识别符(LSP Trail TerminationSource Identifier) | 用于标识该检测包所检测的LSP,与IP检测包中的源/目的地址作用相同 | 20字节 |
填充位(Padding) | 用于检测包长度填充,此处为全0 | 18字节 |
校验位(BIP) | 用于对检测包校验 | 2字节 |
表3
上述表3中,功能类型字段遵循ITUT的Y.1711标准,取值为04H,表示为用于性能检测的检测包。LSP路径源节点识别符和校验位也遵循Y.1711的标准取值。包序列号类似于上述IP网络中检测包的序列号,用于判断是否丢包或乱序。上述包类型字段用于表示检测包的类型。本实施例中的定义值如下:
00:正常检测包;
01:速率协商包。
当包类型字段取值为01时,表明该检测包为速度协商包,并在MPLS检测包中增加发送方的发送最大速度(My_R_speed)和发送方希望发送的速度(My_S_speed)字段。如下表4所示:
字段名称 | 字段说明 | 字段大小 |
功能类型(FunctionType) | 采用ITU性能检测包的编号为04Hex | 1字节 |
包类型(Packet Type) | 用于表示检测包的种类 | 1字节 |
包序列号(Sequencenumber) | 用于记录检测包的序列号 | 2字节 |
LSP路径源节点识别符(LSP Trail TerminationSource Identifier) | 用于标识该检测包所检测的LSP,与IP检测包中的源/目的地址作用相同 | 20字节 |
My_R_speed | 表示发送方的发送最大速度或希望发送的速度 | 4字节 |
My_S_speed | 表示接收方的接收最大速度或希望接收的速度 | 4字节 |
填充位(Padding) | 用于检测包长度填充,此处为全0 | 10字节 |
校验位(BIP) | 用于对检测包校验 | 2字节 |
表4
当进行MPLS检测时,发送方先发送速率协商检测包,该速率协商检测包的My_R_speed字段记录了发送方的发送最大速度或希望发送的速度,该速率协商检测包到达接收方后,接收方根据发送方的发送最大速度或希望发送的速度确定自身的接收最大速度或希望接收的速度,并向接收方返回速度协商检测响应包,该响应包的My_S_speed字段记录了接收方其中的接收最大速度或希望接收的速度。发送方收到速度协商检测响应包后,再确定最终发送正常检测包的速度,并以该速度发送正常的检测包,速度的单位为:包/每秒。通过速度协商,可避免检测包发送得太快或者太慢。如果太快则接收方处理不了,如果太慢可以无法用最快的速度发送,减小了对小概率故障的检测可能。
上述MPLS检测包中,在标签的最内层增加一个标签14,以表明是该MPLS包为检测包,该检测包的其余标签的规定遵循ITU的标签规定,此处不再详述。
上述的MPLS检测包为本发明新定义的检测包,另外,本发明也可以对目前MPLS网络中的CV包或者FFD包进行扩展,增加序列号字段,在各个检测节点上根据序列号对是否丢包进行检测。
如上所述,本发明所述的MPLS检测包符合MPLS网络数据平面的格式,MPLS网络节点的数据平面既可对检测包进行处理,无需控制平面的参与。
如果在MPLS网络中也出现ECMP,则依据第二实施例的处理方法,将MPLS检测包中再开辟一个字段,用于存放分支链路的编号,在分支链路的起始节点将MPLS检测包复制并添加分支路径编号,分别向每一个分支链路进行转发,分支链路中的各个节点对该MPLS检测包的接收状况进行计数,以此确定分支链路的故障情况。具体处理方法可参见上述第二实施例。
对于上述IP网络和MPLS网络混合的情况,所述步骤903也可以省略。本发明也可适用于纯MPLS网络,其处理步骤为上述的步骤903和步骤904。
以上所述,仅为本发明较佳的具体实施方式,但本发明的保护范围并不局限于此,任何熟悉该技术的人在本发明所揭露的技术范围内,可轻易想到的变化或替换,都应涵盖在本发明的保护范围之内。
Claims (11)
1、一种检测网络链路故障并定位故障的方法,其特征在于,该方法在对网络链路检测时,包括:
A、在链路的源节点连续顺序发送携带序列号的检测包,检测包通过链路的中间节点转发到目的节点,所述各检测包的序列号符合预定顺序;
B、链路的非源节点对所接收检测包的序列号进行顺序识别,以此判断接收检测包的状况,并对检测包的接收状况进行计数统计;
C、链路上的节点向网管设备上报计数信息和对应链路的标识;
D、网管设备根据各节点上报的计数信息判断节点接收检测包的状况,并以此判断对应的链路是否发生丢包故障,如果发生丢包,则进一步根据各个节点的计数信息的差别定位链路的故障点。
2、如权利要求1所述的方法,其特征在于,所述被测链路存在等值多路径,所述检测包在转发过程中,等值多路径的起始节点对收到的检测包进行复制,并添加路径编号,再将复制的检测包分别发送到各条等值路径中。
3、如权利要求1所述的方法,其特征在于,所述检测包的格式符合节点数据平面的处理格式,所述节点利用自身的数据平面对检测包进行处理。
4、如权利要求3所述的方法,其特征在于,所述被测链路为纯IP网链路,所述检测包的格式为IP包格式,所述IP包格式中的标志字段用于存放所述序列号,协议字段用于标识检测包。
5、如权利要求4所述的方法,其特征在于,所述的链路标识至少包括源/目的地址。
6、如权利要求3所述的方法,其特征在于,所述被测链路包括IP网段和MPLS网段;
在步骤A至步骤D中,将MPLS网段整体作为被测链路的一跳进行检测并定位故障,且所述检测包的格式为IP包格式;
在步骤D之后,进一步包括:
E、判断故障点是否在MPLS网段,如果是,则执行步骤F;否则,结束流程;
F、利用携带序列号的、符合MPLS包格式的检测包分别逐级对所述MPLS网段的每一段隧道进行故障检测,根据检测结果定位故障点。
7、如权利要求6所述的方法,其特征在于,所述对MPLS网段隧道进行故障检测的具体过程为:
a、所述隧道的起始节点向终止节点连续顺序发送携带序列号的检测包,所述各检测包的序列号符合预定顺序;
b、隧道的终止节点对所接收检测包的序列号进行顺序识别,以此判断接收检测包的状况,并对检测包的接收状况进行计数统计;
c、隧道的起始节点和或终止节点向网管设备上报计数信息和对应的隧道标识;
d、网管设备根据节点上报的计数信息判断隧道终止节点接收检测包的状况,并以此判断对应的隧道否发生丢包故障。
8、如权利要求7所述的方法,其特征在于,所述隧道为标签交换路径LSP。
9、如权利要求1或7所述的方法,其特征在于,所述节点接收检测包的状况为:检测包的丢包状况;
且所述节点对所接收检测包的序列号进行识别、判断接收检测包的状况、并进行计数统计的具体包括:
判断接收的当前检测包序列号与前一个检测包序列号是否符合正确的相邻顺序,如果是,则判定没有丢包,记录当前检测包的序列号;否则,判定有丢包,并对丢包数进行计数统计。
10、如权利要求9所述的方法,其特征在于,所述步骤B中,如果当前检测包序列号与前一个检测包序列号不符合正确的相邻顺序,则进一步包括:
如果当前检测包序列号与所记录的前一个检测包序列号的顺序正确,但序列号不相邻,则判定有丢包,记录当前检测包的序列号,并依照当前接收的检测包序列号与前一检测包序列号的差值对丢包数进行计数统计;
如果当前检测包序列号与前一个检测包序列号的顺序不正确,则判定检测包乱序,将当前检测包丢弃。
11、如权利要求1或7所述的方法,其特征在于,所述节点接收检测包的状况为:节点接收正确的检测包的状态;
且所述节点对所接收检测包的序列号进行识别、判断接收检测包的状况、并进行计数统计的具体包括:
判断接收的当前检测包序列号与前一个检测包序列号是否符合正确的相邻顺序,如果是,则判定当前检测包为正确的检测包,对所接收的正确检测包的数目进行计数统计,记录当前检测包的序列号;否则,判定当前检测包为错误的检测包。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNB2005100052191A CN100417080C (zh) | 2005-02-01 | 2005-02-01 | 一种检测网络链路故障并定位故障的方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNB2005100052191A CN100417080C (zh) | 2005-02-01 | 2005-02-01 | 一种检测网络链路故障并定位故障的方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN1815970A true CN1815970A (zh) | 2006-08-09 |
CN100417080C CN100417080C (zh) | 2008-09-03 |
Family
ID=36907949
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CNB2005100052191A Expired - Fee Related CN100417080C (zh) | 2005-02-01 | 2005-02-01 | 一种检测网络链路故障并定位故障的方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN100417080C (zh) |
Cited By (55)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2008031297A1 (fr) * | 2006-09-08 | 2008-03-20 | Zte Corporation | Procédé de localisation de position de panne de communication du système de surveillance de dispositif |
EP1912372A2 (en) * | 2006-10-10 | 2008-04-16 | NEC Corporation | Method for determining data transmission state in data communication system |
WO2008095390A1 (fr) * | 2007-02-07 | 2008-08-14 | Huawei Technologies Co., Ltd. | Équipement de détection d'incident de ligne en émulation de pseudo-fil et procédé correspondant |
CN1937541B (zh) * | 2005-09-20 | 2010-08-11 | 华为技术有限公司 | 一种网络性能测试方法 |
CN101826976A (zh) * | 2009-03-03 | 2010-09-08 | 中兴通讯股份有限公司 | P2mp通信中故障指示方法及中间、宿节点的故障指示装置 |
CN101369975B (zh) * | 2008-09-17 | 2011-02-09 | 上海华为技术有限公司 | 一种时延丢包的检测方法及系统 |
WO2011035640A1 (zh) * | 2009-09-28 | 2011-03-31 | 中兴通讯股份有限公司 | 一种下行物理链路故障诊断的方法、系统及装置 |
CN101163059B (zh) * | 2007-11-24 | 2011-04-13 | 杭州华三通信技术有限公司 | 一种网络节点检测方法和装置 |
CN102137282A (zh) * | 2010-12-15 | 2011-07-27 | 华为技术有限公司 | 一种检测故障链路的方法、装置、节点和系统 |
CN102204164A (zh) * | 2011-05-24 | 2011-09-28 | 华为技术有限公司 | 网络丢包信息报告方法及装置 |
CN101588271B (zh) * | 2008-05-20 | 2011-10-26 | 中兴通讯股份有限公司 | 一种在ims系统中实现路由检测的方法 |
CN102281146A (zh) * | 2010-06-11 | 2011-12-14 | 阿里巴巴集团控股有限公司 | 一种udp组播方法及装置 |
CN101212366B (zh) * | 2007-12-21 | 2011-12-21 | 杭州华三通信技术有限公司 | 以太环网中的故障检测方法、系统及主节点 |
CN101431448B (zh) * | 2008-10-22 | 2011-12-28 | 华为技术有限公司 | 定位ip承载网故障的方法、设备和系统 |
CN102307122A (zh) * | 2011-09-06 | 2012-01-04 | 北京傲天动联技术有限公司 | EoC链路故障检测系统和方法 |
CN102387039A (zh) * | 2011-10-25 | 2012-03-21 | 北京广利核系统工程有限公司 | 一种分析以太网具体丢包分布状态的方法 |
CN101765137B (zh) * | 2008-12-25 | 2012-03-28 | 中国移动通信集团公司 | 网络故障定位方法、设备及系统 |
CN102594600A (zh) * | 2012-02-21 | 2012-07-18 | 中兴通讯股份有限公司 | 一种确定双向转发检测会话故障位置的方法及系统 |
CN102946335A (zh) * | 2012-12-11 | 2013-02-27 | 广州中国科学院软件应用技术研究所 | 一种网络状况检测方法及系统 |
CN101778113B (zh) * | 2010-01-25 | 2013-09-18 | 福建星网锐捷网络有限公司 | 组播网中rp状态检测方法、装置、rp装置和组播系统 |
CN104066102A (zh) * | 2013-03-18 | 2014-09-24 | 中国移动通信集团公司 | 时间同步系统的故障定位检测方法、系统及装置 |
CN104506369A (zh) * | 2014-12-31 | 2015-04-08 | 北京华为数字技术有限公司 | 一种丢包位置的检测方法和设备 |
CN104683175A (zh) * | 2013-12-03 | 2015-06-03 | 华为技术有限公司 | 网络性能测试的方法及测试装置 |
CN104917641A (zh) * | 2014-03-11 | 2015-09-16 | 中国电信股份有限公司 | 一种用于测试丢包的方法、测试设备和系统 |
CN105308904A (zh) * | 2014-04-04 | 2016-02-03 | 华为技术有限公司 | 一种oam报文处理方法、网络设备和网络系统 |
CN105379164A (zh) * | 2013-07-10 | 2016-03-02 | 三星电子株式会社 | 用于发送和接收数据的方法和设备以及用于执行所述方法的记录介质 |
CN105591843A (zh) * | 2016-02-06 | 2016-05-18 | 中国科学院计算技术研究所 | Tcp传输流中基于接收端的网络性能检测方法及系统 |
CN105723657A (zh) * | 2014-09-26 | 2016-06-29 | 华为技术有限公司 | 交换机、控制器、系统及链路质量检测方法 |
WO2016184245A1 (zh) * | 2015-05-15 | 2016-11-24 | 中兴通讯股份有限公司 | 一种隧道丢包检测方法、装置及网络通信设备 |
WO2016197736A1 (zh) * | 2016-01-08 | 2016-12-15 | 中兴通讯股份有限公司 | 一种网络故障检测方法及装置 |
CN106549819A (zh) * | 2015-09-22 | 2017-03-29 | 华为技术有限公司 | 一种连通性探测方法、控制器和设备 |
CN106656615A (zh) * | 2016-12-29 | 2017-05-10 | 杭州迪普科技股份有限公司 | 一种基于tracert命令的报文处理方法及装置 |
CN106789438A (zh) * | 2016-12-29 | 2017-05-31 | 杭州迪普科技股份有限公司 | 一种设备连通性探测方法及装置 |
CN106982153A (zh) * | 2017-05-18 | 2017-07-25 | 烽火通信科技股份有限公司 | 一种多段伪线网络连通性检测方法 |
CN107171882A (zh) * | 2016-03-08 | 2017-09-15 | 华为技术有限公司 | 检测等价多路径路由功能的方法、设备和系统 |
CN108123824A (zh) * | 2016-11-30 | 2018-06-05 | 华为技术有限公司 | 一种网络故障检测方法及装置 |
CN108494700A (zh) * | 2018-02-02 | 2018-09-04 | 百度在线网络技术(北京)有限公司 | 跨链路数据传输方法、装置、计算机设备及存储介质 |
CN108737174A (zh) * | 2018-05-17 | 2018-11-02 | 深圳友讯达科技股份有限公司 | 异常定位方法及装置 |
CN109005081A (zh) * | 2018-06-26 | 2018-12-14 | 卡斯柯信号有限公司 | 一种丢包自动检测系统及方法 |
CN109218199A (zh) * | 2018-11-21 | 2019-01-15 | 新华三技术有限公司 | 一种报文处理方法和装置 |
WO2019056953A1 (zh) * | 2017-09-25 | 2019-03-28 | 华为技术有限公司 | 业务服务质量的检测方法、设备及系统 |
CN110034971A (zh) * | 2014-05-26 | 2019-07-19 | 华为技术有限公司 | 检测业务链的方法及装置 |
CN110932934A (zh) * | 2019-11-21 | 2020-03-27 | 中国联合网络通信集团有限公司 | 一种网络丢包的检测方法和装置 |
CN111078466A (zh) * | 2019-11-13 | 2020-04-28 | 福建京奥通信技术有限公司 | 传感器数据丢失分析方法及系统 |
CN111106990A (zh) * | 2019-12-30 | 2020-05-05 | 苏州联视泰电子信息技术有限公司 | 一种水下多通道信号采集传输阵列系统环路的自诊断方法 |
CN111371634A (zh) * | 2018-12-26 | 2020-07-03 | 华为技术有限公司 | 一种通信方法、装置及系统 |
CN112532515A (zh) * | 2020-12-21 | 2021-03-19 | 安徽皖通邮电股份有限公司 | 一种基于e1业务线路切换的方法 |
CN112602294A (zh) * | 2018-08-29 | 2021-04-02 | 华为技术有限公司 | 一种检测带宽的方法及检测设备 |
CN112995071A (zh) * | 2021-02-05 | 2021-06-18 | 杭州迪普科技股份有限公司 | 一种问题芯片定位方法 |
CN113645100A (zh) * | 2021-08-13 | 2021-11-12 | 福建天泉教育科技有限公司 | 一种基于元数据标签的全链路压力测试方案及系统 |
CN114338466A (zh) * | 2021-12-21 | 2022-04-12 | 卡斯柯信号有限公司 | 一种自适应的丢包检测方法 |
CN114500266A (zh) * | 2022-01-06 | 2022-05-13 | 云控智行科技有限公司 | 对于节点的工作状态进行分析的方法、装置及设备 |
CN115134228A (zh) * | 2022-06-28 | 2022-09-30 | 中国工商银行股份有限公司 | 环境链路供给与检测方法、装置、设备、介质和程序产品 |
CN116016147A (zh) * | 2022-12-28 | 2023-04-25 | 卡斯柯信号有限公司 | 一种轨旁安全平台的通信故障定位方法 |
CN115134228B (zh) * | 2022-06-28 | 2024-11-15 | 中国工商银行股份有限公司 | 环境链路供给与检测方法、装置、设备、介质和程序产品 |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6636484B1 (en) * | 1998-12-09 | 2003-10-21 | Cisco Technology, Inc. | Automatic generation of OAM cells for connection continuity detection |
US7164652B2 (en) * | 2001-12-17 | 2007-01-16 | Alcatel Canada Inc. | System and method for detecting failures and re-routing connections in a communication network |
CN100449964C (zh) * | 2001-12-31 | 2009-01-07 | 中兴通讯股份有限公司 | 对光同步数字传送体系的网络管理系统软件测试和故障定位的方法 |
CN100456687C (zh) * | 2003-09-29 | 2009-01-28 | 华为技术有限公司 | 网络故障实时相关性分析方法及系统 |
-
2005
- 2005-02-01 CN CNB2005100052191A patent/CN100417080C/zh not_active Expired - Fee Related
Cited By (90)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1937541B (zh) * | 2005-09-20 | 2010-08-11 | 华为技术有限公司 | 一种网络性能测试方法 |
WO2008031297A1 (fr) * | 2006-09-08 | 2008-03-20 | Zte Corporation | Procédé de localisation de position de panne de communication du système de surveillance de dispositif |
EP1912372A2 (en) * | 2006-10-10 | 2008-04-16 | NEC Corporation | Method for determining data transmission state in data communication system |
EP1912372A3 (en) * | 2006-10-10 | 2010-10-06 | NEC Corporation | Method for determining data transmission state in data communication system |
CN101162972B (zh) * | 2006-10-10 | 2014-02-12 | 日本电气株式会社 | 在数据通信系统中确定数据传输状态的方法 |
CN101013928B (zh) * | 2007-02-07 | 2011-09-14 | 华为技术有限公司 | 实现伪线仿真线路故障检测的装置及方法 |
WO2008095390A1 (fr) * | 2007-02-07 | 2008-08-14 | Huawei Technologies Co., Ltd. | Équipement de détection d'incident de ligne en émulation de pseudo-fil et procédé correspondant |
CN101163059B (zh) * | 2007-11-24 | 2011-04-13 | 杭州华三通信技术有限公司 | 一种网络节点检测方法和装置 |
CN101212366B (zh) * | 2007-12-21 | 2011-12-21 | 杭州华三通信技术有限公司 | 以太环网中的故障检测方法、系统及主节点 |
CN101588271B (zh) * | 2008-05-20 | 2011-10-26 | 中兴通讯股份有限公司 | 一种在ims系统中实现路由检测的方法 |
CN101369975B (zh) * | 2008-09-17 | 2011-02-09 | 上海华为技术有限公司 | 一种时延丢包的检测方法及系统 |
CN101431448B (zh) * | 2008-10-22 | 2011-12-28 | 华为技术有限公司 | 定位ip承载网故障的方法、设备和系统 |
CN101765137B (zh) * | 2008-12-25 | 2012-03-28 | 中国移动通信集团公司 | 网络故障定位方法、设备及系统 |
CN101826976B (zh) * | 2009-03-03 | 2014-03-12 | 中兴通讯股份有限公司 | P2mp通信中故障指示方法及中间、宿节点的故障指示装置 |
CN101826976A (zh) * | 2009-03-03 | 2010-09-08 | 中兴通讯股份有限公司 | P2mp通信中故障指示方法及中间、宿节点的故障指示装置 |
WO2011035640A1 (zh) * | 2009-09-28 | 2011-03-31 | 中兴通讯股份有限公司 | 一种下行物理链路故障诊断的方法、系统及装置 |
US8755285B2 (en) | 2009-09-28 | 2014-06-17 | Zte Corporation | Method, system and apparatus for diagnosing physical downlink failure |
AU2010297789B2 (en) * | 2009-09-28 | 2013-10-24 | Zte Corporation | Method, system and apparatus for diagnosing physical downlink failure |
CN101778113B (zh) * | 2010-01-25 | 2013-09-18 | 福建星网锐捷网络有限公司 | 组播网中rp状态检测方法、装置、rp装置和组播系统 |
CN102281146A (zh) * | 2010-06-11 | 2011-12-14 | 阿里巴巴集团控股有限公司 | 一种udp组播方法及装置 |
WO2012079430A1 (zh) * | 2010-12-15 | 2012-06-21 | 华为技术有限公司 | 一种检测故障链路的方法、装置、节点和系统 |
CN102137282B (zh) * | 2010-12-15 | 2014-02-19 | 华为技术有限公司 | 一种检测故障链路的方法、装置、节点和系统 |
CN102137282A (zh) * | 2010-12-15 | 2011-07-27 | 华为技术有限公司 | 一种检测故障链路的方法、装置、节点和系统 |
US9036488B2 (en) | 2010-12-15 | 2015-05-19 | Huawei Technologies Co., Ltd. | Faulty link detection method, apparatus, node, and system |
CN102204164A (zh) * | 2011-05-24 | 2011-09-28 | 华为技术有限公司 | 网络丢包信息报告方法及装置 |
CN102307122A (zh) * | 2011-09-06 | 2012-01-04 | 北京傲天动联技术有限公司 | EoC链路故障检测系统和方法 |
CN102387039A (zh) * | 2011-10-25 | 2012-03-21 | 北京广利核系统工程有限公司 | 一种分析以太网具体丢包分布状态的方法 |
CN102594600A (zh) * | 2012-02-21 | 2012-07-18 | 中兴通讯股份有限公司 | 一种确定双向转发检测会话故障位置的方法及系统 |
CN102594600B (zh) * | 2012-02-21 | 2018-05-08 | 中兴通讯股份有限公司 | 一种确定双向转发检测会话故障位置的方法及系统 |
CN102946335A (zh) * | 2012-12-11 | 2013-02-27 | 广州中国科学院软件应用技术研究所 | 一种网络状况检测方法及系统 |
CN102946335B (zh) * | 2012-12-11 | 2015-12-23 | 广州中国科学院软件应用技术研究所 | 一种网络状况检测方法及系统 |
CN104066102A (zh) * | 2013-03-18 | 2014-09-24 | 中国移动通信集团公司 | 时间同步系统的故障定位检测方法、系统及装置 |
CN105379164A (zh) * | 2013-07-10 | 2016-03-02 | 三星电子株式会社 | 用于发送和接收数据的方法和设备以及用于执行所述方法的记录介质 |
CN105379164B (zh) * | 2013-07-10 | 2019-03-29 | 三星电子株式会社 | 用于发送和接收数据的方法和设备以及用于执行所述方法的记录介质 |
CN104683175A (zh) * | 2013-12-03 | 2015-06-03 | 华为技术有限公司 | 网络性能测试的方法及测试装置 |
CN104683175B (zh) * | 2013-12-03 | 2018-05-11 | 华为技术有限公司 | 网络性能测试的方法及测试装置 |
CN104917641A (zh) * | 2014-03-11 | 2015-09-16 | 中国电信股份有限公司 | 一种用于测试丢包的方法、测试设备和系统 |
CN105308904A (zh) * | 2014-04-04 | 2016-02-03 | 华为技术有限公司 | 一种oam报文处理方法、网络设备和网络系统 |
US10116546B2 (en) | 2014-04-04 | 2018-10-30 | Huawei Technologies Co., Ltd. | OAM packet processing method, network device, and network system |
CN105308904B (zh) * | 2014-04-04 | 2019-05-21 | 华为技术有限公司 | 一种oam报文处理方法、网络设备和网络系统 |
CN110034971B (zh) * | 2014-05-26 | 2022-11-18 | 华为技术有限公司 | 检测业务链的方法及装置 |
CN110034971A (zh) * | 2014-05-26 | 2019-07-19 | 华为技术有限公司 | 检测业务链的方法及装置 |
CN105723657A (zh) * | 2014-09-26 | 2016-06-29 | 华为技术有限公司 | 交换机、控制器、系统及链路质量检测方法 |
US10756994B2 (en) | 2014-09-26 | 2020-08-25 | Huawei Technologies Co., Ltd. | Switch, controller, system, and link quality detection method |
CN104506369B (zh) * | 2014-12-31 | 2019-04-05 | 北京华为数字技术有限公司 | 一种丢包位置的检测方法和设备 |
CN104506369A (zh) * | 2014-12-31 | 2015-04-08 | 北京华为数字技术有限公司 | 一种丢包位置的检测方法和设备 |
CN106301821A (zh) * | 2015-05-15 | 2017-01-04 | 中兴通讯股份有限公司 | 一种隧道丢包检测方法、装置及网络通信设备 |
WO2016184245A1 (zh) * | 2015-05-15 | 2016-11-24 | 中兴通讯股份有限公司 | 一种隧道丢包检测方法、装置及网络通信设备 |
CN106549819B (zh) * | 2015-09-22 | 2019-12-17 | 华为技术有限公司 | 一种连通性探测方法、控制器和设备 |
CN106549819A (zh) * | 2015-09-22 | 2017-03-29 | 华为技术有限公司 | 一种连通性探测方法、控制器和设备 |
CN106961344A (zh) * | 2016-01-08 | 2017-07-18 | 中兴通讯股份有限公司 | 一种网络故障检测方法及装置 |
CN106961344B (zh) * | 2016-01-08 | 2021-02-09 | 中兴通讯股份有限公司 | 一种网络故障检测方法及装置 |
WO2016197736A1 (zh) * | 2016-01-08 | 2016-12-15 | 中兴通讯股份有限公司 | 一种网络故障检测方法及装置 |
CN105591843B (zh) * | 2016-02-06 | 2018-12-04 | 中国科学院计算技术研究所 | Tcp传输流中基于接收端的网络性能检测方法及系统 |
CN105591843A (zh) * | 2016-02-06 | 2016-05-18 | 中国科学院计算技术研究所 | Tcp传输流中基于接收端的网络性能检测方法及系统 |
CN107171882B (zh) * | 2016-03-08 | 2021-02-09 | 华为技术有限公司 | 检测等价多路径路由功能的方法、设备和系统 |
CN107171882A (zh) * | 2016-03-08 | 2017-09-15 | 华为技术有限公司 | 检测等价多路径路由功能的方法、设备和系统 |
CN108123824A (zh) * | 2016-11-30 | 2018-06-05 | 华为技术有限公司 | 一种网络故障检测方法及装置 |
CN108123824B (zh) * | 2016-11-30 | 2021-06-01 | 华为技术有限公司 | 一种网络故障检测方法及装置 |
CN106789438A (zh) * | 2016-12-29 | 2017-05-31 | 杭州迪普科技股份有限公司 | 一种设备连通性探测方法及装置 |
CN106656615B (zh) * | 2016-12-29 | 2020-03-06 | 杭州迪普科技股份有限公司 | 一种基于tracert命令的报文处理方法及装置 |
CN106656615A (zh) * | 2016-12-29 | 2017-05-10 | 杭州迪普科技股份有限公司 | 一种基于tracert命令的报文处理方法及装置 |
CN106982153A (zh) * | 2017-05-18 | 2017-07-25 | 烽火通信科技股份有限公司 | 一种多段伪线网络连通性检测方法 |
WO2019056953A1 (zh) * | 2017-09-25 | 2019-03-28 | 华为技术有限公司 | 业务服务质量的检测方法、设备及系统 |
US11606726B2 (en) | 2017-09-25 | 2023-03-14 | Huawei Technologies Co., Ltd. | Detecting quality of service (QoS) of a service |
CN108494700A (zh) * | 2018-02-02 | 2018-09-04 | 百度在线网络技术(北京)有限公司 | 跨链路数据传输方法、装置、计算机设备及存储介质 |
CN108737174A (zh) * | 2018-05-17 | 2018-11-02 | 深圳友讯达科技股份有限公司 | 异常定位方法及装置 |
CN109005081A (zh) * | 2018-06-26 | 2018-12-14 | 卡斯柯信号有限公司 | 一种丢包自动检测系统及方法 |
CN112602294B (zh) * | 2018-08-29 | 2021-10-15 | 华为技术有限公司 | 一种检测带宽的方法及检测设备 |
CN112602294A (zh) * | 2018-08-29 | 2021-04-02 | 华为技术有限公司 | 一种检测带宽的方法及检测设备 |
US11388090B2 (en) | 2018-08-29 | 2022-07-12 | Huawei Technologies Co., Ltd. | Bandwidth measurement method and measurement device |
CN109218199A (zh) * | 2018-11-21 | 2019-01-15 | 新华三技术有限公司 | 一种报文处理方法和装置 |
CN111371634A (zh) * | 2018-12-26 | 2020-07-03 | 华为技术有限公司 | 一种通信方法、装置及系统 |
CN111371634B (zh) * | 2018-12-26 | 2022-01-18 | 华为技术有限公司 | 一种通信方法、装置及系统 |
CN111078466A (zh) * | 2019-11-13 | 2020-04-28 | 福建京奥通信技术有限公司 | 传感器数据丢失分析方法及系统 |
CN111078466B (zh) * | 2019-11-13 | 2023-04-07 | 福建京奥通信技术有限公司 | 传感器数据丢失分析方法及系统 |
CN110932934B (zh) * | 2019-11-21 | 2021-07-13 | 中国联合网络通信集团有限公司 | 一种网络丢包的检测方法和装置 |
CN110932934A (zh) * | 2019-11-21 | 2020-03-27 | 中国联合网络通信集团有限公司 | 一种网络丢包的检测方法和装置 |
CN111106990B (zh) * | 2019-12-30 | 2021-09-14 | 苏州联视泰电子信息技术有限公司 | 一种水下多通道信号采集传输阵列系统环路的自诊断方法 |
CN111106990A (zh) * | 2019-12-30 | 2020-05-05 | 苏州联视泰电子信息技术有限公司 | 一种水下多通道信号采集传输阵列系统环路的自诊断方法 |
CN112532515A (zh) * | 2020-12-21 | 2021-03-19 | 安徽皖通邮电股份有限公司 | 一种基于e1业务线路切换的方法 |
CN112995071B (zh) * | 2021-02-05 | 2022-06-28 | 杭州迪普科技股份有限公司 | 一种问题芯片定位方法 |
CN112995071A (zh) * | 2021-02-05 | 2021-06-18 | 杭州迪普科技股份有限公司 | 一种问题芯片定位方法 |
CN113645100A (zh) * | 2021-08-13 | 2021-11-12 | 福建天泉教育科技有限公司 | 一种基于元数据标签的全链路压力测试方案及系统 |
CN114338466A (zh) * | 2021-12-21 | 2022-04-12 | 卡斯柯信号有限公司 | 一种自适应的丢包检测方法 |
CN114338466B (zh) * | 2021-12-21 | 2023-10-31 | 卡斯柯信号有限公司 | 一种自适应的丢包检测方法 |
CN114500266A (zh) * | 2022-01-06 | 2022-05-13 | 云控智行科技有限公司 | 对于节点的工作状态进行分析的方法、装置及设备 |
CN115134228A (zh) * | 2022-06-28 | 2022-09-30 | 中国工商银行股份有限公司 | 环境链路供给与检测方法、装置、设备、介质和程序产品 |
CN115134228B (zh) * | 2022-06-28 | 2024-11-15 | 中国工商银行股份有限公司 | 环境链路供给与检测方法、装置、设备、介质和程序产品 |
CN116016147A (zh) * | 2022-12-28 | 2023-04-25 | 卡斯柯信号有限公司 | 一种轨旁安全平台的通信故障定位方法 |
Also Published As
Publication number | Publication date |
---|---|
CN100417080C (zh) | 2008-09-03 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN1815970A (zh) | 一种检测网络链路故障并定位故障的方法 | |
CN1492630A (zh) | 测量网络运行流量经历的网络运行参数 | |
US11894998B2 (en) | Bit-forwarding ingress router, bit-forwarding router, and operation, administration and maintenance test method | |
CN101132320B (zh) | 检测接口故障的方法及网络节点设备 | |
CN102164051B (zh) | 面向业务的故障检测与定位方法 | |
CN1838620A (zh) | 检测混合网络中端到端节点间链路故障的方法 | |
CN1848775A (zh) | 多跳伪线故障检测、上报和维护协商控制方法 | |
US20080159288A1 (en) | TRAFFIC ENGINEERING AND FAST PROTECTION USING IPv6 CAPABILITIES | |
CN102340451B (zh) | 一种跟踪路由测试方法、系统、装置及设备 | |
CN1913496A (zh) | 一种oam报文的转发控制方法及系统 | |
CN112804075B (zh) | 发送报文、接收报文以进行oam的方法、装置及系统 | |
CN101924701B (zh) | 组播转发路径的建立方法及路由设备 | |
CN1716943A (zh) | 获取隧道网关环境中路径最大传输长度的方法及系统 | |
US20230155928A1 (en) | In-Situ Flow Detection Method and Related Device | |
JP2018050186A (ja) | 通信装置およびコンピュータプログラム | |
CN113179189B (zh) | 分段路由故障检测方法、装置、第一分段路由及目的路由 | |
CN111510982B (zh) | 一种传输数据的方法及装置 | |
CN1992638A (zh) | 在网络中获取路径最大传输单元的方法及系统 | |
US8724493B2 (en) | Method for link quality estimation in a wireless network | |
CN108449267B (zh) | 一种基于链路质量估计的可靠路由算法 | |
CN101039265A (zh) | 一种路由器及路由转发方法 | |
CN1685670A (zh) | 无线台站在与接入点关联前确定网络度量的方法 | |
WO2010106651A1 (ja) | 経路解析装置 | |
CN104243224B (zh) | 路由环路的检测方法和装置 | |
WO2011131688A1 (en) | A path selection method for a network |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
CF01 | Termination of patent right due to non-payment of annual fee | ||
CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20080903 Termination date: 20190201 |