Virtual network state connection tracking method and device, equipment and medium

Abstract

The invention relates to the technical field of communication, and discloses a virtual network state connection tracking method and device, equipment and a medium, and the method comprises the steps: determining logic network information; arranging a logic flow table according to the logic network information through the central translation component to obtain a target logic flow table; mapping the connection tracking submission action in the target logic flow table into corresponding physical action information in the physical flow table through the local controller; a local controller configures a connection tracking state space for a local host to submit a connection tracking submission action for all target routing port information according to a constructed context table, and updates a forwarding path of a physical flow table. And enabling the flow to quote the corresponding connection tracking state space according to the updated physical flow table and execute the physical action information for forwarding. According to the technical scheme provided by the invention, the consistency of connection tracking state identification can be ensured during cross-host flow processing in the OVN distributed virtual network control system, so that a security guarantee is provided.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of communication technology, in particular to a virtual network state connection tracking method and device, equipment and medium. BACKGROUND

[0002] In the OVN distributed virtual network control system, because the source host and the destination host do not both make a connection tracking state (CT state) submission, the connection tracking state record of the bidirectional path is not reserved on the source host and the destination host, so that the logical switch routing port on the different hosts cannot identify the established connection for the cross-subnet traffic, which may misjudge the legal reply message as a new connection and discard or reject it, thereby affecting the correct application of the stateful access control policy and forming a security protection blind area for cross-subnet communication. The root cause of this problem lies in that the request and reply messages in the distributed forwarding path are processed on different hosts respectively, while the connection tracking state is not kept bidirectional consistent, so that the OVN is difficult to guarantee the consistency of the connection tracking state and the integrity of the security policy while ensuring efficient cross-node forwarding.

[0003] Therefore, how to ensure the consistency of the connection tracking state identification when processing cross-host traffic in the OVN distributed virtual network control system, and also enable the stateful access control policy on the logical switch routing port, so as to provide stronger security protection for cross-subnet communication is a technical problem that needs to be solved at present. SUMMARY

[0004] The present application provides a virtual network state connection tracking method, device, equipment and medium, which achieves the technical effect of ensuring the consistency of the connection tracking state identification when processing cross-host traffic in the OVN distributed virtual network control system.

[0005] In order to achieve the above purpose, the main technical scheme adopted by the present application includes: In a first aspect, the present application provides a virtual network state connection tracking method, applied to an OVN distributed virtual network control system, the system including a central translation component for translating logical network information in a northbound database into logical flow tables and writing them into a southbound database, and a local controller in each host for translating logical flow tables into physical flow tables, the method comprising: receiving a configuration item change event of a logical switch through the central translation component and the local controller, and determining logical network information; wherein the logical network information includes target routing port information configured to enable an access control list function and connection relationship information of a current logical switch where the target routing port information is located; The central translation component compiles a logical flow table according to the logical network information, to obtain a target logical flow table; wherein the target logical flow table comprises a connection tracking mark and a connection tracking submission action matched based on the connection tracking mark; The local controller maps the connection tracking submission action in the target logical flow table into corresponding physical action information in a physical flow table; The local controller configures a connection tracking state space for the local host to submit the connection tracking submission action for all the target routing port information according to the context table constructed, and updates the forwarding path of the physical flow table, so that the traffic refers to the corresponding connection tracking state space and performs the physical action information for forwarding according to the updated physical flow table; wherein the context table is constructed based on the logical port information and the physical location information of the network interface of the virtual machine.

[0006] The virtual network state connection tracking method provided in the embodiment receives a configuration item change event through a central translation component and a local controller, determines logical network information, and determines the configuration state of target routing port information and the connection relationship of the logical switch where the target routing port information is located. This lays a foundation for subsequent traffic identification and management, and ensures that the access control list function is enabled on the target routing port information, thereby providing protection for traffic safety. According to the determined logical network information, a logical flow table is compiled and a target logical flow table is generated. This flow table contains a connection tracking mark and specifies a connection tracking submission action, ensuring the state consistency of cross-host traffic. The local controller maps the connection tracking submission action in the target logical flow table into corresponding physical actions in the physical flow table, ensuring that network traffic is correctly forwarded at the physical layer and the safety of the traffic is ensured. By updating the forwarding path in the context table and the physical flow table, it is ensured that the cross-host traffic is safely and efficiently forwarded according to the latest state information. The context table is constructed based on the logical port information and the physical location information of the network interface of the virtual machine, so that the local controller can configure a connection tracking state space for the local host to submit the connection tracking submission action for all the target routing port information according to the context table, and update the forwarding path of the physical flow table, so that the traffic refers to the corresponding connection tracking state space for forwarding according to the updated physical flow table. Further, the OVN distributed virtual network control system maintains the identification consistency of the connection tracking state in the cross-host traffic processing process, ensuring the safety of the traffic.

[0007] In one embodiment, the determination of the logical network information comprises: All the logical switches are traversed, and the routing ports of the logical switches are matched with the ports in the configuration item change event that enable the access control list function, to determine target routing port information according to the matching result; Traverse the connection relationships of the current logical switch where the target routing port information is located, and obtain the connection relationship information between the current logical switch and other logical switches and logical routers to determine the logical network information.

[0008] This embodiment traverses all logical switches and matches ports with access control lists enabled to ensure appropriate security policies are applied during traffic transmission. This policy improves network security by managing incoming and outgoing traffic, preventing unauthorized access, and ensuring consistent connection tracking status across host machines. Furthermore, by traversing the connection relationships of the logical switches containing the target routing port information, logical network information is obtained. This helps to understand the connection status of logical switches with other switches or logical routers, providing a basis for traffic routing and security control.

[0009] In one implementation, the step of arranging the logical flow table according to the logical network information by the central translation component to obtain the target logical flow table includes: For each logical switch in the logical network information, a first table is constructed to characterize traffic that controls traffic entering the routing port of the logical switch, a second table is constructed to characterize traffic that controls traffic leaving the routing port of the logical switch, and a pre-table is constructed to characterize traffic processed before the first table and the second table. For the target routing port information in the logical network information, a connection tracking flag is set in the front table, and a connection tracking submission action matching the connection tracking flag is also set. Add matching rules based on the connection tracking tags to the first table and the second table to obtain the target logical flow table.

[0010] This embodiment manages inbound and outbound traffic and its preprocessing operations in a fine-grained manner by constructing a first table, a second table, and a pre-processing table for each logical switch, ensuring the consistency and accuracy of traffic control. Especially in cross-host processing, the use of connection tracking tags and connection tracking commit actions maintains the consistency of connection tracking status, ensuring seamless cross-host traffic transmission and preventing session interruptions or packet loss. Furthermore, through matching rules based on connection tracking tags, the system can dynamically adjust the traffic processing method, further optimizing cross-subnet traffic management and improving communication efficiency and stability.

