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 Rack to IPAM prefix scope #11558

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

Originally created by @alehaa on GitHub (Sep 2, 2025).

NetBox version

v4.4.0

Feature type

Data model extension

Proposed functionality

IPAM prefixes can already be assigned to regions, locations, and sites. I propose extending this feature to racks.

Use case

In spine-leaf architectures, a layer 2 network doesn’t span multiple racks. Therefore, it would be beneficial to assign specific prefixes to the racks where these networks are used.

Database changes

A new field should be added to the CachedScopeMixin. However, since these cached fields are internal, there would be no API change.

External dependencies

None.

Originally created by @alehaa on GitHub (Sep 2, 2025). ### NetBox version v4.4.0 ### Feature type Data model extension ### Proposed functionality IPAM prefixes can already be assigned to regions, locations, and sites. I propose extending this feature to racks. ### Use case In spine-leaf architectures, a layer 2 network doesn’t span multiple racks. Therefore, it would be beneficial to assign specific prefixes to the racks where these networks are used. ### Database changes A new field should be added to the `CachedScopeMixin`. However, since these cached fields are internal, there would be no API change. ### External dependencies None.
adam added the type: featurenetbox labels 2025-12-29 21:46:43 +01:00
adam closed this issue 2025-12-29 21:46:43 +01:00
adam commented 2025-12-29 21:46:45 +01:00
Author
Owner
Copy Link

@bctiemann commented on GitHub (Sep 4, 2025):

This would involve some significant rethinking of how CachedScopeMixin works relative to its existing FK relationships; not all scoped object using it can be scoped to a Rack and thus would need special handling. This needs some further review.

@bctiemann commented on GitHub (Sep 4, 2025): This would involve some significant rethinking of how `CachedScopeMixin` works relative to its existing FK relationships; not all scoped object using it can be scoped to a Rack and thus would need special handling. This needs some further review.
adam commented 2025-12-29 21:46:45 +01:00
Author
Owner
Copy Link

@jnovinger commented on GitHub (Nov 3, 2025):

This seems like overkill for the use case. We believe the site the rack is in should be sufficient for scoping prefixes. If you need rack-level prefix associations, a custom field would be more appropriate than extending the core scoping mechanism.

Racks are physical infrastructure containers within a location, not part of the geographic/organizational hierarchy. The scoping mechanism is for "where in the world/organization is this resource," not "which piece of physical infrastructure."

@jnovinger commented on GitHub (Nov 3, 2025): This seems like overkill for the use case. We believe the site the rack is in should be sufficient for scoping prefixes. If you need rack-level prefix associations, a custom field would be more appropriate than extending the core scoping mechanism. Racks are physical infrastructure containers within a location, not part of the geographic/organizational hierarchy. The scoping mechanism is for "where in the world/organization is this resource," not "which piece of physical infrastructure."
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#11558
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?