CN114205221B

CN114205221B - Fault query method and device

Info

Publication number: CN114205221B
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: 2024-01-02
Anticipated expiration: 2040-08-26
Also published as: CN114205221A

Abstract

The embodiment of the application discloses a fault query method and device, which specifically comprise the following steps: in order to query packet loss information on a certain path, a source network device on the path can generate a request message. When the first network device acquires the request message, if the first network device is a target network device, acquiring a response message according to the request message, wherein the response message comprises packet loss information. The first network device sends the response message to the source network device according to the label information in the response message, so that the source network device obtains the packet loss information on each network device. If the first network device is not the destination network device, the request message is forwarded until the request message is forwarded to the destination network device. Therefore, the 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 reproduction to locate, and provides flexibility of fault inquiry.

Description

Fault query method and device

Technical Field

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

Background

In the service forwarding process of the existing network, sometimes unknown faults occur in equipment, so that the packet loss of the bearing service flow is caused, and the service is damaged. When the current network loses the service flow, not only the service needs to be recovered as soon as possible, but also the fault point and the fault cause need to be checked as soon as possible.

At present, fault location is generally performed by adopting a means in the past, that is, the fault location is performed by repeatedly depending on the current network fault phenomenon. However, because of uncertain service interruption time or because of different operators/operation departments to which a plurality of devices in the existing network belong, it is difficult to log in the devices, so that the existing network cannot be diagnosed and restored quickly.

Disclosure of Invention

The embodiment of the application provides a fault query method and device, which can realize rapid positioning and recovery of faults in the existing network and improve the flexibility of fault detection.

In a first aspect, an embodiment of the present application provides a fault query method, where the method may include: the method comprises the steps that first network equipment obtains a request message, wherein the request message is used for requesting packet loss information, the request message comprises a destination identifier and tag information, and the tag information is used for indicating next hop network equipment of a target path for fault inquiry; when the first network equipment is a destination network equipment corresponding to a destination identifier, the first network equipment acquires a response message according to the request message, wherein the response message comprises packet loss information and 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 a traffic transmission path. When the fault information on the transmission path needs to be queried, the head node on the transmission path can generate a request message, and the request message is transmitted on the transmission path so as to request packet loss information of each network device on the transmission path through the request message. 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 destination network device, and the destination network device obtains a response message according to the request message, wherein the response message comprises packet loss information. The destination 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 acquire the specific information of packet loss of each network device on the transmission path, operation and maintenance personnel are not required to log in one by one, and the fault inquiry efficiency is improved.

In a possible implementation manner, the first network device obtains a response message according to the request message, including: the first network equipment generates a response message according to the request message, and adds the acquired packet loss information to the response message; the first network device sends the response message to the source network device according to the tag information, and the method comprises the following steps: the first network device sends the response message to the second network device according to the tag information, so that the second network device adds the acquired packet loss information to the response message, forwards the response message until the response message is forwarded to the source network device, and the second network device is the next hop network device corresponding to the first network device on the target path.

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

In one possible implementation manner, when the first network device is not a destination network device corresponding to the destination identification, 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 destination network equipment corresponding to the destination identifier.

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

In one possible implementation manner, after the first network device obtains the request packet, the method further includes: the first network device adds the acquired packet loss information to the request message; 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 a third network device according to tag information, so that the third network device adds acquired packet loss information to the request message, 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 the 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, including: the first network device converts the request message into a response message, wherein the response message comprises packet loss information added by each network device on the target path.

In the implementation manner, in the forwarding process of the request message, each network device on the transmission path adds the packet loss information acquired by itself to the request message after receiving the request message. When the request message is forwarded to the destination network device, the destination network device adds the packet loss information acquired 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 one possible implementation manner, the first network device converts the request message into a response message, including: the first network device modifies the message type in the request message to obtain a response message.

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

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

