A message processing method and system

Abstract

The present application provides a message processing method and system, the method comprising: a head node receiving configuration information sent by a controller, and determining, based on the configuration information, a Flow ID and Bitmap information required when generating an IOAM header; when the head node completes a table lookup and encapsulates a VXLAN message, if the quintuple information matches the inner message quintuple corresponding to the VXLAN message, encapsulating the IOAM header generated based on the Flow ID and Bitmap information in the VXLAN message, copying the original Protocol field value of the VXLAN message to the Reserved field of the IOAM header, modifying the Protocol field value of the VXLAN message to an IOAM specific identifier, and obtaining a detection message; the head node uses the Bitmap information of the IOAM header in the detection message to report subscription information related to the head node for implementing flow detection to the controller, and forwarding the detection message to the next node.

Description

Technical Field

[0001] The present application relates to the field of data service technology, and in particular to a message processing method and system. Background Art

[0002] With the continuous development of cloud computing technology and the maturity of Network Function Virtualization (NFV) technology, cloud services are becoming more and more extensive, and the scale of data center networks is constantly increasing. This has prompted new challenges in the daily monitoring and operation of key services and the rapid location of faults. To improve the accuracy and efficiency of data center network operation and maintenance, network telemetry technology has emerged. By introducing flow detection technology and network analysis platforms into data center networks, network devices along the way report parameter information such as the entry and exit ports, timestamps, and latency during packet forwarding to the analysis platform. Combined with data analysis and artificial intelligence technologies, it provides network quality information such as path visibility, packet loss and latency, enabling rapid fault perception and root cause location, and promoting refined network management.

[0003] In related technologies, one of the mainstream solutions for in-band detection technology is to use the Protocol field in the Internet Protocol (IP) message header to identify the message as an in-band operation, administration, and maintenance (IOAM) message. Devices along the way identify the message type and report parameter information such as device ID, inbound and outbound ports, timestamp, and latency to the analysis platform. However, in this solution, the Protocol field of the original message is replaced with a value specific to the detection message. Since data center networks require Equal-Cost Multipath Routing (ECMP), and the Protocol field is one of the parameters for ECMP calculation, if the Protocol field changes, the forwarding path of the detection message will be inconsistent with that of the original message, making the reported data inaccurate and, in turn, reducing the operation and maintenance accuracy of the data center network. Summary of the Invention

[0004] The present application provides a message processing method and system; it can ensure the accuracy of detecting message forwarding paths and improve the operation and maintenance accuracy of data center networks.

[0005] The technical solution of this application is achieved as follows:

[0006] The present application provides a message processing method, the method comprising:

[0007] The head node receives configuration information issued by the controller and determines, based on the configuration information, the flow ID and bitmap information required for generating the IOAM header. The configuration information is generated based on the flow detection requirements issued by the cloud platform and includes five-tuple information. The head node is directly connected to the source host corresponding to the five-tuple information.

[0008] When the head node completes the table lookup and encapsulates a Virtual Extensible Local Area Network (VXLAN) message, if the quintuple information matches the inner message quintuple corresponding to the VXLAN message, an IOAM header generated according to the Flow ID and the bitmap information is encapsulated in the VXLAN message, and an original Protocol field value of the VXLAN message is copied to the Reserved field of the IOAM header. The Protocol field value of the VXLAN message is modified to an IOAM specific identifier, thereby obtaining a detection message.

[0009] The head node uses the Bitmap information of the IOAM header in the detection message to report subscription information related to the head node for implementing follow-up detection to the controller, and forwards the detection message to the next node.

[0010] In some embodiments, when the head node and the tail node corresponding to the VXLAN message are respectively connected to different hosts on the same tenant virtual network in the same data center network, the method further includes:

[0011] After the head node forwards the detection message to the first gateway device, the first gateway device identifies the Protocol field value as an IOAM specific identifier, uses the bitmap information of the IOAM header in the detection message, reports subscription information related to the first gateway device for implementing in-stream detection to the controller, and decrements a Time To Live (TTL) value in the detection message by 1;

[0012] When querying the next hop and forwarding outbound interface, the Protocol field value of the IOAM header in the detection message and the offset value corresponding to the IOAM header are used to obtain port number information for ECMP calculation.

[0013] In some embodiments, the egress node is directly connected to the destination host, and the method further includes:

[0014] forwarding the detection message to the egress node using the first gateway device;

[0015] The egress node uses the bitmap information of the IOAM header in the detection message to report subscription information related to the egress node for implementing follow-up detection to the controller, and then writes back the original Protocol field value of the Reserved field in the IOAM header to the Protocol field of the detection message, removing the IOAM header in the detection message.

[0016] The tail node sends the message with the IOAM header removed to the destination host.

[0017] In some embodiments, when the head node and the tail node corresponding to the VXLAN message are respectively connected to different hosts on different tenant virtual networks in the same data center network, the method further includes:

[0018] After the head node forwards the detection message to the first gateway device, when removing the VXLAN message and the encapsulated IOAM header, the first gateway device saves the IOAM header and TTL value in the detection message into a register, and uses the bitmap information of the IOAM header in the detection message to report subscription information related to the first gateway device for implementing flow detection to the controller;

[0019] When looking up the table and encapsulating a new VXLAN message, the first gateway device re-encapsulates the detection message using the IOAM header obtained from the register, the TTL value after performing a decrement operation by 1, and the first VXLAN network identifier; the first VXLAN network identifier represents an identifier of the tenant virtual network corresponding to the outbound interface of the first gateway device;

[0020] When querying the next hop and forwarding out interface, the Protocol field value of the IOAM header in the re-encapsulated detection message and the offset value of the IOAM header are used to obtain port number information for ECMP calculation.

[0021] In some embodiments, the egress node is directly connected to the destination host, and the method further includes:

[0022] forwarding the re-encapsulated detection message to the egress node using the first gateway device;

[0023] The egress node uses the bitmap information of the IOAM header in the re-encapsulated detection message to report subscription information related to the egress node for implementing in-stream detection to the controller, writes back the original Protocol field value of the Reserved field in the IOAM header to the Protocol field of the detection message, and removes the IOAM header in the re-encapsulated detection message;

[0024] The tail node sends the message with the IOAM header removed to the destination host.

[0025] In some embodiments, when the head node and the tail node corresponding to the VXLAN message are respectively connected to different hosts in different data center networks, the method further includes:

[0026] After the head node forwards the detection message to the first gateway device, when removing the VXLAN message and the encapsulated IOAM header, the first gateway device saves the IOAM header and TTL value in the detection message into a register, and uses the bitmap information of the IOAM header in the detection message to report subscription information related to the first gateway device for implementing flow detection to the controller;

[0027] When looking up the table and encapsulating a new VXLAN message, the first gateway device re-encapsulates the detection message using the IOAM header obtained from the register, the TTL value after performing a decrement operation, the second VXLAN network identifier, and the first value corresponding to the Flow ID field in the IOAM header; the first value represents a preset public flow identifier; the second VXLAN network identifier is used to uniquely identify the corresponding routing domain of the interconnection between different tenant virtual networks in different data center networks, and is used to implement independent planning of network identifiers for tenants in different data center networks;

[0028] When querying the next hop and forwarding out interface, the Protocol field value of the IOAM header in the re-encapsulated detection message and the offset value of the IOAM header are used to obtain port number information for ECMP calculation.

[0029] In some embodiments, the method further comprises:

[0030] When the first gateway device forwards the re-encapsulated detection message to the public node, the public node uses the bitmap information of the IOAM header in the re-encapsulated detection message to report subscription information related to the public node for implementing in-flow detection to the controller, and updates the TTL value in the re-encapsulated detection message to a value after performing a decrement operation; the public node represents a node in the public VXLAN network;

[0031] When querying the next hop and forwarding out interface, the Protocol field value of the IOAM header in the re-encapsulated detection message and the offset value of the IOAM header are used to obtain port number information for ECMP calculation.

[0032] In some embodiments, the method further comprises:

[0033] The re-encapsulated detection message is forwarded to the second gateway device by using the public node. When the VXLAN message and the encapsulated IOAM header are removed, the second gateway device saves the IOAM header and the TTL value in the re-encapsulated detection message into a register, and reports subscription information related to the second gateway device for implementing in-flow detection to the controller by using the bitmap information of the IOAM header in the re-encapsulated detection message;

[0034] When looking up the table and encapsulating a new VXLAN message, the second gateway device uses the IOAM header obtained from the register, the TTL value after continuing to perform the subtraction operation, the third VXLAN network identifier, and the second value corresponding to the Flow ID field in the IOAM header to encapsulate the detection message again; the third VXLAN network identifier represents the identifier of the tenant virtual network corresponding to the outbound interface of the second gateway device; the second value is used to represent the flow identifier corresponding to the data center network to which the second gateway device belongs.

[0035] In some embodiments, the egress node is directly connected to the destination host, and the method further includes:

[0036] forwarding the re-encapsulated detection message to the egress node using the second gateway device;

