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

Make IP-addresses visible in prefixes of other VRFs #10287

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

Originally created by @Nefti-sama on GitHub (Sep 25, 2024).

NetBox version

v4.1.1

Feature type

Change to existing functionality

Proposed functionality

If you create a prefix in VRF Global and create an IP-Address in VRF-2, the IP-Address should be visible in the prefix you created in VRF Global.
The same applies for prefixes and child-prefixes.

Use case

Why would one want to have that?

  • Loopback Pools: Create a /24 prefix that is used for loopbacks in the whole network regardless of the VRF (common practice). That results in one prefix (maybe in Global) containing addresses of many VRFs
  • Transfer networks between VRFs: If one creates a transfer network between 2 VRF's one address is in VRF-1 and the other one in VRF-2, but both are part of the same prefix.
  • Transfer networks within VRF: One might have assigned a /24 prefix for all transfer networks in a system, regardless of the VRF. This network will be sliced in /31 (or any other size) prefixes that are a member of a VRF but should be visible under the /24 prefix

How could that be achieved (just brainstorming)?

  • If an IP-address does not match any prefix in it's VRF but there is a prefix in "Global", make it part of this prefix
  • Possibly add a checkbox "Catchall" to activate this feature for desired prefixes (would need a DB change)

Database changes

Depends

External dependencies

No response

Originally created by @Nefti-sama on GitHub (Sep 25, 2024). ### NetBox version v4.1.1 ### Feature type Change to existing functionality ### Proposed functionality If you create a prefix in VRF Global and create an IP-Address in VRF-2, the IP-Address should be visible in the prefix you created in VRF Global. The same applies for prefixes and child-prefixes. ### Use case Why would one want to have that? * Loopback Pools: Create a /24 prefix that is used for loopbacks in the whole network regardless of the VRF (common practice). That results in one prefix (maybe in Global) containing addresses of many VRFs * Transfer networks between VRFs: If one creates a transfer network between 2 VRF's one address is in VRF-1 and the other one in VRF-2, but both are part of the same prefix. * Transfer networks within VRF: One might have assigned a /24 prefix for all transfer networks in a system, regardless of the VRF. This network will be sliced in /31 (or any other size) prefixes that are a member of a VRF but should be visible under the /24 prefix How could that be achieved (just brainstorming)? * If an IP-address does not match any prefix in it's VRF but there is a prefix in "Global", make it part of this prefix * Possibly add a checkbox "Catchall" to activate this feature for desired prefixes (would need a DB change) ### Database changes Depends ### External dependencies _No response_
adam added the type: featurenetbox labels 2025-12-29 21:29:26 +01:00
adam closed this issue 2025-12-29 21:29:26 +01:00
adam commented 2025-12-29 21:29:27 +01:00
Author
Owner
Copy Link

@cruse1977 commented on GitHub (Sep 28, 2024):

If I log onto a router and show the global table, I don't see VRF routes. Likewise, in the main VRF's don't see other VRF routes, unless I specifically configure routing leaking - so your use case is against how most routers would work.

I think you need to flesh this out more, what you are describing is more akin to a l3 domain - but arguably its not VRF.

@cruse1977 commented on GitHub (Sep 28, 2024): If I log onto a router and show the global table, I don't see VRF routes. Likewise, in the main VRF's don't see other VRF routes, unless I specifically configure routing leaking - so your use case is against how most routers would work. I think you need to flesh this out more, what you are describing is more akin to a l3 domain - but arguably its not VRF.
adam commented 2025-12-29 21:29:27 +01:00
Author
Owner
Copy Link

@Nefti-sama commented on GitHub (Oct 1, 2024):

I think you are mixing up how the real world works (which is like you describe it besides the fact that I do indeed see the transfer-networks in both VRFs that it connects) and how a useful display of information in the netbox GUI could be done.
My usecase addresses the display of information in the GUI. If you are doing a bit of IP address management you are quite happy to see the information that I describe without clicking to 15 different places.
This could also be achieved with selecting a "display-parent prefix" for each prefix which would overwrite the automatic placement. The key point is the ability to display information in a compact way without sacrificing/altering parameters that could be used for automation

@Nefti-sama commented on GitHub (Oct 1, 2024): I think you are mixing up how the real world works (which is like you describe it besides the fact that I do indeed see the transfer-networks in both VRFs that it connects) and how a useful display of information in the netbox GUI could be done. My usecase addresses the display of information in the GUI. If you are doing a bit of IP address management you are quite happy to see the information that I describe without clicking to 15 different places. This could also be achieved with selecting a "display-parent prefix" for each prefix which would overwrite the automatic placement. The key point is the ability to display information in a compact way without sacrificing/altering parameters that could be used for automation
adam commented 2025-12-29 21:29:28 +01:00
Author
Owner
Copy Link