In one possible implementation manner, when there are multiple paths from the source network device to the destination network device, the request message further includes a sequence number, the response message further includes the sequence number, where the sequence number is used to indicate the destination path, or when there are multiple tunnels between the first network device and the second network device, the request message further includes a sequence number, where the response message further includes the sequence number, where the sequence number is used to indicate the 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, there is provided a fault querying device, the device comprising: the first acquisition unit is used for acquiring a request message, wherein the request message is used for requesting packet loss information, the request message comprises a destination identifier and tag information, and the tag information is used for indicating the next hop network equipment on a target path for fault inquiry; the second obtaining unit is used for obtaining a response message according to the request message when the device is a target network device corresponding to a target identifier, wherein the response message comprises packet loss information and label information; and the sending unit is used for sending 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.

In one possible implementation manner, the second obtaining unit is specifically configured to generate a response message according to the request message, and add the acquired packet loss information to the response message; the sending unit is specifically configured to send the response message 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 message, and forwards the response message until the response message 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 the 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 acquiring the request message; 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 acquired packet loss information to the request packet, 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 target 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 by 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, there is provided a communication device, the device comprising: a processor and a memory; the memory is used for storing instructions; the processor is configured to execute the instructions in the memory to cause the device 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, for inquiring the fault information on a certain path, the source network equipment on the path can generate a request message so as to acquire the packet loss information of each network equipment on the path through the request message. When the first network device acquires the request message, if the first network device is the target network device, the first network device acquires a response message according to the request message, wherein the response message comprises packet loss information. The first network device sends the response message to the source network device according to the label information in the response message, so that the source network device obtains the packet loss information on each network device. If the first network device is not the destination network device, the request message is forwarded until the request message is forwarded to the destination network device. 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 reproduction to locate, provides flexibility of 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 that are required to be used in the embodiments or the description of the prior art will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments described in the present application, and other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

FIG. 1 is a schematic diagram of an MPLS message 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 query 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 diagram illustrating another message format according to an embodiment of the present disclosure;

FIG. 5 is a flowchart of another fault query method according to an embodiment of the present disclosure;

FIG. 6 is a flowchart of another fault query method according to an embodiment of the present application;

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

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

Detailed Description

In order to make the solution of the present invention better understood by those skilled in the art, the technical solution of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention, and it is apparent that the described embodiments are only some embodiments of the present invention, not all embodiments.

Currently, in a multiprotocol label switching (multi-protocol label switching, MPLS) system, a label distribution protocol (label distribution protocol, LDP) and a resource reservation protocol (resource reservation protocol, RSVP) are path setup protocols that are more commonly used in MPLS systems. In the actual set-up procedure, label switching routers (label switched router, LSR) bind together according to forwarding equivalence classes (forwarding equivalence class, FEC) and labels and advertise the binding to neighbor LSRs. The FEC refers to a group of data streams forwarded along the same path and the same rule, and all the messages belonging to the same FEC have the same label. For ease of understanding, referring to fig. 1, in a simple LDP tunnel environment, a packet may carry a layer of label, and when the packet enters an ingress interface of a local node from an upstream node, an outgoing label allocated to the FEC by the upstream node (also an ingress label corresponding to the local node) is carried, and when the packet is sent from the local node egress interface to a downstream node, an outgoing label allocated to the corresponding FEC by the local node is carried.

As shown in fig. 1, MPLS labels are distributed, an LSP is established, the destination address is 4.4.4.2/32, and the label actions of MPLS packets in the forwarding process are 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 (label forwarding information base, LFIB), finds that the next hop is an LSR (if the next hop is found to be an IP device, the message forwarding is directly performed according to FIB entries), and because the Ingress node is an Ingress node, a label pressing-in action needs to be performed before the message forwarding is performed, a label to be pressed in is found according to a mapping relation between 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 mapped by the pressed label.

