X

Best Practices from Oracle Development's A‑Team

Basic Routing Scenarios For The Enhanced DRG

Ben Woltz
Principal Cloud Architect

Introduction

In this blog post we will explore some of the new features and functionality of the recently enhanced version of the Dynamic Routing Gateway (DRG).  This updated version of the DRG is now available in all commercial OCI regions, and any newly created DRGs have the updated features by default.  Any DRGs created before June, 2021 may use the legacy version but can be upgraded to the new version.

The legacy DRG was a virtual router that you could use to route your Virtual Cloud Network (VCN) traffic to and from:

  • On premise networks via IPSec tunnels
  • On premise networks via FastConnect virtual circuits
  • Other VCNs in remote OCI regions via Remote Peering Connections (RPC)

The legacy DRG had the below limitations that have been addressed in the new DRG version:

  • VCN Attachment
    The legacy DRG could only be attached to a single VCN in the same region.  In order for customers to connect multiple VCNs in the same region, a Local Peering Gateway (LPG) would be required which was limited to 10 VCN peerings.
  • FastConnect and Site-to-Site Virtual Private Network (VPN)
    Connectivity from on premise networks via FastConnect or IPSec tunnels on the legacy DRG was limited to reaching resources in the local region where the DRG is provisioned.  Customers wishing to connect from on premise networks to resources in another region from where the DRG is provisioned were forced to setup a separate FastConnect or IPSec tunnel to that other region.
  • Legacy DRG Route Table
    Legacy DRG includes a route table that by default routes all traffic between on premise networks and the VCN it's attached to with no ability to modify that behavior.

    
New enhanced DRG version features:

  • VCN Attachment
    The new enhanced DRG now supports multiple VCN attachments within the same region.  VCN to VCN traffic inside the same region can now pass through a mutually connected DRG instead of an LPG.  This feature allows customers to now connect up to 300 local VCNs together opposed to the 10 VCN limit on the LPG.
  • FastConnect and Site-to-Site VPN
    Customers can now reach resources in a remote region from on premise networks via FastConnect or IPSec tunnels to one region.  Traffic would flow from on premise to one region over FastConnect or IPSec tunnel to the new DRG, and then routed over an RPC connection to another region over the OCI backbone.
  • Enhanced DRG Route Table
    You can now have a configurable route table for each network attachment which gives customers more granular control of routing and the ability to meet more complex routing requirements.

    
DRG Attachments, Route Tables, and Route Distributions

The new enhanced DRG can have multiple network attachments:

  • VCN Attachments
  • RPC Attachments
  • IPSec Tunnel Attachments
  • Virtual Circuit (VC) Attachments

One way to think of a DRG attachment is to think of them as interfaces that you plug into a traditional physical router.  You are basically attaching the DRG virtual router to different networks you want the DRG to connect to.

Each DRG attachment will have a route table that is applied to inbound traffic.  When a packet enters a DRG, it is routed using rules in the DRG attachment route table assigned to that attachment to make its forwarding decision.  When you create a DRG, two route tables are autogenerated for you by default.  One for VCN attachments which will apply to traffic entering the DRG from the VCN, and one for all other attachments (RPC, IPSec, VC) that will apply to traffic entering the DRG from the RPC, IPsec or VC.  These are autogenerated for you and applied to the attachments by default, but you can manually create additional route tables and assign them to attachments as well.

The DRG route tables support both static and dynamic routes.  Static routes can be added manually via the OCI console, while dynamic routes are imported and exported to and from the attachments.  The new enhanced DRG gives customers more granular control of the routes being imported  or exported using import or export route distributions.  An import route distribution is autogenerated for each of the two autogenerated route tables (one for VCN attachment and one for IPSec, VC, and RPC attachments).  By default all routes are imported into the VCN attachment route table, and all VCN routes are imported into the attachment route table for all other attachments.  There is also a default export route distribution that exports all routes that is applied to all attachment route tables.  This means by default you will not need to make any changes to the routing tables or route distributions for simple routing behavior between VCN attachments and IPSec, VC, and RPC attachments.  

Routing Scenario 1 - Routing from On Premise to a Private Subnet in OCI

In this scenario we are going to establish basic connectivity from on premise networks (192.168.0.0/16) to a private subnet in a VCN (10.0.0.0/24).  The good news is the autogenerated route tables and import/export route distributions discussed above are generated to allow for this connectivity with minimal changes.  

