Subnet Utilization View/Planner

[DCMattyG]

Hi @letmetechyou, I'm moving this to a discussion as it's a great topic and something I've began to work on.

The ask from Issue #41 was to have some way of visualizing not only the currently utilized subnet blocks in an Azure vNET, but a tool to better understand what blocks are available with varying CIDR masks, similar to this example from the phpIPAM utility...

[binnykmathew]

@DCMattyG Is there already a way in IPAM to find the next available CIDR range inside of a Vnet for a desired Subnet size ?
Something like this does -> https://techcommunity.microsoft.com/t5/azure-networking-blog/programmatically-find-next-available-cidr-for-subnet/ba-p/3266016

[DCMattyG]

Hi @binnykmathew, there isn't yet, but you're the 3rd person that has requested this so I'm going to move it to the top of my list.

Would you be consuming this as an API, or would you also like it exposed in the IPAM UI? If you'd like to see it in the UI, please give me a few details as to how you picture that user flow working so I can use that to better design the experience.

Thanks!

[binnykmathew]

@DCMattyG Thanks for the quick reply.
Initially, we would like to get an API for this, so we can integrate with IaC and Internal Developer platforms.

[DCMattyG]

Wow @binnykmathew, this is AWESOME! Thank you for such a complete example and explanation!

I'll get to work right away on the API, and once we get that working, I'll work closely with you on a UI experience that makes sense for everyone.

[binnykmathew]

@DCMattyG Just wondering if there is a date when you will have the Subnet API ready for us to use in Production :)

[DCMattyG]

Hi @binnykmathew, we have a public holiday today in the US and I'm planning on using this time to try and get this into a Development image for you to test and provide feedback on. Hopefully you'll see an update from me within the next 1-2 days on this item.

[iamastranger]

@DCMattyG - I would vote for the following features, in the priority order
a) Subnet reservation using API - It will then make this tool feature complete :). Currently, this is a key feature thats missing for us to use this in an IaC automation.
b) Show in the portal all the reservations and done by which user
c) Performing a resevation via the portal is nice to have.
d) Subnet planner

Just wondering if there is any timeline when point (a) will be available ?

[DCMattyG]

Hi @iamastranger, thank you so much for the valuable feedback. A few notes/questions for you....

A) I have been working on an API that will provide you the next subnet of size X in a vNET. At the moment, I hadn't planned on making this a full-blown reservation like how the vNET reservations work, simply because there's far less chance of clash within a vNET to make subnets as opposed to multiple users carving out a Block for new vNET(s). Do you feel that this actually needs a complete reservation system in place, or would an API that can return the next subnet of a given mask size be sufficient?
B) This can already be done today. IPAM Admins can see all reservations, whereas non-admins can only see their own within the UI.
C) I've had multiple requests for this, and I'm happy to do it...but I keep thinking to myself "why?". If you are in the UI and can click a few buttons to manually make a reservation, why not just use those clicks to make the vNET in Azure instead? I'll create the functionality, but I keep wondering haha...
D) I've spent quite a bit of time on this over the holiday break. Hoping to have it complete by the new year.

For item A, I am hoping to have a functional test ready by the new year for feedback, but at this moment it will be an API that will reveal the next subnet of mask size X within a given vNET, and not a complete reservation experience. If we need the full reservation experience for subnets, please provide me a few details as to how this will help (example workflow where simply returning the next available subnet would not be sufficient) and of course I can work on getting it implemented.

Thank you for all of the valuable feedback, it's exactly what I wanted for Christmas ;-)

[iamastranger]

@DCMattyG Thankyou for a quick reply even during a holiday break :), shows your dedication towards making this project usefull.

• A) We just need an API that can return the next subnet of a given mask size. The use case is that we plan to integrate this with terraform and/or bicep at the time of subnet creation, so the returned CIDR is immediately used and doesnt require a reservation.
• B) Thanks, I was not aware of it. Thought, it was only possible to see those via a GET call to reservation API.
• C) In our case, we donot require this feature at all. We are happy with the API.
• D) Cool 🥇. Today, my team keeps track of this via a wiki page, so definitely a New year gift :)