After the first intermediate node receives the message, the first intermediate node finds out the outbound label and the outbound interface mapped by the inbound label (the outbound label of the previous node is the inbound label of the own node) according to the LFIB, and performs label switching firstly, namely replaces the original label (Z) in the message with the outbound label (Y) locally distributed for FEC 4.4.4.2/32, and then forwards the message from the outbound interface mapped by the outbound label found above.

After receiving the message, the second intermediate node also finds out the outbound label and the outbound interface mapped by the corresponding inbound label according to the LFIB, replaces the original label (Y) with the outbound label (usually 3) locally allocated for FEC 4.4.4.2/32, and then forwards the outbound label from the outbound interface mapped by the outbound label 3. However, since the Egress score gives a label value of 3 (this is a special label, which must be popped), it is necessary to perform PHP operation first, pop up the outgoing label (the message is not already labeled at this time), and forward the message according to the outgoing interface mapped by the outgoing label 3.

After receiving the unlabeled message, the Egress (Egress) node directly transmits 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 perceives the degradation of service quality and feeds back to an operator. The operation and maintenance department confirms each network device on the service path from the user access terminal, logs in the network device one by one to check whether the network device has packet loss and the cause of the packet loss, and the means are complicated. In addition, when the network devices on the service path belong to different operation and maintenance departments, the inquiry period is increased by the authorization permission of other operation and maintenance departments, and the fault location and the fault recovery cannot be performed quickly.

Based on this, the embodiment of the application provides a fault query method, when a fault on a certain service path needs to be queried, a head node serving as the service path can generate a request message to request fault information, namely packet loss information, through the request message. 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, does not need to log in each node on the service path, does not need to rely on current network fault reproduction, realizes quick fault query, and enables the service to be quickly recovered.

As shown in fig. 2, the network device may also be referred to as a node, which is a device that provides a route forwarding function in a network system. For example, LSR, switch, etc. As shown in fig. 2, taking an example that the service path to be queried includes 4 network devices, which are respectively network device PE2, network device P3, and network device PE1. 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 cases, the node is taken as an independent network device, and in other cases, the node may also be a functional module with a message forwarding capability in the network device. Wherein, the solid arrow represents the transmission direction of the request message, and the dotted arrow represents the transmission direction of the response message.

For the head node, in one case, the head node may generate a node of the request message, that is, when the head node is a node (source network device) corresponding to the source address in the message, the head node is a first node on the end-to-end transmission path of the message; in another case, when a message is initially generated and sent by a user equipment, the source address in the message may be the source address of the user equipment, and the head node may be a 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 the destination address in the message; in another case, it may be the last node on the end-to-end transmission path within the domain in which it is currently located. The intermediate forwarding nodes are one or more forwarding nodes passing between the head node and the tail node when the message is forwarded.

In order to facilitate understanding of the fault query method provided in the embodiments of the present application, the following description will be given with reference to the accompanying drawings.

Referring to fig. 3, the 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 device obtains 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 tag information, where the destination identifier is used to uniquely indicate a network device corresponding to the last hop on the target path, i.e. a destination network device, such as the tail node 204 in fig. 2. The destination identifier may be an IP address assigned to the destination network device, or a device identifier of the destination network device, etc. The label information is used for indicating the next hop network equipment on the target path for fault inquiry, so that the next hop network equipment on the target path can be determined according to the label information when the request message is forwarded. The label information may include FEC corresponding to the head node to the tail node and outbound label or inbound label corresponding to the current node. For example, the head node 201 searches for a corresponding outbound label (an inbound label corresponding to the first intermediate node 202) according to the FEC, and forwards the request message to the first forwarding node 202 through an outbound interface corresponding to the outbound label.

