JP7323636B2 - Cloud network reachability analysis - Google Patents

Description

TECHNICAL FIELD The present disclosure relates to reachability analysis of cloud networks.

Background A Virtual Private Cloud (VPC) is an on-demand configurable pool of shared, allocated computing resources within a public cloud environment. A VPC provides users with independence from other cloud users. A VPC may run one or more virtual machines (VMs) that may communicate with a user's on-premises network or other remote resources via a virtual private network (VPN). Due to the potential size and complexity of a VPC, which can include numerous VMs, network gateways, load balancers, etc., considerable network configuration is often required to operate and maintain the VPC.

Overview One aspect of the present disclosure provides a method for providing cloud network reachability analysis. The method includes receiving, at data processing hardware, a reachability query requesting reachability status of a target. The reachability query includes packet headers associated with data packets. 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 the data processing hardware 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 includes corresponding network configuration information. The method also includes the data processing hardware determining the reachability status of the target based on the one or more simulated transfer paths. The method also includes the data processing hardware providing the determined reachability status and the one or more simulated forwarding paths to a user device associated with the reachability query. . The one or more simulated transfer paths, when received by the user device, cause the user device to present the network configuration information for each simulated transfer path.

Implementations of the disclosure may include one or more of any of the following features. In some implementations, determining the reachability status of the one or more simulated forwarding paths includes using a network abstract state machine. The user device may be configured to send the data packet from a remote network using a locally advertised route. In some examples, the network configuration information includes ports/interfaces for directing the data packets within a virtual private cloud (VPC) network, ports/interfaces for directing the data packets between VPC networks, VPC networks and Ports/interfaces for directing said data packets to and from non-VPC networks, firewall rules applied to said data packets at each step along said corresponding simulated forwarding path, or said corresponding simulated forwarding. network configuration associated with each step along the path.

Optionally, said method comprises said data processing hardware performing a network reachability analysis for each of said one or more simulated forwarding paths based on said corresponding network configuration information. include. The network reachability analysis comprises: identifying a final state of reachability of the data packets along the corresponding simulated forwarding paths; one or more It may be configured to perform at least one of finding a bad configuration or finding a mismatched or obsolete configuration along said corresponding simulated forwarding path.

In some implementations, the reachability final state is a delivery state indicating that the data packet is delivered to the destination, the data packet is forwarded to another network with an unknown configuration a forwarding state indicating that the data packet is dropped due to a configuration checkpoint failure or missing configuration, or a missing critical configuration indicating that the network reachability analysis is not possible Abort state. Performing the network reachability analysis may comprise performing the network reachability analysis in at least one of an on-demand mode, a continuous mode, a pre-submit mode or a post-submit mode.

In some examples, the packet header further includes a protocol associated with the data packet, a source port associated with the data packet, and a destination port associated with the data packet. The source of the data packet may comprise a first instance running on a first network and the destination of the data packet running on a second network different from the first network. may include a second instance of In some implementations, the first network comprises a VPC network and the second network comprises an on-premises network. The first network and the second network may comprise respective VPC networks.

The source of the data packet may comprise a first instance and the destination of the data packet may comprise a second instance. Both the first instance and the second instance run in the same VPC network. The source of the data packet may be located in an external network and the destination of the data packet may comprise a global HTTPS load balancer running in a VPC network. The global HTTPS load balancer is configured to route the data packets to one of multiple different backends. Generating one or more simulated forwarding paths for the data packet comprises generating a corresponding simulated forwarding path from the global HTTPS load balancer to each of the plurality of different backends. may contain.

Another aspect of the present disclosure provides a system for providing cloud reachability analysis. The system includes data processing hardware and memory hardware in communication with the data processing hardware. The memory hardware stores instructions which, when executed on the data processing hardware, cause the data processing hardware to perform operations. The operation includes receiving a reachability query requesting reachability status of a target. The reachability query includes packet headers associated with data packets. 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 using a data plane model to generate one or more simulated forwarding paths for the data packet based on the packet header. Each simulated forwarding path includes corresponding network configuration information. The operations also include determining the reachability status of the target based on the one or more simulated forwarding paths. The operations also include providing the determined reachability status and the one or more simulated forwarding paths to a user device associated with the reachability query. The one or more simulated transfer paths, when received by the user device, cause the user device to present the network configuration information for each simulated transfer path.

This aspect may include one or more of any of the following features, wherein in some implementations determining the reachability status of the one or more simulated forwarding paths includes: , using a network abstract state machine. The user device may be configured to send the data packet from a remote network using a locally advertised route. In some examples, the network configuration information includes ports/interfaces for directing the data packets within a virtual private cloud (VPC) network, ports/interfaces for directing the data packets between VPC networks, VPC networks and Ports/interfaces for directing said data packets to and from non-VPC networks, firewall rules applied to said data packets at each step along said corresponding simulated forwarding path, or said corresponding simulated forwarding. network configuration associated with each step along the path.

Optionally, said operations include performing network reachability analysis for each of said one or more simulated forwarding paths based on said corresponding network configuration information. The network reachability analysis comprises: identifying a final state of reachability of the data packets along the corresponding simulated forwarding paths; one or more It may be configured to perform at least one of finding a bad configuration or finding a mismatched or obsolete configuration along said corresponding simulated forwarding path.

In some implementations, the reachability final state is a delivery state indicating that the data packet is delivered to the destination, the data packet is forwarded to another network with an unknown configuration a forwarding state indicating that the data packet is dropped due to a configuration checkpoint failure or missing configuration, or a missing critical configuration indicating that the network reachability analysis is not possible Abort state. Performing the network reachability analysis may comprise performing the network reachability analysis in at least one of an on-demand mode, a continuous mode, a pre-submit mode or a post-submit mode.

In some examples, the packet header further includes a protocol associated with the data packet, a source port associated with the data packet, and a destination port associated with the data packet. The source of the data packet may comprise a first instance running on a first network and the destination of the data packet running on a second network different from the first network. may include a second instance of In some implementations, the first network comprises a VPC network and the second network comprises an on-premises network. The first network and the second network may comprise respective VPC networks.

The source of the data packet may comprise a first instance and the destination of the data packet may comprise a second instance. Both the first instance and the second instance run in the same VPC network. The source of the data packet may be located in an external network and the destination of the data packet may comprise a global HTTPS load balancer running in a VPC network. The global HTTPS load balancer is configured to route the data packets to one of multiple different backends. Generating one or more simulated forwarding paths for the data packet comprises generating a corresponding simulated forwarding path from the global HTTPS load balancer to each of the plurality of different backends. may contain.

The details of one or more implementations of the disclosure are set forth in the accompanying drawings and the description below. Other aspects, features and advantages will be apparent from the description and drawings and from the claims.

1 is a schematic diagram of an exemplary system for performing cloud network reachability analysis; FIG. 2 is a schematic diagram of exemplary components of a virtual machine of the system of FIG. 1; FIG. 2 is a schematic diagram of exemplary components comprising a network abstract state machine of the system of FIG. 1; FIG. FIG. 4 is a schematic diagram of an exemplary report showing determined reachability status of simulated forwarding paths; 4 is a schematic diagram of the network abstract state machine of FIG. 3; FIG. 1 is a schematic diagram of a state diagram of a network abstract state machine for simulating a transfer path between a virtual machine and another virtual machine; FIG. FIG. 2 is a schematic diagram of a state diagram of a network abstract state machine for simulating forwarding paths between virtual machines and load balancers; FIG. 4 is a schematic diagram of a state diagram of a network abstract state machine for simulating a forwarding path between a virtual machine and an on-premises network; FIG. 2 is a schematic diagram of a state diagram of a network abstract state machine for simulating a transfer path between the Internet and virtual machines; FIG. 3 is a schematic diagram of a state diagram of a network abstract state machine for simulating a transfer path between an on-premises network virtual machine and a virtual private cloud virtual machine; Fig. 3 is a table of causes of final reachability states of simulated data packets; Fig. 3 is a table of causes of final reachability states of simulated data packets; Fig. 3 is a schematic diagram of a simulated forwarding path between an external host and a virtual private cloud virtual machine through a load balancer; 4 is a flowchart of an exemplary configuration of operations for a method of performing cloud network reachability analysis; 1 is a schematic diagram of an exemplary computing device that may be used to implement the systems and methods described herein; FIG.

Like reference numbers in different drawings indicate like elements.
DETAILED DESCRIPTION A Virtual Private Cloud (VPC) is an on-demand configurable pool of shared computing resources allocated within a public cloud environment to provide users with independence from other cloud users. be. This independence may be achieved by assigning private Internet Protocol (IP) subnets and/or virtual communication constructs. A VPC consists of one or more virtual machines (VM ) may be executed. Some VPC environments can be very large (i.e., containing a large number of VMs, network gateways, load balancers, etc.) and very complex, so in order to operate and maintain a VPC network Substantial network configuration is often required.

Implementations herein allow a user to specify a packet header with multiple fields (e.g., source and destination addresses, protocol, source and destination ports, etc.) to configure VPC networks, peering VPCs, and so on. to a cloud reachability analyzer that allows to simulate (using packet headers) at least one expected forwarding path of a data packet through a network, a VPN tunnel, and/or to a user's on-premises network; be directed. A cloud reachability analyzer provides configuration information for each simulated path, including, for example, routes and firewall rules. As opposed to actually verifying the state of the forwarding path (i.e., actually sending the data packet), the cloud reachability analyzer instead bases its analysis on the active configuration of the VPC network. Execute. This is sometimes referred to as "intent-based" packet tracing.

That is, the cloud reachability analyzer provides configuration-based static analysis of network reachability within a VPC or between VPC networks and non-VPC networks (eg, on-premises networks). A user may specify one or more parameters in a packet header, and the cloud reachability analyzer generates and simulates packet forwarding paths. The cloud reachability analyzer provides matching configurations (eg, firewall rules, routes, etc.) for each step of each simulated path. Thus, the cloud reachability analyzer enables users to verify intended reachability with network configurations and discover inconsistent, obsolete or incorrectly configured configurations. to help The cloud reachability analyzer also checks and detects errors from new configuration changes and analyzes the impact of network connectivity due to proposed configuration changes.

Referring to FIG. 1, in some implementations, exemplary system 100 includes user devices 10 associated with respective users 12 and connected to networks 60 (eg, the Internet) and on-premises Communicates with remote system 140 over network 70 (ie, the local network that user device 10 uses to connect to network 60). On-premises network 70 includes a network gateway 72 (eg, router) that acts as a forwarding host for on-premises network 70 . User device 10 may correspond to any computing device such as a desktop workstation, laptop workstation or mobile device (ie, smart phone). User device 10 includes computing resources 18 (eg, data processing hardware) and/or storage resources 16 (eg, memory hardware).

Remote system 140 may be a single computer having scalable/resilient resources 142 including computing resources 144 (e.g., data processing hardware) and/or storage resources 146 (e.g., memory hardware); It may be multiple computers, or a distributed system (eg, cloud environment). Data stores (ie, remote storage devices) may be located on storage resources 146 to enable scalable use of storage resources 146 by one or more of clients or computing resources 144 . Remote system 140 is configured to implement and execute one or more virtual machines (VMs) 250, 250a-n. One or more of the VMs securely run 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, frontends and backends.

In the example shown in FIG. 2, distributed system 140 runs one or more of a collection 210 of resources 110 (eg, hardware resource 110h), a virtual machine monitor (VMM) 220, and a VM 250. and a VM layer 240 and an application layer 260 . Each hardware resource 110 h may include one or more physical central processing units (pCPUs) 144 (“physical processors 144 ”) and memory hardware 146 . Each hardware resource 110 h is shown as having a single physical processor 144 , but any hardware resource 110 h may include multiple physical processors 144 . An operating system 212 may run on collection 210 of resources 110 .

In some examples, VMM 220 corresponds to hypervisor 220 (eg, Compute Engine) that includes at least one of software, firmware, or hardware configured to create and execute VM 250 . A computer associated with a VMM 220 (i.e., data processing hardware 144) running one or more VMs 250 is sometimes referred to as a host machine, whereas each VM 250 is referred to as a guest machine. Sometimes. Here, a 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 manage execution of the corresponding guest OS 212g on the VMs 250 . As used herein, each VM 250 may also be referred to as an "instance" or "VM instance." In some examples, multiple instances of various operating systems may share virtualized resources. For example, a first VM 250 with Linux™ operating system, a second VM 250 with Windows™ operating system, and a third VM 250 with OS X™ operating system are all on a single physical x86 machine. can work on.

