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

Remove unique rule of VRF-RD , Add Device relations #2305

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

Originally created by @Mabuchin on GitHub (Jan 22, 2019).

Environment

  • Python version: 3.6.5
  • NetBox version: 2.5.3

Proposed Functionality

There are several suggestions on vrf.

  • vrf should be unique for each device, not a network. Is it better to attach a relation key that links vrf to device?
  • There should also exist vrf which does not give RD, but currently RD is not nullable and must be unique. It is the right answer that must be unique, but we can not agree in the point that grant is essential. Why not make it nullable?

Use Case

Users can configure the same vrf as the actual network.
Especially by linking vrf to each device, it is possible to link with VRF belonging to the same vrf name and not setting RD

Database Changes

  • VRF Models
    • Add null=True from the rd field.
    • Add device relation key
        device = models.ForeignKey(
           to='dcim.Device',
          on_delete=models.PROTECT,
          related_name='devices'
       )

(Furthermore, if you associate vrf with interface, you need to check if it matches Device)

External Dependencies

None

Originally created by @Mabuchin on GitHub (Jan 22, 2019). <!-- NOTE: This form is only for proposing specific new features or enhancements. If you have a general idea or question, please post to our mailing list instead of opening an issue: https://groups.google.com/forum/#!forum/netbox-discuss NOTE: Due to an excessive backlog of feature requests, we are not currently accepting any proposals which significantly extend NetBox's feature scope. Please describe the environment in which you are running NetBox. Be sure that you are running an unmodified instance of the latest stable release before submitting a bug report. --> ### Environment * Python version: 3.6.5 * NetBox version: 2.5.3 <!-- Describe in detail the new functionality you are proposing. Include any specific changes to work flows, data models, or the user interface. --> ### Proposed Functionality There are several suggestions on vrf. - vrf should be unique for each device, not a network. Is it better to attach a relation key that links vrf to device? - There should also exist vrf which does not give RD, but currently RD is not nullable and must be unique. It is the right answer that must be unique, but we can not agree in the point that grant is essential. Why not make it nullable? <!-- Convey an example use case for your proposed feature. Write from the perspective of a NetBox user who would benefit from the proposed functionality and describe how. ---> ### Use Case Users can configure the same vrf as the actual network. Especially by linking vrf to each device, it is possible to link with VRF belonging to the same vrf name and not setting RD <!-- Note any changes to the database schema necessary to support the new feature. For example, does the proposal require adding a new model or field? (Not all new features require database changes.) ---> ### Database Changes - VRF Models - Add null=True from the rd field. - Add device relation key ```py device = models.ForeignKey( to='dcim.Device', on_delete=models.PROTECT, related_name='devices' ) ``` (Furthermore, if you associate vrf with interface, you need to check if it matches Device) <!-- List any new dependencies on external libraries or services that this new feature would introduce. For example, does the proposal require the installation of a new Python package? (Not all new features introduce new dependencies.) --> ### External Dependencies None
adam closed this issue 2025-12-29 17:24:41 +01:00
adam commented 2025-12-29 17:24:41 +01:00
Author
Owner
Copy Link

@candlerb commented on GitHub (Jan 22, 2019):

vrf should be unique for each device, not a network.

In Netbox, a "VRF" is a namespace for IP addresses.

I do agree that RD should be nullable. You might want to create IP address namespaces (e.g. for private IPs in multiple sites) but have no need for RD tags.

However I don't think it's useful to VRF to Device, and it's certainly not true that "vrf should be unique for each device". I mean: it might be that a particular device sits in a cloud where all its interfaces are in the same VRF. But in general, each interface (or even sub-interface) could be in a different VRF. And that is already recorded, because each interface has one or more IP addresses, and those addresses are associated with a VRF.

@candlerb commented on GitHub (Jan 22, 2019): > vrf should be unique for each device, not a network. In Netbox, a "VRF" is a namespace for IP addresses. I do agree that RD should be nullable. You might want to create IP address namespaces (e.g. for private IPs in multiple sites) but have no need for RD tags. However I don't think it's useful to VRF to Device, and it's certainly not true that "vrf should be unique for each device". I mean: it *might* be that a particular device sits in a cloud where all its interfaces are in the same VRF. But in general, each interface (or even sub-interface) could be in a different VRF. And that is already recorded, because each interface has one or more IP addresses, and those addresses are associated with a VRF.
adam commented 2025-12-29 17:24:41 +01:00
Author
Owner
Copy Link

@Mabuchin commented on GitHub (Jan 22, 2019):

There seems to be the following cases as a reason for linking vrf to device.

  • vrf-lite: The same vrf-name exists on different devices in the same network space, but each one is unique and unique.

I agree that interface is linked to vrf.
but in addition, I think that it is able to create vrf for each device.

However, I'd like to focus on the proposal to make RD nullable rather than issue of vrf-device relation.

@Mabuchin commented on GitHub (Jan 22, 2019): There seems to be the following cases as a reason for linking vrf to device. - vrf-lite: The same vrf-name exists on different devices in the same network space, but each one is unique and unique. I agree that interface is linked to vrf. but in addition, I think that it is able to create vrf for each device. However, I'd like to focus on the proposal to make RD nullable rather than issue of vrf-device relation.
adam commented 2025-12-29 17:24:41 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 22, 2019):

vrf should be unique for each device, not a network.

A VRF is essentially a namespace for IP addressing; it has no relation to a particular device. A VRF may and usually does exist on many devices across a network. This is not a NetBox construct, it's just how VRFs work. Assigning a VRF to a specific device would not make sense. If this is your use case, NetBox is probably not the best solution.

There should also exist vrf which does not give RD, but currently RD is not nullable and must be unique.

Route distinguishers are used to associate routing advertisements with a particular VRF. Again, this is not specific to NetBox (see RFC 4364). It really sounds like you're trying to employ VRFs for some other purpose than what they were intended to model.

@jeremystretch commented on GitHub (Jan 22, 2019): > vrf should be unique for each device, not a network. A VRF is essentially a namespace for IP addressing; it has no relation to a particular device. A VRF may and usually does exist on many devices across a network. This is not a NetBox construct, it's just how VRFs work. Assigning a VRF to a specific device would not make sense. If this is your use case, NetBox is probably not the best solution. > There should also exist vrf which does not give RD, but currently RD is not nullable and must be unique. Route distinguishers are used to associate routing advertisements with a particular VRF. Again, this is not specific to NetBox (see [RFC 4364](https://tools.ietf.org/html/rfc4364)). It really sounds like you're trying to employ VRFs for some other purpose than what they were intended to model.
adam commented 2025-12-29 17:24:42 +01:00
Author
Owner
Copy Link

@candlerb commented on GitHub (Jan 22, 2019):

Before you close this: I'd support making RD nullable. As you say, a VRF is essentially a namespace for IP addressing; there are plenty of use cases where you want VRFs but you are not interested in RDs.

The current config requires you to allocate fake RDs, which is a bit pointless.

@candlerb commented on GitHub (Jan 22, 2019): Before you close this: I'd support making RD nullable. As you say, a VRF is essentially a namespace for IP addressing; there are plenty of use cases where you want VRFs but you are not interested in RDs. The current config requires you to allocate fake RDs, which is a bit pointless.
adam commented 2025-12-29 17:24:42 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 22, 2019):

As it is, this issue entails two different topics. I'm fine with someone opening a separate issue specifically regarding null RDs.

@jeremystretch commented on GitHub (Jan 22, 2019): As it is, this issue entails two different topics. I'm fine with someone opening a separate issue specifically regarding null RDs.
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#2305
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?