CN116132555A

CN116132555A - Message processing method and system

Info

Publication number: CN116132555A
Application number: CN202111350114.5A
Authority: CN
Inventors: 王瑞雪; 秦凤伟; 张译戈
Original assignee: China Mobile Communications Group Co Ltd; China Mobile Communications Ltd Research Institute
Current assignee: China Mobile Communications Group Co Ltd; China Mobile Communications Ltd Research Institute
Priority date: 2021-11-15
Filing date: 2021-11-15
Publication date: 2023-05-16

Abstract

The application provides a message processing method and a message processing system, wherein the method comprises the following steps: the head node receives configuration information issued by the controller, and determines Flow ID and Bitmap information required when the IOAM head is generated according to the configuration information; when the header node finishes looking up a table and encapsulates the VXLAN message, if the quintuple information is matched with an inner layer message quintuple corresponding to the VXLAN message, encapsulating an IOAM header generated according to the Flow ID and Bitmap information in the VXLAN message, copying an original Protocol field value of the VXLAN message into a Reserved field of the IOAM header, and modifying the Protocol field value of the VXLAN message into an IOAM specific identifier to obtain a detection message; the head node reports subscription information which is related to the head node and is used for realizing the detection along with the flow to the controller by utilizing the Bitmap information of the IOAM head in the detection message, and forwards the detection message to the next node.

Description

Message processing method and system

Technical Field

The present disclosure relates to the field of data service technologies, and in particular, to a method and system for processing a message.

Background

With the continuous development of cloud computing technology and mature network function virtualization (Network Functions Virtualization, NFV) technology, cloud services are increasingly wide, the network scale of a data center is continuously improved, and the daily monitoring operation and maintenance of key services and rapid positioning during faults are promoted to be new challenges. In order to improve the operation and maintenance precision and efficiency of a data center network, a network telemetry technology is generated, a flow-following detection technology and a network analysis platform are introduced into the data center network, parameter information such as an access port, a time stamp, time delay and the like in the process of transmitting a message to the analysis platform is reported by all network equipment along the way, and network quality information such as path visibility, packet loss, time delay and the like is provided by combining the technologies such as data analysis, artificial intelligence and the like, so that quick fault perception and root cause positioning are realized, and network refined management is promoted.

In the related art, one of the main schemes of the flow detection technology is to use a Protocol field of a header of an internet Protocol (Internet Protocol, IP) message to identify that the message is of an In-band operation management maintenance (In-situ Operation Administration and Maintenance, IOAM) type, and the along-the-way device reports parameter information such as a device ID, an access port, a timestamp, a time delay and the like to the analysis platform by identifying the type of the message. However, in this scheme, the Protocol field of the original message is replaced with a value specific to the detection message; because the data center network has the requirement of Equal-cost-Cost Multipath Routing (ECMP), and the Protocol field is used as one of the parameters of ECMP calculation, if the Protocol field changes, the forwarding paths of the detection message and the original message are inconsistent, so that the reported data are inaccurate, and further, the operation and maintenance precision of the data center network is reduced.

Disclosure of Invention

The application provides a message processing method and a message processing system; the accuracy of the detected message forwarding path can be ensured, and the operation and maintenance precision of the data center network can be improved.

The technical scheme of the application is realized as follows:

the application provides a message processing method, which comprises the following steps:

The head node receives configuration information issued by the controller, and determines Flow ID and Bitmap information required when the IOAM head is generated according to the configuration information; the configuration information is generated according to the stream following detection requirement issued by the cloud platform, the configuration information comprises quintuple information, and the head node is directly connected with a source host corresponding to the quintuple information;

when the head node completes table lookup and encapsulates a virtual extended local area network (Virtual Extensible Local Area Network, VXLAN) message, if the quintuple information is matched with an inner layer message quintuple corresponding to the VXLAN message, encapsulating an IOAM header generated according to the Flow ID and Bitmap information in the VXLAN message, copying an original Protocol field value of the VXLAN message into a Reserved field of the IOAM header, and modifying the Protocol field value of the VXLAN message as an IOAM specific identifier to obtain a detection message;

and the head node reports subscription information which is related to the head node and is used for realizing the detection along with the flow to the controller by utilizing the Bitmap information of the IOAM head in the detection message, and forwards the detection message to the next node.

In some embodiments, in a case that the head node and the tail node corresponding to the VXLAN packet 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 a first gateway device, the first gateway device recognizes that the Protocol field value is an IOAM specific identifier, reports subscription information related To the first gateway device for realizing flow-following detection To the controller by utilizing Bitmap information of an IOAM header in the detection message, and performs a 1 subtracting operation on a Time To Live (TTL) value in the detection message;

and when the next hop is queried and an interface is forwarded, the Protocol field value of the IOAM head in the detection message and the offset value corresponding to the IOAM head are utilized to acquire port number information for ECMP calculation.

In some embodiments, the tail node is directly connected to the destination host, and the method further comprises:

forwarding the detection message to the tail node by using the first gateway equipment;

the tail node uses Bitmap information of an IOAM header in the detection message to report subscription information related to the tail node and used for realizing stream-following detection to the controller, and then writes back an original Protocol field value of a Reserved field in the IOAM header into a Protocol field of the detection message, and removes the IOAM header in the detection message;

And the tail node sends the message for removing the IOAM header to the target host.

In some embodiments, in a case that a head node and a tail node corresponding to the VXLAN packet 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 a first gateway device, when removing a VXLAN message and an encapsulated IOAM header, the first gateway device stores the IOAM header and a TTL value in the detection message into a register, and reports subscription information which is related to the first gateway device and is used for realizing flow-following detection to the controller by utilizing Bitmap information of the IOAM header in the detection message;

when looking up a table and packaging a new VXLAN message, the first gateway device repackages the detection message by using the IOAM header obtained from the register, the TTL value after the subtracting 1 operation is performed, and the first VXLAN network identifier; the first VXLAN network identifier represents an identifier of a tenant virtual network corresponding to an output interface of the first gateway device;

and when the next hop is queried and an interface is forwarded, the Protocol field value of the IOAM head in the repackaged detection message and the offset value of the IOAM head are utilized to acquire port number information for ECMP calculation.

forwarding the repackaged detection message to the tail node by using the first gateway device;

the tail node uses Bitmap information of an IOAM header in the repackaged detection message to report subscription information related to the tail node and used for realizing stream-following detection to the controller, and then writes back an original Protocol field value of a Reserved field in the IOAM header to a Protocol field of the detection message, and removes the IOAM header in the repackaged detection message;

In some embodiments, in a case that the head node and the tail node corresponding to the VXLAN packet are respectively connected to different hosts in different data center networks, the method further includes:

When looking up a table and packaging a new VXLAN message, the first gateway equipment re-packages the detection message by using an IOAM header obtained from the register, a TTL value after performing 1 subtracting operation, a second VXLAN network identifier and a first value corresponding to a Flow ID field in the IOAM header; the first value represents a preset public flow identifier; the second VXLAN network identifier is used for uniquely identifying different tenant virtual network interworking corresponding routing domains among different data center networks and is used for realizing independent planning of network identifiers of different data center network tenants;

In some embodiments, the method further comprises:

when the first gateway device forwards the repackaged detection message to a public node, the public node reports subscription information which is related to the public node and is used for realizing flow-following detection to the controller by utilizing Bitmap information of an IOAM header in the repackaged detection message, and updates a TTL value in the repackaged detection message into a value after performing a 1 subtracting operation; the common node represents a node in the common VXLAN network;

In some embodiments, the method further comprises:

forwarding the repackaged detection message to a second gateway device by using the public node, when the VXLAN message and the encapsulated IOAM header are removed, storing the IOAM header and TTL value in the repackaged detection message into a register by the second gateway device, and reporting subscription information which is related to the second gateway device and is used for realizing stream-following detection to the controller by using Bitmap information of the IOAM header in the repackaged detection message;

when looking up a table and packaging a new VXLAN message, the second gateway device packages the detection message again by using the IOAM header obtained from the register, the TTL value after continuing to execute the subtracting 1 operation, the third VXLAN network identifier, and the second value corresponding to the Flow ID field in the IOAM header; the third VXLAN network identifier represents an identifier of a tenant virtual network corresponding to the second gateway device output interface; the second value is used for representing a flow identifier corresponding to the data center network to which the second gateway device belongs.

forwarding the repackaged detection message to the tail node by using the second gateway equipment;

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

The present application provides a message processing system, comprising a head node, wherein,

the head node is used for receiving configuration information issued by the controller, and determining Flow ID and Bitmap information required when the IOAM head is generated according to the configuration information; the configuration information is generated according to the stream following detection requirement issued by the cloud platform, the configuration information comprises quintuple information, and the head node is directly connected with a source host corresponding to the quintuple information;

When the header node is used for completing table lookup and packaging a VXLAN message, if the quintuple information is matched with an inner layer message quintuple corresponding to the VXLAN message, packaging an IOAM header generated according to the Flow ID and Bitmap information in the VXLAN message, copying an original Protocol field value of the VXLAN message into a Reserved field of the IOAM header, and modifying the Protocol field value of the VXLAN message into an IOAM specific identifier to obtain a detection message;

the head node is configured to report subscription information related to the head node for implementing flow-following detection to the controller by using Bitmap information of an IOAM header in the detection packet, and forward the detection packet to a next node.

The application provides a message processing method and a message processing system, wherein the method comprises the following steps: the head node receives configuration information issued by the controller, and determines Flow ID and Bitmap information required when the IOAM head is generated according to the configuration information; the configuration information is generated according to the stream following detection requirement issued by the cloud platform, the configuration information comprises quintuple information, and the head node is directly connected with a source host corresponding to the quintuple information; when the header node completes table lookup and encapsulates a VXLAN message, if the quintuple information is matched with an inner layer message quintuple corresponding to the VXLAN message, encapsulating an IOAM header generated according to the Flow ID and Bitmap information in the VXLAN message, copying an original Protocol field value of the VXLAN message into a Reserved field of the IOAM header, and modifying the Protocol field value of the VXLAN message into an IOAM specific identifier to obtain a detection message; and the head node reports subscription information which is related to the head node and is used for realizing the detection along with the flow to the controller by utilizing the Bitmap information of the IOAM head in the detection message, and forwards the detection message to the next node.

As can be seen, in the embodiment of the present application, when the IOAM header obtained according to the configuration information is encapsulated in the VXLAN packet, the content of the Protocol field in the VXLAN packet is copied to the Reserved field of the IOAM header, and the Protocol field of the VXLAN packet is modified to the IOAM specific identifier; in this way, when the forwarding interface of the detection message is determined later, ECMP calculation can be performed based on the Protocol field in the IOAM header, so that the consistency of the forwarding paths of the detection message and the VXLAN message can be ensured, the accuracy of data reporting is improved, and the operation and maintenance precision of the data center network is ensured; in addition, if the network device configures an access control list (Access Control Lists, ACL) rule, ACL matching can be performed based on a Protocol field in an IOAM header in the detection message, so that correct matching of the ACL rule is ensured, and network security risk caused by incorrect matching is reduced.

Drawings

FIG. 1A is a schematic diagram of a structure for performing concurrent detection according to an embodiment of the present application;

FIG. 1B is a flowchart of a message processing method according to an embodiment of the present application;

fig. 1C is a schematic diagram of encapsulating an IOAM header in a VXLAN message according to an embodiment of the present application;

fig. 1D is a schematic diagram of copying a Protocol field to an IOAM header according to an embodiment of the present application;

FIG. 1E is a schematic diagram of an IOAM header in a detection message according to an embodiment of the present application;

FIG. 1F is a schematic diagram of a detection message according to an embodiment of the present application;

FIG. 2A is a schematic diagram of a detection message passing through an underway device in an embodiment of the present application;

FIG. 2B is a schematic diagram of a detection message passing through a tail node according to an embodiment of the present application;

fig. 2C is a schematic diagram of a second detection message passing through a VXLAN gateway according to an embodiment of the present application;

fig. 2D is a schematic diagram of a detection message passing through a VXLAN gateway for a scene three in the embodiment of the present application;

fig. 3A is a schematic structural diagram of a message processing for a first scenario in an embodiment of the present application;

fig. 3B is a schematic structural diagram of a message processing for a second scenario in the embodiment of the present application;

fig. 3C is a schematic structural diagram of a message processing for a third scenario in the embodiment of the present application;

fig. 3D is a flowchart of another message processing method according to an embodiment of the present application.

Detailed Description

The technical solutions in the present application will be clearly and completely described below with reference to the drawings in the present application.

The present application will be described in further detail with reference to the accompanying drawings and examples. It should be understood that the examples provided herein are for the purpose of illustrating the present application only and are not intended to limit the present application. In addition, the embodiments provided below are some of the embodiments for carrying out the present application, and not all of the embodiments for carrying out the present application are provided, and the technical solutions described in the present application may be implemented in any combination without conflict.

It should be noted that, in this application, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a method or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such method or apparatus. Without further limitation, an element defined by the phrase "comprising one does not exclude the presence of other related elements in a method or apparatus comprising the element (e.g., a step in a method or an element in an apparatus, e.g., an element may be part of a processor, part of a program or software, etc.).

The term "and/or" is herein merely an association relationship describing an associated object, meaning that there may be three relationships, e.g., a and/or B, may represent: a exists alone, A and B exist together, and B exists alone. In addition, the term "at least one" herein means any one of a plurality or any combination of at least two of a plurality, for example, including at least one of A, B, C, and may mean including any one or more elements selected from the group consisting of A, B and C.

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 described steps, and similarly, the message processing apparatus provided in the present application includes a series of modules, but the message processing apparatus provided in the present application is not limited to include the explicitly described modules, and may also include modules that are required to be set for acquiring relevant information or performing processing based on the information.

The present application may be implemented on the basis of an electronic device, which here may be a thin client, thick client, handheld or laptop device, microprocessor-based system, set top box, programmable consumer electronics, network personal computer, small computer system, or the like.

The electronic device may implement the corresponding functions by execution of program modules. Generally, program modules may include routines, programs, objects, components, logic, data structures, and so forth. They perform specific tasks or implement specific abstract data types. The computer system may be implemented in a distributed cloud computing environment in which tasks are performed by remote processing devices that are linked through a communications network. In a distributed cloud computing environment, program modules may be located in both local and remote computing system storage media including memory storage devices.

Currently, a data center network comprehensively introduces a software defined network (Software Defined Network, SDN) technology to realize network automation, and VXLAN is taken as a tunneling technology of MAC-in-UDP, so that a large two-layer network capability of the data center can be constructed, the multi-tenant isolation requirement is met, and the method becomes a mainstream technology of the SDN data center.

Under the condition that the VXLAN is fully deployed in the data center network, there are three types of traffic that needs to be detected by end-to-end with flow, as shown in fig. 1A, fig. 1A is a schematic structural diagram of performing the detection by flow in the embodiment of the present application, where the structural diagram includes: a control plane and a networking forwarding plane; wherein the control plane comprises a cloud platform and three controllers (representing a POD1 controller to a POD3 controller); the networking forwarding plane comprises three data center networks and a public VXLAN network C-Spine, and each controller correspondingly manages the flow of one data center network; the data center network comprises VXLAN GateWay (GW) equipment, virtual expansion local area network tunnel endpoints (VXLAN Tunnel Endpoints, VTEP) and various hosts connected with the VTEP; illustratively, taking a data center network corresponding to the POD1 controller as an example, the data center network includes VXLAN GW devices, VTEP1, VTEP2, VPC1-host1 (host 1) connected to the VTEP1, and VPC1-host2 (host 2) and VPC2-host3 (host 3) connected to the VTEP 2; wherein VPC1-host1 (host 1) and VPC1-host2 (host 2) represent different hosts on 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.

Here, each type of flow that needs to be detected end-to-end along with the flow may correspond to one scene; wherein, scene one is: different hosts on the same VPC within the same data center network interwork, e.g., VPC1-host1 (host 1) and VPC1-host2 (host 2) within the data center network to which the POD1 controller corresponds interwork, as shown by the bold solid lines in fig. 1A; the second scene is: different hosts on different VPCs within the same data center network interwork, e.g., VPC1-host1 (host 1) and VPC1-host3 (host 3) within the data center network to which the POD1 controller corresponds interwork, as shown by the dashed lines in fig. 1A; the third scene is: different hosts within different data center networks interwork, e.g., VPC1-host1 (host 1) within the data center network corresponding to the POD1 controller interwork with VPC1-host4 (host 4) within the data center network corresponding to the POD2 controller, as shown by the un-bolded solid line in fig. 1A.

In the related art, when the end-to-end flow detection is performed for the three scenes, the Protocol field of the original message is replaced by a specific value of the detected message, so that the matching cannot be performed based on the Protocol field of the original message when the ECMP is determined to be calculated by the message forwarding interface, the accuracy of the forwarding path of the detected message cannot be ensured, and the operation and maintenance precision of the data center network is reduced.

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

Fig. 1B is a flowchart of a message processing method according to an embodiment of the present application, as shown in fig. 1B, where the flowchart may include:

step 100: the head node receives configuration information issued by the controller, and determines Flow ID and Bitmap information required when the IOAM head is generated according to the configuration information; the configuration information is generated according to the stream following detection requirement issued by the cloud platform, the configuration information comprises quintuple information, and the head node is directly connected with a source host corresponding to the quintuple information.

Here, the cloud platform refers to a service based on hardware resources and software resources, and can provide computing, networking and storage capabilities; for example, the cloud platform may be connected to one or more controllers, where the controllers may be SDN controllers corresponding to one of the PODs.

In the embodiment of the application, the cloud platform can configure the flow-following detection requirement based on quintuple information according to the actual service requirement, and send the flow-following detection requirement to the corresponding controller; the controller configures corresponding configuration information according to the received flow-following detection requirement, and issues the configuration information to the corresponding network equipment.

Illustratively, the configuration information may include five-tuple information; the five-tuple information comprises 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 that issued the configuration information according to the five-tuple information in the configuration information.

Here, the network device corresponds to the head node; the header node represents a source VTEP directly connected to the source host corresponding to the quintuple information in the configuration information issued by the controller, so that the source VTEP may receive the configuration information issued by the controller. Illustratively, the source host may be connected with one or more virtual machines, each of which may be available to a respective tenant. The source VTEP may include, among other things, a software vSwitch switch or a hardware access switch.

Specifically, the VTEP is a device capable of encapsulating and decapsulating an original message in the VXLAN protocol, and may be implemented by a hardware device or may be implemented by software; the source VTEP may be configured to perform VXLAN encapsulation on the received original packet.

Illustratively, the Flow ID and Bitmap information may also be determined according to the configuration information, where the Flow ID and Bitmap information are used for subsequent generation of the IOAM header; for the three scenarios shown in fig. 1A, the values corresponding to the Flow ID fields (i.e., flow IDs) are different, and the values of the Flow ID fields are configured by the controllers corresponding to the data center network; because the data center networks corresponding to the first scene and the second scene are the same, the Flow ID fields in the two scenes are corresponding to the same value, and the value is different from the value corresponding to the Flow ID field in the third scene; for example, in the case where the value corresponding to the Flow ID field in the first scenario and the second scenario is 2000, the value corresponding to the Flow ID field in the third scenario may be 4000.

The Flow ID fields in scenario one and scenario two each correspond to the same value, illustrating that the traffic between end-to-end comes from the same data center network; the Flow ID field in the third scene corresponds to another value, which indicates that the Flow between the end to end is from different data center networks; here, end-to-end means head node to tail node.

In the embodiment of the present application, after the head node receives the configuration information sent by the controller, the IOAM head may be obtained according to the Flow ID field and the Bitmap information (i.e., the Bitmap field content) 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; the type and corresponding definition of each bit in the Bitmap field in the IOAM header is listed below by table 1.

TABLE 1

Illustratively, as can be seen from table 1, the device ID, packet loss, ingress and egress port time stamp, and other related information of the head node can be obtained according to the Bitmap information in the IOAM header.

Step 101: when the header node finishes looking up a table and encapsulates the VXLAN message, if the quintuple information matches an inner layer message quintuple corresponding to the VXLAN message, encapsulating an IOAM header generated according to the Flow ID and Bitmap information in the VXLAN message, copying an original Protocol field value of the VXLAN message into a Reserved field of the IOAM header, and modifying the Protocol field value of the VXLAN message into an IOAM specific identifier to obtain a detection message.

In one embodiment, the source host sends out an Original message (i.e., an inner layer message), where the Original message represents a message that is not VXLAN encapsulated, and the message may be an Original ethernet Frame (Original L2 Frame); in the embodiment of the present application, the table lookup table is used to query the route forwarding table, so as to determine a forwarding interface for forwarding the message to the next node.

After the original message reaches the head node, whether the original message needs to be subjected to flow following detection or not is determined by matching ACL rules, if so, a routing forwarding table is queried to determine the next node (namely the next hop); specifically, the head node may perform ECMP calculation based on the Protocol field value of the original packet and the corresponding quintuple information (i.e., the inner layer packet quintuple); here, the ECMP calculation is performed to determine a preferred path from among a plurality of paths from the head node to the next node, and further, determine a forwarding egress interface corresponding to the head node from the routing forwarding table based on the preferred path; at this point, the head node completes the lookup table.

Further, after the head node completes the table lookup, performing VXLAN encapsulation on the original message to obtain a VXLAN message; illustratively, for the process of obtaining VXLAN messages, it may be: the method comprises the steps of firstly encapsulating a VXLAN Header (VXLAN Header) on the basis of an original message, and then encapsulating the whole VXLAN frame in a user datagram protocol (User Datagram Protocol, UDP) message in a physical network, followed by an IP packet Header and a media access control (Media Access Control Header, MAC Header). To distinguish from the original ethernet frame (original message) inside, the Outer encapsulation is all plus an Outer UDP header (Outer UDP), an Outer IP header (Outer IP), and an Outer MAC header (Outer MAC).

Illustratively, the header node obtains the VXLAN message, and encapsulates the IOAM header obtained according to step 100 in the VXLAN message, specifically, inserts the IOAM header between the L3 and L4 port numbers of the outer layer IP header; next, description will be given with reference to fig. 1C; fig. 1C is a schematic diagram of encapsulating an IOAM Header in a VXLAN packet according to an embodiment of the present application, as shown in fig. 1C, in a VXLAN network, an IOAM Header (IOAM Header) is inserted between the L3 and L4 port numbers of an outer layer IP Header; here, L3 corresponds to the Outer IP in the figure, and L4 corresponds to the Outer UDP in the figure.

Illustratively, in the process of encapsulating the IOAM header in the VXLAN message, the Protocol field content of the VXLAN message is copied into the Reserved field of the IOAM header, as shown with reference to fig. 1D; the structure of the IOAM header after copying is shown in fig. 1E, where the Reserved field of the IOAM header has been replaced by the Protocol field of the VXLAN message (the original Protocol in the corresponding diagram).

Meanwhile, the Protocol field content of the outer layer IP in the VXLAN message is modified into an IOAM specific identifier, so that a detection message can be obtained; it can be seen that the two processes of copying the Protocol field content of the VXLAN message into the Reserved field of the IOAM header and modifying the Protocol field content of the outer IP in the VXLAN message into the IOAM specific identifier can be performed simultaneously; fig. 1F is a schematic diagram of a detection message according to an embodiment of the present application, as shown in fig. 1F, the Protocol field content of the outer layer IP (corresponding to the IPv4 Header in the figure) is modified to an IOAM specific identifier (corresponding to the original IOAM Protocol in the figure).

For example, after obtaining the detection message and defining the forwarding behavior of the message, the detection message may be forwarded to the next node based on the forwarding-out interface corresponding to the head node.

It can be seen that, in the embodiment of the present application, the content of the Protocol field in the VXLAN packet is copied to the Reserved field of the IOAM header, which can solve the problem that the Protocol and five-tuple information forwarding process detection packet based on the VXLAN packet may be inconsistent with the original packet forwarding path, and the problem that the ACL rule based on the original Protocol fails when the ACL rule is configured by the network device.

Step 102: the head node reports subscription information which is related to the head node and is used for realizing the detection along with the flow to the controller by utilizing the Bitmap information of the IOAM head in the detection message, and forwards the detection message to the next node.

In this embodiment, after obtaining the detection packet according to step 101, the head node may report subscription information related to the head node to a controller or an operation and maintenance platform corresponding to the data center network to which the head node belongs, using Bitmap information (specific meaning is shown in table 1) of an IOAM header in the detection packet. Meanwhile, the head node forwards the detection message to the next node; here, the next node may be a gateway device in the data center network.

Illustratively, the subscription information related to the head node includes at least one parameter information of an access port, a time stamp, and a time delay in addition to the device ID and the Flow ID of the head node.

Here, the controller or the operation and maintenance platform subscribes the parameter information of each network device in the data center network in advance, after the controller obtains the subscription information corresponding to the reporting of the head node, the subscription information is analyzed and processed, and the quality condition of the current data center network is determined, so that the rapid fault perception and root cause positioning are realized, the network fine management is promoted, and the operation and maintenance precision of the data center network is improved.

The application provides a message processing method and a message processing system, wherein the method comprises the following steps: the head node receives configuration information issued by the controller, and determines Flow ID and Bitmap information required when the IOAM head is generated according to the configuration information; the configuration information is generated according to the stream following detection requirement issued by the cloud platform, the configuration information comprises quintuple information, and the head node is directly connected with a source host corresponding to the quintuple information; when the header node finishes looking up a table and encapsulates the VXLAN message, if the quintuple information is matched with an inner layer message quintuple corresponding to the VXLAN message, encapsulating an IOAM header generated according to the Flow ID and Bitmap information in the VXLAN message, copying an original Protocol field value of the VXLAN message into a Reserved field of the IOAM header, and modifying the Protocol field value of the VXLAN message into an IOAM specific identifier to obtain a detection message; the head node reports subscription information which is related to the head node and is used for realizing the detection along with the flow to the controller by utilizing the Bitmap information of the IOAM head in the detection message, and forwards the detection message to the next node. As can be seen, in the embodiment of the present application, when the IOAM header obtained according to the configuration information is encapsulated in the VXLAN packet, the content of the Protocol field in the VXLAN packet is copied to the Reserved field of the IOAM header, and the Protocol field of the VXLAN packet is modified to the IOAM specific identifier; in this way, when the forwarding interface of the detection message is determined later, ECMP calculation can be performed based on the Protocol field in the IOAM header, so that the consistency of the forwarding paths of the detection message and the VXLAN message can be ensured, the accuracy of data reporting is improved, and the operation and maintenance precision of the data center network is ensured; in addition, if the network device configures the ACL rule, ACL matching can be performed based on the Protocol field in the IOAM header in the detection message, so that correct matching of the ACL rule is ensured, and network security risk caused by incorrect matching is reduced.

In some embodiments, in a case where a head node and a tail node corresponding to the VXLAN packet are respectively connected to different hosts on the same tenant virtual network in the same data center network (corresponding to scenario one), the method may further include: after the head node forwards the detection message to the first gateway device, the first gateway device recognizes the Protocol field value as the IOAM specific identifier, reports subscription information which is related to the first gateway device and is used for realizing the detection along with the flow to the controller by utilizing Bitmap information of the IOAM head in the detection message, and carries out 1 reduction operation on the time-to-live TTL value in the detection message; and when the next hop is queried and the interface is forwarded, the Protocol field value of the IOAM head in the detection message and the offset value corresponding to the IOAM head are utilized to acquire port number information for ECMP calculation.

In the embodiment of the application, the tail node is directly connected with the target host, and the tail node represents a target VTEP directly connected with the target host; the first gateway device represents a gateway device in a data center network to which the head node belongs.

Here, the port number information may be a TCP or UDP port number; the forwarding interface represents a forwarding interface corresponding to the first gateway device, and represents a physical interface; the next hop indicates the next node (the next network device), i.e. the detection message needs to be forwarded from the forwarding-out interface corresponding to the first gateway device to the next network device.

For example, for scenario one, the process of inquiring the next hop and forwarding out the interface by the first gateway device is described, after 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 may be used to obtain port number information for ECMP, where the ECMP calculation is performed to determine a preferred path from multiple paths between the first gateway device and the next node (i.e. the next hop), and further determine, based on the preferred path, the forwarding out interface corresponding to the first gateway device from the routing forwarding table; at this time, the first gateway device completes the next hop and forwards out the query of the interface.

And then, when the first gateway equipment needs to forward the detection message, the detection message can be forwarded to the next node based on the forwarding-out interface corresponding to the first gateway equipment.

For instance, for scenario one, the first gateway device is not a VTEP, but an underway device. Firstly, determining whether a detection message is an IOAM type message or not based on the Protocol field content of an outer layer IP in the detection message; when the message is determined to be a common IP message, ECMP calculation and ACL matching are carried out based on a Protocol field and a TCP or UDP port number in an IP header of the message; otherwise, when the detected message is determined to be an IOAM type message (namely, the content of a Protocol field is an IOAM specific identifier), the first gateway device reports subscription information which is related to the first gateway device and is used for realizing the detection along with the flow to the controller according to Bitmap information of an IOAM header in the message. Meanwhile, performing 1 subtracting operation on TTL values in the detection messages; and when the next hop is queried and the interface is forwarded out, the port number of the TCP or UDP is obtained based on the content of a Protocol field in the IOAM header and the offset value (offset value of 4 bytes of IOAM header length) corresponding to the IOAM header, and then ECMP calculation and ACL matching are carried out according to the port number, and specific message processing is shown in fig. 2A, it can be seen that when the message does not pass through an underway device (first gateway device), the TTL value in the detected message is 100, and when the message passes through the underway device, the TTL value in the detected message is 99.

Further, the method may further include: forwarding the detection message to the tail node by using the first gateway equipment; the tail node reports subscription information related to the tail node and used for realizing stream following detection to the controller by utilizing Bitmap information of the IOAM header in the detection message, and then writes back an original Protocol field value of a Reserved field in the IOAM header into a Protocol field of the detection message, and removes the IOAM header in the detection message; and the tail node sends the message with the IOAM header removed to the target host.

Illustratively, the destination host represents a target host that establishes communication with the source host; after the detection message reaches the tail node, according to Bitmap information of the IOAM head in the message, reporting subscription information related to the tail node for realizing stream-following detection, and copying the IOAM head and TTL value into a register; the detection message is unpacked, where unpacking the detection message may include: writing the original Protocol field value of the Reserved field in the IOAM header back to the Protocol field of the message, dismantling the IOAM header in the detection message and performing VXLAN (virtual extensible local area network) decapsulation to obtain the original message; finally, the tail node sends the original message to the target host; specific message processing as shown in fig. 2B, it can be seen that after passing through the target VTEP (tail node), the detection message is decapsulated into the original message.

Illustratively, because the tail node is directly connected to the destination host, the IOMA header and TTL values in the registers may be cleared.

Illustratively, the subscription information related to the tail node includes at least one parameter information of an access port, a time stamp and a time delay in addition to the device ID and the Flow ID of the tail node.

In some embodiments, in a case where a head node and a tail node corresponding to the VXLAN packet are respectively connected to different hosts on different tenant virtual networks in the same data center network (corresponding to scenario two), the method may further include: after the head node forwards the detection message to the first gateway equipment, when the VXLAN message and the encapsulated IOAM header are removed, the first gateway equipment stores the IOAM header and TTL value in the detection message into a register, and reports subscription information which is related to the first gateway equipment and is used for realizing stream-following detection to the controller by utilizing Bitmap information of the IOAM header in the detection message; when looking up a table and packaging a new VXLAN message, the first gateway equipment re-packages the detection message by using the IOAM header obtained from the register, the TTL value after the 1 reduction operation is executed and the first VXLAN network identifier; and when the next hop is queried and the interface is forwarded, the Protocol field value of the IOAM header and the offset value of the IOAM header in the repackaged detection message are utilized to acquire port number information for ECMP calculation. Here, the purpose of the lookup table is to determine a forwarding egress interface for the first gateway device to forward the message to the next node in the case of scenario two.

Here, the first VXLAN network identifier (VXLAN Network Identifier, VNI) represents an identifier of the tenant virtual network corresponding to the first gateway device outgoing interface, specifically corresponds to the VNI in the VXLAN header; for the second scene, the VNI value corresponding to the first gateway device inlet interface is different from the VNI value corresponding to the first gateway device outlet interface; for example, referring to the dashed line in fig. 1A, the VNI value corresponding to the first gateway device ingress interface is 1, and the VNI value corresponding to the first gateway device egress interface is 2.

Illustratively, for scenario two, the first gateway device is a VTEP; firstly, determining whether a detection message is an IOAM type message or not based on the Protocol field content of an outer layer IP in the detection message; when the message is determined to be a common IP message, ECMP calculation and ACL matching are carried out based on a Protocol field and a TCP or UDP port number in an IP header of the message; otherwise, determining that the detection message is of an IOAM type (namely, the content of a Protocol field is an IOAM specific identifier), copying the IOAM header and a TTL value into a register by the first gateway device when the VXLAN message and the encapsulated IOAM header are removed, and reporting subscription information which is related to the first gateway device and is used for realizing the detection along with the flow to a controller according to Bitmap information of the IOAM header in the message; at this time, the VNI value in the VXLAN packet is the VNI value corresponding to the first gateway device ingress interface.

Then, when looking up a table and packaging a new VXLAN message, re-packaging the detection message by using the IOAM head obtained from the register, the TTL value after performing the subtracting 1 operation and the first VXLAN network identifier (VNI value corresponding to the tail node), wherein the VNI value in the VXLAN message is the VNI value corresponding to the output interface of the first gateway device; and when the next hop is queried and the interface is forwarded out, the port number of the TCP or UDP is obtained based on the content of the Protocol field in the IOAM header and the offset value (offset value of 4 bytes of IOAM header length) corresponding to the IOAM header, and then ECMP calculation and ACL matching are performed according to the port number, and specific message processing is shown in fig. 2C, it can be seen that when the VXLAN gateway (first gateway device) is not passed, the TTL value in the detection message is 100, the VNI value is 11111, and after the VXLAN gateway (first gateway device) is passed, the TTL value in the repackaged detection message is 99, and the VNI value is 22222.

For example, for scenario two, the process of querying the next hop and forwarding out the interface by the first gateway device is similar to scenario one, and will not be described here again.

Further, the method may further include: forwarding the repackaged detection message to the tail node by using the first gateway equipment; the tail node uses the Bitmap information of the IOAM header in the repackaged detection message to report subscription information related to the tail node and used for realizing stream-following 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 repackaged detection message; and the tail node sends the message with the IOAM header removed to the target host.

Here, the implementation manner of the repackaged detection packet after reaching the tail node is similar to the implementation manner of the detection packet after reaching the tail node in the first scenario, and will not be repeated herein.

In some embodiments, in a case where the head node and the tail node corresponding to the VXLAN packet are respectively connected to different hosts in different data center networks (corresponding to scenario three), the method may further include: after the head node forwards the detection message to the first gateway equipment, when the VXLAN message and the encapsulated IOAM header are removed, the first gateway equipment stores the IOAM header and TTL value in the detection message into a register, and reports subscription information which is related to the first gateway equipment and is used for realizing stream-following detection to the controller by utilizing Bitmap information of the IOAM header in the detection message; when looking up a table and packaging a new VXLAN message, the first gateway equipment re-packages the detection message by using the IOAM header obtained from the register, the TTL value after the 1 subtracting operation is executed, 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; and when the next hop is queried and the interface is forwarded, the Protocol field value of the IOAM header and the offset value of the IOAM header in the repackaged detection message are utilized to acquire port number information for ECMP calculation. Here, the purpose of the lookup table is to determine a forwarding egress interface for the first gateway device to forward the message to the next node in case of scenario three.

For instance, for scenario three, the process of querying the next hop and forwarding out the interface by the first gateway device is similar to scenario one, and will not be described here again.

Here, the second VXLAN network identifier is used to uniquely identify a routing domain corresponding to the interworking of different tenant virtual networks between different data center networks, so as to implement independent planning of network identifications of different data center network tenants.

Illustratively, for scenario three, the first gateway device is a VTEP; firstly, determining whether a detection message is an IOAM type message or not based on the Protocol field content of an outer layer IP in the detection message; when the message is determined to be a common IP message, ECMP calculation and ACL matching are carried out based on a Protocol field and a TCP or UDP port number in an IP header of the message; otherwise, determining that the detection message is of an IOAM type (namely, the content of a Protocol field is an IOAM specific identifier), copying the IOAM header and a TTL value into a register by the first gateway device when the VXLAN message and the encapsulated IOAM header are removed, and reporting subscription information which is related to the first gateway device and is used for realizing the detection along with the flow to a controller according to Bitmap information of the IOAM header in the message; at this time, the VNI value in the VXLAN packet is the VNI value corresponding to the first gateway device ingress interface, and the value corresponding to the Flow ID field is the value of the Flow ID field in the IOAM header in the first or second scenario, that is, the detected packet corresponds to the traffic of the same data center network.

Then, when looking up a table and packaging a new VXLAN message, re-packaging the detection message by using the IOAM header obtained from the register, the TTL value after the subtracting 1 operation is performed, the second VXLAN network identifier (VNI value corresponding to C-Spine) and the first value corresponding to the Flow ID field, where the VNI value in the VXLAN message is the second VXLAN network identifier, that is, the VNI value corresponding to C-Spine; and when the next hop is queried and the interface is forwarded out, based on the Protocol field content in the IOAM header and the offset value corresponding to the IOAM header (offset value of 4 bytes IOAM header length), the TCP or UDP port number is obtained, and further ECMP calculation and ACL matching are performed according to the port number, as shown in fig. 2D, the specific message processing is that, when the VXLAN gateway (first gateway device) is not passed, the TTL value in the detection message is 100, the vni value is 11111, the value of the Flow ID field is 2000, and after the VXLAN gateway (first gateway device) is passed, the TTL value in the repackaged detection message is 99, the vni value is 22222, and the value of the Flow ID field is 4000 (first value corresponding to the Flow ID field).

Further, the method may further include: when the first gateway equipment forwards the repackaged detection message to the public node, the public node reports subscription information which is related to the public node and is used for realizing flow-following detection to the controller by utilizing Bitmap information of an IOAM head in the repackaged detection message, and updates a TTL value in the repackaged detection message into a value after performing a 1 subtracting operation; the public node represents a node in the public VXLAN network; and when the next hop is queried and the interface is forwarded, the Protocol field value of the IOAM header and the offset value of the IOAM header in the repackaged detection message are utilized to acquire port number information for ECMP calculation.

For example, for scenario three, the process of inquiring the next hop and forwarding out the interface by the public node is described, 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 may be used to obtain port number information for ECMP, where the ECMP calculation is performed to determine a preferred path from multiple paths between the public node and the next node (i.e. the next hop), and further determine the forwarding out interface corresponding to the public node from the routing forwarding table based on the preferred path; at this time, the common node completes the next hop and forwards out the query of the interface.

And then, when the public node needs to forward the detection message, forwarding the detection message to the next node based on a forwarding-out interface corresponding to the public node.

Illustratively, the common node represents a node in the common VXLAN network, corresponding to C-Spine in fig. 1A. The processing manner of the detection message by the public node is similar to that of the detection message by the first gateway device in the first scenario, and is not described herein.

Illustratively, the subscription information related to the public node includes at least one parameter information of an access port, a time stamp, and a time delay in addition to the device ID and the Flow ID of the public node.

In some embodiments, the above method may further comprise: forwarding the repackaged detection message to a second gateway device by using a public node, when the VXLAN message and the encapsulated IOAM header are removed, saving the IOAM header and TTL value in the repackaged detection message to a register by the second gateway device, and reporting subscription information which is related to the second gateway device and is used for realizing stream-following detection to a controller by using Bitmap information of the IOAM header in the repackaged detection message; when looking up a table and packaging a new VXLAN message, the second gateway device packages the detection message again by using the IOAM header obtained from the register, the TTL value after continuing to execute the subtracting 1 operation, the third VXLAN network identifier, and the second value corresponding to the Flow ID field in the IOAM header. Here, the purpose of the lookup table is to determine a forwarding egress interface for the second gateway device to forward the message to the next node in case of scenario three.

Here, the third VXLAN network identifier represents an identifier of the tenant virtual network corresponding to the second gateway device outgoing interface; for example, referring to the un-bolded line in fig. 1A, the VNI value corresponding to the second gateway device ingress interface is 1, and the VNI value corresponding to the second gateway device egress interface is 3. The second value corresponding to the Flow ID field is used for representing a Flow identifier corresponding to a data center network to which the second gateway equipment belongs; that is, the second value of the Flow ID field in the IOAM header corresponds to the value of the Flow ID field in scenario one or scenario two, and referring to fig. 2d, the second value of the Flow ID field is 2000.

Illustratively, for scenario three, the second gateway device is a VTEP; the repackaged detection message is forwarded to a second gateway device, when the VXLAN message and the encapsulated IOAM header are removed, the second gateway device copies the IOAM header and TTL values into a register, and reports subscription information which is related to the second gateway device and is used for realizing flow-following detection to a controller according to a Bitmap field of the IOAM header in the message, and then the IOAM header in the detection message is removed; at this time, the VNI value in the detection packet is the VNI value corresponding to the common node.

Then, when looking up a table and packaging a new VXLAN message, packaging the detection message again by using the IOAM header obtained from the register, the TTL value after continuing to execute the subtracting 1 operation, a third VXLAN network identifier (VNI value corresponding to the second gateway equipment outlet interface) and a second value corresponding to the Flow ID field; and repackaging the detection message by using the IOAM header obtained from the register, the TTL value after the subtracting 1 operation is executed, a second VXLAN network identifier (VNI value corresponding to C-Spine) and a second value corresponding to the Flow ID field.

Illustratively, the subscription information related to the second gateway device may include at least one parameter information of an access port, a time stamp, and a time delay in addition to the device ID and the Flow ID of the second gateway device.

In some embodiments, the above method may further comprise: forwarding the repackaged detection message to the tail node by using the second gateway equipment; the tail node uses the Bitmap information of the IOAM header in the repackaged detection message to report subscription information related to the tail node for realizing stream-following 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 repackaged detection message; and the tail node sends the message with the IOAM header removed to the target host.

Here, the implementation manner of the repackaged detection packet after reaching the tail node is similar to the implementation manner of the detection packet after reaching the tail node in the first scenario, and will not be repeated here.

Further description will be made on the basis of the above embodiments of the present application in order to more embody the objects of the present application.

Fig. 3A is a schematic structural diagram of a packet processing for a first scenario in the embodiment of the present application, as shown in fig. 3A, first, an original packet passes through VTEP1 (header node), VXLAN encapsulation is performed on the original packet on the node to obtain a VXLAN packet, and an IOAM header is encapsulated in the VXLAN packet to obtain a detection packet, where a VNI value in the detection packet is 1 (VPC 1 is an L3 VNI value of the present data center network), and then the detection packet is forwarded to VXLAN GW (first gateway device).

When the detection message arrives at the VXLAN GW (which is an Underlay device), the VXLAN GW reports subscription information which is related to the VXLAN GW and is used for realizing the detection along with the flow to the controller according to the Bitmap field of the IOAM header in the message. Meanwhile, performing 1 subtracting operation on TTL values in the detection messages; and when the next hop is queried and the interface is forwarded out, a TCP or UDP port number is obtained based on the content of a Protocol field in the IOAM header and an offset value corresponding to the IOAM header (an offset value of 4 bytes of IOAM header length), and then ECMP calculation and ACL matching are carried out according to the port number.

When the detection message reaches VTEP2 (tail node), the VTEP2 reports subscription information related to the VTEP2 for realizing stream-following detection according to the Bitmap field of the IOAM header in the message, and copies the IOAM header and TTL value into a register; then, the detected message is unpacked to obtain an original message, and finally, the original message is sent to a VPC1-host2 (destination host); because VTEP2 is directly connected to the destination host, the IOMA header and TTL values in the registers need to be cleared.

Fig. 3B is a schematic structural diagram of a packet processing for a second scenario in this embodiment, as shown in fig. 3B, first, an original packet goes through VTEP1 (header node), VXLAN encapsulation is performed on the original packet on the node to obtain a VXLAN packet, and an IOAM header is encapsulated in the VXLAN packet to obtain a detection packet, where a VNI value in the detection packet is 1 (VPC 1 is an L3 VNI value of the data center network), and then the detection packet is forwarded to VXLAN GW (first gateway device).

When determining that the detection message reaches the VXLAN GW (VTEP), the VXLAN GW copies the IOAM header and the TTL value into a register, reports subscription information which is related to the VXLAN GW and is used for realizing the detection along with the flow to a controller according to a Bitmap field of the IOAM header in the message, and then removes the IOAM header in the detection message. The original IOMA header and TTL value are repackaged in the VXLAN message, meanwhile, the VNI value is changed into 2 (the L3 VNI value of the VPC2 in the data center network), when the next hop is inquired and the interface is forwarded out, the TCP or UDP port number is obtained based on the content of the Protocol field in the IOAM header and the offset value (the offset value of the length of the 4-byte IOAM header) corresponding to the IOAM header, and then ECMP calculation and ACL matching are carried out according to the port number.