Wish you a Happy New Year ;-)

[DCMattyG]

Alright @binnykmathew, @iamastranger, and @letmetechyou....finally got some things to show off here!

I'm just about ready to push some major updates, but I'd love some feedback from each of you.

In order to check out the changes, please switch the container images your App Service is pointing to, by appending "dev" to each of them as follows:

There are A LOT of changes, but the specific ones interesting to this thread are:

1. Subnet Planner (Available from the Tools > Planner menu):

NOTE: The filter toggle in the upper right will allow you to flip between vNEt's mapped to a Space/Block, or all vNET's.

2. Experimental "Next Subnet from Virtual Network" API:

POST to this endpoint with the following body:

{
    "vnet_id": <Full Resource ID of the Target Virtual Network (string)>,
    "size": <Network Mask bits for target Subnet (integer)>
}

NOTE: I made this in the "tools" path because you can give it ANY vNET ID you have access to, not just one mapped to a space/block.

Looking forward to your feedback and getting this pushed out to live soon!

[DCMattyG]

Blocks is a list of Block names that exist within the Space, in this context.

[DCMattyG]

@binnykmathew, I think I'm mixing up two things here....

The directly above section is talking about creating a reservation from a Block in IPAM...either at the block level directly, or at the Space level by way of providing a list of Block from which to search for an available CIDR.

I think what you're referring to is not the reservations per-se, but the "Next subnet available in vNET" API....correct? If that is the case, it would look something like this:

{
    "vnet_id": <String: Full Resource ID of the Target Virtual Network>,
    "size": <Integer: Network Mask bits for target Subnet>,
    "reverse_search": <Boolean: If true, new subnets will be selected from as close to the END of the vNET as possible>,
    "smallest_cidr": <Boolean: If true, new subnets will be selected from the smallest available CIDR within the target vNET>
}

In this case, you can use reverse_search, smallest_cidr, or both depending on your use case.

Hope that clears things up!

[binnykmathew]

@DCMattyG Thanks for the clarification. Sorry that some of my replies also contributed to this confusion. All my replies in this thread has been in context of picking a Subnet from a Vnet. Yes, the above proposed changes (smallest_cidr reverse_search) in the "Next subnet available in vNET" API looks great to me.

(Edited )
Regarding the Reservation API, I dont have strong opinion on that. We are already using this API and as long as the "Blocks" field is not mandatory in the body , Iam ok with it. The changes that you make should be backward compatible.

[DCMattyG]

Good morning @binnykmathew. Completely understood, and allow me to provide some clarity. The above is a mix where we've been talking about 3 different API's.

The first one, which is the one you're referring to, is as follows:

You can see this API lives at the Block level, and as such doesn't require a list of Blocks as it uses the Block which is a part of the API url. Here we've added the reverse_search and smallest_cidr flags, however those are optional so the API is indeed backwards compatible.

The next one comes from a use case where you want to select a new CIDR from more thank one Block. It's format is as follows:

You can see here, since this API lives at the Space level, it requires a list of one or more Blocks that live beneath that Space from which to pull a new CIDR from. This could be a case where you have non-contiguous IP space, which may live on the same Azure Virtual Network, but be a part of two different Blocks as it cannot be summarized into a single CIDR. The longer term solution here is to allow more than one CIDR for a Block, but this is a simple way to address this without changing the architecture. This also has the reverse_search and smallest_cidr flags.

Finally, there is the nextAvailableSubnet API, which is designed as follows:

I've incorporated the same reverse_search and smallest_cidr flags here as well so the behavior is consistent across all 3 API's.

I hope that clears things up, you can test out the new DEV code by following the directions HERE (also can be found just above).

Please let me know if you need any further clarification, or if you have any issues with the DEV code.

Thank you as always for helping to make Azure IPAM better for everyone!

[binnykmathew]

@DCMattyG Thanks a lot for the clarification.
We will test it this week and let you know.