Using peering intelligently in public clouds

Abstract

The present disclosure relates to the intelligent use of peering in a public cloud. Integrating an overlay logical network into a cloud provider network introduces new challenges that do not exist in either system alone. For example, some virtual private clouds (VPCs) provided by cloud providers do not allow transitive routing using the cloud-provided network, which makes it difficult to route traffic for services that need to be provided at a service VPC to the service VPC as part of the route from the source VPC to the destination VPC. In addition, some services provided by cloud providers rely on using addresses assigned by the cloud provider and do not integrate well with compute nodes that are assigned addresses in an overlay logical network.

Description

[0001] This application is a divisional application of the invention patent application with the application date of August 14, 2019, application number 201980055833.9, and invention name “Intelligent use of peers in public clouds”. Technical Field

[0002] The present disclosure relates to intelligent use of peering in a public cloud. Background Art

[0003] Integrating an overlay logical network into a cloud provider network introduces new challenges that do not exist in either system alone. For example, some virtual private clouds (VPCs) provided by cloud providers do not allow transitive routing using the cloud-provided network, which makes it difficult to route traffic for services that need to be provided at a service VPC to the service VPC as part of the route from the source VPC to the destination VPC. In addition, some services provided by cloud providers rely on using addresses assigned by the cloud provider and do not integrate well with compute nodes that are assigned addresses in an overlay logical network. Summary of the invention

[0004] Some embodiments provide a centralized overlay network cloud gateway and a set of centralized services in a transit virtual cloud network (VCN), which is connected to multiple other computing VCNs that host computing nodes (VMs, containers, etc.) that are part of (belong to) an overlay network. In some embodiments, a centralized overlay network cloud gateway executed in a transit VCN is used instead of multiple overlay network cloud gateways executed in multiple non-transit VCNs to reduce costs and management overhead. The centralized overlay network cloud gateway provides connections between computing nodes in an overlay network (e.g., a logical network spanning multiple VCNs) and computing nodes in an external network. In some embodiments, the centralized overlay network cloud gateway also provides services for data messages that it processes. In some embodiments, services are provided by a combination of a cloud gateway and third-party services accessed by or through the gateway.

[0005] Some embodiments use a centralized overlay network cloud gateway to provide transitive routing (e.g., routing through a transit VPC) in the absence of direct peering between a source VPC and a destination VPC. In some embodiments, the cloud gateway is accessed from each VPC through a peering relationship established between the transit VPC and the VPC. In some embodiments, a managed forwarding element (MFE) of a logical routing element (LRE) that implements connecting a logical switching element of a logical network to a centralized logical routing element implemented by a cloud gateway performs a set of forwarding operations to direct data messages to the transit VPC. The overlay network of some embodiments uses the same subnet division and default gateway address for each computing node as the cloud provider network provided by a virtual private cloud provider. Using the same address space as the cloud provider network allows seamless integration of services provided by the cloud provider network, and utilizing the novel method of forwarding data messages disclosed herein also allows seamless integration with services provided by the overlay network.

[0006] In embodiments where the same address space is used in both the cloud provider and the overlay network, in order to correctly direct traffic (i.e., using the cloud provider network infrastructure or through a tunnel for implementing an overlay network), some embodiments provide methods and arbitrator modules for determining the correct method of forwarding data messages sent by a computing node (e.g., as part of a managed forwarding element that implements a hybrid switching element that provides logical forwarding for both the overlay network and the cloud provider network). In some embodiments, the arbitrator module determines whether the destination computing node is in the same or different VPC as the source computing node. When the source computing node and the destination computing node are on the same VPC, the default behavior is to use the cloud provider infrastructure for routing. However, if the centralized service is to be provided by a service engine in a transit VPC, the user (e.g., an administrator) can override this default behavior and use an overlay network (i.e., tunneling to a cloud gateway in a transit VPC). When the source computing node and the destination computing node are on different VPCs, the default behavior is to use an overlay network (i.e., a cloud gateway in a transit VPC) to route data messages. This approach allows administrators to override the default behavior for data messages that (1) do not require services provided by a service engine in a transit VPC and (2) for which there is peering between the source VC and the destination VPC (e.g., a tunnel provided by a cloud provider infrastructure).

[0007] In some embodiments, the default behavior for data messages between compute nodes in VPCs (e.g., peer VPCs) connected by a cloud provider tunnel is to use an overlay logical network and a centralized overlay network cloud gateway to route data messages. In order to override the default and forward data messages between VPCs using peer relationships, in some embodiments, the administrator configures a policy-based routing (PBR) rule in the arbitrator module of the MFE that directs the MFE to forward data messages using peers between VPCs. If the default behavior is not overridden using a PBR rule or other method, then the overlay network is used to route data messages that require services provided in the transit VPC based on the routing table implemented by the distributed router. In some embodiments, the routing decision is configured by a PBR implementation that determines the next hop based on a policy defined by the characteristics of the data message or data message flow in addition to the destination address (e.g., a five-tuple specifying the source IP address / port number and the destination IP address / port number and the protocol).

[0008] In some embodiments, the default behavior for data messages between compute nodes in VPCs connected by cloud provider tunnels (e.g., peer VPCs) is to route the data messages using the cloud provider tunnels. In such embodiments, the overlay network is used to route data messages that require services provided in the transit VPC by having the administrator delete the route to the destination compute node (e.g., the route associated with the IP address or subnet of the destination compute node) from the routing table of the distributed router implementation. In some embodiments, the routing decision is configured by a policy-based routing implementation that determines the next hop based on a policy that can be defined by characteristics of the data message or data message flow in addition to the destination address (e.g., a five-tuple specifying the source IP address / port number and the destination IP address / port number and the protocol).

[0009] The foregoing summary is intended to serve as a brief introduction to some embodiments of the present invention. It is not meant to be an introduction or overview of all inventive subject matter disclosed in this document. The following detailed description and the drawings cited in the detailed description will further describe the embodiments described in the summary as well as other embodiments. Therefore, in order to understand all the embodiments described in this document, a comprehensive review of the summary, the detailed description, the drawings, and the claims is required. In addition, the claimed subject matter is not limited by the illustrative details in the summary, the detailed description, and the drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] The novel features of the invention are set forth in the appended claims. However, for purposes of illustration, several embodiments of the invention are set forth in the following figures.

[0011] Figure 1The logical topology of some embodiments is conceptually illustrated as an administrator might input the topology into the management plane.

[0012] Figure 2 An embodiment using a centralized transit VPC that provides access to external networks for compute nodes executing in a compute VPC is illustrated.

[0013] Figure 3 An embodiment is illustrated that uses a centralized transit VPC that provides transit routing and access to external networks for compute nodes executing in any of multiple compute VPCs.

