Next available subnet from an existing Virtual Hub

[tblackshaw-kinly]

Hi all,

At present, we have 4 virtual hubs each with their own 10.20* address.

When we create additional VNets, we manually input the third octet via pipeline variable. We would like to know if it was possible to automatically get the next available /23 range to ensure there is no overlaps when it comes to the vnet peering.

This is our code currently:

var varRGName = 'rg-${parCustomerName}-${parApplication}-${parEnvironment}-${parLocationSC}'
var varVNetName = 'vnet-${parCustomerName}-${parApplication}-${parEnvironment}-${parLocationSC}'
var varSNetName = 'snet-${parCustomerName}-${parApplication}-${parEnvironment}-${parLocationSC}'
var varVNetAddressRange = '${parNetworkPrefix}.${parAppSubnet}.0/23'
var varSNetAddressRange = '${parNetworkPrefix}.${parAppSubnet}.0/24'

resource resVirtualHub 'Microsoft.Network/virtualHubs@2022-11-01' existing = {
  scope: resourceGroup(parHubSubscriptionId, parHubResourceGroupName)
  name: parVirtualHubName
}

module modResourceGroup '../ResourceModulesv0.10.0/modules/Microsoft.Resources/resourceGroups/deploy.bicep' = {
  name: 'mod-VMResourceGroup'
  params: {
    name: varRGName
    location: location
  }
}

module modVirtualNetwork '../ResourceModulesv0.10.0/modules/Microsoft.Network/virtualNetworks/deploy.bicep' = {
  scope: resourceGroup(varRGName)
  name: 'mod-VirtualNetwork-${parApplication}'
  params: {
    addressPrefixes: [varVNetAddressRange]
    name: varVNetName
    location: location
    subnets: [
      {
        name: varSNetName
        addressPrefix: varSNetAddressRange
      }
    ]
  }
  dependsOn: [
    modResourceGroup
  ]
}

// creates the Virtual Hub Connection (vnet peering from hub to spoke)
module modHubVnetConnection '../modules/hubVnetConnection/hubVnetConnection.bicep' = {
  scope: resourceGroup(parHubSubscriptionId, parHubResourceGroupName)
  name: 'mod-hubvnetconnection-${varVNetName}'
  params: {
    parVirtualWanHubResourceId: resVirtualHub.id
    parRemoteVirtualNetworkResourceId: modVirtualNetwork.outputs.resourceId
    allowHubToRemoteVnetTransit: true
    allowRemoteVnetToUseHubVnetGateways: true
    enableInternetSecurity: true // EQ == Portal option: Propagate Default Route Enable
  }
  dependsOn: [
    modVirtualNetwork
  ]
}

[jeskew]

I believe the cidrSubnet function will help if the network topology is defined in a parent template.

If there's no way to map out the network statically (i.e., without looking at the current state of the network), I would caution against using the approach you describe, as it would make deployments non-idempotent. Deploying the same template a second time would give you a clone of the same set of resources instead of updating those resources in place. You could use a deployment script to query the network if you want to go with this approach, but there's no built-in function to query what subnets have already been assigned on.