Method and system for managing virtual private cloud (VPC) network configuration

Abstract

To manage a virtual private cloud (VPC) network configuration, a network topology and a configuration of each network element in the network are obtained, and a reachability intent including intent properties is defined. An abstract network representation is then generated according to the obtained configuration of the network elements and the network topology. The abstract network representation is converted into a Boolean satisfiability problem (SAT)-based network reachability policy. The SAT-based network reachability policy is updated using the defined reachability intent while keeping original reachability properties of all network elements not included in the defined reachability intent. A new network configuration is generated according to the updated SAT-based network reachability policy.

Description

Technical Field

[0001] This invention generally relates to virtual private cloud (VPC) networks, and more specifically, to methods for managing VPC network configurations. Furthermore, this invention relates to systems for managing VPC network configurations. Background Technology

[0002] A Virtual Private Cloud (VPC) is a network abstraction technology for public cloud systems. A VPC typically consists of a set of network services (e.g., SaaS services) that allow defining complex network reachability properties between internal and external cloud systems / entities (e.g., customer virtual machines (VMs) such as Elastic Container Service (ECS) or Elastic Compute Cloud (EC2)) or some common internet nodes. Despite hiding the underlying complexity through an understandable abstraction layer, VPCs remain difficult to configure and manage. While existing industry tools and techniques have been developed to verify the correctness of VPC configurations, no single technique yet allows for proactive and provably modifying VPC configurations based on custom reachability intentions.

[0003] Existing solutions can be used to generate new configuration settings for many types of networks. However, these existing solutions may lead to undesirable behaviors that are often difficult to detect in advance. Formal method-based techniques were developed to address this specific problem. For example, existing solutions use formal method-based network configuration generation systems and techniques primarily for physical networks such as data center networks (DCNs) or wide-area networks (WANs). VPC networks have properties that these network types do not possess, making the application of existing solutions / techniques more challenging. Some properties of VPC networks relate to the following: (i) replicated network elements or configurations (e.g., access control lists (ACLs), firewalls, routing tables, etc.), (ii) replicated network addresses (e.g., coexistence of the same IP space in different parts of the network), and (iii) tangled configurations (e.g., multiple configurations associated with the same network element). Due to this problem, existing methods are difficult to scale to large networks while keeping response times below a threshold, which can be considered an acceptable response time for real-time services.

[0004] Changing the reachability properties of a computer network is highly complex, and therefore, there is a high probability of human error when done manually. To address this, automated systems have been developed that provide formal guarantees of the correctness of configuration changes. However, most of these automated systems can only verify a given configuration change, while others can generate new configurations. In the case of generating configurations for a VPC network (such a potential configuration), existing systems can handle the additional complexities associated with the specific aspects of VPC networks. Additionally, in terms of the configuration costs that the generated configuration may incur (e.g., the number of new configuration lines added to all affected network elements, the total number of affected network elements, or alternatively, some other cost metric), existing systems can only meet business requirements.

[0005] Furthermore, commercial VPC configuration management requires good scalability. A commercial VPC may include thousands of unique devices in a single deployment. Simultaneously, users may need to update the VPC network configuration at a certain rate (e.g., several times per week during normal operation, several times per hour during active development of a new service, or during the migration of an existing service). This means that the system (its changes to the VPC network configuration) must be comparable to a real-time service; it must generate a new configuration within one minute, even for a topology with thousands of unique network elements, while providing near-real-time response times when querying some reachability attributes. This problem presents a challenge to implementing efficient algorithms that both meet the desired functional requirements and runtime deadline constraints.

[0006] The main components of a VPC network stack typically include traffic routing and traffic filtering services. Traffic filtering services can include virtual or physical devices that define a set of rules that allow or deny specific traffic flows through the device (e.g., network ACLs (NACLs), security groups (SGs), firewalls). Routing services can include virtual or physical devices responsible for changing the path attributes of traffic flows. Such virtual or physical devices (e.g., routers, VPC peers, network load balancers (NLBs)) can include explicit rules that may force traffic redirection to a specific device or drop traffic when such a device is unavailable.

[0007] While the VPC network stack can consist of various services, its primary purpose remains interconnecting compute / storage services. These traffic routing and filtering services are mainly composed of common compute units (e.g., ECS, EC2 instances, VMs, Docker containers, building management systems (BMS), etc.). ECS instances are aggregated into groups within the VPC network using virtual subnets. Each ECS instance can connect to one or more associated network interface cards (NICs). The other endpoint of each NIC can connect to a single subnet within the VPC network. Each NIC can be associated with one or more ACLs, and each subnet can be associated with one or more NACLs and one or more routing tables. Additionally, the VPC network may include a direct-connect network gateway that provides connectivity to external networks (e.g., direct-connect, virtual private network, VPN), to other VPCs within the cloud infrastructure (e.g., VPC peering), or to the internet (e.g., network address translation, NAT, extended internet protocol, EIP).

[0008] Each of the above network elements is associated with a corresponding configuration (e.g., a router's routing table, a VPC peer's remote destination, an EIP's public IP address, a NACL's ACL rules, or a SG, etc.). A key characteristic of these configurations is that they typically support N:N mappings with individual network elements. This relationship implies the following properties: (i) replicated configurations, where a single configuration may be associated with multiple network elements (e.g., the same set of ACL rules may reside in two different NACLs); (ii) tangled configurations, where multiple network elements may have more than one associated configuration, which are treated as a single configuration according to some configuration merging mechanism (e.g., a single router associated with a series of different routing tables); and (iii) replicated network addresses, where two or more VPC network elements may be indistinguishable by observing their network characteristics (e.g., two ECSs or subnets belonging to different VPC networks in the same environment may have the same network address space).

[0009] To achieve interoperability, traditional VPC networks operate on the traditional ISO / OSI stack with IPv4 / IPv6 L3 and TCP / UDP / ICMP L4 protocols. Therefore, most network configurations are represented using header fields or intent header spaces (IHS) that include these network protocols. This means that NACL configurations can be represented using TCP / IP 5-tuples, and routing tables can consist of destination IP and next-hop ID pairs. All configurations for all VPC network services define the overall VPC network reachability policy. A reachability policy is a mapping between a pair of VPC elements (representing traffic source and destination) and their corresponding IHS (representing the allowed traffic between these two VPC elements).

[0010] The complexity of determining reachability policies in a VPC network depends on the necessity of analyzing all possible paths for a specific service flow, based on the actual traffic definition and the configuration of all network elements involved in the routing / forwarding / filtering of the service flow. This issue requires examining all possible network paths and all possible combinations of the various header fields included in the service flow definition.

