Next Available IP Address #1246
Comments
|
This FR needs more detail. How would you implement this feature? How would you go about retrieving the next available IP? |
|
Apparently it's a less common feature than I thought. 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. |
|
Do you just want an API endpoint? We should be able to do something like 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? |
|
It should be possible to limit the amount of available ips returned by such an |
|
@cimnine All object lists returned via the API are paginated (to 50 objects per page by default). You can also add |
|
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.
|
|
Ok, so let's say we build A GET request would return a paginated list of available IPs (calculated with consideration to A POST request would accept a subset of the fields of the normal IPAddress serializer ( 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). |
|
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.
|
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.
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. |
|
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>
.
|
|
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. |
|
@mlmingle Any address not defined in NetBox is assumed to be available. |
|
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. |
|
@mlmingle The web UI already does that:
|
|
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 ***@***.***> 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
<#1246 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ANX_o5pLnWh8amTHTHisRLlbHcTijhCvks5sD_eHgaJpZM4NvuCS>
.
|
|
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. |
|
Finished implementing this in 30d1605. Pretty happy with how it turned out. |
|
I'm excited to give it a try (next week, I hope)! |
…ailable IPs for a prefix
…vailable IP address within a prefix
The schema provided by NetBox for getting a next IP address is incorrect, which means generated API clients are also incorrect. I have reported this issue in netbox-community/netbox#1246.
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.
The text was updated successfully, but these errors were encountered: