Method and system for OVN security group to support IPIP protocol in DPDK environment

Abstract

The invention provides a method and a system for an OVN security group to support an IPIP protocol in a DPDK environment, belongs to the technical field of cloud computing and virtualized networks, and is oriented to a logic switch assembly line comprising a preacl stage, a CT stage and an acl stage. Configuring a security group default discarding rule and an IPIP release rule; identifying an IPIP message according to an IP header protocol number in a preacl stage, and resubmitting the IPIP message as a target protocol flow through a bypass flow table or forwarding the target protocol flow to a processing table item after a CT, so that the target protocol flow skips connection tracking; other IP traffic still enters CT tracking; and in the acl stage, stateless release is carried out on the target protocol traffic according to a release rule containing an untracked state matching condition, and missed traffic is discarded according to a default rule. The method can be compatible with the IPIP under the condition that the data path is not switched and can be expanded to other protocols which do not support the CT.

Description

Technical Field

[0001] This invention belongs to the field of cloud computing and virtualization network technology, and in particular relates to a method and system for OVN security groups to support the IPIP protocol in the DPDK environment. Background Technology

[0002] OVN typically uses Connection Tracking (CT) capabilities in logical switch pipelines in conjunction with ACL rules to achieve access control and state-related matching for security groups. In actual deployments, DPDK data paths are often used to improve forwarding performance. However, in a DPDK environment, connection tracking has limited support for some encapsulation protocols (such as IPIP). Related packets may not form a valid tracking state after entering CT, and will therefore be discarded by default rules in subsequent security group processing stages. This manifests as IPIP services being unreachable when security groups are enabled on the same subnet. Existing solutions often rely on disabling security groups, adjusting the service network structure, or switching data paths, resulting in high maintenance costs and significant impact on the original security group policy system. Therefore, a solution is needed that allows the DPDK environment to correctly process IPIP packets while maintaining the OVN security group configuration. Summary of the Invention

[0003] In view of this, the present invention aims to provide a method and system for OVN security groups to support the IPIP protocol in the DPDK environment, so as to at least solve one of the problems in the background art.

[0004] To achieve the above objectives, the technical solution of the present invention is implemented as follows: A method for supporting the IPIP protocol in an OVN security group under a DPDK environment is applied to an OVN-based logical switch processing pipeline. The processing pipeline includes at least a pre_acl stage, a CT stage, and an acl stage, including: configuring security group rules for a target virtual machine. The security group rules include at least a default drop rule for IP packets and an allow rule for IPIP protocol packets. In the pre_acl stage, the IP packets entering the processing pipeline are identified by protocol. When the protocol number field of the IP packet represents the IPIP protocol, the IPIP protocol packet is matched as the target protocol traffic, and the target protocol traffic is bypassed and forwarded to the subsequent processing entries in the acl stage. For IP traffic other than the target protocol traffic, continue to perform connection tracking processing during the CT phase; During the ACL phase, the target protocol traffic is matched according to the security group rules, and the allowed action is performed on the matched target protocol traffic according to the allowed rule, and the discard action is performed on the unmatched IP traffic according to the default discard rule.

[0005] Furthermore, the pre_acl stage includes an uplink pre_acl stage and a downlink pre_acl stage. The bypass forwarding entry action is configured in the uplink pre_acl stage and the downlink pre_acl stage respectively, so that the target protocol traffic is bypassed in both the uplink and downlink directions and transferred to the subsequent processing entries of the acl stage.

[0006] Furthermore, the protocol number field is the IP header field ip.proto. When ip.proto equals 4, the packet is identified as an IPIP protocol packet and the bypass forwarding table entry action is executed as the target protocol traffic.

[0007] Furthermore, the bypass forwarding table entry action is a resubmission action or a table transfer action, which directly imports the target protocol traffic from the pre_acl stage into the corresponding processing table entry after the CT stage.

