A multi-level linkage telemetry method and system based on a cloud environment

Abstract

The application discloses a kind of multilevel linkage telemetry method and system based on cloud environment, the method includes: judging whether the network node of network layer under cloud environment supports probe protocol;If it is judged to support probe protocol, obtain the first detection request in the path transmission of user network in the first detection mode in the network layer;Wherein, first detection request, including the detection message of preset format;Judge whether virtual network and service network element are corresponding transit node, if yes, use virtual network to receive and forward first detection request to service network element, and receive the first detection request forwarded by service network element;Judge whether virtual network is corresponding destination node, if yes, correct the format of detection message, to complete the detection request reply between user network according to the detection message after modification.The application is used for the real-time detection of network fault and timely discovery problem.Through the detailed information of link, problem can be quickly located.

Description

Technical Field

[0001] The present invention relates to the field of cloud computing business technology, and in particular to a multi-level linkage telemetry method and system based on a cloud environment. Background Art

[0002] The growth of cloud computing has driven the large-scale application of cloud networking technologies, leading to the widespread deployment of overlay networks within data centers. Overlay networks are virtualized abstractions based on traditional underlay networks. By adding tunnel encapsulation to multi-tenant network data, they enable more flexible and controllable service delivery. However, network encapsulation also introduces new challenges. Physical network devices only see encapsulated data packets and are unable to perceive actual user traffic forwarding. This makes existing underlay-based network monitoring technologies ineffective.

[0003] Existing solutions are largely based on traditional data interaction and linkage between physical network devices: switches and routers. Technologies like trace route, INT, and MOD have drawbacks, including insufficient awareness of tenant network information, limited scalability, inability to rapidly adapt to business iterations, and inability to meet customization requirements. Furthermore, they face bottlenecks in capacity and detection performance. Summary of the Invention

[0004] The present invention aims to solve one of the technical problems in the related art at least to a certain extent.

[0005] To this end, the present invention proposes a multi-level linkage telemetry method based on a cloud environment, which can detect network failures in real time and discover problems in a timely manner.

[0006] Another object of the present invention is to propose a multi-level linkage telemetry system based on a cloud environment.

[0007] To achieve the above objectives, the present invention proposes a multi-level linkage telemetry method based on a cloud environment, comprising:

[0008] Determine whether the network nodes of the network layer in the cloud environment support the detection protocol; the network nodes include at least the source node, transit node and destination node corresponding to each network layer, and the network layer includes at least the user network, virtual network and service network element; if it is determined that the detection protocol is supported,

[0009] Obtaining a first probe request of the user network in the path transmission of the network layer; wherein the first probe request includes a probe message in a preset format;

[0010] Determine whether the virtual network and the service network element are corresponding transit nodes, and if so, use the virtual network to receive and forward the first probe request to the service network element, and receive the first probe request forwarded by the service network element;

[0011] Determine whether the virtual network is the corresponding destination node; if so, modify the format of the detection message to perform data analysis and processing between the user networks based on the modified detection message.

[0012] In addition, the multi-level linkage telemetry method based on a cloud environment according to the above embodiment of the present invention may also have the following additional technical features:

[0013] Furthermore, in one embodiment of the present invention, the virtual network includes a source network element, a transit platform network element, and a destination network element; and using the virtual network to receive and forward the first probe request to the service network element, and receiving the first probe request forwarded by the service network element, includes:

[0014] The source network element receives and forwards the first detection request to the crossing platform network element;

[0015] Determining whether the transit platform network element is a corresponding transfer node, and if so, forwarding the first detection request to the service network element by the transit platform network element;

[0016] Determining whether the service network element is a corresponding transit node, and if so, forwarding the first detection request to the transit platform network element by the service network element;

[0017] The transit platform network element forwards the first detection request to the destination network element.

[0018] Furthermore, in one embodiment of the present invention, the detection message in the preset format includes: an outer layer, an OAM layer and an inner layer; wherein the OAM layer includes: msg_type identifying the message type, transit_report, transit_id, transit_ip, Timestamp, process_us, l2_src_ip and dst_flag.

[0019] Furthermore, in one embodiment of the present invention, the network layer further includes self-built network elements, and the virtual network further includes self-built network elements of passing customers; the method further includes: if it is determined that the detection protocol is not supported,

