Device IP Allocation Workflow

[100Base-TX]

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?

[jeremystretch]

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.

[LBegnaud]

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

[100Base-TX]

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.

[Know1]

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"

[jeremystretch]

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

[LBegnaud]

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

[jeremystretch]

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

[LukeDRussell]

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.