This topic gives you links to Oracle Cloud Infrastructure Networking components and typical scenarios for using a VCN.
When you work with Oracle Cloud Infrastructure, one of the first steps is to set up a virtual cloud network (VCN) for your cloud resources. This topic gives you an overview of Oracle Cloud Infrastructure Networking components and typical scenarios for using a VCN.
Watch a video introduction to the service.
The Networking service uses virtual versions of traditional network components you might already be familiar with:
- VIRTUAL CLOUD NETWORK (VCN)
- A virtual, private network that you set up in Oracle data centers. It closely resembles a traditional network, with firewall rules and specific types of communication gateways that you can choose to use. A VCN resides in a single Oracle Cloud Infrastructure region and covers one or more CIDR blocks (IPv4 and IPv6, if enabled). See Allowed VCN Size and Address Ranges. The terms virtual cloud network, VCN, and cloud network are used interchangeably in this documentation. For more information, see VCNs and Subnets.
Subdivisions you define in a VCN (for example, 10.0.0.0/24, 10.0.1.0/24, or 2001:DB8::/64). Subnets contain virtual network interface cards (VNICs), which attach to instances. Each subnet consists of a contiguous range of IP addresses (for IPv4 and IPv6, if enabled) that do not overlap with other subnets in the VCN. You can designate a subnet to exist either in a single availability domain or across an entire region (regional subnets are recommended). Subnets act as a unit of configuration within the VCN: All VNICs in a given subnet use the same route table, security lists, and DHCP options (see the definitions that follow). You can designate a subnet as either public or private when you create it. Private means VNICs in the subnet can't have public IPv4 addresses and internet communication with IPv6 endpoints will be prohibited. Public means VNICs in the subnet can have public IPv4 addresses and internet communication is permitted with IPv6 endpoints. See Access to the Internet.
A virtual network interface card (VNIC), which attaches to an instance and resides in a subnet to enable a connection to the subnet's VCN. The VNIC determines how the instance connects with endpoints inside and outside the VCN. Each instance has a primary VNIC that's created during instance launch and cannot be removed. You can add secondary VNICs to an existing instance (in the same availability domain as the primary VNIC), and remove them as you like. Each secondary VNIC can be in a subnet in the same VCN as the primary VNIC, or in a different subnet that is either in the same VCN or a different one. However, all the VNICs must be in the same availability domain as the instance. For more information, see Virtual Network Interface Cards (VNICs). A VNIC attached to a compute instance and residing in an IPv6-enbled subnet can optionally be assigned an IPv6 address.
- PRIVATE IP
- A private IPv4 address and related information for addressing an instance (for example, a hostname for DNS). Each VNIC has a primary private IP, and you can add and remove secondary private IPs. The primary private IP address on an instance doesn't change during the instance's lifetime and cannot be removed from the instance. For more information, see Private IP Addresses.
- PUBLIC IP
- A public IPv4 address and related information. You can optionally assign a public IP to your instances or other resources that have a private IP. Public IPs can be either ephemeral or reserved. For more information, see Public IP Addresses.
- An IPv6 address and related information. IPv6 addressing is supported for all commercial and government regions. For more information, see IPv6 Addresses.
- DYNAMIC ROUTING GATEWAY (DRG)
- An optional virtual router that you can add to your VCN. It provides a path for private network traffic between your VCN and on-premises network. You can use it with other Networking components and a router in your on-premises network to establish a connection by way of Site-to-Site VPN or Oracle Cloud Infrastructure FastConnect. It can also provide a path for private network traffic between your VCN and another VCN in a different region. For more information, see Access to Your On-Premises Network, Dynamic Routing Gateways (DRGs), and Remote VCN Peering using an RPC.
- INTERNET GATEWAY
- Another optional virtual router that you can add to your VCN for direct internet access. For more information, see Access to the Internet and also Scenario A: Public Subnet.
- NETWORK ADDRESS TRANSLATION (NAT) GATEWAY
- Another optional virtual router that you can add to your VCN. It gives cloud resources without public IP addresses access to the internet without exposing those resources to incoming internet connections. For more information, see Public vs. Private Subnets and also NAT Gateway.
- SERVICE GATEWAY
- Another optional virtual router that you can add to your VCN. It provides a path for private network traffic between your VCN and supported services in the Oracle Services Network (examples: Oracle Cloud Infrastructure Object Storage and Autonomous Database). For example, DB Systems in a private subnet in your VCN can back up data to Object Storage without needing public IP addresses or access to the internet. For more information, see Access to Oracle Services: Service Gateway.
- LOCAL PEERING GATEWAY (LPG)
- Another optional virtual router that you can add to your VCN. It lets you peer one VCN with another VCN in the same region. Peering means the VCNs communicate using private IP addresses, without the traffic traversing the internet or routing through your on-premises network. A given VCN must have a separate LPG for each peering it establishes. For more information, see Local VCN Peering using Local Peering Gateways.
- REMOTE PEERING CONNECTION (RPC)
- A component that you can add to a DRG. It lets you peer one VCN with another VCN in a different region. For more information, see Remote VCN Peering using an RPC.
- ROUTE TABLES
- Virtual route tables for your VCN. They have rules to route traffic from subnets to destinations outside the VCN by way of gateways or specially configured instances. Your VCN comes with an empty default route table, and you can add custom route tables of your own. For more information, see VCN Route Tables.
- SECURITY RULES
- Virtual firewall rules for your VCN. They are ingress and egress rules that specify the types of traffic (protocol and port) allowed in and out of the instances. You can choose whether a given rule is stateful or stateless. For example, you 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. To implement security rules, you can use network security groups or security lists. A network security group consists of a set of security rules that apply only to the resources in that group. Contrast this with a security list, where the rules apply to all the resources in any subnet that uses the list. Your VCN comes with a default security list with default security rules. For more information, see Security Rules.
- DHCP OPTIONS
- Configuration information that is automatically provided to the instances when they boot up. For more information, see DHCP Options.
Allowed VCN Size and Address Ranges
A VCN covers one or more IPv4 CIDR blocks or IPv6 prefixes of your choice. The allowable VCN size range is /16 to /30. Example: 10.0.0.0/16. The Networking service reserves the first two IP addresses and the last one in each subnet's CIDR. You can enable IPv6 for your VCNs when you create them, or you can enable IPv6 on existing IPv4-only VCNs. If you decide to use an Oracle-allocated IPv6 prefix, you always receive a /56. Alternately, you can import your own BYOIP IPv6 prefix from which you can assign any prefix of /64 or larger to a VCN, or you can assign a ULA prefix of /64 or larger. GUA ranges can be up to 2000::/3 and ULA ranges can be up to fc00::/7. IPv6 subnets are always /64 in size.
For your VCN, Oracle recommends using the private IP address ranges specified in RFC 1918 (the RFC recommends 10.0/8 or 172.16/12 but Oracle doesn't support those sizes so use 10.0/16, 172.16/16, and 192.168/16). However, you can use a publicly routable range. Regardless, this documentation uses the term private IP address when referring to IP addresses in your VCN's CIDR. Address ranges that are disallowed are described in IP Addresses Reserved for Use by Oracle. For IPv6-enabled VCNs, Oracle can either allocate a global unicast address /56 prefix or you can create a VCN with a BYOIPv6 prefix.
The VCN's CIDR blocks must not overlap with each other, with CIDRs in your on-premises network, or with the CIDRs of another VCN you peer with. The subnets in a given VCN must not overlap with each other. For reference, here's a CIDR calculator.
IPv6 addressing is supported for all commercial and government regions. For more information, see IPv6 Addresses.
Availability Domains and Your VCN
Your VCN resides in a single Oracle Cloud Infrastructure region. A region can have multiple availability domains to provide isolation and redundancy. For more information, see Regions and Availability Domains.
Originally subnets were designed to cover only one availability domain (AD) in a region. They were all AD-specific, which means the subnet's resources were required to reside in a particular availability domain. Now subnets can be either AD-specific or regional. You choose the type when you create the subnet. Both types of subnets can co-exist in the same VCN. In the following diagram, subnets 1-3 are AD-specific, and subnet 4 is regional.
Aside from the removal of the AD constraint, regional subnets behave the same as AD-specific subnets. Oracle recommends using regional subnets because they're more flexible. They make it easier to efficiently divide your VCN into subnets while also designing for availability domain failure.
When you create a resource such as a compute instance, you choose which availability domain the resource will be in. From a virtual networking standpoint, you must also choose which VCN and subnet the instance will be in. You can either choose a regional subnet, or choose an AD-specific subnet that matches the AD you chose for the instance.
Your VCN automatically comes with these default components:
- Default route table, with no route rules
- Default security list, with default security rules
- Default set of DHCP options, with default values
You can't delete these default components. However, you can change their contents (for example, the rules in the default security list). And you can create your own custom versions of each kind of component in your VCN. There are limits to how many you can create and the maximum number of rules. For more information, see Service Limits.
Each subnet always has these components associated with it:
- One route table
- One or more security lists (for the maximum number, see Service Limits)
- One set of DHCP options
During subnet creation, you can choose which route table, security list, and set of DHCP options the subnet uses. If you don't specify a particular component, the subnet automatically uses the VCN's default component. You can change which components the subnet uses at any time.
Security lists are one way to control traffic in and out of the VCN's resources. You can also use network security groups, which let you apply a set of security rules to a set of resources that all have the same security posture.
You can control whether subnets are public or private, and whether instances get public IP addresses. You can set up your VCN to have access to the internet if you like. You can also privately connect your VCN to public Oracle Cloud Infrastructure services such as Object Storage, to your on-premises network, or to another VCN.
Public vs. Private Subnets
When you create a subnet, by default it's considered public, which means instances in that subnet are allowed to have public IPv4 addresses and internet communication is permitted with IPv6 endpoints. Whoever launches the instance chooses whether it has a public IPv4 address or specifies whether an IPv6 address from the allocated prefix will be assigned. You can override that behavior when creating the subnet and request that it be private, which disallows the use of public IPv4 addresses and internet communication with IPv6 endpoints. Network administrators can therefore ensure that instances in the subnet have no internet access, even if the VCN has a working internet gateway, and security rules and firewall rules allow the traffic.
Each instance has a primary VNIC that's created during instance launch and cannot be removed. You can add secondary VNICs to an existing instance (in the same availability domain as the primary VNIC) and remove them as you like.
Every VNIC has a private IP address from the associated subnet's CIDR. You can choose the particular IP address (during instance launch or secondary VNIC creation), or Oracle can choose it for you. The private IP address does not change during the lifetime of the instance and cannot be removed. You can also add secondary private IPv4 addresses or secondary IPv6 addresses to a VNIC.
If the VNIC is in a public subnet, then each private IP on that VNIC can have a public IPv4 address or IPv6 address assigned to it at your discretion. For IPv4, Oracle chooses the particular IP address. For IPv6, you can specify the IP address. There are two types of public IPs: ephemeral and reserved. An ephemeral public IP exists only for the lifetime of the private IP it's assigned to. In contrast, a reserved public IP exists as long as you want it to. You maintain a pool of reserved public IPs and allocate them to your instances at your discretion. You can move them from resource to resource in a region as you need to.
There are two optional gateways (virtual routers) that you can add to your VCN depending on the type of internet access you need:
- Internet gateway: For resources with public IP addresses that need to be reached from the internet (example: a web server) or need to initiate connections to the internet.
- NAT gateway: For resources without public IP addresses that need to initiate connections to the internet (example: for software updates) but need to be protected from inbound connections from the internet.
Just having an internet gateway alone does not expose the instances in the VCN's subnets directly to the internet. The following requirements must also be met:
- The internet gateway must be enabled (by default, the internet gateway is enabled upon creation).
- The subnet must be public.
The subnet must have a route rule that directs traffic to the internet gateway.
- The subnet must have security list rules that allow the traffic (and each instance's firewall must allow the traffic).
The instance must have a public IP address.
To access public services such as Object Storage from your VCN without the traffic going over the internet, use a service gateway.
Also, notice that traffic through an internet gateway between a VCN and a public IP address that is part of Oracle Cloud Infrastructure (such as Object Storage) is routed without being sent over the internet.
You can also give a subnet indirect access to the internet by setting up an internet proxy in your on-premises network and then connecting that network to your VCN by way of a DRG. For more information, see Access to Your On-Premises Network.
Access to Public Oracle Cloud Infrastructure Services
You can use a service gateway with your VCN to enable private access to public Oracle Cloud Infrastructure services such as Object Storage. For example, DB Systems in a private subnet in your VCN can back up data to Object Storage without needing public IP addresses or access to the internet. No internet gateway or NAT is required. For more information, see Access to Oracle Services: Service Gateway.
There are two ways to connect your on-premises network to Oracle Cloud Infrastructure:
- Site-to-Site VPN: Offers multiple IPSec tunnels between your existing network's edge and your VCN, by way of a DRG that you create and attach to your VCN.
- Oracle Cloud Infrastructure FastConnect: Offers a private connection between your existing network's edge and Oracle Cloud Infrastructure. Traffic does not traverse the internet. Both private peering and public peering are supported. That means your on-premises hosts can access private IPv4 or IPv6 addresses in your VCN as well as regional public IPv4 or IPv6 addresses in Oracle Cloud Infrastructure (for example, Object Storage or public load balancers in your VCN).
You can use one or both types of the preceding connections. If you use both, you can use them simultaneously, or in a redundant configuration. These connections come to your VCN by way of a single DRG that you create and attach to your VCN. Without that DRG attachment and a route rule for the DRG, traffic does not flow between your VCN and on-premises network. At any time, you can detach the DRG from your VCN but maintain all the remaining components that form the rest of the connection. You could then reattach the DRG again, or attach it to another VCN.
Access to Another VCN
You can connect your VCN to another VCN over a private connection that doesn't require the traffic to traverse the internet. In general, this type of connection is referred to as VCN peering. Each VCN must have specific components to enable peering. The VCNs must also have specific IAM policies, route rules, and security rules that permit the connection to be made and the wanted network traffic to flow over the connection. For more information, see Access to Other VCNs: Peering.
Connection to Oracle Cloud Infrastructure Classic
You can set up a connection between your Oracle Cloud Infrastructure environment and Oracle Cloud Infrastructure Classic environment. This connection can facilitate hybrid deployments between the two environments, or migration from Oracle Cloud Infrastructure Classic to Oracle Cloud Infrastructure. For more information, see Access to Oracle Cloud Infrastructure Classic.
Connection to Microsoft Azure
Oracle and Microsoft have created a cross-cloud connection between Oracle Cloud Infrastructure and Microsoft Azure in certain regions. This connection lets you set up cross-cloud workloads without the traffic between the clouds going over the internet. For more information, see Access to Microsoft Azure.
Connection to Other Clouds with Libreswan
This documentation includes a few basic networking scenarios to help you understand the Networking service and generally how the components work together. See these topics:
- Scenario A: Public Subnet
- Scenario B: Private Subnet with a VPN
- Scenario C: Public and Private Subnets with a VPN
The following advanced routing scenarios give your on-premises network access beyond the resources in the connected VCN. Traffic travels from your on-premises network to the DRG, and then transits through the DRG to its destination. See these topics:
- Transit Routing inside a hub VCN: Your on-premises network has access to multiple VCNs in the same region over a single FastConnect private virtual circuit or Site-to-Site VPN. The DRG and attached VCNs are in a hub-and-spoke topology, with the on-premises network connected to the DRG which acts as the hub. The spoke VCNs are peered.
- Private Access to Oracle Services: Your on-premises network has private access to Oracle services in the Oracle Services Network by way of a connected VCN and the VCN's service gateway . The traffic does not go over the internet.
Regions and Availability Domains
Your VCN resides in a single Oracle Cloud Infrastructure region. Each subnet resides in a single availability domain (AD). Availability domains are designed to provide isolation and redundancy in your VCN, as illustrated in Scenario B and C earlier. For example, you could set up your primary set of subnets in a single AD, and then set up a duplicate set of subnets in a secondary AD. The two ADs are isolated from each other in the Oracle data centers, so if one fails, you can easily switch over to the other AD. For more information, see Regions and Availability Domains.
Public IP Address Ranges
For a list of Oracle Cloud Infrastructure public IP ranges, see IP Address Ranges.
Certain IP addresses are reserved for Oracle Cloud Infrastructure use and may not be used in your address numbering scheme.
These addresses are used for iSCSI connections to the boot and block volumes, instance metadata, and other services.
Class D and Class E
All addresses from 220.127.116.11 to 18.104.22.168 (Class D) are prohibited for use in a VCN, they are reserved for multicast address assignments in the IP standards. See RFC 3171 for details.
All addresses from 240.0.0.0 to 255.255.255.255 (Class E) are prohibited for use in a VCN, they are reserved for future use in the IP standards. See RFC 1112, Section 4 for details.
Three IP Addresses in Each Subnet
These addresses consist of:
- The first IP address in the CIDR (the network address)
- The last IP address in the CIDR (the broadcast address)
- The first host address in the CIDR (the subnet default gateway address)
For example, in a subnet with CIDR 192.168.0.0/24, these addresses are reserved:
- 192.168.0.0 (the network address)
- 192.168.0.255 (the broadcast address)
- 192.168.0.1 (the subnet default gateway address)
The remaining addresses in the CIDR (192.168.0.2 to 192.168.0.254) are available for use.
Creating Automation with Events
Most types of Oracle Cloud Infrastructure resources have a unique, Oracle-assigned identifier called an Oracle Cloud ID (OCID). For information about the OCID format and other ways to identify your resources, see Resource Identifiers.
Ways to Access Oracle Cloud Infrastructure
You can access Oracle Cloud Infrastructure using the Console (a browser-based interface) or the REST API. Instructions for the Console and API are included in topics throughout this guide. For a list of available SDKs, see Software Development Kits and Command Line Interface.
To access the Console, you must use a supported browser. To go to the Console sign-in page, open the navigation menu at the top of this page and click Infrastructure Console. You are prompted to enter your cloud tenant, your user name, and your password.
For general information about using the API, see REST APIs.
Authentication and Authorization
Each service in Oracle Cloud Infrastructure integrates with IAM for authentication and authorization, for all interfaces (the Console, SDK or CLI, and REST API).
An administrator in your organization needs to set up groups , compartments , and policies that control which users can access which services, which resources, and the type of access. For example, the policies control who can create new users, create and manage the cloud network, launch instances, create buckets, download objects, etc. For more information, see Getting Started with Policies. For specific details about writing policies for each of the different services, see Policy Reference.
If you’re a regular user (not an administrator) who needs to use the Oracle Cloud Infrastructure resources that your company owns, contact your administrator to set up a user ID for you. The administrator can confirm which compartment or compartments you should be using.