Programmatically Find Next Available CIDR for Subnet
Introduction
I've had several customers who, after automating their Azure Infrastructure as Code (IaC), have asked how they can easily find the next available CIDR range for a given subnet size. This is not a task automation can easily do. Keep reading for an explanation of how it works.
Deploying the Code
The code for the Function App can be found in GitHub here. I wrote it using Visual Studio 2019.
Azure Function App
I created the Function App as a Windows .NET instance. It has “Anonymous” as its Authorization Level – if you use a different level you’ll have to do additional work to allow access to it.
After synchronizing the code from Visual Studio to GitHub, I used the “Publish” wizard in Visual Studio to deploy the code to Azure. I used the steps outlined in this documentation. This wizard generated a YAML workflow which was uploaded to GitHub and powered an Action. As a result, any code changes committed to the target GitHub branch are automatically built and deployed to the Function App.
Once the Function App is created and the code deployed via GitHub Actions, I went to the “Identity” blade and created a system-assigned managed identity so that the Function App had access to the target virtual network resources.
I then gave it “Reader” access at the subscription level; you could scope it down to a more focused target such as a resource group or groups as desired.
If you don’t correctly create the Function App’s managed identity you will get an error in the browser similar to the following:
If you create the managed identity, but fail to give it “Reader” access to the specified virtual network, you will get an error like this in the browser:
Usage
This Azure Function takes the following parameters as input and returns the first CIDR range in the given virtual network that matches the specified size.
- Subscription ID
- Virtual Network Name
- Resource Group Name (containing the above VNet)
- Desired CIDR Size of New Subnet (between 2 and 29)
Request Details
Requests to the Function App take the following format:
Response Details
There are two main response formats: one for a successful call, and one for errors.
Successful API Call
If your API call to the Function App is successful, you will receive a 200 HTTP response code and JSON that is similar to the following:
The CIDR you want for your new subnet is contained in the "proposedCIDR" field.
Failed API Call
There are two main reasons why your call may not succeed:
1. You pass in an invalid parameter. That will result in an HTTP 400 response that will look something like this:
2. The specified virtual network does not have sufficient address space left for creation of a subnet of the desired size. For this error you will receive an HTTP 404 error, and a response similar to this:
Conclusion
I hope you find this Function App helpful in automating your Azure virtual network deployments. Please let me know about any bugs or enhancements that should be addressed!
Published on:
Learn more