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

Allow pluggables as front-port/rear-port type #6501

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

Originally created by @netixx on GitHub (May 20, 2022).

NetBox version

v3.2.3

Feature type

Change to existing functionality

Proposed functionality

We should allow more standard types to be selected for front-port and rear-ports.

Could be either static (in the code) or configurable (eg. the user can ADD new port types in the admin UI or the configuration).

Use case

While modeling optical devices that do TDM (Time Division Multiplexing) - or other type of MUX - we often need to associate so called "client" interfaces with one "network" interface.

I believe this use-case could be covered by using existing front-port/rear-port functionality (front-port being the "client" port and rear-port being the "network" port. The issue today is that we cannot set the correct type for the ports, since client port are often pluggables (SFP, QSFP, etc...) and that is not allowed for front and rear ports.

This wouldn't be a passive connection (like it is for patch-panels), but I think it's still the best way to model those connections, since optical devices act on the OSI layer 1.

Database changes

None (i think) - since types are declared in code.

External dependencies

None

Originally created by @netixx on GitHub (May 20, 2022). ### NetBox version v3.2.3 ### Feature type Change to existing functionality ### Proposed functionality We should allow more standard types to be selected for front-port and rear-ports. Could be either static (in the code) or configurable (eg. the user can ADD new port types in the admin UI or the configuration). ### Use case While modeling optical devices that do TDM (Time Division Multiplexing) - or other type of MUX - we often need to associate so called "client" interfaces with one "network" interface. I believe this use-case could be covered by using existing front-port/rear-port functionality (front-port being the "client" port and rear-port being the "network" port. The issue today is that we cannot set the correct type for the ports, since client port are often pluggables (SFP, QSFP, etc...) and that is not allowed for front and rear ports. This wouldn't be a passive connection (like it is for patch-panels), but I think it's still the best way to model those connections, since optical devices act on the OSI layer 1. ### Database changes None (i think) - since types are declared in code. ### External dependencies None
adam added the type: feature label 2025-12-29 19:41:36 +01:00
adam closed this issue 2025-12-29 19:41:36 +01:00
adam commented 2025-12-29 19:41:36 +01:00
Author
Owner
Copy Link

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

Transceivers (e.g. SFPs) should be added as inventory items and associated with the interface into which they are installed. Please see this FAQ in the wiki for why it does not make sense to permit the creation of arbitrary interface/port types.

@jeremystretch commented on GitHub (May 20, 2022): Transceivers (e.g. SFPs) should be added as inventory items and associated with the interface into which they are installed. Please see [this FAQ in the wiki](https://github.com/netbox-community/netbox/wiki/Frequently-Asked-Questions#how-can-i-add-new-interface-types) for why it does not make sense to permit the creation of arbitrary interface/port types.
adam commented 2025-12-29 19:41:37 +01:00
Author
Owner
Copy Link

@netixx commented on GitHub (May 23, 2022):

I have read this section of the FAQ, however the idea here is not to create new interface types, but to allow front-port and rear-port to use already existing types (that are use for interfaces).

For example, we allow "LC/PC" for interfaces, why not allow "QSFP+" for front-ports and rear-ports ?

To clarify what I meant by "the user can ADD new port types in the admin UI or the configuration": we could allow the user to set which types are allowed among the pre-defined (static) list of types already present in Netbox for interfaces and front/rear-ports.

@netixx commented on GitHub (May 23, 2022): I have read this section of the FAQ, however the idea here is not to create new interface types, but to allow front-port and rear-port to use **already existing** types (that are use for interfaces). For example, we allow "LC/PC" for interfaces, why not allow "QSFP+" for front-ports and rear-ports ? To clarify what I meant by "the user can ADD new port types in the admin UI or the configuration": we could allow the user to set which types are allowed among the pre-defined (static) list of types already present in Netbox for interfaces and front/rear-ports.
adam commented 2025-12-29 19:41:37 +01:00
Author
Owner
Copy Link

@AiYoriAoshi commented on GitHub (Jun 17, 2022):

I understand reason behind not wanting to add Transceiver types as opposed to Fiber/Cable types which rarely see a new standard the transceivers are constantly evolving, especially QSFP nowadays and adding them all would make a long complex list but I think it would already help having the type "Transceiver" or "Transceiver Slot" with all details going into inventory but that would model the real world better than "Other" Type.

We mainly use AOC cables for DWDM equipment, so I would use "Other" as closest type. If we would use a lot LR/SR transceivers with LC connectors, I wouldn't have such a difficult time with this as technically LC type would be correct, even if it's actually not hard wired but AOC/DAC is just not a connector type now is it.

@AiYoriAoshi commented on GitHub (Jun 17, 2022): I understand reason behind not wanting to add Transceiver types as opposed to Fiber/Cable types which rarely see a new standard the transceivers are constantly evolving, especially QSFP nowadays and adding them all would make a long complex list but I think it would already help having the type "Transceiver" or "Transceiver Slot" with all details going into inventory but that would model the real world better than "Other" Type. We mainly use AOC cables for DWDM equipment, so I would use "Other" as closest type. If we would use a lot LR/SR transceivers with LC connectors, I wouldn't have such a difficult time with this as technically LC type would be correct, even if it's actually not hard wired but AOC/DAC is just not a connector type now is it.
adam commented 2025-12-29 19:41:37 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jun 17, 2022):

You are conflating interface types with transceiver types. The two are independent attributes and thus modeled separately.

@jeremystretch commented on GitHub (Jun 17, 2022): You are conflating _interface_ types with _transceiver_ types. The two are independent attributes and thus modeled separately.
adam commented 2025-12-29 19:41:37 +01:00
Author
Owner
Copy Link

@netixx commented on GitHub (Jul 4, 2022):

Correct me if I am wrong, but the port types available in Netbox today are not transceiver types. E.G. QSFP is the format of the cage in which a compatible transceiver can be inserted, this is usually bound to the hardware installed (unlike the transceiver, that can be swapped).

Regarding the original issue, and @AiYoriAoshi comment : the issue today is that we cannot model a front or rear port with the correct interface type (eg. QSFP) and must resort to "Other".

It seems indeed logical to me that the transceiver is in the cage should be modeled using inventory items (this way we can record additional attributes - eg. serial number).

@netixx commented on GitHub (Jul 4, 2022): Correct me if I am wrong, but the port types available in Netbox today are not transceiver types. E.G. QSFP is the format of the cage in which a compatible transceiver can be inserted, this is usually bound to the hardware installed (unlike the transceiver, that can be swapped). Regarding the original issue, and @AiYoriAoshi comment : the issue today is that we cannot model a front or rear port with the correct interface type (eg. QSFP) and must resort to "Other". It seems indeed logical to me that the transceiver is in the cage should be modeled using inventory items (this way we can record additional attributes - eg. serial number).
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#6501
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?