[0014] Figure 4 The diagram shows Figure 3 The system is mostly the same as the one in Figure 1 but with additional peering relationships indicated by the connections that exist between the VPCs.

[0015] Figure 5 Conceptually illustrates the processing performed by a managed forwarding element (MFE) to intelligently forward data messages received from a compute node using one of an overlay network or a cloud provider network.

[0016] Figure 6 A set of possible data message paths and headers for intra-VPC traffic in some embodiments is illustrated.

[0017] Figure 7 A set of inter-VPC data message flows in the system of some embodiments is illustrated.

[0018] Figure 8 Conceptually illustrates the configuration of an MFE in some embodiments to implement Figure 5 of the processing of the processing.

[0019] Fig. 9 A computer system for implementing some embodiments of the invention is conceptually illustrated. DETAILED DESCRIPTION

[0020] In the following detailed description of the present invention, many details, examples and embodiments of the present invention are set forth and described. However, it will be apparent to those skilled in the art that the present invention is not limited to the embodiments set forth, and the present invention can be practiced without some of the specific details and examples discussed.

[0021] Some embodiments provide a centralized overlay network cloud gateway and a set of centralized services in a transit virtual cloud network (VCN) that is connected to multiple other computing VCNs that host computing nodes (VMs, containers, etc.) that are part of (belong to) an overlay network. In some embodiments, a centralized overlay network cloud gateway executed in a transit VCN is used instead of multiple overlay network cloud gateways executed in multiple non-transit VCNs to reduce costs and management overhead. The centralized overlay network cloud gateway provides connections between computing nodes of an overlay network (e.g., a logical network spanning multiple VCNs) and computing nodes in an external network. In some embodiments, the centralized overlay network cloud gateway also provides services for data messages that it processes. In some embodiments, services are provided by a combination of a cloud gateway and third-party services accessed by or through the gateway.

[0022] As used in this application, a logical network refers to a specific logical abstraction of a network. In some embodiments, the logical abstraction includes logical counterparts of network elements of a physical network, such as forwarding elements (e.g., switches, hubs, routers, bridges, etc.), load balancers, and firewalls. In some embodiments, a logical forwarding element (e.g., a logical switch or a logical router) is implemented by a set of MFEs (e.g., physical or virtual / software switches or routers) executed on a host machine. A particular host machine can host a data computing node (DCN) (e.g., a container or a virtual machine (VM)) connected to multiple different logical networks, and the set of MFEs implements all logical networks to which the DCN is logically connected. Specifically, further details about logical networks and about logical networks implemented as overlay logical networks in a public cloud environment can be found in U.S. Patent No. 9,787,605 and U.S. Patent Publication No. 2018 / 0062923, respectively, which are incorporated herein by reference.

[0023] In some embodiments, the DCN is hosted by a cloud provider (e.g., Amazon Web Services (AWS) or Microsoft Azure (Azure)), which provides a VCN for at least one tenant (e.g., a virtual private cloud (VPC) for AWS or a virtual network (VNet) for Azure). Each VCN is a virtual network that is logically isolated from other physical networks and from other virtual networks (e.g., VCNs) provided by the cloud provider. In some embodiments, the cloud provider provides a group of tenants with multiple VCNs to the VCNs for multiple tenants. For each VCN, a private IP address range (e.g., an IPv4 and / or IPv6 address range) is specified for communication within the VCN. Communication between computing nodes within the VCN uses a public cloud provider infrastructure and is maintained within the VCN at the logical specification level of the VCN. If a peer relationship is established between the VCNs, data messages can be sent using the private IP addresses of destination computing nodes in different VCNs, and the data messages will not need to be processed by an Internet gateway provided by the cloud provider. Alternatively, in some embodiments, data messages are forwarded using the same method as that used for intra-VCN traffic.

[0024] In some embodiments, peering is achieved by the cloud provider by modifying the configuration of the underlying routing elements (e.g., by adding routing entries, modifying security rules, etc.) so that compute nodes in peered VCNs communicate as if they were in the same VCN. In some embodiments, when two VCNs are not peered, the underlying routing elements enforce this by preventing direct communication between compute nodes in two non-peer VCNs (e.g., using security rules to prevent the private IP addresses of one VCN from communicating with the private IP addresses of the other VCN). It should also be noted that in some embodiments, peering is not transitive, and compute nodes in two VCNs that are peered with a common VCN (but not peered with each other) cannot communicate using the private IP addresses of the non-peer VCNs.

[0025] In some other embodiments, inter-VCN traffic traverses specific interfaces of the cloud provider underlying layer (e.g., gateway forwarding elements). That is, in such embodiments, these specific interfaces in the source and / or destination VCNs enforce peer relationships through a set of routing tables and / or security rules. In such embodiments, the routing tables and security rules of each interface are modified to allow traffic arriving at a cloud provider gateway device destined for a peer VCN to be forwarded to the cloud provider gateway device of the peer VCN. In the case of non-peering, in such embodiments, the cloud provider gateway device will not forward traffic to the cloud provider gateway device of the non-peer VCN.

[0026] A range of unique public IP addresses may additionally be specified to allow communication with external networks such as the Internet through an Internet gateway provided by the cloud provider. In some embodiments, communication between compute nodes in non-peer VCNs uses an Internet gateway provided by the cloud provider and a public IP address associated with the public IP address of the non-peer VCN. In some embodiments, each VCN for a particular tenant has a different private IP address range specified. In some embodiments, the VCN spans multiple physical data centers and is further divided into availability zones, each availability zone spanning a separate set of physical data centers such that no data center supports more than one availability zone.

[0027] By extending the logical network to one or more common data centers, the logical topology can be extended across these data centers. Some embodiments restrict the VMs attached to a given logical switch to one physical data center, while other embodiments even allow a single logical switch to be extended across multiple data centers (e.g., a collection of data centers supporting availability zones).

[0028] Figure 1 The logical topology 100 of some embodiments is conceptually illustrated, because an administrator may input the topology into the management plane. In some embodiments, the logical topology input into the management plane is implemented in the VCN. As shown, the logical topology 100 includes a logical router 105 and four logical switches 110-125. Two virtual machines are attached to each logical switch, and the logical router 105 includes an uplink port to an external network. In this case, only one layer of logical routers is shown in the logical network, but some embodiments may also include multi-layer logical routers. In addition, the management plane of some embodiments may define several logical routing components (e.g., a distributed router and one or more centralized service routers) for the logical router 105. The creation of multi-layer logical routers and multiple routing components for logical routers is further described in detail in U.S. Patent No. 9,787,605, which is incorporated herein by reference. However, a brief overview of logical routing components and possible implementations is provided below.

[0029] In some embodiments, the logical router includes multiple logical routing components, including a distributed logical router, a transit logical switch, and a centralized (service) router. In some embodiments, the distributed logical router is implemented by a set of local MFEs (e.g., a local MFE executed in each VCN, or by each MFE that implements a logical switching element of a logical network). The distributed logical router performs routing of data messages and can determine the logical switch to which the data message should be forwarded. In some cases, the transit logical switch is a logical switching element that is used only by the logical routing element to connect the distributed logical routing component to the centralized (service) logical routing component of the logical routing element. In some embodiments, both the local and centralized MFEs implement a distributed logical router component and a transit logical switch component, while the centralized MFE implements a centralized (service) logical router. In some embodiments, the centralized logical router is used as a gateway to an external network for computing nodes in a tenant logical network.

[0030] In some embodiments, the logical switches 110-125 attached to the logical router 105 are each assigned a subnet, and therefore, a workload VM created to attach to a particular logical switch should be assigned an IP address in the appropriate subnet. In some embodiments, a logical topology is defined for both the overlay network and the VCN implementation so that the IP addresses (subnets and individual DCN IP addresses) assigned by the VCN can be used by and by the overlay logical switches and routers to allow applications to continue to operate using IP addresses from the cloud provider, thereby facilitating easy and seamless integration with other services provided by the cloud provider (such as storage or load balancing services). In some embodiments, this is achieved by using an API provided by the cloud provider (i.e., the provider of the VCN) to determine the addresses assigned by the cloud provider and also use them for the overlay network (e.g., assigning the IP address assigned to the VM by the cloud provider to the tunnel endpoint created for the MFE operating on the VM). However, in some embodiments, the IP address of the VM on the cloud provider is different from the IP address mapped to the logical port of the VM, because the IP address facing the cloud provider network is the IP address of the tunnel endpoint created for the MFE operating on the VM. For example, in some embodiments, the logical switch 110 is assigned subnet 192.168.1.0 / 24 in the overlay network while being assigned 10.1.0.0 / 24 by the cloud provider. Additionally, two VMs are shown attached to the logical switch 110.

[0031] Figure 2 An embodiment is illustrated in AWS using a centralized transit VPC 205 that provides access to an external network 260 for compute nodes (eg, VMs 230 ) executing in a compute VPC 210 . Figure 2The diagram illustrates an example of four VMs 230 attached to two of the four logical switches 110 and 120 as implemented within a single compute VPC 210 of a single public cloud provider, and a transit VPC 205 that implements a cloud gateway 201, a set of service compute nodes (SVMs 202A-M), and a cloud provider internet gateway 203. Figure 2 Also illustrated are external networks 260, an on-premises data center 270 (e.g., a data center run by the owner of VM 230), and a VPN tunnel 204 connecting transit VPC 205 to the on-premises data center. In this example, each logical switch is included within a single VPC (e.g., all VMs attached to logical switches 110 and 120 are instantiated in the same VPC), with multiple logical switches instantiated in VPC 210. VPC 210 is assigned subnet 10.1.0.0 / 16, which can be a public or private subnet depending on how the administrator configures the VPC on the public cloud. In this example, the MFEs all operate in hybrid mode, which allows the VM IP address (e.g., the MFE tunnel endpoint IP address) to be the same as the workload application IP address (i.e., the IP address associated with the logical switch port). The MFE operating in hybrid mode determines whether to forward data messages sent by the workload application through the logical network (overlaid on the cloud provider network) or directly through the cloud provider network.

[0032] As shown, each VM is assigned a different workload IP (e.g., 10.1.0.2, 10.1.0.3, etc.) in the IP subnet (10.1.0.0 / 24) assigned to the logical switch to which it is connected, which is the IP subnet assigned to the subnet of the VPC (e.g., 10.1.0.0 / 16) in which the logical switch is implemented. In some embodiments, these IP addresses are the same as the IP addresses assigned to the VM (or the Virtual Extensible LAN Tunnel Endpoint (VTEP) of the MFE operating on the VM) by the cloud provider. The forwarding operations performed by the MFE implementing the hybrid logical switch for such an embodiment are discussed in more detail below.

[0033] In other embodiments, a different workload IP is assigned to each VM in a subnet of a logical network that is different from the logical switch subnet assigned by the cloud provider (for example, a 192.168.1.0 / 24 subnet instead of a 10.1.1.0 / 24 subnet). When the workload application in these embodiments sends a message, the different workload IP address will be the source IP used in the header of the message. However, the MFE operating on these VMs has a VTEP with a different IP address (10.1.0.2, 10.1.0.3, 10.10.0.2, 10.10.0.3, etc.) on the VPC subnet. Messages leaving the VM will therefore be encapsulated using the VTEP IP address as the source IP address (after the MFE in the source VM performs logical processing) in order to be sent to other destinations in the VPC.

[0034] The figure also illustrates tunnels between the four MFEs and the cloud gateway 201 in the transit VPC 205. In some embodiments, the tunnels use a peer relationship between the computing VPC 210 and the transit VPC 205 illustrated as network connection 250. The cloud gateway 201 provides connectivity to the external network 260 and the internally deployed data center 270 for the overlay logical network. As shown, the cloud gateway 201 is connected to the external network 260 through the Internet gateway 203. In some embodiments, the Internet gateway 203 is provided by the cloud provider as part of the deployment of the transit VPC 205. The tunnel connecting the MFE to the cloud gateway 201 passes through the underlying network of the public cloud provider (referred to as "underlying" in this article). In addition, although not shown here for simplicity, a tunnel is created between each pair of MFEs operating on the VM 230 (through the underlying network). In some embodiments, data messages pass through additional managed forwarding elements in one of the computing VPC and the transit VPC or in both the computing and transit VPCs between the illustrated MFEs and the cloud gateway. In some embodiments, the intermediate MFE implements additional intermediate logical forwarding elements.

[0035] The cloud gateway 201 can also send messages to (or receive messages from) destinations within the on-premises private data center 270. To send these messages, the cloud gateway 201 encapsulates the messages using its VTEP IP so that the destination will recognize the incoming messages as logical network messages. To protect traffic between the cloud gateway 201 in the VPC 205 and destinations in the private data center (e.g., VMs attached to logical switches), in some embodiments, messages are sent via the VPN tunnel 204. In this example, the components of the cloud gateway device 201 are not shown, but these components are discussed in more detail in U.S. Patent Publication No. 2018 / 0062923, which is incorporated herein by reference.

[0036] In some embodiments, cloud gateway 201 is a gateway computing node (e.g., a virtual machine) that provides access to an external network to computing nodes inside a logical network (e.g., forwarding north-south traffic). In some embodiments, cloud gateway 201 also provides services to north-south traffic received at cloud gateway 201. In some embodiments, the services provided at cloud gateway 201 include any one or more of firewall services, load balancing services, network address translation services, intrusion detection, VPN, audit logging, and service chaining (sending data messages to third-party service devices (e.g., SVM 202) for various middlebox processing). In some embodiments, the services provided to traffic received at cloud gateway 201 are provided by forwarding traffic to a service computing node such as one of SVMs 202A-M that is executed in transit VPC 205. In some embodiments, SVMs 202A-M provide a set of logical network services and a set of third-party services. In some embodiments, having a centralized cloud gateway allows third-party devices for north-south logical network traffic to also be centralized to the transit VPC to further reduce costs and management overhead.

[0037] Figure 3 An embodiment using a centralized transit VPC 305 is illustrated that provides transit routing (i.e., routing from a first VPC to a second VPC through a third transit VPC) and access to an external network 260 for a compute node (e.g., VM 230) executing in any of the compute VPCs 310A-N. Figure 3 The diagram illustrates an example of eight VMs 330 attached to four logical switches 110-125 as implemented within multiple compute VPCs 310A-N of a single public cloud provider (specifically shown as implemented in VPCs 310A and 310N), and a VPC 305 that implements a cloud gateway 301 and a set of service compute nodes (SVMs 302A-M), a cloud provider internet gateway 303. Figure 3Also illustrated are external networks 360, an on-premises data center 370 (e.g., a data center run by the owner of VM 330), and a VPN tunnel 304 connecting transit VPC 305 to on-premises data center 370. In this example, each logical switch spans a single VPC (e.g., all VMs attached to logical switches 110-125 are instantiated in the same VPC), where VMs attached to multiple logical switches are instantiated in each VPC. In some embodiments that do not use cloud provider assigned addresses, logical switches span multiple VPCs, as described in U.S. Patent Publication No. 2018 / 0062923. VPC 310A is assigned subnet 10.1.0.0 / 16, while VPC 310B is assigned subnet 10.10.0.0 / 16, either of which can be a public subnet or a private subnet depending on how the administrator has configured the VPCs on the public cloud. In this example (and other examples in this section), the MFEs all operate in hybrid mode, which allows the VM IP address (e.g., the MFE tunnel endpoint IP address) to be the same as the workload application IP address (i.e., the IP address associated with the logical switch port). The MFE operating in hybrid mode determines whether to forward data messages sent by the workload application through the logical network (overlaid on the cloud provider network) or directly through the cloud provider network.

[0038] As shown, each VM is assigned a different workload IP (e.g., 10.1.0.2, 10.10.0.3, etc.) in the IP subnet assigned to the logical switch to which it is connected (e.g., 10.1.0.0 / 24, 10.10.0.0 / 24, etc.). The IP subnet of the logical switch is the IP subnet assigned to the subnet of the VPC in which the logical switch is implemented (e.g., 10.1.0.0 / 16 or 10.10.0.0 / 16). In some embodiments, these IP addresses are the same as the IP addresses assigned to the VM (or the VTEP of the MFE operating on the VM) by the cloud provider. The forwarding operations performed by the MFE implementing the hybrid logical switch for such an embodiment are discussed in more detail below.

[0039] In other embodiments, a different workload IP is assigned to each VM in a subnet of a logical network that is different from the logical switch subnet assigned by the cloud provider (for example, a 192.168.1.0 / 24 subnet instead of a 10.1.1.0 / 24 subnet). When the workload application in these embodiments sends a message, the different workload IP address will be the source IP used in the header of the message. However, the MFE operating on these VMs has a VTEP with a different IP address (10.1.0.2, 10.1.0.3, 10.10.0.2, 10.10.0.3, etc.) on the VPC subnet. Messages leaving the VM will therefore be encapsulated using the VTEP IP address as the source IP address (after the MFE in the source VM performs logical processing) in order to be sent to other destinations in the VPC.

[0040] The figure also illustrates tunnels between these eight MFEs and the cloud gateway 301 in the transit VPC 305. In some embodiments, the tunnels use a peer relationship between the computing VPCs 310A-N and the transit VPC 305 illustrated as network connection 350. These tunnels pass through the underlying network of the public cloud provider (referred to herein as the "underlying layer"). In addition, although not shown here for simplicity, tunnels are created between each pair of MFEs operating on VM 330 (through the underlying network). For example, if there is no peering between the source VPC and the destination VPC or the traffic requires a centralized service provided by or through the cloud gateway 301, then these tunnels between the MFE 340 and the cloud gateway 301 are used to forward traffic between compute nodes (e.g., VMs, containers, etc.) implemented by different VPCs.

[0041] The cloud gateway 301 can also send packets to (and receive packets from) destinations within the on-premises private data center 370. To send these packets, the cloud gateway 301 encapsulates the packets using its VTEP IP so that the destination will recognize the incoming packets as logical network packets. To protect traffic between the cloud gateway 301 in the VPC 305 and destinations in the private data center (e.g., VMs attached to logical switches), in some embodiments, packets are sent via a VPN tunnel 304. In this example, the connection of the gateway to the external network is not shown, and this connection is discussed in more detail in U.S. Patent Publication No. 2018 / 0062923, which is incorporated herein by reference.

[0042] In some embodiments, cloud gateway 301 is a gateway computing node (e.g., a virtual machine) that provides access to external networks to computing nodes inside a logical network (e.g., forwarding north-south traffic). In some embodiments, cloud gateway 301 also provides services to traffic (north-south and east-west) received at cloud gateway 301. In some embodiments, the services provided at cloud gateway 301 include any one or more of logical routing, firewall services, load balancing services, network address translation services, intrusion detection, VPN, audit logging, service chaining (sending data messages to third-party service devices (e.g., SVM 302) for various middlebox processing). In some embodiments, the services provided to traffic received at cloud gateway 301 are provided by forwarding traffic to a service computing node such as one of SVMs 302A-M executed in transit VPC 305. In some embodiments, SVMs 302A-M provide a set of logical network services and a set of third-party services. In some embodiments, having a centralized cloud gateway allows third-party devices for north-south and east-west logical network traffic to also be centralized to the transit VPC to further reduce costs and management overhead.

