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

Add an “exclude_from_allocation” flag to IPRange #11836

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

Originally created by @a-belhadj on GitHub (Nov 17, 2025).

NetBox version

v4.4.5

Feature type

Data model extension

Proposed functionality

Introduce a new boolean field on IPRange objects: exclude_from_allocation = true | false

This flag would instruct NetBox to exclude the corresponding range from the automatic IP allocator (e.g. /prefixes/{id}/available-ips/) without preventing manual creation of IPAddress objects inside that range.

This solves the current limitation where populated = true simultaneously:

  • prevents allocation (desired)
  • but also blocks manual creation of IP addresses (undesired)

The two concepts mark_populated and exclude_from_allocator need to be separated to address real-world use cases

Use case

In NetBox 4.3+, the behavior of IP allocation inside a prefix has changed.

This change introduced a new side effect. When an IPRange is marked populated = true, it is impossible to create an IPAddress manually inside that range.

This was not the behavior in 4.2, and it breaks my workflow where an external system allocates IPs (OpenStack), and NetBox must record those IPs afterward (for DNS purposes).

My objects:

PrefixCAN:
  id: 1
  prefix: 192.168.0.0/24

IPRangeOpenstack:
  id: 2
  range: 192.168.0.0 - 192.168.0.100
  description: OpenStack floating IPs

Workflow before NetBox 4.3

  • VMware IPs were allocated from the prefix using the API POST /api/ipam/prefixes/1/available-ips/

  • NetBox automatically skipped IPs inside all IPRanges when calculating the next available IP.
    This avoided collisions with IPs managed externally by OpenStack and probably already used.

  • When OpenStack assigned a floating IP (e.g. 192.168.0.50), we could still manually create an IPAddress in NetBox with the following

POST /api/ipam/ip-addresses/
{
"address": "192.168.0.50/24",
"dns_name": api.myopenshift.domain.com",
"description": "API for OCP cluster #1"
}

Problem in NetBox 4.3+

To preserve the old allocation behavior, the current recommendation is to set mark_populated = true

This successfully prevents the allocator from picking an IP inside the OpenStack range when doing a POST /api/ipam/prefixes/1/available-ips/

However, once mark_populated=true is set, NetBox rejects any manual creation of IP addresses in that same range:

Cannot create IP address 192.168.0.50/24 inside range 192.168.0.0-192.168.0.100.

This makes it impossible to record floating IPs that are allocated by OpenStack but must still be present in NetBox to manage DNS records.

Database changes

class IPRange:
  exclude_from_allocation = models.BooleanField(
      default=False,
      help_text="Exclude this range from automatic IP allocation"
  )

External dependencies

No response

Originally created by @a-belhadj on GitHub (Nov 17, 2025). ### NetBox version v4.4.5 ### Feature type Data model extension ### Proposed functionality Introduce a new boolean field on **IPRange** objects: `exclude_from_allocation = true | false` This flag would instruct NetBox to **exclude the corresponding range from the automatic IP allocator** (e.g. `/prefixes/{id}/available-ips/`) **without preventing manual creation of IPAddress objects inside that range**. This solves the current limitation where `populated = true` simultaneously: - prevents allocation (desired) - but also blocks manual creation of IP addresses (undesired) The two concepts `mark_populated` and `exclude_from_allocator` need to be separated to address real-world use cases ### Use case In NetBox 4.3+, the behavior of IP allocation inside a prefix has changed. This change introduced a new side effect. When an IPRange is marked `populated = true`, it is impossible to create an IPAddress manually inside that range. This was not the behavior in 4.2, and it breaks my workflow where an external system allocates IPs (OpenStack), and NetBox must record those IPs afterward (for DNS purposes). --- My objects: ```yaml PrefixCAN: id: 1 prefix: 192.168.0.0/24 IPRangeOpenstack: id: 2 range: 192.168.0.0 - 192.168.0.100 description: OpenStack floating IPs ``` --- #### Workflow before NetBox 4.3 - VMware IPs were allocated from the prefix using the API `POST /api/ipam/prefixes/1/available-ips/` - NetBox automatically **skipped IPs inside all IPRanges** when calculating the next available IP. This avoided collisions with IPs managed externally by OpenStack and probably already used. - When OpenStack assigned a floating IP (e.g. `192.168.0.50`), we could still **manually create** an IPAddress in NetBox with the following ``` POST /api/ipam/ip-addresses/ { "address": "192.168.0.50/24", "dns_name": api.myopenshift.domain.com", "description": "API for OCP cluster #1" } ``` #### Problem in NetBox 4.3+ To preserve the old allocation behavior, the current recommendation is to set `mark_populated = true` This successfully prevents the allocator from picking an IP inside the OpenStack range when doing a `POST /api/ipam/prefixes/1/available-ips/` However, once `mark_populated=true` is set, NetBox **rejects any manual creation of IP addresses** in that same range: ``` Cannot create IP address 192.168.0.50/24 inside range 192.168.0.0-192.168.0.100. ``` This makes it impossible to record floating IPs that are allocated by OpenStack but must still be present in NetBox to manage DNS records. ### Database changes ```python class IPRange: exclude_from_allocation = models.BooleanField( default=False, help_text="Exclude this range from automatic IP allocation" ) ``` ### External dependencies _No response_
adam added the type: featurenetbox labels 2025-12-29 21:50:28 +01:00
adam closed this issue 2025-12-29 21:50:29 +01:00
adam commented 2025-12-29 21:50:29 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 20, 2025):

When an IPRange is marked populated = true, it is impossible to create an IPAddress manually inside that range.

AFAICT this was the intended behavior of the change. If this is not desired, you should set the populated field to false.

@jeremystretch commented on GitHub (Nov 20, 2025): > When an IPRange is marked populated = true, it is impossible to create an IPAddress manually inside that range. AFAICT this was the intended behavior of the change. If this is not desired, you should set the `populated` field to false.
adam commented 2025-12-29 21:50:29 +01:00
Author
Owner
Copy Link

@a-belhadj commented on GitHub (Nov 20, 2025):

Hello @jeremystretch,
I want to create an IPRange for my Openstack FIP but I don't want Netbox to pick an IP inside this range when I ask for an IP on the Prefix containing this range (via <prefix>/available-ips).

When Openstack gave me an address in this range, I need to add it in Netbox to create A record via DNS integration.

So I need a protected IPRange that only accept IP if I explicitly ask for an IP in this range.

Before Netbox 4.3, the Netbox algorithm to find the next available IP always skipped IPRange. Now the only way to make the algorithm skip the IPRange is to set mark_populated=true, and this prevent me to add IP inside

When an IPRange is marked populated = true, it is impossible to create an IPAddress manually inside that range.

AFAICT this was the intended behavior of the change. If this is not desired, you should set the populated field to false.

@a-belhadj commented on GitHub (Nov 20, 2025): Hello @jeremystretch, I want to create an IPRange for my Openstack FIP but I don't want Netbox to pick an IP inside this range when I ask for an IP on the Prefix containing this range (via `<prefix>/available-ips`). When Openstack gave me an address in this range, I need to add it in Netbox to create A record via DNS integration. So I need a protected IPRange that only accept IP if I explicitly ask for an IP in this range. Before Netbox 4.3, the Netbox algorithm to find the next available IP always skipped IPRange. Now the only way to make the algorithm skip the IPRange is to set `mark_populated=true`, and this prevent me to add IP inside > > When an IPRange is marked populated = true, it is impossible to create an IPAddress manually inside that range. > > AFAICT this was the intended behavior of the change. If this is not desired, you should set the `populated` field to false.
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 netbox 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#11836
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?