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

Feature request : IP address in a VRF appears in prefix #854

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

Originally created by @VictorJ76 on GitHub (Apr 11, 2017).

I my use case, I use a Prefix to store the IPs of my clients. In this prefix there are multiples IP in multiples VRF so I can't attribute the prefix a VRF and when I add an IP, she doesn't appear in the prefix.
My request is to see in the prefix the different IP in different VRF.

Originally created by @VictorJ76 on GitHub (Apr 11, 2017). I my use case, I use a Prefix to store the IPs of my clients. In this prefix there are multiples IP in multiples VRF so I can't attribute the prefix a VRF and when I add an IP, she doesn't appear in the prefix. My request is to see in the prefix the different IP in different VRF.
adam closed this issue 2025-12-29 16:26:22 +01:00
adam commented 2025-12-29 16:26:22 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 11, 2017):

That would entirely defeat the purpose of modeling a VRF. A prefix either belongs to the global table or to a VRF. If you have multiple overlapping prefixes assigned to different VRFs, each one needs to be modeled in its parent VRF separately.

@jeremystretch commented on GitHub (Apr 11, 2017): That would entirely defeat the purpose of modeling a VRF. A prefix either belongs to the global table or to a VRF. If you have multiple overlapping prefixes assigned to different VRFs, each one needs to be modeled in its parent VRF separately.
adam commented 2025-12-29 16:26:23 +01:00
Author
Owner
Copy Link

@martink2 commented on GitHub (Apr 12, 2017):

Yes, in general I fully agree with the prefix only showing siblings in his own VRF
because thats what VRF's are meant to do.

But I would like to point out one exception where it might make sense to divert.
That would be the prefix type Container. We have a lot of /24 prefixes set aside
as containers to allocate Router ID's and corresponding /32 loopback IP's from
or others we set aside for allocating /31 for transit networks on our routers.

So we used to have a nice workflow where someone needed a transit network he would
go into the container and create a /31 from the list of available sub-prefixes and of cause
assign it to the respective VRF it is needed in. For the special case of Containers it always
worked exceptionally well for us, unfortunately the latest release introduced a functional
change so now we can see all our containers do no longer have any child prefixes thus it is
very cumbersome to figure out what has been allocated from the container and find the "next available".

If you think vrf global + type container is not the right combination to model a vrf spanning pool
for sub-prefix management I would kindly ask to provide another way to achieve this.

I can see that "vrf global" + "type container" would be a convention here to signify cross VRF relevancy of a prefix. The only other thing i could think of would be the ability to flag a Prefix
(and by inheritance/convention all sub-prefixes) as globally unique across all VRF's.

Implementation of the later would of cause be more work than just treating a certain combination
differently but it would also solve a different problem. We are currently using a lot of BGP-L3VPN
connections in our network with route-leaking across VRF's. A lot of central services are leaked
into VRF's which means we need to manage a range of prefixes which should be globally unique
as to not interfere with client VRF routes during leaking. Being able to mark a prefix as global
would make it possible to subsequently give an error message if someone tries to create the same
prefix or sub-prefix from within the unique range in another VRF.

@martink2 commented on GitHub (Apr 12, 2017): Yes, in general I fully agree with the prefix only showing siblings in his own VRF because thats what VRF's are meant to do. But I would like to point out one exception where it might make sense to divert. That would be the prefix type Container. We have a lot of /24 prefixes set aside as containers to allocate Router ID's and corresponding /32 loopback IP's from or others we set aside for allocating /31 for transit networks on our routers. So we used to have a nice workflow where someone needed a transit network he would go into the container and create a /31 from the list of available sub-prefixes and of cause assign it to the respective VRF it is needed in. For the special case of Containers it always worked exceptionally well for us, unfortunately the latest release introduced a functional change so now we can see all our containers do no longer have any child prefixes thus it is very cumbersome to figure out what has been allocated from the container and find the "next available". If you think vrf global + type container is not the right combination to model a vrf spanning pool for sub-prefix management I would kindly ask to provide another way to achieve this. I can see that "vrf global" + "type container" would be a convention here to signify cross VRF relevancy of a prefix. The only other thing i could think of would be the ability to flag a Prefix (and by inheritance/convention all sub-prefixes) as globally unique across all VRF's. Implementation of the later would of cause be more work than just treating a certain combination differently but it would also solve a different problem. We are currently using a lot of BGP-L3VPN connections in our network with route-leaking across VRF's. A lot of central services are leaked into VRF's which means we need to manage a range of prefixes which should be globally unique as to not interfere with client VRF routes during leaking. Being able to mark a prefix as global would make it possible to subsequently give an error message if someone tries to create the same prefix or sub-prefix from within the unique range in another VRF.
adam commented 2025-12-29 16:26:23 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 12, 2017):

@martink2 Please open a new issue for your request as it is not strictly related to this one.

Edit: I believe this is the change you're referring to.

@jeremystretch commented on GitHub (Apr 12, 2017): @martink2 Please open a new issue for your request as it is not strictly related to this one. Edit: I believe [this](https://github.com/digitalocean/netbox/commit/d89314a559a887484e2fd8e5985bb1b2cdf8777f#diff-4f32f0b261822fd085a875ffb8a16bacR423) is the change you're referring to.
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
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#854
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?