CN106411642A - 一种报文转发路径探测的方法和装置 - Google Patents

Abstract

本申请提供一种报文转发路径探测的方法和装置，应用于UMC服务器，所述方法包括：将用户预配置的目标报文特征分别下发至所述若干转发设备；接收所述若干转发设备发送的从基于所述目标报文特征采集到的目标报文中提取到的路径信息；其中，所述路径信息用于计算所述目标报文的转发路径；针对各转发设备发送的所述路径信息进行统计计算，以得到所述目标报文的转发路径。采用本申请提供的技术方案，可以得到报文完整的转发路径。

Description

一种报文转发路径探测的方法和装置

技术领域

本申请涉及网络通信技术领域，特别涉及一种报文转发路径探测的方法和装置。

背景技术

路径追踪，是指报文在网络中传输时，能够快速地了解到报文的转发路径，并根据报文的转发路径，能快速定位报文的丢包位置以及获取报文的传输延时。

相关技术中，网络技术的迅猛发展导致不仅网络的规模日益扩大，而且网络的复杂度也在不断提升。为了提高整个网络的服务质量和提升路径追踪的精确性，探测到的报文转发路径的完整性显的十分重要。

发明内容

有鉴于此，本申请提供一种报文转发路径探测的方法和装置，应用于UMC服务器。

具体地，本申请是通过如下技术方案实现的：

一种报文转发路径探测的方法，应用于UMC服务器，所述UMC服务器管理若干转发设备，包括：

将用户预配置的目标报文特征分别下发至所述若干转发设备；

接收所述若干转发设备发送的从基于所述目标报文特征采集到的目标报文中提取到的路径信息；其中，所述路径信息用于计算所述目标报文的转发路径；

针对各转发设备发送的所述路径信息进行统计计算，以得到所述目标报文的转发路径。

一种报文转发路径探测的装置，应用于UMC服务器，所述UMC服务器管理若干转发设备，包括：

下发单元，用于将用户预配置的目标报文特征分别下发至所述若干转发设备；

接收单元，用于接收所述若干转发设备发送的从基于所述目标报文特征采集到的目标报文中提取到的路径信息；其中，所述路径信息用于计算所述目标报文的转发路径；

计算单元，用于针对各转发设备发送的所述路径信息进行统计计算，以得到所述目标报文的转发路径。

由以上本申请提供的技术方案可见，所述UMC服务器通过将用户预配置的目标报文特征分别下发至所述若干转发设备，并接收所述若干转发设备发送的从基于所述目标报文特征采集到的目标报文中提取到的路径信息；所述路径信息用于计算所述目标报文的转发路径；然后针对各转发设备发送的所述路径信息进行统计计算，以得到所述目标报文的转发路径。

由于所述转发路径是通过汇总各转发设备从基于所述目标报文特征采集到的目标报文中提取到的路径信息，进行统计计算后得到的，因此可以得到所述目标报文完整的转发路径。

附图说明

图1为相关技术中一示例性实施例示出的一种利用TRACERT协议的报文转发路径探测的方法的场景图；

图2为本申请一示例性实施例示出的一种报文转发路径探测的方法流程图；

图3为本申请一示例性实施例示出的一种报文转发路径探测的方法的场景图；

图4为本申请一示例性实施例示出的一种报文转发路径探测的装置所在UMC服务器的一种硬件结构图

图5为本申请一示例性实施例示出的一种报文转发路径探测的装置。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

相关技术中，报文转发路径的探测，通常是利用TRACERT协议中的TTL超时机制来实现的。它的基本原理是当一台设备需要转发报文时，如果发现报文中的TTL超时，则可以向源地址发送不可达报文。通过构造TTL累加的报文，然后可以逐跳探测报文的转发路径。

请参见图1，图1为相关技术中一示例性实施例示出的一种利用TRACERT协议的报文转发路径探测方法的场景图。

在图1中，源主机与目的主机之间通过分别为A，B，C，D，E的五台转发设备相连。其中，假设这五台转发设备均允许发送TTL超时报文。

结合图1，假设源主机将要向目的主机发送数据报文，且报文在转发设备之间只进行三层转发，为了保证数据的安全性，源主机通常会先获悉报文转发的路径，然后再进行数据报文的发送。相关技术中一般通过TTL超时机制进行报文转发路径的探测，探测过程详见如下描述。

1、首先源主机构造ICMP请求报文，其目的IP地址为要探测的目的主机的IP地址，所述ICMP请求报文的TTL初始值设置为1，然后发送，跳转到步骤3；

2、判断TTL值是否已经达到预设的阈值，如果是，表明探测失败，输出探测到的部分路径，结束；否则，源主机将所述ICMP请求报文的TTL取值累加1，然后重新发送，跳转到步骤3；

3、如果源主机接收到来自目的主机的回应报文，则输出探测到的报文转发路径，结束；否则进行步骤4；

4、如果源主机接收到中间转发设备发送的TTL超时报文，则记录该路径，或者源主机在设定的时间内没有接收到任何报文，则表明该TTL的转发路径探测失败，发生本步骤中的任意一种情况都跳转到步骤2。

然而根据上述方法探测报文的转发路径，至少存在以下缺陷：

第一，如果想要得到完整的报文转发路径，需要转发设备均被允许发送TTL超时报文，然而由于为了数据的安全考虑，很多转发设备都会被禁止发送TTL超时报文，因此无法探测到完整的报文转发路径。

第二，由于上述方法，使用的是IP头中的TTL字段，而该字段只有在进行三层转发时才会递减，，因而只能够用于探测三层转发的转发路径。

第三，由于上述方法中发送TTL超时消息需要设备的控制面来进行，而实际数据在进行转发时，则是在数据面进行的，因而两者之间存在时间差。

第四，由于上述方法没有全网拓扑，且在发送TTL超时时，未提供该报文的下一步转发动作(出口，下一跳地址，MAC地址等)，因而得到的转发路径只是一些零碎的信息，不够连续。

为了解决相关技术中存在的问题，本申请提供了一种报文转发路径探测的方法，应用于UMC服务器，所述UMC服务器通过将用户预配置的目标报文特征分别下发至所述若干转发设备，并接收所述若干转发设备发送的从基于所述目标报文特征采集到的目标报文中提取到的路径信息；所述路径信息用于计算所述目标报文的转发路径；然后针对各转发设备发送的所述路径信息进行统计计算，以得到所述目标报文的转发路径。

由于所述转发路径是通过汇总各转发设备从基于所述目标报文特征采集到的目标报文中提取到的路径信息，进行统计计算后得到的，因此可以得到所述目标报文完整的转发路径。

进一步的，所述UMC服务器在基于所述路径信息探测转发路径时，由于所述路径信息中包含TTL的取值以及报文接收时间，因此通过对TTL或者接收时间进行排序，既可以探测到二层转发路径，也可以探测到三层转发路径。

另外，所述UMC服务器在基于所述路径信息探测转发路径时，由于所述路径信息是由各转发设备在数据层面提取到的，因此通过所述路径信息中的报文接收时间，可以计算出各转发设备之间接收到报文的精确延时。

最后，所述UMC服务器在基于所述路径信息探测转发路径之前，由于UMC服务器收集了全网拓扑信息，并生成了相应的全网拓扑，因此基于生成的全网拓扑来进行转发路径探测，可以确保探测到的转发路径的连续性。

请参见图2，图2为本申请一示例性实施例示出的一种报文转发路径探测的方法流程图，应用于UMC服务器，所述UMC服务器管理若干转发设备，具体执行如下步骤：

步骤201：将用户预配置的目标报文特征分别下发至所述若干转发设备；

步骤202：接收所述若干转发设备发送的从基于所述目标报文特征采集到的目标报文中提取到的路径信息；其中，所述路径信息用于计算所述目标报文的转发路径；

步骤203：针对各转发设备发送的所述路径信息进行统计计算，以得到所述目标报文的转发路径。

其中，上述UMC服务器，用于将报文特征下发给它所管理的转发设备，然后可以通过接收转发设备发送的路径信息，并对所述路径信息进行汇总计算，得到报文的转发路径。得到报文的转发路径之后，所述UMC服务器就可以根据所述报文的转发路径以及每一个转发设备接收到报文的时间，计算得到各转发设备接收到所述目标报文的时间延迟。

上述目标报文特征，即为用户配置的需要探测其转发路径的目标报文的报文特征；在实际应用中，上述目标报文可以是二层报文，也可以是三层报文，因此目标报文特征可以是二层报文特征，也可以是三层报文特征。例如，上述目标报文可以是二层报文中的源MAC以及目的MAC等信息；也可以是三层报文中的IP报文五元组等信息。当然，除了以上描述的二层报文特征和三层报文特征以外，也可以是报文的其它特征，只要能基于所述报文特征，可以区别不同的报文即可。

