-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
POE interfaces #1099
Comments
This feature request lacks sufficient detail to be actionable. Per the contributing guidelines:
Please extend the request so that it meets all of these requirements. If no response is received within a week, this issue will be closed. |
A detailed description of the proposed functionality
A use case for the feature; who would use it and what value it would add to NetBox
A rough description of changes necessary to the database schema (if applicable)
OR A new optional dropdown list below the form factor:
Any third-party libraries or other resources which would be involved
|
Some devices also produce/consume nonstandard POE schemes. There's some general agreement on what "passive POE mode A" and "passive POE mode B" means, but even then there's a variety of other specs to consider. Ubiquiti, for example, does a lot of passive POE. They have a fun compatibility matrix of which UniFi APs work with which kinds of power, overflowing with asterisks and parentheticals because nothing can ever be simple. Worse, a single Ubiquiti switch port might be able to output both passive POE of a particular variety and standard POE. Voltages are critically important, both outputs and tolerances. For example, you might have a 48V passive POE adapter paired with a UAP-AC-PRO, and that's fine -- but be careful not to plug it into a UAP-AC-LR lest the magic smoke escape. Yes, these products are adjacent in the brochure. Yes, this is terrible. Amperages and pinouts are important too, hence the whole pile of different Ubiquiti power adapters. Yes, they sell two different 24V 24W passive POE adapters with different pinouts. Yes, this is terrible. Mikrotik runs a fair amount of nonstandard POE as well. Some of their devices raise an interesting point: for example, the hAP can receive power over I think "POE" should be a dropdown modifying an interface, independent of media type, and it definitely needs to support more than three options. |
These have existing names, such as PoE PD (powered device, |
I've been taking a (very) preliminary look at what it would take to resolve #3377. It would be interesting to have this affect the power consumption for a given device. Eg 50W for the base switch, plus the PoE load, and have that trail on back. |
Cascading the power consumption through devices (as requested for power connections in #3377) would be rather useful with this too |
Given that #5401 will add custom field support for interfaces and other device components, I have to wonder whether it's worth pursuing this, or if we're better off just letting users define whatever fields they deem appropriate for tracking PoE. |
I have to disagree, PoE is a critical part of the real-world definition of many networks. It should be built in and standardized, not left to end users to tack on with custom fields. |
@abrahamvegh That's fair, however this issue has been open for over three years with very little discussion and still lacks a firm proposed implementation. Would you like to propose a specific implementation? |
@jeremystretch I’m happy to try and take a pass at it. This is a loose collection of my thoughts on what a useful implementation of PoE looks like in NetBox; hopefully this can serve as a good starting point for a continued discussion and implementation. Desires
Definitions
Proposed New Fields
There is some cross-coverage of possible values in this list. This is because it is unclear to me whether or not the maintainers prefer to explicitly store all possible states, or derive some, or all. As an example: Perhaps it makes the most sense to focus on extending just Interfaces, and derive anything further on the Device and Rack level using just that information. I don’t necessarily think that is the best way to go about it, I just don’t know the codebase well enough to make the assumption either way. |
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. Please see our contributing guide. |
I, for one, would find @abrahamvegh's solution useful. Those PoE flavors would be an excellent start at managing our usage. |
I agree. Incorporating PoE in the Interfaces would be really usefull. @abrahamvegh ideas sounds like a great start for implimentation. |
Looking at the proposal from @abrahamvegh I'm wondering if the device specific information will work that way as some parts (like I would extend the interface specific option list of
with the "usual" four passive PoE options of
provided by many switches and used by a lot of ubnt gear for example. |
I have the miss fortune of running into many different POE standards (several hundred devices in fact..) What is missing from @abrahamvegh list is a cross between POE+ and 802.3bt, called UltraPOE. It uses the 802.3at signaling, but is rated for 50watts of power.. How do I know this? lookup the edge-core as4610 switches. "UltraPOE". Not 802.3bt. I know it was a stop gap solution until 802.3bt was ratified, but it does exist. |
@jeremystretch Can you share on the milestone slip? I know I’m eagerly awaiting this, and I’m sure many others are too. Understand that you can only do so much, just really want to see this implemented. 😅 |
To ensure we can finally move forward with this for v3.3, I'm going to limit the scope of this FR to the interface model only. Any additions to the device model can be considered for a future release. As for the interface model, we'll add two fields per the conversation above: POE mode
POE type
If you would like to propose any additional POE types, please comment below citing the canonical name and reference for each. Proprietary types are fine so long as they are well-defined and uniquely distinguishable. |
In the WISP environment, the following passive PoE "standards" are available, especially from Ubnt, Mikrotik and some other manufacturers:
|
There is also single pair Ethernet with poe. And Poe over coax. |
I assume restricting this to the Interface model means that power budgeting will not be part of 3.3? As in, to know what ports provide power, what ports require power, and be able to cascade power demands through from PoE ports to Power Ports so that budgets can be managed and oversubscription can be warned against? Is there office-type hardware implementing these standards @mzac? Don't know that there's a use case for NetBox supporting an "automotive" PoE standard that links reversing cameras to a head unit. Though, I confess I now want to build some technology using that standard, that seems really cool - thanks for the heads up! (display) |
It would be interesting to be able to configure interfaces as a POE port when choosing the 'form factor' and for example choosing the poe type (15.4w, 30w, 60w) etc...
The text was updated successfully, but these errors were encountered: