starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-13 05:50:33 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Discussion: Child prefix listing in container prefixes #300

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

Originally created by @Zanthras on GitHub (Jul 27, 2016).

An improvement that I found helpful was changing the behavior of a prefix of type container set to the global vrf, to show child prefixes from all vrf's. While this makes alot of sense for my environment, I'm not sure how applicable or useful that would be to others. Anyone have thoughts on it?

Originally created by @Zanthras on GitHub (Jul 27, 2016). An improvement that I found helpful was changing the behavior of a prefix of type container set to the global vrf, to show child prefixes from all vrf's. While this makes alot of sense for my environment, I'm not sure how applicable or useful that would be to others. Anyone have thoughts on it?
adam added the type: feature label 2025-12-29 16:20:39 +01:00
adam closed this issue 2025-12-29 16:20:40 +01:00
adam commented 2025-12-29 16:20:40 +01:00
Author
Owner
Copy Link

@malaiam commented on GitHub (Jul 28, 2016):

Hey!

I just hit this one too. I think this makes sense for all environments where VRF use is prevalent. Maybe not so useful in a DC environment, but for infrastructure / customer address management is definitely needed. I just did some tests on http://netbox-demo01.packetlife.net/ipam/prefixes/ and I found it a bit confusing at start until I figured how it works.

If the current behavior is preferred by some, maybe a knob toggling between the two could be implemented. I think this would be useful also on the main prefixes page, to show prefixes from all VRFs until a VRF is selected via the filters on the side.

Another thing is that in the current behavior, the IP addresses are listed from all VRFs even if child prefixes are not - this is a bit inconsistent.

Thanks,
Marius

@malaiam commented on GitHub (Jul 28, 2016): Hey! I just hit this one too. I think this makes sense for all environments where VRF use is prevalent. Maybe not so useful in a DC environment, but for infrastructure / customer address management is definitely needed. I just did some tests on http://netbox-demo01.packetlife.net/ipam/prefixes/ and I found it a bit confusing at start until I figured how it works. If the current behavior is preferred by some, maybe a knob toggling between the two could be implemented. I think this would be useful also on the main prefixes page, to show prefixes from all VRFs until a VRF is selected via the filters on the side. Another thing is that in the current behavior, the IP addresses are listed from all VRFs even if child prefixes are not - this is a bit inconsistent. Thanks, Marius
adam commented 2025-12-29 16:20:40 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jul 28, 2016):

IMO viewing a specific prefix instils some context around what you want to see. It may or may not make sense to display child prefixes from other VRFs, depending on your particular environment.

As an alternative, I suggest searching by parent prefix to show all children regardless of VRF. For example, if I want to find all children of 192.0.2.0/24, I can go to the prefixes list, enter "192.0.2.0/24" in the "search within" field, and check "expand hierarchy" at the bottom. This will return a hierarchy showing all children.

netbox_-prefixes-_2016-07-28_11 19 10

Another thing is that in the current behavior, the IP addresses are listed from all VRFs even if child prefixes are not - this is a bit inconsistent.

Opened #397 for this.

@jeremystretch commented on GitHub (Jul 28, 2016): IMO viewing a specific prefix instils some context around what you want to see. It may or may not make sense to display child prefixes from other VRFs, depending on your particular environment. As an alternative, I suggest searching by parent prefix to show all children regardless of VRF. For example, if I want to find all children of 192.0.2.0/24, I can go to the prefixes list, enter "192.0.2.0/24" in the "search within" field, and check "expand hierarchy" at the bottom. This will return a hierarchy showing all children. ![netbox_-_prefixes_-_2016-07-28_11 19 10](https://cloud.githubusercontent.com/assets/13487278/17218342/650a4838-54b5-11e6-9b49-9017c7e2d9e7.png) > Another thing is that in the current behavior, the IP addresses are listed from all VRFs even if child prefixes are not - this is a bit inconsistent. Opened #397 for this.
adam commented 2025-12-29 16:20:41 +01:00
Author
Owner
Copy Link

@Zanthras commented on GitHub (Jul 28, 2016):

I agree that a specific prefix + vrf does indicate you want to see specific information. I think the more concise summary of my request is a way to say vrf "all" for a prefix. That way its up to the end user to determine where it is or isnt the correct use case.

@Zanthras commented on GitHub (Jul 28, 2016): I agree that a specific prefix + vrf does indicate you want to see specific information. I think the more concise summary of my request is a way to say vrf "all" for a prefix. That way its up to the end user to determine where it is or isnt the correct use case.
adam commented 2025-12-29 16:20:41 +01:00
Author
Owner
Copy Link

@malaiam commented on GitHub (Jul 28, 2016):

I still think all child prefixes, from all VRFs, should be shown, especially if the current prefix is in the global and not in a specific VRF.

Let's say that I have a prefix that is an "allocation" for some purpose - e.g. infrastructure, so it will have some child prefixes. And those child prefixes will belong to different VRFs, e.g. some in management, some in voice, etc. Then I want to go the parent prefix and make another assigment, doesn't matter in which VRF. How do I do that in a quick way so I don't make duplicate assignments?

@malaiam commented on GitHub (Jul 28, 2016): I still think all child prefixes, from all VRFs, should be shown, especially if the current prefix is in the global and not in a specific VRF. Let's say that I have a prefix that is an "allocation" for some purpose - e.g. infrastructure, so it will have some child prefixes. And those child prefixes will belong to different VRFs, e.g. some in management, some in voice, etc. Then I want to go the parent prefix and make another assigment, doesn't matter in which VRF. How do I do that in a quick way so I don't make duplicate assignments?
adam commented 2025-12-29 16:20:41 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jul 28, 2016):

It seems like it might make sense to show all children (regardless of VRF) only for prefixes which are in the global table. Does that make sense?

@jeremystretch commented on GitHub (Jul 28, 2016): It seems like it might make sense to show all children (regardless of VRF) only for prefixes which are in the global table. Does that make sense?
adam commented 2025-12-29 16:20:41 +01:00
Author
Owner
Copy Link

@malaiam commented on GitHub (Jul 28, 2016):

It does and it would probably work OK for me in most cases, but I don't see why limit it to the global VRF, besides principles. Corner cases might still allow for unwanted duplicate assignment, if the parent prefix is not in the global for some reason. I still believe displaying child prefixes from all VRFs, based on a global user setting if wanted, is a less error prone approach.
Just argumenting for a better IPAM here, otherwise I think you did a very good job so far!

@malaiam commented on GitHub (Jul 28, 2016): It does and it would probably work OK for me in most cases, but I don't see why limit it to the global VRF, besides principles. Corner cases might still allow for unwanted duplicate assignment, if the parent prefix is not in the global for some reason. I still believe displaying child prefixes from all VRFs, based on a global user setting if wanted, is a less error prone approach. Just argumenting for a better IPAM here, otherwise I think you did a very good job so far!
adam commented 2025-12-29 16:20:42 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jul 28, 2016):

I don't see why limit it to the global VRF

Suppose you use 192.168.0.0/16 for each customer within their own VRF. You don't want customer A's 192.168.0.0/16 showing children in customer B's VRF. Doing so would defeat the purpose of using a VRF.

@jeremystretch commented on GitHub (Jul 28, 2016): > I don't see why limit it to the global VRF Suppose you use 192.168.0.0/16 for each customer within their own VRF. You don't want customer A's 192.168.0.0/16 showing children in customer B's VRF. Doing so would defeat the purpose of using a VRF.
adam commented 2025-12-29 16:20:42 +01:00
Author
Owner
Copy Link

@malaiam commented on GitHub (Jul 29, 2016):

Yes, that's a valid example, so a way to see only the specific VRF prefixes should exist.

But I still think limiting for just the global to see all child prefixes, without any option for the user to change that, would open for unwanted behavior - one case is the corner case example above, when a parent prefix might be in a VRF by mistake, and another could be that some customer's IP plan overlaps with some global prefix, and hence the user seeing customer prefixes when he/she doesn't want to.

I still think the best is to allow the user to chose what he wants to see. Maybe the "knob" idea is not the best in this case. What I think the behavior should be is that in the main prefix list all prefixes should be shown (not just global) if the "All" VRF is chosen in the drop-down on the side, and probably a similar drop-down should be shown on the prefix specific page, with the current VRF selected by default if you want to.

@malaiam commented on GitHub (Jul 29, 2016): Yes, that's a valid example, so a way to see only the specific VRF prefixes should exist. But I still think limiting for just the global to see all child prefixes, without any option for the user to change that, would open for unwanted behavior - one case is the corner case example above, when a parent prefix might be in a VRF by mistake, and another could be that some customer's IP plan overlaps with some global prefix, and hence the user seeing customer prefixes when he/she doesn't want to. I still think the best is to allow the user to chose what he wants to see. Maybe the "knob" idea is not the best in this case. What I think the behavior should be is that in the main prefix list all prefixes should be shown (not just global) if the "All" VRF is chosen in the drop-down on the side, and probably a similar drop-down should be shown on the prefix specific page, with the current VRF selected by default if you want to.
adam commented 2025-12-29 16:20:42 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Aug 2, 2016):

Just to add onto this, Global VRF would be where I would see this being used the most, but not always. Would this be something that you could add a toggle onto the individual global VRF to either contain all child prefixes regardless of VRF or not to.

@DanSheps commented on GitHub (Aug 2, 2016): Just to add onto this, Global VRF would be where I would see this being used the most, but not always. Would this be something that you could add a toggle onto the individual global VRF to either contain all child prefixes regardless of VRF or not to.
adam commented 2025-12-29 16:20:42 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 2, 2016):

9f3647cd53 tweaks the prefix display to now include children from all VRFs if the parent is in the global table.

@jeremystretch commented on GitHub (Aug 2, 2016): 9f3647cd53b29b482dd68cc40f11b922e0f81f3a tweaks the prefix display to now include children from all VRFs if the parent is in the global table.
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#300
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?