End-to-end network encryption from a customer on-premises network to a customer virtual cloud network using customer managed keys

Abstract

Systems and methods for encrypting data between a customer and a virtual cloud network (VCN) for end-to-end encryption, where the customer manages the encryption keys.SOLUTION: The network head end device, VCN Head End 704, accepts the first key provisioned by the customer, receives the first data packet sent from the customer's device, and decrypts the first data packet using the first key to obtain the information. The network virtualization device 624 receives the information from the network head-end device, confirms that the information is to be sent to the virtual machine in the virtual cloud network, confirms that data in the virtual cloud network is to be encrypted, encrypts the information using the second key to generate a second data packet, and routes the second data packet to the virtual machine in the virtual cloud network 312.SELECTED DRAWING: Figure 7

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application was filed on December 23, 2020, and is related to "END-TO-END NETWORK ENCRYPTION FROM CUSTOMER ON-PREMISE NETWORK TO CUSTOMER VIRTUAL CLOUD NETWORK USING CUSTOMER-MANAGED KEYS" This application claims the benefit of U.S. Application No. 17 / 133,523, entitled "VIRTUAL CLOUD NETWORK USING CUSTOMER-MANAGED KEYS," the entire contents of which are incorporated herein by reference.

[0002] This application is related to U.S. Application No. 17 / 133,526, filed December 23, 2020, and entitled "MECHANISM TO PROVIDE CUSTOMER VCN NETWORK ENCRYPTION USING CUSTOMER-MANAGED KEYS IN NETWORK VIRTUALIZATION DEVICE." No. 6,229,693, the entire contents of which are incorporated herein by reference. [Background technology]

[0003] background A virtual cloud network (VCN) is a customizable private network. Similar to a traditional data center network, a VCN controls the network environment. This includes allocating private IP addresses, creating subnets, creating route tables, and configuring firewalls. A tenant can have multiple VCNs, allowing for grouping and isolation of related resources. Summary of the Invention [Problem to be solved by the invention]

[0004] Data within a VCN can be encrypted for security. One goal of encryption is to transform plaintext data into unintelligible ciphertext based on a key, such that it is extremely difficult (e.g., computationally infeasible) to revert the ciphertext to the corresponding plaintext without knowledge of the correct key. In a symmetric cryptosystem, the same key is used to both encrypt and decrypt the same data. In some encryption algorithms, the key length can be 128 bits, 192 bits, or 256 bits. In some encryption standard algorithms, such as the Data Encryption Standard (DES), message data is encrypted by passing it through the DES algorithm three times. 3DES can provide a high degree of message security, but comes with a performance penalty. The degree of the performance penalty can vary depending on the speed of the processor performing the encryption. Developed by RSA Data Security, Inc. The RC4 algorithm, developed by RSA, has become the international standard for high-speed data encryption. RC4 is a variable key length stream cipher that operates several times faster than DES, allowing it to encrypt large data transfers with minimal impact on performance. Network data encryption ensures data privacy, preventing unauthorized parties from viewing plaintext data as it travels over the network.

[0005] Quick Overview This disclosure relates generally to virtual cloud networks (VCNs). More specifically, but not by way of limitation, it describes techniques for encrypting data between a customer and a VCN for end-to-end encryption where the customer manages the encryption keys. Instead of terminating the VPN tunnel at the host's VPN gateway using a shared key, the VCN uses hardware-secured, customer-managed encryption keys to encrypt data from customer devices. The VPN tunnel terminates on the host device, which is a bare metal server with a network virtualization device. [Means for solving the problem]

[0006] In certain embodiments, a system includes a network head-end device and a network virtualization device. The network head-end device is configured to receive a first key provisioned by a customer, receive a first data packet transmitted from the customer's device, and / or use the first key to decrypt the first data packet to obtain information. The network virtualization device is configured to receive the information from the network head-end device after the first data packet is decrypted, verify that the information is to be transmitted to a virtual machine in a virtual cloud network, verify that data in the virtual cloud network is configured to be encrypted, encrypt the information using a second key to generate a second data packet, and / or route the second data packet to the virtual machine.

[0007] In certain embodiments, the system is maintained by a host, and the host does not have access to the first key or the second key; the network head-end device is configured to be a termination point of an Internet Protocol Security (IPSec) tunnel formed between the network head-end device and a customer device; the first data packet is routed through a public Internet, and the first data packet is routed through a set of private links without using a link in the public Internet; the network virtualization device supports instances of virtual machines in the virtual cloud network; the network head-end device is a network interface card, and the network head-end device is on a network interface card, and the network virtualization device is part of the network interface card; the network head-end device and the network virtualization device are in the same server; a network head end device is dedicated to the customer to prevent other customers of the host from using the network head end device; the network virtualization device communicates with a key management service to obtain the second key; the customer uses a key management service to provision the first key at the network head end device; the network head end device is a first network head end device; the system further includes a second network head end device configured to decrypt data from the customer; the network virtualization device is a first network virtualization device; the virtual cloud network is a first virtual cloud network; the system further includes a second network virtualization device; and / or the second network virtualization device is configured to receive data from the network head end device and encrypt the data received from the network head end device using a third key for the second virtual cloud network;The first network virtualization device and the second network virtualization device are part of the same network interface card, and / or the network head-end device is configured to receive the first key from the customer after a host authenticates the customer.

[0008] In yet another embodiment, a method includes receiving, using a network head end device, a first key provisioned by a customer; receiving, at the network head end device, a first data packet transmitted from the customer's device; decrypting the first data packet using the first key to obtain information; and, using a network virtualization device, decrypting the first data packet using the network head end device to obtain information. receiving the information from a network virtualization device, verifying that the information is to be sent to a virtual machine in a virtual cloud network, encrypting the information at the network virtualization device using a second key to generate a second data packet, and / or routing the second data packet to the virtual machine.

[0009] The above, together with other features and embodiments, will become more apparent with reference to the following specification, claims, and accompanying drawings. [Brief explanation of the drawings]

[0010] [Figure 1] FIG. 1 is a schematic diagram of an embodiment of a system of network virtualization devices. [Figure 2] FIG. 1 illustrates one embodiment of multiple network virtualization devices that receive encryption keys from a key management service. [Figure 3] FIG. 1 illustrates an embodiment of a network virtualization device that supports multiple customers with different encryption keys. [Figure 4] FIG. 1 is a flowchart illustrating an embodiment of a process for encrypting data in a virtual cloud network. [Figure 5] FIG. 1 is a flowchart illustrating an embodiment of a process for encrypting data for multiple virtual cloud networks using multiple encryption keys. [Figure 6] FIG. 1 illustrates an embodiment of a virtual cloud network that receives data through a VPN gateway. [Figure 7] FIG. 1 illustrates an embodiment of a virtual cloud network that receives data through a virtual cloud network (VCN) headend. [Figure 8] FIG. 1 illustrates an embodiment of one VCN headend supporting two or more virtual cloud networks. [Figure 9] FIG. 1 is a flowchart illustrating an embodiment of a process for end-to-end encryption of a virtual cloud network. [Figure 10] FIG. 1 is a block diagram illustrating one pattern for implementing a cloud infrastructure as a service system, according to at least one embodiment. [Figure 11] FIG. 1 is a block diagram illustrating another pattern for implementing a cloud infrastructure as a service system, according to at least one embodiment. [Figure 12] FIG. 1 is a block diagram illustrating another pattern for implementing a cloud infrastructure as a service system, according to at least one embodiment. [Figure 13] FIG. 1 is a block diagram illustrating another pattern for implementing a cloud infrastructure as a service system, according to at least one embodiment. [Figure 14] FIG. 1 is a block diagram illustrating an exemplary computer system according to at least one embodiment. [Figure 15] FIG. 1 is a high-level diagram of a distributed environment illustrating a virtual or overlay cloud network hosted by a cloud service provider infrastructure, according to certain embodiments. [Figure 16]FIG. 2 is a simplified architectural diagram of physical components in a physical network within a CSPI, according to certain embodiments. [Figure 17] FIG. 1 illustrates an exemplary arrangement within CSPI in which a host machine is connected to multiple network virtualization devices (NVDs), according to certain embodiments. [Figure 18] FIG. 1 illustrates connectivity between a host machine and an NVD for providing I / O virtualization to support multi-tenancy, according to certain embodiments. [Figure 19] FIG. 2 is a simplified block diagram of a physical network provided by a CSPI, according to certain embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0011] Detailed Description In the accompanying drawings, similar components and / or features may have the same reference level. Furthermore, various components of the same type may be distinguished by following the reference label with a dash and a second label that distinguishes between the similar components. When only a first reference label is used herein, the description is applicable to any one of the similar components having the same first reference label, regardless of the second reference label.

[0012] In the following description, for purposes of explanation, specific details are set forth in order to provide a thorough understanding of particular embodiments. It will be apparent, however, that various embodiments may be practiced without these specific details. The drawings and description are not intended to be limiting. The word "exemplary" is used herein to mean "serving as an example, instance, or illustration." Any embodiment or design described herein as "exemplary" is not necessarily intended to be construed as preferred or advantageous over other embodiments or designs.

[0013] A virtual cloud network (VCN) is a customizable private network. A host may provide computing hardware and / or software for a customer to set up a VCN. Typically, the host manages the VCN's encryption, if any. A customer may not want the host to manage encryption due to fear that a data leak on the host could compromise customer data or due to concerns about how much customer data the host can access. This description relates to a mechanism for providing VCN network encryption using customer-managed keys. The customer-managed keys can be delivered over a smart NIC. A smart NIC is a network interface card (e.g., a network adapter) that offloads processing tasks that would normally be handled by a CPU. A smart NIC can perform functions such as encryption, decryption, routing, and firewalling.

[0014] The smart NIC can be used to support a Network Encryption Virtual Function (NEVF) with a dedicated crypto accelerator and / or SRAM. The crypto accelerator can be used for inline packet encryption. The SRAM can be used to store encryption keys. The NEVF assigned to a customer virtual machine (the customer virtual machine is part of the customer VCN) can be used for virtual machine network traffic encryption and to store encryption keys. The hypervisor can map the customer virtual machine to the NEVF. The encryption keys can be securely provisioned in the NEVF within the customer VCN instance (e.g., virtual machine (VM) and / or bare metal (BM)).

[0015] Traffic exchanged between customer VCN instances is encrypted with encryption keys provisioned in the NEVF. Each instance in the VCN shares the same encryption key (e.g., opportunistic encryption). The control plane can provision and / or manage network encryption keys for customer instances (VMs and / or BMs) in the VCN. The control plane can be used to authenticate customer virtual functions and provision encryption keys from the key management service. Using certificates, the key management service and NICs can securely share customer encryption keys. Thus, customers can manage their network encryption keys (e.g., using application program interfaces and / or operating system commands). In some configurations, unique keys are shared between VM hosts in a VCN. The NEVF on each VM host stores metadata associated with the key and / or which key to use.

[0016] Referring to Figure 1, one example of a system for encrypting data in a virtual cloud network is shown. A schematic diagram of an embodiment is shown. The network virtualization device 100 includes a first virtualization engine 104-1 and a second virtualization engine 104-2. The virtualization engine 104 instantiates and provides a virtual network interface card (VNIC) for each bare metal or virtual machine. The virtualization engine 104 may be a network encryption virtual function (NEVF). The network virtualization device 100 may be a physical card (e.g., a smart NIC) with dedicated resources (e.g., memory and / or processor) attached. In some embodiments, the network virtualization device 100 is a SmartTOR, a network appliance, or a service host.

[0017] Routing and / or forwarding of packets within the cloud service provider infrastructure can be performed by a network virtualization device. The network virtualization device can realize one or more virtual network functions, such as a virtual network interface card (VNIC), a virtual router, a virtual network gateway, and a network encryption virtual function. A network virtualization device is a virtual object realized using software (e.g., code or instructions executed by a processor). A network virtualization device is a hardware component that performs a virtual function, such as a virtual router (e.g., a virtual router device is a physical device that executes code that realizes a virtual router). For example, a VNIC is performed by a smart NIC, and the smart NIC is a network virtualization device. When a VNIC is performed by a host machine, the host machine is a network virtualization device. In some embodiments, a virtual router is performed by a top-of-rack (TOR) switch (a TOR is a virtual router device). A smart NIC is just one example of a network virtualization device.

[0018] A virtual machine 108 is a program on a computer that acts like a separate computer within the computer. Virtual machines can be created using virtualization software. Virtual machines 108 can perform a variety of virtual functions.

[0019] The virtualization engine 104 includes a memory device 112 and a cryptographic processor 116. The memory device 112 is configured to store keys, such as cryptographic keys. In some embodiments, the memory device 112 is a static random access memory (SRAM) device that includes capacitors and transistors.

[0020] The crypto processor 116 is configured to encrypt and / or decrypt data to and from the virtual machine 108 using a key stored in the memory device 112. An outgoing packet TX is a data packet sent from the virtual machine 108. An incoming packet RX is a data packet sent to the virtual machine 108. The outgoing packet TX is encrypted by the crypto processor 116. The incoming packet RX is decrypted by the crypto processor 116. The outgoing packet TX and / or the incoming packet RX are encrypted / decrypted using in-line encryption / decryption. In some embodiments, the virtualization engine 104 is configured to provide network routing of data packets (e.g., the virtualization engine 104 provides routing data for the outgoing packet TX).

[0021] In the illustrated embodiment, the virtualization engine 104 is configured to instantiate only one virtual machine 108 at a time, which can increase security by allowing dedicated cryptographic resources (e.g., memory device 112 and / or crypto processor 116) for each virtual machine 108.

[0022] In the illustrated embodiment, the first virtualization engine 104-1 includes a first memory device 112-1 and a first cryptographic processor 116-1, and the second virtualization engine 104-2 includes a second memory device 112-2 and a second cryptographic processor 116-2. Thus, the first virtualization engine 104-1 and the second virtualization engine 104-2 are part of the same device. While two virtualization engines 104 are shown as being part of the network virtualization device 100, it should be understood that more than two virtualization engines 104 may be part of the network virtualization device 100 (e.g., three, five, ten, one hundred, or more virtualization engines 104 may be part of the network virtualization device 100).

[0023] In some embodiments, network virtualization device 100 is used to implement virtual functions such as VNICs, virtual routers, and / or NEVFs. Network virtualization device 100 may be a card (e.g., a smart NIC) in a server. Network virtualization device 100 is managed (e.g., owned and / or operated) by a host for one or more customers to set up one or more VCNs. The host is the administrator of network virtualization device 100. Keys may be stored (e.g., encrypted) in memory device 112 such that the host (e.g., the administrator) does not have access to the keys stored in memory device 112. Not having access to the keys may ensure customer data security even if the security of the host is compromised.

[0024] The Ethernet bridge 120 allows the first virtualization engine 104-1 to communicate over the Internet and / or with the second virtualization engine 104-2 (e.g., if the first virtual machine 108-1 and the second virtual machine 108-2 are part of the same virtual cloud network). The hypervisor 124 is used by the host to share the computing system's resources among the virtual machines 108.

[0025] FIG. 2 illustrates one embodiment of multiple virtualization engines 104 receiving encryption keys 204 from a key management service 208. In the illustrated embodiment, there are three virtualization engines 104. Although three virtualization engines 104 are shown, more or fewer virtualization engines 104 can be used. Each virtualization engine 104 instantiates one (or in some embodiments, only one) virtual machine 108. The virtual machines 108 in FIG. 2 are part of a common virtual cloud network (VCN) 212. Because the virtualization engines 104 are part of the same VCN 212, each virtualization engine 104 receives the same key (e.g., the same encryption key 204), which allows the virtualization engines 104 to securely communicate with each other (e.g., using the Ethernet bridge 120 shown in FIG. 1) using encrypted data. Thus, a first virtualization engine 104-1 is configured to receive an encryption key 204 from the key management service 208. The first virtualization engine 104-1 stores the encryption key 204 in the first memory device 112-1.

[0026] VCN control plane 216 is configured to manage, monitor, and / or modify cloud infrastructure resources. Key management service 208 can provide encryption keys 204 to virtualization engine 104 for the customer without the host of network virtualization device 100 having access to encryption keys 204. By not having the host (e.g., cloud service provider) having access to encryption keys 204, the customer controls the security of VCN 212.

[0027] To import a key into memory device 112 without the host having access to the key, a customer can initialize encryption key 204 in key management service 208 (e.g., OCI's Cloud Key Management Service) and / or grant permission to the virtualization engine 104 to access the key. In a cloud network, each resource can be assigned an identity principal (e.g., OCI's Cloud Identity Principle), which can provide each resource with credentials to authenticate the resource to other cloud resources. The virtualization engine 104 (e.g., NEVF) is a resource and can be assigned an identity principal. The virtualization engine 104 can be authenticated to key management service 208. The virtualization engine 104 can request a customer key (e.g., encryption key 204).

[0028] The virtualization engine 104 can request encryption keys 204 from the key management service 208 (e.g., authenticate itself using an identity principal and request the keys). The key management system 208 can push keys (and / or updates) to the virtualization engine 104 (e.g., after authenticating the virtualization engine 104). The request or push of keys occurs without the cloud network host having to provision the keys to the virtualization engine 104 (e.g., in the SRAM of the virtualization engine 104). Security protocols can be pre-shared between the key management system 208 and the virtualization engine 104, so that the key management system can route data to the virtualization engine 104 using the pre-shared secret to initialize the keys in the memory of the virtualization engine 104.

[0029] The same encryption key 204 is distributed to each virtualization engine 104 supporting virtual machines 108 in the virtual cloud network 212. The encryption key 204 can be distributed to the virtualization engine 104 when the virtual machine 108 is instantiated. For example, when a customer creates a VCN 212, the customer can be asked whether to encrypt the VCN 212 (e.g., the customer can check a box to encrypt the VCN 212). When an instance of a virtual machine 108 is launched, an underlying protocol passes from the key management service 208 to the virtualization engine 104 and distributes the encryption key 204 to the memory device 112 of the virtualization engine 104. The encryption key 204 can be updated periodically (e.g., hourly, daily, weekly, etc.) and / or can be updated by the customer (e.g., the customer selects or defines an update schedule and / or chooses to update the encryption key 204 immediately). In some embodiments, a customer generates multiple keys, and when it is time to rotate to a new key (e.g., at time T each day), the encryption key 204 is updated (e.g., each virtualization engine 104 contacts the key management service 208 at time T). The new key is published in the memory device 112. Key synchronization (e.g., automatic synchronization) may be used across multiple hosts (e.g., a synchronization counter in each virtualization engine 104 may be used to publish the new key in the memory device 112). In some embodiments, the encryption key 204 is rotated (e.g., the encryption key 204 is refreshed) on each virtualization engine 104 based on some encryption scheme. Thus, the encryption key 204 may be pushed and / or refreshed simultaneously to or on each virtualization engine 104 that is part of the VCN 212. Because the key management service 208 can have one encryption relationship with the VCN 212, the key management service 208 does not need to maintain relationships with different devices.

[0030] By encrypting data for which the customer controls the keys, the customer can be assured that the data is encrypted on the wire to the host. In some embodiments, the customer can communicate with the host using a Transport Layer Security (TLS) tunnel. However, TLS has bugs and can have security issues. By allowing customers to control the keys using the key management service 208, TLS bugs and security issues can be avoided or reduced. In some embodiments, a TLS tunnel or a custom security protocol based on a pre-shared key can be used to secure communication between the NEVF and the key management service.

[0031] Although this description shows encryption keys 204 being distributed and managed at the VCN 212 level, similar processes and techniques can be used at other levels, such as the subnet level. For example, encryption keys can be used at L2 or L3 of VCN 212.

[0032] 3 illustrates one embodiment of a network virtualization device 100 that supports multiple customers with different encryption keys 304. The network virtualization device 100 includes a first virtualization engine 104-1, a second virtualization engine 104-2, a third virtualization engine 104-3, and a fourth virtualization engine 104-4. The first virtualization engine 104-1 is configured to instantiate a first virtual machine 108-1. The second virtualization engine 104-2 is configured to instantiate a second virtual machine 108-2. The third virtualization engine 104-3 is configured to instantiate a third virtual machine 108-3. The fourth virtualization engine 104-4 is configured to instantiate a fourth virtual machine 108-4.