When the detection message reaches VTEP2 (tail node), the VTEP2 reports subscription information related to the VTEP2 for realizing stream-following detection according to the Bitmap field of the IOAM header in the message, and copies the IOAM header and TTL value into a register; then, the detected message is unpacked to obtain an original message, and finally, the original message is sent to a VPC2-host3 (destination host); because VTEP2 is directly connected to the destination host, the IOMA header and TTL values in the registers need to be cleared.

Fig. 3C is a schematic structural diagram of a packet processing for a third scenario in this embodiment, as shown in fig. 3C, first, an original packet passes through a VTEP1 node (header node), and VXLAN packets are performed on the original packet on the node to obtain a VXLAN packet, and an IOAM header is encapsulated in the VXLAN packet to obtain a detection packet, where a VNI value in the detection packet is 1 (VPC 1 is an L3 VNI value of the present data center network), and then the detection packet is forwarded to a VXLAN GW (first gateway device).

When determining that the detection message reaches the VXLAN GW1 (VTEP), the VXLAN GW copies the IOAM header and the TTL value to the register, and reports subscription information for realizing flow-following detection related to the VXLAN GW to the controller according to the Bitmap field of the IOAM header in the message, and then removes the IOAM header in the detection message. Repackaging the original IOMA header and TTL value in the VXLAN message, changing the VNI value into 4 (VNI value corresponding to C-Spine) according to VNI Mapping, and replacing the original value (second value corresponding to the Flow ID field) corresponding to the Flow ID field in the POD with the value (first value corresponding to the Flow ID field) corresponding to the Flow ID field between the PODs based on the Flow ID Mapping table configured by the controller; and when the next hop is queried and the interface is forwarded out, a TCP or UDP port number is obtained based on the content of a Protocol field in the IOAM header and an offset value corresponding to the IOAM header (an offset value of 4 bytes of IOAM header length), and then ECMP calculation and ACL matching are carried out according to the port number.

When the detection message reaches the C-spin (not the VTEP), the C-spin reports subscription information related to the VXLAN GW for realizing the detection along with the flow to the controller according to the Bitmap field of the IOAM header in the message. Meanwhile, performing 1 subtracting operation on TTL values in the detection messages; and when the next hop is queried and the interface is forwarded out, a TCP or UDP port number is obtained based on the content of a Protocol field in the IOAM header and an offset value corresponding to the IOAM header (an offset value of 4 bytes of IOAM header length), and then ECMP calculation and ACL matching are carried out according to the port number.

When the detection message arrives at the VXLAN GW2 (second gateway device), the VXLAN GW copies the IOAM header and the TTL value to the register, and reports subscription information for implementing the flow-following detection related to the VXLAN GW to the controller according to the Bitmap field of the IOAM header in the message, and then removes the IOAM header in the detection message. Repackaging the original IOMA header and TTL value in the VXLAN message, and changing the VNI value to 3 (the L3 VNI value of VPC3 in the data center network); replacing the value of the Flow ID field (the first value corresponding to the Flow ID field) with the value in the POD (the second value corresponding to the Flow ID field) based on a mapping table maintained by the local VXLAN gateway; furthermore, the distribution decoupling of Flow IDs among different PODs is realized while the detection of the end-to-end Flow is completed.

When the detection message reaches VTEP3 (tail node), the VTEP2 reports subscription information related to the VTEP2 for realizing stream-following detection according to the Bitmap field of the IOAM header in the message, and copies the IOAM header and TTL value into a register; then, the detected message is unpacked to obtain an original message, and finally, the original message is sent to a VPC3-host4 (destination host); because VTEP2 is directly connected to the destination host, the IOMA header and TTL values in the registers need to be cleared.

Fig. 3D is a flowchart of another method for processing a message according to an embodiment of the present application, as shown in fig. 1B, where the flowchart may include:

step A1: and judging whether the node is a head node or not.

After the message reaches a certain network device in the data center network, it needs to be judged whether the network device reached by the message is a head node, if so, step A2 is executed, otherwise, step A3 is executed.

Step A2: the IOAM header is encapsulated.

Illustratively, after the message reaches the head node, the message is described as the original message; at this time, performing VXLAN encapsulation on the original message to obtain a VXLAN message; and the IOAM header is encapsulated in the VXLAN message, and meanwhile, the Protocol field content of the VXLAN message is copied into the Reserved field of the IOAM header, so that ECMP calculation and ACL matching can be conveniently carried out subsequently.

Step A3: judging whether the VTEP is available.

Illustratively, in the case where the network device to which the message arrives is not the head node, the message is illustrated as a detection message; at this time, it is continuously determined whether the network device is a VTEP, if not, step A4 is performed, and if not, step A5 is performed.

Step A4: and performing first processing on the detection message.

For example, after the detection message reaches the non-VTEP (corresponding to the above C-Spine), the C-Spine uses the IOAM header in the detection message to report the corresponding subscription information to the controller, and updates the TTL value in the detection message to a value after the subtracting 1 operation is performed, and forwards the value.

Step A5: and judging whether the node is a tail node or not.

In an exemplary embodiment, if the network device that the detection packet arrives at is not a head node or a VTEP, the method continues to determine whether the network device is a tail node, if yes, step A6 is performed, and if not, step A7 is performed.

Step A6: and performing second processing on the detection message.

When the detection message reaches the tail node, the tail node reports corresponding subscription information according to the Bitmap field of the IOAM header in the message, and decapsulates the detection message to obtain an original message, and finally, forwards the original message to the target host.

Step A7: judging whether the flow is the flow in the POD.

In an exemplary embodiment, if the network device reached by the detection packet is not a head node, is not a VTEP, is not a tail node, it is determined whether the traffic corresponding to the detection packet is POD traffic, if yes, step A8 is executed, and if not, step A9 is executed. Here, the POD flow amount represents a flow amount within the same data center network; that is, it is determined whether or not the traffic corresponding to the detection packet is traffic in the same data center network.

Step A8: and performing third processing on the detection message.

For example, when the traffic corresponding to the detection packet is the traffic in the same data center network, namely, the traffic corresponds to the second scenario; 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, copies the IOAM header and the TTL value into the register, removes the IOAM header in the detection message, and checks and installs the interface clearly; at this time, if the value corresponding to the Flow ID field is determined to be null, the value corresponding to the Flow ID field does not need to be changed; and repackaging the original IOMA header and the TTL value in the VXLAN message.

Step A9: and carrying out fourth processing on the detection message.

For example, when the traffic corresponding to the detection packet is not the traffic in the same data center network, that is, the traffic corresponds to the third scenario; 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, copies the IOAM header and the TTL value into the register, removes the IOAM header in the detection message, and checks and installs the interface clearly; at this time, if it is determined that the value corresponding to the Flow ID field is not null, the value corresponding to the Flow ID field needs to be changed; and repackaging the original IOMA header and the TTL value in the VXLAN message.

It can be seen that in the embodiment of the present application, the content of the original Protocol field is backed up in the Reserved field of the IOAM header, so that the accuracy of the forwarding path of the detection message and the correct matching of the ACL policy are ensured; meanwhile, different values of Flow IDs are introduced for distinguishing a processing mechanism of traffic between data center networks and in the data center networks, so that allocation decoupling of the Flow IDs among different PODs is realized.

The present application also provides a message processing system, comprising a head node, wherein,

In some embodiments, the system further comprises a first gateway device in case 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, wherein,

after the head node forwards the detection message to a first gateway device, the first gateway device is configured to identify that the Protocol field value is an IOAM specific identifier, report subscription information related to the first gateway device for implementing flow-following detection to the controller by using Bitmap information of an IOAM header in the detection message, and perform a 1 reduction operation on a time-to-live TTL value in the detection message;

And the first gateway device is used for acquiring port number information by using a Protocol field value of an IOAM head in the detection message and an offset value corresponding to the IOAM head to perform equal-cost multipath ECMP calculation when inquiring a next hop and forwarding an interface.

Further, the system also comprises a tail node, which is directly connected with the destination host, wherein,

the tail node is configured to, using Bitmap information of an IOAM header in the detection packet, report subscription information related to the tail node for implementing stream-following detection to the controller, and write back an original Protocol field value of a Reserved field in the IOAM header to a Protocol field of the detection packet, and tear down the IOAM header in the detection packet;

and the tail node is used for sending the message for removing the IOAM header to the target host.

In some embodiments, the system further comprises a first gateway device in the case where 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, wherein,

after the header node forwards the detection message to a first gateway device, when removing a VXLAN message and an encapsulated IOAM header, the first gateway device is used for storing the IOAM header and a TTL value in the detection message into a register, and using Bitmap information of the IOAM header in the detection message to report subscription information related to the first gateway device for realizing stream-following detection to the controller;

When looking up a table and packaging a new VXLAN message, the first gateway device is configured to repackage the detection message by using the IOAM header obtained from the register, the TTL value after the subtracting 1 operation is performed, and the first VXLAN network identifier; the first VXLAN network identifier represents an identifier of a tenant virtual network corresponding to an output interface of the first gateway device;

and the first gateway device is used for acquiring port number information by using a Protocol field value of the IOAM head in the repackaged detection message and an offset value of the IOAM head to perform ECMP calculation when inquiring the next hop and forwarding out an interface.

the tail node is configured to report subscription information related to the tail node for implementing stream-following detection to the controller by using Bitmap information of an IOAM header in the repackaged detection packet, and write back an original Protocol field value of a Reserved field in the IOAM header to a Protocol field of the detection packet, so as to tear down the IOAM header in the repackaged detection packet;

In some embodiments, the system further comprises a first gateway device in the case where the head node and the tail node corresponding to the VXLAN message are respectively connected to different hosts in different data center networks, wherein,

when looking up a table and packaging a new VXLAN message, the first gateway device is configured to repackage the detection message by using an IOAM header obtained from the register, a TTL value after performing the subtracting 1 operation, a second VXLAN network identifier, and a first value corresponding to a Flow ID field in the IOAM header; the first value represents a preset public flow identifier; the second VXLAN network identifier is used for uniquely identifying different tenant virtual network interworking corresponding routing domains among different data center networks and is used for realizing independent planning of network identifiers of different data center network tenants;

Further, the system comprises a common node, wherein,

when the first gateway device forwards the repackaged detection message to a public node, the public node is configured to report subscription information related to the public node for implementing on-stream detection to the controller by using Bitmap information of an IOAM header in the repackaged detection message, and update a TTL value in the repackaged detection message to a value after performing a subtracting 1 operation; the common node represents a node in the common VXLAN network;

and the public node is used for acquiring port number information by using the Protocol field value of the IOAM head in the repackaged detection message and the offset value of the IOAM head to perform ECMP calculation when inquiring the next hop and forwarding out an interface.

Further, the system further comprises a second gateway device, wherein,

forwarding the repackaged detection message to a second gateway device by using the public node, wherein when the VXLAN message and the encapsulated IOAM header are removed, the second gateway device is used for storing the IOAM header and TTL value in the repackaged detection message into a register, and reporting subscription information which is related to the second gateway device and is used for realizing stream-following detection to the controller by using Bitmap information of the IOAM header in the repackaged detection message;

When the second gateway device is used for looking up a table and packaging a new VXLAN message, the second gateway device packages the detection message again by using the IOAM header obtained from the register, the TTL value after continuing to execute the subtracting 1 operation, the third VXLAN network identifier and the second value corresponding to the Flow ID field in the IOAM header; the third VXLAN network identifier represents an identifier of a tenant virtual network corresponding to the second gateway device output interface; the second value is used for representing a flow identifier corresponding to the data center network to which the second gateway device belongs.

the tail node is configured to, using Bitmap information of an IOAM header in the repackaged detection packet, report subscription information related to the tail node for implementing stream-following detection to the controller, and write back an original Protocol field value of a Reserved field in the IOAM header to a Protocol field of the detection packet, and tear down the IOAM header in the repackaged detection packet;

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

The foregoing description of various embodiments is intended to highlight differences between the various embodiments, which may be the same or similar to each other by reference, and is not repeated herein for the sake of brevity.

The methods disclosed in the method embodiments provided by the application can be arbitrarily combined under the condition of no conflict to obtain a new method embodiment.

The features disclosed in the embodiments of the products provided by the application can be arbitrarily combined under the condition of no conflict, so as to obtain new embodiments of the products.

The features disclosed in the embodiments of the method or the apparatus provided in the application may be arbitrarily combined without conflict to obtain a new embodiment of the method or the apparatus.

It will be appreciated by those skilled in the art that embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of a hardware embodiment, a software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, magnetic disk storage, optical storage, and the like) having computer-usable program code embodied therein.

The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the application. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

The foregoing is merely a preferred embodiment of the present application, and is not intended to limit the scope of the present application.

Claims

1. A method for processing a message, the method comprising:

the head node receives configuration information issued by the controller, and determines Flow ID and Bitmap information required when in-band operation management maintenance IOAM head is generated according to the configuration information; the configuration information is generated according to the stream following detection requirement issued by the cloud platform, the configuration information comprises quintuple information, and the head node is directly connected with a source host corresponding to the quintuple information;

when the head node completes table lookup and encapsulates a virtual extended local area network (VXLAN) message, if the quintuple information is matched with an inner layer message quintuple corresponding to the VXLAN message, encapsulating an IOAM header generated according to the Flow ID and Bitmap information in the VXLAN message, copying an original Protocol field value of the VXLAN message into a Reserved field of the IOAM header, and modifying the Protocol field value of the VXLAN message into an IOAM specific identifier to obtain a detection message;

2. The method of claim 1, wherein in a case where a head node and a tail node corresponding to the VXLAN message are respectively connected to different hosts on a same tenant virtual network in a same data center network, the method further comprises:

after the head node forwards the detection message to a first gateway device, the first gateway device recognizes that the Protocol field value is an IOAM specific identifier, reports subscription information related to the first gateway device and used for realizing flow-following detection to the controller by utilizing Bitmap information of an IOAM head in the detection message, and executes 1 subtracting operation on a time-to-live TTL value in the detection message;

and when the next hop is queried and an interface is forwarded, acquiring port number information by using a Protocol field value of an IOAM head in the detection message and an offset value corresponding to the IOAM head to perform equal-cost multipath ECMP calculation.

3. The method of claim 2, wherein the tail node is directly connected to the destination host, the method further comprising:

4. The method of claim 1, wherein in the case where a head node and a 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 comprises:

5. The method of claim 4, wherein the tail node is directly connected to the destination host, the method further comprising:

6. The method according to claim 1, wherein in case that 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 comprises:

7. The method of claim 6, wherein the method further comprises:

8. The method of claim 7, wherein the method further comprises:

9. The method of claim 8, wherein the tail node is directly connected to the destination host, the method further comprising:

10. The method of claim 1, wherein the subscription information includes a device identification number, ID, and a FlowID, of the head node.

11. The message processing system is characterized by comprising a head node, wherein the head node is used for receiving configuration information issued by a controller, and determining Flow ID and Bitmap information required when an IOAM head is generated according to the configuration information; the configuration information is generated according to the stream following detection requirement issued by the cloud platform, the configuration information comprises quintuple information, and the head node is directly connected with a source host corresponding to the quintuple information;