[0008] Furthermore, the bypass forwarding table entries corresponding to the uplink pre_acl stage are configured in a preset uplink table number, and the bypass forwarding table entries corresponding to the downlink pre_acl stage are configured in a preset downlink table number; when the bypass forwarding table entries hit the target protocol traffic, they respectively perform a resubmission action corresponding to the direction, and resubmit the target protocol traffic to the subsequent table number corresponding to the uplink table number and the downlink table number respectively.

[0009] Furthermore, the matching conditions of the bypass forwarding table entry include at least the matching conditions for the message type being IPv4 and the matching conditions for ip.proto being the target protocol, and further include at least one of the following: logical data path identifier matching conditions, logical port identifier matching conditions, and inbound / outbound direction identifier matching conditions.

[0010] Furthermore, the allow rule is a security group rule generation rule of the allow-related type, and the logical flow table corresponding to the allow rule contains matching conditions for not entering the connection tracking state, so that the target protocol traffic can hit the allow rule when it does not enter the CT phase.

[0011] Furthermore, the security group rules are distributed and managed through port groups, which at least contain the logical port identifier of the target virtual machine; the default drop rule applies to IP traffic within the port group, and the allow rule applies to traffic within the port group that meets the IPIP protocol matching conditions.

[0012] Furthermore, the priority of the bypass forwarding table entry is higher than the priority of the forwarding table entry for the connection tracking processing path in the pre_acl stage.

[0013] Furthermore, this solution discloses a system for OVN security groups to support the IPIP protocol in a DPDK environment, comprising: a DPDK data path, a rule management unit, a bypass configuration unit, and a security group processing unit; the rule management unit is used to generate and distribute security group rules containing default drop rules and IPIP protocol allow rules; the bypass configuration unit is used to configure bypass forwarding table entries for target protocol traffic in the pre_acl stage, and perform a resubmission action or a forwarding action when the target protocol traffic is hit to import the target protocol traffic into the subsequent processing table entries of the ACL stage; the security group processing unit is used to perform matching between the target protocol traffic and other IP traffic according to the security group rules in the ACL stage and output an allow action or a drop action; the DPDK data path is used to carry the pre_acl stage, CT stage, and ACL stage and execute the forwarding table entries.

[0014] Furthermore, this solution discloses a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the method described thereon.

[0015] Furthermore, this solution discloses an electronic device, including a processor and a memory, wherein the memory stores a computer program, and the processor executes the computer program to implement the method described above.

[0016] Compared with existing technologies, the method and system for supporting the IPIP protocol in an OVN security group under the DPDK environment described in this invention have the following advantages: This invention performs protocol identification and bypass processing on IPIP packets during the pre_acl stage of the OVN logical switch pipeline. This allows target protocol traffic to skip the CT stage and enter subsequent ACL processing, while preserving the CT processing path for other IP traffic. This balances the processing needs of tunnel encapsulation protocols and regular service traffic within the same network. Combined with allow rules that include untracked state matching conditions, bypassed target protocol traffic can be allowed in a stateless manner during the ACL stage, while the default drop rule still serves as a fallback strategy. This solution has minimal impact on existing security group configurations, can be deployed by issuing bypass flow tables, and can be extended to other CT protocol types that are not supported or are unstable in the DPDK environment. Attached Figure Description

[0017] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an undue limitation of the invention. In the drawings: Figure 1 This is a schematic diagram illustrating the use of stateless security groups to allow IPIP packets according to an embodiment of the present invention. Detailed Implementation

[0018] It should be noted that, unless otherwise specified, the embodiments and features described in the present invention can be combined with each other.

[0019] In the description of this invention, it should be understood that the terms "center," "longitudinal," "lateral," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," and "outer," etc., indicating orientations or positional relationships based on the orientations or positional relationships shown in the accompanying drawings, are used only for the convenience of describing the invention and for simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the invention. Furthermore, the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, features defined with "first," "second," etc., may explicitly or implicitly include one or more of that feature. In the description of this invention, unless otherwise stated, "a plurality of" means two or more.

