Virtual Cloud Network FAQ

General questions

What is a virtual cloud network (VCN)?

A VCN is a customizable private network in Oracle Cloud Infrastructure (OCI). Just like a traditional data center network, a VCN provides you with complete control over your network environment. This includes assigning your own private IP address space, creating subnets, creating route tables, and configuring security controls via security rules, network security groups (NSGs), or Zero Trust Packet Routing (ZPR). A single tenancy (an OCI account) can have multiple VCNs, thereby providing grouping and isolation of related resources. For example, you might use multiple VCNs to separate the resources in different departments in your company.

What are the core components of a VCN?

For a complete list of components, see our networking overview documentation.

How do I get started with VCN?

For a quick tutorial on how to launch an instance inside a VCN in Oracle Cloud Infrastructure, consult our Getting Started Guide.

Also see the following documentation:

• Networking Overview
• VCN and Subnet Management

What IP addresses can I use inside my VCN?

A VCN in OCI supports IPv4 and IPv6 addressing. A VCN and its subnets can have multiple IPv4 and IPv6 prefixes. You create subnets within the VCN by subdividing the VCN's address range into contiguous and non-overlapping IP prefixes. Each IPv4 CIDR or IPv6 prefix of a VCN's subnet must fall within one of the VCN's IPv4 CIDR or IPv6 prefix respectively. When you launch a resource such as a compute instance or network load balancer (NLB) into a subnet, the resource's private IPv4/v6 addresses must be from one of the subnet's IPv4/v6 prefixes.

In the context of a VCN, IPv4 addressing can range from /16 (65,533 usable IP addresses) to /30 (1 usable IP address). Example: 10.0.0.0/16, 192.168.0.0/24. We recommend using an IPv4 CIDR block from the private address ranges specified by RFC1918. For IPv4 addressing, if you use any non-RFC1918 IPv4 CIDR block (especially public IPv4 blocks) for a subnet, note that it is still treated as a private IP address range and is not routable from the internet via OCI's Internet Gateway. Speaking broadly, there is no configuration for an OCI VCN (or its subnets) to have internet-routable IPv4 CIDRs assigned to it. Public IPv4 addresses are always individually applied to a resource in your public subnet. Also note that certain private IPv4 address ranges such as Class D and E are reserved for OCI and hence can't be assigned to a VCN or its subnets.

A VCN needs to be enabled for IPv6 addressing either during creation or afterward. IPv6-enabled VCNs can have three types of IPv6 prefixes as listed below:

1. Oracle GUA IPv6: This prefix type is a single /56 IPv6 global unicast address (GUA) prefix allocated by Oracle. Oracle GUA prefix count is limited to one per VCN.
2. GUA BYOIPv6: Each IPv6 prefix of this type is a /64 or larger BYOIPv6 GUA prefix. Each such prefix must come from a /48 or larger BYOIPv6 GUA prefix already imported into your tenancy. A VCN can have more than one IPv6 prefix of GUA BYOIPv6 prefix type.
3. ULA IPv6: Each IP prefix of this type is /64 or larger unique local address (ULA) prefix. A VCN can have more than one IPv6 prefix of ULA IPv6 prefix type.

We recommend you assign ULA prefixes to private subnets. Even if you assign a GUA range under the ULA IPv6 prefix type to a VCN, it will not still be internet-accessible, as it will be treated as a private IPv6 prefix only.

When IPv6 is enabled for a VCN, you can create a subnet with IPv4 prefix only, or both IPv4 and IPv6 prefixes. Therefore, a VCN can have a mix of IPv4-only subnets and subnets that have both IPv4 and IPv6.
All IPv6-enabled subnets can have /64 IPv6 prefixes only. For IPv6 addressing, only GUA IPv6 addresses (from Oracle or BYOIPv6 GUA prefix types) can be internet-accessible, and only if assigned to a public subnet.
If GUA IPv6 prefixes are assigned to a private subnet, they will not have connectivity to the internet. In this case, addresses from these GUA prefixes can only be used for private communication. We recommend you use only the ULA IPv6 prefix type for private subnets of an IPv6-enabled VCN.

How many IP prefixes can we assign to a VCN and to its subnet?

The following table captures the service limits on the maximum number of IP prefixes for a VCN and its subnets, as per the IP addressing scheme. You can request a limit increase from the OCI Console.

What are size restrictions on IP prefixes assigned to a VCN and its subnet?

Here are the minimum and maximum prefix sizes for VCNs and subnets in OCI:

Does a VCN support single stack IPv6 addressing?

Currently, you can create a VCN that is a single stack with IPv4 addressing or a dual stack with both IPv4 and IPv6 addresses supported. Hence, every VCN always has at least one private IPv4 CIDR. If a VCN is created with only single stack IPv4 addressing, you can later enable IPv6 at any time. A subnet in a VCN, irrespective of whether it is IPv6-enabled or not, must always have at least one IPv4 CIDR.

Can I mark a subnet as private?

Yes. When you create a subnet, you can specify the flag for its access type as either private or public. A subnet is created with public access by default, in which case the instances or resources (such as OCI Load Balancer) in the subnet can be allocated a public IPv4 or public GUA IPv6 address. Resources such as compute instances and load balancers that are launched in a private subnet prohibited from having public IPv4 addresses. This helps ensure that these resources have no direct internet access. After creation, the access type of the subnet cannot be changed.

When is a resource in a VCN directly reachable from the internet?

Only resources with a VNIC or network resource (NLB, load balancer [LB], etc.) that satisfies all the following conditions are reachable for direct ingress connections from the internet:

1. VNIC/resource resides in a public subnet and its subnet has a route to its VCN's internet gateway.
2. VNIC/resource has at least one public IPv4 or public GUA IPv6 address.
3. VNIC/resource has NSG and/or ZPR and/or security lists that allow ingress access from the internet.

Can a VCN span multiple availability domains?

Yes, a VCN always spans across all availability domains (ADs) of its region. Hence, it is a regional entity. A subnet, on the other hand, can be either AD-specific or regional.

Can a subnet span multiple availability domains or multiple VCNs?

Subnets can span multiple availability domains, but not multiple VCNs. If you create a regional subnet, the subnet's resources can reside in any availability domain in the region. When you create resources in a regional subnet, you can select an AD of your choice for that resource's physical residence. However, if you create an AD-specific subnet, the subnet's resources must reside in the subnet's particular availability domain. OCI recommends that you always create regional subnets for future flexibility.

Can I create two VCNs with overlapping IP ranges? Can VCNs have IP range overlap with my on-premises network?

Yes. Each VCN is its own isolated network until you peer it with other VCNs or connect it to your on-premises network. However, if you intend to connect a VCN to your on-premises network or another VCN, we strongly recommend that you ensure the IP address ranges don’t overlap. If they do overlap and the IP routing is not carefully designed, it can lead to unexpected packet delivery.

Are single stack IPv6-only VCNs or subnets supported?

OCI supports either single stack IPv4-only VCN/subnets or dual stack IPv4 and IPv6 VCNs/subnets. Consequently, every VNIC in a subnet of a VCN will always have exactly one private IPv4 address since its creation, which is called its primary IPv4 address.

How many VCNs, subnets, and other networking resources can I create?

For current limits for all services and instructions for requesting a service limit increase, see the service limits documentation.

Can I modify my subnet after I create it?

Yes. You can modify the subnet name, its route table, its security lists, and the set of DHCP options associated with it. You can expand or shrink the IPv4 mask of the subnet, provided the new mask does not exclude an in-use IP address assigned to a resource. You cannot change the subnet IPv6 prefix after assigning it, but you can delete it and reassign a new one. The IPv6 prefixes of a subnet are always /64. You can add a new IP prefix to a subnet subject to limits. You can also delete the existing IP CIDR or prefix of the subnet, provided no resource within the subnet uses an IP address from it.

Dynamic Routing Gateway (DRG)

What is an enhanced DRG and a legacy DRG?

DRGs created before May 17, 2021, are known as legacy DRGs. You must upgrade legacy DRGs by following the process specified in the DRG documentation. An enhanced DRG is the new version of DRGs that has additional features. All the DRGs in all regions of all realms created after May 17, 2021, are enhanced DRGs. Legacy DRGs are discontinued and can no longer be created. Any mention of DRGs in OCI public documentation is referring to enhanced DRGs.

What if I want to continue using my existing legacy DRG as is and do not need the enhanced DRG capabilities?

You can continue to use a legacy DRG, since the default behavior of the DRG has not changed. You need to explicitly enable the new features by upgrading to enhanced DRG. After upgrading a legacy DRG to an enhanced DRG, the default state of the enhanced DRG will mimic legacy DRG behavior, so there is no need to make configuration changes to resume traffic flow.

What are the advantages of enhanced DRG over legacy DRG?

Unlike legacy DRGs, the enhanced DRG offers the following features:

1. Up to 300 VCNs can be connected as attachments in the same region. This eliminates the need for local peering gateways (LPGs) for intra-region VCN peering.
2. On-premises environments connected via OCI FastConnect or VPN to one OCI region are able to reach resources in other OCI regions through the private OCI backbone.
3. Custom route tables are allowed for each attachment, providing granular control over how traffic flows between the networks.
4. Transit routing is supported, enabling advanced hub-and-spoke topologies where traffic between spoke VCNs can be centrally routed through a network virtual appliance (NVA) or firewall for inspection.

How do I upgrade my DRG so that I can use the new functionality?

Please see the Upgrading a DRG section of our documentation.

How do I control which VCNs can communicate with each other?

Communications between DRG attachments (including VCNs) is controlled by route tables and their associated import route distributions. The default VCN attachment route table and route distribution policies are autogenerated for VCN attachments of a DRG. These default settings enable all attached VCNs to communicate with each other. You may change the associated route distribution policies to isolate VCNs, as discussed in the DRG documentation.

What is the difference between import route distribution and export route distribution?

Both import route distribution and export route distribution are applied to the DRG route table of an attachment, but they control route propagation in opposite directions.

See below for a detailed comparison.

Can I directly attach a VCN from another tenancy to my DRG?

Yes. However, this requires specific cross-tenancy IAM policies to be configured. See the documentation IAM Policies for Routing Between VCNs for more information.

What is the default routing configuration in the DRG?