[0011] Since the reachability policy of a VPC network directly affects the traffic allowed through the user network, its effectiveness requires strong guarantees for security reasons. In fact, a given reachability policy must ensure that only a defined subset of traffic is allowed to reach a given subset of network elements. When the problem scales to a certain size, existing algorithms and tools for reachability (e.g., network probing) often do not support such a strong level of guarantee. Therefore, automated reasoning and formal techniques are often used for such tasks. These techniques can include formal modeling of the network, Boolean satisfiability problems (SAT) or satisfiability modulo theory (SMT) formulas, or the use of high-level data structures (e.g., Datalog or binary decision diagram (BDD)). However, because such techniques / solutions use mathematical models to describe the problem, they provide high confidence in the obtained solutions, and, if implemented efficiently, can achieve acceptable runtime and resource utilization.

[0012] Furthermore, since service flows may traverse multiple devices, changes to reachability policies can alter the configurations of multiple network elements along those paths. Manual execution of this can lead to unexpected behaviors, such as service interruptions due to some service flows being unexpectedly blocked, or security policy violations due to some service flows being allowed to flow within sensitive parts of the VPC network. Therefore, determining reachability policies is a highly complex and tedious task.

[0013] The existing solution uses SAT encoding of network reachability policies to manage network ACLs. This existing solution provides basic reachability policy enforcement and / or modification. It is not limited to tree topologies and can be applied to any type of underlying network topology. However, it is not suitable for VPC scenarios because it cannot account for replication / merging configurations and replicated network addresses. This existing solution does not provide scalability attributes and may require more time to develop a solution.

[0014] Another existing approach uses formal techniques to find the network calibration set, i.e., a set of network elements or services whose changes can achieve the desired reachability policy between two endpoints and for a given IHS. This existing approach uses an optimization engine to determine the minimum calibration set. This existing approach is specifically designed for VPC networks. However, this existing approach cannot account for replication / merging configurations and replicated network addresses.

[0015] Another existing approach uses formal techniques to manage reachability policies within individual network elements / services. However, this existing approach also fails to account for replication / merging configurations and replicated network addresses.

[0016] Therefore, it is necessary to address the aforementioned technical issues / deficiencies in managing virtual private cloud (VPC) network configurations. Summary of the Invention

[0017] The purpose of this invention is to provide a method for managing the configuration of a virtual private cloud (VPC) network, and a system for managing the configuration of a VPC network, which also avoids one or more disadvantages of existing technologies.

[0018] This objective is achieved through the features of the independent claim. Other implementations are apparent from the dependent claims, the description, and the drawings.

[0019] This invention provides a method for managing the network configuration of a virtual private cloud (VPC), and a system for managing the network configuration of a VPC.

[0020] According to a first aspect, a method for managing the configuration of a Virtual Private Cloud (VPC) network is provided. The method includes obtaining the configuration of each virtual or physical network element in the deployed VPC network and the network topology of the deployed VPC network. The method includes defining reachability intents that include intent attributes. Intent attributes include source and destination endpoints of the service flow, the intent header space (IHS) of the network service, and a desired reachability attribute, which is either allow or deny. The method includes generating an abstract network representation of the deployed VPC network based on the obtained network element configurations and network topology. Each network element in the abstract network representation is represented as one of a network filter, a network router, and an endpoint, whereby the network filter allows or denies at least a portion of the traversing service flow, the network router modifies the path of at least a portion of the traversing service flow, and the endpoint serves as the endpoint of the service flow. The method includes converting the abstract network representation into a network reachability policy based on the Boolean Satisfactionability Problem (SAT). The method includes: updating the SAT-based network reachability policy by obtaining the logical sum of the SAT-based network reachability policy and the defined reachability intent, while ensuring that the original reachability attributes of all network elements in the deployed VPC network are not included in the defined reachability intent. The method also includes: generating a new network configuration by updating the configuration of one or more network elements in the deployed VPC network according to the updated SAT-based network reachability policy.

[0021] This method uses one or more attributes of the VPC network (such as replicated network elements or configurations (e.g., ACLs, firewalls, routing tables, etc.), replicated network addresses, and tangled configurations) to modify and generate the network configuration of the deployed VPC network. Due to the use of computational techniques, this method offers fast response times and good scalability. It can be implemented in large production VPC networks while still maintaining runtime comparable to real-time applications. This method can manage reachability policies in any tree-based network topology, or in any network that can be simplified to a tree (e.g., Clos-based data center networks, Kubernetes networks, VPC networks, etc.). This method can be used as a customer-facing cloud service or as a tool for network engineers to manage private networks.

[0022] Optionally, the definition of reachability intent includes: (i) one or more intent attributes defined by the user, and (ii) defining omitted intent attributes that have not yet been defined by the user as wildcards to generalize each omitted intent attribute to all suitable network elements.

[0023] Optionally, the method further includes, after generating the abstract network representation, sampling the abstract network representation in such a way as by removing terminal devices from the abstract network representation, except for terminal devices that do not result in a source address space or destination address space overlapping with the IHS of the defined reachability intent, terminal devices that do not have an associated address space, and terminal devices that define at least one explicit route with a mismatched destination address space within one or more network routers of the abstract network representation.

[0024] Optionally, the method further includes: after generating the abstract network representation, quantifying the network filter configuration and network router configuration by converting them into a binary decision diagram (BDD) representation. Transforming the network filter configuration may include: querying the network filter configuration to obtain a response to the IHS's traffic flow, where the response is one of allow, deny, and partial filtering results; and replacing each partial filtering result in the BDD representation with content opposite to the expected reachability attribute of the defined reachability intent.

[0025] Optionally, transforming the network router configuration includes: extracting a set of reachable devices for IHS from the network router configuration; and replacing the network router configuration in the BDD representation with a set of reachable devices.

[0026] According to the second aspect, a system for managing the configuration of a Virtual Private Cloud (VPC) network is provided. The system includes a configuration aggregation module, an intent definition module, and a reachability executor module. The configuration aggregation module is used to obtain the configuration of each virtual or physical network element in the deployed VPC network and the network topology of the deployed VPC network. The intent definition module is used to define reachability intents that include intent attributes. Intent attributes include the source and destination terminal devices of the service flow, the intent header space (IHS) of the network service, and the desired reachability attribute, which can be either allowed or denied. The reachability actuator module is configured to: (i) generate an abstract network representation of the deployed VPC network based on the acquired network element configurations and network topology, wherein each network element is presented in the abstract network representation as one of a network filter, a network router, and an end device, the network filter being used to allow or deny at least a portion of the traversing traffic flow, the network router being used to change the path of at least a portion of the traversing traffic flow, and the end device being used as an endpoint of the traffic flow; (ii) convert the abstract network representation into a network reachability policy based on the Boolean satisfiability problem (SAT); (iii) update the SAT-based network reachability policy by obtaining the logical sum of the SAT-based network reachability policy and the defined reachability intent, while keeping the original reachability attributes of all network elements of the deployed VPC network excluded from the defined reachability intent; and (iv) generate a new network configuration by updating the configurations of one or more network elements of the deployed VPC network according to the updated SAT-based network reachability policy.