VM layer 240 includes one or more virtual machines 250 . Distributed system 140 allows users 12 to launch VMs 250 on demand. VM 250 emulates a real computer system and operates based on the computer architecture and functionality of a real or virtual computer system, which may include dedicated 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, is a VM 250 provided (executed) on data processing hardware 144 of distributed system 140 .

Each VM 250 may include one or more virtual central processing units (vCPUs) 252 (“virtual processors”). In the example shown, a first virtual machine 250 a includes a first set 252 a of one or more virtual processors 252 and a second virtual machine 250 b includes a first set 252 a of one or more virtual processors 252 . 2 set 252b. Although the second set 252b is shown as containing only one virtual processor 252, it can contain any number of virtual processors 252. FIG. Each virtual processor 252 emulates one or more physical processors 144 . For example, a first set 252a of one or more virtual processors 252 emulates a first set 113a of one or more physical processors 144 and a second set 113a of one or more virtual processors 252; 252b emulates a second set 113b of one or more physical processors 144; Application layer 260 includes software resources 110 s , 110 sa , 110 sb (software applications) that may run on virtual machine 250 .

Generally, each instance of software (eg, virtual machine 250 ) includes at least one virtual storage device 262 that provides volatile and nonvolatile storage capacity for servicing on physical memory hardware 146 . For example, the storage capacity on the physical memory hardware 146 may include a persistent disk (PD), which may be used to provide volatile memory to the memory hardware 146 or random access memory (PD). RAM) stores data for user 12 across several physical disks (eg, memory area 116 (FIG. 13)). More specifically, each virtual storage device 262 of the corresponding VM 250 stores bytes or bits (blocks) in an associated physical block storage volume V on memory hardware 146 to provide non-volatile storage. Move the data in sequence. Accordingly, the virtual storage device 262 of the corresponding VM instance 250 provides storage capacity that maps to the 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, a portion of the volatile memory (eg, RAM) of physical memory hardware 146 may be distributed across virtual storage devices 262 .

Within guest operating system 212g is guest kernel 214g. A kernel is a computer program that is the core of an operating system with sufficient access and control over the OS. That is, the kernel is an intermediary between host machine applications 110s and hardware resources 110h. Most modern computing systems separate virtual memory into protected kernel space and user space 216g. In general, kernels remain in volatile memory in protected kernel space, separate from user space 216g. To improve security and reliability, applications 110s and other software services typically run in guest user space 216g and have the necessary privileges to interact with the protected kernel space. do not have.

Returning to FIG. 1, the remote system 140 includes a cloud reachability analyzer 150 for analyzing one or more network transport paths 80, 80a-n between or within the VPC network 148 and/or the on-premises network 70. Execute to determine reachability status 172 and/or network configuration information 162 for each network transfer path 80 .

Cloud reachability analyzer 150 receives reachability queries 20 from user devices 10 requesting reachability status 172 of targets. This target may include an on-premises network gateway 72, one or more VMs 250, firewall rules, and/or other components of VCP network 148 such as load balancers (FIG. 11). If the target is a firewall rule, reachability status 172 depends on whether there are packets that could be delivered to VPC network 148 and hit a particular rule in the configuration. Reachability query 20 includes a packet header 22 (eg, Internet Protocol (IP) version 4 (IPv4) or IP version 6 (IPv6) packet header) associated with data packet 24 . In some examples, reachability query 20 includes data packet 24 and associated packet header 22, while in other examples, cloud reachability analyzer 150 receives packet header 22 and A corresponding data packet 24 is generated. The packet header 22 contains a number of data packet parameters 25, 25a-n. For example, packet header 22 includes source Internet Protocol (IP) address 25a and 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.

The cloud reachability analyzer 150 includes a path generator 160 that receives or obtains data packets 24 with associated packet headers 22 . Path generator 160 uses data plane model 164 to generate one or more simulated forwarding paths 80 (also referred to herein as traces) for data packet 24 based on packet header 22 . do. Each simulated forwarding path 80 includes corresponding network configuration information 162 . The data plane model 164 obtains network configuration information 162 from the network components of the VPC network 148, e.g. Ports/interfaces for directing data packets 24 between VPC network 148 and non-VPC networks (e.g., on-premises network 70), at each step along corresponding simulated forwarding path 80 including firewall rules applied to data packets 24 and/or network configuration associated with each step along the corresponding simulated forwarding path 80 . Each step along the simulated forwarding path 80 as used herein refers to an intermediate device (eg, gateway, load balancer, etc.) between the source and destination instances.

In some implementations, data plane model 164 is an ideal 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 a project configuration associated with VPC network 148 . The data plane model 164 analyzes derived instances to identify and verify reachability properties. That is, the data plane model 164 abstracts the relevant network configuration for reachability analysis. Network configuration information 162 may include VPC network configuration information, network service information (eg, load balancer), hybrid cloud configuration, VM configuration and/or platform configuration (eg, platform for containerized applications).

Simulated forwarding path 80 represents the forwarding path of data packet 24 within VPC network 148 and/or between VPC network 148 and on-premises network 70 . For example, one simulated forwarding path 80 represents a forwarding path from a first instance (eg, VM 250a) to a second instance (eg, VM 250b), where the first and second instances are identical. It runs in VPC network 148 . Optionally, the source of the data packets for one simulated forwarding path 80 is an instance (e.g., VM 250) running in the first network, VPC network 148, and the destination is the first network. A second instance (eg, a different VM 250) running in a second network that is a different VPC network 148 from the .

In another example, one simulated forwarding path 80 represents a forwarding path 80 from one VM 250 to an external network (eg, Internet 60). That is, the source of data packet 24 (i.e., source IP address 25a) includes a first instance running in a first network (e.g., VM 250 in VPC network 148), and the destination of data packet 24 (i.e., a VM 250 in VPC network 148). That is, destination IP address 25b) includes a second instance running in a second network (eg, on-premises network 70) that is different from the first network. In yet another example, simulated forwarding path 80 may be from VM 250 to load balancer 1110 (FIG. 11) and/or from VM 250 to on-premises network 70 (eg, via a virtual private network (VPN) tunnel). Represents to gateway 72 . Each of these examples may be reversed in direction. That is, one of the simulated forwarding paths 80 may include Internet 60 to VMs 250 or load balancer 1110 and/or from on-premises network gateway 72 to VMs 250 . User device 10 may be configured to send data packets 24 from a remote network (eg, on-premises network 70) using locally advertised routes. That is, the cloud reachability analysis unit 150 cannot have access to the network configuration information 162 of the on-premises network 70, so the cloud reachability analysis unit 150 does not allow the data packets 24 originating from the on-premises network 70 to Unable to verify if correct routes and firewall rules are configured. However, the cloud reachability analyzer 150 can check whether the configuration from the VPC network 148 allows the data packet 24 to be delivered to its intended destination. The most important configurations checked by the cloud reachability analyzer 150 include advertised routes and ingress firewall rules.