The DRG has two default route tables that are autogenerated. One is for your FastConnect, site-to-site IPsec VPN, and remote peering connection attachments, and one is for VCN attachments.

The import route distribution for the default route tables of RPC, FastConnect, and site-to-site IPsec VPN attachments imports routes from all VCN attachments on the same DRG.

This allows these attachments to connect to all VCNs on the DRG.

The import route distribution for the default route tables of VCN attachments imports routes from all attachments on the same DRG. This allows VCNs to connect all other attachments of all types on the same DRG.

How do DRG route tables and import route distributions influence routing in the DRG?

The DRG supports dynamic and static routing between its attachments (attached networks) and allows you to have a custom route table for each attachment. Each custom route table in turn can have its own custom import route distribution.

Import route distribution helps you specify the other attachments from which routes are imported dynamically into the associated route table and thus are routable/reachable for its attachment. This allows you to control routes granularly for each attachment without any manual steps and to easily design L3 isolation between specific attachments. The routes decide the next hop attachment depending on the destination IP address of the packet. In other words, DRG route tables of attachments determine the next hop for the inbound packets to the DRG from the attachment, and the next hop is always another attachment on the same DRG.

This dynamic route import into DRG route tables almost entirely eliminates the manual steps for setting up connectivity between attachments.

How do DRG route tables resolve route conflicts?

Each DRG attachment has its own DRG route table to direct the traffic inbound into the DRG from that attachment that is ultimately destined for another VCN or on-premises. Route rules in the DRG route table determine which attachment of the DRG to send the traffic to as the next hop. Like in any route table, if there is only one route with longest prefix match (LPM) for a given destination IP address for a packet, that route is selected.

Route conflicts arise when the DRG route table of the attachment has two or more routes with an identical IP prefix (and hence the same LPM).

In such cases, the DRG route table's conflict resolution considers the following factors in order of precedence for the routes being compared:

1. Whether the route is static or dynamic
2. The attachment type of the route source
3. The AS-Path length of the route, etc.

For details on how route conflicts are handled, please refer to the OCI documentation on DRG route conflict resolution.

How do routes get propagated into the DRG?

Each DRG attachment is associated with its own DRG route table, which determines how traffic entering the DRG from that attachment is forwarded. The attachment’s route table can dynamically learn and install routes advertised by other peer attachments on the DRG, providing reachability to the networks reachable through those peer attachments. You can fine-tune which routes are learned by configuring the import route distribution policy applied to each DRG route table.

With default import route distributions, routes are propagated as follows:

Routes propagated to/from on-premises networks: When you connect site-to-site IPsec VPNs or FastConnect virtual circuits to a DRG, routes are propagated between the DRG and your on-premises router using either BGP or statically, depending on your configuration.
Routes propagated from VCNs: When you attach a VCN to the DRG, the DRG route tables of all other attachments on that DRG will import all the following routes:
- CIDRs for subnets of that VCN (default) or CIDRs of that VCN
- The contents of the DRG ingress route table associated with the VCN (applicable only in advanced setups)
Routes propagated to VCN/subnet route tables: DRG routes are not automatically propagated to the route tables of subnets of your VCN. You must create explicit static routes in your VCN/subnet route tables for traffic destined to on-premises networks or other VCNs attached to the same DRG, with the DRG as the next hop. This also holds true for the gateway ingress route tables of gateways on the VCN. These route tables are managed as part of the VCN configuration.

In addition to these dynamic routes, you can also add static routes to a DRG route table.

Can I create static routes on a DRG route table?

Yes. You can create static routes on the DRG route table for any destination prefix. Static routes must have a next hop of a VCN, RPC, or cross-tenancy VCN/RPC attachment. Static routes with IPSec or virtual circuits as the next hop are not supported. You cannot have multiple static routes in the same DRG route table for the same destination IP prefix.

Can I connect OCI VCNs with identical VCN/subnet IP prefixes to the same DRG?

You can connect two OCI VCNs with overlapping IP prefixes to the same DRG. The DRG’s route table makes a deterministic and consistent forwarding decision to determine which VCN attachment is the next hop for the conflicting subnet/VCN IP prefixes. This preference order is not customer-controlled. Due to the complexity involved in controlling this behavior, overlapping IP prefixes among DRG attachments is not recommended.

Can I use a single FastConnect virtual circuit to connect my on-premises network to all OCI VCNs regardless of the region?

Yes, the DRG allows you to use a FastConnect virtual circuit in one region to communicate with resources in a VCN in that same region or in a VCN in another region. In the latter remote on-ramp scenario, the DRG with the virtual circuit attachment will have a remote peering attachment to another DRG in a different region.

Can my on-premises network connect to the internet via FastConnect or OCI Site-to-Site VPN?

No. Gateway-to-gateway transit routing between DRG and IGW (or NATGW) is not allowed. Thus, the traffic originating from on-premises network cannot transit to the internet via DRG directly.

Can I connect two on-premises networks together via FastConnect or Site-to-Site VPN?

No. DRGs do not advertise routes with the source of on-premises attachment (Site-to-Site VPN or virtual circuit) networks to another attachment for on-premises networks. This holds true even for DRGs chained with RPCs. Hence, DRGs do not allow traffic originating from on-premises to connect to another of your on-premises networks/sites.

What are the default limits or quotas for the DRG?

Details on limits and quotas can be found in our documentation.
Should you need to exceed these limits, please create a support case.

Does the DRG support IPv6?

Yes, the DRG supports attaching VCNs with IPv6 prefixes. The DRG also supports connectivity to on-premises networks with any Site-to-Site VPN or FastConnect virtual circuits using IPv6.

Should I use the local peering gateway (LPG) or the DRG to enable communication between VCNs in the same region?

Each VCN can have up to 10 local peering gateways and a maximum of one DRG. A single DRG supports up to 300 VCN attachments. We recommend using the DRG for all VCN peering scenarios for increased scalability, manageability, and observability.

In addition, If you want extremely high bandwidth and super low-latency traffic between two VCNs in the same region, use the scenario described in Local VCN Peering Using Local Peering Gateways. Peering two VCNs in the same region through a DRG gives you more flexibility in your routing, but comes at the cost of slightly higher latency and potentially lower bandwidth. For most workloads, the difference in latency/bandwidth is negligible.

What is the maximum number of supported equal-cost multipath routing (ECMP) paths?

The current limit is eight active paths for ECMP in DRG route tables.

Virtual network interface cards (VNICs)

What is a virtual network interface card?

The servers in OCI data centers have physical network interface cards (NICs). When you launch an instance on one of these servers, the instance communicates using the networking service virtual NICs (VNICs) associated with the physical NICs. A VNIC enables a compute instance to be connected to a VCN and determines how the instance communicates with endpoints inside and outside the VCN.

For these communications, VNICs use the IP object assigned to them. These IP objects can be either a host IP address (single IP) or an IP CIDR address. The IP CIDR addresses assign a contiguous range of host IPs in CIDR format to a VNIC in a single configuration parameter. All VNICs of the instance always reside in the same AD as that of the instance to which they are attached.

Each VNIC resides in a subnet and has the following configuration:

• One primary private IPv4 address from the subnet the VNIC is in, chosen by either you or Oracle – It must be assigned at the time of VNIC creation. It is always a single host IP address and cannot be an IP CIDR address. After its creation, it cannot be changed or moved to another VNIC.
• Up to 64 secondary IPv4 objects, assigned by either you or Oracle – Secondary IPv4 objects/addresses can be assigned only after creation of the VNIC. All secondary IPv4 objects/addresses can be moved to another VNIC within the same subnet at any time using APIs/SDK/CLI.
• Up to 32 IPv6 objects from the subnet the VNIC is in, assigned by either you or Oracle – Unlike IPv4, IPv6 objects/addresses do not have primary/secondary classification. Only one IPv6 object/address can be assigned to a VNIC during its creation. An IPv6 object/address can be assigned to a VNIC any time after its creation. All IPv6 objects/addresses can be moved to another VNIC within the same subnet at any time using APIs/SDK/CLI.
• Optional public IPv4 address for each private IPv4 host address – This applies if the VNIC is in public subnet.
• Optional hostname for DNS for each private IPv4 host address – Consult the documentation on DNS in VCNs for details. Note that a hostname for DNS for IPv6 address is not currently available.
• A single MAC address
• A VLAN tag assigned by Oracle – This tag is available when the attachment of the VNIC to the instance is complete (relevant only for bare metal instances).

For more information, see our documentation on virtual network interface cards.

What is the primary VNIC of an instance?

Every instance in your VCN is created with a VNIC called its primary VNIC. The primary VNIC cannot be detached from the instance. It gets automatically deleted when the instance is terminated. Every VNIC, primary or secondary, always has its own primary private IPv4 address.

What are secondary VNICs on an instance?

Every instance in your VCN has at least one VNIC, which is its primary VNIC. You can attach additional VNICs to an instance that are referred to as secondary VNICs. The secondary VNICs can belong to different VCNs or subnets. Secondary VNICs can only be added after the instance is created with the LaunchInstance API call. 

What is the maximum number of VNICs supported on an instance?

The maximum number of VNICs that can be attached to an instance varies by shape and is often (but not always) linearly proportional to number of OCPUs available for the shape. For details on these limits, see the Compute Shapes documentation.

Are there any bandwidth limits on each VNIC of compute instance?

No. A specific bandwidth limit is allocated to the entire instance and is often (but not always) linearly proportional to number of OCPUs of the shape of your compute instance. All the VNICs of the compute instance combined get this entire allocated bandwidth. For example, if a compute instance with 10 OCPUs has 10 Gb/sec of allocated bandwidth with only one of its VNICs in use, that VNIC can consume the entire 10 Gb/sec. For additional details, see the Compute Shapes documentation.

Can I find VNIC information from within the instance?

Yes. Query the instance metadata service available at http://169.254.169.254/opc/v1/vnics/.

Can I assign a specific private IP address to a VNIC?

Yes. In the case of the primary VNIC, you can specify the private IP address at the time of instance creation. For secondary VNICs, you can specify a private IP address when you attach the VNIC to an instance. The specified private IP address should belong to the same subnet that the VNIC belongs to and should not already be in use.

Can I move a VNIC from one instance to another?

