starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-13 13:53:31 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Device IP Allocation Workflow #514

New Issue
Closed
opened 2025-12-29 16:22:46 +01:00 by adam · 8 comments
adam commented 2025-12-29 16:22:46 +01:00
Owner
Copy Link

Originally created by @100Base-TX on GitHub (Nov 3, 2016).

Hi,
I've recently installed Netbox and have started to migrate from the old IPAM. So far it's been mostly excellent.
The one thing i've found to be very clunky is the process of allocating new IP addresses to devices. Maybe i'm just doing it wrong, but it's basically:

  1. Go to IP Space --> Prefixes
  2. Find the prefix i want to allocate from
  3. Click IP Addresses tab
  4. Click the " free IPs" button
  5. Copy or note down the IP it allocates in the form
  6. Click "Devices" --> "Add a Device"
  7. Create the device
  8. Click "Add an IP Address", paste in the address from step 5

It works, it's just a pretty long winded workflow.
Is there a more streamlined way of approaching this that i'm not using?
If this is the best way of doing it at the moment, perhaps it should be an option for allocating an binding an IP to a device/interface in the "IP Space" --> "Prefixes" area. Or some sort of "get next available IP in Subnet" option when adding an IP to an interface as per step 8.
Thoughts?

Originally created by @100Base-TX on GitHub (Nov 3, 2016). Hi, I've recently installed Netbox and have started to migrate from the old IPAM. So far it's been mostly excellent. The one thing i've found to be very clunky is the process of allocating new IP addresses to devices. Maybe i'm just doing it wrong, but it's basically: 1. Go to IP Space --> Prefixes 2. Find the prefix i want to allocate from 3. Click IP Addresses tab 4. Click the "<num> free IPs" button 5. Copy or note down the IP it allocates in the form 6. Click "Devices" --> "Add a Device" 7. Create the device 8. Click "Add an IP Address", paste in the address from step 5 It works, it's just a pretty long winded workflow. Is there a more streamlined way of approaching this that i'm not using? If this is the best way of doing it at the moment, perhaps it should be an option for allocating an binding an IP to a device/interface in the "IP Space" --> "Prefixes" area. Or some sort of "get next available IP in Subnet" option when adding an IP to an interface as per step 8. Thoughts?
adam closed this issue 2025-12-29 16:22:46 +01:00
adam commented 2025-12-29 16:22:47 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 3, 2016):

This really depends on whether you're okay with blinding assigning the first available IP from a prefix. In most cases, I would assume you'd want to first verify what IPs are available within the prefix.

For example, let's say you want to assign an IP to each of ten new devices, and you want the IPs to be consecutive. You allocate the IPs out of 192.0.2.0/24 and the first available IP you get is 192.0.2.10. Okay, so we'll use 192.0.2.10 through 192.0.2.19. But then halfway through you find out that .15 was already taken for something else. Now you have to go back and change the assigned IPs to all fit in an available consecutive range. It would have been much more efficient to check what was assigned to the prefix in the first place.

It's also worth noting that you can import and assign IP addresses in bulk.

@jeremystretch commented on GitHub (Nov 3, 2016): This really depends on whether you're okay with blinding assigning the first available IP from a prefix. In most cases, I would assume you'd want to first verify what IPs are available within the prefix. For example, let's say you want to assign an IP to each of ten new devices, and you want the IPs to be consecutive. You allocate the IPs out of 192.0.2.0/24 and the first available IP you get is 192.0.2.10. Okay, so we'll use 192.0.2.10 through 192.0.2.19. But then halfway through you find out that .15 was already taken for something else. Now you have to go back and change the assigned IPs to all fit in an available consecutive range. It would have been much more efficient to check what was assigned to the prefix in the first place. It's also worth noting that you can import and assign IP addresses in bulk.
adam commented 2025-12-29 16:22:47 +01:00
Author
Owner
Copy Link

@LBegnaud commented on GitHub (Nov 3, 2016):

I second @100Base-TX 's idea

Our workflow for deploying a new customer in our hosting requires assigning the next WAN address from our routed subnet. This process is just as cumbersome it is described above for us.

Our procedure currently is to go to all the relevant places to find the "next" item, then document it all into an internal system which spits out the csv data to import. While this works, it would be nice to be able to choose "use next available IP" when assigning an IP to a device's interface. Or even dropdown menus that let you choose prefix, then lists the IPs.