As another example, the source of data packet 24 is located in an external network (eg, on-premises network 70 ) and the destination of data packet 24 includes global HTTPS load balancer 1110 running in VPC network 148 . Global HTTPS load balancer 1110 may be configured to route data packets 24 to one of multiple different backend VMs 250 (FIG. 11). Path generator 160 may generate a corresponding simulated forwarding path 80 from the global HTTPS load balancer to each of multiple different backend VMs 250 .

The exemplary pathways 80 described herein are exemplary only and are not intended to be limiting. That is, the cloud reachability analysis unit 150 may also analyze or simulate other transfer paths 80 . For example, cloud reachability analyzer 150 receives or obtains (eg, from user 12) network configuration information 162 for other networks (eg, on-premises network 70 or peering VPC networks) and performs simulations over those networks. may include a route 80 that is defined. In other words, the cloud reachability analyzer 150 can access any network and associated network components (e.g., gateways, load balancers, frontends, backends) from which the cloud reachability analyzer 150 obtains network configuration information 162. etc.) may be analyzed. In some examples, cloud reachability analysis unit 150 stops analysis when network configuration information 162 is no longer available (eg, at on-premises gateway 72).

The path generator 160 passes the paths 80 and corresponding network configuration information 162 to the path analyzer 170 , which analyzes the target reachability query 20 based on one or more simulated forwarding paths 80 . specifies the reachability status 172 of the . In some examples, path analyzer 170 performs network reachability analysis for each of one or more simulated forwarding paths 80 based on corresponding network configuration information 162 . The path analysis unit 170 may perform network reachability analysis in at least one of on-demand mode, continuous mode, pre-submit mode, or post-submit mode. For example, the reachability query 20 may be used until the user device 10 instructs the cloud reachability analyzer 150 to stop (or until some other threshold is met, e.g., until some time has passed). It may indicate a request for a single simulation or a series of simulations. In some implementations, the path analyzer 170 either by finding one or more bad configurations along the corresponding simulated transfer path 80 or A final state 172 (also referred to herein as reachability status 172) of reachability of data packet 24 along corresponding simulated forwarding path 80 is determined by finding inconsistent or obsolete configurations. ).

Cloud reachability analyzer 150 provides determined reachability status 172 and one or more simulated forwarding paths 80 to user device 10 associated with reachability query 20 . As described in more detail below, one or more of the simulated forwarding paths 80 , when received by the user device 10 , provides the user device 10 with network configuration information 162 for each simulated forwarding path 80 . is presented to the user 12 .

Referring now to FIG. 3A, in some implementations path analyzer 170 includes a network abstract state machine (NAM) 400 for generating one or more simulated forwarding paths 80 . NAM 400 may be an idealized model of how VPC network 148 processes data packets. In some examples, NAM 400 is abstract and thus independent of the actual implementation of VPC network 148 . Optionally, the NAM 400 identifies a reachability final state 172 for the data packet 24, the reachability final state 172 being a delivery state 174a indicating that the data packet 24 is delivered to its destination, the data packet 24 is forwarded to another network with an unknown configuration; a deleted state 174c, indicating that the data packet 24 is deleted due to a configuration checkpoint failure or missing configuration; It includes any one of the abort states 174d indicating that network reachability analysis is not possible due to lack. NAM 400 may be non-deterministic in that a state may have multiple successor states. For example, if several routes with the same IP mask and priority are applied to a data packet, a route is selected among them based on an unspecified hash function. This is basically a deterministic process, but is better modeled by choosing one of the routes non-deterministically. This is because hash functions are internal implementations that are subject to change.

Referring now to FIG. 3B, cloud reachability analyzer 150 provides user device 10 with an identified reachability status 172 of each simulated transfer path 80 . This causes the user device to present network configuration information 162 for each simulated transfer path 80 to user 12 . For example, report 300 may show user 12 details about generated data packets 24 (eg, packet headers 22). Report 300 may show information associated with each step 310 , 310 a - n or hop along traced or simulated forwarding path 80 . In the example shown, the data packet 24 departs from the source instance in step 310a (i.e., step 0), is subjected to egress firewall rules in step 310b (i.e., step 1), and is subjected to step 310c (i.e., step 1). The data packet is routed in step 2), reaches the destination instance in step 310d (i.e. step 3), ingress firewall rules are applied in step 310e (i.e. step 4), and step 310f (i.e. step 5) to the destination instance at . Each of these steps 310 includes associated network configuration information 162 .

The report 300 may indicate the reason or basis for the identified reachability status 172 of each simulated forwarding path 80 (e.g., the packet was dropped because it was denied by a firewall rule) and its purpose to aid in troubleshooting and/or detect network connections caused by inconsistent and invalid configurations, or to verify new or changed configurations. In some examples, cloud reachability analysis unit 150 provides configuration change impact analysis. Each of the simulated transfer paths 80 may be presented as part of a graphical user interface (GUI) on the user device as part of an application (eg, web browser). Although the example shown provides details for only one transfer path 80 (ie, trace 1), each simulated transfer path 80 (ie, multiple traces) may be provided. In some examples, the report 300 includes a summary section 320 showing the determined reachability status 172 of the data packet 24 .

Referring now to FIG. 4, in some implementations, NAM 400 includes an egress check 410, an ingress check 420, and a path specific check 430. In some examples, egress checks 410 include egress firewall checks 412 and matching routes 414 . The egress firewall check looks for matching egress firewall rules (eg, in network configuration information 162). Egress firewall rules are firewall rules that apply to the source instance (eg, VM 250). Matching route 414 may locate and apply a suitable route for simulated forwarding path 80 . Matching route 414 may also determine whether there is a matching route for destination IP address 25b when the source instance is VM 250 . If no route matches, NAM 400 may match the route with a default route with the next hop as the Internet gateway. Ingress firewall check 422, like egress firewall check 412, locates and applies matching ingress firewall rules (ie, firewall rules that apply to the destination instance).