[0020] Obtaining a second probe request of the user network in the path transmission of the network layer;

[0021] Using a transit platform network element determined to be a corresponding transit node to receive and forward the second detection request forwarded by the source network element to a service network element determined to be a corresponding transit node; and using a transit platform network element to receive the second detection request forwarded by the service network element and forward it to a destination network element determined to be a corresponding transit node;

[0022] The destination network element uses message conversion to request that the second detection message be converted into a service message and sent to the self-built network element. The destination network element matches the service message forwarded by the self-built network element, and converts the matched service message into the second detection message and forwards it to the self-built network element of the passing customer to reply to the second detection request.

[0023] Furthermore, in one embodiment of the present invention, the message conversion method includes:

[0024] From the destination network element to the self-built network element, remove the OAM layer, convert the second detection message into a service message, and use the inner 5-tuples to calculate the key value and save it in the index table to point to the OAM information;

[0025] Calculate the hash key for the 5-tuple contained in the inner layer: sip, dip, sport, dport, protocol.

[0026] Furthermore, in one embodiment of the present invention, the method further includes:

[0027] Before the virtual network forwards the message to the service network element, check the node type of the nexthop port and determine whether the node type supports the trace-flag. If the flag is supported, forward the message;

[0028] If it is determined that the nexthop is a remote port and is located on the same plane of the virtual network, it is determined that the detection protocol is supported;

[0029] If the node in the virtual network does not support the detection protocol, the message is discarded and a non-support message is replied to the source node.

[0030] To achieve the above objectives, the present invention further proposes a multi-level linkage telemetry system based on a cloud environment, comprising:

[0031] The protocol judgment module is used to judge whether the network nodes of the network layer in the cloud environment support the detection protocol; the network nodes include at least the transit nodes and destination nodes corresponding to each network layer, and the network layer includes at least the user network, the virtual network and the service network element; if it is judged that the detection protocol is supported,

[0032] A request detection module, configured to obtain a first detection request of the user network in the path transmission of the network layer; wherein the first detection request includes a detection message in a preset format;

[0033] a request forwarding module, configured to determine whether the virtual network and the service network element are corresponding transit nodes, and if so, to receive and forward the first probe request to the service network element using the virtual network, and to receive the first probe request forwarded by the service network element;

[0034] The detection and analysis module is used to determine whether the virtual network is the corresponding destination node, and if so, to modify the format of the detection message so as to perform data analysis and processing between the user networks according to the modified detection message.

[0035] The multi-layered, cloud-based telemetry method and system of this invention enables real-time detection of network faults and timely identification of problems. Detailed link information allows for rapid problem location, supporting rapid recovery from network failures and enhancing the visual experience of cloud networks.

[0036] Additional aspects and advantages of the present invention will be set forth in part in the description which follows and, in part, will be obvious from the description which follows, or may be learned through practice of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] The above and / or additional aspects and advantages of the present invention will become apparent and readily understood from the following description of the embodiments in conjunction with the accompanying drawings, in which:

[0038] Figure 1 is a flow chart of a multi-level linkage telemetry method based on a cloud environment according to an embodiment of the present invention;

[0039] Figure 2 This is a diagram of the network system layering in a typical cloud environment;

[0040] Figure 3 is a logic flow chart of a multi-level linkage telemetry method based on a cloud environment according to an embodiment of the present invention;

[0041] Figure 4 is a schematic diagram of a message format according to an embodiment of the present invention;

[0042] Figure 5 is a schematic diagram of a normal detection mode according to an embodiment of the present invention;

[0043] Figure 6 is a schematic diagram of an advanced detection mode according to an embodiment of the present invention;

[0044] Figure 7 This is a schematic diagram of message conversion according to an embodiment of the present invention;

[0045] Figure 8 2 is a structural diagram of a multi-level linkage telemetry system based on a cloud environment according to an embodiment of the present invention. DETAILED DESCRIPTION

[0046] It should be noted that, in the absence of conflict, the embodiments and features of the embodiments of the present invention can be combined with each other. The present invention will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