You must create the DRG first before you create an IPSec VPN or FastConnect, however when you create the IPSec VPN or FastConnect it is automatically attached to the DRG for you and the autogenerated route table, import and export route distributions are applied to that attachment as well.  The DRG is not automatically attached to the VCN however, so you will need to manually do that by going to the DRG and clicking Create Virtual Cloud Network Attachment under the Virtual Cloud Network Attachments resource and selecting your VCN (See below).  Don't forget to add route rules in your subnet routing table to point the on premise networks to the DRG route target and modify any Security Lists or Network Security Groups to permit the traffic.  

Routing Scenario 2 - Routing from On Premise to the Oracle Services Network

This scenario builds upon what we have already setup in Scenario 1, but instead of communicating between on premise networks and the private subnet in the VCN, we will be using the VCN as a transit network to route between on premise networks and resources in the Oracle Services Network (OSN).

First let's dig a little deeper on the VCN attachment to understand the routing.  The VCN attachment, unlike the other attachment types, actually has 2 routing tables.  One is the DRG routing table for traffic entering the DRG from the VCN attachment.  By default this is the autogenerated routing table discussed above which will automatically contain the dynamic routes for the VCN subnets and on premise networks it learns from the IPSec or Fast Connect attachment.  The second routing table is the VCN routing table for traffic leaving the DRG and entering the VCN through the attachment.  This routing table was not required in Scenario 1 because there is a hidden implicit routing table used by default that will always permit connectivity to all the subnets in the VCN.  However, if you want to use the VCN as a transit network as in Scenario 2, we must create this VCN route table and apply it to the DRG VCN attachment shown below to route the OSN network.  The below assumes you already have a Service Gateway for the VCN and associated a route table to the Service Gateway routing your on premise networks to the DRG.

Create a route table for the DRG VCN Attachment

  1. Click on the VCN under Networking >> Virtual Cloud Networks
  2. On the left hand side under the Resources menu, click Route Tables
  3. Click the blue button "Create Route Table"
  4. Give it a name, for example DRG_Route_Table
  5. Under Route Rules click the "+ Another Route Rule" button
  6. Select Service Gateway for target type
  7. Destination CIDR Block we will select the OSN services that you need access to from on premise,  Object Storage or All Services within that region
  8. Target Service Gateway select the Service Gateway you created 
  9. Click the blue Create button

Associate route table to the DRG VCN Attachment

  1. Click on the DRG under Networking >> Customer Connectivity >> Dynamic Routing Gateways
  2. Click on the VCN Attachment Name
  3. Click the gray Edit button at the top
  4. Select Advanced Options
  5. Select VCN route table tab
  6. Click the Select Existing radio button
  7. Select the DRG route table you created in the above section in the drop down box.  In our example this is DRG_Route_Table

Routing Scenario 3 - Routing from On Premise to another region through a single VPN or FastConnect

In Scenario 1 above we leveraged a VPN or FastConnect in Ashburn to connect to a VCN in the same Ashburn region. If you recall from the Introduction section above, one of the limitations of the legacy DRG was only allowing customers to connect from on premise to a single region where the VPN or FastConnect terminated in.  If a customer wanted to reach a remote region, this would require provisioning another VPN or FastConnect from on premise to the remote region. In this Scenario 3 we will establish connectivity from on premise (192.168.0.0/16) to a private subnet in a VCN in Phoenix region (172.16.0.0/24) utilizing the same VPN or FastConnect from Scenario 1 in Ashburn and the new enhanced DRG functionality.

In order to connect between two OCI regions, we will utilize a Remote Peering Connection (RPC) on the DRG.  It is assumed that the Phoenix DRG is already provisioned and attached to the Phoenix VCN.

On the Ashburn DRG:

  1. Click on the DRG under Networking >> Customer Connectivity >> Dynamic Routing Gateways
  2. Click on Remote Peering Connection Attachments on the left side under Resources
  3. Click the blue button labeled "Create Remote Peering Connection" and give it a name, for example "Phoenix RPC"

On the Phoenix DRG:

  1. Click on the DRG under Networking >> Customer Connectivity >> Dynamic Routing Gateways
  2. Click on Remote Peering Connection Attachments on the left side under Resources
  3. Click the blue button labeled "Create Remote Peering Connection" and give it a name, for example "Ashburn RPC"

Once you have the Remote Peering Connections created on both DRGs, the next step is to peer the two RPCs as each one needs to know about the other before peering can happen.  The process is simple, you only need to tell one DRG RPC what the other RPC OCID is and they will establish a peering relationship.  You can do this in either of the RPCs, we will outline the steps to initiate a peering relationship from Phoenix.

On the Ashburn DRG:

  1. Click on the DRG under Networking >> Customer Connectivity >> Dynamic Routing Gateways
  2. Click on Remote Peering Connection Attachments on the left side under Resources
  3. Click on the Remote Peering Connection you named earlier, in our example it's "Phoenix RPC"
  4. Click the Copy option in the top right under OCID:.  This will copy the Ashburn RPC OCID into your clipboard as we will need it to establish the peering in Phoenix.