@PieterL75 commented on GitHub (Oct 2, 2024):

Current behavior is : if your prefix is set to 'global' then you will see all of the child prefixes and the IPs of all VRFs. once you select a VRF for the prefix, then only the child prefix and IPs of that VRF will be shown.

@PieterL75 commented on GitHub (Oct 2, 2024): Current behavior is : if your prefix is set to 'global' then you will see all of the child prefixes and the IPs of all VRFs. once you select a VRF for the prefix, then only the child prefix and IPs of that VRF will be shown.
adam commented 2025-12-29 21:29:28 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Oct 2, 2024):

I think you are mixing up how the real world works (which is like you describe it besides the fact that I do indeed see the transfer-networks in both VRFs that it connects) and how a useful display of information in the netbox GUI could be done.

The main consumers of NetBox are Network Engineers. NetBox is designed to mimic the real-world where possible. To your proposal, I do not want my IP's that are in VRF ABC to be displayed in the global table, irregardless of whether or not there is containing active prefix.

My usecase addresses the display of information in the GUI. If you are doing a bit of IP address management you are quite happy to see the information that I describe without clicking to 15 different places.

This is your use case, but not the thousands of other users of NetBox.

This could also be achieved with selecting a "display-parent prefix" for each prefix which would overwrite the automatic placement. The key point is the ability to display information in a compact way without sacrificing/altering parameters that could be used for automation

I don't think we need to add any additional knobs for this. I don't think this is an option the vast majority of the community wants. That said, you are free to create a plugin to display this how you like using the existing models.

Current behavior is : if your prefix is set to 'global' then you will see all of the child prefixes and the IPs of all VRFs. once you select a VRF for the prefix, then only the child prefix and IPs of that VRF will be shown.

Not 100% true. Behaviour is:

If Prefix:

  • is container
  • solely encompasses addresses/prefixes (no "longer" match)
  • is in Global VRF

it will display those IPs

@DanSheps commented on GitHub (Oct 2, 2024): > I think you are mixing up how the real world works (which is like you describe it besides the fact that I do indeed see the transfer-networks in both VRFs that it connects) and how a useful display of information in the netbox GUI could be done. The main consumers of NetBox are Network Engineers. NetBox is designed to mimic the real-world where possible. To your proposal, I do not want my IP's that are in VRF ABC to be displayed in the global table, irregardless of whether or not there is containing active prefix. > My usecase addresses the display of information in the GUI. If you are doing a bit of IP address management you are quite happy to see the information that I describe without clicking to 15 different places. This is your use case, but not the thousands of other users of NetBox. > This could also be achieved with selecting a "display-parent prefix" for each prefix which would overwrite the automatic placement. The key point is the ability to display information in a compact way without sacrificing/altering parameters that could be used for automation I don't think we need to add any additional knobs for this. I don't think this is an option the vast majority of the community wants. That said, you are free to create a plugin to display this how you like using the existing models. > Current behavior is : if your prefix is set to 'global' then you will see all of the child prefixes and the IPs of all VRFs. once you select a VRF for the prefix, then only the child prefix and IPs of that VRF will be shown. Not 100% true. Behaviour is: If Prefix: * is `container` * solely encompasses addresses/prefixes (no "longer" match) * is in Global VRF it will display those IPs
adam commented 2025-12-29 21:29:28 +01:00
Author
Owner
Copy Link

@Nefti-sama commented on GitHub (Oct 9, 2024):

