VCN Route Tables

This topic describes how to manage the route tables  in a virtual cloud network (VCN). For more on route tables in a Dynamic Routing Gateway (DRG), see Dynamic Routing Gateways.

Overview of Routing for Your VCN

Your VCN uses 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 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 subnet. 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.
  • VCN local routing automatically handles traffic within the VCN's subnets. Local routing does not require defining route rules to enable traffic.
  • You can also use intra-VCN routing to specify a next-hop private IP, LPG, or DRG within a VCN for traffic destined to another subnet in the VCN. Intra-VCN routing enables more complex security and network virtualization use cases. OCI also supports intra-VCN routing for traffic entering a VCN through a gateway in addition to traffic between subnets.
  • 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). Two CIDRs are said to overlap when one CIDR is contained within the other. VCN route tables contain entries for the local VCN routes. If you create a static route for the VCN CIDR block (with the same prefix length as the VCN local route), the static route takes precedence.
  • If no route rule matches the network traffic you intend to route outside the VCN, the traffic is dropped (blackholed).
  • IPv6 addressing is supported for all commercial and government regions. 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 implicit rules which include the routes for VCN CIDRs. 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. However, you can create custom route tables for each subnet if needed. For example, when you have a public subnet and a private subnet in your VCN (for an example, see Scenario C: Public and Private Subnets with a VPN), you'll need to use different route tables for the subnets because the route rules for the subnets need to be different.

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 can 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 when it is the target for a route rule. For example, you can't delete an internet gateway that has traffic routed to it. Delete all rules (in all route tables) with that internet gateway as the target before you try to delete the gateway or other resource.

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 a 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 or a gateway, such as DRG, LPG, IGW, NGW or SGW.

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

Intra-VCN Routing

Intra-VCN routing allows you to override the default routing decisions applied to traffic destined to IP addresses contained within the VCN CIDR block. Intra-VCN routing has the following capabilities:

  • Default routes: Every VCN route table has an implicit local route for the VCN CIDR. It is used in local direct routing to destinations in the VCN. Together with custom routes in the route table, this implicit local route is used in the best route selection.
  • Custom intra-VCN routes: Route rules you create in the route table for intra-VCN traffic. All custom routes have a target (DRG, LPG, private IP in the VCN) and a route type of static.
  • Route Selection: The longest prefix match (or most specific route) is selected. If there are multiple routes for the same prefix, the best route is selected based on the following route type priority:
    1. Static (user-defined)
    2. Implicit local routes (created automatically by OCI)
  • IPv6: OCI supports intra-VCN routing for IPv6 VCN prefixes.
Note

Intra-subnet routing is not supported. Traffic with a destination IP address in the same subnet as the originating VNIC is forwarded (not routed) directly to the appropriate destination.

Gateway Ingress Routing

Traffic leaving a subnet is routed by using the subnet route table. Traffic entering a subnet is routed using a gateway route table (a route table associated with that gateway). Route rules for gateway ingress routing are supported in route tables associated with the following resources:
  • Local Peering Gateway (LPG)
  • Dynamic Routing Gateways
  • Internet Gateways
  • NAT Gateways
  • Service Gateways
Note

If you associate a route table with one of these gateways, afterward the gateway must always have an associated route table. The associated route table's rules can be modified or removed. For an internet gateway, the target must be in a public subnet.

Intra-VCN Routing Usage

In the following example, all traffic flowing between the internet and VNICs in a VCN is routed through a security appliance in Subnet-A. Also, traffic between subnets will go through the same firewall. To implement this example, you would:
  1. Create static route rules in the IGW route table that specify a next hop of 10.0.1.4 (a firewall) for inbound traffic.
  2. Create route tables for subnets A, B, and C. Traffic from the internet to subnet B and C must go through the firewall appliance at 10.0.1.4 in subnet A. Traffic between subnet B and C must go through the same firewall.

The following image shows an example of internal routing:

Internal Routing example diagram
Callout 1: IGW route table
Destination Target Route Type
10.0.0.0/16 10.0.1.4 Static
Callout 2: Subnet A route table
Destination Target Route Type
0.0.0.0/0 IGW Static
Callout 3: Subnet B route table
Destination Target Route Type
10.0.0.0/16 10.0.1.4 Static
0.0.0.0/0 10.0.1.4 Static
Callout 4: Subnet C route table
Destination Target Route Type
10.0.0.0/16 10.0.1.4 Static
0.0.0.0/0 10.0.1.4 Static

Required IAM Policy

To use Oracle Cloud Infrastructure, you must be granted security access in a policy  by an administrator. This access is required whether you're using the Console or the REST API with an SDK, CLI, or other tool. If you get a message that you don’t have permission or are unauthorized, verify with your administrator what type of access you have and which compartment  to work in.

For administrators: see IAM Policies for Networking.

VCN Route Table Limits

This section is specific to limits for VCN route tables. DRG route table limits are provided in the DRG Route Table Limits section.

Resource Scope Oracle Universal Credits Pay As You Go or Trial
VCN Route tables VCN 300 300
Route rules VCN Route table 200 200

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

OCI uses a given subnet's route table to route traffic to a destination IP address that is outside of the subnet. If the destination is outside the VCN, typically you set up a route rule to route the traffic to a gateway on the VCN (for example, a DRG connected to your on-premises network or another VCN, or an Internet gateway connected to the Internet). If the destination is in another subnet of the same VCN, by default the traffic is routed using the local route for the VCN CIDR. However, you might want to route that traffic 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 in 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.

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 Moving a Secondary Private IP Address to a Different VNIC (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 Overview of VNICs and Physical NICs.
  • 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.

    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.
  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 Overview of VNICs and Physical NICs.
  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: See the list of target types in Overview of Routing for Your VCN. If the target type is a DRG, the VCN's attached DRG is automatically selected as the target, and you don't have to specify the target yourself. If the target is a private IP object, before you specify the target you must first disable the source/destination check on the VNIC that uses that private IP object. For more information, see Using a Private IP as a Route Target.
    • Destination CIDR Block: Available only if the target is not a service gateway. The value is the destination CIDR block for the traffic. You can provide a specific destination CIDR block, or use 0.0.0.0/0 if all traffic leaving the subnet needs to be routed to the target specified in this rule.
    • Destination Service: Available only if the target is a service gateway. The value is the service CIDR label that you're interested in.
    • Compartment: The compartment where the target is located.
    • Target: The target. If the target is a private IP object, enter its OCID. Or you can enter the private IP address itself, in which case 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.