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

Fiber interfaces (SFPs, qSFP, etc...) simplex or duplex #6267

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

Originally created by @ppcarvalhof on GitHub (Mar 27, 2022).

NetBox version

v3.1.10

Feature type

Change to existing functionality

Proposed functionality

It is common for modular interfaces (SFP+ for example) on devices (SFP+ for example) we have transivers that using a single fiber connection (simplex in wdm/bidi mode) or two fiber connections (duplex in Tx/Rx mode) behaving as a single interface.

Thus, it would be interesting to have a checkbox to define whether the module is simplex (unchecked by default to maintain compatibility) or duplex and, by checking this option, the interface changes to two fiber "connectors" fiber (one being Tx and the other Rx) . Another solution would be to treat such interfaces (modular Ethernet) as a "device bay" interface and, treat the modules as a "common" interface (as they really are). When we create the devices to occupy this bay, we identify whether it is simplex or duplex.

PS.: In both approaches, it would be good if we had fields such as: manufacturer, model, range in KM, serial, and laser wavelength (remembering that duplex modules use the same wavelength in Tx and Rx and simplex modules use different wavelengths. Examples: GSTP317-DSL10D is simplex and uses 1310nm and SFP-10G-BX90-U and SFP-10G-BX90-D use Tx1490/Rx1550nm and Tx1550/Rx1490nm respectively. Photos attached). So for duplex it would be just one wavelength field "xxxx nm" and for simplex it would be two fields equivalent to "Tx xxxx nm" "Rx xxxx nm".

Use case

I have a switch with two SFP+ ports. One has a 10G WDM/BIDI module and the other has a duplex module. Both are connected in a Fiber Optic Patch Panel Furukawa. The first is connected by a fiber at position 13. The second is connected by two cables at positions (Tx) 21 and (Rx) 22. The first is possible to map normally, but the second I can only map one of the cables (even though there are two for a single interface).

Database changes

No response

External dependencies

No response

Originally created by @ppcarvalhof on GitHub (Mar 27, 2022). ### NetBox version v3.1.10 ### Feature type Change to existing functionality ### Proposed functionality It is common for modular interfaces (SFP+ for example) on devices (SFP+ for example) we have transivers that using a single fiber connection (simplex in wdm/bidi mode) or two fiber connections (duplex in Tx/Rx mode) behaving as a single interface. Thus, it would be interesting to have a checkbox to define whether the module is simplex (unchecked by default to maintain compatibility) or duplex and, by checking this option, the interface changes to two fiber "connectors" fiber (one being Tx and the other Rx) . Another solution would be to treat such interfaces (modular Ethernet) as a "device bay" interface and, treat the modules as a "common" interface (as they really are). When we create the devices to occupy this bay, we identify whether it is simplex or duplex. PS.: In both approaches, it would be good if we had fields such as: manufacturer, model, range in KM, serial, and laser wavelength (remembering that duplex modules use the same wavelength in Tx and Rx and simplex modules use different wavelengths. Examples: GSTP317-DSL10D is simplex and uses 1310nm and SFP-10G-BX90-U and SFP-10G-BX90-D use Tx1490/Rx1550nm and Tx1550/Rx1490nm respectively. Photos attached). So for duplex it would be just one wavelength field "xxxx nm" and for simplex it would be two fields equivalent to "Tx xxxx nm" "Rx xxxx nm". ### Use case I have a switch with two SFP+ ports. One has a 10G WDM/BIDI module and the other has a duplex module. Both are connected in a Fiber Optic Patch Panel Furukawa. The first is connected by a fiber at position 13. The second is connected by two cables at positions (Tx) 21 and (Rx) 22. The first is possible to map normally, but the second I can only map one of the cables (even though there are two for a single interface). ### Database changes _No response_ ### External dependencies _No response_
adam added the type: featurestatus: revisions needed labels 2025-12-29 19:38:43 +01:00
adam closed this issue 2025-12-29 19:38:43 +01:00
adam commented 2025-12-29 19:38:43 +01:00
Author
Owner
Copy Link

