CN114205221A

CN114205221A - Fault query method and device

Info

Publication number: CN114205221A
Application number: CN202010872141.8A
Authority: CN
Inventors: 侯云龙
Original assignee: Beijing Huawei Digital Technologies Co Ltd
Current assignee: Beijing Huawei Digital Technologies Co Ltd
Priority date: 2020-08-26
Filing date: 2020-08-26
Publication date: 2022-03-18
Anticipated expiration: 2040-08-26
Also published as: CN114205221B

Abstract

The embodiment of the application discloses a fault query method and a fault query device, and the method specifically comprises the following steps: in order to query packet loss information on a certain path, the source network device on the path may generate a request message. When the first network device obtains the request message, if the first network device is the target network device, obtaining a response message according to the request message, wherein the response message comprises packet loss information. And the first network equipment sends the response message to the source network equipment according to the label information in the response message, so that the source network equipment acquires packet loss information on each network equipment. And if the first network equipment is not the target network equipment, forwarding the request message until the request message is forwarded to the target network equipment. Therefore, the network device can obtain the packet loss information of each network device on the target path in a mode of sending the request message, does not need to log in each network device, does not need to rely on fault recurrence for positioning, and provides flexibility for fault query.

Description

Fault query method and device

Technical Field

The present application relates to the field of communications technologies, and in particular, to a fault query method and apparatus.

Background

In the service forwarding process of the existing network, sometimes unknown faults occur in the equipment, which causes packet loss of the bearer service flow and service damage. When the traffic packet loss occurs in the current network, not only the service needs to be recovered as soon as possible, but also the fault point and the fault reason need to be checked as soon as possible.

At present, usually, the fault location is carried out by adopting an in-service means, namely, the fault location is carried out by depending on the repeated occurrence of the fault phenomenon of the current network. However, the service interruption time is uncertain, or multiple devices in the current network belong to different operators/operation and maintenance departments, so that the devices are difficult to log in, and the current network cannot be diagnosed and recovered quickly.

Disclosure of Invention

The embodiment of the application provides a fault query method and a fault query device, which can be used for rapidly positioning and recovering faults in the existing network and improving the flexibility of fault detection.

In a first aspect, an embodiment of the present application provides a fault query method, which may include: a first network device acquires a request message, wherein the request message is used for requesting packet loss information, the request message comprises a destination identifier and label information, and the label information is used for indicating a next hop network device of a target path for fault query; when the first network device is a destination network device corresponding to a destination identifier, the first network device obtains a response message according to the request message, wherein the response message comprises packet loss information and the label information; and the first network equipment sends the response message to source network equipment according to the label information, wherein the source network equipment is the network equipment for generating the request message.

The first network device may be any network device on the service traffic transmission path. When the failure information on the transmission path needs to be queried, the head node on the transmission path may generate a request packet and transmit the request packet on the transmission path, so as to request packet loss information of each network device on the transmission path through the request packet. When other network devices on the transmission path receive the request message, the request message can be forwarded until the request message is forwarded to the target network device, and the target network device obtains a response message according to the request message, wherein the response message includes packet loss information. The target network device forwards the response message according to the label information in the response message, so that the response message can be forwarded to the source network device, the source network device can know the specific information of packet loss of each network device on the transmission path, operation and maintenance personnel do not need to log in one by one, and the fault query efficiency is improved.

In a possible implementation manner, the acquiring, by the first network device, a response packet according to the request packet includes: the first network equipment generates a response message according to the request message, and adds the collected packet loss information to the response message; the first network device sends the response message to a source network device according to the label information, including: and the first network equipment sends the response message to second network equipment according to the label information, so that the second network equipment adds the collected packet loss information to the response message and forwards the response message until the response message is forwarded to source network equipment, wherein the second network equipment is next-hop network equipment corresponding to the first network equipment on the target path.

In the implementation manner, the request message is forwarded from the source network device to the destination network device, the destination network device generates a response message according to the request message, adds packet loss information acquired by the destination network device to the response message, and forwards the packet loss information according to label information in the response message until the packet loss information is forwarded to the source network device.

In one possible implementation, when the first network device is not a destination network device corresponding to the destination identifier, the method further includes: and the first network equipment sends the request message to third network equipment according to the label information, so that the third network equipment forwards the request message until the request message is forwarded to the target network equipment corresponding to the target identifier.

In one possible implementation, the target path is generated based on resource reservation protocol RSVP or label distribution protocol LDP.

In a possible implementation manner, after the first network device obtains the request packet, the method further includes: the first network equipment adds the collected packet loss information to the request message; when the first network device is not a destination network device corresponding to the destination identifier, the first network device sends the request message to a third network device according to tag information, so that the third network device adds the acquired packet loss information to the request message and forwards the request message until the request message is forwarded to the destination network device corresponding to the destination identifier, and the third network device is a next hop network device corresponding to the first network device on the target path; the first network device obtains a response message according to the request message, and the method comprises the following steps: and the first network equipment converts the request message into a response message, wherein the response message comprises packet loss information added by each network equipment on the target path.

In the implementation manner, in the forwarding process of the request message, after each network device on the transmission path receives the request message, the packet loss information acquired by the network device is added to the request message. When the request message is forwarded to the destination network device, the destination network device adds the packet loss information collected by the destination network device to the request message, and converts the request message into a response message. And the target network equipment forwards the response message according to the label information in the response message until the response message is forwarded to the source network equipment.

In a possible implementation manner, the converting, by the first network device, the request packet into a response packet includes: and the first network equipment modifies the message type in the request message to obtain a response message.

In a possible implementation manner, the message type is a request message when the message type is a first numerical value, and is a response message when the message type is a second numerical value.

In one possible implementation, the target path is generated based on the resource reservation protocol RSVP.

In a possible implementation manner, when multiple paths exist from the source network device to the destination network device, the request packet further includes a sequence number, the response packet further includes the sequence number, and the sequence number is used to indicate the destination path, or when multiple tunnels exist between the first network device and the second network device, the request packet further includes a sequence number, the response packet further includes the sequence number, and the sequence number is used to indicate a destination tunnel.