[0043] Although the embodiments described above, as well as the entire remainder of the specification, are discussed in terms of a single transit VPC and cloud gateway, other embodiments implement the cloud gateway as a cluster of two or more cloud gateway devices in active-active or active-standby mode in a single transit VPC. Still other embodiments implement a cluster of two or more transit VPCs, each of which hosts a cloud gateway device configured in one of an active-active or active-standby configuration. The cloud gateways (or transit VPCs) in active-active mode are each addressable by a compute node in a logical network, and in some embodiments are load balanced, or addressed by the same multicast address. In such an embodiment, as described below with respect to Figure 5 The MFE is configured as described to route data messages to a specific gateway device / transit VPC or any active gateway device / transit VPC. In some embodiments, stateful processing is maintained by assigning a specific flow to a specific cloud gateway device / transit VPC based on sharding (e.g., based on source IP address or destination IP address) or hashing (e.g., based on a hash of an n-tuple defining the flow). In an active / standby configuration, a single cloud gateway device / transit VPC acts as a cloud gateway / transit VPC, with additional devices or VPCs in the cluster providing redundancy in the event of an active device / transit VPC failure.

[0044] Figure 4 The diagram shows Figure 3300 but with an additional peering relationship indicated by connection 450 existing between VPCs 310A and 310N. In system 400, in addition to being able to forward data messages between VPCs 310A and 310N via transit VPC 305 (and cloud gateway 301), the peering relationship can also be used to forward data messages. Figure 5 The process of leveraging existing peering and intra-VPC connections and a centralized cloud gateway device is conceptually illustrated.

[0045] Figure 5 Conceptually illustrates the processing of intelligently forwarding data messages received from a computing node using one of an overlay network or a cloud provider network performed by a managed forwarding element (MFE). The processing begins (at 510) by receiving a data message from a computing node (e.g., a virtual machine or container) that is destined for another computing node. Different data messages will be sent to different computing nodes in different virtual private clouds and require different services. In some embodiments, the cloud provider provides some services, while other services are provided by elements of the overlay network. In some embodiments, the services provided by the cloud provider are of the same type as the services provided by the elements of the overlay network (e.g., firewalls, load balancing, WAN optimization, etc.).

[0046] Upon receiving the data message, the MFE performs (at 520) ingress processing. In some embodiments, the ingress processing includes distributed firewall operations. After ingress processing, in some embodiments, the MFE consults an arbitrator to determine (at 530) whether the data message needs to be processed by a cloud gateway executing in a transit VPC. In some embodiments, the arbitrator is part of the MFE. In some embodiments, the determination is based on whether the destination of the data message is in the same VPC as the source of the data message, whether the data message requires any centralized services, and whether there is peering between the source VPC and the destination VPC.

