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

Interface Description max_length #2659

New Issue
Closed
opened 2025-12-29 18:20:59 +01:00 by adam · 8 comments
adam commented 2025-12-29 18:20:59 +01:00
Owner
Copy Link

Originally created by @seismiccollision on GitHub (Jun 8, 2019).

Environment

  • Python version:
  • NetBox version: 2.5.13

Proposed Functionality

Allow for 256 characters in interface descriptions

Use Case

For devices with 'ifalias long' enabled we're able to exceed the current maximum of 100 characters and we use interface descriptions for aggregating pertinent data tech would need to know when generating alerts

Database Changes

I know and understand the argument for maintaining close control over interface name lengths etc. from #1817 but the description is more like a custom field in many respects

External Dependencies

None AFAIK

Originally created by @seismiccollision on GitHub (Jun 8, 2019). <!-- NOTE: This form is only for proposing specific new features or enhancements. If you have a general idea or question, please post to our mailing list instead of opening an issue: https://groups.google.com/forum/#!forum/netbox-discuss NOTE: Due to an excessive backlog of feature requests, we are not currently accepting any proposals which significantly extend NetBox's feature scope. Please describe the environment in which you are running NetBox. Be sure that you are running an unmodified instance of the latest stable release before submitting a bug report. --> ### Environment * Python version: <!-- Example: 3.5.4 --> * NetBox version: 2.5.13 <!-- Describe in detail the new functionality you are proposing. Include any specific changes to work flows, data models, or the user interface. --> ### Proposed Functionality Allow for 256 characters in interface descriptions <!-- Convey an example use case for your proposed feature. Write from the perspective of a NetBox user who would benefit from the proposed functionality and describe how. ---> ### Use Case For devices with 'ifalias long' enabled we're able to exceed the current maximum of 100 characters and we use interface descriptions for aggregating pertinent data tech would need to know when generating alerts <!-- Note any changes to the database schema necessary to support the new feature. For example, does the proposal require adding a new model or field? (Not all new features require database changes.) ---> ### Database Changes I know and understand the argument for maintaining close control over interface name lengths etc. from #1817 but the description is more like a custom field in many respects <!-- List any new dependencies on external libraries or services that this new feature would introduce. For example, does the proposal require the installation of a new Python package? (Not all new features introduce new dependencies.) --> ### External Dependencies None AFAIK
adam closed this issue 2025-12-29 18:20:59 +01:00
adam commented 2025-12-29 18:20:59 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Oct 15, 2019):

What is the motivation for 256 characters specifically? Is there a canonical real-world length limitation that we can use a reference? (Example: Cisco IOS support a maximum of n characters.)

@jeremystretch commented on GitHub (Oct 15, 2019): What is the motivation for 256 characters specifically? Is there a canonical real-world length limitation that we can use a reference? (Example: Cisco IOS support a maximum of _n_ characters.)
adam commented 2025-12-29 18:20:59 +01:00
Author
Owner
Copy Link

@seismiccollision commented on GitHub (Oct 15, 2019):

Yup, you guessed it! Most of my Cisco devices allow for >200 character interface descriptions.
I picked 256 in my request because that's the limit for enabling "snmp ifalias long" which seems consistently documented https://www.cisco.com/en/US/docs/ios-xml/ios/snmp/configuration/15-0s/nm-snmp-cfg-snmp-support.html#GUID-D9F64D3A-AE0E-49A9-A685-EFB119AF50A0

Doing some quick checking on maximums I can actually configure:
NXOS <6.2 = 80 char
NXOS 7.0 = 242 char
IOS 15.0 = 200 char
IOSXR 6.x = 1010 char

@seismiccollision commented on GitHub (Oct 15, 2019): Yup, you guessed it! Most of my Cisco devices allow for >200 character interface descriptions. I picked 256 in my request because that's the limit for enabling "snmp ifalias long" which seems consistently documented https://www.cisco.com/en/US/docs/ios-xml/ios/snmp/configuration/15-0s/nm-snmp-cfg-snmp-support.html#GUID-D9F64D3A-AE0E-49A9-A685-EFB119AF50A0 Doing some quick checking on maximums I can actually configure: NXOS <6.2 = 80 char NXOS 7.0 = 242 char IOS 15.0 = 200 char IOSXR 6.x = 1010 char
adam commented 2025-12-29 18:20:59 +01:00
Author
Owner
Copy Link

@brandelf68 commented on GitHub (Nov 5, 2019):

Is it possible to increase the limit of all descriptions to 256 characters?