In one possible implementation, when the first network device is the source network device, the method further includes: and the first network equipment outputs the packet loss information in the response message.

In a second aspect, a fault querying device is provided, the device comprising: a first obtaining unit, configured to obtain a request packet, where the request packet is used to request packet loss information, the request packet includes a destination identifier and tag information, and the tag information is used to indicate a next-hop network device on a target path for performing a fault query; a second obtaining unit, configured to obtain, when the apparatus is a destination network device corresponding to a destination identifier, a response packet according to the request packet, where the response packet includes packet loss information and the tag information; and the sending unit is used for sending the response message to source network equipment according to the label information, and the source network equipment is the network equipment for generating the request message.

In a possible implementation manner, the second obtaining unit is specifically configured to generate a response packet according to the request packet, and add the collected packet loss information to the response packet; the sending unit is specifically configured to send the response packet to a second network device according to the tag information, so that the second network device adds the acquired packet loss information to the response packet and forwards the response packet until the response packet is forwarded to a source network device, where the second network device is a next-hop network device corresponding to the first network device on the target path.

In a possible implementation manner, when the apparatus is not a destination network device corresponding to the destination identifier, the sending unit is further configured to send the request packet to a third network device according to the tag information, so that the third network device forwards the request packet until the request packet is forwarded to the destination network device corresponding to the destination identifier.

In one possible implementation, the apparatus further includes: the adding unit is used for adding the acquired packet loss information to the request message after the request message is acquired; the sending unit is further configured to send the request packet to a third network device according to tag information when the apparatus is not a destination network device corresponding to the destination identifier, so that the third network device adds the acquired packet loss information to the request packet and forwards the request packet until the request packet is forwarded to the destination network device corresponding to the destination identifier, where the third network device is a next hop network device corresponding to the first network device on the destination path; the second obtaining unit is specifically configured to convert the request packet into a response packet, where the response packet includes packet loss information added to each network device on the target path.

In a possible implementation manner, the second obtaining unit is specifically configured to modify a message type in the request message to obtain a response message.

In one possible implementation, the apparatus further includes:

and the output unit is used for outputting the packet loss information in the response message when the device is the source network equipment.

In a third aspect, a communication device is provided, the device comprising: a processor and a memory; the memory to store instructions; the processor is configured to execute the instructions in the memory to cause the apparatus to perform the method of the first aspect.

In a fourth aspect, there is provided a computer-readable storage medium comprising instructions which, when run on a computer, cause the computer to perform the method of the first aspect above.

According to the technical scheme provided by the embodiment of the application, the source network equipment serving as a path can generate the request message for inquiring the fault information on the path, so that the packet loss information of each network equipment on the path can be acquired through the request message. When the first network device obtains the request message, if the first network device is the target network device, the first network device obtains a response message according to the request message, wherein the response message comprises packet loss information. And the first network equipment sends the response message to the source network equipment according to the label information in the response message, so that the source network equipment acquires packet loss information on each network equipment. And if the first network equipment is not the target network equipment, forwarding the request message until the request message is forwarded to the target network equipment. Therefore, according to the embodiment of the application, the source network device can acquire the packet loss information of each network device on the target path in a mode of sending the request message, does not need to log in each network device, does not need to rely on fault recurrence for positioning, provides flexibility for fault query, and can quickly recover network service.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings needed to be used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments described in the present application, and other drawings can be obtained by those skilled in the art without creative efforts.

Fig. 1 is a schematic diagram of an MPLS packet forwarding scenario;

fig. 2 is a schematic view of an application scenario provided in an embodiment of the present application;

fig. 3 is a flowchart of a fault querying method according to an embodiment of the present application;

fig. 4a is a schematic diagram of a message format according to an embodiment of the present application;

fig. 4b is a schematic diagram of another message format provided in the embodiment of the present application;

fig. 5 is a flowchart of another fault querying method provided in the embodiment of the present application;

fig. 6 is a flowchart of another fault querying method provided in the embodiment of the present application;

fig. 7 is a structural diagram of a fault query apparatus according to an embodiment of the present application;

fig. 8 is a structural diagram of a communication device according to an embodiment of the present application.

Detailed Description

In order to make those skilled in the art better understand the solution of the present invention, the technical solution in the embodiment of the present invention will be clearly and completely described below with reference to the drawings in the embodiment of the present invention, and it is obvious that the described embodiment is only a part of the embodiment of the present invention, and not all embodiments.

Currently, in a multi-protocol label switching (MPLS) system, a Label Distribution Protocol (LDP) and a resource reservation protocol (RSVP) are the more common path establishment protocols in the MPLS system. In an actual establishment process, Label Switched Routers (LSRs) are bound according to Forwarding Equivalence Classes (FECs) and labels, and notify neighbor LSRs of the binding relationship. The FEC refers to a group of data streams forwarded along the same path and the same rule, and packets belonging to the same FEC all have the same label. For convenience of understanding, referring to fig. 1, in a pure LDP tunnel environment, a packet may carry a layer of label, where an outgoing label (also an incoming label corresponding to a local node) assigned to the FEC by an upstream node is carried when the packet enters an incoming interface of the local node from the upstream node, and an outgoing label assigned to a corresponding FEC by the local node is carried when the packet is sent to a downstream node from an outgoing interface of the local node.

As shown in fig. 1, after the MPLS label is distributed, an LSP is established, the destination address of the LSP is 4.4.4.2/32, and the label action of the MPLS packet in the forwarding process is as follows:

after receiving a message with a destination address of 4.4.4.2, an Ingress node first finds a corresponding next hop according to a Label Forwarding Information Base (LFIB), finds that the next hop is an LSR (if it finds that the next hop is an IP device, it directly forwards the message according to an FIB entry), and because the Ingress node is an Ingress node, it needs to perform a label push action before forwarding the message, finds a label to be pushed according to a mapping relationship between an FEC 4.4.4.2 and the label (for example, Z is used as an egress label), and then forwards the message from an egress interface to which the pushed label is mapped.

