Subnet Creation API Providing Incorrect Subnet

[tonydean37]

Hi Matt, long time no speak. Hope all is well with you? We updated our IPAM to the latest version (3.5.0) yesterday and this morning seen a bit of an issue with subnet as below.

Describe the bug
We are using the subnet API Tool to get an unused subnet from within a Vnet, but IPAM is returning a subnet that cannot be used.

To Reproduce
Use the script:
$requestUrl = "https://$ipamAppName.azurewebsites.net/api/tools/nextAvailableSubnet"
$body = @{
vnet_id = "redacted"
smallest_cidr = "true"
size = $size
} | ConvertTo-Json

$headers = @{
    'Accept'       = 'application/json'
    'Content-Type' = 'application/json'
}

$response = Invoke-RestMethod `
    -Method 'Post' `
    -Uri $requestUrl `
    -Authentication 'Bearer' `
    -Token $accessToken `
    -Headers $headers `
    -Body $body

PS C:\repos> ($responseBLock | Where-Object {$_.name -eq "redacted"}).prefixes
10.171.129.0/24
10.168.255.128/27
10.171.44.0/25
10.168.255.160/27
10.171.44.128/25
10.171.48.0/22
10.171.45.0/24
10.171.46.0/24
PS C:\repos>
PS C:\repos> $response

vnet_name resource_group subscription_id cidr

---

redacted 10.171.44.0/24

Expected behavior
Should have provided a /25

Desktop (please complete the following information):
Using Powershell locally and in a pipeline provides the same issue

Additional context
Add any other context about the problem here.

[DCMattyG]

Hi @tonydean37, thank you for the feedback as always!

At first glance it would seem the issue here is that the Azure IPAM tools is summarizing all of the Address Spaces that belong to a Virtual Network and as such the disjoint Address Spaces of "10.171.44.0/25" and "10.171.44.128/25" are being summarized to "10.171.44.0/24". Actually, because we also have "10.171.45.0/24" here, both are being summarized to "10.171.44.0/23" which under normal circumstances would make sense...but in the wonderful world of Azure networking (today) a Subnet cannot span across multiple Virtual Network Address Spaces. As such, what we really need to be doing in the code is comparing each Address Space separately instead of summarizing them all together and comparing the summary.

That said, I understand what changes need to be made and I'll wrap those into the upcoming v3.6.0 release that I already have in the works. I'll keep you posted on my progress here and will also update any other calculation API's that may be affected by this behavior as well.

Thanks again, I'll keep you posted on v3.6.0 progress.

[tonydean37]

Hi @tonydean37, thank you for the feedback as always!

At first glance it would seem the issue here is that the Azure IPAM tools is summarizing all of the Address Spaces that belong to a Virtual Network and as such the disjoint Address Spaces of "10.171.44.0/25" and "10.171.44.128/25" are being summarized to "10.171.44.0/24". Actually, because we also have "10.171.46.0/24" here, both are being summarized to "10.171.44.0/23" which under normal circumstances would make sense...but in the wonderful world of Azure networking (today) a Subnet cannot span across multiple Virtual Network Address Spaces. As such, what we really need to be doing in the code is comparing each Address Space separately instead of summarizing them all together and comparing the summary.

That said, I understand what changes need to be made and I'll wrap those into the upcoming v3.6.0 release that I already have in the works. I'll keep you posted on my progress here and will also update any other calculation API's that may be affected by this behavior as well.

Thanks again, I'll keep you posted on v3.6.0 progress.

Makes complete sense and thanks for the quick reply as always. Have a great weekend!

[DCMattyG]

Hey @tonydean37, I'm wrapping up my work on v3.6.0 and wanted to verify a few things for testing...

In the above example you provided the Address Prefixes assigned to the target Virtual Network. Can you also provide me the list of Subnet CIDR's that existed at the time when you expected a /25 result for your query? I want to text as similar of a scenario as you have just to be sure things are working.

Also, you have the $size variable above, but I'm not sure what value you set that to here. I'm guessing 25, but I would like to verify that as well.

Thanks so much, we're almost there!

[tonydean37]

Hey @DCMattyG - $size was definitely set to /25 when I tested. For the LZ, I've had a look back to the PR and it was a new vend, so we had:
"vnetCidrs": [
"/24",
"/27",
"/25",
"/27",
"/25",
"/22",
"/24",
"/24"
]

"subnets":
/24
/25
/27
/27
/22
/24
/24

We've configured our vend process to reserve the Address Prefixes, then create the subscription and vnet with the required Address Prefixes. We then have another step that vends the subnets sequentially after sorting them (so the largest e.g /22 subnet is created first), in this case there would 7 deployments for the subnets as we can't reserve those.

Body used to create subnet:
$bodysubnet = @{
'vnet_id' = $landingzoneOutput.virtualNetwork.value.id
'size' = $size
'reverse_search' = "false"
'smallest_cidr' = "true"
} | ConvertTo-Json

Hope this makes some sense! Happy to jump on a call if needed though :)

As always, thanks for your help on this one!

[DCMattyG]

Hi @tonydean37, this issue should now be address with the v3.6.0 release which came as part of PR #364.

Please give everything a try and let me know if you have any problems at all. Thank so much!

[tonydean37]

Hey @DCMattyG - thanks for this. I've had a read of the changes and as we are still using docker compose, we'll need to upgrade to the latest pattern. As we have deployed this in code then it'll take a bit of work our end to solutionise (is that a word!) it, but I really appreciate you fixing that one for us. :)