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).

Warning

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.
  • 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).

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:

Note

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 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. The gateway enables cloud resources to privately access Oracle services (such as Object Storage and Autonomous Database) without exposing the resources to the public internet., 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'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.

Advanced Scenario: Transit Routing

There's an advanced routing scenario called transit routing that enables communication between an on-premises network and multiple VCNs over a single Oracle Cloud Infrastructure FastConnect or IPSec VPN. The scenario involves creating route tables that you associate with a DRG attachment or an LPG on that VCN, instead of a subnet. The Networking service imposes restrictions on how the route tables can be used:

  • 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 as the target.
  • Similarly, if you associate a route table with an LPG, the route table can contain only rules that use the VCN's attached DRG 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 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.

Tip

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.

    Important

    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 0.0.0.0/0.
    • 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 rules in an existing route table
To create a route table
To change which route table a subnet uses
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: