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

ipam/prefix , a "container" prefix with no vrf assigned doesn't show children in other vrfs #7771

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

Originally created by @anubisg1 on GitHub (Mar 20, 2023).

NetBox version

3.4.5

Python version

3.8

Steps to Reproduce

  1. create a prefix, assign role container and do not assign a vrf (this will make netbox automatically assign global)
  2. create another prefix, children of the container and assign it to a vrf

Expected Behavior

while it is clear that a vrf is a separate "ip stack" , a prefix marked as "container" should be considered a different object especially when it is not associated to a vrf.

by mean of being a "container" it should display all children prefixes across all different vrfs

view of the same object across different pages should be consistent

Observed Behavior

  • ipam/prefix will share no parent/child relation what so ever
  • opening the prefix specific page, and clicking on children prefixes, will show children prefixes in other vrfs but without depth indicators

image

image

image

Originally created by @anubisg1 on GitHub (Mar 20, 2023). ### NetBox version 3.4.5 ### Python version 3.8 ### Steps to Reproduce 1. create a prefix, assign role container and do not assign a vrf (this will make netbox automatically assign global) 2. create another prefix, children of the container and assign it to a vrf ### Expected Behavior while it is clear that a vrf is a separate "ip stack" , a prefix marked as "container" should be considered a different object especially when it is not associated to a vrf. by mean of being a "container" it should display all children prefixes across all different vrfs view of the same object across different pages should be consistent ### Observed Behavior - ipam/prefix will share no parent/child relation what so ever - opening the prefix specific page, and clicking on children prefixes, will show children prefixes in other vrfs but without depth indicators ![image](https://user-images.githubusercontent.com/4518931/226307362-91dd75a9-5b46-4e86-bf04-f187ddb93a34.png) ![image](https://user-images.githubusercontent.com/4518931/226307531-e7c0681a-829a-49ca-bff6-a13b30f2a36c.png) ![image](https://user-images.githubusercontent.com/4518931/226307778-d8f4e513-6f15-425f-ad2c-79e39b67f327.png)
adam added the type: bugstatus: revisions needed labels 2025-12-29 20:28:00 +01:00
adam closed this issue 2025-12-29 20:28:01 +01:00
adam commented 2025-12-29 20:28:01 +01:00
Author
Owner
Copy Link

@bobbwest commented on GitHub (Apr 4, 2023):

I disagree with your idea of "container".

If I am allocating addresses in my global table, and in VRFs, from a specific prefix, I want an specific container to allocate these from, regardless of whether it's global or a VRF.

The downside of including all VRFs under a container without an assigned VRF is that it's almost impossible to work out what has and hasn't been allocate in global: there's no way to filter Child Prefixes like there is for the IPAM > Prefixes table.

The downside of not including all VRFs under a container is that you might need to duplicate a few prefix containers, one for each VRF (and global). This is easier to work around than the former.

@bobbwest commented on GitHub (Apr 4, 2023): I disagree with your idea of "container". If I am allocating addresses in my global table, and in VRFs, from a specific prefix, I want an specific container to allocate these from, regardless of whether it's global or a VRF. The downside of including all VRFs under a container without an assigned VRF is that it's almost impossible to work out what has and hasn't been allocate in global: there's no way to filter Child Prefixes like there is for the IPAM > Prefixes table. The downside of not including all VRFs under a container is that you might need to duplicate a few prefix containers, one for each VRF (and global). This is easier to work around than the former.
adam commented 2025-12-29 20:28:01 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Apr 4, 2023):

I disagree with your idea of "container".

Unfortuantely, this idea of "container" is the documented behaviour of container, with respect to the global table. If you assign a VRF to a container, it operates as a container for prefixes within that VRF only.

If I am allocating addresses in my global table, and in VRFs, from a specific prefix, I want an specific container to allocate these from, regardless of whether it's global or a VRF.

The downside of including all VRFs under a container without an assigned VRF is that it's almost impossible to work out what has and hasn't been allocate in global: there's no way to filter Child Prefixes like there is for the IPAM > Prefixes table.

The downside of not including all VRFs under a container is that you might need to duplicate a few prefix containers, one for each VRF (and global). This is easier to work around than the former.

This isn't the place to request behaviour changes, you would need to open a FR for that. This is a long standing behaviour and the FR for it is in the double digits or the low 100's

@DanSheps commented on GitHub (Apr 4, 2023): > I disagree with your idea of "container". Unfortuantely, this idea of "container" is the documented behaviour of container, with respect to the global table. If you assign a VRF to a container, it operates as a container for prefixes within that VRF only. > If I am allocating addresses in my global table, and in VRFs, from a specific prefix, I want an specific container to allocate these from, regardless of whether it's global or a VRF. > > The downside of including all VRFs under a container without an assigned VRF is that it's almost impossible to work out what has and hasn't been allocate in global: there's no way to filter Child Prefixes like there is for the IPAM > Prefixes table. > > The downside of not including all VRFs under a container is that you might need to duplicate a few prefix containers, one for each VRF (and global). This is easier to work around than the former. This isn't the place to request behaviour changes, you would need to open a FR for that. This is a long standing behaviour and the FR for it is in the double digits or the low 100's
adam commented 2025-12-29 20:28:02 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Apr 4, 2023):

@anubisg1 It properly shows the prefixes, it just is an inconsistent display, correct?

@DanSheps commented on GitHub (Apr 4, 2023): @anubisg1 It properly shows the prefixes, it just is an inconsistent display, correct?
adam commented 2025-12-29 20:28:02 +01:00
Author
Owner
Copy Link

@anubisg1 commented on GitHub (Apr 4, 2023):

@anubisg1 It properly shows the prefixes, it just is an inconsistent display, correct?

That's what I see.

If you are in the prefixes page, it shows only nested prefixes from the global vrf, but if you open the prefix in the prefix specific page and click on child prefixes page, then it shows them all as I would expect. The screenshot above should clarify visually

@anubisg1 commented on GitHub (Apr 4, 2023): > @anubisg1 It properly shows the prefixes, it just is an inconsistent display, correct? That's what I see. If you are in the prefixes page, it shows only nested prefixes from the global vrf, but if you open the prefix in the prefix specific page and click on child prefixes page, then it shows them all as I would expect. The screenshot above should clarify visually
adam commented 2025-12-29 20:28:02 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (May 2, 2023):

Could you provide some data to reproduce this properly (to ensure what needs to be fixed is fixed)?

@DanSheps commented on GitHub (May 2, 2023): Could you provide some data to reproduce this properly (to ensure what needs to be fixed is fixed)?
adam commented 2025-12-29 20:28:02 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jun 23, 2023):

Closing this out as I see nothing to indicate unexpected behavior, and OP has not responded to a request for additional information.

@jeremystretch commented on GitHub (Jun 23, 2023): Closing this out as I see nothing to indicate unexpected behavior, and OP has not responded to a request for additional information.
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 status: revisions needed 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#7771
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?