TCP service network state detection method based on OVN

Abstract

The invention provides a TCP service network state detection method based on an OVN. The method comprises the following steps: creating a first monitoring point in a direction in which a server virtual machine enters a logic switch; and configuring a first flow table rule in the first monitoring point. And determining a first flow table count of the first monitoring point based on the first flow table rule. And creating a second monitoring point in the direction in which the server virtual machine enters the logic switch. And configuring a second flow table rule in the second monitoring point. And determining a second flow table count of a second monitoring point based on the second flow table rule. And determining the connection state of the TCP service network according to the first flow table count and the second flow table count of the first monitoring point and the second monitoring point. According to the method provided by the invention, the connection state of the client and the server can be accurately judged.

Description

Technical Field

[0001] The present application relates to the field of data processing technology, and in particular to a TCP service network status detection method based on OVN. Background Art

[0002] With the continuous development of technology, the network has become an indispensable part of people's lives. In cloud networks, security groups are used to control traffic access and filtering. Usually, when a client accesses a server, the traffic is introduced into the Connection Tracking (CT) table of the Linux kernel or DPDK, and the rules of the security group are used to decide whether to allow the data packet to pass. However, there may be a large number of different clients accessing the server, and the security group rules may discard some traffic, which makes it impossible to accurately judge the connection status between the client and the server.

[0003] Therefore, how to accurately determine the connection status between the client and the server has become a technical problem that technical personnel in this field urgently need to solve. Summary of the invention

[0004] Based on the above problems, the present application provides a method for detecting the TCP service network status based on OVN, and the method comprises the following steps:

[0005] Create a first monitoring point in the direction where the server virtual machine enters the logical switch, the first monitoring point being used to monitor the synchronization sequence number packet and confirmation character packet of the TCP connection initiated from the client virtual machine;

[0006] configuring a first flow table rule in a first monitoring point, wherein the first flow table rule matches the synchronization sequence number packet and the confirmation character packet;

[0007] Determine a first flow table count of a first monitoring point based on the first flow table rule, where the first flow table count is used to determine whether the synchronization sequence number packet and the confirmation character packet pass through the logical switch;

[0008] Create a second monitoring point in the direction where the server virtual machine enters the logical switch, where the second monitoring point is used to monitor a reply packet sent by the server virtual machine to the client virtual machine;

[0009] configuring a second flow table rule in a second monitoring point, wherein the second flow table rule matches the reply packet;

[0010] determining a second flow table count of a second monitoring point based on the second flow table rule, where the second flow table count is used to determine whether the reply packet passes through the logical switch;

[0011] The connection status of the TCP service network is determined according to the first flow table count and the second flow table count of the first monitoring point and the second monitoring point.

[0012] In a possible implementation manner, the first flow table rule includes:

[0013] The matching source IP address is the IP address of the client virtual machine, the matching target IP address is the IP address of the server virtual machine, the matching target port is the port of the server virtual machine, and the matching TCP flag is the synchronization sequence number.

[0014] In a possible implementation, the second flow table rule includes:

[0015] The source IP address to be matched is the IP address of the client virtual machine, the target IP address to be matched is the IP address of the server virtual machine, the target port to be matched is the port of the server virtual machine, and the TCP flag to be matched is the confirmation character.

[0016] In a possible implementation manner, the first flow table count is specifically used to:

[0017] Determine whether the TCP connection initiated by the client VM successfully passes through the logical switch;

[0018] If the count of the first flow table is 0, it means that the synchronization sequence number packet or the confirmation character packet is discarded by the logical switch;

[0019] If the first flow table count is greater than 0, it means that the synchronization sequence number packet and the confirmation character packet successfully pass through the logical switch.

[0020] In a possible implementation manner, the second flow table count is specifically used to:

[0021] Determine whether the TCP connection replied by the server VM successfully passes through the logical switch;

[0022] If the second flow table count is 0, it means that the reply packet is discarded by the logical switch;

[0023] If the second flow table count is greater than 0, it means that the reply packet successfully passes through the logical switch.

[0024] In a possible implementation, the method further includes:

[0025] Based on the flow table counts of the first monitoring point and the second monitoring point, it is determined whether the TCP connection is blocked or lost by network intermediate devices such as the security group, and then the network connection status of the TCP service is determined.

[0026] The present application also provides a TCP service network status detection device based on OVN, the device comprising:

