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

Native tracking of RPKI ROAs to tie ASN + Prefix + Aggregates together #6711

New Issue
Closed
opened 2025-12-29 19:44:21 +01:00 by adam · 4 comments
adam commented 2025-12-29 19:44:21 +01:00
Owner
Copy Link

Originally created by @falz on GitHub (Jul 23, 2022).

NetBox version

3.2.7

Feature type

Data model extension

Proposed functionality

IP Aggregate and prefix tracking is a pivotal feature of netbox that i suspect is widely used. It would be keen to have native support to help track RPKI ROAs (https://en.wikipedia.org/wiki/Resource_Public_Key_Infrastructure) which would help network operators determine which ROAs should be created and which should be a part of which RPKI manifest.

Key fields to ROAs are:

  1. ROA name (arbitrary)
  2. prefix + length
  3. Origin ASN
  4. Start / End date
  5. Private Key

Of these fields, I believe we only would need to track 2, 3, and possibly 1. 2 and 3 are supported in Netbox, but there is no way to tie them together. Issue https://github.com/netbox-community/netbox/issues/8782 also speaks of this (and RPKI is mentioned in a comment).

Im envisioning two different ways to possibly do this. My preference is item 2 but I'd take either.

  1. "not called rpki" - This would track item 2 and 3 above. Sites and ASNs in netbox can currently be tied together (an ASN can have multiple sites), having this same type of reltationship for ASNs to Prefixes and Aggregates would achieve this.

  2. "RPKI ROA" netbox object - This would track 1, 2, 3 above. In the IPAM section, have a top level RPKI ROA area. A ROA would have 3 required fields - ROA name, a link to a single existing ASN, and a 1:many link to Prefixes AND Aggregates (unsure if this is possible). This would also mean that an Aggregate or Prefix would have an optional field where you could select a single ROA that it is a part of (1:1 from the prefix/aggregate perspective)

Use case

While you may be able to track such objects in Netbox using Tags and Custom Fields, it seems like it may be a widespread enough use case to support it natively, which may also help with RPKI awareness and adoption.

If one were to use a custom field on a prefix or aggregate, it would be for an ASN and we would then have duplicate data.

We are a service provider-ish organization. We have our own IP space. We have some downstream eyeballs with prefixes (/24s, /23s, etc) advertised from a customer ASN, while we have the covering /16 advertised from our prefix, which is standard in service provider environments. To create a single ROA manifest we need the complete list of all prefixes and origin ASNs that are within that /16, the current method to track this is a spreadsheet, which quickly becomes out of date.

Please note that I'm writing this request before we fully have RPKI ROAs signed, and encountered this request in the planning phases. It's possible that we're missing something key here to ROA deployment and we'd love to hear feedback from folks with operational experience if this feature would be beneficial.

Database changes

IPAM -> RPKI object type must be created, then tied to prefixes + aggregates + asns.

External dependencies

none?

Originally created by @falz on GitHub (Jul 23, 2022). ### NetBox version 3.2.7 ### Feature type Data model extension ### Proposed functionality IP Aggregate and prefix tracking is a pivotal feature of netbox that i suspect is widely used. It would be keen to have native support to help track RPKI ROAs (https://en.wikipedia.org/wiki/Resource_Public_Key_Infrastructure) which would help network operators determine which ROAs should be created and which should be a part of which RPKI manifest. Key fields to ROAs are: 1) ROA name (arbitrary) 2) prefix + length 3) Origin ASN 4) Start / End date 5) Private Key Of these fields, I believe we only would need to track 2, 3, and possibly 1. 2 and 3 are supported in Netbox, but there is no way to tie them together. Issue https://github.com/netbox-community/netbox/issues/8782 also speaks of this (and RPKI is mentioned in a comment). Im envisioning two different ways to possibly do this. My preference is item 2 but I'd take either. 1) "not called rpki" - This would track item 2 and 3 above. Sites and ASNs in netbox can currently be tied together (an ASN can have multiple sites), having this same type of reltationship for ASNs to Prefixes *and* Aggregates would achieve this. 2) "RPKI ROA" netbox object - This would track 1, 2, 3 above. In the IPAM section, have a top level RPKI ROA area. A ROA would have 3 required fields - ROA name, a link to a single existing ASN, and a 1:many link to Prefixes AND Aggregates (unsure if this is possible). This would also mean that an Aggregate or Prefix would have an optional field where you could select a single ROA that it is a part of (1:1 from the prefix/aggregate perspective) ### Use case While you may be able to track such objects in Netbox using Tags and Custom Fields, it seems like it may be a widespread enough use case to support it natively, which may also help with RPKI awareness and adoption. If one were to use a custom field on a prefix or aggregate, it would be for an ASN and we would then have duplicate data. We are a service provider-ish organization. We have our own IP space. We have some downstream eyeballs with prefixes (/24s, /23s, etc) advertised from a customer ASN, while we have the covering /16 advertised from our prefix, which is standard in service provider environments. To create a single ROA manifest we need the complete list of all prefixes and origin ASNs that are within that /16, the current method to track this is a spreadsheet, which quickly becomes out of date. Please note that I'm writing this request before we fully have RPKI ROAs signed, and encountered this request in the planning phases. It's possible that we're missing something key here to ROA deployment and we'd love to hear feedback from folks with operational experience if this feature would be beneficial. ### Database changes IPAM -> RPKI object type must be created, then tied to prefixes + aggregates + asns. ### External dependencies none?
adam added the type: featureplugin candidate labels 2025-12-29 19:44:21 +01:00
adam closed this issue 2025-12-29 19:44:21 +01:00
adam commented 2025-12-29 19:44:22 +01:00
Author
Owner
Copy Link

@falz commented on GitHub (Jul 23, 2022):

I missed an item that's required to create a ROA - "max prefix length" - this would have to exist as an optional field when using implementation method 2 - native support for RPKI.

Additionally, an RPKI object should be able to optionally be assigned a tenant.

@falz commented on GitHub (Jul 23, 2022): I missed an item that's required to create a ROA - "max prefix length" - this would have to exist as an optional field when using implementation method 2 - native support for RPKI. Additionally, an RPKI object should be able to optionally be assigned a tenant.
adam commented 2025-12-29 19:44:22 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Sep 27, 2022):

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 27, 2022): 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 19:44:22 +01:00
Author
Owner
Copy Link

@ryanmerolle commented on GitHub (Oct 22, 2022):

This feels like a good plugin to me. It could really model out RPKI. netbox-rpki

@ryanmerolle commented on GitHub (Oct 22, 2022): This feels like a good plugin to me. It could really model out RPKI. netbox-rpki
adam commented 2025-12-29 19:44:22 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 16, 2022):

Agreed; I'd like to see this implemented as a plugin. I feel that it needs someone very familiar with the intricacies of RPKI to own it. If it gains traction, we could consider incorporating the functionality into core in the future.

@jeremystretch commented on GitHub (Nov 16, 2022): Agreed; I'd like to see this implemented as a plugin. I feel that it needs someone very familiar with the intricacies of RPKI to own it. If it gains traction, we could consider incorporating the functionality into core in the future.
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 plugin candidate 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#6711
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?