[0047] In order to enable those skilled in the art to better understand the solutions of the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the embodiments described are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of the present invention.

[0048] The following describes a multi-level linkage telemetry method and system based on a cloud environment according to an embodiment of the present invention with reference to the accompanying drawings.

[0049] Figure 1 This is a flowchart of a multi-level linkage telemetry method based on a cloud environment according to an embodiment of the present invention.

[0050] like Figure 1 As shown, the method includes but is not limited to the following steps:

[0051] S1, determine whether the network nodes of the network layer in the cloud environment support the detection protocol; the network nodes include at least the source node, transit node and destination node corresponding to each network layer, and the network layer includes at least the user network, virtual network and service network element; if it is determined that the detection protocol is supported,

[0052] S2, obtaining a first probe request from the user network in the path transmission of the network layer; wherein the first probe request includes a probe message in a preset format;

[0053] S3, determining whether the virtual network and the service network element are corresponding transit nodes, and if so, using the virtual network to receive and forward the first probe request to the service network element, and receiving the first probe request forwarded by the service network element;

[0054] S4, determining whether the virtual network is the corresponding destination node, and if so, modifying the format of the detection message to perform data analysis and processing between user networks based on the modified detection message.

[0055] Understandably, traditional physical network hardware is a black box, often closed to users, preventing in-depth modification and customization. However, cloud network network element nodes are typically built using software or programmable technology that integrates hardware and software. Cloud network platforms offer strong service customization capabilities, allowing for the flexible implementation of specific services on network element nodes as needed. This opens up the possibility of implementing a new link detection mechanism on virtualized network forwarding links. This can be achieved by adding a universal detection mechanism to network element nodes within virtual network links.

[0056] The fundamental goal of network probing is to determine whether a fixed source node is reachable to a fixed destination node, which nodes constitute the intermediate link, and, if the link is unreachable, the specific location of the fault. Furthermore, the goal is to determine the segment delay across the entire network link.

[0057] As an example, Figure 2 As shown in FIG, a network forwarding link is actually composed of multiple network nodes.

[0058] The network system layering in a typical cloud environment can be divided into four levels, from bottom to top: 1. The basic physical network, maintained by the cloud platform and based on traditional hardware network devices such as switches and routers. 2. The basic virtual network, typically provided by the platform and built on the host machine through software virtualization based on SDN technology. 3. The virtual service network element, typically provided by the platform and based on NFV technology, built on the cloud platform's guest virtual machines to provide advanced network services. 4. The tenant network, or the network within the guest virtual machine, is typically maintained by the customer and built on the foundational capabilities provided in 1-3 above.

[0059] As an example, the cloud network data flow is defined as follows: logical flow, which is generally from user VM1 to another VM2, and is the network communication from the user's perspective; physical flow, which involves the customer virtual machine network, host network, physical network, and platform business network elements, at multiple levels.

[0060] As an example, the network layer definition is: L1: physical network, L2: virtual network, L3: platform network elements and user networks; the physical network L1 does not perceive the user IP and cannot respond to the user layer IP; the virtual network L2 perceives but does not own the user IP, and has the concept of proxy_ip. In certain cases, it can match user data packets based on the proxy_ip and perform necessary proxy processing.

[0061] As an example, a node type definition shows that the actual network flow has a path from the global device perspective, with multiple roles within that path. Furthermore, each network plane has three corresponding roles: source node, transit node, and destination node.

[0062] L3-source node: the sending node of the data request, the source IP of the data packet, and the matching node instance_ip;

[0063] L3-destination node: the destination IP of the data request, which is equal to the node instance_ip itself;

[0064] L3-transit node: sip and dip are evenly matched, and the data packet is forwarded to the next hop based on L3 routing lookup;

[0065] L2-source node: sip match proxy_ip;

[0066] L2-destination node: dip match proxy_ip;

[0067] L2-transit node: Neither sip nor dip matches, and the packet is forwarded to the next hop according to the L2 layer routing.

[0068] As an example, the node field definition is: instance_ip: L2.ins_ip is the host ip, L3.ins_ip is the vm ip; proxy_ip: L2.proxy_ip is the vm_ip, L3 has no proxy_ip.