[0037] The egress node uses the bitmap information of the IOAM header in the re-encapsulated detection message to report subscription information related to the egress node for implementing in-stream detection to the controller, writes back the original Protocol field value of the Reserved field in the IOAM header to the Protocol field of the detection message, and removes the IOAM header in the re-encapsulated detection message;

[0038] The tail node sends the message with the IOAM header removed to the destination host.

[0039] In some embodiments, the subscription information includes a device identity identification number (Identity Document, ID) and a Flow ID of the head node.

[0040] The present application provides a message processing system, which includes a head node, wherein:

[0041] The head node is used to receive configuration information issued by the controller and, based on the configuration information, determine the flow ID and bitmap information required when generating the IOAM header; the configuration information is generated based on the flow detection requirements issued by the cloud platform, and the configuration information includes quintuple information. The head node is directly connected to the source host corresponding to the quintuple information;

[0042] When the head node completes the table lookup and encapsulates the VXLAN message, if the quintuple information matches the inner message quintuple corresponding to the VXLAN message, the head node encapsulates the IOAM header generated according to the Flow ID and the bitmap information into the VXLAN message, copies the original Protocol field value of the VXLAN message to the Reserved field of the IOAM header, modifies the Protocol field value of the VXLAN message to the IOAM specific identifier, and obtains a detection message;

[0043] The head node is configured to report subscription information related to the head node for implementing follow-up detection to the controller by using the Bitmap information of the IOAM header in the detection message, and forward the detection message to the next node.

[0044] The present application provides a message processing method and system, the method comprising: a head node receiving configuration information issued by a controller, and determining, based on the configuration information, a Flow ID and Bitmap information required when generating an IOAM header; the configuration information is generated based on a flow detection requirement issued by a cloud platform, the configuration information includes quintuple information, and the head node is directly connected to a source host corresponding to the quintuple information; when the head node completes a table lookup and encapsulates a VXLAN message, if the quintuple information matches an inner message quintuple corresponding to the VXLAN message, encapsulating an IOAM header generated based on the Flow ID and Bitmap information in the VXLAN message, copying an original Protocol field value of the VXLAN message to a Reserved field of the IOAM header, modifying the Protocol field value of the VXLAN message to an IOAM specific identifier, and obtaining a detection message; the head node uses the Bitmap information of the IOAM header in the detection message to report subscription information related to the head node for implementing flow detection to the controller, and forwarding the detection message to the next node.

[0045] It can be seen that in the embodiment of the present application, when encapsulating the IOAM header obtained according to the configuration information in the VXLAN message, the Protocol field content in the VXLAN message is copied to the Reserved field of the IOAM header, and the Protocol field of the VXLAN message is modified to an IOAM specific identifier; in this way, when the forwarding interface of the detection message is subsequently determined, ECMP calculation can be performed based on the Protocol field in the IOAM header. In this way, the consistency of the forwarding path of the detection message and the VXLAN message can be guaranteed, the accuracy of data reporting can be improved, and the operation and maintenance accuracy of the data center network can be ensured; in addition, if the network device is configured with Access Control Lists (ACL) rules, ACL matching can be performed based on the Protocol field in the IOAM header in the detection message to ensure the correct matching of the ACL rules and reduce the network security risks caused by incorrect matching. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] Figure 1A This is a structural diagram of a flow detection method according to an embodiment of the present application;

[0047] Figure 1B This is a flowchart of a message processing method according to an embodiment of the present application;

[0048] Figure 1C This is a schematic diagram of encapsulating an IOAM header in a VXLAN message according to an embodiment of the present application;

[0049] Figure 1D This is a schematic diagram of copying the Protocol field to the IOAM header according to an embodiment of the present application;

[0050] Figure 1E This is a schematic diagram of an IOAM header in a detection message according to an embodiment of the present application;

[0051] Figure 1F A schematic diagram of a detection message according to an embodiment of the present application;

[0052] Figure 2A This is a schematic diagram of a detection message passing through an underlay device in an embodiment of the present application;

[0053] Figure 2B This is a schematic diagram of a detection message passing through an egress node in an embodiment of the present application;

[0054] Figure 2C This is a schematic diagram of detecting a message passing through a VXLAN gateway for scenario 2 according to an embodiment of the present application;

[0055] Figure 2DThis is a schematic diagram of a detection message passing through a VXLAN gateway for scenario three according to an embodiment of the present application;

[0056] Figure 3A This is a structural diagram of message processing for scenario 1 according to an embodiment of the present application;

[0057] Figure 3B This is a structural diagram of message processing for scenario 2 according to an embodiment of the present application;

[0058] Figure 3C This is a structural diagram of message processing for scenario three in an embodiment of the present application;

[0059] Figure 3D This is a flowchart of another message processing method according to an embodiment of the present application. DETAILED DESCRIPTION

[0060] The technical solutions in this application will be described clearly and completely below in conjunction with the accompanying drawings in this application.

[0061] The present application will be further described in detail below in conjunction with the accompanying drawings and examples. It should be understood that the embodiments provided herein are merely intended to explain the present application and are not intended to limit the present application. In addition, the embodiments provided below are partial embodiments for implementing the present application, rather than providing all embodiments for implementing the present application. In the absence of conflict, the technical solutions described in the present application may be implemented in any combination.

[0062] It should be noted that, in this application, the terms "comprises", "includes" or any other variants thereof are intended to cover non-exclusive inclusion, so that a method or apparatus comprising a series of elements includes not only the elements explicitly stated, but also other elements not explicitly listed, or also includes elements inherent to the implementation of the method or apparatus. In the absence of further restrictions, an element defined by the phrase "comprising a ..." does not exclude the presence of other related elements (such as steps in the method or units in the apparatus, for example, a unit may be part of a processor, part of a program or software, etc.) in the method or apparatus comprising the element.

[0063] The term "and / or" herein simply describes an association relationship between associated objects, indicating that three relationships can exist. For example, "A and / or B" can represent the existence of three situations: A alone, A and B simultaneously, and B alone. Furthermore, the term "at least one" herein refers to any combination of at least two of any one or more of a plurality of items. For example, "at least one of A, B, and C" can represent any one or more elements selected from the set consisting of A, B, and C.

[0064] For example, the message processing method provided in the present application includes a series of steps, but the message processing method provided in the present application is not limited to the recorded steps. Similarly, the message processing device provided in the present application includes a series of modules, but the message processing device provided in the present application is not limited to including the modules explicitly recorded, and may also include modules that need to be set up to obtain relevant information or perform processing based on information.

[0065] The present application can be implemented based on an electronic device, where the electronic device can be a thin client, a thick client, a handheld or laptop device, a microprocessor-based system, a set-top box, a programmable consumer electronic product, a network personal computer, a small computer system, etc.

[0066] Electronic devices can implement corresponding functions through the execution of program modules. Generally, program modules can include routines, programs, object programs, components, logic, data structures, etc. They perform specific tasks or implement specific abstract data types. Computer systems can be implemented in distributed cloud computing environments, in which tasks are performed by remote processing devices linked via a communication network. In distributed cloud computing environments, program modules can be located on local or remote computing system storage media, including storage devices.

[0067] Currently, data center networks have fully introduced Software Defined Network (SDN) technology to achieve network automation. VXLAN, as a MAC-in-UDP tunneling technology, can build large-scale Layer 2 network capabilities in data centers and meet the needs of multi-tenant isolation, becoming the mainstream technology in SDN data centers.

[0068] When VXLAN is fully deployed in the data center network, there are three types of traffic that require end-to-end flow detection, such as Figure 1A As shown, Figure 1ASchematic diagram of a structure for performing flow detection in an embodiment of the present application, the structure diagram includes: a control plane and a networking forwarding plane; wherein the control plane includes a cloud platform and three controllers (representing POD1 controller to POD3 controller); the networking forwarding plane includes three data center networks and a public VXLAN network C-Spine, and each controller manages the traffic of a data center network; the data center network includes a VXLAN gateway (GateWay, GW) device, a virtual extended LAN tunnel endpoint (VXLAN Tunnel Endpoints, VTEP) and each host connected to the VTEP; for example, taking the data center network corresponding to the POD1 controller as an example, the data center network includes a VXLAN GW device, VTEP1, VTEP2, VPC1-host1 (host 1) connected to VTEP1, and VPC1-host2 (host 2) and VPC2-host3 (host 3) connected to VTEP2; wherein VPC1-host1 (host 1) and VPC1-host2 (host 2) represent the same tenant virtual network (Virtual Private Cloud, VPC); VPC1-host2 (host 2) and VPC2-host3 (host 3) represent different hosts on different tenant virtual networks.

[0069] Here, each type of traffic that requires end-to-end flow detection can correspond to a scenario. Scenario 1 is: different hosts on the same VPC in the same data center network communicate with each other. For example, VPC1-host1 (host 1) and VPC1-host2 (host 2) in the data center network corresponding to the POD1 controller communicate with each other. Figure 1A As shown by the bold solid line in the figure; Scenario 2 is: different hosts on different VPCs in the same data center network communicate with each other. For example, VPC1-host1 (host 1) and VPC1-host3 (host 3) in the data center network corresponding to the POD1 controller communicate with each other, as shown in the following example: Figure 1A As shown by the dotted line in the figure; Scenario 3: Different hosts in different data center networks communicate with each other. For example, VPC1-host1 (host 1) in the data center network corresponding to the POD1 controller communicates with VPC1-host4 (host 4) in the data center network corresponding to the POD2 controller. Figure 1A Indicated by the non-bold solid line in .

[0070] In related technologies, when performing end-to-end flow detection for the above three scenarios, the Protocol field of the original message will be replaced with a value specific to the detection message. As a result, when determining the interface from which the message is forwarded and calculating ECMP, it is impossible to match based on the Protocol field of the original message. Consequently, the accuracy of the detection message forwarding path cannot be guaranteed, reducing the operation and maintenance accuracy of the data center network.

[0071] In order to solve the above problems, the following embodiments are proposed.

[0072] Figure 1B This is a flow chart of a message processing method according to an embodiment of the present application, such as Figure 1B As shown, the process may include:

[0073] Step 100: The head node receives the configuration information sent by the controller and determines the Flow ID and Bitmap information required when generating the IOAM header based on the configuration information. The configuration information is generated based on the flow detection requirements sent by the cloud platform. The configuration information includes five-tuple information. The head node is directly connected to the source host corresponding to the five-tuple information.

[0074] Here, the cloud platform refers to a service based on hardware resources and software resources, which can provide computing, network and storage capabilities; illustratively, the cloud platform can be connected to one or more controllers, where the controller can be an SDN controller corresponding to one of the PODs.

[0075] In an embodiment of the present application, the cloud platform can configure the flow detection requirements based on the five-tuple information according to actual business needs, and send the flow detection requirements to the corresponding controller; the controller configures the corresponding configuration information based on the received flow detection requirements, and sends the configuration information to the corresponding network device.

[0076] For example, the configuration information may include a five-tuple of information, including a source IP address, a source port, a destination IP address, a destination port, and a transport layer protocol. That is, the controller may determine the network device to which the configuration information is to be sent based on the five-tuple information in the configuration information.

[0077] Here, the network device corresponds to the head node; the head node represents the source VTEP directly connected to the source host corresponding to the five-tuple information in the configuration information issued by the controller. Therefore, the source VTEP can receive the configuration information issued by the controller. For example, the source host can be connected to one or more virtual machines, each of which can be used by a corresponding tenant. The source VTEP can include a software vSwitch or a hardware access switch.

[0078] Specifically, VTEP is a device in the VXLAN protocol that can encapsulate and decapsulate original messages. It can be implemented by hardware or software. Among them, the source VTEP can be used to perform VXLAN encapsulation on the received original messages.

[0079] For example, the Flow ID and Bitmap information may be determined based on the configuration information, wherein the Flow ID and Bitmap information are used to subsequently generate the IOAM header; Figure 1A In the three scenarios shown, the values ​​corresponding to the Flow ID field (i.e., Flow ID) are different, and the value of the Flow ID field is configured by the controller corresponding to the data center network; because the data center networks corresponding to scenario one and scenario two are the same, the Flow ID fields in these two scenarios correspond to the same value, which is different from the value corresponding to the Flow ID field in scenario three; for example, when the value corresponding to the Flow ID field in scenario one and scenario two is 2000, the value corresponding to the Flow ID field in scenario three can be 4000.

[0080] For example, the Flow ID field in scenario one and scenario two corresponds to the same value, indicating that the end-to-end traffic comes from the same data center network; while the Flow ID field in scenario three corresponds to another value, indicating that the end-to-end traffic comes from different data center networks; here, end-to-end means from the head node to the tail node.

[0081] In an embodiment of the present application, after the head node receives the configuration information sent by the controller, the IOAM header can be obtained based on the Flow ID field and Bitmap information (i.e., the content of the Bitmap field) in the configuration information; here, the IOAM header includes a 16-bit Flow ID field, an 8-bit Bitmap field, and an 8-bit Reserved field; Table 1 below lists the type and corresponding definition of each bit in the Bitmap field in the IOAM header.

[0082]

[0083] Table 1

[0084] For example, as can be seen from Table 1, the relevant information such as the device ID of the head node, packet loss, and ingress and egress port timestamps can be obtained based on the Bitmap information in the IOAM header.

[0085] Step 101: When the head node completes the table lookup and encapsulates the VXLAN message, if the quintuple information matches the inner message quintuple corresponding to the VXLAN message, the IOAM header generated based on the Flow ID and Bitmap information is encapsulated in the VXLAN message, and the original Protocol field value of the VXLAN message is copied to the Reserved field of the IOAM header. The Protocol field value of the VXLAN message is modified to the IOAM specific identifier to obtain a detection message.

[0086] In one embodiment, the source host sends an original message (i.e., an inner message) outward. Here, the original message refers to a message that has not been VXLAN encapsulated, and the message can be an original Ethernet frame (Original L2Frame); below, the process of the head node looking up the table is explained. It should be noted that, in the embodiments of the present application, looking up the table means querying the routing table, the purpose of which is to determine the forwarding interface for forwarding the message to the next node.

[0087] When the original message arrives at the head node, it is determined by matching the ACL rules whether the original message needs to be inspected in-flow. If so, the routing table is queried to determine the next node (i.e., the next hop). Specifically, the head node can perform ECMP calculation based on the Protocol field value of the original message and the corresponding quintuple information (i.e., the inner message quintuple). The purpose of performing ECMP calculation here is to determine a better path from multiple paths between the head node and the next node, and then determine the corresponding forwarding interface of the head node from the routing table based on the better path. At this point, the head node completes the table lookup.

[0088] Furthermore, after the head node completes the table lookup, the original message is VXLAN encapsulated to obtain a VXLAN message. Exemplarily, the process of obtaining the VXLAN message can be as follows: first encapsulate the VXLAN header (VXLAN Header) on the basis of the original message, and then encapsulate the entire VXLAN frame in a User Datagram Protocol (UDP) message in the physical network, followed by an IP header and a Media Access Control Header (MAC header). In order to distinguish it from the original Ethernet frame (original message) inside, the outer UDP header (Outer UDP), outer IP header (Outer IP) and outer MAC header (Outer MAC) are added to the external encapsulation.

[0089] Exemplarily, when the head node obtains the above VXLAN message, the IOAM header obtained according to step 100 is encapsulated in the VXLAN message. Specifically, the IOAM header is inserted between the L3 and L4 port numbers of the outer IP header. Figure 1C Provide explanation; Figure 1C This is a schematic diagram of encapsulating an IOAM header in a VXLAN message according to an embodiment of the present application, as shown in FIG. Figure 1C As shown in the figure, in the VXLAN network, the IOAM header is inserted between the L3 and L4 port numbers of the outer IP header; here, L3 corresponds to the Outer IP in the figure, and L4 corresponds to the Outer UDP in the figure.

[0090] For example, in the process of encapsulating the IOAM header in the VXLAN message, the Protocol field content of the VXLAN message is copied to the Reserved field of the IOAM header. Figure 1D As shown; Among them, the IOAM header structure after copying is as follows Figure 1E As shown in the figure, the Reserved field of the IOAM header has been replaced by the Protocol field of the VXLAN message (corresponding to the original Protocol in the figure).

[0091] At the same time, the Protocol field content of the outer IP address in the VXLAN message is modified to the IOAM specific identifier to obtain the detection message. This shows that the two processes of copying the Protocol field content of the VXLAN message to the Reserved field of the IOAM header and modifying the Protocol field content of the outer IP address in the VXLAN message to the IOAM specific identifier can be performed simultaneously. Figure 1F A schematic diagram of a detection message according to an embodiment of the present application is shown in FIG. Figure 1F As shown, the Protocol field content of the outer IP (corresponding to the IPv4 Header in the figure) is modified to the IOAM specific identifier (corresponding to the original IOAM Protocol in the figure).

[0092] Exemplarily, after the detection message is obtained and the forwarding behavior of the message is determined, the detection message may be forwarded to the next node based on the forwarding outgoing interface corresponding to the head node.

[0093] It can be seen that the embodiment of the present application copies the content of the Protocol field in the VXLAN message to the Reserved field of the IOAM header, which can solve the problem that the forwarding path of the detection message and the original message may be inconsistent when forwarding based on the Protocol and quintuple information of the VXLAN message, and the problem that the ACL rules based on the original Protocol become invalid when the network device is configured with ACL rules.

[0094] Step 102: The head node uses the bitmap information of the IOAM header in the detection message to report subscription information related to the head node for implementing follow-up detection to the controller, and forwards the detection message to the next node.

[0095] In this embodiment of the present application, after receiving the detection message according to step 101, the head node can use the bitmap information of the IOAM header in the detection message (the specific meaning is shown in Table 1) to report the subscription information related to the head node to the controller or operation and maintenance platform corresponding to the data center network to which the head node belongs. At the same time, the head node forwards the detection message to the next node; in this case, the next node can be a gateway device in the data center network.