[0027] A first creation module is used to create a first monitoring point in the direction where the server virtual machine enters the logical switch, wherein the first monitoring point is used to monitor the synchronization sequence number packet and confirmation character packet of the TCP connection initiated from the client virtual machine;

[0028] A first configuration module, configured to configure a first flow table rule in a first monitoring point, wherein the first flow table rule matches the synchronization sequence number packet and the confirmation character packet;

[0029] A first determination module, configured to determine a first flow table count of a first monitoring point based on the first flow table rule, wherein the first flow table count is used to determine whether the synchronization sequence number packet and the confirmation character packet pass through a logical switch;

[0030] A second creation module is used to create a second monitoring point in the direction where the server virtual machine enters the logical switch, and the second monitoring point is used to monitor the reply packet of the server virtual machine to the client virtual machine;

[0031] A second configuration module, configured to configure a second flow table rule in a second monitoring point, wherein the second flow table rule matches the reply packet;

[0032] A second determination module determines a second flow table count of a second monitoring point based on the second flow table rule, where the second flow table count is used to determine whether the reply packet passes through the logical switch;

[0033] A judgment module, used to determine the connection status of the TCP service network according to the first flow table count and the second flow table count of the first monitoring point and the second monitoring point

[0034] The present application also provides an electronic device, the electronic device comprising a processor and a memory:

[0035] The memory is used to store a computer program and transmit the computer program to the processor;

[0036] The processor is used to execute the steps of the above-mentioned OVN-based TCP service network status detection method according to the instructions in the computer program.

[0037] The present application also provides a computer-readable storage medium, which is used to store a computer program. When the computer program is executed by an electronic device, the steps of the above-mentioned OVN-based TCP service network status detection method are implemented.

[0038] Compared with the prior art, this application has the following beneficial effects:

[0039] The present application proposes a TCP service network status detection method based on OVN, which effectively solves the problem that the connection status of the client and the server cannot be accurately judged in the prior art by setting a monitoring point between the server virtual machine and the logical switch and monitoring the traffic through the flow table rules. Specifically, the present application accurately monitors and judges the establishment process of the TCP connection by setting the first monitoring point and the second monitoring point in the inbound and outbound traffic directions of the server virtual machine, especially when the security group rules cause the traffic to be discarded, it can help identify the specific cause of the connection failure. Compared with the traditional processing method that only relies on the connection tracking table (CT table) and the security group, the solution of the present application can provide more accurate network status information through fine-grained traffic monitoring and counting. In particular, when there are a large number of different clients requesting the server, it is possible to clearly determine which link caused the connection failure by counting the traffic counts of different monitoring points, thereby helping to locate and solve network failures. In this way, the system can provide more reliable network status detection and fault diagnosis, avoiding problems caused by security groups discarding traffic. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0041] Figure 1 A flow chart of a TCP service network status detection method based on OVN provided in an embodiment of the present application;

[0042] Figure 2 A schematic diagram of the structure of an OVN-based TCP service network status detection device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0043] As described above, when a client accesses a server, the traffic is introduced into the Connection Tracking (CT) table of the Linux kernel or DPDK, and the security group rules are used to determine whether to allow the data packet to pass. However, there may be a large number of different clients accessing the server, and the security group rules may discard some traffic, which makes it impossible to accurately determine the connection status between the client and the server.

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

[0045] It is understandable that the method provided in the present application can be applied to a processing device, which is a processing device that can create a first monitoring point in the direction where the server-side virtual machine enters the logical switch, for example, a terminal device or server that can create a second monitoring point in the direction where the server-side virtual machine enters the logical switch. The method provided in the present application can be executed independently by a terminal device or a server, and can also be applied to a network scenario where a terminal device and a server communicate, and is executed by the cooperation of a terminal device and a server. Among them, the terminal device can be a computer, a mobile phone and other devices. The server can be understood as an application server or a Web server. In actual deployment, the server can be a standalone server or a cluster server.

[0046] Figure 1 A flow chart of a TCP service network status detection method based on OVN provided in this application, the method comprises the following steps:

[0047] S101: Create a first monitoring point in the direction where the server-side virtual machine enters the logical switch.

[0048] The processing device creates a first monitoring point in the direction where the server virtual machine enters the logical switch, and the first monitoring point is used to monitor the synchronization sequence number packet (SYN) and the confirmation character packet (ACK) of the TCP connection initiated from the client virtual machine.