[0020] In the description of this invention, it should be noted that, unless otherwise explicitly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art will understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0021] The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0022] This embodiment uses an OVN-built VPC network as an example to illustrate a method for supporting the IPIP protocol and being compatible with security group control under the DPDK data path. OVN uses OVS as its forwarding foundation. The data processing pipeline of the logical switch includes the security group preprocessing stage (pre_acl), the connection tracking stage (CT), and the security group access control stage (acl). Security group rules are issued to OVS through the OVN logical flow table. Typically, before entering the acl stage, a connection tracking mark needs to be obtained in the CT stage. Subsequently, in the acl stage, allow or drop rules are executed based on the connection status or rule conditions. Under the DPDK data path, the OVS CT module does not support or fully support some tunnel encapsulation protocols (such as IPIP). This causes such packets to fail to form valid connection tracking entries after entering the CT and may be marked as invalid, thus triggering the security group's drop rule.

[0023] Without this approach, a logical switch DMZ is constructed, and virtual machines vm1 and vm2 are created within it. Both belong to the DMZ and are bound to security groups. Security groups are configured using port groups. For example, a port group sg_drop is created and configured with default drop rules, causing inbound and outbound IP traffic within the port group to be dropped by default during the security group phase. Simultaneously, a port group sg_test is created and configured with rules allowing the IPIP protocol to pass (in OVN, allow-related rules can be used to generate corresponding logical flows). Under this configuration, when an IPIP packet is sent from vm1 to vm2, the packet is not received by the vm2 side in packet capture. Checking the connection tracking table of the DPDK data path reveals no conntrack entry for IPIP. Furthermore, in the flow table statistics generated by OVS / OVN, an increase in the count of drop entries related to invalid connection states is observed, indicating that the packet is intercepted by the security group path in an invalid state after entering the CT. Further comparison with the conntrack results under the kernel data path shows that the same IPIP packets can be correctly identified and form a trace record with protocol type 4, thus confirming that the problem is related to CT's ability to process the IPIP protocol in the DPDK environment.

[0024] To address the aforementioned issues, this embodiment introduces "target protocol bypass" processing in the pre_acl stage of the logic switch pipeline: IP packets entering the pipeline are first identified by protocol. When the protocol number is identified as IPIP, the packet is determined to be target protocol traffic and is no longer entered into the CT stage. Instead, in the pre_acl stage, it is directly imported into the subsequent processing table after the CT stage through a preset bypass forwarding table entry, allowing the target protocol traffic to skip connection tracking processing. IP traffic that is not a target protocol continues to enter the CT stage along its original path for connection tracking. Subsequently, in the acl stage, target protocol traffic is matched and processed according to security group rules. Since target protocol traffic does not carry CT tracking markers after being bypassed, this embodiment employs security group allow rules that can match traffic that has not entered the CT state. This allows target protocol traffic to be hit in a stateless manner and perform allow actions in the acl stage, while traffic that does not match the allow rules is still processed according to the default drop rules. The direct effect of this approach is that target protocol traffic no longer triggers invalid state paths caused by DPDK CT not supporting it; at the same time, other ordinary IP traffic can still enter CT as originally designed and maintain the state detection capability of the security group.

