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

IP ranges not visible within prefix, and not reserving IPs within the range #5171

New Issue
Closed
opened 2025-12-29 19:25:03 +01:00 by adam · 5 comments
adam commented 2025-12-29 19:25:03 +01:00
Owner
Copy Link

Originally created by @candlerb on GitHub (Aug 10, 2021).

Originally assigned to: @jeremystretch on GitHub.

NetBox version

v3.0-feature (on beta-demo.netbox.dev)

Python version

3.8

Steps to Reproduce

  1. Create IP address 1.1.1.1/24
  2. Create IP range 1.1.1.2/24-1.1.1.10/24
  3. Create prefix 1.1.1.0/24
  4. Navigate to the prefix
  5. Select the "IP addresses" tab (/ipam/prefixes/<N>/ip-addresses/)

Expected Behavior

  • Under the prefix, I was expecting to see both the IP and the range.
  • I was also expecting by default that allocating a new IP would not pick one within the existing range (e.g. this might be a DHCP pool)
  • I was expecting to see the prefix utilisation as 10/254 = 3.94% (showing as 3% or 4%)

Observed Behavior

The IP address 1.1.1.1/24 is shown, and "253 IPs available".

image

Clicking on "253 IPs available" allocates 1.1.1.2/24 - clashing with the range

Browsing to the prefix shows utilisation as 0%

(Aside: browsing to the main IP addresses listing /ipam/ip-addresses/ also does not show ranges mixed in, and I think it might be good if it did, but that's less important than when looking at IPs under a prefix)

Originally created by @candlerb on GitHub (Aug 10, 2021). Originally assigned to: @jeremystretch on GitHub. ### NetBox version v3.0-feature (on beta-demo.netbox.dev) ### Python version 3.8 ### Steps to Reproduce 1. Create IP address 1.1.1.1/24 2. Create IP range 1.1.1.2/24-1.1.1.10/24 3. Create prefix 1.1.1.0/24 4. Navigate to the prefix 5. Select the "IP addresses" tab (`/ipam/prefixes/<N>/ip-addresses/`) ### Expected Behavior * Under the prefix, I was expecting to see both the IP and the range. * I was also expecting by default that allocating a new IP would not pick one within the existing range (e.g. this might be a DHCP pool) * I was expecting to see the prefix utilisation as 10/254 = 3.94% (showing as 3% or 4%) ### Observed Behavior The IP address 1.1.1.1/24 is shown, and "253 IPs available". ![image](https://user-images.githubusercontent.com/44789/128918653-b7652801-c7d0-4ed2-bec2-d57f8788cfa0.png) Clicking on "253 IPs available" allocates 1.1.1.2/24 - clashing with the range Browsing to the prefix shows utilisation as 0% (Aside: browsing to the main IP addresses listing `/ipam/ip-addresses/` also does not show ranges mixed in, and I think it might be good if it did, but that's less important than when looking at IPs under a prefix)
adam added the type: bugstatus: acceptedbeta labels 2025-12-29 19:25:03 +01:00
adam closed this issue 2025-12-29 19:25:03 +01:00
adam commented 2025-12-29 19:25:04 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 10, 2021):

Under the prefix, I was expecting to see both the IP and the range.

This was not a design goal for v3.0. Per my comment on #834:

Something I've been stuck on for a long time is how to integrate IP ranges with individual addresses e.g. in a prefix's child IPs list. But maybe I'm overthinking it. Just having the IP range model in place, even without any especially convenient integration with individual IPs, is pretty valuable.

and

If we accept the introduction of IPRange as a new model separate from the Prefix and IPAddress models, with its own parallel views and API endpoints, this becomes very straightforward to implement, and I'd be open to tackling it for v3.0.

We should have a "ranges" tab under the prefix view, though.

