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 utilization metric to Patch Panels #9172

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

Originally created by @xiSlickix on GitHub (Jan 30, 2024).

NetBox version

v3.6.6

Feature type

New functionality

Proposed functionality

Similar to the Power and Space Utilization metrics tracks for the power consumption and consumed rack units within a cabinet, I would like to propose the Front and Rear ports on a patch panel track how many ports have been "used" or how many are "available", etc. The two bar graphs (Front and Rear) could be displayed on the "Device" tab for the given patch panel.

Separate Front and Rear fields could be automatically generated based on the type (RJ45, Fiber, MPO, etc.) of patch panel installed in a given cabinet. The summation of each individual patch panel's available capacity could be rolled up at the cabinet level where RU Space and Power are currently displayed today. (The cabinet level roll up may be better suited as its own Feature Request.)

Use case

This feature would assist NetBox users in planning future cable capacity upgrades within a cabinet. This could also assist users in notifying server owners that adding additional cables to their servers could become problematic as capacity dwindles, helping avoid implementation failures.

Additionally, if the organization a user works for has a policy related to keeping at least "x" percent of ports available at any given time, this metric could be used as a trigger to order additional structured cabling to be installed, etc.

Database changes

Unsure. Likely two new fields that are each derived from the number of consumed ports on a given side (front or rear) divided by the number of ports available on a given side. This would allow for a report to be generated that shows the port utilization for every patch panel in NetBox.

External dependencies

None.

Originally created by @xiSlickix on GitHub (Jan 30, 2024). ### NetBox version v3.6.6 ### Feature type New functionality ### Proposed functionality Similar to the Power and Space Utilization metrics tracks for the power consumption and consumed rack units within a cabinet, I would like to propose the Front and Rear ports on a patch panel track how many ports have been "used" or how many are "available", etc. The two bar graphs (Front and Rear) could be displayed on the "Device" tab for the given patch panel. Separate Front and Rear fields could be automatically generated based on the type (RJ45, Fiber, MPO, etc.) of patch panel installed in a given cabinet. The summation of each individual patch panel's available capacity could be rolled up at the cabinet level where RU Space and Power are currently displayed today. (The cabinet level roll up may be better suited as its own Feature Request.) ### Use case This feature would assist NetBox users in planning future cable capacity upgrades within a cabinet. This could also assist users in notifying server owners that adding additional cables to their servers could become problematic as capacity dwindles, helping avoid implementation failures. Additionally, if the organization a user works for has a policy related to keeping at least "x" percent of ports available at any given time, this metric could be used as a trigger to order additional structured cabling to be installed, etc. ### Database changes Unsure. Likely two new fields that are each derived from the number of consumed ports on a given side (front or rear) divided by the number of ports available on a given side. This would allow for a report to be generated that shows the port utilization for every patch panel in NetBox. ### External dependencies None.
adam added the type: feature label 2025-12-29 20:46:32 +01:00
adam closed this issue 2025-12-29 20:46:32 +01:00
adam commented 2025-12-29 20:46:33 +01:00
Author
Owner
Copy Link

@sleepinggenius2 commented on GitHub (Jan 31, 2024):

How do you propose handling modular patch panels, where not all of the modules have been populated yet? We have some that can take 12F or 24F cassettes depending on whether you are using SC or LC connectors, so that complicates utilization calculations. We would want to be able to distinguish between "I'm almost out of available ports and I need to install a new module" or "I'm almost out of available ports and I need to install a new panel."

This also assumes that all the rear ports connect to the same place. We definitely have split panels where some ports are wired to a cable that goes to one location and other ports go to a different location (typically an east/west kind of situation), so a strict panel utilization could introduce additional confusion. Your cabinet-level roll-up would be even more confusing, as most data centers I've seen have centralized racks for aggregating fiber panels to facilitate cross-connects, so rolling up the utilization for all those panels going to all different locations wouldn't be particularly useful.

@sleepinggenius2 commented on GitHub (Jan 31, 2024): How do you propose handling modular patch panels, where not all of the modules have been populated yet? We have some that can take 12F or 24F cassettes depending on whether you are using SC or LC connectors, so that complicates utilization calculations. We would want to be able to distinguish between "I'm almost out of available ports and I need to install a new module" or "I'm almost out of available ports and I need to install a new panel." This also assumes that all the rear ports connect to the same place. We definitely have split panels where some ports are wired to a cable that goes to one location and other ports go to a different location (typically an east/west kind of situation), so a strict panel utilization could introduce additional confusion. Your cabinet-level roll-up would be even more confusing, as most data centers I've seen have centralized racks for aggregating fiber panels to facilitate cross-connects, so rolling up the utilization for all those panels going to all different locations wouldn't be particularly useful.
adam commented 2025-12-29 20:46:33 +01:00
Author
Owner
Copy Link

@mrtn-r commented on GitHub (Feb 2, 2024):

You first need a metric for what a patch port is.

Netbox is quite modular, so it makes no sense to tie this down too much, i'd rather have a general "Mark as utilized when connected"-field which would work with switches too.