After receiving the message, the first intermediate node finds the outgoing label and the outgoing interface mapped by the corresponding incoming label (the outgoing label of the previous node is the incoming label of the node) according to the LFIB, firstly performs label switching, that is, replaces the original label (Z) in the message with the outgoing label (Y) locally allocated for FEC 4.4.4.2/32, and then forwards the outgoing label and the outgoing interface mapped by the found outgoing label.

After receiving the message, the second intermediate node also finds the outgoing label and the outgoing interface mapped by the corresponding incoming label according to the LFIB, replaces the original label (Y) with the outgoing label (usually 3) locally allocated to FEC 4.4.4.2/32, and then forwards the outgoing label from the outgoing interface mapped by the outgoing label 3. However, since Egress is given with an outgoing label value of 3 (this is a special label and must be popped up), PHP operation is required to be performed first, pop up the outgoing label (at this time, the message does not have the label), and forward the message according to the outgoing interface mapped by the outgoing label 3.

After receiving the non-labeled message, the Egress node directly transmits the data to the destination host 4.4.4.2/32 according to the corresponding IP routing table entry.

When a certain node in the network loses packets, the user side senses that the service quality is reduced and feeds back the service quality to an operator. The operation and maintenance department confirms each network device on the service path from the user access end, and logs in the network devices one by one to check whether the network devices have packet loss and the reason of the packet loss, and the means is complicated. Moreover, when the network devices on the service path belong to different operation and maintenance departments, authorization permission of other operation and maintenance departments is required, the query period is increased, and fault location and fault recovery cannot be performed quickly.

Based on this, an embodiment of the present application provides a fault query method, where when a fault on a certain service path needs to be queried, a head node serving as the service path may generate a request packet, so as to request fault information, that is, packet loss information, through the request packet. When the request message is forwarded to the tail node of the service path, the tail node generates a response message according to the request message, wherein the response message comprises packet loss information. The tail node forwards the response message to the head node, so that the head node can acquire packet loss information of each node on the service path without logging in each node on the service path or relying on the current network fault recurrence, and quick fault query is realized, thereby quickly recovering the service.

Referring to fig. 2, a network device, which may also be referred to as a node, is a device that provides a route forwarding function in a network system. For example, may be LSRs, switches, etc. As shown in fig. 2, taking the service path to be queried includes 4 network devices, which are respectively a network device PE2, a network device P2, a network device P3, and a network device PE1 as an example. The network device PE2 is a head node 201, the network device P2 and the network device P3 are intermediate forwarding nodes, which are respectively referred to as a first forwarding node 202 and a second forwarding node 203, and the network device PE1 is a tail node 204. In the above case, the node is taken as an independent network device as an example, and in other cases, the node may also be a functional module having a message forwarding capability in the network device. The solid line arrow represents the transmission direction of the request message, and the dotted line arrow represents the transmission direction of the response message.

As for the head node, in one case, the head node may be a node that generates the request packet, that is, when the head node is a node (source network device) corresponding to the source address in the packet, the head node is a first node on an end-to-end transmission path of the packet; in another case, when the message is initially generated and sent by the user equipment, the source address in the message may be the source address of the user equipment, and the head node may be the node connected to the user equipment.

For the tail node, in one case, the tail node may be a node (destination network device) corresponding to a destination address in the message; in another case, it may be the last node in the end-to-end transmission path within the domain where the node is currently located. The intermediate forwarding nodes are one or more forwarding nodes passing between the head node and the tail node during message forwarding.

For the convenience of understanding the fault querying method provided by the embodiments of the present application, the following description will be made with reference to the accompanying drawings.

Referring to fig. 3, which is a flowchart of a fault query method provided in an embodiment of the present application, as shown in fig. 3, the method may include:

s301: the first network equipment acquires the request message.

In this embodiment, the request packet is used to request packet loss information, where the packet loss information may include a packet loss reason and a packet loss number. The request message includes a destination identifier and label information, where the destination identifier is used to uniquely indicate a network device corresponding to a last hop on the target path, that is, a destination network device, such as tail node 204 in fig. 2. The destination identifier may be an IP address allocated to the destination network device, or a device identifier of the destination network device, or the like. The label information is used to indicate the next hop network device on the target path for performing the fault query, so that when the request packet is forwarded, the next hop network device on the target path can be determined according to the label information. The label information may include FEC corresponding to a head node to a tail node and an outgoing label or an incoming label corresponding to a current node. For example, the head node 201 searches for a corresponding outgoing label (an incoming label corresponding to the first intermediate node 202) according to the FEC, and forwards the request packet to the first forwarding node 202 through an outgoing interface corresponding to the outgoing label.

Specifically, when the first network device is a head node 201 on the service path, the first network device may generate the request message according to configuration operations of operation and maintenance staff; when the first network device is the first forwarding node 202 or the second forwarding node 203 on the traffic path, the first network device is forwarded by the previous-hop node on the received traffic path. For example, when the first network device is the first forwarding node 202, the first network device receives the request packet sent by the head node 201; when the first network device is the second forwarding node 203, the first network device receives the request packet sent by the first forwarding node 202.

Specifically, when the first network device is the head node 201 on the service path, the operation and maintenance staff may confirm information of the target path, such as information of an ingress node, an egress node, and a specific ingress/egress label, on the first network device, and perform configuration of the label information, so that the head node may generate the request packet according to the configured label information. After the head node 201 generates the request message, the egress interface corresponding to the label is determined according to the FEC in the request message and the egress label, so as to send the request message to the first forwarding node 202. After receiving the request message, the first forwarding node 202 determines an outgoing interface corresponding to the label according to FEC, so as to send the request message to the second forwarding node 203. After receiving the request packet, the second forwarding node 203 determines an outgoing interface corresponding to the label according to FEC, so as to send the request packet to the tail node 204.

It should be noted that, when there are multiple service paths between the head node 201 and the tail node 202, in order to ensure that the request packet corresponds to the target path one to one, the request packet may further carry a serial number, where the serial number is used to identify the target path to distinguish from other service paths. Or, when there are multiple tunnels between the head node 201 and the first forwarding node 202, different tunnels may be allocated to different users for service transmission, and when it is necessary to perform fault detection on a certain tunnel or multiple tunnels, the request packet may also include a sequence number, where the sequence number is used to distinguish detection for different tunnels. For example, there are tunnel 1 and tunnel 2 between head node 201 and first forwarding node 202, where tunnel 1 is allocated to user a for traffic transmission and tunnel 2 is allocated to user B for traffic transmission. When the transmission path corresponding to the user a and the transmission path corresponding to the user B need to be subjected to fault detection at the same time, the head node 201 includes a sequence number 1 in the generated first request message, where the sequence number 1 is used to indicate that the transmission path corresponding to the tunnel 1 is subjected to fault detection; the head node 202 includes a sequence number 2 in the generated second request message, where the sequence number 2 is used to instruct to perform fault detection on the transmission path corresponding to the tunnel 2.

In order to embody the continuity of message transmission, in this embodiment, both the request message sent by the head node 201 to the first forwarding node 202 and the request message sent by the first forwarding node 202 to the second forwarding node 203 are referred to as request messages, but it can be understood that there is a difference in actual application scenarios between the request message sent by the head node 201 to the first forwarding node 202 and the request message sent by the first forwarding node 202 to the second forwarding node 203. For example, there may be a difference between Time To Live (TTL) and information such as an outgoing label, that is, when the first forwarding node 202 forwards the request packet sent by the head node 201 to the second forwarding node 203, the updated request packet may actually be an updated request packet with some necessary information modified. The so-called request packet sent by the subsequent second forwarding node 203 to the tail node 204 is also of similar meaning, and may be substantially an updated request packet.

S302: and when the first network equipment is the destination network equipment corresponding to the destination identifier, the first network equipment generates a response message according to the request message.

In this embodiment, after acquiring the request message, the first network device may determine according to the destination identifier in the request message and the identifier of the first network device, so as to determine whether the first network device is a destination network device corresponding to the destination identifier. For example, when the destination identifier is the destination IP address, the first network device may determine whether its own IP address is consistent with the destination IP address after receiving the request packet, and if so, it indicates that the first network device is the destination network device. Or, when the target identifier is the destination device identifier, after receiving the request packet, the first network device may determine whether its own device identifier is consistent with the destination device identifier, and if so, it indicates that the first network device is the destination network device.

When the first network device confirms that the first network device is the destination network device, the first network device indicates that the request message is forwarded to the last hop network device of the destination path, and at this time, the first network device can obtain the response message according to the request message without forwarding. The first network device obtains the response message according to the request message by adding the packet loss information acquired by each network device on the target path to the request message when forwarding the request message, and the target network device generates the response message according to the request message when the target network device is reached; and the other is that each network device on the target path only forwards the request message until the request message is forwarded to the target network device, the target network device generates a response message, adds packet loss information in the response message, and forwards the response message to the next-hop network device on the target path until the response message is forwarded to the source network device. Specific implementation of the above two modes will be described in the following embodiments.

The response message includes packet loss information and label information. The packet loss information includes packet loss information corresponding to each network device on the target path. Specifically, when each network device on the target path forwards the service traffic, the forwarding plane may automatically capture the discarded packet, and record the packet loss number and the packet loss reason. For example, as shown in fig. 1, an outgoing label in a packet forwarded by an ingress node is K, and after receiving the packet, a first forwarding node finds that an assigned label is Z and the label K in the packet is inconsistent, and discards the packet. The label information is used for indicating the next hop network device corresponding to the first network device on the target path. For example, the first network device is the tail node 204 and the label information is used to indicate the second forwarding node 203.

S303: and the first network equipment sends the response message to the source network equipment according to the label information.

After the first network device obtains the response message according to the request message, the first network device may forward the response message to the second network device according to the tag information in the response message, and the second network device forwards the response message according to the tag information in the message until the response message is forwarded to the source network device, such as the head node 201, so that the source network device obtains the packet loss information of each network device on the target path, and thus, a maintenance person may perform fault location according to the packet loss information in the response message, and then perform fault recovery, thereby improving fault query efficiency. And the second network equipment is the next hop network equipment corresponding to the first network equipment on the target path.

Specifically, when the first network device is the tail node 204, the first network device may find the label according to the FEC, so as to send the response packet to the second forwarding node 203 according to the outgoing interface corresponding to the outgoing label. After receiving the response packet, the second forwarding node 203 finds the label according to the FEC, and sends the response packet to the first forwarding node 202 according to the outgoing interface corresponding to the outgoing label. When the first forwarding node 202 receives the response packet, the label is found according to the FRC, so that the corresponding packet is sent to the head node 201 according to the outgoing interface corresponding to the outgoing label. When the head node 201 receives the response packet, it is determined that it is the source network device, and the response packet may be analyzed to obtain packet loss information corresponding to each node on the path.

In order to embody the continuity of message transmission, in this embodiment, both the response message sent by the tail node 204 to the second forwarding node 203 and the request message sent by the second forwarding node 203 to the first forwarding node 202 are referred to as response messages, but it can be understood that there is a difference in actual application scenarios between the response message sent by the tail node 204 to the second forwarding node 203 and the response message sent by the second forwarding node 203 to the first forwarding node 202. For example, there may be a difference between Time To Live (TTL) and information such as an outgoing label, that is, when the second forwarding node 203 forwards the response packet sent by the tail node 201 to the first forwarding node 202, the updated request packet may actually be an updated request packet with some necessary information modified. The so-called response message sent by the first forwarding node 202 to the head node 201 is also of similar meaning, and may be substantially an updated response message.

In a possible implementation manner, after the source network device receives the response message, the packet loss information in the response message may be output, so that maintenance personnel may intuitively know the packet loss information on each network device. Specifically, the source network device may send the packet loss information to a terminal with a display function for display, or send the packet loss information to a user device corresponding to a maintenance worker.

