Cloud network reachability analysis for virtual private clouds

Abstract

A method (1200) for providing cloud network reachability analysis includes receiving a reachability query (20) that requests the reachability status (172) of a target (70, 250, 1110), the reachability query (20) including a packet header (22) associated with a data packet (24). The packet header includes a source IP address (25a) and a destination IP address (25b). The method further includes generating one or more simulated forwarding paths (80) for the data packet based on the packet header using a data plane model (164). Each simulated forwarding path contains corresponding network configuration information (162). The method includes determining the reachability status of a target based on the one or more simulated forwarding paths and providing the determined reachability status and the one or more simulated forwarding paths to a user equipment (10) associated with the reachability query, causing the user equipment to present the network configuration information for each simulated forwarding path.

Description

[0001] This application is a divisional application of the following application:

[0002] International application number of the original application: PCT / US2020 / 026729

[0003] International filing date of the original application: April 3, 2020

[0004] The original application's national application number was 202080040858.4.

[0005] Original invention title: Cloud Network Reachability Analysis Technical Field

[0006] This disclosure relates to the reachability analysis of cloud networks. Background Technology

[0007] A Virtual Private Cloud (VPC) is a pool of on-demand, configurable, shared computing resources allocated within a public cloud environment. A VPC provides isolation between users and other cloud users. A VPC can run one or more virtual machines (VMs), which can communicate with the user's on-premises network or other remote resources via a Virtual Private Network (VPN). Due to the potential size and complexity of VPCs, which may include any number of VMs, network gateways, load balancers, etc., significant network configuration is typically required to operate and maintain a VPC. Summary of the Invention

[0008] One aspect of this disclosure provides a method for providing cloud network reachability analysis. The method includes receiving, at data processing hardware, a reachability query for the reachability status of a requested target. The reachability query includes a packet header associated with a data packet. The packet header includes a source Internet Protocol (IP) address associated with the source of the data packet and a destination IP address associated with the destination of the data packet. The analysis also includes generating one or more simulated forwarding paths for the data packet based on the packet header using a data plane model by the data processing hardware. Each simulated forwarding path contains corresponding network configuration information. The method further includes determining the reachability status of the target based on the one or more simulated forwarding paths by the data processing hardware. The method also includes providing the determined reachability status and the one or more simulated forwarding paths to a user equipment associated with the reachability query by the data processing hardware. When the one or more simulated forwarding paths are received by the user equipment, the user equipment presents the network configuration information for each simulated forwarding path.

[0009] Implementations of this disclosure may include one or more of the following optional features. In some embodiments, determining the reachability state of the one or more simulated forwarding paths includes using a network abstraction state machine. The user equipment may be configured to send the packet from a remote network using locally advertised routes. In some examples, the network configuration information includes at least one of the following: a port / interface for routing the packet within a Virtual Private Cloud (VPC) network; a port / interface for routing the packet between VPC networks; a port / interface for routing the packet between VPC networks and non-VPC networks; firewall rules applied to the packet at each step along the respective simulated forwarding path; or network configuration associated with each step along the respective simulated forwarding path.

[0010] Optionally, the method includes performing a network reachability analysis on each of the one or more simulated forwarding paths based on the corresponding network configuration information by the data processing hardware. The network reachability analysis may be configured to: determine the final state of the reachability of the data packet along the corresponding simulated forwarding path; identify one or more misconfigurations along the corresponding simulated forwarding path; or identify inconsistent or outdated configurations along the corresponding simulated forwarding path.

[0011] In some embodiments, the final reachability state includes any of the following: a delivery state indicating that the packet will be delivered to the destination; a forwarding state indicating that the packet will be forwarded to another network with an unknown configuration; a discard state indicating that the packet will be discarded due to a configuration checkpoint failure or lost configuration; or an abort state indicating that the network reachability analysis cannot be performed due to a lack of critical configuration. Performing the network reachability analysis may include performing the network reachability analysis in at least one of on-demand mode, continuous mode, pre-commit mode, or post-commit mode.

[0012] In some examples, the packet header also includes: a protocol associated with the packet; a source port associated with the packet; and a destination port associated with the packet. The source of the packet may include a first instance executing in a first network, and the destination of the packet may include a second instance executing in a second network different from the first network. In some embodiments, the first network includes a Virtual Private Cloud (VPC) network and the second network includes an on-premises deployment network. The first network and the second network each include their respective Virtual Private Cloud (VPC) networks.

[0013] The source of the data packet may include a first instance, and the destination of the data packet may include a second instance. Both the first and second instances are running within the same Virtual Private Cloud (VPC) network. Alternatively, the source of the data packet may be located on an external network, and the destination of the data packet may include a global HTTPS load balancer running within the VPC network. This global HTTPS load balancer is configured to route the data packet to one of multiple different backend virtual machines (VMs). Generating one or more simulated forwarding paths for the data packet may include generating corresponding simulated forwarding paths from the global HTTPS load balancer to each of the multiple different backends.

[0014] Another aspect of this disclosure provides a system for providing cloud reachability analysis. The system includes data processing hardware and memory hardware communicating with the data processing hardware. The memory hardware stores instructions that, when executed on the data processing hardware, cause the data processing hardware to perform operations. The operations include receiving a reachability query for the reachability status of a requested target. The reachability query includes a packet header associated with a data packet. The packet header includes a source Internet Protocol (IP) address associated with the source of the data packet and a destination IP address associated with the destination of the data packet. The analysis also includes generating one or more simulated forwarding paths for the data packet based on the packet header using a data plane model. Each simulated forwarding path contains corresponding network configuration information. The operation also includes determining the reachability status of a target based on the one or more simulated forwarding paths. The operation further includes providing the determined reachability status and the one or more simulated forwarding paths to a user equipment associated with the reachability query. When the one or more simulated forwarding paths are received by the user equipment, the user equipment presents the network configuration information for each simulated forwarding path.

[0015] This aspect may include one or more of the following optional features. In some embodiments, determining the reachability state of the one or more simulated forwarding paths includes using a network abstraction state machine. The user equipment may be configured to send the packet from a remote network using locally advertised routes. In some examples, the network configuration information includes at least one of the following: a port / interface for routing the packet within a Virtual Private Cloud (VPC) network; a port / interface for routing the packet between VPC networks; a port / interface for routing the packet between VPC networks and non-VPC networks; firewall rules applied to the packet at each step along the respective simulated forwarding path; or network configuration associated with each step along the respective simulated forwarding path.

[0016] Optionally, the operation includes performing a network reachability analysis on each of the one or more simulated forwarding paths based on the corresponding network configuration information. The network reachability analysis may be configured to: determine the final reachability status of the data packet along the corresponding simulated forwarding path; identify one or more misconfigurations along the corresponding simulated forwarding path; or identify inconsistent or outdated configurations along the corresponding simulated forwarding path.

[0017] In some embodiments, the final reachability state includes any of the following: a delivery state indicating that the packet will be delivered to the destination; a forwarding state indicating that the packet will be forwarded to another network with an unknown configuration; a discard state indicating that the packet will be discarded due to a configuration checkpoint failure or lost configuration; or an abort state indicating that the network reachability analysis cannot be performed due to a lack of critical configuration. Performing the network reachability analysis may include performing the network reachability analysis in at least one of on-demand mode, continuous mode, pre-commit mode, or post-commit mode.

[0018] In some examples, the packet header also includes: a protocol associated with the packet; a source port associated with the packet; and a destination port associated with the packet. The source of the packet may include a first instance executing in a first network, and the destination of the packet may include a second instance executing in a second network different from the first network. In some embodiments, the first network includes a Virtual Private Cloud (VPC) network and the second network includes an on-premises deployment network. The first network and the second network each include their respective Virtual Private Cloud (VPC) networks.

[0019] The source of the data packet may include a first instance, and the destination of the data packet may include a second instance. Both the first and second instances are running within the same Virtual Private Cloud (VPC) network. Alternatively, the source of the data packet may be located on an external network, and the destination of the data packet may include a global HTTPS load balancer running within the VPC network. This global HTTPS load balancer is configured to route the data packet to one of multiple different backend virtual machines (VMs). Generating one or more simulated forwarding paths for the data packet may include generating corresponding simulated forwarding paths from the global HTTPS load balancer to each of the multiple different backends.

[0020] Details of one or more embodiments of this disclosure are set forth in the accompanying drawings and the following description. Other aspects, features, and advantages will become apparent from the description, the drawings, and the claims. Attached Figure Description

[0021] Figure 1This is a schematic diagram of an example system used to perform cloud network reachability analysis.

[0022] Figure 2 yes Figure 1 A schematic diagram of an exemplary component of the system's virtual machine.

[0023] Figure 3A It includes Figure 1 A schematic diagram of an exemplary component of the network abstract state machine of the system.

[0024] Figure 3B This is a schematic diagram of an exemplary report indicating the reachability status of the determined simulated forwarding path.

[0025] Figure 4 This is a schematic diagram of the network abstract state machine shown in Figure 3.

[0026] Figure 5 It is a schematic diagram of the state diagram of a network abstract state machine used to simulate the forwarding path between one virtual machine and another virtual machine.

[0027] Figure 6 It is a schematic diagram of the state diagram of a network abstract state machine used to simulate the forwarding path between virtual machines and load balancers.

[0028] Figure 7 It is a schematic diagram of the state diagram of a network abstract state machine used to simulate the forwarding path between virtual machines and locally deployed networks.

[0029] Figure 8 It is a schematic diagram of the state diagram of a network abstract state machine used to simulate the forwarding path between the Internet and virtual machines.

[0030] Figure 9 It is a schematic diagram of the state diagram of a network abstract state machine used to simulate the forwarding path between locally deployed network virtual machines and virtual private cloud virtual machines.

[0031] Figure 10A and 10B This is a reason table simulating the final reachability state of data packets.

[0032] Figure 11 This is a diagram illustrating the simulated forwarding path between an external host and a virtual private cloud virtual machine via a load balancer.

[0033] Figure 12 This is a flowchart of an example operational arrangement for performing cloud network reachability analysis.

[0034] Figure 13 This is a schematic diagram of an example computing device that can be used to implement the systems and methods described herein.

[0035] In the various figures, the same reference numerals denote the same elements. Detailed Implementation

[0036] A Virtual Private Cloud (VPC) is a pool of on-demand, configurable, shared computing resources allocated within a public cloud environment to provide isolation to users from other cloud users. This isolation can be achieved through the allocation of a private Internet Protocol (IP) subnet and / or virtual communication infrastructure. A VPC can run one or more virtual machines (VMs) that can communicate with the user's on-premises network or other remote resources via a Virtual Private Network (VPN) to ensure secure access to the VPC environment. Because some VPC environments are complex and large (i.e., including several VMs, network gateways, load balancers, etc.), significant network configuration is typically required to operate and maintain the VPC network.

[0037] The implementation described here targets a cloud reachability analyzer that allows a user to specify a packet header with multiple fields (e.g., source and destination addresses, protocol, source and destination ports, etc.) and simulate packets (using the header) through at least one intended forwarding path to the user's on-premises network, a VPC network, a peering VPC network, a VPN tunnel, and / or to the user's on-premises network. The cloud reachability analyzer provides configuration information for each simulated path, including, for example, routing and firewall rules. Instead of actually verifying the state of the forwarding path (i.e., by actually transmitting packets), the cloud reachability analyzes based on the active configuration of the VPC network. This can be referred to as "intent-based" packet tracing.

[0038] In short, the cloud reachability analyzer provides configuration-based static analysis of network reachability within a VPC or between a VPC and a non-VPC network (e.g., an on-premises network). Users can specify one or more parameters in the packet header, and the cloud reachability analyzer generates and simulates packet forwarding paths. The cloud reachability analyzer provides matching configurations (e.g., firewall rules, routes, etc.) for each step of each simulated path. Therefore, the cloud reachability analyzer allows users to verify expected reachability through their network configurations and helps discover inconsistent, outdated, or misconfigured configurations. Furthermore, the cloud reachability analyzer verifies and detects errors in new configuration changes and analyzes the impact of proposed configuration changes on network connectivity.

[0039] refer to Figure 1In some implementations, example system 100 includes user equipment 10 associated with a corresponding user 12 and communicating with remote system 140 via network 60 (e.g., the Internet) and local deployment network 70 (i.e., the local network for which user equipment 10 connects to network 60). Local deployment network 70 includes a network gateway 72 (e.g., a router) that acts as a forwarding host for the local deployment network 70. User equipment 10 can correspond to any computing device, such as a desktop workstation, laptop workstation, or mobile device (i.e., a smartphone). User equipment 10 includes computing resources 18 (e.g., data processing hardware) and / or storage resources 16 (e.g., memory hardware).

[0040] Remote system 140 may be a single computer, multiple computers, or a distributed system (e.g., a cloud environment) with scalable / elastic resources 142, including computing resources 144 (e.g., data processing hardware) and / or storage resources 146 (e.g., memory hardware). Data storage (i.e., remote storage devices) may overlay on storage resources 146 to allow clients or one or more of computing resources 144 to scalably utilize storage resources 146. Remote system 140 is configured to implement and execute one or more virtual machines (VMs) 250, 250a-n. One or more VMs execute securely in a Virtual Private Cloud (VPC) environment or VPC network 148 associated with or operated by user 12. VPC network 148 may include various other network elements, such as load balancers, gateways, front-ends, and back-ends.

[0041] exist Figure 2 In the example shown, the distributed system 140 includes a collection 210 of resources 110 (e.g., hardware resources 110h), a virtual machine monitor (VMM) 220, a VM layer 240 executing one or more of VMs 250, and an application layer 260. Each hardware resource 110h may include one or more physical central processing units (pCPUs).

[0042] 144 (“physical processor 144”) and memory hardware 146. Although each hardware resource 110h is shown as having a single physical processor 144, any hardware resource 110h may include multiple physical processors 144. Operating system 212 may execute on the collection 210 of resources 110.

[0043] In some examples, VMM 220 corresponds to hypervisor 220 (e.g., computing engine), which includes at least one of software, firmware, or hardware configured to create and execute VMs 250. The computer (i.e., data processing hardware 144) associated with the VMM 220 executing one or more VMs 250 may be referred to as a host machine, and each VM 250 may be referred to as a guest machine. Here, the VMM 220 or hypervisor is configured to provide each VM 250 with a corresponding guest operating system (OS) 212g having a virtual operating platform and to manage the execution of the corresponding guest OS 212g on the VM 250. As used herein, each VM 250 may be referred to as an "instance" or "VM instance." In some examples, multiple instances of various operating systems may share virtualization resources. For example, The first VM 250 operating system The second VM 250 and OS of the operating system The third VM 250 operating system can all run on a single physical x86 machine.

[0044] VM layer 240 includes one or more virtual machines 250. Distributed system 140 enables user 12 to launch VMs 250 on demand. VMs 250 emulate real computer systems and operate based on the computer architecture and functionality of real or hypothetical computer systems, which may involve specialized hardware, software, or a combination thereof. In some examples, distributed system 140 authorizes and authenticates user 12 before launching one or more VMs 250. A software instance, or simply an instance, refers to a VM 250 hosted (executing) on ​​data processing hardware 144 of distributed system 140.

[0045] Each VM 250 may include one or more virtual central processing units (vCPUs) 252 (“virtual processors”). In the illustrated example, a first virtual machine 250a includes a first group 252a of one or more virtual processors 252, and a second virtual machine 250b includes a second group 252b of one or more virtual processors 252. Although the second group 252b is shown to include only one virtual processor 252, any number of virtual processors 252 is possible. Each virtual processor 252 emulates one or more physical processors 144. For example, the first group 252a of one or more virtual processors 252 emulates a first group 113a of one or more physical processors 144, and the second group 252b of one or more virtual processors 252 emulates a second group 113b of one or more physical processors 144. The application layer 260 includes software resources 110s, 110sa, 110sb (software applications) that can be executed on the virtual machines 250.

[0046] Typically, each instance of the software (e.g., virtual machine 250) includes at least one virtual storage device 262 that provides volatile and non-volatile storage capacity for services on physical memory hardware 146. For example, the storage capacity on physical memory hardware 146 may include a persistent disk (PD) that stores data for user 12 across multiple physical disks (e.g., memory region 116 of memory hardware 146), or may include random access memory (RAM) to provide volatile storage. More specifically, each virtual storage device 262 corresponding to VM 250 moves data in sequences of bytes or bits (blocks) to an associated physical block storage volume V on memory hardware 146 to provide non-volatile storage. Thus, the virtual storage device 262 corresponding to VM instance 250 provides storage capacity mapped to a corresponding physical block storage volume V on memory hardware 146. In some examples, virtual storage device 262 supports random access to data on memory hardware 146 and typically uses buffered I / O. Examples include hard disks, CD-ROM drives, and flash drives. Similarly, portions of the volatile memory (e.g., RAM) of the physical memory hardware 146 can be partitioned across the virtual storage device 262.

[0047] A guest kernel 214g resides within the guest operating system 212g. The kernel is a computer program that is the core of the operating system and has complete access to and control over the operating system (OS). In other words, the kernel acts as an intermediary between the application 110s and the host machine's hardware resources 110h. Most modern computing systems isolate virtual memory into a protected kernel space and a user space 216g. The kernel is typically stored in volatile memory within the protected kernel space and is isolated from the user space 216g. To increase security and reliability, the application 110s and other software services typically execute in the guest user space 216g and lack the permissions required to interact with the protected kernel space.

[0048] Return to reference Figure 1 The remote system 140 executes the cloud reachability analyzer 150 to analyze one or more network forwarding paths 80, 80a-n between or within the VPC network 148 and / or the on-premises network 70 to determine reachability status 172 and / or network configuration information 162 about each network forwarding path 80.

[0049] The cloud reachability analyzer 150 receives a reachability query 20 from the user device 10, which is a 172-level reachability status of the requested target. The target may include a local network gateway 72, one or more VMs 250, firewall rules, and / or other components of the VCP network 148, such as a load balancer. Figure 11 When the target is a firewall rule, reachability state 172 depends on the existence of a packet that can be delivered to VPC network 148 and hit a specific rule in the configuration. Reachability query 20 includes a packet header 22 associated with packet 24 (e.g., an Internet Protocol (IP) version 4 (IPv4) or IP version 6 (IPv6) header). In some examples, reachability query 20 includes packet 24 and the associated packet header 22, while in other examples, cloud reachability analyzer 150 receives the packet header 22 and generates the corresponding packet 24. Packet header 22 includes multiple packet parameters 25, 25a-n. For example, packet header 22 includes a source Internet Protocol (IP) address 25a and a destination IP address 25b. Optionally, packet header 22 includes other parameters 25, such as protocol type 25c, source port 25d, and / or destination port 25e.

[0050] The cloud reachability analyzer 150 includes a path generator 160 that receives or obtains data packets 24 with associated headers 22. The path generator 160 uses a data plane model 164 to generate one or more simulated forwarding paths 80 (also referred to herein as traces) for the data packets 24 based on the headers 22. Each simulated forwarding path 80 contains corresponding network configuration information 162. The data plane model 164 obtains the network configuration information 162 from network components of the VPC network 148 and includes, for example, ports / interfaces for routing the data packets 24 within the VPC network 148, ports / interfaces for routing the data packets 24 between different VPC networks 148, ports / interfaces for routing the data packets 24 between the VPC network 148 and non-VPC networks (e.g., on-premises network 70), firewall rules applied to the data packets 24 at each step along the corresponding simulated forwarding path 80, and / or network configurations associated with each step along the corresponding simulated forwarding path 80. As used here, each step along the simulated forwarding path 80 refers to an intermediate device (e.g., gateway, load balancer, etc.) between the source instance and the destination instance.

[0051] In some implementations, data plane model 164 is an idealized data plane model that models the data plane of network 148 by deriving instances from network configuration information 162. In some examples, network configuration information 162 is stored in project configurations associated with VPC network 148. Data plane model 164 analyzes the derived instances to determine and verify reachability attributes. That is, data plane model 164 abstracts the relevant network configurations for reachability analysis. Network configuration information 162 may include VPC network configuration information, network service information (e.g., load balancing), hybrid cloud configuration, VM configuration, and / or platform configuration (e.g., a platform for containerized applications).

[0052] A simulated forwarding path 80 represents a packet 24 forwarding path within VPC network 148 and / or between VPC network 148 and on-premises deployment network 70. For example, a simulated forwarding path 80 represents a forwarding path from a first instance (e.g., VM 250a) to a second instance (e.g., VM 250b), where both the first and second instances are executed within the same VPC network 148. Optionally, the source of packets in a simulated forwarding path 80 is an instance (e.g., VM 250) executed in a first network that is VPC network 148, and the destination is a second instance (e.g., a different VM 250) executed in a second network that is a different VPC network 148 from the first network.

