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 DOCSIS Interface Type(s) #6407

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

Originally created by @sleepinggenius2 on GitHub (Apr 26, 2022).

NetBox version

v3.2.1

Feature type

Data model extension

Proposed functionality

Add a new interface type for DOCSIS interfaces. Ideally, it would be nice to include the maximum supported version, so we could have ones for the following, though I'm not sure 1.0 or 1.1 would really be relevant anymore:

  • DOCSIS 1.0
  • DOCSIS 1.1
  • DOCSIS 2.0
  • DOCSIS 3.0
  • DOCSIS 3.1
  • DOCSIS 4.0

Use case

This would be useful when modeling CMTS/CCAP or cable modem devices. While it can be modeled by using the Other type today, I see that there is already a type for ATM / xDSL, so I think this would be appropriate as well. Adding multiple types for the maximum supported versions would be useful for reporting purposes, but I also understand just using a single type, like how xDSL was consolidated.

Database changes

None

External dependencies

None

Originally created by @sleepinggenius2 on GitHub (Apr 26, 2022). ### NetBox version v3.2.1 ### Feature type Data model extension ### Proposed functionality Add a new interface type for DOCSIS interfaces. Ideally, it would be nice to include the maximum supported version, so we could have ones for the following, though I'm not sure 1.0 or 1.1 would really be relevant anymore: * DOCSIS 1.0 * DOCSIS 1.1 * DOCSIS 2.0 * DOCSIS 3.0 * DOCSIS 3.1 * DOCSIS 4.0 ### Use case This would be useful when modeling CMTS/CCAP or cable modem devices. While it can be modeled by using the *Other* type today, I see that there is already a type for ATM / xDSL, so I think this would be appropriate as well. Adding multiple types for the maximum supported versions would be useful for reporting purposes, but I also understand just using a single type, like how xDSL was consolidated. ### Database changes None ### External dependencies None
adam added the type: featurepending closure labels 2025-12-29 19:40:19 +01:00
adam closed this issue 2025-12-29 19:40:20 +01:00
adam commented 2025-12-29 19:40:20 +01:00
Author
Owner
Copy Link

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

I would be okay adding a single DOCSIS interface type in this fashion:

COAX

  • DOCSIS

I don't think we need one for every conceivable DOCSIS specification, especially given the precident already set with ATM / xDSL. My understand (I am not a docsis engineer), the physical interface doesn't change much like it does for example between SFP+ and SFP28.

@DanSheps commented on GitHub (Apr 28, 2022): I would be okay adding a single DOCSIS interface type in this fashion: ### COAX * DOCSIS I don't think we need one for every conceivable DOCSIS specification, especially given the precident already set with ATM / xDSL. My understand (I am not a docsis engineer), the physical interface doesn't change much like it does for example between SFP+ and SFP28.
adam commented 2025-12-29 19:40:21 +01:00
Author
Owner
Copy Link

@sleepinggenius2 commented on GitHub (Apr 28, 2022):

I'm good with that. From a physical standpoint, it is typically an F Connector, regardless of the digital or analog RF protocol that is being transmitted. Do you think it would make more sense to make it even more generic to just be an F Connector from a physical standpoint? That would then support DOCSIS, MoCA, CATV, or whatever other RF protocol is being used.

That does go a bit against the current precedent of distinguishing not just physical connector, but also protocol/signaling. For example, SFP+ (10GE) is specifically called out as being Ethernet, and SFP+ (8GFC) and SFP+ (16GFC) are specifically called out as FibreChannel, but there is a type for OC-192/STM-64 and no way to also indicate if it is using an SFP+ form factor optic. I ran into a similar issues trying to represent a fixed LC duplex connector for a 10G interface, as the only fixed 10G option is 10GBASE-T, and a 10/100ME SFP, as the SFP options only go down to 1GE. Maybe there's an opportunity to start decoupling the form factor and protocol/signaling for some of these interface types.

Following a similar convention, we could have something like F Connector (DOCSIS), F Connector (MoCA), F Connector (CATV). Unfortunately, I know DOCSIS and video can coexist together, so that could throw a bit of a wrench into things.

