revit написал(а):
Это громкое заявление, вы точно уверены? На какой прошивке? Не понимаю как мои 80 УМ-ов работают с резервом. Может объясните?
Никто не говорит, что резерв не работает. Говорят о том, что если в удаленной УМ КСЛ с двумя рутерами перешел на запасной канал, он на нем и останется. Пока с запасным каналом какая-нибудь хрень не случится, которая вынудит КСЛ переключится обратно на основной. Например, ребут КСЛ или запасного маршрутизатора.
Т.е. восстановление (в схеме от ЛКДС с двумя рутерами) основного канала - не говорит о том, что КСЛ на него переключится через какое-то время. Ну восстановился и восстановился. Обь раюотает дальше на резерве.
revit написал(а):
Какая политика -UDP и пинг... Что там обезопасивать?
Вас не взламывали? Не пытались?
Нас пока нет. Тьфу-тьфу.
! НО! Мы понимаем, что элементарно может появится юный хакер, который захочет поотключать лифты со своего компа забавы ради, или обиженный (уволенный) сотрудник ранее связанный с диспетчеризацией ОБИ или конкуренты предложат кому за 10 тыс. на денек вывести из строя Вашу центральную диспетчерскую перед заключением важного контракта... много вариантов.
Так вот, есть простой способ перехватить управление сетью Оби и всеми лифтами. Достаточно знать IP центральной диспетчерской. У меня это получилось случайно, из дома. Ничто не мешает кому-то сделать это не случайно.
Вы полагаете статические IP - это защита? НЕТ. Разработчики Оби сделали так, что их ПО и микропрограммы не всегда сверяют IP отправитиля пакета с IP прописанном в связи с УМ откуда пришел пакет. Это очень большая дыра.
Но мы понимаем, что есть куда более важные дела у разработчиков. Так что мы молчим и сами занимаемся своей безопасностью.
Остальным клиентам похоже пофиг. Случаев как говорится ПОКА не было. Пинги, UDP, чего там защищать то.....
to котяра
у нас работают с резервом 5 точек. 2 по схеме ЛКДС, 3 по нашему методу описанному Выше как решение проблемы обозначенной в теме. Нигде нет УПП. Нигде он и не нужен. Дергать потому что ничего не надо. Кому, что как говорится...
Не соответствие протоколов:
Если Вы возьмете любой прикладной протокол, HTTP, SMTP или SNMP например, то заметите что у него есть правила запросов-ответов, приветствий. Любой из них в качестве транспортного использует TCP или UDP, в зависимости от необходимости подтверждения доставки. Сначала обычно идет приветсвие, после запрос, после ответ, потом паузы, новый обмен и т.д. Запросы бывают разные, ответы. Если что-то идет не так, происходит разрыв соединения. Которое может потом быть инициировано заново.
Разработчики ОБИ создали какие-то правила, по которым КСЛ/Моноблок/ПКСЛ/ЛБпро/ПКЛШ общаются между собой. Какие-то приветствия, запросы, ответы, уведомления и т.д. Эти правила я и называю "протоколом Оби".
Проблема поднятая в этой теме состоит в том, что "протокол ОБИ" не переваривает реализацию NAT в маршрутизаторах при переключении на разных провайдеров. Он не подстраивается и не настраивается под такое переключение. Хотя мог бы. Вариант для продвинутых маршрутизаторов был мной уже описан.
to Tma_Jaguar
У Вас очень сумбурный пост.
Проблема не ясна. Что используете, как настроили. Опишите схему.
Описание TCP и UDP не верное. Главное их отличие - гарантия доставки.
Т.е. TCP - заказное письмо (для обычной почты), когда Вы получаете от адресата уведомление с росписью в том, что он получил Вашу посылку. А UDP - обычное письмо. Дошло оно до адресата или нет, Вы от почты не узнаете и гарантий нет.
Вот как раз ее то и нужно резервировать т.к она зависима от энергоснабжения, которое не резервируется источником бесперебойного питания находящимся в диспетчерской (если она у вас конечно она не прямая до серверной провайдера). И резервировать каналом сохраняющим работоспособность длительно работать от ИБП диспетчера (соnовый или ADSL)