[0027] This system uses one or more attributes of the VPC network (such as replicated network elements or configurations (e.g., ACLs, firewalls, routing tables, etc.), replicated network addresses, and tangled configurations) to modify and generate the network configuration of the deployed VPC network. Thanks to the use of computational technologies, the system offers fast response times and excellent scalability. It can be implemented in large production VPC networks while still maintaining runtime comparable to real-time applications. The system can manage reachability policies in any tree-based network topology, or in any network that can be simplified to a tree (e.g., Clos-based data center networks, Kubernetes networks, VPC networks, etc.). The system can be used as a customer-facing cloud service or as a tool for network engineers to manage private networks.

[0028] Optionally, the intent definition module is used to: (i) support users in defining one or more intent attributes, and (ii) define omitted intent attributes that have not yet been defined by the user as wildcards to generalize each omitted intent attribute to all suitable network elements.

[0029] Optionally, the reachability actuator module is also configured to sample the abstract network representation by removing terminal devices from the abstract network representation that do not result in a source address space or destination address space overlapping with the IHS of the defined reachability intent, terminal devices that do not have an associated address space, and terminal devices that define at least one explicit route with a mismatched destination address space within one or more network routers of the abstract network representation.

[0030] Optionally, the reachability actuator module is also used to: quantify the configuration of network filters and network routers by converting the configuration of network filters and network routers into binary decision diagram (BDD) representations.

[0031] Optionally, the reachability actuator module is used to convert the network filter configuration into a BDD representation by: querying the network filter configuration to obtain a response to the IHS's traffic flow, where the response is one of allow, deny, and partial filtering results; and replacing each partial filtering result in the BDD representation with something that is the opposite of the expected reachability attribute of the defined reachability intent.

[0032] Optionally, the reachability actuator module is used to convert the network filter configuration into a BDD representation by: extracting a set of reachable devices for IHS from the network router configuration; and replacing the network router configuration in the BDD representation with a set of reachable devices.

[0033] Therefore, unlike existing approaches, this method uses one or more attributes of the VPC network (such as replicated network elements or configurations (e.g., ACLs, firewalls, routing tables, etc.), replicated network addresses, and tangled configurations) to modify and generate the network configuration of the deployed VPC network. Due to the use of computational techniques, this method offers fast response times and good scalability. It can be implemented in large production VPC networks while still maintaining runtime comparable to real-time applications. This method can manage reachability policies in any tree-based network topology, or in any network that can be simplified to a tree (e.g., Clos-based data center networks, Kubernetes networks, VPC networks, etc.).

[0034] These and other aspects of the invention will be apparent from one or more implementations described below. Attached Figure Description

[0035] The implementation of the present invention will be described below by way of example only, with reference to the accompanying drawings.

[0036] Figure 1 This is a block diagram of a system for managing the network configuration of a virtual private cloud (VPC) according to an implementation of the present invention.

[0037] Figure 2 The workflow for managing the configuration of a virtual private cloud (VPC) network according to an implementation of the present invention is shown.

[0038] Figure 3 An exemplary diagram is shown of a network configuration abstraction for managing virtual private cloud (VPC) network configuration according to an implementation of the present invention.

[0039] Figure 4 An exemplary illustration is shown that defines an reachability intent specification for managing virtual private cloud (VPC) network configuration according to an implementation of the present invention.

[0040] Figures 5A to 5B An exemplary illustration of the preprocessing of network elements for managing the configuration of a virtual private cloud (VPC) network according to an implementation of the present invention is shown.

[0041] Figures 6A to 6B This is a flowchart of a method for managing the network configuration of a virtual private cloud (VPC) according to an implementation of the present invention.

[0042] Figure 7 It is a diagram of a computing system, in which various architectures and functions of the previous implementation methods can be realized. Detailed Implementation

[0043] The present invention provides a method for managing the network configuration of a virtual private cloud (VPC), and a system for managing the network configuration of a VPC.

[0044] To enable those skilled in the art to more easily understand the present invention, the following implementation of the present invention is described in conjunction with the accompanying drawings.

[0045] The terms “first,” “second,” “third,” and “fourth” (if any) used in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a particular sequence or order. It should be understood that such terms are interchangeable where appropriate, for example, to allow implementations of the invention described herein to be implemented in sequences other than those shown or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to the steps or units expressly listed, but may include other steps or units not expressly listed or inherent to such processes, methods, products, or apparatuses.

[0046] Figure 1This is a block diagram of a system for managing the configuration of a Virtual Private Cloud (VPC) network according to an implementation of the present invention. The system includes a configuration aggregation module 102, an intent definition module 104, and a reachability executor module 106. The configuration aggregation module 102 is used to obtain the configuration of each virtual or physical network element 108 (e.g., access control list (ACL), route table (RTB)) in the deployed VPC network and the network topology 110 of the deployed VPC network. The intent definition module 104 is used to define reachability intents 112 including intent attributes. Intent attributes include the source and destination terminal devices of the service flow, the intent header space (IHS) of the network service, and a desired reachability attribute, which is either allowed or denied. The reachability executor module 106 is used to generate an abstract network representation of the deployed VPC network based on the obtained configuration of the network elements 108 and the network topology 110. Each network element 108 is represented in the abstract network representation as one of a network filter (e.g., ACL), a network router, and an end device 118 (e.g., network device 1, network device 2, etc.). The network filter is used to allow or deny (e.g., filter) at least a portion of the traversing traffic flow. The network router is used to change the path of at least a portion of the traversing traffic flow. The end device 118 serves as the endpoint of the traffic flow. The reachability executor module 106 is used to convert the abstract network representation into a network reachability policy based on the Boolean satisfiability problem (SAT). The reachability executor module 106 is used to update the SAT-based network reachability policy by obtaining the logical sum of the SAT-based network reachability policy and the defined reachability intent 112, while ensuring that the original reachability attributes of all network elements 108 in the deployed VPC network are not included in the defined reachability intent 112. The reachability executor module 106 is used to generate a new network configuration by updating the configuration of one or more network elements 108 in the deployed VPC network according to the updated SAT-based network reachability policy.

[0047] This system uses one or more attributes of the VPC network (such as replicated network elements or configurations (e.g., ACLs, firewalls, routing tables, etc.), replicated network addresses, and tangled configurations) to modify and generate the network configuration of the deployed VPC network. Thanks to the use of computational technologies, the system offers fast response times and excellent scalability. It can be implemented in large production VPC networks while still maintaining runtime comparable to real-time applications. The system can manage reachability policies in any tree-based network topology, or in any network that can be simplified to a tree (e.g., Clos-based data center networks, Kubernetes networks, VPC networks, etc.). The system can be used as a customer-facing cloud service or as a tool for network engineers to manage private networks.

[0048] This system enforces reachability attributes between pairs of nodes / elements within a VPC network while preserving reachability attributes between other nodes. The system supports user-specified VPC configurations or given objective functions, thereby reducing capital costs. It also utilizes replicated network configurations / elements, replicated network addresses, and tangled network configurations / elements to manage VPC network configurations. This system provides a flexible approach to generating new configurations, rather than simply editing existing ones, while maintaining reachability attributes within the VPC network.

[0049] This system not only verifies the correctness of the VPC network deployment or the correctness of the identification of network element 108, but also generates the VPC network configuration based on user intent. The system uses replicated configurations or network elements, replicated network addresses, and tangled network configurations / elements to ensure the correctness of the generated VPC network configuration. The system also provides scalability and performance in large VPC network deployments while still ensuring the formal correctness of the generated configuration. The system can enrich user intent with additional cost functions to optimize specific metrics. These metrics can be the number of network configuration changes or the overall cost of the solution (financial or performance costs).

[0050] Optionally, the deployed VPC network includes virtual or physical network elements 108 (e.g., ACL-1-6, RTB-1, RTBL-1, etc.) interconnected via communication links. End devices 118A to 118C (e.g., network device 1, network device 2, and network device 3, etc.) can allow network traffic to flow and filter and / or route at least a portion of the traffic present in the deployed VPC network. Optionally, virtual or physical network elements 108 can generate network flows. Optionally, the VPC network includes a virtual or physical network 114, which represents the actual network to be operated. Virtual or physical network 114 can be any virtual or physical network that can be scaled down to a topology. Virtual or physical network 114 can include network elements 108 / services, which represent packet network filters / routers. Examples of network filters include network access control lists (NACLs), security groups (SGs), firewalls, VPC pairs, etc. The deployed VPC network configuration includes a list of rules that maps the header space or intent header space (IHS) to allowed or denied operations. Examples of network routers include elastic load balancers (ELBs), transport gateways, etc. The deployed VPC network configuration may include a list of rules that maps the header space or IHS to the next-hop network element. Optionally, end devices (e.g., 118A through 118C) can be source or destination endpoints of traffic flows. Examples of end devices (e.g., 118A through 118C) include elastic container services (ECS), bare metal servers (BMS), managed cloud services, and elastic internet protocol (EIP). The deployed VPC network configuration may include at least an associated unique identifier (ID) or an associated internet protocol (IP) address.

[0051] Optionally, the configuration of each virtual or physical network element 108 can be accessed through the configuration aggregation module 102. The configuration aggregation module 102 aggregates / obtains the network configuration of each network element 108 in the deployed VPC network. To obtain the available network configuration of each network element 108, the system can utilize existing tools and technologies or general user-oriented technologies 120 (e.g., cloud-specific software development kits (SDKs), application programming interfaces (APIs), graphical user interfaces (GUIs), web gateways, configuration dump mechanisms, etc.). The configuration aggregation module 102 extracts the network topology 110 of the deployed VPC network to obtain the network configuration of each network element 108. Therefore, the configuration aggregation module 102 can identify the virtual or physical links between each network element 108 and their characteristics. Furthermore, the configuration aggregation module 102 provides all details regarding the network configuration of the network elements 108 and the network topology 110 of the deployed VPC network.

[0052] Optionally, the intent definition module 104 is used to: (i) support users in defining one or more intent attributes, and (ii) define omitted intent attributes that have not yet been defined by the user as wildcards to generalize each omitted intent attribute to all appropriate network elements. For example, omitting the header space or IHS can apply the desired reachability policy to traffic present in the deployed VPC network. Similarly, omitting the destination device may result in the desired reachability attribute being applied to all possible destination devices. Optionally, the defined reachability intent 112 is specified through a common user-oriented technology 120 (e.g., SDK, API, GUI, etc.). Optionally, the intent definition module 104 provides users with the possibility to specify certain desired reachability / security attributes to be applied in the deployed VPC network. The intent definition module 104 may support specifying desired reachability attributes through a set of network element weights 116.

[0053] Optionally, the reachability actuator module 106 further includes a network element preprocessing module 124 for preprocessing network elements 108. The network element preprocessing module 124 converts the network configuration into its formal configuration representation or abstract network representation, and reduces the dimensionality of the total network elements 108 and the size of the network configuration. The network element preprocessing module 124 may also perform two steps: (i) network element sampling / filtering, and (ii) network element quantization. Optionally, the network element preprocessing module 124 is also used to sample / filter the abstract network representation by removing terminal devices 118A to 118C from the abstract network representation, except for terminal devices 118A to 118C that do not result in a source address space or destination address space overlapping with the IHS (e.g., TCP / IP 5-tuple) of the defined reachability intent 112, terminal devices 118A to 118C that do not have an associated address space, and terminal devices 118A to 118C that define at least one explicit route with a mismatched destination address space within one or more network routers of the abstract network representation. Optionally, the reachability actuator module 106 securely and demonstrably executes custom intents. Optionally, the network element preprocessing module 124 is used to quantify the network filter configuration and network router configuration by converting the network filter configuration and network router configuration into a binary decision diagram (BDD) representation.

[0054] Optionally, the reachability executor module 106 further includes a model generation module 126, used to convert the quantized and sampled / filtered network elements 108 in the abstract network representation into their formal representation. This formal representation captures the relationships between each network element 108 in an analytical manner and provides a SAT-based representation of the entire network reachability policy. That is, the model generation module 126 is used to: convert the abstract network representation into a SAT-based network reachability policy; and update the SAT-based network reachability policy by obtaining the logical sum of the SAT-based network reachability policy and the defined reachability intent 112, while maintaining that the original reachability attributes of all network elements 108 of the deployed VPC network are not included in the defined reachability intent 112. The model generation module 126 is also used to: generate a new network configuration by updating the configuration of one or more network elements 108 of the deployed VPC network according to the updated SAT-based network reachability policy.

[0055] The reachability actuator module 106 is used to: obtain a response to the IHS's traffic flow by querying the network filter configuration, and convert the network filter configuration into a BDD representation. This response can be one of allow, deny, or partial filtering results. Each partial filtering result in the BDD representation is replaced with something contrary to the desired reachability attribute of the defined reachability intent 112 (e.g., allow or deny).

[0056] Optionally, the reachability actuator module 106 is used to convert the network filter configuration into a BDD representation by: extracting a set of reachable devices for IHS from the network router configuration; and replacing the network router configuration in the BDD representation with a set of reachable devices.

[0057] Optionally, the reachability executor module 106 further includes: a scheme generation module 128, for applying the generated new network configuration to the VPC network to achieve user intent; and a network rule synthesis module 130, for generating actual ACL rules and / or routing rules and inserting them into given locations within the affected ACLs / RTBLs of the VPC network. Optionally, the output of the scheme generation module 128 is a set of network filters / routers that need to be changed / added.

