一种故障查询方法及装置与流程

1.本技术涉及领域通信技术领域，尤其涉及一种故障查询方法及装置。


背景技术：

2.在现网的业务转发过程中，有时设备会出现未知故障，导致承载业务流量丢包，业务受损。当现网出现业务流量丢包时，不仅需要尽快恢复业务，还需要尽快排查出故障点和故障原因。
3.目前，通常采用事中手段进行故障定位，也就是依赖现网故障现象重复发生进行定位。然而，由于业务中断时间不确定，或者由于现网中的多台设备归属不同的运营商/运维部门，登陆设备困难，导致无法快速对现网进行诊断和恢复。


技术实现要素：

4.本技术实施例提供了一种故障查询方法及装置，可以实现快速对现网中的故障进行定位和恢复，提高故障检测的灵活性。
5.第一方面，本技术实施例提供了一种故障查询方法，该方法可以包括：第一网络设备获取请求报文，所述请求报文用于请求丢包信息，所述请求报文包括目的标识和标签信息，所述标签信息用于指示进行故障查询的目标路径的下一跳网络设备；当所述第一网络设备为目的标识对应的目的网络设备时，所述第一网络设备根据所述请求报文获取响应报文，所述响应报文包括丢包信息和所述标签信息；所述第一网络设备根据所述标签信息将所述响应报文发送给源网络设备，所述源网络设备为生成所述请求报文的网络设备。
6.其中，第一网络设备可以为业务流量传输路径上的任意网络设备。当需要查询传输路径上的故障信息时，作为传输路径上的头节点，可以生成请求报文，并在传输路径上传输该请求报文，以通过该请求报文请求传输路径上各个网络设备的丢包信息。当传输路径上的其他网络设备接收到请求报文时，可以对该请求报文进行转发，直至转发至目的网络设备，由该目的网络设备根据请求报文获取响应报文，该响应报文中包括丢包信息。目的网络设备根据响应报文中的标签信息对响应报文进行转发，以使得该响应报文可以转发至源网络设备，从而使得源网络设备可以获知传输路径上各个网络设备存在丢包的具体信息，无需运维人员逐一登陆，提高故障查询效率。
7.在一种可能的实现方式中，所述第一网络设备根据所述请求报文获取响应报文，包括：所述第一网络设备根据所述请求报文生成响应报文，并添加所采集的丢包信息至所述响应报文；所述第一网络设备根据所述标签信息将所述响应报文发送给源网络设备，包括：所述第一网络设备根据所述标签信息将所述响应报文发送给第二网络设备，以使得所述第二网络设备将采集的丢包信息添加至所述响应报文，并对所述响应报文进行转发，直至转发给源网络设备，所述第二网络设备为所述目标路径上所述第一网络设备对应的下一跳网络设备。
8.在该实现方式中，请求报文从源网络设备转发至目的网络设备，由目的网络设备
根据请求报文生成响应报文，并将自身采集的丢包信息添加至响应报文中，并根据响应报文中的标签信息进行转发，直至转发至源网络设备。
9.在一种可能的实现方式中，当所述第一网络设备非为所述目的标识对应的目的网络设备时，所述方法还包括：所述第一网络设备根据所述标签信息将所述请求报文发送给第三网络设备，以使得所述第三网络设备对所述请求报文进行转发，直至转发给所述目的标识对应的目的网络设备。
10.在一种可能的实现方式中，所述目标路径是基于资源预留协议rsvp或标签分发协议ldp生成的。
11.在一种可能的实现方式中，所述第一网络设备在获取所述请求报文后，所述方法还包括：所述第一网络设备将采集的丢包信息添加至所述请求报文；当所述第一网络设备非为所述目的标识对应的目的网络设备时，所述第一网络设备根据标签信息将所述请求报文发送给第三网络设备，以使得所述第三网络设备将采集的丢包信息添加至所述请求报文，并对所述请求报文进行转发，直至转发给所述目的标识对应的目的网络设备，所述第三网络设备为所述目标路径上所述第一网络设备对应的下一跳网络设备；所述第一网络设备根据所述请求报文获取响应报文，包括：所述第一网络设备将所述请求报文转换为响应报文，所述响应报文包括所述目标路径上各个网络设备所添加的丢包信息。
12.在该实现方式中，请求报文在转发过程中，传输路径上的各个网络设备在接收到请求报文后，将自身采集的丢包信息添加至请求报文中。当请求报文被转发至目的网络设备时，目的网络设备将自身采集的丢包信息添加至请求报文中，并将请求报文转换为响应报文。目的网络设备根据响应报文中的标签信息进行转发，直至该响应报文转发至源网络设备。
13.在一种可能的实现方式中，所述第一网络设备将所述请求报文转换为响应报文，包括：所述第一网络设备修改所述请求报文中的报文类型获取响应报文。
14.在一种可能的实现方式中，当所述报文类型为第一数值时，为请求报文，当所述报文类型为第二数值时，为响应报文。
15.在一种可能的实现方式中，所述目标路径基于资源预留协议rsvp生成的。
16.在一种可能的实现方式中，当所述源网络设备到所述目的网络设备存在多条路径时，所述请求报文还包括序列号，所述响应报文还包括所述序列号，所述序列号用于指示所述目标路径，或者，当所述第一网络设备与第二网络设备之间存在多条隧道时，所述请求报文还包括序列号，所述响应报文还包括所述序列号，所述序列号用于指示目标隧道。
17.在一种可能的实现方式中，当所述第一网络设备为所述源网络设备时，所述方法还包括：所述第一网络设备输出所述响应报文中的丢包信息。
18.第二方面，提供了一种故障查询装置，所述装置包括：第一获取单元，用于获取请求报文，所述请求报文用于请求丢包信息，所述请求报文包括目的标识和标签信息，所述标签信息用于指示进行故障查询的目标路径上的下一跳网络设备；第二获取单元，用于当所述装置为目的标识对应的目的网络设备时，根据所述请求报文获取响应报文，所述响应报文包括丢包信息和所述标签信息；发送单元，用于根据所述标签信息将所述响应报文发送给源网络设备，所述源网络设备为生成所述请求报文的网络设备。
19.在一种可能的实现方式中，所述第二获取单元，具体用于根据所述请求报文生成
响应报文，并添加所采集的丢包信息至所述响应报文；所述发送单元，具体用于根据所述标签信息将所述响应报文发送给第二网络设备，以使得所述第二网络设备将采集的丢包信息添加至所述响应报文，并对所述响应报文进行转发，直至转发给源网络设备，所述第二网络设备为所述目标路径上所述第一网络设备对应的下一跳网络设备。
20.在一种可能的实现方式中，当所述装置非为所述目的标识对应的目的网络设备时，所述发送单元，还用于根据所述标签信息将所述请求报文发送给第三网络设备，以使得所述第三网络设备对所述请求报文进行转发，直至转发给所述目的标识对应的目的网络设备。
21.在一种可能的实现方式中，所述目标路径是基于资源预留协议rsvp或标签分发协议ldp生成的。
22.在一种可能的实现方式中，所述装置还包括：添加单元，用于在获取所述请求报文后，将采集的丢包信息添加至所述请求报文；所述发送单元，还用于当所述装置非为所述目的标识对应的目的网络设备时，根据标签信息将所述请求报文发送给第三网络设备，以使得所述第三网络设备将采集的丢包信息添加至所述请求报文，并对所述请求报文进行转发，直至转发给所述目的标识对应的目的网络设备，所述第三网络设备为所述目标路径上所述第一网络设备对应的下一跳网络设备；所述第二获取单元，具体用于将所述请求报文转换为响应报文，所述响应报文包括所述目标路径上各个网络设备所添加的丢包信息。
23.在一种可能的实现方式中，所述第二获取单元，具体用于修改所述请求报文中的报文类型获取响应报文。
24.在一种可能的实现方式中，当所述报文类型为第一数值时，为请求报文，当所述报文类型为第二数值时，为响应报文。
25.在一种可能的实现方式中，所述目标路径基于资源预留协议rsvp生成的。
26.在一种可能的实现方式中，当所述源网络设备到所述目的网络设备存在多条路径时，所述请求报文还包括序列号，所述响应报文还包括所述序列号，所述序列号用于指示所述目标路径，或者，当所述第一网络设备与第二网络设备之间存在多条隧道时，所述请求报文还包括序列号，所述响应报文还包括所述序列号，所述序列号用于指示目标隧道。
27.在一种可能的实现方式中，所述装置还包括：
28.输出单元，用于当所述装置为所述源网络设备时，输出所述响应报文中的丢包信息。
29.第三方面，提供了一种通信设备，所述设备包括：处理器和存储器；所述存储器，用于存储指令；所述处理器，用于执行所述存储器中的所述指令，以使得所述设备执行第一方面所述的方法。
30.第四方面，提供了一种计算机可读存储介质，包括指令，当其在计算机上运行时，使得计算机执行以上第一方面所述的方法。
31.通过本技术实施例提供的技术方案，为查询某一路径上的故障信息，作为该路径上的源网络设备可以生成请求报文，以通过该请求报文获取该路径上各个网络设备的丢包信息。当第一网络设备获取到请求报文时，如果第一网络设备为目的网络设备，则第一网络设备根据请求报文获取响应报文，该响应报文中包括丢包信息。第一网络设备根据响应报文中的标签信息将该响应报文发送给源网络设备，从而使得源网络设备获取各个网络设备
上的丢包信息。如果第一网络设备非为目的网络设备，则转发请求报文，直至转发给目的网络设备。可见，通过本技术实施例，源网络设备可以通过发送请求报文的方式获取目标路径上各个网络设备的丢包信息，无需登陆各个网络设备，也无需依赖故障重现来进行定位，提供故障查询的灵活性，从而可以快速恢复网络服务。
附图说明
32.为了更清楚地说明本技术实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本技术中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
33.图1为一种mpls报文转发场景示意图；
34.图2为本技术实施例提供的一种应用场景示意图；
35.图3为本技术实施例提供的一种故障查询方法流程图；
36.图4a为本技术实施例提供的一种报文格式示意图；
37.图4b为本技术实施例提供的另一种报文格式示意图；
38.图5为本技术实施例提供的另一种故障查询方法流程图；
39.图6为本技术实施例提供的又一种故障查询方法流程图；
40.图7为本技术实施例提供的一种故障查询装置结构图；
41.图8为本技术实施例提供的一种通信设备结构图。
具体实施方式
42.为了使本技术领域的人员更好地理解本发明中的方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本发明一部分实施例，而不是全部的实施例。
43.目前，在多协议标签交换(multi-protocol label switching，mpls)体系中，标签分发协议(label distribution protocol，ldp)和资源预留协议(resource reservation protocol，rsvp)是mpls体系中较为常用的路径建立协议。在实际的建立过程中，标签交换路由器(label switched router，lsr)之间根据转发等价类(forwarding equivalence class，fec)以及标签进行绑定，并将该绑定关系通告给相邻lsr。其中，fec是指一组沿着相同路径和相同规则进行转发的数据流，属于同一fec的报文均具有相同的标签。为便于理解，参见图1，在单纯的ldp隧道环境下，报文可以携带一层标签，报文从上游节点进入本地节点的入接口时携带的是上游节点分配给该fec的出标签(也是本地节点对应的入标签)，从本地节点出接口向下游节点发送时携带的是本地节点分配给对应fec的出标签。
44.如图1所示，mpls标签已分发完成，建立了一条lsp，其目的地址为4.4.4.2/32，mpls报文在转发过程中的标签动作如下：
45.ingress(入)节点收到目的地址为4.4.4.2的报文后，首先根据标签转发信息库(label forwarding information base，lfib)找到对应的下一跳，发现下一跳是lsr(如果发现下一跳是ip设备时会直接按fib表项进行报文转发)，并且因为本节点是入节点，所以在进行报文转发前需要进行标签压入动作，需压入的标签是根据fec 4.4.4.2与标签的映
射关系找到的(例如z，作为出标签)，然后把报文从压入的标签所映射的出接口转发出去。
46.第一中间节点收到报文后，根据lfib找到对应入标签(上一节点的出标签就是本节点的入标签)所映射的出标签、出接口，先进行标签交换，即用本地为fec 4.4.4.2/32分配的出标签(y)替换报文中原来的标签(z)，然后从以上找到的出标签所映射的出接口转发出去。
47.第二中间节点收到报文后，同样根据lfib找到对应入标签所映射的出标签、出接口，先用本地为fec 4.4.4.2/32分配的出标签(通常为3)替换原来的标签(y)，然后从出标签3所映射的出接口转发出去。但是因为egress分给他的出标签值为3(这是一个特殊的标签，必须弹出)，所以需要先进行php操作，弹出出标签(此时报文已不带标签)，并根据出标签3所映射的出接口转发报文。
48.egress(出)节点收到无标签的报文后，直接根据对应的ip路由表项把数据传输给目的主机4.4.4.2/32。
49.当网络中某节点出现丢包时，用户侧感知服务质量下降，向运营商进行反馈。运维部门从用户接入端确认业务路径上的每一台网络设备，并逐一登陆网络设备检查该网络设备是否存在丢包以及丢包原因，手段繁琐。而且，当业务路径上的网络设备属于不同的运维部门时，需要经过其它运维部门的授权许可，增加查询周期，无法快速进行故障定位以及故障恢复。
50.基于此，本技术实施例提供了一种故障查询方法，当需要查询某一业务路径上的故障时，作为业务路径的头节点可生成请求报文，以通过该请求报文请求故障信息，即丢包信息。当请求报文转发至业务路径的尾节点时，尾节点根据请求报文生成响应报文，该响应报文中包括丢包信息。尾节点将该响应报文转发给头节点，从而使得头节点可以获取业务路径上每个节点的丢包信息，无需登陆业务路径上各个节点，也无需依赖现网故障重现，实现快速故障查询，从而使得业务进行快速恢复。
51.参见图2所示，网络设备也可以称为节点，其为在网络系统中提供路由转发功能的设备。例如，可以为lsr、交换机等。如图2所示，以待查询的业务路径包括4个网络设备为例，分别为网络设备pe2、网络设备p2、网络设备p3、网络设备pe1。其中，网络设备pe2为头节点201，网络设备p2和网络设备p3均为中间转发节点，分别称为第一转发节点202、第二转发节点203，网络设备pe1为尾节点204。以上情形以节点为独立的网络设备为例，其他情形中，节点也可以为网络设备中具备报文转发能力的功能模块。其中，实线箭头表示请求报文的传输方向，虚线箭头表示响应报文的传输方向。
52.其中，对于头节点，在一种情形中，头节点可以为生成该请求报文的节点，即头节点为该报文中源地址对应的节点(源网络设备)时，该头节点为该报文端到端传输路径上的第一个节点；在另一种情形中，当报文初始时由用户设备生成并发送时，该报文中的源地址可以为用户设备的源地址，而头节点可以为与该用户设备连接的节点。
53.对于尾节点，在一种情形中，尾节点可以为报文中目的地址对应的节点(目的网络设备)；在另一种情形中，也可以为端到端传输路径上在当前所在域范围内的最后一个节点。中间转发节点为报文转发时在头节点和尾节点之间经过的一个或多个转发节点。
54.为便于理解本技术实施例提供的故障查询方法，下面将结合附图进行说明。
55.参见图3，该图为本技术实施例提供的一种故障查询方法流程图，如图3所示，该方
法可以包括：
56.s301：第一网络设备获取请求报文。
57.本实施例中，请求报文用于请求丢包信息，该丢包信息可以包括丢包原因和丢包数量。请求报文中包括目的标识和标签信息，其中，目的标识用于唯一指示目标路径上最后一跳对应的网络设备，即目的网络设备，如图2中尾节点204。目的标识可以为目的网络设备所分配的ip地址，或者为目的网络设备的设备标识等。标签信息用于指示进行故障查询的目标路径上的下一跳网络设备，以便在进行请求报文转发时，可以根据该标签信息确定目标路径上的下一跳网络设备。其中，标签信息可以包括头节点到尾节点所对应的fec以及当前节点所对应的出标签或入标签。例如，头节点201根据fec查找对应的出标签(第一中间节点202对应的入标签)，通过该出标签对应的出接口向第一转发节点202转发请求报文。
58.其中，第一网络设备获取请求报文的方式和其在业务路径上所处的位置有关，具体地，当第一网络设备为业务路径上的头节点201时，第一网络设备可以根据运维人员的配置操作生成请求报文；当第一网络设备为业务路径上的第一转发节点202或第二转发节点203时，第一网络设备是接收业务路径中上一跳节点转发的。例如，当第一网络设备为第一转发节点202时，第一网络设备接收头节点201发送的请求报文；当第一网络设备为第二转发节点203时，第一网络设备接收第一转发节点202发送的请求报文。
59.具体地，当第一网络设备为业务路径上的头节点201时，运维人员可以在第一网络设备上确认目标路径的信息，例如入节点、出节点、以及具体的出/入标签等信息，并进行标签信息的配置，以使得头节点可以根据配置的标签信息生成请求报文。头节点201生成请求报文后，根据请求报文中的fec以及出标签确定出标签对应的出接口，以便将该请求报文发送给第一转发节点202。第一转发节点202接收到请求报文后，根据fec确定出标签对应的出接口，以将该请求报文发送给第二转发节点203。当第二转发节点203接收到请求报文后，根据fec确定出标签对应的出接口，以将该请求报文发送给尾节点204。
60.需要说明的是，当头节点201与尾节点202之间存在多条业务路径时，为保证请求报文与目标路径一一对应，请求报文中还可以携带序列号，该系列号用于标识目标路径，以与其他业务路径进行区分。或者，当头节点201与第一转发节点202之间存在多条隧道时，不同的隧道可以分配给不同的用户进行业务传输，当需要对某一隧道或多个隧道进行故障检测时，该请求报文中也可以包括序列号，该序列号用于区分针对不同隧道的检测。例如，头节点201与第一转发节点202之间存在隧道1和隧道2，隧道1分配给用户a进行业务传输，隧道2分配给用户b进行业务传输。当同时需要对用户a对应的传输路径和用户b对应的传输路径进行故障检测时，则头节点201在生成的第一请求报文中包括序列号1，该序列号1用于指示对隧道1对应的传输路径进行故障检测；头节点202在生成的第二请求报文中包括序列号2，该序列号2用于指示对隧道2对应的传输路径进行故障检测。
61.为体现报文传输的连续性，在本实施例中将头节点201向第一转发节点202发送的请求报文和第一转发节点202向第二转发节点203发送的请求报文均称为请求报文，但可以理解地，头节点201向第一转发节点202发送的请求报文和第一转发节点202向第二转发节点203发送的请求报文在实际应用场景中存在差别。例如，生存时间(time to live，ttl)和出标签等信息可能均存在差异，即，第一转发节点202在将头节点201发送的请求报文转发给第二转发节点203时，实际可以为修改了一些必要信息的更新后的请求报文。后续第二转
发节点203向尾节点204发送的所谓请求报文也是类似含义，实质也可以是更新后的请求报文。
62.s302：当第一网络设备为目的标识对应的目的网络设备时，第一网络设备根据请求报文生成响应报文。
63.本实施例中，第一网络设备在获取到请求报文后，可以根据请求报文中的目的标识以及自身的标识进行判断，以确定自身是否为目的标识对应的目的网络设备。例如，当目的标识为目的ip地址时，第一网络设备在接收到请求报文后，可以判断自身的ip地址是否与目的ip地址一致，如果一致，则表明该第一网络设备为目的网络设备。或者，当目标标识为目的设备标识时，第一网络设备在接收到请求报文后，可以判断自身的设备标识是否与目的设备标识一致，如果一致，则表明第一网络设备为目的网络设备。
64.当第一网络设备确认自身为目的网络设备时，表明请求报文已转发至目标路径的最后一跳网络设备，此时可以无需再进行转发，第一网络设备根据请求报文获取响应报文。其中，第一网络设备根据请求报文获取响应报文可以通过以下方式获取，一种是目标路径上的各个网络设备在转发请求报文时，将各自采集的丢包信息添加至请求报文中，当到达目的网络设备时，目的网络设备根据请求报文生成响应报文；另一种是，目标路径上的各个网络设备仅转发请求报文，直至该请求报文转发至目的网络设备，目的网络设备生成响应报文，并在该响应报文中添加丢包信息，同时将该响应报文转发给目标路径上的下一跳网络设备，直至转发至源网络设备。其中，关于上述两种方式的具体实现，将在后续实施例进行说明。
65.其中，响应报文包括丢包信息和标签信息。其中，丢包信息中包括目标路径上各个网络设备各自对应的丢包信息。具体地，目标路径上的各个网络设备在进行业务流量转发时，转发平面可以自动抓取被丢弃的报文，并记录丢包数量和丢包原因。其中，丢包原因可以包括多种，例如，由于报文的标签与当前网络设备所分配的标签不一致，如图1中，入节点所转发的报文中的出标签为k，第一转发节点接收该报文后发现所分配的标签为z与报文中的标签k不一致，则丢弃该报文。标签信息用于指示目标路径上第一网络设备对应的下一跳网络设备。例如，第一网络设备为尾节点204，标签信息用于指示第二转发节点203。
66.s303：第一网络设备根据标签信息将响应报文发送给源网络设备。
67.当第一网络设备根据请求报文获取响应报文后，可以根据响应报文中的标签信息将该响应报文转发第二网络设备，该第二网络设备根据报文中的标签信息进行转发，直至转发给源网络设备，如头节点201，从而使得源网络设备获取目标路径上各个网络设备的丢包信息，以便维护人员可以根据响应报文中的丢包信息进行故障定位，进而进行故障恢复，提高故障查询效率。其中，第二网络设备为目标路径上第一网络设备对应的下一跳网络设备。
68.具体地，当第一网络设备为尾节点204时，第一网络设备可以根据fec查找出标签，以便根据出标签对应的出接口将响应报文发送给第二转发节点203。当第二转发节点203接收到响应报文后，根据fec查找出标签，以根据出标签对应的出接口将响应报文发送给第一转发节点202。当第一转发节点202接收到响应报文后，根据frc查找出标签，以根据出标签对应的出接口将相应报文发送给头节点201。当头节点201接收到响应报文时，确认自身为源网络设备，则可以解析该响应报文，获取路径上各个节点对应的丢包信息。
69.为体现报文传输的连续性，在本实施例中将尾节点204向第二转发节点203发送的响应报文和第二转发节点203向第一转发节点202发送的请求报文均称为响应报文，但可以理解地，尾节点204向第二转发节点203发送的响应报文和第二转发节点203向第一转发节点202发送的响应报文在实际应用场景中存在差别。例如，生存时间(time to live，ttl)和出标签等信息可能均存在差异，即，第二转发节点203在将尾节点201发送的响应报文转发给第一转发节点202时，实际可以为修改了一些必要信息的更新后的请求报文。后续第一转发节点202向头节点201发送的所谓响应报文也是类似含义，实质也可以是更新后的响应报文。
70.在一种可能的实现方式中，当源网络设备接收到响应报文后，可以输出该响应报文中的丢包信息，以便维护人员可以直观地了解各个网络设备上的丢包信息。具体地，源网络设备可以将丢包信息发送至具备显示功能的终端上进行显示，或者将丢包信息发送至维护人员对应的用户设备上。
71.其中，请求报文和响应报文的报文类型通过新增的类型长度值(type-length-value，tlv)进行定义，其中，type字段用于指示报文的类型，例如当type＝0x3e0c时，表示该报文为请求报文；当type＝0x3e0d时，表示该报文为响应报文。length字段用于指示“vlaue”字段所包含的字节数；而vlaue字段没有限制，其中，而且vlaue字段本身就可以由多个tlv组成。具体地，请求报文和响应报文均可以包括数据部分，该数据部分用于封装丢包溯源参数，例如图4a所示，数据部分可以包括序列号字段、保留字段、ingress lsr id字段、egress lsr id字段、fec tlv字段、label tlv字段以及hop record 1
…
n字段。
72.其中，sequence number：请求序列号，可以发起者设置，例如头节点201进行设置。
73.ingress lsr id：ingress设备id。
74.egress lsr id：egress设备id。
75.fec tlv：转发等价类。
76.label tlv：下一跳设备的入标签，每一跳设备向上游转发时更新此字段。
77.hop record 1..n：具体的丢包记录。
78.其中，hop record的具体格式如图4b所示，其包括：lsr id字段、record count字段、packet loss reson 1
…
n字段以及packet loss count 1
…
n。
79.lsr id：用于标识一台lsr，例如标识pe1设备。
80.record count：本设备的丢包记录数量。
81.packet loss reson 1..n：一条丢包记录的丢包原因。
82.packet loss count 1..n：一条丢包记录的丢包数量，与packet loss reson 1..n构成一条丢包记录。每个网络设备lsr可能存在多条丢包记录。
83.基于上述实施例可知，第一网络设备基于请求报文获取响应报文可以通过两种方式实现，一种是作为目的网络设备的第一网络设备根据请求报文生成响应报文，并添加自身所采集的丢包信息至响应报文；根据响应报文中的标签信息将该响应报文转发给第二网络设备，以使得第二网络设备将采集的丢包信息添加至响应报文，并对该响应报文进行转发，直至转发给源网络设备。在该实现方式中，请求报文从源网络设备被转发至目的网络设备，由目的网络设备根据请求报文生成响应报文，并将自身采集的丢包信息添加至响应报文中。目的网络设备根据响应报文中的标签信息队该响应报文进行转发，直至转发至源网
络设备，从而获取目标路径上各个网络设备的丢包信息。
84.另一种是，第一网络设备将采集的丢包信息添加至请求报文中，当第一网络设备非为目的标识对应的目的网络设备时，第一网络设备根据标签信息将请求报文发送给第三网络设备，以使得第三网络设备将采集的丢包信息添加至请求报文，并对该请求报文进行转发，直至转发给目的标识对应的目的网络设备。其中，第三网络设备为目标路径上第一网络设备对应的下一跳网络设备。当请求报文被转发至目的网络设备时，作为目的网络设备的第一网络设备可以将自身采集的丢包信息添加至请求报文中，并将请求报文转换为响应报文，此时，该响应报文中包括目标路径上各个网络设备所添加的丢包信息。也就是，在该实现方式中，请求报文在被转发的过程中，各个网络设备将自身采集的丢包信息添加至请求报文中，进而当请求报文被转发至目的网络设备时，由目的网络设备根据请求报文生成响应报文。
85.为便于理解上述两种获取方式，下面将结合附图分别进行说明。需要说明的是，下面将结合图2的场景进行说明。
86.参见图5，该图为本技术实施例提供的一种获取响应报文的流程图，该图中涉及的一些具体实现可以参见图3所述实施例，该方法可以包括：
87.s501：头节点201生成请求报文，并根据标签信息将请求报文发送给第一转发节点202。
88.本实施例中，作为目标路径上的头节点201，其可以根据运维人员所配置的参数创建请求报文，例如，运维人员配置的目标路径、目标路径对应的fec等，该请求报文中可以包括目的标识以及标签信息。其中，标签信息可以为第一转发节点为目标路径所分配的第一出标签。具体地，头节点201根据第一出标签对应的出接口将请求报文发送给第一转发节点202。
89.s502：第一转发节点202根据请求报文中的标签信息向第二转发节点203发送请求报文。
90.本实施例中，第一转发节点202接收到头节点201发送的请求报文后，第一转发节点根据请求报文确定入标签(请求报文中的第一出标签)，并根据fec查找该入标签对应的第二出标签以及第二出标签对应的出接口，将请求报文中的第一出标签替换为第二出标签，并利用第二出标签对应的出接口将请求报文转发给第二转发节点203。其中，第二出标签为第二转发节点为目标路径所分配的出标签。
91.s503：第二转发节点203根据请求报文中的标签信息向尾节点204发送请求报文。
92.本实施例中，第二转发节点203接收到请求报文后，根据请求报文确定入标签(请求报文中的第二出标签)，并根据fec查找入标签对应的第三出标签以及第三出标签对应的出接口，将请求报文中的第二出标签替换为第三出标签，并利用第三出标签对应的出接口将请求报文转发给尾节点204。其中，第三出标签为尾节点204为目标路径所分配的出标签。
93.s504：尾节点204根据请求报文生成响应报文，并添加所采集的丢包信息至响应报文。
94.本实施例中，当尾节点204接收到请求报文后，根据请求报文中的目的标识确定自身为目标标识对应的目的节点，则根据请求报文生成响应报文。同时，尾节点204将自身采集的丢包信息添加至响应报文中。其中，响应报文中还可以包括标签信息和目的标识，该标
签信息用于指示下一跳节点，该目的标识用于指示生成请求报文的节点，如头节点201。
95.其中，尾节点204根据请求报文生成响应报文，可以包括：尾节点204将请求报文转换成响应报文。具体地，尾节点204通过修改请求报文中报文类型的方式获取响应报文。例如，报文类型为0时，表示该报文为请求报文；报文类型为1时，表示该报文为响应报文。尾节点204将请求报文中的报文类型0修改为1，从而获得响应报文。
96.需要说明的是，在上述请求报文转发过程中，目标路径上的各个节点在接收到请求报文时，根据请求报文中的目的标识确定自身是否为目的标识对应的目的节点，如果不是目的节点，则根据请求报文中的标签信息进行后续转发；如果是目的节点，则根据请求报文生成响应报文。
97.s505：尾节点204根据响应报文中的标签信息将响应报文发送给第二转发节点203。
98.本实施例中，尾节点204根据响应报文中的标签信息确定第四出标签，并利用第四出标签对应的出接口将响应报文发送的第二转发节点203。
99.s506：第二转发节点203将自身采集的丢包信息添加至响应报文，并根据响应报文中的标签信息将响应报文发送给第一转发节点202。
100.当第二转发节点203接收到尾节点204发送的响应报文时，第二转发节点203从本地读取预先采集的丢包信息，并将该丢包信息添加至响应报文中。同时，第二转发节点203根据请求报文确定入标签(请求报文中的第四出标签)，并根据fec查询该入标签对应的第五出标签以及第五出标签对应的出接口，将响应报文中的第四出标签替换为第五出标签，并利用第五出标签对应的出接口将响应报文转发给第一转发节点202。
101.s507：第一转发节点202将自身采集的丢包信息添加至响应报文，并根据响应报文中的标签信息将响应报文发送给头节点201。
102.其中，关于第一转发节点202根据响应报文的标签信息进行转发的具体实现可以参见s505或s506，本实施例在此不再赘述。
103.s508：头节点201输出丢包信息。
104.本实施例中，头节点201在接收到第一中间点202发送的响应报文时，可以先将自身采集的丢包信息添加至响应报文中，然后再输出响应报文中的丢包信息。或者，头节点201在接收到第一转发节点202发送的响应报文时，输出响应报文中的丢包信息以及自身采集的丢包信息。
105.需要说明的是，在响应报文转发过程中，目标路径上的各个节点在接收到响应报文时，根据响应报文中的目的标识确定自身是否为目的标识对应的节点，如果不是目的标识对应的节点，则根据响应报文中的标签信息进行后续转发；如果是目的标识对应的节点，则输出响应报文中的丢包信息。
106.在该实施例中，各个节点在响应报文中添加丢包信息的应用场景，可以应用于rsvp协议或ldp协议构建的lsp中。
107.参见图6，该图为本技术实施例提供的另一种获取响应报文的流程图，该图中涉及的一些具体实现可以参见图3或图5所述实施例，该方法可以包括：
108.s601：头节点201生成请求报文，并将自身采集的丢包信息添加至请求报文中。
109.本实施例中，头节点201在生成请求报文后，可以从本地读取预先采集的丢包信
息，并将该丢包信息添加至请求报文中，以使得该请求报文中包括头节点201所对应的丢包信息。可以理解的是，头节点201也可以仅生成请求报文，无需添加自身采集的丢包信息，而是从第一转发节点202开始，将自身采集的丢包信息添加至请求报文中。关于头节点201是否在请求报文中添加丢包信息，可以根据实际应用情况进行选择，本实施例在此不进行限定。
110.其中，关于头节点201生成请求报文的具体实现可以参见s301和s501，本实施例在此不再赘述。
111.s602：头节点201根据请求报文中的标签信息将请求报文转发给第一转发节点202。
112.其中，s602的具体实现可以参见s502或s503，本实施例在此不再赘述。
113.s603：第一转发节点202将自身采集的丢包信息添加至请求报文。
114.s604：第一转发节点202根据请求报文中的标签信息将请求报文转发给第二转发节点203。
115.其中，第一转发节点202执行的转发操作具体可以参见s502、s302或s303，此处不再赘述。
116.s605：第二转发节点203将自身采集的丢包信息添加至请求报文。
117.s606：第二转发节点203根据请求报文中的标签信息将请求报文转发给尾节点204。
118.其中，第二转发节点203执行的转发操作具体可以参见s504、s502、s302或s303，此处不再赘述。
119.s607：尾节点204根据请求报文生成响应报文。
120.本实施例中，当尾节点204接收到请求报文后，根据请求报文中的目的标识确定自身为目标标识对应的目的节点，则根据请求报文生成响应报文。具体地，尾节点204可以先将自身采集的丢包信息添加至请求报文，再根据请求报文生成响应报文。或者，尾节点204根据请求报文生成响应报文，再将自身采集的丢包信息添加至响应报文。
121.其中，尾节点204根据请求报文生成响应报文，可以包括：尾节点204将请求报文转换成响应报文。具体地，尾节点204通过修改请求报文中报文类型的方式获取响应报文。例如，报文类型为0时，表示该报文为请求报文；报文类型为1时，表示该报文为响应报文。尾节点204将请求报文中的报文类型0修改为1，从而获得响应报文。
122.s608：尾节点204根据响应报文中的标签信息将响应报文发送给第二转发节点203。
123.s609：第二转发节点203根据响应报文中的标签信息将响应报文发送给第一转发节点202。
124.s610：第一转发节点202根据响应报文中的标签信息将响应报文发送给头节点201。
125.s611：头节点201输出丢包信息。
126.本实施例中，头节点201在接收到第一中间点202发送的响应报文时，可以先将自身采集的丢包信息添加至响应报文中，然后再输出响应报文中的丢包信息。或者，头节点201在接收到第一转发节点202发送的响应报文时，输出响应报文中的丢包信息以及自身采
集的丢包信息。
127.需要说明的时，在该实施例中，各个节点在请求报文中添加丢包信息的应用场景，主要是针对基于rsvp协议构建的lsp。
128.基于上述方法实施例，本技术实施例提供了一种故障查询装置，下面将结合附图对该装置进行说明。
129.参见图7，该图为本技术实施例提供的一种故障查询装置结构示意图，该装置可以应用于第一网络设备，执行图3所示实施例中第一网络设备的功能，可以包括：第一获取单元701、第二获取单元702和发送单元703。
130.其中，第一获取单元701，用于第一获取单元，用于获取请求报文，所述请求报文用于请求丢包信息，所述请求报文包括目的标识和标签信息，所述标签信息用于指示进行故障查询的目标路径上的下一跳网络设备。
131.当装置700所应用的网络设备为头节点201时，第一获取单元701获取请求报文的具体实现可以参见s301、s501或s601。当该装置700所应用的网络设备为第一转发节点202、第二转发节点203或尾节点204时，第一获取单元701可以从上一跳网络设备接收请求报文，具体实现可以参见s502、s503、s602、s604或s606。
132.第二获取单元702，用于当所述装置为目的标识对应的目的网络设备时，根据所述请求报文获取响应报文，所述响应报文包括丢包信息和所述标签信息。
133.其中，装置700所应用的网络设备为目的标识对应的目的网络设备时，第二获取单元702根据请求报文获取响应报文的具体实现可以参见s302、s504或s607。
134.发送单元703，用于根据所述标签信息将所述响应报文发送给源网络设备，所述源网络设备为生成所述请求报文的网络设备。
135.其中，发送单元703向源网络设备发送响应报文的实现可以参见s303、s505-s507或者s607-s610。
136.在一种可能的实现方式中，第二获取单元，具体用于根据所述请求报文生成响应报文，并添加所采集的丢包信息至所述响应报文；发送单元，具体用于根据所述标签信息将所述响应报文发送给第二网络设备，以使得所述第二网络设备将采集的丢包信息添加至所述响应报文，并对所述响应报文进行转发，直至转发给源网络设备，所述第二网络设备为所述目标路径上所述第一网络设备对应的下一跳网络设备。
137.其中，关于第二获取单元生成响应报文的具体实现可以参见s504，发送单元向第二网络设备发送响应报文的实现可以参见s505、s506或s507。
138.在一种可能的实现方式中，当所述装置非为所述目的标识对应的目的网络设备时，所述发送单元，还用于根据所述标签信息将所述请求报文发送给第三网络设备，以使得所述第三网络设备对所述请求报文进行转发，直至转发给所述目的标识对应的目的网络设备。
139.其中，当装置700所应用的网络设备非为目的网络设备时，即非为尾节点时，发送单元的实现可以参见s502、s503。
140.在一种可能的实现方式中，所述目标路径是基于资源预留协议rsvp或标签分发协议ldp生成的。
141.在一种可能的实现方式中，所述装置还包括：
142.添加单元，用于在获取所述请求报文后，将采集的丢包信息添加至所述请求报文；
143.所述发送单元，还用于当所述装置非为所述目的标识对应的目的网络设备时，根据标签信息将所述请求报文发送给第三网络设备，以使得所述第三网络设备将采集的丢包信息添加至所述请求报文，并对所述请求报文进行转发，直至转发给所述目的标识对应的目的网络设备，所述第三网络设备为所述目标路径上所述第一网络设备对应的下一跳网络设备；
144.所述第二获取单元，具体用于将所述请求报文转换为响应报文，所述响应报文包括所述目标路径上各个网络设备所添加的丢包信息。
145.其中，关于添加单元的具体实现可以参见s601-s606任一步骤，当装置700所应用的网络设备非为目的网络设备时，发送单元的实现可以参见s601-s606。第二获取单元的具体实现可以参见s607。
146.在一种可能的实现方式中，所述第二获取单元，具体用于修改所述请求报文中的报文类型获取响应报文。
147.其中，第二获取单元的具体实现可以参见s504或s607。
148.在一种可能的实现方式中，当所述报文类型为第一数值时为请求报文，当所述报文类型为第二数值时为响应报文。
149.在一种可能的实现方式中，所述目标路径基于标资源预留协议rsvp生成的。
150.在一种可能的实现方式中，当所述源网络设备到所述目的网络设备存在多条路径时，所述请求报文还包括序列号，所述响应报文还包括所述序列号，所述序列号用于指示所述目标路径，或者，当所述第一网络设备与第二网络设备之间存在多条隧道时，所述请求报文还包括序列号，所述响应报文还包括所述序列号，所述序列号用于指示目标隧道。
151.在一种可能的实现方式中，所述装置还包括：
152.输出单元，用于当所述装置为所述源网络设备时，输出所述响应报文中的丢包信息。
153.其中，输出单元的具体实现可以参见s508或s611。
154.关于装置700具体可执行的功能和实现，可以参见图3、图5或图6所示实施例中关于第一网络设备的相应描述，此处不再赘述。
155.图8为本技术实施例提供的一种网络设备的结构示意图，该网络设备例如可以是图3、图5或图6所示实施例中的第一网络设备或第二网络设备或第三网络设，或者也可以是图7所示实施例中的故障查询装置700的设备实现。
156.请参阅图8所示，网络设备800包括：处理器810、通信接口820和存储器830。其中报文转发设备800中的处理器810的数量可以一个或多个，图8中以一个处理器为例。本技术实施例中，处理器810、通信接口820和存储器830可通过总线系统或其它方式连接，其中，图8中以通过总线系统840连接为例。
157.处理器810可以是cpu、np、或者cpu和np的组合。处理器810还可以进一步包括硬件芯片。上述硬件芯片可以是专用集成电路(application-specific integrated circuit，asic)，可编程逻辑器件(programmable logic device，pld)或其组合。上述pld可以是复杂可编程逻辑器件(complex programmable logic device，cpld)，现场可编程逻辑门阵列(field-programmable gate array，fpga)，通用阵列逻辑(generic array logic,gal)或
其任意组合。
158.处理器810可以执行上述方法实施例中获取请求报文、获取响应报文以及在响应报文中添加丢包信息等的相关功能。
159.通信接口820用于接收和发送报文，具体地，通信接口820可以包括接收接口和发送接口。其中，接收接口可以用于接收报文，发送接口可以用于发送报文。通信接口820的个数可以为一个或多个。
160.存储器830可以包括易失性存储器(英文：volatile memory)，例如随机存取存储器(random-access memory，ram)；存储器830也可以包括非易失性存储器(英文：non-volatile memory)，例如快闪存储器(英文：flash memory)，硬盘(hard disk drive，hdd)或固态硬盘(solid-state drive，ssd)；存储器830还可以包括上述种类的存储器的组合。
161.可选地，存储器830存储有操作系统和程序、可执行模块或者数据结构，或者它们的子集，或者它们的扩展集，其中，程序可包括各种操作指令，用于实现各种操作。操作系统可包括各种系统程序，用于实现各种基础业务以及处理基于硬件的任务。处理器810可以读取存储器830中的程序，实现本技术实施例提供的故障查询方法。
162.其中，存储器830可以为网络设备800中的存储器件，也可以为独立于网络设备800的存储装置。
163.总线系统840可以是外设部件互连标准(peripheral component interconnect，pci)总线或扩展工业标准结构(extended industry standard architecture，eisa)总线等。总线系统840可以分为地址总线、数据总线、控制总线等。为便于表示，图8中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。
164.本技术的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
165.所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
166.在本技术所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，单元的划分，仅仅为一种逻辑业务划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
167.作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
168.另外，在本技术各个实施例中的各业务单元可以集成在一个处理单元中，也可以
是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件业务单元的形式实现。
169.集成的单元如果以软件业务单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本技术的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本技术各个实施例方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-only memory)、随机存取存储器(ram，random access memory)、磁碟或者光盘等各种可以存储程序代码的介质。
170.本领域技术人员应该可以意识到，在上述一个或多个示例中，本发明所描述的业务可以用硬件、软件、固件或它们的任意组合来实现。当使用软件实现时，可以将这些业务存储在计算机可读介质中或者作为计算机可读介质上的一个或多个指令或代码进行传输。计算机可读介质包括计算机存储介质和通信介质，其中通信介质包括便于从一个地方向另一个地方传送计算机程序的任何介质。存储介质可以是通用或专用计算机能够存取的任何可用介质。
171.以上的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上仅为本发明的具体实施方式而已。
172.以上，以上实施例仅用以说明本技术的技术方案，而非对其限制；尽管参照前述实施例对本技术进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本技术各实施例技术方案的范围。