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

Aggregate with VRF support #1378

New Issue
Closed
opened 2025-12-29 16:31:55 +01:00 by adam · 2 comments
adam commented 2025-12-29 16:31:55 +01:00
Owner
Copy Link

Originally created by @wanglf on GitHub (Nov 3, 2017).

Issue type

[x] Feature request
[ ] Bug report
[ ] Documentation

Environment

  • Python version: 3.4.5
  • NetBox version: Example: 2.2.4

Description

In IPAM module, both ip address and prefix have a VRF field. Since ip address belong to prefix and prefix itself belong to aggregate, it will be helpful for aggregate to have a VRF field either.

Currently if ip prefixes from different VRF overlap, it will difficult to distinguish in aggregate view. And in private corporate network, same aggregate might be assigned by different RIRs.

Originally created by @wanglf on GitHub (Nov 3, 2017). ### Issue type [x] Feature request [ ] Bug report [ ] Documentation ### Environment * Python version: 3.4.5 * NetBox version: Example: 2.2.4 ### Description In IPAM module, both ip address and prefix have a VRF field. Since ip address belong to prefix and prefix itself belong to aggregate, it will be helpful for aggregate to have a VRF field either. Currently if ip prefixes from different VRF overlap, it will difficult to distinguish in aggregate view. And in private corporate network, same aggregate might be assigned by different RIRs.
adam closed this issue 2025-12-29 16:31:56 +01:00
adam commented 2025-12-29 16:31:56 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 3, 2017):

Prefixes don't really "belong" to aggregates. The purpose of defining aggregates is simply to establish the root level of the IP space hierarchies (v4 and v6). They provide a mechanism for defining the scope of your IPAM to show only the portions of the global address space in which you're interested (as opposed to starting from 0.0.0.0/0). It's also perfectly acceptable to have prefixes which are not covered by any aggregate (e.g. circuits numbered with provider-owned IPs).

There's no concept of VRF assignment at the root of the hierarchy because it would result in redundant objects. For instance, you might have a hundred VRFs addressed out of the 10.0.0.0/8 space; you would not want a hundred instances of 10.0.0.0/8 in the aggregates list.

@jeremystretch commented on GitHub (Nov 3, 2017): Prefixes don't really "belong" to aggregates. The purpose of defining aggregates is simply to establish the root level of the IP space hierarchies (v4 and v6). They provide a mechanism for defining the scope of your IPAM to show only the portions of the global address space in which you're interested (as opposed to starting from 0.0.0.0/0). It's also perfectly acceptable to have prefixes which are not covered by any aggregate (e.g. circuits numbered with provider-owned IPs). There's no concept of VRF assignment at the root of the hierarchy because it would result in redundant objects. For instance, you might have a hundred VRFs addressed out of the 10.0.0.0/8 space; you would not want a hundred instances of 10.0.0.0/8 in the aggregates list.
adam commented 2025-12-29 16:31:56 +01:00
Author
Owner
Copy Link

@ghost commented on GitHub (Nov 3, 2017):

If aggregate only take global address space into account, I get your point.

But when I define an aggregate 10.0.0.0/8 and a prefix 10.0.0.0/16 which is put into a vrf(not default global). The latter one will be counted as prefix numbers and utilization in aggregate 10.0.0.0/8. Sometimes this can be confusing.

@ghost commented on GitHub (Nov 3, 2017): If aggregate only take `global address space` into account, I get your point. But when I define an aggregate 10.0.0.0/8 and a prefix 10.0.0.0/16 which is put into a vrf(not default global). The latter one will be counted as prefix numbers and utilization in aggregate 10.0.0.0/8. Sometimes this can be confusing.
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
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#1378
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?