Implement reserved IP ranges

[nem1989]

NetBox version

v3.2.6

Feature type

New functionality

Proposed functionality

Improve IP ranges functionality by implementing these features:

• An option to display particular IP ranges in IP address lists.
• An option to mark an IP range as restricted/reserved/fully utilized. IP addresses within such ranges will not show up as available in any IP lists.

Use case

This would be extremely useful for DHCP ranges for instance. Right now nothing stops netbox users from using "free" IP addresses reserved for particular IP ranges.

Example: I have an IP range defined which describes DHCP range in one of my subnets, but when browsing IP address lists nothing indicates that these addresses are reserved, thus they can be assigned to any device or VM leading to an IP conflict.

There is a workaround: bulk create IP addresses for the whole range and set a corresponding role for them all. But in this scenario users have to manually match ranges and IP addresses in case of range changes and accidents may happen due to human factor. Also a lot of unnecessary information is stored in the database and displayed in IP lists especially for large IPv6 prefixes where there can be thousands of reserved addresses in one prefix.

With my proposal implemented one could mark an IP range as reserved and users would not be allowed to allocate addresses from reserved ranges anymore or atleast will be notified that these addresses are reserved. It would also decrease amount of excessive information in IP lists, dramatically in some cases.

These features are optional and will not break existing databases.

Database changes

Some new boolean fields for IP range description will be needed to implement this.

External dependencies

No response

[jeremystretch]

An option to display particular IP ranges in IP address lists.

Can you elaborate on this? How do you anticipate this working? What would the UI look like with this change in place?

An option to mark an IP range as restricted/reserved/fully utilized

This has already been captured in #7947.

[nem1989]

An option to display particular IP ranges in IP address lists.

Can you elaborate on this? How do you anticipate this working? What would the UI look like with this change in place?

An option to mark an IP range as restricted/reserved/fully utilized

This has already been captured in #7947.

I'm no UI designer but from my viewpoint in IP lists (doesn't matter if it is in prefix, filter or just all IPs list) there could be placeholders for IP ranges just like there are now for available ranges.

Like this: 10.177.100.1 10.177.100.2 100 IPs available (green) 100 IPs reserved (with reserved IP range Role in Role column) (yellow/red/configurable for each IP range?) 10.177.100.203 ...

Wether to show IP range in lists or not could be configured with either a checkbox or dropdown list inside IP range edit menu. With dropdown this functionality can be extended with reasons why range is reserved/utilized (if it is just utilized or intended to be used for a special purpose).

If there is an IP address within range it should be showed too.

Like this: 10.177.100.1 10.177.100.2 100 IPs available 49 IPs reserved 10.177.100.151 50 IPs reserved 10.177.100.203

Reserved ranges should be treated like available on-click - user can assign an IP from reserved range by clicking on it's placeholder in the list. But there should be some kind of a prompt when new IP is on reserved range. Like: "This IP is reserved, are you sure?" or a red/yellow/contrast informational note in IP edit menu saying that this IP is reserved so that reserved IPs could be used only on purpose and not accidentally.

There also could be a checkbox in IP range edit menu toggling if IP range is displayed in IP lists or not. Defaults to not so that nothing is changed for users not needing this functionality.

[CharlesSerrett]

This may increase the scope of the issue but I'd like to be able to assign DHCP and SLACC to IP ranges and then see this in the IP addresses view.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

[elipsion]

I'm unsure about the maintainers' opinion about this feature, since the tag removal on Aug. 8. The flowchart on feature intake seems to have lost track on "In scope for core?"

In any case, we also see a huge potential in this. Right now we have quite vast (/16 and larger) networks containing different DHCP scopes together with blocks of static assignments. It's a bit unwieldy to bulk create 10k addresses with status DHCP to have the usage calculator work and make sure nobody accidentally places a static IP in the DHCP scope.

[fercalbla]

I'm unsure about the maintainers' opinion about this feature, since the tag removal on Aug. 8. The flowchart on feature intake seems to have lost track on "In scope for core?"

In any case, we also see a huge potential in this. Right now we have quite vast (/16 and larger) networks containing different DHCP scopes together with blocks of static assignments. It's a bit unwieldy to bulk create 10k addresses with status DHCP to have the usage calculator work and make sure nobody accidentally places a static IP in the DHCP scope.

Same opinion here, we have lot of ranges for DHCP and this will be a very good feature to avoid people assigning these IPs

[dutchman80]

This may increase the scope of the issue but I'd like to be able to assign DHCP and SLACC to IP ranges and then see this in the IP addresses view.

Or at least not show as "Available" in the IP Addresses tab of the Prefix view, like it does now

