OCI Dynamic Routing Gateway Attachments Part 2 – Dynamic Route Import Distributions

On part 1 of the DRG version 2 we looked on basics and how you can control which VCN can be accessed and how, regardless if the source is through FastConnect, VPN Connect, VCN or Remote Peering Connection (another DRG).

This time we’re gonna look on dynamic route import distributions.

Since each VCN attachment can have their own route table in DRG, and in many cases you don’t necessarily want to allow every VCN talk with each other or want to add every route as static there’s way to make this easier.

When you use Import Distributions you define only the VCNs you want to get automatically propagated to that DRG route table. If you wouldn’t define, you could use auto-generated distribution list, that would have Dynamic rules for all attached VCN’s.

Here I want to transform my earlier setup to use specific DRG Route Table for each attachment and also create specific import distributions for each.

In basics we covered using one DRG route table but real life scenarios will involve specific route table for each attachment.

Setting things up

I have my VCNs set and I’m creating the VCN attachments on the DRG, note that as first step I’m using those auto-generated distribution lists.

If I now look the actual attachment and the route table, I can view all route rules which are currently imported dynamically.

This is good! But this would let each VCN speak with each other without limitations. You could obviously control access from VCN route table but we don’t really want that, I want DRG to be in control who can access and what. This would be handy if not all VCNs are managed by central team for example.

Enter Import Distributions

I’m following my diagram from above and setting up DRG RT 1 and DRG RT 2 respectively. I don’t have on-premises connection available but to show how it looks like I’ve setup Virtual Circuit as location as well with attachment type. What if you would have multiple FastConnects? Just setup routing for specific Attachments.

Once this is done I still need to setup attachment route tables, DRG RT 1 will be for VCN C while DRG RT 2 will be linked to Shared Services VCN attachment.

This way when traffic leaves from Shared Services VCN, DRG RT 2 handles traffic forward depending where it’s going to.

Dynamic Routes

Now that my import distribution for Shared Services Attachment gets all routes from VCNs, what happens if I add new CIDR block for VCN A?

I added 10.1.0.0/24 to VCN A, created subnet, and if I go to look routes my DRG RT 2 has, I can see route is added there .

Summary

To manage larger networks without having to sacrifice security or adding static rules, one option which makes most sense to me right now (May 2021) is using specific route table for each attachment in the DRG and creating specific import distributions which you add to route table you are using in the DRG.

You can still share the import distribution with multiple VCNs if you like, only for those specific ones where you want to restrict traffic this makes life way easier. If you need to, static routes can be added to DRG route tables in addition to dynamic ones. Remember, if routes match then static routes take priority over dynamic ones. (fixed the initial statement that dynamic routes takes priority, which is only true if routes don’t match)

On next part I’ll look on how Remote Peering Connection works together DRGv2 and what to do when you have existing design with Hub & Spoke model (transit VCNs).