Next Available IP Address

[MTecknology]

Feature Request: Support for requesting next available IP address in a subnet/vlan/prefix

When adding a system, it'd be nice to have some way to specify a vlan/prefix for an address and have the next available IP address pulled from that pool.

My goal is to use netbox in an "inventory defined infrastructure" project and finding a sane way to allocate IP addresses is something I assumed would already be a feature, but I'm not finding it anywhere.

[jeremystretch]

This FR needs more detail. How would you implement this feature? How would you go about retrieving the next available IP?

[MTecknology]

Apparently it's a less common feature than I thought.
This! http://api.device42.com/#suggest-next-available-subnet

Request an IP address from a prefix, know that this IP address is used by nothing else and has been reserved for use, assign it to a network interface. It'd be nice to be able to request an address from a prefix when creating the device, but that may be pushing the scope of netbox design.

[jeremystretch]

Do you just want an API endpoint? We should be able to do something like /api/ipam/prefixes/<pk>/available-ips/ to retrieve all available IPs from a prefix. The client could pick however many they need from the list.

Or do you also want this to be integrated with the web UI? If so, how do you envision this being implemented? E.g. a button on the "create IP" view, a separate view, or something else?

[cimnine]

It should be possible to limit the amount of available ips returned by such an available-ips endpoint, as it could potentially be huge for IPv6 prefixes.

[jeremystretch]

@cimnine All object lists returned via the API are paginated (to 50 objects per page by default). You can also add ?limit=1 to retrieve a single object.

[MTecknology]

The point is to use the API to claim an available address and know it won't be in use. If we use a script to get a list, then try to create the address, there's a chance it will have been claimed by another process so then a script needs to handle that error condition and make another attempt and keep going until it's claimed one not in use. ... I realize it first sounds like an unlikely race condition and easily handled, but depending on who writes the scripts/processes, it could be very easy to deploy multiple systems with the same address. If, however, we can simply request the next available address in a subnet, we can trust that netbox marked an address reserved (or active?) just for this request. If we need more addresses, my vote is to require multiple queries. Perhaps, the response we get back could include an ID that could be passed to the create device call instead of manually assigned after the creation! :) As far as the API call... The example I provided makes the most sense to me. Request an address suggestion from the subnet and optionally mark it reserved.

[jeremystretch]

Ok, so let's say we build /api/ipam/prefixes/<pk>/available-ips/.

A GET request would return a paginated list of available IPs (calculated with consideration to is_pool).

A POST request would accept a subset of the fields of the normal IPAddress serializer (tenant, status, interface, etc.). The address field would be taken from the first available IP, and vrf would be inherited from the parent prefix. The response would include the full serialization of the created object.

PUT and DELETE operations would of course be unavailable.

Seems like it should be feasible. The only catch is what to do about IPv6. Is there any practical use for this function for IPv6, given that a /64 is effectively infinite in size? It might be prudent to simply disable this feature for IPv6 prefixes (returning a human-friendly error for GETs and POSTs).

[MTecknology]

A POST request would accept a subset of the fields of the normal IPAddress serializer (tenant, status, interface, etc.). The address field would be taken from the first available IP, and vrf would be inherited from the parent prefix. The response would include the full serialization of the created object. This sounds perfect! A little gold plating... Maybe also include a start/stop within the prefix range? I recall seeing that feature request buried on a thread somewhere for a different project. They wanted to be able to avoid getting addresses from special spaces within the subnet, like avoiding .8x for routing/switching devices. Granted, the same thing can be achieved by marking address in that space as reserved. Seems like it should be feasible. The only catch is what to do about IPv6. Is there any practical use for this function for IPv6, given that a /64 is effectively infinite in size? It might be prudent to simply disable this feature for IPv6 prefixes (returning a human-friendly error for GETs and POSTs). In my environment, I have a /48 and I use it to create a /64 with the vlan ID. So I'll request a v4 address for the prefix in that vlan and then use that address to build the v6 address. 10.22.<vlan>.45/22 --> 2001:23:45:<vlan>::45/64 For me, I just need something from v4 and I'll assign the v6 address from that. However, if I wasn't using ipv4, I'd want the same thing available for ipv6. The v6 pool sizes are virtually limitless, but the things we can do in those spaces is also pretty much limitless. I can think of a number of situations where it would be preferable to have ipv6 come from inventory management, most of them involve datacenter design.

[jeremystretch]

A little gold plating... Maybe also include a start/stop within the prefix range? I recall seeing that feature request buried on a thread somewhere for a different project. They wanted to be able to avoid getting addresses from special spaces within the subnet, like avoiding .8x for routing/switching devices. Granted, the same thing can be achieved by marking address in that space as reserved.

I'd like to keep the automatic provisioning logic simple. If there are special rules about where to pick the IP from, the user will have to request a specific IP. It will still be possible to obtain a list of available IPs first.

However, if I wasn't using ipv4, I'd want the same thing available for ipv6. The v6 pool sizes are virtually limitless, but the things we can do in those spaces is also pretty much limitless. I can think of a number of situations where it would be preferable to have ipv6 come from inventory management, most of them involve datacenter design.

The biggest issue is conforming to the API's pagination structure, which includes a total count of objects found. An empty /64 would contain 2^64 objects, all except a few of which we don't care about. I'll have to see if we can easily "fake" the numbers instead of actually creating a list of a bajillion IPs in memory.

[MTecknology]

What about artificially limiting it to the first 1,000 for both v4 and v6?

…

On Jun 7, 2017 13:46, "Jeremy Stretch" ***@***.***> wrote: A little gold plating... Maybe also include a start/stop within the prefix range? I recall seeing that feature request buried on a thread somewhere for a different project. They wanted to be able to avoid getting addresses from special spaces within the subnet, like avoiding .8x for routing/switching devices. Granted, the same thing can be achieved by marking address in that space as reserved. I'd like to keep the automatic provisioning logic simple. If there are special rules about where to pick the IP from, the user will have to request a specific IP. It will still be possible to obtain a list of available IPs first. However, if I wasn't using ipv4, I'd want the same thing available for ipv6. The v6 pool sizes are virtually limitless, but the things we can do in those spaces is also pretty much limitless. I can think of a number of situations where it would be preferable to have ipv6 come from inventory management, most of them involve datacenter design. The biggest issue is conforming to the API's pagination structure, which includes a total count of objects found. An empty /64 would contain 2^64 objects, all except a few of which we don't care about. I'll have to see if we can easily "fake" the numbers instead of actually creating a list of a bajillion IPs in memory. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1246 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABWRNnlQY2aX9vRJePZqXHr18E0N5EiRks5sBwwggaJpZM4NvuCS> .