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 Speed & Duplex #5676

New Issue
Closed
opened 2025-12-29 19:31:12 +01:00 by adam · 5 comments
adam commented 2025-12-29 19:31:12 +01:00
Owner
Copy Link

Originally created by @ryanmerolle on GitHub (Nov 17, 2021).

Originally assigned to: @DanSheps on GitHub.

NetBox version

v3.0.10

Feature type

Data model extension

Proposed functionality

Generally NetBox should support most base functions an interface supports. One obvious function missing in the current model is the ability to set interface speed.

None of the maintainers could recall anyone ever requesting this, which is quite surprising. I completed a rough search through the backlog of issues, and could not find anything obvious existing.

Use case

There 2 possible use cases I am thinking of, but there could be more:

  • People who want to hard set speed for whatever reason like removing auto-negotiation with fickle peer interfaces.
  • People who want a way to track actual speed of a port without going into the granularity of tracking the SFP inserted into the port. Example: SFP28 capable ports with SFP+ optics installed are currently hard to model. A lot of people likely do not want to deal with the overhead of SFP management in Netbox, though that could become a thing later.

Database changes

No response

External dependencies

No response

Originally created by @ryanmerolle on GitHub (Nov 17, 2021). Originally assigned to: @DanSheps on GitHub. ### NetBox version v3.0.10 ### Feature type Data model extension ### Proposed functionality Generally NetBox should support most base functions an interface supports. One obvious function missing in the current model is the ability to set interface speed. None of the maintainers could recall anyone ever requesting this, which is quite surprising. I completed a rough search through the backlog of issues, and could not find anything obvious existing. ### Use case There 2 possible use cases I am thinking of, but there could be more: - People who want to hard set speed for whatever reason like removing auto-negotiation with fickle peer interfaces. - People who want a way to track actual speed of a port without going into the granularity of tracking the SFP inserted into the port. Example: SFP28 capable ports with SFP+ optics installed are currently hard to model. A lot of people likely do not want to deal with the overhead of SFP management in Netbox, though that could become a thing later. ### Database changes _No response_ ### External dependencies _No response_
adam added the status: acceptedtype: feature labels 2025-12-29 19:31:12 +01:00
adam closed this issue 2025-12-29 19:31:12 +01:00
adam commented 2025-12-29 19:31:13 +01:00
Author
Owner
Copy Link

@sdktr commented on GitHub (Nov 17, 2021):

I was surprised to find no 'auto negotiation'/duplex setting somewhere. Glad it's getting addressed, thumbs up

@sdktr commented on GitHub (Nov 17, 2021): I was surprised to find no 'auto negotiation'/duplex setting somewhere. Glad it's getting addressed, thumbs up
adam commented 2025-12-29 19:31:13 +01:00
Author
Owner
Copy Link

@hiddenman commented on GitHub (Nov 17, 2021):

That's what we also was looking for and discussed in the Slack channel.
Actually, the most asked options from my colleagues are: SFP modules and Interface speed (and other options).

@hiddenman commented on GitHub (Nov 17, 2021): That's what we also was looking for and discussed in the Slack channel. Actually, the most asked options from my colleagues are: SFP modules and Interface speed (and other options).
adam commented 2025-12-29 19:31:13 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 17, 2021):

I imagine we'll declare speed as a positive integer value, and provide a widget on the UI to select from one of several common predefined values, as we do today with circuit terminations. This will allow users to set the speed conveniently while still allowing the flexibility to define arbitrary speeds where necessary.

Do we want to tackle duplex as part of this as well? I know it's not commonly a concern these days, but I still see stories of people being forced to connect terrible equipment at 100/half.

@jeremystretch commented on GitHub (Nov 17, 2021): I imagine we'll declare `speed` as a positive integer value, and provide a widget on the UI to select from one of several common predefined values, as we do today with circuit terminations. This will allow users to set the speed conveniently while still allowing the flexibility to define arbitrary speeds where necessary. Do we want to tackle duplex as part of this as well? I know it's not commonly a concern these days, but I still see stories of people being forced to connect terrible equipment at 100/half.
adam commented 2025-12-29 19:31:13 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Nov 17, 2021):

forced to connect terrible equipment at 100/half

Building Systems
Alarm panels
Door locks

It is all produce from companies with little networking knowledge that rely on archic protocols like BACnet.

@DanSheps commented on GitHub (Nov 17, 2021): > forced to connect terrible equipment at 100/half Building Systems Alarm panels Door locks It is all produce from companies with little networking knowledge that rely on archic protocols like BACnet.
adam commented 2025-12-29 19:31:13 +01:00
Author
Owner
Copy Link

@sdktr commented on GitHub (Nov 18, 2021):

+1 for facing a fixed duplex external connection sometimes

@sdktr commented on GitHub (Nov 18, 2021): +1 for facing a fixed duplex external connection sometimes
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 status: accepted 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#5676
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?