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:
The legacy DRG had the below limitations that have been addressed in the new DRG version:
New enhanced DRG version features:
The new enhanced DRG can have multiple network 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.
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.
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
Associate route table to the DRG VCN Attachment
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:
On the Phoenix DRG:
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:
On the Phoenix DRG:
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
On the Ashburn DRG - Create Import Route Distribution for RPC
On the Ashburn DRG - Create Route Table for On Prem
On the Ashburn DRG - Create Route Table for RPC
On the Ashburn DRG - Apply the new Route Tables to the Attachments
You should now be able to reach the 172.16.0.0/24 network from on prem 192.168.0.0/16.