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 Field length is too short #9043

New Issue
Closed
opened 2025-12-29 20:44:43 +01:00 by adam · 6 comments
adam commented 2025-12-29 20:44:43 +01:00
Owner
Copy Link

Originally created by @SteveRodrigue on GitHub (Jan 4, 2024).

NetBox version

v3.7.0

Feature type

Change to existing functionality

Proposed functionality

The (device) interface description field should be longer. The current limit is 200 characters, some platform supports longer description field.

Use case

JunOS supports unlimited description field length.

Netbox should offer a longer interface description field.

Database changes

Increase the size/length of the Interface description field or make it "text" (unlimited length).

External dependencies

N/A

Originally created by @SteveRodrigue on GitHub (Jan 4, 2024). ### NetBox version v3.7.0 ### Feature type Change to existing functionality ### Proposed functionality The (device) interface description field should be longer. The current limit is 200 characters, some platform supports longer description field. ### Use case JunOS supports [unlimited description](https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/add-interface-text-description-radius-options.html#:~:text=There%20is%20no%20character%20limit,characters%2C%20the%20description%20is%20truncated.) field length. Netbox should offer a longer interface description field. ### Database changes Increase the size/length of the Interface description field or make it "text" (unlimited length). ### External dependencies N/A
adam added the type: feature label 2025-12-29 20:44:43 +01:00
adam closed this issue 2025-12-29 20:44:43 +01:00
adam commented 2025-12-29 20:44:44 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 4, 2024):

JunOS supports unlimited description field length.

This is not a use case.

This has been proposed and declined previously. The length limit exists specifically to prevent users from abusing the field to store improperly formatted data. If you find that the description field is not long enough, this is almost certainly and indication that you should be offloading values to other fields.

@jeremystretch commented on GitHub (Jan 4, 2024): > JunOS supports [unlimited description](https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/add-interface-text-description-radius-options.html#:~:text=There%20is%20no%20character%20limit,characters%2C%20the%20description%20is%20truncated.) field length. This is not a use case. This has been proposed and declined previously. The length limit exists specifically to prevent users from abusing the field to store improperly formatted data. If you find that the description field is not long enough, this is almost certainly and indication that you should be offloading values to other fields.
adam commented 2025-12-29 20:44:44 +01:00
Author
Owner
Copy Link

@i3D-RyanHamel commented on GitHub (Jan 4, 2024):

An increase to 255 characters would be a suitable middle ground, as that is the max limit for Arista, Fortinet, and a few other manufacturers.

@i3D-RyanHamel commented on GitHub (Jan 4, 2024): An increase to 255 characters would be a suitable middle ground, as that is the max limit for Arista, Fortinet, and a few other manufacturers.
adam commented 2025-12-29 20:44:44 +01:00
Author
Owner
Copy Link

@i3D-RyanHamel commented on GitHub (Jan 4, 2024):

https://github.com/netbox-community/netbox/issues/3249#issuecomment-588517221

While I see the meaning behind this, it saves the engineers time by having a subset of the information available in the description. This is a known practice by many carriers.

@i3D-RyanHamel commented on GitHub (Jan 4, 2024): https://github.com/netbox-community/netbox/issues/3249#issuecomment-588517221 While I see the meaning behind this, it saves the engineers time by having a subset of the information available in the description. This is a known practice by many carriers.
adam commented 2025-12-29 20:44:45 +01:00
Author
Owner
Copy Link

@SteveRodrigue commented on GitHub (Jan 4, 2024):

I understand your stance... Even if I don't fully agree.
Thanks for your quick response @jeremystretch .

For posterity, some example of Network OS limits:
Arista - 255 characters
Cisco - 240 characters
Fortinet - 255 characters
HPe (old) - 64 characters
Nokia - 160 Characters

@SteveRodrigue commented on GitHub (Jan 4, 2024): I understand your stance... Even if I don't fully agree. Thanks for your quick response @jeremystretch . For posterity, some example of Network OS limits: Arista - 255 characters Cisco - 240 characters Fortinet - 255 characters HPe (old) - 64 characters Nokia - 160 Characters
adam commented 2025-12-29 20:44:45 +01:00
Author
Owner
Copy Link

@kmorin18 commented on GitHub (Jan 4, 2024):

I agree that the max should at least match what is available in actual network devices
The point of netbox is to represent reality

@kmorin18 commented on GitHub (Jan 4, 2024): I agree that the max should at least match what is available in actual network devices The point of netbox is to represent reality
adam commented 2025-12-29 20:44:46 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 4, 2024):

The point of netbox is to represent reality

Rest assured, it does. The description field in NetBox is for exactly that: the human-readable free-form text description. Everything else should go in a different field (core or custom) or tag. These other attributes might be combined to generate a longer string for the configuration to be provisioned - hence the support longer strings in the actual network OS - but should not live there.

This has been discussed ad nauseam and the decision has already been made, so I'm going to lock this as resolved.

@jeremystretch commented on GitHub (Jan 4, 2024): > The point of netbox is to represent reality Rest assured, it does. The description field in NetBox is for exactly that: the human-readable free-form _text description_. Everything else should go in a different field (core or custom) or tag. These other attributes might be combined to **generate** a longer string for the configuration to be provisioned - hence the support longer strings in the actual network OS - but should not live there. This has been discussed ad nauseam and the decision has already been made, so I'm going to lock this as resolved.
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#9043
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?