Path-specific checks 430 are based on the type of simulated forwarding path 80 that NAM 400 is evaluating. That is, the path-specific checks 430 depend on the source and destination instances of the simulated forwarding path 80 . For example, if the destination instance is VPN gateway 432 over VPN tunnel 434, then certain states (FIG. 7) are included in evaluation by NAM 400. FIG. Similarly, if the destination instance is a load balancer with forwarding rules 436, different states (FIGS. 6 and 8) are evaluated. If the destination instance is a peering network gateway 438, yet another state is evaluated in the NAM 400 state machine.

5-9 illustrate exemplary state machines 500, 600, 700, 800, 900 representing NAM 400 in analyzing various simulated forwarding paths 80 of data packet 24. FIG. For example, FIG. 5 shows state machine 500 of NAM 400 in analyzing simulated forwarding path 80 between first VM 250 and second VM 250 or from first VM 250 to Internet 60 . State machine 500 starts with instance state 510 corresponding to source VM 250 . From there, the state machine 500 goes to an abort state 512 (e.g. parsing cannot continue due to missing network configuration information 162), applies egress firewall rules 514, or VMs 250 send and receive data packets with foreign IPs. Spoof Check 518 state allowed to. In the delete state 516 , the data packet 24 may be deleted due to a failed network configuration check or missing network configuration information 162 . At state 520 the appropriate route is found and applied, at state 522 the data packet 24 may reach the VM instance, and at state 528 the data packet 24 is of unknown composition (hence the parsing stopped), the packet header 22 may be modified by network address translation (NAT) at state 526, or ingress firewall rules may be applied at state 524. In state 530 , data packet 24 is delivered to the destination specified in packet header 22 .

Referring now to Figure 6, state machine 600 represents NAM 400 in analyzing simulated forwarding path 80 between VM 250 and load balancer 1110 (Figure 11). State machine 600 starts with instance state 610 corresponding to source VM 250 . From there, the state machine 600 goes to an abort state 612 (e.g. parsing cannot continue due to missing network configuration information 162), apply egress firewall rules 614, or allow VM 250 to send and receive data packets with external IPs. Spoof Check 618 state. In delete state 616 , data packet 24 may be deleted due to a failed network configuration check or missing network configuration information 162 . In state 620 an appropriate route is found and applied, and in state 622 it may be forwarded to another network whose configuration is unknown (hence parsing stops). At state 624 , NAM 400 applies the appropriate forwarding rules and reaches internal or external load balancer 1110 at state 626 . From there, the data packet 24 may be forwarded to one or more backends 628 , 628 a - n where the data packet is either dropped at state 630 or delivered at state 632 .

Referring now to FIG. 7, state machine 700 represents NAM 400 in analyzing simulated forwarding path 80 between VM 250 and on-premises network 70 via VPN. State machine 700 starts with instance state 710 corresponding to source VM 250 . From there, the state machine 600 goes to an abort state 712 (e.g. parsing cannot continue due to missing network configuration information 162), apply egress firewall rules 714, or allow VM 250 to send and receive data packets with external IPs. spoof check 718 state. In the delete state 716 , the data packet 24 may be deleted due to a failed network configuration check or missing network configuration information 162 . Appropriate routes are found and applied in state 720, forwarded to another network whose configuration is unknown (thus parsing stops) in state 722, and then one or more on-premises backends 728. , 728a-n. At state 724 the data packet 24 reaches the local side of the VPN tunnel, and at state 726 the data packet 24 may reach the VPN gateway and be forwarded to one or more VCP backends 628 .

Referring now to FIG. 8, state machine 800 represents NAM 400 in analyzing simulated forwarding path 80 between Internet 60 and VM 250 or between Internet 60 and load balancer 1110 . State machine 800 begins with Internet state 810 of a data packet 24 originating from Internet 60 . From there, state machine 800 may proceed to state 816 where data packet 24 is dropped due to a failed network configuration check or missing network configuration information 162 . State machine 800 may also proceed to state 812 to modify packet header 22 with NAT. From NAT state 812 , data packet 24 reaches VM instance at 818 and is either dropped at state 820 or delivered at state 822 . State machine 800 may also proceed to state 814, where if the destination is load balancer 1110, apply the appropriate forwarding rules. From there, state machine 800 proceeds to state 824 where data packet 24 reaches the external load balancer. State machine 800 then transitions to proxy connection state 826, in which the previous connection is proxied to the new connection, and NAM 400 prepares the new data packet 24 for subsequent tracing or simulation. Generate. Otherwise, state machine 800 simulates forwarding data packet 24 to one or more backends 628 , and the data packet is dropped at state 828 or delivered at state 830 .

Referring now to FIG. 9, state machine 900 represents NAM 400 in analyzing simulated forwarding path 80 between on-premises network 70 (eg, a VM located within on-premises network 70) and VCP VM 250. . Here, state machine 900 begins at state 910 where data packet 24 originates from a private network (eg, on-premises network 70). From there, state machine 900 transitions to state 912 to apply the appropriate route. The state machine 900 then drops the packet due to a failed network configuration check or missing network configuration information 162 at state 914 or proceeds to reach the instance at state 916 . From there, NAM 400 applies ingress firewall rules at state 918 and delivers data packets at state 920 .

In some examples, cloud reachability analyzer 150 simulates forwarding path 80 by tracing the route advertised by VPC network 148 back to on-premises network 70 . Cloud reachability analysis unit 150 typically does not have access to on-premises network configuration, but cloud reachability analysis unit 150 can configure static and dynamic routes to on-premises network 70, e.g., via a VPN. have access to Accordingly, the cloud reachability analyzer may simulate routes of the VPC network 148 that the on-premises network 70 should have configured or received for dynamic routes. If data packet 24 is sourced from an on-premises network range (derived from VPN-related routes), cloud reachability analyzer 150 may apply a "guessed" route on the packet.

10A and 10B, Tables 1000a, 1000b show possible final reachability states 172 (i.e., deleted 174a, forwarded 174b, delivered 174c or aborted 174d) of a data packet in NAM 400, from the final state The previous NAM 400 states (FIGS. 5-9) and the associated causes of the final state are shown. That is, tables 1000a, 1000b provide examples of what causes state machines 500, 600, 700, 800, 900 to transition to final states 174a-d.

Referring now to FIG. 11 , exemplary forwarding path 80 c starts at an external host (eg, user device 10 ) and goes through Internet 60 to load balancer 1110 within VPC network 148 . Load balancer 1110 forwards the data packets to front-end servers 1020 , which distribute the data packets to one or more back-ends or VMs 250 . In this scenario, forwarding path 80c is more complex than typical network level load balancers. In this example, cloud reachability analyzer 150 traces data packets 24 from an external host (eg, user device 10) to load balancer 1110 (eg, a global HTTPS load balancer). In some examples, the load balancer is a proxy load balancer, so the TCP connection terminates at the frontend server 1020 and the frontend server 1020 opens a new TCP connection with one or more backend VMs 250. Start. The Cloud Reachability Analyzer uses NAM 400 to simulate this behavior. In a real data plane, a load balancing algorithm may select a VM for each connection, but cloud reachability analyzer 150 does not predict data plane paths, but instead identifies any configuration issues. It may also be a static configuration analysis tool that provides the user with more visibility into expected behavior. Thus, in this case, cloud reachability analyzer 150 provides a trace for each possible path (e.g., a first trace for VM 250a, a second trace for VM 250b, and a third trace).

FIG. 12 is a flowchart of an exemplary configuration of operations for a method 1200 of performing cloud network reachability analysis. Method 1200 includes, at operation 1202 , receiving reachability query 20 requesting reachability status 172 of target 70 , 250 , 1110 at data processing hardware 144 . The reachability query 20 includes a packet header 22 associated with the data packet 24, the packet header 22 associated with the source IP address 25a associated with the source of the data packet 24 and the destination of the data packet 24. and the destination IP address 25b.

At operation 1204 , method 1200 causes data processing hardware 144 to generate one or more simulated forwarding paths 80 for data packet 24 based on packet header 22 using data plane model 164 . include. Each simulated forwarding path 80 includes corresponding network configuration information 162 . At operation 1206 , method 1200 includes data processing hardware 144 determining reachability status 172 of target 70 , 250 , 1110 based on one or more simulated transfer paths 80 . At operation 1208 , method 1200 causes data processing hardware 144 to transmit the identified reachability status 172 and one or more simulated forwarding paths 80 to user device 10 associated with reachability query 20 . including the step of providing. When one or more simulated transfer paths 80 are received by user device 10 , cause user device 10 to present network configuration information 162 for each simulated transfer path 80 .

FIG. 13 is a schematic diagram of an exemplary computing device 1300 that can be used to implement the systems and methods described herein. Computing device 1300 is intended to represent various forms of digital computers such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes and other suitable computers. The components, their connections and relationships, and their functions shown herein are intended to be exemplary only and are intended to implement the invention described and/or claimed herein. The examples are not intended to be limiting.

Computing device 1300 includes processor 1310, memory 1320, storage device 1330, high speed interface/controller 1340 connecting to memory 1320 and high speed expansion port 1350, low speed interface/controller connecting to low speed bus 1370 and storage device 1330. 1360 and . Each of the components 1310, 1320, 1330, 1340, 1350 and 1360 are interconnected using various buses and may be mounted on a common motherboard or otherwise as appropriate. Processor 1310 can process instructions for execution within computing device 1300 and these instructions can be presented to a graphical user interface (GUI) on an external input/output device such as display 1380 coupled to high speed interface 1340 . ), including instructions stored in memory 1320 or on storage device 1330 for displaying graphical information for. In other implementations, multiple processors and/or multiple buses may be used, as appropriate, along with multiple memories and types of memory. Also, multiple computing devices 1300 may be connected, each providing a portion of the required operations (eg, as a server bank, a group of blade servers, or a multi-processor system).

Memory 1320 non-transitory stores information within computing device 1300 . Memory 1320 may be a computer-readable medium, a volatile memory unit or a non-volatile memory unit. Non-transitory memory 1320 is a physical memory used to temporarily or permanently store programs (eg, sequences of instructions) or data (eg, program state information) for use by computing device 1300 . device. Examples of non-volatile memory include flash memory and read-only memory (ROM)/programmable read-only memory (PROM)/erasable programmable read-only memory (EPROM)/electronically erasable programmable read-only memory (EEPROM). (for example, commonly used in firmware such as boot programs), but is not limited to these. 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 disk or tape. not something.

Storage device 1330 may provide mass storage for computing device 1300 . In some implementations, storage device 1330 is a computer-readable medium. In various different implementations, storage device 1330 may be a floppy disk device, hard disk device, optical disk device, or tape device, flash memory or other similar solid state device, including devices in a storage area network or other configuration. It may be a state memory device, or an array of devices. In a further implementation, a computer program product is tangibly embodied in an information carrier. The computer program product contains instructions that, when executed, perform one or more methods, such as the methods described above. The information carrier is a computer or machine-readable medium such as memory 1320 , storage device 1330 or memory-on-processor 1310 .

High speed controller 1340 manages bandwidth-intensive operations for computing device 1300, while low speed controller 1360 manages less bandwidth-intensive operations. Such role assignments are exemplary only. In some implementations, high speed controller 1340 is coupled to memory 1320, display 1380 (eg, via a graphics processor or accelerator), and high speed expansion port 1350, which may accept various expansion cards (not shown). . In some implementations, low speed controller 1360 is coupled to storage device 1330 and low speed expansion port 1390 . A low-speed expansion port 1390, which may include various communication ports (e.g., USB, Bluetooth, Ethernet, Wireless Ethernet), provides access to one or more input/output devices (e.g., via a network adapter). keyboards, pointing devices, scanners, etc.) or networking devices (such as switches or routers).

Computing device 1300 may be embodied in many different forms, as shown in the figures. For example, it may be implemented as a standard server 1300a, or it may be implemented multiple times in a group of such servers 1300a, or it may be implemented as a laptop computer 1300b, or a rack server system 1300c. may be implemented as part of

Various implementations of the systems and techniques described herein may include digital electronic and/or optical circuits, integrated circuits, specially designed ASICs (Application Specific Integrated Circuits), computer hardware, firmware, software , and/or combinations thereof. These various implementations can include implementations in one or more computer programs executable and/or interpretable on a programmable system that includes at least one programmable processor, where the at least one programmable processor , a special purpose processor or a general purpose processor, coupled to transmit and receive data and instructions to and from the storage system, at least one input device and at least one output device.

A software application (ie, software resource) may be computer software that causes a computing device to perform a task. In some instances, software applications may also be referred to as "applications," "apps," or "programs." Examples of 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. not a thing

These computer programs (also known as programs, software, software applications or code) contain machine instructions for programmable processors and are written in high-level procedural and/or object-oriented programming languages and/or in assembly / can be implemented in machine language. The terms "machine-readable medium" and "computer-readable medium" as used herein refer to machine instructions and/or data programmable, including machine-readable media that receive machine instructions as machine-readable signals. Refers to any computer program product, non-transitory computer-readable medium, apparatus and/or device (eg, magnetic disk, optical disk, memory, programmable logic device (PLD)) used to provide a processor. The term "machine-readable signal" refers to any signal used to provide machine instructions and/or data to a programmable processor.

The processes and logic flows described herein can be performed by one or more programmable processors, also referred to as data processing hardware, which process data on input data. Execute one or more computer programs to perform functions by operating on and generating output. The processes and logic flows may also be performed by special purpose logic circuits (eg, FPGAs (Field Programmable Gate Arrays) or ASICs (Application Specific Integrated Circuits)). Processors suitable for the execution of a computer program include, by way of example, any one or more processors of any kind of digital computer, both general and special purpose microprocessors. Generally, a processor receives instructions and data from read-only memory and/or random-access memory. The essential elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Generally, a computer also includes one or more mass storage devices (e.g., magnetic, magneto-optical or optical disks) for storing data or receiving data from one or more mass storage devices. operatively coupled to transmit, transmit, and receive. 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 memories, media and memory devices, by way of example, semiconductor memory devices (e.g., EPROM, EEPROM and flash memory devices). , magnetic disks (eg, internal or removable disks), magneto-optical disks, and CD ROM and DVD-ROM disks. The processor and memory may be supplemented by, or incorporated into, special purpose logic circuitry.

To provide user interaction, one or more aspects of the present disclosure include a display device (e.g., a CRT (cathode ray tube), LCD (liquid crystal display) monitor or touch screen) for displaying information to the user. and, optionally, a keyboard and pointing device (eg, a mouse or trackball) that allows a user to provide input to the computer. Other types of devices may also be used to provide user interaction, for example, the feedback provided to the user may be any form of sensory feedback (e.g., visual, auditory, or tactile feedback). The input from the user may be received in any form including acoustic, speech or tactile input. The computer also sends and receives documents to and from the device used by the user, e.g., by sending web pages to the web browser on the user's client device in response to requests received from the web browser. Can interact with the user.

We have described several implementations. However, it will be understood that various modifications may be made without departing from the spirit and scope of the disclosure. Accordingly, other implementations are within the scope of the following claims.

Claims (29)

