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.
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:
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:
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:
Below is an image from the OCI console on what this Import Route Distribution looks like:
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:
Below is an image from the OCI console on what this Import Route Distribution looks like:
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:
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.
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.
The Match Type of Match All is self-explanatory; this will match all attachment types and import the CIDRs accordingly:
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:
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:
Previous Post