[0011] In one implementation, the matching rules include tracking and established connections and / or tracking and associated connections.

[0012] In one embodiment, the method further includes: For traffic that matches the tracking and has an established connection or the tracking and has a related connection, set a connection tracking submission action to characterize the allowed action; For unmatched traffic, set up a connection tracking submission action to characterize the rejection action.

[0013] In one implementation, mapping the connection tracking submission action in the target logical flow table to the corresponding physical action information in the physical flow table via the local controller includes: Convert the connection tracking submission action in the target logical flow table into the corresponding physical action information in the physical flow table; The converted physical action information is written into the physical flow table.

[0014] This embodiment converts the Connection Tracking Commit (CT commit) action in the target logical flow table into physical action information in the physical flow table. This ensures that the source and destination hosts can correctly identify the connection tracking status during cross-host communication, avoiding inconsistencies in connection tracking status. Writing the converted physical action information into the physical flow table allows network devices to execute stateful access control policies based on the connection tracking status, thereby enabling fine-grained traffic control and improved security. The combination of logical and physical flow table conversion not only optimizes the processing efficiency of cross-host traffic but also improves the security and consistency of cross-subnet communication, thus achieving efficient and secure network traffic management.

[0015] In one implementation, the context table is constructed as follows: Obtain interface binding information; wherein the interface binding information is used to characterize the binding relationship between the virtual machine's network interface and the logical switch; Based on the interface binding information, determine the logical port information and physical location information of the network interface of the virtual machine; Based on the logical port information and the physical location information, a context table is constructed; wherein, the context table represents the access information of the virtual machine, the logical port information includes the network identification information of the virtual machine and the logical switch and logical router information to which the virtual machine belongs, and the physical location information includes the host machine information to which the virtual machine belongs.

[0016] This embodiment obtains the interface binding information of the virtual machine, which clearly identifies the binding relationship between the virtual machine's network interface and the logical switch, laying the foundation for subsequent traffic matching and forwarding. Based on the interface binding information, the logical port information and physical location information of the virtual machine are determined. A context table is constructed based on this information, covering the virtual machine's network identification information, its affiliated logical switch and logical router information, and host information. This context table is provided to the local controller for reference, ensuring the consistency of connection tracking status when handling cross-host traffic. In this way, the system can accurately identify and manage the virtual machine's traffic path during cross-subnet communication.

[0017] Secondly, embodiments of this application provide a virtual network state connection tracking device applied to an OVN distributed virtual network control system. The system includes a central translation component for translating logical network information in a northbound database into logical flow tables and writing them into a southbound database, and local controllers in each host machine for translating logical flow tables into physical flow tables. The device includes: The logical network determination unit is used to determine logical network information through configuration item change events of logical switches received by the central translation component and the local controller; wherein, the logical network information includes target routing port information configured to enable access control list function and connection relationship information of the current logical switch where the target routing port information is located; The logical flow table obtaining unit is used to arrange logical flow tables according to the logical network information through the central translation component to obtain a target logical flow table; wherein, the target logical flow table includes connection tracking tags and connection tracking submission actions matched based on the connection tracking tags; A connection tracking mapping unit is used to map the connection tracking submission action in the target logical flow table to the corresponding physical action information in the physical flow table through the local controller. The physical flow table update unit is used by the local controller to configure the connection tracking state space for the local host to submit the connection tracking submission action for all the target routing port information according to the constructed context table, and to update the forwarding path of the physical flow table so that the traffic is forwarded according to the updated physical flow table referencing the corresponding connection tracking state space and executing the physical action information; wherein, the context table is constructed based on the logical port information and physical location information of the network interface of the virtual machine.

[0018] Thirdly, embodiments of this application provide a computer device, including: The system includes a memory and a processor, which are interconnected. The memory stores computer instructions, and the processor executes these computer instructions to perform the virtual network state connection tracking method described above.

[0019] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer instructions, which are used to cause a computer to execute the virtual network state connection tracking method described above. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the specific embodiments of this application or the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0021] Figure 1 The diagram shows a three-layer forwarding schematic of a cross-subnet request message; Figure 2 The diagram shows a three-layer forwarding schematic of a cross-subnet response message; Figure 3 The diagram shows the CT status submission point of the request message; Figure 4 The diagram shown is a schematic of CT status matching for the response message; Figure 5 This is a schematic diagram of the OVN distributed virtual network control system provided in this embodiment; Figure 6 A flowchart illustrating a virtual network state connection tracking method provided in this application embodiment; Figure 7 A flowchart for determining logical network information provided in embodiments of this application; Figure 8 A flowchart of step S3 provided in the embodiments of this application; Figure 9 A flowchart of step S5 provided in an embodiment of this application; Figure 10 A flowchart illustrating the construction method of the context table provided in the embodiments of this application; Figure 11 This is a schematic diagram illustrating the specific implementation of the virtual network state connection tracking method based on this application; Figure 12 A block diagram of a virtual network status connection tracking device provided in an embodiment of this application; Figure 13 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0023] In existing OVN (Open Virtual Network) architectures, cross-subnet traffic typically travels between multiple hosts (chassis). OVN uses a distributed virtual network control system for forwarding, a mechanism based on logical switches, logical routers, and pipelines for packet processing. This distributed architecture improves network forwarding efficiency and flexibility, especially when packets need to be forwarded across hosts, avoiding centralized gateway nodes and reducing potential performance bottlenecks.

[0024] However, this distributed forwarding design also introduces some new challenges. Because the connection tracking (conntrack) state of the forwarding path between the routing ports of logical switches on different hosts is not kept bidirectionally consistent, this leads to the loss or inconsistency of the connection tracking state when cross-subnet traffic is processed on different nodes. For example... Figure 1 The diagram illustrates the Layer 3 forwarding of a cross-subnet request packet. The request packet is generated on the initiating virtual machine (VM1). The request packet is sent from the initiating virtual machine (VM1) to the virtual switch (OVS1) on the source host (Chassis1). The virtual switch (OVS1) forwards the request packet to the logical switch (LS11), which is responsible for Layer 2 forwarding within the same subnet. The request packet is then forwarded from the logical switch (LS11) to the logical router (LR1), which performs a Layer 3 lookup. After the lookup is complete, the request packet is forwarded to the logical switch (LS12). The request packet undergoes tunnel encapsulation within the Layer 2 forwarding domain of the logical switch (LS12), using the LS12's ID for the tunnel. The encapsulated request packet is then forwarded across nodes via a VXLAN tunnel to the destination host (Chassis2). After the encapsulated request message arrives at the destination host (Chassis2), it undergoes tunnel decapsulation. The decapsulated request message, based on the tunnel ID, is then directly forwarded at Layer 2 on the logical switch (LS22), ultimately reaching the responding virtual machine (VM2) via the virtual switch (OVS2). Correspondingly, as... Figure 2The diagram illustrates the Layer 3 forwarding of a cross-subnet response message. The response message is generated on the responding virtual machine (VM2). The response message is sent from the responding virtual machine (VM2) to the virtual switch (OVS2) on the destination host machine (Chassis2). The virtual switch (OVS2) forwards the response message to the logical switch (LS22), which is responsible for Layer 2 forwarding within the same subnet. The response message is forwarded from the logical switch (LS22) to the logical router (LR2). The logical router (LR2) is responsible for the Layer 3 query. After the query is completed, the message is forwarded to the logical switch (LS21). The logical switch (LS21) encapsulates the response message with tunnel ID using the ID of the logical switch (LS21). The encapsulated response message is forwarded back to the source host (Chassis1) across nodes through the VXLAN tunnel. Upon arrival at the source host (Chassis1), the tunnel is decapsulated. The decapsulated response message is then forwarded at Layer 2 in the logical switch (LS11) based on the tunnel ID. Finally, it reaches the virtual machine (VM1) that initiated the request message through the virtual switch (OVS1).

