Interface Physical Name vs Logical Name

[jameno123]

Environment

• Python version: 3.6.10 and 3.8.2
• NetBox version: 2.8.3

Proposed Functionality

In linux servers in particular the interface names are usually something like "eth0" or "eno1" however on the back of the physical machine they are generally labeled something "1" or "Eth 2".

This request would be to add an extra "label" field that would tag the physical label in the "interface" view of devices. Currently we have to put names in like "eth0 (1)" which then breaks automation platforms because things like ansible are expecting "eth0" but a technician working on site needs to know port# "1". Sometimes the device names arnt always clear which port they map to such as systemds "enps0f0" and "enps0f1".

The physical interface is labeled "1"
The logical/OS-interface is named "eth0".

It would be nice to be able to represent these in two different fields in the UI so we can perform automation with OUT coding in complex logic like "eth0 (1)" or using things like string-splitting and regexes on the interface names.

I would expect that the "Physical label" should be OPTIONAL and hidden by default however display it in parenthesis in the interface fiew "eth0 (1)" or something.

Dell servers come with the onboard nics labeled "1,2,3,4" its nice to be able to capture that information which we currently cant do without putting it into description or interface name.

Use Case

Being able to display both physical ports and logical port numbers would allow for automation systems to work without requiring regexing of names. Onsite technicians would have additional details to ensure correct actions are performed and the correct ports are able to be more quickly identified during "racking and stacking" where things may not be fully labeled yet.

Database Changes

Likely an additional field in the interface model

External Dependencies

none

[kobayashi]

This issue has been closed as it does not conform to one of the provided templates as required by the contributing guide. If you'd like to request that your issue be re-opened, please first update the content so that it matches the appropriate template (this may require rewriting your issue entirely).

[jameno123]

@kobayashi please consider re-opening or let me know if i need to create another. I did not see the issue template somehow. I clicked new issue and it dropped be directly to the form. Now I see its showing a list of templates. I would have used previously. I apologize.

[mrfroggg]

Yes, I agree!
We have many automation that uses the physical name/position of a card (s4p1 (slot 4 port 1) instead of eth* names for a Linux server and it's how our datacenter teams are working when patching cables.
Since there is no Custom Field for interfaces to store this info, I would really like a physical name/position field!

Thanks!

[jeremystretch]

This probably makes sense to add to other components as well. I can see a use case for power ports, for example, where the physical labeling differs from what e.g. show chassis reports.

[cpmills1975]

Is it too late to consider how the labels are represented on virtual chassis - particularly the master member. When adding member switches to a virtual chassis, I rename the interfaces to match their actual logical address, but having multiple 'Port 12's appear in the list of interfaces on the main chassis member won't be helpful. I could of course label the ports uniquely in the same way as I currently name them, but (I think) this breaks the use-case of labelling them with the physical 'port' number.

[jsenecal]

@cpmills1975 what exactly did you have in mind?

Right now, the label is simply added to the API endpoints and represented in between "( )" next to its name in views when populated. Adding additional logic to the str() representation could lead to performance issues if we require to fetch additional objects.

[cpmills1975]

I'm not sure and open to suggestions and I can't see how this is/will be rendered on screen as it stands. The label in () works well for a single device - taking a Juniper switch for example, ge-0/1/12 rendered as "ge-0/1/12 (Port 12)" makes perfect sense. But when I add multiple Juniper switches to a virtual chassis (and rename the ports) to e.g. ge-0/1/12 and ge-1/1/12, it seems counter intuitive to then have them rendered as "ge-0/1/12 (Port 12)" and "ge-1/1/12 (Port 12)" - both ports will be marked as "12" on the front of the device, but logically named differently.

I like the simplicity of labelling them as Port 12 as cable installers will not necessarily know they are part of a virtual chassis and will typically refer to the switch by the labels and stencilling on the front of it, perhaps by asset number in some circumstances. I am working on a script to import an Excel spreadsheet so allowing the installers just to put '12' in a column and match that to the label makes sense.

I'm wondering whether the rendering could be templated somehow? On an individual switch, "ge-0/1/12 (Port 12)" makes sense, but perhaps on a virtual chassis, "ge-0/1/12 (Member 0, Port 12)" or "ge-0/1/12 (#ASSETNO Port 12)" might make more sense. Templating it would allow different organisations to decide how they would like it shown. Perhaps not at all if it isn't relevant to their environment?

Perhaps I'm over complicating this and I should just label every port uniquely and regex match '12' to 'Member 0, Port 12' in my script?

[jsenecal]

@cpmills1975 PR #4723 enables bulk creation of labels the same way one would do interface names. So whatever you do to "rename" your interfaces, you could do to the labels.

I believe using some form of templated rendition of the label or even the interface name itself when it's parent device is member of a cluster should be considered as a separate use-case/issue. (Your idea is one I've had myself but I don't believe it fits this issue's purpose)

[jeremystretch]

IMO we should include the label field on DeviceBays as well.

[jsenecal]

@jeremystretch I did not think there would be a "logical" representation of a device bay, but then I realized that some blade server chassis have their own management interface, so I added this in a37d060