starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-02-26 02:35:12 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Enhance VRF export/import RT modeling #7810

New Issue
Open
opened 2025-12-29 20:28:30 +01:00 by adam · 16 comments
adam commented 2025-12-29 20:28:30 +01:00
Owner
Copy Link

Originally created by @dmulyalin on GitHub (Mar 30, 2023).

NetBox version

v3.4.6

Feature type

New functionality

Proposed functionality

Add support to document Route-Target export and imports for VRF on a per-device basis by adding new VRF Export/Import model

Use case

Documetn route-leaking between different VRF by adding new table that will link RT, VRF and devices together allowing to document which devices in which VRF export and import which RT.

Route leaking using route-targets is a common approach in networking to implement routing between VRF which is known as hard to keep track of. Adding new capability to Netbox will greatly enhance its offering on VRF documentation side.

Current models does not allow to capture information about what devices in which VRF import and export what route-targets. Current capabilities only allow to capture information on what RT imported and exported for given VRF, while in real world this always tied to actual network devices.

Database changes

New model with this fields:
id
vrf - refers to existing VRF record
rt - refers to existing RT record
device - refers to existing device record
action - value of "import" or "export"

External dependencies

Nill

Originally created by @dmulyalin on GitHub (Mar 30, 2023). ### NetBox version v3.4.6 ### Feature type New functionality ### Proposed functionality Add support to document Route-Target export and imports for VRF on a per-device basis by adding new VRF Export/Import model ### Use case Documetn route-leaking between different VRF by adding new table that will link RT, VRF and devices together allowing to document which devices in which VRF export and import which RT. Route leaking using route-targets is a common approach in networking to implement routing between VRF which is known as hard to keep track of. Adding new capability to Netbox will greatly enhance its offering on VRF documentation side. Current models does not allow to capture information about what devices in which VRF import and export what route-targets. Current capabilities only allow to capture information on what RT imported and exported for given VRF, while in real world this always tied to actual network devices. ### Database changes New model with this fields: id vrf - refers to existing VRF record rt - refers to existing RT record device - refers to existing device record action - value of "import" or "export" ### External dependencies Nill
adam added the type: featurenetboxneeds milestonestatus: backlogcomplexity: high labels 2025-12-29 20:28:31 +01:00
adam commented 2025-12-29 20:28:31 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Mar 30, 2023):

You can already do this directly on VRF's. You can add additional import targets onto a VRF.

Now, granted this would be difficult to use to properly generate configurations per device as some devices may import that additional route-target and some may not. Perhaps it would make more sense to make the VRF model as a whole assigned per-device but that also introduces a number of difficulties.

@DanSheps commented on GitHub (Mar 30, 2023): You can already do this directly on VRF's. You can add additional import targets onto a VRF. Now, granted this would be difficult to use to properly generate configurations per device as some devices may import that additional route-target and some may not. Perhaps it would make more sense to make the VRF model as a whole assigned per-device but that also introduces a number of difficulties.
adam commented 2025-12-29 20:28:32 +01:00
Author
Owner
Copy Link

@dmulyalin commented on GitHub (Mar 30, 2023):

Adding route targets to vrf is great, but it does not capture which device exports or imports those route targets. Adding new table to hold those dependencies is what i hope could be the simplest way of doing it.

@dmulyalin commented on GitHub (Mar 30, 2023): Adding route targets to vrf is great, but it does not capture which device exports or imports those route targets. Adding new table to hold those dependencies is what i hope could be the simplest way of doing it.
adam commented 2025-12-29 20:28:32 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Mar 30, 2023):

VRFs are associated with devices via interface assignment. Each interface can be assigned to a VRF.

@jeremystretch commented on GitHub (Mar 30, 2023): VRFs are associated with devices via interface assignment. Each interface can be assigned to a VRF.
adam commented 2025-12-29 20:28:32 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Mar 30, 2023):

Yeah, I think the issue is here, with the way it is modelled in Netbox vs real life.

Like, you could have 3 devices, device A, device B, device C. Lets say they are all ASR-1001-X's for simplicity.

On A you could have:

vrf def WAN
  rd 1:1
  address-family ipv4 unicast
    route-target both 1:1
    route-target import 1:5453