Update: I have been informed by our video engineers that ASI uses BNC connectors. I know there have been proposals in the past that have rejected more generic RF modeling, so I am comfortable with limiting this to DOCSIS and potentially MoCA, as they are used for network connectivity with MAC addresses, IPs, etc. I have also found that the Cisco cBR-8 actually uses a UCH.8 modular connector (8 x MCX connectors) on the PIC cards and a cable to break out to F connectors. I don't see MCX (micro coaxial) connectors as an option for front/rear ports currently.

At some point, it would be nice to have the cable type options limited to only the ones that make sense for the interface that they are connecting to, like it being Coax in this case. That's something I've been considering creating a custom validator at least for, and one of the reasons I'm just trying to make sure we set a good precedent going forward on all of this.

@sleepinggenius2 commented on GitHub (Apr 28, 2022): I'm good with that. From a physical standpoint, it is typically an F Connector, regardless of the digital or analog RF protocol that is being transmitted. Do you think it would make more sense to make it even more generic to just be an F Connector from a physical standpoint? That would then support DOCSIS, MoCA, CATV, or whatever other RF protocol is being used. That does go a bit against the current precedent of distinguishing not just physical connector, but also protocol/signaling. For example, SFP+ (10GE) is specifically called out as being Ethernet, and SFP+ (8GFC) and SFP+ (16GFC) are specifically called out as FibreChannel, but there is a type for OC-192/STM-64 and no way to also indicate if it is using an SFP+ form factor optic. I ran into a similar issues trying to represent a fixed LC duplex connector for a 10G interface, as the only fixed 10G option is 10GBASE-T, and a 10/100ME SFP, as the SFP options only go down to 1GE. Maybe there's an opportunity to start decoupling the form factor and protocol/signaling for some of these interface types. Following a similar convention, we could have something like F Connector (DOCSIS), F Connector (MoCA), F Connector (CATV). Unfortunately, I know DOCSIS and video can coexist together, so that could throw a bit of a wrench into things. ***Update:** I have been informed by our video engineers that ASI uses BNC connectors. I know there have been proposals in the past that have rejected more generic RF modeling, so I am comfortable with limiting this to DOCSIS and potentially MoCA, as they are used for network connectivity with MAC addresses, IPs, etc. I have also found that the Cisco cBR-8 actually uses a UCH.8 modular connector (8 x MCX connectors) on the PIC cards and a cable to break out to F connectors. I don't see MCX (micro coaxial) connectors as an option for front/rear ports currently.* At some point, it would be nice to have the cable type options limited to only the ones that make sense for the interface that they are connecting to, like it being Coax in this case. That's something I've been considering creating a custom validator at least for, and one of the reasons I'm just trying to make sure we set a good precedent going forward on all of this.
adam commented 2025-12-29 19:40:21 +01:00
Author
Owner
Copy Link

@martinum4 commented on GitHub (Apr 29, 2022):

Maybe there's an opportunity to start decoupling the form factor and protocol/signaling for some of these interface types.

Yes, i think now that NetBox supports more wireless features, the coax-connectors could come in handy too.

Maybe this could be handled by a "two-stage-dropdown" (not a developer, so this might not be the right wording) where first the physical connection is selected and after that the protocol which is based on it.

@martinum4 commented on GitHub (Apr 29, 2022): > Maybe there's an opportunity to start decoupling the form factor and protocol/signaling for some of these interface types. Yes, i think now that NetBox supports more wireless features, the coax-connectors could come in handy too. Maybe this could be handled by a "two-stage-dropdown" (not a developer, so this might not be the right wording) where first the physical connection is selected and after that the protocol which is based on it.
adam commented 2025-12-29 19:40:21 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jun 28, 2022):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Jun 28, 2022): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. **Do not** attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 19:40:21 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jul 28, 2022):

This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.

@github-actions[bot] commented on GitHub (Jul 28, 2022): This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.
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 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#6407
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?