VCN with multiple CIDR ranges

Recently, we have added a brand new feature to our VCN functionalities. The new feature is related to enable multiple CIDR ranges for a given VCN. This new feature will solve different use cases raised by our Customers during the time, I will list some of the use cases solved below:

- one VCN CIDR space exhausted and the need for more IP addresses;

- the need to activate other non-overlapping VCN CIDRs to accommodate the On-Premise IP addressing plan;

- to resolve some overlapping IP address space issues;

There are some limitations of the service listed in our public documentation: https://docs.cloud.oracle.com/en-us/iaas/Content/Network/Tasks/managingVCNs_topic-Overview_of_VCNs_and_Subnets.htm

In this blog, we will focus on how a new VCN CIDR is interacting with the existing VCN CIDR(s). For simplicity, we will consider the case when the VCN had one CIDR being the initial one and we will add a new one.

We will analyze the feature from the VCN routing and security perspective and two main points raised here:

1. How the VCN routing is done between the existing subnets from the existing CIDR and the new subnets created using the new CIDR added?

2. Will the Security Lists and/or NSGs attached to the subnets from the existing CIDR and new CIDR needs to include entries to permit the traffic to pass?

We will find the answers to the above questions right away.

The Case

1. Define the new CIDR range for a VCN:

I have defined the VCN with 10.0.0.0/24 and later I added 10.0.10.0/24.

From 10.0.0.0/24 I have defined a subnet of 10.0.0.0/29 with a Route Table and Security List attached. From the new 10.0.10.0/24 CIDR I have defined a subnet of 10.0.10.0/29 with a new Route Table and Security List attached.

2. I did not add any routing entry for the other subnet in the routing table of each subnet. Even if you will try to add the route to the other subnet the VCN will tell you that the route cannot be added because the routing between all the subnets from all CIDRs assigned to the VCN is already created.

Let's try to see if the traffic between two VMs is working:

3. On the Security Lists attached to each subnet I have added an entry to permit the ICMP:

10.0.0.0/29 Subnet Security List:

10.0.10.0/29 Subnet Security List:

The traffic:

Once we have permitted the traffic in the Security Lists, the connectivity between the two subnets from the existing CIDR and new CIDR has been established.

In conclusion, when using multiple CIDRs ranges assigned to a given VCN, for the traffic between subnets of the same VCN we only need to take care of security, the routing is already done for us. Great, isn't it?