Netbox: POE interfaces

Created on 22 Apr 2017  路  10Comments  路  Source: netbox-community/netbox

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

API change under review feature

Most helpful comment

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.

All 10 comments

This feature request lacks sufficient detail to be actionable. Per the contributing guidelines:

When submitting a feature request on GitHub, be sure to include the following:

    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)
    Any third-party libraries or other resources which would be involved

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

  • Tag Internfaces as POE/POE+/UPOE capable

A use case for the feature; who would use it and what value it would add to NetBox

  • All POE ports could be identified easily on switches that support it. If polling of the switch is supported in the future, the power usage on the port could be reported. Also, if a device could have its power source listed as POE the system could allow that power to come from an interface somehow?

A rough description of changes necessary to the database schema (if applicable)

  • Some new entries on the Form factor:
  • 100BASE-TX POE
  • 1000BASE-T POE

OR

A new optional dropdown list below the form factor:
POE Port:

  • POE (802.3af - Type 1 - 15.4W)
  • POE+ (802.3at - Type 2 - 30W)
  • UPOE (802.3bt - Type 3 - 60W)

Any third-party libraries or other resources which would be involved

  • N/A

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.

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.

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鈥檓 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鈥檛 necessarily think that is the best way to go about it, I just don鈥檛 know the codebase well enough to make the assumption either way.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Grokzen picture Grokzen  路  3Comments

soer7022 picture soer7022  路  3Comments

aarjbdea picture aarjbdea  路  3Comments

bellwood picture bellwood  路  3Comments

billyzoellers picture billyzoellers  路  3Comments