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

Change the relation of Prefix / VRF to Prefix / Route Target #5240

New Issue
Closed
opened 2025-12-29 19:25:47 +01:00 by adam · 2 comments
adam commented 2025-12-29 19:25:47 +01:00
Owner
Copy Link

Originally created by @timrabl on GitHub (Aug 29, 2021).

NetBox version

v2.11.12

Feature type

Change to existing functionality

Proposed functionality

Example case

Let's take a Site A ( a data center ) with the autonomous system number (ASN) 1234.
There are two or more routers in one of the racks in this data center.

Each router announces its routes to the directly connected networks via BGP.
All routers speak to each other using a Link Aggregation Protocol (HSRP, LACP, whatever).
Each VRF now imports and exports its routes to the corresponding other VRFs.

According to EVPN RFCs, route distinguisher values ​​should be unique per MAC-VRF or IP-VRF.
See IP Prefix Advertisement in EVPN or RFC 7432.

As a result, there are now n VRFs and in order to avoid route leaking there is exactly one routing table (route target) created in Netbox.

As an example:

vrf definition router-1
  rd 1234:1000

  route target import 1234:100
  route target export 1234:100

vrf definition router-2
  rd 1234:2000

  route target import 1234:100
  route target export 1234:100

Current behaviour

If a new prefix is ​​now entered in Netbox, which is announced by any of the n routers, this must be assigned to a single VRF.

If you now assume that a router fails and a BGP route is no longer announced, the whole thing may still be manageable as soon as the primary router ( router with highest priority ) announces routes again. This means that the entries in Netbox are correct again after the failure has been resolved. Technically, however, they are temporarily wrong.

However, if one assumes that ECMP is used as the routing strategy (different route distinguisher are absolutely necessary here), then no firm statement can be made as to which BGP route is used or which VRF routes the traffic to the network.

So there is currently no possibility of entering prefixes correctly, in the sense of routing table specific and not VRF specifically, in Netbox.

It would be nice if you had a clear assignment of prefixes to routing tables in the prefix overview. Because the VRF is not very meaningful in some cases.

Implementation ideas

1. Adding multiple VRFs to a prefix

I deliberately write VRFs to a prefix, because you can currently theoretically create two "same" prefixes in two different VRFs. However, you then have to give the end device two IP addresses in this network, which again is completely wrong.

2. Change the prefix relations

Currently, VRF and Prefix are related:

  • a VRF several prefixes (1:n)
  • a prefix a VRF (1:1)

It would be better and more correct (in my opinion) to relate the prefix and the VRF to a route target.

  • one VRF several route targets (1:n) (this is currently already possible)
  • one route target several prefixes (1:n)
  • one prefix several route targets (1:n)

Use case

See section current behaviour. I think that's explained in detail there.

Database changes

I would guess that database relations between VRF / Prefix / Route Target have to be changed in any case. How far remains to be seen.

External dependencies

I think there is no need for external libraries here.

