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

Adding a Site relation to the VRF Model #5122

New Issue
Closed
opened 2025-12-29 19:24:30 +01:00 by adam · 6 comments
adam commented 2025-12-29 19:24:30 +01:00
Owner
Copy Link

Originally created by @martijnremmen on GitHub (Jul 30, 2021).

NetBox version

v2.11.9

Feature type

Data model extension

Proposed functionality

Addition of a Site relation to the VRF Model.

Use case

Our company manages a very diverse selection of sites for many different costumers. Some of our sites are campuses in which we use VRF's and in some/most, we don't.

This way we manage VRF's means that we associate them directly with a certain site and are not just global across all costumers/sites. Some Sites have multiple VRFs and some only the implied 'default'. Currently we put the site name in the VRF name separated with an underscore (eg 'amsterdam_default'), but this is suboptimal for obvious reasons.

For us, adding a Site relation to the VRF Model would be extremely helpful (and borderline required for accurately representing our organizational structure).

Database changes

Site relation field to the VRF table

External dependencies

None

Originally created by @martijnremmen on GitHub (Jul 30, 2021). ### NetBox version v2.11.9 ### Feature type Data model extension ### Proposed functionality Addition of a Site relation to the VRF Model. ### Use case Our company manages a very diverse selection of sites for many different costumers. Some of our sites are campuses in which we use VRF's and in some/most, we don't. This way we manage VRF's means that we associate them directly with a certain site and are not just global across all costumers/sites. Some Sites have multiple VRFs and some only the implied 'default'. Currently we put the site name in the VRF name separated with an underscore (eg 'amsterdam_default'), but this is suboptimal for obvious reasons. For us, adding a Site relation to the VRF Model would be extremely helpful (and borderline required for accurately representing our organizational structure). ### Database changes Site relation field to the VRF table ### External dependencies None
adam added the type: feature label 2025-12-29 19:24:30 +01:00
adam closed this issue 2025-12-29 19:24:30 +01:00
adam commented 2025-12-29 19:24:31 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Jul 30, 2021):

Can you elaborate more on your use case, this doesn't sound like best practices. If you have VRF x at site y and VRF x at site z, and they use the same RD and targets they are the same VRF and you should not be creating different VRFs in Netbox to model that. If they use different targets then how are you routing between the networks?

If they have different RD's at sites, then you should be using the RD to locate them. I don't see us adding this into core any time soon.

@DanSheps commented on GitHub (Jul 30, 2021): Can you elaborate more on your use case, this doesn't sound like best practices. If you have VRF x at site y and VRF x at site z, and they use the same RD and targets they are the same VRF and you should not be creating different VRFs in Netbox to model that. If they use different targets then how are you routing between the networks? If they have different RD's at sites, then you should be using the RD to locate them. I don't see us adding this into core any time soon.
adam commented 2025-12-29 19:24:31 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jul 30, 2021):

Honestly it sounds like you're not using VRFs for their intended purpose. A VRF is a layer three routing domain: it's not typically bound to a specific location. Rather, you have multiple VRFs present at each location. I agree with @DanSheps that adding this would not agree with NetBox's employment of the VRF concept.

@jeremystretch commented on GitHub (Jul 30, 2021): Honestly it sounds like you're not using VRFs for their intended purpose. A VRF is a layer three routing domain: it's not typically bound to a specific location. Rather, you have multiple VRFs present at each location. I agree with @DanSheps that adding this would not agree with NetBox's employment of the VRF concept.
adam commented 2025-12-29 19:24:31 +01:00
Author
Owner
Copy Link

@martijnremmen commented on GitHub (Aug 3, 2021):

I think I jumped the gun on this solution. So I'll take a step back here and explain our situation in more detail.

Scenario

We are a service provider with multiple different customers. So our situation might look like this (note that we have a lot more customers and sites):

  • Customer A

    • Site 1
      • Prefix 10.0.0.0/9
    • Site 2
      • Prefix 10.128.0.0/9
    • Site 3 - Azure
      • vnet 1
        • prefix 172.16.0.0/16

  • Customer B

    • Site 1 (campus site)
      • VRF01 - Tenant A
        • Subnet 10.0.0.0/8
      • VRF02 - Tenant B
        • Subnet 10.0.0.0/8

  • Our own company C

    • Site 1 - HQ
      • prefix 10.0.0.0/16
    • Site 2 - Azure
      • vnet 1
        • prefix 172.16.0.0/12

To explain what's going on

Customer A is a typical scenario, they have a couple of sites with unique prefixes (including an azure 'site'). The only thing to note is that we can have more customers that use overlapping prefixes. So this 'routing domain' is in this case limited to one particular customer. All prefixes within that customer/routing domain are unique.

Customer B represents a campus. We provide some more advanced services at campuses. Like we give tenants the ability to choose their own subnets, by providing them with their own VRF. These VRFs are scoped to this particular tenant, at this particular campus.

Customer C represents our own company (we do our own networking). There's nothing weird here, it's like Customer A.

Problem

The only way to model these different routing domains in Netbox is by using VRFs (?). But then it's relatively easy to loose track of which VRF represents which routing domain. We'd have to resort to a fairly complex naming scheme which isn't ideal for this many different customers. Not to mention we are modeling something as being a VRF that isn't an actual VRF.

For example, this obviously happens without using VRFs to seperate the two customer routing domains.
image

Conclusion

I'd like to hear any suggestions on how to model this scenario in Netbox. But it does raise the question whether Netbox currently supports a Service Provider use case

I'd be happy to answer any questions

@martijnremmen commented on GitHub (Aug 3, 2021): I think I jumped the gun on this solution. So I'll take a step back here and explain our situation in more detail. ### Scenario We are a service provider with multiple different customers. So our situation might look like this (note that we have a lot more customers and sites): * Customer A * Site 1 * Prefix 10.0.0.0/9 * Site 2 * Prefix 10.128.0.0/9 * Site 3 - Azure * vnet 1 * prefix 172.16.0.0/16 * Customer B * Site 1 (campus site) * VRF01 - Tenant A * Subnet 10.0.0.0/8 * VRF02 - Tenant B * Subnet 10.0.0.0/8 * Our own company C * Site 1 - HQ * prefix 10.0.0.0/16 * Site 2 - Azure * vnet 1 * prefix 172.16.0.0/12 ### To explain what's going on **Customer A** is a typical scenario, they have a couple of sites with unique prefixes (including an azure 'site'). The only thing to note is that we can have more customers that use overlapping prefixes. So this 'routing domain' is in this case limited to one particular customer. All prefixes within that customer/routing domain are unique. **Customer B** represents a campus. We provide some more advanced services at campuses. Like we give tenants the ability to choose their own subnets, by providing them with their own VRF. These VRFs are scoped to this particular tenant, at this particular campus. **Customer C** represents our own company (we do our own networking). There's nothing weird here, it's like Customer A. ### Problem The only way to model these different routing domains in Netbox is by using VRFs (?). But then it's relatively easy to loose track of which VRF represents which routing domain. We'd have to resort to a fairly complex naming scheme which isn't ideal for this many different customers. Not to mention we are modeling something as being a VRF that isn't an actual VRF. For example, this obviously happens without using VRFs to seperate the two customer routing domains. ![image](https://user-images.githubusercontent.com/36697826/127980349-c3b0899c-2719-4009-9794-b1281b22cbde.png) ### Conclusion I'd like to hear any suggestions on how to model this scenario in Netbox. But it does raise the question whether Netbox currently supports a Service Provider use case I'd be happy to answer any questions
adam commented 2025-12-29 19:24:31 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 4, 2021):