[0033] The first virtual machine 108-1 and the third virtual machine 108-3 are part of a first VCN 312-1. The second virtual machine 108-2 and the fourth virtual machine 108-4 are part of a second VCN 312-2. The first VCN 312-1 is for a first customer. The second VCN 312-2 is for a second customer, which is not the same as the first customer. Thus, multiple NEVFs on a single device can be used to support virtual machines that belong to different virtual cloud networks.

[0034] The first virtualization engine 104-1 and the third virtualization engine 104-3 receive the first encryption key 304-1 from the first key management service 208-1. The second virtualization engine 104-2 and the fourth virtualization engine 104-4 receive the second encryption key 304-2 from the second key management service 208-2. The second encryption key 304-2 is different from the first encryption key 304-1. In some embodiments, the virtualization engine 104 of the second VCN 312-2 receives the second encryption key 304-2 from the same key management service as the virtualization engine 104 of the first VCN 312-1 (e.g., the virtualization engine 104 of the second VCN 312-2 receives the second encryption key 304-2 from the first key management service 208-1).

[0035] The first virtualization engine 104-1 stores the first encryption key 304-1 in the first memory device 112-1. The second virtualization engine 104-2 stores the second encryption key 304-2 in the second memory device 112-2. Similarly, the third virtualization engine 104-3 and the fourth virtualization engine 104-4 each store their respective encryption keys 304 in the memory device 112. The host of the network virtualization device 100 does not have access to the first encryption key 304-1 or the second encryption key 304-2. Having one virtualization engine 104 per virtual machine 108 (e.g., by having dedicated resources, such as one memory device 112, per virtual machine 108) enables one network virtualization device 100 to securely support multiple VCNs 312 for multiple customers. Because each customer manages their own encryption key 304 for the VCN 312, each customer's data can be managed securely. Furthermore, even if the host's data is compromised, the data in VCN312 is not compromised. This allows us to provide our customers with even greater security reliability.

[0036] 4 is a flow chart illustrating one embodiment of a process 400 for encrypting data in a virtual cloud network. Process 400 begins in step 402 with instantiating a first virtual machine. For example, as shown in FIG. 1, first virtualization engine 104-1 instantiates first virtual machine 108-1. In step 404, a second virtual machine is instantiated. For example, in FIG. 1, second virtualization engine 104-2 instantiates second virtual machine 108-2. As shown in FIG. 1, virtualization engine 104 includes memory device 112 and cryptographic processor 116.

[0037] The first key is stored in the first memory device (step 406). For example, as shown in FIG. 2, the encryption key 204 is stored in the first memory device 112-1 of the first virtualization engine 104-1. The first key may be retrieved from (e.g., requested from or pushed by) a key management service. In some embodiments, the virtual cloud network customer controls the first key such that the host of the first virtualization engine 104-1 does not have access to the key.

[0038] The second key is stored in a second memory device (step 408). For example, as shown in FIG. 2, the encryption key 204 is stored in the second memory device 112-2 of the second virtualization engine 104-2. The second key may be retrieved from (e.g., requested from or pushed by) a key management service. In some embodiments, the virtual cloud network customer controls the second key such that the host of the virtualization engine 104 does not have access to the second key. As shown in FIG. 2, the second key may be the same as the first key. As shown in FIG. 3, the second key may be different from the first key. For example, the second key may be different from the first key because the second virtual machine is part of a different virtual cloud network than the first virtual machine.

[0039] In step 410, data of the first virtual machine is encrypted using a first key. For example, in FIG. 1, the first cryptographic processor 116-1 encrypts the transmission data TX from the first virtual machine 108-1. In step 412, data of the second virtual machine is encrypted using a second key. For example, in FIG. 1, the second cryptographic processor 116-2 encrypts the transmission data TX from the second virtual machine 108-2. If the first virtual machine 108-1 and the second virtual machine 108-2 are part of the same virtual cloud network, the first virtual machine 108-1 can use the same key to securely transmit data to and / or receive data from the second virtual machine 108-2 (see, for example, FIG. 2). However, if the first key is different from the second key as shown in FIG. 3, the first virtual machine 108-1 will not send encrypted data to and / or receive encrypted data from the second virtual machine 108-2 (unless there is some additional arrangement between the first VCN 312-1 and the second VCN 312-2 in FIG. 3).

[0040] The first virtualization engine 104-1 and the second virtualization engine 104-2 are on the same device (e.g., part of the same card in a server). Because the virtualization engine 104 is used to instantiate only one virtual machine and / or because the virtualization engine has one or more dedicated resources, the host of the network virtualization device can securely encrypt and / or decrypt data to and from each virtual machine without having access to the first key or the second key. do.

[0041] FIG. 5 is a flow chart illustrating one embodiment of a process 500 for encrypting data for multiple virtual cloud networks using multiple encryption keys. Process 500 begins in step 502 by instantiating a first set of virtual machines for a first customer. A first set of virtualization engines is used to instantiate the first set of virtual machines. The first set of virtual machines is part of a first virtual cloud network. In this embodiment, a set includes two or more. For example, in FIG. 3, first virtualization engine 104-1 and third virtual machine 108-1 and third virtual machine 108-3 are used to instantiate first virtual machine 108-1 and third virtual machine 108-3, and first virtual machine 108-1 and third virtual machine 108-3 are part of first virtual cloud network 312-1.

[0042] A second set of virtual machines for the second customer is instantiated (step 504). The second set of virtual machines is instantiated using a second set of virtualization engines. The second set of virtual machines is part of a second virtual cloud network. For example, in FIG. 3, the second virtualization engine 104-2 and the fourth virtual machine 108-2 and 108-4 are instantiated using the second virtualization engine 104-2 and the fourth virtual machine 108-4, and the second virtual machine 108-2 and the fourth virtual machine 108-4 are part of the second virtual cloud network 312-2.

[0043] In step 506, a first key, e.g., first encryption key 304-1 of Figure 3, is received by a virtualization engine used to instantiate virtual machines in the first virtual cloud network. A second key, e.g., second encryption key 304-2 of Figure 3, is received by a virtualization engine used to instantiate virtual machines in the second virtual cloud network (step 508). The first key can be received from a first key management service and the second key can be received from a second key management service different from the first key management service.

[0044] The first key is used to encrypt data for a first customer, step 510. The second key is used to encrypt data for a second customer, step 512. The host does not have access to the first key and / or the second key.

[0045] FIG. 6 illustrates one embodiment of virtual cloud network 312 receiving data through a virtual private network (VPN) gateway 604. The data is encrypted at the customer headend 608 (e.g., VPN headend). A headend is a device used to terminate a secure transmission link. Customer headend 608 is part of customer on-premises network 612. Data is sent from customer headend 608 to VPN gateway 604 (e.g., through Inet gateway 616). The VPN gateway is owned and / or operated by a host in VCN 312. An Internet Protocol Security (IPSec) tunnel can be formed from customer headend 608 to VPN gateway 604 so that data packets are encrypted at customer headend 608 and decrypted at VPN gateway 604, and vice versa for encrypted data sent from VPN gateway 604 to customer headend 608. Data sent from customer headend 608 to VPN gateway 604 can be sent over a public link (e.g., the Internet) or a private link (e.g., using Oracle FastConnect). IPSec tunnels can use Layer 1 and / or Layer 2 encryption.

[0046] In the VPN gateway 604, the host can receive data from one or more customers. In some embodiments, the VPN gateway 604 can be a bare-metal host dedicated to a single customer or a multi-tenant host with network hardware having multiple NEVFs that terminate VPN connections from multiple customers. The redirector 620 is used to route data from a first customer to a first network virtualization device 624-1 and data from a second customer to a second network virtualization device 624-2. The first network virtualization device 624-1 encrypts the first customer's data for the first virtual cloud network 312-1. The second network virtualization device 624-2 encrypts the second customer's data for the second virtual cloud network 312-2.

[0047] Unencrypted data is sent from VPN gateway 604 to redirector 620. Network virtualization device 624 is configured to encrypt the data for virtual cloud network 312. For example, network virtualization device 624 is virtualization engine 104 as shown in FIG. 2. Virtualization engine 104 can receive encryption key 204 from key management service 208 as shown in FIG. 2 and can therefore encrypt data in virtual cloud network 312 using encryption key 204 provisioned by the customer.

[0048] The customer on-premise network 612 includes devices owned and / or maintained by the host. For example, the customer headend 608 is a network card in a machine owned and / or maintained by the customer. In some embodiments, the customer headend 608 is 5 kilometers, 10 kilometers, 20 kilometers, 50 kilometers, 100 kilometers, 500 kilometers, or more away from the VPN gateway 604 (e.g., a network card owned and / or maintained by the host).

[0049] The VPN gateway 604, redirector 620, and network virtualization device 624 are part of a cloud service provider infrastructure (CSPI) 628. The host owns and / or maintains the CSPI 628. Thus, the host manages data security, if any, from the VPN gateway 604 to the network virtualization device 624. Additionally, to establish an IPSec tunnel from the customer headend 608 to the VPN gateway 604, the customer and the host share a key (e.g., in the case of symmetric encryption) and / or multiple keys (e.g., in the case of asymmetric encryption). For example, the host can provide the customer with a key to establish the IPSec tunnel, the customer can provide the host with the key, or the customer and host can agree on an encryption scheme.

[0050] 7 illustrates one embodiment of a virtual cloud network that receives data through a virtual cloud network (VCN) headend 704. In some situations, a customer may want to securely reach the virtual cloud network 312 from the customer on-premises network 612 without the host having access to the data and / or keys used for encryption. For example, the VPN gateway 604 uses an encryption key accessible to the host to decrypt data from the customer headend 608. Furthermore, the customer may not want their data sent unencrypted between the host's machines. For example, in FIG. 6, data is not encrypted through the redirector 620.

[0051] The VCN headend 704 provides a secure connection to the VCN from the customer's on-premises network (referred to in this disclosure as end-to-end encryption). , and / or to allow customers to control / manage encryption keys. The VCN headend 704 is a network resource dedicated to a particular customer (e.g., a host provides electricity and / or cooling, but the host cannot log into the VCN headend 704). In some embodiments, the VCN headend 704 may be or include a smart NIC, or one or several NICs, other network virtualization devices such as SmartToR. A smart NIC can be an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or a system-on-chip (SoC). The VCN headend 704 may include one or more processors and one or more memory devices.

[0052] Data is encrypted from customer headend 608 to VCN headend 704 using encryption key 708. VCN headend 704 may be configured to receive the encrypted data over a public link (e.g., the public Internet) and / or over a private link (e.g., Oracle FastConnect). For example, a VPN tunnel is formed from customer headend 608 to VCN headend 704, with customer headend 608 and VCN headend 704 being termination points of the VPN tunnel. Thus, instead of terminating the VPN tunnel at VPN gateway 604 as shown in FIG. 6, the VPN tunnel terminates at VCN headend 704 (e.g., bypassing VPN gateway 604 and / or bypassing redirector 620).

[0053] Because VCN headend 704 is a customer-dedicated resource, the customer can securely provision encryption key 708 in a memory device of VCN headend 704. For example, the customer can log in to VCN headend 704 to provision encryption key 708, and / or the customer can use key management service 208 of FIG. 2 to provision encryption key 708, similar to how key management service 208 is used to provision encryption key 304 to virtualization device 104. For example, key management service 208 can provide encryption key 708 to VCN headend 704 after verifying (e.g., authenticating) that VCN headend 704 has the appropriate authorization or credentials to receive encryption key 708.

[0054] The VCN headend 704, in certain embodiments, is a physical device that does not provide virtualization functions. Decrypted data is sent from the VCN headend 704 to the network virtualization device 624. In the illustrated embodiment, the VCN headend 704 and the network virtualization device 624 are part of the VCN gateway 712. For example, the VCN gateway 712 is a physical host with two network cards: one network card for the VCN headend 704 and a second network card for the network virtualization device 624. The VCN gateway 712 can be dedicated to one customer to prevent other customers of the host from using the VCN gateway 712. In one example, the VCN headend 704 and the network virtualization device 624 are part of the same server to increase security while unencrypted data is being sent from the VCN headend 704 to the network virtualization device 624. In some embodiments, the VCN headend 704 is on the same board (e.g., network card), on the same rack, and / or in the same space as the network virtualization device 624 (e.g., for security purposes). The VCN headend 704 and network virtualization device 624 can be part of a high performance NIC to handle traffic as needed. The VCN gateway 712 can terminate IPSec tunnels and has a NEVF that provisions encryption keys to encrypt traffic and inject it into the virtual cloud network. The VCN gateway 712 allows the customer to control / manage both the encryption key 304 and the encryption key 708. Although the VCN gateway 712 is part of the cloud service provider infrastructure (the host's infrastructure), the host does not manage or have access to the encryption key 708.

[0055] The network virtualization device 624 is used to encrypt (e.g., using a network encryption virtual function) data for the virtual cloud network 312. For example, the network virtualization device 624 is a virtualization engine 104 as described in FIGS. 1-3 and uses the encryption key 304 to encrypt data for the virtual cloud network 312. Thus, the network virtualization device 624 can provide instances of virtual machines in the virtual cloud network 312.

[0056] In some embodiments, the network virtualization device 624 is part of the VCN headend 704, so that the VPN tunnel can terminate at an instance of the virtual cloud network 312. The VCN gateway 712 can be used to decrypt data using the encryption key 708 and encrypt data using the encryption key 304.

[0057] In some configurations, a single customer can have more than one VCN headend 704. For example, a customer with high capacity may have multiple VCN headends 704 to increase bandwidth for securely uploading and / or downloading data to one or more virtual cloud networks 312. A single encryption key 708 can be used for multiple VCN headends 704 supporting a single customer, or different encryption keys 708 can be used for different VCN headends 704. Because the customer provisions the encryption key 708, the customer can decide whether to have one encryption key 708 or multiple encryption keys 708. In some embodiments, a single NIC is used for multiple VCN headends 704.

[0058] In some configurations, encryption key 708 is a long-lived key (e.g., rotated or changed weekly, monthly, or manually). Encryption key 304 may be a short-lived key (e.g., rotated or changed less frequently than weekly or daily, such as every 4 hours, 8 hours, 12 hours, 24 hours, or 36 hours). Thus, encryption key 708 may be configured to be changed less frequently than encryption key 304.

[0059] The system may include a network head-end device (e.g., VCN head-end 704). The network head-end device may be configured to receive a first key (e.g., encryption key 708) provisioned by a customer (e.g., the customer may log in to VCN head-end 704 to provision the first key and / or use a key management service). The network head-end device is configured to receive a first data packet from a customer device. For example, the network head-end device is configured to receive data from customer head-end 608. The network head-end device is configured to decrypt the first data packet using the first key to obtain information, the information being at least a portion of the decrypted data. A network virtualization device (e.g., network virtualization device 624) receives the information from the network head-end device after the first data packet is decrypted, determines that the information is to be sent to a virtual machine in a virtual cloud network (e.g., a virtual machine in virtual cloud network 312), encrypts the information using a second key, and sends the information to a virtual machine in a virtual cloud network (e.g., a virtual machine in virtual cloud network 312). For example, the information is encrypted using an encryption key 304. The second data packet is routed to the virtual machine (e.g., to a network virtualization device used to instantiate the virtual machine).

[0060] FIG. 8 illustrates an embodiment of one VCN gateway 712 supporting two or more virtual cloud networks 312 for a customer. Data from a customer headend 608 is securely transmitted to a VCN headend 704 using an encryption key 708. The VCN headend 704 is part of a VCN gateway 712. The VCN gateway includes a first network virtualization device 624-1 and a second network virtualization device 624-2. While two network virtualization devices 624 and two virtual cloud networks 312 are shown, more than two (e.g., three, four, five, ten, twenty, or more) can be used. As mentioned in connection with FIG. 7, more than two (e.g., two, three, four, or more) VCN headends 704 can also be used.

[0061] After decrypting the data received from the customer headend 608, the VCN headend 704 determines whether the data is intended for the first virtual cloud network 312-1, the second virtual cloud network 312-2, or both the first virtual cloud network 312-1 and the second virtual cloud network 312-2. If the data is intended for the first virtual cloud network 312-1, the data is re-encrypted using the first encryption key 304-1 with the first network virtualization device 624-1 and sent to the first virtual cloud network 312-1. If the data is intended for the second virtual cloud network 312-2, the data is re-encrypted using the second network virtualization device 624-2 with the second encryption key 304-2 and sent to the second virtual cloud network 312-2. Thus, one VCN headend 704 can be used to support multiple virtual cloud networks 312 for a customer. In some embodiments, one NIC is used for multiple network virtualization devices 624. In some embodiments, the network virtualization devices 624 are part of the same NIC as the VCN headend 704. In other embodiments, the VCN headend 704 is on a different NIC than the network virtualization devices 624.

[0062] FIG. 9 is a flow chart illustrating one embodiment of a process 900 for end-to-end encryption of a virtual cloud network. Process 900 begins in step 902 with receiving a first key at a network head-end device. For example, encryption key 708 shown in FIG. 7 is the first key, and VCN head-end 704 is the network head-end device. The first key can be provisioned by the customer (e.g., such that the first key is managed by the customer and the host is unaware of what the first key is). In step 904, the network head-end device receives a first data packet. For example, VCN head-end 704 receives encrypted data from a customer device (e.g., from customer head-end 608). The network head-end device decrypts the first data packet to obtain information (step 906). The information is at least a portion of the decrypted first data packet. In some embodiments, a gateway (e.g., VPN gateway 604 in FIG. 6) can terminate a VPN tunnel from a customer headend 608 using a first key and re-encrypt the traffic using a second key to send packets to an instance (e.g., VM / BM) in the VCN, where the second key is a VCN encryption key.

[0063] The network head-end device sends information to the network virtualization device, which then As a result, the network virtualization device receives the information from the network head-end device (step 908). For example, in FIG. 7, VCN head-end 704 sends the decrypted data to network virtualization device 624. In some embodiments, network virtualization device 624 may be an integrated component of VCN head-end 704. At step 910, the network virtualization device encrypts the information using the second key to generate a second data packet. For example, network virtualization device 624 encrypts the data for virtual cloud network 312 using encryption key 304. The second data packet is then routed to a virtual machine in the virtual cloud network. For example, in FIG. 7, the encrypted data is sent by network virtualization device 624 to virtual cloud network 312.

[0064] 7 is encrypted, or data from the network virtualization device 624 to the virtual cloud network 312 is encrypted, but not both. In some embodiments, the network virtualization device 624 verifies that data within the virtual cloud network should be encrypted before encrypting information received from the VCN headend 704.

[0065] Infrastructure as a service (IaaS) is a specific type of cloud computing. IaaS can be configured to provide virtualized computing resources over a public network (e.g., the Internet). In the IaaS model, a cloud computing provider may host infrastructure components (e.g., servers, storage devices, network nodes (e.g., hardware), deployment software, platform virtualization (e.g., hypervisor layer), etc.). In some cases, an IaaS provider may also offer various services (e.g., billing, monitoring, logging, security, load balancing, clustering, etc.) that accompany those infrastructure components. Thus, these services can be policy-driven, allowing IaaS users to implement policies that drive load balancing to maintain application availability and performance.

[0066] In some examples, IaaS customers may access resources and services over a wide area network (WAN), such as the Internet, and can use the cloud provider's services to install the remaining elements of their application stack. For example, a user can log in to an IaaS platform, create virtual machines (VMs), install an operating system (OS) on each VM, deploy middleware such as databases, create storage buckets for workloads and backups, and even install enterprise software on the VMs. The customer can then use the provider's services to perform a variety of functions, including balancing network traffic, troubleshooting application issues, monitoring performance, and managing disaster recovery.

[0067] In most cases, cloud computing models involve the participation of a cloud provider, which may or may not be a third-party service specialized in providing (e.g., offering, renting, selling) IaaS. Also, an entity may choose to deploy a private cloud and become its own provider of infrastructure services.

[0068] In some instances, IaaS deployments may require a new application or a new version The process of placing an application onto a provisioned application server, etc., may also include the process of provisioning the server (e.g., installing libraries, daemons, etc.). This is often managed below the hypervisor layer (e.g., server, storage, network hardware, and virtualization) by the cloud provider. Thus, the customer may be responsible for handling (e.g., on self-service virtual machines (e.g., that can be spun up on demand)), middleware, and / or application deployment.

[0069] In some instances, IaaS provisioning may refer to obtaining the computers or virtual hosts to be used and even installing the required libraries or services on them. In most cases, deployment does not include provisioning, which may need to be performed first.

[0070] In some cases, IaaS provisioning presents two distinct challenges. First, there is the initial challenge of provisioning an initial set of infrastructure before anything works. Second, there is the challenge of evolving the existing infrastructure after everything is provisioned (e.g., adding new services, modifying services, removing services, etc.). In some cases, these two challenges may be addressed by allowing the configuration of the infrastructure to be defined declaratively. In other words, the infrastructure (e.g., which components are needed and how they interact) may be defined by one or more configuration files. Thus, the overall topology of the infrastructure (e.g., which resources depend on which resources and how they work together with each other) may be described declaratively. In some examples, once the topology is defined, workflows may be generated to create and / or manage the different components described in the configuration files.

[0071] In some examples, the infrastructure may have many interconnected elements. For example, there may be one or more virtual private clouds (VPCs) (e.g., potentially on-demand pools of configurable and / or shared computing resources), also known as a core network. In some examples, there may also be one or more security group rules and one or more virtual machines (VMs) provisioned to define how the network's security is set up. Other infrastructure elements, such as load balancers, databases, etc., may also be provisioned. The infrastructure may evolve incrementally as more infrastructure elements are desired and / or added.

[0072] In some examples, continuous deployment techniques may be employed to enable deployment of infrastructure code across various virtual computing environments. In addition, the described techniques may enable infrastructure management within these environments. In some examples, a service team may write code that is desired to be deployed to one or more, but often many, different production environments (e.g., across a wide variety of geographic locations, sometimes spanning the entire world). However, in some examples, the infrastructure onto which the code will be deployed must first be set up. In some examples, provisioning may be done manually, utilizing a provisioning tool to provision resources and / or a deployment tool to deploy the code once the infrastructure is provisioned.

[0073] FIG. 10 is a block diagram 1000 illustrating an example pattern of an IaaS architecture, according to at least one embodiment. A service operator 1002 provides a virtual cloud network. The service operator 1002 may be communicatively coupled to a secure host tenancy 1004, which may include a virtualized network (VCN) 1006 and a secure host subnet 1008. In some examples, the service operator 1002 may employ one or more client computing devices. The client computing devices may be portable handheld devices (e.g., iPhone®, mobile phone, iPad®, computing tablet, personal digital assistant (PDA)) or wearable devices (e.g., Google Glass® head-mounted display) that run software such as Microsoft Windows Mobile® and / or various mobile operating systems such as iOS, Windows Phone, Android, BlackBerry 8, Palm OS, and that support Internet, email, short message service (SMS), Blackberry®, or other communication protocols. Alternatively, the client computing devices may be, by way of example, various versions of Microsoft Windows Mobile®. The client computing devices may be general-purpose personal computers, including personal computers and / or laptop computers running various GNU / Linux operating systems, such as, but not limited to, Google Chrome OS. The client computing devices may be workstation computers running any of a variety of commercially available UNIX or UNIX-like operating systems, including the standard UNIX operating system. Alternatively or additionally, the client computing devices may be other electronic devices capable of communicating over VCN 1006 and / or an Internet-accessible network, such as thin-client computers, Internet-enabled gaming systems (e.g., Microsoft Xbox game consoles with or without Kinect gesture input devices), and / or personal messaging devices.

[0074] The VCN 1006 may include a local peering gateway (LPG) 1010. The LPG 1010 may be communicatively coupled to a secure shell (SSH) VCN 1012 via the LPG 1010 included in the SSH VCN 1012. The SSH VCN 1012 may include an SSH subnet 1014, which may be communicatively coupled to a control plane VCN 1016 via the LPG 1010 included in the control plane VCN 1016. The SSH VCN 1012 may also be communicatively coupled to a data plane VCN 1018 via the LPG 1010. The control plane VCN 1016 and the data plane VCN 1018 may be included in a service tenancy 1019, which may be owned and / or operated by the IaaS provider.

[0075] The control plane VCN 1016 may include a control plane demilitarized zone (DMZ) tier 1020 that serves as a perimeter network (e.g., the portion of the enterprise network between the enterprise intranet and external networks). DMZ-based servers may have limited responsibilities and help mitigate security breaches. Additionally, the DMZ tier 1020 may include one or more load balancer (LB) subnets 1022, a control plane app tier 1024 that may include an app subnet 1026, and a control plane data tier 1028 that may include a database (DB) subnet 1030 (e.g., a front-end DB subnet and / or a back-end DB subnet). The LB subnet 1022 included in the control plane DMZ tier 1020 may be communicatively coupled to an app subnet 1026 included in the control plane app tier 1024 and to an Internet gateway 1034 that may be included in the control plane VCN 1016, and the app subnet 1026 may be communicatively coupled to a DB subnet 1030 included in the control plane data tier 1028, to a service gateway 1036, and to a network address translation (NAT) gateway 1038. The control plane VCN 1016 may include the service gateway 1036 and the NAT gateway 1038.

[0076] The control plane VCN 1016 may include a data plane mirror app layer 1040, which may include an app subnet 1026. The app subnet 1026 included in the data plane mirror app layer 1040 may include a virtual network interface controller (VNIC) 1042, which may run a compute instance 1044. The compute instance 1044 may communicatively couple the app subnet 1026 of the data plane mirror app layer 1040 to the app subnet 1026, which may be included in the data plane app layer 1046.

[0077] The data plane VCN 1018 may include a data plane app layer 1046, a data plane DMZ layer 1048, and a data plane data layer 1050. The data plane DMZ layer 1048 may include a LB subnet 1022 that may be communicatively coupled to an app subnet 1026 of the data plane app layer 1046 and an Internet gateway 1034 of the data plane VCN 1018. The app subnet 1026 may be communicatively coupled to a service gateway 1036 of the data plane VCN 1018 and a NAT gateway 1038 of the data plane VCN 1018. The data plane data layer 1050 may also include a DB subnet 1030 that may be communicatively coupled to the app subnet 1026 of the data plane app layer 1046.

[0078] The internet gateways 1034 of the control plane VCN 1016 and the data plane VCN 1018 may be communicatively coupled to a metadata management service 1052, which may be communicatively coupled to the public internet 1054. The public internet 1054 may be communicatively coupled to a NAT gateway 1038 of the control plane VCN 1016 and the data plane VCN 1018. The service gateways 1036 of the control plane VCN 1016 and the data plane VCN 1018 may be communicatively coupled to cloud services 1056.

[0079] In some examples, a service gateway 1036 of the control plane VCN 1016 or the data plane VCN 1018 may make an application programming interface (API) call to a cloud service 1056 without traversing the public Internet 1054. The API call from the service gateway 1036 to the cloud service 1056 may be one-way. That is, the service gateway 1036 may make an API call to the cloud service 1056, and the cloud service 1056 may send the requested data to the service gateway 1036. However, the cloud service 1056 may not initiate the API call to the service gateway 1036.

[0080] In some examples, secure host tenancy 1004 may be directly connected to service tenancy 1019, which may otherwise be separate. Secure host subnet 1008 may communicate with SSH subnet 1014 through LPG 1010, which may allow bidirectional communication through otherwise separate systems. Connecting secure host subnet 1008 to SSH subnet 1014 may give secure host subnet 1008 access to other entities within service tenancy 1019.

[0081] The control plane VCN 1016 may enable users of the service tenancy 1019 to set up or otherwise provision desired resources. The desired resources provisioned in the control plane VCN 1016 may be deployed or otherwise used in the data plane VCN 1018. In some examples, the control plane VCN 1016 may be separate from the data plane VCN 1018. The data plane mirror app layer 1040 of the control plane VCN 1016 may communicate with the data plane app layer 1046 of the data plane VCN 1018 via a VNIC 1042 that may be included in the data plane mirror app layer 1040 and the data plane app layer 1046.

[0082] In some examples, a user or customer of the system may make a request, such as a create, read, update, or delete (CRUD) operation, over the public internet 1054, which may communicate the request to the metadata management service 1052. The metadata management service 1052 may communicate the request to the control plane VCN 1016 through the internet gateway 1034. The request may be received by the LB subnet 1022 included in the control plane DMZ tier 1020. The LB subnet 1022 may determine that the request is valid, and in response to this determination, the LB subnet 1022 may send the request to the app subnet 1026 included in the control plane app tier 1024. If the request is validated and requires a call to the public internet 1054, the call to the public internet 1054 may be sent to the NAT gateway 1038, which may make the call to the public internet 1054. Memory that may be desired to be stored by the request may be stored in the DB subnet 1030.

[0083] In some examples, the data plane mirror app layer 1040 may facilitate direct communication between the control plane VCN 1016 and the data plane VCN 1018. For example, it may be desired that a configuration change, update, or other appropriate modification be applied to resources included in the data plane VCN 1018. Through the VNIC 1042, the control plane VCN 1016 may communicate directly with resources included in the data plane VCN 1018, thereby performing the change, update, or other appropriate modification to the configuration.

[0084] In some embodiments, the control plane VCN 1016 and the data plane VCN 1018 may be included in the service tenancy 1019. In this case, a user or customer of the system may not own or operate either the control plane VCN 1016 or the data plane VCN 1018. Instead, an IaaS provider may own or operate the control plane VCN 1016 and the data plane VCN 1018, both of which may be included in the service tenancy 1019. This embodiment may enable network isolation that may prevent a user or customer from interacting with other users' or customers' resources. This embodiment may also allow a user or customer of the system to store databases informally without having to rely on the public internet 1054 for storage, which may not have the desired level of security.

[0085] In another embodiment, the LB subnet 1022 included in the control plane VCN 1016 may be configured to receive signals from the service gateway 1036. In this embodiment, the control plane VCN 1016 and the data plane VCN 1018 may be configured to be called by the IaaS provider's customers without calling the public internet 1054. Customers of the IaaS provider may desire this embodiment because the databases used by the customers may be controlled by the IaaS provider and stored on the service tenancy 1019, which may be isolated from the public internet 1054.

[0086] 11 is a block diagram 1100 illustrating another example pattern of an IaaS architecture, according to at least one embodiment. A service operator 1102 (e.g., service operator 1002 of FIG. 10) provides a secure host tenancy 1102, which may include a virtual cloud network (VCN) 1106 (e.g., VCN 1006 of FIG. 10) and a secure host subnet 1108 (e.g., secure host subnet 1008 of FIG. 10). 10 ). VCN 1106 may include a local peering gateway (LPG) 1110 (e.g., LPG 1010 in FIG. 10 ), which may be communicatively coupled to a secure shell (SSH) VCN 1112 (e.g., SSH VCN 1012 in FIG. 10 ) via an LPG 1010 included in SSH VCN 1112. SSH VCN 1112 may include an SSH subnet 1114 (e.g., SSH subnet 1014 in FIG. 10 ), which may be communicatively coupled to a control plane VCN 1116 (e.g., control plane VCN 1016 in FIG. 10 ) via an LPG 1110 included in control plane VCN 1116. The control plane VCN 1116 may be included in a service tenancy 1119 (e.g., service tenancy 1019 in FIG. 10), and the data plane VCN 1118 (e.g., data plane VCN 1018 in FIG. 10) may be included in a customer tenancy 1121, which may be owned or operated by a user or customer of the system.

[0087] The control plane VCN 1116 may include a control plane DMZ tier 1120 (e.g., control plane DMZ tier 1020 in FIG. 10 ) that may include a LB subnet 1122 (e.g., LB subnet 1022 in FIG. 10 ), a control plane app tier 1124 (e.g., control plane app tier 1024 in FIG. 10 ) that may include an app subnet 1126 (e.g., app subnet 1026 in FIG. 10 ), and a control plane data tier 1128 (e.g., control plane data tier 1028 in FIG. 10 ) that may include a database (DB) subnet 1130 (e.g., similar to DB subnet 1030 in FIG. 10 ). The LB subnet 1122 included in the control plane DMZ layer 1120 may be communicatively coupled to an app subnet 1126 included in the control plane app layer 1124 and to an Internet gateway 1134 (e.g., Internet gateway 1034 in FIG. 10 ) that may be included in the control plane VCN 1116, and the app subnet 1126 may be communicatively coupled to a DB subnet 1130 included in the control plane data layer 1128, to a service gateway 1136 (e.g., service gateway in FIG. 10 ), and to a network address translation (NAT) gateway 1138 (e.g., NAT gateway 1038 in FIG. 10 ). The control plane VCN 1116 may include the service gateway 1136 and the NAT gateway 1138.

[0088] Control plane VCN 1116 may include a data plane mirror app layer 1140 (e.g., data plane mirror app layer 1040 in FIG. 10 ), which may include an app subnet 1126. App subnet 1126 included in data plane mirror app layer 1140 may include a virtual network interface controller (VNIC) 1142 (e.g., VNIC 1042) that may run compute instance 1144 (e.g., similar to compute instance 1044 in FIG. 10 ). Compute instance 1144 may facilitate communication between app subnet 1126 in data plane mirror app layer 1140 and app subnet 1126 that may be included in data plane app layer 1146 (e.g., data plane app layer 1046 in FIG. 10 ), via VNIC 1142 included in data plane mirror app layer 1140 and VNIC 1142 included in data plane app layer 1146.

[0089] An internet gateway 1134 included in the control plane VCN 1116 may be communicatively coupled to a metadata management service 1152 (e.g., metadata management service 1052 in FIG. 10 ), which may be communicatively coupled to a public internet 1154 (e.g., public internet 1054 in FIG. 10 ). The public internet 1154 may be communicatively coupled to a NAT gateway 1138 included in the control plane VCN 1116. A service gateway 1136 included in the control plane VCN 1116 may be communicatively coupled to cloud services 1156 (e.g., cloud services 1056 in FIG. 10 ).

[0090] In some examples, the data plane VCN 1118 may be included in the customer tenancy 1121. In this case, the IaaS provider may provide a control plane VCN 1116 for each customer, and the IaaS provider may set up a unique compute instance 1144, included in the service tenancy 1119, for each customer. Each compute instance 1144 may enable communication between the control plane VCN 1116 included in the service tenancy 1119 and the data plane VCN 1118 included in the customer tenancy 1121. The compute instance 1144 may enable resources provisioned in the control plane VCN 1116 included in the service tenancy 1119 to be deployed or otherwise used in the data plane VCN 1118 included in the customer tenancy 1121.

[0091] In another example, a customer of the IaaS provider may have a database that resides in customer tenancy 1121. In this example, control plane VCN 1116 may include data plane mirror app tier 1140, which may include app subnet 1126. Data plane mirror app tier 1140 may reside in data plane VCN 1118, but data plane mirror app tier 1140 may not reside in data plane VCN 1118. That is, data plane mirror app tier 1140 may have access to customer tenancy 1121, but data plane mirror app tier 1140 may not reside in data plane VCN 1118 or be owned or operated by the IaaS provider's customer. Data plane mirror app tier 1140 may be configured to make calls to data plane VCN 1118, but may not be configured to make calls to any entities included in control plane VCN 1116. A customer may desire to deploy or otherwise use resources in a data plane VCN 1118 that are provisioned in a control plane VCN 1116, and the data plane mirror app layer 1140 may facilitate the desired deployment or other use of the customer's resources.

[0092] In some embodiments, the IaaS provider's customer may apply filters to the data plane VCN 1118. In this embodiment, the customer may determine what the data plane VCN 1118 can access, and the customer may restrict access from the data plane VCN 1118 to the public internet 1154. The IaaS provider may not be able to apply filters or otherwise control access to the data plane VCN 1118 to any external networks or databases. Applying filters and controls by the customer on the data plane VCN 1118 included in the customer tenancy 1121 can help isolate the data plane VCN 1118 from other customers and the public internet 1154.

[0093] In some embodiments, cloud services 1156 may be invoked by the service gateway 1136 to access services that may not reside on the public internet 1154, the control plane VCN 1116, or the data plane VCN 1118. The connection between the cloud services 1156 and the control plane VCN 1116 or the data plane VCN 1118 may not be live or continuous. The cloud services 1156 may reside on different networks owned or operated by the IaaS provider. The cloud services 1156 may be configured to receive calls from the service gateway 1136 and may not be configured to receive calls from the public internet 1154. Some cloud services 1156 may be isolated from other cloud services 1156, and the control plane VCN 1116 may be isolated from cloud services 1156 that may not be in the same region as the control plane VCN 1116. For example, the control plane VCN 1116 may be in a "region" 1" and cloud service "Deployment 10" may be located in Region 1 and Region 2. If a call to Deployment 10 is made by a service gateway 1136 included in control plane VCN 1116 located in Region 1, the call may be sent to Deployment 10 in Region 1. In this example, control plane VCN 1116, or Deployment 10 in Region 1, may not be communicatively coupled to or otherwise in communication with Deployment 10 in Region 2.

[0094] 12 is a block diagram 1200 illustrating another example pattern of an IaaS architecture, according to at least one embodiment. A service operator 1202 (e.g., service operator 1002 of FIG. 10 ) may be communicatively coupled to a secure host tenancy 1204 (e.g., secure host tenancy 1004 of FIG. 10 ), which may include a virtual cloud network (VCN) 1206 (e.g., VCN 1006 of FIG. 10 ) and a secure host subnet 1208 (e.g., secure host subnet 1008 of FIG. 10 ). VCN 1206 may include an LPG 1210 (e.g., LPG 1010 of FIG. 10 ) that may be communicatively coupled to an SSH VCN 1212 (e.g., SSH VCN 1012 of FIG. 10 ) via an LPG 1210 included in SSH VCN 1212. SSH VCN 1212 may include SSH subnet 1214 (e.g., SSH subnet 1014 in FIG. 10 ), which may be communicatively coupled to control plane VCN 1216 (e.g., control plane VCN 1016 in FIG. 10 ) via LPG 1210 included in control plane VCN 1216, and to data plane VCN 1218 (e.g., data plane 1018 in FIG. 10 ) via LPG 1210 included in data plane VCN 1218. Control plane VCN 1216 and data plane VCN 1218 may be included in service tenancy 1219 (e.g., service tenancy 1019 in FIG. 10 ).

[0095] The control plane VCN 1216 may include a control plane DMZ tier 1220 (e.g., control plane DMZ tier 1020 in FIG. 10 ) that may include a load balancer (LB) subnet 1222 (e.g., LB subnet 1022 in FIG. 10 ), a control plane app tier 1224 (e.g., control plane app tier 1024 in FIG. 10 ) that may include an app subnet 1226 (e.g., similar to app subnet 1026 in FIG. 10 ), and a control plane data tier 1228 (e.g., control plane data tier 1028 in FIG. 10 ) that may include a DB subnet 1230. LB subnet 1222 included in control plane DMZ layer 1220 may be communicatively coupled to app subnet 1226 included in control plane app layer 1224 and to an Internet gateway 1234 (e.g., Internet gateway 1034 in FIG. 10 ) that may be included in control plane VCN 1216, and app subnet 1226 may be communicatively coupled to DB subnet 1230 included in control plane data layer 1228 and to a service gateway 1236 (e.g., service gateway in FIG. 10 ) and a network address translation (NAT) gateway 1238 (e.g., NAT gateway 1038 in FIG. 10 ). Control plane VCN 1216 may include service gateway 1236 and NAT gateway 1238.

[0096] Data plane VCN 1218 may include a data plane app layer 1246 (e.g., data plane app layer 1046 in FIG. 10 ), a data plane DMZ layer 1248 (e.g., data plane DMZ layer 1048 in FIG. 10 ), and a data plane data layer 1250 (e.g., data plane data layer 1050 in FIG. 10 ). Data plane DMZ layer 1248 may include a LB subnet 1222 that may be communicatively coupled to trusted app subnet 1260 and untrusted app subnet 1262 of data plane app layer 1246 and to an Internet gateway 1234 included in data plane VCN 1218. Trusted app subnet 1260 is a LB subnetwork that may be communicatively coupled to trusted app subnet 1260 and untrusted app subnet 1262 of data plane app layer 1246 and to an Internet gateway 1234 included in data plane VCN 1218. Untrusted app subnet 1262 may be communicatively coupled to service gateway 1236 included in data plane VCN 1218, NAT gateway 1238 included in data plane VCN 1218, and DB subnet 1230 included in data plane data layer 1250. Untrusted app subnet 1262 may be communicatively coupled to service gateway 1236 included in data plane VCN 1218 and DB subnet 1230 included in data plane data layer 1250. Data plane data layer 1250 may include DB subnet 1230, which may be communicatively coupled to service gateway 1236 included in data plane VCN 1218.

