PoE Adapters - How to model?

[danner26]

Hello all,

Recently we have been struggling with deciding on the best way to model PoE adapters. This specific poll is stemming from #1190

We are torn between:

1. Modelling it as is in that PR, basically as a passthrough port - but in this implementation you lose the applicable PoE information

• upside is you are able to trace from the switch to the connected WiFi backhaul gear / see it directly on the switches interfaces page / the API, which you lose if these are interfaces.
• downside is you lose the PoE information

3. Modelling it such that 1 interface has PoE Mode set to Powered Device PD for the internal end (PoE in side), and the second interface has PoE Mode set to Power Sourcing PSE for the PoE out side

• upside is you retain the PoE information
• downside is you lose the tracability

Both ways are completely valid and useful, but neither are exactly the same. While I initially purposed option 2, I think I am leaning towards option 1 now. I am going to abstain from voting on this one, but please do let me know your opinions!

[sc68cal]

I think I'd rather be able to trace a device and know what port is connected back to the switch, compared to just knowing that there's some POE device attached to a switch and it might be the device I'm looking for, or it might not. My two cents.

[powerburner-nl]

Technically, it's a passthrough device that adds power. You might lose the PoE information, but there is a description field or other place you can record that information?
And if people really want, they can always create a new device type themselves that has 2 interfaces and includes the PoE types.

[bryanward-net]

Option 2 would result in double-counting of the power draw. Option 1 wouldn't include the PoE information, but since it's an injector, do you really care about power budget?

[ZPrimed]

My employer is in the WISP space too... but I had to go look up details about this device. It accepts standards-based (802.3 af/at) PoE in, and outputs passive 24V PoE for Ubiquiti. It technically is both a PD and PSE. However, you have no control over the PD status or the PSE status, it's entirely "invisible." It's not really an "injector" per typical understanding, since it has no AC input on it... it's just a passive converter.

How to model it though... ugh. (We use a fair amount of Ubiquiti as well, but we've used their "EdgePoint" switches instead of these devices, so I have "native" 24V passive PoE available in the field.)

I think I would lean to wanting the "full traceability" aspect (so, option 1), with a note in the Device Template explaining that this equipment converts from "smart" & "high voltage" PoE down to passive 24V. Continue to set the radio at the far end as a 24V-passive PD, and set the switch to whatever you have it outputting (whether that is 802.3af or at). That way you maintain cable traceability from switch to radio, and this thing just looks like a "patch panel" in the line.