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

Form factor for coax connectors #2356

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

Originally created by @candlerb on GitHub (Feb 7, 2019).

Environment

  • Python version: 3.5.2
  • NetBox version: 2.5.5

Proposed Functionality

Add form factors for RF connectors: either just generic "Coax", or common specific ones like Belling-Lee, BNC, F, N, UHF.

Use Case

I have a data centre where we have satellite feeds presented on F connectors into multiswitches, and the multiswitches in turn have coax connections to tuner cards dedicated satellite receivers and servers with multi-input PCI tuner cards. Also DVB-T into tuner cards.

Database Changes

None. The form factors are a static list of integers in code.

External Dependencies

None.

Originally created by @candlerb on GitHub (Feb 7, 2019). ### Environment * Python version: 3.5.2 * NetBox version: 2.5.5 ### Proposed Functionality Add form factors for [RF connectors](https://en.wikipedia.org/wiki/List_of_RF_connector_types): either just generic "Coax", or common specific ones like Belling-Lee, BNC, F, N, UHF. ### Use Case I have a data centre where we have satellite feeds presented on F connectors into multiswitches, and the multiswitches in turn have coax connections to tuner cards dedicated satellite receivers and servers with multi-input PCI tuner cards. Also DVB-T into tuner cards. ### Database Changes None. The form factors are a static list of integers in code. ### External Dependencies None.
adam added the type: feature label 2025-12-29 17:25:12 +01:00
adam closed this issue 2025-12-29 17:25:12 +01:00
adam commented 2025-12-29 17:25:13 +01:00
Author
Owner
Copy Link

@pernwall commented on GitHub (Feb 8, 2019):

I would also have good use of this, I'm about to implement Netbox for a TV Broadcaster, and we have a lot of video equipment with COAX cables and SDI connections. Would it also be possible to add video (eg. different types of SDI) as an interface form factor? I'm very new to Netbox, therefor I'm not really sure what would be the best way to do it?

@pernwall commented on GitHub (Feb 8, 2019): I would also have good use of this, I'm about to implement Netbox for a TV Broadcaster, and we have a lot of video equipment with COAX cables and SDI connections. Would it also be possible to add video (eg. different types of SDI) as an interface form factor? I'm very new to Netbox, therefor I'm not really sure what would be the best way to do it?
adam commented 2025-12-29 17:25:14 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Feb 8, 2019):

This sounds out of scope for NetBox. We've made the conscious decision to support only network interfaces to limit scope creep.

@jeremystretch commented on GitHub (Feb 8, 2019): This sounds out of scope for NetBox. We've made the conscious decision to support only network interfaces to limit scope creep.
adam commented 2025-12-29 17:25:14 +01:00
Author
Owner
Copy Link

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

This sounds out of scope for NetBox. We've made the conscious decision to support only network interfaces to limit scope creep.

What about PON interfaces? Does that count as a "network interface" or not? I need these too.

It seems fairly arbitrary distinction, and it's currently implemented very inconsistently. Note that:

  • Several types of non-IP 'interface' are already included: e.g. stacking cables, fibre channel. You can't assign an IP address to a stacking cable port. You can argue whether or not fibre channel is a "network interface", but SAS and SATA cables are functionally very similar.
  • A 'frontport' or 'rearport' has a physical interface type (e.g. LC or 8P8C), whereas an 'interface' has a layer 2 type (e.g. 1000baseT) or a modular type (e.g. SFP). However, you create a cable with SFP at one end and (single) LC at the other. This is mixing layers: one end is network, the other end is physical.
  • Console ports and power ports are not network interfaces

I think it would make more sense to have a single physical "port" with a physical form factor: if it's C13 it's power, if it's LC it's fibre, if it's SFP it takes an SFP module - with an optional IP interface attached. You could have a checkbox to indicate if the port or connector type is IP-capable (in the same way that certain Device Roles can be marked as usable for Virtual Machines)

The MAC and IP settings could be fields on the port (ignored for non-IP ports), or on a separate interface object linked to a parent port. Separating them has some advantages:

  • an IP interface with no port is a virtual interface
  • multiple IP interfaces on one physical port => tagged VLANs
  • multiple IP interfaces on one physical port => QSFP
  • the IP interface may be known to the OS by a different name than the physical port. (For example: FreeBSD and various flavours of Linux and FreeBSD name their ethernet ports differently)

