Welcome back to Part 2 of the Detailed Overview of DRG Route Tables and Import Distributions. In Part 1 of this blog, we went through the default configurations related DRG Route Tables and Import Route Distributions and concluded that the default configurations are acceptable to use. However, I also presented various traffic flows that would be better managed using unique DRG Route Tables and Import Distributions if we wanted to achieve granular control of the routing on a per-attachment basis.
Below is a logical diagram of the default design when we use the Autogenerated DRG Route Tables and Import Distributions. All FastConnect, IPSec Tunnel, and Remote Peering Connection attachments leverage the Autogenerated DRG Route Table for RPC, VC, and IPSec attachments and all Virtual Cloud Network attachments leverage the Autogenerated DRG Route Table for VCN attachments. Both of the Autogenerated DRG Route Tables have corresponding Autogenerated Import Route Distributions which import from the various attachments.
However, what if we wanted to reach the OCI Phoenix Region via the FastConnect or IPSec Tunnel attachment? Or what if I had multiple VCN attachments and I wanted a subset of them to be reachable via the IPSec Tunnel attachments only and not the FastConnect Virtual Circuit? What if I had multiple VCN attachments and I did not want them to be reachable by any VCN without transiting through a hub VCN? Would this work with the default configurations provided by the Autogenerated DRG Route Table for RPC, VC, and IPSec attachments?
The short answer is no, at least not by default. So, what do we need to do properly manage the routing for each of the attachments? You guessed it – we’ll need to create unique DRG Route Tables with corresponding Import Distributions and associate the various attachments to their corresponding DRG Route Tables. Below is a diagram of the relationship between DRG attachments, DRG Route Tables, and DRG Import Distributions:
For the purposes of this blog, I have the following attachments to work with:
Considering I have a total of three attachments, the logical design I am working with is as follows:
The first thing I will need to do is create three unique Import Route Distributions and associate them with three unique DRG Route Tables. However, I first need to determine what type of traffic flows are acceptable for my use case. The traffic flow requirements that I’ve enforced upon myself are to achieve the following:
Now that I have defined the requirements on acceptable traffic flows, I can begin creating three new Import Route Distributions as follows:
Note: Could I use a shared Import Route Distribution that can be used by the RPC and IPSec DRG Route Tables we will soon create? Yes, however, it is best to keep the Import Route Distributions unique amongst DRG Route Tables so we can be as granular as possible in future route imports.
Below is what the new Import Route Distributions look like in the OCI console:
Below is the VCN-rd, which will be used by the DRG Route Table associated with VCN attachments. Notice we are importing from the RPC and the IPSec Tunnels since the VCN attached to the DRG Route Table that is associated with this Import Route Distribution will need to know what attachment to use for its next-hop towards the destination CIDRs:
Below is the IPSec-rd and the RPC-rd, which will be used by the DRG Route Tables associated with IPSec Tunnel attachments and RPC attachments respectively. Notice we are importing from the VCN in both Import Route Distributions since the DRG Route Tables associated with the IPSec Tunnel attachment and the RPC attachment will need to know what attachment to use for its next-hop towards the destination VCN CIDRs:
Now that we have the Import Route Distributions, we can create the unique DRG Route Tables. Please note that we’ll need to select the corresponding Import Route Distribution when creating the new DRG Route Tables. This is done by expanding the Advanced Options, selecting Enable Import Route Distribution, and selecting the corresponding Import Route Distribution name. Below is what this would look like in the OCI console for the DRG Route Table that will be associated to the VCN attachment:
Let’s look at the OCI console to see what it looks like once I’ve created the three DRG Route Tables.
Note: Notice the fourth column labeled Import Route Distribution. This column indicates that the respective DRG Route Table is associated with its corresponding Import Route Distribution
Now that we have all three DRG Route Tables created and associated with their corresponding Import Route Distributions, we can associate the VCN, RPC, and IPSec Tunnel attachments with their respective DRG Route Tables.
To accomplish this, we’ll need to edit each attachment and associate the attachments with their corresponding DRG Route Tables:
Note: The screenshots above are for the VCN attachment only. We will need to repeat the DRG Route Table association for each attachment.
Once the corresponding DRG Route Table is selected, we should see it reflected in the OCI console for each attachment:
Now that each attachment is associated with a unique DRG Route Table which further has a unique Import Route Distribution, what does our design look like? The diagram below is a logical representation on how the design looks after our modifications:
We have now the DRG attachments leveraging their own unique DRG Route Tables and each DRG Route Table can be influenced individually by their respective DRG Import Route Distributions. For example, if I had a requirement to attach a new VCN and a new FastConnect circuit, I would create new Import Route Distributions and configure it with the attachments to import from, create new DRG Route Tables with the corresponding Import Route Distributions, and associate the new DRG attachments with their respective DRG Route Tables.
With all of this said, what happens to the Autogenerated DRG Route Tables and Import Route Distributions? They still have relevance in the current design because these will be considered the defaults for future attachments, as seen below:
We could create new DRG Route Tables and corresponding Import Route Distributions as a place holder for future attachments. In turn, this will allow us to delete the Autogenerated DRG Route Tables and Autogenerated Import Route Distributions which will clean up any unused DRG items.
To modify the default DRG Route Table for a given attachment type, select the Edit Default Assignment from the DRG Route Tables menu and modify the default DRG Route Table for each attachment type:
In summary, the Autogenerated DRG Route Tables and Import Route Distributions are perfectly acceptable to use. However, the traffic flow requirements may dictate certain traffic flows are allowed or not allowed from certain source attachments. Therefore, it is always in our best interest to create the new DRG Route Tables and Import Route Distributions, so we are prepared to granularly control the importing of CIDRs from a given set of DRG attachments.
References:
Additional Resources:
Overview of DRG Route Tables and Import Distribution Lists - Part 1
Previous Post
Next Post