[0025] In a specific configuration, bypass flow tables can be manually added to the uplink and downlink entries corresponding to `pre_acl` in the business bridge (e.g., the business bridge) to complete verification. For the official product, these can be automatically distributed by control plane or node-side components. In the example, the uplink `pre_acl` stage corresponds to table=15, and the downlink `pre_acl` stage corresponds to table=45. Matching and resubmitting actions for the IPIP protocol are added to these two tables respectively. For example, in table=15, the matching condition is configured as IP, the metadata as the logical data path identifier, and `nw_proto` as 4, and a resubmit is executed to table=16; in table=45, the matching condition is configured as IP, the metadata as the logical data path identifier, and `nw_proto` as 4, and a resubmit is executed to table=46. The aforementioned metadata can be the identifier value corresponding to the logical switch data path (obtainable through existing OVS flow table matching items, data path binding information in the SB database, or maintenance queries). After completing the bypass flow table insertion, the IPIP packet is sent again by VM1. On the VM2 side, the arrival of the packet with protocol type IPIP (4) can be observed through tcpdump, indicating that the target protocol traffic has entered the subsequent security group processing stage along the bypass path and passed the allow rule. Further analysis of the logical flow table generated by the security group allow rule shows that the allow-related type rule usually generates two logical flows, which include matching conditions for not entering the CT tracking state (e.g., the logical condition includes the state matching of "not tracked by CT"). This logical flow can hit the target protocol traffic after bypassing. According to the actual flow table count of OVS, the corresponding matching item count increases, which verifies from the side that the IPIP traffic after bypassing is processed by the security group rule in a stateless manner in the ACL stage.

[0026] In some implementations, to reduce the impact of bypassing on other services, the matching conditions of the bypass flow table can be further superimposed with at least one limiting condition in addition to the protocol number: logical port identifier limitation, port group identifier limitation, inbound or outbound direction limitation, tunnel endpoint IP limitation, source / destination subnet limitation, or combined matching using OVS register fields (e.g., register bit fields used to carry port group or logical port mapping results). Through these limitations, the bypass scope can be converged to "only effective for virtual machine ports bound to a specific security group and with IPIP enabled," making it easier to directly elevate this limiting feature to the claims to enhance the distinguishing point. In some implementations, the bypass flow table action, in addition to resubmit, can also use goto_table, learn in conjunction with table conversion, or write to the flag register first and then convert the table to achieve equivalent control of "skipping the CT stage and entering the post-CT processing table entries." In some implementations, the priority of the bypass flow table can be set higher than the general processing rules for entering the CT path in the same table (e.g., set to 110 or higher, and ensure that it does not cover higher priority abnormal drop rules) to ensure that the bypass path is taken first when the target protocol is hit.

[0027] In some implementations, the target protocol is not limited to IPIP (protocol number 4), but can be extended to any encapsulation protocol that is not supported by connection tracking in the DPDK environment or is prone to invalid states, such as GRE; a "target protocol list" can be maintained, and bypass matching items can be configured for each protocol number in the list during the pre_acl stage, or multiple protocol numbers can be covered at once using a range / set matching method. Correspondingly, the security group allow rule can be configured with protocol number matching conditions for each target protocol, or configured as a combination logic of "allow if one of the target protocol lists is met"; at the same time, a default discard rule is retained as a fallback.

[0028] In some implementations, to facilitate online acceptance and fault location, verification can be performed before and after the bypass rule takes effect. This includes reading the DPDK conntrack table to confirm that the target protocol does not generate valid entries, reading the OVS flow table to confirm that the invalid state drop count no longer increases with the transmission of target protocol packets, and capturing packets at the receiving end to confirm that the target protocol packets are reachable. When the verification does not meet the preset conditions, the bypass flow table can be rolled back or the bypass priority can be reduced to restore the original path. Based on the description of the above embodiments, additional technical features such as "pipeline stage of bypass occurrence (uplink / downlink pre_acl)", "bypass matching conditions (protocol number, metadata, port group / port identifier, register flag, etc.)", "bypass action type (resubmit / goto_table, etc.)", "allowing rules to include matching conditions that have not entered the CT state (stateless hit)", and "bypass rule priority and rollback verification mechanism" can be selectively defined in subsequent examination opinion responses as needed to further limit the claims.