All that said, our workflow works, I just wish it were a little more streamlined (perhaps r/w api will solve the problem :) )

@LBegnaud commented on GitHub (Nov 3, 2016): I second @100Base-TX 's idea Our workflow for deploying a new customer in our hosting requires assigning the next WAN address from our routed subnet. This process is just as cumbersome it is described above for us. Our procedure currently is to go to all the relevant places to find the "next" item, then document it all into an internal system which spits out the csv data to import. While this works, it would be nice to be able to choose "use next available IP" when assigning an IP to a device's interface. Or even dropdown menus that let you choose prefix, then lists the IPs. All that said, our workflow works, I just wish it were a little more streamlined (perhaps r/w api will solve the problem :) )
adam commented 2025-12-29 16:22:47 +01:00
Author
Owner
Copy Link

@100Base-TX commented on GitHub (Nov 4, 2016):

Yeah I can see situations where a "next available" would be an issue.

Two reasonable (from a UX perspective) options I can see is:

In the device IP Assignment form, allow the user to search for a prefix. Easiest to implement would probably be typing in the Network IP Address (10.1.2.0/24 for example), however being able to search for a prefix by vlan/prefix name etc would be handy. This would then show more or less what is shown in /ipam/prefixes//ip-addresses/, allowing the user to determine what IP's are used, and what is free.

In the IP Assignment form (url like /ip-addresses/add/?address=10.1.2.1/24), allow the user to assign the IP to a device/interface. It would just involve having a pair of optional drop down list (would have to be filterable i suppose), for Device + Interface.

Doing it in bulk certainly helps. However at least in my workplace, 95% of allocations are driven by "Hey, i'm spinning up a new server, I want to allocate it an IP Address". So CSV import isn't very useful in this instance. And at the moment, the workflow described in OP appears to be the only realistic way to achieve it.

@100Base-TX commented on GitHub (Nov 4, 2016): Yeah I can see situations where a "next available" would be an issue. Two reasonable (from a UX perspective) options I can see is: 1) In the device IP Assignment form, allow the user to search for a prefix. Easiest to implement would probably be typing in the Network IP Address (10.1.2.0/24 for example), however being able to search for a prefix by vlan/prefix name etc would be handy. This would then show more or less what is shown in /ipam/prefixes/<num>/ip-addresses/, allowing the user to determine what IP's are used, and what is free. 2) In the IP Assignment form (url like /ip-addresses/add/?address=10.1.2.1/24), allow the user to assign the IP to a device/interface. It would just involve having a pair of optional drop down list (would have to be filterable i suppose), for Device + Interface. Doing it in bulk certainly helps. However at least in my workplace, 95% of allocations are driven by "Hey, i'm spinning up a new server, I want to allocate it an IP Address". So CSV import isn't very useful in this instance. And at the moment, the workflow described in OP appears to be the only realistic way to achieve it.
adam commented 2025-12-29 16:22:47 +01:00
Author
Owner
Copy Link

@Know1 commented on GitHub (Nov 4, 2016):

I had also mentioned something like this in another issue. I think the workflow could be streamlined as 100Base-TX suggested above, some sort of next available or pop up the free IPs like the IP Address add window.
Having to go and manually find out what IPs are free every time, either through another tab/page in Netbox or running nmap for every new IP is more work than editing the occasional IP or IPs where someone has failed to follow process as cited in the example. As stated in the "Why Netbox doesn't scan IPs" (which I agree with)
"All this boils down to a single concept: NetBox is intended to represent the intended state of the network, as defined by humans"

@Know1 commented on GitHub (Nov 4, 2016): I had also mentioned something like this in another issue. I think the workflow could be streamlined as 100Base-TX suggested above, some sort of next available or pop up the free IPs like the IP Address add window. Having to go and manually find out what IPs are free every time, either through another tab/page in Netbox or running nmap for every new IP is more work than editing the occasional IP or IPs where someone has failed to follow process as cited in the example. As stated in the "Why Netbox doesn't scan IPs" (which I agree with) "All this boils down to a single concept: NetBox is intended to represent the intended state of the network, as defined by humans"
adam commented 2025-12-29 16:22:47 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 4, 2016):

