Oracle Cloud Infrastructure Documentation

Route Tables

This topic describes how to manage the Virtual route table for your VCN that provides mapping for the traffic from subnets via gateways to external destinations. in a virtual cloud network (VCN).


Oracle recommends that you avoid using string values that include confidential information in the Oracle Cloud Infrastructure Console, API, or CLI.

Working with Route Tables

Your cloud network uses virtual route tables to send traffic out of the VCN (for example, to the internet or to your on-premises network). These virtual route tables have rules that look and act like traditional network route rules you might already be familiar with. Each rule specifies a destination CIDR block and the target (the next hop) for any traffic that matches that CIDR. Here are a few details about routing in your VCN:

  • When routing traffic, Oracle uses a subnet's route table only if the destination IP address is not within the VCN's CIDR block. No route rules are required in order to enable traffic within the VCN itself.
  • If a route table has overlapping rules, Oracle uses the most specific rule in the table to route the traffic (that is, the rule with the longest prefix match).
  • If there is no route rule that matches the network traffic you intend to route outside the VCN, the traffic is dropped (blackholed).

Here are the allowed types of targets for a route rule:

Each VCN automatically comes with a default route table that has no rules. If you don't specify otherwise, every subnet uses the VCN's default route table. When you add route rules to your VCN, you can simply add them to the default table if that suits your needs. However, if you need both a public subnet and a private subnet (for example, see Scenario C: Public and Private Subnets with a VPN), you instead create a separate route table for each subnet.

Each subnet in a VCN uses a single route table. When you create the subnet, you specify which one to use. You can't change which route table a subnet uses after the subnet is created, so make sure to create the route table before creating the subnet. However, remember that you can also change a table's rules.

You may optionally assign a friendly name to the route table during creation. It doesn't have to be unique, and you can change it later. Oracle automatically assigns the route table a unique identifier called an Oracle Cloud ID (OCID). For more information, see Resource Identifiers.

When adding a route rule to a route table, you provide the destination CIDR block and target (plus the A collection of related resources that can be accessed only by certain groups that have been given permission by an administrator in your organization. where the target resides). Exception: if the target is a An optional virtual router that you can add to your VCN to provide a path for private network traffic between your VCN and a public Oracle Cloud Instrastructure service such as Object Storage., instead of a destination CIDR block, you specify an Oracle-provided string that represents the public endpoints for the service of interest. That way you don't need to know all the service's CIDR blocks, which might change over time.

If you misconfigure a rule (for example, enter the wrong destination CIDR block), the network traffic you intended to route will be dropped (blackholed) if there's no other rule in the table that matches that trafic.

To delete a route table, it must not be associated with a subnet yet. You can't delete a VCN's default route table.

For information about the maximum number of route tables and route rules, see Service Limits.

Using a Private IP as a Route Target

If you're not familiar with the definition of a private IP, see Private IP Addresses. In short: a private IP is an object that contains a private IP address and related properties and has its own OCID.

General Use Cases

As mentioned earlier, Oracle uses a given subnet's route table only for traffic with a destination IP address outside the VCN. Typically you set up one or more rules to route that traffic to a gateway on the VCN (for example, a DRG connected to your on-premises network, or an internet gateway connected to the internet). However, you might want to route that traffic (going to destinations outside the VCN) through an instance in the VCN first. In that case, you can use a private IP in the VCN as the target instead of a gateway on the VCN. Here are a few reasons you might do this:

  • To implement a virtual network function (such as a firewall or intrusion detection) that filters outgoing traffic from instances.
  • To manage an overlay network on the VCN, which lets you run container orchestration workloads.
  • To implement Network Address Translation (NAT) in the VCN. Note that Oracle instead recommends using a NAT gateway with your VCN. In general, NAT enables outbound internet access for instances that don't have direct internet connectivity.

To implement these use cases, there's more to do than simply route traffic to the instance. There's also configuration required on the instance itself.


You can enable high availability of the private IP route target by using a secondary private IP address. In the event of a failure, you can move the secondary private IP from an existing VNIC to another VNIC in the same subnet. See To move a secondary private IP to another VNIC in the same subnet (Console instructions) and UpdatePrivateIp (API instructions).

Requirements for Using a Private IP as a Target

  • The private IP must be in the same VCN as the route table.
  • The private IP's VNIC must be configured to skip the source/destination check so that the VNIC can forward traffic. By default, VNICs are configured to perform the check. For more information, see Source/Destination Check.
  • You must configure the instance itself to forward packets. For more information, see NAT Instance Configuration.
  • The route rule must specify the OCID of the private IP as the target, and not the IP address itself. Exception: If you use the Console, you can instead specify the private IP address itself as the target, and the Console determines and uses the corresponding OCID in the rule.


    A route rule with a private IP target can result in blackholing in these cases:

    • The instance the private IP is assigned to is stopped or terminated
    • The VNIC the private IP is assigned to is updated to enable the source/destination check or is deleted
    • The private IP is unassigned from the VNIC

    When a target private IP is terminated, in the Console, the route rule displays a note that the target OCID no longer exists.

    For failover: If your target instance is terminated before you can move the secondary private IP to a standby, you must update the route rule to use the OCID of the new target private IP on the standby. The rule uses the target's OCID and not the private IP address itself.

General Setup Process

  1. Determine which instance will receive and forward the traffic (the NAT instance, for example).
  2. Choose a private IP on the instance (can be on the instance's primary VNIC or a secondary VNIC). If you want to implement failover, set up a secondary private IP on one of the VNICs on the instance.
  3. Disable the source/destination check on the private IP's VNIC. See Source/Destination Check.
  4. Get the OCID for the private IP. If you're using the Console, you can get either the OCID or the private IP address itself, along with the name of the private IP's compartment.
  5. For the subnet that needs to route traffic to the private IP, view the subnet's route table. If the table already has a rule with the same destination CIDR but a different target, delete that rule.
  6. Add a route rule with the following:
    • Destination CIDR block: If all traffic leaving the subnet needs to go to the private IP, use
    • Target type: Private IP.
    • Compartment: The compartment of the private IP.
    • Target: The OCID of the private IP. If you're using the Console and instead enter the private IP address itself, the Console determines the corresponding OCID and uses it as the target for the route rule.

As mentioned earlier, you must configure the instance itself to forward packets. For more information, see NAT Instance Configuration.

Required IAM Policy

To use Oracle Cloud Infrastructure, you must be given the required type of access in a An IAM document that specifies who has what type of access to your resources. It is used in different ways: to mean an individual statement written in the policy language; to mean a collection of statements in a single, named "policy" document (which has an Oracle Cloud ID (OCID) assigned to it); and to mean the overall body of policies your organization uses to control access to resources. written by an administrator, whether you're using the Console or the REST API with an SDK, CLI, or other tool. If you try to perform an action and get a message that you don’t have permission or are unauthorized, confirm with your administrator the type of access you've been granted and which A collection of related resources that can be accessed only by certain groups that have been given permission by an administrator in your organization. you should work in.

For administrators: see IAM Policies for Networking.

Tagging Resources

You can apply tags to your resources to help you organize them according to your business needs. You can apply tags at the time you create a resource, or you can update the resource later with the desired tags. For general information about applying tags, see Resource Tags.

Using the Console

To view a cloud network's default route table
To update a route table
To create a route table
To delete a route table
To manage tags for a route table

Using the API

For information about using the API and signing requests, see REST APIs and Security Credentials. For information about SDKs, see Software Development Kits and Command Line Interface.

To manage a VCN's route tables, use these operations: