A most bizarre PoE problem w/hEX S

[kg4peq]

I recently deployed a MikroTik hEX S to replace my Linksys WRT1900ACS on my home network, and I am now having a strange PoE issue downstream that I’m having a hard time troubleshooting. Here’s the setup:

MikroTik hEX S
3 x Netgear ProSafe GS108PEv3 8-port PoE switches, on ether2, ether3, and ether4
WAN on ether1

The GS108PE’s have 8 ports – 4 PoE (15.4W) and 4 non-PoE. Downstream on two switches I have some GS105PE’s which are PoE-powered off those GS108’s. The GS108PE serves standard PoE (802.3af) at 15.4W per port. Quick and dirty diagram of a portion of this setup:
[Router - hEX S] <---- (ether4) ----> [Switch 3 - GS108PE] <---- (PoE port 4) ----> [Switch 4 - GS105PE]
The GS105PE’s will autodetect 802.3af vs. 802.3at (PoE+), and have always run with the 15-watt 802.3af, as expected, until I put the hEX S in place. Now what’ll happen is the GS105PE’s will power up and LED’s indicate they’re running with 802.3at POE+, but periodically (seemingly random intervals) the PoE will cycle down to 802.3af for about two seconds and then back up to 802.3at PoE+. This drop causes devices on the GS105PE PoE passthrough ports to lose power momentarily.

Those GS105PE’s detect the correct PoE type (802.3af) if I disconnect the hEX S and/or replace it with the old WRT1900ACS. The erratic behavior also stops if I disable the interface on the hEX S – in the diagram above, that would be ether4. Shut that off, and the PoE link between the GS108PE and the GS105PE works fine. Re-enable ether4, it gets wonky.

I’ll admit to not having a deep understanding of PoE but after several hours of research I can’t find anything to explain the behavior. Why does the router even play a role in what’s happening in this situation?

EDIT: Turns out, the issue seems to be coming from ether5, which is the only PoE output on the hEX S. Currently there’s an AP on that port, but if I disable ether5, all of my PoE stuff on the Netgear switches works fine. How on earth do I fix this?!

[sindy]

It sounds really strange. Assuming that ether4 and ether5 are on the same bridge, what is the protocol-mode of that bridge? If set to none, it forwards frames which should not be forwarded, so it lets LLDP through. Same happens if you have hardware-assisted forwarding enabled. LLDP has no role in the initial negotiation of PoE type (as the latter takes place before the data layer becomes available), but forwarding LLDP allows the devices to talk LLDP to each other which may confuse them as LLDP does convey information about available PoE types on the remote port. So if ether4 and ether5 are member ports of the same bridge, do a test: set hw in /interface brodge port to no for ether5, and set protocol-mode to rstp. If the issue disappears, my wild guess was right.

[kg4peq]

It sounds really strange. Assuming that ether4 and ether5 are on the same bridge, what is the protocol-mode of that bridge? If set to none, it forwards frames which should not be forwarded, so it lets LLDP through. Same happens if you have hardware-assisted forwarding enabled. LLDP has no role in the initial negotiation of PoE type (as the latter takes place before the data layer becomes available), but forwarding LLDP allows the devices to talk LLDP to each other which may confuse them as LLDP does convey information about available PoE types on the remote port. So if ether4 and ether5 are member ports of the same bridge, do a test: set hw in /interface brodge port to no for ether5, and set protocol-mode to rstp. If the issue disappears, my wild guess was right.

You may be on to something. protocol-mode of the bridge is set to none. I’m not understanding the steps suggested for the test. “set hw in /interface brodge port to no for ether5” doesn’t make sense to me, sorry. Would you mind clarifying the recommended test steps please?

EDIT: Upon setting protocol-mode=rstp for bridge1, the PoE links almost instantly dropped back down to the 802.3f mode where they’re supposed to be. Any other recommended changes beyond that one edit to bridge1?

[sindy]

Would you mind clarifying the recommended test steps please?

I don’t know whether you use clicking or typing to set up your Mikrotik So “hw” is the name of a parameter of a row of a configuration table which defines the membership of interfaces in bridges (/interface bridge port); the name on the clickface (WebFig, Winbox) may differ. It tells RouterOS whether to permit frames to and from that interface to be forwarded to another port directly by the switch chip (which is called “hardware acceleration” in RouterOS) rather than handling them in CPU. So you need to prohibit this for ether5, as the switch chip is dumb and cannot identify destination MAC addresses which it should not forward. The second step is to set the protocol-mode of the bridge to something else than “none” as with “none”, the bridge also behaves as a dumb switch.