The manner in which the first network device obtains the request message is related to the position of the request message on the service path, specifically, when the first network device is the head node 201 on the service path, the first network device may generate the request message according to the configuration operation of the operation and maintenance personnel; 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 receives the forwarding of the last hop node on the traffic path. For example, when the first network device is the first forwarding node 202, the first network device receives a 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 message 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 personnel can confirm information of the target path, such as information of the ingress node, the egress node, and a specific egress/ingress label, on the first network device, and perform configuration of the label information, so that the head node can generate the request message according to the configured label information. After the head node 201 generates the request message, an outbound interface corresponding to the label is determined according to the FEC and the outbound label in the request message, 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 the FEC, so as to send the request message to the second forwarding node 203. When the second forwarding node 203 receives the request message, it determines the egress interface corresponding to the label according to the FEC, so as to send the request message to the tail node 204.

It should be noted that, when there are multiple traffic 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 by 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 traffic paths. Alternatively, 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 traffic transmission, and when a failure detection needs to be performed on a certain tunnel or multiple tunnels, the request message may also include a sequence number, where the sequence number is used to distinguish detection for different tunnels. For example, between the head node 201 and the first forwarding node 202, there are a tunnel 1 and a tunnel 2, where the tunnel 1 is allocated to the user a for traffic transmission, and the tunnel 2 is allocated to the 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 indicate that the transmission path corresponding to the tunnel 2 is subjected to fault detection.

In order to reflect the continuity of the packet transmission, in this embodiment, the request packet sent by the head node 201 to the first forwarding node 202 and the request packet sent by the first forwarding node 202 to the second forwarding node 203 are both referred to as request packets, but it will be understood that, in the actual application scenario, the request packet sent by the head node 201 to the first forwarding node 202 and the request packet sent by the first forwarding node 202 to the second forwarding node 203 are different. For example, there may be a difference between the Time To Live (TTL) and the out-label information, 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 be modified with some necessary information. The so-called request message 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 message.

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

In this embodiment, after the first network device obtains the request packet, the first network device may determine, according to the destination identifier in the request packet and its own identifier, whether the first network device itself is a destination network device corresponding to the destination identifier. For example, when the destination identifier is a 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, indicate that the first network device is the destination network device. Or when the target identifier is the target device identifier, the first network device can judge whether the device identifier of the first network device is consistent with the target device identifier after receiving the request message, and if so, the first network device is indicated to be the target network device.

When the first network device confirms that the first network device is the target network device, the first network device indicates that the request message is forwarded to the last hop network device of the target path, and then the first network device can acquire a response message according to the request message without forwarding. The first network device obtains a response message according to the request message, wherein the response message can be obtained in a way that each network device on the target path adds the acquired packet loss information to the request message when forwarding the request message, and the target network device generates the response message according to the request message when reaching the target network device; 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 into 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. The following embodiments will describe specific implementations of the two modes.

The response message comprises packet loss information and label information. The packet loss information comprises 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 can automatically grab the discarded messages and record the number of the discarded packets and the reason of the discarded packets. The reasons for packet loss may include various reasons, for example, because the label of the packet is inconsistent with the label allocated by the current network device, as in fig. 1, the outgoing label in the packet forwarded by the ingress node is K, and after the first forwarding node receives the packet, it finds that the allocated label is Z inconsistent with the label K in the packet, and discards the packet. The label information is used for indicating the next hop network equipment corresponding to the first network equipment 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: the first network device sends the response message to the source network device according to the tag information.

After the first network device obtains the response message according to the request message, the response message Wen Zhuaifa can be forwarded by the second network device according to the label information in the response message until the second network device 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 maintenance personnel can perform fault location according to the packet loss information in the response message, and further perform fault recovery, thereby improving the fault query efficiency. The second network device is the next-hop network device corresponding to the first network device on the target path.

Specifically, when the first network device is the tail node 204, the first network device may find out the label according to the FEC, so as to send the response message to the second forwarding node 203 according to the egress interface corresponding to the egress label. When the second forwarding node 203 receives the response message, it finds the label according to the FEC, so as to send the response message 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 message, a label is found according to the FRC, so that the corresponding message 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 message, it confirms that the head node itself is the source network device, and then the response message can be parsed to obtain the packet loss information corresponding to each node on the path.

