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

Prefixes are displayed under containers in different VRFs #412

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

Originally created by @LukeDRussell on GitHub (Sep 3, 2016).

Prefixes aren't displayed under the correct container when they are in difference VRFs

For example, there is a container prefix in VRF A of 192.168.0.0/16. If we expand the prefixes we can see 192.168.128.0/17 in VRF B underneath the VRF A container.

Originally created by @LukeDRussell on GitHub (Sep 3, 2016). Prefixes aren't displayed under the correct container when they are in difference VRFs For example, there is a container prefix in VRF A of 192.168.0.0/16. If we expand the prefixes we can see 192.168.128.0/17 in VRF B underneath the VRF A container.
adam added the type: bug label 2025-12-29 16:21:48 +01:00
adam closed this issue 2025-12-29 16:21:48 +01:00
adam commented 2025-12-29 16:21:49 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 3, 2016):

This is intentional. VRFs represent unique IP spaces.

@jeremystretch commented on GitHub (Sep 3, 2016): This is intentional. VRFs represent unique IP spaces.
adam commented 2025-12-29 16:21:49 +01:00
Author
Owner
Copy Link

@LukeDRussell commented on GitHub (Sep 4, 2016):

I'm not really following...

Why would I want to see a prefix in the global table listed under a container in a different VRF?

If I look at prefix's page it is listed under the correct container (see http://netbox-demo01.packetlife.net/ipam/prefixes/27/)

However if I look at the all prefix page with subnets expanded (see http://netbox-demo01.packetlife.net/ipam/prefixes/?parent=&expand=on) our prefix is listed under a different container.

From: Jeremy Stretch notifications@github.com
Sent: Sunday, 4 September 2016 12:38 AM
To: digitalocean/netbox
Cc: lukerussell; Author
Subject: Re: [digitalocean/netbox] Prefixes are displayed under containers in different VRFs (#531)

This is intentional. VRFs represent unique IP spaces.

You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/digitalocean/netbox/issues/531#issuecomment-244550043, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AGbGab4SLcJaruHu9Gl3Id6Ox68yoP9hks5qmYZwgaJpZM4J0ScJ.

@LukeDRussell commented on GitHub (Sep 4, 2016): I'm not really following... Why would I want to see a prefix in the global table listed under a container in a different VRF? If I look at prefix's page it is listed under the correct container (see http://netbox-demo01.packetlife.net/ipam/prefixes/27/) However if I look at the all prefix page with subnets expanded (see http://netbox-demo01.packetlife.net/ipam/prefixes/?parent=&expand=on) our prefix is listed under a different container. --- From: Jeremy Stretch notifications@github.com Sent: Sunday, 4 September 2016 12:38 AM To: digitalocean/netbox Cc: lukerussell; Author Subject: Re: [digitalocean/netbox] Prefixes are displayed under containers in different VRFs (#531) This is intentional. VRFs represent unique IP spaces. ## You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/digitalocean/netbox/issues/531#issuecomment-244550043, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AGbGab4SLcJaruHu9Gl3Id6Ox68yoP9hks5qmYZwgaJpZM4J0ScJ.
adam commented 2025-12-29 16:21:49 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 6, 2016):

For a prefix in the global table, NetBox will show child prefixes from all VRFs (see #395). However, a prefix which has been assigned to a VRF will list children only within its own VRF. Hopefully that makes sense. Apologies if I'm misunderstanding your question.

@jeremystretch commented on GitHub (Sep 6, 2016): For a prefix in the global table, NetBox will show child prefixes from all VRFs (see #395). However, a prefix which has been assigned to a VRF will list children only within its own VRF. Hopefully that makes sense. Apologies if I'm misunderstanding your question.
adam commented 2025-12-29 16:21:49 +01:00
Author
Owner
Copy Link

@LukeDRussell commented on GitHub (Sep 10, 2016):

Thanks for re-opening. Having a read of #395 has given me some good context.

However, a prefix which has been assigned to a VRF will list children only within its own VRF.

It's not working like that right now. 1.5.2 will show global prefixes under a container in a VRF, if there is no container in global. Even adding a container in global later will still show the global prefix under the VRF container. Deleting the VRF container will then put the global prefix under the global container.

@LukeDRussell commented on GitHub (Sep 10, 2016): Thanks for re-opening. Having a read of #395 has given me some good context. > However, a prefix which has been assigned to a VRF will list children only within its own VRF. It's not working like that right now. 1.5.2 will show global prefixes under a container in a VRF, if there is no container in global. Even adding a container in global later will still show the global prefix under the VRF container. Deleting the VRF container will then put the global prefix under the global container.
adam commented 2025-12-29 16:21:50 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 12, 2016):

I've tried replicating this but it doesn't happen when viewing a specific prefix. Could you post a screenshot of where you're seeing this?

@jeremystretch commented on GitHub (Sep 12, 2016): I've tried replicating this but it doesn't happen when viewing a specific prefix. Could you post a screenshot of where you're seeing this?
adam commented 2025-12-29 16:21:50 +01:00
Author
Owner
Copy Link

@LukeDRussell commented on GitHub (Sep 12, 2016):

netbox prefixes
To clarify, it doesn't happen when viewing specific prefix, it happens when viewing all prefixes. Note 10.0.0.0/9 Global is listed under 10.0.0.0/8 cust_evil01.

@LukeDRussell commented on GitHub (Sep 12, 2016): ![netbox prefixes](https://cloud.githubusercontent.com/assets/6735465/18452613/fe5b6556-797e-11e6-89a9-6b7d3d954de2.jpg) To clarify, it doesn't happen when viewing specific prefix, it happens when viewing all prefixes. Note 10.0.0.0/9 Global is listed under 10.0.0.0/8 cust_evil01.
adam commented 2025-12-29 16:21:50 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 13, 2016):

Having pondered this further, I think it makes sense to keep the list exactly as it is. When you're viewing the prefix hierarchy, you presumably want to include everything, so it makes sense to include all prefixes from all tables. If you only want to see a specific VRF or tenant, you can utilize the filters to do so.

@jeremystretch commented on GitHub (Sep 13, 2016): Having pondered this further, I think it makes sense to keep the list exactly as it is. When you're viewing the prefix hierarchy, you presumably want to include everything, so it makes sense to include all prefixes from all tables. If you only want to see a specific VRF or tenant, you can utilize the filters to do so.
adam commented 2025-12-29 16:21:50 +01:00
Author
Owner
Copy Link

@LukeDRussell commented on GitHub (Sep 14, 2016):

I agree that I do want to see everything from all VRFs (including global) with no filters applied.

However, I do not agree that the case illustrated in the screenshot is inline with the "replicate the real world" philosophy. Prefix Global:10.0.0.0/8 literally does contain Global:10.0.0.0/9. cust_evil01:10.0.0.0/8 does not.

What happens when Global:10.0.0.0/8 doesn't exist though? #395 covered this to an extent. My opinion is that Global:10.0.0.0/9 should be shown as a parent/root item, seperate to cust_evil01:10.0.0.0/8. Otherwise what determines a prefixes' parent if it doesn't have a larger container within the same VRF? Global:10.0.0.0/9 could end up listed under any arbitrary VRF (I am guessing this is tied to the order the VRFs were created).

Tangent: I can't find an issue already for this. Can I raise an issue to add "Global" to the list of VRFs in the filter list? It would apply /ipam/prefixes/?parent=&vrf=0

@LukeDRussell commented on GitHub (Sep 14, 2016): I agree that I do want to see everything from all VRFs (including global) with no filters applied. However, I do not agree that the case illustrated in the screenshot is inline with the "replicate the real world" philosophy. Prefix Global:10.0.0.0/8 literally does contain Global:10.0.0.0/9. cust_evil01:10.0.0.0/8 does not. What happens when Global:10.0.0.0/8 doesn't exist though? #395 covered this to an extent. My opinion is that Global:10.0.0.0/9 should be shown as a parent/root item, seperate to cust_evil01:10.0.0.0/8. Otherwise what determines a prefixes' parent if it doesn't have a larger container within the same VRF? Global:10.0.0.0/9 could end up listed under any arbitrary VRF (I am guessing this is tied to the order the VRFs were created). Tangent: I can't find an issue already for this. Can I raise an issue to add "Global" to the list of VRFs in the filter list? It would apply /ipam/prefixes/?parent=&vrf=**0**
adam commented 2025-12-29 16:21:50 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 14, 2016):

Sorry, when I went to replicate this I didn't realize you had two 10/8s, one in the global table and one in a VRF. I get it now. Will have to do some thinking on how to resolve this.

Can I raise an issue to add "Global" to the list of VRFs in the filter list? It would apply /ipam/prefixes/?parent=&vrf=0

Yes please. I've been meaning to overhaul the method in which filters are generated anyway.

@jeremystretch commented on GitHub (Sep 14, 2016): Sorry, when I went to replicate this I didn't realize you had two 10/8s, one in the global table and one in a VRF. I get it now. Will have to do some thinking on how to resolve this. > Can I raise an issue to add "Global" to the list of VRFs in the filter list? It would apply /ipam/prefixes/?parent=&vrf=0 Yes please. I've been meaning to overhaul the method in which filters are generated anyway.
adam commented 2025-12-29 16:21:50 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 14, 2016):

I think the most practical way to fix this is to order prefixes first by VRF, and then by address. Does that make sense? Trying to maintain parallel hierarchies for multiple tables would be very difficult and probably introduce significant performance degradation.

@jeremystretch commented on GitHub (Sep 14, 2016): I think the most practical way to fix this is to order prefixes first by VRF, and then by address. Does that make sense? Trying to maintain parallel hierarchies for multiple tables would be very difficult and probably introduce significant performance degradation.
adam commented 2025-12-29 16:21:51 +01:00
Author
Owner
Copy Link

@LukeDRussell commented on GitHub (Sep 14, 2016):

Could we order by Tenant, then VRF, then prefix? I think it might help visualising address space with #259. But that may be getting out of scope for a single issue.

Order by VRF, then by address sounds good.

I'm not sure I follow with your second sentence though, my Python is absolute beginner.

@LukeDRussell commented on GitHub (Sep 14, 2016): Could we order by Tenant, then VRF, then prefix? I think it might help visualising address space with #259. But that may be getting out of scope for a single issue. Order by VRF, then by address sounds good. I'm not sure I follow with your second sentence though, my Python is absolute beginner.
adam commented 2025-12-29 16:21:51 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 15, 2016):

What I mean is it would be very difficult to do this:

  • 10.0.0.0/8 (global)
    • 10.1.0.0/16 (global)
  • 10.0.0.0/8 (VRF A)
    • 10.1.0.0/16 (VRF A)
  • 192.168.0.0/16 (global)
  • 192.168.0.0/16 (VRF A)

This is because 10.1.0.0/16 will be ordered after all 10.0.0.0/8 networks in the hierarchy. However, I believe an acceptable alternative is to simply arrange the hierarchy by VRF, which is much more efficient:

  • 10.0.0.0/8 (global)
    • 10.1.0.0/16 (global)
  • 192.168.0.0/16 (global)
  • 10.0.0.0/8 (VRF A)
    • 10.1.0.0/16 (VRF A)
  • 192.168.0.0/16 (VRF A)
@jeremystretch commented on GitHub (Sep 15, 2016): What I mean is it would be very difficult to do this: - 10.0.0.0/8 (global) - 10.1.0.0/16 (global) - 10.0.0.0/8 (VRF A) - 10.1.0.0/16 (VRF A) - 192.168.0.0/16 (global) - 192.168.0.0/16 (VRF A) This is because 10.1.0.0/16 will be ordered after all 10.0.0.0/8 networks in the hierarchy. However, I believe an acceptable alternative is to simply arrange the hierarchy by VRF, which is much more efficient: - 10.0.0.0/8 (global) - 10.1.0.0/16 (global) - 192.168.0.0/16 (global) - 10.0.0.0/8 (VRF A) - 10.1.0.0/16 (VRF A) - 192.168.0.0/16 (VRF A)
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: 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#412
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?