[0096] Exemplarily, the subscription information related to the head node includes the device ID and Flow ID of the head node, and may also include at least one parameter information of the input and output ports, timestamp, and delay.

[0097] Here, the controller or operation and maintenance platform will pre-subscribe to the parameter information of each network device in the data center network. After the controller receives the corresponding subscription information reported by the head node, it will analyze and process this subscription information to determine the quality of the current data center network, thereby achieving rapid fault perception and root cause location, promoting refined network management, and improving the operation and maintenance accuracy of the data center network.

[0098] The present application provides a message processing method and system, the method comprising: a head node receiving configuration information issued by a controller, and determining, based on the configuration information, flow ID and bitmap information required for generating an IOAM header; the configuration information is generated based on a flow detection requirement issued by a cloud platform, the configuration information including five-tuple information, and the head node is directly connected to a source host corresponding to the five-tuple information; when the head node completes a table lookup and encapsulates a VXLAN message, if the five-tuple information matches an inner message five-tuple corresponding to the VXLAN message, the IOAM header generated based on the flow ID and bitmap information is encapsulated in the VXLAN message, the original protocol field value of the VXLAN message is copied to the reserved field of the IOAM header, the protocol field value of the VXLAN message is modified to an IOAM specific identifier, and a detection message is obtained; the head node uses the bitmap information of the IOAM header in the detection message to report subscription information related to the head node for implementing flow detection to the controller, and forwards the detection message to the next node. It can be seen that in the embodiment of the present application, when encapsulating the IOAM header obtained according to the configuration information in the VXLAN message, the Protocol field content in the VXLAN message is copied to the Reserved field of the IOAM header, and the Protocol field of the VXLAN message is modified to an IOAM specific identifier; in this way, when the forwarding interface of the detection message is subsequently determined, ECMP calculation can be performed based on the Protocol field in the IOAM header. In this way, the consistency of the forwarding path of the detection message and the VXLAN message can be guaranteed, the accuracy of data reporting can be improved, and the operation and maintenance accuracy of the data center network can be ensured; in addition, if the network device is configured with ACL rules, ACL matching can be performed based on the Protocol field in the IOAM header in the detection message to ensure the correct matching of the ACL rules and reduce the network security risks caused by incorrect matching.

[0099] In some embodiments, when the head node and tail node corresponding to the VXLAN message are respectively connected to different hosts on the same tenant virtual network in the same data center network (corresponding to scenario one), the above method may also include: after the head node forwards the detection message to the first gateway device, the first gateway device identifies that the Protocol field value is an IOAM specific identifier, and uses the Bitmap information of the IOAM header in the detection message to report to the controller the subscription information related to the first gateway device for implementing in-flow detection, and performs a subtraction operation on the TTL value of the lifetime in the detection message; when querying the next hop and forwarding the interface, the Protocol field value of the IOAM header in the detection message and the offset value corresponding to the IOAM header are used to obtain the port number information for ECMP calculation.

[0100] In an embodiment of the present application, the tail node is directly connected to the destination host, which represents the target VTEP directly connected to the destination host; the first gateway device represents the gateway device in the data center network to which the head node belongs.

[0101] Here, the port number information can be a TCP or UDP port number; the forwarding interface represents the forwarding interface corresponding to the first gateway device, which represents a physical interface; the next hop represents the next node (next network device), that is, the detection message needs to be forwarded from the forwarding interface corresponding to the first gateway device to the next network device.

[0102] Exemplarily, for scenario one, the process of the first gateway device querying the next hop and forwarding out interface is explained. When the detection message arrives at the first gateway device, the Protocol field value of the IOAM header in the detection message and the offset value corresponding to the IOAM header can be used to obtain the port number information for ECMP. Here, the purpose of ECMP calculation is to determine a better path from multiple paths between the first gateway device and the next node (i.e., the next hop), and then determine the forwarding out interface corresponding to the first gateway device from the routing table based on the better path; at this time, the first gateway device completes the query of the next hop and forwarding out interface.

[0103] Afterwards, when the first gateway device needs to forward the detection message, it may forward the detection message to the next node based on the forwarding outbound interface corresponding to the first gateway device.

[0104] For example, for scenario one, the first gateway device is not a VTEP, but an Underlay device. First, based on the content of the Protocol field of the outer IP in the detection message, determine whether the detection message is an IOAM type message; when it is determined that the message is an ordinary IP message, perform ECMP calculation and ACL matching based on the Protocol field and TCP or UDP port number in the IP header of the message; conversely, when it is determined that the detection message is an IOAM type message (that is, the content of the Protocol field is an IOAM specific identifier), the first gateway device reports the subscription information related to the first gateway device for implementing flow detection to the controller based on the Bitmap information of the IOAM header in the message. At the same time, perform a subtraction operation on the TTL value in the detection message; and when querying the next hop and forwarding out interface, obtain the TCP or UDP port number based on the content of the Protocol field in the IOAM header and the offset value corresponding to the IOAM header (the offset value of the 4-byte IOAM header length), and then perform ECMP calculation and ACL matching based on the port number. The specific message processing is as follows: Figure 2AAs shown, it can be seen that before passing through the Underlay device (first gateway device), the TTL value in the detection message is 100, while after passing through the Underlay device, the TTL value in the detection message is 99.

[0105] Furthermore, the above method may also include: using the first gateway device to forward the detection message to the tail node; the tail node uses the Bitmap information of the IOAM header in the detection message to report the subscription information related to the tail node for implementing flow detection to the controller, and then writes back the original Protocol field value of the Reserved field in the IOAM header to the Protocol field of the detection message, and removes the IOAM header in the detection message; the tail node sends the message with the IOAM header removed to the destination host.

[0106] Exemplarily, the destination host represents the target host that establishes communication with the source host; after the detection message arrives at the tail node, the subscription information related to the tail node for implementing flow detection is reported according to the Bitmap information of the IOAM header in the message, and the IOAM header and TTL value are copied to the register; the detection message is then decapsulated. Here, decapsulating the detection message may include: writing back the original Protocol field value of the Reserved field in the IOAM header to the Protocol field of the message, removing the IOAM header in the detection message and performing VXLAN decapsulation to obtain the original message; finally, the tail node sends the original message to the destination host; the specific message processing is as follows Figure 2B As shown in FIG, it can be seen that after passing through the target VTEP (egress node), the detection message is decapsulated into the original message.

[0107] Exemplarily, because the tail node is directly connected to the destination host, the IOMA header and TTL value in the register may be cleared at this time.

[0108] Exemplarily, the subscription information related to the tail node includes the device ID and flow ID of the tail node, and may also include at least one parameter information of the input and output ports, timestamp, and delay.

[0109] In some embodiments, when the head node and tail node corresponding to the VXLAN message are respectively connected to different hosts on different tenant virtual networks in the same data center network (corresponding to scenario two), the above method may also include: after the head node forwards the detection message to the first gateway device, when removing the VXLAN message and the encapsulated IOAM header, the first gateway device saves the IOAM header and TTL value in the detection message to the register, and uses the Bitmap information of the IOAM header in the detection message to report the subscription information related to the first gateway device for implementing flow detection to the controller; when looking up the table and encapsulating a new VXLAN message, the first gateway device uses the IOAM header obtained from the register, the TTL value after performing the minus 1 operation, and the first VXLAN network identifier to re-encapsulate the detection message; when querying the next hop and forwarding interface, the Protocol field value of the IOAM header in the re-encapsulated detection message and the offset value of the IOAM header are used to obtain the port number information for ECMP calculation. Here, the purpose of the table lookup is to determine that in the case of scenario two, the first gateway device forwards the message to the forwarding interface of the next node.

[0110] Here, the first VXLAN network identifier (VNI) represents the identifier of the tenant virtual network corresponding to the outbound interface of the first gateway device, specifically corresponding to the VNI in the VXLAN header; for scenario 2, the VNI value corresponding to the inbound interface of the first gateway device is different from the VNI value corresponding to the outbound interface of the first gateway device; for example, referring to Figure 1A As shown by the dotted line in , the VNI value corresponding to the inbound interface of the first gateway device is 1, and the VNI value corresponding to the outbound interface of the first gateway device is 2.

[0111] Exemplarily, for scenario two, the first gateway device is a VTEP; first, based on the content of the Protocol field of the outer IP in the detection message, determine whether the detection message is an IOAM type message; when it is determined that the message is an ordinary IP message, ECMP calculation and ACL matching are performed based on the Protocol field and TCP or UDP port number in the IP header of the message; conversely, when it is determined that the detection message is an IOAM type message (that is, the content of the Protocol field is an IOAM specific identifier), when removing the VXLAN message and the encapsulated IOAM header, the first gateway device copies the IOAM header and TTL value to the register, and reports the subscription information related to the first gateway device for implementing flow detection to the controller based on the Bitmap information of the IOAM header in the message; at this time, the VNI value in the VXLAN message is the VNI value corresponding to the input interface of the first gateway device.