In order to embody continuity of message transmission, in this embodiment, 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 both referred to as response messages, but it is understood that 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 are different in actual application scenario. For example, there may be a difference between the Time To Live (TTL) and the out-label information, that is, the second forwarding node 203 may actually be an updated request message modified with some necessary information when forwarding the response message sent by the tail node 201 to the first forwarding node 202. 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 one possible implementation, after the source network device receives the response message, the packet loss information in the response message may be output, so that a maintainer 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 maintainer.

The message types of the request message and the response message are defined by a newly added Type-length-value (TLV), wherein the Type field is used for indicating the Type of the message, for example, when type=0x3e0c, the message is indicated as the request message; when type=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; and the Vlaue field is not limited, wherein the Vlaue field itself may be composed of multiple TLVs. Specifically, the request message and the response message may each include a data portion, where the data portion is used to encapsulate the packet loss tracing parameter, for example, as shown in fig. 4a, and the data portion may include a sequence number field, a reserved field, an entry 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, e.g., by the head node 201.

Ingress LSR Id: the Ingress device Id.

The Egress LSR Id: the Egress device Id.

FEC TLV: forwarding equivalence classes.

Label TLV: the next hop device's in-tag, each hop device updates this field as it forwards upstream.

Hop Record 1..N: and specific packet loss records.

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

LSR Id: for identifying an LSR, e.g., for identifying a PE1 device.

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

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

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

Based on the above embodiments, the first network device may obtain the response message based on the request message in two ways, where one is that the first network device serving as the destination network device generates the response message according to the request message, and adds the acquired packet loss information 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 acquired packet loss information to the response message, and forwards the response message until the response message is forwarded to the source network equipment. In the implementation mode, 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, and the packet loss information acquired by the destination network device is added into the 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, so that the packet loss information of each network equipment on the target path is obtained.

And the first network equipment adds the acquired packet loss information to the request message, and when the first network equipment is not the destination network equipment corresponding to the destination identifier, the first network equipment sends the request message to the third network equipment according to the label information, so that the third network equipment 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 equipment corresponding to the destination identifier. The third network device is the next-hop network device corresponding to the first network device on the target path. When the request message is forwarded to the destination network device, the first network device serving as the destination network device may add the packet loss information acquired by the first network device to the request message, and convert the request message into a response message, where the response message includes the packet loss information added by each network device on the destination path. That is, in this implementation manner, in the process of forwarding the request packet, each network device adds the packet loss information acquired by itself to the request packet, and when the request packet is forwarded to the destination network device, the destination network device generates a response packet according to the request packet.

In order to facilitate understanding of the above two acquisition modes, the following description will be given with reference to the accompanying drawings. Note that, the following will explain the scenario in conjunction with fig. 2.

Referring to fig. 5, which is a flowchart of obtaining a response message according to an embodiment of the present application, some specific implementations involved in the drawing may refer to the embodiment shown in fig. 3, and the method may include:

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

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

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

In this embodiment, after receiving the request packet sent by the head node 201, the first forwarding node 202 determines an in-tag (a first out-tag in the request packet) according to the request packet, searches for a second out-tag corresponding to the in-tag and an out-interface corresponding to the second out-tag according to the FEC, replaces the first out-tag in the request packet with the second out-tag, and forwards the request packet to the second forwarding node 203 by using the out-interface corresponding to the second out-tag. The second outbound label is an outbound 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 tag information in the request message.

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

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

In this embodiment, after the tail node 204 receives the request message, it determines that the tail node is the destination node corresponding to the destination identifier according to the destination identifier in the request message, and 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 tag information and a destination identifier, where the tag 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 message according to the request message, which may include: the tail node 204 converts the request message into a response message. Specifically, the tail node 204 obtains the response message by modifying the message type in the request message. 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 a response message. The tail node 204 modifies message type 0 in the request message to 1, thereby obtaining a response message.

