starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-13 13:53:31 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

New interface form factors #270

New Issue
Closed
opened 2025-12-29 16:20:23 +01:00 by adam · 7 comments
adam commented 2025-12-29 16:20:23 +01:00
Owner
Copy Link

Originally created by @filiperegis on GitHub (Jul 21, 2016).

Hi,

Is it possible to add Wifi, DOCSIS (Cable) and DAC (Twinax) as a Form Factor for interfaces?

Best Regards,
Filipe.

Originally created by @filiperegis on GitHub (Jul 21, 2016). Hi, Is it possible to add Wifi, DOCSIS (Cable) and DAC (Twinax) as a Form Factor for interfaces? Best Regards, Filipe.
adam added the status: duplicate label 2025-12-29 16:20:23 +01:00
adam closed this issue 2025-12-29 16:20:23 +01:00
adam commented 2025-12-29 16:20:24 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jul 21, 2016):

Could you provide a list of the specific names you'd like to add? For reference, here are the currently defined form factors:

IFACE_FF_CHOICES = [
    [IFACE_FF_VIRTUAL, 'Virtual'],
    [IFACE_FF_100M_COPPER, '10/100M (100BASE-TX)'],
    [IFACE_FF_1GE_COPPER, '1GE (1000BASE-T)'],
    [IFACE_FF_SFP, '1GE (SFP)'],
    [IFACE_FF_10GE_COPPER, '10GE (10GBASE-T)'],
    [IFACE_FF_SFP_PLUS, '10GE (SFP+)'],
    [IFACE_FF_XFP, '10GE (XFP)'],
    [IFACE_FF_QSFP_PLUS, '40GE (QSFP+)'],
]
@jeremystretch commented on GitHub (Jul 21, 2016): Could you provide a list of the specific names you'd like to add? For reference, here are the currently defined form factors: ``` IFACE_FF_CHOICES = [ [IFACE_FF_VIRTUAL, 'Virtual'], [IFACE_FF_100M_COPPER, '10/100M (100BASE-TX)'], [IFACE_FF_1GE_COPPER, '1GE (1000BASE-T)'], [IFACE_FF_SFP, '1GE (SFP)'], [IFACE_FF_10GE_COPPER, '10GE (10GBASE-T)'], [IFACE_FF_SFP_PLUS, '10GE (SFP+)'], [IFACE_FF_XFP, '10GE (XFP)'], [IFACE_FF_QSFP_PLUS, '40GE (QSFP+)'], ] ```
adam commented 2025-12-29 16:20:24 +01:00
Author
Owner
Copy Link

@ryanmerolle commented on GitHub (Jul 22, 2016):

I started working on defining this in the models.py. I used Finisar as a guide to try to be inclusive of the different types of form factors. I'm sure I will find a ton more form factors, but its getting to be a large list.

Here are most of the form factors:

  • QSFP+
  • QSFP28 (100G SFPs aka by some vendors as QSFP100)
  • CXP
  • SFP+
  • SFP
  • X2
  • XENPAK
  • SFF

If we want to be inclusive of the different transceiver types, we may want to split this out into different parts (speed, form/size, model number, wavelength) or make this a custom field? If we want to model this all, it will be a long drop down. Furthermore, I think most people will not find use for all of these types.

More Granular Example (SFP+ options):

  • Various Speeds: 1G, 8G, 10G, 16G, 25G, 25.78G, & 32G
  • Various Protocols: Ethernet, Fibre Channel, SONET/SDH, FTTX, & CPRI
  • Various Wavelengths: 850nm, 1310nm, 1550nm, BiDi, C-Band
  • Other Options: DAC/Twinax Passive, DAC/Twinax Active

Before I work on this, let's agree on how far we want to model this down. Wireless will also add a lot of variation. Furthermore, people will just get annoyed sorting through a list of form factors and variations that they just never used. Similar to the situation with device types. Maybe its a good idea to define parts like we do device types?

This also seems like an overlap with #167, #157, & #20

@ryanmerolle commented on GitHub (Jul 22, 2016): I started working on defining this in the models.py. I used [Finisar](https://www.finisar.com/optical-transceivers) as a guide to try to be inclusive of the different types of form factors. I'm sure I will find a ton more form factors, but its getting to be a large list. Here are most of the form factors: - QSFP+ - QSFP28 (100G SFPs aka by some vendors as QSFP100) - CXP - SFP+ - SFP - X2 - XENPAK - SFF If we want to be inclusive of the different transceiver types, we may want to split this out into different parts (speed, form/size, model number, wavelength) or make this a custom field? If we want to model this all, it will be a long drop down. Furthermore, I think most people will not find use for all of these types. More Granular Example (SFP+ options): - Various Speeds: 1G, 8G, 10G, 16G, 25G, 25.78G, & 32G - Various Protocols: Ethernet, Fibre Channel, SONET/SDH, FTTX, & CPRI - Various Wavelengths: 850nm, 1310nm, 1550nm, BiDi, C-Band - Other Options: DAC/Twinax Passive, DAC/Twinax Active Before I work on this, let's agree on how far we want to model this down. Wireless will also add a lot of variation. Furthermore, people will just get annoyed sorting through a list of form factors and variations that they just never used. Similar to the situation with device types. Maybe its a good idea to define parts like we do device types? This also seems like an overlap with #167, #157, & #20
adam commented 2025-12-29 16:20:24 +01:00
Author
Owner
Copy Link

@ryanmerolle commented on GitHub (Jul 22, 2016):

http://www.ethernetalliance.org/the-2015-ethernet-roadmap-2/

I'm not finding better article or table with the different standardized Ethernet interfaces, but the above was helpful. It probably makes sense to follow their approach of module form factor, copper types (including on board and twinax), fiber (SM and MM), Ethernet vs WDM vs whatever else, and then link speed. Defining a form factor as "splittable" or as a parent of sub interfaces for a split out cable seems more and more useful.

@ryanmerolle commented on GitHub (Jul 22, 2016): http://www.ethernetalliance.org/the-2015-ethernet-roadmap-2/ I'm not finding better article or table with the different standardized Ethernet interfaces, but the above was helpful. It probably makes sense to follow their approach of module form factor, copper types (including on board and twinax), fiber (SM and MM), Ethernet vs WDM vs whatever else, and then link speed. Defining a form factor as "splittable" or as a parent of sub interfaces for a split out cable seems more and more useful.
adam commented 2025-12-29 16:20:24 +01:00
Author
Owner
Copy Link

@filiperegis commented on GitHub (Jul 22, 2016):

I agree with @ryanmerolle on diversity of interface form factors and the annoyance of sorting a long list for most people.
I suggest the solution of extensibility of this field, like this:

  1. Change to a custom field. It's now a entity on data model stored on database.
  2. The system comes pre-populated with most used types, like the current ones.

Additionally, make tags available to every entity, allowing maximum flexibility. You enter an interface name and description, but depending of other characteristics you may want to define a wave length, which doesn't make sense to most interfaces. So you don't need this attribute in data-model, but can add this information with a tag.

@filiperegis commented on GitHub (Jul 22, 2016): I agree with @ryanmerolle on diversity of interface form factors and the annoyance of sorting a long list for most people. I suggest the solution of extensibility of this field, like this: 1) Change to a custom field. It's now a entity on data model stored on database. 2) The system comes pre-populated with most used types, like the current ones. Additionally, make tags available to every entity, allowing maximum flexibility. You enter an interface name and description, but depending of other characteristics you may want to define a wave length, which doesn't make sense to most interfaces. So you don't need this attribute in data-model, but can add this information with a tag.
adam commented 2025-12-29 16:20:25 +01:00
Author
Owner
Copy Link

@kenspi commented on GitHub (Jul 22, 2016):

My concern is physical "form factor" and speed/standard are not necessarily synonymous. Much like RJ45 aka 8P8C can support 10BASE-T up through 10GBASE-T, as well as console, SFP's can support both ethernet and FibreChannel. Same holds true for SFP+ and CX4. As noted in #167, data centers are not limited to ethernet/802.3 variants. Obviously having every standard available would be excessive, but I think that can be tempered by limiting the "form factor" to the physical connection type, and not including the standard that's using it. These could be left to a separate field like "technology" or "standard". Such "standards" could further be limited to "1GE", "10GE", and so on, rather than "1GE (1000BASE-T)", "1GE (SFP)", and so on. The form factor would define whether it's BASE-T versus SFP.

@kenspi commented on GitHub (Jul 22, 2016): My concern is physical "form factor" and speed/standard are not necessarily synonymous. Much like RJ45 aka 8P8C can support 10BASE-T up through 10GBASE-T, as well as console, SFP's can support both ethernet and FibreChannel. Same holds true for SFP+ and CX4. As noted in #167, data centers are not limited to ethernet/802.3 variants. Obviously having every standard available would be excessive, but I think that can be tempered by limiting the "form factor" to the physical connection type, and not including the standard that's using it. These could be left to a separate field like "technology" or "standard". Such "standards" could further be limited to "1GE", "10GE", and so on, rather than "1GE (1000BASE-T)", "1GE (SFP)", and so on. The form factor would define whether it's BASE-T versus SFP.
adam commented 2025-12-29 16:20:25 +01:00
Author
Owner
Copy Link

@ryanmerolle commented on GitHub (Jul 22, 2016):

@kenspi I'm with you on form factor vs all the other attributes. I am saying module/form factor type (SFP, SFP+, QSFP+/28/100, X2, XenPak, SFF, copper on board, etc). The rest would just be model numbers, link speed, protocols, and other custom attributes/standards.

@ryanmerolle commented on GitHub (Jul 22, 2016): @kenspi I'm with you on form factor vs all the other attributes. I am saying module/form factor type (SFP, SFP+, QSFP+/28/100, X2, XenPak, SFF, copper on board, etc). The rest would just be model numbers, link speed, protocols, and other custom attributes/standards.
adam commented 2025-12-29 16:20:25 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jul 28, 2016):

Folding this into #167. Please feel free to post lists of suggested new form factors there, and I'll try to knock them all out at once.

@jeremystretch commented on GitHub (Jul 28, 2016): Folding this into #167. Please feel free to post lists of suggested new form factors there, and I'll try to knock them all out at once.
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: duplicate
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#270
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?