[0112] Next, when looking up the table and encapsulating a new VXLAN message, the IOAM header obtained from the register, the TTL value after the minus 1 operation, and the first VXLAN network identifier (the VNI value corresponding to the tail node) are used to re-encapsulate the detection message. At this time, the VNI value in the VXLAN message is the VNI value corresponding to the outgoing interface of the first gateway device; and when querying the next hop and forwarding outgoing interface, the TCP or UDP port number is obtained based on the Protocol field content in the IOAM header and the offset value corresponding to the IOAM header (the offset value of the 4-byte IOAM header length), and then ECMP calculation and ACL matching are performed based on the port number. The specific message processing is as follows Figure 2C As shown, it can be seen that before passing through the VXLAN gateway (first gateway device), the TTL value in the detection message is 100 and the VNI value is 11111. After passing through the VXLAN gateway (first gateway device), the TTL value in the re-encapsulated detection message is 99 and the VNI value is 22222.

[0113] For example, for scenario 2, the process of the first gateway device querying the next hop and forwarding the interface is similar to that of scenario 1, and will not be described in detail here.

[0114] Furthermore, the above method may also include: using the first gateway device to forward the re-encapsulated detection message to the tail node; the tail node uses the Bitmap information of the IOAM header in the re-encapsulated detection message to report the subscription information related to the tail node for implementing flow detection to the controller, and then writes the original Protocol field value of the Reserved field in the IOAM header back to the Protocol field of the detection message, and removes the IOAM header in the re-encapsulated detection message; the tail node sends the message with the IOAM header removed to the destination host.

[0115] Here, the implementation method after the re-encapsulated detection message arrives at the egress node is similar to the implementation method after the detection message arrives at the egress node in the above scenario 1, and will not be repeated here.

[0116] In some embodiments, when the head node and tail node corresponding to the VXLAN message are respectively connected to different hosts in different data center networks (corresponding to scenario three), the above method may also include: after the head node forwards the detection message to the first gateway device, when removing the VXLAN message and the encapsulated IOAM header, the first gateway device saves the IOAM header and TTL value in the detection message to the register, and uses the Bitmap information of the IOAM header in the detection message to report the subscription information related to the first gateway device for implementing flow detection to the controller; when looking up the table and encapsulating a new VXLAN message, the first gateway device uses the IOAM header obtained from the register, the TTL value after performing a subtraction operation, the second VXLAN network identifier, and the first value corresponding to the Flow ID field in the IOAM header to re-encapsulate the detection message; the first value represents a preset public traffic identifier; when querying the next hop and forwarding the outgoing interface, the Protocol field value of the IOAM header in the re-encapsulated detection message and the offset value of the IOAM header are used to obtain the port number information for ECMP calculation. Here, the purpose of looking up the table is to determine the outgoing interface of the first gateway device that forwards the message to the next node in the case of scenario three.

[0117] For example, for scenario three, the process of the first gateway device querying the next hop and forwarding the interface is similar to that of scenario one, and will not be described in detail here.

[0118] Here, the second VXLAN network identifier is used to uniquely identify the routing domain corresponding to the interconnection between different tenant virtual networks in different data center networks, and is used to implement independent planning of tenant network identifiers in different data center networks.

[0119] Exemplarily, for scenario three, the first gateway device is a VTEP; first, based on the content of the Protocol field of the outer IP in the detection message, determine whether the detection message is an IOAM type message; when it is determined that the message is an ordinary IP message, ECMP calculation and ACL matching are performed based on the Protocol field and TCP or UDP port number in the IP header of the message; conversely, when it is determined that the detection message is an IOAM type message (that is, the content of the Protocol field is an IOAM specific identifier), when removing the VXLAN message and the encapsulated IOAM header, the first gateway device copies the IOAM header and TTL value to the register, and reports the subscription information related to the first gateway device for implementing flow detection to the controller based on the Bitmap information of the IOAM header in the message; at this time, the VNI value in the VXLAN message is the VNI value corresponding to the input interface of the first gateway device, and the value corresponding to the Flow ID field is the value of the Flow ID field in the IOAM header in scenario one or scenario two, that is, the detection message corresponds to the traffic of the same data center network.

[0120] Next, when looking up the table and encapsulating a new VXLAN message, the IOAM header obtained from the register, the TTL value after the minus 1 operation, the second VXLAN network identifier (the VNI value corresponding to C-Spine), and the first value corresponding to the Flow ID field are used to re-encapsulate the detection message. At this time, the VNI value in the VXLAN message is the second VXLAN network identifier, that is, the VNI value corresponding to C-Spine; and when querying the next hop and forwarding out of the interface, the TCP or UDP port number is obtained based on the Protocol field content in the IOAM header and the offset value corresponding to the IOAM header (the offset value of the 4-byte IOAM header length), and then ECMP calculation and ACL matching are performed according to the port number. The specific message processing is as follows Figure 2D As shown, it can be seen that before passing through the VXLAN gateway (first gateway device), the TTL value in the detection message is 100, the VNI value is 11111, and the value of the Flow ID field is 2000. After the VXLAN gateway (first gateway device), the TTL value in the re-encapsulated detection message is 99, the VNI value is 22222, and the value of the Flow ID field is 4000 (the first value corresponding to the Flow ID field).

[0121] Furthermore, the above method may also include: when the first gateway device forwards the re-encapsulated detection message to the public node, the public node uses the Bitmap information of the IOAM header in the re-encapsulated detection message to report the subscription information related to the public node for implementing flow detection to the controller, and updates the TTL value in the re-encapsulated detection message to the value after performing a minus 1 operation; the public node represents a node in the public VXLAN network; when querying the next hop and forwarding out interface, the Protocol field value of the IOAM header in the re-encapsulated detection message and the offset value of the IOAM header are used to obtain the port number information for ECMP calculation.

[0122] Exemplarily, for scenario three, the process of the public node querying the next hop and forwarding interface is explained. When the detection message arrives at the public node, the Protocol field value of the IOAM header in the detection message and the offset value corresponding to the IOAM header can be used to obtain the port number information for ECMP. Here, the purpose of ECMP calculation is to determine a better path from multiple paths between the public node and the next node (i.e., the next hop), and then determine the forwarding interface corresponding to the public node from the routing table based on the better path; at this time, the public node completes the query of the next hop and forwarding interface.

[0123] Afterwards, when the public node needs to forward the detection message, the detection message may be forwarded to the next node based on the forwarding outbound interface corresponding to the public node.

[0124] Exemplarily, a public node represents a node in a public VXLAN network, corresponding to Figure 1A Here, the public node processes the detection message in a similar manner to the first gateway device in the above scenario 1, and will not be described in detail here.

[0125] Exemplarily, the subscription information related to the public node includes the device ID and Flow ID of the public node, and may also include at least one parameter information of the input and output ports, timestamp, and delay.

[0126] In some embodiments, the above method may also include: using a public node to forward the re-encapsulated detection message to a second gateway device; when removing the VXLAN message and the encapsulated IOAM header, the second gateway device saves the IOAM header and TTL value in the re-encapsulated detection message to a register; and using the Bitmap information of the IOAM header in the re-encapsulated detection message to report subscription information related to the second gateway device for implementing flow detection to the controller; when looking up the table and encapsulating a new VXLAN message, the second gateway device uses the IOAM header obtained from the register, the TTL value after continuing to perform the subtraction operation, the third VXLAN network identifier, and the second value corresponding to the Flow ID field in the IOAM header to encapsulate the detection message again. Here, the purpose of the table lookup is to determine that in the case of scenario three, the second gateway device forwards the message to the forwarding interface of the next node.

[0127] Here, the third VXLAN network identifier represents the identifier of the tenant virtual network corresponding to the second gateway device outbound interface; for example, referring to Figure 1A As shown by the unbold solid line in the figure, the VNI value corresponding to the inbound interface of the second gateway device is 1, while the VNI value corresponding to the outbound interface of the second gateway device is 3. The second value corresponding to the Flow ID field is used to represent the flow identifier corresponding to the data center network to which the second gateway device belongs; that is, the value of the Flow ID field in the IOAM header in scenario 1 or scenario 2, refer to Figure 2D , the second value of the Flow ID field is 2000.

[0128] Exemplarily, for scenario three, the second gateway device is VTEP; the re-encapsulated detection message is forwarded to the second gateway device. When removing the VXLAN message and the encapsulated IOAM header, the second gateway device copies the IOAM header and TTL value to the register, and reports the subscription information related to the second gateway device for implementing in-flow detection to the controller based on the Bitmap field of the IOAM header in the message, and then removes the IOAM header in the detection message; at this time, the VNI value in the detection message is the VNI value corresponding to the public node.

[0129] Then, when looking up the table and encapsulating a new VXLAN message, the IOAM header obtained from the register, the TTL value after continuing to perform the subtraction operation, the third VXLAN network identifier (the VNI value corresponding to the second gateway device output interface), and the second value corresponding to the Flow ID field are used to encapsulate the detection message again; the IOAM header obtained from the register, the TTL value after performing the subtraction operation, the second VXLAN network identifier (the VNI value corresponding to the C-Spine), and the second value corresponding to the Flow ID field are used to re-encapsulate the detection message.

