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

Marking IP addresses as unavailable when populated range exists #11825

New Issue
Open
opened 2025-12-29 21:50:19 +01:00 by adam · 2 comments
adam commented 2025-12-29 21:50:19 +01:00
Owner
Copy Link

Originally created by @stockfx0 on GitHub (Nov 12, 2025).

NetBox version

v4.4.5

Feature type

Change to existing functionality

Proposed functionality

In netbox it's possible to create child range for prefix and to mark it as populated to prevent creating new addresses.
Image
But in prefix's addres list ones from range are still marked as "available". When click to this "available", open menu of address creation but due to populated range, address is not created.

Image

it would be better when if there is a populated range, addresses in it are not marked in list as available. For this case, first green available address has to be .21.

Use case

We not not automate creation of VMs and we do not use DHCP. Addresses are scanned from ARP tables. Users open prefixes to see for available IPs to manually assign to VM or server, but we need to have some addresses unused and we can't mark it visually explicitly.

Database changes

No response

External dependencies

No response

Originally created by @stockfx0 on GitHub (Nov 12, 2025). ### NetBox version v4.4.5 ### Feature type Change to existing functionality ### Proposed functionality In netbox it's possible to create child range for prefix and to mark it as populated to prevent creating new addresses. <img width="1424" height="385" alt="Image" src="https://github.com/user-attachments/assets/d96e940f-f5a8-4632-9638-753c88ec68ed" /> But in prefix's addres list ones from range are still marked as "available". When click to this "available", open menu of address creation but due to populated range, address is not created. <img width="1394" height="939" alt="Image" src="https://github.com/user-attachments/assets/8cb06265-f621-443a-bc81-89c299d55e90" /> it would be better when if there is a populated range, addresses in it are not marked in list as available. For this case, first green available address has to be .21. ### Use case We not not automate creation of VMs and we do not use DHCP. Addresses are scanned from ARP tables. Users open prefixes to see for available IPs to manually assign to VM or server, but we need to have some addresses unused and we can't mark it visually explicitly. ### Database changes _No response_ ### External dependencies _No response_
adam added the type: featurestatus: needs ownernetboxcomplexity: low labels 2025-12-29 21:50:19 +01:00
adam commented 2025-12-29 21:50:20 +01:00
Author
Owner
Copy Link

@pheus commented on GitHub (Nov 13, 2025):

Thanks for opening this issue — and for the clear screenshot.

From what I can see, this looks like a side effect of how “mark populated” works on IP ranges. I suspect the IP addresses were created before the IP range was defined with mark populated. When the range is created first (with mark populated checked), NetBox marks all addresses in the range as reserved and prevents creating new IP addresses there — which matches what you’re seeing in the first row of your screenshot. However, if IP addresses already exist and you then create the range with mark populated, NetBox doesn’t retroactively reserve those existing addresses.

Intent of “mark populated”
The idea behind mark populated is to treat every IP in the range as “in use / not available for assignment / managed outside of NetBox” (e.g., by a DHCP server). It’s a way to protect the space from new allocations rather than a per‑address permission mechanism.

If your goal is access control:

  • Consider splitting the space into multiple IP ranges (e.g., one for managed by “team A” and one for “team B”).
  • Use NetBox object permissions to restrict who can create IP addresses within the range while still allowing documentation of actual usage.

Possible improvement / bug:
It feels inconsistent that you can create an IP range with mark populated while IP addresses in that range already exist, without blocking the operation with a clear validation error.

@pheus commented on GitHub (Nov 13, 2025): Thanks for opening this issue — and for the clear screenshot. From what I can see, this looks like a side effect of how **“mark populated”** works on IP ranges. I suspect the IP addresses were created *before* the IP range was defined with **mark populated**. When the range is created first (with **mark populated** checked), NetBox marks all addresses in the range as **reserved** and prevents creating new IP addresses there — which matches what you’re seeing in the first row of your screenshot. However, if IP addresses already exist and you then create the range with **mark populated**, NetBox doesn’t retroactively reserve those existing addresses. **Intent of “mark populated”** The idea behind **mark populated** is to treat every IP in the range as “in use / not available for assignment / managed outside of NetBox” (e.g., by a DHCP server). It’s a way to protect the space from new allocations rather than a per‑address permission mechanism. **If your goal is access control:** - Consider splitting the space into **multiple IP ranges** (e.g., one for managed by “team A” and one for “team B”). - Use **NetBox object permissions** to restrict who can create IP addresses within the range while still allowing documentation of actual usage. **Possible improvement / bug:** It feels inconsistent that you can create an IP range with **mark populated** while IP addresses in that range already exist, without blocking the operation with a clear validation error.
adam commented 2025-12-29 21:50:21 +01:00
Author
Owner
Copy Link

@stockfx0 commented on GitHub (Nov 13, 2025):

Thanks for opening this issue — and for the clear screenshot.

From what I can see, this looks like a side effect of how “mark populated” works on IP ranges. I suspect the IP addresses were created before the IP range was defined with mark populated. When the range is created first (with mark populated checked), NetBox marks all addresses in the range as reserved and prevents creating new IP addresses there — which matches what you’re seeing in the first row of your screenshot. However, if IP addresses already exist and you then create the range with mark populated, NetBox doesn’t retroactively reserve those existing addresses.

Intent of “mark populated” The idea behind mark populated is to treat every IP in the range as “in use / not available for assignment / managed outside of NetBox” (e.g., by a DHCP server). It’s a way to protect the space from new allocations rather than a per‑address permission mechanism.

If your goal is access control:

  • Consider splitting the space into multiple IP ranges (e.g., one for managed by “team A” and one for “team B”).
  • Use NetBox object permissions to restrict who can create IP addresses within the range while still allowing documentation of actual usage.

Possible improvement / bug: It feels inconsistent that you can create an IP range with mark populated while IP addresses in that range already exist, without blocking the operation with a clear validation error.

Addresses existing before creating a range is not a problem. A problem is that in list there are lines with "available" addresses when they are in range.

Image IMO if look at my first screenshot, first line with available addresses has to be after 192.168.249.19 and it has to have 10 addresses available instad of 11 (as 192.168.249.20 is busy due to range)
@stockfx0 commented on GitHub (Nov 13, 2025): > Thanks for opening this issue — and for the clear screenshot. > > From what I can see, this looks like a side effect of how **“mark populated”** works on IP ranges. I suspect the IP addresses were created _before_ the IP range was defined with **mark populated**. When the range is created first (with **mark populated** checked), NetBox marks all addresses in the range as **reserved** and prevents creating new IP addresses there — which matches what you’re seeing in the first row of your screenshot. However, if IP addresses already exist and you then create the range with **mark populated**, NetBox doesn’t retroactively reserve those existing addresses. > > **Intent of “mark populated”** The idea behind **mark populated** is to treat every IP in the range as “in use / not available for assignment / managed outside of NetBox” (e.g., by a DHCP server). It’s a way to protect the space from new allocations rather than a per‑address permission mechanism. > > **If your goal is access control:** > > * Consider splitting the space into **multiple IP ranges** (e.g., one for managed by “team A” and one for “team B”). > * Use **NetBox object permissions** to restrict who can create IP addresses within the range while still allowing documentation of actual usage. > > **Possible improvement / bug:** It feels inconsistent that you can create an IP range with **mark populated** while IP addresses in that range already exist, without blocking the operation with a clear validation error. Addresses existing before creating a range is not a problem. A problem is that in list there are lines with "available" addresses when they are in range. <img width="1086" height="59" alt="Image" src="https://github.com/user-attachments/assets/2f48d3e2-c43d-4fee-b132-b3d252645fcf" /> IMO if look at my first screenshot, first line with available addresses has to be after 192.168.249.19 and it has to have 10 addresses available instad of 11 (as 192.168.249.20 is busy due to range)
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 complexity: low netbox status: needs owner type: feature
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#11825
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?