The message types of the request message and the response message are defined by a newly added Type-length-value (TLV), wherein a Type field is used to indicate the Type of the message, and for example, when the Type is 0x3E0C, the message is a request message; when the Type is 0x3E0D, it indicates that the message is a response message. The Length field is used for indicating the number of bytes contained in the 'Vlaue' field; the Vlaue field is not limited, and may be composed of a plurality of TLVs. Specifically, the request message and the response message may each include a data portion for encapsulating the packet loss tracing parameter, for example, as shown in fig. 4a, the data portion may include a sequence number field, a reserved field, an Ingress LSR ID field, an Egress LSR ID field, an FEC TLV field, a Label TLV field, and a Hop Record 1 … N field.

Wherein, Sequence Number: the request sequence number may be set by the initiator, such as by head node 201.

Ingress LSR Id: ingress device Id.

Egress LSR Id: egress device Id.

FEC TLV: the equivalence class is forwarded.

Label TLV: the incoming label of the next hop device updates this field as each hop device forwards upstream.

Hop Record 1.. N: and (5) recording the specific packet loss.

The specific format of the Hop Record is shown in fig. 4b, and includes: an LSR ID field, Record Count field, Packet Loss Reson 1 … N field, and Packet Loss Count 1 … N.

LSR Id: for identifying an LSR, such as identifying a PE1 device.

Record Count: the number of packet loss records of the device.

Packet Loss Reson 1.. N: and a packet loss reason of a packet loss record.

Packet Loss Count 1.. N: the Packet Loss number of one Packet Loss record and Packet Loss Reson 1. There may be multiple packet loss records per network device LSR.

Based on the above embodiment, it can be known that the first network device obtains the response message based on the request message through two ways, one is that the first network device serving as the target network device generates the response message according to the request message, and adds the packet loss information acquired by the first network device to the response message; and forwarding the response message to the second network equipment according to the label information in the response message, so that the second network equipment adds the collected packet loss information to the response message and forwards the response message until the response message is forwarded to the source network equipment. In this implementation, the request packet is forwarded from the source network device to the destination network device, and the destination network device generates a response packet according to the request packet and adds packet loss information collected by itself to the response packet. And the target network equipment forwards the response message according to the label information in the response message until the response message is forwarded to the source network equipment, so that the packet loss information of each network equipment on the target path is obtained.

And the other way is that the first network device adds the collected packet loss information to the request message, and when the first network device is not the destination network device corresponding to the destination identifier, the first network device sends the request message to the third network device according to the label information, so that the third network device adds the collected packet loss information to the request message and forwards the request message until the packet loss information is forwarded to the destination network device corresponding to the destination identifier. And the third network equipment is the next hop network equipment corresponding to the first network equipment on the target path. When the request packet is forwarded to the destination network device, the first network device serving as the destination network device may add packet loss information acquired by the first network device to the request packet and convert the request packet into a response packet, where the response packet includes the packet loss information added by each network device on the target path. That is, in this implementation manner, in the process of forwarding the request packet, each network device adds packet loss information acquired by itself to the request packet, and then when the request packet is forwarded to the destination network device, the destination network device generates a response packet according to the request packet.

For the convenience of understanding the two above-mentioned acquisition modes, they will be separately described with reference to the accompanying drawings. It should be noted that the following description will be made in conjunction with the scenario of fig. 2.

Referring to fig. 5, which is a flowchart of obtaining a response packet according to an embodiment of the present application, some specific implementations related to this figure may refer to the embodiment described in fig. 3, where the method may include:

s501: head node 201 generates a request message and sends the request message to first forwarding node 202 according to the label information.

In this embodiment, as the head node 201 on the target path, it may create a request message according to the parameters configured by the operation and maintenance staff, for example, the target path configured by the operation and maintenance staff, the FEC corresponding to the target path, and the like, where the request message may include the destination identifier and the label information. The label information may be a first outgoing label assigned to the target path by the first forwarding node. Specifically, the head node 201 sends the request packet to the first forwarding node 202 according to the outgoing interface corresponding to the first outgoing label.

S502: the first forwarding node 202 sends the request message to the second forwarding node 203 according to the label information in the request message.

In this embodiment, after receiving the request message sent by the head node 201, the first forwarding node 202 determines an incoming label (a first outgoing label in the request message) according to the request message, searches for a second outgoing label corresponding to the incoming label and an outgoing interface corresponding to the second outgoing label according to FEC, replaces the first outgoing label in the request message with the second outgoing label, and forwards the request message to the second forwarding node 203 by using the outgoing interface corresponding to the second outgoing label. And the second outgoing label is an outgoing label distributed by the second forwarding node for the target path.

S503: the second forwarding node 203 sends the request message to the tail node 204 according to the label information in the request message.

In this embodiment, after receiving the request message, the second forwarding node 203 determines an incoming label (a second outgoing label in the request message) according to the request message, searches for a third outgoing label corresponding to the incoming label and an outgoing interface corresponding to the third outgoing label according to the FEC, replaces the second outgoing label in the request message with the third outgoing label, and forwards the request message to the tail node 204 by using the outgoing interface corresponding to the third outgoing label. The third outgoing label is an outgoing label assigned to the target path by the tail node 204.

S504: the tail node 204 generates a response packet according to the request packet, and adds the collected packet loss information to the response packet.

In this embodiment, after the tail node 204 receives the request message, it determines that it is a destination node corresponding to the target identifier according to the destination identifier in the request message, and then generates a response message according to the request message. Meanwhile, the tail node 204 adds the packet loss information acquired by itself to the response message. The response message may further include label information and a destination identifier, where the label information is used to indicate a next hop node, and the destination identifier is used to indicate a node that generates the request message, such as the head node 201.

The tail node 204 generates a response packet according to the request packet, which may include: tail node 204 converts the request message into a response message. Specifically, the tail node 204 obtains the response packet by modifying the type of the packet in the request packet. For example, when the message type is 0, it indicates that the message is a request message; and when the message type is 1, the message is represented as a response message. The tail node 204 modifies the message type 0 in the request message to 1, thereby obtaining a response message.

It should be noted that, in the process of forwarding the request message, when each node on the target path receives the request message, it is determined whether the node is a target node corresponding to the target identifier according to the target identifier in the request message, and if the node is not a target node, subsequent forwarding is performed according to the tag information in the request message; and if the node is the destination node, generating a response message according to the request message.

S505: the tail node 204 sends the response message to the second forwarding node 203 according to the label information in the response message.

In this embodiment, the tail node 204 determines the fourth outgoing label according to the label information in the response packet, and sends the response packet to the second forwarding node 203 by using the outgoing interface corresponding to the fourth outgoing label.

S506: the second forwarding node 203 adds the packet loss information acquired by itself to the response message, and sends the response message to the first forwarding node 202 according to the label information in the response message.

When the second forwarding node 203 receives the response message sent by the tail node 204, the second forwarding node 203 reads packet loss information acquired in advance from the local, and adds the packet loss information to the response message. Meanwhile, the second forwarding node 203 determines an incoming label (a fourth outgoing label in the request message) according to the request message, queries a fifth outgoing label corresponding to the incoming label and an outgoing interface corresponding to the fifth outgoing label according to the FEC, replaces the fourth outgoing label in the response message with the fifth outgoing label, and forwards the response message to the first forwarding node 202 by using the outgoing interface corresponding to the fifth outgoing label.

S507: the first forwarding node 202 adds the packet loss information acquired by itself to the response message, and sends the response message to the head node 201 according to the label information in the response message.

For specific implementation of forwarding by the first forwarding node 202 according to the label information of the response packet, refer to S505 or S506, which is not described herein again in this embodiment.

S508: the head node 201 outputs packet loss information.

In this embodiment, when receiving the response message sent by the first intermediate point 202, the head node 201 may add the packet loss information acquired by itself to the response message, and then output the packet loss information in the response message. Or, when receiving the response message sent by the first forwarding node 202, the head node 201 outputs packet loss information in the response message and packet loss information acquired by itself.

It should be noted that, in the process of forwarding the response packet, when each node on the target path receives the response packet, it is determined whether the node is a node corresponding to the destination identifier according to the destination identifier in the response packet, and if the node is not a node corresponding to the destination identifier, subsequent forwarding is performed according to the tag information in the response packet; and if the node is the node corresponding to the destination identifier, outputting packet loss information in the response message.

In this embodiment, each node adds an application scenario of packet loss information in a response packet, and may be applied to an LSP constructed by an RSVP protocol or an LDP protocol.

Referring to fig. 6, which is another flow chart for acquiring a response packet provided in the embodiment of the present application, some specific implementations related to this figure may refer to the embodiment described in fig. 3 or fig. 5, where the method may include:

s601: the head node 201 generates a request message, and adds packet loss information acquired by itself to the request message.

In this embodiment, after generating the request message, the head node 201 may locally read packet loss information acquired in advance, and add the packet loss information to the request message, so that the request message includes the packet loss information corresponding to the head node 201. It can be understood that the head node 201 may also generate only the request packet without adding the packet loss information acquired by itself, but add the packet loss information acquired by itself to the request packet from the first forwarding node 202. Whether the head node 201 adds the packet loss information to the request packet may be selected according to an actual application, and this embodiment is not limited herein.

For specific implementation of generating the request packet by the head node 201, reference may be made to S301 and S501, which is not described herein again in this embodiment.

S602: head node 201 forwards the request message to first forwarding node 202 based on the label information in the request message.

For specific implementation of S602, refer to S502 or S503, which is not described herein again.

S603: the first forwarding node 202 adds the packet loss information acquired by itself to the request packet.

S604: the first forwarding node 202 forwards the request message to the second forwarding node 203 according to the label information in the request message.

For the forwarding operation performed by the first forwarding node 202, reference may be specifically made to S502, S302, or S303, which is not described herein again.

S605: the second forwarding node 203 adds the packet loss information collected by itself to the request packet.

S606: the second forwarding node 203 forwards the request message to the tail node 204 according to the label information in the request message.

The forwarding operation performed by the second forwarding node 203 may specifically refer to S504, S502, S302, or S303, which is not described herein again.

S607: the tail node 204 generates a response message from the request message.

In this embodiment, after the tail node 204 receives the request message, it determines that it is a destination node corresponding to the target identifier according to the destination identifier in the request message, and then generates a response message according to the request message. Specifically, the tail node 204 may add the packet loss information collected by itself to the request packet, and then generate a response packet according to the request packet. Or, the tail node 204 generates a response message according to the request message, and then adds the packet loss information acquired by itself to the response message.

S608: the tail node 204 sends the response message to the second forwarding node 203 according to the label information in the response message.

S609: the second forwarding node 203 sends the response message to the first forwarding node 202 according to the label information in the response message.

S610: first forwarding node 202 sends the response message to head node 201 according to the label information in the response message.

S611: the head node 201 outputs packet loss information.

It should be noted that, in this embodiment, each node adds an application scenario of packet loss information in a request packet, mainly for an LSP constructed based on an RSVP protocol.

Based on the above method embodiments, the present application provides a fault query apparatus, which will be described below with reference to the accompanying drawings.

Referring to fig. 7, which is a schematic structural diagram of a fault querying device provided in an embodiment of the present application, where the fault querying device may be applied to a first network device, and perform the function of the first network device in the embodiment shown in fig. 3, where the fault querying device may include: a first acquisition unit 701, a second acquisition unit 702, and a transmission unit 703.

The first obtaining unit 701 is configured to obtain a request packet, where the request packet is used to request packet loss information, the request packet includes a destination identifier and tag information, and the tag information is used to indicate a next-hop network device on a target path for performing a fault query.

When the network device applied by the apparatus 700 is the head node 201, the specific implementation of the first obtaining unit 701 obtaining the request packet may refer to S301, S501, or S601. When the network device applied by the apparatus 700 is the first forwarding node 202, the second forwarding node 203, or the tail node 204, the first obtaining unit 701 may receive the request packet from the previous-hop network device, and the specific implementation may refer to S502, S503, S602, S604, or S606.

A second obtaining unit 702, configured to, when the apparatus is a destination network device corresponding to a destination identifier, obtain a response packet according to the request packet, where the response packet includes packet loss information and the tag information.

When the network device applied to the apparatus 700 is a destination network device corresponding to the destination identifier, the specific implementation of the second obtaining unit 702 obtaining the response message according to the request message may refer to S302, S504, or S607.

A sending unit 703, configured to send the response packet to a source network device according to the tag information, where the source network device is a network device that generates the request packet.

The implementation of sending the response packet to the source network device by the sending unit 703 may refer to S303, S505-S507, or S607-S610.

In a possible implementation manner, the second obtaining unit is specifically configured to generate a response packet according to the request packet, and add the collected packet loss information to the response packet; a sending unit, configured to send the response packet to a second network device according to the tag information, so that the second network device adds the collected packet loss information to the response packet, and forwards the response packet until the response packet is forwarded to a source network device, where the second network device is a next-hop network device corresponding to the first network device on the target path.

For a specific implementation of the second obtaining unit generating the response packet, see S504, and for an implementation of the sending unit sending the response packet to the second network device, see S505, S506, or S507.

When the network device applied by the apparatus 700 is not the destination network device, that is, is not the tail node, the implementation of the sending unit may refer to S502 and S503.

In one possible implementation, the apparatus further includes:

the adding unit is used for adding the acquired packet loss information to the request message after the request message is acquired;

the sending unit is further configured to send the request packet to a third network device according to tag information when the apparatus is not a destination network device corresponding to the destination identifier, so that the third network device adds the acquired packet loss information to the request packet and forwards the request packet until the request packet is forwarded to the destination network device corresponding to the destination identifier, where the third network device is a next hop network device corresponding to the first network device on the destination path;

the second obtaining unit is specifically configured to convert the request packet into a response packet, where the response packet includes packet loss information added to each network device on the target path.

For a specific implementation of the adding unit, see any step of S601-S606, and when the network device applied by the apparatus 700 is not the destination network device, the sending unit may be implemented as S601-S606. The specific implementation of the second obtaining unit can be seen in S607.

For a specific implementation of the second obtaining unit, see S504 or S607.

In a possible implementation manner, the message type is a request message when the message type is a first numerical value, and the message type is a response message when the message type is a second numerical value.

In one possible implementation, the target path is generated based on the standard resource reservation protocol RSVP.

In one possible implementation, the apparatus further includes:

For a specific implementation of the output unit, see S508 or S611.

For specific executable functions and implementations of the apparatus 700, reference may be made to corresponding descriptions of the first network device in the embodiments shown in fig. 3, fig. 5, or fig. 6, which are not described herein again.

Fig. 8 is a schematic structural diagram of a network device provided in an embodiment of the present application, where the network device may be, for example, a first network device, a second network device, or a third network device in the embodiments shown in fig. 3, fig. 5, or fig. 6, or may also be a device implementation of the fault querying apparatus 700 in the embodiment shown in fig. 7.

Referring to fig. 8, a network device 800 includes: a processor 810, a communication interface 820, and a memory 830. The number of the processors 810 in the message forwarding device 800 may be one or more, and fig. 8 illustrates one processor as an example. In the embodiment of the present application, the processor 810, the communication interface 820 and the memory 830 may be connected by a bus system or other means, wherein fig. 8 is exemplified by the connection via the bus system 840.

The processor 810 may be a CPU, an NP, or a combination of a CPU and an NP. The processor 810 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a Programmable Logic Device (PLD), or a combination thereof. The PLD may be a Complex Programmable Logic Device (CPLD), a field-programmable gate array (FPGA), a General Array Logic (GAL), or any combination thereof.

The processor 810 may perform related functions of obtaining the request message, obtaining the response message, and adding packet loss information in the response message in the above method embodiments.

The communication interface 820 is used for receiving and transmitting messages, and particularly, the communication interface 820 may include a receiving interface and a transmitting interface. The receiving interface may be configured to receive a message, and the sending interface may be configured to send a message. The number of the communication interfaces 820 may be one or more.

Memory 830 may include volatile memory (RAM), such as random-access memory (RAM); the memory 830 may also include a non-volatile memory (SSD), such as a flash memory (flash memory), a hard disk (HDD) or a solid-state drive (SSD); memory 830 may also comprise a combination of the above types of memory.

Optionally, memory 830 stores an operating system and programs, executable modules or data structures, or subsets thereof or extensions thereof, wherein the programs may include various operating instructions for performing various operations. The operating system may include various system programs for implementing various basic services and for handling hardware-based tasks. The processor 810 can read the program in the memory 830 to implement the fault query method provided by the embodiment of the present application.

The memory 830 may be a storage device in the network device 800, or may be a storage device independent from the network device 800.

The bus system 840 may be a Peripheral Component Interconnect (PCI) bus, an Extended Industry Standard Architecture (EISA) bus, or the like. The bus system 840 may be divided into an address bus, a data bus, a control bus, and so on. For ease of illustration, only one thick line is shown in FIG. 8, but this is not intended to represent only one bus or type of bus.

The terms "first," "second," "third," "fourth," and the like in the description and in the claims of the present application and in the drawings described above, if any, are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It will be appreciated that the data so used may be interchanged under appropriate circumstances such that the embodiments described herein may be practiced otherwise than as specifically illustrated or described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed, but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.

It is clear to those skilled in the art that, for convenience and brevity of description, the specific working processes of the above-described systems, apparatuses and units may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.

In the several embodiments provided in the present application, it should be understood that the disclosed system, apparatus and method may be implemented in other manners. For example, the above-described embodiments of the apparatus are merely illustrative, and for example, a division of a unit is only a logical division, and an actual implementation may have another division, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

Units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

In addition, each service unit in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a hardware form, and can also be realized in a software service unit form.

The integrated unit, if implemented in the form of a software business unit and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application may be substantially implemented or contributed to by the prior art, or all or part of the technical solution may be embodied in a software product, which is stored in a storage medium and includes instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method of the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk, and other various media capable of storing program codes.

Those skilled in the art will recognize that, in one or more of the examples described above, the services described in this disclosure may be implemented in hardware, software, firmware, or any combination thereof. When implemented in software, the services may be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A storage media may be any available media that can be accessed by a general purpose or special purpose computer.

The above embodiments are intended to explain the objects, aspects and advantages of the present invention in further detail, and it should be understood that the above embodiments are merely illustrative of the present invention.

The above embodiments are only used to illustrate the technical solutions of the present application, and not to limit the same; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; and the modifications or the substitutions do not make the essence of the corresponding technical solutions depart from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A method of fault querying, the method comprising:

a first network device acquires a request message, wherein the request message is used for requesting packet loss information, the request message comprises a destination identifier and label information, and the label information is used for indicating a next hop network device of a target path for fault query;

when the first network device is a destination network device corresponding to a destination identifier, the first network device obtains a response message according to the request message, wherein the response message comprises packet loss information and the label information;

and the first network equipment sends the response message to source network equipment according to the label information, wherein the source network equipment is the network equipment for generating the request message.

2. The method of claim 1, wherein the obtaining, by the first network device, a response packet according to the request packet comprises:

the first network equipment generates a response message according to the request message, and adds the collected packet loss information to the response message;

the first network device sends the response message to a source network device according to the label information, including:

and the first network equipment sends the response message to second network equipment according to the label information, so that the second network equipment adds the collected packet loss information to the response message and forwards the response message until the response message is forwarded to source network equipment, wherein the second network equipment is next-hop network equipment corresponding to the first network equipment on the target path.

3. The method of claim 2, wherein when the first network device is not a corresponding destination network device for the destination identification, the method further comprises:

and the first network equipment sends the request message to third network equipment according to the label information, so that the third network equipment forwards the request message until the request message is forwarded to the target network equipment corresponding to the target identifier.

4. The method according to claim 2 or 3, wherein the target path is generated based on resource reservation protocol RSVP or label distribution protocol LDP.

5. The method of claim 1, wherein after the first network device obtains the request packet, the method further comprises:

the first network equipment adds the collected packet loss information to the request message;

when the first network device is not a destination network device corresponding to the destination identifier, the first network device sends the request message to a third network device according to tag information, so that the third network device adds the acquired packet loss information to the request message and forwards the request message until the request message is forwarded to the destination network device corresponding to the destination identifier, and the third network device is a next hop network device corresponding to the first network device on the target path;

the first network device obtains a response message according to the request message, and the method comprises the following steps:

and the first network equipment converts the request message into a response message, wherein the response message comprises packet loss information added by each network equipment on the target path.

6. The method according to any of claims 1-5, wherein the obtaining, by the first network device, a response message according to the request message comprises:

and the first network equipment modifies the message type in the request message to obtain a response message.

7. The method of claim 6, wherein the message type is a request message when the message type has a first value and a response message when the message type has a second value.

8. The method according to any of claims 5-7, wherein the target path is generated based on the label distribution protocol RSVP.

9. The method according to any of claims 1-8, wherein the request packet further includes a sequence number when there are multiple paths from the source network device to the destination network device, and wherein the response packet further includes the sequence number, and wherein the sequence number is used to indicate the destination path, or wherein the request packet further includes a sequence number when there are multiple tunnels between the first network device and the second network device, and wherein the response packet further includes the sequence number, and wherein the sequence number is used to indicate a destination tunnel.

10. The method according to any of claims 1-9, wherein when the first network device is the source network device, the method further comprises:

and the first network equipment outputs the packet loss information in the response message.

11. A fault querying device, the device comprising:

a first obtaining unit, configured to obtain a request packet, where the request packet is used to request packet loss information, the request packet includes a destination identifier and tag information, and the tag information is used to indicate a next-hop network device on a target path for performing a fault query;

a second obtaining unit, configured to obtain, when the apparatus is a destination network device corresponding to a destination identifier, a response packet according to the request packet, where the response packet includes packet loss information and the tag information;

and the sending unit is used for sending the response message to source network equipment according to the label information, and the source network equipment is the network equipment for generating the request message.

12. The apparatus according to claim 11, wherein the second obtaining unit is specifically configured to generate a response packet according to the request packet, and add the collected packet loss information to the response packet;

the sending unit is specifically configured to send the response packet to a second network device according to the tag information, so that the second network device adds the acquired packet loss information to the response packet and forwards the response packet until the response packet is forwarded to a source network device, where the second network device is a next-hop network device corresponding to the first network device on the target path.

13. The apparatus according to claim 12, wherein when the apparatus is not a destination network device corresponding to the destination identifier, the sending unit is further configured to send the request packet to a third network device according to the tag information, so that the third network device forwards the request packet until the request packet is forwarded to the destination network device corresponding to the destination identifier.

14. The apparatus according to claim 12 or 13, wherein the target path is generated based on resource reservation protocol RSVP or label distribution protocol LDP.

15. The apparatus of claim 11, further comprising:

16. The apparatus according to any one of claims 11 to 15, wherein the second obtaining unit is specifically configured to modify a message type obtaining response message in the request message.

17. The apparatus of claim 16, wherein the message type is a request message when the message type has a first value and a response message when the message type has a second value.

18. The apparatus according to any of claims 15-17, wherein the target path is generated based on resource reservation protocol RSVP.

19. The apparatus according to any of claims 11-18, wherein the request packet further includes a sequence number when there are multiple paths from the source network device to the destination network device, wherein the response packet further includes the sequence number, wherein the sequence number is used to indicate the destination path, or wherein the request packet further includes a sequence number when there are multiple tunnels between the first network device and the second network device, wherein the response packet further includes the sequence number, wherein the sequence number is used to indicate a destination tunnel.

20. The apparatus of any one of claims 11-19, further comprising:

21. A communication device, the device comprising: a processor and a memory;

the memory to store instructions;

the processor configured to execute the instructions in the memory to cause the apparatus to perform the method of any one of claims 1-10.

22. A computer-readable storage medium comprising instructions which, when executed on a computer, cause the computer to perform the method of any of claims 1-10 above.