IMHO you could just use Tags (for including/excluding ports) and export templates right now to generate overviews

@mrtn-r commented on GitHub (Feb 2, 2024): You first need a metric for what a patch port is. Netbox is quite modular, so it makes no sense to tie this down too much, i'd rather have a general "Mark as utilized when connected"-field which would work with switches too. IMHO you could just use Tags (for including/excluding ports) and export templates right now to generate overviews
adam commented 2025-12-29 20:46:34 +01:00
Author
Owner
Copy Link

@xiSlickix commented on GitHub (Feb 2, 2024):

How do you propose handling modular patch panels, where not all of the modules have been populated yet? We have some that can take 12F or 24F cassettes depending on whether you are using SC or LC connectors, so that complicates utilization calculations. We would want to be able to distinguish between "I'm almost out of available ports and I need to install a new module" or "I'm almost out of available ports and I need to install a new panel."

Perhaps the better term I should use is "Installed Utilization". If you have a fiber panel with cassettes, at the fiber patch panel level, you could show your utilization of the cassettes installed divided by the total available cassette modules. This would give you your cassette capacity. Then, based on the variety and quantity of cassettes installed (similar to server modules with NICs) you could then give an "Installed Utilization" of the consumed ports.

Looking to be able to generate actionable information such as:
"If we go past 80% installed capacity, order another module installed in this month's datacenter capacity planning meeting."
"If we have consumed more than 90% of the modules for cassettes, order another fiber housing patch panel (and perhaps rack it based on rack capacity utilization, etc.)"

This also assumes that all the rear ports connect to the same place. We definitely have split panels where some ports are wired to a cable that goes to one location and other ports go to a different location (typically an east/west kind of situation), so a strict panel utilization could introduce additional confusion. Your cabinet-level roll-up would be even more confusing, as most data centers I've seen have centralized racks for aggregating fiber panels to facilitate cross-connects, so rolling up the utilization for all those panels going to all different locations wouldn't be particularly useful.

So we also have split panels (1-24 go from Rack A to Rack B 1-24, 25-48 Rack A could go to Rack C 1-24 for a high-level example).

We often have to go east - west in a given row to an aggregation switch or aggregation patch panel to get from a server row to a switch row. The rack level capacity could show me that while I could get a 3u server in Rack B or Rack C (assuming my switch is in A) Rack B may only have 2 patch ports available to get to rack A, while Rack C might have 6 available for the same task. Individual Patch Panel utilization is the more actionable information necessary for this, but the Rack level patch panel utilization might help a non-datacenter worker realize those how full of cables the cabinet is before asking for a server to be racked..

... Just thoughts.

@xiSlickix commented on GitHub (Feb 2, 2024): > How do you propose handling modular patch panels, where not all of the modules have been populated yet? We have some that can take 12F or 24F cassettes depending on whether you are using SC or LC connectors, so that complicates utilization calculations. We would want to be able to distinguish between "I'm almost out of available ports and I need to install a new module" or "I'm almost out of available ports and I need to install a new panel." > Perhaps the better term I should use is "Installed Utilization". If you have a fiber panel with cassettes, at the fiber patch panel level, you could show your utilization of the cassettes installed divided by the total available cassette modules. This would give you your cassette capacity. Then, based on the variety and quantity of cassettes installed (similar to server modules with NICs) you could then give an "Installed Utilization" of the consumed ports. Looking to be able to generate actionable information such as: "If we go past 80% installed capacity, order another module installed in this month's datacenter capacity planning meeting." "If we have consumed more than 90% of the modules for cassettes, order another fiber housing patch panel (and perhaps rack it based on rack capacity utilization, etc.)" > This also assumes that all the rear ports connect to the same place. We definitely have split panels where some ports are wired to a cable that goes to one location and other ports go to a different location (typically an east/west kind of situation), so a strict panel utilization could introduce additional confusion. Your cabinet-level roll-up would be even more confusing, as most data centers I've seen have centralized racks for aggregating fiber panels to facilitate cross-connects, so rolling up the utilization for all those panels going to all different locations wouldn't be particularly useful. > So we also have split panels (1-24 go from Rack A to Rack B 1-24, 25-48 Rack A could go to Rack C 1-24 for a high-level example). We often have to go east - west in a given row to an aggregation switch or aggregation patch panel to get from a server row to a switch row. The rack level capacity could show me that while I could get a 3u server in Rack B or Rack C (assuming my switch is in A) Rack B may only have 2 patch ports available to get to rack A, while Rack C might have 6 available for the same task. Individual Patch Panel utilization is the more actionable information necessary for this, but the Rack level patch panel utilization might help a non-datacenter worker realize those how full of cables the cabinet is before asking for a server to be racked.. ... Just thoughts.
adam commented 2025-12-29 20:46:34 +01:00
Author
Owner
Copy Link

@coloHsq commented on GitHub (Feb 5, 2024):

