Overview of DRG Route Tables and Import Distribution Lists - Part 1

March 30, 2023 | 7 minute read
Raffi Shahabazian
Principal Cloud Network Architect
Text Size 100%:

Dynamic Routing Gateways (DRGs) have been around for quite some time in OCI.  Yet, a frequently asked question I receive is if the autogenerated DRG Route Tables and autogenerated Import Distributions that come pre-bundled when a DRG is created are acceptable to use permanently or if there are alternative approaches when using the DRG Route Tables and Import Route Distributions.

Before we begin, let’s take a quick look at what these autogenerated DRG Route Tables and Import Route Distributions look like in the OCI console when you first create a DRG.

Default View of DRG Routet Tables
Default View of DRG Route Tables

 

Default View of DRG Import Route Distributions
Default View of DRG Import Route Distributions

 

While the autogenerated DRG Route Tables and Import Route Distributions are perfectly acceptable to use, it does not mean this is the recommended approach to take.  For example, what if I wanted my Prod VCN to use Virtual Circuits and my Dev VCN with IPSec connections?  What if I wanted had a requirement to allow my east-west traffic between VCNs to communicate without needing to traverse a hub VCN?  What if a subset of my VCNs needed east-west communication, but the remaining VCNs would need to traverse a hub VCN?  The examples of these traffic flows are common uses cases and can be simpler to manage in the long run if we were to leverage unique DRG Route Tables with unique corresponding Import Route Distributions.

DRG Route Tables and Import Route Distributions

Upon initial creation (or immediately after a legacy DRG upgrade), we will have two DRG Route Tables that are autogenerated for us, and each has a specific purpose.  One of the DRG Route Tables is used as an aggregate route table for Virtual Cloud Network (VCN) attachments.  The other DRG Route Table is used as an aggregate route table for Remote Peering Connections (RPC), Virtual Circuits, and IPSec Tunnels.  The names of these DRG Route Tables are as follows:

  • Autogenerated Drg Route Table for RPC, VC, and IPSec attachments
    • This is the also the default DRG Route Table for all existing and future RPC, VC, and IPSec attachments (we will go over how to change this default setting in a Part 2 of this blog). 
  • Autogenerated Drg Route Table for VCN attachments
    • This is the also the default DRG Route Table for all existing and future VCN attachments (we will go over how to change this default setting in a Part 2 of this blog). 
Autogenerated DRG Route Tables
Autogenerated DRG Route Tables

 

Based on the purpose of the two DRG Route Tables, their names are self-explanatory; however, the Import Route Distributions that are associated with these DRG Route Tables make them unique.  By default, when a DRG is created (or upgraded from a legacy DRG), the autogenerated DRG Route Tables are associated with unique Import Route Distributions.  The names of the autogenerated Import Route Distributions are as follows:

  • Autogenerated Import Route Distribution for ALL Routes
  • Autogenerated Import Route Distribution for VCN Routes
Autogenerated DRG Import Route Distributions Associations
Autogenerated DRG Import Route Distributions Associations

 

Every DRG Route Table needs to be associated with a corresponding Import Route Distribution.  DRG Route Tables can share Import Route Distributions, meaning multiple DRG Route Tables can reference a single Import Route Distribution, or there could one unique Import Route Distribution for each DRG Route Table.

If we were to look at the autogenerated Import Route Distributions, we would see that they have different criteria to make their decisions on which DRG attachment to import from.

Autogenerated Import Route Distribution for ALL routes

This Import Route Distribution has a single statement with a Match Type of Match All and a Match Criteria of -- (since the statement is matching on all, there is no need for specific criteria).  This statement explicity defines the following:

  • Import Route Distribution has a single statement to match on ALL attachments, which includes VCN, RPC, IPSec, and Virtual Circuit attachments. 
  • This Import Route Distribution is associated with the Autogenerated DRG Route Table for VCN attachments

Below is an image from the OCI console on what this Import Route Distribution looks like:

Autogenerated Import Route Distribution for ALL Routes
Autogenerated Import Route Distribution for ALL Routes

 

Autogenerated Import Route Distribution for VCN routes

This Import Route Distribution has a single statement with a Match Type of Attachment Type and a Match Criteria of Virtual Cloud Network.  This statement explicity defines the following:

  • This statement explicitily states that any existing (and future) VCN that is attached to this DRG will be imported.
  • This Import Route Distribution is associated with the Autogenerated Drg Route Table for RPC, VC, and IPSec attachments

Below is an image from the OCI console on what this Import Route Distribution looks like:

Autogenerated Import Route Distribution for VCN routes
Autogenerated Import Route Distribution for VCN routes

 

Before we begin creating DRG Route Tables and Import Route Distributions, let’s take a closer look on what type of criteria we can match within an Import Route Distribution.

Import Route Distribuion Statements

The next item to decide is what to match in the Match Type drop down.  We have three options:

  • Attachment type
  • Attachment
  • Match All

The Match Type of Attachment type allows us to select to match on one of the four permitted attachment types:  Virtual Cloud Network, IPSec Tunnel, Virtual Circuit, or Remote Peering Connection.

Route Distribution Statement: Match Type of Attachment
Route Distribution Statement: Match Type of Attachment

 

This method is all encompassing for the given attachment selected, meaning, if I had 50 VCNs attached to the DRG and this Import Route Distribution was used by a DRG Route Table for IPSec Tunnels, then all 50 VCN CIDRs would be imported into the DRG Route Table used by the IPSec Tunnels.

However, the Match Type of Attachment allows us to select individual attachments, whether they are VCNs, IPSec Tunnels, RPCs, Cross-Tenancy, or Virtual Circuit attachments.

This method is the most granular level we can filter within an Import Route Distribution.  I can granularly select individual VCNs, IPSec Tunnels, RPCs, or Virtual Circuits and import only the CIDRs within a given DRG Route Table.  For example, the picture below showcases that I can match a specific IPSec Tunnel attachment for an Import Route Distribution.

Route Distribution Statement: Match Type of Attachment
Route Distribution Statement: Match Type of Attachment

 

The Match Type of Match All is self-explanatory; this will match all attachment types and import the CIDRs accordingly:

Route Distribution Statement: Match Type of Match All
Route Distribution Statement: Match Type of Match All

 

Now that we have an understanding on the default configurations for DRG Route Tables and Import Route Distributions, what’s next?  The fun stuff!  We'lll need to create new Import Route Distributions, create new DRG Route Tables, associate the Import Route Distributions with their respective DRG Route Tables, and change the defaults for the attachment types.  Once we've performed these steps, we can start associating the various attachements to their respective DRG Route Tables so we can selectively import CIDRs from other attachments on a per DRG Route Table basis, which will ultimately provide us the ability to granularly control routing on a per DRG Route Table basis.  iPlease keep an eye out for Part 2 of this blog so we can go through the next steps together.

References:

Dynamic Routing Gateways

Additional Resources

For an in-depth Technical Overview and Design Workshop related to the DRG, please take a look at the following video on YouTube:

 

 

 

Raffi Shahabazian

Principal Cloud Network Architect


Previous Post

FAW Connectors - Augmenting Fusion Analytics Data With Google Analytics Data

Matthieu Lombard | 5 min read

Next Post


OCI Network Firewall - Securing the Private LBaaS traffic

Andrei Stoian | 6 min read