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 console port form factors #1536

New Issue
Closed
opened 2025-12-29 16:32:46 +01:00 by adam · 6 comments
adam commented 2025-12-29 16:32:46 +01:00
Owner
Copy Link

Originally created by @explody on GitHub (Feb 6, 2018).

Issue type

[ X ] Feature request

The explanation here is mostly forklifted from its PR as this was also discussed at some length in #167. Some of the language in here relates the the content of the PR.

I propose two one enhancement

  • 3 Additional form factors for serial network interfaces (dropped, as this is too much of an edge case)

    • DE9
    • DB25
    • RJ45

  • Adding form factor selection for console ports and console server ports as well as their related templates.

    • RJ45
    • DE9
    • DB25
    • USB to Serial
    • Micro USB to Serial
    • Mini USB to Serial
    • KVM (offering a generic 'KVM' type to distinguish from Serial, but not go down a rathole of connector types)

The rationale here is that even now, there are machines with call-home on landlines that use serial-to-modem for that connection. In particular, door access control systems and the like in our DCs and telco spaces often have old or unusual connections. The added serial types cover the most common.

For the console port form factors, it is because we determined that nearly every device we found has one or more console ports, but not all the same type or quantity of each. Specifying a FF for the console connections allows a user to more thoroughly plan interconnections between devices such as with network, without, IMHO, bogging down in too much detail.

I added the FF to the console port table, but I did not enable bulk editing since there's really only the one setting per port. Might make sense later if it were worthwhile to record baud rate or other serial settings.

Originally created by @explody on GitHub (Feb 6, 2018). ### Issue type [ X ] Feature request <!-- An enhancement of existing functionality --> The explanation here is mostly forklifted from its PR as this was also discussed at some length in #167. Some of the language in here relates the the content of the PR. I propose ~~two~~ one enhancement * ~~3 Additional form factors for serial network interfaces~~ (dropped, as this is too much of an edge case) * ~~DE9~~ * ~~DB25~~ * ~~RJ45~~ * Adding form factor selection for console ports and console server ports as well as their related templates. * RJ45 * DE9 * DB25 * USB to Serial * Micro USB to Serial * Mini USB to Serial * KVM (offering a generic 'KVM' type to distinguish from Serial, but not go down a rathole of connector types) The rationale here is that even now, there are machines with call-home on landlines that use serial-to-modem for that connection. In particular, door access control systems and the like in our DCs and telco spaces often have old or unusual connections. The added serial types cover the most common. For the console port form factors, it is because we determined that nearly every device we found has one or more console ports, but not all the same type or quantity of each. Specifying a FF for the console connections allows a user to more thoroughly plan interconnections between devices such as with network, without, IMHO, bogging down in too much detail. I added the FF to the console port table, but I did not enable bulk editing since there's really only the one setting per port. Might make sense later if it were worthwhile to record baud rate or other serial settings.
adam added the status: acceptedtype: feature labels 2025-12-29 16:32:46 +01:00
adam closed this issue 2025-12-29 16:32:46 +01:00
adam commented 2025-12-29 16:32:47 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Feb 21, 2018):

The litmus test for whether something counts as a network interface is generally "can you put an IP address on it, and is it still in common use?" Additionally, "form factor" is a misnomer in this instance (I'd actually like to rename it a some point) as it describes a physical interface type like 1000BASE-TX or SFP+. So we wouldn't add RJ-45, for example, because several Ethernet standards employ it. And I don't know of any DB25/DE9 interfaces which support IP routing still in common use.

As for the console side, NetBox doesn't currently track form factor for console ports. We can certainly implement it at some point (as well as bitrate and perhaps other attributes), but more research is necessary to determine what would be appropriate. It might be best to raise this discussion on the mailing list first for general discussion before we propose a list here. (Form factors have been a fairly active topic of discussion in the past.)

@jeremystretch commented on GitHub (Feb 21, 2018): The litmus test for whether something counts as a network interface is generally "can you put an IP address on it, and is it still in common use?" Additionally, "form factor" is a misnomer in this instance (I'd actually like to rename it a some point) as it describes a physical interface type like 1000BASE-TX or SFP+. So we wouldn't add RJ-45, for example, because several Ethernet standards employ it. And I don't know of any DB25/DE9 interfaces which support IP routing still in common use. As for the console side, NetBox doesn't currently track form factor for console ports. We can certainly implement it at some point (as well as bitrate and perhaps other attributes), but more research is necessary to determine what would be appropriate. It might be best to raise this discussion on the [mailing list](https://groups.google.com/forum/#!forum/netbox-discuss) first for general discussion before we propose a list here. (Form factors have been a fairly active topic of discussion in the past.)
adam commented 2025-12-29 16:32:47 +01:00
Author
Owner
Copy Link

@explody commented on GitHub (Feb 28, 2018):

re:Network interfaces, I think that's reasonable. We definitely have DE-9 interfaces connected to modems on some ancient gear but at this point, it's esoteric and certainly not in common use. That's also a very small change, only in the constants, and of less value than interface types for console connections. I'll mark out that part from the original post.

re: "form factor", no argument on that either. I used that verbiage just to follow the naming patterns that were already in place in the constants, e.g. "IFACE_FF_XXXX". I agree there's probably different and/or better ways they could be described but I didn't address that here.

In general, the primary request is for form factor/interface type for console connections. I'll follow up on the ML.

@explody commented on GitHub (Feb 28, 2018): re:Network interfaces, I think that's reasonable. We definitely have DE-9 interfaces connected to modems on some ancient gear but at this point, it's esoteric and certainly not in common use. That's also a very small change, only in the constants, and of less value than interface types for console connections. I'll mark out that part from the original post. re: "form factor", no argument on that either. I used that verbiage just to follow the naming patterns that were already in place in the constants, e.g. "IFACE_FF_XXXX". I agree there's probably different and/or better ways they could be described but I didn't address that here. In general, the primary request is for form factor/interface type for console connections. I'll follow up on the ML.
adam commented 2025-12-29 16:32:47 +01:00
Author
Owner
Copy Link

@alexjhart commented on GitHub (Jan 18, 2019):

I'd like to see the ability to track baud rate of the console port on a device. My goal is to use that data to configure serial console server. I assume this is a fine issue to add this to, rather than separate feature request that gets linked back. Connector type is less important to me, but I could see its usefulness as well.

@alexjhart commented on GitHub (Jan 18, 2019): I'd like to see the ability to track baud rate of the console port on a device. My goal is to use that data to configure serial console server. I assume this is a fine issue to add this to, rather than separate feature request that gets linked back. Connector type is less important to me, but I could see its usefulness as well.
adam commented 2025-12-29 16:32:47 +01:00
Author
Owner
Copy Link

@candlerb commented on GitHub (Feb 7, 2019):

The litmus test for whether something counts as a network interface is generally "can you put an IP address on it, and is it still in common use?"

Not all device-to-device connections carry IP, and yet they are important parts of data centre infrastructure which still need to be tracked. Fibre Channel SAN is one example.

The design of Netbox has special cases for "console" and "power" connections (although having form factors for power connectors could be useful too) - but apart from those, everything else has to be modelled as "interface", even if it's non-IP.

@candlerb commented on GitHub (Feb 7, 2019): > The litmus test for whether something counts as a network interface is generally "can you put an IP address on it, and is it still in common use?" Not all device-to-device connections carry IP, and yet they are important parts of data centre infrastructure which still need to be tracked. Fibre Channel SAN is one example. The design of Netbox has special cases for "console" and "power" connections (although having form factors for power connectors could be useful too) - but apart from those, everything else has to be modelled as "interface", even if it's non-IP.
adam commented 2025-12-29 16:32:47 +01:00
Author
Owner
Copy Link

@alexjhart commented on GitHub (Oct 30, 2019):

@jeremystretch I don't see baud rate in the commit. Is there a reason this wasn't included?

@alexjhart commented on GitHub (Oct 30, 2019): @jeremystretch I don't see baud rate in the commit. Is there a reason this wasn't included?
adam commented 2025-12-29 16:32:47 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Oct 30, 2019):

@alexjhart Best to break that out into its own FR since the two fields are not dependent on one another. It also needs further discussion to establish e.g. bit vs baud rate, standard speeds, etc.

@jeremystretch commented on GitHub (Oct 30, 2019): @alexjhart Best to break that out into its own FR since the two fields are not dependent on one another. It also needs further discussion to establish e.g. bit vs baud rate, standard speeds, etc.
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#1536
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?