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

VRF route target import/export tracking #191

New Issue
Closed
opened 2025-12-29 16:19:08 +01:00 by adam · 13 comments
adam commented 2025-12-29 16:19:08 +01:00
Owner
Copy Link

Originally created by @LukeDRussell on GitHub (Jul 11, 2016).

Originally assigned to: @jeremystretch on GitHub.

After #43 we would like to be able to stop duplicate addresses across different VRFs, in an arbitrary manner.

Some of our customers have multiple VRFs for security reasons but they shouldn't be NATing between VRFs. We also have some customers wanting to talk to each other directly (not via the internet). We would also want to reserve some RFC1918 to never overlap with any VRF for certain UC and network services.

I imagine there would be some sort of linking of multiple VRFs to a "address space", with an option to prevent duplicate IPs within the namespace. I'm seeing "address space" as being seperate from "tenant".

Originally created by @LukeDRussell on GitHub (Jul 11, 2016). Originally assigned to: @jeremystretch on GitHub. After #43 we would like to be able to stop duplicate addresses across different VRFs, in an arbitrary manner. Some of our customers have multiple VRFs for security reasons but they shouldn't be NATing between VRFs. We also have some customers wanting to talk to each other directly (not via the internet). We would also want to reserve some RFC1918 to never overlap with any VRF for certain UC and network services. I imagine there would be some sort of linking of multiple VRFs to a "address space", with an option to prevent duplicate IPs within the namespace. I'm seeing "address space" as being seperate from "tenant".
adam added the status: acceptedtype: feature labels 2025-12-29 16:19:08 +01:00
adam closed this issue 2025-12-29 16:19:08 +01:00
adam commented 2025-12-29 16:19:08 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jul 11, 2016):

This is probably best served by introducing import/export tracking among VRFs. This is something I've had in the back of my mind for a while as a long-term goal. Not sure what the timeline would be.

@jeremystretch commented on GitHub (Jul 11, 2016): This is probably best served by introducing import/export tracking among VRFs. This is something I've had in the back of my mind for a while as a long-term goal. Not sure what the timeline would be.
adam commented 2025-12-29 16:19:08 +01:00
Author
Owner
Copy Link

@LukeDRussell commented on GitHub (Jul 11, 2016):

Yeh that fits with the technology too. In our case it's all done via firewalls instead of MPLS import/export, but it's the same concept.

It's probably not a common use case, I just wanted to get it on the pipeline.

@LukeDRussell commented on GitHub (Jul 11, 2016): Yeh that fits with the technology too. In our case it's all done via firewalls instead of MPLS import/export, but it's the same concept. It's probably not a common use case, I just wanted to get it on the pipeline.
adam commented 2025-12-29 16:19:08 +01:00
Author
Owner
Copy Link

@bdlamprecht commented on GitHub (Oct 23, 2017):

I'd like to see this get added as well... (so bump?)

I'm trying to model the VRF RT (or "route-target") into the existing VRF RD (or "route-distinguisher"), but it doesn't work very well and I end up doing a lot of hacks to make it work.

I don't think it would be too complex to implement, but don't want to assume things as I tend to not fully conceptualize how things are modeled and how those changes impact the DB and overall application performance.

@bdlamprecht commented on GitHub (Oct 23, 2017): I'd like to see this get added as well... (so bump?) I'm trying to model the VRF `RT` (or "route-target") into the existing VRF `RD` (or "route-distinguisher"), but it doesn't work very well and I end up doing a lot of hacks to make it work. I don't think it would be _too_ complex to implement, but don't want to assume things as I tend to not fully conceptualize how things are modeled and how those changes impact the DB and overall application performance.
adam commented 2025-12-29 16:19:09 +01:00
Author
Owner
Copy Link

@nward commented on GitHub (Jan 30, 2018):

This is a tricky one, as there are instances where you have a VRF or routing instance configured which has different import/exports than other routers. Or, you might have two VRFs on one router with very similar exports and imports, but maybe a couple of differences.

I generally dislike the idea of modelling a network-wide "VRF" or IPVPN or whatever construct. The only way to accurately model it is to model:

  • VRFs per router, with import/export lists of RTs, with notes against each RT (i.e. "except community x").
  • List of RTs associated through import/exports with VRFs above
  • List of RDs associated to VRFs above

At that point you can inspect a VRF on a router and see what other VRFs on the network it interacts with.

Right now VRFs have a network wide "RD" which is how I got to this issue - on many (most modern?) networks, RD is unique per VRF per router.

