OCI Dynamic Routing Gateway Attachments Part 1 – Basics

As you might have seen, few weeks ago Oracle announced improved Dynamic Routing Gateway functionality which I was super excited about. Why?

Previously when you’ve designed Transit Networking on OCI you’ve always had to use Hub & Spoke model for your traffic to flow from on-premises to Spoke VCN.

Also, setting up connectivity between VCNs requires Local Peering Gateways between each VCN and if you have multiple VCNs requiring to talk with each other, you’d suddenly have bunch of VCNs!

In this first part I’ll go basics of new DRG functionality to get you up to speed, on part 2 we will be looking routing to different Region and what we can do with Dynamic or Static routes.

New DRG attachments

Now with DRG attachments you can start re-thinking how you design your network infrastructure on OCI. It has some similarities with AWS Transit Gateway as well so for those who have been working with that, this should be fairly easy concept to follow.

Instead of Hub VCN, DRG will be your point of contact from now on. You will route your traffic from VCN towards to DRG and DRG will route traffic forward based on DRG attachments and route tables. Routes can be to another VCN in the same Region, another Region in different Region or to on-premises over FastConnect or VPN Connect for example.

I have a fictional setup case where I have on-premises & multiple VCNs and I want to setup connectivity from Shared Services to all VCNs (and the other way around) and have connectivity from On-Premises to all VCNs and the other way around.

• On-premises uses 10.0.0.0/8
• VCN A uses 10.0.0.0/24
• VCN B uses 10.10.0.0/24
• VCN C uses 10.20.0.0/24
• Shared Services VCN uses 10.100.0.0/24

Above diagram visualizes the requirement and also shows how we use DRG now instead of the old Hub VCN and it’s route tables. We attach either VCN, FC, VPN or RPC to our DRG.

Setting up routing

To make this easier to understand, I’ve only included VCN C and Shared Services for deeper investigation. How this would look like with new Attachment features is this.

I have multiple attachments in my DRG but for this example I’m only using single Route Table which is assigned to each of my attachments. In the future posts will look what you can do with multiple Route Tables and why you would use them!

Remember that most specific route always takes precedence. From VCN C I want to be able to connect to Public Internet, that’s why nat-gw is in the route table for 0.0.0.0/0. I also want to use service-gw for all Oracle Services in that Region.

We know on-premises CIDR block is 10.0.0.0/8 and my OCI CIDR blocks are also covered within that range. That’s why from VCN C, I can route all 10.0.0.0/8 traffic towards DRG. What’s cool now is DRG taking care of the rest!

DRG knows that if I have traffic going to 10.100.0.0/24 (Shared Services), it will route it towards correct VCN attachment since that’s what my DRG RT 1 tells it. Similarly if I have traffic going towards on-premises, it uses attachment from the Virtual Circuit. (FastConnect)

Another new concept is that DRG route table can import routes automatically from VCNs attached or from ALL attached services either from automatically created distribution list or from distribution list you create. These would then be propagated automatically to the DRG route table! Or you can use static rules if you prefer those.

More on dynamic and static routes in the next post.

Summary

There’s obviously lot to learn with this new functionality but I like how it enables us to support more complex networking scenarios and at the same time makes also designing them lot easier.

In the next post we’ll look on more advanced scenarios and what we can do with DRG attachments. I’m also really eager to see some A-Team posts in the future related to DRG attachments! Always great to learn, I’ll be sure to link them here.