[0025] It should be noted that in the diagram, logical switches (LS11) and (LS21) are different instances of the same logical switch, as are logical switches (LS12) and (LS22). Although they run on the source host (Chassis1) and destination host (Chassis2) respectively, they represent the same logical entity. Similarly, logical routers (LR1) and (LR2) are also different instances of the same logical router, running on the source host (Chassis1) and destination host (Chassis2) respectively. All these logical devices (LS11, LS12, LR1, LS21, LS22, LR2) are uniformly managed and configured by the central controller (OVN Central) to ensure network configuration consistency and connectivity.

[0026] Therefore, request and response messages are processed on different hosts via different logical switch routing ports. Due to the distributed nature of OVN, the connection tracking state is not synchronized among these hosts. This causes the logical switch routing port on the destination host (Chassis2) to be unable to recognize the established connection, potentially leading to the erroneous interpretation of the response message as a new connection, resulting in its discarding or rejection.

[0027] The root cause of this problem lies in the fact that connection tracking state (CT state) is managed locally in the OVN architecture. The conntrack table on each host and node is maintained independently, which complicates the synchronization of connection tracking state across hosts. On the traffic path of requests and responses, the existence of different CT zones may lead to a situation where connection-related state information cannot be found on a certain node, thus affecting the correct identification and processing of traffic.

[0028] For example, please see Figure 3 The diagram illustrates the CT state submission point of a request message, which is generated on the initiating virtual machine (VM1). The request message is sent from VM1 to the virtual switch (OVS1) on the source host (Chassis1). OVS1 forwards the request message to the logical switch (LS11), which handles Layer 2 forwarding within the same subnet. From LS1, the request message is forwarded to the logical router (LR1), which performs a Layer 3 query. After the query, it is forwarded to the logical switch (LS12), where it undergoes tunnel encapsulation within the Layer 2 forwarding domain of LS12. The encapsulated request message is then forwarded across nodes via a VXLAN tunnel to the destination host (Chassis2). Upon arrival at the destination host (Chassis2), the encapsulated request message undergoes tunnel decapsulation on the logical switch (LS22) on the destination host (Chassis2). After decapsulation, the request message is forwarded directly at Layer 2 on the logical switch (LS22) based on the tunnel ID, and finally reaches the responding virtual machine (VM2) through the virtual switch (OVS2). The CT status of the request message is submitted and recorded on the logical switches (LS11) and (LS12) on the source host (Chassis1), and on the logical switch (LS22) on the destination host (Chassis2).

[0029] Please see Figure 4The diagram illustrates the CT state matching of a response message, generated on the responding virtual machine (VM2). The response message is sent from VM2 to the virtual switch (OVS2) on the destination host (Chassis2). OVS2 forwards the response message to the logical switch (LS22), which handles Layer 2 forwarding within the same subnet. On the destination host (Chassis2), the routing port of the logical switch (LS22) does not record the CT state of the request message because the request message did not pass through the routing port of the logical switch (LS22) during processing on the destination host (Chassis2), and the CT state cannot be created on the destination host (Chassis2). Therefore, when the response message is on the destination host (Chassis2), the routing port of the logical switch (LS22) cannot recognize this connection, potentially causing the response message to be misjudged as a new connection and thus dropped or rejected.

[0030] In summary, currently, especially when dealing with stateful access control policies (ACLs), routing ports in OVN cannot fully utilize connection tracking information to perform fine-grained security checks. Because routing ports cannot access the complete context of cross-host connections, they cannot correctly identify connection tracking states (e.g., ESTABLISHED or RELATED), thus preventing security protection policies in distributed virtual network environments from functioning properly. This not only may lead to network security vulnerabilities but also prevents OVN from effectively applying end-to-end security measures when handling complex cross-subnet traffic.

[0031] Therefore, ensuring consistent connection tracking status identification during cross-host traffic processing in the OVN distributed virtual network control system, and enabling stateful access control policies on the routing ports of logical switches to provide stronger security for cross-subnet communication are urgent technical problems that need to be solved.

[0032] To address the aforementioned technical problems, according to an embodiment of this application, a virtual network state connection tracking method embodiment is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0033] This embodiment provides a virtual network state connection tracking method, applied to the OVN distributed virtual network control system. The system includes a central translation component for translating logical network information in the northbound database into logical flow tables and writing them into the southbound database, and local controllers in each host machine for translating logical flow tables into physical forwarding flow tables.

[0034] Before introducing this embodiment, it should be noted that you should refer to [link / reference needed]. Figure 5 This embodiment illustrates the OVN distributed virtual network control system, which includes an OVN Central controller and several host machines (Chassis). The OVN Central controller includes a Northbound Database (OVN-NB) for storing logical network information, a Central Translation Component (OVN Northd) for translating the Northbound and Southbound databases, and a Southbound Database (OVN-SB) for storing physical network information. Each host machine (Chassis) runs a local controller (OVN-Controller) responsible for converting the logical network information in the OVN-NB into physical flow tables and distributing them to the Open vSwitch (OVS) via the OpenFlow protocol. The Open vSwitch (OVS), acting as a forwarding component on the local host, is responsible for forwarding traffic based on the flow tables distributed by the local controller (OVN-Controller). Prior to this embodiment, the OVN distributed virtual network control system operated in a standard OVN environment. The central translation component (OVNNorthd) reads the logical switches, logical routers, and their port information from the OVN-NB, establishes a logical forwarding model, and writes the corresponding port binding table and logical flow table into the OVN-SB. The local controller (OVN-Controller) subscribes to the OVN-SB and, combined with the local host's Chassis information, identifies the binding relationship between logical ports and physical ports. Based on the logical flow table provided by the central translation component (OVNNorthd), it generates an OVS physical flow table and distributes it to the local Open vSwitch for actual data forwarding. Under the default mechanism, logical switch routing ports are directly allowed in the pipeline's ACL table stage without triggering connection tracking (CT) actions.

[0035] Therefore, stateful ACLs cannot be enabled on logical switch routing ports under existing mechanisms. This embodiment, based on the existing mechanism, implements stateful connection tracking on logical switch routing ports by adding a subscription and flow table reconstruction mechanism. This includes adding support for CTs in the central translation component (OVN Northd) and the local controller (OVN-Controller), ensuring the consistency of CT states across host environments, thereby supporting the stateful ACL function on logical switch routing ports.

[0036] Specifically, please refer to Figure 6A flowchart of a virtual network state connection tracking method provided in this application embodiment is shown below. Figure 6 As shown, the process includes the following steps: Step S1: Determine the logical network information by receiving configuration item change events of the logical switch from the central translation component and the local controller; wherein, the logical network information includes the target routing port information configured to enable the access control list function and the connection relationship information of the current logical switch where the target routing port information is located.

[0037] Specifically, the central translation component and the local controller are responsible for listening to and processing configuration change events for the logical network. These configuration change events may include: adding or modifying logical switches; adding or removing routing ports within logical switches; enabling or modifying access control list (ACL) rules. When a configuration change event occurs, the central translation component and the local controller perform the following operations to determine logical network information: Read configuration change events: Read configuration change events from the northbound database to identify which logical switches or routing ports are affected.

[0038] Identify target routing port information: Determine which routing ports are configured to enable access control lists (ACLs). This involves examining ACL rules, which include traffic filtering requirements based on factors such as source address, destination address, and protocol type, to identify which rules apply to specific routing ports.

[0039] Obtain connectivity information: For each affected routing port, obtain the logical switch it belongs to and its connectivity information with other logical routers or logical switches. This helps in understanding how traffic flows within the logical network.

[0040] Based on the steps described above, the central translation component and the local controller will generate the latest logical network information. This information includes the routing ports with ACLs enabled, the logical switches where the routing ports are located, and the connection relationships between the switches.

[0041] Step S3: The central translation component arranges the logical flow table according to the logical network information to obtain the target logical flow table; wherein, the target logical flow table includes connection tracking tags and connection tracking submission actions that match the connection tracking tags.

[0042] Specifically, the central translation component analyzes logical network information received from the northbound database, including logical switches, logical routers, routing ports, and related ACL rules. It determines which routing ports require ACL rules to be enabled, typically based on whether the ACL rules contain allow-related actions or other actions requiring CT (Connection Tracking) status. For traffic requiring tracking, the central translation component sets connection tracking flags in the logical flow table. These connection tracking flags instruct subsequent access control lists (Stateful ACLs) in the OVN distributed virtual network control system to track the connection tracking status of this traffic. In the logical flow table, for each connection tracking flag, a corresponding connection tracking commit action is defined. It ensures that the connection tracking commit action is associated with the correct routing port and traffic type to properly manage the state of network connections. All connection tracking flags and connection tracking commit actions are integrated into the logical flow table to ensure this information guides network devices on how to track and manage connections.

[0043] Step S5: The connection tracking submission action in the target logical flow table is mapped to the corresponding physical action information in the physical flow table through the local controller.

[0044] Specifically, the local controller reads the latest target logical flow table from the northbound database. Within the target logical flow table, the local controller identifies connection tracking submission actions that require connection tracking. For each connection tracking submission action, the local controller translates it into a physical action that the physical network device can understand and execute. This involves setting specific OpenFlow instructions to track and update their connection tracking tags as packets pass through.

[0045] Step S7: The local controller configures the connection tracking state space for submitting connection tracking actions for all target routing port information based on the constructed context table, and updates the forwarding path of the physical flow table so that traffic is forwarded according to the updated physical flow table referencing the corresponding connection tracking state space and executing physical action information; wherein, the context table is constructed based on the logical port information and physical location information of the virtual machine's network interface.

[0046] Specifically, the context table is a key data structure used by the local controller to manage the network interfaces of virtual machines. It is constructed based on the logical port information and physical location information of the virtual machine's network interface. Logical port information includes the virtual machine's network identification information (such as IP address, MAC address, etc.) and the logical switch and router information to which the virtual machine belongs. Physical location information includes the host machine information to which the virtual machine belongs. The context table records the logical port information and physical location information of the virtual machines, enabling the local controller to accurately manage the connection state between virtual machines. Next, based on the context table, the local controller configures a dedicated connection tracking state space for each target routing port, ensuring that each subsequent routing port can correctly reference the corresponding connection tracking state space and submit its connection tracking state when forwarding traffic based on the physical flow table on the local host. Subsequently, the local controller updates the physical flow table to reflect these changes, ensuring that all network traffic is forwarded according to the new flow table rules. That is, when traffic is sent from one virtual machine to another virtual machine belonging to the same logical router but located on a different host, the local controller constructs and updates the tunnel encapsulation physical flow table based on the context table. When the traffic reaches the destination host, the local controller constructs the tunnel decapsulation physical flow table based on the context table, ensuring that the traffic can correctly reach the target virtual machine. This seamless process not only enables precise and efficient control of network traffic, but also efficiently manages the connections between virtual machines and network devices, ensuring state consistency and security of cross-host traffic.

[0047] It's also worth noting that, for uniqueness assurance, the tunnel ID uses the logical router's ID. By using the logical router's ID as the tunnel ID, the logical router to which the traffic belongs can be quickly identified, thus enabling efficient traffic forwarding.

[0048] For example, the local controller constructs a context table based on the logical port information and physical location information of the virtual machine's network interface. Virtual machine A has an IP address of 192.168.1.10, a MAC address of 00:11:22:33:44:55, belongs to logical switch 1 and logical router 1, and its physical location is on host machine 1. The local controller assigns a unique connection tracking state space zone ID to each target routing port based on the context table. For example, the target routing port of logical router 1 is assigned zone ID 1001. Simultaneously, the ID of logical router 1 is used as the tunnel ID, meaning the tunnel ID is also 1001.

[0049] The local controller updates the forwarding paths in the physical flow table based on the context table and zone ID. For example, a rule is added to the physical flow table instructing the device to forward traffic from virtual machine A to virtual machine B on host machine 2. The local controller maps connection tracking submission actions in the logical flow table to physical action information in the physical flow table. For example, if there is an action "Submit Connection Tracking" in the logical flow table, the local controller maps it to the action "Record Connection State and Forward Traffic" in the physical flow table.

