MikroTik Power-Over-Ethernet Foibles

(This is a technical posting for the benefit of industry colleagues.  Subscribers to our service won’t miss anything by skipping it.

OmnitikThe OmniTik UPA-5HnD with POE-out is tailor-made for small neighborhood towers. You can run a single ethernet cable from the host site to the unit, supplied by the beefy 1.6A 24VDC transformer that comes with it, and then use short patch cables at height to power several other SXTs or similar for feeds and relay links. (If MikroTik would only make a version of this OmniTik in 2.4GHz, ah, the trailer parks I could serve!)

We ordered two (one to replace a perfectly-good non-POE-out OmniTik) for two tower upgrades planned this month.

After mounting the first unit on our new mast tower, we tested the access point portion and it worked flawlessly. When we hooked up the feed link SXT, the grief started. The unit wouldn’t power up—the OmniTik diagnosed it as a “short circuit.” Same for the other two SXT units.

Our patch cables tested out fine, but we swapped them out with known-good commercial indoor cables anyway, only to get the same result. We ran a commercial indoor cable up to power the OmniTik, and ditto. We gingerly turned on the “forced on” POE-out setting, but still got “short circuit” (and no lights on the SXTs, meaning no power).

We checked out the POE documentation to see if maybe we were trying to draw too much power. It assured us that the SXT was tested and certified to run fine.

Searching for “short,” among other references we found this global configuration setting:

ether1‑poe‑in‑long‑cable
(default: no)
setting to yes will disable short detection on all poe-out ports to enable use of longer ethernet cables. This is potentially dangerous settings and should be used with caution.

However, our POE-out cables were only three feet long—hardly candidates for turning on a “dangerous” option.

We phoned for assistance from our dealer technical support group. They were baffled, as was a professional west-coast MikroTik consultant (it was too late in the day to call east).

Our only option was to pack it in for the day. We went back to the shop and experimented with the other OmniTik unit. It had no problems running three SXTs. We concluded that the original unit was faulty and requested an RMA.

The next day, we replaced the first unit with the second we had tested. To our chagrin, we got exactly the same behavior we got from the first unit. The original unit, when tested indoors worked fine. Something about the action of putting the unit atop the mast was causing this behavior—there was no other conclusion. (It wasn’t a grounding issue, since the unit is entirely housed in insulating plastic and stands 3″ off the mast.)

At this point, the light went on, to be immediately reinforced once I noticed the tiny clue that the name of the option listed above was “ether1-poe-in-long-cable”. The long-cable issue didn’t involve the POE-out ports—it involved the POE-in port! Somehow (and this is really unintuitive!) the length of the feed cable causes the OmniTik to diagnose the satellite cables as short circuits. How this could even be an issue with a 24VDC, 1.6A feed transformer over a 25′ cable still boggles me.

We turned this “dangerous” configuration value on, and the problem evaporated.

In short order, we wired the rest of tower together, fixed the remaining configuration bugs, and had a working service. But the job isn’t over until the paperwork is done, and part of the paperwork on this job involves requesting a few improvements from MikroTik:

  1. “Longer ethernet cables” is way too vague, especially when a 25′ cable apparently qualifies. OmniTiks are designed to be strapped to masts, not to sit on people’s desks. A 25′ mast seems to me to be pretty modest, given that the technical limit for the length of an ethernet cable is over 300 feet. To think I have to turn on a “dangerous” option to run a tower that is 8′ above roof level is not soothing.
  2. The POE-out documentation needs to make it much clearer that the length limitation applies to the input cable, not the output cables. The single digit “1” is too easily overlooked a clue to convey this important and counterintuitive a distinction. How about: “setting to yes will disable short detection on all poe-out ports to enable use of an ethernet cable over [length value] on the poe-in port”?
  3. This option is apparently one of the few configuration parameters that Winbox doesn’t make available. It’s only available through the CLI, and you have to know it’s there to go looking for it. That makes debugging this issue tougher than it needs to be. Winbox knows to display POE-out ports differently (status, power consumption, etc.)—it should also make available the “long cable” setting for the POE-in port.
  4. The POE documentation has material in it about POE firmware versions that I suspect is obsolete. The documented POE firmware upgrade command no longer exists in ROS 6.17. Although you can obtain the version of the currently-running POE firmware, there’s no place to find out whether that is the newest version, the version you should be running, or what you should do about it either way. If the upgrade documentation is no longer useful, it should be deleted, or at least accompanied by the older RouterOS version numbers to which it applies.

If this posting keeps even one engineer from going down the frustrating rathole we did this weekend, my work here is done.

9 thoughts on “MikroTik Power-Over-Ethernet Foibles

  1. To change it in later ROS versions:
    [admin@MikroTik] > /interface ethernet poe settings edit ether1-poe-in-long-cable

    the you have the option to text edit “no/yes” and save.

    • Or, more directly:

      /interface ethernet poe settings set ether1-poe-in-long-cable=yes

      As far as I know, this has always been the case in the CLI (no earlier/later distinction). I just wish it was in Winbox. In fact, since beta 3 is now open, I’ve hit them again today with this suggestion.

      • That is weird, as i tried that (and many other variations) for hours and it would not work in a winbox terminal, now it does! For some reason in winbox yesterday it was auto predicting filling the lines as i typed [/inter_ etc], today it would not(hence typing it did not work), but now when i login it’s back to auto predicting, and your suggestion works like it should! Thanks for the info, I think now my Port Flapping has now been fixed!!

      • In ROS 6.7, I reported port flapping that occurred only whenever you were monitoring the POE status. Drove me bats until I figured out what was causing it and how to stop causing it. It was fixed in 6.8, but I’m sorry to hear it came back.

        The “auto prediction” you report sounds like “hotlock mode,” which happens when you type control-V. It’s a “clever feature” that I’ve always found to be more of a curse than a blessing. It interacts badly with lots of other things — such as when you paste in a command line, it auto-predicts (and therefore doubles) everything it sees, trashing it. A good rule is never to use control-V in the terminal — use right-click paste instead. If you use it by mistake, you can tell you’re in hotlock mode because the command prompt will have two >> instead of one > .

      • Ahhh, that makes a lot of sense now! I’m learning MTik fast… lol. Thank you 🙂

  2. I found the option accidentally in the web interface under System-Routerboard-PoESettings and I went “Huh?”
    For me, the issue are a number of RB750UPs. They seem to be stupid when powered by the PoE cable regardless of distance. I admit, I haven’t tried anything shorter than a 12ft cable but that’s still ridiculous.

    • I don’t know what you found in the web interface. To my knowledge, both Webfig and Winbox show POE options for the power-out ports, but the option for the power-in port is available only through the Terminal. MikroTik admitted to me that it “is not available through Winbox as a precaution [because] use of this option actually can have dire consequences.”

      We are currently using one RB750UP as a tower controller, a central router driving several dumb sectors (RB912 AP bridges) and inter-tower links (SXT 5 lites in L2 mode). It’s powered over a relatively short CAT5, and hasn’t given us any problems. We laid another up in stock for when we might have to replace an RB450G doing the same job at another tower, but since that one is powered over 80′ of armored overground CAT5, I now believe I’ll run a little testing on it ahead of time to make sure it doesn’t “go stupid” at that distance.

  3. thanks for this post mate. I put a couple of Sextant units out on 30-40m cat6 cables via POE and found they were rebooting quite frequently. I heard about this setting the other day, but always figured it only applied to cables longer than 90m. Will be looking into this tomorrow.

Leave a Reply

Your email address will not be published. Required fields are marked *