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

Create cable groups to model structured cabling #5730

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

Originally created by @joaolucasmacedo on GitHub (Dec 3, 2021).

NetBox version

v3.0.11

Feature type

New functionality

Proposed functionality

Create "cable groups" to represent horizontal structured cabling systems. Each cable group may represent a set of horizontal cables that may belong to a rack, like a set of cables that begin in a user work area(usually a wall keystone) and terminate inside a rack.
Each cable group may have a number of cables in witch each side represent a rear port(keystone in user's work area) and a front port(the may connect to a patch panel rear port).
Each cable edge inside cable groups may belong to a location, so we can see in which work area inside a site it is located.
Each cable group may belong to a rack.
Each cable group may have a tenant.
Each cable inside a cable group may have length, color, labels, type, etc.

Use case

Today I often use fictional devices to represent what I'm calling "cable groups", to represent set of laying cables inside a building or building area. Each device has a number of front and rear ports, so I can connect each rear port to a patch panel inside a rack. So, each front port (in one of these fictional devices) represents a keystone plug at the desk of a user, and each cable created is a laying horizontal cable.
Cable groups
It is important to me because I model a set of cable just after people has finished the installation project, and I have all certification reports. This way, I can model/document all my cables without necessarily having other device connected on user's side.
I describe each location(work area) where a cable/keystone goes to in the front port's description field of each fictional device because it is not possible to associate with NetBox locations.
So, if there was possible to implement a functionality to represent these set of cables, it would be a great leap forward on cable management and documentation, like where we are involved on cabling projects. Then we could represent all cable infrastructure without necessarily have devices connected to it and document all project details.

Database changes

No response

External dependencies

No response

Originally created by @joaolucasmacedo on GitHub (Dec 3, 2021). ### NetBox version v3.0.11 ### Feature type New functionality ### Proposed functionality Create "cable groups" to represent horizontal structured cabling systems. Each cable group may represent a set of horizontal cables that may belong to a rack, like a set of cables that begin in a user work area(usually a wall keystone) and terminate inside a rack. Each cable group may have a number of cables in witch each side represent a rear port(keystone in user's work area) and a front port(the may connect to a patch panel rear port). Each cable edge inside cable groups may belong to a location, so we can see in which work area inside a site it is located. Each cable group may belong to a rack. Each cable group may have a tenant. Each cable inside a cable group may have length, color, labels, type, etc. ### Use case Today I often use fictional devices to represent what I'm calling "cable groups", to represent set of laying cables inside a building or building area. Each device has a number of front and rear ports, so I can connect each rear port to a patch panel inside a rack. So, each front port (in one of these fictional devices) represents a keystone plug at the desk of a user, and each cable created is a laying horizontal cable. ![Cable groups](https://user-images.githubusercontent.com/66760118/144603254-daaff6eb-6bd2-4ccd-bde1-82549046cd1f.jpg) It is important to me because I model a set of cable just after people has finished the installation project, and I have all certification reports. This way, I can model/document all my cables without necessarily having other device connected on user's side. I describe each location(work area) where a cable/keystone goes to in the front port's description field of each fictional device because it is not possible to associate with NetBox locations. So, if there was possible to implement a functionality to represent these set of cables, it would be a great leap forward on cable management and documentation, like where we are involved on cabling projects. Then we could represent all cable infrastructure without necessarily have devices connected to it and document all project details. ### Database changes _No response_ ### External dependencies _No response_
adam closed this issue 2025-12-29 19:31:58 +01:00
adam commented 2025-12-29 19:31:59 +01:00
Author
Owner
Copy Link

@tb-killa commented on GitHub (Dec 3, 2021):

I like the idea.
I think about something similar but want to call them cable bound because sometimes you have multiple cables in one cable stage for Racks.
It should allow to track multiple cables inside one bound via trace too.

@tb-killa commented on GitHub (Dec 3, 2021): I like the idea. I think about something similar but want to call them cable bound because sometimes you have multiple cables in one cable stage for Racks. It should allow to track multiple cables inside one bound via trace too.
adam commented 2025-12-29 19:31:59 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Dec 3, 2021):

What is different from using a cable group model compared to a "fictional" device under your proposal?

I put "fictional" in quotes because even though you call it fictional, from other persons perspectives a RJ45 connector on a wall is a real device. A device doesn't have to have an IP address, a console connection, a power connection, a OS. A device in NetBox can represent anything physical.

Database changes

No response

Please fill out your proposal more in-depth. There will be some changes so you should at least propose some changes

@DanSheps commented on GitHub (Dec 3, 2021): What is different from using a cable group model compared to a "fictional" device under your proposal? I put "fictional" in quotes because even though you call it fictional, from other persons perspectives a RJ45 connector on a wall is a real device. A device doesn't have to have an IP address, a console connection, a power connection, a OS. A device in NetBox can represent **anything** physical. > ### Database changes > > No response Please fill out your proposal more in-depth. There **will** be some changes so you should at least propose some changes
adam commented 2025-12-29 19:31:59 +01:00
Author
Owner
Copy Link

@joaolucasmacedo commented on GitHub (Dec 4, 2021):

What is different from using a cable group model compared to a "fictional" device under your proposal?

Well, it may be clearer for cabling management/modeling to ha a specific object do handle and shelter a number of cables that belong to a given area. Additionally, it may solve the problem where you want to locate where a specific cable point is, associating it to a NetBox Location, then we can have a much more detailed representation of cabling system. I understand when you say that NetBox can represent anything physical, but I think it is more close to a real world thing than creating a object that have multiple keystones that are not actually inside a rack and have a number of peaces placed on multiple locations.
Maybe if we have a object to shelter some cables an handle them it can be closer to real world and ease the handling of multiple cables inside a building. Also, when we model some connections, typically inside a rack, like routers and servers, it makes sense to connect each cable to ensure a level of true representation. But when modeling large sets of cables connected in a sequential manner on patch panels and on user's desk on the other side is much more complex to do and to (almost) manually create them and connect to each path panel.
If we have a object/functionality like this it may be easier to manage and understand the representation of large access level cabling and enhance the way we create batches of cables. Also, as we associate each end to a specific location it eliminates the need of checking the building's blue print to show where a cable point is.

OBS: I've just figured out the in my picture, on the patch panel, rear ports and front ports are inverted. So, switchs actually connects to front ports.

@joaolucasmacedo commented on GitHub (Dec 4, 2021): > What is different from using a cable group model compared to a "fictional" device under your proposal? > Well, it may be clearer for cabling management/modeling to ha a specific object do handle and shelter a number of cables that belong to a given area. Additionally, it may solve the problem where you want to locate where a specific cable point is, associating it to a NetBox Location, then we can have a much more detailed representation of cabling system. I understand when you say that NetBox can represent anything physical, but I think it is more close to a real world thing than creating a object that have multiple keystones that are not actually inside a rack and have a number of peaces placed on multiple locations. Maybe if we have a object to shelter some cables an handle them it can be closer to real world and ease the handling of multiple cables inside a building. Also, when we model some connections, typically inside a rack, like routers and servers, it makes sense to connect each cable to ensure a level of true representation. But when modeling large sets of cables connected in a sequential manner on patch panels and on user's desk on the other side is much more complex to do and to (almost) manually create them and connect to each path panel. If we have a object/functionality like this it may be easier to manage and understand the representation of large access level cabling and enhance the way we create batches of cables. Also, as we associate each end to a specific location it eliminates the need of checking the building's blue print to show where a cable point is. OBS: I've just figured out the in my picture, on the patch panel, rear ports and front ports are inverted. So, switchs actually connects to front ports.
adam commented 2025-12-29 19:31:59 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Dec 4, 2021):

I still don't see the draw to this approach as opposed to:

Switch [Interface] <=> [Front Port] Patch Panel (Device with type "Patch Panel") [Rear Port] <=> [Rear Port] Termination (Device with DT of "Wall Plate" [Front Port] <=> [Interface] End User Device

Infact, I would argue this is the most correct way to do this type of modelling. Sure, it is a bit of a pain to initially build out, but your inside plant should be relatively static.

I don't see us adding a cable model to already accomodate something that is already currently do-able in NetBox. If you have difficulty adding devices, etc, I suggest you look into scripts to make those tasks easier.

This can all be done in NetBox currently. The only thing I could possibly see is allowing cable groups to "bundle" cables (example 2 cables going to 1 location, or just logically grouping cables per panel). I could also see a model for a generic End-User device, but this is arguably already do-able as well.

So, perhaps only legitimate model(s) are:

  1. Cable Group to support cable bundling but nothing else (no end-devices, no connections, just group currently existing cables together)
  2. Model to model generic end-user devices (but I don't see this being taken up either IMO)
@DanSheps commented on GitHub (Dec 4, 2021): I still don't see the draw to this approach as opposed to: Switch [Interface] <=> [Front Port] Patch Panel (Device with type "Patch Panel") [Rear Port] <=> [Rear Port] Termination (Device with DT of "Wall Plate" [Front Port] <=> [Interface] End User Device Infact, I would argue this is the **most** correct way to do this type of modelling. Sure, it is a bit of a pain to initially build out, but your inside plant should be relatively static. I don't see us adding a cable model to already accomodate something that is already currently do-able in NetBox. If you have difficulty adding devices, etc, I suggest you look into scripts to make those tasks easier. This can all be done in NetBox currently. The only thing I could possibly see is allowing cable groups to "bundle" cables (example 2 cables going to 1 location, or just logically grouping cables per panel). I could also see a model for a generic End-User device, but this is arguably already do-able as well. So, perhaps only legitimate model(s) are: 1. Cable Group to support cable bundling but nothing else (no end-devices, no connections, just group currently existing cables together) 2. Model to model generic end-user devices (but I don't see this being taken up either IMO)
adam commented 2025-12-29 19:32:00 +01:00
Author
Owner
Copy Link

@joaolucasmacedo commented on GitHub (Dec 4, 2021):

That's fair enough. But I still support the idea of cable groups to bundle cables and associate it (optionally) to locations, sites, and racks, just as you said. So it would be easier to locate where cable terminations are inside buildings and work areas.

@joaolucasmacedo commented on GitHub (Dec 4, 2021): That's fair enough. But I still support the idea of cable groups to bundle cables and associate it (optionally) to locations, sites, and racks, just as you said. So it would be easier to locate where cable terminations are inside buildings and work areas.
adam commented 2025-12-29 19:32:00 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Dec 6, 2021):

The problem with that is the location, site, rack can easily be obtained by searching in the endpoints themselves. A filter could be added but think about this. Lets say you have a 300ft Cat6. That could span 1 room, yes, but more then likely there are going to be a bunch of rooms, hallways and other things in between. With a cable group, you would only be able to model one of those.

If you want to re-adjust your FR to just add the cable group for now and nothing else we can give it another look.

@DanSheps commented on GitHub (Dec 6, 2021): The problem with that is the location, site, rack can easily be obtained by searching in the endpoints themselves. A filter could be added but think about this. Lets say you have a 300ft Cat6. That could span 1 room, yes, but more then likely there are going to be a bunch of rooms, hallways and other things in between. With a cable group, you would only be able to model one of those. If you want to re-adjust your FR to just add the cable group for now and nothing else we can give it another look.
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
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#5730
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?