[0050] When traffic is sent from virtual machine A to virtual machine B, virtual switch 1 on host machine 1, where virtual machine A resides, executes the physical action information in the physical flow table, identifies the logical router 1 to which the traffic belongs (via Tunnel ID 1001), and encapsulates the traffic before forwarding it to virtual switch 2 on host machine 2, where virtual machine B resides. Virtual switch 2 on host machine 2 identifies the logical router 1 to which the traffic belongs based on Tunnel ID 1001, decapsulates the traffic, and forwards it to virtual machine B. Simultaneously, the device records connection status information based on the zone ID to ensure that return traffic can correctly reach virtual machine A. This embodiment provides a virtual network state connection tracking method that determines logical network information and clarifies the configuration status of the target routing port information and its connection relationship information on the logical switch by receiving configuration item change events from the central translation component and the local controller. This lays the foundation for subsequent traffic identification and management and ensures that access control list functionality is enabled on the target routing port information, thereby providing security for traffic. Based on the determined logical network information, logical flow tables are arranged and a target logical flow table is generated. This flow table contains connection tracking tags and specifies connection tracking commit actions to ensure the consistency of state of cross-host traffic. By mapping connection tracking submission actions in the target logical flow table to corresponding physical actions in the physical flow table through the local controller, network traffic is correctly forwarded at the physical layer, ensuring traffic security. Updating the forwarding paths in the context table and physical flow table ensures that cross-host traffic is forwarded securely and efficiently according to the latest state information. The context table is constructed based on the logical port information and physical location information of the virtual machine network interface, enabling the local controller to configure the connection tracking state space for all target routing port information for local host connection tracking submission actions and update the forwarding paths in the physical flow table, so that traffic is forwarded according to the updated physical flow table references the corresponding connection tracking state space. Furthermore, the OVN distributed virtual network control system maintains the consistency of connection tracking state identification during cross-host traffic processing, ensuring traffic security.

[0051] Figure 7 The flowchart for determining logical network information provided in this application embodiment may include the following steps: Step S11: Traverse all logical switches and match the routing ports of the logical switches with the ports that have enabled the access control list function in the configuration item change event, so as to determine the target routing port information based on the matching results.

[0052] Specifically, the central translation component, as part of the central controller, traverses all defined logical switches. For each logical switch, the central translation component checks its routing ports to determine if they match ports that have enabled Stateful ACL rules in the configuration change event. Each routing port has an identifier (such as port ID, name, etc.), which is compared with ports that have enabled Stateful ACL rules in the configuration change event. Once a matching port with Stateful ACL rules is found, the central translation component designates these ports as target routing ports. These target routing ports will be subject to specific security rules, such as Stateful ACL rules, meaning they not only filter traffic but also track the state of traffic, providing more intelligent traffic control.

[0053] Step S13: Traverse the connection relationships of the current logical switch where the target routing port information is located, and obtain the connection relationship information between the current logical switch and other logical switches and logical routers to determine the logical network information.

[0054] Specifically, after locating the target routing port information, the central translation component examines the connectivity information of the logical switch containing that port. This includes how the current logical switch connects to other logical switches and how the target routing port interacts with logical routers and other relevant devices (such as other logical switches). By acquiring this connectivity information, the central translation component can construct logical network information, helping to understand the path and direction of network traffic. This is crucial for traffic analysis, performance optimization, and the deployment of security policies.

[0055] This embodiment traverses all logical switches and matches ports with access control lists enabled to ensure appropriate security policies are applied during traffic transmission. This policy improves network security by managing incoming and outgoing traffic, preventing unauthorized access, and ensuring consistent connection tracking status across host machines. Furthermore, by traversing the connection relationships of the logical switches containing the target routing port information, logical network information is obtained. This helps to understand the connection status of logical switches with other switches or logical routers, providing a basis for traffic routing and security control.

[0056] Figure 8 The flowchart for step S3 provided in the embodiments of this application may include the following steps: Step S31: For each logical switch in the logical network information, construct a first table to represent traffic that controls traffic entering the routing port of the logical switch, a second table to represent traffic that controls traffic leaving the routing port of the logical switch, and a pre-table to represent traffic processed before the first and second tables.

[0057] Specifically, a target logical flow table is constructed for each logical switch to control traffic entering and leaving the logical switch's routing ports. The first table (Ingress table) controls traffic entering the logical switch's routing ports. This includes matching incoming packets and determining how to process them (e.g., forwarding, rejecting) based on preset matching rules. The second table (Egress table) controls traffic leaving the logical switch's routing ports. This includes matching outgoing packets from the logical switch and determining how to process them (e.g., forwarding, rejecting) based on preset matching rules. A preprocessing table is used to perform preprocessing operations before the traffic is processed in the first (Ingress) and second (Egress) tables. These preprocessing operations include Connection Tracking (CT) marking and Connection Tracking Submission actions.

[0058] Step S33: For the target routing port information in the logical network information, set the connection tracking flag in the front table and the connection tracking submission action based on the matching connection tracking flag.

[0059] Specifically, in the front table, a Connection Tracking (CT) flag is set for the target routing port information in the logical network information. This is to track the status of each network connection (such as whether the connection has been established, whether it needs to be reconnected, etc.). In this way, network devices can distinguish data traffic in different states; for example, some packets may belong to an established connection, while other packets may be new connection requests. A Connection Tracking commit action is set in the front table for these target routing port information based on the matching Connection Tracking flag. This means that whenever a packet passes through these target routing ports, its Connection Tracking (CT) status will be updated, and a corresponding Connection Tracking commit action will be performed.

[0060] Step S35: Add matching rules based on connection tracking tags to the first and second tables to obtain the target logical flow table.

[0061] Specifically, matching rules based on connection tracking tags are added to the first table (Ingress table) and the second table (Egress table). These rules define which traffic should be tracked and how to handle it based on connection tracking status (e.g., established or associated), such as ct_state=+trk+est (tracked and established connection) and ct_state=+trk+rel (tracked and associated connection). These rules allow the system to decide whether to allow traffic based on the connection status (e.g., new, established, associated). By adding these connection tracking tag-based matching rules to the first and second tables (Ingress and Egress tables), a target logical flow table is ultimately constructed. This target logical flow table contains all the necessary flow control rules to guide how packets in the virtual network are processed. The updated target logical flow table is written to the OVN Southbound Database (OVN-SB) so that the local controller can read it and convert it into a physical flow table for distribution to OVS.

[0062] In some preferred embodiments, the method further includes: setting a connection tracking submission action to characterize an allowed action for traffic that matches the tracking and has established a connection or is tracked and has an associated connection; and setting a connection tracking submission action to characterize a rejected action for traffic that does not match the tracking.

[0063] Specifically, for traffic that matches the trace and has an established connection, or traffic that is traced and has a related connection, a connection trace submission action is set to characterize the allowed action. For traffic that does not match an established connection or a related connection, an action is set to deny that traffic. This helps prevent unauthorized access and potential security threats.