In the process of forwarding the request message, when each node on the target path receives the request message, determining whether the node is a destination node corresponding to the destination identifier according to the destination identifier in the request message, and if not, performing subsequent forwarding according to the label 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 tag information in the response message.

In this embodiment, the tail node 204 determines a fourth outbound label according to the label information in the response message, and uses the outbound interface corresponding to the fourth outbound label to send the response message to the second forwarding node 203.

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 tag 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 the pre-collected packet loss information from the local and adds the packet loss information to the response message. Meanwhile, the second forwarding node 203 determines an in-tag (a fourth out-tag in the request message) according to the request message, queries a fifth out-tag corresponding to the in-tag and an out-interface corresponding to the fifth out-tag according to the FEC, replaces the fourth out-tag in the response message with the fifth out-tag, and forwards the response message to the first forwarding node 202 by using the out-interface corresponding to the fifth out-tag.

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 tag information in the response message.

For a specific implementation of forwarding by the first forwarding node 202 according to the tag information of the response message, refer to S505 or S506, which are not described herein again.

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 first 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.

In the process of forwarding the response message, when each node on the target path receives the response message, determining whether the node is a node corresponding to the target identifier according to the target identifier in the response message, and if the node is not the node corresponding to the target identifier, performing subsequent forwarding according to the label information in the response message; and if the node is the node corresponding to the destination identifier, outputting packet loss information in the response message.

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

Referring to fig. 6, which is a flowchart of another embodiment of obtaining a response message, some specific implementations involved in the fig. may refer to the embodiment shown in fig. 3 or fig. 5, and the method may include:

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

In this embodiment, after the head node 201 generates the request message, the pre-collected packet loss information may be read locally, and the packet loss information is added to the request message, so that the request message includes the packet loss information corresponding to the head node 201. It may be appreciated that the head node 201 may just generate the request message, without adding the self-collected packet loss information, but start from the first forwarding node 202, and add the self-collected packet loss information to the request message. Whether or not the header node 201 adds packet loss information to the request packet may be selected according to the actual application, which is not limited in this embodiment.

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

S602: the head node 201 forwards the request message to the first forwarding node 202 according to the tag information in the request message.

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

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

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

The forwarding operation performed by the first forwarding node 202 may be specifically referred to S502, S302 or S303, which are not described herein.

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

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

The forwarding operation performed by the second forwarding node 203 may be specifically referred to S504, S502, S302 or S303, and will not be described herein.

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 the tail node is the destination node corresponding to the destination identifier according to the destination identifier in the request message, and generates a response message according to the request message. Specifically, the tail node 204 may first add the packet loss information acquired by itself to the request message, and then generate the response message according to the request message. 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 tag information in the response message.

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

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

S611: the head node 201 outputs packet loss information.

When it should be noted that, in this embodiment, the application scenario in which each node adds packet loss information in a request packet is mainly directed to an LSP constructed based on RSVP protocol.

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

Referring to fig. 7, the schematic structural diagram of a fault query apparatus provided in the embodiment of the present application, where the fault query apparatus may be applied to a first network device, and perform functions of the first network device in the embodiment shown in fig. 3 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, and 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 to which the apparatus 700 is applied is the head node 201, specific implementation of the first obtaining unit 701 for obtaining the request packet may refer to S301, S501, or S601. When the network device to which the apparatus 700 is applied is the first forwarding node 202, the second forwarding node 203, or the tail node 204, the first obtaining unit 701 may receive a request packet from the previous hop network device, and specific implementation may refer to S502, S503, S602, S604, or S606.

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

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

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

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

The specific implementation of the second obtaining unit to generate the response message may refer to S504, and the implementation of the sending unit to send the response message to the second network device may refer to S505, S506 or S507.

