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

Add interface-type 1000BaseBX20-D, 1000BaseBX20-U and 1000BaseBX40-D 1000BaseBX40-U #11737

New Issue
Closed
opened 2025-12-29 21:49:18 +01:00 by adam · 6 comments
adam commented 2025-12-29 21:49:18 +01:00
Owner
Copy Link

Originally created by @xkilian on GitHub (Oct 16, 2025).

NetBox version

v4.4.2

Feature type

Data model extension

Proposed functionality

Add new interface types that are commonly used related to 1000BaseBX.

1000BaseBX20-D
1000BaseBX20-U
1000BaseBX40-D
1000BaseBX40-U
10GBaseBX20-D
10GBaseBX20-U
10GBaseBX40-D
10GBaseBX40-U

Use case

Commnly used in enterprise environments with Cisco, Alcatel and other vendors supported SFPs.
The SFPs are physical different for U and D as they use two different wavelengths for transmit and receive.
It is important to know which type of 1000BaseX SFP is slotted in the equipement,1000BaseBX is a general term that means either a 1000BaseBX-U or 1000BaseBX-D.

As stated below in the comments, 4.4.1 now supports 1000BaseBX-D and U, but I will leave the description above for reference.

Even though they are not an official standard, they are standard in the sense that they are generally available from most manufacturers and need to be tracked the same way as the base case (10GbaseBX-U/D and 1000BaseBX-U/D).

Database changes

Announce that users should migrate their 1000BaseBX interfaces to the appropriate 1000BaseBX-D or U.
Eventually deprecate 1000BaseBX.

External dependencies

No response

Originally created by @xkilian on GitHub (Oct 16, 2025). ### NetBox version v4.4.2 ### Feature type Data model extension ### Proposed functionality Add new interface types that are commonly used related to 1000BaseBX. 1000BaseBX20-D 1000BaseBX20-U 1000BaseBX40-D 1000BaseBX40-U 10GBaseBX20-D 10GBaseBX20-U 10GBaseBX40-D 10GBaseBX40-U ### Use case Commnly used in enterprise environments with Cisco, Alcatel and other vendors supported SFPs. The SFPs are physical different for U and D as they use two different wavelengths for transmit and receive. It is important to know which type of 1000BaseX SFP is slotted in the equipement,1000BaseBX is a general term that means either a 1000BaseBX-U or 1000BaseBX-D. As stated below in the comments, 4.4.1 now supports 1000BaseBX-D and U, but I will leave the description above for reference. Even though they are not an official standard, they are standard in the sense that they are generally available from most manufacturers and need to be tracked the same way as the base case (10GbaseBX-U/D and 1000BaseBX-U/D). ### Database changes Announce that users should migrate their 1000BaseBX interfaces to the appropriate 1000BaseBX-D or U. Eventually deprecate 1000BaseBX. ### External dependencies _No response_
adam added the type: featurepending closurestatus: revisions needed labels 2025-12-29 21:49:18 +01:00
adam closed this issue 2025-12-29 21:49:18 +01:00
adam commented 2025-12-29 21:49:18 +01:00
Author
Owner
Copy Link

@xkilian commented on GitHub (Oct 17, 2025):

Added the U and D prefixes for wavelength designations. Essential with these types of SFPs, as a 1000BaseBX SFP simply does not exist.

@xkilian commented on GitHub (Oct 17, 2025): Added the U and D prefixes for wavelength designations. Essential with these types of SFPs, as a 1000BaseBX SFP simply does not exist.
adam commented 2025-12-29 21:49:18 +01:00
Author
Owner
Copy Link

@sleepinggenius2 commented on GitHub (Oct 20, 2025):

There are already 1000BASE-BX10-D and 1000BASE-BX10-U interface types that were added in v4.4.1. Technically, BX10 is the only defined IEEE standard and the values you are proposing are proprietary/non-standard, even if they might be interoperable between different manufacturers. In our environment, we have seen a variety of different reach values, including the 20km and 40km that you are proposing, as well as 80km and even 160km. There seems to be some consensus around which wavelengths to use for particular reaches, but we've even seen that vary between manufacturers. We are using a "Pluggable" Module Type Profile to capture attributes for the reach, as well as the transmit and receive wavelengths, and other values, like connector type, data rate, form factor, media, and temperature range. So far that has been working really well for us and allows for more flexibility to capture the subtle differences between implementations from different manufacturers, while still adhering to standards-based interface types.

@sleepinggenius2 commented on GitHub (Oct 20, 2025): There are already 1000BASE-BX10-D and 1000BASE-BX10-U interface types that were added in v4.4.1. Technically, BX10 is the only defined IEEE standard and the values you are proposing are proprietary/non-standard, even if they might be interoperable between different manufacturers. In our environment, we have seen a variety of different reach values, including the 20km and 40km that you are proposing, as well as 80km and even 160km. There seems to be some consensus around which wavelengths to use for particular reaches, but we've even seen that vary between manufacturers. We are using a "Pluggable" Module Type Profile to capture attributes for the reach, as well as the transmit and receive wavelengths, and other values, like connector type, data rate, form factor, media, and temperature range. So far that has been working really well for us and allows for more flexibility to capture the subtle differences between implementations from different manufacturers, while still adhering to standards-based interface types.
adam commented 2025-12-29 21:49:19 +01:00
Author
Owner
Copy Link

@xkilian commented on GitHub (Oct 21, 2025):

I will think about this approach using module-types. This does entail modifyin all standard Device-Types to convert modules with pluggable interfaces to become modules, to benefit devices that need more information. More complexe provisioning steps for the benefit of more accurate modeling.
Our installations are more along the Metropolitain scale, so we probably do not have an extreme variety of a regional provider or big datacenter provider would run into.

@xkilian commented on GitHub (Oct 21, 2025): I will think about this approach using module-types. This does entail modifyin all standard Device-Types to convert modules with pluggable interfaces to become modules, to benefit devices that need more information. More complexe provisioning steps for the benefit of more accurate modeling. Our installations are more along the Metropolitain scale, so we probably do not have an extreme variety of a regional provider or big datacenter provider would run into.
adam commented 2025-12-29 21:49:19 +01:00
Author
Owner
Copy Link

@arthanson commented on GitHub (Oct 23, 2025):

@xkilian Can you please link to the specs so we can evaluate.

@arthanson commented on GitHub (Oct 23, 2025): @xkilian Can you please link to the specs so we can evaluate.
adam commented 2025-12-29 21:49:19 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Oct 31, 2025):

This is a reminder that additional information is needed in order to further triage this issue. If the requested details are not provided, the issue will soon be closed automatically.

@github-actions[bot] commented on GitHub (Oct 31, 2025): This is a reminder that additional information is needed in order to further triage this issue. If the requested details are not provided, the issue will soon be closed automatically.
adam commented 2025-12-29 21:49:20 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Nov 7, 2025):

This issue is being closed as no further information has been provided. If you would like to revisit this topic, please first modify your original post to include all the requested detail, and then ask that the issue be reopened.

@github-actions[bot] commented on GitHub (Nov 7, 2025): This issue is being closed as no further information has been provided. If you would like to revisit this topic, please first modify your original post to include all the requested detail, and then ask that the issue be reopened.
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 pending closure 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#11737
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?