@martinum4 commented on GitHub (Mar 27, 2022):

I solved this for me by giving all fiber patch panels back ports with two positions, when i deploy BiDi i just generate a new front port.
All my front ports in my device types contain [nn].1, when i deploy BiDi i just add a [nn].2 front ports the appropriate devices.
Example:
grafik

@martinum4 commented on GitHub (Mar 27, 2022): I solved this for me by giving all fiber patch panels back ports with two positions, when i deploy BiDi i just generate a new front port. All my front ports in my device types contain [nn].1, when i deploy BiDi i just add a [nn].2 front ports the appropriate devices. Example: ![grafik](https://user-images.githubusercontent.com/18295403/160297363-f62ceaf8-0c02-4b9f-bba1-32db897e7ef7.png)
adam commented 2025-12-29 19:38:44 +01:00
Author
Owner
Copy Link

@salvador-andes commented on GitHub (Mar 28, 2022):

I love netbox, but this is a limitation for us, since in some cases we use simplex transceivers (which only use one LC port in the ODF), but in other cases we use duplex transceivers, which use two LC ports in the ODF.
Please consider this feature for future releases :)

We have to use IXP Manager's patch panel section as a workaround, but we would love to have everything in Netbox

Here is an example who is it managed in other solutions:

image

It looks like this in the configuration of the ODF port
image

@salvador-andes commented on GitHub (Mar 28, 2022): I love netbox, but this is a limitation for us, since in some cases we use simplex transceivers (which only use one LC port in the ODF), but in other cases we use duplex transceivers, which use two LC ports in the ODF. Please consider this feature for future releases :) We have to use IXP Manager's patch panel section as a workaround, but we would love to have everything in Netbox Here is an example who is it managed in other solutions: <img width="1332" alt="image" src="https://user-images.githubusercontent.com/102494234/160310539-d6542721-5568-4526-a6d3-24ea0878ad52.png"> It looks like this in the configuration of the ODF port <img width="941" alt="image" src="https://user-images.githubusercontent.com/102494234/160310604-c6ffbfd0-def7-4db6-9ea0-555b261d11c9.png">
adam commented 2025-12-29 19:38:44 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 5, 2022):

Thank you for your interest in extending NetBox. Unfortunately, the information you have provided does not constitute an actionable feature request. Per our contributing guide, a feature request must include a thorough description of the proposed functionality, including any database changes, new views or API endpoints, and so on. It must also include a detailed use case justifying its implementation. If you would like to elaborate on your proposal, please modify your post above. If sufficient detail is not added, this issue will be closed.

@jeremystretch commented on GitHub (Apr 5, 2022): Thank you for your interest in extending NetBox. Unfortunately, the information you have provided does not constitute an actionable feature request. Per our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md), a feature request must include a thorough description of the proposed functionality, including any database changes, new views or API endpoints, and so on. It must also include a detailed use case justifying its implementation. If you would like to elaborate on your proposal, please modify your post above. If sufficient detail is not added, this issue will be closed.
adam commented 2025-12-29 19:38:44 +01:00
Author
Owner
Copy Link

@ghost commented on GitHub (Apr 11, 2022):

This could possibly also be solved by allowing an interface to connect to multiple ports using the same cable.

For instance, if you have a fiber distribution panel that is 24 strands, you can create this device 1 of 2 ways. You can either assign it 24 front ports, or 12 front ports.

If you assign it 12 front ports you would only be able to use duplex fiber. You would connect port 1 to an interface and its up to the user to understand that 2 fiber strands equal 1 transmit/receive pair to create a connection to interface X.

If you assign it 24 front ports you now have the flexibility to use simplex OR duplex fiber. The problem here is that you can only assign 1 front port to an interface. If you are a 100% simplex environment that also wouldn't be much of an issue.

The issue arises when you have a mix of duplex AND simplex. In the above example of an FDP with 24 front ports you may have ports 1 and 2 and 3 and 4 all being simplex connections going to 4 different interfaces. The problem is, how do you now assign BOTH ports 5 AND 6 to 1 interface using 1 cable.

