Помощь - Поиск - Пользователи - Календарь
Полная версия: Резервирование одним маршрутизатором
Лифт-Комплекс ДС > Форум «Лифт-Комплекс ДС» > КСЛ
Страницы: 1, 2, 3
pavel
Приветствую.

Резервирование УМ с использованием двух маршрутизаторов прекрасно описана ЛКДС и прекрасно работает. Но, хотим сделать резервирование не плодя на каждой УМ по 2 маршрутизатора. Приобретать один, но хороший. Итак, проблема:

У диспетчерского компа два внешних статических IP. Работает только один из двух.
109.х.х.х - проводной канал, основной. 82.х.х.х - 3G билайн, на случай падения основного, включает диспетчер его руками. Здесь ПКСЛ.

Есть УМ, в которой есть проводной канал со статическим IP 109.у.у.у и USB 3G модем со статическим IP 82.у.у.у. И проводной канал и 3G приходят в DIR-320NRU (192.168.0.1 LAN). В УМ стоит КСЛ (192.168.0.10).

Пробовал в течении двух месяцев, на двух разных точках - не работает. С двумя разными маршрутизаторами (DIR-320NRU, MikroTik). Провел 4 эксперимента по полтора - два часа.

Если на УМ поставить два маршрутизатора: один с проводом, другой с 3G - то всё ок, как в инструкции.

НО! Если в один маршрутизатор подключить и проводного провайдера и 3G, то канал интернета на маршрутизаторе переключается, а связь КСЛ (Моноблока) с Диспетчерской - НЕТ.
Смотрел соединения на маршрутизаторе: КСЛ постоянно пробовал соединиться с резервным адресом диспетчерской... и только после перезагрузки (иногда ни одной) маршрутизатора и/или КСЛ связь восстанавливалась. Причем это наблюдалось в обе стороны: при переключении на резерв и с резерва на основной канал.

Подскажите, у кого-нибудь такая схема с одним маршрутизатором на УМ работает? На чем?
котяра
ну мы тож так пытались вначале... на TP-Link 3420.... не работает...
revit
Цитата(pavel @ 21.2.2013, 17:37) *
Подскажите, у кого-нибудь такая схема с одним маршрутизатором на УМ работает? На чем?

Ну тут наверное лучше бы объяснил разработчик ПО LKDSDRV Андрей Ефименко.
Я не использую резервирование на удаленных УМ. В центральной использую резервирование по интерфейсам и стоит два роутера.
По поводу применения одного маршрутизатора в резервировании было мыслишки такие. Проверял работу Zyxel Keenetik 4G провод+Skylink просто для выхода в инет с компа - работает как часы. К сожалению проверить его в работе с ОБЬю пока не получилось, но правда и применить я хотел такую связку только в ЦД. Теоретически должно работать, а практически могут всплыть всякие сюрпризы-что видимо у вас и получилось, поскольку работа резервирования задумана была и отлаживалась , как я понимаю именно по интерфейсам в ПКСЛ и по шлюзам в моно и КСЛ.
Если, в моем случае, с ПКСЛ и одним интерфейсом резервирование должно быть и не противоречит работе винды, то в вашем случае железяка всегда один шлюз знает. а второго резервного нет.
вы вообще как второй шлюз прописываете в железяке?
pavel
Цитата(revit @ 22.2.2013, 0:52) *

Ну тут наверное лучше бы объяснил разработчик ПО LKDSDRV Андрей Ефименко.
вы вообще как второй шлюз прописываете в железяке?


Мы уже давно общаемся по почте на эту тему с Андреем. Сегодня, например, был выслан захваченный в процессе 40 минутного эксперимента трафик.

"Второй шлюз в железке" - если это про аппаратный КСЛ. То делал по разному: не прописывал, прописывал повторно 192.168.0.1 (как и основной). Не работают оба варианта.
revit
Цитата(pavel @ 22.2.2013, 3:33) *

То делал по разному: не прописывал, прописывал повторно 192.168.0.1 (как и основной). Не работают оба варианта.
Т.е резервный шлюз с дублирующим IP прописывается... Но это уже недоработка разработчика-если КСЛ рассчитан на резервирование по шлюзам, то одинаковыми они быть не могут. Тем более что они и не работают, да и не должны по идее работать на одном.
Fixer
Так поднимите VPN тогда. И микротики в оба конца, пускай пинают друг друга ping watchdog'ом. И переключать ничего не придется
Андрей Ефименко
Цитата(revit @ 22.2.2013, 0:52) *

Ну тут наверное лучше бы объяснил разработчик ПО LKDSDRV Андрей Ефименко.

Конечно использование саморезервирующихся маршрутизаторов было бы заманчиво, но это резервирование ориентировано на бытовое применение, т.е. на короткоживущий обмен "Запрос"-"Ответ". В случае оборудования "Обь" происходит длительный обмен по фиксированным портам.

Был проведен эксперимент c DIR320 c прошивкой 1.21

1) в LAN DIR320 подключен Моноблок
2) разъем Internet DIR320 подключен во внешнюю Ethernet сеть
3) 3G модем (МТС) подключен в разъем USB DIR320
4) в LAN DIR320 подключен компьютер в котором настроен ЛокальныйПКСЛ

Ну и суть эксперимента:

Переключая вручную внешнее подключение DIR320 с помощью компьютера между Internet и USB проверяем хождение пакетов между моноблоком и удаленным ПКСЛом, между локальным ПКСЛом и удаленным ПКСЛом

После переключения Internet <-> USB связь Моноблок<->УдаленныйПКСЛ теряется, теряется и связь локальн.ПКСЛ <-> УдаленныйПКСЛ

Если загрузить программу посылки UDP пакетов на компьютере в LAN маршрутизатора и на компьютере удаленного ПКСЛ, то обмен идет.

Связь Моноблок<->УдаленныйПКСЛ и локальн.ПКСЛ <-> УдаленныйПКСЛ восстанавливается только после перезагрузки маршрутизатора из страницы управления (кнопка "Перезагрузка" )

Проблема в маршрутизаторе. После смены WAN интерфейсов в маршрутизаторе сохраняются маршруты в таблице протокола NAT. После рестарта маршрутизатора таблицы протокола NAT очищаются и работоспособность восстанавливается.
revit
Древний (уже) DIR-320 с МТС, имхо, не показатель, у них были причуды. Нужно бы проверить на ZYXEL Keenetik 4G с прошивкой v.2.
pavel
Цитата(revit @ 21.3.2013, 18:24) *

Древний (уже) DIR-320 с МТС, имхо, не показатель, у них были причуды. Нужно бы проверить на ZYXEL Keenetik 4G с прошивкой v.2.


Проверяли с Keenetik 4G, проверяли с Mikrotik, проверяли с несколькими D-Link - НЕ РАБОТАЕТ. Хотя все остальные сервисы и протоколы Интернет работают.

В корне не согласен с Андреем Ефименко про "бытовой обмен". Андрей, по вашему маршрутизаторы Cisco или Juniper или тот же D-Link от 10 тыс. руб., которые также могут самостоятельно переходить на резервные каналы, которых может быть хоть 10 - это тоже бытовые приборы???

Признаю, возможно, Вы верно определили проблему. Но только дело не в маршрутизаторе - они все так себя ведут. И это запись в таблице NAT не долгоживущая. Если сделать хотя бы небольшую паузу в обмене, либо сменить на время порт - всё заработает.

Считаю, что резервирование через один маршрутизатор в случае УМ более предпочтительно.
Возьмем вашу схему с двумя. Как Вы понимаете у КСЛ один сетевой интерфейс и он может быть подключен только в один из маршрутизаторов, второй маршрутизатор подключается также в первый. Таким образом при выходе из строя основного маршрутизатора - резерв не работает. Т.е. смысла в двух железках нет. Вместо двух за 1000 руб. мы можем взять один, но уже за две. Тот же Zyxel, Keenetiк, которые могут и умеют намного больше обычно D-Link. Ведь когда всё работает разницы между маршрутизаторами мы не видим. А вот когда начинаются проблемы - иметь под рукой более продвинутую железку намного лучше.

На zyxel была прошивка v.2. Выше котяра писал, что пробовали на TP-Link 3420 - тоже не работает.
Van Gog
Цитата(pavel @ 25.3.2013, 7:23) *

Считаю, что резервирование через один маршрутизатор в случае УМ более предпочтительно.
Возьмем вашу схему с двумя. Как Вы понимаете у КСЛ один сетевой интерфейс и он может быть подключен только в один из маршрутизаторов, второй маршрутизатор подключается также в первый. Таким образом при выходе из строя основного маршрутизатора - резерв не работает. Т.е. смысла в двух железках нет. Вместо двух за 1000 руб. мы можем взять один, но уже за две.

Сколько людей - столько мнений... Как вы говорите "...при выходе из строя основного маршрутизатора - резерв не работает." Совершенно верно, но достаточно ОПЕРАТИВНО может приехать связист, подойти электромеханик или (даже не очень грамотный) обходчик и просто переткнуть кросс от второго маршрутизатора напрямую в КСЛ. А в Вашем случае нужно держать такую же железяку, залить в неё настройки и привезти на объект. Кроме того, нужно учитывать, что резервируются КАНАЛЫ связи на случай "падения", но не оборудование. Иначе Вам придётся каким-то образом резервировать оборудование ЛКДС wink.gif . Ещё один нюанс: в текущей схеме вся логика переключения зашита в ПО от ЛКДС и в рамках сети "Обь" оптимизирована, а вот как будут вести себя железяки разных производителей (или даже одни и те же железки, но с разными прошивками) предсказать сложно.
Цитата(pavel @ 25.3.2013, 7:23) *

Тот же Zyxel, Keenetiк, которые могут и умеют намного больше обычно D-Link. Ведь когда всё работает разницы между маршрутизаторами мы не видим. А вот когда начинаются проблемы - иметь под рукой более продвинутую железку намного лучше.

Я только "за" продвинутые железки, когда они стоят в офисе и действительно создают комфорт в работе. Но если дешёвый DIR справляется с поставленной задачей на 300% зачем платить больше и ставить "киску"? Тем более, что их надо не две и не три штуки в отличие от офиса.
Fixer
Зачем платить за унылый DLink, если можно купить микротик?
Я повторю: чтобы не клепать КСЛу мозги резервными связями через разные аплинки на роутере, проще абстрагировать КСЛ от интернетов вообще. Объясните роутеру, что хотите VPN, покажите ему два аплинка, покажите порт с КСЛ. Вуаля! Рабоатет.
lms-i
Цитата(Van Gog @ 25.3.2013, 23:25) *

Сколько людей - столько мнений... Как вы говорите "...при выходе из строя основного маршрутизатора - резерв не работает." Совершенно верно, но достаточно ОПЕРАТИВНО может приехать связист, подойти электромеханик или (даже не очень грамотный) обходчик и просто переткнуть кросс от второго маршрутизатора напрямую в КСЛ. А в Вашем случае нужно держать такую же железяку, залить в неё настройки и привезти на объект. Кроме того, нужно учитывать, что резервируются КАНАЛЫ связи на случай "падения", но не оборудование. Иначе Вам придётся каким-то образом резервировать оборудование ЛКДС wink.gif . Ещё один нюанс: в текущей схеме вся логика переключения зашита в ПО от ЛКДС и в рамках сети "Обь" оптимизирована, а вот как будут вести себя железяки разных производителей (или даже одни и те же железки, но с разными прошивками) предсказать сложно.

Я только "за" продвинутые железки, когда они стоят в офисе и действительно создают комфорт в работе. Но если дешёвый DIR справляется с поставленной задачей на 300% зачем платить больше и ставить "киску"? Тем более, что их надо не две и не три штуки в отличие от офиса.

Ууу, как интересно. Какая бесполезная критика из темы лишь бы что-то сказать не подумавши. Вы маленько сами запутались и других пытаетесь запутать.
Необходимо понять что Вам не нравиться в схеме. Наличие одной железки вместо двух или возможность вручную специально не обученным персоналом переключить "кросс" в КСЛ, а также наличие админа сети.
С Вашими доводами не соглашусь, т.к.:
1. Две железки - большее количество точек отказа, тех же гнезд, кроссов, блоков питания, аппаратная часть самих железок. Если УМ 10-15, то количество проблем возрастает в прогрессии. Я это говорю из опыта, а не просто так теоритически. Мы этот этап прошли.
2. Качество. Более умная железка - это еще и более качественная железка бизнесс класса (а не Home вариант), по цене сопоставимая (ну может чуть дороже) с двумя железками, хорошей сборки. Т.о. отказоустойчивость одной хорошей железки в несколько раз выше чем у двух дешевых. Zyxel считаю все таки бюджетным вариантом, есть получше производители, но уже удачнее чем dir-320.
3. Обслуживание. Если вы уже взялись обслуживать такую схему, структуру, то извините, вы должны иметь запасную железку, хоть плохого качества, хоть хорошего. И ту и другую необходимо будет настраивать при замене. И хоть в одном случае, хоть в другом МОЖНО ПЕРЕТКНУТЬ "КРОСС" В КСЛ!!! Нет разницы одна или две железки, даже слабообученный может это сделать.
И, что очень считаю важным, раз вы взялись за сетевое оборудование, то будьте любезны иметь системного админа в штате! Это уровень организации качественного обслуживания, специалист должен обслуживать сетевое оборудование (пусть и не на полную ставку), а не самоучка. Это не камень в огород добрых ребят которые с опытом познали хитрсти сетевого оборудования, а подход с точки зрения организации обслуживания. Каждый должен делать свою работу, и между связистом и админом должна быть разделена зона ответственности. ИМХО.
4. Замена. Любой КСЛ, Моноблок, маршрутизатор при замене необходимо конфигурировать. Любую из этих железок может законфигурировать по инструкции любой лузер, мало мальски знакомый с компьютером. Главное как граммотно составлена инструкция, подготовлены ли конфиги под все УМ, под все оборудование. Тем более админ должен быть всегда на связи. В XXI веке есть ноутбук, WiFi, 3G инет, телефон, и по этим средствам он может всегда помочь организовать замену если сам не имеет возможности.
5. А вы не резервируете оборудование ЛКДС? Очень интересно, как так? Ждете пока придет от производителя, оплата, доставка и т.д.? Не понятно...
6. Логика переключения в ЛКДС своеобразна. Логика переключения всех маршрутизаторов - логична и одинакова. Я не админ, спросите у системного администратора с высшим профильным образованием, он вам объяснит. Переключение на ноутбуке с одним маршрутизатором и двумя провайдерами работает, а такая же схема с КСЛ не работает, при чем использовались 3 разных производителя маршрутизаторов.
7. Dir-320 не справляется с поставленной задачей на 300% - факт! У меня дома такой, имели неосторожность на работе поставить для раздачи WiFi на ноут в 3-х метрах. Постоянно проблемы. Часто сбоит. Отказались. Если у вас справляется - дикое везение. Наверное мало штук эксплуатируется.