@jeremystretch commented on GitHub (Aug 10, 2021): > Under the prefix, I was expecting to see both the IP and the range. This was not a design goal for v3.0. Per my [comment](https://github.com/netbox-community/netbox/issues/834#issuecomment-869666707) on #834: > Something I've been stuck on for a long time is how to integrate IP ranges with individual addresses e.g. in a prefix's child IPs list. But maybe I'm overthinking it. Just having the IP range model in place, even without any especially convenient integration with individual IPs, is pretty valuable. and > If we accept the introduction of IPRange as a new model separate from the Prefix and IPAddress models, with its own parallel views and API endpoints, this becomes very straightforward to implement, and I'd be open to tackling it for v3.0. We should have a "ranges" tab under the prefix view, though.
adam commented 2025-12-29 19:25:05 +01:00
Author
Owner
Copy Link

@candlerb commented on GitHub (Aug 10, 2021):

And what about prefix utilisation?

ISTM that the "IPAddress" view is automatically calculating ranges - of the gaps between IP addresses (e.g. "253 IPs available" in this example). Therefore I think it would make sense to merge in the explcit "Range" objects in this view, although it's slightly complicated in that a range may also overlap with IPAddress objects (they could be indented under the "parent" range).

This merge would, as a side-effect, ensure that the auto-generated ranges of 'free' addresses are correct. i.e. what I really wanted to see was "243 IPs available", and clicking on this would give me 1.1.1.11/24

But this can wait for a later iteration.

@candlerb commented on GitHub (Aug 10, 2021): And what about prefix utilisation? ISTM that the "IPAddress" view is automatically calculating ranges - of the gaps between IP addresses (e.g. "253 IPs available" in this example). Therefore I think it would make sense to merge in the explcit "Range" objects in this view, although it's slightly complicated in that a range may also overlap with IPAddress objects (they could be indented under the "parent" range). This merge would, as a side-effect, ensure that the auto-generated ranges of 'free' addresses are correct. i.e. what I really wanted to see was "243 IPs available", and clicking on this would give me 1.1.1.11/24 But this can wait for a later iteration.
adam commented 2025-12-29 19:25:05 +01:00
Author
Owner
Copy Link

@sdktr commented on GitHub (Aug 11, 2021):

It depends on what you try to administer with an IPrange imo. If the range is supposed to signal a delegation ('dhcp controls this range') it makes sense to mark it as utilized from a parent prefix point of view.

If on the other hand an IPrange is used to dictate some sort of standardized subnet arrangement ('use this range for switch management IPs, this other range for routers') it is very natural to allow assignment within the range. Like: get-next-available-ip from a prefix, but must be within the allocation/range dedicated to 'end-user-pcs'.

Do we need a 'mark-utilized' or 'assignent-delegated' flag (or logic) on the IPrange model to suit both use cases?

@sdktr commented on GitHub (Aug 11, 2021): It depends on what you try to administer with an IPrange imo. If the range is supposed to signal a delegation ('dhcp controls this range') it makes sense to mark it as utilized from a parent prefix point of view. If on the other hand an IPrange is used to dictate some sort of standardized subnet arrangement ('use this range for switch management IPs, this other range for routers') it is very natural to allow assignment within the range. Like: get-next-available-ip from a prefix, but must be within the allocation/range dedicated to 'end-user-pcs'. Do we need a 'mark-utilized' or 'assignent-delegated' flag (or logic) on the IPrange model to suit both use cases?
adam commented 2025-12-29 19:25:05 +01:00
Author
Owner
Copy Link

@candlerb commented on GitHub (Aug 11, 2021):

I'm happy to allow assignment within a range, if you explictly choose to do so (e.g. by clicking on the range), although having a flag to disable this would be good - then you'd have to explicitly create an IP address by hand, to overlap the range.

At the moment, I see the main problem is that the ranges are completely invisible in this view, and clicking on a "253 IPs available" (i.e. the range of "unused" IPs) is allocating an IP that can overlap ranges which may exist.

Ideally what I'd expect to see is:

  • 1.1.1.1
  • 1.1.1.2-1.1.1.10 (i.e. range)
  • 243 IPs available # i.e. unused 1.1.1.11 - 1.1.1.254
@candlerb commented on GitHub (Aug 11, 2021): I'm happy to *allow* assignment within a range, if you explictly choose to do so (e.g. by clicking on the range), although having a flag to disable this would be good - then you'd have to explicitly create an IP address by hand, to overlap the range. At the moment, I see the main problem is that the ranges are completely invisible in this view, and clicking on a "253 IPs available" (i.e. the range of "unused" IPs) is allocating an IP that can overlap ranges which may exist. Ideally what I'd expect to see is: * 1.1.1.1 * 1.1.1.2-1.1.1.10 (i.e. range) * 243 IPs available # i.e. unused 1.1.1.11 - 1.1.1.254
adam commented 2025-12-29 19:25:05 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 13, 2021):

I believe I've addressed all of the items noted above. If there's anything anyone would like to revisit, please open a new issue for each individual proposed change.

@jeremystretch commented on GitHub (Aug 13, 2021): I believe I've addressed all of the items noted above. If there's anything anyone would like to revisit, please open a new issue for each individual proposed change.
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 beta status: accepted type: bug
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#5171
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?