Originally created by @timrabl on GitHub (Aug 29, 2021). ### NetBox version v2.11.12 ### Feature type Change to existing functionality ### Proposed functionality ### Example case ### Let's take a **Site A** ( a data center ) with the autonomous system number (ASN) **1234**. There are two or more routers in one of the racks in this data center. Each router announces its routes to the directly connected networks via BGP. All routers speak to each other using a Link Aggregation Protocol (HSRP, LACP, whatever). Each VRF now imports and exports its routes to the corresponding other VRFs. According to EVPN RFCs, route distinguisher values ​​should be unique per MAC-VRF or IP-VRF. See [IP Prefix Advertisement in EVPN](https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-prefix-advertisement-11) or [RFC 7432](https://datatracker.ietf.org/doc/html/rfc7432#section-7.9). As a result, there are now `n` VRFs and in order to avoid route leaking there is exactly `one` routing table (route target) created in Netbox. As an example: ``` vrf definition router-1 rd 1234:1000 route target import 1234:100 route target export 1234:100 ``` ``` vrf definition router-2 rd 1234:2000 route target import 1234:100 route target export 1234:100 ``` ### Current behaviour ### If a new prefix is ​​now entered in Netbox, which is announced by any of the `n` routers, this must be assigned to a **single** VRF. If you now assume that a router fails and a BGP route is no longer announced, the whole thing may still be manageable as soon as the primary router ( router with highest priority ) announces routes again. This means that the entries in Netbox are correct again after the failure has been resolved. Technically, however, they are temporarily wrong. However, if one assumes that ECMP is used as the routing strategy (different route distinguisher are absolutely necessary here), then no firm statement can be made as to which BGP route is used or which VRF routes the traffic to the network. So there is currently no possibility of entering prefixes *correctly*, in the sense of routing table specific and not VRF specifically, in Netbox. It would be nice if you had a clear assignment of prefixes to routing tables in the prefix overview. Because the VRF is not very meaningful in some cases. ### Implementation ideas ### #### 1. Adding multiple VRFs to a prefix #### I deliberately write VRFs to a prefix, because you can currently theoretically create two "same" prefixes in two different VRFs. However, you then have to give the end device two IP addresses in this network, which again is completely wrong. #### 2. Change the prefix relations #### Currently, VRF and Prefix are related: - a VRF several prefixes (1:n) - a prefix a VRF (1:1) It would be better and more correct (in my opinion) to relate the prefix and the VRF to a route target. - one VRF several route targets (1:n) (this is currently already possible) - one route target several prefixes (1:n) - one prefix several route targets (1:n) ### Use case See section current behaviour. I think that's explained in detail there. ### Database changes I would guess that database relations between VRF / Prefix / Route Target have to be changed in any case. How far remains to be seen. ### External dependencies I think there is no need for external libraries here.
adam added the type: feature label 2025-12-29 19:25:47 +01:00
adam closed this issue 2025-12-29 19:25:47 +01:00
adam commented 2025-12-29 19:25:47 +01:00
Author
Owner
Copy Link

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

So, I think I understand what you are getting at here is...

Because prefixes are tied to a VRF, you can't "see" when a prefix is in an imported VRF in Netbox. I think the proposal you are proposing is the wrong workaround for it as it does not match the real world implementation. Take for example this configuration:

vrf definition RED
  rd 64512:100
  address-family ipv4 unicast
    route-target export 64512:100
    route-target import 64512:100

vrf definition GREEN
  rd 64512:200
  address-family ipv4 unicast
    route-target export 64512:200
    route-target import 64512:200
    route-target import 64512:100

interface Gi0/1
  vrf forwarding RED
  ip address 10.231.23.1 255.255.255.0

The prefix, in this relation, is assigned to the VRF, not the route target.

I think it would be very rare that you would have the "same" VRF with a differnet name advertising the same prefix.

Now, I could see adding a little more advanced checking to check for prefixes that are existing in route-targets that are being imported into the VRF you are creating the new prefix it. However, this type of heavy lifting might be best left to some custom validation (see NetBox 3.0)

@DanSheps commented on GitHub (Aug 30, 2021): So, I think I understand what you are getting at here is... Because prefixes are tied to a VRF, you can't "see" when a prefix is in an imported VRF in Netbox. I think the proposal you are proposing is the **wrong** workaround for it as it does not match the real world implementation. Take for example this configuration: ``` vrf definition RED rd 64512:100 address-family ipv4 unicast route-target export 64512:100 route-target import 64512:100 vrf definition GREEN rd 64512:200 address-family ipv4 unicast route-target export 64512:200 route-target import 64512:200 route-target import 64512:100 interface Gi0/1 vrf forwarding RED ip address 10.231.23.1 255.255.255.0 ``` The prefix, in this relation, is assigned to the VRF, not the route target. I think it would be very rare that you would have the "same" VRF with a differnet name advertising the same prefix. Now, I could see adding a little more advanced checking to check for prefixes that are existing in route-targets that are being imported into the VRF you are creating the new prefix it. However, this type of heavy lifting might be best left to some custom validation (see NetBox 3.0)
adam commented 2025-12-29 19:25:48 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 9, 2021):

@DanSheps hit the nail on the head here. NetBox's model for VRFs, route targets, and related objects replicates how the objects interact in the real world, and this is not something we would want to deviate from.

@jeremystretch commented on GitHub (Sep 9, 2021): @DanSheps hit the nail on the head here. NetBox's model for VRFs, route targets, and related objects replicates how the objects interact in the real world, and this is not something we would want to deviate from.
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#5240
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?