[0097] The untrusted app subnet 1262 may include one or more primary VNICs 1264(1)-(N), which may be communicatively coupled to tenant virtual machines (VMs) 1266(1)-(N). Each tenant VM 1266(1)-(N) may be communicatively coupled to a respective app subnet 1267(1)-(N), which may be included in a respective container egress VCN 1268(1)-(N), which may be included in a respective customer tenancy 1270(1)-(N). Each secondary VNIC 1272(1)-(N) may facilitate communication between the untrusted app subnet 1262 included in the data plane VCN 1218 and the app subnet included in the container egress VCN 1268(1)-(N). Each container egress VCN 1268(1)-(N) may include a NAT gateway 1238, which may be communicatively coupled to the public internet 1254 (e.g., public internet 1054 in FIG. 10 ).

[0098] An internet gateway 1234 included in the control plane VCN 1216 and included in the data plane VCN 1218 may be communicatively coupled to a metadata management service 1252 (e.g., metadata management system 1052 of FIG. 10 ), which may be communicatively coupled to the public internet 1254. The public internet 1254 may be communicatively coupled to a NAT gateway 1238 included in the control plane VCN 1216 and included in the data plane VCN 1218. A service gateway 1236 included in the control plane VCN 1216 and included in the data plane VCN 1218 may be communicatively coupled to cloud services 1256.

[0099] In some embodiments, data plane VCN 1218 may be integrated with customer tenancy 1270. This integration may be useful or desirable for an IaaS provider's customer in some cases, such as when they want runtime support for their code. A customer may provide code to run that may be disruptive, communicate with other customer resources, or otherwise cause undesirable effects. In response, the IaaS provider may determine whether to run the code that the customer provided to the IaaS provider.

[0100] In some examples, a customer of an IaaS provider may request temporary network access to the IaaS provider to attach a function to data plane layer app 1246. The code to perform the function may run in VMs 1266(1)-(N), and the code may not be configured to run anywhere else on data plane VCN 1218. Each VM 1266(1)-(N) may be connected to one customer tenancy 1270. Each container 1271(1)-(N) included in VM 1266(1)-(N) may be configured to run code. In this case, there may be double isolation (e.g., container 1271(1)-(N) may run code, and container 1271(1)-(N) may be included in at least VMs 1266(1)-(N) included in untrusted app subnet 1262), which may help prevent erroneous or otherwise unwanted code from damaging the IaaS provider's network or the networks of different customers. Containers 1271(1)-(N) may be communicatively coupled to customer tenancy 1270 and may be configured to send or receive data to or from customer tenancy 1270. 271(1)-(N) may not be configured to send or receive data to or from any other entity in data plane VCN 1218. Once the code execution is complete, the IaaS provider may kill or otherwise discard containers 1271(I)-(N).

[0101] In some embodiments, trusted app subnet 1260 may execute code that may be owned or operated by the IaaS provider. In this embodiment, trusted app subnet 1260 may be communicatively coupled to DB subnet 1230 and configured to perform CRUD operations on DB subnet 1230. Untrusted app subnet 1262 may be communicatively coupled to DB subnet 1230, but in this embodiment, the untrusted app subnet may be configured to perform read operations on DB subnet 1230. Containers 1271(1)-(N) that may be included in each customer's VMs 1266(1)-(N) and that may execute code from the customer may not be communicatively coupled to DB subnet 1230.

[0102] In other embodiments, the control plane VCN 1216 and the data plane VCN 1218 may not be directly communicatively coupled. In this embodiment, there may be no direct communication between the control plane VCN 1216 and the data plane VCN 1218. However, communication may occur indirectly through at least one method. An LPG 1210 may be established by the IaaS provider to facilitate communication between the control plane VCN 1216 and the data plane VCN 1218. In another example, the control plane VCN 1216 or the data plane VCN 1218 may make a call to a cloud service 1256 through a service gateway 1236. For example, a call from the control plane VCN 1216 to the cloud service 1256 may include a request for a service that may communicate with the data plane VCN 1218.

[0103] 13 is a block diagram 1300 illustrating another example pattern of an IaaS architecture, according to at least one embodiment. A service operator 1302 (e.g., service operator 1002 of FIG. 10 ) may be communicatively coupled to a secure host tenancy 1304 (e.g., secure host tenancy 1004 of FIG. 10 ), which may include a virtual cloud network (VCN) 1306 (e.g., VCN 1006 of FIG. 10 ) and a secure host subnet 1308 (e.g., secure host subnet 1008 of FIG. 10 ). VCN 1306 may include an LPG 1310 (e.g., LPG 1010 of FIG. 10 ) that may be communicatively coupled to an SSH VCN 1312 (e.g., SSH VCN 1012 of FIG. 10 ) via an LPG 1310 included in SSH VCN 1312. SSH VCN 1312 may include SSH subnet 1314 (e.g., SSH subnet 1014 in FIG. 10 ), which may be communicatively coupled to control plane VCN 1316 (e.g., control plane VCN 1016 in FIG. 10 ) via LPG 1310 included in control plane VCN 1316, and to data plane VCN 1318 (e.g., data plane 1018 in FIG. 10 ) via LPG 1310 included in data plane VCN 1318. Control plane VCN 1316 and data plane VCN 1318 may be included in service tenancy 1319 (e.g., service tenancy 1019 in FIG. 10 ).

[0104] The control plane VCN 1316 includes a control plane DMZ layer 1320 (e.g., the control plane DMZ layer 1020 in FIG. 10 ) that may include a LB subnet 1322 (e.g., the LB subnet 1022 in FIG. 10 ), a control plane app layer 1324 (e.g., the control plane app layer 1024 in FIG. 10 ) that may include an app subnet 1326 (e.g., the app subnet 1026 in FIG. 10 ), and a control plane data layer 1328 (e.g., the control plane data layer 1028 in FIG. 10 ) that may include a DB subnet 1330 (e.g., the DB subnet 1230 in FIG. 12 ). 10 ) and a network address translation (NAT) gateway 1338 (e.g., NAT gateway 1038 in FIG. 10 ). The LB subnet 1322 included in the control plane DMZ layer 1320 may be communicatively coupled to an app subnet 1326 included in the control plane app layer 1324 and to an Internet gateway 1334 (e.g., Internet gateway 1034 in FIG. 10 ) that may be included in the control plane VCN 1316, and the app subnet 1326 may be communicatively coupled to a DB subnet 1330 included in the control plane data layer 1328 and to a service gateway 1336 (e.g., service gateway in FIG. 10 ) and a network address translation (NAT) gateway 1338 (e.g., NAT gateway 1038 in FIG. 10 ). The control plane VCN 1316 may include the service gateway 1336 and the NAT gateway 1338.

[0105] Data plane VCN 1318 may include a data plane app layer 1346 (e.g., data plane app layer 1046 in FIG. 10 ), a data plane DMZ layer 1348 (e.g., data plane DMZ layer 1048 in FIG. 10 ), and a data plane data layer 1350 (e.g., data plane data layer 1050 in FIG. 10 ). Data plane DMZ layer 1348 may include LB subnet 1322, which may be communicatively coupled to trusted app subnet 1360 (e.g., trusted app subnet 1260 in FIG. 12 ) and untrusted app subnet 1362 (e.g., untrusted app subnet 1262 in FIG. 12 ) of data plane app layer 1346 and to an Internet gateway 1334 included in data plane VCN 1318. Trusted app subnet 1360 may be communicatively coupled to service gateway 1336 included in data plane VCN 1318, NAT gateway 1338 included in data plane VCN 1318, and DB subnet 1330 included in data plane data layer 1350. Untrusted app subnet 1362 may be communicatively coupled to service gateway 1336 included in data plane VCN 1318 and DB subnet 1330 included in data plane data layer 1350. Data plane data layer 1350 may include DB subnet 1330, which may be communicatively coupled to service gateway 1336 included in data plane VCN 1318.

[0106] The untrusted app subnet 1362 may include primary VNICs 1364(1)-(N), which may be communicatively coupled to tenant virtual machines (VMs) 1366(1)-(N) residing within the untrusted app subnet 1362. Each tenant VM 1366(1)-(N) may execute code in a respective container 1367(1)-(N), which may be communicatively coupled to an app subnet 1326, which may be included in a data plane app tier 1346, which may be included in a container egress VCN 1368. Each secondary VNIC 1372(1)-(N) may facilitate communication between the untrusted app subnet 1362, which is included in the data plane VCN 1318, and the app subnet included in the container egress VCN 1368. The container egress VCN may include a NAT gateway 1338, which may be communicatively coupled to the public internet 1354 (e.g., public internet 1054 in FIG. 10 ).

[0107] An internet gateway 1334 included in the control plane VCN 1316 and included in the data plane VCN 1318 may be communicatively coupled to a metadata management service 1352 (e.g., metadata management system 1052 of FIG. 10 ), which may be communicatively coupled to the public internet 1354. The public internet 1354 may be communicatively coupled to a NAT gateway 1338 included in the control plane VCN 1316 and included in the data plane VCN 1318. A service gateway 1336 included in the control plane VCN 1316 and included in the data plane VCN 1318 may be communicatively coupled to cloud services 1356.

[0108] In some examples, the performance illustrated by the architecture of block diagram 1300 of FIG. Turns may be considered an exception to the pattern illustrated by the architecture of block diagram 1200 in FIG. 12 and may be desirable for an IaaS provider's customers when the IaaS provider cannot communicate directly with the customer (e.g., in a disconnected area). Each container 1367(1)-(N) contained in a VM 1366(1)-(N) for each customer may be accessed by the customer in real time. The containers 1367(1)-(N) may be configured to make calls to a respective secondary VNIC 1372(1)-(N) contained in the app subnet 1326 of the data plane app tier 1346, which may be contained in a container egress VCN 1368. The secondary VNICs 1372(1)-(N) may send the calls to a NAT gateway 1338, which may send the calls to the public Internet 1354. In this example, containers 1367(1)-(N) that may be accessed in real time by a customer may be isolated from control plane VCN 1316 and may be isolated from other entities included in data plane VCN 1318. Containers 1367(1)-(N) may also be isolated from resources from other customers.

[0109] In another example, a customer may invoke cloud service 1356 using containers 1367(1)-(N). In this example, the customer may execute code in containers 1367(1)-(N) that requests a service from cloud service 1356. Containers 1367(1)-(N) may send the request to secondary VNICs 1372(1)-(N), which may send the request to a NAT gateway, which may send the request to public internet 1354. Public internet 1354 may send the request to LB subnet 1322, which is included in control plane VCN 1316, via internet gateway 1334. In response to determining that the request is valid, LB subnet 1326 may send the request to app subnet 1326, which may send the request to cloud service 1356 via service gateway 1336.

[0110] It should be noted that the illustrated IaaS architectures 1000, 1100, 1200, and 1300 may have components other than those shown. Moreover, the illustrated embodiments are only a few examples of cloud infrastructure systems that may incorporate embodiments of the present disclosure. In some other embodiments, the IaaS systems may have more or fewer components than those shown, may combine two or more components, or may have different configurations or arrangements of components.

[0111] In certain embodiments, the IaaS system described herein may include a suite of application, middleware, and database service offerings that are self-service, subscription-based, elastically scalable, reliable, highly available, and securely delivered to customers. One example of such an IaaS system is Oracle Cloud Infrastructure (OCI), offered by the assignee of the present application.

[0112] 14 illustrates an exemplary computer system 1400 upon which various embodiments of the present disclosure may be implemented. System 1400 may be used to implement any of the computer systems described above. As shown, computer system 1400 includes a processing unit 1404 that communicates with several peripheral subsystems via a bus subsystem 1402. These peripheral subsystems may include a processing acceleration unit 1406, an I / O subsystem 1408, a storage subsystem 1418, and a communication subsystem 1424. Storage subsystem 1418 includes a tangible computer-readable storage medium 1422 and a system memory 1410.

[0113] Bus subsystem 1402 provides a mechanism for allowing the various components and subsystems of computer system 1400 to communicate with each other as intended. While bus subsystem 1402 is shown schematically as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses. Bus subsystem 1402 may be any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. For example, such architectures may include a Peripheral Component Interconnect (PCI) bus, which may be implemented as an Industry Standard Architecture (ISA) bus, a MicroChannel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, and a mezzanine bus manufactured in accordance with the IEEE P1386.1 standard.

[0114] Processing unit 1404, which may be implemented as one or more integrated circuits (e.g., conventional microprocessors or microcontrollers), controls the operation of computer system 1400. One or more processors may be included in processing unit 1404. These processors may include single-core or multi-core processors. In particular embodiments, processing unit 1404 may be implemented as one or more independent processing units 1432 and / or 1434, with each processing unit including a single-core or multi-core processor. In other embodiments, processing unit 1404 may also be implemented as a quad-core processing unit formed by integrating two dual-core processors into one chip.

[0115] In various embodiments, processing unit 1404 may execute various programs in response to program code and may maintain multiple programs or processes running simultaneously. At any given time, some or all of the program code to be executed may reside in processor 1404 and / or storage subsystem 1418. Through appropriate programming, processor 1404 may provide the various functions described above. Computer system 1400 may additionally include a processing acceleration unit 1406, which may include a digital signal processor (DSP), special purpose processor, and / or others.

[0116] The I / O subsystem 1408 may include user interface input devices and user interface output devices. User interface input devices may include a keyboard, a pointing device such as a mouse or trackball, a touchpad or touchscreen integrated into a display, a scroll wheel, a click wheel, a dial, buttons, switches, a keypad, a voice input device with a voice command recognition system, a microphone, and other types of input devices. User interface input devices may include, for example, a motion-sensing and / or gesture-recognition device such as a Microsoft Kinect® motion sensor that allows a user to control and interact with an input device such as a Microsoft Xbox® 360 game controller through a natural user interface using gestures and spoken commands. User interface input devices may also detect eye movements from a user (e.g., "blinking" while taking a picture and / or selecting a menu) and transmit the eye gestures as input to an input device (e.g., Google Glass®). In addition, the user interface input devices may include voice recognition sensing devices that allow a user to interact with a voice recognition system (e.g., the Siri® navigator) through voice commands.

[0117] User interface input devices also include, but are not limited to, three-dimensional (3D) mice, joysticks or pointing sticks, gamepads, and graphics The user interface input devices may include tablets, as well as audio / visual devices such as speakers, digital cameras, digital camcorders, portable media players, webcams, image scanners, fingerprint scanners, barcode readers, 3D scanners, 3D printers, laser range finders, and eye-tracking devices. In addition, the user interface input devices may include medical imaging input devices such as, for example, computed tomography, magnetic resonance imaging, positron emission tomography, medical ultrasound, etc. The user interface input devices may also include audio input devices such as, for example, MIDI keyboards, digital musical instruments, etc.

[0118] User interface output devices may include a display subsystem, indicator lights, or non-visual displays such as audio output devices. The display subsystem may be a flat panel device such as one using a cathode ray tube (CRT), a liquid crystal display (LCD), or a plasma display, a projection device, a touch screen, etc. In general, the use of the term "output device" is intended to include all possible types of devices and mechanisms for outputting information from computer system 1400 to a user or to another computer. For example, user interface output devices may include various display devices that visually convey text, graphics, and audio / visual information, such as, but not limited to, monitors, printers, speakers, headphones, car navigation systems, plotters, audio output devices, and modems.

[0119] Computer system 1400 may include a storage subsystem 1418 that includes software elements currently shown as being in system memory 1410. System memory 1410 may store program instructions that are loadable and executable on processing unit 1404, as well as data generated during the execution of these programs.

[0120] Depending on the configuration and type of computer system 1400, system memory 1410 may be volatile (such as random access memory (RAM)) and / or non-volatile (such as read-only memory (ROM), flash memory, etc.). RAM typically contains data and / or program modules that are immediately accessible to and / or presently being operated on and executed by the processing unit 1404. In some implementations, system memory 1410 may include several different types of memory, such as static random access memory (SRAM) or dynamic random access memory (DRAM). In some implementations, a basic input / output system (BIOS), containing the basic routines that help to transfer information between elements within computer system 1400, such as during start-up, may typically be stored in ROM. By way of example and not limitation, system memory 1410 also illustrates application programs 1412, which may include client applications, a web browser, a middle-tier application, a relational database management system (RDBMS), etc.; program data 1414; and an operating system 1416. By way of example, operating system 1416 may include various versions of Microsoft Windows®, Apple Macintosh®, and / or Linux® operating systems, Various commercially available UNIX® or UNIX®-like operating systems (including, but not limited to, various GNU / Linux® operating systems, Google Chrome® OS, etc.), and / or iOS, Windows® Phone, Android® OS, BlackBerry® 14 OS, and Palm® OS operating systems. The operating system may include a mobile operating system such as a cellular operating system.

[0121] Storage subsystem 1418 also includes tangible, computer-readable storage media for storing the basic programming and data constructs that provide the functionality of some embodiments. The storage subsystem 1418 may provide a repository for storing data used in accordance with the present disclosure. Software (programs, code modules, instructions) that, when executed by a processor, provide the above functionality may be stored in the storage subsystem 1418. These software modules or instructions may be executed by the processing unit 1404. The storage subsystem 1418 may also provide a repository for storing data used in accordance with the present disclosure.

[0122] Storage subsystem 1400 may also include a computer-readable storage medium reader 1420 that may be further connected to a computer-readable storage medium 1422. Along with system memory 1410, and optionally in combination with system memory 1410, computer-readable storage medium 1422 may comprehensively represent remote, local, fixed, and / or removable storage devices plus storage media for temporarily and / or more permanently containing, storing, transmitting, and retrieving computer-readable information.