On B you could have:

vrf def B
  rd 1:5453
  address-family ipv4 unicast
    route-target both 1:5453
    route-target import 1:1

On C you could have:

vrf def B
  rd 1:5453
  address-family ipv4 unicast
    route-target both 1:5453

So like, on C you aren't importing 1:1 but on B you are. It isn't possible to model the state of the vrf itself on each device currently in NetBox and you would have to use config contexts or intuit it currently.

I think this FR is proposing to more or less move the Route Target assignments to a device M2M model. If I was doing this, I would do it this way:

Models:

VRF:
  name = string
  rd = string

RouteTarget:
  route-target = string

VRFDefinition:
  vrf = VRF
  route_targets = [RouteTarget]
  device = [Device]

Interface:
  ...
  vrf = VRF

It would make the model slightly more complex but it would allow proper configuration generation.

@DanSheps commented on GitHub (Mar 30, 2023): Yeah, I think the issue is here, with the way it is modelled in Netbox vs real life. Like, you could have 3 devices, device A, device B, device C. Lets say they are all ASR-1001-X's for simplicity. On A you could have: ``` vrf def WAN rd 1:1 address-family ipv4 unicast route-target both 1:1 route-target import 1:5453 ``` On B you could have: ``` vrf def B rd 1:5453 address-family ipv4 unicast route-target both 1:5453 route-target import 1:1 ``` On C you could have: ``` vrf def B rd 1:5453 address-family ipv4 unicast route-target both 1:5453 ``` So like, on C you aren't importing 1:1 but on B you are. It isn't possible to model the state of the vrf itself on each device currently in NetBox and you would have to use config contexts or intuit it currently. I think this FR is proposing to more or less move the Route Target assignments to a device M2M model. If I was doing this, I would do it this way: Models: ``` VRF: name = string rd = string RouteTarget: route-target = string VRFDefinition: vrf = VRF route_targets = [RouteTarget] device = [Device] Interface: ... vrf = VRF ``` It would make the model slightly more complex but it would allow proper configuration generation.
adam commented 2025-12-29 20:28:32 +01:00
Author
Owner
Copy Link

@dmulyalin commented on GitHub (Mar 30, 2023):

@DanSheps precisely yes, this is the use case I was trying to document in Netbox but apart from using config contexts or change vrf to per-device by encoding device name in vrf name, was not able to come up with any other workarounds.

@jeremystretch assigning interfaces to VRF is great and very representative of how real networks work. Current VRF and RT modeling approach, however, does not capture the relationship between RT and VRF on a per-device basis, which is how it is done in the networks. In fact, VRF name is having device local significance, and (as you of course aware) RT control the routing between VRFs on different devices.

I was hoping that addint new vpn_import_export model would be able to serve us to capture RT usage for VRFs on a per-device basis. At the end it would be good to end up with this table that user can interface with:

id vrf device rt action description
1 FOO router-1 1:123 import Import spoke routes
2 BAR router-2 1:234 export Export spoke routes
3 FOOBAR router-3 1:234 both HUB, receive all routes from all spokes

Same vpn_import_export can be used for L2VPN as well, or any other future entities that rely on route-targets for NLRI exchange. Moreover, having dedicated vpn_import_export model likely would allow to remove relationship between RT and VRF as it is not fully representative of how real networks implemented.

@dmulyalin commented on GitHub (Mar 30, 2023): @DanSheps precisely yes, this is the use case I was trying to document in Netbox but apart from using config contexts or change vrf to per-device by encoding device name in vrf name, was not able to come up with any other workarounds. @jeremystretch assigning interfaces to VRF is great and very representative of how real networks work. Current VRF and RT modeling approach, however, does not capture the relationship between RT and VRF on a per-device basis, which is how it is done in the networks. In fact, VRF name is having device local significance, and (as you of course aware) RT control the routing between VRFs on different devices. I was hoping that addint new `vpn_import_export` model would be able to serve us to capture RT usage for VRFs on a per-device basis. At the end it would be good to end up with this table that user can interface with: | id | vrf | device | rt | action | description | |---|---|---|---|---|---| | 1 | FOO | router-1 | 1:123 | import | Import spoke routes | | 2 | BAR | router-2 | 1:234 | export | Export spoke routes | | 3 | FOOBAR | router-3 | 1:234 | both | HUB, receive all routes from all spokes | Same `vpn_import_export` can be used for L2VPN as well, or any other future entities that rely on route-targets for NLRI exchange. Moreover, having dedicated `vpn_import_export` model likely would allow to remove relationship between RT and VRF as it is not fully representative of how real networks implemented.
adam commented 2025-12-29 20:28:33 +01:00
Author
Owner
Copy Link

@DetunizedGravity commented on GitHub (Jun 16, 2023):

Yeah, I think the issue is here, with the way it is modelled in Netbox vs real life.

Like, you could have 3 devices, device A, device B, device C. Lets say they are all ASR-1001-X's for simplicity.

On A you could have:

vrf def WAN
  rd 1:1
  address-family ipv4 unicast
    route-target both 1:1
    route-target import 1:5453

On B you could have:

vrf def B
  rd 1:5453
  address-family ipv4 unicast
    route-target both 1:5453
    route-target import 1:1

On C you could have:

vrf def B
  rd 1:5453
  address-family ipv4 unicast
    route-target both 1:5453

So like, on C you aren't importing 1:1 but on B you are. It isn't possible to model the state of the vrf itself on each device currently in NetBox and you would have to use config contexts or intuit it currently.

I think this FR is proposing to more or less move the Route Target assignments to a device M2M model. If I was doing this, I would do it this way:

Models:

VRF:
  name = string
  rd = string

RouteTarget:
  route-target = string

VRFDefinition:
  vrf = VRF
  route_targets = [RouteTarget]
  device = [Device]

Interface:
  ...
  vrf = VRF

It would make the model slightly more complex but it would allow proper configuration generation.

I would go as far as to say that if one wants to truly describe the real world, vrf names need not be unique, since they are local to a device. The actual primary key for VRF should be (device id, name). Dunno if Netbox and its foundations allow that, though.

@DetunizedGravity commented on GitHub (Jun 16, 2023): > Yeah, I think the issue is here, with the way it is modelled in Netbox vs real life. > > Like, you could have 3 devices, device A, device B, device C. Lets say they are all ASR-1001-X's for simplicity. > > On A you could have: > > ``` > vrf def WAN > rd 1:1 > address-family ipv4 unicast > route-target both 1:1 > route-target import 1:5453 > ``` > > On B you could have: > > ``` > vrf def B > rd 1:5453 > address-family ipv4 unicast > route-target both 1:5453 > route-target import 1:1 > ``` > > On C you could have: > > ``` > vrf def B > rd 1:5453 > address-family ipv4 unicast > route-target both 1:5453 > ``` > > So like, on C you aren't importing 1:1 but on B you are. It isn't possible to model the state of the vrf itself on each device currently in NetBox and you would have to use config contexts or intuit it currently. > > I think this FR is proposing to more or less move the Route Target assignments to a device M2M model. If I was doing this, I would do it this way: > > Models: > > ``` > VRF: > name = string > rd = string > > RouteTarget: > route-target = string > > VRFDefinition: > vrf = VRF > route_targets = [RouteTarget] > device = [Device] > > Interface: > ... > vrf = VRF > ``` > > It would make the model slightly more complex but it would allow proper configuration generation. I would go as far as to say that if one wants to truly describe the real world, vrf names need not be unique, since they are local to a device. The actual primary key for VRF should be (device id, name). Dunno if Netbox and its foundations allow that, though.
adam commented 2025-12-29 20:28:33 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Sep 15, 2023):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Sep 15, 2023): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. **Do not** attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 20:28:33 +01:00
Author
Owner
Copy Link

@davidgwatkins commented on GitHub (Sep 30, 2023):

Stumbled across this issue searching for per-device route distinguisher support. I really like VRFDefinition model idea! Would propose also moving the VRF RD into that model to allow unique RDs per PE (Type 1 RD per RFC 4364).

Another argument for more granular RT control: CSPs often reuse one VRF globally with multiple regional routing domains and associated ASNs / RTs. When I modeled this in the past, I used a Custom Field on the VRF model with an assigned number field and varied the admin fields for both RD and RT using Region-based Config Contexts. The VRFDefinition model would eliminate the need for that workaround and ambiguity.

@davidgwatkins commented on GitHub (Sep 30, 2023): Stumbled across this issue searching for per-device route distinguisher support. I really like `VRFDefinition` model idea! Would propose also moving the VRF RD into that model to allow unique RDs per PE (Type 1 RD per RFC 4364). Another argument for more granular RT control: CSPs often reuse one VRF globally with multiple regional routing domains and associated ASNs / RTs. When I modeled this in the past, I used a Custom Field on the VRF model with an assigned number field and varied the admin fields for both RD and RT using Region-based Config Contexts. The `VRFDefinition` model would eliminate the need for that workaround and ambiguity.
adam commented 2025-12-29 20:28:34 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Dec 5, 2023):

I came across this searching for something else. Let me model out the ERD in mermaid I would be willing to take this on in 4.0 or later.

@DanSheps commented on GitHub (Dec 5, 2023): I came across this searching for something else. Let me model out the ERD in mermaid I would be willing to take this on in 4.0 or later.
adam commented 2025-12-29 20:28:34 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Dec 6, 2023):

If we could get some commentns on this proposed model that would be great.

