Networking Overview

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.

Tip

Watch a video introduction to the service.

Networking Components

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.
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.
VNIC: 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 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.
IPV6: 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, and Remote VCN Peering using a Legacy DRG.
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 a Legacy DRG.
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.
CIDR NOTATION: A compact method for specifying IP addresses or address ranges and network masks. For example, using IPv4 a private IP address range of 10.0.0.0/24 represents all addresses between 10.0.0.0 and 10.0.0.255. The /24 represents a subnet mask of 255.255.255.0 because the first 24 bits are masked. IPv6 uses similar notation to for address blocks. For more information, see RFC1817 and RFC1519.

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.

This image shows a VCN with a regional subnet and three AD-specific subnets.

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.

Default Components that Come With Your VCN

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.

Tip

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.

Connectivity Choices

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.

How IP Addresses Are Assigned

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.

Access to the Internet

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.

Tip

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.

Access to Your On-Premises Network

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

You can connect your VCN to another cloud provider by using Site-to-Site VPN with a Libreswan VM as the customer-premises equipment (CPE). For more information, see Access to Other Clouds with Libreswan.

Networking Scenarios

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:

Transit Routing

Scenarios A–C show your on-premises network connected to one or more VCNs by way of a DRG and FastConnect or Site-to-Site VPN, and accessing only the resources in those VCNs.

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 Scenario C mentioned 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.

IP Addresses Reserved for Use by Oracle

Certain IP addresses are reserved for Oracle Cloud Infrastructure use and may not be used in your address numbering scheme.

169.254.0.0/16

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 224.0.0.0 to 239.255.255.255 (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

You can create automation based on state changes for your Oracle Cloud Infrastructure resources by using event types, rules, and actions. For more information, see Overview of Events.

Resource Identifiers

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 (OCI) by using the Console (a browser-based interface), REST API, or OCI CLI. Instructions for using the Console, API, and CLI are included in topics throughout this documentation. 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, and so on. 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.

IAM Policies for Networking

The simplest approach to granting access to Networking is the policy listed in Let network admins manage a cloud network. It covers the cloud network and all the other Networking components (subnets, security lists, route tables, gateways, and so on). To also give network admins the ability to launch instances (to test network connectivity), see Let users launch compute instances.

If you're new to policies, see Getting Started with Policies and Common Policies.

For reference material for writing more detailed policies for Networking, see Details for the Core Services.

Individual Resource-Types

If you'd like, you can write policies that focus on individual resource-types (for example, security lists only) instead of the broader virtual-network-family. The instance-family resource-type also includes several permissions for VNICs, which reside in a subnet but attach to an instance. For more information, see Details for Verb + Resource-Type Combinations and Virtual Network Interface Cards (VNICs).

There's a resource-type called local-peering-gateways that is included within virtual-network-family and includes two other resource-types related to local VCN peering (within region):

local-peering-from
local-peering-to

The local-peering-gateways resource-type covers all permissions related to local peering gateways (LPGs). The local-peering-from and local-peering-to resource-types are for granting permission to connect two LPGs and define a peering relationship within a single region. For more information, see Local Peering using an LPG (VCNs in the Same Tenancy) or Local Peering using an LPG (VCNs in Different Tenancies).

Similarly, there's a resource-type called remote-peering-connections that is included within virtual-network-family and includes two other resource-types related to remote VCN peering (across regions):

remote-peering-from
remote-peering-to

The remote-peering-connections resource-type covers all permissions related to remote peering connections (RPCs). The remote-peering-from and remote-peering-to resource-types are for granting permission to connect two RPCs and define a peering relationship across regions. For more information, see Remote Peering with a Legacy DRG and Remote Peering with an Upgraded DRG.

Nuances of Different Verbs

If you'd like, you can write policies that limit the level of access by using a different policy verb (manage versus use, and so on). If you do, there are some nuances to understand about the policy verbs for Networking.

Be aware that the inspect verb not only returns general information about the cloud network's components (for example, the name and OCID of a security list, or of a route table). It also includes the contents of the component (for example, the actual rules in the security list, the routes in the route table, and so on).

Also, the following types of abilities are available only with the manage verb, not the use verb:

Update (enable/disable) internet-gateways
Update security-lists
Update route-tables
Update dhcp-options
Attach a Dynamic Routing Gateway (DRG) to a Virtual Cloud Network (VCN)
Create an IPSec connection between a DRG and customer-premises equipment (CPE)
Peer VCNs

Important

Each VCN has various components that directly affect the behavior of the network (route tables, security lists, DHCP options, Internet Gateway, and so on). When you create one of these components, you establish a relationship between that component and the VCN, which means you must be allowed in a policy to both create the component and manage the VCN itself. However, the ability to update that component (to change the route rules, security list rules, and so on) does NOT require permission to manage the VCN itself, even though changing that component can directly affect the behavior of the network. This discrepancy is designed to give you flexibility in granting least privilege to users, and not require you to grant excessive access to the VCN just so the user can manage other components of the network. Be aware that by giving someone the ability to update a particular type of component, you're implicitly trusting them with controlling the network's behavior.

For more information about policy verbs, see Policy Basics.

Peering Policies

For policies used in connecting a DRG to VCNs and DRGs in other regions and tenancies, see IAM Policies for Routing Between VCNs.

Limits on Your Networking Components

See Service Limits for a list of applicable limits and instructions for requesting a limit increase.

Oracle Cloud Infrastructure Documentation