netbox-community / netbox

The premier source of truth powering network automation. Open source under Apache 2. Try NetBox Cloud free: https://netboxlabs.com/free-netbox-cloud/
http://netboxlabs.com/oss/netbox/
Apache License 2.0
16.17k stars 2.59k forks source link

Interface Description max_length #3249

Closed seismiccollision closed 4 years ago

seismiccollision commented 5 years ago

Environment

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

jeremystretch commented 5 years ago

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.)

seismiccollision commented 5 years ago

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

brandelf68 commented 5 years ago

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

hSaria commented 4 years ago

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)

DanSheps commented 4 years ago

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

hSaria commented 4 years ago

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).

DanSheps commented 4 years ago

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

jeremystretch commented 4 years ago

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.