No. Currently, VNICs are always bound to the instance and do not exist independently. The primary VNIC is created and destroyed with the instance. All secondary VNICs are created and destroyed when they are attached and detached respectively or when their compute instance is terminated.

Can I attach two VNICs from the same subnet to an instance?

Yes. However, attaching multiple VNICs from the same subnet IP prefix to an instance can introduce asymmetric routing, especially on instances using a variant of Linux. If you need this type of configuration, Oracle recommends assigning multiple private IP addresses to one VNIC or using policy-based routing. For an example, see the script under Linux: Configuring the OS for Secondary VNICs in the documentation.

Can the VNICs attached to an instance belong to subnets in different availability domains (ADs)?

No. All VNICs must belong to subnets in the same AD as the instance. When using regional subnets, the VNICs must be created in the same AD as the instance.

Can the VNICs attached to an instance belong to subnets in different VCNs?

Yes. You can attach secondary VNICs that belong to a subnet of a VCN that is different from the VCN and/or subnet of the primary VNIC.

Which VNICs are used for I/O to block volumes of the instance?

I/O to iSCSI block volumes, if attached to the instance, exclusively uses its primary VNIC. I/O to para-virtualized block volumes of the instance does not use any VNIC of the instance. All block volume I/O (iSCSI and PV) consumes the total network bandwidth allocated to the instance.

IP Addressing

Can I assign one or more private IP addresses of my choice to my compute instance?

Every compute instance in your VCN is created with a VNIC and is assigned a private IPv4 address from the subnet provided at instance launch. These are the primary VNIC and its primary private IPv4 address, respectively. You can also attach additional VNICs to an instance, referred to as secondary VNICs, each of which also always has a primary private IPv4 address.

You can let Oracle choose the private IPv4 address, or you can choose it from the subnet's IPv4 CIDR blocks. If the address you specify is already in use, the launch request will fail.

Additionally, you can assign secondary private IPv4 objects to a VNIC. Like primary private IPv4 addresses, a secondary private IPv4 object provides connectivity to destinations within your VCN and/or on-premises (when there is connectivity through OCI Site-to-Site VPN or OCI FastConnect). Secondary private IPv4 object can be a host IP or IP CIDR address. You can also assign IPv6 objects to a VNIC when that VNIC is in an IPv6-enabled VCN/subnet. An IPv6 object assigned to a VNIC can be a host IPv6 address or an IPv6 CIDR address.

Can I move an IP object from one VNIC to another?

IPv4 Objects: You can move any secondary private IPv4 object from a VNIC on one instance to a VNIC on the same or another instance, provided that both VNICs belong to the same subnet. The primary IPv4 address of a VNIC cannot be moved. For primary IPv4 addresses, you must delete the VNIC—only then can the same private IPv4 address be assigned to another VNIC.
IPv6 Objects: You can move any IPv6 object from a VNIC on one instance to a VNIC on the same or another instance, provided that both VNICs belong to the same subnet.

Please note that, here, move means the removal of an IP object from one VNIC and the assignment of that exact host IP (or IP CIDR address) as a new IP object to another VNIC using OCI API/SDK/CLI. When using regional subnets, the IP object can be moved to a VNIC in a different AD as well.

Can I assign a range of IPs to a VNIC?

Yes, you can. A VNIC has a single primary IPv4 address as host IP. In addition, a VNIC can have multiple secondary IPv4 and IPv6 addresses assigned as host IPs. All the host IP addresses have an implicit /32 prefix length for IPv4 addresses and /128 prefix length for IPv6 addresses. To assign a contiguous range of host IPs to a VNIC, use an IP CIDR address. An IP CIDR address is an IP and network prefix length in CIDR notation (e.g., 10.0.0.32/28) that assigns all host IPs within that prefix to the VNIC. You can assign IP CIDR addresses to any VNIC of a compute instance as a secondary IP object.

For more information, see Private IP Objects and Assignment of IPv6 Addresses to a VNIC.

What are the constraints for IP CIDR address allocations to a VNIC?

The following are constraints for IP CIDR addresses assigned to a VNIC:

• Always secondary IP objects; they cannot be a primary IP assigned to a VNIC
• Cannot include any IP address in use or reserved by users or OCI
• Must be fully contained within one of the subnet’s IPv4 CIDR blocks or IPv6 prefix.
• IPv4 CIDR address prefix length value must be /18 to /32 and at least 2 bits longer than the subnet netmask itself; for IPv6, prefix must be between and include /80 and /128.
• Must start on a valid network boundary for both IPv4 and IPv6; for IPv6, must be incremented by a hexadecimal digit (nibble or 4-bit boundary)

For further details, please refer to OCI Networking documentation.

What are the limitations of IP CIDR addresses?

The following are limitations for IP CIDR addresses:

• No public IPv4 association for IPv4 addresses defined within an IP CIDR address; use of NAT gateway required for internet access on IPv4
• Only supported on compute VNICs
• Creation of FQDNs not supported by VCN DNS for addresses within IP CIDR address
• Not supported on L2/VLAN VNICs
• Queries sourced from secondary private IP objects (including IP CIDR addresses) not supported by instance metadata service

For further details, please refer to the OCI Networking documentation.

Can the instance OS discover and configure the secondary private IP address automatically (using DHCP)?

The OS cannot discover any of the secondary private IPv4 addresses assigned to any VNIC of the instance using mechanisms such as DHCP. You need to configure the secondary private IPv4 addresses using an OS-specific procedure. The OS can discover IPv6 addresses on any VNIC using DHCPv6.

DHCP is not applicable to IP CIDR addresses assigned to VNIC. Broadly speaking, for Linux and Windows OS, see the scripts provided in the documentation Assigning a New Secondary Private IP to a VNIC. For Oracle Linux, we also provide CLI oci-network-config utility to easily configure secondary VNICs and IP addresses.

What is a public IP address and how is it different from a private IP address?

A public IP address is an IP address that is reachable from the internet (i.e., an internet-routable IP address). An instance in your VCN communicates with hosts on the internet via a public IP address. A private IP address is not internet-routable. Instances inside the VCN communicate with each other using private IPv4 addresses or IPv6 (ULA/GUA).

For IPv4 addressing, if you use a public (non-RFC1918) IPv4 CIDR block for a subnet, note that it is still treated as a private IPv4 address range and is not routable natively to and from the internet (via OCI's internet gateway).

You can assign a public IP address to a resource (e.g. compute, load balancer) and enable them to communicate with the internet. A private IPv4 address assigned to a VNIC always requires a public IPv4 association for internet connectivity through an internet gateway.

IPv6 does not have this requirement; IPv6 GUA prefixes assigned to VNICs in public subnets can be natively routed to and from the internet via an internet gateway.

All public IP addresses and their respective IP prefixes are regional resources and hence cannot be ported from one region to another region of OCI. Similarly, BYOIP prefixes are imported to a specific region of OCI but can be later moved to another region.

An IP address assigned to a resource is accessible for ingress connections from the internet if all the following conditions are met:

1. It is either an IPv6 address (from GUA BYOIPv6 prefix type or Oracle GUA IPv6 prefix type of the VCN) or public IPv4 address (from BYOIPv4 prefix or Oracle assigned)
2. It is assigned to a resource/VNIC with a route to the internet gateway of the VCN within its subnet route table
3. It is assigned to a VNIC residing in a public subnet
4. It has security lists, NSGs, or ZPR rules permitting network connectivity

What are the types of public IPv4 addresses?

There are two types of public IPv4 addresses assigned to your resources in the VCN: ephemeral and reserved.

• Ephemeral public IPv4 addresses are essentially temporary, existing only for the lifetime of the resource to which they are assigned.
  You cannot select the ephemeral IPv4 address. Instead, at your request, Oracle will assign one automatically from Oracle's available pool of public IPv4 addresses. It cannot be from your BYOIPv4 prefixes.
  An ephemeral public IPv4 address is always bound to the lifecycle of the private IPv4 address of a VNIC of instance or another network resource like LB. If you unassign the public IPv4 address explicitly or terminate the corresponding resource (LB/NATGW, etc.), the public IPv4 address gets released back into the OCI pool. If you later request a public IPv4 address again, it may be a different address than before. Ephemeral public IPv4 addresses cannot be moved from one VNIC/IP address to another.
• Reserved public IPv4 addresses are essentially floating public IPv4 addresses that reside in a compartment & region of your choice. They are persistent and exist beyond the lifetime of the resources. to which they're assigned. You can keep a reserved public IPv4 address unassigned within your compartment, or assign it to a private IPv4 address of an instance or a load balancer within the same region it was created in. You can also move it to any another resource in your tenancy within the same region. Reserved public IPv4 addresses can come from Oracle's available pool of public IPv4 addresses. They can also be from your specific public IPv4 pool carved out of one of your BYOIPv4 prefixes.

A public IPv4 address of any type can only be associated with a private IPv4 host address assigned to a resource in a public subnet of a VCN. Except for a NATGW, the association/assignment of public IPv4 address of either type is always one private IPv4 address. NATGW can have a public IPv4 address with no private IPv4 address for it. For more details and a table comparing the two types, see the Public IP Addresses documentation.

What are the types of public IPv6 addresses?

A public IPv6 address always comes from one of the IPv6 GUA prefixes assigned to your VCN. The public IPv6 address for your VCN resource will always come from one of the following two types of IPv6 GUA prefixes:

• Oracle-assigned GUA IPv6 prefix
• Your imported BYOIPv6 GUA prefix

The lifecycle of an Oracle-assigned GUA IPv6 prefix assigned to your VCN stays with your VCN until you remove it from VCN, or its VCN is deleted. If you try to reassign an Oracle-owned GUA prefix to that VCN after removal, it might be different. Hence, the concept of ephemeral does not directly apply to individual public IPv6 addresses. However, you can have an individual IPv6 address as reserved, but this reservation is always scoped to a subnet. This is different from public IPv4 addresses where a reservation is scoped to a tenancy. Reserved GUA IPv6 addresses can be from an Oracle-owned GUA prefix or your imported BYOIPv6 GUA prefix. When assigned to resources in a private subnet of a VCN, the public IPv6 address cannot access the internet. For more information, see IPv6 Addresses.

Why do I need reserved public IP addresses?

A public IP address becomes the identity of your service for clients that cannot use the DNS FQDN. A reserved public IP address allows you to keep this identity regardless of any changes to the underlying resources. Here are a couple of specific scenarios that can benefit from a reserved public IP address:

• Insulating clients from any instance-specific failures: You can assign a reserved public IP address to your instance and seamlessly move it to another instance in case of a failure. Your clients are insulated from this change as they continue to connect to the same public IP address.
• Optimizing usage of compute resources with no impact to users: Whether you want to change the size of an instance or terminate your instances based on the usage patterns to save costs, a reserved public IP address enables you to expose the same public IP address to your clients.
• IP address-based allowlisting: Sometimes external public endpoints have requirements for static IP address-based access controls as a security mechanism. This requires you to consistently use fixed IP addresses throughout the lifecycle of your architecture.

How many reserved public IPv4 addresses can I assign to an instance?

You can assign only one reserved public IPv4 address to any primary or secondary private IPv4 address of a VNIC. However, you can assign multiple private IPv4 addresses to each VNIC attached to your instance. You can then assign/associate a reserved public IPv4 address to each of these private IPv4 addresses.

There is a limit on the maximum number of reserved public IPv4 addresses you can create in your tenancy. See the Service Limits documentation for more details.

How many ephemeral public IPv4 addresses can I assign to an instance?

You can assign only one ephemeral public IPv4 address to any primary private IPv4 address of the VNIC. However, you can create and attach multiple VNICs to your instance. You can then assign an ephemeral public IPv4 address to the primary private IPv4 address of each VNIC. You cannot assign an ephemeral public IPv4 address to any secondary private IPv4 address of a VNIC.

There is a limit on the maximum number of ephemeral public IPv4 addresses that can be assigned to an instance. See the Service Limits documentation for more details.

Can I move an ephemeral public IPv4 address from one VNIC/instance to another?

No. An ephemeral public IPv4 address can only be associated with a primary private IPv4 address of the VNIC. A primary private IPv4 address cannot be moved from one VNIC to another; its associated ephemeral public IPv4 address cannot be moved either. You can associate or disassociate the ephemeral public IPv4 address with the primary private IPv4 address of the instance’s VNIC at any time.

Can I move a reserved public IPv4 address from one VNIC/instance to another?

Yes. You can move it from one availability domain or VCN or subnet to another, but only within the same region.

There are two ways to move a reserved public IPv4 address:

• You can unassign the reserved public IPv4 address from its associated private IPv4 address and then reassign it to another private IPv4 address. The newly chosen private IPv4 address can be on a VNIC in a different availability domain or VCN/subnet than the original VNIC. Note that this new VNIC must be in the public subnet.
• If the reserved public IPv4 address is assigned to a secondary private IPv4 address, you can move the private IPv4 address to a different VNIC (which must be in the same public subnet). This maps the public IPv4 address to the new VNIC.

When is an ephemeral public IPv4 address released?

In the following cases, the ephemeral public IPv4 address assigned to a resource will get released back to the OCI public IPv4 pool:

• When you unassign an ephemeral public IPv4 address from a primary private IPv4 address of a VNIC, its corresponding ephemeral public IP address will be released.
• When you detach/delete a secondary VNIC of an instance, any corresponding ephemeral public IPv4 address will be released.
• When you terminate the instance, all its VNICs are terminated too, including the primary VNIC. Thus, all ephemeral IPv4 addresses on each attached VNIC are released as well. Note that there is no impact on the corresponding ephemeral public IPv4 addresses when you reboot the instance.
• When you delete the resource associated with an ephemeral public IPv4 address (such as a LB, NLB, or NATGW), that ephemeral IP4v address will be released.

What IP addresses do I see when I log into my compute instance?

When you log into an instance, on your OS network interfaces, you will see all the IP addresses assigned to its respective VNIC, excluding the public IPv4 addresses.

For public IPv4 addresses, the networking service provides a one-to-one static NAT at the internet gateway to your associated private IPv4 address. IPv6 GUA and ULA addresses are directly visible on the OS NIC. There is no one-to-one static IPv6 NAT for public GUA IPv6 addresses.

How does the traffic for a public IPv4 address show up on the instance?

At the instance OS level, you see only the private IPv4 addresses of all the VNICs attached to the instance. For any egress traffic destined to an external public IPv4 address, an internet gateway will do a one-to-one source NAT from a private IPv4 of the VNIC to its associated public IPv4 address. For any ingress traffic destined to a VNIC's public IPv4 address from the internet, an internet gateway will do a one-to-one destination NAT from the VNIC's public IPv4 address to its associated private IPv4. Hence, from the perspective of your instance, it communicates to an external public IPv4 address via a private IPv4 address of its VNIC.

Can I assign a MAC address to my compute instance?

No. The OCI networking service assigns the MAC address to a VNIC of an instance. Users can neither assign it during the VNIC's creation, nor can they modify it afterwards.

Is IPv6 supported?

Yes. IPv6 is supported. For more information, see IPv6 Addresses.

Do you support IP multicast or broadcast within the VCN?

No, not currently.

Does VCN support transparent IP takeover using gratuitous ARPs (GARP)?

No, not currently.

Can a private IPv4 address be reserved?

Yes. Reservation of a private IPv4 address is scoped to a single subnet of a single VCN. Reserved private IPv4 addresses are excluded from IP auto-allocation by OCI during the creation of a new resource in the same subnet. This allows you to move the reserved IPv4 address explicitly from one resource to another during failover scenarios with certainty. Hence, the reserved IPv4 address acts as a stable private endpoint for your services.

Can an IPv6 address be reserved?

Yes. An IPv6 address of any type (Oracle-owned GUA, ULA, or BYOIPv6 GUA) can be reserved at the subnet level. OCI does not support tenancy‑wide reserved public IPv6 addresses as it does for public IPv4. Reserved IPv6 addresses are excluded from IP auto-allocation by OCI during the creation of a new resource in the same subnet. This allows you to move the reserved IPv6 address explicitly from one resource to another during failover scenarios with certainty. Hence, the reserved IPv6 address acts as a stable endpoint for your services.

Bring Your Own IP Address (BYOIP)

What is Bring Your Own IP Address (BYOIP)?

BYOIP allows you to import publicly routable IP prefixes (IPv4 CIDR blocks or IPv6 GUA prefixes) that you own (or lease) to Oracle Cloud Infrastructure. Once your IP prefixes are imported into OCI, your OCI resources such as compute instances, NATGW, and LBs can use them.

What are the advantages of BYOIP?

Public IP addresses are assets that are carefully managed and controlled by an organization. Some reasons for granular IP management and control include:

• Applications that require strong IP reputation for sending email
• Previously established access control policies
• Application dependencies tied to specific IP addresses

The migration of an IP prefix from an on-premises infrastructure to OCI allows you to minimize the impact to your customers and applications while taking advantage of all the benefits of Oracle Cloud Infrastructure. BYOIP in OCI will allow you to minimize downtime during migration by simultaneously advertising your IP address prefix from OCI and withdrawing it from the on-premises environment.

How do I get started with BYOIP?

The IP prefix you want to import to OCI under BYOIP must meet the following criteria:

1. The network prefix/range must be owned by your organization or leased by you.
2. TFor an IPV4 CIDR, it must be /24 or larger. For an IPv6 prefix, it must be /48 or larger.

The process to move an IP prefix for use in OCI starts in the OCI Console under Networking > IP Management. It can also be initiated via the API. From there, simply follow these steps:

1. Initiate the request to bring an IP prefix to OCI.
2. Register the validation token generated from the request with the Regional Internet Registry (RIR) service (ARIN, RIPE, or APNIC). See the documentation for more details on this step.
3. After you register your token, return to the OCI Console and click Validate CIDR block so Oracle can complete the validation process. Oracle then validates that your IP prefix has been properly registered for the transfer and provisions your BYOIP. This step can take up to 10 business days. You will be notified by email when the process is complete. You can also check the progress of this step in your work requests.

For more information on the import process, please see the BYOIP documentation.

What do I do with the validation token issued by Oracle?

As part of BYOIP CIDR block import process, Oracle will issue you a validation token. Once you have your token, you will need to modify it slightly by adding the information shown below. You can use any text editor for this step.

OCITOKEN:: <CIDRblock> : <validation_token>

Depending on your RIR, you must do the following to submit the validation token:

How do I use BYOIP addresses with OCI resources? What OCI resources can be used with a BYOIP prefix?

After the IP prefix is validated, you have full control over it.

For the BYOIP IPv6 (BYOIPv6) prefix, sub-prefixes are assigned directly as IPv6 prefixes to a VCN or subnet. IPv6 addresses from the subnet prefixes can then be assigned to resources within your VCN, such as compute instances, network load balancers, and load balancers.

Therefore, you can use the IP prefixes with resources in VCNs that are in the same region where those prefixes were imported.

Do I control the advertisement of the BYOIP prefix after it is onboarded?

Once the IP prefix is onboarded to OCI, you control the advertisement and withdrawal of the prefix.

How long does BYOIP validation and onboarding take?

BYOIP validation and provisioning can take up to 10 business days. You will be notified by email when the process is complete.

Can a BYOIP prefix be moved between OCI regions?

No. The BYOIP prefix is assigned to a specific OCI region. Also, it will only be advertised to the internet (via BGP) for the region it is onboarded to. Consequently, internet traffic destined to IP addresses of the BYOIP prefix will route to its specific onboarding OCI region. However, you can delete the BYOIP prefix onboarded to one OCI region and then create/onboard it on another OCI region, effectively moving your BYOIP prefix between regions.

What are the minimum and maximum size prefixes I can use for BYOIP?

Under BYOIP, the IPv4 CIDR must be a minimum of /24 or a maximum of /8. An IPv6 prefix must be a minimum of /48 or a maximum of /8. You do not have to bring all your IP space to OCI. If you own a larger IP block, you can choose which prefixes to bring to OCI.

How do I distribute my BYOIP prefix into IP pools?

After your public IPv4 prefix is onboarded, you control the distribution of addresses and policy within your OCI tenancy. You can keep the entire IPv4 prefix you imported in a single IP pool or subdivide the prefix down to /28s and keep each sub-prefix in its separate IP pool. The minimum size of an IPv4 block for IP pools can be /28. Public IP pools are supported only for IPv4. A public IPv4 address from your BYOIPv4 prefix can only be used after it is part of an IPv4 block of an IP pool. IP pools provide a mechanism for organization and IAM policy control for your imported IPv4 prefixes. When public IPv4 addresses from an IP pool are assigned to a resource, they are applied individually and not as a CIDR. For example, you cannot assign a CIDR from the IP pool as a prefix to your VCN.

Your BYOIPv6 IPv6 addresses do not use the IP pool functionality. Instead, you can directly assign these prefixes (or their subdivisions) to VCNs and subnets. GUA IPv6 addresses from your BYOIPv6 prefixes can be assigned to your resource only if the IPv6 prefix containing them is assigned to their parent VCN/subnet.

Can I create reserved IP addresses from my BYOIP prefix?

You can create a reserved public IPv4 address, at a tenancy level, from an IPv4 pool carved from a BYOIPv4 CIDR.

You can create a reserved public IPv6 address from a BYOIPv6 prefix once a ::/64 sub-prefix range from the same BYOIPv6 prefix is assigned to a subnet. Reservation of a public IPv6 address is always at the subnet level.

Can I still use Oracle-owned ephemeral and reserved IP addresses if I bring my own prefix to OCI?

Yes. You can still use Oracle-owned ephemeral and reserved IP addresses along with IP addresses from your own BYOIP ranges imported into OCI. Standard limits apply to Oracle-owned addresses.

Can IP addresses from BYOIP ranges be used as IP CIDR addresses for a VNIC of an instance?

IPv6 addresses from BYOIPv6 prefixes can be used as IP CIDR addresses for VNICs of instances, provided that the IPv6 prefix containing them is assigned to a subnet and VCN where the VNIC resides.
Public IPv4 addresses from a CIDR block of any type (BYOIP or Oracle-owned) are always assigned individually to a network resource (NLB/LB) or instance VNIC. Hence, any sub-prefix of a public IPv4 pool or BYOIPv4 CIDR block cannot be assigned as an IP CIDR address for a VNIC of an instance.

Are OCI resources with public IP addresses from a BYOIP prefix accessible over OCI FastConnect with public peering?

Yes, your OCI resources with public IP addresses from your BYOIPv4/6 prefix can be accessed over FastConnect with public peering to the same region where your IP prefix has been imported.

Connectivity

What connectivity options are available for instances running in my VCN?

The instances can connect to:

• The internet (via an internet gateway or NAT gateway)
• Your on-premises data center using an OCI Site-to-Site VPN connection or FastConnect (via a Dynamic Routing Gateway)
• Instances in peered VCNs (in the same region or another region)
• Oracle Cloud Infrastructure services such as Object Storage or Autonomous Data Warehouse (via a service gateway, private endpoints, or private service access)

What is an internet gateway?

An internet gateway is a software-defined, highly available, fault-tolerant gateway that provides public internet connectivity for resources inside your VCN. Using an internet gateway, a compute instance with a public IP address assigned to it can communicate with hosts and services on the internet.

Alternatively, you can connect your VCN to your on-premises data center using FastConnect, from which you can route traffic to the internet via your existing, on-premises network egress points. This option will use private IP space.

What is a NAT gateway?

A NAT gateway is a reliable and highly available gateway that provides outbound-only internet connectivity for resources inside your VCN. With a NAT gateway, private instances (with only a private IP address) can initiate connections to hosts and services on the internet but cannot receive inbound connections initiated from the internet. Please note that currently OCI NAT gateways can have only one public IP and support only Transmission Control Protocol, User Datagram Protocol, and Internet Control Message Protocol.

Can I have more than one NAT gateway per VCN?

No. The default limit is one NAT gateway per VCN. This should be sufficient for most applications.
If you would like to allocate more than one NAT gateway in a specific VCN, you can request a limit increase. For instructions on how to request an increase, see the documentation on service limits.

Are there any new throughput limits when using a NAT gateway?

Instances get the same throughput with the NAT gateway as they do when the traffic is routed through an internet gateway.

Is there a concurrent connection limit when using a NAT gateway?

Yes.

There is a limit of approximately 20,000 concurrent connections to a unique destination on the internet for all its client within an AD in an OCI region with 3 ADs. This limit is an aggregate of all the connections initiated by instances across the VCN residing in a particular AD that are using that VCN's NAT gateway. For a mono-AD OCI region, the limit is approximately 65,000. Note that here, by unique destination on the internet, we mean a unique combination of destination public IP address, destination port, and protocol.

What is a Dynamic Routing Gateway (DRG)?

A Dynamic Routing Gateway is a software-defined, highly available, fault-tolerant virtual router that you can attach to your VCNs.

It provides a secure path for the following:
- East-west traffic between a VCN and other VCNs residing in the same OCI region
- East-west traffic between VCNs in different OCI regions connected using remote peering
- North-south traffic between VCNs and on-premises networks over the internet using a site-to-site IPsec attachment or over a dedicated line using FastConnect virtual circuits

Thus, a DRG acts as a central hub that can facilitate secure communication using private IP space for your entire network, including VCNs in different OCI regions and your on-premises networks.

What is a customer premise equipment (CPE) object and why do I need it?

You use this object if you set up a site-to-site IPsec VPN. It's a virtual representation of the actual router that is on-premises at your site, i.e., at your end of the VPN. When you create this object as part of setting up a site-to-site IPsec VPN, you specify the public IP address of your on-premises router.

Do I need an internet gateway to establish a site-to-site IPsec VPN to my on-premises data center?

No. You just need to provision a DRG, attach it to your VCN, configure the CPE object and IPSec connection, and configure the route tables.

Which customer premise equipment routers or gateways have you tested with OCI Site-to-Site VPN?

See the list of tested device configurations.

I have an IPsec VPN router that is not on the above list of tested equipment. Can I use it to connect to my VCN?

Yes, provided that your generic CPE's configuration supports phase 1 and phase 2 IPsec parameters supported by OCI's site-to-site IPsec VPN service. Consult our list of supported parameters for more information. We support multiple configuration options to maximize interoperability with different VPN devices.

How do I ensure availability of my site-to-site IPsec VPN connection between Oracle Cloud Infrastructure and my on-premises data center?

Oracle provisions two VPN tunnels as part of the IPsec connection. Both tunnels within a single IPsec connection are designed to automatically be redundant on the OCI side, each terminating on a different VPN device. Make sure to configure both tunnels on your CPE for redundancy.

Additionally, you can deploy two CPE routers in your on-premises data center with each configured for two tunnels.

Can I use a software VPN to connect to my VCN?

IPsec VPN is an open, standards-based protocol, and hence software-based IPsec VPNs can interoperate with the OCI Site-to-Site VPN service. You need to verify that your software IPsec VPN supports at least one supported IPsec parameter for OCI Site-to-Site VPN in each configuration group according to generic CPE configuration. See the documentation on supported IPsec parameters for details.

Does traffic between two public IP addresses managed by OCI stay within OCI?

Yes. Please note that public IP addresses managed by OCI include both public IP addresses that are Oracle-owned and BYOIP addresses of Oracle customers. Within an OCI realm, traffic between OCI-managed public IP addresses always remains within that OCI realm and will not traverse the internet. This holds true irrespective of which VCN gateway is on the route of traffic.

More specifically, traffic between two OCI-managed public IP addresses in the same region stays within that OCI region. On the other hand, when the public IPs are in different OCI regions of the same realm, traffic traverses over a private OCI backbone of that realm. Find out more about the OCI backbone network.

Naturally, traffic between an OCI-managed public IP address and a private IP address in a VCN also remains within the OCI realm.

The complete list of OCI public IP addresses can be found here: https://docs.cloud.oracle.com/en-us/iaas/tools/public_ip_ranges.json.

Private access to services

What is the Oracle Services Network?

The Oracle Services Network is a conceptual network in Oracle Cloud Infrastructure that is reserved for Oracle services. The network comprises a list of region-specific public CIDR blocks owned by Oracle. Every service in the Oracle Services Network exposes a service endpoint that uses public IP addresses from the Oracle Service Network's reserved IP range. Almost all Oracle services are available in this network (see the complete list), and more services will be added in future as they get deployed on OCI.

What is a service gateway?

A service gateway (SGW) lets resources in your VCN privately and securely access Oracle services in the Oracle Services Network, such as OCI Object Storage, Database, Monitoring, Identity, Logging, etc. Traffic between an instance in the VCN and a supported Oracle service uses the instance's private IP address for routing, traversing over the OCI fabric and never over the internet. Much like the internet gateway or NAT gateway, the service gateway is a virtual device that is highly available and scales dynamically. With SGW, resources in your VCN can only reach the Oracle Services Network and no other networks such as the internet. With SGW, you can also connect your on-premises resources to Oracle services in the Oracle Services Network via transit routing.

What Oracle Cloud Infrastructure services can I access through a service gateway?

Almost all OCI PaaS or SaaS services are available on Oracle Services Network (OSN) and can be accessed through a service gateway.

I am currently using an internet gateway or NAT gateway to access an Oracle service such as ADW. How do I use the service gateway to access the same Oracle service endpoint?

• Create a service gateway for the VCN.
• Update the VCN/subnet routing to forward all traffic for Oracle services in the Oracle Services Network using the service gateway instead of the internet gateway or NAT gateway.
• Permit traffic to OSN CIDR with SL/NSG.

For instructions, see Access to Object Storage: Service Gateway. Please note that the service gateway allows access to Oracle services within the region to protect your data from the internet. Your applications may still require access to public endpoints, e.g., for updates or patches. Ensure you have a NAT gateway or other means of access to the internet, if necessary, in your VCN.

What is a service CIDR label?

The service gateway uses the concept of a service CIDR label, called a moniker, which is a string that represents all the regional public IP address ranges for the service or group of services. For example, “OCI IAD Services” in the Oracle Services Network is the label that maps to the regional CIDR blocks in the Oracle Services Network in us-ashburn-1. You use the service CIDR label when you configure the service gateway and route/security rules. For instructions, see Access to Oracle Services: Service Gateway.

Can I configure the service gateway to access services running in a different region?

No. SGW is a regional service. In other words, resources within the VCN with a service gateway can only reach OCI services in that region. If a VCN in one region of OCI wants to reach OCI PaaS or SaaS services in another region, you can leverage transit routing.

Can I allow access to an Object Storage Service from only specific VCNs or subnets?

Yes. You can use egress rules in SL/NSGs to control which subnets/VNICs or resources from your VCN can reach OSN or specifically Object storages service. Alternatively, you can also use the Network Sources feature of OCI IAM.

For an example of an IAM policy, see Access to Object Storage: Service Gateway.

Can I have multiple service gateways within my VCN?

No. A VCN can have only one service gateway at this time.

Can I use a service gateway with VCN peering?

No, if two VCNs residing in the same region are peered with local peering gateway. Yes, when the two VCNs residing in the same region are peered with a DRG and with transit routing configured for a VCN with an SGW. Yes, if two VCNs residing in different regions are peered with two DRGs using RPCs and with transit routing configured for a VCN with an SGW.

From my on-premises network, how can I connect to OCI services through a SGW attached to my VCN?

Yes, you can use FastConnect or the IPSec VPN service with transit routing for the hub VCN attached to a DRG. For details, please refer to the documentation Private Access to Oracle Services.

Can I get direct dedicated access to public OCI services in OSN such as Fusion Apps without the internet or an SGW?

Yes. You can leverage FastConnect in public peering mode and get your on-premises networks to connect to OCI services without going through the internet/an SGW/a DRG. With FastConnect public peering to a region, your on-premises network gets dedicated connectivity to all OCI-managed public IPs within that region. For details, please see the FastConnect documentation.

Are there any new throughput limits when using a service gateway?

No. Instances get the same throughput with the service gateway as they do when traffic is routed through an internet gateway. An SGW is a horizontally scaling and highly available fleet in each OCI region.

How much does the service gateway cost?

The service gateway is free for all Oracle Cloud Infrastructure customers.

How do all three methods of private access to OCI services compare: OCI Service Gateway, OCI Private Endpoint, and OCI Private Service Access?

All three methods of private access don’t require internet connectivity from your VCN to access OCI services and therefore traffic never traverses the internet. All three methods of private access are regional and are at the level of a VCN.

See the table below for an in-depth comparison of each private access method.

Can all three methods of private access co-exist in the same VCN?

Yes.

What are the recommended guidelines to decide the right method of private access to OCI services?

Broadly speaking:

OCI Private Service Access: Use when you need private access without code changes or reliance on public IPs, want ZPR security features and need traffic metrics.

OCI Private Endpoints: This option is best when you need to limit access to specific compartments or service-specific resources/instances (e.g., Object Storage namespace/bucket, OCI Streams) for selected clients—ideal for fine-grained control and dedicated FQDNs.

OCI Service Gateway: Use when you need higher bandwidth or simple, broad access to OCI services with less granularity and fewer security controls.

VCN security

What are security lists and why do I need them?

A security list defines security policies for controlling traffic to and from compute instances or other network resources hosted in OCI VCNs. Each security list belongs to a VCN and can be applied to one or more subnets within that VCN. When applied, the security list enforces its rules on all VNICs in the subnet, permitting or denying traffic at the VNIC level.

A security list consists of ingress and egress rules that regulate traffic entering and leaving VNICs in the subnets. Each rule specifies matching criteria, such as source or destination IP CIDR, IP protocols, and source or destination ports. Ingress rules define criteria for incoming traffic (source IP CIDR, IP protocol, source and destination ports), while egress rules define criteria for outgoing traffic (destination IP CIDR, IP protocol, source and destination ports).

Currently, OCI security lists only support permit rules. By default, all traffic is denied unless explicitly permitted by a rule, enforcing an allowlist-based security policy.

What security lists are applicable to a given instance? How is the VCN's default security list involved?

Compute instance VNICs and network resources—such as network load balancers, load balancers as a service, next-generation firewalls, or private endpoints—are subject to the security lists associated with the subnet in which they are deployed.

Each VCN has a default security list, and customers can create additional security lists as needed. A subnet can be associated with multiple security lists but must have at least one. When creating a subnet, you can specify which security lists to associate with it. If you do not specify any security list during subnet creation, the VCN’s default security list will be automatically associated with the subnet.

Security lists are applied at the subnet level, but their rules are enforced at the VNIC level.

Can I change the security lists used by my subnet after I create the subnet?

Yes. You can edit subnet properties to add or remove security lists. You can also edit the individual rules in a security list.

How many security lists and rules can I configure?

There's a limit to the number of security lists you can create, the number of lists you can associate with a subnet, and the number of rules you can add to a given list. For current service limits and instructions on how to request an increase in limits, see the service limits documentation.

Can I use "deny" rules within the security lists?

No. Security lists use only "allow" rules. All traffic is denied by default. Only network traffic matching the attributes specified in the rules is permitted.

What type of rules are supported in the security lists?

Each rule is either stateful or stateless, and either an ingress rule or an egress rule.

With stateful rules, once a network packet matching the rule is allowed, connection tracking is used and all further network packets belonging to this connection will be automatically allowed. If you create a stateful ingress rule, both incoming traffic matching the rule and the corresponding outgoing (response) traffic will be allowed.

With stateless rules, only the network packets matching the rule are allowed. If you create a stateless ingress rule, only the incoming traffic will be allowed. You need to create a corresponding stateless egress rule to match the corresponding outgoing (response) traffic.

For more information, see the security lists support documentation.

What are network security groups and how are they different from security lists?

Network security groups and security lists are two different ways to implement security rules, which are rules that control the ingress and egress traffic allowed to and from VNICs.

Security lists let you define a set of security rules that apply to all the VNICs in a given subnet. Network security groups (NSGs) let you define a set of security rules that apply to a group of VNICs of your choice, such as a group of compute instances that have the same security posture. Both network security groups and security lists are resources specific to a VCN.

For more information, see the following documentation:

• Security Rules
• Network Security Groups

Is there an ordering or priority of security rules in NSGs versus security lists?

No. By default, all traffic is denied. Security rules only allow traffic. The set of rules that applies to a given VNIC is the union of these items:

• The security rules in the security lists associated with the VNIC's subnet
• The security rules in all NSGs the VNIC is in

Which Oracle services support the use of NSGs?

Compute instance VNICs, network load balancers (NLB), load balancers as a service (LBaaS), next-generation firewalls, API gateways, streaming services, and database services can all be associated with network security groups (NSGs). When you provision these resources in your VCN, you can specify one or more NSGs from the VCN to control traffic to and from them.

Private endpoints in a VCN represent the OCI services for which they are deployed. Each private endpoint is assigned a VNIC within the VCN subnet. As with the compute instance VNICs, these private endpoint VNICs also support association with NSGs.

With the introduction of the NSG feature, do we need a security list?

The functionality of security lists remains unchanged with the introduction of NSGs. NSGs and security lists operate at different scopes and provide varying levels of granularity. Depending on your security policy requirements, you can use either one or both together.

Security lists are applied to subnets. All VNICs and network resources within a subnet are subject to the rules defined in the associated security lists. Use security lists to define common security policies that should apply to every VNIC or resource within a subnet.

NSGs, on the other hand, are applied directly to VNICs or specific resources, offering more granular control. NSGs allow you to define and assign distinct security policies to individual resources within the same subnet, or to reuse the same NSG across resources in different subnets. This enables you to decouple security policies from subnet boundaries.

A best practice is to use security lists for broad policies that affect entire subnets, and NSGs for detailed, resource-specific access control.

Security lists and NSGs are additive in their rule enforcement on a VNIC or specific resource. For a given VNIC or resource, traffic is permitted if it matches any rule in either the subnet’s security list(s) or the resource’s assigned NSG(s). Since both mechanisms support only permit rules, traffic is denied by default unless explicitly allowed by at least one rule in either policy type.

Can we define NSG as a source or destination for security rules?

When writing rules for an NSG, you have the option to specify an NSG as the source of traffic (for ingress rules) or the traffic's destination (for egress rules). The ability to specify an NSG means that you can easily write rules to control traffic between two different NSGs. The two NSGs must be in the same VCN.

Can I write security rules that control traffic explicitly between NSGs in different VCNs?

No. When you write an NSG security rule that specifies another NSG as the source or destination, that NSG must be in the same VCN. This is true even if the other NSG is in a peered VCN.

Security lists let you define a set of security rules that apply to all the VNICs in an entire subnet, while NSGs let you define a set of security rules that apply to a group of VNICs of your choice (including VNICs of load balancers or database systems) within a VCN.

Are there limits on connection tracking for security rules of NSGs and security lists?

Yes. The connection tracking limits (or size of conntrack table) for a compute instance depends on its shape, as detailed in this connection tracking table.

How does ZPR prevent lateral movement if a resource is compromised?

OCI Zero Trust Packet Routing (ZPR) prevents lateral movement by decoupling security from the network topology using security attributes.

In a traditional network, if an attacker gains control of an IP address, they can pivot to any other IP address allowed by the firewall. ZPR prevents this by using security attributes (e.g., app: database or env: production).
Policy logic: Instead of saying "Allow 10.0.0.5 to talk to 10.0.0.10," a ZPR policy says “In VCN-A, allow ‘app: web-server' to connect to 'app: database' on port 1521.”
Enforcement: Because OCI's network fabric tags every packet with the identity/security attribute of the source, even if the attacker changes their IP address or the network architecture changes, the packet will be dropped because it lacks the required security attribute. This helps ensure that only authorized identities can communicate, regardless of their location in the network.
Given that ZPR constructs apply across multiple peered VCNs and are intent-based, ZPR helps reduce misconfigurations that can occur in large network setups.

What happens to existing traffic when I apply a ZPR’s security attribute to a resource?

Traffic is immediately blocked due to ZPR’s implicit, default “Deny ALL" behavior. As soon as you apply a security attribute to a resource (such as an autonomous database or a compute instance), that resource enters ZPR-protected mode. Even if your security lists and NSGs allow all traffic, all communication will stop until you write and deploy an explicit ZPR policy that allows the specific traffic path or flow.

What are all security checklists for a VNIC?

For a packet to reach from source VNIC S to its destination VNIC D in a Virtual Network in the OCI, all three of the following conditions should be satisfied:

1. Egress allow: Allowed by at least one security rule for egress in either the security lists of a subnet of VNIC S or in NSGs of VNIC S (only if NSGs are applied to S).
2. Ingress allow: Allowed by at least one security rule for ingress in either the security lists of a subnet of VNIC D or in NSGs of VNIC D (only if NSGs are applied to D).
3. ZPR allow (only if enabled): If either VNIC S or D is ZPR tagged, the traffic must also be allowed by a ZPR policy.

In addition, you can also have an OCI Network Firewall or OCI Web Application Firewall for more diverse security enforcement. For details, refer to the documentation.

VCN routing

Where can a VCN route table be applied?

A VCN route table can be applied to a subnet, a VNIC, or a gateway associated with the VCN (internet gateway, NAT gateway, local peering gateway, service gateway, or DRG). When associated with a subnet or VNIC, the route table controls how traffic from the subnet or VNIC is routed outside of the subnet. When associated with a gateway, it manages ingress routing—that is, how the gateway routes externally originated traffic inbound into the VCN.

Since VNICs are deployed within subnets, there is a hierarchical relationship between route tables applied to a VNIC and those applied to its subnet. If a VNIC has its own VCN route table, it uses that table to control egress routing. If a VNIC does not have a dedicated route table, it defaults to using the subnet’s route table to control egress traffic. By default, VNICs do not have an associated route table and therefore inherit the subnet’s route table for routing control. For more information, see VCN Route Tables.

Can I create custom route rules in a subnet route table for traffic whose destination is within the same subnet?

No, custom route rules for intra-subnet routing are not supported on OCI. Traffic within a subnet is always routed directly to its destination. Therefore, route rules to destinations within the subnet are not allowed in the subnet route table.

Can I change the route table used by my subnet after I create the subnet?

Yes. You can edit subnet properties to change the route table. You can also edit the individual rules within the subnet’s route table.

Does VCN support source-based routing?

No, not currently. However, OCI does currently support a similar capability called per-resource routing.

How many route rules can I create in a single route table?

There's a limit to the number of rules in a route table. See the service limits documentation for more information.

Can I use a private IP as the route target in the VCN route rule?

Yes. You can use a private IP as the target of a route rule in situations where you want to route a subnet's traffic to another instance in the same VCN. For requirements and other details, see Using a Private IP as a Route Target.

What is a gateway ingress route table?

A gateway ingress route table is a VCN route table attached to a particular gateway. It controls how traffic entering the VCN through that gateway is forwarded to the next hop once it arrives at that gateway. As a result, it’s used only for inbound traffic coming into the VCN via that gateway, not for traffic originating inside the VCN.

Gateway ingress route tables enable the following two advanced transit routing use cases:

1. Gateway to gateway: This refers to the use-cases where traffic needs to go directly from one gateway of a VCN to another gateway of the same VCN, thus bypassing the VNICs/IPs within that VCN. Depending on the type of gateway, there are some restrictions. Refer Learn Routing in OCI document for further details.
2. Redirection: This refers to the use-cases where traffic needs to pass through a private IP of the VCN like that of a network virtual appliance (firewall, virtual router, etc.) or through OCI Flexible Network Load Balancer.

For details, see the transit routing documentation.

What is per-resource routing?

Per-resource routing is an OCI virtual networking feature that allows you to assign a custom VCN route table to a particular VNIC of a compute instance or to a particular IP address on a VNIC of a compute instance.

In doing so, it enables the granular control required in highly advanced setups. Learn more about per-resource routing.

What are supported targets (or next hops) for route rules of a subnet’s route table?

For route rules of a subnet’s route table, possible next hops can be either of the following:

• A gateway (DRG, LPG, NATGW, etc.) associated to the same VCN, thus directing the traffic outside the VCN
• A private IP residing in the same VCN

What are supported targets (or next hops) for route rules of gateway ingress route tables?

• Another gateway associated to the same VCN
• A private IP of a VNIC (possibly of an instance or NLB) residing in the same VCN

Depending on the type of gateway, there are certain restrictions. See Learn Routing in OCI (PDF) for further details.

Do we need route rules for intra-VCN traffic?

Each VCN route table includes an implicit local route rule for the VCN CIDR that directly routes traffic to destinations within the VCN. Therefore, you do not need to create additional route rules for intra-VCN traffic if the default local routing meets your requirements.

However, you may prefer to define custom route rules to redirect traffic through an intermediate hop, such as a firewall or load balancer. This is supported for intra-VCN traffic between two subnets—meaning the destination is in a different subnet than the source. In such cases, you can add route rules to the source subnet's route table that specify the desired intermediate hop (e.g., the private IP address of a firewall in the VCN) as the target.

Note that for intra-VCN traffic within the same subnet, the traffic is always routed directly to the destination. Custom route rules are not supported in this scenario. For more information, refer to VCN Route Tables.

VCN peering

What is VCN peering?

VCN peering is a process of connecting two VCNs to enable private connectivity and traffic flow between them. There are two general types of peering:

• Local VCN peering (or intra-region peering): The two VCNs are in the same region. They can be in the same tenancy (in the same or different compartments) or different tenancies. Local VCN peering can be done with a local peering gateway (LPG) or with a dynamic routing gateway (DRG).
• Remote VCN peering (or inter-region VCN peering): The two VCNs are in different regions. They can be in the same tenancy (in the same or different compartments), or even different tenancies. Remote VCN peering is configured with a DRG via its remote peering connection (RPC) feature.

For more information, see Access to Other VCNs: Peering.

Is VCN peering supported in all regions?

• Local VCN peering (with either LPG or DRG) is supported in all regions and realms.
• Remote VCN peering (with DRG) is supported in all regions and realms.

Why do I need VCN peering?

• With local VCN peering, you get the flexibility to organize your resources into separate VCNs and adhere to requirements for governance and regional presence, while enabling private connectivity across these VCNs. With cross-tenancy local VCN peering, you can organize your resources into separate VCNs in different tenancies, while enabling private connectivity across these VCNs. You can also enable a service provider model by providing private access to your services for multiple consumer VCNs (in different tenancies) located in the same region.
• With remote VCN peering, you can organize your resources into separate VCNs and fulfill your requirements for governance, multiregional presence, and disaster recovery while enabling private connectivity across these VCNs in different regions.

What are the benefits of local VCN peering?

Local VCN peering offers the following benefits:

• A no-cost, reliable alternative to connectivity models such as VPN, achieved by eliminating internet gateways, public IPs for instances, encryption, and performance bottlenecks
• Ease of peering enablement between VCNs with no scheduled downtime
• Private connectivity for resources in peered VCNs using the highly redundant links with predictable bandwidth and latency of the OCI network fabric.

Can I establish a remote peering connection (RPC) between two DRGs in the same region?

In almost all cases, all attachments in the same region can be attached to a single enhanced DRG for interconnectivity, eliminating the need to peer two DRGs in the same region.

However, you can use a remote peering connection between two DRGs in the same region. This can be useful in rare administrative scenarios. Some such scenarios include:

• You already have multiple VCNs on two different DRGs in the same region, and now you need interconnectivity with no downtime for existing workloads.
• You already have two networks on two different DRGs in the same region and now need to connect these networks but with controlled route distribution between them. For this purpose, you would leverage more constrained import route distribution policies on DRGs on each side of the RPC.
• Networks of each DRG need to be under the IAM access of different network administration teams.

Can I establish local peering between two VCNs with overlapping address ranges?

When locally peered with an LPG, two VCNs can’t have overlapping address ranges (IP prefixes). Moreover, once two VCNs are peered with an LPG, you can’t add new IP prefixes to any peered VCN that can overlap with those of another VCN.
On the other hand, two VCNs that are locally peered with a DRG can have overlapping IP prefixes. However, though allowed, this can result in route conflicts and thus it is not recommended.

Can I establish local peering from my VCN to two other VCNs that have overlapping IP address ranges?

Yes. If your VCN is peered with two other VCNs using LPGs, those two VCNs can have overlapping IP CIDRs.

How many local peerings can I establish per VCN?

A given VCN can have a maximum of 10 local peerings at a time when using an LPG. A given VCN can have a maximum of 300 local peerings at a time when using a DRG.

What are the benefits of remote VCN peering?

Remote VCN peering offers the following benefits:

• A low-cost, reliable alternative to connectivity models such as VPN, achieved by eliminating internet gateways, public IPs for instances, encryption, and performance bottlenecks
• Ease of peering enablement between VCNs with no scheduled downtime
• Private connectivity for resources in peered VCNs using OCI's highly redundant backbone links with predictable bandwidth and latency

Do I need an internet gateway to create a remote peering connection?

No. You establish a remote peering connection between two Dynamic Routing Gateways. The VCNs connected to each of these DRGs can communicate with each other over the OCI backbone network using this remote peering connection.

How do I establish a remote VCN peering between two VCNs?

FFor instructions, see Remote VCN Peering.

Can I establish remote peering between two VCNs with overlapping address ranges?

Two VCNs that are peered with DRGs via a remote peering connection can have overlapping IP prefixes. However, though allowed, this can result in route conflicts and thus it is not recommended.

Can I establish remote peering from my VCN to two other VCNs that have overlapping IP address ranges?

Yes, if your VCN is remotely peered with two other VCNs using a DRG, those two VCNs can have overlapping IP prefixes. However, this can result in route conflicts and thus it is not recommended.

Can I establish a remote peering connection to a VCN that belongs to another account?

Yes. For details, see Remote VCN Peering Through an Upgraded DRG and Attaching to VCNs in Other Tenancies.

Is my remote VCN peering traffic encrypted?

Yes. When you connect two VCNs in two different regions using an RPC, all the communication between them traverses the backbone of OCI. These communications are secured by the industry-standard encryption protocol MACsec, which helps ensure confidentiality for all transactions between Oracle data centers. With this level of encryption, your data is protected while in transit on the backbone. When you connect two VCNs in the same region with local peering or by using an RPC, all the communication remains within the region. It does not use the OCI backbone and is not encrypted at the link layer.

As an administrator of VCN-A, can I control connectivity to only a specific subnet on the peered VCN-B?

Yes. You can use VCN-A's route tables and different security constructs (SLs, NSGs, ZPR e.g.) to control connectivity to the peered VCN-B. You can allow connectivity to the full address range of VCN-B or limit it to one or more subnets.

In both local and remote peering, irrespective of gateways used for peering, route tables of subnets of any VCN are not automatically updated. You must create static routes in route tables of subnets of each VCN for the traffic destined to other peered VCNs. Hence you would have to update VCN-A's route tables anyway and at that time you can restrict it specific subnets of VCB-B.

Needless to say, on similar lines, VCN-B's administrator can control the connectivity to VCN-A.

Is there a performance impact based on throughput and latency over the established local peering between two VCNs?

No. Throughput and latency should be close to intra-VCN connections. Traffic over local peering has similar availability and bandwidth constraints as the traffic between instances in a VCN.

How do I observe latency between VCNs in different regions peered with an RPC?

Remote VCN peering uses the OCI inter-region backbone, which is designed to deliver superior performance and high availability characteristics. Oracle publishes and actively updates the inter-region latency dashboard directly accessible from your Oracle Cloud Account. For details, please refer to the documentation.

What is the price for VCN peering?

• Local peering (intra-region): No charge.
• Remote peering (inter-region): Remote peering itself has no charge. Only outbound data transfer is charged after a certain threshold. Refer to the latest published pricing for outbound data transfer.

VCN transit routing

What is VCN transit routing (VTR)?

VCN transit routing (VTR) is based on a hub-and-spoke topology, enabling the hub VCN to provide transit connectivity between multiple spoke VCNs (within the region) and on-premises networks. Only a single FastConnect or IPSec VPN connected to a DRG is required for an on-premises network to communicate with all the spoke VCNs via the hub VCN. VTR can be set up with just a DRG or a combination of DRG and LPG(s). The hub VCN is always connected to the DRG in this design.

How do I get started with VCN transit routing?

See the instructions in Setting Up VCN Transit Routing in the Console.

What kinds of remote networks can the spoke VCNs access using the hub VCN?

The spoke VCNs can access your on-premises networks using the hub VCN. Remote spoke VCNs connected to the hub VCN over a remote peering connection can also access other spoke VCNs directly attached to the hub VCN's DRG.

Can I configure the hub VCN to provide connectivity to spoke VCNs in remote OCI regions?

If it’s designed with LPGs and legacy DRGs, VCN transit routing only supports consolidated connectivity between VCNs in the same region. However, you can design a multi-region hub-and-spoke topology with enhanced DRGs.

Can I configure the hub VCN so a spoke VCN can access only specific subnets in the on-premises network?

Yes. You can control route advertisements to on-premises networks by customizing the route tables on the hub VCN and/or its gateways. Alternatively, you can control the access with specific SLs/NSGs on subnets/VNICs to allow traffic to/from only selected network prefixes of on-premises networks.

Can I configure the hub VCN so the on-premises network can access only specific subnets in the spoke VCN?

Yes. You control this with the route table associated with the DRG on the hub VCN. You can configure specific route rules that specify only the spoke VCN subnets that you want to make available to the on-premises network. The routes from the ingress route table associated with the hub VCN attachment are then imported to the DRG route table for advertisement to the on-premises network.

Is there a limit to the number of spoke VCNs that can peer with the hub VCN?

Yes. In LPG-only VTR design, the hub VCN is limited to a maximum of 10 spoke VCNs, as 10 is the limit for LPG peering per VCN. DRG-only VTR design can scale up to 299 spoke VCNs (based on the 300 VCN attachment limit per DRG with one hub VCN).

Can I configure the hub VCN so the on-premises network can access Oracle services?

Yes. You need to take all the following steps:

1. Add a service gateway to the hub VCN that is connected to your on-premises network by way of FastConnect or Site-to-Site VPN.
2. Configure a gateway ingress route table on the hub VCN's route table associated to the DRG attachment with the OSN service moniker desired and a SGW as the next hop.
3. Configure a gateway ingress route table on OCI Service Gateway attached to the hub VCN that targets the DRG attachment as the next hop for destination IP prefixes of your on-premises network.

On-premises hosts can use their private IPs when communicating with Oracle services. This traffic does not go over the internet. For more information, see Transit Routing: Private Access to Oracle Services.

Can I enable routing via a network virtual appliance (such as a firewall instance) in the hub VCN?

Yes. You can set up transit routing through a private IP in the hub VCN. In this case, you route the traffic to a private IP on the firewall instance in the hub VCN. The firewall instance can inspect all traffic between your on-premises network and spoke VCNs.

Consult the documentation for details on transit routing through a private IP.

Are there any performance limits related to VCN transit routing?

If you are routing via a firewall instance (or any other network virtual appliance) in the hub VCN, the performance limits are based on the I/O characteristics of the network virtual appliance. If you're not routing the traffic through a network virtual appliance—and are routing directly through the hub VCN's gateways—there are no performance limits. These gateways are virtual devices that are highly available and can dynamically scale to support the bandwidth requirements of your network.

DHCP options

What are DHCP options?

The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on an IP network. Configuration parameters and other control information are carried to the instance in the options field ( RFC 2132) of the DHCP message. Each subnet in a VCN must have a single set of DHCP options associated with it.

How are IP addresses configured on network interfaces on OS with VCN’s DHCP?

For applications to leverage IPs assigned to VNICs, the VNICs need to be configured properly on network interfaces on the OS/instance level. You will see one-to-one correspondence between VNIC and network interfaces on the OS level by matching their MAC addresses.

For IP addresses of primary VNICs, DHCP clients of OS/instances will communicate with the DHCP service managed by the VCNs and will autoconfigure them.

Details are listed in table below:

**Users need to statically configure the IP, netmask, and routing for network interfaces at the OS level explicitly.

Also note that most OCI images disable DHCP on non-primary interfaces by default. For guidance, please refer to the OCI documentation: Configuring the Instance OS for Secondary VNICs and Private IP Addresses. Specifically for Oracle Linux, OCI provides utilities to simplify configurations of IPs and network interfaces at the OS level.

Which DHCP options can I configure?

You can configure two options that control how instances in your VCN resolve domain name system (DNS) hostnames:

• Search domain - You can specify a single search domain.
• DNS type - Choose either:
  • Internet and VCN resolver (default)
  • Custom resolver (you can specify up to three DNS servers of your choice that are set up, managed, and maintained by you)

When resolving a DNS query, the instance's OS uses the DNS servers specified by DNS type. On most Linux images, the resolver configuration in /etc/resolv.conf (including options such as ndots) controls how the OS treats short (non-FQDN) names and when it appends the DHCP-provided search domain when resolving such short names. This is standard OS resolver behavior, not specific to OCI. For more information, see DHCP Options.

Can I change the DHCP options used by my subnet after I create it?

Yes. You can edit subnet properties to change which set of DHCP options the subnet uses. You can also change the values of the DHCP options.

Domain name system (DNS)

How do I configure a DNS hostname for my instance?

When you launch an instance, you can specify a hostname for the instance, along with a display name. This hostname, combined with the subnet's domain name, becomes the fully qualified domain name (FQDN) of your instance. This FQDN is unique within the VCN and resolves to the private IP address of your instance. For more details, see DNS in a Virtual Cloud Network.

Note that to specify a hostname for the instance, the VCN and subnet must be configured to enable DNS hostnames.

How do I configure the VCN and subnet to enable hostnames?

When you create a VCN, you can specify its DNS label. This, combined with the parent domain oraclevcn.com, becomes the domain name of the VCN.

When you create a subnet, you can specify its DNS label. This, combined with the VCN's domain name, becomes the domain name of the subnet.

You can enable a hostname for a compute instance only if the VCN and subnet are both created with a DNS label.

What is a DNS hostname of a compute instance?

A DNS hostname is a name that corresponds to the IP address of an instance connected to a network. In the case of an OCI VCN, every instance can be configured with a DNS hostname that corresponds to the private address of the instance.

A fully qualified domain name (FQDN) of an instance looks like hostname.subnetdnslabel.vcndnslabel.oraclevcn.com, where hostname is the DNS hostname of the instance, and subnetdnslabel, vcndnslabel are the DNS labels of the instance's subnet and the VCN respectively.

The parent domain oraclevcn.com is reserved for use with DNS hostnames created in Oracle Cloud Infrastructure.

Can I rename the hostname of my instance?

Yes, you can change it on the OCI Console or via API. If you change the hostname directly on the instance, the FQDN of the instance does not get updated.

Can I rename the DNS label of an existing VCN or a subnet?

No.

If my subnet is configured to use a custom resolver for DNS, are DNS hostnames created for instances in this subnet?

Yes. DNS hostnames are created for instances regardless of the DNS type selected for the subnet.

Can my instance resolve hostnames of instances in other VCNs?

No, not by default. By default, the instance can resolve hostnames only of instances within the same VCN. To resolve hostnames across VCNs, either private views must be attached to the VCN resolver or listening endpoints, forwarding endpoints, and forwarding rules must be configured.

Can I configure my custom DNS servers to resolve VCN internal DNS hostnames?

Yes, you can do this with custom DNS servers set up within the VCN. You can configure your custom DNS servers to use 169.254.169.254 as the forwarder for the VCN domain (like contoso.oraclevcn.com).

Note that the custom DNS servers must be configured in a subnet that uses "internet and VCN resolver" as the DNS type (to allow access to the 169.254.169.254 IP address).

For an example of an implementation with the OCI Terraform provider, see Hybrid DNS Configuration.

Billing

Do I get charged for using a VCN?

There is no charge for creating and using VCNs. However, usage charges for other OCI services (including compute and block volumes) and data transfer charges apply at the published rates. There are no data transfer charges for any communication among resources within a VCN.

How will I be charged for using OCI Site-to-Site VPN to connect to my VCN?

OCI Site-to-site VPN is a free managed service. There are no per-tunnel charges or data transfer fees for VPN traffic.

What are my usage charges if I use other resources, such as the database or object storage service, from instances inside my VCN?

You don’t incur data transfer charges when accessing other public OCI services, such as object storage, in the same region. All network traffic via private or public IPs between your instances and other resources inside your VCN, such as a database or load balancer, is free of data transfer charges.

If you access public OCI resources via your VPN from inside your VCN, you incur the published outbound data transfer charges.

Do your prices include taxes?

Unless otherwise noted, the OCI prices—including outbound data transfer charges—exclude applicable taxes and duties, including VAT and any applicable sales tax.