But sorry, I digress from the topic of this ticket.

@candlerb commented on GitHub (Feb 13, 2019): > This sounds out of scope for NetBox. We've made the conscious decision to support only network interfaces to limit scope creep. What about PON interfaces? Does that count as a "network interface" or not? I [need these too](https://github.com/digitalocean/netbox/issues/2882). It seems fairly arbitrary distinction, and it's currently implemented very inconsistently. Note that: * Several types of non-IP 'interface' are already included: e.g. stacking cables, fibre channel. You can't assign an IP address to a stacking cable port. You can argue whether or not fibre channel is a "network interface", but SAS and SATA cables are functionally very similar. * A 'frontport' or 'rearport' has a physical interface type (e.g. LC or 8P8C), whereas an 'interface' has a layer 2 type (e.g. 1000baseT) or a modular type (e.g. SFP). However, you create a cable with SFP at one end and (single) LC at the other. This is mixing layers: one end is network, the other end is physical. * Console ports and power ports are not network interfaces I think it would make more sense to have a single physical "port" with a physical form factor: if it's C13 it's power, if it's LC it's fibre, if it's SFP it takes an SFP module - with an optional IP interface attached. You could have a checkbox to indicate if the port or connector type is IP-capable (in the same way that certain Device Roles can be marked as usable for Virtual Machines) The MAC and IP settings could be fields on the port (ignored for non-IP ports), or on a separate interface object linked to a parent port. Separating them has some advantages: * an IP interface with no port is a virtual interface * multiple IP interfaces on one physical port => tagged VLANs * multiple IP interfaces on one physical port => QSFP * the IP interface may be known to the OS by a different name than the physical port. (For example: FreeBSD and various flavours of Linux and FreeBSD name their ethernet ports differently) But sorry, I digress from the topic of this ticket.
adam commented 2025-12-29 17:25:14 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Feb 13, 2019):

All we're talking about in this issue is the proposal to add coaxial connectors. Let me phrase it this way: Are these interfaces being used to send and receive packets of data which are forwarded based on a destination address?

@jeremystretch commented on GitHub (Feb 13, 2019): All we're talking about in this issue is the proposal to add coaxial connectors. Let me phrase it this way: Are these interfaces being used to send and receive packets of data which are forwarded based on a destination address?
adam commented 2025-12-29 17:25:14 +01:00
Author
Owner
Copy Link

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

Are these interfaces being used to send and receive packets of data which are forwarded based on a destination address?

They are being used to carry MP4-encoded digital TV transmissions. The MP4 frames are multiplexed onto higher bitrate streams and then modulated onto RF carriers. However there is no "destination address", it's broadcast.

At layer 1, they are also black cables which plug into ports on boxes (hundreds of them). When somebody asks me "what is plugged into port 4 on box A?" I want to be able to tell them what's on the other end of the cable.

@candlerb commented on GitHub (Feb 13, 2019): > Are these interfaces being used to send and receive packets of data which are forwarded based on a destination address? They are being used to carry MP4-encoded digital TV transmissions. The MP4 frames are multiplexed onto higher bitrate streams and then modulated onto RF carriers. However there is no "destination address", it's broadcast. At layer 1, they are also black cables which plug into ports on boxes (hundreds of them). When somebody asks me "what is plugged into port 4 on box A?" I want to be able to tell them what's on the other end of the cable.
adam commented 2025-12-29 17:25:14 +01:00
Author
Owner
Copy Link

@tb-killa commented on GitHub (Feb 14, 2019):

Are these interfaces being used to send and receive packets of data which are forwarded based on a destination address?

We use Micro DSLAM Technology where a coaxial cable is used instead of a network cable between Switches or other active network components.
This sort are often used in various hotels.

@tb-killa commented on GitHub (Feb 14, 2019): > Are these interfaces being used to send and receive packets of data which are forwarded based on a destination address? We use Micro DSLAM Technology where a coaxial cable is used instead of a network cable between Switches or other active network components. This sort are often used in various hotels.
adam commented 2025-12-29 17:25:14 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Mar 6, 2019):