所述转发设备，用于接收所述UMC服务器发送的用户预配置的报文特征，然后可以将所述报文特征上传至CPU，除此之外，还可以动态地添加ACL(Access Control List，访问控制列表)规则，该规则对应的动作为将与所述报文特征相同的目标报文进行拷贝，然后将所述目标报文上传至CPU。CPU接收到所述拷贝上送的目标报文后，根据报文特征对所述拷贝上送的目标报文进行路径信息的提取，所述路径信息可以是转发设备自身标识、接收到的报文的特征值(包括IP中的ipid，checksum，TTL等关键字段)、接收到报文的时间以及报文入口和出口等信息，最后，转发设备可以将提取到的路径信息进行组包后发送给UMC服务器，由UMC服务器对所述路径信息进一步处理。

以下结合全网拓扑生成、时钟同步、目标报文特征下发、报文上送、路径计算五个阶段，对本申请实施例进行详细描述。

1)、拓扑生成

由于相关技术中，没有全网拓扑，且在发送TTL超时报文时，所述超时报文中未提供ICMP请求报文的下一步转发动作(包括出口、下一跳地址，MAC地址等)，因而得到的转发路径只是一些零碎的信息，不是一条完整的转发路径。因此，为了解决上述问题，所述UMC服务器可以预先进行全网拓扑的生成，便于后续输出的报文转发路径的精确与完整。

在示出的一种实施方式中，为了便于后续输出报文的精确路径，所述UMC服务器可以从所述若干转发设备中收集网络拓扑信息，然后基于收集到的所述网络拓扑信息，生成对应的网络拓扑。

在实现时，所述UMC服务器可以通过标准的snmp或者自定义协议进行网络拓扑的生成。所述UMC服务器从所述若干转发设备收集到的网络拓扑信息包括所述转发设备的接口以及IP地址等信息。

2)、时钟同步

另外，为了后续的报文转发路径的计算，以及基于所述转发路径计算各转发设备接收到所述目标报文的时间延迟，所述若干转发设备的时钟需要保持同步。所述时钟同步过程可以选择使用标准的或者自定义的时钟同步技术来完成。

3)、目标报文特征下发

所述若干转发设备完成时钟同步之后，所述UMC服务器就可以下发所述目标报文特征。所述目标报文特征可以是用户提前配置好的，用于转发设备基于所述目标报文特征匹配到目标报文，然后CPU可以基于所述目标报文特征从所述目标报文中提取出路径信息。

由于要得到符合所述目标报文特征的目标报文完整的转发路径，因此，所述UMC服务器需要将所述目标报文特征通告给它管理的所有转发设备。

如果所述若干转发设备在同一个网段中，所述UMC服务器也可以采用广播的形式将所述目标报文特征分别下发至所述若干转发设备。如果所述若干转发设备不在同一个网段中，所述UMC服务器可以采用组播的形式将所述目标报文特征分别下发至所述若干转发设备。当然，UMC服务器也可以采用其他方式将所述目标报文特征下发至所述若干转发设备，只要保证所有转发设备能接收到所述目标报文特征即可。

4)、报文上送

所述若干转发设备接收到UMC服务器下发的目标报文特征后，可以基于所述目标报文特征匹配到目标报文，并从所述目标报文中提取到所述目标报文的路径信息，最后将所述路径信息发送至所述UMC服务器，由所述UMC服务器基于所述路径信息来统计计算得到所述目标报文的转发路径。

在实现时，所述若干转发设备接收到所述UMC服务器下发的所述目标报文特征后，可以将所述目标报文特征上传至CPU，同时也可以动态地添加ACL规则，所述规则对应的动作为将与所述ACL规则匹配成功的报文上送至CPU。所述若干转发设备添加完该ACL规则后，就可以对需要进行转发的报文进行匹配。如果匹配成功，则表明该报文为目标报文，转发设备就会执行ACL规则对应的动作，它就会拷贝该目标报文，并将该目标报文上送至CPU。同时，为了不影响业务正常运行，转发设备会将该目标报文进行正常转发。

CPU接收到所述拷贝上送的目标报文后，可以基于所述目标报文特征，从所述拷贝上送的目标报文中提取该目标报文的路径信息。所述路径信息可以包括转发设备自身的标识，接收到的目标报文的特征值、接收到报文的时间以及报文的入口和出口等信息。其中，上述目标报文的特征值可以是IP报文头中关键字段的取值。

在示出的一种实施方式中，上述目标报文的特征值，可以包括IP报文头中的ipid，checksum，TTL等关键字段的取值。

CPU提取到所述路径信息后，可以将所述路径信息组包后发送至UMC服务器，由所述UMC服务器根据若干转发设备发送的路径信息，来计算得到所述目标报文的转发路径。

5)、路径计算

UMC服务器接收到转发设备发送的路径信息后，所述UMC服务器可以统计计算所述路径信息来得到所述目标报文的转发路径。

在实现时，UMC服务器接收到转发设备发送的路径信息后，可以从各路径信息中提取出对应的TTL取值、设备标识和报文接收时间。

在示出的一种实施方式中，当UMC服务器管理的各转发设备之间进行三层转发时，在这种场景下，由于在三层转发中，TTL取值会发生递减，因此UMC服务器可以基于TTL取值由大到小的顺序，针对各转发设备发送的路径信息进行排序；然后按顺序提取排序后的所述路径信息中的设备标识，以得到所述目标报文的转发路径。

通过这种方式，可以利用在三层转发过程中，TTL取值会发生递减的特性，通过对TTL取值进行排序，可以探测到完整的三层转发路径。

在示出的一种实施方式中，当UMC服务器管理的各转发设备之间进行二层转发时，由于二层转发的过程中，报文中的TTL字段的取值通常不发生变化，因此在这种情况下，UMC服务器可以基于所述目标报文的报文接收时间由小到大的顺序，针对各转发设备发送的路径信息进行排序；然后按顺序提取排序后的所述路径信息中的设备标识，以得到所述目标报文的转发路径。

通过这种方式，可以利用在二层转发过程中，报文接收时间会发生递增的特性，通过对报文接收时间进行排序，可以探测到完整的二层转发路径。

当然，除了上述两种情况之外，也会出现上述两种情况的混合情况，即报文在上述各转发设备之间不仅进行了三层转发，也进行了二层转发。在这样的情况下，所述UMC服务器可以先按照三层转发的情况，将路径信息进行排序，然后在基础上按照二层转发的情况，将路径信息进行排序，这样就可以得到完成的报文转发路径，当然也可以直接基于报文接收时间由小到大的顺序，针对各转发设备发送的路径信息进行排序，然后按顺序提取排序后的所述路径信息中的设备标识，以得到报文的转发路径，最后得到的这条报文转发路径即为完整的转发路径。

下面以在具体场景中报文转发路径计算为例。

请参见图3，图3为本申请一示例性示出的一种报文转发路径探测的方法的场景图。假设所述目标报文依次经过了设备标识分别为A，B，C，D，E的5个转发设备，那么所述UMC服务器从所述路径信息中提取出的TTL取值、设备标识和报文接收时间，可能会出现如表1所示的情况。

表1

其中，表中的报文接收时间Ta<Tb<Tc<Td<Te。

由于表中各转发设备的TTL取值互不相同，因此可以确定，报文在所述5个转发设备之间只进行了三层转发。

从表中可以看出，上述5个转发设备的TTL取值分别为10，9，8，7，6，因此根据TTL取值由大到小的顺序，针对转发设备发送的路径信息进行排序的结果就是(A，10，Ta)→(B，9，Tb)→(C，8，Tc)→(D，7，Td)→(E，6，Te)，然后按照顺序提取排序后的路径信息中的设备标识，来得到所述目标报文的转发路径，从而可以得到A→B→C→D→E这样一条转发路径，由于报文在上述5个转发设备之间只进行了三层转发，因此得到的这条转发路径是一条完整的报文转发路径。

然而，所述UMC从若干转发设备发送的路径信息中提取出的TTL取值，设备标识，以及报文接收时间，也可能出现如表2所示的情况。

设备标识	TTL	报文接收时间
			A	10	Ta
B	10	Tb
			C	10	Tc
D	10	Td
			E	10	Te

表2

其中，表中的报文接收时间Ta<Tb<Tc<Td<Te。

从表中可以看出，上述5个转发设备的报文接收时间分别为Ta，Tb，Tc，Td，Te，且Ta<Tb<Tc<Td<Te，因此根据报文接收时间由小到大的顺序，针对转发设备发送的路径信息进行排序的结果就是(A，10，Ta)→(B，10，Tb)→(C，10，Tc)→(D，10，Td)→(E，10，Te)，然后按照顺序提取排序后的路径信息中的设备标识，来得到所述目标报文的转发路径，从而可以得到A→B→C→D→E这样一条转发路径，得到的这条转发路径即为一条完整的报文转发路径。

