POE interfaces #882

@willglynn commented on GitHub (Apr 27, 2017):

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 ether1 while providing power over ether5. This configuration is fixed in hardware, and as long as I'm documenting the POE role of each interface, I would like to distinguish source from sink.

I think "POE" should be a dropdown modifying an interface, independent of media type, and it definitely needs to support more than three options.

@willglynn commented on GitHub (Apr 27, 2017): 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](https://help.ubnt.com/hc/en-us/articles/115000263008--UniFi-Understanding-PoE-and-How-UniFi-Devices-are-Powered#supported%20unifi%20devices) 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](https://community.ubnt.com/t5/UniFi-Wireless/Warning-UAP-AC-LITE-and-UAP-AC-LR-with-UniFi-Switch-on-PoE/td-p/1771809). Yes, these products are [adjacent in the brochure](https://dl.ubnt.com/datasheets/unifi/UniFi_AC_APs_DS.pdf). Yes, this is terrible. Amperages and pinouts are important too, hence the [whole pile of different Ubiquiti power adapters](https://dl.ubnt.com/datasheets/poe/PoE_Adapters_DS.pdf). 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](https://routerboard.com/RB951Ui-2nD) can receive power over `ether1` while providing power over `ether5`. This configuration is fixed in hardware, and as long as I'm documenting the POE role of each interface, I would like to distinguish source from sink. I think "POE" should be a dropdown modifying an interface, independent of media type, and it definitely needs to support more than three options.

adam commented

@dorkmatt commented on GitHub (Dec 12, 2017):

These have existing names, such as PoE PD (powered device, ether1 in the example above) or PoE PSE (power sourcing equipment, ether5). Don't worry, @willglynn forgot to mention UPoE (Cisco up to 60W) - the insanity grows.

@dorkmatt commented on GitHub (Dec 12, 2017): These have existing names, such as PoE PD (powered device, `ether1` in the example above) or PoE PSE (power sourcing equipment, `ether5`). Don't worry, @willglynn forgot to mention UPoE (Cisco up to 60W) - the insanity grows.

adam commented

@millijuna commented on GitHub (Oct 30, 2019):

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.

@millijuna commented on GitHub (Oct 30, 2019): 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.

adam commented

@girlpunk commented on GitHub (Sep 9, 2020):

Cascading the power consumption through devices (as requested for power connections in #3377) would be rather useful with this too

@girlpunk commented on GitHub (Sep 9, 2020): Cascading the power consumption through devices (as requested for power connections in #3377) would be rather useful with this too

adam commented

@jeremystretch commented on GitHub (Dec 21, 2020):

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.

@jeremystretch commented on GitHub (Dec 21, 2020): 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.

adam commented

@abrahamvegh commented on GitHub (Dec 21, 2020):

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 commented on GitHub (Dec 21, 2020): 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.

adam commented

@jeremystretch commented on GitHub (Dec 21, 2020):

@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 commented on GitHub (Dec 21, 2020): @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?

adam commented

@abrahamvegh commented on GitHub (Dec 28, 2020):

@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

Accurate modeling of real world hardware configuration
PoE power utilization and budget calculations
- Similar to existing power utilization calculations, but not wholly as a component of it

Definitions

PSE: Power sourcing equipment
- Can provide power via PoE interfaces to PDs
- Typically a switch (endspan PoE)
- Sometimes an injector (midspan PoE)
PD: Powered device
- Can consume power via a PoE interface
- Typically a wireless AP or camera
- Sometimes a switch
- Sometimes lights
- Pretty much could be anything
- It is valid for a PD to also be a PSE
  - i.e. switches that can be powered by PoE while also passing through PoE power
PoE flavors: (intentionally ignoring the complexities of power class levels and modes)
- PoE (802.3af / Type 1) (15.4W max)
- PoE+ (802.3at / Type 2) (30W max)
- PoE++ (802.3bt)
  - Type 3: 60W max
  - Type 4: 100W max
- Non-802.3 (e.g. Ubiquiti 'passive' PoE)
Power budgets:
- PSE
  - Typically an overall maximum specified for the entire device (e.g. 150W, 250W, 500W, etc.)
  - Individual interfaces will be rated for specific flavors or maximum wattage
    - e.g. 24-port switch with 20 PoE+ ports, 4 PoE++ ports, max output 30W
- PD
  - Input minimum PoE flavor or wattage (e.g. 802.3at required)
  - Input max power consumption (e.g. max 16.5W for a particular AP)
  - Typically a single interface is identified as the PoE input (e.g. port 1, rear port)

Proposed New Fields

Device
- PSE Power Budget: Unsigned Integer (Watts)
- PSE Max Output per Interface: Unsigned Integer (Watts)
- PD: Boolean
- PD Min Input Power: Unsigned Integer (Watts)
- PD Max Power Consumption: Unsigned Integer (Watts)
Interface
- PoE Mode: Single Choice
  - None (default)
  - Powered Device
  - Power Sourcing Equipment
- PoE Type: Single Choice (nullable)
  - 802.3af
  - 802.3at
  - 802.3bt (Type 3)
  - 802.3bt (Type 4)
  - Other

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.

@abrahamvegh commented on GitHub (Dec 28, 2020): @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 - Accurate modeling of real world hardware configuration - PoE power utilization and budget calculations - Similar to existing power utilization calculations, but not wholly as a component of it ### Definitions - PSE: Power sourcing equipment - Can provide power via PoE interfaces to PDs - Typically a switch (endspan PoE) - Sometimes an injector (midspan PoE) - PD: Powered device - Can consume power via a PoE interface - Typically a wireless AP or camera - Sometimes a switch - Sometimes lights - Pretty much could be anything - It is valid for a PD to also be a PSE - i.e. switches that can be powered by PoE while also passing through PoE power - PoE flavors: _(intentionally ignoring the complexities of power class levels and modes)_ - PoE (802.3af / Type 1) (15.4W max) - PoE+ (802.3at / Type 2) (30W max) - PoE++ (802.3bt) - Type 3: 60W max - Type 4: 100W max - Non-802.3 (e.g. Ubiquiti 'passive' PoE) - Power budgets: - PSE - Typically an overall maximum specified for the entire device (e.g. 150W, 250W, 500W, etc.) - Individual interfaces will be rated for specific flavors or maximum wattage - e.g. 24-port switch with 20 PoE+ ports, 4 PoE++ ports, max output 30W - PD - Input minimum PoE flavor or wattage (e.g. 802.3at required) - Input max power consumption (e.g. max 16.5W for a particular AP) - Typically a single interface is identified as the PoE input (e.g. port 1, rear port) ### Proposed New Fields - Device - PSE Power Budget: Unsigned Integer (Watts) - PSE Max Output per Interface: Unsigned Integer (Watts) - PD: Boolean - PD Min Input Power: Unsigned Integer (Watts) - PD Max Power Consumption: Unsigned Integer (Watts) - Interface - PoE Mode: Single Choice - None _(default)_ - Powered Device - Power Sourcing Equipment - PoE Type: Single Choice (nullable) - 802.3af - 802.3at - 802.3bt (Type 3) - 802.3bt (Type 4) - Other 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.

adam commented

@stale[bot] commented on GitHub (Feb 13, 2021):

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.

@stale[bot] commented on GitHub (Feb 13, 2021): 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](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).

adam commented

@bobjacobsen commented on GitHub (Feb 13, 2021):

I, for one, would find @abrahamvegh's solution useful. Those PoE flavors would be an excellent start at managing our usage.

@bobjacobsen commented on GitHub (Feb 13, 2021): I, for one, would find @abrahamvegh's solution useful. Those PoE flavors would be an excellent start at managing our usage.

adam commented

@rvall67 commented on GitHub (Mar 17, 2021):

I agree. Incorporating PoE in the Interfaces would be really usefull.
In our company we have over 100 switches, soon more than 250 cameras, 75 door, 20 AP, ....
99% of the units are driven by PoE+from the switches or injectors.
To have the ability to calculate the power usage for the switch (or complete rack) would be nice.
It is a big difference between a switch without PoE and a switch with full usage, it could be 10W compared to 560W.

@abrahamvegh ideas sounds like a great start for implimentation.

@rvall67 commented on GitHub (Mar 17, 2021): I agree. Incorporating PoE in the Interfaces would be really usefull. In our company we have over 100 switches, soon more than 250 cameras, 75 door, 20 AP, .... 99% of the units are driven by PoE+from the switches or injectors. To have the ability to calculate the power usage for the switch (or complete rack) would be nice. It is a big difference between a switch without PoE and a switch with full usage, it could be 10W compared to 560W. @abrahamvegh ideas sounds like a great start for implimentation.

adam commented

@BarbarossaTM commented on GitHub (Jun 8, 2021):

Looking at the proposal from @abrahamvegh I'm wondering if the device specific information will work that way as some parts (like Max Output per Interface) might be different between line cards in a modular chassis.

I would extend the interface specific option list of

PoE Mode: Single Choice
     None (default)
     Powered Device
     Power Sourcing Equipment
PoE Type: Single Choice (nullable)
     802.3af
     802.3at
     802.3bt (Type 3)
     802.3bt (Type 4)
     Other

with the "usual" four passive PoE options of

24V (0.75A)
24VH (1.5A)
48V (0.75A)
48VH (1.5A)

provided by many switches and used by a lot of ubnt gear for example.

@BarbarossaTM commented on GitHub (Jun 8, 2021): Looking at the proposal from @abrahamvegh I'm wondering if the device specific information will work that way as some parts (like `Max Output per Interface`) might be different between line cards in a modular chassis. I would extend the interface specific option list of ``` PoE Mode: Single Choice None (default) Powered Device Power Sourcing Equipment PoE Type: Single Choice (nullable) 802.3af 802.3at 802.3bt (Type 3) 802.3bt (Type 4) Other ``` with the "usual" four passive PoE options of * 24V (0.75A) * 24VH (1.5A) * 48V (0.75A) * 48VH (1.5A) provided by many switches and used by a lot of ubnt gear for example.

adam commented

@ThomasADavis commented on GitHub (Oct 6, 2021):

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.

@ThomasADavis commented on GitHub (Oct 6, 2021): 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.

adam commented

@abrahamvegh commented on GitHub (Dec 20, 2021):

@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. 😅

@abrahamvegh commented on GitHub (Dec 20, 2021): @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. 😅

adam commented

@jeremystretch commented on GitHub (May 19, 2022):

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

None (default)
Powered device (PD)
Power sourcing equipment (PSE)

POE type

None (default)
802.3af
802.3at
802.3bt (Type 3)
802.3bt (Type 4)
Other

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.

@jeremystretch commented on GitHub (May 19, 2022): 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 * None (default) * Powered device (PD) * Power sourcing equipment (PSE) #### POE type * None (default) * 802.3af * 802.3at * 802.3bt (Type 3) * 802.3bt (Type 4) * Other 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.

adam commented

https://www.netonix.com/media/wysiwyg/ws-specsheet.pdf

@tioan commented on GitHub (May 19, 2022):

In the WISP environment, the following passive PoE "standards" are available, especially from Ubnt, Mikrotik and some other manufacturers:

24V @ 1A (2 Pair)
48V @ 1A (2 Pair)
24VH @ 2A (4 Pair)
48VH @ 2A (4 Pair)

@tioan commented on GitHub (May 19, 2022): In the WISP environment, the following passive PoE "standards" are available, especially from Ubnt, Mikrotik and some other manufacturers: - 24V @ 1A (2 Pair) - 48V @ 1A (2 Pair) - 24VH @ 2A (4 Pair) - 48VH @ 2A (4 Pair) <img width="783" alt="image" src="https://user-images.githubusercontent.com/259990/169407515-e528582a-465d-4e2f-ab72-ab8a02ed89b0.png"> https://www.netonix.com/media/wysiwyg/ws-specsheet.pdf

adam commented