[0064] This embodiment manages inbound and outbound traffic and its preprocessing operations in a fine-grained manner by constructing a first table, a second table, and a pre-processing table for each logical switch, ensuring the consistency and accuracy of traffic control. Especially in cross-host processing, the use of connection tracking tags and connection tracking commit actions maintains the consistency of connection tracking status, ensuring seamless cross-host traffic transmission and preventing session interruptions or packet loss. Furthermore, through matching rules based on connection tracking tags, the system can dynamically adjust the traffic processing method, further optimizing cross-subnet traffic management and improving communication efficiency and stability.

[0065] Figure 9 The flowchart for step S5 provided in the embodiments of this application may include the following steps: Step S51: Convert the connection tracking submission action in the target logical flow table into the corresponding physical action information in the physical flow table.

[0066] Step S53: Write the converted physical action information into the physical flow table.

[0067] Specifically, the local controller reads the latest target logical flow tables from the OVN-SB, which contain network policies and rules at the logical layer. For each connection tracking submission action in the target logical flow table, the local controller converts these connection tracking submission actions into physical action information according to predefined mapping relationships.

[0068] For example, a ct commit(zone) action in the target logical flow table needs to be translated into a specific CT commit action in the physical flow table. This involves setting specific OpenFlow instructions to track and update Connection Tracking (CT) tags. Based on the mapping, physical action information that can be executed on physical network devices (such as OVS) is generated. This physical action information will guide the physical devices on how to handle network traffic, including how to perform CT tracking and state updates.

[0069] Using physical action information, the local controller constructs physical flow tables. These physical flow tables define how packets are processed on the physical network. Through the OpenFlow protocol, the local controller distributes the constructed physical flow tables to physical network devices (such as OVS). These physical flow tables contain specific matching conditions and actions, guiding the devices on how to handle passing network traffic. The local controller continuously monitors network status and changes in logical network information within the OVN-SB to ensure that the physical flow tables are updated in a timely manner to reflect the latest network policies.

[0070] This embodiment converts the Connection Tracking Commit (CT commit) action in the target logical flow table into physical action information in the physical flow table. This ensures that the source and destination hosts can correctly identify and track the connection tracking status during cross-host communication, avoiding inconsistencies in connection tracking status. Writing the converted physical action information into the physical flow table allows network devices to execute stateful access control policies based on the connection tracking status, thereby enabling fine-grained traffic control and improved security. The combination of logical and physical flow table conversion not only optimizes the processing efficiency of cross-host traffic but also improves the security and consistency of cross-subnet communication, thus achieving efficient and secure network traffic management.

[0071] Figure 10 A flowchart illustrating the construction method of the context table provided in this application embodiment, the process may include the following steps: Step S701: Obtain interface binding information; wherein, the interface binding information is used to characterize the binding relationship between the virtual machine's network interface and the logical switch.

[0072] Specifically, in the OVN distributed virtual network control system, port binding information describes how a virtual machine's (VM) network interface connects to a logical switch port. The local controller queries the northbound database for port binding information to obtain the binding relationship between each VM's network interface and the logical switch. These binding relationships include: Network Interface ID: a unique identifier for the VM's network interface, used to track the interface within the logical network; Routing Port ID: the port ID of the logical switch where the VM resides, connected to the logical router, defining the port interaction between the logical switch and the logical router; and Chassis information: the host information to which the VM is bound, which helps determine the VM's physical location and how traffic is processed on the physical device.

[0073] Step S703: Based on the interface binding information, determine the logical port information and physical location information of the virtual machine's network interface.

[0074] Specifically, after obtaining the interface binding information, the local controller uses this information to determine the logical port information and physical location information of the network interface. Based on the interface binding information, the local controller can determine the logical port information and physical location information to which each virtual machine's network interface is connected. The logical port information includes the virtual machine's network identification information (such as IP address, MAC address, etc.), as well as the logical switch and logical router information to which the virtual machine belongs. The physical location information includes the host machine information to which the virtual machine belongs.

[0075] Step S705: Construct a context table based on logical port information and physical location information; wherein, the context table represents the access information of the virtual machine, the logical port information includes the network identification information of the virtual machine and the logical switch and logical router information to which the virtual machine belongs, and the physical location information includes the host information to which the virtual machine belongs.

[0076] Specifically, by combining logical port information and physical location information, a more comprehensive context table is constructed, containing all the necessary information for virtual machines to access the network. This context table is written to the southbound database. All local controllers can configure the connection tracking state space for local hosts to submit connection tracking actions based on this context table, and then update the physical flow table so that traffic can be forwarded according to the updated physical flow table referencing the corresponding connection tracking state space. Specifically, the local controller updates the forwarding path of the physical flow table for virtual machines that belong to the same logical router in terms of logical port information but belong to different hosts in terms of physical location information, based on the context table. These updated physical flow tables are placed in the Egress (egress) of the logical router. The IDs of logical switches and logical routers are managed through centralized allocation to ensure the uniqueness and conflict-free nature of each ID. Therefore, the tunnel ID directly uses the logical router ID. The updated physical flow table forwards traffic to the corresponding logical router's Egress based on the tunnel's Tunnel ID, ensuring traffic security during cross-subnet communication based on the above path orchestration. With this design, OVN can maintain the consistency of connection tracking state during cross-host traffic processing, avoiding network interruptions or communication failures caused by inconsistent states.

[0077] This embodiment obtains the interface binding information of the virtual machine, which clearly identifies the binding relationship between the virtual machine's network interface and the logical switch, laying the foundation for subsequent traffic matching and forwarding. Based on the interface binding information, the logical port information and physical location information of the virtual machine are determined. A context table is constructed based on this information, covering the virtual machine's network identification information, the logical switch and logical router information it belongs to, and the host machine information. This context table is provided to the local controller for reference, ensuring the consistency of connection tracking status when handling cross-host traffic. In this way, when communicating across subnets, the system can accurately identify and manage the virtual machine's traffic path.

[0078] The following description is based on the specific implementation of the virtual network state connection tracking method of this application. See [link to relevant documentation]. Figure 11 To ensure correct forwarding of cross-host traffic and consistency of connection tracking status, the forwarding paths in the physical flow table need to be updated. The update process is as follows: The request packet is generated on the virtual machine (VM1) and enters the logical switch (LS11) through the virtual switch (OVS1). The local controller (OVN-Controller) marks the logical inport in the physical flow table. When the request packet needs to be forwarded across subnets, the local controller generates a Layer 3 lookup flow in the router ingress of the logical router (LR1). The system matches the destination IP of the request packet and performs longest prefix matching (LPM) to obtain the egress port information. Based on the destination IP, it queries the access context (AC) information to obtain the physical destination host (Chassis2) and logical switch, as well as the logical router information. If the source host (Chassis1) and the destination host (Chassis2) are different, the local controller adds tunnel encapsulation to the packet and places it in the engress of the logical router (LR1) on the source host (Chassis1). The encapsulated request packet is then transmitted to the destination host (Chassis2) through a VXLAN tunnel. After tunnel decapsulation on the destination host (Chassis2), the process proceeds to the logical router (LR2) based on the tunnel ID. The process continues after port matching in the logical router's (LR2) engress, and then proceeds from the logical switch (LS22) ingress pipeline to its router port. In the logical switch's (LS22) ingress pipeline, connection tracking (CT) submission and matching actions are performed on the router port.

[0079] The response message is generated on the virtual machine (VM2). The response message enters the logical switch (LS22) through the virtual switch (OVS2). When a packet needs to be forwarded across subnets, the local controller generates a Layer 3 lookup flow in the Router Ingress of the logical router (LR2). The system matches the destination IP of the packet and performs Longest Prefix Match (LPM) to obtain the egress port information. Based on the destination IP, it queries the AC information to obtain the source host (Chassis1) and logical switch / router information of the destination IP.

[0080] If the source host (Chassis1) and destination host (Chassis2) are different, the local controller adds tunnel encapsulation to the response packet. The encapsulated response packet is transmitted back to the source host (Chassis1) through a VXLAN tunnel. The tunnel encapsulation of the response packet is placed in the Engress of the logical router (LR2) on the destination host (Chassis2). After the packet reaches the source host (Chassis1), it is decapsulated in the tunnel and enters the Engress of the logical router (LR1) according to the tunnel ID. In the Engress of the logical switch (LS11), the packet is matched with the outgoing port and enters LS11. On LS11, it passes through the Router Ingress and enters the Ingress of the logical switch (LS11) for processing. In the Ingress Pipeline of the logical switch (LS11), the CT submission and matching actions of the router port are performed.

[0081] By rearranging the forwarding paths of logical routers and their associated logical switches, it is ensured that the connection tracking (CT) state between the source host (Chassis1) and the destination host (Chassis2) performs a connection tracking (CT) commit action on request packets, and a connection tracking state space is dynamically allocated for each routing port. This isolates CT entries, ensuring the isolation and consistency of connection tracking information. Through this orchestration, cross-host response packets are also forwarded along the same path, ensuring that request and response packets can be identified in the same connection tracking state space within the same connection. This achieves consistency of connection tracking state in a cross-host environment, ensuring correct traffic forwarding and security.

[0082] Accordingly, please refer to Figure 12 A block diagram of a virtual network state connection tracking device provided in this application embodiment, applied to an OVN distributed virtual network control system, includes a central translation component for translating logical network information in a northbound database into logical flow tables and writing them into a southbound database, and local controllers in each host machine for translating logical flow tables into physical flow tables. The device includes: The logical network determination unit 101 is used to determine logical network information based on configuration item change events of logical switches received by the central translation component and the local controller; wherein, the logical network information includes target routing port information configured to enable access control list function and connection relationship information of the current logical switch where the target routing port information is located; The logic flow table obtaining unit 103 is used to arrange the logic flow table according to the logic network information through the central translation component to obtain the target logic flow table; wherein, the target logic flow table includes connection tracking tags and connection tracking submission actions based on the connection tracking tags. The connection tracking mapping unit 105 is used to map the connection tracking submission action in the target logical flow table to the corresponding physical action information in the physical flow table through the local controller. The physical flow table update unit 107 is used by the local controller to configure the connection tracking state space for submitting connection tracking actions for all target routing port information based on the constructed context table, and to update the forwarding path of the physical flow table so that traffic is forwarded according to the updated physical flow table referencing the corresponding connection tracking state space and executing physical action information; wherein, the context table is constructed based on the logical port information and physical location information of the virtual machine's network interface.

[0083] In some optional implementations, the logic network determination unit 101 includes: Traverse all logical switches and match the routing ports of the logical switches with the ports that have enabled the access control list function in the configuration item change event, so as to determine the target routing port information based on the matching results; Traverse the connection relationships of the current logical switch where the target routing port information is located, obtain the connection relationship information between the current logical switch and other logical switches and logical routers, and determine the logical network information.

[0084] In some alternative implementations, the logic flow table obtaining unit 103 includes: For each logical switch in the logical network information, construct a first table to characterize traffic that controls the traffic entering the routing port of the logical switch, a second table to characterize traffic that controls the traffic leaving the routing port of the logical switch, and a pre-table to characterize traffic that is processed before the first and second tables. For the target routing port information in the logical network information, set the connection tracking flag in the front table and the connection tracking submission action based on the matching connection tracking flag; Add matching rules based on connection tracking tags to the first and second tables to obtain the target logical flow table.

[0085] In some alternative implementations, the matching rules include tracking and established connections and / or tracking and associated connections.

[0086] In some alternative embodiments, the apparatus further includes: For traffic that matches the tracking and has established a connection, or for traffic that is tracked and has a related connection, set up a connection tracking submission action to characterize the allowed action; For unmatched traffic, set up a connection tracking submission action to characterize the rejection action.

[0087] In some alternative implementations, the connection tracking mapping unit 105 includes: Convert the connection tracking submission action in the target logical flow table into the corresponding physical action information in the physical flow table; The converted physical action information is written into the physical flow table.

[0088] In some alternative implementations, the context table is constructed as follows: Obtain interface binding information; whereby the interface binding information is used to characterize the binding relationship between the virtual machine's network interface and the logical switch; Based on the interface binding information, determine the logical port information and physical location information of the virtual machine's network interface; A context table is constructed based on logical port information and physical location information. The context table represents the access information of the virtual machine. The logical port information includes the network identification information of the virtual machine and the logical switch and logical router information to which the virtual machine belongs. The physical location information includes the host machine information to which the virtual machine belongs.

[0089] Further functional descriptions of the above modules and units are the same as those in the corresponding embodiments described above, and will not be repeated here.

[0090] In this embodiment, a virtual network status connection tracking device is presented in the form of a functional unit. Here, a unit refers to an ASIC (Application Specific Integrated Circuit) circuit, a processor and memory that execute one or more software or fixed programs, and / or other devices that can provide the above functions.

[0091] Please see Figure 13 , Figure 13 This application provides a schematic diagram of the structure of a computer device, as shown in the embodiment of the present application. Figure 13As shown, the computer device includes one or more processors 10, memory 20, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components communicate with each other via different buses and can be mounted on a common motherboard or otherwise installed as needed. The processors can process instructions executed within the computer device, including instructions stored in or on memory to display graphical information of a GUI on external input / output devices (such as display devices coupled to the interfaces). In some alternative implementations, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple computer devices can be connected, each providing some of the necessary operations (e.g., as a server array, a group of blade servers, or a multiprocessor system). Figure 13 Take a processor 10 as an example.

[0092] Processor 10 may be a central processing unit, a network processor, or a combination thereof. Processor 10 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The programmable logic device may be a complex programmable logic device (CAMP), a field-programmable gate array (FPGA), a general-purpose array logic (GDA), or any combination thereof.

[0093] The memory 20 stores instructions executable by at least one processor 10 to cause the at least one processor 10 to perform the method shown in the above embodiments.

[0094] The memory 20 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the computer device. Furthermore, the memory 20 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some alternative embodiments, the memory 20 may optionally include memory remotely located relative to the processor 10, and these remote memories may be connected to the computer device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0095] The memory 20 may include volatile memory, such as random access memory; the memory may also include non-volatile memory, such as flash memory, hard disk or solid-state drive; the memory 20 may also include a combination of the above types of memory.

[0096] The computer device also includes a communication interface 30 for communicating with other devices or communication networks.

[0097] This application also provides a computer-readable storage medium. The methods described in this application can be implemented in hardware or firmware, or implemented as recordable on a storage medium, or implemented as computer code downloaded over a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and subsequently stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code. When the software or computer code is accessed and executed by the computer, processor, or hardware, the methods shown in the above embodiments are implemented.

[0098] The systems, devices, and units described in the above embodiments can be implemented by computer chips or physical entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or any combination of these devices.

[0099] For ease of description, the above devices are described separately by function as various units. Of course, in implementing this application, the functions of each unit can be implemented in one or more software and / or hardware.

[0100] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or apparatus. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0101] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatuses, and devices according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can 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, generate instructions for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0102] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0103] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0104] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0105] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the apparatus embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0106] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

[0107] Although embodiments of this application have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of this application, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A method for tracking virtual network state connections, characterized in that, An OVN distributed virtual network control system is applied, the system comprising a central translation component for translating logical network information in a northbound database into logical flow tables and writing them into a southbound database, and local controllers in each host machine for translating logical flow tables into physical flow tables, the method comprising: Logical network information is determined by receiving configuration item change events of logical switches from the central translation component and the local controller; wherein, the logical network information includes target routing port information configured to enable access control list function and connection relationship information of the current logical switch where the target routing port information is located; The central translation component arranges logical flow tables according to the logical network information to obtain a target logical flow table; wherein, the target logical flow table includes connection tracking tags and connection tracking submission actions that match the connection tracking tags; The local controller maps the connection tracking submission actions in the target logical flow table to the corresponding physical action information in the physical flow table. The local controller configures the connection tracking state space for all target routing port information based on the constructed context table, which is used for the local host to submit the connection tracking submission action, and updates the forwarding path of the physical flow table, so that traffic is forwarded according to the updated physical flow table referencing the corresponding connection tracking state space and executing the physical action information; wherein, the context table is constructed based on the logical port information and physical location information of the virtual machine's network interface.

2. The method according to claim 1, characterized in that, The determined logical network information includes: Traverse all the logical switches and match the routing ports of the logical switches with the ports that have enabled the access control list function in the configuration item change event, so as to determine the target routing port information based on the matching results; Traverse the connection relationships of the current logical switch where the target routing port information is located, and obtain the connection relationship information between the current logical switch and other logical switches and logical routers to determine the logical network information.

3. The method according to claim 1, characterized in that, The step of arranging the logical flow table according to the logical network information by the central translation component to obtain the target logical flow table includes: For each logical switch in the logical network information, a first table is constructed to characterize traffic that controls traffic entering the routing port of the logical switch, a second table is constructed to characterize traffic that controls traffic leaving the routing port of the logical switch, and a pre-table is constructed to characterize traffic processed before the first table and the second table. For the target routing port information in the logical network information, a connection tracking flag is set in the front table, and a connection tracking submission action matching the connection tracking flag is also set. Add matching rules based on the connection tracking tags to the first table and the second table to obtain the target logical flow table.

4. The method according to claim 3, characterized in that, The matching rules include tracking and established connections and / or tracking and related connections.

5. The method according to claim 4, characterized in that, The method further includes: For traffic that matches the tracking and has an established connection or the tracking and has a related connection, set a connection tracking submission action to characterize the allowed action; For unmatched traffic, set up a connection tracking submission action to characterize the rejection action.

6. The method according to claim 1, characterized in that, The step of mapping the connection tracking submission action in the target logical flow table to the corresponding physical action information in the physical flow table through the local controller includes: Convert the connection tracking submission action in the target logical flow table into the corresponding physical action information in the physical flow table; The converted physical action information is written into the physical flow table.

7. The method according to claim 1, characterized in that, The method for constructing the context table includes: Obtain interface binding information; wherein the interface binding information is used to characterize the binding relationship between the virtual machine's network interface and the logical switch; Based on the interface binding information, determine the logical port information and physical location information of the network interface of the virtual machine; Based on the logical port information and the physical location information, a context table is constructed; wherein, the context table represents the access information of the virtual machine, the logical port information includes the network identification information of the virtual machine and the logical switch and logical router information to which the virtual machine belongs, and the physical location information includes the host machine information to which the virtual machine belongs.

8. A virtual network status connection tracking device, characterized in that, An application is made to the OVN distributed virtual network control system, the system comprising a central translation component for translating logical network information in a northbound database into logical flow tables and writing them into a southbound database, and local controllers in each host machine for translating logical flow tables into physical flow tables, the device comprising: The logical network determination unit is used to determine logical network information through configuration item change events of logical switches received by the central translation component and the local controller; wherein, the logical network information includes target routing port information configured to enable access control list function and connection relationship information of the current logical switch where the target routing port information is located; The logical flow table obtaining unit is used to arrange logical flow tables according to the logical network information through the central translation component to obtain a target logical flow table; wherein, the target logical flow table includes connection tracking tags and connection tracking submission actions matched based on the connection tracking tags; A connection tracking mapping unit is used to map the connection tracking submission action in the target logical flow table to the corresponding physical action information in the physical flow table through the local controller. The physical flow table update unit is used by the local controller to configure the connection tracking state space for the local host to submit the connection tracking submission action for all the target routing port information according to the constructed context table, and to update the forwarding path of the physical flow table so that the traffic is forwarded according to the updated physical flow table referencing the corresponding connection tracking state space and executing the physical action information; wherein, the context table is constructed based on the logical port information and physical location information of the network interface of the virtual machine.

9. A computer device, characterized in that, include: A memory and a processor are communicatively connected, the memory storing computer instructions, and the processor executing the computer instructions to perform the virtual network state connection tracking method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing the computer to perform the virtual network state connection tracking method according to any one of claims 1 to 7.

Images