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

IP Prefix in VRF showing in all parent global container prefixes as well as master prefix list #2099

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

Originally created by @DanSheps on GitHub (Nov 7, 2018).

Originally assigned to: @DanSheps on GitHub.

Environment

  • Python version: 3.4
  • NetBox version: 2.3.7

Prefixes that are within a global container also visible on the main prefix list page, as well as subsequent child prefix lists within a prefix.

Related: #1073

Steps to Reproduce

  1. Create a IP Prefix in the Global as a container: 10.0.0.0/8
  2. Create a IP Prefix in the Global as a any status: 192.16.0.0/16
  3. Create a Child IP Prefix of 10.0.0.0/8 in the Global as a container: 10.0.0.0/16
  4. Create a Child IP Prefix of 10.0.0.0/8 in the Global as a active: 10.1.0.0/16
  5. Create a Child IP Prefix of 10.0.0.0/16 in VRF as a active network: 10.0.0.0/24
  6. Create a Child IP Prefix of 10.0.0.0/16 in VRF as a active network: 10.1.0.0/24
  7. Create a Child IP Prefix of 10.0.0.0/16 in VRF as a container network: 10.0.1.0/24
  8. Create a Child IP Prefix of 10.1.0.0/24 in VRF as a active network: 10.1.0.0/25
  9. Create a Child IP Prefix of 10.1.0.0/16 in VRF as a active network: 10.1.1.0/24

Expected Behavior

  • 10.0.0.0/24 visible as a child of 10.0.0.0/16
  • 10.1.0.0/24 visible as a child of 10.0.0.0/16
  • 10.1.0.0/25 visible as a child of 10.1.0.0/24

Observed Behavior

Prefix 10.0.0.0/24 is visible in (incorrect):

  • The main prefix list page (/ipam/prefixes) (incorrect)
  • 10.0.0.0/8 Child Prefixes (incorrect)
  • 10.0.0.0/16 Child Prefixes (correct)

Prefix 10.1.0.0/24 is visible in:

  • The main prefix list page (/ipam/prefixes) (incorrect)
  • 10.0.0.0/8 Child Prefixes (incorrect)
  • 10.0.0.0/16 Child Prefixes (correct)

Prefix 10.1.0.0/25 is visible in (this behaviour is correct, just included as a test case):

  • 10.1.0.0/24 child prefixes (correct)
Originally created by @DanSheps on GitHub (Nov 7, 2018). Originally assigned to: @DanSheps on GitHub. ### Environment * Python version: 3.4 * NetBox version: 2.3.7 Prefixes that are within a global container also visible on the main prefix list page, as well as subsequent child prefix lists within a prefix. Related: #1073 ### Steps to Reproduce 1. Create a IP Prefix in the **Global** as a **container**: 10.0.0.0/8 1. Create a IP Prefix in the **Global** as a **any status**: 192.16.0.0/16 2. Create a Child IP Prefix of 10.0.0.0/8 in the **Global** as a **container**: 10.0.0.0/16 2. Create a Child IP Prefix of 10.0.0.0/8 in the **Global** as a **active**: 10.1.0.0/16 3. Create a Child IP Prefix of 10.0.0.0/16 in **VRF** as a **active** network: 10.0.0.0/24 3. Create a Child IP Prefix of 10.0.0.0/16 in **VRF** as a **active** network: 10.1.0.0/24 3. Create a Child IP Prefix of 10.0.0.0/16 in **VRF** as a **container** network: 10.0.1.0/24 4. Create a Child IP Prefix of 10.1.0.0/24 in **VRF** as a **active** network: 10.1.0.0/25 4. Create a Child IP Prefix of 10.1.0.0/16 in **VRF** as a **active** network: 10.1.1.0/24 ### Expected Behavior * 10.0.0.0/24 visible as a child of 10.0.0.0/16 * 10.1.0.0/24 visible as a child of 10.0.0.0/16 * 10.1.0.0/25 visible as a child of 10.1.0.0/24 ### Observed Behavior Prefix 10.0.0.0/24 is visible in (incorrect): * The main prefix list page (/ipam/prefixes) (incorrect) * 10.0.0.0/8 Child Prefixes (incorrect) * 10.0.0.0/16 Child Prefixes (correct) Prefix 10.1.0.0/24 is visible in: * The main prefix list page (/ipam/prefixes) (incorrect) * 10.0.0.0/8 Child Prefixes (incorrect) * 10.0.0.0/16 Child Prefixes (correct) Prefix 10.1.0.0/25 is visible in (this behaviour is correct, just included as a test case): * 10.1.0.0/24 child prefixes (correct)
adam added the type: bugstatus: accepted labels 2025-12-29 17:22:17 +01:00
adam closed this issue 2025-12-29 17:22:17 +01:00
adam commented 2025-12-29 17:22:18 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Nov 7, 2018):

I am unable to recreate as was originally posted.

I am able to recreate this by importing my prefixes from production onto development. Further information, this looks like it is related to the amount of prefixes in the database.

I will slowly add prefixes and see where it errors out.

@DanSheps commented on GitHub (Nov 7, 2018): I am unable to recreate as was originally posted. I am able to recreate this by importing my prefixes from production onto development. Further information, this looks like it is related to the amount of prefixes in the database. I will slowly add prefixes and see where it errors out.
adam commented 2025-12-29 17:22:18 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Nov 7, 2018):

Edited test case, should now be able to reproduce.

Import(s) for prefixes:

prefix,vrf,tenant,site,vlan_group,vlan_vid,status,role,is_pool,description 10.0.0.0/8,,,,,,Container,,, 10.0.0.0/16,,,,,,Container,,, 10.1.0.0/16,,,,,,Container,,, 192.168.0.0/16,,,,,,Container,,, 10.0.0.0/24,1:1,,,,,Active,,, 10.0.1.0/24,1:1,,,,,Active,,, 10.1.0.0/24,1:1,,,,,Container,,, 10.1.0.0/25,1:1,,,,,Active,,, 10.1.1.0/24,1:1,,,,,Active,,,

Imports for VRFs:

name,rd,tenant,enforce_unique,description Test,1:1,,,

@DanSheps commented on GitHub (Nov 7, 2018): Edited test case, should now be able to reproduce. Import(s) for prefixes: `prefix,vrf,tenant,site,vlan_group,vlan_vid,status,role,is_pool,description 10.0.0.0/8,,,,,,Container,,, 10.0.0.0/16,,,,,,Container,,, 10.1.0.0/16,,,,,,Container,,, 192.168.0.0/16,,,,,,Container,,, 10.0.0.0/24,1:1,,,,,Active,,, 10.0.1.0/24,1:1,,,,,Active,,, 10.1.0.0/24,1:1,,,,,Container,,, 10.1.0.0/25,1:1,,,,,Active,,, 10.1.1.0/24,1:1,,,,,Active,,,` Imports for VRFs: `name,rd,tenant,enforce_unique,description Test,1:1,,,`
adam commented 2025-12-29 17:22:18 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Nov 7, 2018):

Screenshots

Observed:

prefixes
prefixes-10 0 0 0_8

Expected:

prefixes-10 0 0 0_8_expected
prefixes-10 0 0 0_16_expected

@DanSheps commented on GitHub (Nov 7, 2018): Screenshots Observed: ![prefixes](https://user-images.githubusercontent.com/11049792/48153378-aae0f080-e28b-11e8-8e7a-f122d1a71c35.PNG) ![prefixes-10 0 0 0_8](https://user-images.githubusercontent.com/11049792/48153380-ab798700-e28b-11e8-9b18-6c4ecace4298.PNG) Expected: ![prefixes-10 0 0 0_8_expected](https://user-images.githubusercontent.com/11049792/48153472-ebd90500-e28b-11e8-8f4c-fca2d012a618.PNG) ![prefixes-10 0 0 0_16_expected](https://user-images.githubusercontent.com/11049792/48153474-ebd90500-e28b-11e8-8baa-20b9f041d704.PNG)
adam commented 2025-12-29 17:22:19 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Nov 16, 2018):

Looks like this might be related to #1073

Root cause appears to be annotate_depth as annotate depth expects the next prefix to either be a child prefix or a new prefix and when something gets in the way between two child prefixes, it breaks.

@DanSheps commented on GitHub (Nov 16, 2018): Looks like this might be related to #1073 Root cause appears to be annotate_depth as annotate depth expects the next prefix to either be a child prefix or a new prefix and when something gets in the way between two child prefixes, it breaks.
adam commented 2025-12-29 17:22:19 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Nov 19, 2018):

I did some work on this, and discovered that the fix isn't as easy as I originally thought, It does hide the prefix, but it also hides the prefix if it is in a different VRF, so there will need some logic added to check for that, which is where I think it was failing before.

@DanSheps commented on GitHub (Nov 19, 2018): I did some work on this, and discovered that the fix isn't as easy as I originally thought, It does hide the prefix, but it also hides the prefix if it is in a different VRF, so there will need some logic added to check for that, which is where I think it was failing before.
adam commented 2025-12-29 17:22:19 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Jan 2, 2020):

I can confirm that this is still a bug.

I will be starting work on this shortly

@DanSheps commented on GitHub (Jan 2, 2020): I can confirm that this is still a bug. I will be starting work on this shortly
adam commented 2025-12-29 17:22:19 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Mar 31, 2020):

@DanSheps What is the status of this?

@jeremystretch commented on GitHub (Mar 31, 2020): @DanSheps What is the status of this?
adam commented 2025-12-29 17:22:20 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 21, 2020):

After speaking with @DanSheps, I don't think it's feasible to address this efficiently given the current logic in place for determining the IP prefix hierarchy. I'm going to close this out, and hope to revisit the issue once we have a better performing solution in place for calculating nested prefix depth.

@jeremystretch commented on GitHub (Apr 21, 2020): After speaking with @DanSheps, I don't think it's feasible to address this efficiently given the current logic in place for determining the IP prefix hierarchy. I'm going to close this out, and hope to revisit the issue once we have a better performing solution in place for calculating nested prefix depth.
adam commented 2025-12-29 17:22:20 +01:00
Author
Owner
Copy Link

@vladsol commented on GitHub (Jun 27, 2020):

So, at this moment is it not possible to display nested subnets in different VRF display as child with respect to global container?
Earlier we used phpipam, and there the hierarchy of networks was very convenient.
In netbox, this is more complicated :) In this case, it is probably easier to completely abandon the use of VRF.

@vladsol commented on GitHub (Jun 27, 2020): So, at this moment is it not possible to display nested subnets in different VRF display as child with respect to global container? Earlier we used phpipam, and there the hierarchy of networks was very convenient. In netbox, this is more complicated :) In this case, it is probably easier to completely abandon the use of VRF.
adam commented 2025-12-29 17:22:20 +01:00
Author
Owner
Copy Link

@DukeNuke3D commented on GitHub (Jul 14, 2020):

Hi developers!
Imagine the following - we have contiguous IPv6 /32 prefix. Next we slice it into peaces and assign child prefixes to different security zones, locations. projects and VRFs - these are all containers. This result in deep hierarchy of address plan and in netbox last lowest-level /64 assignments will be shown apart from top-level containers. This would make sense in IPv4, but it looks weird for IPv6 since all the address space is flat.
I hope I described the problem clearly, if needed I could show screenshots with actual address plan example.

@DukeNuke3D commented on GitHub (Jul 14, 2020): Hi developers! Imagine the following - we have contiguous IPv6 /32 prefix. Next we slice it into peaces and assign child prefixes to different security zones, locations. projects and VRFs - these are all containers. This result in deep hierarchy of address plan and in netbox last lowest-level /64 assignments will be shown apart from top-level containers. This would make sense in IPv4, but it looks weird for IPv6 since all the address space is flat. I hope I described the problem clearly, if needed I could show screenshots with actual address plan example.
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: accepted 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#2099
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?