在示出的一种实施方式中，所述UMC服务器得到报文完整的转发路径后，可以根据所述报文接收时间，计算各转发设备之间接收到所述目标报文的时间延迟。

在实现时，由于相关技术中，是通过TTL超时报文的发送时间来探测报文的时间延迟，然而发送TTL超时报文是需要在设备的控制面来进行的，而实际数据报文在进行转发时是在数据面进行的，二者之间存在着时间差，因此相关技术无法精确探测到报文的时间延迟。

相比于相关技术，本申请提供的技术方案可以精确地探测到报文的时间延迟。

在实现时，UMC服务器计算得到所述目标报文的转发路径后，提取出各转发设备的报文接收时间，然后将各转发设备的报文接收时间进行差运算，得到各转发设备之间接收到所述目标报文的时间延迟。

以在图3所示的具体场景中接收到报文的时间延迟计算为例。

参照表2中设备标识分别为B和C的转发设备，它们的报文接收时间分别为Tb和Tc。由于报文在进行转发时是在数据面进行的，而Tb和Tc也是从数据面得到的，因此根据Tc和Tb就可以得到所述目标报文精确的时间延迟，所述目标报文的时间延迟即为Tc-Tb。

所述UMC服务器计算出所述目标报文完整的转发路径后，可以根据所述转发路径，快速定位丢包位置(比如某个设备或者某个接口)，便于进行丢包分析。

在实现时，比如所述UMC服务器已经统计计算出完整的报文转发路径后，如果UMC服务器对各个转发设备发送来的数据进行汇总计算后，得到转发路径不完整，比如没有得到某个转发设备之后的路径，则可以进一步分析该转发设备发送来的报文，如果其指示由于查找路由失败导致出口为空，则可以明确得知是由于该转发设备的原因丢包；如果该转发设备发送至所述UMC服务器的报文指示有确定的出口等信息，则可以将故障原因定位至是由于该转发设备发送报文失败或者是该转发设备相连设备收取报文失败。除此之外，如果中间转发设备主动丢包时，还可以提供对于该报文的丢包原因，比如配置了黑洞路由，或者由于ARP(Address Resolution Protocol，地址解析协议)无效导致无法正确转发等。

以在图3所示的具体场景中丢包位置的定位为例。

比如所述UMC服务器已经统计计算出完整的报文转发路径为A→B→C→D→E，如果UMC服务器对各个转发设备发送来的数据进行汇总计算后，得到转发路径为A→B→C，则可以进一步分析C转发设备发送来的报文，如果其指示由于查找路由失败导致出口为空，则可以明确得知是由于C转发设备的原因丢包；如果C转发设备发送至所述UMC服务器的报文指示有确定的出口等信息，则可以将故障原因定位至是由于C转发设备发送报文失败或者是D转发设备收取报文失败。

由以上本申请提供的技术方案可见，所述UMC服务器可以管理若干转发设备，它通过将用户预配置的目标报文特征分别下发至所述若干转发设备，然后接收所述若干转发设备发送的从基于所述目标报文特征采集到的目标报文中提取到的路径信息；所述路径信息用于计算所述目标报文的转发路径；最后，针对各转发设备发送的所述路径信息进行统计计算，以得到所述目标报文的转发路径。

由于UMC服务器将用户预配置的目标报文特征分别下发至它所管理的若干转发设备，然后通过接收所述若干转发设备发送的路径信息，其中所述路径信息是所述若干转发设备从基于所述目标报文特征采集到的目标报文中提取到的，因此，可以得到所述目标报文完整的路径信息，最后通过对所述路径信息进行统计计算，可以得到所述目标报文完整的转发路径。

与前述一种报文转发路径探测的方法的实施例相对应，本申请还提供了一种报文转发路径探测的装置的实施例。

本申请一种报文转发路径探测的装置的实施例可以应用在UMC服务器上。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在UMC服务器的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图4所示，为本申请一种报文转发路径探测的装置所在UMC服务器的一种硬件结构图，除了图4所示的处理器、内存、网络接口、以及非易失性存储器之外，实施例中装置所在的UMC服务器通常根据该报文转发路径探测的实际功能，还可以包括其他硬件，对此不再赘述。

请参考图5，图5为本申请一示例性实施例示出的一种报文转发路径探测的装置，应用于UMC服务器，所述装置包括：下发单元510，接收单元520，计算单元530，收集单元540，生成单元550，时延计算单元560。

其中，下发单元510，用于将用户预配置的目标报文特征分别下发至所述若干转发设备；