[iamjla]

@jsenecal closed the above mentioned issue with the notice to continue here.

We've also got some proposals to shape this feature:

We would suggest "IP Ranges" gets the following 2 new booleans to add this functionality:

• "Exclude from Available IPs" This still allows creation of IPs of this IP Range but prohibits them from being used in available ip logic (API&UI)
• "Block creation of IPs in this Range" As the name suggests, any IP creation in this range should be blocked

tl;dr of the use case is saving on database entrys, as a lot comments in this issue mention. For a full explanation from our standing i'd suggest taking a look at #11678 The comment of @do9xe in #11678 adds some use cases as well

[do9xe]

I was just looking at the code and found a way how this might be possible. There is a function called add_available_ipaddresses() which creates a list of tuples that represent all the blocks that are free. You'd need to add ip-ranges into that function and add an additional element to the touples to distinguish between "free" and "reserved", maybe even a fourth so you could display the name of the range there.

I'd like to look into this and propose a pull-request, if this feature request is accepted.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

[do9xe]

According to the contribution guide I'm supposed to wait.

You're welcome to volunteer to implement your FR, but don't submit a pull request until it has been approved.

Now this FR/Issue is marked as pending closure again. I'm not quite sure if anyone from the maintainers has an eye on this.

[nem1989]

I see I should not be "bumping this" but I believe something went wrong here. Can this issue be under review and pending closure at the same time? It was not reviewed by maintainers and this will just lead to a creation of a new duplicate feature request after this one is closed.

[DanSheps]

Going to mark this as needs milestone as there clearly is a decent amount of interest in this.

@nem1989 Thank you for trying to follow the rules, however a thing to keep in mind is that pending closure is automatically added when there hasn't been much activity on an issue in a certain amount of time.

[parentsb]

Is there any updates on this? I'm keeping this page in bookmarks and checking it every month.

[jmiezitis]

We have mixed usage prefixes where one part of the prefix is allocated to openstack which deploys from that range using DHCP while other parts of the range are manually configured for different infrastructure. Doing what CharlesSerret suggests would be best from my and my teams point of view. At the moment, before allocating an address from the IP Address tab using the IP's Available button, we have to check the Child Prefix tab and Child Range tab to see if the IP is part of a Child Prefix pool or a Child Range. To help avoid mistakes this needs to be reduced to just viewing the IP Addresses tab where we should be able to see, in one place, how addresses are currently allocated;

• free and not allocated to a child range or child prefix pool with a button to click to reserve/use and address
• free and allocated to a child range or child prefix pool with a button to click to reserve/use and address
• reserved/used and not allocated to a child range or child prefix pool
• reserved/used and allocated to a child range or child prefix pool

[DanSheps]

To summarize this FR to be clear about the intended changes, this FR will:

• Add a boolean to disable the allocation of IP addresses, so long as those addresses fall within the range's serviced prefix and VRF
• Add UI indicators for this range to replace the "available IP(s)" with "reserved IP(s)" where IPs are impacted by these reseved ranges

Proposed changes:

• Add new boolean on the model to denote that a range is not available for allocation in netbox
• Add form fields for the specified boolean
• Modify the detail view of a prefix to retrieve ranges within the prefix and change any "available IP" indicators to "reserved"
• Modify the form clean() to disallow allocation of addresses within a reserved range

This sound somewhat reasonable to everyone?

[nem1989]

To summarize this FR to be clear about the intended changes, this FR will:

• Add a boolean to disable the allocation of IP addresses, so long as those addresses fall within the range's serviced prefix and VRF
• Add UI indicators for this range to replace the "available IP(s)" with "reserved IP(s)" where IPs are impacted by these reseved ranges

Proposed changes:

• Add new boolean on the model to denote that a range is not available for allocation in netbox
• Add form fields for the specified boolean
• Modify the detail view of a prefix to retrieve ranges within the prefix and change any "available IP" indicators to "reserved"
• Modify the form clean() to disallow allocation of addresses within a reserved range

This sound somewhat reasonable to everyone?

Sounds great!

There should be a link to a range itself from IP list views. Clicking available IP creates a new IP and clicking reserved IP would open a range view.

It also might be nice to have an IP range description/role indicator of some sort in IP list views so that one could see WHY is it reserved.

For example: 10 IPs 10 IPs DHCP 10 IPs Private ...

[elipsion]

• Modify the detail view of a prefix to retrieve ranges within the prefix and change any "available IP" indicators to "reserved"

I think it would be nice if the indicator displayed the status from the range object, instead of just showing a generic "reserved" keyword.