A method (1200) of cloud network reachability analysis, comprising:
receiving, in data processing hardware (144), a reachability query (20) requesting the reachability status (172) of a target (70, 250, 1110) over a network; The query (20) comprises a packet header (22) associated with a data packet (24), said packet header (22) comprising:
a source Internet Protocol (IP) address (25a) associated with the source of said data packet (24);
a destination IP address (25b) associated with the destination of the data packet (24);
The method (1200) further comprises:
in said data processing hardware (144) using a data plane model (164) to simulate one or more forwarding paths (80) of said data packet (24) based on said packet header (22); each simulated forwarding path (80) comprises corresponding network configuration information (162) associated with said network , said method (1200) further comprising:
In each simulated transfer path of said one or more simulated transfer paths (80):
determining in data processing hardware (144) from said corresponding network configuration information (162) at least one egress firewall rule of a first instance to be applied to said respective simulated forwarding path;
determining in data processing hardware (144) from said corresponding network configuration information (162) at least one ingress firewall rule of a second instance to be applied to each simulated forwarding path;
In said data processing hardware (144), from said corresponding network configuration information (162), a path specific check based on each simulated transfer path type based on said first instance and said second instance. a step of determining
In said data processing hardware (144 ), using said path specific checks, based on said at least one egress firewall rule and said at least one ingress firewall rule, said target (70, 250, 1110) identifying said reachability status (172);
in said data processing hardware (144) each determined reachability status (172) and said one or more simulated forwarding paths (80) are associated with said reachability query (20); and providing said one or more simulated forwarding paths (80) to said source , upon receipt by said source , each simulated forwarding path ( presenting the corresponding network configuration information (162) of 80) ;
The presented network configuration information (162) includes:
said at least one egress firewall rule for said first instance;
and said at least one ingress firewall rule of said second instance . The method of claim 1, wherein determining the reachability status (172) of the one or more simulated forwarding paths (80) comprises using a network abstract state machine (400). (1200). The method (1200) of claim 1 or claim 2, wherein the source is configured to transmit the data packet (24) from a remote network using a locally advertised route. The network configuration information (162) includes:
a port/interface for directing said data packet (24) within a Virtual Private Cloud (VPC) network (148) ; or
ports/interfaces for directing said data packets (24) between VPC networks (148);
ports/ interfaces for directing said data packets (24) between a VPC network (148) and a non-VPC network (70). or the method of claim 1 (1200). performing, at said data processing hardware (144), a network reachability analysis for each of said one or more simulated forwarding paths (80) based on said corresponding network configuration information (162); The method (1200) of any one of claims 1 to 4, further comprising steps. The network reachability analysis includes:
identifying a final state of reachability of the data packet (24) along the corresponding simulated forwarding path (80);
finding one or more bad configurations along said corresponding simulated transfer path (80); or finding mismatched or obsolete configurations along said corresponding simulated transfer path (80). 6. The method (1200) of claim 5, configured to perform at least one of: discovering. The final state of reachability is
a delivery status (174a) indicating that the data packet (24) is delivered to the destination;
a forwarding state (174b) indicating that the data packet (24) is forwarded to another network with an unknown configuration;
A deleted state (174c) indicating that said data packet (24) is deleted due to configuration checkpoint failure or missing configuration, or indicating that said network reachability analysis is not possible due to missing critical configuration. 7. The method (1200) of claim 6, comprising any one of: an abort state (174d). Said packet header (22) further comprises:
a protocol (25c) associated with said data packet (24);
a source port (25d) associated with said data packet (24);
A destination port (25e) associated with the data packet ( 24 ). The source of the data packet (24) comprises the first instance running in a first network and the destination of the data packet (24) is a second network different from the first network. The method (1200) of any one of claims 1 to 8 , comprising the second instance running in a network of . 10. The method (1200) of claim 9 , wherein the first network comprises a Virtual Private Cloud (VPC) network (148) and the second network comprises an on-premises network (70). 10. The method (1200) of claim 9 , wherein the first network and the second network comprise respective virtual private cloud (VPC) networks (148). said source of said data packet (24) comprises said first instance and said destination of said data packet (24) comprises said second instance, said first instance also comprising said second instance The method (1200) of any one of claims 1 to 8 , wherein the instances are also run in the same Virtual Private Cloud (VPC) network (148). The source of the data packet (24) is located in an external network and the destination of the data packet (24) is a global HTTPS load balancer (1110) running in a Virtual Private Cloud (VPC) network (148). ), wherein the global HTTPS load balancer (1110) is configured to route the data packets (24) to one of a plurality of different backend virtual machines (VMs) (250). The method (1200) of any of claims 1-12 . generating one or more simulated forwarding paths (80) for said data packets (24) from said global HTTPS load balancer (1110) to each of said plurality of different backend VMs (250); 14. The method (1200) of claim 13 , comprising generating a simulated forwarding path (80) corresponding to . A system (100) comprising:
data processing hardware;
memory hardware in communication with the data processing hardware, the memory hardware storing instructions which, when executed on the data processing hardware, cause the data processing hardware to perform operations; Executed, said operation comprising:
receiving a reachability query (20) requesting the reachability status (172) of a target (70, 250, 1110) over a network , said reachability query (20) comprising a data packet ( 24) associated with a packet header (22), said packet header (22) comprising:
a source Internet Protocol (IP) address (25a) associated with the source of said data packet (24);
a destination IP address (25b) associated with the destination of the data packet (24);
Said operation further comprises:
generating one or more simulated forwarding paths (80) for said data packets (24) based on said packet headers (22) using a data plane model (164); The forwarded path (80) comprises corresponding network configuration information (162) associated with said network , said operation further comprising:
In each simulated transfer path of said one or more simulated transfer paths (80):
determining from said corresponding network configuration information (162) at least one egress firewall rule of a first instance to be applied to said respective simulated forwarding path;
determining from said corresponding network configuration information (162) at least one ingress firewall rule for a second instance to be applied to each simulated forwarding path;
determining, from the corresponding network configuration information (162), path-specific checks based on each simulated forwarding path type based on the first instance and the second instance;
determining the reachability status (172) of the target (70, 250, 1110) based on the one or more simulated forwarding paths (80);
providing the determined reachability status (172) and the one or more simulated forwarding paths (80) to a source associated with the reachability query (20); Said one or more simulated forwarding paths (80), when received by said source , transmits to said source said corresponding network configuration information (162) for each simulated forwarding path (80) to present
The presented network configuration information is
said at least one egress firewall rule for said first instance;
and said at least one ingress firewall rule of said second instance . 16. The system of claim 15 , wherein determining the reachability status (172) of the one or more simulated forwarding paths (80) comprises using a network abstract state machine (400). (100). 17. A system (100) according to claim 15 or 16 , wherein said source is configured to transmit said data packet (24) from a remote network using a locally advertised route. The network configuration information (162) includes:
a port/interface for directing said data packet (24) within a Virtual Private Cloud (VPC) network (148);
a port/interface for directing said data packets (24) between VPC networks (148) ; or
ports/ interfaces for directing said data packets ( 24 ) between a VPC network (148) and a non-VPC network ( 70 ). or the system (100) of claim 1. Said operation further comprises performing a network reachability analysis for each of said one or more simulated forwarding paths (80) based on said corresponding network configuration information (162). The system (100) of any one of claims 15-18 . The network reachability analysis includes:
identifying a final state of reachability of the data packet (24) along the corresponding simulated forwarding path (80);
finding one or more bad configurations along said corresponding simulated transfer path (80); or finding mismatched or obsolete configurations along said corresponding simulated transfer path (80). 20. The system (100) of claim 19 , configured to perform at least one of: discovering. The final state of reachability is
a delivery status (174a) indicating that the data packet (24) is delivered to the destination;
a forwarding state (174b) indicating that the data packet (24) is forwarded to another network with an unknown configuration;
A deleted state (174c) indicating that said data packet (24) is deleted due to configuration checkpoint failure or missing configuration, or indicating that said network reachability analysis is not possible due to missing critical configuration. The system (100) of claim 20 , comprising any one of: an abort state (174d). Said packet header (22) further comprises:
a protocol (25c) associated with said data packet (24);
a source port (25d) associated with said data packet (24);
A destination port (25e) associated with the data packet ( 24 ). The source of the data packet (24) comprises the first instance running in a first network and the destination of the data packet (24) is a second network different from the first network. 23. The system (100) according to any one of claims 15 to 22 , comprising said second instance running in a network of . 24. The system (100) of claim 23 , wherein the first network comprises a Virtual Private Cloud (VPC) network (148) and the second network comprises an on-premises network (70). 24. The system (100) of claim 23 , wherein the first network and the second network comprise respective virtual private cloud (VPC) networks (148). said source of said data packet (24) comprises said first instance and said destination of said data packet (24) comprises said second instance, said first instance also comprising said second instance 23. The system (100) of any one of claims 15 to 22 , wherein the instances also run in the same Virtual Private Cloud (VPC) network (148). The source of the data packet (24) is located in an external network and the destination of the data packet (24) is a global HTTPS load balancer (1110) running in a Virtual Private Cloud (VPC) network (148). ), wherein the global HTTPS load balancer (1110) is configured to route the data packets (24) to one of a plurality of different backend virtual machines (VMs) (250). 27. The system (100) of any of claims 15-26 . generating one or more simulated forwarding paths (80) for said data packets (24) from said global HTTPS load balancer (1110) to each of said plurality of different backend VMs (250); 28. The system (100) of claim 27 , comprising generating a simulated transfer path (80) corresponding to . A program for causing a computer to execute the method according to any one of claims 1 to 14 .

Images