[0058] Optionally, the user connects to the system using a public / private access network 122 via a customer-facing technology 120 (e.g., cloud-specific SDK, API, GUI, web gateway, configuration dump mechanism, etc.) and specifies a desired reachability intent 112 (e.g., ECS reachability, subnet isolation). Optionally, the reachability executor module 106 obtains the latest network configuration from the configuration aggregation module 102 and combines it with the desired reachability intent 112. Optionally, the reachability executor module 106 obtains a network model and performs formal reasoning to find a set of configurations that satisfy the user's intent.

[0059] Figure 2 A workflow for managing a Virtual Private Cloud (VPC) network configuration according to an implementation of the present invention is illustrated. First, the network configuration 202 of each virtual or physical network element in the deployed VPC network and the network topology 210 of the deployed VPC network are obtained. Then, an reachability intent 212 is defined. The reachability intent 212 includes intent attributes. Intent attributes include the source and destination terminal devices of the service flow, the intent header space (IHS) of the network service, and a desired reachability attribute, which is either allowed or denied. Optionally, the definition of the reachability intent 212 includes: (i) one or more intent attributes defined by the user, and (ii) defining omitted intent attributes not yet defined by the user as wildcards to generalize each omitted intent attribute to all suitable network elements.

[0060] During the network element preprocessing (204) step of this process, the network configuration 202 of each virtual or physical network element is converted into an abstract network representation or formal configuration representation 220. During network element preprocessing 204, an abstract network representation 220 of the deployed VPC network is generated based on the acquired network element configuration and network topology 210. Each network element is represented in the abstract network representation as one of a network filter 206, a network router 208, and an end device. The network filter 206 is used to allow or deny at least a portion of the traversing traffic flow. The network router 208 is used to change the path of at least a portion of the traversing traffic flow. The end device serves as the endpoint of the traffic flow.

[0061] Optionally, network element preprocessing 204 further includes the following two steps: (i) network element sampling / filtering 218, and (ii) network element quantization 222. Optionally, during network element sampling / filtering 218, after generating the abstract network representation 220, the abstract network representation 220 is sampled / filtered by removing terminal devices from the abstract network representation that do not result in a source address space or destination address space overlapping with the IHS of the defined reachability intent 212, terminal devices without associated address spaces, and terminal devices that define at least one explicit route with a mismatched destination address space within one or more network routers 208 of the abstract network representation 220. Optionally, during network element quantization 222, after generating the abstract network representation 220, the configuration of network filters 206 and network routers 208 is quantized by converting the configuration into a binary decision diagram (BDD) representation. Network element preprocessing 204 helps reduce the dimensionality of the total network elements and the size of the network configuration 202.

[0062] Transforming the network filter configuration may include querying the network filter configuration to obtain a response to the IHS's traffic flow. This response may be one of allow, deny, or partial filtering results. Each partial filtering result in the BDD representation is replaced with something contrary to the expected reachability attribute of the defined reachability intent 212. Optionally, transforming the network router configuration includes: extracting a set of reachable devices for the IHS from the network router configuration; and replacing the network router configuration in the BDD representation with a set of reachable devices.

[0063] During the model generation (214) step of this process, the quantized and sampled / filtered network elements in the abstract network representation 220 are transformed into their formal representation. This formal representation captures the relationships between each network element in an analytical manner and provides a SAT-based representation of the overall network reachability policy. Optionally, model generation 214 provides details about the network configuration 202 and the network topology 210. During model generation 214, the abstract network representation 220 is transformed into a network reachability policy based on the Boolean satisfiability problem (SAT), which is updated by obtaining the logical sum of the SAT-based network reachability policy and the defined reachability intent 212, while keeping the original reachability attributes of all network elements in the deployed VPC network excluded from the defined reachability intent 212. Furthermore, during model generation 214, a new network configuration is generated by updating the configuration of one or more network elements in the deployed VPC network according to the updated SAT-based network reachability policy.

[0064] Optionally, the model generation (214) process encodes dependencies across network elements / configurations and generates target reachability constraints and security maintenance constraints. The encoding of dependencies across network elements / configurations includes the following steps: basic reachability encoding 224, operational reachability encoding 226, reachability maintenance encoding 228, and target reachability encoding 230.

[0065] To obtain / formulate the logical sum of the SAT-based network reachability strategy and the defined reachability intent 212, it is necessary to consider the unquantified network and decision variables given in Table 1.

[0066] Table 1

[0067]

[0068]