Господа форумчане! Примите участие в обсуждении. Все мнения интересны и "+" и "-", только конструктивно! )
pavel
Цитата(Fixer @ 26.3.2013, 9:16) *

Зачем платить за унылый DLink, если можно купить микротик?
Я повторю: чтобы не клепать КСЛу мозги резервными связями через разные аплинки на роутере, проще абстрагировать КСЛ от интернетов вообще. Объясните роутеру, что хотите VPN, покажите ему два аплинка, покажите порт с КСЛ. Вуаля! Рабоатет.


Приветствую. Спасибо за внимание к теме.

Идею я понял еще из первого Вашего поста. В принципе, VPN для нас - это выход из ситуации. Собираемся постепенно переходить на Микротики в УМ, в диспетчерской стоит сервер Linux. Так что сделать такую схему можно. Плюс повышение сетевой безопасности оборудования ЛКДС и самой диспетчерской - то о чем производитель вообще не думает, на мой взгляд.

Просьба поделиться опытом реализации VPN для сети Обь, если таковой имеется.

Однако, есть диспетчерские, в которых мы отвечаем за программную часть и за связь с обслуживаемыми УМ. Их несколько. Там сервера нет. Соответственно нужно будет ставить программку VPN на винду... и тут надженость связи падает. Еще одна точка отказа.

В маршрутизаторах, умеющих переключать каналы Интернет, нет ничего особенного. На то они и маршрутизаторы. Считаю, что ЛКДС должны довести до ума протокол обмена Оби. Ведь подобная проблема с таблицей NAT, по большому счету, может встречаться и в случае обычного не статического 3G на стороне провайдера. Если ЛКДС решит данную проблему то, надежность самого протокола Оби только возрастет.

Как сказал Van Gog:"резервируются КАНАЛЫ связи на случай "падения", но не оборудование". Так пусть каналы как раз и резервируются. Количество железок и сами каналы - это выбор клиента ЛКДС, заплатившего около 10 000 за КСЛ или Моноблок.
Gaff
Цитата(pavel @ 26.3.2013, 9:50) *

в диспетчерской стоит сервер Linux.

Извиняюсь за оффтоп. А расскажите пожалуйста, если не сложно, в качестве чего у Вас используется сервер с Linux? Просто база данных хранится или программа портирована, или просто в качестве маршрутизатора, или ..., или .... smile.gif Вообще как?
Любопытно знать
котяра
Цитата(pavel @ 26.3.2013, 11:50) *

Приветствую. Спасибо за внимание к теме.

Идею я понял еще из первого Вашего поста. В принципе, VPN для нас - это выход из ситуации. Собираемся постепенно переходить на Микротики в УМ, в диспетчерской стоит сервер Linux. Так что сделать такую схему можно. Плюс повышение сетевой безопасности оборудования ЛКДС и самой диспетчерской - то о чем производитель вообще не думает, на мой взгляд.

Просьба поделиться опытом реализации VPN для сети Обь, если таковой имеется.

Однако, есть диспетчерские, в которых мы отвечаем за программную часть и за связь с обслуживаемыми УМ. Их несколько. Там сервера нет. Соответственно нужно будет ставить программку VPN на винду... и тут надженость связи падает. Еще одна точка отказа.

В маршрутизаторах, умеющих переключать каналы Интернет, нет ничего особенного. На то они и маршрутизаторы. Считаю, что ЛКДС должны довести до ума протокол обмена Оби. Ведь подобная проблема с таблицей NAT, по большому счету, может встречаться и в случае обычного не статического 3G на стороне провайдера. Если ЛКДС решит данную проблему то, надежность самого протокола Оби только возрастет.

Как сказал Van Gog:"резервируются КАНАЛЫ связи на случай "падения", но не оборудование". Так пусть каналы как раз и резервируются. Количество железок и сами каналы - это выбор клиента ЛКДС, заплатившего около 10 000 за КСЛ или Моноблок.



нда... и откуда такие люди берутся... умничать многие могут, а вот помочь...
Van Gog
Цитата(котяра @ 26.3.2013, 18:37) *

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

Я уже говорил, что сколько людей, столько и мнений. Возможно господа пришли в лифтовую отрасль из "сетевиков", возможно у них настолько могучая и богатая организация, что не жалеет денег на грамотных спецов и дорогое оборудование, возможно... и т. д. Я лишь высказал своё IMHO.
revit
котяра ты бы цитаты более конкретные делал (и маленькие ). А то нифига непонятно к чему относится ответ, а пол страницы занимает.
Fixer
Цитата(pavel @ 26.3.2013, 10:50) *

Просьба поделиться опытом реализации VPN для сети Обь, если таковой имеется.

Что именно интересует?
Режим VPN - EoIP, это позволяет включать OSPF, каковой самостоятельно разбирается с отвалившимися маршрутами, главное не забыть usb свистульке метрику побольше нарисовать. 3G модем в режим wake on demand. Все вроде. Единственная проблема - 3G у нас так себе, связь нестабильная и переговорка рвется
pavel
to Gaff:
В качестве всего smile.gif: маршрутизатор (несколько внешних подключений), сетевое хранилище, архивное хранилище, NTP сервер (у нас в диспетчерских точное время, а у Вас smile.gif ), SFTP сервер (архивное копирование LKDSDrv с удаленных диспетчерских). Есть и web-приложения: мониторинг работы инетернет каналов УМ, база данных и т.д.

to котяра:
Уточни свою реплику. Если это переход на личности - welcome в личку, тема создавалась не для этого. Что касается помощи: по просьбам и методикам ЛКДС я лично провел 4 теста, часа по полтора каждый, не считая времени на подготовку, а в случае УМ это не так просто. Все результаты отправлял им, в том числе захваченные пакеты обмена Оби. До этого было тестов 10, пока они обратили внимание на проблему. Если им что-то еще нужно, мы протестируем и поможем. Но на данный момент, из поста Ефименко, ничего делать они не собираются.

to Van Gog:
я лично из "сетевиков". Но только я из них никуда не уходил. У меня есть своя часть работы, за которую и отвечаю. В этой работе мне бы очень помогло, если бы КСЛ и Моноблоки избавились от проблемы обозначенной в заголовке темы. Денег у нас немного. Просто вместо двух D-Linkов хотим один Микротик. Деньги теже.

to Fixer:
Будем на неделе обкатывать VPN.

Давайте вернемся к теме.
Итак, резерв на УМ через один маршрутизатор не работает. Нашей компании нужно, чтобы он работал. Аргументы уже были приведены. Если Вам сейчас, либо в будущем может понадобится подобная схема, просьба сообщить об этом в данной ветке. Чтобы господа из ЛКДС все-таки начали решать проблему. Спасибо.

lms-i
Цитата(Van Gog @ 27.3.2013, 0:23) *

Я уже говорил, что сколько людей, столько и мнений. Возможно господа пришли в лифтовую отрасль из "сетевиков", возможно у них настолько могучая и богатая организация, что не жалеет денег на грамотных спецов и дорогое оборудование, возможно... и т. д. Я лишь высказал своё IMHO.

Уважаемый Van Gog, господа пришли в лифтовую отрасль из советского треста "Союзлифтмонтаж" после реорганизации, который был создан по постановлению совета министров СССР в 1949г., за подписью товарища Сталина! Я не шучу. Это наша история, много кто в стране от туда.
Что касается сетевиков, могучести и богатства - все проще. Всего на обслуге 1200 единиц, это по сравнению с конторами по стране не много, мы не монополисты, есть в городе и больше. У нас в регионе тариф один из самых низких в стране, а наличие спеца - это необходимость. Условия жизни на рынке заставляют выкручиваться, если хочешь быть на пол шага впереди.
И что самое главное, технологии идут вперед, заказчик требует надежности и безотказности, а мы в данной теме как раз этого и добиваемся. На перспективу и развитие предприятие наверное должно работать! Сейчас основные жилые массивы диспетчеризированны в локальные местные диспетчерские. По городам растут точечные застройки, в частных секторах, на месте снесенных бараков, выкроенных кусочках и т.д. Которые необходимо тоже диспетчеризировать и как-то обслуживать. Такие же точечные ситуации есть в коммерческих и бюджетных организациях (не жилье). Так вот именно в таком случае и необходимо применять новые технологии, в основном Ethernet. А если таких одиночек много, то встает вопрос о втором провайдере и соответственно о надежности оборудования УМ. Чтобы как можно меньше туда ездить, если еще объекты географически по разным частям города разбросаны. Железо должно стабильно работать, а не выносить мозг (как в случае с dir-320 и подобными).
Каждый раз когда пропадает связь с таким объектом (не важно по какой причине), а там как правило элитное жилье, то становится жутковато. Если какой-нибудь вааажный член там застрянет и не дозвониться до диспетчера, и сотовая связь не ловит - он потом тебя найдет, приедет и по шапке даст. Это в лучшем случае, а если ребенок, старая бабуля...

Неужели это надо Вам объяснять, опытные лифтовики? Мы ничего сверхестественного не просим, только доработку в пользу отрасли.

P.S.: Есть такая поговорка: "Один дурак может задать вопрос на который сто умных не ответят". Давайте коллеги по теме и без флуда.
pavel
Резервирование УМ с использованием двух маршрутизаторов прекрасно описано ЛКДС и прекрасно работает.

Резервирование через один маршрутизатор, в который подключены два и более провайдеров (ethernet + 3G, либо два Ethernet) не работает.

Вся история здесь:
http://www.lkds.ru/forum/index.php?showtopic=2925

Голосуем, высказываемся!

Просьба к модераторам закрепить тему сверху.
pavel
Создал опрос в ветке про КСЛ.

Просьба принять участие!

http://www.lkds.ru/forum/index.php?showtopic=2946
revit
Я, допустим, на самом деле, настолько острой проблемы резервирования УМ не ощущаю пока, т.к в основном используются подключения ADSL и Skylink и с нормальными роутерами соединения достаточно надежные (более 50 скай и 30 или более адсл, все без УПП) Проблема в полный рост проявляется на Ethernet подключениях в жилье (FTTH, FTTB). Да-да той самой- "надежной оптике". При всей своей простоте и якобы надежности она на практике в жилом фонде проигрывает по стабильности подключения вышеуказанным технологиям т.к использует энергозависимое промежуточное оборудование - те же конвертороы , свитчи провайдера и пр., которые провайдеры не балуют хорошими ИБП или вообще их не ставят. Получается что при каждом отключении электроэнергии, и не только в доме где стоит оборудование, но и в других через которые проходит оптика, пропадает связь. Вот тут бы и пригодилось резервирование на основе проводного роутера с USB свистком. И просто и дешево и без дополнительных железяк, да еще и запитать можно от моно (ну почти-есть проблемы).....
Но ! как быть с контролем тех же USB свистков резервных каналов. Их же надо как-то контролировать? Ну т.е если основное оборудование всегда он-лайн и всегда на контроле то это, резервное –как пожарное оборудование. Оно вроде и есть и всегда должно быть в 100% готовности, но кто об этом знает ?? Я уже где то писал об этом.. И может получиться так что пропала связь –а там уже оказывается нет свистка, кто-то вытащил , или он не работает или еще чего (учитывая что в мет.ящик их не спрячешь)
Вообщем выходит что тут не только однозначно польза, но и дополнительные проблемы. Нужно программно делать его проверку по расписанию с отчетом каждые сутки.
Нужно иметь подменное резервное оборудование кроме основного.
Нужно следить и платить за резервные каналы не используя практически их.

А кстати в диспетчерской никто не пробовал такой вид резервирование? В ЦД и ЛД такой вариант точно нужен т.к на тех же ноутах только один сетевой интерфейс а прикручивать USB-ишные не есть гуд. Ну а о пользе применения ноута в диспечтерских, думаю объяснять не нужно.. smile.gif
revit
Не могу ответить ни ДА ни НЕТ. Считаю что если будет такая возможность в КСЛ-ах, без ущерба остальным функциям, то конечно хорошо. Ну а если нет, то тем кому очень нужно могут и микротики пристроитьс VPN-ами. ИМХО.
Gaff
Цитата(revit @ 27.3.2013, 10:43) *

Не могу ответить ни ДА ни НЕТ. Считаю что если будет такая возможность в КСЛ-ах, без ущерба остальным функциям, то конечно хорошо. Ну а если нет, то тем кому очень нужно могут и микротики пристроитьс VPN-ами. ИМХО.

+1
Gaff
Хотел бы что-нибудь добавить к rivit`у, а нечего, потому что все точно так же, за исключением того, что вместо скайлинка, у меня мегафон (в городе нет cdma), а вместо adsl - wi-max (adsl сейчас уже практически не подключают и по опыту коллег из конкурентной компании знаю, что качество его оставляло желать лучшего, особенно работа тех. поддержки, бывало, что по полмесяца не могут восстановить канал).
А насчет проводных интернетов, у нас в городе цены для организаций такие, что мне дешевле позвать wi-max провайдера и не надо в обязательном порядке резервный канал поднимать, достаточно ИБП, а если уж что случится, что происходит крайне редко и не связано с отключением света чаще с вандалами, то тут в любом случае на объект ехать
Александр Смышляев
Цитата(pavel @ 27.3.2013, 12:13) *
Резервирование УМ с использованием двух маршрутизаторов прекрасно описано ЛКДС и прекрасно работает.

Резервирование через один маршрутизатор, в который подключены два и более провайдеров (ethernet + 3G, либо два Ethernet) не работает.

Вся история здесь:
http://www.lkds.ru/forum/index.php?showtopic=2925

Возможно вы невнимательно читали ответы... возможно что-то еще... Но так или иначе так и не смогли понять, что резервирование, с использованием одного маршрутизатора, от ЛКДС ни как не зависит. Это внутренняя функция маршрутизатора.
Отсюда ваш опрос сводится к теме: стоит ли ЛКДС разработать собственный маршрутизатор. Ответ однозначный, на мой взгляд - нет, не стоит. Ничего другого в данном аспекте вопроса компания сделать не сможет...

... как модератор: опрос считаю некорректным - подниматься не будет (но и удалять пока не стану...)
Van Gog
Цитата(revit @ 27.3.2013, 9:43) *

Не могу ответить ни ДА ни НЕТ. Считаю что если будет такая возможность в КСЛ-ах, без ущерба остальным функциям, то конечно хорошо. Ну а если нет, то тем кому очень нужно могут и микротики пристроитьс VPN-ами. ИМХО.

Не могу ответить ни ДА ни НЕТ ибо на сегодня не вижу никакой проблемы. Но раз у Лифт-Комплекса есть заказчики, которые эту проблему видят и (судя по достаточно эмоциональным постам) это проблема велика, то конечно нужно что-то решать. Я бы предложил в новой версии КСЛ и Моно устанавливать два сетевых интерфейса и USB для программирования и подключения "свистков", тем более, что в линейке Cortex наверняка найдётся подходящий проц. А ценой нас не испугать wink.gif ! У конкурентов всё равно ничего подобного не предвидится.
revit
Александр, вопрос звучал так -почему не работает с пакетами UDP ОБИ а с другими работает?
Цитата(pavel @ 25.3.2013, 7:23) *

Проверяли с Keenetik 4G, проверяли с Mikrotik, проверяли с несколькими D-Link - НЕ РАБОТАЕТ. Хотя все остальные сервисы и протоколы Интернет работают.

У меня тоже было такое предположение что это особенность роутеров.
Нечто похожее у меня проявлялось при работе УМ на динамике Ская на две диспетчерские. При реконнекте точки она могла отвалиться от одной из диспетчерских и я выяснил что так вели себя именно роутеры именно у Ская. Он продолжал держать сессию на старом IP, когда свисток уже получил новый.

Если Андрей Владимирович разъяснит ситуацию, думаю все будут благодарны.
Александр Смышляев
Цитата(revit @ 27.3.2013, 13:32) *
Александр, вопрос звучал так -почему не работает с пакетами UDP ОБИ а с другими работает?
Так в том-то и дело. На чем вы еще UDP пакеты проверите? В 95% случаев (а может и больше) вы имеете дело с TCP - там работают совершенно другие законы...

Цитата(revit @ 27.3.2013, 13:32) *
У меня тоже было такое предположение что это особенность роутеров.
Нечто похожее у меня проявлялось при работе УМ на динамике Ская на две диспетчерские. При реконнекте точки она могла отвалиться от одной из диспетчерских и я выяснил что так вели себя именно роутеры именно у Ская. Он продолжал держать сессию на старом IP, когда свисток уже получил новый.
Ну так вот и один из вариантов ответа. Модем/роутер/свисток или что там еще может быть вносят свой "посильный вклад" в общую картину. И КСЛ/моноблок тут и ни при чем...
pavel
revit совершенно верно подметил, что вопрос несколько в другом.

Я уже несолько раз писал, что скорее всего ЛКДС верно определило суть проблемы, вот слова Андрея Ефименко:
"проблема в маршрутизаторе. После смены WAN интерфейсов в маршрутизаторе сохраняются маршруты в таблице протокола NAT. После рестарта маршрутизатора таблицы протокола NAT очищаются и работоспособность восстанавливается."

Под данную гипотезу все наши проблемы, с четырьма разными маршрутизаторами, подходят.
Итак пусть гипотеза верна.

Зайдем с другой стороны. Четыре разных маршрутизатора, от разных производителей, переключаются на резервный канал. Через них работают все сервисы и протоколы Интернет. Если какие-то сессии и рвутся, то достаточно переподключить программу и всё работает дальше. Не нужно для этого перезагружать маршрутизатор. Почему? Потому что так устроены протоколы Интернета. Они справляются с таким переключением.

Мы хотим чтобы протокол Оби так же справлялся с этим.
Из описания проблемы я вижу несколько выходов:
1) увеличить интервал между отправкой пакетов от КСЛ к соседям в случае, если нет подтверждения связи, либо постоянно поступают запросы от соседей на обмен информацией. Можно сделать его параметром в окне настройки КСЛ.
2) вместо указания второго шлюза КСЛ, сделать возможность задавать паузу в обмене с соседями в случае потери связи. Т.е. те у кого два маршрутизатора - указывают второй шлюз, мы указываем "помолчи немного" пока запись в таблице NAT маршрутизатора состарится и сама удалится.
3) временно переключаться на другой порт отправки данных (использовать голосовой, например).

Повторюсь. Переключение на резервный канал - обычная функция для маршрутизаторов. В них во всех есть таблицы NAT. Во всех них записи удаляются только если не используются. Это можно сказать стандарт сети Интернет. Ну, так давайте с учетом этого стандарта разрабатывать оборудование, раз оно передает данные через этот самый Интернет.

Не нужен нам маршрутизатор от ЛКДС! Не нужно аппаратно менять КСЛ!
Нужно только чуть-чуть докрутить микропрограмму в нем и в LKDSDrv для ПКСЛ. Всё!

Конечно, никто не говорит об ухудшении КСЛов за счет этой доработки. Доработка - улучшение функионала, а никак не наоборот. Нам ухудшенные КСЛ тоже не нужны smile.gif

У меня есть возможность протестировать переключение на маршрутизаторе Juniper SRX100 стоимостью (в рознице так сказать) около 30 000 руб. Это корпоративный уровень, это вторая после Cisco компания по качеству производимых маршрутизаторов. Вопрос к ЛКДС. Если тест на Juniper даст теже результаты, Вы не станете говорить, что это маршрутизатор? Что это не Ваша проблема? Вы начнете ее решать?

Скажите нам тогда, а какой маршрутизатор ПРАВИЛЬНО переключается на резерв. В студию!
Александр Смышляев
Цитата(pavel @ 27.3.2013, 14:33) *
Я уже несолько раз писал... (и далее по тексту)
Хорошо пишите... много... местами аргументировано...
Только все, что вам нужно уже сделано. Возьмите УПП, настройте КСЛ и будет вам счастье.
pavel
Цитата(Александр Смышляев @ 27.3.2013, 14:57) *

Хорошо пишите... много... местами аргументировано...
Только все, что вам нужно уже сделано. Возьмите УПП, настройте КСЛ и будет вам счастье.


За 950 руб. можно и маршрутизатор выпустить, OEM D-Link. Который всё будет делать как надо wink.gif
котяра
вот достала тема. весь день на неё угробил, только для чего сам не пойму... а время не резиновое..
собрал на столе конструкцию...
1. моноблок с 3 подключёными блоками
2. маршрутер с поддержкой WAN и 3G
3. проводной и "свисток" имели статические IP-адреса.
4. на ноуте создал ПКСЛ через 3g-модем (статика). прописал как положено всё...
5. настроек минимум указал (я ж не "сетевик" мне чем попроще тем лучше)

одним словом. с TP-Link 3420 заработало... на столе...

буду юзать дальше...
котяра
Цитата(pavel @ 27.3.2013, 14:33) *

Из описания проблемы я вижу несколько выходов:
1) увеличить интервал между отправкой пакетов от КСЛ к соседям в случае, если нет подтверждения связи, либо постоянно поступают запросы от соседей на обмен информацией. Можно сделать его параметром в окне настройки КСЛ.


насколько знаю в ксл/моноблоке есть параметр: "ожидание соединения после рестарта" думаю можно воспользоваться и им... зачем новое городить то...
lms-i
Цитата(котяра @ 27.3.2013, 17:02) *

вот достала тема.


Конечно достала, зачем ее и открыли.

Я вот мужики одного не пойму, в каком сегменте отрасли вы работаете. Ведь хоть с DSL, хоть со Скайлинком, хоть с Мегафоном, хоть с оптикой, да хоть с чем могут быть проблемы. Я повторюсь: отключения питания, аварии на оборудовании провайдера (у всех были), плановые технические отключения - это все присутствует в нашей жизни, этого не избежать.
Так вот про сегмент. Мне не понятно, почему то вас особо не беспокоит отсутствие связи с удаленным УМ. То ли вы не сталкиваетесь с этим непосредственно; то ли не отвечаете за это напрямую; то ли у вас служба налажена с таким давлением на Заказчика, что мол мы крутые, нет связи - "ну такие дела" мы не причем и все, ждем пока наладится; то ли конкуренции нет; то ли идеальные услуги провайдер предоставляет и ни одного перебоя нет; то ли начальству по барабану кто там застрянет - сам вылезет. Честно, ей богу, мне не понятно...
Мы пытаемся найти понимание на форуме, а получается "требуем фигню", нас еще и дураками пытаются обозвать. Ну мы же не из пальца высосали эту проблему. Если у вас нет такой ситуации, то это не значит что в других городах так же. По каким то причинам народ не беспокоится. Но поверьте, рано или поздно поднимется вопрос о повышении надежности и качества. Кто то поддерживает идею, а кто то и стесняется согласиться, а кто то подводные камни ищет.
Мы за здоровый диалог и надо подумать хорошо прежде чем критиковать.

Разработчики конечно смотрят на это отчасти с непониманием - "вот пристали"...Но им не ходить в прокуратуру, почему бабуля прибралась и т.д. А кто хоть раз там был (в прокуратуре) тот поймет, и каждый раз при отсутствии связи будет нервничать. Все эти нервы увеличиваются с количеством УМ.

Начинают припарки предлагать. Поставьте две железки, поставьте УПП. Зачем городульки городить. Пытаемся оптимизировать и упростить схему. Обратите внимание на проблему, мы не просим завтра ее решить. Пытаемся уровень приподнять. Ведь вы поставляете продукцию и на запад. Мне кажется европейские специалисты усмехнуться и спросят зачем две железки, почему нельзя реализовать одну? УПП не плохая вещь, на не в этом случае.

Что касается сохранности и диагностики УМ - все это фигня, если захотеть можно все организовать. Персонал который заходит в МП можно четко отследить, опять же при желании. Также этот персонал можно обязать проверять и наличие свистка, и проверить резерв (выдернув шнурок). Ведь кто-то ходит по МП с определенной периодичностью. Тут дело организации - это не есть проблема. Платить дополнительно 150 руб в месяц за точку и быть спокойным - мы согласны, нервы дороже и бензин и труд (если придется туда ехать). Порой и Заказчик даже это понимает, он согласен платить за второго провайдера, лишь бы надежнее было.

Я просто две ветки почитал и расстроился если честно. Мне на семинаре в июле 2012 в Бердске всё казалось таким светлым и дружным. А оказывается не так все и светло. С пониманием туго. Но энтузиасты пока есть!!! )))

Котяра, я надеюсь проверял преключение на 3G при отключении WAN? И что значит заработало, на ЦД выводил? Очень интересно чем эксперимент закончится.

revit, в нескольких диспетчерских стоят свистки, роутер там ставить не резонно.




Александр Смышляев
Цитата(pavel @ 27.3.2013, 15:17) *
За 950 руб. можно и маршрутизатор выпустить, OEM D-Link. Который всё будет делать как надо wink.gif
Если можно, то сделайте - народ вам спасибо скажет (ну и покутать, наверно, будет...)

Цитата(pavel @ 27.3.2013, 14:33) *
Из описания проблемы я вижу несколько выходов:
1) увеличить интервал между отправкой пакетов от КСЛ к соседям в случае, если нет подтверждения связи, либо постоянно поступают запросы от соседей на обмен информацией. Можно сделать его параметром в окне настройки КСЛ.
2) вместо указания второго шлюза КСЛ, сделать возможность задавать паузу в обмене с соседями в случае потери связи. Т.е. те у кого два маршрутизатора - указывают второй шлюз, мы указываем "помолчи немного" пока запись в таблице NAT маршрутизатора состарится и сама удалится.
3) временно переключаться на другой порт отправки данных (использовать голосовой, например).
1. Боюсь, что вы не являетесь разработчиком маршрутизаторов... и даже отдаленно не представляете, сколько времени требуется на то ожидание, которое вы предлагаете. Сколько ждать-то? Минуту, десять, час... Просто ждать и ничего не делать! Пусть человек посидит в кабине! (ему, наверно, полезно...)
И еще очень большой вопрос, а сбросится ли она (таблица/запись) по истечении какого-либо времени. Очень может быть, что она сбросится (как очень старая) только, если вся таблица будет заполнена, и понадобятся новые строки. А она (таблица) никогда не заполнится - некому ее заполнять, кроме КСЛ'а...
2. Ну, собственно, это все о том же...
3. Переключение на другой порт (но только не на голосовой) даст эффект. Но не следует забывать, что есть и статическая маршрутизация. А ей пользуются многие, почти все (если IP статический).

Цитата(pavel @ 27.3.2013, 14:33) *
Мы хотим чтобы протокол Оби так же справлялся с этим.
"Мы" - это вы о себе во множиственном числе? Кроме вас об изменении протокола, вроде, ни кто не говорит...

Ну и если вы готовы поставить роутер за 30 т.р., то купите лучше за 15... и УПП за тысячу... а остальной прогуляйте... smile.gif
котяра
Цитата(lms-i @ 27.3.2013, 18:46) *


Котяра, я надеюсь проверял преключение на 3G при отключении WAN? И что значит заработало, на ЦД выводил? Очень интересно чем эксперимент закончится.



ну мы то так писать неумеем... больше ручками работаем и иногда головой smile.gif

разумеется проверял. и при физическом обрыве wan и при имитации проблем на оборудовании (сервере) проводного провайдера...
время переключения от 2 до 6 минут...

кстати у тп-линка есть фича... он иногда "теряет свистки" и не всегда может автоматически переконектится... тут иногда и ПП пригодилось бы...


===================

Так вот про сегмент. Мне не понятно, почему то вас особо не беспокоит отсутствие связи с удаленным УМ. То ли вы не сталкиваетесь с этим непосредственно; то ли не отвечаете за это напрямую; то ли у вас служба налажена с таким давлением на Заказчика, что мол мы крутые, нет связи - "ну такие дела" мы не причем и все, ждем пока наладится; то ли конкуренции нет; то ли идеальные услуги провайдер предоставляет и ни одного перебоя нет; то ли начальству по барабану кто там застрянет - сам вылезет. Честно, ей богу, мне не понятно...

====================

а вот это вооще непонятно к чему...

ну понимаю конечно что контора жопится на второй роутер за 600р... понимаю... но причём тут разработчики... убей не пойму...



lms-i
Цитата(котяра @ 27.3.2013, 19:58) *

ну мы то так писать неумеем... больше ручками работаем и иногда головой smile.gif

smile.gif
Цитата(котяра @ 27.3.2013, 19:58) *


а вот это вооще непонятно к чему...

ну понимаю конечно что контора жопится на второй роутер за 600р... понимаю... но причём тут разработчики... убей не пойму...

...эх...это не к разработчикам адресовалось, а к эксплуатационщикам.
...дело не в жопится, смысла нет в роутере за 600 р... опять 25...
Gaff
lms-i, конечно в идеале связь должна работать бесперебойно и все к этому стремятся, но на данный момент если допустим прибавить еще по резервному каналу на каждую точку, то стоимость обслуживания возрастет прилично, а все эти затраты ложатся на плечи обслуживающей организации, а ни как не заказчика. И если заказчики хотя бы просто вовремя расчитывались, то это было бы проще воплотить в реальность, а на деле получается, что перед нами у некоторых долги почти по миллиону, и они не могут его погасить, т.к. с ними так же не расчитываются, но уже собственники. Администрация так же, программу по замене лифтов отработавших свой срок запускает, но замена идет за счет организации, а оплата производится после всех работ, как можно ближе к 31 декабря, а зарплату работникам ни кто не отменял.
Плюс появляются организации, которые зарезают и так низкие тарифы, приходят и говорят, что мы готовы обслуживать в 2 раза дешевле, а по факту не имеют ни запчастей, ни механников толковых, т.к. туда прибежали те, кого выпнули из других организаций. Заказчики некотрые клюют на это, а итог один, через 2-5 лет лифты превращаются в рухлять, и заказчик потом сам же прибегает обратно и умоляет сделать что-нибудь. А мы всегда работали и будем работать только на качество.
Мы не говорим, что то что Вы предлагаете плохо и Вы дурак, нет, мы пытаемся донести свою позицию, суровую реальность в которой мы живем. Я в частности сказал, что просто не использую резервирование, т.к. на данный момент придется заплатить слишком высокую цену за это, хоть это и хорошо. Мы так же стремимся к идеалу и когда-нибудь надеюсь к нему придем, но исходим в первую очередь из реальных возможностей и рациональности. И введение новых правил (имею ввиду техрегламент и все последующие реформы) не помогает желаниям осуществится. Страна у нас такая. Возможно у Вас в регионе как-то лучше обстоят дела в этой отрасли, но у нас вот так.

А по теме, я думаю разработчики услышали Вас и будет какая-то ответная реакция от них, просто для принятия правильного решения требуется время. Надеюсь, что в скором времени мы все и Вы в том числе получим то, что желаем.
revit
УПП не выход, тут я не согласен с Александром. УПП это вообще то костыли, имхо, чтобы можно было как то похромать пока не вылечишься. smile.gif
Я считаю что нужно все таки изучить максимально эту проблему и с помощью нашего коллективного разума помочь разработчикам. Да, и главный мегамозг Олег Владимирович что думает по этому поводу?
lms-i
Цитата(Gaff @ 27.3.2013, 22:01) *

Да в той же стране живем. Прекрасно понимаю Вас в плане долгов и ФЗ-185, демпингов и тупых тех. регламентов и т.д. Все это и у нас есть, есть болевые точки и проблемы. И я часто плююсь из-за этого. Но это не относится к теме напрямую smile.gif . Долги только косвенно. Это глобальные проблемы отрасли.

Тут еще на организацию обслуживания надо обратить внимание. У нас допустим, на лифтеров тариф в 1,5 раза выше чем на тех. обслуживание. И я считаю что такие затраты как интернет и второй провайдер должны возложены на службу д. контроля и осмотры (лифтеров). Потому что ДК "Обь" позволяет сокращать их персонал. Наша контора в основном ориентирована на тех. обслуживание, и в последние годы вынуждена брать на комплекс (+ лифтеры) удаленные и точечные объекты. Так вот за счет ДК "Обь" мы оптимизируем затраты на лифтеров и соответственно можем выделить деньги на инет.

И когда мы беремся за такой проект удаленного УМ, с Заказчиком работаем, объясняем ему подводные камни, и т.д. Он в основном закупает оборудование, часто и инет сам платит, но где-то и мы, в зависимости от объема и других нюансов, по разному. Это же его оборудование, его собственность. Все толерантно стараемся делать на начальном этапе и Заказчика не потерять и максимально объяснить что дом его, и по другому не взять на обслуживание. Конечно это наша ситуация, может и сложнее есть, вынужденно взятые объекты не спорю.

А 3G модем в качестве резерва (у нас) просит 150 руб. в месяц wink.gif , с 1-го дома в 3-5 подъездов можно позволить. А если несколько домов, то подавно.

Можно поподробнее про мегафон. Стабильно работает? У нас Билайн лидер по качеству 3G, пробовали и МТС и Мегафон. Но не смотря на лидерство частые разрывы. Помогает только в качестве резерва на не продолжительное время. Как основной канал использовали несколько месяцев на разных точках - отказались, устали бороться с отсутсвием связи. Я в то время вздрагивал от поздних звонков диспетчера про отсутствие связи (когда уже даже сгоняли аварийку и переключили).

Спасибо за внимание к теме, тоже искренне надеюсь на помощь разработчиков.
котяра
Можно поподробнее про мегафон. Стабильно работает? У нас Билайн лидер по качеству 3G, пробовали и МТС и Мегафон. Но не смотря на лидерство частые разрывы. Помогает только в качестве резерва на не продолжительное время. Как основной канал использовали несколько месяцев на разных точках - отказались, устали бороться с отсутсвием связи. Я в то время вздрагивал от поздних звонков диспетчера про отсутствие связи (когда уже даже сгоняли аварийку и переключили).

=========================

а поставить там прерыватели питания слабо? у нас мтс используется...
если глобальные катаклизмы в сети прровайдера то ничего не поможет вернуть его в чуство.
а если какой либо мелкий сбой то да. по первости ездили передёргивали... ну а опосля поставили ПП и отдыxаем...
кстати ПП ставим и на резервные каналы с 3Gмодемами... таж проблема. была...
Александр Смышляев
Цитата(revit @ 27.3.2013, 23:20) *
УПП не выход, тут я не согласен с Александром. УПП это вообще то костыли, имхо, чтобы можно было как то похромать пока не вылечишься. smile.gif
Если речь идет о сбросе таблицы, тем более посредством рестарта, то, лично я, альтернативы не вижу...

Цитата(revit @ 27.3.2013, 23:20) *
Я считаю что нужно все таки изучить максимально эту проблему и с помощью нашего коллективного разума помочь разработчикам.
Золотые слова. Изучать проблему нужно, а не кричать: "Эй, разоаботчики Оби, вы там протокол собираетесь менять? Мы тут умные и знаем, что вам нужно делать, а вы не чешитесь!"
smile.gif
pavel
Цитата(Александр Смышляев @ 28.3.2013, 10:57) *

Изучать проблему нужно, а не кричать: "Эй, разоаботчики Оби, вы там протокол собираетесь менять? Мы тут умные и наем, что вам нужно делать, а вы не чешитесь!"
smile.gif


День добрый. Но Вы нас (компанию, не только меня лично) тоже поймите. Первый раз такую схему опробовали еще в начале ноября, месяцев пять назад. Тогда ограничивались звонками с места событий в Вашу тех. поддержку. Они советовали поставить динамич. IP и другое разное. В общем раза три ездили тестировали - без результата. В декабре нам было не до резерва. Конец года - много объектов. В январе начали возвращаться к теме. Уже на другом УМ. Опять пробовали по телефону. Опять ничего. В феврале, наконец-то, на нас обратил внимание Андрей Ефименко. В течении месяца сделали теста 4 по его методике (разработчики все еще не верили в проблему). Кое-как добились того, чтобы разработчики собрали у себя подобный стенд и убедились, что проблема есть. Убедились, сказали что в маршрутизаторе и больше на данную тему не общаются.
Собственно поэтому и полезли в форум, чтобы привлечь внимание. Да, и честно говоря думали что народ поддержит, кто-то тоже сталкивался с такой проблемой, кому-то может понадобиться в будущем.

В форуме уже не только наша компания ждет какой-либо реакции от разработчиков. Повторюсь, мы
готовы оказать посильную помощь в решении данной проблемы. Уже предложили несколько вариантов, которые можно было бы опробовать, либо обсудить.
Я понимаю, что проблема в том, что используется NAT. Без него скорее всего, все бы работало. Но дело в том, что разрабатывали оборудование Вы уже после повсеместного внедрения данной технологии. И более того указываете на ее использование в руководствах по КСЛ/Моноблокам.
Поэтому необходимо учесть ее реализацию в маршрутизаторах. Либо в руководствах и описании сетевых продуктов (КСЛ/Моноблок/ЛБпро) предупреждать о возможных проблемах и не полной совместимости с NAT. Чтобы клиенты знали, что они берут и какие проблемы могут возникнуть.
А с учетом повсеместности NAT - это весомый минус для продукции.

Маршрутизатор Juniper могу взять на время для теста. Но просто так тестировать больше не буду, только если для дела.

Нашел в Микротике параметр отвечающий за сброс записей в таблице NAT для UDP. Сегодня попробую поменять на 1с. Из предыдущих тестов с захватом пакетов сделал вывод, что КСЛ при потере связи каждые 2с что-то отправляет на ПКСЛ. Так что может сработать.
revit
Цитата(lms-i @ 27.3.2013, 15:46) *

revit, в нескольких диспетчерских стоят свистки, роутер там ставить не резонно.
Всмысле два свистка у вас в компе?

lms-i
Цитата(revit @ 28.3.2013, 11:38) *

Всмысле два свистка у вас в компе?

В одном компе один основной кабель и один резервный 3G модем. На нескольких компах так.
Александр Смышляев
Цитата(pavel @ 28.3.2013, 11:19) *
Нашел в Микротике параметр отвечающий за сброс записей в таблице NAT для UDP. Сегодня попробую поменять на 1с. Из предыдущих тестов с захватом пакетов сделал вывод, что КСЛ при потере связи каждые 2с что-то отправляет на ПКСЛ. Так что может сработать.
1 с - маловато... боюсь, что с этим параметром вы можете получить нестабильный обмен...
Gaff
lms-i, наконец-то начался конструктивный разговор, а не просто крики с просьбами сделать что-нибудь)))
По мегафону, да у нас в регионе (именно у нас) лидер и работает стабильно, у Вас может быть все абсолютно наоборот, поэтому однозначно говорить что обязательно используйте не буду. А по поводу резервов именно на Очень удаленных объектах, это разумеется необходимо, особенно если нет людей способных перезапустить оборудование (не хорошо это, но сбои бывают во всем), ведь если частые сбои, то действительно не наездишься. УПП пока еще вообще ни разу не использовал, мысли были, но смог и так все отладить.
А вот такие очень удаленные объекты это уже частный случай, там действительно возможны варианты приобретения оборудования и оплаты интернет заказчиком, но у нас пока, но отмечу что ПОКА, такого не было. Удаленные объекты у нас имеют как правило свой штат лифтеров, и это административные здания, где к лифтам относятся бережно. Я уверен, что со временем и у нас может возникнуть необходимость в резерве, а сейчас я не готов ответить на Ваш опрос ни да ни нет, т.к. во первых нет острой необходимости, во вторых, не понятно как на нашей компании отразятся изменения и в третьих, разработчики не сказали свое слово, может быть на их взгляд действительно проблемы есть, но заключается в чем то другом, а может измения как то повлияют на безопасность протокола, ну или еще что-то в этом роде. Вообщем, предлагаю просто дождаться что скажут разработчики и совместно решить эту проблему, если таковая имеется.
pavel
Коллеги, разработчики! Проблема решена! Всё оказалось очень просто. Жаль только, что пришлось потратить столько сил и времени. Доказывать наличие проблемы разработчикам и т.д.

В общем проблема действительно записями в таблице NAT. В каждом маршрутизаторе есть таймауты, по истечении которых, если нет повторных пакетов, запись удаляется. Эти таймауты различны для разных маршрутизаторов и различных соединений (UDP, TCP, ICMP и т.д.). КСЛ и Моноблок при потере связи шлет пакеты с периодичность 2с (параметр "Ожидание подтверждения связи" в окне Адреса связи настройки КСЛ). А для UDP соединений обычно время таймауты около 10с (маршрутизатор Микротик, например). Вот и получается, что маршрутизатор не успевает сбросить запись в таблице NAT, так как КСЛ постоянно (раз в 2с) шлет пакеты по своим связям.

С Микротиком решается просто: заходим в меню IP -> Firewall -> Connections -> Tracking и меняем параметры "UDP Timeout" и "UDP Stream Timeout" на 5 секунд. Оба, потому что не разбирался пока в какой попадет обмен Оби. Далее заходим в КСЛ/Моноблок и ставим в окне Адреса связи параметр "Время ожидания подтверждения связи" в 10 секунд. Вуаля! Всё работает!

Главное, чтобы параметр "Ожидание подтверждения связи" КСЛ/Моноблока был больше, чем таймаут UDP соединений в маршрутизаторе.
Чтобы запись в таблице NAT успела сброситься.

Вопрос к котяра. Ты писал, что вчера у тебя все заработало на TP-Link. Если еще не разобрал схему, скажи нам всем на будущее какой параметр "Время ожидания подтверждения связи" стоит у тебя на КСЛ. отсюда мы поймем, что нужно ставить для TP-Linkов. Для остальных "простеньких" маршрутизаторов рецепт такой: играйтесь с параметром "Время ожидания подтверждения связи" КСЛ/Моноблока пока не заработает.

Все-таки считаю, что разработчики должны были поучаствовать в решении проблемы. Занимались они ей не долго: собрали стенд, посмотрели, определили суть проблемы (за что им огромное СПАСИБО) и сказали, что это маршрутизатор. Наша компания потратила куда больше времени и ресурсов. Причем большинство из тестов, были направлены лишь на то, чтобы доказать наличие проблемы разработчикам.

Коллективный разум РУЛИТ, отдельное спасибо Ефименко Андрею и котяра. Именно последний натолкнул на мысль про "Время ожидания подтверждения связи" на КСЛ.
Это текстовая версия — только основной контент. Для просмотра полной версии этой страницы, пожалуйста, нажмите сюда.
Русская версия Invision Power Board © 2001-2021 Invision Power Services, Inc.