Route Tables

This topic describes how to manage the route tables  in a virtual cloud network (VCN).


Avoid entering confidential information when assigning descriptions, tags, or friendly names to your cloud resources through the Oracle Cloud Infrastructure Console, API, or CLI.

Overview of Routing for Your VCN

Your VCN uses virtual route tables to send traffic out of the VCN (for example, to the internet, to your on-premises network, or to a peered VCN). 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 basics about routing in your VCN:

  • The primary routing scenario is for sending a subnet's traffic to destinations outside the VCN. A subnet has a single route table of your choice associated with it. All VNICs in that subnet are subject to the rules in the route table. The rules govern how the traffic leaving the subnet is routed.
  • Traffic within the VCN is automatically handled by the VCN local routing. No route rules are required to enable that traffic. And in general: for any route table that belongs to a given VCN, you can't create a rule that lists that VCN's CIDR (or a sub-section) as the rule's destination. Oracle uses a subnet's route table only if the destination IP address is not within the VCN's CIDR block.
  • 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).
  • IPv6 addressing and routing is currently supported only in the US Government Cloud. For more information, see IPv6 Addresses.

For important details about routing between your VCN and on-premises network, see Routing Details for Connections to Your On-Premises Network.

Working with Route Tables and Route Rules

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 (custom) 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 change which route table the subnet uses at any time. You can also edit a route table's rules, or remove all the rules from the table.

You may optionally assign a descriptive name to a custom 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.

A route rule specifies a destination CIDR block and the target (the next hop) for any traffic that matches that CIDR. Here are the allowed types of targets for a route rule:


You can't delete a particular resource if it's the target in a route rule. For example, you can't delete an internet gateway that has traffic routed to it. You must first delete all rules (in all route tables) with that internet gateway as the target.

When adding a route rule to a route table, you provide the destination CIDR block and target (plus the compartment  where the target resides). Exception: if the target is a service gateway , 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 might be dropped (blackholed) or sent to an unintended target.

You can move route tables from one compartment to another. Moving a route table doesn’t affect its attachment to VCNs or subnets. When you move a route table to a new compartment, inherent policies apply immediately and affect access to the route table. For more information, see Access Control.

You can't delete a VCN's default route table. To delete a custom route table, it must not be associated with a subnet yet. Or, in the advanced scenario of transit routing, it must not be associated with a DRG attachment or LPG in the VCN.

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

Required IAM Policy

To use Oracle Cloud Infrastructure, you must be given the required type of access in a policy  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 compartment  you should work in.

For administrators: see IAM Policies for Networking.

Advanced Scenarios: Transit Routing

This documentation includes a few basic networking scenarios to help you understand the Networking service and generally how the components work together. See scenarios A, B, and C in Networking Scenarios

Scenarios A–C show your on-premises network connected to a VCN by way of FastConnect or VPN Connect, and accessing only the resources in that VCN.

The following advanced routing scenarios give your on-premises network additional access beyond the resources in the connected VCN. Traffic travels from your on-premises network to the VCN, and then transits through the VCN to its destination. See these topics:

Both of the transit routing scenarios involve creating route tables that you associate with a gateway instead of a subnet.

For example:

The Networking service imposes restrictions on how the route tables can be used:

  • DRG attachment: If you associate a route table with the DRG attachment on a VCN, the route table can contain only rules that use an LPG on the VCN, a service gateway on the VCN, or a private IP in the VCN as the target.
  • LPG or service gateway: If you associate a route table with an LPG or a service gateway, the route table can contain only rules that use the VCN's attached DRG or a private IP in the VCN as the target.

A DRG attachment or LPG can exist without a route table associated with it. However, after you associate a route table with a DRG attachment or LPG, there must always be a route table associated with it. But, you can associate a different route table. You can also edit the table's rules, or delete some or all of the rules.

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 appliance (NVA) 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.
  • 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:

    • Target type: Private IP.
    • Destination CIDR block: If all traffic leaving the subnet needs to go to the private IP, use
    • 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.
    • Description: An optional description of the rule.

As mentioned earlier, you must configure the instance itself to forward packets.

Using the Console

To view a VCN's default route table
To update rules in an existing route table
To create a route table
To change which route table a subnet uses
To move a route table to a different compartment
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: