Marking IP addresses as unavailable when populated range exists

[stockfx0]

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.

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.

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

[pheus]

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.

[stockfx0]

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.

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)