@100Base-TX:

  1. In the device IP Assignment form, allow the user to search for a prefix. Easiest to implement would probably be typing in the Network IP Address (10.1.2.0/24 for example), however being able to search for a prefix by vlan/prefix name etc would be handy. This would then show more or less what is shown in /ipam/prefixes//ip-addresses/, allowing the user to determine what IP's are used, and what is free.

A user might want to identify an IP by prefix, VRF, site, and/or tenant. That's a lot to try and squeeze into a single form, which is why I recommend using the dedicated IP/prefix views. It also avoids blindly assigning IPs without knowing what's already allocated within a prefix.

  1. In the IP Assignment form (url like /ip-addresses/add/?address=10.1.2.1/24), allow the user to assign the IP to a device/interface. It would just involve having a pair of optional drop down list (would have to be filterable i suppose), for Device + Interface.

A more direct way of achieving this is to first navigate to the device from the device list, then assign an IP to one of its interfaces using the IP assignment form. (This form was admittedly limited prior to v1.7.0 but was improved just recently.)

@Know1:

Having to go and manually find out what IPs are free every time, either through another tab/page in Netbox or running nmap for every new IP is more work than editing the occasional IP or IPs where someone has failed to follow process as cited in the example.

In the scenario I provided above, 192.0.2.15/24 was already added to NetBox correctly by someone else and was intended to be there. My point is that you couldn't have known that without first verifying that the entire range of desired IPs is in fact available. A naive "next free IP" button can't provide you that information, which is why I recommend always checking the parent prefix before assigning a new IP.

@jeremystretch commented on GitHub (Nov 4, 2016): @100Base-TX: > 1) In the device IP Assignment form, allow the user to search for a prefix. Easiest to implement would probably be typing in the Network IP Address (10.1.2.0/24 for example), however being able to search for a prefix by vlan/prefix name etc would be handy. This would then show more or less what is shown in /ipam/prefixes//ip-addresses/, allowing the user to determine what IP's are used, and what is free. A user might want to identify an IP by prefix, VRF, site, and/or tenant. That's a lot to try and squeeze into a single form, which is why I recommend using the dedicated IP/prefix views. It also avoids blindly assigning IPs without knowing what's already allocated within a prefix. > 2) In the IP Assignment form (url like /ip-addresses/add/?address=10.1.2.1/24), allow the user to assign the IP to a device/interface. It would just involve having a pair of optional drop down list (would have to be filterable i suppose), for Device + Interface. A more direct way of achieving this is to first navigate to the device from the device list, then assign an IP to one of its interfaces using the IP assignment form. (This form was admittedly limited prior to v1.7.0 but was improved just recently.) @Know1: > Having to go and manually find out what IPs are free every time, either through another tab/page in Netbox or running nmap for every new IP is more work than editing the occasional IP or IPs where someone has failed to follow process as cited in the example. In the scenario I provided above, 192.0.2.15/24 was already added to NetBox correctly by someone else and was intended to be there. My point is that you couldn't have known that without first verifying that the entire range of desired IPs is in fact available. A naive "next free IP" button can't provide you that information, which is why I recommend always checking the parent prefix before assigning a new IP.
adam commented 2025-12-29 16:22:48 +01:00
Author
Owner
Copy Link

@LBegnaud commented on GitHub (Nov 4, 2016):

Yes I agree that the ability to assign IPs to interfaces from the IP side of things improves the workflow tremendously in 1.7.

@LBegnaud commented on GitHub (Nov 4, 2016): Yes I agree that the ability to assign IPs to interfaces from the IP side of things improves the workflow tremendously in 1.7.
adam commented 2025-12-29 16:22:48 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 14, 2016):

Closing this out as I don't think there's really anything actionable.

@jeremystretch commented on GitHub (Nov 14, 2016): Closing this out as I don't think there's really anything actionable.
adam commented 2025-12-29 16:22:48 +01:00
Author
Owner
Copy Link

@LukeDRussell commented on GitHub (Nov 28, 2016):

I still think there is work to be done with this. I'm not in a position to do anything myself just yet but hopefully in the near future.

I am totally OK with blindly accepting the next available IP from a subnet, or next available subnet from a supernet. It is a critical feature of the write API in my opinion.

@LukeDRussell commented on GitHub (Nov 28, 2016): I still think there is work to be done with this. I'm not in a position to do anything myself just yet but hopefully in the near future. I am totally OK with blindly accepting the next available IP from a subnet, or next available subnet from a supernet. It is a critical feature of the write API in my opinion.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#514
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?