PoE на расстоянии 200+ метров. Мониторинг и автоматический перезапуск PoE клиентов

В моей практике запитать устройство и получить с него картинку на значительном удалении от свитча оказалось не самой простой задачей. Особенно когда от одной железки отходят сети к нескольким камерам на разном удалении.

Любое маломальски сложное устройство периодически виснет. Что-то реже, а что-то чаще, и это догма. Чаще всего это решается… верно… вот этим:

И если с другой стороны трубки не окажется нужных рук, придется отрывать свою пятую точку от стула и идти/ехать/лететь к устройству.

Особо неприятно, если этот девайс где-нибудь под крышей или на столбе… или в удаленном офисе.

Экономия — главный бич удаленного администрирования. Иногда насяльника-ма находит на алиэкспрессе камеру/свитч/роутер и объяснить почему эта железка стоит 700 рублей, а так которую предлагаешь больше 5к бывает непосильной задачей. Особенно, если это устройство уже в наличии и к тебе обращаются по принципу «а чего это оно у нас не работает?». Клиент всегда прав, особенно когда звонит, как можно реже. А это значит то, что это самое китайское г***о плохое устройство должно обладать некой самостоятельностью и желательно «пинаться» автоматически еще до того, как клиент это заметит.

Ситуацию готовы спасти управляемые PoE коммутаторы, благо на рынке они представлены в огромном количестве.

