Next Available IP Address #1010

@jeremystretch commented on GitHub (Jun 6, 2017):

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

@jeremystretch commented on GitHub (Jun 6, 2017): This FR needs more detail. How would you implement this feature? How would you go about retrieving the next available IP?

adam commented

@MTecknology commented on GitHub (Jun 7, 2017):

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.

@MTecknology commented on GitHub (Jun 7, 2017): 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.

adam commented

@jeremystretch commented on GitHub (Jun 7, 2017):

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?

@jeremystretch commented on GitHub (Jun 7, 2017): 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?

adam commented

@cimnine commented on GitHub (Jun 7, 2017):

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.

@cimnine commented on GitHub (Jun 7, 2017): 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.

adam commented

@jeremystretch commented on GitHub (Jun 7, 2017):

@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.

@jeremystretch commented on GitHub (Jun 7, 2017): @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.

adam commented

@MTecknology commented on GitHub (Jun 7, 2017):

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.

@MTecknology commented on GitHub (Jun 7, 2017): 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.

adam commented

@jeremystretch commented on GitHub (Jun 7, 2017):

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).

@jeremystretch commented on GitHub (Jun 7, 2017): 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).

adam commented

@MTecknology commented on GitHub (Jun 7, 2017):

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..45/22
--> 2001:23:45:::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.

@MTecknology commented on GitHub (Jun 7, 2017): 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.

adam commented

@jeremystretch commented on GitHub (Jun 7, 2017):

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.

@jeremystretch commented on GitHub (Jun 7, 2017): > 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.

adam commented

@MTecknology commented on GitHub (Jun 8, 2017):

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

On Jun 7, 2017 13:46, "Jeremy Stretch" notifications@github.com 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
https://github.com/digitalocean/netbox/issues/1246#issuecomment-306919537,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABWRNnlQY2aX9vRJePZqXHr18E0N5EiRks5sBwwggaJpZM4NvuCS
.

@MTecknology commented on GitHub (Jun 8, 2017): What about artificially limiting it to the first 1,000 for both v4 and v6? On Jun 7, 2017 13:46, "Jeremy Stretch" <notifications@github.com> 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 > <https://github.com/digitalocean/netbox/issues/1246#issuecomment-306919537>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/ABWRNnlQY2aX9vRJePZqXHr18E0N5EiRks5sBwwggaJpZM4NvuCS> > . >

adam commented

@minglematt commented on GitHub (Jun 14, 2017):

It would be nice to have an "Available" option added to the Status of IP Addresses. That way you could add the entire subnet and set the status Available on the IPs that are not in use.

@minglematt commented on GitHub (Jun 14, 2017): It would be nice to have an "Available" option added to the Status of IP Addresses. That way you could add the entire subnet and set the status Available on the IPs that are not in use.

adam commented

@jeremystretch commented on GitHub (Jun 14, 2017):

@mlmingle Any address not defined in NetBox is assumed to be available.

@jeremystretch commented on GitHub (Jun 14, 2017): @mlmingle Any address not defined in NetBox is assumed to be available.

adam commented

@minglematt commented on GitHub (Jun 14, 2017):

I see that if the IP is not listed, but it would be nice if you could list it in the IP addresses Tab under the prefix and just give it a status of Available. Then you could see what is available and what is used and could go there to find whats next.

@minglematt commented on GitHub (Jun 14, 2017): I see that if the IP is not listed, but it would be nice if you could list it in the IP addresses Tab under the prefix and just give it a status of Available. Then you could see what is available and what is used and could go there to find whats next.

adam commented

@jeremystretch commented on GitHub (Jun 14, 2017):

@mlmingle The web UI already does that:

@jeremystretch commented on GitHub (Jun 14, 2017): @mlmingle The web UI already does that: ![available_ips](https://user-images.githubusercontent.com/13487278/27139712-bad911b6-50f1-11e7-8e3a-a88e56ad401f.png)

adam commented

@minglematt commented on GitHub (Jun 14, 2017):

Ok well maybe I am doing something wrong then. We are adding the ENTIRE
Prefix. So ALL 255 IPs of a /24 to the list. Some will be used and have a
description which are marked active, but there is not a status to set the
unused ones to Available. Not a huge deal, we are just used to it with
other IPAM software we have used. Otherwise you would need to add and IP
each time you use it instead of just editing it and changing the
description.

Matt

On Wed, Jun 14, 2017 at 11:08 AM, Jeremy Stretch notifications@github.com
wrote:

@mlmingle https://github.com/mlmingle The web UI already does that:

[image: available_ips]
https://user-images.githubusercontent.com/13487278/27139712-bad911b6-50f1-11e7-8e3a-a88e56ad401f.png

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/digitalocean/netbox/issues/1246#issuecomment-308461719,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ANX_o5pLnWh8amTHTHisRLlbHcTijhCvks5sD_eHgaJpZM4NvuCS
.

@minglematt commented on GitHub (Jun 14, 2017): Ok well maybe I am doing something wrong then. We are adding the ENTIRE Prefix. So ALL 255 IPs of a /24 to the list. Some will be used and have a description which are marked active, but there is not a status to set the unused ones to Available. Not a huge deal, we are just used to it with other IPAM software we have used. Otherwise you would need to add and IP each time you use it instead of just editing it and changing the description. ![ips](https://user-images.githubusercontent.com/14024611/27145377-927af2b8-5103-11e7-8ffb-0457297271c7.png) Matt On Wed, Jun 14, 2017 at 11:08 AM, Jeremy Stretch <notifications@github.com> wrote: > @mlmingle <https://github.com/mlmingle> The web UI already does that: > > [image: available_ips] > <https://user-images.githubusercontent.com/13487278/27139712-bad911b6-50f1-11e7-8e3a-a88e56ad401f.png> > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <https://github.com/digitalocean/netbox/issues/1246#issuecomment-308461719>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/ANX_o5pLnWh8amTHTHisRLlbHcTijhCvks5sD_eHgaJpZM4NvuCS> > . >

adam commented

@kasimon commented on GitHub (Jun 14, 2017):

Especially for IPv6, having a start, stop (default to first/last ip of an subnet) and max_amount parameter, which would default to a globally set maximum value and can only be set to a lower value that that maximum, would make quite some sense.

@kasimon commented on GitHub (Jun 14, 2017): Especially for IPv6, having a start, stop (default to first/last ip of an subnet) and max_amount parameter, which would default to a globally set maximum value and can only be set to a lower value that that maximum, would make quite some sense.

adam commented