Netbox: 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..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.

[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" [e-mail] 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
.

[mlmingle]

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.

[jeremystretch]

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

[mlmingle]

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.

[jeremystretch]

@mlmingle The web UI already does that:

[mlmingle]

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 [e-mail]
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
.

[kasimon]

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.

[jeremystretch]

Finished implementing this in 30d160500704cfe442fcd7ec2d1f79aa9507d371. Pretty happy with how it turned out.

[MTecknology]

I'm excited to give it a try (next week, I hope)!