[0053] In another example, a simulated forwarding path 80 represents a forwarding path 80 from a VM 250 to an external network (e.g., the Internet 60). That is, the source of packet 24 (i.e., source IP address 25a) includes a first instance (e.g., VM 250 in VPC network 148) executing in a first network, and the destination of packet 24 (i.e., destination IP address 25b) includes a second instance executing in a second network (e.g., local deployment network 70) different from the first network. In other examples, a simulated forwarding path 80 represents a path to load balancer 1110 ( Figure 11 The virtual machine 10 (VM 250) can be configured to send packets 24 from a remote network (e.g., local network 70) using locally advertised routes. This means that the virtual machine 10 may be connected to the internet 60 to VM 250 or load balancer 1110 and / or to local network gateway 72 to VM 250. User device 10 can be configured to send packets 24 from a remote network (e.g., local network 70) using locally advertised routes. That is, because cloud reachability analyzer 150 may not have access to network configuration information 162 of local network 70, cloud reachability analyzer 150 may not be able to verify whether the correct routing and firewall rules are configured for packets 24 originating from local network 70. However, cloud reachability analyzer 150 can verify whether the configuration from VPC network 148 will allow packets 24 to be delivered to their intended destination. The most critical configurations verified by cloud reachability analyzer 150 include advertised routes and ingress firewall rules.

[0054] As another example, the source of packet 24 is located in an external network (e.g., local deployment network 70) and the destination of packet 24 includes a global HTTPS load balancer 1110 operating in VPC network 148. The global HTTPS load balancer 1110 can be configured to route packet 24 to one of multiple different backend VMs 250. Figure 11 The path generator 160 can generate corresponding simulated forwarding paths 80 from the global HTTPS load balancer to each of multiple different backend VMs 250.

[0055] The exemplary path 80 discussed herein is illustrative and not limiting. That is, the cloud reachability analyzer 150 can also analyze or simulate other forwarding paths 80. For example, the cloud reachability analyzer 150 can receive or obtain network configuration information 162 (e.g., from user 12) of other networks (e.g., on-premises network 70 or peering VPC networks) and include simulated paths 80 through these networks. In other words, the cloud reachability analyzer 150 can analyze forwarding paths 80 of any network and associated network components (e.g., gateways, load balancers, front-ends, back-ends, etc.) through which the cloud reachability analyzer 150 obtains network configuration information 162. In some examples, the cloud reachability analyzer 150 stops analysis when network configuration information 162 is no longer available (e.g., at on-premises gateway 72).

[0056] Path generator 160 passes path 80 and corresponding network configuration information 162 to path analyzer 170, which determines the reachability state 172 of the target of reachability query 20 based on one or more simulated forwarding paths 80. In some examples, path analyzer 170 performs network reachability analysis on each of the one or more simulated forwarding paths 80 based on the corresponding network configuration information 162. Path analyzer 170 may perform network reachability analysis in at least one of on-demand mode, continuous mode, pre-commit mode, or post-commit mode. For example, reachability query 20 may indicate a request for a single simulation, or a request for consecutive simulations until user equipment 10 instructs cloud reachability analyzer 150 to stop (or meets some other threshold, e.g., a certain amount of time has elapsed). In some implementations, path analyzer 170 determines the final reachability state 172 (also referred to herein as reachability state 172) of packet 24 along the corresponding simulated forwarding path 80 by discovering one or more misconfigurations along the corresponding simulated forwarding path 80 or by discovering inconsistent or outdated configurations along the corresponding simulated forwarding path 80.

[0057] The cloud reachability analyzer 150 provides the user equipment 10 associated with the reachability query 20 with a defined reachability status 172 and one or more simulated forwarding paths 80. As discussed in more detail below, when one or more simulated forwarding paths 80 are received by the user equipment 10, the user equipment 10 causes the user equipment 10 to present network configuration information 162 for each simulated forwarding path to the user 12.

[0058] Now for reference Figure 3AIn some implementations, the path analyzer 170 includes a network abstract state machine (NAM) 400 for generating one or more simulated forwarding paths 80. The NAM 400 can be an idealized model of how the VPC network 148 processes packets. In some examples, the NAM 400 is an abstraction and therefore independent of the actual implementation of the VPC network 148. Optionally, the NAM 400 determines a final state 172 of the reachability of packet 24, which includes any of the following: a delivery state 174a indicating that packet 24 will be delivered to its destination; a forwarding state 174b indicating that packet 24 will be forwarded to another network with an unknown configuration; a discard state 174c indicating that packet 24 will be discarded due to a configuration checkpoint failure or lost configuration; or an abort state 174d indicating that network reachability analysis cannot be performed due to a lack of critical configuration. The NAM 400 can be nondeterministic, as a state can have multiple successor states. For example, when multiple routes with the same IP mask and priority are applied to a packet, a route is selected from them based on an unspecified hash function. Although this is a deterministic process in principle, it is better to model it by selecting one of the routes nondeterministically, since the hash function is an internal implementation that may change.

[0059] Now for reference Figure 3B The cloud reachability analyzer 150 provides user equipment 10 with a determined reachability status 172 for each simulated forwarding path 80. This causes the user equipment to present network configuration information 162 for each simulated forwarding path 80 to user 12. For example, report 300 may indicate to user 12 details about the generated packet 24 (e.g., header 22). Report 300 may indicate information related to each step 310, 310a-n, or hop along the trace or simulated forwarding path 80. In the example shown, packet 24 leaves the source instance at step 310a (i.e., step 0), is applied to an egress firewall rule at step 310b (i.e., step 1), is routed at step 310c (i.e., step 2), arrives at the destination instance at step 310d (i.e., step 3), is applied to an ingress firewall rule at step 310e (i.e., step 4), and is delivered to the destination instance at step 310f (i.e., step 5). Each of these steps 310 includes the associated network configuration information 162.

[0060] Report 300 may indicate the cause or underlying reason for the determined reachability state 172 of each simulated forwarding path 80 (e.g., packet drop due to firewall rule rejection) to help rule out and / or detect network connectivity issues caused by inconsistent and invalid configurations, or to verify new or changed configurations. In some examples, cloud reachability analyzer 150 provides analysis of the impact of configuration changes. Each simulated forwarding path 80 may be presented as part of a graphical user interface (GUI) on a user device as part of an application (e.g., a web browser). While the example shown provides only details about a single forwarding path 80 (i.e., trace 1), it is possible to provide details about each simulated forwarding path 80 (i.e., multiple traces). In some examples, report 300 includes a summary section 320 indicating the determined reachability state 172 of packet 24.

[0061] Now for reference Figure 4 In some implementations, NAM 400 includes egress inspection 410, ingress inspection 420, and path-specific inspection 430. In some examples, egress inspection 410 includes egress firewall inspection 412 and matching route 414. The egress firewall inspection finds (e.g., within network configuration information 162) matching egress firewall rules. Egress firewall rules are firewall rules applied to the source instance (e.g., VM 250). Matching route 414 can find and apply an appropriate route for simulating forwarding path 80. When the source instance is VM 250, matching route 414 can also determine whether a matching route exists for destination IP address 25b. When no matching route exists, NAM 400 can match the route with the default route whose next hop is the Internet gateway. Ingress firewall inspection 422, like egress firewall inspection 412, finds and applies matching ingress firewall rules (i.e., firewall rules applied to the destination instance).

[0062] Path-specific checks 430 are based on the type of simulated forwarding path 80 being evaluated by NAM 400. That is, path-specific checks 430 depend on the source and destination instances of the simulated forwarding path 80. For example, when the destination instance is a VPN gateway 432 via VPN tunnel 434, specific states ( Figure 7 This is included in the NAM 400 evaluation. Similarly, when the target instance is a load balancer with forwarding rule 436, different states are evaluated. Figure 6 and Figure 8 When the destination instance is a peer-to-peer network gateway 438, other states are evaluated in the state machine of NAM 400.

[0063] Figure 5-9Exemplary state machines 500, 600, 700, 800, and 900 are shown to represent NAM 400 when analyzing different simulated forwarding paths 80 of packet 24. For example, Figure 5 The state machine 500 of NAM 400 is shown when analyzing a simulated forwarding path 80 between the first VM 250 and the second VM 250, or between the first VM 250 and the Internet 60. State machine 500 begins in instance state 510 corresponding to the source VM 250. From there, when VM 250 is allowed to send / receive packets with an external IP address, state machine 500 transitions to abort state 512 (when analysis cannot continue due to, for example, lost network configuration information 162), applies egress firewall rules 514, or performs a spoofing check 518 state. Due to a failed network configuration check or lost network configuration information 162, packet 24 may be dropped in drop state 516. An appropriate route is found and applied in state 520, and packet 24 may arrive at the VM instance in state 522, be forwarded to another network with an unknown configuration in state 528 (thus analysis stops), have its packet header 22 modified due to Network Address Translation (NAT) in state 526, or have ingress firewall rules applied in state 524. In state 530, packet 24 is transmitted to the destination specified in packet header 22.

[0064] Now for reference Figure 6 When analyzing VM 250 and load balancer 1110 ( Figure 11 When simulating forwarding path 80 between the source VM 250 and the target VM 400, state machine 600 represents NAM 400. State machine 600 begins at instance state 610 corresponding to the source VM 250. From there, when VM 250 is allowed to send / receive packets with an external IP, state machine 600 transitions to abort state 612 (when analysis cannot continue due to, for example, lost network configuration information 162), apply egress firewall rule 614, or spoofing check state 618. Due to network configuration check failure or lost network configuration information 162, packet 24 may be dropped in drop state 616. In state 620, an appropriate route is found and applied, and in state 622, it is forwarded to another network with an unknown configuration (therefore analysis stops). In state 624, NAM 400 applies appropriate forwarding rules, and in state 626, it reaches internal or external load balancer 1110. From there, packet 24 can be forwarded to one or more backends 628, 628a-n, and the packet is either dropped in state 630 or forwarded in state 632.

[0065] Now for reference Figure 7When analyzing the simulated forwarding path 80 between VM 250 and the on-premises network 70 via VPN, state machine 700 represents NAM 400. State machine 700 begins at instance state 710 corresponding to the source VM 250. From there, when VM 250 is allowed to send / receive packets with an external IP, state machine 600 transitions to abort state 712 (when analysis cannot continue due to, for example, lost network configuration information 162), apply egress firewall rule 714, or spoofing check state 718. Due to the failure of the network configuration check or the loss of network configuration information 162, packet 24 may be dropped in drop state 716. In state 720, an appropriate route is found and applied, and in state 722, it is forwarded to another network with an unknown configuration (therefore analysis stops), and subsequently forwarded to one or more on-premises backends 728, 728a-n. In state 724, packet 24 arrives at the local side of the VPN tunnel, and in state 726, packet 24 arrives at the VPN gateway and can be forwarded to one or more VCP backends 628.

[0066] Now for reference Figure 8 When analyzing the simulated forwarding path 80 between Internet 60 and VM 250 or between Internet 60 and load balancer 1110, state machine 800 represents NAM 400. State machine 800 starts from Internet state 810 for packet 24 originating from Internet 60. From there, when packet 24 is dropped due to a network configuration check failure or loss of network configuration information 162, state machine 800 can proceed to state 816. State machine 800 can also proceed to state 812 and modify packet header 22 due to NAT. From NAT state 812, packet 24 arrives at the VM instance at 818 and is either dropped in state 820 or forwarded in state 822. When the destination is load balancer 1110, state machine 800 can also proceed to state 814 and apply appropriate forwarding rules. From there, state machine 800 proceeds to state 824, where packet 24 arrives at the external load balancer. Next, when the previous connection is proxied to the new connection, state machine 800 transitions to the proxied connection state 826, and NAM 400 generates a new packet 24 for subsequent tracing or simulation. Otherwise, state machine 800 simulates forwarding packet 24 to one or more backends 628, where the packet is either dropped in state 828 or transmitted in state 830.

[0067] Now for reference Figure 9When analyzing the simulated forwarding path 80 between the local deployment network 70 (e.g., VMs located within the local deployment network 70) and the VCPVM 250, state machine 900 represents NAM 400. Here, state machine 900 begins at state 910, where packet 24 originates from the private network (e.g., local deployment network 70). From there, state machine 900 transitions to state 912 and applies the appropriate route. State machine 900 then either drops the packet in state 914 due to a network configuration check failure or loss of network configuration information 162, or it is processed in state 916 to reach the instance. From there, NAM 400 applies inbound firewall rules in state 918 and forwards the packet in state 920.

[0068] In some examples, the cloud reachability analyzer 150 simulates forwarding path 80 by tracing back the route advertised by VPC network 148 to on-premises network 70. While the cloud reachability analyzer 150 typically does not have access to the on-premises network configuration, it does have access to the configuration of static and dynamic routes (e.g., via a VPN to on-premises network 70). Therefore, the cloud reachability analyzer can simulate VPC network 148 routes that on-premises network 70 should configure or receive for dynamic routes. When packet 24 originates from the on-premises network range (derived from VPN-related routes), the cloud reachability analyzer 150 can apply "inferred" routes to that packet.

[0069] Now for reference Figure 10A and 10B Tables 1000a and 1000b illustrate the potential final reachability state 172 (i.e., discard 174a, forward 174b, transmit 174c, or abort 174d) of a data packet in NAM 400, relative to the previous state 400 of NAM ( Figure 5-9 ), and the reasons for the final state. That is, Tables 1000a and 1000b provide exemplary reasons for transitioning to the final states 174a-d in state machines 500, 600, 700, 800, and 900.

[0070] Now for reference Figure 11An exemplary forwarding path 80c begins on an external host (e.g., user device 10), is passed via the Internet 60 to a load balancer 1110 within the VPC network 148. The load balancer 1110 forwards the packets to a front-end server 1020, which then distributes the packets to one or more back-end or VM 250 locations. Forwarding path 80c in this scenario is more complex than a typical network-level load balancer. In this example, the cloud reachability analyzer 150 tracks packets 24 from the external host (e.g., user device 10) to the load balancer 1110 (e.g., a global HTTPS load balancer). In some examples, the load balancer is a proxy load balancer, and therefore the TCP connection terminates at the front-end server 1020, which then initiates a new TCP connection with one or more back-end VMs 250. The cloud reachability analyzer uses NAM 400 to simulate this behavior. In the actual data plane, the load balancing algorithm can select a VM for each connection. The cloud reachability analyzer 150 can be a static configuration analysis tool that does not predict data plane paths but identifies any configuration issues to provide users with additional visibility into expected behavior. Therefore, in this case, the cloud reachability analyzer 150 provides a trace for each possible path (e.g., a first trace to VM 250a, a second trace to VM 250b, and a third trace to VM 250b).

[0071] Figure 12 This is a flowchart of an exemplary operational arrangement for performing cloud network reachability analysis. Method 1200 includes, in operation 1202, receiving at data processing hardware 144 a reachability query 20 requesting the reachability status 172 of targets 70, 250, and 1110. The reachability query 20 includes a header 22 associated with packet 24, the header 22 including a source IP address 25a associated with the source of packet 24 and a destination IP address 25b associated with the destination of packet 24.

[0072] In operation 1204, method 1200 includes generating one or more simulated forwarding paths 80 for packet 24 based on packet header 22 using data plane model 164 by data processing hardware 144. Each simulated forwarding path 80 includes corresponding network configuration information 162. In operation 1206, method 1200 includes determining the reachability state 172 of targets 70, 250, 1110 by data processing hardware 144 based on one or more simulated forwarding paths 80. In operation 1208, method 1200 includes providing the determined reachability state 172 and one or more simulated forwarding paths 80 to user equipment 10 associated with reachability query 20 by data processing hardware 144. Upon being received by user equipment 10, one or more simulated forwarding paths 80 cause user equipment 10 to present network configuration information 162 for each simulated forwarding path 80.

[0073] Figure 13 This is a schematic diagram of an example computing device 1300 that can be used to implement the systems and methods described in this document. The computing device 1300 is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the inventions described and / or claimed in this document.

[0074] The computing device 1300 includes: a processor 1310 (e.g., data processing hardware), a memory 1320, a storage device 1330, a high-speed interface / controller 1340 connected to the memory 1320 and a high-speed expansion port 1350, and a low-speed interface / controller 1360 connected to a low-speed bus 1370 and the storage device 1330. Each component 1310, 1320, 1330, 1340, 1350, and 1360 is interconnected using different buses, and each component can be mounted on a common motherboard or otherwise installed as needed. The processor 1310 can process instructions that execute within the computing device 1300, including instructions stored in the memory 1320 or the storage device 1330 to display graphical information of a graphical user interface (GUI) on an external input / output device such as a display 1380 coupled to the high-speed interface 1340. In other embodiments, multiple processors and / or multiple buses can be used with multiple memories and various types of memory, if needed. Similarly, multiple computing devices 1300 can be connected, each providing some of the necessary operations (e.g., as a server array, a group of blade servers, or a multiprocessor system).

[0075] Memory 1320 stores information non-temporarily within computing device 1300. Memory 1320 may be a computer-readable medium, volatile memory cells(s), or non-volatile memory cells(s). Non-volatile memory 1320 may be a physical device for storing programs (e.g., instruction sequences) or data (program state information) used by computing device 1300 on a temporary or permanent basis. Examples of non-volatile memory include, but are not limited to: flash memory and read-only memory (ROM) / programmable read-only memory (PROM) / erasable programmable read-only memory (EPROM) / electrically erasable programmable read-only memory (EEPROM) (e.g., commonly used for firmware such as bootloaders). Examples of volatile memory include, but are not limited to: random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), phase-change memory (PCM), and optical discs or magnetic tapes.

[0076] Storage device 1330 provides massive storage for computing device 1300. In some embodiments, storage device 1330 is a computer-readable medium. In various embodiments, storage device 1330 may be a floppy disk device, hard disk device, optical disk device, magnetic tape device, flash memory or other similar solid-state storage device, or device array, including devices in a storage area network or other configuration. In additional embodiments, the computer program product is tangibly embodied as an information carrier. The computer program product contains instructions that, when executed, perform one or more methods, such as those described above. The information carrier is a computer-readable or machine-readable medium, such as memory 1320, storage device 1330, or memory on processor 1310.

[0077] High-speed controller 1340 manages bandwidth-intensive operations of computing device 1300, while low-speed controller 1360 manages lower bandwidth-intensive operations. This functional allocation is merely exemplary. In some embodiments, high-speed controller 1340 is coupled to memory 1320, display 1380 (e.g., via a graphics processor or accelerator) is coupled to high-speed expansion port 1350, which can accept various expansion cards (not shown). In some embodiments, low-speed controller 1360 is coupled to storage device 1330 and low-speed expansion port 1390. Low-speed expansion port 1390 may include various communication ports (e.g., USB, Bluetooth, Ethernet, and wireless Ethernet) and may be coupled to one or more input / output devices, such as keyboards, pointing devices, scanners, or network devices such as switches or routers, for example, via a network adapter.

[0078] As shown in the figure, the computing device 1300 can be implemented in various forms. For example, the computing device 1300 can be implemented as a standard server 1300a, or multiple times in a group of such servers 1300a, or as a laptop computer 1300b, or as part of a rack server system 1300c.

[0079] Various implementations of the systems and techniques described herein can be implemented in digital electronic circuit systems and / or optical circuit systems, integrated circuit systems, application-specific integrated circuits (ASICs), computer hardware, firmware, software, and / or combinations thereof. These various implementations may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be dedicated or general-purpose, and can receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, the at least one input device, and the at least one output device.

[0080] A software application (i.e., a software resource) can refer to computer software that instructs a computing device to perform a task. In some examples, a software application may be referred to as an "application," "program," or simply a "program." Example applications include, but are not limited to, system diagnostic applications, system management applications, system maintenance applications, word processing applications, spreadsheet applications, messaging applications, media streaming applications, social networking applications, and gaming applications.

[0081] These computer programs (also referred to as programs, software, software applications, or code) include machine instructions for a programmable processor and can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. As used herein, the terms “machine-readable medium” and “computer-readable medium” refer to any computer program product, non-transitory computer-readable medium, device, and / or apparatus (e.g., disk, optical disk, memory, programmable logic device (PLD)) used to provide machine instructions and / or data to a programmable processor, including machine-readable media that receive machine instructions as machine-readable signals. The term “machine-readable signal” refers to any signal used to provide machine instructions and / or data to a programmable processor.

[0082] The processes and logic flows described herein can be executed by one or more programmable processors, which execute one or more computer programs to perform functions by manipulating input data and generating output. Processes and logic flows can also be executed by special-purpose logic circuits such as FPGAs (Field-Programmable Gate Arrays) or ASICs (Application-Specific Integrated Circuits). Processors suitable for executing computer programs include, for example, general-purpose microprocessors, special-purpose microprocessors, and any type of digital computer processor. Generally, the processor receives instructions and data from read-only memory or random access memory, or both. Essential components of a computer are: a processor for executing instructions, and one or more memory devices for storing instructions and data. Generally, a computer will also include one or more mass storage devices for storing data, or the computer may be operatively coupled to receive data from or transfer data to or both of these mass storage devices, such as magnetic disks, magneto-optical disks, or optical disks. However, a computer need not have such devices. Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and storage devices, including, for example, semiconductor storage devices (e.g., EPROM, EEPROM, and flash memory devices), magnetic disks (e.g., internal hard disks or removable disks), magneto-optical disks, and CD-ROM and DVD-ROM disks. The processor and memory may be supplemented by or incorporated into a dedicated logic circuit system.

[0083] To provide interaction with a user, one or more aspects of this disclosure can be implemented on a computer having: a display device for displaying information to the user, such as a CRT (cathode ray tube) or LCD (liquid crystal display) monitor, or a touchscreen, and optionally including a keyboard and pointing device (e.g., a mouse or trackball), through which the user provides input to the computer. Other types of devices can be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including sound input, voice input, or tactile input. Additionally, the computer can interact by sending documents to and receiving documents from the device used by the user, for example, by sending a webpage to a web browser on the user's client device in response to a request received from a web browser.

[0084] Several embodiments have been described. However, it is understood that various modifications can be made without departing from the spirit and scope of this disclosure. Therefore, other embodiments are within the scope of the appended claims.

Claims

1. A computer-implemented method, characterized in that, The method is executed by data processing hardware, causing the data processing hardware to perform operations, including: Receive a Virtual Private Cloud (VPC) reachability request from a user device. The request requests the reachability status of network traffic from a source Internet Protocol (IP) address in the VPC network to a destination IP address in the VPC network. The VPC reachability request includes the protocol type. Obtain network configuration information that defines the VCP network; Based on the source IP address and the destination IP address, a simulated forwarding path for data packets is generated using model and network configuration information, and the simulated forwarding path includes multiple hops; Using a network abstraction state machine, it is determined that the destination IP address from the source IP address is unreachable based on the simulated forwarding path, wherein the network abstraction state machine includes a path-specific check based on the type of the simulated forwarding path determined from the network configuration information, and the type of the simulated forwarding path is based on the source instance and destination instance of the simulated forwarding path. In response to determining that the destination IP address is unreachable, a reachability report is generated, the reachability report including: Each of the multiple hops in the simulated forwarding path; and The reason why the destination IP address is unreachable from the source IP address; and The reachability report is provided to the user equipment.

2. The method according to claim 1, characterized in that, The VPC reachability request also includes the destination port.

3. The method according to claim 1, characterized in that, The network configuration information includes: The port / interface for routing data packets within the VPC network; Firewall rules applied to the packet at each step along the simulated forwarding path; and The network configuration associated with each of the plurality of hops along the simulated forwarding path.

4. The method according to claim 1, characterized in that, Determining that the destination IP address is unreachable includes determining: A discard status indicating that the data packet will be dropped due to a configuration checkpoint failure or lost configuration; or This indicates an aborted state where the destination IP address is unreachable due to a lost configuration.

5. The method according to claim 1, characterized in that, The VPC reachability request also includes: The source port associated with the data packet; and The destination port associated with the data packet.

6. The method according to claim 1, characterized in that: The source IP address is associated with the first virtual machine (VM); and The destination IP address is associated with the second VM.

7. The method according to claim 1, characterized in that, At least one of the multiple hops includes a load balancer within the VPC network.

8. A system, characterized in that, include: Data processing hardware; and Memory hardware communicating with the data processing hardware, the memory hardware storing instructions that, when executed on the data processing hardware, cause the data processing hardware to perform operations, including: Receive a Virtual Private Cloud (VPC) reachability request from a user device. The request requests the reachability status of network traffic from a source Internet Protocol (IP) address in the VPC network to a destination IP address in the VPC network. The VPC reachability request includes the protocol type. Obtain network configuration information that defines the VCP network; Based on the source IP address and the destination IP address, a simulated forwarding path for data packets is generated using model and network configuration information, and the simulated forwarding path includes multiple hops; Using a network abstraction state machine, it is determined that the destination IP address from the source IP address is unreachable based on the simulated forwarding path, wherein the network abstraction state machine includes a path-specific check based on the type of the simulated forwarding path determined from the network configuration information, and the type of the simulated forwarding path is based on the source instance and destination instance of the simulated forwarding path. In response to determining that the destination IP address is unreachable, a reachability report is generated, the reachability report including: Each of the multiple hops in the simulated forwarding path; and The reason why the destination IP address is unreachable from the source IP address; and The reachability report is provided to the user equipment.

9. The system according to claim 8, characterized in that, The VPC reachability request also includes the destination port.

10. The system according to claim 8, characterized in that, The network configuration information includes: The port / interface for routing data packets within the VPC network; Firewall rules applied to the packet at each step along the simulated forwarding path; and The network configuration associated with each of the plurality of hops along the simulated forwarding path.

11. The system according to claim 8, characterized in that, Determining that the destination IP address is unreachable includes determining: A discard status indicating that the data packet will be dropped due to a configuration checkpoint failure or lost configuration; or This indicates an aborted state where the destination IP address is unreachable due to a lost configuration.

12. The system according to claim 8, characterized in that, The VPC reachability request also includes: The source port associated with the data packet; and The destination port associated with the data packet.

13. The system according to claim 8, characterized in that: The source IP address is associated with the first virtual machine (VM); and The destination IP address is associated with the second VM.

14. The system according to claim 8, characterized in that, At least one of the multiple hops includes a load balancer within the VPC network.

Images