When the network device to which the apparatus 700 is applied is not a destination network device, that is, is not a 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 acquiring the request message;

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 acquired packet loss information to the request packet, 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 target 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 by each network device on the target path.

The specific implementation of the adding unit may refer to any step of S601 to S606, and when the network device to which the apparatus 700 is applied is not a destination network device, the implementation of the sending unit may refer to S601 to S606. The specific implementation of the second acquisition unit can be seen in S607.

The specific implementation of the second acquisition unit may be referred to S504 or S607.

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

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

In one possible implementation, the apparatus further includes:

The specific implementation of the output unit may be referred to S508 or S611.

With respect to the specific executable functions and implementation of the apparatus 700, reference may be made to the corresponding description of the first network device in the embodiments shown in fig. 3, 5 or 6, and the detailed description is omitted here.

Fig. 8 is a schematic structural diagram of a network device provided in the 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 embodiment 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. Where the number of processors 810 in message forwarding device 800 may be one or more, one processor is illustrated in fig. 8. In the present embodiment, processor 810, communication interface 820, and memory 830 may be connected by a bus system or other means, such as bus system 840 in FIG. 8.

The processor 810 may be a CPU, an NP, or a combination of a CPU and 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 (programmable logic device, PLD), or a combination thereof. The PLD may be a complex programmable logic device (complex programmable logic device, CPLD), a field-programmable gate array (field-programmable gate array, FPGA), general-purpose array logic (generic array logic, GAL), or any combination thereof.

The processor 810 may perform the functions described above in connection with the method embodiments of obtaining a request message, obtaining a response message, adding packet loss information to the response message, and so on.

Communication interface 820 is used to receive and transmit messages, and in particular, communication interface 820 may include a receive interface and a transmit interface. The receiving interface may be used for receiving a message, and the transmitting interface may be used for transmitting a message. The number of communication interfaces 820 may be one or more.

Memory 830 may include volatile memory (English) such as random-access memory (RAM); the memory 830 may also include a nonvolatile memory (english: non-volatile memory), such as a flash memory (english: flash memory), a hard disk (HDD) or a Solid State Drive (SSD); memory 830 may also include a combination of the above types of memory.

Optionally, the memory 830 stores an operating system and programs, executable modules or data structures, or a subset thereof, or an extended set thereof, wherein the programs may include various operational instructions for performing various operations. The operating system may include various system programs for implementing various underlying services and handling hardware-based tasks. The processor 810 may read the program in the memory 830, and implement the fault query method provided in 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 of the network device 800.

The bus system 840 may be a peripheral component interconnect (peripheral component interconnect, PCI) bus, or an extended industry standard architecture (extended industry standard architecture, EISA) bus, among others. The bus system 840 may be divided into an address bus, a data bus, a control bus, and the like. For ease of illustration, only one thick line is shown in fig. 8, but not only one bus or one type of bus.

The terms "first," "second," "third," "fourth" and the like in the description and in the claims of this application and in the above-described figures, if any, are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used may be interchanged where appropriate such that the embodiments described herein may be implemented in other sequences than those illustrated or otherwise 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 will be clear to those skilled in the art that, for convenience and brevity of description, specific working procedures of the above-described systems, apparatuses and units may refer to corresponding procedures in the foregoing method embodiments, which are not repeated herein.

In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods may be implemented in other ways. For example, the above-described apparatus embodiments are merely illustrative, e.g., the division of units is merely a logical service division, and there may be additional divisions in actual implementation, e.g., multiple units or components may be combined or integrated into another system, or some features may be omitted, or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.

The units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed over a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each service unit in each embodiment of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit. The integrated units may be implemented in hardware or in software business units.

The integrated units, if implemented in the form of software business units and sold or used as stand-alone products, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application may be embodied in essence or a part contributing to the prior art or all or part of the technical solution in the form of a software product stored in a storage medium, including several instructions to cause a computer device (which may be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods 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, random Access Memory), a magnetic disk, or an optical disk, or other various media capable of storing program codes.