@brandelf68 commented on GitHub (Nov 5, 2019): Is it possible to increase the limit of all descriptions to 256 characters?
adam commented 2025-12-29 18:20:59 +01:00
Author
Owner
Copy Link

@hSaria commented on GitHub (Jan 25, 2020):

Is this something I can work on? We could also replace all of current max_length=100 for the description field with a single constant (see #3880)

@hSaria commented on GitHub (Jan 25, 2020): Is this something I can work on? We could also replace all of current `max_length=100` for the description field with a single constant (see #3880)
adam commented 2025-12-29 18:20:59 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Jan 25, 2020):

Is this something I can work on?

I don't see anything wrong with that

We could also replace all of current max_length=100 for the description field with a single constant (see #3880)

This would technically be a separate issue, but I do like it, something like DESCRIPTION_SMALL, DESCRIPTION_MEDIUM, DESCRIPTION_LARGE, DESCRIPTION_XL. Not sure what @jeremystretch thinks but I would be receptive to a change like that, if you want to open a FR for it

@DanSheps commented on GitHub (Jan 25, 2020): > Is this something I can work on? I don't see anything wrong with that > We could also replace all of current `max_length=100` for the description field with a single constant (see #3880) This would technically be a separate issue, but I do like it, something like DESCRIPTION_SMALL, DESCRIPTION_MEDIUM, DESCRIPTION_LARGE, DESCRIPTION_XL. Not sure what @jeremystretch thinks but I would be receptive to a change like that, if you want to open a FR for it
adam commented 2025-12-29 18:20:59 +01:00
Author
Owner
Copy Link

@hSaria commented on GitHub (Jan 25, 2020):

For starters, I'd like to do it just for this ticket. I could just change the 100 to 256 and call it a day, but – as a good practice following #3880 – I would constant-ize it.

On another note, where do we have different sizes of descriptions? The only place I found it to be not 100 is the ExportTemplate (currently 200, but I was planning on changing it to match the 256 for the sake of consistency).

@hSaria commented on GitHub (Jan 25, 2020): For starters, I'd like to do it just for this ticket. I could just change the 100 to 256 and call it a day, but – as a good practice following #3880 – I would constant-ize it. On another note, where do we have different sizes of descriptions? The only place I found it to be not 100 is the `ExportTemplate` (currently 200, but I was planning on changing it to match the 256 for the sake of consistency).
adam commented 2025-12-29 18:21:00 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Jan 25, 2020):

It isn't just description, it is interface names and the like

@DanSheps commented on GitHub (Jan 25, 2020): It isn't just description, it is interface names and the like
adam commented 2025-12-29 18:21:00 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Feb 19, 2020):

we use interface descriptions for aggregating pertinent data tech would need to know when generating alerts

This is fine in the configuration, because there's often nowhere else to store this information on the device. However, that is not the case with NetBox. The interface description is intended to store exactly that: a description of the interface and/or what it's connected to. It should not be used to encode formatted data such as peer IP, AS number, etc. as it would be extremely tedious, redundant, and error-prone.

For example, it's common practice to denote the ID of a connected circuit in the interface description. That's fine, but you wouldn't manually enter the circuit ID in the description field of the interface in NetBox, because NetBox provides the Circuit model with an ID field specifically for this purpose. In practice, you would form the description string by concatenating the interface's description field, the circuit's ID field, and any other pertinent information. This ensures that all information is being pulled from its canonical origin where validation has been enforced.

At any rate, I'm going to roll this into #4078, which seeks to standardize field lengths application-wide.

@jeremystretch commented on GitHub (Feb 19, 2020): > we use interface descriptions for aggregating pertinent data tech would need to know when generating alerts This is fine in the configuration, because there's often nowhere else to store this information on the device. However, that is not the case with NetBox. The interface description is intended to store exactly that: a description of the interface and/or what it's connected to. It should *not* be used to encode formatted data such as peer IP, AS number, etc. as it would be extremely tedious, redundant, and error-prone. For example, it's common practice to denote the ID of a connected circuit in the interface description. That's fine, but you wouldn't manually enter the circuit ID in the `description` field of the interface in NetBox, because NetBox provides the Circuit model with an ID field specifically for this purpose. In practice, you would form the description string by concatenating the interface's `description` field, the circuit's `ID` field, and any other pertinent information. This ensures that all information is being pulled from its canonical origin where validation has been enforced. At any rate, I'm going to roll this into #4078, which seeks to standardize field lengths application-wide.
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#2659
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?