[0130] Exemplarily, the subscription information related to the second gateway device includes the device ID and Flow ID of the second gateway device, and may also include at least one parameter information of the input and output ports, timestamp, and delay.

[0131] In some embodiments, the above method may also include: using a second gateway device to forward the re-encapsulated detection message to the tail node; the tail node uses the Bitmap information of the IOAM header in the re-encapsulated detection message to report the subscription information related to the tail node for implementing in-flow detection to the controller, and then writes the original Protocol field value of the Reserved field in the IOAM header back to the Protocol field of the detection message, and removes the IOAM header in the re-encapsulated detection message; the tail node sends the message with the IOAM header removed to the destination host.

[0132] Here, the implementation method after the re-encapsulated detection message arrives at the egress node is similar to the implementation method after the detection message arrives at the egress node in the above scenario 1, and will not be repeated here.

[0133] In order to better reflect the purpose of this application, further explanation is given based on the above embodiments of this application.

[0134] Figure 3A This is a structural diagram of message processing for scenario 1 according to an embodiment of the present application. Figure 3A As shown, first, the original message passes through VTEP1 (head node), and the original message is VXLAN encapsulated on the node to obtain a VXLAN message, and the IOAM header is encapsulated in the VXLAN message to obtain a detection message. At this time, the VNI value in the detection message is 1 (the L3 VNI value of VPC1 in this data center network), and then the detection message is forwarded to the VXLAN GW (first gateway device).

[0135] When a detection message reaches the VXLAN GW (an underlay device), the VXLAN GW reports its subscription information for in-flight detection to the controller based on the Bitmap field in the IOAM header. At the same time, the TTL value in the detection message is decremented by 1. When querying the next hop and outgoing interface, the GW obtains the TCP or UDP port number based on the Protocol field in the IOAM header and the offset value (the offset value of the 4-byte IOAM header length) corresponding to the IOAM header. ECMP calculation and ACL matching are then performed based on this port number.

[0136] When the detection message reaches VTEP2 (the egress node), VTEP2 reports its subscription information for in-flight detection based on the Bitmap field in the IOAM header of the message, and copies the IOAM header and TTL value to the register. The detection message is then decapsulated to obtain the original message, and finally, the original message is sent to VPC1-host2 (the destination host). Because VTEP2 is directly connected to the destination host, the IOAM header and TTL value in the register must be cleared.

[0137] Figure 3B This is a structural diagram of message processing for scenario 2 according to an embodiment of the present application. Figure 3B As shown, first, the original message passes through VTEP1 (head node), and the original message is VXLAN encapsulated on the node to obtain a VXLAN message, and the IOAM header is encapsulated in the VXLAN message to obtain a detection message. At this time, the VNI value in the detection message is 1 (the L3 VNI value of VPC1 in this data center network), and then the detection message is forwarded to the VXLAN GW (first gateway device).

[0138] When it is determined that the detection message has arrived at the VXLAN GW (which is a VTEP), the VXLAN GW copies the IOAM header and TTL value to the register, and reports the subscription information related to the VXLAN GW for implementing flow detection to the controller based on the Bitmap field of the IOAM header in the message. After that, the IOAM header in the detection message is removed. The original IOAM header and TTL value are re-encapsulated in the VXLAN message, and the VNI value is changed to 2 (the L3 VNI value of VPC2 in this data center network). When querying the next hop and forwarding interface, the TCP or UDP port number is obtained based on the Protocol field content in the IOAM header and the offset value corresponding to the IOAM header (the offset value of the 4-byte IOAM header length). Then, ECMP calculation and ACL matching are performed based on the port number.

[0139] When the detection message reaches VTEP2 (the egress node), VTEP2 reports its subscription information for in-stream detection based on the Bitmap field in the IOAM header of the message, and copies the IOAM header and TTL value to the register. The detection message is then decapsulated to obtain the original message, and finally, the original message is sent to VPC2-host3 (the destination host). Because VTEP2 is directly connected to the destination host, the IOAM header and TTL value in the register must be cleared.

[0140] Figure 3C This is a structural diagram of message processing for scenario three in an embodiment of the present application. Figure 3C As shown, first, the original message passes through the VTEP1 node (head node), and the original message is VXLAN encapsulated on the node to obtain a VXLAN message, and the IOAM header is encapsulated in the VXLAN message to obtain a detection message. At this time, the VNI value in the detection message is 1 (the L3 VNI value of VPC1 in this data center network), and then the detection message is forwarded to the VXLAN GW (first gateway device).

[0141] When the detection message is determined to have arrived at VXLAN GW1 (which is a VTEP), the VXLAN GW copies the IOAM header and TTL value to a register and, based on the Bitmap field in the IOAM header, reports the subscription information related to the VXLAN GW for implementing in-flow detection to the controller. The IOAM header in the detection message is then removed. The original IOAM header and TTL value are re-encapsulated in the VXLAN message and, based on VNI Mapping, the VNI value is changed to 4 (the VNI value corresponding to C-Spine). Based on the controller-configured Flow ID mapping table, the original value corresponding to the intra-POD Flow ID field (the second value corresponding to the Flow ID field) is replaced with the value corresponding to the inter-POD Flow ID field (the first value corresponding to the Flow ID field). When querying the next hop and forwarding interface, the TCP or UDP port number is obtained based on the Protocol field in the IOAM header and the offset value corresponding to the IOAM header (the offset value of the 4-byte IOAM header length). ECMP calculation and ACL matching are then performed based on this port number.

[0142] When a detection message arrives at the C-spine (not the VTEP), the C-spine reports subscription information related to the VXLAN GW for in-flow detection to the controller based on the Bitmap field in the IOAM header of the message. At the same time, the TTL value in the detection message is decremented by 1. When querying the next hop and forwarding interface, the TCP or UDP port number is obtained based on the Protocol field in the IOAM header and the offset value corresponding to the IOAM header (the offset value of the 4-byte IOAM header length). ECMP calculation and ACL matching are then performed based on this port number.

[0143] When the detection message arrives at VXLAN GW2 (the second gateway device), VXLAN GW copies the IOAM header and TTL value to the register, and reports the subscription information related to VXLAN GW for implementing flow detection to the controller based on the Bitmap field of the IOAM header in the message. After that, the IOAM header in the detection message is removed. The original IOAM header and TTL value are re-encapsulated in the VXLAN message, and the VNI value is changed to 3 (the L3 VNI value of VPC3 in this data center network); and based on the mapping table maintained by the local VXLAN gateway, the value of the Flow ID field (the first value corresponding to the Flow ID field) is replaced with the value in this POD (the second value corresponding to the Flow ID field); thereby, while completing the end-to-end flow detection, the allocation of Flow IDs between different PODs is decoupled.

[0144] When the detection message reaches VTEP3 (the egress node), VTEP2 reports its subscription information for in-flight detection based on the Bitmap field in the IOAM header of the message, and copies the IOAM header and TTL value to the register. The detection message is then decapsulated to obtain the original message, and finally, the original message is sent to VPC3-host4 (the destination host). Because VTEP2 is directly connected to the destination host, the IOAM header and TTL value in the register must be cleared.

[0145] Figure 3D This is a flow chart of another message processing method according to an embodiment of the present application, such as Figure 1B As shown, the process may include:

[0146] Step A1: Determine whether it is the head node.

[0147] For example, after the message reaches a certain network device in the data center network, it is necessary to determine whether the network device where the message arrives is a head node. If yes, execute step A2; otherwise, execute step A3.

[0148] Step A2: Encapsulate the IOAM header.

[0149] For example, after the message arrives at the head node, it is indicated that the message is an original message; at this time, the original message is VXLAN encapsulated to obtain a VXLAN message; and the IOAM header is encapsulated in the VXLAN message, and the Protocol field content of the VXLAN message is copied to the Reserved field of the IOAM header to facilitate subsequent ECMP calculation and ACL matching.

[0150] Step A3: Determine whether it is a VTEP.

[0151] Exemplarily, when the network device to which the message arrives is not the head node, it indicates that the message is a detection message; at this time, it is further determined whether the network device is a VTEP, if not, executing step A4, otherwise executing step A5.

[0152] Step A4: Perform a first process on the detection message.

[0153] For example, after the detection message reaches the non-VTEP (corresponding to the above-mentioned C-Spine), C-Spine uses the IOAM header in the detection message to report the corresponding subscription information to the controller, and at the same time updates the TTL value in the detection message to the value after performing the minus 1 operation, and forwards it.

[0154] Step A5: Determine whether it is the tail node.

[0155] Exemplarily, when the network device to which the message arrives is neither the head node nor the VTEP, it is further determined whether the network device is the tail node. If so, step A6 is executed; otherwise, step A7 is executed.

[0156] Step A6: Perform a second process on the detection message.

[0157] Illustratively, when the detection message reaches the egress node, the egress node reports the corresponding subscription information according to the Bitmap field of the IOAM header in the message, decapsulates the detection message to obtain the original message, and finally forwards the original message to the destination host.

[0158] Step A7: Determine whether the traffic is within the POD.