接收单元520，用于接收所述若干转发设备发送的从基于所述目标报文特征采集到的目标报文中提取到的路径信息；其中，所述路径信息用于计算所述目标报文的转发路径；

计算单元530，用于针对各转发设备发送的所述路径信息进行统计计算，以得到所述目标报文的转发路径。

收集单元540，用于从所述若干转发设备中收集网络拓扑信息；

生成单元550，用于基于收集到的所述网络拓扑信息生成对应的网络拓扑。

时延计算单元560，用于根据所述转发设备的所述目标报文的接收时间，计算得到各转发设备接收到所述目标报文的时间延迟。

在本例中，所述计算单元530，具体用于基于TTL取值由大到小的顺序，针对各转发设备发送的路径信息进行排序；按顺序提取排序后的所述路径信息中的设备标识，以得到所述目标报文的转发路径。

所述计算单元530，进一步用于基于所述目标报文的报文接收时间由小到大的顺序，针对各转发设备发送的路径信息进行排序；按顺序提取排序后的所述路径信息中的设备标志，以得到所述目标报文的转发路径。

上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

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

Claims (10)

1.一种报文转发路径探测的方法，应用于统一管理中心UMC服务器，所述UMC服务器管理若干转发设备，其特征在于，包括：

将用户预配置的目标报文特征分别下发至所述若干转发设备；

接收所述若干转发设备发送的从基于所述目标报文特征采集到的目标报文中提取到的路径信息；其中，所述路径信息用于计算所述目标报文的转发路径；

针对各转发设备发送的所述路径信息进行统计计算，以得到所述目标报文的转发路径。

2.根据权利要求1所述的方法，其特征在于，在将用户预配置的目标报文特征分别下发至所述若干转发设备之前，所述方法还包括：

从所述若干转发设备中收集网络拓扑信息；

基于收集到的所述网络拓扑信息，生成对应的网络拓扑。

3.根据权利要求1所述的方法，其特征在于，所述路径信息包括转发设备的设备标识，以及所述目标报文中的TTL取值；

所述针对各转发设备发送的所述路径信息进行统计计算，以得到所述目标报文的转发路径，包括：

基于TTL取值由大到小的顺序，针对各转发设备发送的路径信息进行排序；

按顺序提取排序后的所述路径信息中的设备标识，以得到所述目标报文的转发路径。

4.根据权利要求1所述的方法，其特征在于，所述路径信息包括转发设备的设备标识，以及所述目标报文的报文接收时间；

所述针对各转发设备发送的所述路径信息进行统计计算，以得到所述目标报文的转发路径，包括：

基于所述目标报文的报文接收时间由小到大的顺序，针对各转发设备发送的路径信息进行排序；

按顺序提取排序后的所述路径信息中的设备标识，以得到所述目标报文的转发路径。

5.根据权利要求4所述的方法，其特征在于，

所述方法还包括：

根据所述报文接收时间，计算各转发设备之间接收到所述目标报文的时间延迟。

6.一种报文转发路径探测的装置，应用于UMC服务器，其特征在于，所述UMC服务器管理若干转发设备，包括：

下发单元，用于将用户预配置的目标报文特征分别下发至所述若干转发设备；

接收单元，用于接收所述若干转发设备发送的从基于所述目标报文特征采集到的目标报文中提取到的路径信息；其中，所述路径信息用于计算所述目标报文的转发路径；

计算单元，用于针对各转发设备发送的所述路径信息进行统计计算，以得到所述目标报文的转发路径。

7.根据权利要求6所述的装置，其特征在于，所述装置还包括：

收集单元，用于从所述若干转发设备中收集网络拓扑信息；

生成单元，用于基于收集到的所述网络拓扑信息生成对应的网络拓扑。

8.根据权利要求6所述的装置，其特征在于，包括：

所述计算单元具体用于：

基于TTL取值由大到小的顺序，针对各转发设备发送的路径信息进行排序；

按顺序提取排序后的所述路径信息中的设备标识，以得到所述目标报文的转发路径。

9.根据权利要求6所述的装置，其特征在于，包括：

所述计算单元进一步用于：

基于所述目标报文的报文接收时间由小到大的顺序，针对各转发设备发送的路径信息进行排序；

按顺序提取排序后的所述路径信息中的设备标志，以得到所述目标报文的转发路径。

10.根据权利要求6所述的装置，其特征在于，所述装置还包括：

时延计算单元，用于根据所述报文接收时间，计算各转发设备之间接收到所述目标报文的时间延迟。