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

Allow multiple entries for VRF Route Distinguisher #983

New Issue
Closed
opened 2025-12-29 16:27:34 +01:00 by adam · 6 comments
adam commented 2025-12-29 16:27:34 +01:00
Owner
Copy Link

Originally created by @stuh84 on GitHub (May 23, 2017).

Issue type: Feature Request

I would like to have the ability to assign multiple route distinguishers to a VRF. This is a common-ish use case, as routes are imported/export from a VRF via the route target, the RD just guarantees uniqueness in the "global" VPNv4/6 table.

A good example of it's usage is with Route Reflectors that cannot use/understand BGP Add-Path, receiving the same prefix from multiple routers (eg a default route from multiple transit providers). Without distinct RDs, the route reflector applies standard BGP Best Path selection rules and advertises on the best route from it's perspective. This does not mean that the recipient of routes from the route reflector would have chosen the same route, potentially having a better IGP cost to the route which was "discarded" by the route reflector.

Having different RDs but the same route target makes the routes unique to the route reflector, and the recipient of routes (i.e. a PE router) can then evaluate the routes as to what is it's best path (and can process both routes due to a common route target).

There are other examples, and my current workplace uses multiple RDs for the same Customer VRF for other reasons, the above is the best way of getting the point across I think!

If there is a constraint on keeping RDs unique, then being able to have multiple options for Custom Fields that are not predefined (prepopulating every single RD in the network as a selection seems cumbersome), in a similar way to adding multiple interfaces to a device, would definitely help.

Originally created by @stuh84 on GitHub (May 23, 2017). ### Issue type: Feature Request I would like to have the ability to assign multiple route distinguishers to a VRF. This is a common-ish use case, as routes are imported/export from a VRF via the route target, the RD just guarantees uniqueness in the "global" VPNv4/6 table. A good example of it's usage is with Route Reflectors that cannot use/understand BGP Add-Path, receiving the same prefix from multiple routers (eg a default route from multiple transit providers). Without distinct RDs, the route reflector applies standard BGP Best Path selection rules and advertises on the best route from it's perspective. This does not mean that the recipient of routes from the route reflector would have chosen the same route, potentially having a better IGP cost to the route which was "discarded" by the route reflector. Having different RDs but the same route target makes the routes unique to the route reflector, and the recipient of routes (i.e. a PE router) can then evaluate the routes as to what is it's best path (and can process both routes due to a common route target). There are other examples, and my current workplace uses multiple RDs for the same Customer VRF for other reasons, the above is the best way of getting the point across I think! If there is a constraint on keeping RDs unique, then being able to have multiple options for Custom Fields that are not predefined (prepopulating every single RD in the network as a selection seems cumbersome), in a similar way to adding multiple interfaces to a device, would definitely help.
adam closed this issue 2025-12-29 16:27:34 +01:00
adam commented 2025-12-29 16:27:35 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (May 26, 2017):

How do you propose extending the data model to support this? The RD is currently a fixed field on the VRF model.

@jeremystretch commented on GitHub (May 26, 2017): How do you propose extending the data model to support this? The RD is currently a fixed [field on the VRF model](https://github.com/digitalocean/netbox/blob/develop/netbox/ipam/models.py#L85).
adam commented 2025-12-29 16:27:35 +01:00
Author
Owner
Copy Link

@stuh84 commented on GitHub (May 26, 2017):

As an idea, maybe rather than RD field changing to be non-unique, some form of "Associated RDs" area, with the query using the "primary" RD (i.e. the one the VRF is created with) to tie them together in PSQL

Something along the lines of
SELECT * FROM associated_rds WHERE master_rd like "%65001:1234%";

Fields I could imagine within the table (non-exhaustive) would be: -

assoc_rd text;
master_rd text;
on_device text (or with joins to the devices table);
assoc_rd_desc text;

I personally wouldn't look to associate prefixes and IPs to the "secondary" RDs, as otherwise that adds complexity for ensuring uniqueness within a VRF.

Really, the main use for it from our perspective is being able to search from the RD configured on a device (eg 192.0.2.1:1234, 192.0.2.15:1234), and find the VRF these are part of (eg 65001:1234)

Does that answer your question? Happy to provide any further info or rethink the suggestion if this isn't valid

@stuh84 commented on GitHub (May 26, 2017): As an idea, maybe rather than RD field changing to be non-unique, some form of "Associated RDs" area, with the query using the "primary" RD (i.e. the one the VRF is created with) to tie them together in PSQL Something along the lines of SELECT * FROM associated_rds WHERE master_rd like "%65001:1234%"; Fields I could imagine within the table (non-exhaustive) would be: - assoc_rd text; master_rd text; on_device text (or with joins to the devices table); assoc_rd_desc text; I personally wouldn't look to associate prefixes and IPs to the "secondary" RDs, as otherwise that adds complexity for ensuring uniqueness within a VRF. Really, the main use for it from our perspective is being able to search from the RD configured on a device (eg 192.0.2.1:1234, 192.0.2.15:1234), and find the VRF these are part of (eg 65001:1234) Does that answer your question? Happy to provide any further info or rethink the suggestion if this isn't valid
adam commented 2025-12-29 16:27:35 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (May 26, 2017):

Keep in mind that the VRF model is not specific to any particular device, and that only prefixes and IP addresses can be assigned to VRFs. It sounds like what you're doing is using discrete RDs per device, which cannot be modeled on the VRF object. These would need to be tied to their individual devices somehow, perhaps through the use of custom fields. Sorry I don't have a better answer for you.

@jeremystretch commented on GitHub (May 26, 2017): Keep in mind that the VRF model is not specific to any particular device, and that only prefixes and IP addresses can be assigned to VRFs. It sounds like what you're doing is using discrete RDs _per device_, which cannot be modeled on the VRF object. These would need to be tied to their individual devices somehow, perhaps through the use of custom fields. Sorry I don't have a better answer for you.
adam commented 2025-12-29 16:27:35 +01:00
Author
Owner
Copy Link

@stuh84 commented on GitHub (May 29, 2017):

From this perspective, yes it is essentially a per-device RD, but in another network I worked with, it was used for a "local" Internet VRF (i.e. Go out via the nearest Internet Edge Router when available).

Thanks for taking a look, I might look into a way of trying to rationalise the approach (and how we document it) a bit, as it does appear we are heading towards Netbox for our IPAM (with the push coming from myself). This is probably the only issue I can see for us adopting it, and maybe a bit of process/documentation can take care of it rather than any code changes.

@stuh84 commented on GitHub (May 29, 2017): From this perspective, yes it is essentially a per-device RD, but in another network I worked with, it was used for a "local" Internet VRF (i.e. Go out via the nearest Internet Edge Router when available). Thanks for taking a look, I might look into a way of trying to rationalise the approach (and how we document it) a bit, as it does appear we are heading towards Netbox for our IPAM (with the push coming from myself). This is probably the only issue I can see for us adopting it, and maybe a bit of process/documentation can take care of it rather than any code changes.
adam commented 2025-12-29 16:27:35 +01:00
Author
Owner
Copy Link

@itomkins commented on GitHub (Jan 21, 2019):

Can I request that the decision to close this request is re-visited please?
in a network with private "customer" VRFs and "service" VRFs it is a reasonable design to have a prefix exist in multiple different VRFs to enable IP routing between customer and service networks.

@itomkins commented on GitHub (Jan 21, 2019): Can I request that the decision to close this request is re-visited please? in a network with private "customer" VRFs and "service" VRFs it is a reasonable design to have a prefix exist in multiple different VRFs to enable IP routing between customer and service networks.
adam commented 2025-12-29 16:27:35 +01:00
Author
Owner
Copy Link

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

@itomkins What you're describing is route import/export, a bit different in concept than the issue described here, but see #259.

@jeremystretch commented on GitHub (Jan 22, 2019): @itomkins What you're describing is route import/export, a bit different in concept than the issue described here, but see #259.
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#983
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?