[0069] Understandably, network measurement and analysis in a cloud computing environment presents greater complexity due to the involvement of multiple layers, such as the platform and tenant layers, the physical and virtual layers, and SDN and NFV. Interconnectivity between these multiple network layers must be addressed, and these layers vary in their technical implementation principles, degree of openness, and network operations and maintenance responsibilities.

[0070] As an example, Figure 3 As shown, the present invention proposes a mechanism that can connect multiple layers of networks so that all types of intermediate network elements can participate in the key information of the network diagnosis process. Through customized message protocols and customized forwarding methods of virtual networks, detection messages can be converted and penetrated between various network layers, achieving the purpose of full detection and analysis of E2E network links. The main content of the present invention is the multi-level linkage analysis-mechanism, in which the normal mode means that the intermediate node itself supports the detection protocol and is directly sent to the VM for interaction. The advanced mode means that the intermediate node VM does not support the detection protocol and requires the intermediate Host to perform proxy processing. There are two ways here. The present invention mainly converts the conversion mode into an ordinary message through the session information of the relay host, and sends it to the inside of the VM to simulate the coverage of the real path. After the VM sends a message, the ordinary message is converted into a detection message according to the session information and continues to be forwarded.

[0071] It is understandable that the virtual network of the present invention can be a source network element, a transit platform network element, a destination network element, and a transit customer self-built network element.

[0072] As an example, Figure 4 As shown, the protocol field parsing of the present invention defines the main format of the probe message. Relying on these key fields, each network node identifies and processes these control message fields according to the protocol. In particular, the OAM information determines the message type and the action that each node should take.

[0073] Outer layer: Underlay platform information, where the vxlan header identifies tenant information, the oam_flag is set, and the next layer protocol is OAM.

[0074] OAM: msg_type identifies the message type, including request, report, and echo, where report identifies the message and echo identifies the reverse request.

[0075] transit_report, identifies whether the transit node needs to report information directly to src_nc;

[0076] transit_id, a cumulative value that identifies how many intermediate network elements the packet has passed through. Requests are accumulated and copied to the report.

[0077] transit_ip, records the IP information of each transit network element along the way, used in the report message;

[0078] timestamp, records the timestamp when this node sends the msg, according to the egress time;

[0079] process_us, records the processing delay of the transfer node;

[0080] l2_src_ip, records the outer host IP address of the source node, so that the report message can be directly returned to the source end;

[0081] dst_flag is used for report messages. If dip has completed the final match, it means that the probe message has reached the destination and the report flag is set.

[0082] As an example, multi-level linkage analysis-mechanism: normal data flow, the problem is how to cover the entire path of this link; the platform is naturally controllable, L4 is not necessarily controllable and trustworthy, and can support the detection protocol; if the transit node supports the detection protocol, it is sent directly in; if the transit node does not support detection, there are two ways to solve it: packet loss-analysis interruption, forwarding-path simulation.

[0083] As an example, Figure 5 As shown, the normal detection mode M1: 1. Host-1 simulates VM-1 to initiate a detection request, and the Host-1 forwarding layer receives the request; 2. Host-1 forwards the request to Host-2; 3. Host-2 determines that it is a transit node, and L3 nextnode supports trace; 4. Host-2 forwards the request to VM-2; 5. VM-2 determines that it is a transit node; 6. VM-2 forwards the request to Host-2; 7. Host-2 forwards the request to Host-3; 8. Host-3proxy_ip matches dip, and L3 node does not support trace; 9. Host-3 makes a proxy reply, reverses the sip and dip of the request, changes the type to reply, and proxies VM-3 to reply to VM-1.

[0084] As an example, Figure 6 As shown, the advanced detection mode M2: 1. VM-1 initiates a detection request, Host-1 receives the request; 2. Host-1 forwards the request to Host-2; 3. Host-2 determines that it is a transit node, and L3 Nextnode supports trace; 4. Host-2 forwards the request to VM-2; 5. VM-2 determines that it is a transit node; 6. VM-2 forwards the request to Host-2; 7. Host-2 forwards the request to Host-3 (up to this point, the processing flow is the same as the normal mode); 8. Host-3 determines that it is a transit node, and L2 to L3 does not support trace, and enters [proxy mode]. There are two solutions [message conversion | simulated forwarding], using the message conversion method; 9. Host-3 converts the request message into a business message, sends it to VM-3, and caches the session record; 10. VM-3 forwards the VM-3 message out of the queue according to normal business behavior; 11. Host-3 matches the business message through [unique identification] based on the previous session record, and [converts] the business message into a detection message, and continues to forward it. Furthermore, since the self-built network element does not recognize the detection protocol packet, Host-4 can process the detection message in two ways: proxy reply and modified forwarding, to ensure that the detection link is not interrupted.