[0159] For example, if the network device to which the detection message arrives is neither the head node, nor the VTEP, nor the egress node, a determination is made as to whether the traffic corresponding to the detection message is intra-Pod traffic. If so, step A8 is executed; otherwise, step A9 is executed. Intra-Pod traffic refers to traffic within the same data center network; that is, a determination is made as to whether the traffic corresponding to the detection message is intra-Pod traffic.

[0160] Step A8: Perform third processing on the detection message.

[0161] For example, when the traffic corresponding to the detection message is the traffic within the same data center network, that is, corresponding to the above-mentioned scenario 2; at this time, the network device where the detection message is located reports the corresponding subscription information according to the Bitmap field of the IOAM header in the message, and copies the IOAM header and TTL value to the register, and then removes the IOAM header in the detection message, checks and forwards to determine the output interface; at this time, if it is determined that the value corresponding to the Flow ID field is empty, there is no need to change the value corresponding to the Flow ID field; the original IOAM header and TTL value are re-encapsulated in the VXLAN message.

[0162] Step A9: Perform the fourth processing on the detection message.

[0163] For example, when the traffic corresponding to the detection message is not the traffic within the same data center network, that is, corresponding to the above-mentioned scenario three; at this time, the network device where the detection message is located reports the corresponding subscription information according to the Bitmap field of the IOAM header in the message, and copies the IOAM header and TTL value to the register, and then removes the IOAM header in the detection message, checks and forwards to determine the output interface; at this time, if it is determined that the value corresponding to the Flow ID field is not empty, it is necessary to change the value corresponding to the Flow ID field; and re-encapsulate the original IOAM header and TTL value in the VXLAN message.

[0164] It can be seen that in the embodiment of the present application, the original Protocol field content is first backed up in the Reserved field of the IOAM header to ensure the accuracy of the detection message forwarding path and the correct matching of the ACL policy; at the same time, different values ​​of Flow ID are introduced to distinguish the processing mechanism of traffic between and within data center networks, thereby realizing the decoupling of the allocation of FlowIDs between different PODs.

[0165] The present application also provides a message processing system, which includes a head node, wherein:

[0166] The head node is used to receive configuration information issued by the controller and, based on the configuration information, determine the flow ID and bitmap information required when generating the IOAM header; the configuration information is generated based on the flow detection requirements issued by the cloud platform, and the configuration information includes quintuple information. The head node is directly connected to the source host corresponding to the quintuple information;

[0167] When the head node completes the table lookup and encapsulates the VXLAN message, if the quintuple information matches the inner message quintuple corresponding to the VXLAN message, the head node encapsulates the IOAM header generated according to the Flow ID and the bitmap information into the VXLAN message, copies the original Protocol field value of the VXLAN message to the Reserved field of the IOAM header, modifies the Protocol field value of the VXLAN message to the IOAM specific identifier, and obtains a detection message;

[0168] The head node is configured to report subscription information related to the head node for implementing follow-up detection to the controller by using the Bitmap information of the IOAM header in the detection message, and forward the detection message to the next node.

[0169] In some embodiments, when the head node and tail node corresponding to the VXLAN message are respectively connected to different hosts on the same tenant virtual network in the same data center network, the system further includes a first gateway device, wherein,

[0170] After the head node forwards the detection message to the first gateway device, the first gateway device is configured to identify that the Protocol field value is an IOAM specific identifier, use the bitmap information of the IOAM header in the detection message, report subscription information related to the first gateway device for implementing in-stream detection to the controller, and perform a decrement operation on the TTL value in the detection message;

[0171] The first gateway device is used to obtain port number information and perform equal cost multi-path ECMP calculation using the Protocol field value of the IOAM header in the detection message and the offset value corresponding to the IOAM header when querying the next hop and forwarding the interface.

[0172] Furthermore, the system further includes an end node, which is directly connected to the destination host, wherein:

[0173] forwarding the detection message to the egress node using the first gateway device;

[0174] The egress node is configured to use the bitmap information of the IOAM header in the detection message to report subscription information related to the egress node for implementing follow-up detection to the controller, write back the original Protocol field value of the Reserved field in the IOAM header to the Protocol field of the detection message, and remove the IOAM header in the detection message;

[0175] The tail node is used to send the message with the IOAM header removed to the destination host.

[0176] In some embodiments, when the head node and tail node corresponding to the VXLAN message are respectively connected to different hosts on different tenant virtual networks in the same data center network, the system further includes a first gateway device, wherein,

[0177] After the head node forwards the detection message to the first gateway device, when removing the VXLAN message and the encapsulated IOAM header, the first gateway device is used to save the IOAM header and TTL value in the detection message into a register, and use the bitmap information of the IOAM header in the detection message to report subscription information related to the first gateway device for implementing flow detection to the controller;

[0178] When looking up the table and encapsulating a new VXLAN message, the first gateway device is used to re-encapsulate the detection message using the IOAM header obtained from the register, the TTL value after performing the decrement operation, and the first VXLAN network identifier; the first VXLAN network identifier represents an identifier of the tenant virtual network corresponding to the outbound interface of the first gateway device;

[0179] The first gateway device is configured to obtain port number information and perform ECMP calculation using the Protocol field value of the IOAM header in the re-encapsulated detection message and the offset value of the IOAM header when querying the next hop and forwarding out interface.

[0180] Furthermore, the system further includes an end node, which is directly connected to the destination host, wherein:

[0181] forwarding the re-encapsulated detection message to the egress node using the first gateway device;

[0182] The egress node is configured to use the bitmap information of the IOAM header in the re-encapsulated detection message to report subscription information related to the egress node for implementing in-stream detection to the controller, write back the original Protocol field value of the Reserved field in the IOAM header to the Protocol field of the detection message, and remove the IOAM header in the re-encapsulated detection message;

[0183] The tail node is used to send the message with the IOAM header removed to the destination host.

[0184] In some embodiments, when the head node and tail node corresponding to the VXLAN message are respectively connected to different hosts in different data center networks, the system further includes a first gateway device, wherein:

[0185] After the head node forwards the detection message to the first gateway device, when removing the VXLAN message and the encapsulated IOAM header, the first gateway device is used to save the IOAM header and TTL value in the detection message into a register, and use the bitmap information of the IOAM header in the detection message to report subscription information related to the first gateway device for implementing flow detection to the controller;

[0186] When looking up the table and encapsulating a new VXLAN message, the first gateway device is used to re-encapsulate the detection message using the IOAM header obtained from the register, the TTL value after performing the decrement operation, the second VXLAN network identifier, and the first value corresponding to the Flow ID field in the IOAM header; the first value represents a preset public flow identifier; the second VXLAN network identifier is used to uniquely identify the corresponding routing domain of the interconnection between different tenant virtual networks in different data center networks, and is used to implement independent planning of tenant network identifiers in different data center networks;

[0187] The first gateway device is configured to obtain port number information and perform ECMP calculation using the Protocol field value of the IOAM header in the re-encapsulated detection message and the offset value of the IOAM header when querying the next hop and forwarding out interface.

[0188] Furthermore, the system also includes a public node, wherein:

[0189] When the first gateway device forwards the re-encapsulated detection message to the public node, the public node is used to use the bitmap information of the IOAM header in the re-encapsulated detection message to report subscription information related to the public node for implementing flow detection to the controller, and update the TTL value in the re-encapsulated detection message to a value after performing a decrement operation; the public node represents a node in the public VXLAN network;

[0190] The public node is used to obtain port number information and perform ECMP calculation using the Protocol field value of the IOAM header in the re-encapsulated detection message and the offset value of the IOAM header when querying the next hop and forwarding the outgoing interface.

[0191] Furthermore, the system further includes a second gateway device, wherein:

[0192] The re-encapsulated detection message is forwarded to the second gateway device using the public node. When the VXLAN message and the encapsulated IOAM header are removed, the second gateway device is used to save the IOAM header and TTL value in the re-encapsulated detection message into a register, and use the bitmap information of the IOAM header in the re-encapsulated detection message to report subscription information related to the second gateway device for implementing flow detection to the controller;

[0193] When the second gateway device is used to look up the table and encapsulate a new VXLAN message, the second gateway device uses the IOAM header obtained from the register, the TTL value after continuing to perform the subtraction operation, the third VXLAN network identifier, and the second value corresponding to the Flow ID field in the IOAM header to re-encapsulate the detection message; the third VXLAN network identifier represents the identifier of the tenant virtual network corresponding to the outbound interface of the second gateway device; the second value is used to represent the flow identifier corresponding to the data center network to which the second gateway device belongs.

[0194] Furthermore, the system further includes an end node, which is directly connected to the destination host, wherein:

[0195] forwarding the re-encapsulated detection message to the egress node using the second gateway device;

[0196] The egress node is configured to use the bitmap information of the IOAM header in the re-encapsulated detection message to report subscription information related to the egress node for implementing in-stream detection to the controller, write back the original Protocol field value of the Reserved field in the IOAM header to the Protocol field of the detection message, and remove the IOAM header in the re-encapsulated detection message;

[0197] The tail node is used to send the message with the IOAM header removed to the destination host.