The only way to model these different routing domains in Netbox is by using VRFs (?). But then it's relatively easy to loose track of which VRF represents which routing domain.

I'm afraid I don't follow. VRFs are not a concept unique to NetBox: They are well-defined constructs that can be employed to manage separate L3 routing domains on a shared infrastructure (using MPLS/VPN, for instance). Each VRF is a separate routing table, and routes can be exchanged among VRFs using route targets (which can also be modeled in NetBox).

If each customer has its own routing domain, each should get its own VRF.

We'd have to resort to a fairly complex naming scheme which isn't ideal for this many different customers.

I'd have to disagree. Providers routinely manage many thousands of customers using VRFs. Each VRF can also be assigned to a tenant in NetBox, which may simplify things significantly.

@jeremystretch commented on GitHub (Aug 4, 2021): > The only way to model these different routing domains in Netbox is by using VRFs (?). But then it's relatively easy to loose track of which VRF represents which routing domain. I'm afraid I don't follow. VRFs are not a concept unique to NetBox: They are well-defined constructs that can be employed to manage separate L3 routing domains on a shared infrastructure (using MPLS/VPN, for instance). Each VRF is a separate routing table, and routes can be exchanged among VRFs using route targets (which can also be modeled in NetBox). If each customer has its own routing domain, each should get its own VRF. > We'd have to resort to a fairly complex naming scheme which isn't ideal for this many different customers. I'd have to disagree. Providers routinely manage many thousands of customers using VRFs. Each VRF can also be assigned to a tenant in NetBox, which may simplify things significantly.
adam commented 2025-12-29 19:24:32 +01:00
Author
Owner
Copy Link

@martijnremmen commented on GitHub (Aug 5, 2021):

We are not a "internet service provider" nor do we have a central platform to which all customers attach. We simply manage the LAN networks of multiple completely different companies. We're totally aware of the usecase of VRF's since we apply those at the large campus networks that some of our customers have.

The solution we're looking for is a way to use 1 single netbox instance for all our customers, instead of a separate netbox instance per customer (with their own campus VRF's). Currently we only run into the issue that prefixes of totally different customers overlap, but are combined within Netbox. The only way to separate them is to link them to "VRFs that don't really exist" since those customers do not share a network.

@martijnremmen commented on GitHub (Aug 5, 2021): We are not a "internet service provider" nor do we have a central platform to which all customers attach. We simply manage the LAN networks of multiple completely different companies. We're totally aware of the usecase of VRF's since we apply those at the large campus networks that some of our customers have. The solution we're looking for is a way to use 1 single netbox instance for all our customers, instead of a separate netbox instance per customer (with their own campus VRF's). Currently we only run into the issue that prefixes of totally different customers overlap, but are combined within Netbox. The only way to separate them is to link them to "VRFs that don't really exist" since those customers do not share a network.
adam commented 2025-12-29 19:24:32 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 5, 2021):

Again, a VRF is a discrete L3 routing domain, of which you have many. So, using a VRF for each customer makes sense. But that's tangential to the feature request you submitted.

The FR is to add a relationship from the VRF model to the site model, which doesn't make sense: Even where you have unique prefixes per site, they are presumably part of the same routing domain. (Why else would they be unique?)

This should be modeled in NetBox as a single VRF per customer (tenant), with each prefix being assigned to the appropriate site. This approach is supported today and requires no changes to the code.

@jeremystretch commented on GitHub (Aug 5, 2021): Again, a VRF is a discrete L3 routing domain, of which you have many. So, using a VRF for each customer makes sense. But that's tangential to the feature request you submitted. The FR is to add a relationship from the VRF model to the site model, which doesn't make sense: Even where you have unique prefixes per site, they are presumably part of the same routing domain. (Why else would they be unique?) This should be modeled in NetBox as a single VRF per customer (tenant), with each prefix being assigned to the appropriate site. This approach is supported today and requires no changes to the code.
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: 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#5122
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?