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 moreRelated posts
Routing options for VMs from Private Subnets
Virtual Machines deployed in Azure used to have Default Outbound Internet Access. Until today, this allows virtual machines to connect to...
Secure, High-Performance Networking for Data-Intensive Kubernetes Workloads
The intersection of Generative AI and cloud computing has been transforming how organizations build and manage their infrastructure. The deman...
Network Connectivity for RISE with SAP S/4HANA Cloud Private Edition on Azure
In this article, we will explore different ways to connect to RISE with SAP S/4HANA Cloud Private Edition deployment on Azure, guiding yo...
Optimize Azure Landing Zone with Azure Virtual Network Manager IP Address Management
Optimize Azure Landing Zone with Azure Virtual Network Manager IP Address Management What you will learn from this blog This blog explores how...
ExpressRoute Metro is now generally available!!
We are excited to announce general availability of ExpressRoute Metro, a new private connectivity architecture designed to enhance network res...
ExpressRoute guided configuration of multi-site circuits and connections is generally available
ExpressRoute guided experience for configuring multi-site resiliency circuits and connections is generally available in Azure public cloud. Th...
Manage NSG association on Subnets via Azure Policy
In this blog article, we will cover how to deny the creation of a subnet in a Virtual Network if the subnet does not have a Network Sec...
Effortless Private Endpoint Management in Azure Landing Zones: A Streamlined and Compliant Approach
1. Challenge In Azure Landing Zones, the network infrastructure, including components like VNET Gateways and ExpressRoute circuits, is part of...
Unlocking Secure VM Connectivity with Azure Bastion
In today’s digital landscape, where security breaches are an unfortunate reality, safeguarding sensitive data and infrastructure has become mo...
Use cases of Advanced Network Observability for your Azure Kubernetes Service clusters
Introduction Advanced Network Observability is the inaugural feature of the Advanced Container Networking Services (ACNS) suite bringing...