@nward commented on GitHub (Jan 30, 2018): This is a tricky one, as there are instances where you have a VRF or routing instance configured which has different import/exports than other routers. Or, you might have two VRFs on one router with very similar exports and imports, but maybe a couple of differences. I generally dislike the idea of modelling a network-wide "VRF" or IPVPN or whatever construct. The only way to accurately model it is to model: - VRFs per router, with import/export lists of RTs, with notes against each RT (i.e. "except community x"). - List of RTs associated through import/exports with VRFs above - List of RDs associated to VRFs above At that point you can inspect a VRF on a router and see what other VRFs on the network it interacts with. Right now VRFs have a network wide "RD" which is how I got to this issue - on many (most modern?) networks, RD is unique per VRF per router.
adam commented 2025-12-29 16:19:09 +01:00
Author
Owner
Copy Link

@afics commented on GitHub (Feb 23, 2018):

@nward We use L3VPN extensively, so we would need a way to tie a VRF to a group of routers.
In our network VRF import/export is configured the same on all of those. On each of these routers only the VRFs which are actually used on a specific router are configured.

To summarize, what we'd need are per group-of-routers VRFs and VRF import/export information. We could then use that to automatically provision required VRFs to a router if an L3 interface with a prefix in a certain VRF is added to it.

@afics commented on GitHub (Feb 23, 2018): @nward We use L3VPN extensively, so we would need a way to tie a VRF to a group of routers. In our network VRF import/export is configured the same on all of those. On each of these routers only the VRFs which are actually used on a specific router are configured. To summarize, what we'd need are per group-of-routers VRFs and VRF import/export information. We could then use that to automatically provision required VRFs to a router if an L3 interface with a prefix in a certain VRF is added to it.
adam commented 2025-12-29 16:19:09 +01:00
Author
Owner
Copy Link

@steffann commented on GitHub (Mar 4, 2020):

This is probably best served by introducing import/export tracking among VRFs. This is something I've had in the back of my mind for a while as a long-term goal.

What ideas do you already have? A per-prefix list of "also exported to VRF x", or more on a "VRF y is imported into VRF z" level? I wouldn't mind spending some brain cycles on this…

@steffann commented on GitHub (Mar 4, 2020): > This is probably best served by introducing import/export tracking among VRFs. This is something I've had in the back of my mind for a while as a long-term goal. What ideas do you already have? A per-prefix list of "also exported to VRF x", or more on a "VRF y is imported into VRF z" level? I wouldn't mind spending some brain cycles on this…
adam commented 2025-12-29 16:19:10 +01:00
Author
Owner
Copy Link

@nward commented on GitHub (Mar 5, 2020):

Having thought more about this from last time I posted on the subject, I don't think that Netbox can or should model VRF import/export stuff. Different vendors and options and so on really makes this too complex a problem to solve, and there will always be deficiencies.

I think the original poster's suggestion is reasonable. I (and others I know) use the term "addressing domain" to describe an area of a network where addresses cannot overlap. I think that to achieve this, we could re-purpose netbox's "VRF" concept as an "Addressing Domain" and remove "RD" and other parameters from the VRF model.

Then, we should add in links between Addressing Domains, for example:

  • 3 domains - A, B, C
  • "Link" between A and B preventing overlapping prefixes/addresses between these two domains
  • "Link" between B and C preventing overlapping prefixes/addresses between these two domains
  • A and C can have overlapping addresses, as they are not linked

I think this is the most flexible, and doesn't impose any limitations or network specific concepts about what a "VRF" is. It means users can define however many addressing domains they like, including zero.

@nward commented on GitHub (Mar 5, 2020): Having thought more about this from last time I posted on the subject, I don't think that Netbox can or should model VRF import/export stuff. Different vendors and options and so on really makes this too complex a problem to solve, and there will always be deficiencies. I think the original poster's suggestion is reasonable. I (and others I know) use the term "addressing domain" to describe an area of a network where addresses cannot overlap. I think that to achieve this, we could re-purpose netbox's "VRF" concept as an "Addressing Domain" and remove "RD" and other parameters from the VRF model. Then, we should add in links between Addressing Domains, for example: - 3 domains - A, B, C - "Link" between A and B preventing overlapping prefixes/addresses between these two domains - "Link" between B and C preventing overlapping prefixes/addresses between these two domains - A and C can have overlapping addresses, as they are not linked I think this is the most flexible, and doesn't impose any limitations or network specific concepts about what a "VRF" is. It means users can define however many addressing domains they like, including zero.
adam commented 2025-12-29 16:19:10 +01:00
Author
Owner
Copy Link

@steffann commented on GitHub (Mar 5, 2020):

I think the original poster's suggestion is reasonable. I (and others I know) use the term "addressing domain" to describe an area of a network where addresses cannot overlap. I think that to achieve this, we could re-purpose netbox's "VRF" concept as an "Addressing Domain" and remove "RD" and other parameters from the VRF model.

Euhm, No, we actively use the VRF information in NetBox. And I'm sure others do as well.

@steffann commented on GitHub (Mar 5, 2020): > I think the original poster's suggestion is reasonable. I (and others I know) use the term "addressing domain" to describe an area of a network where addresses cannot overlap. I think that to achieve this, we could re-purpose netbox's "VRF" concept as an "Addressing Domain" and remove "RD" and other parameters from the VRF model. Euhm, No, we actively use the VRF information in NetBox. And I'm sure others do as well.
adam commented 2025-12-29 16:19:10 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Mar 5, 2020):

The scope of this issue is the implementation of route target modeling to inform the import/export of prefixes among VRFs. This is all well-defined in RFC 4364 so the implementation should be fairly straightforward.

@jeremystretch commented on GitHub (Mar 5, 2020): The scope of this issue is the implementation of route target modeling to inform the import/export of prefixes among VRFs. This is all well-defined in RFC 4364 so the implementation should be fairly straightforward.
adam commented 2025-12-29 16:19:11 +01:00
Author
Owner
Copy Link

@LukeDRussell commented on GitHub (Mar 5, 2020):

Will that include the functionality to prevent overlapping addresses across VRFs?

An arbitrary “VRF group” might be another seperate option. IIRC @jeremystretch you changed the title of this Issue way back.

It’s simple enough to implement a report that would show overlaps, but it wouldn’t prevent users creating those prefixes in the first place.

@LukeDRussell commented on GitHub (Mar 5, 2020): Will that include the functionality to prevent overlapping addresses across VRFs? An arbitrary “VRF group” might be another seperate option. IIRC @jeremystretch you changed the title of this Issue way back. It’s simple enough to implement a report that would show overlaps, but it wouldn’t prevent users creating those prefixes in the first place.
adam commented 2025-12-29 16:19:11 +01:00
Author
Owner
Copy Link

@jsenecal commented on GitHub (Jun 2, 2020):

@jeremystretch I could start working on this and submit a PR if nobody has already started working on this.

I had planned to map what VRFs are leaked into another and augment the uniqueness validation to what has been mentionned earlier in this issue.

Do we need/want to track the directionality of the leaking? ie. Import vs Export ?

@jsenecal commented on GitHub (Jun 2, 2020): @jeremystretch I could start working on this and submit a PR if nobody has already started working on this. I had planned to map what VRFs are leaked into another and augment the uniqueness validation to what has been mentionned earlier in this issue. Do we need/want to track the directionality of the leaking? ie. Import vs Export ?
adam commented 2025-12-29 16:19:11 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 23, 2020):

Seems like we jumped the gun a bit by tagging this for v2.10 without having a firm model in place. Below is a quick draft of my proposal:

class RouteTarget(ChangeLoggedModel):
    name = models.CharField(
        max_length=??,
        unique=True
    )
    description = models.CharField(...)

    class Meta:
        ordering = ['name']


class VRF:
    ...
    import_targets = models.ManyToManyField(
        to='ipam.RouteTarget',
        related_name='import_for_vrfs',
        blank=True
    )
    export_targets = models.ManyToManyField(
        to='ipam.RouteTarget',
        related_name='export_for_vrfs',
        blank=True
    )

This adds a new RouteTarget model and provides two relationships from VRF to it (for import and export). It then becomes possible to query all the prefixes or IP addresses that one would expect to be visible by any given VRF:

vrf = VRF.objects.get(name='MyVRF')
Prefix.objects.filter(
    Q(vrf=vrf) |
    Q(vrf__import_targets__in=vrf.export_targets.all())
)

I like this approach because it's relatively simple and it very closely mirrors how route targets work in reality. We'd probably extend the RouteTarget model to support tenancy and tags as well.

@jeremystretch commented on GitHub (Sep 23, 2020): Seems like we jumped the gun a bit by tagging this for v2.10 without having a firm model in place. Below is a quick draft of my proposal: ```python class RouteTarget(ChangeLoggedModel): name = models.CharField( max_length=??, unique=True ) description = models.CharField(...) class Meta: ordering = ['name'] class VRF: ... import_targets = models.ManyToManyField( to='ipam.RouteTarget', related_name='import_for_vrfs', blank=True ) export_targets = models.ManyToManyField( to='ipam.RouteTarget', related_name='export_for_vrfs', blank=True ) ``` This adds a new RouteTarget model and provides two relationships from VRF to it (for import and export). It then becomes possible to query all the prefixes or IP addresses that one would expect to be visible by any given VRF: ```python vrf = VRF.objects.get(name='MyVRF') Prefix.objects.filter( Q(vrf=vrf) | Q(vrf__import_targets__in=vrf.export_targets.all()) ) ``` I like this approach because it's relatively simple and it very closely mirrors how route targets work in reality. We'd probably extend the RouteTarget model to support tenancy and tags as well.
adam commented 2025-12-29 16:19:11 +01:00
Author
Owner
Copy Link

@LukeDRussell commented on GitHub (Sep 24, 2020):

Love your work @jeremystretch

@LukeDRussell commented on GitHub (Sep 24, 2020): Love your work @jeremystretch
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 status: accepted 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#191
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?