[0049] The processing device first creates a first monitoring point in the direction where the server-side virtual machine enters the logical switch, which is used to monitor the synchronization sequence number packet (SYN packet) and confirmation character packet (ACK packet) of the TCP connection initiated from the client virtual machine. These packets are the core signs of TCP connection establishment. The SYN packet indicates a connection request, and the ACK packet indicates a connection confirmation.

[0050] S102: Configure a first flow table rule in a first monitoring point.

[0051] The processing device configures a first flow table rule in the first monitoring point, and the first flow table rule matches the synchronization sequence number packet and the confirmation character packet.

[0052] The processing device can match these two packets by configuring the first flow table rule at the monitoring point, wherein the first flow table rule may include: the source IP address is the IP address of the client virtual machine, the target IP address is the IP address of the server virtual machine, the target port is the port of the server virtual machine, and the TCP flag is matched as the synchronization sequence number (SYN) and the confirmation character (ACK). These matching rules enable the monitoring point to accurately identify and capture these key TCP packets.

[0053] S103: Determine a first flow table count of a first monitoring point based on a first flow table rule.

[0054] The processing device determines a first flow table count of a first monitoring point based on a first flow table rule, where the first flow table count is used to determine whether a synchronization sequence number packet and a confirmation character packet pass through the logical switch.

[0055] Based on the configured first flow table rules, the first flow table count will increase or remain at zero. The first flow table count is used to determine whether the synchronization sequence number packet and the confirmation character packet successfully pass through the logical switch. If the count is 0, it means that these packets failed to pass through the logical switch and may be discarded; if the count is greater than 0, it means that these packets successfully passed through the logical switch and the initial stage of the TCP connection (connection request and confirmation) is normal.

[0056] S104: Create a second monitoring point in the direction where the server-side virtual machine enters the logical switch.

[0057] The processing device creates a second monitoring point in the direction where the server virtual machine enters the logical switch, and the second monitoring point is used to monitor a reply packet sent by the server virtual machine to the client virtual machine.

[0058] In the direction of the server virtual machine, a second monitoring point is then created to monitor the TCP reply packets that the server virtual machine replies to the client virtual machine.

[0059] S105: Configure a second flow table rule in the second monitoring point.

[0060] The processing device configures a second flow table rule in the second monitoring point, and the second flow table rule matches the reply packet.

[0061] The processing device is configured with second flow table rules, which are used to match the reply packets sent by the server virtual machine. The second flow table rules may include: the source IP address is the IP address of the server virtual machine, the target IP address is the IP address of the client virtual machine, the target port is the port of the client virtual machine, and the matching TCP flag is SYN-ACK. Through these rules, the TCP connection reply packet from the server to the client can be accurately captured.

[0062] S106: Determine a second flow table count of a second monitoring point based on the second flow table rule.

[0063] The processing device determines a second flow table count of the second monitoring point based on the second flow table rule, where the second flow table count is used to determine whether the reply packet passes through the logical switch;

[0064] Based on the second flow table rule, the second flow table count will also increase or remain at zero. This count is used to determine whether the server VM reply packet successfully passes through the logical switch. If the count is 0, it means that the reply packet is discarded by the logical switch; if the count is greater than 0, it means that the reply packet successfully passes through the logical switch and the TCP connection establishment has been successfully returned.

[0065] S107: Determine the connection status of the TCP service network according to the first flow table count and the second flow table count of the first monitoring point and the second monitoring point.

[0066] The processing device determines the connection state of the TCP service network according to the first flow table count and the second flow table count of the first monitoring point and the second monitoring point.

[0067] The processing device can determine the network connection status of the entire TCP service by comprehensively analyzing the first flow table count and the second flow table count of the first monitoring point and the second monitoring point. For example, if the flow count in one direction is zero and the other directions are normal, it may mean that the flow in that direction is discarded or blocked, thereby affecting the success of the connection. This method can determine whether there is a network intermediate device (such as a security group, etc.) that blocks or loses the flow through the flow count of the monitoring point.