[0085] As an example, Figure 7 As shown, L2-L3 message conversion involves searching the index table based on the inner 5-tuples and removing / adding the OAM layer. Service and probe message conversion occurs between L2 and L3 in two directions: from L2 to L3. When sending from the host to the VM, the OAM layer is removed and the probe message is converted into a service message. The key value is calculated using the inner 5-tuples and stored in the index table, pointing to the OAM information. A conventional hash key is calculated using the 5-tuples: sip, dip, sport, dport, and protocol.

[0086] As an example, determine the nexthop node (differentiating between platform and self-built): 1. When L2 forwards a message, when forwarding it to the local L3, it is necessary to check the node type of the nexthop port to determine whether it supports the trace-flag. Only if the flag is supported can the message be forwarded; 2. If the nexthop is a remote port and is on the same plane as L2, it is assumed to support trace by default; 3. If the local L2-node does not support trace, the message is discarded and a non-support message is replied to the source node.

[0087] As an example, to handle non-support (self-built network element node): For the problem that the transit node cannot support the detection protocol:

[0088] Method 1 - Using session: Select ready-made 5-tuples from the L2 session of the source point, construct a specific request message, and perform detection. This method has certain limitations.

[0089] Method 2 - Generate session: If there is no session at the source node and no session in the intermediate path, a path is constructed through the source proxy node to generate a message (real message), make a request to the destination, and generate a path along the way.

[0090] Method 3 - Message Mapping: Converts customized messages into ordinary messages and sends them to the VM. A session is established at the host level. When a message request or reply is sent from the VM, the message is converted by matching the session and converted into a special customized message, which is then sent to the subsequent process.

[0091] As an example, the L2 node action definition is as follows: normal forwarding: if L3 supports it, forward it according to the normal business process; simulated forwarding: if L3 does not support it, simulate the forwarding behavior of the previous message based on the existing session; forward conversion: if L3 does not support it, convert the probe message into a business message and send it to L3; reverse conversion: receive the business message and convert the probe message according to the rules; proxy reply: if L3 does not support it and dip matches proxy_ip, L2 performs a proxy reply; discard the message; locally log and calculate rtt.

[0092] L3 node action definition: Reply: If dip matches instance_ip, the L3 destination node replies; Forward: If dip does not match instance_ip, the message is forwarded according to the L3 internal routing; Discard: If instance_ip does not match and no route is found, the message is discarded.

[0093] The multi-layered, cloud-based telemetry method according to the present invention enables real-time detection of network faults, enabling prompt problem identification. Detailed link information allows for rapid problem location, enabling rapid recovery from network failures. This enhances the cloud network's visual experience and reduces inefficient resource consumption when service failures are not caused by the network.

[0094] In order to implement the above embodiment, Figure 8 As shown, this embodiment also provides a multi-level linkage telemetry system 10 based on a cloud environment. The system 10 includes a protocol judgment module 100, a request detection module 200, a request forwarding module 300 and a detection analysis module 400.

[0095] The protocol judgment module 100 is used to judge whether the network nodes of the network layer in the cloud environment support the detection protocol; the network nodes include at least the transit nodes and destination nodes corresponding to each network layer, and the network layer includes at least the user network, the virtual network and the service network element; if it is judged that the detection protocol is supported,

[0096] The request detection module 200 is used to obtain a first detection request of the user network in the path transmission of the network layer; wherein the first detection request includes a detection message in a preset format;

[0097] The request forwarding module 300 is configured to determine whether the virtual network and the service network element are corresponding transit nodes, and if so, to receive and forward the first probe request to the service network element using the virtual network, and to receive the first probe request forwarded by the service network element;