Thats great, because I am a network engineer too - and I need that. And yes, Netbox shall mimic the real world (while it does not in many cases, just thinking of SFPs with multiple lanes that are broke out to multiple "physical" ports where you can't assign lanes to these ports or "use" the same SFP).
And you are right in the case where you don't want IP's "pop up" in other VRFs, that would be a disaster if it is unintentionally. But you can't deny the fact that it is currently not possible to accurately display the very real world example where there is a /30 network that connects 2 VRFs together. You would have the first IP sit in VRF1 and the second IP in VRF2 while the prefix can't sit in either (because its between those 2) and the IP's would be "orphaned" in the VRFs.

Netbox is not just about storing real world data. If you want to do that you create some database and push data into it or put files into a directory. The very fact that Netbox has a GUI and does some very incredible visualizations proof that. And I remember when Netbox did not have many of these things - apparently the community was asking for it and I am sure it was not the vast majority. I am also sure that there are many more already implemented features that this vast majority does not want or need (more "not need" than "not want").
The problem is that you do not know for sure. You have now way of knowing. Because ppl will probably workaround this problem by creating a "Interconnect VRF" or a "Loopback Pool VRF" where they put in the prefixes and IPs and use some syntax in the Comments or Tags (if even needed) to make it understandable to the automation what that fuzz is about. Most of them don't got through the effort of creating a GitHub issue and wait for days/weeks/months for this to be implemented. They need the solution now (because they stumbled across it) and creating an issue for the future is not relevant to them because they won't change their workaround anyways (it works fine for them). And this way they slowly deviate from the idea you defend so much: mimicing the real-world where possible

And yes, it is true, I can just create a plugin and be happy. But if everyone would have just created his own plugins, Netbox would miss out on many cool features that ppl love and wanted to use. And as I pointed out earlier, I assume for pretty much no feature the "vast majority" did ask for it.

I do not think being a plugin-hub is the way to go for Netbox but I also don't think every idea should be implemented. I layed down my arguments why I think this would be a good thing to have and I proposed two possible implementations: automatic or semi automatic - where I would argue that the semi-automatic would be more deterministic and would not result in addresses popping up in Global (or another VRF) where they should not be. There could also be a different solution that I did not think of.

@Nefti-sama commented on GitHub (Oct 9, 2024): Thats great, because I am a network engineer too - and I need that. And yes, Netbox shall mimic the real world (while it does not in many cases, just thinking of SFPs with multiple lanes that are broke out to multiple "physical" ports where you can't assign lanes to these ports or "use" the same SFP). And you are right in the case where you don't want IP's "pop up" in other VRFs, that would be a disaster if it is unintentionally. But you can't deny the fact that it is currently not possible to accurately display the very real world example where there is a /30 network that connects 2 VRFs together. You would have the first IP sit in VRF1 and the second IP in VRF2 while the prefix can't sit in either (because its between those 2) and the IP's would be "orphaned" in the VRFs. Netbox is not just about storing real world data. If you want to do that you create some database and push data into it or put files into a directory. The very fact that Netbox has a GUI and does some very incredible visualizations proof that. And I remember when Netbox did not have many of these things - apparently the community was asking for it and I am sure it was not the vast majority. I am also sure that there are many more already implemented features that this vast majority does not want or need (more "not need" than "not want"). The problem is that you do not know for sure. You have now way of knowing. Because ppl will probably workaround this problem by creating a "Interconnect VRF" or a "Loopback Pool VRF" where they put in the prefixes and IPs and use some syntax in the Comments or Tags (if even needed) to make it understandable to the automation what that fuzz is about. Most of them don't got through the effort of creating a GitHub issue and wait for days/weeks/months for this to be implemented. They need the solution now (because they stumbled across it) and creating an issue for the future is not relevant to them because they won't change their workaround anyways (it works fine for them). And this way they slowly deviate from the idea you defend so much: mimicing the real-world where possible And yes, it is true, I can just create a plugin and be happy. But if everyone would have just created his own plugins, Netbox would miss out on many cool features that ppl love and wanted to use. And as I pointed out earlier, I assume for pretty much no feature the "vast majority" did ask for it. I do not think being a plugin-hub is the way to go for Netbox but I also don't think every idea should be implemented. I layed down my arguments why I think this would be a good thing to have and I proposed two possible implementations: automatic or semi automatic - where I would argue that the semi-automatic would be more deterministic and would not result in addresses popping up in Global (or another VRF) where they should not be. There could also be a different solution that I did not think of.
adam commented 2025-12-29 21:29:28 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Oct 9, 2024):

And yes, Netbox shall mimic the real world (while it does not in many cases, just thinking of SFPs with multiple lanes that are broke out to multiple "physical" ports where you can't assign lanes to these ports or "use" the same SFP).

There is a parent/child relationship for exactly this reason within NetBox on the Interface model to specifically allow modelling a breakout cable.

And you are right in the case where you don't want IP's "pop up" in other VRFs, that would be a disaster if it is unintentionally. But you can't deny the fact that it is currently not possible to accurately display the very real world example where there is a /30 network that connects 2 VRFs together. You would have the first IP sit in VRF1 and the second IP in VRF2 while the prefix can't sit in either (because its between those 2) and the IP's would be "orphaned" in the VRFs.

The simple fact of the matter is, for consistency reasons, the data model cannot handle this use case, and it won't.

You have two choices:

  • Leave the prefix in the global VRF
  • Place the prefix in a VRF, assign both IPs to that VRF, have the interface VRF assignment be your determinator for interface configuration

I am also sure that there are many more already implemented features that this vast majority does not want or need (more "not need" than "not want"). The problem is that you do not know for sure. You have now way of knowing. Because ppl will probably workaround this problem by creating a "Interconnect VRF" or a "Loopback Pool VRF" where they put in the prefixes and IPs and use some syntax in the Comments or Tags (if even needed) to make it understandable to the automation what that fuzz is about. Most of them don't got through the effort of creating a GitHub issue and wait for days/weeks/months for this to be implemented. They need the solution now (because they stumbled across it) and creating an issue for the future is not relevant to them because they won't change their workaround anyways (it works fine for them). And this way they slowly deviate from the idea you defend so much: mimicing the real-world where possible

The community is very active on both GitHub and slack, if a feature is missing, they will request it. We have had over 10K, we just recently crossed the 10000 issue mark, which just goes to show that we are in fact a very active community.

And yes, it is true, I can just create a plugin and be happy. But if everyone would have just created his own plugins, Netbox would miss out on many cool features that ppl love and wanted to use. And as I pointed out earlier, I assume for pretty much no feature the "vast majority" did ask for it.

You can always release your plugin. Many people have released their plugins.

@DanSheps commented on GitHub (Oct 9, 2024): > And yes, Netbox shall mimic the real world (while it does not in many cases, just thinking of SFPs with multiple lanes that are broke out to multiple "physical" ports where you can't assign lanes to these ports or "use" the same SFP). There is a parent/child relationship for exactly this reason within NetBox on the Interface model to specifically allow modelling a breakout cable. > And you are right in the case where you don't want IP's "pop up" in other VRFs, that would be a disaster if it is unintentionally. But you can't deny the fact that it is currently not possible to accurately display the very real world example where there is a /30 network that connects 2 VRFs together. You would have the first IP sit in VRF1 and the second IP in VRF2 while the prefix can't sit in either (because its between those 2) and the IP's would be "orphaned" in the VRFs. The simple fact of the matter is, for consistency reasons, the data model cannot handle this use case, and it won't. You have two choices: * Leave the prefix in the global VRF * Place the prefix in a VRF, assign both IPs to that VRF, have the interface VRF assignment be your determinator for interface configuration > I am also sure that there are many more already implemented features that this vast majority does not want or need (more "not need" than "not want"). The problem is that you do not know for sure. You have now way of knowing. Because ppl will probably workaround this problem by creating a "Interconnect VRF" or a "Loopback Pool VRF" where they put in the prefixes and IPs and use some syntax in the Comments or Tags (if even needed) to make it understandable to the automation what that fuzz is about. Most of them don't got through the effort of creating a GitHub issue and wait for days/weeks/months for this to be implemented. They need the solution now (because they stumbled across it) and creating an issue for the future is not relevant to them because they won't change their workaround anyways (it works fine for them). And this way they slowly deviate from the idea you defend so much: mimicing the real-world where possible The community is very active on both GitHub and slack, if a feature is missing, they will request it. We have had over 10K, we just recently crossed the 10000 issue mark, which just goes to show that we are in fact a very active community. > And yes, it is true, I can just create a plugin and be happy. But if everyone would have just created his own plugins, Netbox would miss out on many cool features that ppl love and wanted to use. And as I pointed out earlier, I assume for pretty much no feature the "vast majority" did ask for it. You can always release your plugin. Many people have released their plugins.
adam commented 2025-12-29 21:29:29 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 23, 2025):

The proposed behavior would violate the intended functioning of VRFs in NetBox, which exist primarily to define isolated domains, as has been detailed above.

@jeremystretch commented on GitHub (Jan 23, 2025): The proposed behavior would violate the intended functioning of VRFs in NetBox, which exist primarily to define isolated domains, as has been detailed above.
adam commented 2025-12-29 21:29:29 +01:00
Author
Owner
Copy Link

@PieterL75 commented on GitHub (Jan 23, 2025):

@DanSheps
This feature has been requested multiple times, by me and many others. The ISP workgroup is also asking for it.
The implementation of a VRF in NetBox is too limited. One IP range can be unique across vrfs, when these vrfs are interconnected ( firewall, leaking, redist in other protocol, ... ) and not only within the vrf.
I understand that the current implementation is deep in the logic, but maybe it is time to change that, before more routing logic is implemented and making it even more difficult.

Just my 5 cents, I really hope to see this in NetBox

@PieterL75 commented on GitHub (Jan 23, 2025): @DanSheps This feature has been requested multiple times, by me and many others. The ISP workgroup is also asking for it. The implementation of a VRF in NetBox is too limited. One IP range can be unique across vrfs, when these vrfs are interconnected ( firewall, leaking, redist in other protocol, ... ) and not only within the vrf. I understand that the current implementation is deep in the logic, but maybe it is time to change that, before more routing logic is implemented and making it even more difficult. Just my 5 cents, I really hope to see this in NetBox
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 netbox 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#10287
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?