@DanSheps commented on GitHub (Dec 6, 2023): [![](https://mermaid.ink/img/pako:eNqdlM1uwjAMx1_Fyhl4gJ4R0oQ2IcZ26iUiLrVGE-S6aIj23ZekRe0K-4Bekrq_-uNvJ2e1dQZVopDnpHesi9SCf-Z4pC3CuX0LD1kBMrBaQqpWTIXmEyzxlKoeKYXJ7sDqAsFTL2F1WedrCAZfBjOyJORsCYvg9H298OjFCIx7HTaX_5p2CdTjWb0t-7S8pxsYGw95Z2tXCYKhUryVyhx5lEgENpp3KI8lxMHBVFoPMeYmx9YtdFYyaIUyugrucx9IdV_4gBw5a0VfdyqXOR1A3FiUtlFxFG7i1639YQa-N3dUzZMV5EzfPW-XSn6vwwfpR6d2s5k7j_RLINflLWFrN516etjqBKg4OJb_8_g54Ltz1fyRRofVdcR6fQZIb4xR61he9z21aqIK5EKT8Wc7qpoqybHwvUr81mj-CPo0ntOVuNeT3apEuMKJqg5GC3a3gUoyvS-9FQ2J4-f2soh3RvMFXINUYA?type=png)](https://mermaid.live/edit#pako:eNqdlM1uwjAMx1_Fyhl4gJ4R0oQ2IcZ26iUiLrVGE-S6aIj23ZekRe0K-4Bekrq_-uNvJ2e1dQZVopDnpHesi9SCf-Z4pC3CuX0LD1kBMrBaQqpWTIXmEyzxlKoeKYXJ7sDqAsFTL2F1WedrCAZfBjOyJORsCYvg9H298OjFCIx7HTaX_5p2CdTjWb0t-7S8pxsYGw95Z2tXCYKhUryVyhx5lEgENpp3KI8lxMHBVFoPMeYmx9YtdFYyaIUyugrucx9IdV_4gBw5a0VfdyqXOR1A3FiUtlFxFG7i1639YQa-N3dUzZMV5EzfPW-XSn6vwwfpR6d2s5k7j_RLINflLWFrN516etjqBKg4OJb_8_g54Ltz1fyRRofVdcR6fQZIb4xR61he9z21aqIK5EKT8Wc7qpoqybHwvUr81mj-CPo0ntOVuNeT3apEuMKJqg5GC3a3gUoyvS-9FQ2J4-f2soh3RvMFXINUYA) If we could get some commentns on this proposed model that would be great.
adam commented 2025-12-29 20:28:34 +01:00
Author
Owner
Copy Link

@dmulyalin commented on GitHub (Dec 6, 2023):

Am i reading right that vrfdefinition gonna be tied to device? If so, rd could be moved to vrfdefinition model as well, as rd always of device local significance e.g. ot uncommon rd could encode device loopback ip to be device specific.

@dmulyalin commented on GitHub (Dec 6, 2023): Am i reading right that vrfdefinition gonna be tied to device? If so, rd could be moved to vrfdefinition model as well, as rd always of device local significance e.g. ot uncommon rd could encode device loopback ip to be device specific.
adam commented 2025-12-29 20:28:34 +01:00
Author
Owner
Copy Link

@dmulyalin commented on GitHub (Dec 6, 2023):

Also think interface relationship with vrf need to be with vrfdefinition model if vrfdefinition represents an instance of the vrf. In that case the original vrf model does not needed? Could it be rebuild as say l3domain model, representing routing contingency across multiple vrfs?

@dmulyalin commented on GitHub (Dec 6, 2023): Also think interface relationship with vrf need to be with vrfdefinition model if vrfdefinition represents an instance of the vrf. In that case the original vrf model does not needed? Could it be rebuild as say l3domain model, representing routing contingency across multiple vrfs?
adam commented 2025-12-29 20:28:34 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Dec 11, 2023):

Also think interface relationship with vrf need to be with vrfdefinition model if vrfdefinition represents an instance of the vrf. In that case the original vrf model does not needed? Could it be rebuild as say l3domain model, representing routing contingency across multiple vrfs?

While the VRF definition is locally significant, the interface could either tie to VRF or the VRFDefinition. This could be something looked at for future iterations as well.

Also think interface relationship with vrf need to be with vrfdefinition model if vrfdefinition represents an instance of the vrf. In that case the original vrf model does not needed? Could it be rebuild as say l3domain model, representing routing contingency across multiple vrfs?

VRF is tied to other things within netbox beyond those modelled here. This is a simple snippet of the relevant relationships for this specific FR. So, no, we could not rebuild it.

L3 Domain would need to be a separate proposal and has already been investigated and didn't go anywhere.

@DanSheps commented on GitHub (Dec 11, 2023): > Also think interface relationship with vrf need to be with vrfdefinition model if vrfdefinition represents an instance of the vrf. In that case the original vrf model does not needed? Could it be rebuild as say l3domain model, representing routing contingency across multiple vrfs? While the VRF definition is locally significant, the interface could either tie to VRF or the VRFDefinition. This could be something looked at for future iterations as well. > Also think interface relationship with vrf need to be with vrfdefinition model if vrfdefinition represents an instance of the vrf. In that case the original vrf model does not needed? Could it be rebuild as say l3domain model, representing routing contingency across multiple vrfs? VRF is tied to other things within netbox beyond those modelled here. This is a simple snippet of the relevant relationships for this specific FR. So, no, we could not rebuild it. L3 Domain would need to be a separate proposal and has already been investigated and didn't go anywhere.
adam commented 2025-12-29 20:28:34 +01:00
Author
Owner
Copy Link

@ajackson79 commented on GitHub (Sep 6, 2024):

Adding my voice to the list. We use a unique RD per device so routes are unique across the network. We would like to model that in Netbox. Having device specific RD and RTs would be ideal for flexibility.

@ajackson79 commented on GitHub (Sep 6, 2024): Adding my voice to the list. We use a unique RD per device so routes are unique across the network. We would like to model that in Netbox. Having device specific RD and RTs would be ideal for flexibility.
adam commented 2025-12-29 20:28:35 +01:00
Author
Owner
Copy Link

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

I think this might be a good candidate for 4.2

@DanSheps commented on GitHub (Sep 9, 2024): I think this might be a good candidate for 4.2
adam commented 2025-12-29 20:28:35 +01:00
Author
Owner
Copy Link

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

I think this might be a good candidate for 4.2

Yes I agree this could be a great candidate for 4.2 and the SP focus. We would then not have to use config contexts to rewrite RD and RT per devices.

@ajackson79 commented on GitHub (Oct 2, 2024): > I think this might be a good candidate for 4.2 Yes I agree this could be a great candidate for 4.2 and the SP focus. We would then not have to use config contexts to rewrite RD and RT per devices.
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 complexity: high needs milestone netbox status: backlog 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#7810
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?