Enable treating IP ranges as fully populated #6679

@jeremystretch commented on GitHub (Jul 27, 2022):

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.

@jeremystretch commented on GitHub (Jul 27, 2022): > 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.

adam commented

@nem1989 commented on GitHub (Aug 3, 2022):

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.

@nem1989 commented on GitHub (Aug 3, 2022): > > 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.

adam commented

@CharlesSerrett commented on GitHub (Sep 13, 2022):

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.

@CharlesSerrett commented on GitHub (Sep 13, 2022): 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. ![image](https://user-images.githubusercontent.com/49439212/189995923-823595e6-5bb9-4e49-96db-43388d173d8c.png)

adam commented

@github-actions[bot] commented on GitHub (Nov 13, 2022):

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.

@github-actions[bot] commented on GitHub (Nov 13, 2022): 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](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).

adam commented

@elipsion commented on GitHub (Nov 15, 2022):

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.

@elipsion commented on GitHub (Nov 15, 2022): I'm unsure about the maintainers' opinion about this feature, since the tag removal on Aug. 8. The flowchart on [feature intake](https://github.com/netbox-community/netbox/wiki/Issue-Intake-Policy#feature-requests) 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.

adam commented

@fercalbla commented on GitHub (Nov 17, 2022):

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

@fercalbla commented on GitHub (Nov 17, 2022): > I'm unsure about the maintainers' opinion about this feature, since the tag removal on Aug. 8. The flowchart on [feature intake](https://github.com/netbox-community/netbox/wiki/Issue-Intake-Policy#feature-requests) 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

adam commented

@dutchman80 commented on GitHub (Dec 17, 2022):

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

@dutchman80 commented on GitHub (Dec 17, 2022): > 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. ![image](https://user-images.githubusercontent.com/49439212/189995923-823595e6-5bb9-4e49-96db-43388d173d8c.png) Or at least not show as "Available" in the IP Addresses tab of the Prefix view, like it does now

adam commented

@iamjla commented on GitHub (Feb 15, 2023):

@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

@iamjla commented on GitHub (Feb 15, 2023): @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

adam commented

@do9xe commented on GitHub (Mar 2, 2023):

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.

@do9xe commented on GitHub (Mar 2, 2023): 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.

adam commented

@github-actions[bot] commented on GitHub (Jun 1, 2023):

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.

@github-actions[bot] commented on GitHub (Jun 1, 2023): 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](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).

adam commented

@do9xe commented on GitHub (Jun 2, 2023):

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.

@do9xe commented on GitHub (Jun 2, 2023): 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.

adam commented

@nem1989 commented on GitHub (Jun 6, 2023):

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.

@nem1989 commented on GitHub (Jun 6, 2023): 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.

adam commented

@DanSheps commented on GitHub (Jun 6, 2023):

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.

@DanSheps commented on GitHub (Jun 6, 2023): 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.

adam commented

@parentsb commented on GitHub (Oct 23, 2023):

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

@parentsb commented on GitHub (Oct 23, 2023): Is there any updates on this? I'm keeping this page in bookmarks and checking it every month.

adam commented

@jmiezitis commented on GitHub (Oct 25, 2023):

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

@jmiezitis commented on GitHub (Oct 25, 2023): 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

adam commented

@DanSheps commented on GitHub (Oct 25, 2023):

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?

@DanSheps commented on GitHub (Oct 25, 2023): 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?

adam commented

@nem1989 commented on GitHub (Oct 25, 2023):

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

@nem1989 commented on GitHub (Oct 25, 2023): > 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 <role> 10 IPs DHCP 10 IPs Private ...

adam commented

@elipsion commented on GitHub (Oct 26, 2023):

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.

@elipsion commented on GitHub (Oct 26, 2023): > * 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.

adam commented

@jeremystretch commented on GitHub (Apr 2, 2025):

I'm currently working on this. I've introduced a new boolean named mark_populated on the IPRange model. I've opted for this name in part to avoid confusion with the "reserved" status, which is meant to indicate planned future use.

If true, mark_populated will cause NetBox to treat the range as though every IP address within the range already exists (even though the individual database records for those IPs do not). Note that this is distinct from the purpose of the existing mark_utilized boolean field, which instructs NetBox on how to represent a range when calculating the utilization of a parent object.

The child IP addresses view for a prefix has been extended to show ranges, IP, and available space in the table (see below). Only IP ranges with mark_populated=True will be included in the list.

This leaves us with four possible flag combinations for an IP range:

`mark_populated`	`mark_utilized`	Can create IPs in range?	Utilization reported
-	-	Yes	Calculated based on number of IPs
✅	-	No	0% (no IPs exist)
-	✅	Yes	100%
✅	✅	No	100%

The first case applies when an IP range is used merely for organization of the space within a prefix.

The second case is admittedly a bit esoteric, but I can see it being useful to represent e.g. recently reclaimed IP space.

The third case applies when you want to manage IPs within a range but always consider the range itself as utilized for planning purposes (probably the most common use case).

The final case is for effectively deferring the management of an IP range from NetBox to some other system (e.g. a DHCP server).

@jeremystretch commented on GitHub (Apr 2, 2025): I'm currently working on this. I've introduced a new boolean named `mark_populated` on the IPRange model. I've opted for this name in part to avoid confusion with the "reserved" status, which is meant to indicate planned future use. If true, `mark_populated` will cause NetBox to treat the range as though every IP address within the range already exists (even though the individual database records for those IPs do not). Note that this is distinct from the purpose of the existing `mark_utilized` boolean field, which instructs NetBox on how to represent a range when calculating the utilization of a parent object. The child IP addresses view for a prefix has been extended to show ranges, IP, and available space in the table (see below). Only IP ranges with `mark_populated=True` will be included in the list. ![Image](https://github.com/user-attachments/assets/05d72662-7c88-4377-9157-db5302650c56) This leaves us with four possible flag combinations for an IP range: | `mark_populated` | `mark_utilized` | Can create IPs in range? | Utilization reported | |--------------------|--------------------|--------------------------|-----------------------------------| | - | - | Yes | Calculated based on number of IPs | | :white_check_mark: | - | No | 0% (no IPs exist) | | - | :white_check_mark: | Yes | 100% | | :white_check_mark: | :white_check_mark: | No | 100% | The first case applies when an IP range is used merely for organization of the space within a prefix. The second case is admittedly a bit esoteric, but I can see it being useful to represent e.g. recently reclaimed IP space. The third case applies when you want to manage IPs within a range but always consider the range itself as utilized for planning purposes (probably the most common use case). The final case is for effectively deferring the management of an IP range from NetBox to some other system (e.g. a DHCP server).

adam commented

@DanSheps commented on GitHub (Apr 3, 2025):

Thanks for the summary table and the breakdown of what each case should be used for. Based on the description, I think this will accomplish what everyone is looking for.

@DanSheps commented on GitHub (Apr 3, 2025): Thanks for the summary table and the breakdown of what each case should be used for. Based on the description, I think this will accomplish what everyone is looking for.

adam commented