CN102177681A - 检测故障的方法和系统 - Google Patents
检测故障的方法和系统 Download PDFInfo
- Publication number
- CN102177681A CN102177681A CN2011800003150A CN201180000315A CN102177681A CN 102177681 A CN102177681 A CN 102177681A CN 2011800003150 A CN2011800003150 A CN 2011800003150A CN 201180000315 A CN201180000315 A CN 201180000315A CN 102177681 A CN102177681 A CN 102177681A
- Authority
- CN
- China
- Prior art keywords
- message
- port
- destination
- tcp
- measurement point
- 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
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
- H04L43/0823—Errors, e.g. transmission errors
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0677—Localisation of faults
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/10—Active monitoring, e.g. heartbeat, ping or trace-route
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/24—Multipath
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/28—Routing or path finding of packets in data switching networks using route fault recovery
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Environmental & Geological Engineering (AREA)
- Health & Medical Sciences (AREA)
- Cardiology (AREA)
- General Health & Medical Sciences (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明实施例提供了检测故障的方法和系统。该方法包括:向目的端发送基于至少两个端口对的端口扫描报文,其中每个端口对包括源端口号和目的端口号,并与源端和目的端之间的一条路径相对应;接收目的端发送的响应报文,响应报文携带目的端基于端口扫描报文确定的未接收到的端口对;基于响应报文携带的端口对,确定出现故障的路径。基于本发明实施例提供的技术方案,通过基于多个端口对发送端口扫描报文,可以使端口扫描报文经过多条路径到达目的端,从而对源端和目的端之间的多条路径进行检测,相比相关技术只能检测到一条路径的情况,可以实现更加有效的故障检测,准确发现网络中故障的存在。
Description
技术领域
本发明涉及网络通信领域,并且更具体地,涉及网络通信领域中检测故障的方法和系统。
背景技术
全IP(Internet Protocol,网络互联协议)网络作为未来业务发展的趋势已经是不争的事实,越来越多的运营商将传统的电信业务和新兴业务承载于IP网络上,以获取诸如新业务、高带宽利用率、低成本之类的特性和优势。等价多路径(Equal-Cost MultiPath,ECMP)作为IP网络的一个显著特性,虽然极大地提高了IP网络的资源利用率、均衡了IP网络的负载,但是也给IP网络的故障检测和定位带来了极大的困难。
ECMP可以将从源端发往目的端的IP报文负荷分担到多条等价路径上,以达到最大限度利用承载网资源的目的。所谓等价路径是指在源端和目的端之间存在的多条路径中,如果其中某些路径的路径开销相等例如跳数相同,那么这些路径就是等价路径。
路由器一般均支持基于2元组(源IP地址、目的IP地址)和5元组(源IP地址、目的IP地址、协议号、源端口、目的端口)的ECMP负荷分担。在5元组的ECMP负荷分担中,路由器对通过它自身的报文进行分组,5元组完全相同的报文作为一组,并按照负荷分担算法为每组的报文指定一条路径。这样,从同一源端发往同一目的端的报文,如果协议号、源端口号、目的端口号中的任一项不同,则将可能经过不同的路径。在这种以ECMP网络为代表的基于端口选路的网络中,针对从同一源端到同一目的端的报文,可以根据由源端口号和目的端口号组成的端口对来进行路由选择,从而可以分流从同一源端到同一目的端的流量。
但是,当基于端口选路的网络(例如利用ECMP进行负荷分担的ECMP网络)出现故障时,由于目前存在的对网络故障进行检测的方法不能基于端口来经过不同的路径,因此很难检测到故障的存在,并且也很难对故障进行定位。
目前,可以通过使用Ping命令来进行连通性测试,进而检测是否存在网络故障。使用Ping命令时,源端向目的端发送ICMP(Internet ControlMessage Protocol,互联网控制消息协议)回显请求报文(类型为8),当目的端接收到ICMP回显请求报文时,返回ICMP回显响应报文(类型为0),源端可以计算出往返时间和丢包率。如果源端在一定时间内接收不到ICMP回显响应报文,则判断目的端不可达,IP网络出现故障。由于通过Ping命令发送的Ping报文具有相同的源IP地址和目的IP地址,并且协议号都为1,但是没有端口号,因此从源端发往目的端的Ping报文只能经过同一条路径,从而通过Ping报文只能检测到一条路径的连通性。当其他路径发生故障时,Ping报文无法感知,从而无法确定其他路径故障的存在。并且,Ping命令不能对故障进行定位。
还可以通过使用双向转发检测(Bidirectional Forwarding Detection,BFD)报文来检测网络故障。源端和目的端在它们之间所建立的会话通道上周期性地向对方发送BFD检测报文。BFD报文的协议号为17,源端口号和目的端口号均为3784。如果源端或目的端在足够长的时间内没有收到对方发送的检测报文,则认为之间的通道发生了故障。由于从一方发给另一方的BFD报文的5元组均相同,因此在基于端口选路的网络中,该BFD报文只能通过一条路径,从而只能检测到一条路径的故障,而不能检测到源端和目的端之间其他等价路径的故障。同时,BFD也不能进行故障定位。
另外,还可以通过使用Traceroute(跟踪路由)命令来确定源端到目的端的路径,从而可以发现该路径是否存在故障以及故障在何处。Traceroute操作通过修改IP报文头部中的TTL(生命周期)字段,并利用ICMP超时报文,可以实现对故障的检测和定位。源端通过依次递增TTL字段来向目的端发送ICMP回显请求报文,接收到ICMP回显请求报文的路由器将TTL减1,如果发现TTL是0,则丢弃该报文,向源端返回ICMP超时报文(类型为11),这样可以得到某路由器的地址。如果未得到某路由器的地址,则认为在该处出现了故障。然而,虽然从源端发给目的端的Traceroute报文具有相同的源IP地址、目的IP地址、协议号(为1),但是由于没有源端口号和目的端口号,所以Traceroute报文也只能通过一条路径,只能检测并定位一条路径的故障。
由此可见,上述的相关技术由于在检测故障的过程中不区分端口号,发送的报文只能经过相同的路径,因此只能检测到一条路径的故障,而无法检测到源端和目的端之间其他路径的故障。这样,在基于端口选路的网络(例如ECMP网络)中,不能对源端到目的端之间出现的故障进行有效地检测。
发明内容
本发明实施例提供了检测故障的方法和系统,可以有效检测源端和目的端之间出现的网络故障,使得源端和目的端之间与由源端口号和目的端口号组成的端口对相应的多条路径都能得到有效检测,从而可以方便地确定网络故障的存在。
一方面,本发明实施例提供了一种检测故障的方法,包括:向目的端发送基于至少两个端口对的端口扫描报文,其中每个端口对包括源端口号和目的端口号,并与源端和目的端之间的一条路径相对应;接收目的端发送的响应报文,响应报文携带目的端基于端口扫描报文确定的未接收到的端口对;基于响应报文携带的端口对,确定出现故障的路径。
另一方面,本发明实施例提供了一种用于检测故障的系统,该系统包括源测量点和目的测量点。源测量点包括:第一发送模块,用于向目的测量点发送基于至少两个端口对的端口扫描报文,其中每个端口对包括源端口号和目的端口号,并与源测量点和目的测量点之间的一条路径相对应;第一接收模块,用于接收目的测量点发送的响应报文,响应报文携带目的测量点基于端口扫描报文确定的未接收到的端口对;第一确定模块,用于基于响应报文携带的端口对,确定出现故障的路径。目的测量点包括:第二接收模块,用于接收来自源测量点的端口扫描报文;第二确定模块,用于基于端口扫描报文,确定未接收到的端口对;第二发送模块,用于向源测量点发送携带所确定的端口对的响应报文。
基于本发明实施例提供的上述技术方案,为了检测源端和目的端之间的多条路径,源端可以基于至少两个端口对来发送用于检测路径故障的端口扫描报文,使得端口扫描报文可以经过多条路径到达目的端,目的端根据接收到的端口扫描报文携带的端口对来确定未接收到的端口对,从而可以确定与未接收到的端口对相应的路径存在故障。这样,由于端口扫描报文可以经过与不同端口对相应的路径,从而可以对源端和目的端之间的多条路径进行检测,相比于相关技术只能检测到一条路径的情况,可以实现更加有效的故障检测,准确发现网络中故障的存在。
附图说明
为了更清楚地说明本发明实施例的技术方案,下面将对实施例中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1是根据本发明实施例的检测故障的方法的流程图。
图2是根据本发明实施例的检测故障的另一方法的流程图。
图3是根据本发明实施例的确定目的端是否支持端口扫描报文的方法的流程图。
图4是根据本发明实施例的利用检测故障的方法在RNC(Radio Network Controller,无线网络控制器)和UMG(Universal Media Gateway,通用媒体网关)之间检测故障并进行故障定位的例子的示意图。
图5是根据本发明实施例的用于检测故障的系统的结构框图。
图6是根据本发明实施例的用于检测故障的另一系统的结构框图。
具体实施方式
下面将结合本发明实施例中的附图,对本发明实施例的技术方案进行清楚、完整地描述,显然,所描述的实施例是本发明的一部分实施例,而不是全部实施例。基于本发明中的所述实施例,本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例,都应属于本发明保护的范围。
首先,结合图1描述根据本发明实施例的检测故障的方法100。
如图1所示,方法100包括:在S110中,向目的端发送基于至少两个端口对的端口扫描报文,其中每个端口对包括源端口号和目的端口号,并与源端和目的端之间的一条路径相对应;在S120中,接收目的端发送的响应报文,响应报文携带目的端基于端口扫描报文确定的未接收到的端口对;在S130中,基于响应报文携带的端口对,确定出现故障的路径。
在源端和目的端之间可以存在多条路径,每条路径可以与由源端口号和目的端口号组成的端口对相对应。源端和目的端之间的转发节点(例如路由器)基于IP报文携带的源端口号和目的端口号,可以为该IP报文选择路由而进行转发。为了检测源端和目的端之间的网络故障,源端通过扫描端口对,基于所扫描的多个端口对中的每一个来生成端口扫描报文,使得端口扫描报文可以经过与其携带的端口对相应的路径而送达目的端。目的端不停地接收来自源端的端口扫描报文,确定有哪个或哪些端口对没有接收到,并将没有接收到的端口对作为故障信息返回给源端。源端基于返回的故障信息,确定与返回的端口对相应的路径存在故障,从而检测出网络中存在的故障。
根据本发明实施例提供的检测故障的方法,源端基于多个端口对发送用于检测路径故障的端口扫描报文,使得端口扫描报文可以经过与不同端口对相应的路径到达目的端,而目的端根据接收到的端口扫描报文携带的端口对来确定未接收到的端口对,从而可以确定与未接收到的端口对相应的路径存在故障。这样,由于端口扫描报文可以经过与不同端口对相应的路径,从而可以对源端和目的端之间的多条路径进行检测,相比于相关技术只能检测到一条路径的情况,可以实现更加有效的故障检测,准确发现网络中故障的存在。
接下来,详细描述根据本发明实施例的S110至S130。
在S110中,在诸如ECMP网络之类的基于端口选路的网络中,由于从源端发往目的端的IP报文具有相同的源IP地址和目的IP地址,其IP报文的路径与源端口号和目的端口号组成的端口对有关。即便在路由还与协议号有关的情况下,如果固定协议号,那么IP报文的路径也只与端口对有关。这样,每个端口对可以对应源端到目的端之间的一条路径,多个端口对对应的路径可以相同。
通过基于端口对发送的端口扫描报文,可以检测源端和目的端之间路径的故障。由于在端口扫描报文中携带有端口对,因此端口扫描报文可以经过与携带的端口对相应的路径,从而对该路径进行故障检测。如果改变端口扫描报文中携带的端口对,可以覆盖例如基于5元组进行路由选择的网络中的多条路径。如果目的端能够收到端口扫描报文,则说明该端口扫描报文所经过的路径没有故障存在,反之则说明与该端口扫描报文携带的端口对相应的路径存在故障。
根据本发明的一个实施例,源端可以顺序遍历至少两个端口对;基于当前遍历的端口对,向目的端发送基于该端口对的端口扫描报文。
由于在源端和目的端之间存在多条路径,因此存在多个端口对。源端通过顺序遍历源端和目的端之间存在的多个端口对,即对端口对进行顺序扫描,可以发送与当前扫描的端口对相应的端口扫描报文。从而,源端发送的端口扫描报文可以经过源端和目的端之间的多条路径,使得源端和目的端之间的多条路径得以覆盖。
根据本发明的一个实施例,每个端口对中的源端口号和目的端口号可以相等。通常,在基于IP网络的电信网络中,进行通信的源端和目的端采用相同的端口号,这样使得IP报文中的源端口号和目的端口号相同。因此,源端和目的端之间的路径可以用相等的源端口号和目的端口号表征。即使在IP网络中,携带业务信息的IP报文通过的路径对应着不同的源端口号和目的端口号,进行故障检测所使用的源端口号和目的端口号也可以相同,使得虽然用于检测的端口扫描报文与携带业务信息的IP报文通过的路径不同,但是仍然可以通过遍历端口对来用端口扫描报文覆盖源端到目的端之间的路径。
当采用源端口号等于目的端口号的方式对端口对进行顺序遍历或扫描时,由于端口号的范围为0至65535,所以每次扫描时,依次扫描0至65535范围内的端口号。例如,首先发送源端口号和目的端口号都是0的端口扫描报文,然后发送源端口号和目的端口号都是1的端口扫描报文,再发送源端口号和目的端口号都是2的端口扫描报文,以此类推,直到从目的端接收到响应消息。由于在源端和目的端之间一般最多存在几十条等价路径(根据路由跳数和组网而定),因此一般情况下只需要对几十个端口对进行扫描就可以覆盖源端和目的端之间的等价路径。
如果每个端口对中的源端口号和目的端口号不一定相同,那么每次扫描时,源端可以首先固定源端口号,对目的端口号进行扫描;再将源端口号增加1,并再对目的端口号进行扫描;以此类推。例如,源端首先固定源端口号是0,分别将目的端口号设置为0至65535,发送相应的端口扫描报文;然后将源端口号设置为1,分别将目的端口号设置为0至65535,再发送相应的端口扫描报文;以此类推。这样,无论源端口号和目的端口号是否相同,都可以利用多个端口对来对网络中的多条路径进行故障检测。
根据本发明的一个实施例,端口扫描报文可以通过IP头部中的DF(Don’t Fragment,不分片)标志位、MF(More Fragments,更多分片)标志位和偏移字段来进行标识。
可以通过对对端口扫描报文的IP头部中的字段进行新的定义,来使目的端可以识别出端口扫描报文,处理之后直接丢弃该端口扫描报文,而不将端口扫描报文上交到业务处理模块,这样不会使故障检测对正常的业务处理产生影响。
可以通过为IP头部中的DF标志位、MF标志位和偏移字段填充特定的字段来表征当前报文为端口扫描报文。此时需要DF标志位、MF标志位和偏移字段的填充形式与现有的普通用法不一样。目前,DF标志位为0时,MF标志位和偏移字段都为0;DF标志位为1时,MF标志位可以为1,此时偏移字段可以为任意值;DF标志位为0时,MF标志位还可以为0,此时偏移字段为0。
为了与目前的用法相区分,根据本发明的一个实施例,可以将DF标志位的值设置为1,将MF标志位的值设置为0,将偏移字段的值设置为不全为0。其中,为了与目前协议中的含义相兼容,值为1的DF标志位可以用于表示不进行分片;值为0的MF标志位可以用于表示没有更多的分片;值不全为0的偏移字段可以用于结合DF标识位和MF标识符来表示该报文是端口扫描报文。例如,当DF标志位为1、MF标志位为0、偏移字段为1010101010101时,可以表示当前报文为端口扫描报文。
通过重新定义IP头部中的DF标志位、MF标志位和偏移字段以作为端口扫描报文的标识,不仅不会与现在的用法相冲突,从而不会对现在的数据处理造成异常,还可以极大提高端口扫描报文的识别效率。并且由于通过IP头部就可以识别出端口扫描报文,从而无需对端口扫描报文进行深度报文解析,不会对正常的业务产生影响。
在S120中,由于源端顺序扫描端口对,进而向目的端发送相应的端口扫描报文,如果目的端没有接收到与某个端口对相应的端口扫描报文,则说明该端口扫描报文经过的路径存在故障,故将未接收到的端口对作为故障信息携带在响应报文中返回给源端。响应报文可以采用ICMP报文,也可以采用UDP(user Datagram Protocol,用户数据报协议)数据报,当然还可以采用其他形式的IP报文。
在S130中,源端从响应报文中提取出作为故障信息返回的端口对,确定与该端口对相应的路径存在故障,从而完成对网络故障的检测。
以采用源端口号等于目的端口号的方式进行端口对扫描为例,描述方法100的具体实现的例子,过程如下:
在S110中,源端向目的端发送携带当前扫描的端口对的端口扫描报文。在该端口扫描报文中,源IP地址为源端IP地址,目的IP地址为目的端IP地址,协议号为17(UDP协议),源端口号和目的端口号都等于当前扫描的端口号。针对每个扫描的端口号,源端可以向目的端发送多个相同的端口扫描报文,以防止由于干扰等造成的目的端解码失败或不能识别端口扫描报文等,避免对故障检测造成影响。例如,针对每个扫描的端口号,可以发送3个相同的端口扫描报文。
虽然在S110中发送的端口扫描报文是UDP数据报,但是本领域技术人员可以想到,端口扫描报文也可以是TCP(Transmission Control Protocol,传输控制协议)数据报,此时端口扫描报文携带的协议号是6。通过将UDP数据报或TCP数据报作为端口扫描报文,使得在扫描端口时,基于不同端口对的端口扫描报文可以经过不同的路径。
在S120中,目的端接收源端发送的端口扫描报文,如果发现没有接收到与某个端口对相应的端口扫描报文,则向源端返回端口扫描故障信息,将该端口对携带在响应报文中发送给源端。例如,如果目的端接收到源端口号和目的端口号都为98的端口扫描报文,还接收到源端口号和目的端口号都为100的端口扫描报文,但是没有接收到源端口号和目的端口号都为99的端口扫描报文,那么目的端将源端口号和目的端口号都为99的端口对作为扫描故障信息返回给源端。携带故障信息的响应报文可以采用Ping方式中的ICMP报文,也可以采用UDP数据报,当然还可以采用其他形式的IP报文,只要可以通知源端即可。
在S130中,源端根据接收到的响应报文中携带的端口对,可以知晓目的端没有接收到与该端口对相应的端口扫描报文,从而可以确定该端口扫描报文经过的路径存在故障。
根据本发明实施例提供的测量故障的方法,源端通过顺序遍历端口对,可以使端口扫描报文经过多条路径到达目的端,从而端口扫描报文可以经过与不同端口对相应的路径,实现对源端和目的端之间多条路径的检测,相比相关技术只能检测到一条路径的情况,可以实现更加有效的故障检测,准确发现网络中故障的存在。另外,通过IP头部中的DF标志位、MF标志位和偏移字段,可以方便地标识端口扫描报文,不仅不会与现在的用法相冲突,还可以极大提高端口扫描报文的识别效率。并且无需对端口扫描报文进行深度报文解析,不会对正常的业务产生影响。
接下来,结合图2描述根据本发明实施例的检测故障的方法200。方法200的S210、S220和S230与方法100中的S110、S120和S130基本相同。
根据本发明的一个实施例,在方法200的S210之前,还可以包括S202和S204。
在S202中,向目的端发送用于确定目的端是否支持端口扫描报文的协商请求报文。
当利用根据本发明实施例的检测故障的方法对网络进行测量时,源端不能确定目的端是否也支持该方法,也就是说,源端不能确定目的端是否可以支持端口扫描报文。如果目的端支持端口扫描报文,则目的端可以识别端口扫描报文,知道端口扫描报文是用于进行网络故障检测的,其携带的端口对表明与该端口对相应的路径没有故障,并在未接收到某端口对的情况下向源端返回故障信息。
由于源端不能确定目的端是否支持端口扫描报文,所以源端可以向目的端发送协商请求报文来判断目的端是否支持端口扫描报文,以防止在目的端不支持端口扫描报文的情况下无谓地进行根据本发明实施例的故障检测,从而避免给不支持端口扫描报文的目的端造成处理负担,影响目的端的处理性能。
在S204中,接收目的端发送的用于表示支持端口扫描报文的协商响应报文。
如果目的端支持端口扫描报文,即可以支持根据本发明实施例的检测故障的方法,则向目的端返回协商响应报文。否则,对于协商请求报文不做出响应,或者以表示不支持端口扫描报文的形式做出响应。
根据本发明的一个实施例,源端可以采用如图3所示的方法300,来确定目的端是否支持端口扫描报文。
在S310中,向目的端发送ICMP回显请求报文,在ICMP回显请求报文的选项字段中填充第一标识符。
例如,可以在ICMP回显请求报文的选项字段即数据域中填充第一标识符A,A可以使特殊字符串。将在选项字段中携带A的ICMP回显请求报文发送给目的端。
在S320中,接收从目的端返回的ICMP回显响应报文。
响应于ICMP回显请求报文,目的端会返回ICMP回显响应报文。
在S330中,确定在ICMP回显响应报文的选项字段中是否填充有与第一标识符不同的第二标识符。
源端在ICMP回显请求报文的选项字段填充的第一标识符是为了帮助判断目的端是否支持端口扫描报文。
如果目的端支持端口扫描报文,即支持根据本发明实施例提供的检测故障的方法,目的端可以将与第一标识符A不同的第二标识B填充在ICMP回显响应报文中返回给源端。第二标识符B也可以是特定字符串,只要与第一标识符A不同即可。
如果目的端不支持端口扫描报文,则目的端不知道第一标识符A的含义。目的端在返回ICMP回显响应报文时,不会修改第一标识符A。也就是说,如果目的端不支持端口扫描报文,则目的端返回的ICMP回显响应报文仍在选项字段携带第一标识符A。
在S340中,如果确定填充有第二标识符,则确定ICMP回显响应报文是协商响应报文。
如果在S320中确定在ICMP回显响应报文中的选项字段中携带有第二标识符,则表明目的端支持端口扫描报文,即支持根据本发明实施例的检测故障的方法,此时的ICMP回显响应报文就是表明目的端支持端口扫描报文的协商响应报文。
根据本发明实施例提供的确定目的端是否支持端口扫描报文的方法,可以利用现有的ICMP回显请求报文和ICMP回显响应报文,在进行Ping操作的同时仅仅在选项字段中填充标识符,就可以方便地确定目的端是否支持端口扫描报文,实现简单。
返回图2,根据本发明的一个实施例,方法200在S230之后还可以包括S232和S234。
在S232中,基于响应报文携带的端口对,向目的端发送故障定位报文。
响应报文中携带的端口对表明与该端口对相应的路径存在故障,因此源端可以进一步对存在故障的路径进行故障定位,以确定是哪个网段或哪个路由器出现了故障。
为了对故障进行定位,源端可以采用Traceroute操作的方式。在源端发送给目的端的故障定位报文中,可以采用与端口扫描报文相同的源端口号和目的端口号,来使得故障定位报文与端口扫描报文经过相同的路径。如果网络的路由还与协议号有关,则故障定位报文还需要采用与端口扫描报文相同的协议号,但只要固定了协议号,携带相同的端口号就可以经过相同的路径。因此,在确定出现故障的路径对应的源端口号和目的端口号的情况下,在故障定位报文中携带故障端口对,就可以通过Traceroute操作方式在故障路径上进行故障定位。
例如,当用于检测故障的端口扫描报文采用协议号为17的UDP数据报时,用于定位故障的故障定位报文也采用协议号为17的UDP数据报。当端口扫描报文采用协议号为6的TCP数据报时,故障定位报文也采用协议号为6的TCP数据报。这样,端口扫描报文和故障定位报文的5元组相同,经过相同的路径,从而使得故障定位报文经过存在故障的路径,完成对故障的定位。此时通过UDP数据报或TCP数据报来完成Tracerout操作,在UDP数据报或TCP数据报中携带目的端通过响应报文返回的端口对信息,使UDP数据报或TCP数据报经过存在故障的路径。
在S234中,基于故障定位报文的TTL字段,在路径上进行故障定位。
采用修改TTL字段进行故障定位的方式与相关技术基本相同。具体过程如下:
例如,当利用UDP数据报进行故障定位时,源端向目的端发送TTL字段为1的UDP数据报(故障定位报文的例子)。在该UDP数据报中,源IP地址为源端IP地址,目的IP地址为目的端IP地址,协议号为17,源端口号为出现故障的源端口号(即响应消息返回的端口对中的源端口号),目的端口号为出现故障的目的端口号(即响应消息返回的端口对中的目的端口号)。处理该UDP数据报的第一个路由器将TTL值减1,发现TTL为0,丢弃该UDP数据报,并返回ICMP超时报文(类型为11),这样就得到了该路径中的第一个路由器的IP地址。
然后,源端向目的端发送TTL字段为2的UDP数据报,UDP数据报中的5元组同上。第一个路由器将TTL减1后发现不为0,则转发给第二个路由器。第二个路由器将TTL减1后发现等于0,丢弃该UDP数据报,并返回ICMP超时报文,这样就得到了该路径中的第二个路由器的IP地址。
继续这个过程直到某个TTL取值的UDP数据报发出后,没有接收到ICMP超时报文。没有返回ICMP超时报文的路由器就是故障点,通过故障点可以确定该路由器存在故障,或者该路由器与其上一跳路由器之间的网段存在故障。
根据本发明实施例提供的检测故障的方法,通过在检测故障之前,首先确定目的端是否支持端口扫描报文,可以防止盲目地发送端口扫描报文,对不支持端口扫描报文的目的端造成不必要的处理负担,从而使得检测故障的方法可以有效地执行。通过在检测故障之后,利用诸如UDP数据报、TCP数据报之类的故障定位报文来基于Traceroute操作对故障进行定位,可以更准确地确定故障发生的具体位置,利于故障的排除和修复。
接下来,参考图4描述利用检测故障的方法在RNC和UMG之间检测故障并进行故障定位的例子。
随着电信IP化的进展,越来越多的运营商逐渐将其语音业务搬迁到IP网络中,语音数据报文途径的路径例如基站1-RNC1-UMG1-RNC2-基站2均承载在IP承载网上,而IP承载网多数启动了基于5元组的负载分担,不同用户的语音业务可能分别在不同的承载路径上,当出现故障时难以检测并定位故障。
当需要在RNC(如RNC1)和UMG(如UMG1)之间检测故障时,可以利用根据本发明实施例的检测故障的方法。在图4中示出了检测RNC和UMG之间故障的示意图,其中源端为RNC,目的端为UMG。
在S410中,RNC向UMG发送协商请求报文,协商请求报文采用ICMP回显请求报文,并在ICMP回显请求报文中的选项字段中填充特殊字符串A。
在S420中,UMG向RNC返回协商响应报文,表明UMG也支持根据本发明实施例的检测故障的方法。协商响应报文采用ICMP回显响应报文,并在ICMP回显响应报文中的选项字段中填充特殊字符串B。
在S430中,RNC顺序扫描端口对,基于当前扫描的端口对,发送携带该端口对的端口扫描报文。由于一对用户的通话占用相同的源端口号和目的端口号,所以扫描采用源端口号等于目的端口号的方式进行顺序遍历。端口扫描报文的源IP地址为RNC的IP地址,目的IP地址为UMG的IP地址,协议号为17,源端口号和目的端口号相等。以0至65535顺序遍历,每个端口号发送3个相同的端口扫描报文。
在S440中,如果UMG发现没有接收到与某个端口对相应的端口扫描报文,则向RNC发送响应报文,以返回端口扫描的故障信息。例如,如果UMG接收到端口号100的端口扫描报文、但没有接收到端口号99的端口扫描报文,则向RNC返回携带端口号99的响应报文。响应报文可以采用ICMP报文,也可以采用其他形式。
在S450中,RNC接收到响应报文之后,停止端口扫描,根据从响应报文中获取的故障信息,对故障端口(例如端口号99)相应的路径进行故障定位,向UMG发送故障定位报文。在故障定位报文中,源IP地址是RNC的IP地址,目的IP地址是UMG的IP地址,协议号是17,源端口号和目的端口号都是故障端口号(例如端口号99)。采用Traceroute操作的方式,通过修改TTL取值来发送故障定位报文。
在S460中,在故障路径上接收到故障定位报文的路由器将TTL值减1,如果TTL为0,则返回故障定位响应报文即ICMP超时报文。故障定位报文和故障定位响应报文的操作类似于Traceroute操作,可以参考图2的方法200中的S232和S234。基于在故障路径上没有返回ICMP超时报文的路由器,可以定位故障所在。
上面描述了根据本发明实施例的检测故障的方法,下面结合图5和图6描述用于检测故障的系统的结构框图。
如图5所示,用于检测故障的系统500包括源测量点510和目的测量点560。源测量点510和目的测量点560可以是网络中的网元,也可以是位于网元上的功能模块。通过在源测量点510和目的测量点560之间执行上述方法,可以检测源测量点510和目的测量点560之间多条路径(如多条等价路径)的故障。
源测量点510包括第一发送模块520、第一接收模块525和第一确定模块530。第一发送模块520可用于向目的测量点560发送基于至少两个端口对的端口扫描报文,其中每个端口对包括源端口号和目的端口号,并与源测量点510和目的测量点560之间的一条路径相对应。第一接收模块525可用于接收目的测量点560发送的响应报文,响应报文携带目的测量点560基于端口扫描报文确定的未接收到的端口对。第一确定模块530可用于基于响应报文携带的端口对,确定出现故障的路径。
目的测量点560包括第二接收模块565、第二确定模块570和第二发送模块575。第二接收模块565可用于接收来自源测量点510的端口扫描报文。第二确定模块570可用于基于端口扫描报文,确定未接收到的端口对。第二发送模块575可用于向源测量点510发送携带所确定的端口对的响应报文。
目的测量点560的操作和源测量点510的操作相对应。其中,目的测量点560的第二接收模块565接收由源测量点510的第一发送模块520发送的端口扫描报文。目的测量点560的第二发送模块575向源测量点510的第一接收模块525发送响应报文,响应报文携带的端口对由目的测量点560的第二确定模块570得出。因此,第一发送模块520、第一接收模块525、第一确定模块530、第二接收模块565、第二确定模块570和第二发送模块575的上述和其他操作和/或功能可以参考上述检测故障的方法100的S110至S130中的相应部分,为了避免重复,在此不再赘述。
在根据本发明实施例提供的系统中,源测量点基于多个端口对来发送用于检测路径故障的端口扫描报文,使得端口扫描报文可以经过多条路径到达目的测量点,从而目的测量点可以基于接收到的端口扫描报文中携带的端口号来确定未接收到的端口对,基于未接收到的端口对就可以确定存在故障的路径。这样,端口扫描报文可以经过与不同端口对相应的路径,实现对源测量点和目的测量点之间多条路径的检测,相比相关技术只能检测到一条路径的情况,可以实现更加有效的故障检测,准确发现网络中故障的存在。
图6是根据本发明实施例的用于检测故障的系统600的结构框图。
系统600包括源测量点610和目的测量点660。源测量点610中的第一发送模块620、第一接收模块625和第一确定模块630与源测量点510中的第一发送模块520、第一接收模块525和第一确定模块530基本相同。目的测量点660中的第二接收模块665、第二确定模块670和第二发送模块675与目的测量点510中的第二接收模块565、第二确定模块570和第二发送模块575基本相同。
根据本发明的一个实施例,源测量点610的第一发送模块620可以包括遍历单元621和发送单元622。遍历单元621可用于顺序遍历至少两个端口对。发送单元622可用于基于当前遍历的端口对,向目的测量点660发送基于该端口对的端口扫描报文。
根据本发明的一个实施例,第一发送模块620可用于向目的测量点660发送基于至少两个端口对的端口扫描报文,每个端口对中的源端口号和目的端口号相等。这样,基于端口对扫描时,按照源端口号等于目的端口号的方式进行顺序扫描。
根据本发明的一个实施例,源测量点610还可以包括第三发送模块635和第三接收模块640。第三发送模块635可用于向目的测量点660发送用于确定目的测量点660是否支持端口扫描报文的协商请求报文。第三接收模块640可用于接收目的测量点660发送的用于表示支持端口扫描报文的协商响应报文。
根据本发明的一个实施例,第三接收模块635可用于向目的测量点660发送ICMP回显请求报文,在ICMP回显请求报文的选项字段中填充第一标识符。此时,第三接收模块640可以包括接收单元641、第一确定单元642和第二确定单元643。接收单元641可用于接收从目的测量点660返回的ICMP回显响应报文。第一确定单元642可用于确定在ICMP回显响应报文的选项字段中是否填充有与第一标识符不同的第二标识符。第二确定单元643可用于如果确定填充有第二标识符,则确定ICMP回显响应报文是协商响应报文。
根据本发明的一个实施例,第一发送模块620发送的端口扫描报文可以通过IP头部中的DF标志位、MF标志位和偏移字段来进行标识。
例如,在端口扫描报文中,DF标志位的值为1,用于表示不进行分片;MF标志位的值为0,用于表示没有更多的分片;偏移字段的值不全为0,用于结合DF标识位和MF标识符表示该报文是端口扫描报文。
根据本发明的一个实施例,源测量点610还可以包括第四发送模块645和定位模块650。第四发送模块645可用于基于响应报文携带的端口对,向目的测量点660发送故障定位报文。定位模块650可用于基于故障定位报文的TTL字段,在路径上进行故障定位。
第一发送模块620、第三发送模块535、第三接收模块540、接收单元641、第一确定单元642、第二确定单元643、第四发送模块645和定位模块650的上述和其他操作和/或功能可以参考上述方法100中的S110、方法200中的S202、S204、S232和S234以及方法300中的S310至S340。
根据本发明实施例提供的系统中的源测量点,利用第三发送模块和第三接收模块,可以通过在检测故障之前首先确定目的测量点是否支持端口扫描报文,从而防止盲目地发送端口扫描报文,对不支持端口扫描报文的目的端造成不必要的处理负担,以使得检测故障的过程可以有效地执行。当利用现有的ICMP回显请求报文和ICMP回显响应报文确定目的测量点是否支持端口扫描报文时,由于在进行Ping操作的同时仅仅在选项字段中填充标识符,所以可以方便地确定目的测量点是否支持端口扫描报文,实现简单。另外,利用第四发送模块和定位模块,可以通过在检测故障之后利用诸如UDP数据报、TCP数据报之类的故障定位报文,基于Traceroute操作对故障进行定位,从而可以更准确地确定故障发生的具体位置,有利于故障的排除和修复。
本领域技术人员可以意识到,结合本文中所公开的实施例中描述的各方法步骤和单元,能够以电子硬件、计算机软件或者二者的结合来实现,为了清楚地说明硬件和软件的可互换性,在上述说明中已经按照功能一般性地描述了各实施例的步骤及组成。这些功能究竟以硬件还是软件方式来执行,取决于技术方案的特定应用和设计约束条件。本领域技术人员可以对每个特定的应用使用不同方法来实现所描述的功能,但是这种实现不应认为超出本发明的范围。
结合本文中所公开的实施例描述的方法步骤可以用硬件、处理器执行的软件程序、或者二者的结合来实施。软件程序可以置于随机存取存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM或技术领域内所公知的任意其它形式的存储介质中。
尽管已示出和描述了本发明的一些实施例,但本领域技术人员应该理解,在不脱离本发明的原理和精神的情况下,可对这些实施例进行各种修改,这样的修改应落入本发明的范围内。
Claims (17)
1.一种检测故障的方法,其特征在于,包括:
向目的端发送基于至少两个端口对的端口扫描报文,其中每个端口对包括源端口号和目的端口号,并与源端和所述目的端之间的一条路径相对应;
接收所述目的端发送的响应报文,所述响应报文携带所述目的端基于所述端口扫描报文确定的未接收到的端口对;
基于所述响应报文携带的端口对,确定出现故障的路径。
2.根据权利要求1所述的方法,其特征在于,所述向目的端发送基于至少两个端口对的端口扫描报文包括:
顺序遍历所述至少两个端口对;
基于当前遍历的端口对,向所述目的端发送基于该端口对的端口扫描报文。
3.根据权利要求1所述的方法,其特征在于,所述向目的端发送基于至少两个端口对的端口扫描报文包括:
向目的端发送基于至少两个端口对的端口扫描报文,每个端口对中的源端口号和目的端口号相等。
4.根据权利要求1所述的方法,其特征在于,所述向目的端发送基于至少两个端口对的端口扫描报文之前,还包括:
向所述目的端发送用于确定所述目的端是否支持所述端口扫描报文的协商请求报文;
接收所述目的端发送的用于表示支持所述端口扫描报文的协商响应报文。
5.根据权利要求4所述的方法,其特征在于,所述向所述目的端发送用于确定所述目的端是否支持所述端口扫描报文的协商请求报文包括:
向所述目的端发送ICMP回显请求报文,在所述ICMP回显请求报文的选项字段中填充第一标识符,
其中,所述接收所述目的端发送的用于表示支持所述端口扫描报文的协商响应报文包括:
接收从所述目的端返回的ICMP回显响应报文;
确定在所述ICMP回显响应报文的选项字段中是否填充有与所述第一标识符不同的第二标识符;
如果确定填充有所述第二标识符,则确定所述ICMP回显响应报文是所述协商响应报文。
6.根据权利要求1所述的方法,其特征在于,所述向目的端发送基于至少两个端口对的端口扫描报文包括:
向目的端发送基于至少两个端口对的端口扫描报文,所述端口扫描报文通过IP头部中的DF标志位、MF标志位和偏移字段来进行标识。
7.根据权利要求6所述的方法,其特征在于,所述端口扫描报文通过IP头部中的DF标志位、MF标志位和偏移字段来进行标识包括:
所述DF标志位的值为1,用于表示不进行分片;
所述MF标志位的值为0,用于表示没有更多的分片;
所述偏移字段的值不全为0,用于结合所述DF标识位和所述MF标识符表示该报文是端口扫描报文。
8.根据权利要求1所述的方法,其特征在于,还包括:
基于所述响应报文携带的端口对,向所述目的端发送故障定位报文;
基于所述故障定位报文的TTL字段,在所述路径上进行故障定位。
9.根据权利要求8所述的方法,其特征在于,所述端口扫描报文和所述故障定位报文采用用户数据报协议和传输控制协议之一。
10.一种用于检测故障的系统,其特征在于,包括源测量点和目的测量点,其中:
所述源测量点包括:
第一发送模块,用于向所述目的测量点发送基于至少两个端口对的端口扫描报文,其中每个端口对包括源端口号和目的端口号,并与所述源测量点和所述目的测量点之间的一条路径相对应;
第一接收模块,用于接收所述目的测量点发送的响应报文,所述响应报文携带所述目的测量点基于所述端口扫描报文确定的未接收到的端口对;
第一确定模块,用于基于所述响应报文携带的端口对,确定出现故障的路径,
所述目的测量点包括:
第二接收模块,用于接收来自所述源测量点的所述端口扫描报文;
第二确定模块,用于基于所述端口扫描报文,确定未接收到的端口对;
第二发送模块,用于向所述源测量点发送携带所确定的端口对的响应报文。
11.根据权利要求10所述的系统,其特征在于,所述第一发送模块包括:
遍历单元,用于顺序遍历所述至少两个端口对;
发送单元,用于基于当前遍历的端口对,向所述目的测量点发送基于该端口对的端口扫描报文。
12.根据权利要求10所述的系统,其特征在于,所述第一发送模块用于向所述目的测量点发送基于至少两个端口对的端口扫描报文,每个端口对中的源端口号和目的端口号相等。
13.根据权利要求10所述的系统,其特征在于,所述源测量点还包括:
第三发送模块,用于向所述目的测量点发送用于确定所述目的测量点是否支持所述端口扫描报文的协商请求报文;
第三接收模块,用于接收所述目的测量点发送的用于表示支持所述端口扫描报文的协商响应报文。
14.根据权利要求13所述的系统,其特征在于,所述第三发送模块用于向所述目的测量点发送ICMP回显请求报文,在所述ICMP回显请求报文的选项字段中填充第一标识符;
其中,所述第三接收模块包括:
接收单元,用于接收从所述目的测量点返回的ICMP回显响应报文;
第一确定单元,用于确定在所述ICMP回显响应报文的选项字段中是否填充有与所述第一标识符不同的第二标识符;
第二确定单元,用于如果确定填充有所述第二标识符,则确定所述ICMP回显响应报文是所述协商响应报文。
15.根据权利要求10所述的系统,其特征在于,所述第一发送模块用于向目的端发送基于至少两个端口对的端口扫描报文,所述端口扫描报文通过IP头部中的DF标志位、MF标志位和偏移字段来进行标识。
16.根据权利要求15所述的系统,其特征在于,所述端口扫描报文通过IP头部中的DF标志位、MF标志位和偏移字段来进行标识包括:
所述DF标志位的值为1,用于表示不进行分片;
所述MF标志位的值为0,用于表示没有更多的分片;
所述偏移字段的值不全为0,用于结合所述DF标识位和所述MF标识符表示该报文是端口扫描报文。
17.根据权利要求10所述的系统,其特征在于,所述源测量点还包括:
第四发送模块,用于基于所述响应报文携带的端口对,向所述目的测量点发送故障定位报文;
定位模块,用于基于所述故障定位报文的TTL字段,在所述路径上进行故障定位。
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/CN2011/073144 WO2011110118A2 (zh) | 2011-04-21 | 2011-04-21 | 检测故障的方法和系统 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN102177681A true CN102177681A (zh) | 2011-09-07 |
CN102177681B CN102177681B (zh) | 2013-04-24 |
Family
ID=44519900
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN2011800003150A Active CN102177681B (zh) | 2011-04-21 | 2011-04-21 | 检测故障的方法和系统 |
Country Status (4)
Country | Link |
---|---|
US (1) | US9203716B2 (zh) |
EP (1) | EP2611075B1 (zh) |
CN (1) | CN102177681B (zh) |
WO (1) | WO2011110118A2 (zh) |
Cited By (19)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103166786A (zh) * | 2011-12-15 | 2013-06-19 | 中兴通讯股份有限公司 | 一种实现链路跟踪的方法和系统 |
CN104053176A (zh) * | 2014-06-26 | 2014-09-17 | 国家计算机网络与信息安全管理中心 | 一种基于traceroute的运营商核心节点识别方法 |
WO2016082588A1 (zh) * | 2014-11-26 | 2016-06-02 | 中兴通讯股份有限公司 | 链路连通性检测方法及装置 |
CN105939212A (zh) * | 2016-02-25 | 2016-09-14 | 杭州迪普科技有限公司 | 状态探测的方法及装置 |
WO2017008712A1 (zh) * | 2015-07-10 | 2017-01-19 | 杭州华三通信技术有限公司 | Vxlan隧道端点vtep之间的路径可达检测 |
WO2017050198A1 (zh) * | 2015-09-25 | 2017-03-30 | 华为技术有限公司 | 路径检测方法和装置 |
CN107171882A (zh) * | 2016-03-08 | 2017-09-15 | 华为技术有限公司 | 检测等价多路径路由功能的方法、设备和系统 |
CN107342908A (zh) * | 2016-11-30 | 2017-11-10 | 新华三技术有限公司 | 一种发送双向转发检测报文的方法和装置 |
WO2017202166A1 (zh) * | 2016-05-23 | 2017-11-30 | 中兴通讯股份有限公司 | 一种报文传输方法和发送设备、存储介质 |
CN107948989A (zh) * | 2016-10-13 | 2018-04-20 | 北京国双科技有限公司 | 一种移动终端联网时长的计算方法及装置 |
CN108737206A (zh) * | 2017-04-24 | 2018-11-02 | 中兴通讯股份有限公司 | 网络通道的选路方法、装置及其计算机设备 |
CN110290067A (zh) * | 2019-07-01 | 2019-09-27 | 北京云端智度科技有限公司 | 一种基于多次协议测试的端到端网络路径的发现方法 |
CN111245666A (zh) * | 2018-11-29 | 2020-06-05 | 华为技术有限公司 | 数据传输方法、装置及系统 |
CN112787881A (zh) * | 2019-11-11 | 2021-05-11 | 中兴通讯股份有限公司 | 通信链路检测方法、通信装置、存储介质 |
CN112787857A (zh) * | 2020-12-29 | 2021-05-11 | 中国航空工业集团公司西安飞机设计研究所 | 一种远程数据集中器数据监控与故障定位方法 |
CN113300873A (zh) * | 2021-02-05 | 2021-08-24 | 阿里巴巴集团控股有限公司 | 基于五元组哈希路径的故障绕行方法以及装置 |
CN113890838A (zh) * | 2021-09-24 | 2022-01-04 | 天津津航计算技术研究所 | 一种基于icmp协议的网络连通性能判断方法 |
CN114978868A (zh) * | 2022-07-01 | 2022-08-30 | 杭州迪普科技股份有限公司 | 基于oam环路自检网络报文加速芯片功能异常的方法和装置 |
CN113300873B (zh) * | 2021-02-05 | 2024-05-24 | 阿里巴巴集团控股有限公司 | 基于五元组哈希路径的故障绕行方法以及装置 |
Families Citing this family (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP5842641B2 (ja) * | 2012-01-31 | 2016-01-13 | 富士通株式会社 | 通信システム、および生成装置 |
US9239749B2 (en) * | 2012-05-04 | 2016-01-19 | Paraccel Llc | Network fault detection and reconfiguration |
US9311022B2 (en) * | 2013-10-07 | 2016-04-12 | Dell Products L.P. | System and method for improved communication in a storage network |
US9813911B2 (en) * | 2015-12-08 | 2017-11-07 | Panasonic Avionics Corporation | Methods and systems for monitoring computing devices on a vehicle |
CN105847460B (zh) * | 2016-03-15 | 2018-12-28 | 迈普通信技术股份有限公司 | 一种实现双向转发检测的方法及设备 |
US10298491B2 (en) * | 2016-08-25 | 2019-05-21 | Cisco Technology, Inc. | Efficient path detection and validation between endpoints in large datacenters |
CN106130800B (zh) * | 2016-08-29 | 2020-01-03 | 杭州迪普科技股份有限公司 | 一种数据帧的处理方法及装置 |
US10320954B2 (en) | 2017-02-03 | 2019-06-11 | Microsoft Technology Licensing, Llc | Diffusing packets to identify faulty network apparatuses in multipath inter-data center networks |
US20180278514A1 (en) * | 2017-03-27 | 2018-09-27 | Juniper Networks, Inc. | Traceroute for multi-path routing |
CN108776625A (zh) * | 2018-06-26 | 2018-11-09 | 郑州云海信息技术有限公司 | 一种服务故障的修复方法、装置和存储介质 |
CN112994961B (zh) * | 2019-12-02 | 2023-02-07 | 华为技术有限公司 | 传输质量检测方法及装置、系统、存储介质 |
US11398970B2 (en) | 2020-08-05 | 2022-07-26 | Cisco Technology, Inc. | Internet last-mile outage detection using IP-route clustering |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1610496A1 (en) * | 2004-06-18 | 2005-12-28 | Avaya Technology Corp. | Rapid fault detection and recovery for internet protocol telephony |
CN101459547A (zh) * | 2007-12-13 | 2009-06-17 | 华为技术有限公司 | 标签转发路径故障的检测方法及系统 |
CN101471822A (zh) * | 2007-12-29 | 2009-07-01 | 华为技术有限公司 | 一种定位网络故障的方法和系统 |
Family Cites Families (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020120730A1 (en) * | 2001-02-27 | 2002-08-29 | Goudzwaard Daniel John | Reliability for simple network management protocol trap messages |
JP2005260321A (ja) * | 2004-03-09 | 2005-09-22 | Nec Corp | ラベルパスネットワークの迂回制御方式 |
JP4334419B2 (ja) * | 2004-06-30 | 2009-09-30 | 富士通株式会社 | 伝送装置 |
US8040893B2 (en) * | 2004-08-11 | 2011-10-18 | Alcatel Lucent | Method for fast source routed connection setup |
JP4840236B2 (ja) * | 2007-04-12 | 2011-12-21 | 株式会社日立製作所 | ネットワークシステム及びノード装置 |
US7962957B2 (en) * | 2007-04-23 | 2011-06-14 | International Business Machines Corporation | Method and apparatus for detecting port scans with fake source address |
-
2011
- 2011-04-21 WO PCT/CN2011/073144 patent/WO2011110118A2/zh active Application Filing
- 2011-04-21 EP EP11752861.2A patent/EP2611075B1/en active Active
- 2011-04-21 CN CN2011800003150A patent/CN102177681B/zh active Active
-
2013
- 2013-06-28 US US13/931,041 patent/US9203716B2/en active Active
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1610496A1 (en) * | 2004-06-18 | 2005-12-28 | Avaya Technology Corp. | Rapid fault detection and recovery for internet protocol telephony |
CN101459547A (zh) * | 2007-12-13 | 2009-06-17 | 华为技术有限公司 | 标签转发路径故障的检测方法及系统 |
CN101471822A (zh) * | 2007-12-29 | 2009-07-01 | 华为技术有限公司 | 一种定位网络故障的方法和系统 |
Cited By (29)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103166786A (zh) * | 2011-12-15 | 2013-06-19 | 中兴通讯股份有限公司 | 一种实现链路跟踪的方法和系统 |
CN103166786B (zh) * | 2011-12-15 | 2019-03-08 | 中兴通讯股份有限公司 | 一种实现链路跟踪的方法和系统 |
CN104053176B (zh) * | 2014-06-26 | 2017-10-17 | 国家计算机网络与信息安全管理中心 | 一种基于traceroute的运营商核心节点识别方法 |
CN104053176A (zh) * | 2014-06-26 | 2014-09-17 | 国家计算机网络与信息安全管理中心 | 一种基于traceroute的运营商核心节点识别方法 |
WO2016082588A1 (zh) * | 2014-11-26 | 2016-06-02 | 中兴通讯股份有限公司 | 链路连通性检测方法及装置 |
WO2017008712A1 (zh) * | 2015-07-10 | 2017-01-19 | 杭州华三通信技术有限公司 | Vxlan隧道端点vtep之间的路径可达检测 |
US10659253B2 (en) | 2015-09-25 | 2020-05-19 | Huawei Technologies Co., Ltd. | Path detection method and apparatus |
WO2017050198A1 (zh) * | 2015-09-25 | 2017-03-30 | 华为技术有限公司 | 路径检测方法和装置 |
CN106559325A (zh) * | 2015-09-25 | 2017-04-05 | 华为技术有限公司 | 路径检测方法和装置 |
CN106559325B (zh) * | 2015-09-25 | 2020-06-09 | 华为技术有限公司 | 路径检测方法和装置 |
CN105939212A (zh) * | 2016-02-25 | 2016-09-14 | 杭州迪普科技有限公司 | 状态探测的方法及装置 |
CN107171882B (zh) * | 2016-03-08 | 2021-02-09 | 华为技术有限公司 | 检测等价多路径路由功能的方法、设备和系统 |
CN107171882A (zh) * | 2016-03-08 | 2017-09-15 | 华为技术有限公司 | 检测等价多路径路由功能的方法、设备和系统 |
WO2017202166A1 (zh) * | 2016-05-23 | 2017-11-30 | 中兴通讯股份有限公司 | 一种报文传输方法和发送设备、存储介质 |
CN107948989A (zh) * | 2016-10-13 | 2018-04-20 | 北京国双科技有限公司 | 一种移动终端联网时长的计算方法及装置 |
CN107948989B (zh) * | 2016-10-13 | 2021-02-12 | 北京国双科技有限公司 | 一种移动终端联网时长的计算方法及装置 |
CN107342908A (zh) * | 2016-11-30 | 2017-11-10 | 新华三技术有限公司 | 一种发送双向转发检测报文的方法和装置 |
CN108737206A (zh) * | 2017-04-24 | 2018-11-02 | 中兴通讯股份有限公司 | 网络通道的选路方法、装置及其计算机设备 |
CN108737206B (zh) * | 2017-04-24 | 2021-11-12 | 中兴通讯股份有限公司 | 网络通道的选路方法、装置及其计算机设备 |
CN111245666A (zh) * | 2018-11-29 | 2020-06-05 | 华为技术有限公司 | 数据传输方法、装置及系统 |
CN111245666B (zh) * | 2018-11-29 | 2022-12-06 | 华为技术有限公司 | 数据传输方法、装置及系统 |
CN110290067A (zh) * | 2019-07-01 | 2019-09-27 | 北京云端智度科技有限公司 | 一种基于多次协议测试的端到端网络路径的发现方法 |
CN112787881A (zh) * | 2019-11-11 | 2021-05-11 | 中兴通讯股份有限公司 | 通信链路检测方法、通信装置、存储介质 |
CN112787857A (zh) * | 2020-12-29 | 2021-05-11 | 中国航空工业集团公司西安飞机设计研究所 | 一种远程数据集中器数据监控与故障定位方法 |
CN113300873A (zh) * | 2021-02-05 | 2021-08-24 | 阿里巴巴集团控股有限公司 | 基于五元组哈希路径的故障绕行方法以及装置 |
CN113300873B (zh) * | 2021-02-05 | 2024-05-24 | 阿里巴巴集团控股有限公司 | 基于五元组哈希路径的故障绕行方法以及装置 |
CN113890838A (zh) * | 2021-09-24 | 2022-01-04 | 天津津航计算技术研究所 | 一种基于icmp协议的网络连通性能判断方法 |
CN114978868A (zh) * | 2022-07-01 | 2022-08-30 | 杭州迪普科技股份有限公司 | 基于oam环路自检网络报文加速芯片功能异常的方法和装置 |
CN114978868B (zh) * | 2022-07-01 | 2023-04-25 | 杭州迪普科技股份有限公司 | 基于oam环路自检网络报文加速芯片功能异常的方法和装置 |
Also Published As
Publication number | Publication date |
---|---|
CN102177681B (zh) | 2013-04-24 |
WO2011110118A3 (zh) | 2012-03-22 |
US20130286859A1 (en) | 2013-10-31 |
US9203716B2 (en) | 2015-12-01 |
EP2611075B1 (en) | 2018-01-24 |
WO2011110118A2 (zh) | 2011-09-15 |
EP2611075A4 (en) | 2013-07-17 |
EP2611075A2 (en) | 2013-07-03 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN102177681B (zh) | 检测故障的方法和系统 | |
US7852778B1 (en) | Verification of network paths using two or more connectivity protocols | |
US9497107B1 (en) | Seamless path monitoring and rapid fault isolation using bidirectional forwarding detection in a network environment | |
US9344325B2 (en) | System, method and apparatus providing MVPN fast failover | |
CN101174975B (zh) | 一种以太网中的链路故障定位方法及系统 | |
CN107925629B (zh) | 一种IPv6网络中数据报文的发送方法及装置 | |
US8559318B2 (en) | Method, node and system for obtaining link aggregation group information | |
US9294369B2 (en) | Method and device for processing location information of fault point | |
CN102281200B (zh) | 选取当前备份路由的方法和路由器 | |
EP2536066A1 (en) | Link detecting method, apparatus and system | |
EP2436152B1 (en) | Failure localisation in a mpls-tp network | |
US8107388B2 (en) | Route tracing program configured to detect particular network element making type of service modification | |
CN108270602B (zh) | 一种数据链路的检测方法、装置及系统 | |
WO2008148334A1 (fr) | Procédé, système et appareil pour détecter la réception anormale d'un message | |
EP3001615B1 (en) | Bit error rate detecting method and network device | |
US10567272B2 (en) | Bit error information transfer method, network device, and communications system | |
US11962491B2 (en) | Source routing tunnel ingress protection | |
US20120134365A1 (en) | Method and network device for associated channel capability negotiation | |
CN102195832A (zh) | 一种环回测试方法、装置及系统 | |
US20120218883A1 (en) | Multicast fast re-route | |
US8254271B1 (en) | Point-to-multipoint connectivity verification | |
CN103297340A (zh) | Mpls和bgp组网中的路由收敛方法和设备 | |
CN101640672A (zh) | 一种网际协议网络的故障定位检测方法、系统和装置 | |
CN100438452C (zh) | 下一代网络中检测信令或媒体路径故障的方法和设备 | |
CN105634776A (zh) | 一种确定报文转发接口的方法及设备 |
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 |