[0123] The computer-readable storage medium 1422 containing the code or portions of code may also include any suitable medium known or used in the art, including, but not limited to, storage media and communication media, such as volatile and nonvolatile, removable and non-removable media, implemented in any method or technology for storing and / or transmitting information. This may include tangible computer-readable storage media, such as RAM, ROM, electronically erasable programmable ROM (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disk (DVD), or other optical storage, magnetic cassette, magnetic tape, magnetic disk storage, or other magnetic storage, or other tangible computer-readable medium. This may also include non-tangible computer-readable media, such as a data signal, data transmission, or any other medium that can be used to transmit the desired information and that can be accessed by computing system 1400.

[0124] By way of example, computer-readable storage medium 1422 may include a hard disk drive that reads from and writes to non-removable, non-volatile magnetic media, a magnetic disk drive that reads from and writes to removable, non-volatile magnetic disks, and removable media such as CD-ROMs, DVDs, and Blu-Ray® disks or other optical media. The computer system 1400 may include an optical disk drive that reads from and writes to a removable, nonvolatile optical disk. The computer-readable storage medium 1422 may include, but is not limited to, a Zip® drive, a flash memory card, a Universal Serial Bus (USB) flash drive, a Secure Digital (SD) card, a DVD disk, a digital video tape, etc. The computer-readable storage medium 1422 may also include flash memory-based SSDs, enterprise flash drives, solid-state drives (SSDs) based on nonvolatile memory such as solid-state ROM, SSDs based on volatile memory such as solid-state RAM, dynamic RAM, static RAM, DRAM-based SSDs, magnetoresistive RAM (MRAM) SSDs, and hybrid SSDs that use a combination of DRAM and flash memory-based SSDs. The disk drives and their associated computer-readable media may provide nonvolatile storage of computer-readable instructions, data structures, program modules, and other data for the computer system 1400.

[0125] The communications subsystem 1424 provides an interface to other computer systems and networks. The communications subsystem 1424 acts as an interface for sending and receiving data between other systems and the computer system 1400. For example, the communications subsystem 1424 may enable the computer system 1400 to connect to one or more devices over the Internet. In some embodiments, In some embodiments, the communications subsystem 1424 may include a radio frequency (RF) transceiver component for accessing wireless voice and / or data networks (e.g., using cellular technology, advanced data network technologies such as 3G, 4G, or EDGE (enhanced data rates for global evolution), Wi-Fi (IEEE 802.11 family of standards, or other mobile communications technologies, or any combination thereof), a global positioning system (GPS) receiver component, and / or other components. In some embodiments, the communications subsystem 1424 may provide wired network connectivity (e.g., Ethernet) in addition to or instead of a wireless interface.

[0126] In some embodiments, the communications subsystem 1424 may also receive incoming communications in the form of structured and / or unstructured data feeds 1426, event streams 1428, event updates 1430, etc., on behalf of one or more users who may be using the computer system 1400.

[0127] For example, the communication subsystem 1424 may provide a Twitter feed, Facebook feed, Registered Trademark) updates, web feeds such as Rich Site Summary (RSS) feeds, and and / or may be configured to receive data feeds 1426 in real time from users of social networks and / or other communication services, such as real-time updates from one or more third-party sources.

[0128] Additionally, the communications subsystem 1424 may also be configured to receive data in the form of continuous data streams, which may include event streams 1428 of real-time events and / or event updates 1430, which may be continuous or infinite in nature without a definite end. Examples of applications that generate continuous data may include, for example, sensor data applications, financial tickers, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, automobile traffic monitoring, etc.

[0129] The communications subsystem 1424 may also be configured to output structured and / or unstructured data feeds 1426, event streams 1428, event updates 1430, etc. to one or more databases that may communicate with one or more streaming data source computers coupled to the computer system 1400.

[0130] The computer system 1400 may be one of a variety of types, including a handheld portable device (e.g., an iPhone® mobile phone, an iPad® computing tablet, a PDA), a wearable device (e.g., a Google Glass® head-mounted display), a PC, a workstation, a mainframe, a kiosk, a server rack, or any other data processing system.

[0131] Due to the ever-changing nature of computers and networks, the description of computer system 1400 shown in the figure is intended as only one specific example. Many other configurations are possible having more or fewer components than the system shown in the figure. For example, customized hardware may be used and / or particular elements may be implemented in hardware, firmware, software (including applets), or a combination. Furthermore, connections to other computing devices, such as network input / output devices, may be employed. Based on the disclosure and teachings provided herein, one of ordinary skill in the art will recognize other ways and / or methods for implementing various embodiments.

[0132] The term cloud services is commonly used to refer to services made available on-demand (e.g., via a subscription model) by a cloud service provider (CSP) to users or customers using systems and infrastructure (cloud infrastructure) provided by the CSP. Typically, the servers and systems that make up the CSP's infrastructure are separate from the customer's own on-premises servers and systems. Thus, customers can use cloud services provided by a CSP without having to purchase separate hardware and software resources for those services. Cloud services are designed to provide customers with easy and scalable access to applications and computing resources without requiring subscribing customers to invest in procuring the infrastructure used to deliver those services.

[0133] There are several cloud service providers offering different types of cloud services: Software-as-a-Service (SaaS), Service Platform-as-a-Service (PaaS), as a Service Infrastructure-as-a-Service (IaaS) and various other services. There are many different types or models of cloud services.

[0134] A customer can subscribe to one or more cloud services offered by a CSP. A customer can be any entity, such as an individual, organization, or business. When a customer subscribes or registers for a service offered by a CSP, a tenancy or account is created for that customer. The customer can then access one or more subscribed cloud resources associated with the account through this account.

[0135] As mentioned above, Infrastructure as a Service (IaaS) is a specific type of cloud computing service. In the IaaS model, a CSP provides infrastructure (called Cloud Service Provider Infrastructure, or CSPI) that customers can use to build their own customizable networks and deploy customer resources. Thus, customer resources and networks are hosted in a distributed environment by infrastructure provided by the CSP. This differs from traditional computing, where customer resources and networks are hosted by infrastructure provided by the customer.

[0136] CSPI may include interconnected high-performance computing resources, including various host machines, memory resources, and network resources that form a physical network, also known as a backbone or underlay network. CSPI resources may be distributed across one or more data centers, which may be geographically distributed across one or more geographic regions. Virtualization software may run on these physical resources to provide a virtualized distributed environment. Virtualization creates an overlay network (also known as a software-based network, software-defined network, or virtual network) on the physical network. The CSPI physical network provides the basis for creating one or more overlay or virtual networks on top of the physical network. A virtual or overlay network may include one or more virtual cloud networks (VCNs). A virtual network is realized using software virtualization technologies (e.g., hypervisors, functions performed by network virtualization devices (NVDs) (e.g., smart NICs), top-of-rack (TOR) switches, smart TORs that implement one or more functions performed by the NVDs, and other mechanisms) to create a network abstraction layer that can operate on top of the physical network. Virtual networks can take various forms, including peer-to-peer networks, IP networks, etc. Virtual networks are typically either Layer 3 IP networks or Layer 2 VLANs. This method of virtual or overlay networking is often called virtual Layer 3 networking or overlay Layer 3 networking. Examples of protocols developed for virtual networks include IP-in-IP (or Generic Routing Encapsulation (GRE)), Virtual Extensible LAN (VXLAN - IETF RFC7348), Virtual Private Networks (VPNs) (e.g., MPLS Layer 3 Virtual Private Networks (RFC4364)), VMware's NSX, and Generic Network Virtualization Encapsulation (GENEVE).

[0137] In the case of IaaS, the infrastructure (CSPI) provided by the CSP may be configured to provide virtualized computing resources over a public network (e.g., the Internet). In the IaaS model, a cloud computing service provider may host infrastructure components (e.g., servers, storage devices, network nodes (e.g., hardware), deployment software, platform virtualization (e.g., hypervisor layer), etc.). In some cases, the IaaS provider may also offer various services (e.g., billing, monitoring, logging, security, load balancing, clustering, etc.) that accompany those infrastructure components. These services may thus be policy-driven, allowing IaaS users to implement policies that drive load balancing to maintain application availability and performance. The CSPI provides infrastructure and a set of complementary cloud services that enable customers to build and run a wide range of applications and services in a highly available, hosted, distributed environment. The CSPI provides high-performance computing resources and power, as well as storage capacity, in a flexible virtual network that can be securely accessed from various network locations, such as from the customer's on-premises network. When a customer subscribes or signs up for an IaaS service offered by a CSP, the tenancy created for that customer is a secure, isolated partition within the CSP in which the customer can create, organize, and manage their cloud resources.

[0138] Customers can build their own virtual networks using the compute, memory, and networking resources provided by CSPI. They can deploy one or more customer resources or workloads, such as compute instances, on these virtual networks. For example, customers can build one or more customizable private virtual networks called virtual cloud networks (VCNs) using resources provided by CSPI. Customers can deploy one or more customer resources, such as compute instances, on the customer VCN. Compute instances can take the form of virtual machines, bare metal instances, and so on. CSPI thus provides infrastructure and a set of complementary cloud services that enable customers to build and run a wide range of applications and services in a highly available, virtual hosted environment. Customers do not manage or control the underlying physical resources provided by CSPI, but they do control the operating systems, storage, and deployed applications, and in some cases have limited control over some networking components (e.g., firewalls).

[0139] The CSP may provide a console that enables customers and network administrators to configure, access, and manage resources deployed in the cloud using CSPI resources. In certain embodiments, the console provides a web-based user interface that can be used to access and manage the CSPI. In some implementations, the console is a web-based application provided by the CSP. It is a communication.

[0140] CSPI may support single-tenancy or multi-tenancy architectures. In a single-tenancy architecture, software (e.g., applications, databases) or hardware components (e.g., host machines or servers) serve a single customer or tenant. In a multi-tenancy architecture, software or hardware components serve multiple customers or tenants. Thus, in a multi-tenancy architecture, CSPI resources are shared among multiple customers or tenants. In a multi-tenancy situation, precautions and safeguards are taken in CSPI to ensure that each tenant's data remains isolated and invisible to other tenants.

[0141] In a physical network, a network endpoint (“endpoint”) refers to a computing device or system that is connected to a physical network and communicates bidirectionally with the network to which it is connected. Network endpoints in a physical network may be connected to a local area network (LAN), a wide area network (WAN), or other types of physical networks. Examples of traditional endpoints in a physical network include modems, hubs, bridges, switches, routers, and other networking devices, physical computers (or host machines), etc. Each physical device in a physical network has a fixed network address that can be used to communicate with the device. This fixed network address may be a Layer 2 address (e.g., a MAC address), a fixed Layer 3 address (e.g., an IP address), etc. In a virtualized environment or virtual network, endpoints may include various virtual endpoints, such as virtual machines hosted by components of the physical network (e.g., hosted by a physical host machine). These endpoints in the virtual network are addressed by overlay addresses, such as overlay Layer 2 addresses (e.g., an overlay MAC address) and overlay Layer 3 addresses (e.g., an overlay IP address). Network overlays enable flexibility by allowing network administrators to move overlay addresses associated with network endpoints using software management (e.g., via software that implements the virtual network's control plane). Thus, unlike physical networks, in virtual networks, overlay addresses (e.g., overlay IP addresses) can be moved from one endpoint to another using network management software. Because virtual networks are built on top of physical networks, communication between components in a virtual network involves both the virtual network and the underlying physical network.To facilitate such communications, CSPI components are configured to learn and store mappings that map overlay addresses in the virtual network to actual physical addresses in the backbone network, and vice versa. These mappings are then used to facilitate communications. Customer traffic is encapsulated to facilitate routing within the virtual network.

[0142] Thus, physical addresses (e.g., physical IP addresses) are associated with components in a physical network, and overlay addresses (e.g., overlay IP addresses) are associated with entities in a virtual network. Physical and overlay IP addresses are both types of real IP addresses. They are distinct from virtual IP addresses, which map to multiple real IP addresses. Virtual IP addresses provide a one-to-many mapping between a virtual IP address and multiple real IP addresses.

[0143] Cloud Infrastructure or CSPI is a service that runs on a network of servers in one or more regions around the world. It is physically hosted in one or more data centers. CSPI may include components within a physical or backbone network and virtualized components (e.g., virtual networks, compute instances, virtual machines, etc.) within a virtual network built on top of the physical network components. In particular embodiments, CSPI is organized and hosted in realms, regions, and availability domains. A region is typically a localized geographic area that includes one or more data centers. Regions are generally independent of each other and can be separated by vast distances (e.g., across countries or even continents). For example, a first region may be in Australia, another region in Japan, yet another region in India, etc. CSPI resources are divided among regions so that each region has its own independent subset of CSPI resources. Each region may provide a set of core infrastructure services and resources, such as compute resources (e.g., bare metal servers, virtual machines, containers, and related infrastructure), storage resources (e.g., block volume storage, file storage, object storage, archive storage), networking resources (e.g., virtual cloud networks (VCNs), load balancing resources, connectivity to on-premises networks), database resources, edge networking resources (e.g., DNS), and access management and monitoring resources. Each region typically has multiple paths connecting it to other regions within the realm.

[0144] Generally, because using nearby resources is faster than using resources that are farther away, an application is deployed in the region where it is most heavily used (i.e., on the infrastructure associated with that region). Applications may also be deployed in different regions for a variety of reasons, such as redundancy to mitigate the risk of region-wide events such as large-scale weather systems or earthquakes, or to meet various requirements such as legal jurisdictions, tax territories, and other business or societal criteria.

[0145] Data centers within a region can be further organized and subdivided into availability domains (ADs). An availability domain may correspond to one or more data centers located within a region. A region can consist of one or more availability domains. In such a distributed environment, CSPI resources can be region-specific, such as a virtual cloud network (VCN), or availability domain-specific, such as a compute instance.

[0146] ADs within a region are isolated from each other, fault-tolerant, and configured to rarely fail simultaneously. This is achieved by ADs not sharing critical infrastructure resources such as networking, physical cables, cable paths, or cable entry points, so that a failure in one AD in a region is unlikely to affect the availability of other ADs in the same region. ADs within the same region can be connected to each other by low-latency, high-bandwidth networks, providing highly available connections to other networks (e.g., the Internet, customer on-premises networks, etc.), and multiple ADs can be used to build replicated systems for both high availability and disaster recovery. Cloud services use multiple ADs to ensure high availability and protect against resource failures. As the infrastructure offered by an IaaS provider evolves, more regions and ADs can be added along with additional capacity. Traffic between availability domains is typically encrypted.

[0147] In certain embodiments, regions are grouped into realms. A realm is a logical collection of regions. Realms are isolated from each other and do not share data. Within the same realm Regions in different realms can communicate with each other, but regions in different realms cannot communicate with each other. A CSP's customer's tenancy or account resides in one realm and can span one or more regions belonging to that realm. Typically, when a customer subscribes to an IaaS service, a tenancy or account is created for that customer in a customer-specified region (called the "home" region) within the realm. The customer can extend their tenancy to one or more other regions within the realm. The customer cannot access regions that are not within the realm in which their tenancy resides.

[0148] An IaaS provider may offer multiple realms, each targeted to a specific set of customers or users. For example, a commercial realm may be offered to commercial customers. As another example, a realm may be offered to a specific country or customers in that country. As yet another example, a government realm may be offered to a government, and so on. For example, a government realm may be targeted to a specific government and may have a higher security level than a commercial realm. For example, Oracle Cloud Infrastructure (OCI) currently offers a realm for its commercial region and two realms for its government cloud region (e.g., FedRAMP-certified and IL5-certified).

[0149] In certain embodiments, an AD can be subdivided into one or more fault domains. A fault domain is a grouping of infrastructure resources within an AD to provide anti-affinity. Fault domains can distribute compute instances so that they are not on the same physical hardware within an AD. This is known as anti-affinity. A fault domain refers to a set of hardware components (computers, switches, and so on) that share a single point of failure. A compute pool is logically divided into fault domains. Thus, a hardware failure or compute hardware maintenance event that affects one fault domain does not affect instances in other fault domains. Depending on the embodiment, the number of fault domains in each AD can vary. For example, in certain embodiments, each AD includes three fault domains. Fault domains act as logical data centers within an AD.

[0150] When a customer subscribes to an IaaS service, resources from CSPI are provisioned for the customer and associated with the customer's tenancy. Customers can use these provisioned resources to build private networks and deploy resources on these networks. A customer network hosted in the cloud by CSPI is called a virtual cloud network (VCN). Customers can set up one or more virtual cloud networks (VCNs) using the CSPI resources allocated to them. A VCN is a virtual or software-defined private network. Customer resources deployed in a customer's VCN may include compute instances (e.g., virtual machines, bare metal instances) and other resources. These compute instances may represent various customer workloads, such as applications, load balancers, and databases. Compute instances deployed on a VCN can communicate with publicly accessible endpoints (“public endpoints”) over a public network such as the Internet; with other instances in the same VCN or other VCNs (e.g., other VCNs of the customer or VCNs not belonging to the customer); with the customer's on-premises data center or network; and with service endpoints and other types of endpoints.

[0151] A CSP may use a CSPI to provide a variety of services. In some instances, a CSPI's customer may themselves act as a service provider and use CSPI resources. A service provider may provide services using public IP addresses. A service provider may expose service endpoints characterized by identifying information (e.g., IP addresses, DNS names, and ports). A customer's resources (e.g., compute instances) can consume a particular service by accessing the service endpoint exposed by the service for that particular service. These service endpoints are generally publicly accessible by users over a public communications network, such as the Internet, using a public IP address associated with the endpoint. A publicly accessible network endpoint is sometimes referred to as a public endpoint.

[0152] In particular embodiments, a service provider may expose a service through a service endpoint (sometimes referred to as a service endpoint). Customers of the service can then access the service using this service endpoint. In particular implementations, a service endpoint provided for a service can be accessed by multiple customers who intend to consume the service. In other implementations, a dedicated service endpoint may be provided to a customer so that only that customer can access the service using that dedicated service endpoint.

[0153] In certain embodiments, when a VCN is created, it is associated with a private overlay Classless Inter-Domain Routing (CIDR) address space, which is a range of private overlay IP addresses (e.g., 10.0 / 16) assigned to the VCN. A VCN includes associated subnets, route tables, and gateways. A VCN resides within a region but can span one, more, or all of that region's availability domains. A gateway is a virtual interface configured for a VCN that enables traffic to communicate between the VCN and one or more endpoints outside the VCN. One or more different types of gateways may be configured for a VCN to enable communication between different types of endpoints.

[0154] A VCN can be subdivided into one or more subnetworks, such as one or more subnets. A subnet is thus a building block or subdivision that can be created within a VCN. A VCN can have one or more subnets. Each subnet in a VCN is associated with a contiguous range of overlay IP addresses that does not overlap with other subnets in the VCN and represents a subset of address space within the VCN's address space (e.g., 10.0.0.0 / 24 and 10.0.1.0 / 24).

[0155] Each compute instance is associated with a virtual network interface card (VNIC) that allows the compute instance to participate in a subnet of a VCN. A VNIC is a logical representation of a physical network interface card (NIC). Generally, a VNIC is an interface between an entity (e.g., a compute instance, a service) and a virtual network. A VNIC resides in a subnet and has one or more associated IP addresses and associated security rules or policies. A VNIC corresponds to a Layer 2 port on a switch. A VNIC is attached to a compute instance and a subnet within a VCN. A VNIC associated with a compute instance allows the compute instance to be part of a subnet of a VCN, allowing the compute instance to communicate (e.g., send and receive packets) with endpoints on the same subnet as the compute instance, with endpoints in a different subnet within the VCN, or with endpoints outside the VCN. Thus, a VNIC associated with a compute instance determines how the compute instance connects to endpoints inside and outside the VCN. A VNIC for a compute instance is created and associated with that compute instance when that compute instance is created and added to a subnet in the VCN. For a subnet that contains a set of compute instances, the subnet contains VNICs that correspond to the set of compute instances, and each VNIC is attached to a compute instance in the set of compute instances.

[0156] Each compute instance is assigned a private overlay IP address via the VNIC associated with that compute instance. This private overlay IP address is assigned to the VNIC associated with the compute instance when the compute instance is created and is used to route traffic to and from the compute instance. All VNICs within a given subnet use the same route table, security lists, and DHCP options. As described above, each subnet within a VCN is associated with a contiguous range of overlay IP addresses that do not overlap with other subnets within that VCN and that represent a subset of address space within the VCN's address space (e.g., 10.0.0.0 / 24 and 10.0.1.0 / 24). For a VNIC on a particular subnet of a VCN, the private overlay IP address assigned to that VNIC is an address from the contiguous range of overlay IP addresses assigned to the subnet.

[0157] In particular embodiments, a compute instance may be assigned additional overlay IP addresses, such as one or more public IP addresses if they are in a public subnet, in addition to the private overlay IP address. These multiple addresses may be assigned on the same VNIC or on multiple VNICs associated with the compute instance. However, each instance has a primary VNIC that is created during instance launch and associated with the overlay private IP address assigned to the instance. This primary VNIC cannot be deleted. Additional VNICs, called secondary VNICs, can be added to an existing instance in the same availability domain as the primary VNIC. All VNICs are in the same availability domain as the instance. Secondary VNICs can be in a subnet in the same VCN as the primary VNIC, or in a different subnet in the same or a different VCN.

[0158] If a compute instance is in a public subnet, it may optionally be assigned a public IP address. A subnet can be designated as either a public or private subnet when creating the subnet. A private subnet means that resources (e.g., compute instances) and associated VNICs in the subnet cannot have public overlay IP addresses. A public subnet means that resources in the subnet and associated VNICs can have public IP addresses. Customers can specify whether a subnet resides in one availability domain or across multiple availability domains within a region or realm.

[0159] As mentioned above, a VCN may be subdivided into one or more subnets. In certain embodiments, a virtual router (referred to as a VCN VR or simply VR) configured for a VCN enables communication between subnets of the VCN. For a subnet within a VCN, the VR represents a logical gateway for that subnet, allowing the subnet (i.e., the compute instances on that subnet) to communicate with endpoints on other subnets within the VCN and with other endpoints outside the VCN. A VCN VR is a logical entity configured to route traffic between VNICs in a VCN and a virtual gateway ("gateway") associated with the VCN. A gateway is a virtual router, as shown in Figure 1. This is further described below with respect to the VCN VR. A VCN VR is a Layer 3 / IP layer concept. In one embodiment, there is one VCN VR for a VCN, and the VCN VR potentially has an unlimited number of ports addressed by IP addresses, one port for each subnet of the VCN. Thus, a VCN VR has a different IP address for each subnet in the VCN to which the VCN VR is attached. The VRs are also connected to various gateways configured for the VCN. In certain embodiments, specific overlay IP addresses from a subnet's overlay IP address range are reserved for ports in the VCN VR for that subnet. For example, consider a VCN with two subnets, each associated with the address ranges 10.0 / 16 and 10.1 / 16. For the first subnet in the VCN with the address range 10.0 / 16, addresses from this range are reserved for ports in the VCN VR for that subnet. In some examples, the first IP address from that range may be reserved for a VCN VR. For example, for a subnet with overlay IP address range 10.0 / 16, IP address 10.0.0.1 may be reserved for the VCN VR's port for that subnet. For a second subnet in the same VCN with address range 10.1 / 16, the VCN VR may have the second subnet's port with IP address 10.1.0.1. VCN VRs have different IP addresses for each subnet in a VCN.

[0160] In some other embodiments, each subnet in a VCN may have its own associated VR that is addressable by the subnet using a reserved or default IP address associated with the VR. The reserved or default IP address may, for example, be the first IP address from a range of IP addresses associated with the subnet. VNICs in the subnet can use this default or reserved IP address to communicate (e.g., send and receive packets) with the VR associated with the subnet. In such embodiments, the VR is the ingress / egress point for that subnet. VRs associated with subnets in a VCN can communicate with other VRs associated with other subnets in the VCN. VRs can also communicate with gateways associated with the VCN. The VR functions for a subnet are running on or performed by one or more NVDs that perform the VNIC functions for VNICs in the subnet.

[0161] Route tables, security rules, and DHCP options may be configured for a VCN. A route table is a virtual route table for a VCN and contains rules for routing traffic from subnets inside the VCN to destinations outside the VCN via gateways or specially configured instances. You configure a VCN's route table to control how packets are forwarded and routed in and out of the VCN. DHCP options are configuration information that is automatically given to an instance when it boots up.

[0162] Security rules configured for a VCN represent the overlay firewall rules for the VCN. Security rules include ingress and egress rules and can specify the type of traffic (e.g., based on protocol and port) that is allowed in and out of instances in the VCN. Customers can choose whether a given rule is stateful or stateless. For example, a customer can allow incoming SSH traffic from anywhere to a set of instances by setting up a stateful ingress rule with source CIDR 0.0.0.0 / 0 and destination TCP port 22. Security rules can be implemented using network security groups or security lists. Network security groups apply only to resources within that group. A VCN consists of a set of security rules that are applied to resources in a subnet. A security list, in turn, contains rules that apply to all resources in any subnet that uses that security list. A VCN may be given a default security list with default security rules. DHCP options configured for a VCN provide configuration information that is automatically given to instances in the VCN when they boot up.

[0163] In particular embodiments, configuration information for a VCN is determined and stored by a VCN control plane. The configuration information for a VCN may include, for example, information about address ranges associated with the VCN, subnets and associated information within the VCN, one or more VRs associated with the VCN, compute instances and associated VNICs within the VCN, NVDs performing various virtualized network functions (e.g., VNICs, VRs, gateways) associated with the VCN, state information for the VCN, and other VCN-related information. In particular embodiments, a VCN distribution service publishes the configuration information stored by the VCN control plane, or portions thereof, to the NVD. The distributed information may be used to update information stored and used by the NVD (e.g., forwarding tables, routing tables, etc.) to forward packets to and from compute instances within the VCN.

[0164] In particular embodiments, VCN and subnet creation is handled by a VCN control plane (CP), and compute instance launch is handled by the compute control plane. The compute control plane is responsible for allocating physical resources for the compute instances and then calls the VCN control plane to create VNICs and attach the VNICs to the compute instances. The VCN CP also sends VCN data mappings to the VCN data plane, which is configured to perform packet forwarding and routing functions.

[0165] A customer may create one or more VCNs using resources hosted by CSPI. Compute instances deployed on a customer VCN may communicate with different endpoints. These endpoints may include endpoints hosted by CSPI and endpoints external to CSPI.

[0166] Various different architectures for implementing cloud-based services using CSPI are shown in Figures 15, 16, 17, 18, and 19 and are described below. Figure 15 is a high-level diagram of a distributed environment 1500 illustrating an overlay or customer VCN hosted by CSPI, according to certain embodiments. The distributed environment shown in Figure 15 includes multiple components within an overlay network. The distributed environment 1500 shown in Figure 15 is merely an example and is not intended to unduly limit the scope of the claimed embodiments. Many variations, alternatives, and modifications are possible. For example, in some implementations, the distributed environment shown in Figure 15 may have more or fewer systems or components than those shown in Figure 1, may combine two or more systems, or may have a different configuration or arrangement of systems.

[0167] As shown in the example of FIG. 15, distributed environment 1500 includes CSPI 1501, which provides services and resources that customers can subscribe to and use to build a virtual cloud network (VCN). In a particular embodiment, CSPI 1501 provides IaaS services to subscribing customers. Data centers within CSPI 1501 may be organized into one or more regions. An example region, "Region US" 1502, is shown in FIG. 15. A customer configures Customer VCN 1504 for region 1502. A customer may deploy various compute instances on VCN 1504, which may include virtual machine or bare metal instances. Example instances include applications, databases, load balancers, etc. .

[0168] In the embodiment shown in FIG. 15, customer VCN 1504 includes two subnets, "Subnet-1" and "Subnet-2," each with its own CIDR IP address range. In FIG. 15, Subnet-1's overlay IP address range is 10.0 / 16, and Subnet-2's address range is 10.1 / 16. VCN virtual router 1505 represents the VCN's logical gateway, enabling communication between subnets in VCN 1504 and with other endpoints outside the VCN. VCN VR 1505 is configured to route traffic between VNICs in VCN 1504 and the gateway associated with VCN 1504. VCN VR 1505 provides a port to each subnet in VCN 1504. For example, VR 1505 may provide a port with IP address 10.0.0.1 to Subnet-1 and a port with IP address 10.1.0.1 to Subnet-2.

[0169] Multiple compute instances may be deployed on each subnet, and the compute instances may be virtual machine instances and / or bare metal instances. The compute instances in a subnet may be hosted by one or more host machines in CSPI1501. A compute instance joins a subnet through a VNIC associated with the compute instance. For example, as shown in FIG. 15, compute instance C1 is part of subnet-1 through a VNIC associated with the compute instance. Similarly, compute instance C2 is part of subnet-1 through a VNIC associated with C2. Similarly, multiple compute instances, which may be virtual machine instances or bare metal instances, may be part of subnet-1. Each compute instance is assigned a private overlay IP address and MAC address through its associated VNIC. For example, in FIG. 15, compute instance C1 has overlay IP address 10.0.0.2 and MAC address M1, and compute instance C2 has private overlay IP address 10.0.0.3 and MAC address M2. Each compute instance in Subnet-1, including compute instances C1 and C2, has a default route to VCN VR1505 using IP address 10.0.0.1, which is the IP address of a port in VCN VR1505 in Subnet-1.

[0170] Multiple compute instances, including virtual machine instances and / or bare metal instances, may be deployed on subnet-2. For example, as shown in FIG. 15, compute instances D1 and D2 are part of subnet-2 via VNICs associated with the respective compute instances. In the embodiment shown in FIG. 15, compute instance D1 has overlay IP address 10.1.0.2 and MAC address MM1, and compute instance D2 has private overlay IP address 10.1.0.3 and MAC address MM2. Each compute instance in subnet-2, including compute instances D1 and D2, has a default route to VCN VR1505 using IP address 10.1.0.1, which is the IP address of a port in VCN VR1505 in subnet-2.

[0171] VCN A 1504 may also include one or more load balancers. For example, a load balancer may be provided for a subnet and configured to load balance traffic among multiple compute instances on the subnet. A load balancer may also be provided to load balance traffic among subnets within the VCN.

[0172] A particular compute instance deployed on the VCN1504 can be used with a variety of different endpoints. These endpoints may include endpoints hosted by CSPI 1600 and endpoints external to CSPI 1600. Endpoints hosted by CSPI 1501 may include endpoints on the same subnet as a particular compute instance (e.g., communication between two compute instances in subnet-1), endpoints on a different subnet but within the same VCN (e.g., communication between a compute instance in subnet-1 and a compute instance in subnet-2), endpoints in a different VCN within the same region (e.g., communication between a compute instance in subnet-1 and an endpoint in a VCN in the same region 1506 or 1510, communication between a compute instance in subnet-1 and an endpoint in service network 1510 in the same region), or endpoints in a VCN in a different region (e.g., communication between a compute instance in subnet-1 and an endpoint in a VCN in a different region 1508). Compute instances in subnets hosted by CSPI 1501 may also communicate with endpoints not hosted by CSPI 1501 (i.e., external to CSPI 1501). These external endpoints include endpoints within the customer's on-premises network 1516, endpoints within other remote cloud-hosted networks 1518, public endpoints 1514 accessible via public networks such as the Internet, and other endpoints.

[0173] Communication between compute instances on the same subnet is facilitated using VNICs associated with the source and destination compute instances. For example, compute instance C1 in Subnet-1 may want to send a packet to compute instance C2 in Subnet-1. For a packet originating from the source compute instance and destined for another compute instance in the same subnet, the packet is first processed by the VNIC associated with the source compute instance. The processing performed by the VNIC associated with the source compute instance may include determining the packet's destination information from the packet header, identifying any policies (e.g., security lists) configured for the VNIC associated with the source compute instance, determining the packet's next hop, performing any packet encapsulation / decapsulation functions as needed, and forwarding / routing the packet to the next hop to facilitate communication of the packet to its intended destination. If the destination compute instance is in the same subnet as the source compute instance, the VNIC associated with the source compute instance is configured to identify the VNIC associated with the destination compute instance and forward the packet to that VNIC for processing. The VNIC associated with the destination compute instance then executes and forwards the packet to the destination compute instance.

[0174] When a packet is communicated from a compute instance in a subnet to an endpoint in a different subnet of the same VCN, the communication is facilitated by the VNICs and VCN VRs associated with the source and destination compute instances. For example, if compute instance C1 in Subnet-1 in Figure 15 wants to send a packet to compute instance D1 in Subnet-2, the packet is first processed by the VNIC associated with compute instance C1. The VNIC associated with compute instance C1 is configured to route the packet to VCN VR1505 using the VCN VR's default route or port 10.0.0.1. VCN VR1505 is configured to route the packet to Subnet-2 using port 10.1.0.1. The packet is then received and processed by the VNIC associated with D1, which forwards the packet to compute instance D1.

[0175] Passing packets from a compute instance in VCN1504 to an endpoint outside VCN1504 When communicating packets, the communication is facilitated by the VNIC associated with the source compute instance, the VCN VR 1505, and a gateway associated with the VCN 1504. One or more types of gateways may be associated with the VCN 1504. A gateway is an interface between a VCN and another endpoint, where the other endpoint is external to the VCN. A gateway is a Layer 3 / IP layer concept that allows a VCN to communicate with endpoints outside the VCN. Thus, a gateway facilitates traffic flow between a VCN and other VCNs or networks. Various different types of gateways may be configured for a VCN to facilitate different types of communication with different types of endpoints. Depending on the gateway, communication may be over a public network (e.g., the Internet) or a private network. Various communication protocols may be used for these communications.

[0176] For example, compute instance C1 may want to communicate with an endpoint outside of VCN1504. The packet may first be processed by the VNIC associated with the source compute instance C1. The VNIC processing determines that the packet's destination is outside of Cl's subnet-1. The VNIC associated with C1 may forward the packet to VCN VR1505 of VCN1504. VCN VR1505 then processes the packet and, as part of that processing, determines a particular gateway associated with VCN1504 as the packet's next hop based on the packet's destination. VCN VR1505 may then forward the packet to this particular identified gateway. For example, if the destination is an endpoint within a customer's operating premises network, the packet may be forwarded to VCN VR1505. The VR 1505 may forward the packet to a dynamic routing gateway (DRG) gateway 1522 configured for the VCN 1504. The gateway may then forward the packet to a next hop to facilitate communication of the packet to its intended final destination.

[0177] Various different types of gateways can be configured for a VCN. Examples of gateways that can be configured for a VCN are shown in FIG. 15 and described below. As shown in the embodiment of FIG. 15, a dynamic routing gateway (DRG) 1522 may be added to or associated with a customer VCN 1504 to provide a path for private network traffic communication between the customer VCN 1504 and another endpoint. The other endpoint may be a customer's on-premises network 1516, a VCN 1508 in a different region of CSPI 1501, or another remote cloud network 1518 not hosted by CSPI 1501. The customer on-premises network 1516 may be a customer network or customer data center built using customer resources. Access to the customer on-premises network 1516 is generally highly restricted. For a customer with both a customer on-premises network 1516 and one or more VCNs 1504 deployed or hosted in the cloud by CSPI 1501, the customer may want their on-premises network 1516 and their cloud-based VCN 1504 to be able to communicate with each other. This allows customers to build an extended hybrid environment that includes their own VCN 1504 hosted by CSPI 1501 and their own on-premises network 1516. DRG 1522 enables this communication. To enable such communication, a communication channel 1524 is set up, with one endpoint of the channel in the customer on-premises network 1516 and the other endpoint in CSPI 1501 connected to the customer VCN 1504. The communication channel 1524 can be over a public communication network, such as the Internet, or a private communication network. Examples include IPsec VPN technology over a public communication network, such as the Internet, or Oracle VPN using a private network instead of a public network. A variety of different communication protocols may be used, such as the FastConnect technology of A device or equipment in the customer on-premise network 1516 that forms one endpoint of the channel 1524 is called customer premises equipment (CPE), such as the CPE 1526 shown in Figure 15. On the CSPI 1501 side, the endpoint may be a host machine running the DRG 1522.

[0178] In certain embodiments, remote peering connections (RPCs) can be added to a DRG, allowing customers to peer one VCN with another VCN in a different region. Using such RPCs, customer VCN 1504 can connect to VCN 1508 in another region using DRG 1522. DRG 1522 can also be used to connect to other cloud services, such as Microsoft® Azure Cloud, Amazon® ) may communicate with other remote cloud networks 1518 not hosted by CSPI 1501, such as the AWS cloud.

[0179] As shown in Figure 15, an internet gateway (IGW) 1520 may be configured for customer VCN 1504, which allows compute instances on VCN 1504 to communicate with public endpoints 1514 accessible over a public network, such as the internet. IGW 15120 is a gateway that connects a VCN to a public network, such as the internet. IGW 1520 allows public subnets in a VCN, such as VCN 1504 (resources in the public subnet have public overlay IP addresses) to directly access public endpoints 1512 over the public network 1514, such as the internet. Using IGW 1520, connections may be initiated from subnets within VCN 1504 or from the internet.

[0180] A network address translation (NAT) gateway 1528 may be configured for customer VCN 1504 to enable cloud resources in the customer VCN that do not have dedicated public overlay IP addresses to access the internet, and to do so without exposing those resources to direct incoming internet connections (e.g., L4-L7 connections). This allows private subnets in the VCN, such as private subnet-1 in VCN 1504, to privately access public endpoints on the internet. With a NAT gateway, connections can only be initiated from the private subnet to the public internet, not from the internet to the private subnet.

[0181] In particular embodiments, a service gateway (SGW) 1526 may be configured for customer VCN 1504, providing a path for private network traffic between VCN 1504 and service endpoints supported in service network 1510. In particular embodiments, service network 1510 may be provided by a CSP and may offer a variety of services. One example of such a service network is Oracle's Services Network, which offers a variety of services available to customers. For example, a compute instance (e.g., a database system) in a private subnet of customer VCN 1504 can back up data to a service endpoint (e.g., Object Storage) without requiring a public IP address or access to the Internet. In particular embodiments, a VCN may have only one SGW, and connections can only be initiated from subnets within the VCN, not from service network 1510. When a VCN is peered with another VCN, resources in the other VCN typically do not have access to the SGW. Also, resources in an on-premises network connected to a VCN with FastConnect or VPN Connect may not have access to the SGW for that VCN. A configured service gateway can be used.

[0182] In a specific implementation, the SGW 1526 uses the concept of a service classless inter-domain routing (CIDR) label, which is a string that represents all the regional public IP address ranges for a service or group of services of interest. Customers use the service CIDR label when configuring the SGW and associated route rules to control traffic to the service. Customers can optionally use the service CIDR label when configuring security rules without having to adjust the security rules if the service's public IP address changes in the future.

[0183] A local peering gateway (LPG) 1532 is a gateway that can be added to a customer VCN 1504 to enable the VCN 1504 to peer with another VCN in the same region. Peering means that the VCNs communicate using private IP addresses without the traffic traversing a public network such as the Internet or routing the traffic through the customer's on-premises network 1516. In a preferred embodiment, a VCN has a separate LPG for each peering the VCN establishes. Local peering or VCN peering is a common practice used to establish network connectivity between different applications or infrastructure management functions.

[0184] A service provider, such as a provider of a service in service network 1510, may provide access to a service using different access models. According to a public access model, a service may be exposed as a public endpoint publicly accessible by a compute instance in a customer VCN over a public network such as the Internet, and / or may be privately accessible through SGW 1526. According to a specific private access model, a service is made accessible as a private IP endpoint in a private subnet in a customer VCN. This is called private endpoint (PE) access and allows a service provider to expose its service as an instance in a customer's private network. A private endpoint resource represents a service in a customer's VCN. Each PE appears as a VNIC (called a PE-VNIC, with one or more private IPs) in a subnet chosen by the customer in the customer's VCN. Thus, a PE provides a way to present a service in a private customer VCN subnet using a VNIC. Because the endpoint is exposed as a VNIC, all characteristics associated with the VNIC, such as routing rules, security lists, etc., are shared with the PE. It will be available for VNICs.

[0185] Service providers can register their services to enable access through the PE. Providers can associate policies with services that limit the visibility of the service to customer tenancies. Providers can register multiple services under one virtual IP address (VIP), especially for multi-tenant services. There can be multiple such private endpoints (in multiple VCNs) representing the same service.

[0186] The compute instances in the private subnet can then access the service using the private IP address of the PE VNIC or the service DNS name. The compute instances in the customer VCN can access the service by sending traffic to the private IP address of the PE in the customer VCN. The private access gateway (PAGW) 1530 connects the customer subnet private PAGW 1530 is a gateway resource that can be attached to a service provider VCN (e.g., a VCN in service network 1510) that serves as the ingress / egress point for all traffic to and from the endpoints. PAGW 1530 allows providers to scale the number of PE connections without utilizing internal IP address resources. Providers only need to configure one PAGW for any number of services registered in one VCN. Providers can represent services as private endpoints in multiple VCNs for one or more customers. From the customer's perspective, the PE VNIC is not attached to the customer's instance, but rather to the service the customer wants to interact with. Traffic destined for the private endpoint is routed to the service through PAGW 1530. These are called customer-to-service private connections (C2S connections).

[0187] The PE concept can also be used to extend private access of services to customer on-premises networks and data centers by allowing traffic to pass through FastConnect / IPSec links and private endpoints in the customer VCN, and to extend private access of services to customer peered VCNs by allowing traffic to pass between LPG1532 and the PE in the customer VCN.

[0188] Customers can control routing within a VCN at the subnet level, allowing them to specify which subnets within a customer's VCN, such as VCN 1504, use each gateway. A VCN's route tables are used to determine whether traffic is allowed to exit the VCN through a particular gateway. For example, in a particular case, the route table for a public subnet in customer VCN 1504 may send non-local traffic through IGW 1520. The route table for a private subnet in the same customer VCN 1504 may send traffic destined for CSP services through SGW 1526. All remaining traffic may be sent through NAT gateway 1528. Route tables only control traffic that exits the VCN.

[0189] Security lists associated with a VCN are used to control traffic entering the VCN through a gateway via an inbound connection. All resources within a subnet use the same route table and security lists. Security lists may be used to control specific types of traffic allowed to and from instances within a VCN's subnets. Security list rules may include ingress (inbound) and egress (outbound) rules. For example, an ingress rule may specify an allowed source address range, and an egress rule may specify an allowed destination address range. Security rules may specify a specific protocol (e.g., TCP, ICMP), a specific port (e.g., 22 for SSH, 3389 for Windows RDP), etc. In certain implementations, the instance's operating system may enforce its own firewall rules that match security list rules. Rules may be stateful (e.g., connections are tracked and responses are automatically allowed without an explicit security list rule for the response traffic) or stateless.

[0190] Access from a customer VCN (i.e., by resources or compute instances deployed on VCN 1504) can be categorized as public access, private access, or dedicated access. Public access refers to an access model where a public IP address or NAT is used to access a public endpoint. Private access Private access enables customer workloads in VCN 1504 with private IP addresses (e.g., resources in a private subnet) to access services without traversing a public network such as the Internet. In particular embodiments, CSPI 1501 enables customer VCN workloads with private IP addresses to access (public service endpoints of) services using a service gateway. Thus, the service gateway provides a private access model by establishing a virtual link between the customer's VCN and the public endpoints of services that reside outside the customer's private network.

[0191] In addition to this, CSPI is using technologies such as FastConnect public peering to For example, you may provide dedicated public access, where customer on-premises instances can use a FastConnect connection and connect to a public network such as the Internet. CSPI also uses FastConnect private peering to provide access to one or more services within a customer VCN without traversing the network. may provide private access to the customer's VCN, where customer on-premises instances with private IP addresses can connect to the customer's VCN using a FastConnect connection. FastConnect allows you to access your workloads over the public internet. FastConnect is an alternative network connectivity solution to connect a customer's on-premises network to CSPI and its services using an internet-based connection. In comparison, it offers an easy, flexible, and economical way to create a dedicated, private connection with higher bandwidth options and a more reliable and consistent networking experience.

[0192] FIG. 15 and the accompanying description above describe various virtualized components in an exemplary virtual network. As mentioned above, a virtual network is built on an underlying physical or backbone network. FIG. 16 illustrates a simplified architectural diagram of physical components in a physical network within CSPI 1600 that provides the foundation for the virtual network, according to a particular embodiment. As illustrated, CSPI 1600 provides a distributed environment including components and resources (e.g., compute, memory, and networking resources) provided by a cloud service provider (CSP). These components and resources are used to provide cloud services (e.g., IaaS services) to subscribing customers, i.e., customers who subscribe to one or more services offered by the CSP. Based on the services to which the customer subscribes, a subset of CSPI 1600's resources (e.g., compute, memory, and networking resources) is provisioned to the customer. The customer can then build their own cloud-based (i.e., CSPI-hosted), customizable private virtual network using the physical compute, memory, and networking resources provided by CSPI 1600. As mentioned above, these customer networks are called virtual cloud networks (VCNs). Customers can deploy one or more customer resources, such as compute instances, on these customer VCNs. Compute instances can take the form of virtual machines, bare metal instances, etc. CSPI1600 provides infrastructure and a set of complementary cloud services that enable customers to build and run a wide range of applications and services in a highly available, hosted environment.

[0193] In the exemplary embodiment shown in FIG. 16, the physical components of CSPI 1600 include one or more physical host machines or servers (e.g., 1602, 1606, 1608), network virtualization devices (NVDs) (e.g., 1610, 1612), and a top The VCN includes a TOR switch (e.g., 1614, 1616), a physical network (e.g., 1618), and switches within the physical network 1618. The physical host machines or servers may host and execute various compute instances that participate in one or more subnets of the VCN. The compute instances may include virtual machine instances and bare metal instances. For example, the various compute instances shown in FIG. 15 may be hosted by the physical host machines shown in FIG. 16. The virtual machine compute instances in the VCN may be executed by one host machine or by multiple different host machines. Also, the physical host machines may host virtual host machines, container-based hosts or functions, etc. The VNICs and VCN VRs shown in FIG. 15 may be executed by the NVDs shown in FIG. 16. The gateways shown in FIG. 15 may be executed by the host machines and / or NVDs shown in FIG. 16.

[0194] A host machine or server may run a hypervisor (also called a virtual machine monitor or VMM) that creates and enables a virtualized environment on the host machine. Virtualization or a virtualized environment facilitates cloud-based computing. One or more compute instances may be created, executed, and managed on the host machine by the hypervisor on the host machine. The hypervisor on the host machine enables the host machine's physical computing resources (e.g., compute, memory, and networking resources) to be shared among the various compute instances executed by the host machine.

[0195] For example, as shown in FIG. 16 , host machines 1602 and 1608 run hypervisors 1660 and 1666, respectively. These hypervisors may be implemented using software, firmware, or hardware, or a combination thereof. Typically, a hypervisor is a process or software layer that resides on a host machine's operating system (OS), which runs on the host machine's hardware processor. A hypervisor provides a virtualized environment by enabling the host machine's physical computing resources (e.g., processing resources such as processors / cores, memory resources, and networking resources) to be shared among various virtual machine computing instances executed by the host machine. For example, in FIG. 16 , hypervisor 1660 may reside on the OS of host machine 1602 and enable the host machine's computing resources (e.g., processing resources, memory resources, and networking resources) to be shared among computing instances (e.g., virtual machines) executed by host machine 1602. A virtual machine can have its own operating system (called a guest operating system), which may be the same as or different from the host machine's OS. The operating system of a virtual machine executed by a host machine may be the same as or different from the operating system of another virtual machine executed by the same host machine. Thus, a hypervisor allows multiple operating systems to run side by side with each other while sharing the same computing resources of the host machine. The host machines shown in Figure 16 may have the same type of hypervisor or different types of hypervisors.

[0196] A compute instance can be a virtual machine instance or a bare metal instance. In Figure 16, compute instance 1668 on host machine 1602 and compute instance 1674 on host machine 1608 are examples of virtual machine instances. Host machine 1606 is an example of a bare metal instance provided to a customer.

[0197] In certain examples, an entire host machine may be provisioned for a single customer, and all of the one or more compute instances (either virtual machines or bare metal instances) hosted by that host machine belong to that same customer. In other examples, a host machine may be shared among multiple customers (i.e., multiple tenants). In such a multi-tenancy scenario, the host machine may host virtual machine compute instances belonging to different customers. These compute instances may be members of different VCNs for different customers. In certain embodiments, bare metal compute instances are hosted by bare metal servers without a hypervisor. When a bare metal compute instance is provisioned, a single customer or tenant maintains control of the physical CPU, memory, and network interfaces of the host machine hosting that bare metal instance, and the host machine is not shared with other customers or tenants.

[0198] As described above, each compute instance that is part of a VCN is associated with a VNIC that enables the compute instance to be a member of a subnet of the VCN. The VNIC associated with a compute instance facilitates communication of packets or frames to and from the compute instance. When a compute instance is created, a VNIC is associated with the compute instance. In particular embodiments, for a compute instance executed by a host machine, the VNIC associated with the compute instance is executed by an NVD connected to the host machine. For example, in FIG. 16 , host machine 1602 executes virtual machine compute instance 1668 associated with VNIC 1676, which is executed by NVD 1610 connected to host machine 1602. As another example, bare metal instance 1672 hosted by host machine 1606 is associated with VNIC 1680, which is executed by NVD 1612 connected to host machine 1606. As yet another example, the VNIC 1684 is associated with a compute instance 1674 executed by the host machine 1608 , and the VNIC 1684 is executed by the NVD 1612 connected to the host machine 1608 .

[0199] For compute instances hosted by a host machine, the NVD connected to that host machine also runs VCN VRs corresponding to the VCNs of which the compute instances are members. For example, in the embodiment shown in Figure 16, NVD 1610 runs VCN VR 1677 corresponding to the VCN of which compute instance 1668 is a member. NVD 1612 may also run one or more VCN VRs 1683 corresponding to the VCNs corresponding to the compute instances hosted by host machines 1606 and 1608.

[0200] A host machine may include one or more network interface cards (NICs) that allow the host machine to be connected to other devices. The NICs on a host machine may provide one or more ports (or interfaces) that allow the host machine to be communicatively connected to other devices. For example, one or more ports (or interfaces) provided on a host machine and on an NVD may be used to connect the host machine to the NVD. A host machine may also be connected to other devices, such as another host machine.

[0201] For example, in FIG. 16, host machine 1602 is connected to NVD 1610 using link 1620 extending between port 1634 provided by NIC 1632 of host machine 1602 and port 1636 of NVD 1610. Host machine 1606 is connected to NVD 1612 using link 1624 extending between port 1646 provided by NIC 1644 of host machine 1606 and port 1648 of NVD 1612. Host machine 1608 is connected to NVD 1612 using link 1624 extending between port 1646 provided by NIC 1644 of host machine 1606 and port 1648 of NVD 1612. The NVD 1612 is connected to the NVD 1612 using a link 1626 extending between a port 1652 provided by the NVD 1612 and a port 1654 of the NVD 1612 .

[0202] The NVDs are in turn connected via communication links to top-of-rack (TOR) switches that are connected to a physical network 1618 (also called a switch fabric). In particular embodiments, the links between the host machines and the NVDs and the links between the NVDs and the TOR switches are Ethernet links. For example, in FIG. 16, NVDs 1610 and 1612 are connected to TOR switches 1614 and 1616, respectively, using links 1628 and 1630. In particular embodiments, links 1620, 1624, 1626, 1628, and 1630 are Ethernet links. The collection of host machines and NVDs connected to a TOR may also be referred to as a rack.

[0203] The physical network 1618 provides a communications fabric that allows the TOR switches to communicate with each other. The physical network 1618 can be a multi-tier network. In a particular implementation, the physical network 1618 is a multi-tier Clos network of switches, with the TOR switches 1614 and 1616 representing leaf-level nodes of the multi-tier and multi-node physical switching network 1618. Different Clos network configurations are possible, including, but not limited to, 2-tier networks, 3-tier networks, 4-tier networks, 5-tier networks, and generally "n"-tier networks. An example of a Clos network is shown in FIG. 19 and described below.

[0204] A variety of different connection configurations are possible between host machines and NVDs, including one-to-one, many-to-one, and one-to-many configurations. In a one-to-one implementation, each host machine is connected to its own separate NVD. For example, in FIG. 16, host machine 1602 is connected to NVD 1610 via NIC 1632 on host machine 1602. In a many-to-one configuration, multiple host machines are connected to a single NVD. For example, in FIG. 16, host machines 1606 and 1608 are connected to the same NVD 1612 via NICs 1644 and 1650, respectively.

[0205] In a one-to-many configuration, one host machine is connected to multiple NVDs. FIG. 17 shows an example of a CSPI 1700 in which a host machine is connected to multiple NVDs. As shown in FIG. 17, a host machine 1702 includes a network interface card (NIC) 1704 with multiple ports 1706 and 1708. The host machine 1700 is connected to a first NVD 1710 via port 1706 and link 1720, and to a second NVD 1712 via port 1708 and link 1722. Ports 1706 and 1708 may be Ethernet ports, and links 1720 and 1722 between the host machine 1702 and the NVDs 1710 and 1712 may be Ethernet links. The NVD 1710 is connected to a first TOR switch 1714, and the NVD 1712 is connected to a second TOR switch 1716. The links between the NVDs 1710 and 1712 and the TOR switches 1714 and 1716 may be Ethernet links. The TOR switches 1714 and 1716 represent layer-0 switching devices in a multi-tier physical network 1718.

[0206] The arrangement shown in Figure 17 provides two separate physical network paths from the physical switch network 1718 to the host machine 1702: a first path traversing the TOR switch 1714 to the NVD 1710 and the host machine 1702, and a second path traversing the TOR switch 1716 to the NVD 1712 and the host machine 1702. These separate paths provide improved availability (called high availability) for the host machine 1702. If there is a problem with one path (e.g., a link on one path goes down) or a problem with a device (e.g., a particular NVD is not functioning), the host machine 1702 can be easily accessed. If the other path is not available, the other path may be used for communication between the host machine 1702.

[0207] In the configuration shown in Figure 17, the host machine is connected to two different NVDs using two different ports provided by the host machine's NIC. In other embodiments, the host machine may include multiple NICs that allow the host machine to connect to multiple NVDs.

[0208] Referring again to Figure 16, an NVD is a physical device or component that performs one or more network and / or storage virtualization functions. An NVD may be any device that has one or more processing units (e.g., a CPU, a network processing unit (NPU), an FPGA, a packet processing pipeline, etc.), memory including cache, and ports. Various virtualization functions may be performed by software / firmware executed by one or more processing units of the NVD.

[0209] The NVD can be implemented in a variety of different forms. For example, in a particular embodiment, the NVD is implemented as an interface card called a smart NIC or intelligent NIC with an embedded processor. The smart NIC is a separate device from the NIC on the host machine. In FIG. 16, the NVD 1610 may be implemented as a smart NIC connected to the host machine 1602, and the NVD 1612 may be implemented as a smart NIC connected to the host machines 1606 and 1608.

[0210] However, a smart NIC is merely one implementation of an NVD. Various other implementations are possible. For example, in some other implementations, the NVD or one or more functions performed by the NVD may be incorporated into or performed by one or more host machines, one or more TOR switches, and other components of CSPI1600. For example, the NVD may be embodied in a host machine, and the functions performed by the NVD may be performed by the host machine. As another example, the NVD may be part of a TOR switch, or a TOR switch may be configured to perform the functions performed by the NVD that enable the TOR switch to perform various complex packet transformations used in public clouds. A TOR that performs the functions of an NVD may also be referred to as a smart TOR. In yet other implementations where customers are provided with virtual machine (VM) instances rather than bare metal (BM) instances, the functions provided by the NVD may be implemented within the hypervisor of the host machine. In some other implementations, some of the NVD's functions may be offloaded to a centralized service running on a set of host machines.

[0211] In certain embodiments, such as when implemented as a smart NIC as shown in FIG. 16, an NVD may include multiple physical ports that allow the NVD to connect to one or more host machines and one or more TOR switches. Ports on an NVD may be classified as host-facing ports (also called "south ports") or network-facing or TOR-facing ports (also called "north ports"). Host-facing ports of an NVD are ports used to connect the NVD to host machines. Examples of host-facing ports in FIG. 16 include port 1636 on NVD 1610 and ports 1648 and 1654 on NVD 1612. Network-facing ports of an NVD are ports used to connect the NVD to TOR switches. Examples of network-facing ports in FIG. 16 include port 1656 on NVD 1610 and port 1658 on NVD 1612. As shown in Figure 16, the NVD 1610 is connected to the TOR switch 1614 using a link 1628 that extends from port 1656 of the NVD 1610 to the TOR switch 1614. Similarly, the NVD 1612 is connected to the TOR switch 1616 using a link 1628 that extends from port 1658 of the NVD 1612 to the TOR switch 1616. It is connected to the TOR switch 1616 using link 1630 .

[0212] The NVD may receive packets and frames from a host machine (e.g., packets and frames generated by a compute instance hosted by the host machine) via a host-facing port, perform any necessary packet processing, and then forward the packets and frames to a TOR switch via the NVD's network-facing port. The NVD may receive packets and frames from a TOR switch via the NVD's network-facing port, perform any necessary packet processing, and then forward the packets and frames to a host machine via the NVD's host-facing port.

[0213] In certain embodiments, there may be multiple ports and associated links between the NVD and the TOR switch. These ports and links may be aggregated to form a link aggregator group (called a LAG) of multiple ports or links. Link aggregation allows multiple physical links between two endpoints (e.g., between the NVD and the TOR switch) to be treated as a single logical link. All physical links within a given LAG may operate at the same speed and in full-duplex mode. LAGs help increase the bandwidth and reliability of the connection between two endpoints. If one of the physical links in a LAG goes down, traffic is dynamically and transparently reassigned to one of the other physical links in the LAG. The aggregated physical link achieves higher bandwidth than each individual link. Multiple ports associated with a LAG are treated as a single logical port. Traffic can be load-balanced across the multiple physical links in a LAG. One or more LAGs may be configured between two endpoints. The two endpoints may be between the NVD and the TOR switch, between a host machine and the NVD, etc.

[0214] The NVD implements or performs network virtualization functions. These functions are performed by software / firmware executed by the NVD. Examples of network virtualization functions include, but are not limited to, packet encapsulation and decapsulation functions, functions for creating VCN networks, functions for enforcing network policies such as VCN security list (firewall) functions, functions for facilitating routing and forwarding of packets to and from compute instances within the VCN, etc. In particular embodiments, upon receiving a packet, the NVD is configured to execute a packet processing pipeline to process the packet and determine how to forward or route the packet. As part of this packet processing pipeline, the NVD may execute one or more virtual functions associated with the overlay network, such as running VNICs associated with compute instances in the VCN, running virtual routers (VRs) associated with the VCN, encapsulating and decapsulating packets to facilitate forwarding or routing within the virtual network, running specific gateways (e.g., local peering gateways), implementing security lists, network security groups, network address translation (NAT) functions (e.g., public IP to private IP translation on a per-host basis), throttling functions, and other functions.

[0215] In particular embodiments, the packet processing data path within the NVD may include multiple packet pipelines, each of which may consist of a series of packet transformation stages. In a particular implementation, upon receiving a packet, the packet is parsed and classified into a pipeline. The packet is then processed linearly from stage to stage until the packet is dropped or sent out through an interface of the NVD. These stages provide basic functional packet processing building blocks (e.g., header validation, throttling, inserting new Layer 2 headers, L4 firewalling, VCN encapsulation / decapsulation, etc.), and new stages can be configured by composing existing stages. New pipelines can be built, and new functionality can be added by creating new stages and inserting them into existing pipelines.

[0216] The NVD may perform both control plane and data plane functions corresponding to the VCN's control plane and data plane. Control plane functions include functions used to configure the network (e.g., setting up routes and route tables, configuring VNICs, etc.) that control how data is forwarded. In certain embodiments, a VCN control plane is provided that centrally computes all overlay-to-substrate mappings and publishes them to the NVD and to virtual network edge devices such as various gateways, such as DRGs, SGWs, and IGWs. Firewall rules may also be published using the same mechanism. In certain embodiments, the NVD retrieves only the mappings that are relevant to the NVD. Data plane functions include functions for actually routing / forwarding packets based on the configuration set up using the control plane. The VCN data plane is realized by encapsulating customer network packets before they traverse the backbone network. The encapsulation / decapsulation functions are realized on the NVD. In certain embodiments, the NVD is configured to intercept all network packets entering and leaving host machines and perform network virtualization functions.

[0217] As described above, the NVD performs various virtualization functions, including VNICs and VCN VRs. The NVD may execute VNICs associated with compute instances hosted by one or more host machines connected to the VNICs. For example, as shown in FIG. 16, NVD 1610 executes functions for VNIC 1676 associated with compute instance 1668 hosted by host machine 1602 connected to NVD 1610. As another example, NVD 1612 executes VNIC 1680 associated with bare metal compute instance 1672 hosted by host machine 1606 and VNIC 1684 associated with compute instance 1674 hosted by host machine 1608. The host machines may host compute instances belonging to different VCNs that belong to different customers, and the NVDs connected to the host machines may execute VNICs (i.e., perform functions related to the VNICs) corresponding to the compute instances.

[0218] NVDs also run VCN virtual routers corresponding to the VCNs of the compute instances. For example, in the embodiment shown in FIG. 16, NVD 1610 runs VCN VR 1677 corresponding to the VCN to which compute instance 1668 belongs. NVD 1612 runs one or more VCN VRs 1683 corresponding to one or more VCNs to which compute instances hosted by host machines 1606 and 1608 belong. In particular embodiments, the VCN VRs corresponding to that VCN are run by all NVDs connected to a host machine that hosts at least one compute instance belonging to that VCN. If a host machine hosts compute instances that belong to different VCNs, the NVDs connected to that host machine may run VCN VRs corresponding to those different VCNs.

[0219] In addition to VNICs and VCN VRs, an NVD may include one or more hardware components that run various software (e.g., daemons) and facilitate various network virtualization functions performed by the NVD. For simplicity, these various components are grouped as "packet processing components" shown in FIG. 16. For example, NVD 1610 includes packet processing component 1686, and NVD 1612 includes packet processing component 1688. For example, the packet processing components of an NVD may be configured to process packets from the NVD's ports and hardware interfaces. The NVD may include a packet processor configured to monitor all packets received by and communicated using the NVD by interacting with the NVD interface and store network information. The network information may include, for example, network flow information identifying different network flows processed by the NVD and per-flow information (e.g., per-flow statistics). In particular embodiments, the network flow information may be stored on a per-VNIC basis. The packet processor may implement stateful NAT and L4 firewall (FW) functions in addition to performing per-packet operations. As another example, the packet processing component may include a replication agent configured to replicate information stored by the NVD to one or more different replication target stores. As yet another example, the packet processing component may include a logging agent configured to perform the NVD's logging functions. The packet processing component may also include software for monitoring the performance and health of the NVD, and possibly the state and health of other components connected to the NVD.

[0220] FIG. 15 illustrates components of an exemplary virtual network or overlay network, including a VCN, subnets within the VCN, compute instances deployed on the subnets, VNICs associated with the compute instances, VRs for the VCN, and a set of gateways configured for the VCN. The overlay components illustrated in FIG. 15 may be executed or hosted by one or more of the physical components illustrated in FIG. 16. For example, compute instances within a VCN may be executed or hosted by one or more host machines illustrated in FIG. 16. For compute instances hosted by a host machine, the VNICs associated with the compute instance are typically executed by an NVD connected to the host machine (i.e., the VNIC functionality is provided by an NVD connected to the host machine). The VCN VR functionality is performed by all NVDs connected to the host machines that host or execute compute instances that are part of the VCN. The gateways associated with a VCN may be executed by one or more different types of NVDs. For example, certain gateways may be executed by smart NICs, while other gateways may be executed by one or more host machines or other implementations of NVDs.

[0221] As described above, a compute instance within a customer VCN may communicate with a variety of different endpoints, which may be in the same subnet as the source compute instance, in a different subnet but within the same VCN as the source compute instance, or may have endpoints outside the VCN of the source compute instance. These communications are facilitated using VNICs associated with the compute instances, VCN VRs, and gateways associated with the VCN.

[0222] For communication between two compute instances on the same subnet within a VCN, the communication is facilitated using VNICs associated with the source and destination compute instances. The source and destination compute instances may be hosted by the same host machine or by different host machines. Packets outgoing from the source compute instance may be forwarded from the host machine hosting the source compute instance to an NVD connected to that host machine. On the NVD, the packet is processed using a packet processing pipeline, which may include running the VNIC associated with the source compute instance. Because the packet's destination endpoint is in the same subnet, running the VNIC associated with the source compute instance forwards the packet to the NVD running the VNIC associated with the destination compute instance, which then processes the packet and forwards it to the destination compute instance. The VNICs associated with the source and destination compute instances may be configured to run on the same host machine (e.g., when both the source and destination compute instances are running on the same host machine). VNICs may run on the same NVD (e.g., if they are hosted by the same VNIC), or on different NVDs (e.g., if the source and destination compute instances are hosted by different host machines connected to different NVDs). A VNIC may use routing / forwarding tables stored by the NVD to determine the next hop for a packet.

[0223] When communicating a packet from a compute instance in a subnet to an endpoint in a different subnet within the same VCN, the packet originating from the source compute instance is communicated from the host machine hosting the source compute instance to the NVD connected to that host machine. On the NVD, the packet is processed using a packet processing pipeline, which may include running one or more VNICs and VRs associated with the VCN. For example, as part of the packet processing pipeline, the NVD executes or invokes a function corresponding to the VNIC associated with the source compute instance (also referred to as executing the VNIC). The function executed by the VNIC may include noting the VLAN tag on the packet. Because the packet's destination is outside the subnet, a VCN VR function is then invoked and executed by the NVD. The VCN VR then routes the packet to the NVD executing the VNIC associated with the destination compute instance. The VNIC associated with the destination compute instance then processes the packet and forwards the packet to the destination compute instance. The VNICs associated with the source compute instance and the destination compute instance may run on the same NVD (e.g., if both the source compute instance and the destination compute instance are hosted by the same host machine) or may run on different NVDs (e.g., if the source compute instance and the destination compute instance are hosted by different host machines connected to different NVDs).

[0224] If the packet's destination is outside the VCN of the source compute instance, the packet leaving the source compute instance is communicated from the host machine hosting the source compute instance to the NVD connected to that host machine. The NVD runs the VNIC associated with the source compute instance. Because the packet's destination endpoint is outside the VCN, the packet is then processed by the VCN VR for that VCN. The NVD invokes a VCN VR function, which results in the packet being forwarded to an NVD running the appropriate gateway associated with the VCN. For example, if the destination is an endpoint in a customer's on-premises network, the packet may be forwarded by the VCN VR to an NVD running the DRG gateway configured for the VCN. The VCN VR may run on the same NVD as the NVD running the VNIC associated with the source compute instance, or it may be run by a different NVD. The gateway may be run by the NVD, which may be a smart NIC, a host machine, or another NVD implementation. The packet is then processed by the gateway and forwarded to the next hop, which facilitates communication of the packet to the intended destination endpoint. 16, a packet outgoing from compute instance 1668 may be communicated from host machine 1602 to NVD 1610 via link 1620 (using NIC 1632). On NVD 1610, VNIC 1676 is invoked because VNIC 1676 is the VNIC associated with source compute instance 1668. VNIC 1676 is configured to examine encapsulation information within the packet, determine a next hop for forwarding the packet to facilitate communication of the packet to its intended destination endpoint, and then forward the packet to the determined next hop.

[0225] Compute instances deployed on a VCN can communicate with a variety of different endpoints. These endpoints are hosted by CSPI1600. The endpoints hosted by CSPI1600 may include instances within the same VCN or within other VCNs, which may be the customer's VCN or a VCN not belonging to the customer. Communication between endpoints hosted by CSPI1600 may be performed over physical network 1618. Compute instances may also communicate with endpoints not hosted by CSPI1600 or external to CSPI1600. Examples of these endpoints include endpoints within a customer's on-premises network or data center, or public endpoints accessible over a public network such as the Internet. Communication with endpoints external to CSPI1600 may be performed over a public network (e.g., the Internet) (not shown in FIG. 16 ) or a private network (not shown in FIG. 16 ) using various communication protocols.

[0226] The architecture of CSPI1600 shown in FIG. 16 is exemplary only and is not intended to be limiting. Variations, substitutions, and modifications are possible in alternative embodiments. For example, in some implementations, CSPI1600 may have more or fewer systems or components than shown in FIG. 16, may combine two or more systems, or may have a different configuration or arrangement of systems. The systems, subsystems, and other components shown in FIG. 16 may be implemented in software (e.g., code, instructions, programs) executed by one or more processing units (e.g., processors, cores) of the respective systems, using hardware, or a combination thereof. The software may be stored on a non-transitory storage medium (e.g., on a memory device).

[0227] FIG. 18 illustrates connectivity between host machines and an NVD to provide I / O virtualization to support multitenancy, according to a particular embodiment. As shown in FIG. 18, a host machine 1802 runs a hypervisor 1804 that provides a virtualized environment. The host machine 1802 runs two virtual machine instances: VM1 1806 belonging to customer / tenant #1 and VM2 1808 belonging to customer / tenant #2. The host machine 1802 includes a physical NIC 1810 connected to an NVD 1812 via link 1814. Each of the compute instances is attached to a VNIC run by the NVD 1812. In the embodiment of FIG. 18, VM1 1806 is attached to VNIC-VM1 1820, and VM2 1808 is attached to VNIC-VM2 1822.

[0228] As shown in FIG. 18, NIC 1810 includes two logical NICs: logical NIC A 1816 and logical NIC B 1818. Each virtual machine is attached to and configured to operate with its own logical NIC. For example, VM1 1806 is attached to logical NIC A 1816, and VM2 1808 is attached to logical NIC B 1818. Although host machine 1802 contains only one physical NIC 1810 shared by multiple tenants, the logical NICs allow each tenant's virtual machine to believe it has its own host machine and NIC.

[0229] In particular embodiments, each logical NIC is assigned its own VLAN ID. Thus, logical NIC A 1816 for Tenant #1 is assigned a particular VLAN ID, and logical NIC B 1818 for Tenant #2 is assigned a different VLAN ID. When a packet is communicated from VM1 1806, the tag assigned to Tenant #1 is attached to the packet by the hypervisor, and the packet is then communicated from host machine 1802 to NVD 1812 over link 1814. Similarly, when a packet is communicated from VM2 1808, the tag assigned to Tenant #2 is attached to the packet by the hypervisor. The tag 1826 is attached to the packet, which is then communicated from host machine 1802 to NVD 1812 via link 1814. Thus, packets 1824 communicated from host machine 1802 to NVD 1812 have an associated tag 1826 that identifies the particular tenant and associated VM. On the NVD, for packets 1824 received from host machine 1802, the tag 1826 associated with the packet is used to determine whether the packet should be processed by VNIC-VM1 1820 or VNIC-VM2 1822. The packet is then processed by the corresponding VNIC. The configuration shown in FIG. 18 allows each tenant's compute instance to believe it has its own host machine and NIC. The setup shown in FIG. 18 provides I / O virtualization to support multi-tenancy.

[0230] FIG. 19 illustrates a simplified block diagram of a physical network 1900 according to a particular embodiment. The embodiment illustrated in FIG. 19 is constructed as a Clos network. A Clos network is a particular type of network topology designed to provide connection redundancy while maintaining high bisection bandwidth and maximum resource utilization. A Clos network is a type of non-blocking, multi-stage or multi-tier switching network, where the number of stages or tiers can be 2, 3, 4, 5, etc. The embodiment illustrated in FIG. 19 is a three-tier network, including tiers 1, 2, and 3. TOR switch 1904 represents a tier-0 switch in the Clos network. One or more NVDs are connected to a TOR switch. A tier-0 switch is also referred to as an edge device of the physical network. A tier-0 switch is connected to a tier-1 switch, also referred to as a leaf switch. In the embodiment illustrated in FIG. 19, a set of “n” tier-0 TOR switches are connected to a set of “n” tier-1 switches, together forming a pod. Each tier-0 switch in a pod is interconnected to all tier-1 switches within that pod, but there is no switch connectivity between pods. In a specific implementation, the two pods are referred to as blocks. Each block is served by or connected to a set of "n" layer-2 switches (sometimes called spine switches). There may be several blocks in a physical network topology. The layer-2 switches are then connected to "n" layer-3 switches (sometimes called super-spine switches). Communication of packets over the physical network 1900 is typically performed using one or more layer-3 communication protocols. Typically, all layers of the physical network except the TOR layer are n-way redundant, thus enabling high availability. Policies may be specified for pods and blocks to control the visibility of switches in the physical network to each other to enable scaling of the physical network.

[0231] A characteristic of Clos networks is that the maximum hop count to reach from one tier-0 switch to another tier-0 switch (or from an NVD connected to a tier-0 switch to another NVD connected to a tier-0 switch) is fixed. For example, in a three-tier Clos network, a packet requires a maximum of seven hops to reach from one NVD to another, with the source and destination NVDs connected at the leaf layers of the Clos network. Similarly, in a four-tier Clos network, a packet requires a maximum of nine hops to reach from one NVD to another, with the source and destination NVDs connected at the leaf layers of the Clos network. Thus, the Clos network architecture maintains constant latency throughout the network, which is important for intra- and inter-datacenter communications. Clos topologies are horizontally scalable and cost-effective. The bandwidth / throughput capacity of the network can be easily increased by adding more switches (e.g., more leaf switches and spine switches) at various tiers and by increasing the number of links between switches in adjacent tiers.

[0232] In certain embodiments, each resource in the CSPI is assigned a unique identifier called a Cloud Identifier (CID). This identifier is included as part of the resource's information and can be used to manage the resource, for example, via a console or through an API. An exemplary syntax for a CID is: ocid1.<RESOURCE TYPE> . <realm>.[REGION][.FUTURE USE].<UNIQUE ID> In the formula, "ocid1" is a literal string that indicates the version of the CID.

[0233] "resource type" is the type of resource (for example, instance, volume, V) CN, subnet, user, group, etc.

[0234] "realm" is the realm in which the resource resides. An example value is "c1 " for the government cloud realm, "c2" for the federal government cloud realm, or "c3" for the federal government cloud realm, etc. Each realm may have its own domain name.

[0235] "region" is the region the resource is in. This part may be blank if no region applies to the resource.

[0236] "Future use" is reserved for future use. The "unique ID" is the unique part of the ID. The format is specific to the resource or service. May vary by type.

[0237] Although specific embodiments of the present disclosure have been described, various modifications, alternatives, alternative configurations, and equivalents are encompassed within the scope of the present disclosure. The embodiments of the present disclosure are not limited to operation in a particular specific data processing environment, but can freely operate in multiple data processing environments. Additionally, while the embodiments of the present disclosure have been described using a particular sequence of transactions and steps, it should be apparent to those skilled in the art that the scope of the present disclosure is not limited to the described sequence of transactions and steps. Various features and aspects of the above-described embodiments may be used individually or jointly.

[0238] Furthermore, while embodiments of the present disclosure have been described using a particular combination of hardware and software, it should be recognized that other combinations of hardware and software are within the scope of the present disclosure. Embodiments of the present disclosure may be implemented exclusively in hardware, exclusively in software, or using a combination thereof. The various processes described herein may be implemented on the same processor or any combination of different processors. Thus, when a component or module is described as being configured to perform a particular operation, such configuration may be achieved, for example, by designing electronic circuitry to perform that operation, by programming a programmable electronic circuit (such as a microprocessor) to perform that operation, or any combination thereof. Processes may communicate using a variety of techniques, including, but not limited to, conventional techniques for inter-process communication; different pairs of processes may use different techniques, or the same pair of processes may use different techniques at different times.

[0239] Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. It will be apparent, however, that additions, subtractions, deletions, and other modifications and changes may be made thereto without departing from the broader spirit and scope of the appended claims. Thus, while particular embodiments of the present disclosure have been described, they are not intended to be limiting. Various modifications and equivalents are intended to fall within the scope of the appended claims. can be.

[0240] The use of the words "a," "an," and "the," and similar referents in the context of describing the disclosed embodiments (particularly in the context of the appended claims), should be construed to include both the singular and the plural, unless otherwise stated herein or clearly contradicted by context. The words "comprising," "having," "including," and "containing" should be construed as open-ended (i.e., meaning "including, but not limited to"), unless otherwise stated. The word "connected" should be construed as partly or wholly contained within, attached to, or coupled to, even if there is something intervening. The recitation of ranges of values ​​herein is merely intended as a shorthand way of referring individually to each individual value contained within the range, unless otherwise stated herein, and each individual value is incorporated herein as if set forth individually herein. All methods described herein can be performed in any suitable order, unless otherwise stated herein or clearly contradicted by context. Any examples provided herein, or the use of exemplary language (e.g., "such as"), are intended merely to further clarify embodiments of the present disclosure and do not limit the scope of the disclosure unless specifically claimed. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the disclosure.

[0241] Disjunctive language, such as the phrase "at least one of X, Y, or Z," is intended to be understood within the context in which it is generally used to indicate that an item, term, etc. can be either X, Y, or Z, or any combination thereof (e.g., X, Y, and / or Z), unless specifically stated otherwise. Thus, such disjunctive language is generally not intended to, and should not, imply that a particular embodiment requires that at least one of X, at least one of Y, or at least one of Z, respectively, be present.

[0242] Preferred embodiments of the present disclosure are described herein, including the best mode known for carrying out the disclosure. Variations of these preferred embodiments will become apparent to those skilled in the art upon reading the above description. Those skilled in the art will be able to adapt such variations as appropriate, and the present disclosure may be practiced in ways other than as specifically described herein. Accordingly, this disclosure includes all modifications and equivalents of the subject matter recited in the claims appended hereto as permitted by applicable law. Moreover, any combination of the above-described elements in all possible variations thereof is encompassed by the present disclosure unless otherwise indicated herein.

[0243] All references cited in this specification, including publications, patent applications, and patents, are herein incorporated by reference to the same extent as if each individual reference were individually and specifically indicated to be incorporated by reference and were set forth in its entirety herein.

[0244] While the foregoing specification describes aspects of the disclosure with reference to specific embodiments thereof, those skilled in the art will recognize that the disclosure is not limited thereto. Various features and aspects of the above-described disclosure may be used individually or jointly. Moreover, the embodiments can be utilized in any number of environments and applications beyond those described herein without departing from the broader spirit and scope of the specification. Accordingly, the specification and drawings should be regarded as illustrative rather than restrictive.< / realm>

Claims

1. 1. A system comprising: a network head end device, the network head end device comprising: receiving a first key provisioned by a customer; receiving a first data packet transmitted from the customer device; and configured to decrypt the first data packet using the first key to obtain information, the system further comprising: a network virtualization device, the network virtualization device comprising: receiving the information from the network head end device after the first data packet is decoded; Verifying that the information should be sent to a virtual machine within a virtual cloud network; Verifying that data within the virtual cloud network is configured to be encrypted; encrypting the information using a second key to generate a second data packet; The system is configured to route the second data packet to the virtual machine.

2. 10. The system of claim 1, wherein the system is maintained by a host, and the host does not have access to the first key or the second key.

3. 3. The system of claim 1, wherein the network head end device is configured to be a termination point of an Internet Protocol Security (IPSec) tunnel formed between the network head end device and a customer device.

4. The system of any one of claims 1 to 3, wherein the first data packet is routed through the public Internet.

5. The system of any one of claims 1 to 3, wherein the first data packet is routed through a set of private links without using any link in the public Internet.

6. The system of any one of claims 1 to 5, wherein the network virtualization device supports instances of the virtual machines in the virtual cloud network.

7. The system of any one of claims 1 to 6, wherein the network headend device is a network interface card.

8. The system of any one of claims 1 to 6, wherein the network head-end device is on a network interface card, and the network virtualization device is part of the network interface card.

9. The system of any one of claims 1 to 6, wherein the network head-end device and the network virtualization device are located in the same server.

10. 7. The method of claim 1, wherein the network head end device is dedicated to the customer so that other customers of the host do not use the network head end device.

10. The system of claim 1.

11. The system of any preceding claim, wherein the network virtualization device communicates with a key management service to obtain the second key.

12. The system of any one of claims 1 to 11, wherein the customer provisions the first key at the network head-end device using a key management service.

13. The system of any one of claims 1 to 12, wherein the network head end device is a first network head end device, and the system further includes a second network head end device configured to decrypt data from the customer.

14. the network virtualization device is a first network virtualization device; the virtual cloud network is a first virtual cloud network; the system further includes a second network virtualization device; 14. The system of claim 1, wherein the second network virtualization device is configured to receive data from the network head-end device and encrypt the data received from the network head-end device using a third key for a second virtual cloud network.

15. 15. The system of claim 14, wherein the first network virtualization device and the second network virtualization device are part of the same network interface card.

16. The system of any one of claims 1 to 15, wherein the network head end device is configured to receive the first key from the customer after a host authenticates the customer.

17. 1. A method comprising: receiving a first key provisioned by a customer using a network headend device; receiving, at the network headend device, a first data packet transmitted from the customer device; decrypting the first data packet using the first key to obtain information; receiving the information from the network head-end device using a network virtualization device; Verifying that the information should be sent to a virtual machine in a virtual cloud network; encrypting the information at the network virtualization device using a second key to generate a second data packet; and routing the second data packet to the virtual machine.

18. 20. The method of claim 17, wherein the method includes verifying that data in the virtual cloud network is configured to be encrypted before encrypting the information using the second key.

19. A non-transitory computer that stores multiple instructions that can be executed by one or more processors. a data-readable memory, the plurality of instructions including instructions that, when executed by the one or more processors, cause the one or more processors to perform a process, the process comprising: receiving a first key provisioned by a customer using a network headend device; receiving, at the network headend device, a first data packet transmitted from the customer device; decrypting the first data packet using the first key to obtain information; receiving the information from the network head-end device using a network virtualization device; Verifying that the information should be sent to a virtual machine in a virtual cloud network; encrypting the information at the network virtualization device using a second key to generate a second data packet; and routing the second data packet to the virtual machine.

20. 20. The non-transitory computer-readable memory of claim 19, wherein the plurality of instructions further comprise instructions that, when executed by the one or more processors, cause the one or more processors to perform a process including receiving the first data packet over a public internet.

Images