[0198] In some embodiments, the subscription information includes the device ID and Flow ID of the head node.

[0199] The above description of the various embodiments tends to emphasize the differences between the various embodiments. The same or similar aspects can be referenced with each other and will not be repeated herein for the sake of brevity.

[0200] The methods disclosed in the various method embodiments provided in this application can be arbitrarily combined without conflict to obtain new method embodiments.

[0201] The features disclosed in the various product embodiments provided in this application can be arbitrarily combined without conflict to obtain new product embodiments.

[0202] The features disclosed in the various method or device embodiments provided in this application can be arbitrarily combined without conflict to obtain new method embodiments or device embodiments.

[0203] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may adopt the form of hardware embodiments, software embodiments, or embodiments combining software and hardware. Furthermore, the present application may adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage and optical storage, etc.) containing computer-usable program code.

[0204] The present application is described with reference to the flow chart and / or block diagram of the method, device (system) and computer program product according to the embodiment of the present application. It should be understood that each flow process and / or box in the flow chart and / or block diagram and the combination of the flow process and / or box in the flow chart and / or block diagram can be realized by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded processing machine or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device produce a device for realizing the function specified in one flow chart flow or multiple flows and / or one box or multiple boxes of the block diagram.

[0205] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, whereby the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0206] The above are merely preferred embodiments of the present application and are not intended to limit the scope of protection of the present application.

Claims

1. A message processing method, characterized in that: The method comprises: The head node receives configuration information issued by the controller and, based on the configuration information, determines the flow ID and bitmap information required for generating an in-band operation, management, and maintenance (IOAM) header. The configuration information is generated based on the in-flow detection requirements issued by the cloud platform and includes five-tuple information. The head node is directly connected to the source host corresponding to the five-tuple information. When the head node completes the table lookup and encapsulates the Virtual Extended Local Area Network (VXLAN) message, if the quintuple information matches the inner message quintuple corresponding to the VXLAN message, the head node encapsulates the IOAM header generated according to the Flow ID and the bitmap information into the VXLAN message, copies the original Protocol field value of the VXLAN message to the Reserved field of the IOAM header, modifies the Protocol field value of the VXLAN message to the IOAM specific identifier, and obtains a detection message; The head node uses the Bitmap information of the IOAM header in the detection message to report subscription information related to the head node for implementing follow-up detection to the controller, and forwards the detection message to the next node.

2. The method according to claim 1, characterized in that When the head node and the tail node corresponding to the VXLAN message are respectively connected to different hosts on the same tenant virtual network in the same data center network, the method further includes: After the head node forwards the detection message to the first gateway device, the first gateway device identifies the Protocol field value as an IOAM specific identifier, uses the bitmap information of the IOAM header in the detection message, reports subscription information related to the first gateway device for implementing in-stream detection to the controller, and decrements the TTL value in the detection message by 1. When querying the next hop and forwarding outbound interface, the Protocol field value of the IOAM header in the detection message and the offset value corresponding to the IOAM header are used to obtain port number information for performing equal cost multi-path (ECMP) calculation.

3. The method according to claim 2, characterized in that The tail node is directly connected to the destination host, and the method further includes: forwarding the detection message to the egress node using the first gateway device; The egress node uses the bitmap information of the IOAM header in the detection message to report subscription information related to the egress node for implementing follow-up detection to the controller, and then writes back the original Protocol field value of the Reserved field in the IOAM header to the Protocol field of the detection message, removing the IOAM header in the detection message. The tail node sends the message with the IOAM header removed to the destination host.

4. The method according to claim 1, wherein When the head node and the tail node corresponding to the VXLAN message are respectively connected to different hosts on different tenant virtual networks in the same data center network, the method further includes: After the head node forwards the detection message to the first gateway device, when removing the VXLAN message and the encapsulated IOAM header, the first gateway device saves the IOAM header and TTL value in the detection message into a register, and uses the bitmap information of the IOAM header in the detection message to report subscription information related to the first gateway device for implementing flow detection to the controller; When looking up the table and encapsulating a new VXLAN message, the first gateway device re-encapsulates the detection message using the IOAM header obtained from the register, the TTL value after performing a decrement operation by 1, and the first VXLAN network identifier; the first VXLAN network identifier represents an identifier of the tenant virtual network corresponding to the outbound interface of the first gateway device; When querying the next hop and forwarding out interface, the Protocol field value of the IOAM header in the re-encapsulated detection message and the offset value of the IOAM header are used to obtain port number information for ECMP calculation.

5. The method according to claim 4, characterized in that The tail node is directly connected to the destination host, and the method further includes: forwarding the re-encapsulated detection message to the egress node using the first gateway device; The egress node uses the bitmap information of the IOAM header in the re-encapsulated detection message to report subscription information related to the egress node for implementing in-stream detection to the controller, writes back the original Protocol field value of the Reserved field in the IOAM header to the Protocol field of the detection message, and removes the IOAM header in the re-encapsulated detection message; The tail node sends the message with the IOAM header removed to the destination host.

6. The method according to claim 1, characterized in that When the head node and the tail node corresponding to the VXLAN message are respectively connected to different hosts in different data center networks, the method further includes: After the head node forwards the detection message to the first gateway device, when removing the VXLAN message and the encapsulated IOAM header, the first gateway device saves the IOAM header and TTL value in the detection message into a register, and uses the bitmap information of the IOAM header in the detection message to report subscription information related to the first gateway device for implementing flow detection to the controller; When looking up the table and encapsulating a new VXLAN message, the first gateway device re-encapsulates the detection message using the IOAM header obtained from the register, the TTL value after performing a decrement operation, the second VXLAN network identifier, and the first value corresponding to the Flow ID field in the IOAM header; the first value represents a preset public flow identifier; the second VXLAN network identifier is used to uniquely identify the corresponding routing domain of the interconnection between different tenant virtual networks in different data center networks, and is used to implement independent planning of network identifiers for tenants in different data center networks; When querying the next hop and forwarding out interface, the Protocol field value of the IOAM header in the re-encapsulated detection message and the offset value of the IOAM header are used to obtain port number information for ECMP calculation.

7. The method according to claim 6, characterized in that The method further comprises: When the first gateway device forwards the re-encapsulated detection message to the public node, the public node uses the bitmap information of the IOAM header in the re-encapsulated detection message to report subscription information related to the public node for implementing in-flow detection to the controller, and updates the TTL value in the re-encapsulated detection message to a value after performing a decrement operation; the public node represents a node in the public VXLAN network; When querying the next hop and forwarding out interface, the Protocol field value of the IOAM header in the re-encapsulated detection message and the offset value of the IOAM header are used to obtain port number information for ECMP calculation.

8. The method according to claim 7, characterized in that The method further comprises: The re-encapsulated detection message is forwarded to the second gateway device by using the public node. When the VXLAN message and the encapsulated IOAM header are removed, the second gateway device saves the IOAM header and the TTL value in the re-encapsulated detection message into a register, and reports subscription information related to the second gateway device for implementing in-flow detection to the controller by using the bitmap information of the IOAM header in the re-encapsulated detection message; When looking up the table and encapsulating a new VXLAN message, the second gateway device uses the IOAM header obtained from the register, the TTL value after continuing to perform the subtraction operation, the third VXLAN network identifier, and the second value corresponding to the Flow ID field in the IOAM header to encapsulate the detection message again; the third VXLAN network identifier represents the identifier of the tenant virtual network corresponding to the outbound interface of the second gateway device; the second value is used to represent the flow identifier corresponding to the data center network to which the second gateway device belongs.

9. The method according to claim 8, characterized in that The tail node is directly connected to the destination host, and the method further includes: forwarding the re-encapsulated detection message to the egress node using the second gateway device; The egress node uses the bitmap information of the IOAM header in the re-encapsulated detection message to report subscription information related to the egress node for implementing in-stream detection to the controller, writes back the original Protocol field value of the Reserved field in the IOAM header to the Protocol field of the detection message, and removes the IOAM header in the re-encapsulated detection message; The tail node sends the message with the IOAM header removed to the destination host.

10. The method according to claim 1, characterized in that The subscription information includes the device identification number ID and Flow ID of the head node.

11. A message processing system, characterized in that: The message processing system includes a head node, wherein the head node is used to receive configuration information issued by the controller and determine, based on the configuration information, flow ID and bitmap information required when generating an IOAM header; the configuration information is generated based on the flow detection requirements issued by the cloud platform, the configuration information includes quintuple information, and the head node is directly connected to the source host corresponding to the quintuple information; When the head node completes the table lookup and encapsulates the VXLAN message, if the quintuple information matches the inner message quintuple corresponding to the VXLAN message, the head node encapsulates the IOAM header generated according to the Flow ID and the bitmap information into the VXLAN message, copies the original Protocol field value of the VXLAN message to the Reserved field of the IOAM header, modifies the Protocol field value of the VXLAN message to the IOAM specific identifier, and obtains a detection message; The head node is configured to report subscription information related to the head node for implementing follow-up detection to the controller by using the Bitmap information of the IOAM header in the detection message, and forward the detection message to the next node.

Images