Add a generic model for simple IDs.

[LarsNorlys]

NetBox version

v2.10.x

Feature type

Data model extension

Proposed functionality

Add a generic model for simple serial numbers. Netbox does not currently contain a model for more generic uses like ESI’s, Simple circuit-id’s or relations with a need for unique ID’s. In order to make Netbox the central SOT, a generic model supported in the UI, API and pynetbox would be benificial. Features could be:

• Unique constraint
• State (active/reserved/deprecated)
• Reference to one or more entities (interface/devices/vlans/VRFs)
• Possible regex data validation.
• get_next()

Use case

• Generic Circuit ID
• Ethernet Segment ID’s This value needs to be unique for a given SP network - but can be shared between interfaces for specific use cases
• Redundancy group In order to mark devices for part of a redundant setup - and hence not candidates for upgrades in the same service-window we need to indicate a relation between a service and a set of devices

Database changes

No response

External dependencies

No response

[jeremystretch]

I'm afraid it's not clear from your description what it is you're trying to accomplish.

Add a generic model for simple serial numbers.

Models represent complex objects like site, racks, devices, etc; A serial number would not exist as a separate model.

Please revise your post above to explain exactly what change(s) you're proposing and why it would be beneficial.

[LarsNorlys]

I will try and explain better.

In some cases we would like to have the option to generate and store specific unique IDs in Netbox in order to utilize the single source and providing UI and API in a uniform way.

Boiled down we would like to be able to generate a unique identifier. Preferably the unique identifier has possibility for validation, auto-prefix and -suffix, being decimal or hex. If the API/GUI build support get_next_available_id() it would greatly improve accessibility

Use cases in more detail.

Consider a network using eVPN. ESI’s are used to identify unique ethernet segments. ESI are a 10-octet integer. These can be associated to one or more interfaces. We would like to be able to generate, store and validate these in Netbox - coupled with a Tenant, a description and a state. Functionality for getting the next available value/ESI would be nice. We see no current ways to store this is Netbox in a meaningful manner Example: Name: “ESIpool” Prefix: “000303” Suffix: “01” Type: Hex Range: 000000000000 - ffffff ffffff Output: 00030300000000000001, 00030300000000000101 ... 000303ffffffffffff01

Circuit ID: Consider a small network with no big OSS/BSS systems. They want to use Netbox as their sole Source of Truth exposing a circuit and its relations using Netbox’s strong features. This could be done using a unique identifier generated using a predefined range and regex validation. Example: Name: “CircuitIDs” Prefix: ”CID” Suffix: None Type: Decimal Range: 100000 – 999999 Output: CID100000, CID100001... CID999999

Consider having a redundant customer circuit that on the network provider side terminates in two different network elements/interfaces. Doing software upgrades on the service provider network without downtime for the redundant circuit will require a way to document the relation between network elements in order to avoid upgrading software at two nodes redundant for each other at the same time. Use case is to do a redundancy group for each relation between network elements. This could also be used for devices instead of interfaces if one considers a ring structure where simultaneous upgrade of two devices would result in isolated nodes in the ring. Example: Name: “RedundacyGroup” Prefix: ”RDG” Suffix: None Type: Decimal Range: 100000 – 999999 Output: RDG100000, RDG100001... RDG999999

Consideration (as mentioned) has been to propose a list of Netbox objects to each instance of above, but this can be solved using custom fields on the objects or tags, so this part has been left out.

[oh-c]

I like the idea of having something that creates a uniqe object, with some constraints like the ESI. This coupled with https://github.com/netbox-community/netbox/issues/8157 and a custom field pointing to the generated ESI object would ensure that no overlapping ESI are created.

The L2VPN already has the "identifier" field, but besides regex contraints there is not way to ensure uniquness. This could be extended to be a relation to an object instead of an integer.

[phurrelmann]

what comes next to my mind are cable labels. right now one needs to maintain and generate those outside of netbox. this could mobe the generation of them into netbox and the source of truth

[github-actions[bot]]

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]]

This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.