Hi everyone, I've actually done something similar, see #11633 for reference.
For my use case, aggregating on devices role in the same rack is more practical, instead of knowing how many sc or lc free ports I have, I prefer to know how many multi mode or copper ports I have.
I don't gather much details about the difference between ports of the same "role", but since we use EOR design, once i know there's "4 free ports on 24", i know that a rack have 2 patch panels, each with 12 ports that goes on loop A/B, and most likely there's 2 free ports on each side.
Anyway, I've started working on a much more generic implementation that could probably be used for both use cases (this and the other fr).
If you have some more ideas, let's discuss them.

@coloHsq commented on GitHub (Feb 5, 2024): Hi everyone, I've actually done something similar, see #11633 for reference. For my use case, aggregating on devices role in the same rack is more practical, instead of knowing how many sc or lc free ports I have, I prefer to know how many multi mode or copper ports I have. I don't gather much details about the difference between ports of the same "role", but since we use EOR design, once i know there's "4 free ports on 24", i know that a rack have 2 patch panels, each with 12 ports that goes on loop A/B, and most likely there's 2 free ports on each side. Anyway, I've started working on a much more generic implementation that could probably be used for both use cases (this and the other fr). If you have some more ideas, let's discuss them.
adam commented 2025-12-29 20:46:34 +01:00
Author
Owner
Copy Link

@sleepinggenius2 commented on GitHub (Feb 5, 2024):

I guess a lot of this has to do with how your company handles capacity planning. For us, it's more useful for the planning teams to get periodic reports on the specific equipment that they are responsible for, tailored to their specific queries. That way we can calculate burn rate between successive reports, add additional inputs, like queued orders for a given site, and they can proactively add capacity as needed. If, in contrast, you have a more reactive model where an engineer is looking each time an order comes across to find somewhere with capacity and that triggers a notification to the planning team, then I can see where this approach is more useful. Capacity planning is absolutely critical to doing business, but either way, I'm not sure that there is a one-size-fits-all approach to this problem. I do see this more as a reporting thing though and not something I would want to incur additional overhead for every time the device table is loaded. @coloHsq, I would be interested to see this as a plugin that would allow such a reporting interface and potentially allow end users to easily customize such reporting to their needs without an admin always having to write actual Report classes each time. A simple reporting interface for end users to develop ad-hoc or repeatable, saved reports is actually one of the things that I miss most from our old system with the transition into NetBox.

@sleepinggenius2 commented on GitHub (Feb 5, 2024): I guess a lot of this has to do with how your company handles capacity planning. For us, it's more useful for the planning teams to get periodic reports on the specific equipment that they are responsible for, tailored to their specific queries. That way we can calculate burn rate between successive reports, add additional inputs, like queued orders for a given site, and they can proactively add capacity as needed. If, in contrast, you have a more reactive model where an engineer is looking each time an order comes across to find somewhere with capacity and that triggers a notification to the planning team, then I can see where this approach is more useful. Capacity planning is absolutely critical to doing business, but either way, I'm not sure that there is a one-size-fits-all approach to this problem. I do see this more as a reporting thing though and not something I would want to incur additional overhead for every time the device table is loaded. @coloHsq, I would be interested to see this as a plugin that would allow such a reporting interface and potentially allow end users to easily customize such reporting to their needs without an admin always having to write actual Report classes each time. A simple reporting interface for end users to develop ad-hoc or repeatable, saved reports is actually one of the things that I miss most from our old system with the transition into NetBox.
adam commented 2025-12-29 20:46:34 +01:00
Author
Owner
Copy Link

@coloHsq commented on GitHub (Feb 21, 2024):

Hi everyone, I've finally managed to put togheter a plugin that i think would be flexible enough.
Here it is : https://github.com/coloHsq/aggregatron.git

@coloHsq commented on GitHub (Feb 21, 2024): Hi everyone, I've finally managed to put togheter a plugin that i think would be flexible enough. Here it is : https://github.com/coloHsq/aggregatron.git
adam commented 2025-12-29 20:46:35 +01:00
Author
Owner
Copy Link

@PieterL75 commented on GitHub (Feb 21, 2024):

This FR might help.
https://github.com/netbox-community/netbox/issues/14205
A proposal to allow custom jinja templates for tech views

@PieterL75 commented on GitHub (Feb 21, 2024): This FR might help. https://github.com/netbox-community/netbox/issues/14205 A proposal to allow custom jinja templates for tech views
adam commented 2025-12-29 20:46:35 +01:00
Author
Owner
Copy Link

@jeffgdotorg commented on GitHub (Apr 3, 2024):

Thank you for submitting your idea. I see you already started down the road of building a plugin that scratches your itch 👏

Please reach out via our mailing list or Slack channel if you need any assistance. There's a #netbox-plugin-development channel on the Slack that might be of particular interest.

@jeffgdotorg commented on GitHub (Apr 3, 2024): Thank you for submitting your idea. I see you already started down the road of building a plugin that scratches your itch 👏 Please reach out [via our mailing list or Slack channel](https://github.com/netbox-community/netbox/wiki) if you need any assistance. There's a `#netbox-plugin-development` channel on the Slack that might be of particular interest.
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#9172
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?