[0098] The detection and analysis module 400 is configured to determine whether the virtual network corresponds to the destination node, and if so, to modify the format of the detection message, so as to perform data analysis and processing between the user networks according to the modified detection message.

[0099] Furthermore, the virtual network includes a source network element, a transit platform network element, and a destination network element; and the request detection module 200 is further configured to:

[0100] The source network element receives and forwards the first detection request to the crossing platform network element;

[0101] Determining whether the transit platform network element is a corresponding transfer node, and if so, forwarding the first detection request to the service network element by the transit platform network element;

[0102] Determining whether the service network element is a corresponding transit node, and if so, forwarding the first detection request to the transit platform network element by the service network element;

[0103] The transit platform network element forwards the first detection request to the destination network element.

[0104] Furthermore, the network layer also includes self-built network elements, and the virtual network also includes self-built network elements of passing customers; the system 10 also includes: a detection mode module for determining that the detection protocol is not supported,

[0105] Obtain a second detection request of the user network in the path transmission of the network layer in the second detection mode;

[0106] Using a transit platform network element determined to be a corresponding transit node to receive and forward the second detection request forwarded by the source network element to a service network element determined to be a corresponding transit node; and using a transit platform network element to receive the second detection request forwarded by the service network element and forward it to a destination network element determined to be a corresponding transit node;

[0107] The destination network element uses message conversion to request that the second detection message be converted into a service message and sent to the self-built network element. The destination network element matches the service message forwarded by the self-built network element, and converts the matched service message into the second detection message and forwards it to the self-built network element of the passing customer to reply to the second detection request.

[0108] Furthermore, the message conversion method includes:

[0109] From the destination network element to the self-built network element, remove the OAM layer, convert the second detection message into a service message, and use the inner 5-tuples to calculate the key value and save it in the index table to point to the OAM information;

[0110] Calculate the hash key for the 5-tuple contained in the inner layer: sip, dip, sport, dport, protocol.

[0111] The multi-layered, cloud-based telemetry system, based on embodiments of the present invention, provides real-time detection of network faults and promptly identifies problems. Detailed link information allows for rapid problem location, supporting rapid recovery from network failures. This enhances the cloud network's visual experience and reduces inefficient consumption when service failures are not caused by the network.

[0112] In the description of this specification, the reference terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" mean that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present invention. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any one or more embodiments or examples in a suitable manner. In addition, those skilled in the art can combine and combine different embodiments or examples described in this specification and features of different embodiments or examples without contradiction.

[0113] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of the technical features being referred to. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one such feature. In the description of the present invention, "plurality" means at least two, such as two, three, etc., unless otherwise specifically defined.

Claims

1. A multi-level linkage telemetry method based on a cloud environment, characterized in that: The following steps are involved: Determine whether the network nodes in the network layer of the cloud environment support the detection protocol; The network nodes include at least a source node, a transit node, and a destination node corresponding to each network layer. The network layer includes at least a user network, a virtual network, and a service network element. If it is determined that the detection protocol is supported, Obtaining a first probe request of the user network in the path transmission of the network layer; wherein the first probe request includes a probe message in a preset format; Determine whether the virtual network and the service network element are corresponding transit nodes, and if so, use the virtual network to receive and forward the first probe request to the service network element, and receive the first probe request forwarded by the service network element; Determine whether the virtual network is the corresponding destination node; if so, modify the format of the detection message to perform data analysis and processing between the user networks based on the modified detection message.

2. The method according to claim 1, characterized in that The virtual network includes a source network element, a transit platform network element, and a destination network element; The receiving and forwarding the first detection request to the service network element by using the virtual network, and receiving the first detection request forwarded by the service network element, includes: The source network element receives and forwards the first detection request to the crossing platform network element; Determining whether the transit platform network element is a corresponding transfer node, and if so, forwarding the first detection request to the service network element by the transit platform network element; Determining whether the service network element is a corresponding transit node, and if so, forwarding the first detection request to the transit platform network element by the service network element; The transit platform network element forwards the first detection request to the destination network element.

3. The method according to claim 1, characterized in that The detection message of the preset format includes: an outer layer, an OAM layer and an inner layer; wherein the OAM layer includes: msg_type identifying the message type, transit_report, transit_id, transit_ip, Timestamp, process_us, l2_src_ip and dst_flag.

