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 Last Available Prefix Instead of First Available #4457

New Issue
Closed
opened 2025-12-29 18:36:11 +01:00 by adam · 2 comments
adam commented 2025-12-29 18:36:11 +01:00
Owner
Copy Link

Originally created by @MrHamel on GitHub (Jan 12, 2021).

Environment

  • Python version: Unknown
  • NetBox version: v2.9.3

Proposed Functionality

Be able to allocate an IP block from the available-prefixes API call in descending order (last IP block), instead of ascending order (first IP block).

Use Case

172.31.254.0/24 is used for firewalls and point-to-point Ethernet circuit IP assignments within a VRF. A separate custom network automation system assigns tenants /24s from 172.16.0.0/12 in ascending order, in order for those two systems to not clash, I would like to be able to allocate infrastructure IPs in descending order. We have not run into the issue yet as we were manually creating these assignments in an internal Wiki table, but are looking towards automation to speed up our workflows.

Database Changes

None that I know of.

External Dependencies

None that I know of.

Originally created by @MrHamel on GitHub (Jan 12, 2021). ### Environment * Python version: Unknown * NetBox version: v2.9.3 ### Proposed Functionality Be able to allocate an IP block from the available-prefixes API call in descending order (last IP block), instead of ascending order (first IP block). ### Use Case 172.31.254.0/24 is used for firewalls and point-to-point Ethernet circuit IP assignments within a VRF. A separate custom network automation system assigns tenants /24s from 172.16.0.0/12 in ascending order, in order for those two systems to not clash, I would like to be able to allocate infrastructure IPs in descending order. We have not run into the issue yet as we were manually creating these assignments in an internal Wiki table, but are looking towards automation to speed up our workflows. ### Database Changes None that I know of. ### External Dependencies None that I know of.
adam added the type: feature label 2025-12-29 18:36:11 +01:00
adam closed this issue 2025-12-29 18:36:11 +01:00
adam commented 2025-12-29 18:36:12 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 19, 2021):

The "allocate next" function is provided merely as a convenience. If you need any sort of arbitrary logic beyond that, you'll need to apply it either within the client (by determining available space and then requesting a particular prefix) or within a plugin.

@jeremystretch commented on GitHub (Jan 19, 2021): The "allocate next" function is provided merely as a convenience. If you need any sort of arbitrary logic beyond that, you'll need to apply it either within the client (by determining available space and then requesting a particular prefix) or within a plugin.
adam commented 2025-12-29 18:36:12 +01:00
Author
Owner
Copy Link

@MrHamel commented on GitHub (Jan 19, 2021):

I understand it is a convenience thing overall, but in Python, [0] and [-1] list references is a simple thing to do, and easily specified with a "direction" like parameter. I understand it is a convenience asking for this feature to be put in, but it beats having to reinventing wheel when the core logic is already implemented.

Is there a possibility this can be reconsidered?

Thanks!

@MrHamel commented on GitHub (Jan 19, 2021): I understand it is a convenience thing overall, but in Python, [0] and [-1] list references is a simple thing to do, and easily specified with a "direction" like parameter. I understand it is a convenience asking for this feature to be put in, but it beats having to reinventing wheel when the core logic is already implemented. Is there a possibility this can be reconsidered? Thanks!
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 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#4457
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?