Interface Physical Name vs Logical Name #3664

New Issue

adam · 2025-12-29T18:30:28+01:00

adam commented

2025-12-29 18:30:28 +01:00

Originally created by @jameno123 on GitHub (May 9, 2020).

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

Originally created by @jameno123 on GitHub (May 9, 2020).  ### 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

adam added the status: accepted type: feature labels 2025-12-29 18:30:28 +01:00

adam closed this issue

2025-12-29 18:30:28 +01:00

adam commented

2025-12-29 18:30:28 +01:00

@kobayashi commented on GitHub (May 10, 2020):

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

@kobayashi commented on GitHub (May 10, 2020): This issue has been closed as it does not conform to one of the [provided templates](https://github.com/digitalocean/netbox/issues/new/choose) as required by the [contributing guide](https://github.com/digitalocean/netbox/blob/master/CONTRIBUTING.md). 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).

adam commented

2025-12-29 18:30:29 +01:00

@jameno123 commented on GitHub (May 10, 2020):

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

@jameno123 commented on GitHub (May 10, 2020): @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.

adam commented

2025-12-29 18:30:29 +01:00

@mrfroggg commented on GitHub (May 11, 2020):

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!

@mrfroggg commented on GitHub (May 11, 2020): 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!

adam commented

2025-12-29 18:30:29 +01:00

@jeremystretch commented on GitHub (May 20, 2020):

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.

@jeremystretch commented on GitHub (May 20, 2020): 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.

adam commented

2025-12-29 18:30:29 +01:00

@cpmills1975 commented on GitHub (Jun 9, 2020):

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.

@cpmills1975 commented on GitHub (Jun 9, 2020): 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.

adam commented

2025-12-29 18:30:29 +01:00

@jsenecal commented on GitHub (Jun 9, 2020):

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

@jsenecal commented on GitHub (Jun 9, 2020): @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.

adam commented

2025-12-29 18:30:29 +01:00

@cpmills1975 commented on GitHub (Jun 9, 2020):

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?

@cpmills1975 commented on GitHub (Jun 9, 2020): 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?

adam commented

2025-12-29 18:30:29 +01:00

@jsenecal commented on GitHub (Jun 10, 2020):

@cpmills1975 PR https://github.com/netbox-community/netbox/pull/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)

@jsenecal commented on GitHub (Jun 10, 2020): @cpmills1975 PR https://github.com/netbox-community/netbox/pull/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)

adam commented

2025-12-29 18:30:29 +01:00

@jeremystretch commented on GitHub (Jun 10, 2020):

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

@jeremystretch commented on GitHub (Jun 10, 2020): IMO we should include the `label` field on DeviceBays as well.

adam commented

2025-12-29 18:30:29 +01:00

@jsenecal commented on GitHub (Jun 11, 2020):

@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 a37d06064a

@jsenecal commented on GitHub (Jun 11, 2020): @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 https://github.com/netbox-community/netbox/pull/4723/commits/a37d06064a9a2200fa6007d4000c68dd8fe81bec

adam referenced this issue

2025-12-29 21:50:48 +01:00

Deletion of tag allowed when referenced in config context #11857

adam referenced this issue

2025-12-29 22:22:44 +01:00

[PR #3752] [MERGED] implement 3664 #12629

adam referenced this issue

2025-12-29 22:22:44 +01:00

[PR #3755] [MERGED] 3664 configcontext tags #12630

Sign in to join this conversation.