Those skilled in the art will appreciate that in one or more of the examples described above, the services described herein may be implemented in hardware, software, firmware, or any combination thereof. When implemented in software, the services may be stored in a computer-readable medium or transmitted 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 objects, technical solutions and advantageous effects of the present invention have been described in further detail in the above embodiments, and it should be understood that the above are only embodiments of the present invention.

The above embodiments are only for illustrating the technical solution of the present application, and not for limiting 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 scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit of the corresponding technical solutions from the scope of the technical solutions of the embodiments of the present application.

Claims

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

the method comprises the steps that first network equipment obtains a request message, wherein the request message is used for requesting packet loss information, the request message comprises a destination identifier and tag information, and the tag information is used for indicating next hop network equipment of a target path for fault inquiry;

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

the first network device sends the response message to source network device according to the label information, wherein the source network device is the network device for generating the request message;

the first network device obtains a response message according to the request message, including:

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

the first network device sends the response message to the source network device according to the tag information, and the method comprises the following steps:

the first network device sends the response message to the second network device according to the tag information, so that the second network device adds the acquired packet loss information to the response message, forwards the response message until the response message is forwarded to the source network device, and the second network device is the next hop network device corresponding to the first network device on the target path.

2. The method of claim 1, wherein when the first network device is not identifying a corresponding destination network device for the destination, 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 destination network equipment corresponding to the destination identifier.

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

4. The method of claim 1, wherein the first network device, after obtaining the request message, further comprises:

the first network device adds the acquired packet loss information to the request message;

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 a third network device according to tag information, so that the third network device adds acquired packet loss information to the request message, 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 the next hop network device corresponding to the first network device on the target path;

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

5. The method of claim 1, wherein the first network device obtains a response message according to the request message, comprising:

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

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

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

8. The method of claim 1, wherein the request message further comprises a sequence number when there are multiple paths from the source network device to the destination network device, wherein the response message further comprises the sequence number for indicating the target path, or wherein the request message further comprises a sequence number for indicating a target tunnel when there are multiple tunnels between the first network device and the second network device.

9. The method of claim 1, 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.

10. A fault querying device, the device comprising:

the first acquisition unit is used for acquiring a request message, wherein the request message is used for requesting packet loss information, the request message comprises a destination identifier and tag information, and the tag information is used for indicating the next hop network equipment on a target path for fault inquiry;

the second obtaining unit is used for obtaining a response message according to the request message when the device is a target network device corresponding to a target identifier, wherein the response message comprises packet loss information and label information;

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

the second obtaining unit is specifically configured to generate a response message according to the request message, and add the acquired packet loss information to the response message;

The sending unit is specifically configured to send the response message 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 message, and forwards the response message until the response message is forwarded to a source network device, where the second network device is a next hop network device corresponding to the device on the target path.

11. The apparatus of claim 10, 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 forwarding the request packet to the destination network device corresponding to the destination identifier.

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

13. The apparatus of claim 10, wherein the apparatus further comprises:

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 acquired packet loss information to the request packet, 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 apparatus on the target path;

14. The apparatus according to claim 10, wherein the second obtaining unit is specifically configured to modify a message type obtaining response message in the request message.

15. The apparatus of claim 14, wherein the message type is a request message when the message type is a first value and wherein the message type is a response message when the message type is a second value.

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

17. The apparatus of claim 10, wherein the request message further comprises a sequence number when there are multiple paths from the source network device to the destination network device, wherein the response message further comprises the sequence number for indicating the target path, or wherein the request message further comprises a sequence number for indicating a target tunnel when there are multiple tunnels between the apparatus and a second network device.

18. The apparatus of claim 10, wherein the apparatus further comprises:

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

the memory is used for storing instructions;

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

20. A computer readable storage medium comprising instructions which, when run on a computer, cause the computer to perform the method of any of the preceding claims 1-9.