[0047] In some embodiments, the determination that the destination computing node is in the same VPC as the source computing node is based on whether the destination IP address of the data message falls within the IP address range of the VPC assigned to the source computing node. In some embodiments, the determination of whether the data message requires centralized service is based on a policy-based routing policy or other form of policy received from a network controller. In some embodiments, the policy is specified based on a tuple associated with the data message (e.g., a five-tuple specifying the source IP address and destination IP address, the source port and destination port, and the protocol). In some embodiments, the routing table is processed to remove routes to addresses that are unavailable from the VPC or require routing through a cloud gateway in a transit VPC (e.g., regarding Figure 8In some embodiments, the determination of whether a peer exists between the source VPC and the destination VPC is based on whether a route for the destination IP address in the destination VPC exists in the routing table of the source VPC (or an MFE implementing a logical router of the overlay network). In some embodiments, information about whether a peer exists between the source VPC and the destination VPC is provided by a user (e.g., a system administrator) and is pushed to the MFE executing at a different VPC.

[0048] In some embodiments of implicitly determining whether a data message needs to be forwarded to a cloud gateway in a transit VPC (either because it requires a service or because there is no peering with the destination VPC), the MFE (or a separate managed switching and routing element as discussed below) or an arbitrator module performs logical switching and routing operations associated with the logical switching and routing elements of the overlay network (e.g., the tenant logical network). In some embodiments, the logical switching operations include: identifying an egress logical port of the logical switching element that received the data message from the source computing node, and logically forwarding the data message to the egress logical port connected to the logical routing element. In some embodiments, the logical routing operations include implementing a distributed logical router to identify a logical port of the logical routing element associated with the destination address of the data message. As discussed above, in some embodiments, the distributed logical router is configured such that (1) data messages that require services provided at the overlay cloud gateway or (2) that are sent to a VPC that does not have a peering relationship with the source VPC are routed to the cloud gateway. In some embodiments, this is equivalent to determining that the data message should be forwarded to a distributed logical routing element of a centralized service routing element implemented by the overlay cloud gateway.

[0049] In some embodiments, if the data message (1) requires centralized services provided by a cloud gateway (regardless of whether the source VPC and the destination VPC are the same or different) or (2) is sent to a VPC that is not peered with the source VPC, then the data message needs to be processed by an overlay cloud gateway (e.g., a device that implements a logical router to provide access to external networks for computing nodes in the overlay network). Conversely, if (1) the data message is sent to a computing node in the same VPC and does not require centralized services provided by a cloud gateway or (2) the data message is sent to a computing node on a VPC that is peered with the VPC of the source computing node and the data message does not require centralized services, then the data message does not need to be processed by the overlay cloud gateway.

[0050] If the process determines (at 530) that the data message requires processing by the cloud gateway, then the process encapsulates (at 530) the data message with a header that directs the message to a tunnel endpoint of the cloud gateway. In some embodiments, the tunnel endpoint is a virtual extensible local area network (VXLAN) tunnel endpoint (VTEP). In some embodiments, the encapsulation is a generic network virtualization encapsulation (GENEVE) header.

[0051] If the process determines (at 530) that the data message does not require processing by the cloud gateway or determines (at 530) that the data message requires processing by the cloud gateway and has already encapsulated (at 540) the data message, then the process forwards the data message to the destination. In some embodiments, the data message is forwarded to a forwarding element of the cloud provider and the process ends. In some embodiments, the cloud provider forwarding element provides further encapsulation to traverse the physical network on which the virtual private cloud is implemented.

[0052] In some embodiments, a data message encapsulated to be forwarded to a cloud gateway is received at the cloud gateway, which then decapsulates the data message, provides any required services, and forwards the data message to the destination computing node. In some embodiments, the forwarded data message does not require encapsulation to be forwarded from the cloud gateway to the destination computing node due to the transit VPC on which the cloud gateway is peered with each VPC hosting the computing nodes of the overlay network.

[0053] Figure 6 A set of possible data message paths and headers for intra-VPC traffic in some embodiments is illustrated. Figure 6 Depicted is system 600, which is a simplified view of system 300, including a physical cloud host machine 680 including a public cloud forwarding element (PCFE) 690 on which VM1 executes, and the figure does not show the tunnel relationship between MFE 340 and cloud gateway 301. Similar public cloud host machines 680 on which other VMs execute are not shown. Figure 6 Data messages directed from applications executing on VM1 to VM6 are illustrated.As depicted, VM1 belongs to the 10.1.0.0 / 24 subnet of a first logical switch and the VMs belong to the 10.1.1.0 / 24 subnet of a second logical switch, both of which are implemented in VPC 310A assigned IP subnet 10.1.0.0 / 16.

[0054] For intra-VPC traffic, a first and second path from VM1 to VM6 is depicted. Each path begins with a data message (labeled “1”) sent from the workload application using equivalent source and destination IP addresses in the overlay network and the cloud provider network. In some embodiments using different overlay network IP addresses, the overlay network address will appear in the header of the data message from the workload application. In embodiments using containers, the container sends a data message “1” to the MFE (e.g., OVS) using the IP address assigned by the overlay network. As described with respect to Figure 5 As described, MFE 340 determines whether the data message needs to be forwarded to cloud gateway 301 (e.g., based on PBR, or lack of routing entries for the destination switch subnet as described above). If MFE 340 determines that the data message should be forwarded directly to the destination (i.e., VM6), then the MFE forwards the data message to the PCFE provided by the cloud provider and implements the provider logical network on the underlying network infrastructure. The MFE forwards the data message as data message "2" without encapsulation, and the PCFE encapsulates the data message as data message "3" to traverse the underlying network to reach the public cloud host machine (not shown) hosting the destination computing node (i.e., VM6).

[0055] For intra-VPC traffic that the MFE determines needs to be forwarded to cloud gateway 301 based on demand for a particular service provided by cloud gateway 301, the MFE encapsulates the data message (as data message "4") with the IP address of the cloud gateway (e.g., 10.12.0.1), which is accessible based on peering 350 between compute VPC 310A and transit VPC 305. In this case, the address of cloud gateway 301 is both an overlay address and a cloud provider address, but in their different embodiments, the MFE uses the VTEP address of the MFE to which cloud gateway 301 is attached in the encapsulation. Data message "4" is received by PCFE 690 and, similar to data message "3", is encapsulated as data message "5" to traverse the underlying network to reach cloud gateway 301. The structure of data messages "1" to "5" is shown in FIG. Figure 6 on the right side.

[0056] Once the cloud gateway 301 receives the data message "5", it provides services (e.g., firewall, NAT, load balancing, etc.) to / for the data message. In some embodiments, providing services includes forwarding the data message as data message "6" to a service computing node (i.e., SVM302A) that is one of a logical network service device or a third-party service device in some embodiments. In some embodiments, forwarding the data message to the service device uses overlay encapsulation, while in other embodiments, the service device is addressed using a cloud provider logical network address. After performing / providing the service, the service device returns the data message "7" to the cloud gateway 301 to be forwarded to the destination as a data message "8". In some embodiments, based on the peer relationship between the transit VPC 305 and the computing VPC 310A, the data message "8" is sent without overlay encapsulation, which allows direct addressing of computing nodes in other VPCs. Regardless of whether the data message is sent encapsulated or unencapsulated by the cloud gateway 301, the PCFE executed on the host machine on which the cloud gateway operates encapsulates the data message as data messages "3" and "5". In some embodiments, data messages "6" and "7" are not sent because the service is provided by the cloud gateway itself.

[0057] Figure 7 A set of inter-VPC data message flows in system 700 are illustrated. System 700 depicts three computing VPCs 710A, B, and N having respective IP subnets (e.g., CIDR blocks) 10.1.0.0 / 16, 10.8.0.0 / 16, and 10.10.0.0 / 16, and including VM 1, VM 4, and VM 8 having respective IP addresses 10.1.0.2, 10.8.0.3, and 10.10.1.3 (VM 1, 4, and 8 are logically as Figure 1 In some embodiments, each of VM 1, VM 4, and VM 8 operates in a public cloud host machine, which includes Figure 6 The PCFE shown in FIG. 5 is not shown for the sake of clarity. Figure 7 Three basic inter-VPC traffic patterns are depicted in Figure 1: (1) inter-VPC traffic through a transit VPC that provides services; (2) inter-VPC traffic using peering between compute VPCs; and (3) inter-VPC traffic using a transit VPC when there is no peering between the source and destination compute VPCs.

[0058] Figure 7Data message “1” depicts the first data message that has been determined to require a service provided by or through cloud gateway 701. Data message “1” is sent from an application or container on VM1 addressed to an IP address in another VPC. After determining that the data message needs to be forwarded to cloud gateway 701 (e.g., because there is no peering between the source VPC and the destination VPC (for data message “3”), or because a service is required (data message “2n” or “3”)), the MFE encapsulates the data message into a VTEP IP address associated with cloud gateway 701. Figure 6 The data message "4" is encapsulated in the data message "4" and forwarded to the PCFE, which further encapsulates the data message in Figure 6 The data message "5" is included in the data message "2a" and forwarded to the cloud gateway 701. The data messages "2a" to "2m" represent a set of data messages for implementing a service chain of multiple services provided by the cloud gateway 701. In some embodiments, the service chain is a supplement to the services provided by the cloud gateway. In some embodiments, the services provided by the service device 702 are not required, and the traffic is directly from the data message "1" to the data message "2n" or "3". As discussed above, an overlay encapsulation or a cloud provider network can be used to send data messages such as data message "2n" sent from the cloud gateway 701 to the VM in the computing VPC.

[0059] Data message "4" is a data message sent from a VM in the first compute VPC 710A to a second compute VPC 710B where a peer exists. MFE 740 receives the data message from an application or container on VM1 and determines that the data message does not need to be routed through transit VPC 705 and that a peer relationship exists between the current compute VPC and the destination compute VPC. Based on this determination, the cloud provider address (e.g., for Figure 6 The data message "2" of the packet sends the data message "4" to the PCFE (not shown) so that the PCFE encapsulates it using the underlying network IP address and header.

[0060] Figure 8 Conceptually illustrates the configuration of an MFE in some embodiments to implement Figure 5Processing 800 of processing. Processing 800 receives (at 810) configuration data. In some embodiments, the configuration data includes a list of directly available endpoint addresses. In some embodiments, the directly available addresses are specified for a particular VPC. In other embodiments, the list specifies addresses that are directly available for multiple VPCs at the same time. For a list of directly available addresses for multiple VPCs, the list can be arranged as a list of addresses and VPCs that are directly available to them. In some embodiments, the directly available addresses for a particular VPC include addresses available on a VPC that is peered to the particular VPC, and addresses available through a cloud provider virtual private network (VPN). In some embodiments, the configuration data includes (1) identification of the peer VPCs and (2) VPNs that exist between the VPCs. In some embodiments, the configuration data is received by a network controller from a user (e.g., a system administrator). In some embodiments, identification of peer VPCs and existing VPNs is automatically retrieved using an application programming interface (API) provided by the cloud provider. In some embodiments, the configuration data specifies preferred communication methods between particular computing nodes or computing node types (e.g., web server to application server, application server to database server, etc.) or priority of communication methods for computing nodes connected in multiple ways (e.g., preferably using VPC peering of a provider network for VPN traffic).

[0061] Once the configuration data has been received (at 810), the process pushes (at 820) the configuration data to the compute nodes in the overlay network. In some embodiments, the configuration data pushed to the compute nodes is configuration data received by the controller. In some embodiments, the controller converts the received configuration data into data specific to the compute node or VPC that reflects the portion of the configuration data that is relevant to the compute node or the VPC in which the compute node is executed (e.g., the VPC is peered with 2 other VPCs). In some embodiments, the controller transmits the configuration information to the local agent of the compute node to be configured. In some embodiments, the configuration data is in addition to other configuration data sets used to construct / populate routing tables of different MFEs.

[0062] Once the configuration information is pushed (at 820) to the compute node, the compute node receives (at 830) the configuration data. In some embodiments, the compute node operates an MFE that overlays the network. In some embodiments, the MFE is executed in a virtual machine together with a set of applications or containers for which the MFE provides forwarding services. In some embodiments, the MFE is an open vSwitch (OVS) and the configuration data is received as a set of forwarding entries for the open vSwitch (OYS). In some embodiments in which the MFE includes a routing table, the configuration includes a set of routing entries that reflect the existence of a peer relationship between VPCs, the existence of a VPN, or a specific flow that should be directed to a cloud gateway in a transit VPC.

[0063] In some embodiments, instead of a single MFE, there is a set of managed switching and routing elements that process data messages to and from the source of the data messages. The configuration data in such embodiments includes configuration data for each managed switching and routing element separately to implement the desired logical switching and routing elements of the overlay network (e.g., tenant logical network), respectively. In some embodiments, the compute nodes execute only the managed switching elements, where the managed routing elements execute on separate compute nodes.

[0064] Some embodiments place routing entries in a routing table of a Tier-1 or Tier-0 distributed router implemented by an MFE or a managed routing element. Logical networks implementing Tier-1 and Tier-0 logical routers are described in U.S. Patent No. 9,787,605, which is incorporated herein by reference. In embodiments where the configuration data is not converted by a controller receiving it, the compute node converts the configuration data into forwarding data (e.g., entries in a routing table, flow entries for OVS). Some embodiments receive the configuration data as (1) policy-based routing data that defines policies based on data message or flow characteristics (e.g., a quintuple or other header value), and (2) private routing table data that is used to (i) instruct the MFE to use private routing table data when characteristics of the data message match, and (ii) generate and populate private routing tables, respectively.

[0065] After receiving (at 830) the configuration data, the process configures (at 840) the MFE to implement a forwarding decision based on the received configuration data. In some embodiments, configuring the MFE includes updating a routing table of the MFE (or a managed routing element) with routes based on the configuration data. The routing table entries of the updated routing table may include routing entries for forwarding traffic by: (1) forwarding the traffic to the destination compute node using a cloud provider network (e.g., sending the traffic without encapsulation through the MFE), (2) encapsulating by the MFE to use a direct tunnel between the source compute node and the destination compute node (e.g., between the source compute node and the MFE to which the destination compute node is connected), or (3) encapsulating to use a tunnel to a cloud gateway (e.g., a cloud gateway in a transit VPC) so that the cloud gateway forwards to the destination compute node. In some embodiments, configuring the MFE includes updating flow entries of the OVS to forward the traffic in any of the ways outlined above for the routing entries. The MFE is now configured and the process ends.

[0066] Many of the above features and applications are implemented as software processing designated as a set of instructions recorded on a computer-readable storage medium (also referred to as a computer-readable medium). When these instructions are executed by one or more processing units (e.g., one or more processors, cores of a processor, or other processing units), they cause the (one or more) processing units to perform the actions indicated in the instructions. Examples of computer-readable media include, but are not limited to, CD-ROMs, flash drives, RAM chips, hard drives, EPROMs, etc. Computer-readable media do not include carrier waves and electronic signals transmitted wirelessly or via wired connections.

[0067] In this specification, the term "software" is intended to include firmware residing in a read-only memory or an application stored in a magnetic storage device, which can be read into a memory for processing by a processor. Similarly, in some embodiments, multiple software inventions can be implemented as sub-parts of a larger program while retaining different software inventions. In some embodiments, multiple software inventions can also be implemented as separate programs. Finally, any combination of separate programs that implement the software inventions described herein together are within the scope of the present invention. In some embodiments, the software program, when installed to operate on one or more electronic systems, defines one or more specific machine implementations for executing the operations of the software program.

[0068] Fig. 9A computer system 900 is conceptually illustrated with which some embodiments of the present invention are implemented. The computer system 900 can be used to implement any of the above-mentioned hosts, controllers, and managers. Thus, it can be used to perform any of the above-mentioned processes. The computer system includes various types of non-transitory machine-readable media and interfaces for various other types of machine-readable media. The computer system 900 includes a bus 9105, (one or more) processing units 910, a system memory 925, a read-only memory 930, a permanent storage device 935, an input device 940, and an output device 945.

[0069] Bus 905 collectively represents all system buses, peripheral buses, and chipset buses that communicatively connect the many internal devices of computer system 900. For example, bus 905 communicatively connects processing unit(s) 910 with read-only memory 930, system memory 925, and permanent storage device 935.

[0070] The processing unit(s) 910 retrieves instructions to be executed and data to be processed from these various memory units in order to perform the processing of the present invention. In different embodiments, the processing unit(s) may be a single processor or a multi-core processor. The read-only memory (ROM) 930 stores static data and instructions required by the processing unit(s) 910 and other modules of the computer system. On the other hand, the permanent storage device 935 is a read-write memory device. The device is a non-volatile memory unit that stores instructions and data even when the computer system 900 is turned off. Some embodiments of the present invention use a mass storage device (such as a magnetic disk or optical disk and its corresponding disk drive) as the permanent storage device 935.

[0071] Other embodiments use removable storage devices (such as floppy disks, flash drives, etc.) as permanent storage devices. Like permanent storage device 935, system memory 925 is a read-write memory device. However, unlike storage device 935, system memory is a volatile read-write memory, such as random access memory. System memory stores some instructions and data required by the processor at run time. In some embodiments, the processing of the present invention is stored in system memory 925, permanent storage device 935, and / or read-only memory 930. (One or more) processing unit 910 retrieves instructions to be executed and data to be processed from these various memory units in order to perform the processing of some embodiments.

[0072] The bus 905 is also connected to input and output devices 940 and 945. Input devices enable a user to communicate information to the computer system and select commands. Input devices 940 include an alphanumeric keyboard and a pointing device (also called a "cursor control device"). Output devices 945 display images generated by the computer system. Output devices include printers and display devices, such as cathode ray tubes (CRTs) or liquid crystal displays (LCDs). Some embodiments include devices such as touch screens that function as both input devices and output devices.

[0073] Finally, if Fig. 9 As shown, bus 905 also couples computer system 900 to a network 965 via a network adapter (not shown). In this manner, the computer may be part of a network of computers, such as a local area network ("LAN"), a wide area network ("WAN"), or an intranet, or a network of networks, such as the Internet. Any or all of the components of computer system 900 may be used in conjunction with the present invention.

[0074] Some embodiments include electronic components such as a microprocessor, a storage device and memory that stores computer program instructions in a machine-readable or computer-readable medium (alternatively referred to as a computer-readable storage medium, a machine-readable medium, or a machine-readable storage medium). Some examples of such computer-readable media include RAM, ROM, a compact disc read only (CD-ROM), a compact disc recordable (CD-R), a compact disc rewritable (CD-RW), a read-only digital versatile disc (e.g., DVD-ROM, dual-layer DVD-ROM), various recordable / rewritable DVDs (e.g., DVD-RAM, DVD-RW, DVD+RW, etc.), flash memory (e.g., SD card, mini SD card, micro SD card, etc.), magnetic and / or solid-state hard drives, read-only and recordable A computer readable medium may store a computer program that is executable by at least one processing unit and includes a set of instructions for performing various operations. Examples of computer programs or computer code include machine code such as produced by a compiler, and files including higher level code that is executed by a computer, electronic component, or microprocessor using an interpreter.

[0075] Although the above discussion mainly refers to microprocessors or multi-core processors that execute software, some embodiments are performed by one or more integrated circuits such as application specific integrated circuits (ASICs) or field programmable gate arrays (FPGAs). In some embodiments, such integrated circuits execute instructions stored on the circuit itself.

[0076] As used in this specification, the terms "computer", "server", "processor" and "memory" all refer to electronic or other technical devices. These terms do not include people or groups of people. For the purposes of this specification, the terms display or being displayed means displayed on an electronic device. As used in this specification, the terms "computer-readable medium", "computer-readable medium" and "machine-readable medium" are entirely limited to tangible physical objects that store information in a computer-readable form. These terms do not include any wireless signals, wired download signals, and any other short-lived or transient signals.

[0077] Although the present invention has been described with reference to many specific details, it will be appreciated by those skilled in the art that the present invention may be implemented in other specific forms without departing from the spirit of the present invention. For example, several figures conceptually illustrate processing. The specific operations of these processing may not be performed in the exact order shown and described. The specific operations may not be performed in a continuous series of operations, and different specific operations may be performed in different embodiments. In addition, the processing may be implemented using several sub-processes, or as part of a larger macro-process. Therefore, it will be appreciated by those skilled in the art that the present invention is not limited by the foregoing illustrative details, but is defined by the appended claims.

Claims

1. A method of processing a data message at a first virtual private cloud (VPC) defined in a public cloud, the method comprising: At the transit gateway device executed in the transit, first VPC: In response to a managed forwarding element MFE in a second VPC defined in the public cloud for the first tenant determining that the data message needs to be forwarded to the transit gateway device based on a need to perform a service operation on the data message, receiving the data message from the MFE; performing the service operation on the data message by: (i) forwarding the data message to a set of one or more service devices in the public cloud to perform a set of one or more network services, and (ii) receiving the data message from the set of service devices after the set of network services have been performed; as well as The data message on which the service operation has been performed is forwarded to a destination machine outside of the first and second VPCs. 2 . The method of claim 1 , wherein the destination machine is located in a third VPC defined in the public cloud. 3 . The method of claim 2 , wherein the first, second, and third VPCs have first, second, and third virtual networks that are isolated from each other. The method of claim 1 , wherein the set of service devices includes at least one third-party service device. 5 . The method of claim 1 , wherein the set of network services includes at least one of a network address translation, a firewall service, a load balancing service, and an intrusion detection service.

6. The method of claim 1 , wherein receiving the data message comprises: An encapsulated data message is received having an encapsulation header identifying a tunnel endpoint associated with the gateway device.

7. The method of claim 1, wherein the gateway device of the first VPC is configured to forward data messages between a group of two or more VPCs, the two or more VPCs being defined in the public cloud and not configured to communicate directly with each other.

8. The method of claim 7, wherein when two VPCs are not peered, one or more security rules prevent a private network address of one VPC from communicating with a private network address of another VPC.

9. A method for processing data messages for a machine deployed in a set of one or more data centers, the method comprising: At a managed forwarding element (MFE) executing on a host computer having a first machine, the first machine being located in a first virtual private cloud (VPC) defined in a set of one or more public cloud data centers of a set of VPCs defined for a tenant in a set of public cloud data centers, the MFE together with other MFEs implementing at least one logical forwarding element (LFE) of a logical network for the tenant, receiving a data message from the first machine of the tenant operating in the first VPC in the set of VPCs, the destination of the data message being an external network outside the first VPC or any VPC of the tenant; performing ingress processing on the data message; forwarding the data message to a transit gateway operating in a second VPC, wherein the transit gateway forwards the data message to the external network, The first VPC does not include a gateway connecting the first VPC to an external network outside the second VPC or any VPC of the tenant, and forwarding the data message includes forwarding the data message through a tunnel defined between the MFE and the transit gateway.

10. The method of claim 9, wherein the at least one LFE comprises a logical routing element (LRE).

11. The method of claim 9, wherein the at least one LFE comprises a logical switching element (LSE) that is logically connected to the first machine. 12 . The method of claim 9 , wherein the MFE is an open vswitch executed on a computer in the public cloud for implementing the first VPC.

13. The method of claim 9, wherein the MFE is configured to route all logical network traffic destined for external networks outside the first VPC or any VPC of the tenant to a set of one or more transit gateways in a set of one or more transit VPCs of the tenant.

14. A machine-readable medium storing a program, which, when executed by at least one processing unit, implements the method according to any one of claims 1 to 13.

15. A computing device comprising: a set of processing units; as well as A machine-readable medium storing a program which, when executed by at least one of the processing units, implements the method according to any one of claims 1 to 13.

16. A system comprising components for implementing the method according to any one of claims 1-13.

17. A computer program product comprising instructions which, when executed by a computer, perform the method according to any one of claims 1 to 13.

Images