4. The method according to claim 3, characterized in that The network layer also includes self-built network elements, and the virtual network also includes self-built network elements of passing customers; the method also includes: if it is determined that the detection protocol is not supported, Obtaining a second probe request of the user network in the path transmission of the network layer; Using the transit platform network element determined to be the corresponding transit node to receive and forward the second detection request forwarded by the source network element to the service network element determined to be the corresponding transit node; and using the transit platform network element to receive the second detection request forwarded by the service network element and forward it to the destination network element determined to be the corresponding transit node; The destination network element uses message conversion to request that the second detection message be converted into a service message and sent to the self-built network element. The destination network element matches the service message forwarded by the self-built network element, and converts the matched service message into the second detection message and forwards it to the self-built network element of the passing customer to reply to the second detection request.

5. The method according to claim 4, characterized in that The message conversion method includes: From the destination network element to the self-built network element, remove the OAM layer, convert the second detection message into a service message, and use the inner 5-tuples to calculate the key value and save it in the index table to point to the OAM information; Calculate the hash key for the 5-tuple contained in the inner layer: sip, dip, sport, dport, protocol.

6. The method according to claim 5, characterized in that The method further comprises: Before the virtual network forwards the message to the service network element, check the node type of the nexthop port and determine whether the node type supports the trace-flag. If the flag is supported, forward the message; If it is determined that the nexthop is a remote port and is located on the same plane of the virtual network, it is determined that the detection protocol is supported; If the node in the virtual network does not support the detection protocol, the message is discarded and a non-support message is replied to the source node.

7. A multi-level linkage telemetry system based on a cloud environment, characterized in that: include: The protocol judgment module is used to judge whether the network nodes of the network layer in the cloud environment support the detection protocol; The network nodes include at least a transit node and a destination node corresponding to each network layer, and the network layer includes at least a user network, a virtual network, and a service network element; if it is determined that the detection protocol is supported, A request detection module, configured to obtain a first detection request of the user network in the path transmission of the network layer; wherein the first detection request includes a detection message in a preset format; a request forwarding module, configured to determine whether the virtual network and the service network element are corresponding transit nodes, and if so, to receive and forward the first probe request to the service network element using the virtual network, and to receive the first probe request forwarded by the service network element; The detection and analysis module is used to determine whether the virtual network is the corresponding destination node, and if so, to modify the format of the detection message so as to perform data analysis and processing between the user networks according to the modified detection message.

8. The system according to claim 7, characterized in that The virtual network includes a source network element, a transit platform network element, and a destination network element; the request detection module is further used to: The source network element receives and forwards the first detection request to the crossing platform network element; Determining whether the transit platform network element is a corresponding transfer node, and if so, forwarding the first detection request to the service network element by the transit platform network element; Determining whether the service network element is a corresponding transit node, and if so, forwarding the first detection request to the transit platform network element by the service network element; The transit platform network element forwards the first detection request to the destination network element.

9. The system according to claim 8, characterized in that The network layer also includes self-built network elements, and the virtual network also includes self-built network elements of passing customers; the system also includes: a detection mode module for determining that the detection protocol is not supported, Obtain a second detection request of the user network in the path transmission of the network layer in the second detection mode; Using a transit platform network element determined to be a corresponding transit node to receive and forward the second detection request forwarded by the source network element to a service network element determined to be a corresponding transit node; and using a transit platform network element to receive the second detection request forwarded by the service network element and forward it to a destination network element determined to be a corresponding transit node; The destination network element uses message conversion to request that the second detection message be converted into a service message and sent to the self-built network element. The destination network element matches the service message forwarded by the self-built network element, and converts the matched service message into the second detection message and forwards it to the self-built network element of the passing customer to reply to the second detection request.

10. The system according to claim 9, characterized in that The message conversion method includes: From the destination network element to the self-built network element, remove the OAM layer, convert the second detection message into a service message, and use the inner 5-tuples to calculate the key value and save it in the index table to point to the OAM information; Calculate the hash key for the inner 5-tuple: sip, dip, sport, dport, protocol.

Images