If the limitation was removed to be able to assign multiple front ports to 1 interface, and have those ports share the same cable then you would accomplish the main objective.
After that, it's just a matter of drop down selections for cable type to distinguish between simplex/duplex

@ghost commented on GitHub (Apr 11, 2022): This could possibly also be solved by allowing an interface to connect to multiple ports using the same cable. For instance, if you have a fiber distribution panel that is 24 strands, you can create this device 1 of 2 ways. You can either assign it 24 front ports, or 12 front ports. If you assign it 12 front ports you would only be able to use duplex fiber. You would connect port 1 to an interface and its up to the user to understand that 2 fiber strands equal 1 transmit/receive pair to create a connection to interface X. If you assign it 24 front ports you now have the flexibility to use simplex OR duplex fiber. The problem here is that you can only assign 1 front port to an interface. If you are a 100% simplex environment that also wouldn't be much of an issue. The issue arises when you have a mix of duplex AND simplex. In the above example of an FDP with 24 front ports you may have ports 1 and 2 and 3 and 4 all being simplex connections going to 4 different interfaces. The problem is, how do you now assign BOTH ports 5 AND 6 to 1 interface using 1 cable. If the limitation was removed to be able to assign multiple front ports to 1 interface, and have those ports share the same cable then you would accomplish the main objective. After that, it's just a matter of drop down selections for cable type to distinguish between simplex/duplex
adam commented 2025-12-29 19:38:45 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Apr 11, 2022):

I think it would be better to treat a interface as having multiple connection points (upstream and downstream).

@DanSheps commented on GitHub (Apr 11, 2022): I think it would be better to treat a interface as having multiple connection points (upstream and downstream).
adam commented 2025-12-29 19:38:45 +01:00
Author
Owner
Copy Link

@ghost commented on GitHub (Apr 11, 2022):

I think we're saying the same thing. I'm saying it from the perspective of the patch panel, you're saying it from the perspective of the interface.

For multiple front ports to connect to an interface, an interface conversely has to be able to connect to multiple connection points.

@ghost commented on GitHub (Apr 11, 2022): I think we're saying the same thing. I'm saying it from the perspective of the patch panel, you're saying it from the perspective of the interface. For multiple front ports to connect to an interface, an interface conversely has to be able to connect to multiple connection points.
adam commented 2025-12-29 19:38:45 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Apr 11, 2022):

Yes, but you wouldn't have the multiple connections on the front port, as that would likely cause issues elsewhere (lets say someone gets it into their head to connect 2 front ports to a single front port, that is going to cause issues). Instead it would be easier to have 2 connection points per interface.

We don't want to get too complex here (yet), I think in the past when we approached this, we tried to cram too much in to one FR and it ended up biting us in the butt and the model needed to be re-written. If you look at it in another sense, if you have a duplex port, it is a discrete front port for both upstream and downstream on the patch panel, so it should be treated as such when we are thinking about redesigning this to support duplex connections.

@DanSheps commented on GitHub (Apr 11, 2022): Yes, but you wouldn't have the multiple connections on the front port, as that would likely cause issues elsewhere (lets say someone gets it into their head to connect 2 front ports to a single front port, that is going to cause issues). Instead it would be easier to have 2 connection points per interface. We don't want to get too complex here (yet), I think in the past when we approached this, we tried to cram too much in to one FR and it ended up biting us in the butt and the model needed to be re-written. If you look at it in another sense, if you have a duplex port, it is a discrete front port for both upstream and downstream on the patch panel, so it should be treated as such when we are thinking about redesigning this to support duplex connections.
adam commented 2025-12-29 19:38:45 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Apr 11, 2022):

Going to supercede this with: #9102

@DanSheps commented on GitHub (Apr 11, 2022): Going to supercede this with: #9102
adam commented 2025-12-29 19:38:46 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Apr 11, 2022):

Duplicate of #9102

@DanSheps commented on GitHub (Apr 11, 2022): Duplicate of #9102
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: revisions needed 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#6267
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?