И тут проблема номер Раз: кем или вернее, чем осуществлять мониторинг, чтобы в случае «залипания» устройства push`ить команду сброса питания на порту PoE-свитча. Поднимание и настраивание сервера – это дополнительные телодвижения и железо.

Допустим, у меня на объекте: всего 15 видеокамер, видеорегистратор и… всё. При этом 7 находятся на расстоянии менее 100 м, еще 5 до 150, и еще 3 на расстоянии в 200 м. Надо упростить инфраструктуру так, чтобы на этот объект приезжать только с профилактикой.

Решение достаточно простое – наличие PoE свитча, который умеет мониторить камеры и сбрасывать питание на порту, а также «дотягивается» по кабелю на расстояние 200+ метров «без единого разрыва».

Mikrotik

При наличии двух сертификатов (MTCNA и MTCRE) мой взор в первую очередь пал на Mikrotik. Выбор у данного производителя моделей с индексом P небольшой, например, вот эта.

ИМХО, слишком малый набор настроек. Что будет, если камера задумалась и пропустила пару пингов? — в ребут!

А если камера просто сдохла? Микротик будет каждую минуту её отрубать?..

В моей практике было большое количество брака у CCR по блоку питания. А какой смысл в PoE коммутаторе, если он имеет высокий риск сдохнуть по питанию через полгода?..

К тому же я не нашёл информации, что Микротик умеет работать с проводами длиной хотя бы 150+ метров…

Zyxel

При изучении представителей конкурирующих вендоров наткнулся на Хабре. Свитч от Zyxel серии GS1350. Стоит ощутимо дороже Микротика, но при этом мною проблем у Zyxel со «слабыми» блоками питания замечено не было.

Зуксель позиционирует свитчи GS1350 как, созданные специально для систем видеонаблюдения. Коммутаторы определяют, что камера «залипла» и перезагружают ее по питанию.

Метод определения зависания

До того, как я начал знакомиться с этим устройством, я представлял себе, что свитч анализирует тип трафика и как только видеопоток заканчивается — свитч сбрасывает питание…
Но все оказалось намного проще.

«Auto PD Recovery» может работать в двух режимах:

1. LLDP, то есть устройство само предоставляет информацию о себе, если, конечно, устройство поддерживает. LLDP ответ пришел — значит железка «жива». Если ответа нет – принудительно «режем» питание и ждем отклика.
2. Ping. Куда проще? Пингуем — Нет ответа — Ребутаем!

Количество пингов без ответа, время сброса и количество сбросов питания задается. Что вполне логично, ведь нет никакого смысла «пинать» железку, если она с третьего раза не завелась.

Только я не понял: в чём ТУТ специализация на видеокамерах?
Таким способом можно мониторить любое сетевое устройство. Даже то, которое не поддерживает PoE.

Заказываем с алиэкспресс такой гаджет и любое сетевое устройство у нас превращается в РoЕ.

В случае зависания гаджета, коммутатор сбросит питание на порту и в логах мы увидим примерно это:

233 Sep 07 17:24:41 DE interface: Port 4 - ReoLink link up 100M/F
 234 Sep 07 17:24:39 DE interface: Port 4 - ReoLink link down
 235 Sep 07 17:24:32 DE interface: Port 4 - ReoLink link up 100M/F
 236 Sep 07 17:24:30 DE interface: Port 4 - ReoLink link down
 237 Sep 07 17:24:26 NO system: PethPse Port 4 - ReoLink OnOff Trap, Port Detection Status is Delivering Power
 238 Sep 07 17:24:24 DE interface: Port 4 - ReoLink link up 100M/F
 239 Sep 07 17:24:04 NO system: PethPse Port 4 - ReoLink OnOff Trap, Port Detection Status is Disabled
 240 Sep 07 17:24:02 DE interface: Port 4 - ReoLink link down
 241 Sep 07 17:24:01 WA interface: Port 4 - ReoLink PD failure is detected and reboot due to Auto PD Recovery (ping mode)

Максимальная длина кабеля.

На странице Zyxel сказано:

Применение в этих коммутаторах режима Extended range позволяет увеличить максимальное расстояние до запитываемых устройство до 250 метров.

Мы привыкли к любому рекламному проспекту относиться скептически.

Я обжал два конца новой бухты (305 метров) и воткнул один в камеру, а другой в свитч. Камера не взлетела… Вроде бы ожидаемо ^_^

Посидел, почесал тыкву – зашел в настройки, поставил галочку «Extended range», и… секунд десять молчания – барабанная дробь… камера заработала! На 305 МЕТРАХ!

Без потерь пакетов!


Таким образом, свитч GS1350 серии дотянулся не на 250 заявленных, а аж на 305 метров!

Правда, возможно, чит кроется еще и в качестве кабеля:
Rexant FTP Cat.6 и обошёлся почти 12к рублей

Если требуется бОльшая длина, можно состыковать несколько отрезков кабеля через какой-нибудь повторитель. Так же на конце можно подключить ещё одни poe свитч для подключения нескольких устройств.

Например, через UPVEL UP-215SGE (На сколько надёжный — не проверял. Просто попался в руки.) Он сам питается по PoE и запитывает устройства по PoE.

Но это отдельная тема под конкретные условия так, как требует проектирования с учетом всех факторов.

При включении опции «Extended range» порт автоматически установит протокол 802.3at и задаёт бюджет мощности в 33W.

Но стоит расставить приоритеты на случай, когда все потребители начнут активно кушать… Порты с низким приоритетом, в случае дефицита мощности на свитче, получат запрашиваемые мощности в последнюю очередь.

Грозозащита

Второй вопрос при расположении девайсов на свежем воздухе — защита от перепадов напряжения.

Значение ESD/Surge Protection:
ESD – 15 кВ / 8 кВ (Air/Contact);
Surge – 4 кВ (Ethernet Port).

Примечание. ESD – защита от электростатического напряжения, Surge –
защита от перенапряжения. Если возникнет статический разряд в воздухе до 15
киловольт, или 8 кВ электростатики при близком контакте, или временный скачок
напряжения до 4 киловольт — коммутатор имеет хорошие шансы пережить подобные
неприятности.

Ну и на корпусе есть куда прицепить заземление.
Надеюсь, мне этого проверять не придётся ^_^

Continuous PoE

Подаёт питание даже если устройство не отвечает. По умолчанию эта опция включена. Не забывайте проверить эту опцию перед обновлением прошивок на камерах. Иначе может быть неприятно…

Cisco like CLI

Для любителей консолей, а так же для автоматизации настройки, можно воспользоваться привычной CLI в стиле Cisco.

Если Вы не используете, например, telnet/snmp и другие протоколы, то рекомендую их выключить для повышения безопасности устройства.

Не без ложки дёгтя…

На коммутаторе есть пункт меню «Cloud Management»

Но при попытке заригистрироваться получаем это

На данный момент поддержка данных устройств на Nebula пока не включена. Производитель обещает их добавить в 2020 году. При этом обновлять прошивку свитча не надо будет!

Заключение

Zyxel GS1350 пока единственный коммутатор, который удовлетворил мои запросы:

• управляемый со стандартным набором функционала
• длина кабеля 200+ метров без стыков
• мониторинг и перезагрузка PoE потребителей
• простота и гибкость конфигурирования.

Возможно на рынке есть и другие решения, которые закроют мои потребности, но я их пока не нашёл.

Желающих обсудить статью приглашаю в Telegram на мною созданные чаты:

1. @zyxelru — Тематический чат по Zyxel
2. @router_os — Тематический чат по Mikrotik

Источник: habr.com