Oracle Cloud Infrastructure Documentation

Overview of Networking

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.

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 a single, contiguous IPv4 CIDR block of your choice. 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 and 10.0.1.0/24). Subnets contain virtual network interface cards (VNICs), which attach to instances. Each subnet consists of a contiguous range of IP addresses that do not overlap with other subnets in the VCN. You can designate a subnet to exist either in a single One or more isolated, fault-tolerant Oracle data centers that host cloud resources such as instances, volumes, and subnets. A region contains one or more availability domains. 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 IP addresses. Public means VNICs in the subnet can have public IP addresses at your discretion. 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 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).
private ip
A private IP 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 IP 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.
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 IPSec 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 (Across Regions).
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 Access to the Internet 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 (Within Region).
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 (Across Regions).
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 Route Tables.
security lists
Virtual firewall rules for your VCN. Security lists have 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 subnet's instances by setting up a stateful ingress rule with source CIDR 0.0.0.0/0, and destination TCP port 22. Your VCN comes with a default security list with default rules, and you can add custom security lists of your own. For more information, see Security Lists.
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 a single, contiguous IPv4 CIDR block 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. After you've created a VCN or subnet, you can't change its size, so it's important to think about the size of VCN and subnets you need before creating them.

For your VCN, Oracle recommends using one of the private IP address ranges specified in RFC 1918 (10.0.0.0/8, 172.16/12, 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.

The VCN's CIDR must not overlap with your on-premises network or another VCN you peer with. The subnets in a given VCN must not overlap with each other. For reference, here's a CIDR calculator.

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:

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.

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 IP addresses. Whoever launches the instance chooses whether it will have a public IP address. You can override that behavior when creating the subnet and request that it be private, which means instances launched in the subnet are prohibited from having public IP addresses. 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 lists 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 IPs to a VNIC.

If the VNIC is in a public subnet, then each private IP on that VNIC can have a public IP assigned to it at your discretion. Oracle chooses the particular 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, be aware that when an internet gateway receives traffic from your VCN destined for a public IP address that is part of Oracle Cloud Infrastructure (such as Object Storage), the internet gateway routes the traffic to the destination without sending the traffic 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:

  • IPSec 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 addresses in your VCN as well as regional public IPv4 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 lists that permit the connection to be made and the desired 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 Other Clouds with Libreswan

You can connect your VCN to another cloud provider by using an IPSec 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:

There's also an advanced scenario that enables communication between an on-premises network and multiple VCNs over a single Oracle Cloud Infrastructure FastConnect or IPSec VPN. For more information, see Advanced Scenario: Transit Routing.

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 to whitelist, 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.

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.

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 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. You can use the Console link at the top of this page to go to the sign-in page. You will be 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 A collection of users who all need a particular type of access to a set of resources or compartment., A collection of related resources that can be accessed only by certain groups that have been given permission by an administrator in your organization., and An IAM document that specifies who has what type of access to your resources. It is used in different ways: to mean an individual statement written in the policy language; to mean a collection of statements in a single, named "policy" document (which has an Oracle Cloud ID (OCID) assigned to it); and to mean the overall body of policies your organization uses to control access to resources. 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.

Limits on Your Networking Components

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