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

Make interface name optional #7570

New Issue
Closed
opened 2025-12-29 20:25:33 +01:00 by adam · 3 comments
adam commented 2025-12-29 20:25:33 +01:00
Owner
Copy Link

Originally created by @BegBlev on GitHub (Jan 27, 2023).

NetBox version

v3.4.3

Feature type

Change to existing functionality

Proposed functionality

I think interface name should be optional.

The documentation specifies interface name is "The name of the interface, as reported by the device's operating system". A bare metal provider, won't know the name of the interface inside the operating system. He doen't even know which OS is installed. As an other exemple, if you have a JunOS device, the internal name depends of the SFP you will install (ge-0/0/0 or xe-0/0/0 or te-0/0/0...).

In my case, "label" has much more meaning as I have to make the cabling. The documentation specifies label is "An alternative physical label identifying the interface".

Of course, for virtual interfaces (bond0 on Linux or ae1 on JunOS) the name is much more relevant.

In a general way I wonder if the name should be optional also for other objects. Probably some people don't care about device names as they use serial number as a reference. In my case device name is just for printing on stckers :). My reference is definitly S/N

Best regards
Vincent

Use case

A bare metal provider, won't know the name of the interface inside the operating system. He doen't even know which OS is installed. As an other exemple, if you have a JunOS device, the internal name depends of the SFP you will install (ge-0/0/0 or xe-0/0/0 or te-0/0/0...).

Database changes

No response

External dependencies

No response

Originally created by @BegBlev on GitHub (Jan 27, 2023). ### NetBox version v3.4.3 ### Feature type Change to existing functionality ### Proposed functionality I think interface name should be optional. The documentation specifies interface name is "The name of the interface, as reported by the device's operating system". A bare metal provider, won't know the name of the interface inside the operating system. He doen't even know which OS is installed. As an other exemple, if you have a JunOS device, the internal name depends of the SFP you will install (ge-0/0/0 or xe-0/0/0 or te-0/0/0...). In my case, "label" has much more meaning as I have to make the cabling. The documentation specifies label is "An alternative physical label identifying the interface". Of course, for virtual interfaces (bond0 on Linux or ae1 on JunOS) the name is much more relevant. In a general way I wonder if the name should be optional also for other objects. Probably some people don't care about device names as they use serial number as a reference. In my case device name is just for printing on stckers :). My reference is definitly S/N Best regards Vincent ### Use case A bare metal provider, won't know the name of the interface inside the operating system. He doen't even know which OS is installed. As an other exemple, if you have a JunOS device, the internal name depends of the SFP you will install (ge-0/0/0 or xe-0/0/0 or te-0/0/0...). ### Database changes _No response_ ### External dependencies _No response_
adam added the type: feature label 2025-12-29 20:25:33 +01:00
adam closed this issue 2025-12-29 20:25:33 +01:00
adam commented 2025-12-29 20:25:34 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Feb 18, 2023):

Technically this is going to be difficult to implement, and somewhat impractical.

A bare metal provider, won't know the name of the interface inside the operating system. He doen't even know which OS is installed.

There are a couple of options for this, typically I just name it "ethernet" and rename as needed. If you are using automation, this should be part of your automation.

As an other exemple, if you have a JunOS device, the internal name depends of the SFP you will install (ge-0/0/0 or xe-0/0/0 or te-0/0/0...).

I am not sure about JunOS, but in Cisco IOS/IOS-XE you actually have all interfaces in the config (Gi, Te, Fo, etc) but only the active interface is the config that is used (for example, you have both Gi1/1/4 and Te1/1/4. You can have separate configs for each based on the network module inserted, a 1G SFP will still use the 10G config)

I definitely want to see comments based on this though, so upvote/downvote and comment please.

@DanSheps commented on GitHub (Feb 18, 2023): Technically this is going to be difficult to implement, and somewhat impractical. > A bare metal provider, won't know the name of the interface inside the operating system. He doen't even know which OS is installed. There are a couple of options for this, typically I just name it "ethernet" and rename as needed. If you are using automation, this should be part of your automation. > As an other exemple, if you have a JunOS device, the internal name depends of the SFP you will install (ge-0/0/0 or xe-0/0/0 or te-0/0/0...). I am not sure about JunOS, but in Cisco IOS/IOS-XE you actually have all interfaces in the config (Gi, Te, Fo, etc) but only the active interface is the config that is used (for example, you have both Gi1/1/4 and Te1/1/4. You can have separate configs for each based on the network module inserted, a 1G SFP will still use the 10G config) I definitely want to see comments based on this though, so upvote/downvote and comment please.
adam commented 2025-12-29 20:25:34 +01:00
Author
Owner
Copy Link

@BarbarossaTM commented on GitHub (Apr 22, 2023):

I agree with @DanSheps that this would be impractical and just "inventing" an interface name here feels to be the easiest solution.

If this where to be allowed every automation piece would need to get a check for this new corner case as part of input validation.

@BarbarossaTM commented on GitHub (Apr 22, 2023): I agree with @DanSheps that this would be impractical and just "inventing" an interface name here feels to be the easiest solution. If this where to be allowed every automation piece would need to get a check for this new corner case as part of input validation.
adam commented 2025-12-29 20:25:34 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (May 3, 2023):

I strongly agree that this isn't something we can reasonably entertain, as it would violate many presumptions baked into both NetBox itself as well as user workflows. I suggest using formulaic placeholders in situations where interface names aren't known ahead of time.

@jeremystretch commented on GitHub (May 3, 2023): I strongly agree that this isn't something we can reasonably entertain, as it would violate many presumptions baked into both NetBox itself as well as user workflows. I suggest using formulaic placeholders in situations where interface names aren't known ahead of time.
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#7570
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?