[0069] Optionally, each network filter 206 is associated with a set of header spaces or intent header spaces (IHS) that provide the behavior for VPC network configuration. The header spaces or IHS are defined as explicit allow, deny, and match header spaces, respectively. Since a single node / network element may be associated with multiple configurations, it is necessary to define an appropriate node filtering encoding function c(f1,..,f n This function will apply all filtering configurations associated with the node / network element. Convert them into their composite representation. This function is recursively defined as:

[0070]

[0071] in:

[0072]

[0073] According to this definition, the total allowed head space R on node n is... n Defined as:

[0074]

[0075] A pair of nodes in a three-level tree topology The total allowed flow between them is expressed as:

[0076]

[0077] Where P(n) is defined as a node The parent node.

[0078] Alternatively, the above expression / equation can be easily extended to an n-layer tree topology using a recursive formula, such as in the node filtering encoding function. For simplicity, consider a three-layer (i.e., ECS-Subnet-VPC) tree topology. The equation above represents the traffic that can flow between a given pair of nodes. To design an algorithm that can modify the above formula to implement a desired target reachability strategy for a specific set of nodes, the above-formulated expression / equation is modified to include a set of decision variables. Logically, decision variables allow the omission of the normal expression for allowed traffic on any given configuration or network device. For network configurations, this is done by encoding conditions, i.e., if a decision variable is set to a certain headspace, the set headspace is returned; otherwise, the normally allowed headspace is returned. If both allow and deny queries need to be supported simultaneously, two types of decision variables must be introduced for each network element and filter. A new expression becomes a ternary expression of the form: "If the allowed decision variable is set to some headspace, then return the headspace; otherwise, if the deny decision variable is set to some headspace, return the negative headspace; otherwise, return the normally allowed headspace."

[0079] Therefore, the operable node filtering encoding function is a(f1,..,f n The expression for ) is defined as:

[0080]

[0081] in:

[0082]

[0083] The above expression allows adding explicit deny / explicit allow or explicit routing rules to a set of configurations associated with a single node / network element. In many cases, a node may not have any associated configurations, or no configurations existing in the network (e.g., adding an Elastic Internet Protocol (EIP) to an Elastic Container Service (ECS) without any configuration). To address this, an additional set of node ternary decision variables is defined that encode the above requirements, as follows:

[0084]

[0085] Given the above formula, the operable filter expression is defined as:

[0086]

[0087] Finally, based on the above-formulated equation, the logical sum of the SAT-based network reachability policy and the defined reachability intent 212 is obtained, while ensuring that the original reachability attributes of all network elements in the deployed VPC network are not included in the defined reachability intent 212, to update the SAT-based network reachability policy. The logical sum is defined as follows:

[0088]

[0089] as well as

[0090]

[0091] To satisfy the above constraints, Φ is required. (A) ,Φ (D) ,Ψ (A) ,Ψ (D) Find appropriate values ​​for all elements. This assignment guarantees that only... and Reachability strategies between these two points may be affected, while all other end-to-end reachability strategies may remain unaffected.

[0092] Optionally, during the scheme generation (216) step of this process, the generated new network configuration is applied to the VPC network to achieve the user intent. The scheme generation (216) step minimizes the configuration cost 232. The configuration cost 232 may be related to the cost of adding explicit allow / deny rules or to generating the new network configuration. Optionally, the output of the scheme generation (216) step is a set of network filters / routers that need to be changed / added.

[0093] During the network rule synthesis (234) step of this process, in order to modify the output of scheme generation (216), actual access control list (ACL) rules and / or routing rules are generated and inserted into given locations within the affected ACL / RTBL of the VPC network. The actual ACL rules and / or routing rules can be generated by appending the corresponding action (i.e., allow or deny) to the IHS at the beginning of the affected ACL and appending the corresponding routing action to the IHS at the beginning of the affected RTBL.

[0094] Figure 3 An exemplary diagram of a network configuration abstraction for managing a Virtual Private Cloud (VPC) network configuration according to an implementation of the present invention is shown. The network configuration 302 of each virtual or physical network element in the deployed VPC network and the network topology 304 of the deployed VPC network are obtained. Optionally, each node or network element is abstracted based on the network behavior of each node or network element in the deployed VPC network. The network topology 304 is obtained based on the actual network elements (e.g., ECS, subnets, VPCs) present in the network. Based on the obtained network element configurations and the network topology 304, each network element within the network topology 304 is abstracted or presented as an abstract network representation 306 (i.e., a network filter / router chain). Each network element is presented in the abstract network representation 306 as one of a network filter, a network router, and an end device. The network filter is used to allow or deny at least a portion of a passing traffic flow (e.g., ACL1, ACL2, etc.). The network router is used to change the path of at least a portion of the passing traffic flow. The end device serves as the endpoint of the traffic flow.

[0095] Figure 4An exemplary illustration is shown of an reachability intent specification for managing a Virtual Private Cloud (VPC) network configuration, as defined according to an implementation of the present invention. Reachability intent 402 includes intent attributes defined to manage the VPC network configuration. Intent attributes include a source node or endpoint 404 and a destination node or endpoint 406 (e.g., ECS1, ECS4, etc.) of the service flow, an intent header space (IHS) 408 of the network service, and a desired reachability attribute 410 or target action, which is either allowed or denied. Optionally, IHS 408 includes a source IP address, a destination IP address, a protocol, a source port, and a destination port. Optionally, reachability intent 402 is defined by: (i) defining one or more intent attributes by a user, and (ii) defining omitted intent attributes not yet defined by the user as wildcards to generalize each omitted intent attribute to all suitable network elements.

[0096] Figures 5A to 5B An exemplary illustration of the preprocessing of network elements for managing a Virtual Private Cloud (VPC) network configuration according to an implementation of the present invention is shown. During network element preprocessing, the network configuration of each virtual or physical network element is converted into an abstract network representation. The abstract network representation of the deployed VPC network is then generated based on the acquired network element configurations and network topology. Each network element is presented in the abstract network representation as one of a network filter, a network router, and an end device. The network filter is used to allow or deny at least a portion of the traversing traffic flow. The network router is used to change the path of at least a portion of the traversing traffic flow. The end device serves as the endpoint of the traffic flow. Network element preprocessing helps reduce the dimensionality of the total network elements and the size of the network configuration.

[0097] Optionally, network element preprocessing further includes the following two steps: (i) network element sampling / filtering 502, and (ii) network element quantization 504. Optionally, in such... Figure 5ADuring the network element sampling / filtering 502 shown, after generating the abstract network representation, the abstract network representation is sampled / filtered in the following ways: terminal devices are removed from the abstract network representation that do not result in a source address space or destination address space overlapping with the intent header space (IHS) of the defined reachability intent, terminal devices that do not have an associated address space, and terminal devices that define at least one explicit route with a mismatched destination address space within one or more network routers of the abstract network representation. Network element sampling / filtering 502 reduces the total number of network elements present in the network's abstract network representation.

[0098] For example, the IHS defined in the reachability intent includes the source IP address space 1.1.1.1 / 32, the destination IP address space 2.2.2.0 / 24, and the destination TCP port 22. All network elements without associated IP addresses in the ranges of 2.2.2.0 to 2.2.2.255 or 1.1.1.1 can be removed from the network topology. That is, even if the IHS traffic between filtered end devices is affected by configuration changes, the overall reachability policy can remain unchanged due to default traffic filtering at the end devices (e.g., traffic filtering for mismatched IPs). Network sampling or filtering is not performed on devices that: (i) do not include end devices with associated address spaces (e.g., Elastic Internet Protocol (EIP) can provide connectivity to the entire public IP), or (ii) have at least one explicit route defined within one or more network routers with a mismatched destination address space (e.g., there is a route in the network for traffic destined for 2.2.2.0 / 24 via a host with associated IP address 1.1.1.1 / 32).

[0099] Optionally, in such Figure 5B During the network element quantization 504 process shown, after generating the abstract network representation, the configuration of network filters and network routers is quantified by converting the configuration into a binary decision diagram (BDD) representation.

[0100] The element quantization (504) step quantifies the behavior of network elements in response to the transport traffic defined by IHS. For quantization, the network configuration is converted into a corresponding binary decision diagram (BDD) representation. For network filters and network routers, each line of the configuration file is converted by representing the associated header space as a BDD representation. For network filters, the BDD representation is negated after construction only in the case of a "reject" configuration line. For both network elements, quantization is performed by iteratively applying a sequence of Boolean operations to the BDD representations negated for each individual configuration line and the BDD representations negated by IHS.

[0101] Optionally, the transformation of network filter configurations may include querying the network filter configuration to obtain a response to IHS traffic flows. This response may be one of allow, deny, or partial filtering results. Each partial filtering result in the BDD representation is replaced with the opposite of the expected reachability attribute of the defined reachability intent (e.g., if the expected reachability attribute is "allow," the partial filtering / quantization result is replaced with "deny"). After configuration quantization is performed, each profile associated with the network filter is replaced with the quantized filtering result (i.e., "allow" or "deny").

[0102] Optionally, transforming the network router configuration includes: extracting a set of reachable devices for IHS from the network router configuration; and replacing the network router configuration in the BDD representation with the set of reachable devices. Reachable devices are extracted by considering the next-hop field in the network router configuration. After quantization is performed, each profile associated with the network router will be replaced with the extracted set of reachable devices.

[0103] Figures 6A to 6BThis is a flowchart of a method for managing the configuration of a Virtual Private Cloud (VPC) network according to an implementation of the present invention. In step 602, the configuration of each virtual or physical network element in the deployed VPC network and the network topology of the deployed VPC network are obtained. In step 604, reachability intents are defined. Reachability intents include intent attributes. Intent attributes include the source and destination terminal devices of the service flow, the intent header space (IHS) of the network service, and a desired reachability attribute, which is either allow or deny. In step 606, an abstract network representation of the deployed VPC network is generated based on the obtained network element configurations and network topology. Each network element in the abstract network representation is represented as one of a network filter, a network router, and a terminal device. The network filter is used to allow or deny at least a portion of the traversing service flow, the network router is used to change the path of at least a portion of the traversing service flow, and the terminal device serves as the endpoint of the service flow. In step 608, the abstract network representation is converted into a network reachability policy based on the Boolean Satisfactionability Problem (SAT). In step 610, the SAT-based network reachability policy is updated by obtaining the logical sum of the SAT-based network reachability policy and the defined reachability intent, while ensuring that the original reachability attributes of all network elements in the deployed VPC network are not included in the defined reachability intent. In step 612, a new network configuration is generated by updating the configuration of one or more network elements in the deployed VPC network according to the updated SAT-based network reachability policy.

[0104] This method uses one or more attributes of the VPC network (such as replicated network elements or configurations (e.g., ACLs, firewalls, routing tables, etc.), replicated network addresses, and tangled configurations) to modify and generate the network configuration of the deployed VPC network. Due to the use of computational techniques, this method offers fast response times and good scalability. It can be implemented in large production VPC networks while still maintaining runtime comparable to real-time applications. This method can manage reachability policies in any tree-based network topology, or in any network that can be simplified to a tree (e.g., Clos-based data center networks, Kubernetes networks, VPC networks, etc.). This method can be used as a customer-facing cloud service or as a tool for network engineers to manage private networks.

[0105] This method enforces reachability attributes between a pair of nodes / elements within a VPC network while preserving reachability attributes between the remaining nodes. It allows users to specify the desired VPC configuration or a given objective function, thereby reducing capital costs. The method also utilizes replicated network configurations / elements, replicated network addresses, and tangled network configurations / elements to manage VPC network configurations. This approach provides a flexible method for generating new configurations, rather than simply editing existing ones, while maintaining reachability attributes within the VPC network.

[0106] This method not only verifies the correctness of VPC network deployment or the correctness of network element identification, but also generates VPC network configurations based on user intent. It uses replicated configurations or network elements, replicated network addresses, and tangled network configurations / elements to ensure the correctness of the generated VPC network configuration. This method also provides scalability and performance in large VPC network deployments while still ensuring the formal correctness of the generated configuration. The method can enrich user intent with additional cost functions to optimize specific metrics. These metrics can be the number of network configuration changes or the overall cost of the solution (financial or performance costs).

[0107] Optionally, the definition of reachability intent includes: (i) one or more intent attributes defined by the user, and (ii) defining omitted intent attributes that have not yet been defined by the user as wildcards to generalize each omitted intent attribute to all suitable network elements.

[0108] Optionally, the method further includes, after generating the abstract network representation, sampling the abstract network representation in such a way as by removing terminal devices from the abstract network representation, except for terminal devices that do not result in a source address space or destination address space overlapping with the IHS of the defined reachability intent, terminal devices that do not have an associated address space, and terminal devices that define at least one explicit route with a mismatched destination address space within one or more network routers of the abstract network representation.

[0109] Optionally, the method further includes: after generating the abstract network representation, quantifying the network filter configuration and network router configuration by converting them into a binary decision diagram (BDD) representation. Transforming the network filter configuration may include: querying the network filter configuration to obtain a response to the IHS's traffic flow, where the response is one of allow, deny, and partial filtering results; and replacing each partial filtering result in the BDD representation with content opposite to the expected reachability attribute of the defined reachability intent.

[0110] Optionally, transforming the network router configuration includes: extracting a set of reachable devices for IHS from the network router configuration; and replacing the network router configuration in the BDD representation with a set of reachable devices.

[0111] Figure 7 This is a diagram of a computing system that can implement various architectures and functions of the previously described implementations. As shown, computer system 700 includes at least one processor 704 connected to bus 702. Computer system 700 can be implemented using any suitable protocol, such as peripheral component interconnect (PCI), PCI-Express, accelerated graphics port (AGP), HyperTransport, or any other bus or point-to-point communication protocol. Computer system 700 also includes memory 706.

[0112] The control logic (software) and data are stored in memory 706, which may take the form of random-access memory (RAM). In this invention, a single semiconductor platform can refer to a unique integrated circuit or chip based on a single semiconductor. It should be noted that the term "single semiconductor platform" can also refer to multi-chip modules with increased connectivity, simulating on-chip modules with increased connectivity and on-chip operations, and representing a substantial improvement over implementations using traditional central processing units (CPUs) and buses. Of course, depending on the user's needs, various modules can also be placed individually or in various combinations of semiconductor platforms.

[0113] The computer system 700 may also include auxiliary storage 710. For example, auxiliary storage 710 includes hard disk drives and removable storage drives, including floppy disk drives, magnetic tape drives, compact disk drives, digital versatile disk (DVD) drives, recording devices, and universal serial bus (USB) flash memory. The removable storage drives read from and / or write to the removable storage unit in a well-known manner.

[0114] Computer programs or computer control logic algorithms may be stored in at least one of the memory 706 and the auxiliary memory 710. When executed, these computer programs enable the computer system 700 to perform the various functions described above. The memory 706, the auxiliary memory 710, and any other memory are possible examples of computer-readable media.

[0115] In one implementation, the architecture and functionality described in the preceding figures can be implemented in the context of processor 704, a graphics processor coupled to communication interface 712, an integrated circuit (not shown) capable of having at least a portion of the capabilities of processor 704 and graphics processor, and a chipset (i.e., a set of integrated circuits designed to operate and be sold as units performing related functions, etc.).

[0116] Furthermore, the architecture and functionality described in the various figures above can be implemented within the context of general computer systems, circuit board systems, game console systems designed for entertainment purposes, and application-specific systems. For example, computer system 700 can take the form of a desktop computer, laptop computer, server, workstation, game console, or embedded system.

[0117] Furthermore, the computer system 700 can take the form of various other devices, including but not limited to personal digital assistant (PDA) devices, mobile phone devices, smartphones, televisions, etc. Additionally, although not shown, the computer system 700 can be coupled to a network (e.g., telecommunications networks, local area networks (LANs), wireless networks, wide area networks (WANs) such as the Internet, peer-to-peer networks, cable networks, etc.) via I / O interface 708 for communication.

[0118] It should be understood that the arrangement of components shown in the described figures is exemplary, and other arrangements are possible. It should also be understood that the various system components (and modules) defined by the claims, described below, and shown in the various block diagrams represent components in some systems configured according to the subject matter disclosed herein. For example, one or more of these system components (and modules) may be implemented, in whole or in part, by at least some of the components in the arrangements shown in the described figures.

[0119] Furthermore, while at least one of these components is implemented at least partially as an electronic hardware component and thus constitutes a machine, the other components may be implemented as software, which, when included in the execution environment, constitutes a machine, hardware, or a combination of software and hardware.

[0120] While the invention and its advantages have been described in detail, it should be understood that various changes, substitutions and modifications may be made without departing from the spirit and scope of the invention as defined in the appended claims.

Claims

1. A method for managing the network configuration of a virtual private cloud (VPC), characterized in that, The method includes: Obtain the configuration of each virtual or physical network element (108) in the deployed VPC network and the network topology (110, 210, 304) of the deployed VPC network. The definition includes reachability intents (112, 212, 402) with intent attributes, which include the source and destination terminal devices of the service flow (404, 406), the intent header space (IHS) of the network service (408), and a desired reachability attribute (410), which is either allowed or denied. Based on the obtained network element configuration and network topology, an abstract network representation (220, 306) of the deployed VPC network is generated, wherein each network element is presented in the abstract network representation as one of a network filter (206), a network router (208), and a terminal device. The network filter (206) is used to allow or deny at least a portion of the passing traffic flow, the network router (208) is used to change the path of at least a portion of the passing traffic flow, and the terminal device serves as the endpoint of the traffic flow. The abstract network representation is then converted into a network reachability strategy based on the Boolean satisfiability problem (SAT). The SAT-based network reachability policy is updated by obtaining the logical sum of the SAT-based network reachability policy and the defined reachability intent, while ensuring that the original reachability attributes of all network elements in the deployed VPC network are not included in the defined reachability intent. A new network configuration is generated by updating the configuration of one or more network elements of the deployed VPC network according to the updated SAT-based network reachability policy.

2. The method according to claim 1, characterized in that, The reachability intent is defined as including: The user defines one or more intent attributes from the intent attributes. The omitted intent attributes that have not yet been defined by the user are defined as wildcards to generalize each omitted intent attribute to all appropriate network elements.

3. The method according to claim 1 or 2, characterized in that, Also includes: After generating the abstract network representation The abstract network representation is sampled by removing terminal devices from the abstract network representation, except for terminal devices that do not result in a source address space or destination address space overlapping with the IHS of the defined reachability intent, terminal devices that do not have an associated address space, and terminal devices that define at least one explicit route with a mismatched destination address space within one or more network routers in the abstract network representation.

4. The method according to any one of claims 1 to 3, characterized in that, Also includes: After generating the abstract network representation, the configurations of the network filters and the network routers are quantified by converting them into binary decision diagram (BDD) representations.

5. The method according to claim 4, characterized in that, Transforming the network filter configuration includes: querying the network filter configuration to obtain a response to the IHS's traffic flow, wherein the response is one of allow, deny, and partial filtering results; and replacing each partial filtering result in the BDD representation with content that is the opposite of the desired reachability attribute of the defined reachability intent.

6. The method according to claim 4 or 5, characterized in that, The process of transforming the network router configuration includes: extracting a set of reachable devices for the IHS from the network router configuration; and replacing the network router configuration in the BDD representation with the set of reachable devices.

7. A system for managing the network configuration of a virtual private cloud (VPC), characterized in that, include: The configuration aggregation module (102) is used to obtain the configuration of each virtual or physical network element (108) in the deployed VPC network and the network topology (110, 210, 304) of the deployed VPC network. The intent definition module (104) is used to define reachability intents (112, 212, 402) including intent attributes. These intent attributes include the source and destination terminal devices of the service flow (404, 406), the intent header space (IHS) of the network service (408), and a desired reachability attribute (410), which can be either allowed or denied. Reachability actuator module (106), used for: An abstract network representation (220, 306) of the deployed VPC network is generated based on the obtained network element configuration and network topology. Each network element in the abstract network representation is presented as one of a network filter (206), a network router (208), and a terminal device (118). The network filter (206) is used to allow or deny at least a portion of the passing service flow. The network router (208) is used to change the path of at least a portion of the passing service flow. The terminal device (118) serves as an endpoint of the service flow. The abstract network representation is then converted into a network reachability strategy based on the Boolean satisfiability problem (SAT). The SAT-based network reachability policy is updated by obtaining the logical sum of the SAT-based network reachability policy and the defined reachability intent, while ensuring that the original reachability attributes of all network elements in the deployed VPC network are not included in the defined reachability intent. A new network configuration is generated by updating the configuration of one or more network elements of the deployed VPC network according to the updated SAT-based network reachability policy.

8. The system according to claim 7, characterized in that, The intent definition module is used for: Users can define one or more intent attributes among the intent attributes. The omitted intent attributes that have not yet been defined by the user are defined as wildcards to generalize each omitted intent attribute to all appropriate network elements.

9. The system according to claim 7 or 8, characterized in that, The reachability actuator module is also used for: The abstract network representation is sampled by removing terminal devices from the abstract network representation, except for terminal devices that do not result in a source address space or destination address space overlapping with the IHS of the defined reachability intent, terminal devices that do not have an associated address space, and terminal devices that define at least one explicit route with a mismatched destination address space within one or more network routers in the abstract network representation.

10. The system according to any one of claims 7 to 9, characterized in that, The reachability actuator module is further configured to: quantify the configuration of the network filter and the configuration of the network router by converting the configuration of the network filter and the configuration of the network router into a binary decision diagram (BDD) representation.

11. The system according to claim 10, characterized in that, The reachability actuator module is used to convert the network filter configuration into the BDD representation by: querying the network filter configuration to obtain a response to the IHS traffic flow, wherein the response is one of allow, deny, and partial filtering results; and replacing each partial filtering result in the BDD representation with content that is the opposite of the expected reachability attribute of the defined reachability intent.

12. The system according to claim 10 or 11, characterized in that, The reachability actuator module is used to convert the network filter configuration into the BDD representation by: extracting a set of reachable devices for the IHS from the network router configuration; and replacing the network router configuration in the BDD representation with the set of reachable devices.

Images