On the Phoenix DRG:

  1. Click on the DRG under Networking >> Customer Connectivity >> Dynamic Routing Gateways
  2. Click on Remote Peering Connection Attachments on the left side under Resources
  3. Click on the Remote Peering Connection you named earlier, in our example it's "Ashburn RPC"
  4. Click on the blue button labeled "Establish Connection"
  5. Select the region, in our example it's Ashburn which is us-ashburn-1
  6. And paste the Ashburn RPC OCID in your clipboard in the Remote Peering Connection OCID field
  7. Click on the blue button labeled "Establish Connection"

If you recall earlier from the Introduction section, the new enhanced DRG will autogenerate two DRG routing tables.  One for the VCN attachment, and the other is for all other attachments (RPC, IPSec, FC).  So far in Scenario 1 and Scenario 2 those autogenerated routing tables work without any changes, however for Scenario 3 we will need to make some changes here.  The issue is the autogenerated DRG route table for the RPC, IPSec, FC is by default configured with an import route distribution that imports routes from VCN attachments only.  This worked for us in Scenario 1 and Scenario 2, however for this Scenario it means that the on premise route for 192.168.0.0/16 will not propagate over the RPC connection to Phoenix, and vice versa as the Phoenix route for VCN 172.16.0.0/24 will not propagate to on premise.  In order to accomplish this we will create two separate route tables in Ashburn, one for the IPSec/VC attachment and the other for the RPC attachment and we will be specific on what types of routes to import. 

On the Ashburn DRG - Create Import Route Distribution for On Prem

  1. Click on the DRG under Networking >> Customer Connectivity >> Dynamic Routing Gateways
  2. Click on Import Route Distributions on the left side under Resources
  3. Click on the blue button labeled Create Import Route Distribution
  4. Name it Import_Onprem
  5. Under Route Distribution Statements create two statements with different priority numbers.  One with Attachment Type RPC and the other with Attachment Type VCN
  6. Click blue button labeled Create Import Route Distribution

On the Ashburn DRG - Create Import Route Distribution for RPC

  1. Click on the DRG under Networking >> Customer Connectivity >> Dynamic Routing Gateways
  2. Click on Import Route Distributions on the left side under Resources
  3. Click on the blue button labeled Create Import Route Distribution
  4. Name it Import_RPC
  5. Under Route Distribution Statements create a statements with Attachment Type IPSec Tunnel or Virtual Circuit depending on your on prem connection
  6. Click blue button labeled Create Import Route Distribution

On the Ashburn DRG - Create Route Table for On Prem

  1. Click on the DRG under Networking >> Customer Connectivity >> Dynamic Routing Gateways
  2. Click on DRG Route Tables on the left side under Resources
  3. Click on the blue Create DRG Route Table button
  4. We will name this Onprem_RT
  5. Leave the static routes empty
  6. Click Show Advanced Options
  7. Select the Enable Import Route Distribution button and select the Import_Onprem Route Distribution created above
  8. Click the blue button labeled Create DRG Route Table 

On the Ashburn DRG - Create Route Table for RPC

  1. Click on the DRG under Networking >> Customer Connectivity >> Dynamic Routing Gateways
  2. Click on DRG Route Tables on the left side under Resources
  3. Click on the blue Create DRG Route Table button
  4. We will name this RPC_RT
  5. Leave the static routes empty
  6. Click Show Advanced Options
  7. Select the Enable Import Route Distribution button and select the Import_RPC Route Distribution created above
  8. Click the blue button labeled Create DRG Route Table 

On the Ashburn DRG - Apply the new Route Tables to the Attachments

  1. Click on the DRG under Networking >> Customer Connectivity >> Dynamic Routing Gateways
  2. Click on the IPSec or Virtual Circuit Attachments on the left side under Resources
  3. Click on the Attachment Name
  4. Click Edit and select the DRG Route Table Onprem_RT
  5. Click the blue button labeled Save Changes
  6. Click on the RPC Attachments on the left side under Resources
  7. Click on the Attachment Name
  8. Click Edit and select the DRG Route Table RPC_RT
  9. Click the blue button labeled Save Changes

You should now be able to reach the 172.16.0.0/24 network from on prem 192.168.0.0/16.

Related Links

Enhanced DRG Release Notes

OCI DRG Documentation

On-premises access to multiple DRGs and VCNs in different regions through a single connection

Enhanced DRG Product Announcement

 

 

 

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha