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

Prefix in different VRF wrongly sees global prefix as its parent #7624

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

Originally created by @candlerb on GitHub (Feb 9, 2023).

Originally assigned to: @DanSheps on GitHub.

NetBox version

v3.4.4

Python version

3.8

Steps to Reproduce

  1. Create VRF "testvrf"
  2. Create prefix 192.168.0.0/24 in global VRF
  3. Create prefix 192.168.0.0/28 in "testvrf"
  4. Browse to 192.168.0.0/28 (which is where you'll be right after creation)

Expected Behavior

192.168.0.0/28@testvrf and 192.168.0.0/24 should be independent from each other, as they are in different VRFs.

Observed Behavior

192.168.0.0/28@testvrf sees 192.168.0.0/24 as its parent.

image

However, 192.168.0.0/24 does not see 192.168.0.0/28@testvrf as its child.

This is inconsistent: this child<->parent relationship should either work in both ways, or neither.

In this case, I think it should be neither: otherwise 192.168.0.0/24 could see many different prefixes and IP addresses in different VRFs as its children, which would mix lots of VRFs together in the same view.

EDIT: the current behaviour does appear to be intentional in the code:

        # Parent prefixes table
        parent_prefixes = Prefix.objects.restrict(request.user, 'view').filter(
            Q(vrf=instance.vrf) | Q(vrf__isnull=True)
Originally created by @candlerb on GitHub (Feb 9, 2023). Originally assigned to: @DanSheps on GitHub. ### NetBox version v3.4.4 ### Python version 3.8 ### Steps to Reproduce 1. Create VRF "testvrf" 2. Create prefix 192.168.0.0/24 in global VRF 3. Create prefix 192.168.0.0/28 in "testvrf" 4. Browse to 192.168.0.0/28 (which is where you'll be right after creation) ### Expected Behavior 192.168.0.0/28@testvrf and 192.168.0.0/24 should be independent from each other, as they are in different VRFs. ### Observed Behavior 192.168.0.0/28@testvrf sees 192.168.0.0/24 as its parent. ![image](https://user-images.githubusercontent.com/44789/217877506-1e926779-8829-4f31-b6ed-b0035195efdb.png) However, 192.168.0.0/24 does *not* see 192.168.0.0/28@testvrf as its child. This is inconsistent: this child<->parent relationship should either work in both ways, or neither. In this case, I think it should be neither: otherwise 192.168.0.0/24 could see many different prefixes and IP addresses in different VRFs as its children, which would mix lots of VRFs together in the same view. EDIT: the current behaviour *does* appear to be intentional in the [code](https://github.com/netbox-community/netbox/blob/v3.4.4/netbox/ipam/views.py#L461-L463): ``` # Parent prefixes table parent_prefixes = Prefix.objects.restrict(request.user, 'view').filter( Q(vrf=instance.vrf) | Q(vrf__isnull=True) ```
adam added the type: bugstatus: accepted labels 2025-12-29 20:26:12 +01:00
adam closed this issue 2025-12-29 20:26:12 +01:00
adam commented 2025-12-29 20:26:12 +01:00
Author
Owner
Copy Link

@jsenecal commented on GitHub (Feb 10, 2023):

The current behavior is indeed intentional. This allows for Container prefixes in the Global VRF to nest under it smaller prefixes in the table views.

Can you clarify what you would like fixed in that case, if anything ?

@jsenecal commented on GitHub (Feb 10, 2023): The current behavior is indeed intentional. This allows for Container prefixes in the Global VRF to nest under it smaller prefixes in the table views. Can you clarify what you would like fixed in that case, if anything ?
adam commented 2025-12-29 20:26:12 +01:00
Author
Owner
Copy Link

@candlerb commented on GitHub (Feb 10, 2023):

If A is the parent of B, then B should be the child of A. This isn't the case currently.

If you want to make a container prefix for prefixes in VRF X, then the container should also be within VRF X (IMO).

@candlerb commented on GitHub (Feb 10, 2023): If A is the parent of B, then B should be the child of A. This isn't the case currently. If you want to make a container prefix for prefixes in VRF X, then the container should also be within VRF X (IMO).
adam commented 2025-12-29 20:26:12 +01:00
Author
Owner
Copy Link

@bobbwest commented on GitHub (Feb 11, 2023):

Worse still, if there are two 192.168.0.0/24 prefixes, one in global, one in the VRF "testvrf", which one would be the parent of 192.168.0.0/28@testvrf ? Both? It should be the one in the same VRF.

VRFs are separate routing domains; there's no reason for a prefix in global to show up in a VRF. In the rare cases when route leaking is happening between VRFs, then I think that the prefix should be listed in each VRF with a note as to how it is appearing there.

@bobbwest commented on GitHub (Feb 11, 2023): Worse still, if there are two 192.168.0.0/24 prefixes, one in global, one in the VRF "testvrf", which one would be the parent of 192.168.0.0/28@testvrf ? Both? It should be the one in the same VRF. VRFs are separate routing domains; there's no reason for a prefix in global to show up in a VRF. In the rare cases when route leaking is happening between VRFs, then I think that the prefix should be listed in each VRF with a note as to how it is appearing there.
adam commented 2025-12-29 20:26:13 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Feb 18, 2023):

The current behavior is indeed intentional. This allows for Container prefixes in the Global VRF to nest under it smaller prefixes in the table views.

Can you clarify what you would like fixed in that case, if anything ?

It is only suppose to work this way if it is set as "Container" for status.

@DanSheps commented on GitHub (Feb 18, 2023): > The current behavior is indeed intentional. This allows for Container prefixes in the Global VRF to nest under it smaller prefixes in the table views. > > Can you clarify what you would like fixed in that case, if anything ? It is only suppose to work this way if it is set as "Container" for status.
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#7624
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?