[0068] The present application proposes a TCP service network status detection method based on OVN, which effectively solves the problem that the connection status of the client and the server cannot be accurately judged in the prior art by setting a monitoring point between the server virtual machine and the logical switch and monitoring the traffic through the flow table rules. Specifically, the present application accurately monitors and judges the establishment process of the TCP connection by setting the first monitoring point and the second monitoring point in the inbound and outbound traffic directions of the server virtual machine, especially when the security group rules cause the traffic to be discarded, it can help identify the specific cause of the connection failure. Compared with the traditional processing method that only relies on the connection tracking table (CT table) and the security group, the solution of the present application can provide more accurate network status information through fine-grained traffic monitoring and counting. In particular, when there are a large number of different clients requesting the server, it is possible to clearly determine which link caused the connection failure by counting the traffic counts of different monitoring points, thereby helping to locate and solve network failures. In this way, the system can provide more reliable network status detection and fault diagnosis, avoiding problems caused by security groups discarding traffic.

[0069] The present application also provides a Figure 2 The schematic diagram of the structure of the device for detecting the TCP service network status based on OVN is shown, and the TCP service network status detection device 200 based on OVN includes:

[0070] A first creation module 201 is used to create a first monitoring point in the direction where the server virtual machine enters the logical switch, wherein the first monitoring point is used to monitor the synchronization sequence number packet and confirmation character packet of the TCP connection initiated from the client virtual machine;

[0071] A first configuration module 202, configured to configure a first flow table rule in a first monitoring point, wherein the first flow table rule matches the synchronization sequence number packet and the confirmation character packet;

[0072] A first determination module 203, configured to determine a first flow table count of a first monitoring point based on the first flow table rule, wherein the first flow table count is used to determine whether the synchronization sequence number packet and the confirmation character packet pass through a logical switch;

[0073] A second creation module 204 is used to create a second monitoring point in the direction where the server virtual machine enters the logical switch, and the second monitoring point is used to monitor the reply packet of the server virtual machine to the client virtual machine;

[0074] A second configuration module 205, configured to configure a second flow table rule in a second monitoring point, wherein the second flow table rule matches the reply packet;

[0075] A second determination module 206 determines a second flow table count of a second monitoring point based on the second flow table rule, where the second flow table count is used to determine whether the reply packet passes through the logical switch;

[0076] The judgment module 207 is used to determine the connection status of the TCP service network according to the first flow table count and the second flow table count of the first monitoring point and the second monitoring point.

[0077] The present application proposes a TCP service network status detection device based on OVN, which effectively solves the problem that the connection status of the client and the server cannot be accurately judged in the prior art by setting a monitoring point between the server virtual machine and the logical switch and monitoring the traffic through the flow table rules. Specifically, the present application accurately monitors and judges the establishment process of the TCP connection by setting the first monitoring point and the second monitoring point in the inbound and outbound traffic directions of the server virtual machine, especially when the security group rules cause the traffic to be discarded, it can help identify the specific cause of the connection failure. Compared with the traditional processing method that only relies on the connection tracking table (CT table) and the security group, the solution of the present application can provide more accurate network status information through fine-grained traffic monitoring and counting. In particular, when there are a large number of different clients requesting the server, it is possible to clearly determine which link caused the connection failure by counting the traffic counts of different monitoring points, thereby helping to locate and solve network failures. In this way, the system can provide more reliable network status detection and fault diagnosis, avoiding problems caused by the security group discarding traffic.

[0078] An embodiment of the present application also provides an OVN-based TCP service network status detection device, wherein the device includes a memory and a processor, the memory is used to store instructions or codes, and the processor is used to execute the instructions or codes so that the device performs the steps of the OVN-based TCP service network status detection method described in any embodiment of the present application.

[0079] In practical applications, the computer-readable storage medium may be any combination of one or more computer-readable media, which may be a computer-readable signal medium or a computer-readable storage medium.

[0080] The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination thereof. More specific examples of computer-readable storage media (a non-exhaustive list) include: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In the present embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that may be used by or in conjunction with an instruction execution system, device, or device.

[0081] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, which carry computer-readable program code. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Computer-readable signal media may also be any computer-readable medium other than a computer-readable storage medium, which may send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0082] The program code embodied on the computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0083] Computer program code for performing the operations of the present invention may be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0084] It should be noted that each embodiment in this specification is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment. The device embodiment described above is merely schematic, in which the unit described as a separate component may or may not be physically separated, and the component prompted as a unit may or may not be a physical unit, that is, it may be located in one place, or it may be distributed on multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the scheme of this embodiment. Ordinary technicians in this field can understand and implement it without paying creative work.

[0085] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any changes or substitutions that can be easily thought of by a person skilled in the art within the technical scope disclosed in the present application should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. A TCP service network status detection method based on OVN, characterized in that: include: Create a first monitoring point in the direction where the server virtual machine enters the logical switch, the first monitoring point being used to monitor the synchronization sequence number packet and confirmation character packet of the TCP connection initiated from the client virtual machine; configuring a first flow table rule in a first monitoring point, wherein the first flow table rule matches the synchronization sequence number packet and the confirmation character packet; Determine a first flow table count of a first monitoring point based on the first flow table rule, where the first flow table count is used to determine whether the synchronization sequence number packet and the confirmation character packet pass through the logical switch; Create a second monitoring point in the direction where the server virtual machine enters the logical switch, where the second monitoring point is used to monitor a reply packet sent by the server virtual machine to the client virtual machine; configuring a second flow table rule in a second monitoring point, wherein the second flow table rule matches the reply packet; determining a second flow table count of a second monitoring point based on the second flow table rule, where the second flow table count is used to determine whether the reply packet passes through the logical switch; The connection status of the TCP service network is determined according to the first flow table count and the second flow table count of the first monitoring point and the second monitoring point.

2. The method according to claim 1, characterized in that The first flow table rules include: The matching source IP address is the IP address of the client virtual machine, the matching target IP address is the IP address of the server virtual machine, the matching target port is the port of the server virtual machine, and the matching TCP flag is the synchronization sequence number.

3. The method according to claim 1, characterized in that The second flow table rules include: The source IP address to be matched is the IP address of the client virtual machine, the target IP address to be matched is the IP address of the server virtual machine, the target port to be matched is the port of the server virtual machine, and the TCP flag to be matched is the confirmation character.

4. The method according to claim 1, characterized in that: The first flow table count is specifically used for: Determine whether the TCP connection initiated by the client VM successfully passes through the logical switch; If the count of the first flow table is 0, it means that the synchronization sequence number packet or the confirmation character packet is discarded by the logical switch; If the first flow table count is greater than 0, it means that the synchronization sequence number packet and the confirmation character packet successfully pass through the logical switch.

5. The method according to claim 1, characterized in that The second flow table count is specifically used for: Determine whether the TCP connection replied by the server VM successfully passes through the logical switch; If the second flow table count is 0, it means that the reply packet is discarded by the logical switch; If the second flow table count is greater than 0, it means that the reply packet successfully passes through the logical switch.

6. The method according to claim 1, characterized in that The method further comprises: Based on the flow table counts of the first monitoring point and the second monitoring point, it is determined whether the TCP connection is blocked or lost by network intermediate devices such as the security group, and then the network connection status of the TCP service is determined.

7. A TCP service network status detection device based on OVN, characterized in that: include: A first creation module is used to create a first monitoring point in the direction where the server virtual machine enters the logical switch, wherein the first monitoring point is used to monitor the synchronization sequence number packet and confirmation character packet of the TCP connection initiated from the client virtual machine; A first configuration module, configured to configure a first flow table rule in a first monitoring point, wherein the first flow table rule matches the synchronization sequence number packet and the confirmation character packet; A first determination module, configured to determine a first flow table count of a first monitoring point based on the first flow table rule, wherein the first flow table count is used to determine whether the synchronization sequence number packet and the confirmation character packet pass through a logical switch; A second creation module is used to create a second monitoring point in the direction where the server virtual machine enters the logical switch, and the second monitoring point is used to monitor the reply packet of the server virtual machine to the client virtual machine; A second configuration module, configured to configure a second flow table rule in a second monitoring point, wherein the second flow table rule matches the reply packet; A second determination module determines a second flow table count of a second monitoring point based on the second flow table rule, where the second flow table count is used to determine whether the reply packet passes through the logical switch; A judgment module is used to determine the connection status of the TCP service network according to the first flow table count and the second flow table count of the first monitoring point and the second monitoring point.

8. An electronic device, characterized in that: comprising a memory and a processor, wherein: The memory is used to store the computer program; The processor is used to execute the computer program to implement the OVN-based TCP service network status detection method as described in any one of claims 1-6.

9. A computer-readable storage medium, characterized in that: Used to store a computer program, wherein when the computer program is executed by a processor, the OVN-based TCP service network status detection method according to any one of claims 1 to 6 is implemented.

Images