[0029] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for supporting the IPIP protocol in an OVN security group under a DPDK environment, applied to an OVN-based logical switch processing pipeline, wherein the processing pipeline includes at least a pre_acl stage, a CT stage, and an acl stage, characterized in that: Configure security group rules for the target virtual machine, the security group rules including at least a default drop rule for IP packets and an allow rule for IPIP protocol packets; In the pre_acl stage, the IP packets entering the processing pipeline are identified by protocol. When the protocol number field of the IP packet represents the IPIP protocol, the IPIP protocol packet is matched as the target protocol traffic, and the target protocol traffic is bypassed and forwarded to the subsequent processing entries in the acl stage. For IP traffic other than the target protocol traffic, continue to perform connection tracking processing during the CT phase; During the ACL phase, the target protocol traffic is matched according to the security group rules, and the allowed action is performed on the matched target protocol traffic according to the allowed rule, and the discard action is performed on the unmatched IP traffic according to the default discard rule.

2. The method as described in claim 1, characterized in that: The pre_acl stage includes an uplink pre_acl stage and a downlink pre_acl stage. The bypass forwarding entry action is configured in the uplink pre_acl stage and the downlink pre_acl stage respectively, so that the target protocol traffic is bypassed in both the uplink and downlink directions and transferred to the subsequent processing entries of the acl stage.

3. The method as described in claim 1, characterized in that: The bypass forwarding table entry action is a resubmission action or a table forwarding action. The resubmission action or table forwarding action directly imports the target protocol traffic from the pre_acl stage into the corresponding processing table entry after the CT stage.

4. The method as described in claim 2, characterized in that: The bypass forwarding entries corresponding to the uplink pre_acl stage are configured in a preset uplink table number, and the bypass forwarding entries corresponding to the downlink pre_acl stage are configured in a preset downlink table number. When the bypass forwarding entry hits the target protocol traffic, it performs a resubmission action corresponding to the direction, resubmitting the target protocol traffic to the subsequent table number corresponding to the uplink table number and downlink table number, respectively.

5. The method as described in claim 1, characterized in that: The matching conditions of the bypass forwarding table entry include at least the matching conditions for the message type being IPv4 and the matching conditions for ip.proto being the target protocol, and further include at least one of the following: logical data path identifier matching conditions, logical port identifier matching conditions, and inbound / outbound direction identifier matching conditions.

6. The method as described in claim 1, characterized in that: The allow rule is a security group rule generation rule of type allow-related. The logical flow table corresponding to the allow rule contains matching conditions for traffic that has not entered the connection tracking state, so that the target protocol traffic can hit the allow rule when it has not entered the CT phase.

7. The method as described in claim 1, characterized in that: The security group rules are distributed and managed through port groups, which at least contain the logical port identifier of the target virtual machine; the default drop rule applies to IP traffic within the port group, and the allow rule applies to traffic within the port group that meets the IPIP protocol matching conditions.

8. The method as described in claim 1, characterized in that: The priority of the bypass forwarding table entry is higher than the priority of the forwarding table entry for the connection tracking processing path in the pre_acl phase.

9. A system for OVN security groups to support the IPIP protocol in a DPDK environment, characterized in that, include: DPDK data path, rule management unit, bypass configuration unit, and security group processing unit; The rule management unit is used to generate and issue security group rules containing default drop rules and IPIP protocol allow rules; the bypass configuration unit is used to configure bypass forwarding table entries for target protocol traffic in the pre_acl stage, and perform a resubmission action or a table forwarding action when the target protocol traffic is hit to import the target protocol traffic into the subsequent processing table entries of the ACL stage; the security group processing unit is used to perform matching between the target protocol traffic and other IP traffic according to the security group rules in the ACL stage and output an allow action or a drop action; the DPDK data path is used to carry the pre_acl stage, CT stage and ACL stage and execute the forwarding table entries.

10. A computer-readable storage medium having a computer program stored thereon, the computer program, when executed by a processor, implementing the method as claimed in any one of claims 1 to 8.

Images