Could someone provide a list of form factors

@DanSheps commented on GitHub (Mar 6, 2019): Could someone provide a list of form factors
adam commented 2025-12-29 17:25:15 +01:00
Author
Owner
Copy Link

@candlerb commented on GitHub (Mar 6, 2019):

Oooh, there are loads :-)

The ones I deal with regularly:

  • RF connector
    • Belling-Lee
    • BNC
    • F-type
    • N-type
    • SMA

That plus "Other" would probably cover quite a wide range of uses. These would also need to be available as Front Ports and Rear Ports as well as Interfaces, to allow for RF patch panels.

I can completely understand the reluctance to add these, given that the logical follow-on is to add audio connectors (RCA, quarter-inch jack, XLR etc).

Hopefully you can understand why: Netbox does make a good match for broadcast suites. They use almost exclusively the same 19" racks as data centres, and they have patch panels plus a ton of cabling to manage. It's just that the cabling isn't all ethernet and serial.

I wonder if it's time to reconsider #84 and make the port types customisable? After all, nobody would expect a hard-coded list of Platforms or Manufacturers.

@candlerb commented on GitHub (Mar 6, 2019): Oooh, there are [loads](https://en.wikipedia.org/wiki/List_of_RF_connector_types) :-) The ones I deal with regularly: * *RF connector* * Belling-Lee * BNC * F-type * N-type * SMA That plus "Other" would probably cover quite a wide range of uses. These would also need to be available as Front Ports and Rear Ports as well as Interfaces, to allow for RF patch panels. I can completely understand the reluctance to add these, given that the logical follow-on is to add [audio connectors](https://en.wikipedia.org/wiki/Audio_and_video_interfaces_and_connectors) (RCA, quarter-inch jack, XLR etc). Hopefully you can understand why: Netbox *does* make a good match for broadcast suites. They use almost exclusively the same 19" racks as data centres, and they have patch panels plus a ton of cabling to manage. It's just that the cabling isn't all ethernet and serial. I wonder if it's time to reconsider #84 and make the port types customisable? After all, nobody would expect a hard-coded list of Platforms or Manufacturers.
adam commented 2025-12-29 17:25:15 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Mar 13, 2019):

Hopefully you can understand why: Netbox does make a good match for broadcast suites. They use almost exclusively the same 19" racks as data centres, and they have patch panels plus a ton of cabling to manage. It's just that the cabling isn't all ethernet and serial.

I get that, I do. But this use case unfortunately isn't in scope for NetBox. I've said this before: As an IPAM/DCIM application, NetBox is inherently vulnerable to scope creep, because it's so easy to start tacking on things that are only tangentially related to its core purpose. In order to ensure the long-term maintainability of the product, the DCIM component of NetBox is intentionally limited to modeling network, console, and power objects. Any proposal to add anything even slightly outside this definition must be rejected. Otherwise, the scope of the product stretches that much further, inviting yet more slightly-out-of-scope proposals in a perpetual cycle.

It's clear from the description you provided above that these are not network interfaces, so it would not make sense to model them using an object expressly intended to represent network interfaces.

@jeremystretch commented on GitHub (Mar 13, 2019): > Hopefully you can understand why: Netbox does make a good match for broadcast suites. They use almost exclusively the same 19" racks as data centres, and they have patch panels plus a ton of cabling to manage. It's just that the cabling isn't all ethernet and serial. I get that, I do. But this use case unfortunately isn't in scope for NetBox. I've said this before: As an IPAM/DCIM application, NetBox is inherently vulnerable to scope creep, because it's so easy to start tacking on things that are only tangentially related to its core purpose. In order to ensure the long-term maintainability of the product, the DCIM component of NetBox is intentionally limited to modeling network, console, and power objects. Any proposal to add anything even slightly outside this definition must be rejected. Otherwise, the scope of the product stretches that much further, inviting yet more slightly-out-of-scope proposals in a perpetual cycle. It's clear from the description you provided above that these are not network interfaces, so it would not make sense to model them using an object expressly intended to represent network interfaces.
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 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#2356
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?