Версия для печати темы

Нажмите сюда для просмотра этой темы в обычном формате

Лифт-Комплекс ДС _ КСЛ _ Резервирование одним маршрутизатором

Автор: pavel 21.2.2013, 19:37

Приветствую.

Резервирование УМ с использованием двух маршрутизаторов прекрасно описана ЛКДС и прекрасно работает. Но, хотим сделать резервирование не плодя на каждой УМ по 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, то канал интернета на маршрутизаторе переключается, а связь КСЛ (Моноблока) с Диспетчерской - НЕТ.
Смотрел соединения на маршрутизаторе: КСЛ постоянно пробовал соединиться с резервным адресом диспетчерской... и только после перезагрузки (иногда ни одной) маршрутизатора и/или КСЛ связь восстанавливалась. Причем это наблюдалось в обе стороны: при переключении на резерв и с резерва на основной канал.

Подскажите, у кого-нибудь такая схема с одним маршрутизатором на УМ работает? На чем?

Автор: котяра 21.2.2013, 20:27

ну мы тож так пытались вначале... на TP-Link 3420.... не работает...

Автор: revit 21.2.2013, 23:52

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

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

Автор: pavel 22.2.2013, 5:33

Цитата(revit @ 22.2.2013, 0:52) *

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


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

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

Автор: revit 22.2.2013, 10:52

Цитата(pavel @ 22.2.2013, 3:33) *

То делал по разному: не прописывал, прописывал повторно 192.168.0.1 (как и основной). Не работают оба варианта.
Т.е резервный шлюз с дублирующим IP прописывается... Но это уже недоработка разработчика-если КСЛ рассчитан на резервирование по шлюзам, то одинаковыми они быть не могут. Тем более что они и не работают, да и не должны по идее работать на одном.

Автор: Fixer 20.3.2013, 23:46

Так поднимите VPN тогда. И микротики в оба конца, пускай пинают друг друга ping watchdog'ом. И переключать ничего не придется

Автор: Андрей Ефименко 21.3.2013, 14:13

Цитата(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 21.3.2013, 17:24

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

Автор: pavel 25.3.2013, 9:23

Цитата(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 25.3.2013, 22:25

Цитата(pavel @ 25.3.2013, 7:23) *

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

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

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

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

Автор: Fixer 26.3.2013, 8:16

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

Автор: lms-i 26.3.2013, 8:40

Цитата(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 26.3.2013, 10:50

Цитата(Fixer @ 26.3.2013, 9:16) *

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


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

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

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

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

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

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

Автор: Gaff 26.3.2013, 20:27

Цитата(pavel @ 26.3.2013, 9:50) *

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

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

Автор: котяра 26.3.2013, 20:37

Цитата(pavel @ 26.3.2013, 11:50) *

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

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

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

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

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

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



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

Автор: Van Gog 26.3.2013, 23:23

Цитата(котяра @ 26.3.2013, 18:37) *

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

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

Автор: revit 27.3.2013, 0:29

котяра ты бы цитаты более конкретные делал (и маленькие ). А то нифига непонятно к чему относится ответ, а пол страницы занимает.

Автор: Fixer 27.3.2013, 1:36

Цитата(pavel @ 26.3.2013, 10:50) *

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

Что именно интересует?
Режим VPN - EoIP, это позволяет включать OSPF, каковой самостоятельно разбирается с отвалившимися маршрутами, главное не забыть usb свистульке метрику побольше нарисовать. 3G модем в режим wake on demand. Все вроде. Единственная проблема - 3G у нас так себе, связь нестабильная и переговорка рвется

Автор: pavel 27.3.2013, 8:52

to Gaff:
В качестве всего smile.gif: маршрутизатор (несколько внешних подключений), сетевое хранилище, архивное хранилище, NTP сервер (у нас в диспетчерских точное время, а у Вас smile.gif ), SFTP сервер (архивное копирование LKDSDrv с удаленных диспетчерских). Есть и web-приложения: мониторинг работы инетернет каналов УМ, база данных и т.д.

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

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

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

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


Автор: lms-i 27.3.2013, 8:53

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

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

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

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

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


Эскизы прикрепленных изображений
Прикрепленное изображение

Автор: pavel 27.3.2013, 11:13

Резервирование УМ с использованием двух маршрутизаторов прекрасно описано ЛКДС и прекрасно работает.

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

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

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

Просьба к модераторам закрепить тему сверху.

Автор: pavel 27.3.2013, 11:17

Создал http://www.lkds.ru/forum/index.php?showtopic=2946 в ветке про КСЛ.

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

http://www.lkds.ru/forum/index.php?showtopic=2946

Автор: revit 27.3.2013, 11:38

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

А кстати в диспетчерской никто не пробовал такой вид резервирование? В ЦД и ЛД такой вариант точно нужен т.к на тех же ноутах только один сетевой интерфейс а прикручивать USB-ишные не есть гуд. Ну а о пользе применения ноута в диспечтерских, думаю объяснять не нужно.. smile.gif

Автор: revit 27.3.2013, 11:43

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

Автор: Gaff 27.3.2013, 11:52

Цитата(revit @ 27.3.2013, 10:43) *

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

+1

Автор: Gaff 27.3.2013, 12:09

Хотел бы что-нибудь добавить к rivit`у, а нечего, потому что все точно так же, за исключением того, что вместо скайлинка, у меня мегафон (в городе нет cdma), а вместо adsl - wi-max (adsl сейчас уже практически не подключают и по опыту коллег из конкурентной компании знаю, что качество его оставляло желать лучшего, особенно работа тех. поддержки, бывало, что по полмесяца не могут восстановить канал).
А насчет проводных интернетов, у нас в городе цены для организаций такие, что мне дешевле позвать wi-max провайдера и не надо в обязательном порядке резервный канал поднимать, достаточно ИБП, а если уж что случится, что происходит крайне редко и не связано с отключением света чаще с вандалами, то тут в любом случае на объект ехать

Автор: Александр Смышляев 27.3.2013, 12:20

Цитата(pavel @ 27.3.2013, 12:13) *
Резервирование УМ с использованием двух маршрутизаторов прекрасно описано ЛКДС и прекрасно работает.

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

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

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

... как модератор: опрос считаю некорректным - подниматься не будет (но и удалять пока не стану...)

Автор: Van Gog 27.3.2013, 12:28

Цитата(revit @ 27.3.2013, 9:43) *

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

Не могу ответить ни ДА ни НЕТ ибо на сегодня не вижу никакой проблемы. Но раз у Лифт-Комплекса есть заказчики, которые эту проблему видят и (судя по достаточно эмоциональным постам) это проблема велика, то конечно нужно что-то решать. Я бы предложил в новой версии КСЛ и Моно устанавливать два сетевых интерфейса и USB для программирования и подключения "свистков", тем более, что в линейке Cortex наверняка найдётся подходящий проц. А ценой нас не испугать wink.gif ! У конкурентов всё равно ничего подобного не предвидится.

Автор: revit 27.3.2013, 12:32

Александр, вопрос звучал так -почему не работает с пакетами UDP ОБИ а с другими работает?

Цитата(pavel @ 25.3.2013, 7:23) *

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

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

Если Андрей Владимирович разъяснит ситуацию, думаю все будут благодарны.

Автор: Александр Смышляев 27.3.2013, 13:30

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

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

Автор: pavel 27.3.2013, 13:33

revit совершенно верно подметил, что вопрос несколько в другом.

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

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

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

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

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

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

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

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

Скажите нам тогда, а какой маршрутизатор ПРАВИЛЬНО переключается на резерв. В студию!

Автор: Александр Смышляев 27.3.2013, 13:57

Цитата(pavel @ 27.3.2013, 14:33) *
Я уже несолько раз писал... (и далее по тексту)
Хорошо пишите... много... местами аргументировано...
Только все, что вам нужно уже сделано. Возьмите http://lkds.ru/setevoe-oborudovanie/ustroystvo-preryvaniya-pitaniya-pro.html, настройте КСЛ и будет вам счастье.

Автор: pavel 27.3.2013, 14:17

Цитата(Александр Смышляев @ 27.3.2013, 14:57) *

Хорошо пишите... много... местами аргументировано...
Только все, что вам нужно уже сделано. Возьмите http://lkds.ru/setevoe-oborudovanie/ustroystvo-preryvaniya-pitaniya-pro.html, настройте КСЛ и будет вам счастье.


За 950 руб. можно и маршрутизатор выпустить, OEM D-Link. Который всё будет делать как надо wink.gif

Автор: котяра 27.3.2013, 16:02

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

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

буду юзать дальше...

Автор: котяра 27.3.2013, 16:13

Цитата(pavel @ 27.3.2013, 14:33) *

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


насколько знаю в ксл/моноблоке есть параметр: "ожидание соединения после рестарта" думаю можно воспользоваться и им... зачем новое городить то...

Автор: lms-i 27.3.2013, 17:46

Цитата(котяра @ 27.3.2013, 17:02) *

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


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

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

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

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

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

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

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

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





Автор: Александр Смышляев 27.3.2013, 18:02

Цитата(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

Автор: котяра 27.3.2013, 18:58

Цитата(lms-i @ 27.3.2013, 18:46) *


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



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

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

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


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

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

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

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

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




Автор: lms-i 27.3.2013, 19:12

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

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

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


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

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

...эх...это не к разработчикам адресовалось, а к эксплуатационщикам.
...дело не в жопится, смысла нет в роутере за 600 р... опять 25...

Автор: Gaff 27.3.2013, 21:01

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

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

Автор: revit 27.3.2013, 22:20

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

Автор: lms-i 28.3.2013, 7:59

Цитата(Gaff @ 27.3.2013, 22:01) *

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

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

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

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

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

Спасибо за внимание к теме, тоже искренне надеюсь на помощь разработчиков.

Автор: котяра 28.3.2013, 9:28

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

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

а поставить там прерыватели питания слабо? у нас мтс используется...
если глобальные катаклизмы в сети прровайдера то ничего не поможет вернуть его в чуство.
а если какой либо мелкий сбой то да. по первости ездили передёргивали... ну а опосля поставили ПП и отдыxаем...
кстати ПП ставим и на резервные каналы с 3Gмодемами... таж проблема. была...

Автор: Александр Смышляев 28.3.2013, 9:57

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

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

Автор: pavel 28.3.2013, 10:19

Цитата(Александр Смышляев @ 28.3.2013, 10:57) *

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


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

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

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

Нашел в Микротике параметр отвечающий за сброс записей в таблице NAT для UDP. Сегодня попробую поменять на 1с. Из предыдущих тестов с захватом пакетов сделал вывод, что КСЛ при потере связи каждые 2с что-то отправляет на ПКСЛ. Так что может сработать.

Автор: revit 28.3.2013, 10:38

Цитата(lms-i @ 27.3.2013, 15:46) *

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


Автор: lms-i 28.3.2013, 10:50

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

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

В одном компе один основной кабель и один резервный 3G модем. На нескольких компах так.

Автор: Александр Смышляев 28.3.2013, 11:01

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

Автор: Gaff 28.3.2013, 11:24

lms-i, наконец-то начался конструктивный разговор, а не просто крики с просьбами сделать что-нибудь)))
По мегафону, да у нас в регионе (именно у нас) лидер и работает стабильно, у Вас может быть все абсолютно наоборот, поэтому однозначно говорить что обязательно используйте не буду. А по поводу резервов именно на Очень удаленных объектах, это разумеется необходимо, особенно если нет людей способных перезапустить оборудование (не хорошо это, но сбои бывают во всем), ведь если частые сбои, то действительно не наездишься. УПП пока еще вообще ни разу не использовал, мысли были, но смог и так все отладить.
А вот такие очень удаленные объекты это уже частный случай, там действительно возможны варианты приобретения оборудования и оплаты интернет заказчиком, но у нас пока, но отмечу что ПОКА, такого не было. Удаленные объекты у нас имеют как правило свой штат лифтеров, и это административные здания, где к лифтам относятся бережно. Я уверен, что со временем и у нас может возникнуть необходимость в резерве, а сейчас я не готов ответить на Ваш опрос ни да ни нет, т.к. во первых нет острой необходимости, во вторых, не понятно как на нашей компании отразятся изменения и в третьих, разработчики не сказали свое слово, может быть на их взгляд действительно проблемы есть, но заключается в чем то другом, а может измения как то повлияют на безопасность протокола, ну или еще что-то в этом роде. Вообщем, предлагаю просто дождаться что скажут разработчики и совместно решить эту проблему, если таковая имеется.

Автор: pavel 28.3.2013, 12:12

Коллеги, разработчики! Проблема решена! Всё оказалось очень просто. Жаль только, что пришлось потратить столько сил и времени. Доказывать наличие проблемы разработчикам и т.д.

В общем проблема действительно записями в таблице 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ов. Для остальных "простеньких" маршрутизаторов рецепт такой: играйтесь с параметром "Время ожидания подтверждения связи" КСЛ/Моноблока пока не заработает.

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

Коллективный разум РУЛИТ, отдельное спасибо Ефименко Андрею и котяра. Именно последний натолкнул на мысль про "Время ожидания подтверждения связи" на КСЛ.

Автор: Александр Смышляев 28.3.2013, 13:00

Цитата(pavel @ 28.3.2013, 13:12) *
Главное, чтобы параметр "Ожидание подтверждения связи" КСЛ/Моноблока был больше, чем таймаут UDP соединений в маршрутизаторе. Чтобы запись в таблице NAT успела сброситься.
Если бы все было так безоблачно... Я же вам в прошлом своем посте писал...
Попробую разжевать. Выставили вы 1 с в роутере. В КСЛ'е 2 с. И, в придачу к этому, имеете прохождение запрос/ответ более 1 с. Что в этом случае произойдет? Догадались? Или дальше объяснять?
Вы, попросту, не получите соединения вообще. КСЛ пошлет пакет - будет установлено соответствие источник-получатель-параметры_маршрута. Через 1 с это соответствие сбросится, а ответный пакет придет на 0,5 с позднее. КСЛ бы его принял (таймаут стоит 2 с), ба вот роутер уже не будет знать, что с этим пакетом делать... и попросту сбросит его. Связи не будет.

Автор: pavel 28.3.2013, 13:12

Цитата(Александр Смышляев @ 28.3.2013, 14:00) *

Если бы все было так безоблачно...


Александр, я же учел Вашу критику:
Цитата

на 5 секунд. Оба, потому что не разбирался пока в какой попадет обмен Оби. Далее заходим в КСЛ/Моноблок и ставим в окне Адреса связи параметр "Время ожидания подтверждения связи" в 10 секунд.


Да и потом. На обратное прохождение пакета это никак не повлияет, т.к. на маршрутизаторе проброшены порты 44000 и 44001 на КСЛ. Так что, когда прилетает пакет снаружи, маршрутизатор не смотрит таблицу NAT. Вот если их не пробросить...

Мой предыдущий пост - это не гипотеза. Я проверил всё именно на том УМ, на котором ранее неработала связь с КСЛ с использованием трех маршрутизаторов.
И туда и обратно замечательно переключается всё и работает. С Микротиком wink.gif

Автор: Александр Смышляев 28.3.2013, 15:03

Цитата(pavel @ 28.3.2013, 14:12) *
Александр, я же учел Вашу критику:
Простите, как-то между глаз попало 5 сек...

Цитата(pavel @ 28.3.2013, 14:12) *
Да и потом. На обратное прохождение пакета это никак не повлияет, т.к. на маршрутизаторе проброшены порты 44000 и 44001 на КСЛ. Так что, когда прилетает пакет снаружи, маршрутизатор не смотрит таблицу NAT.
Так ведь таблица NAT строится с учетом этого правила. Если правило(а) прописаны, то пакет выходит из роутера в WAN не абы от какого порта, а от того, который соответствует правилам. Если нет проброса портов, то и пакет вылетает с произвольным портом. Исходя из этого таблица NAT вообще, вроде, ни при чем... если только в ней не фигурирует еще и WAN интерфейс (достоверно судить не могу - как предположение).

Автор: pavel 28.3.2013, 15:21

Цитата(Александр Смышляев @ 28.3.2013, 16:03) *

Если правило(а) прописаны, то пакет выходит из роутера в WAN не абы от какого порта, а от того, который соответствует правилам. Если нет проброса портов, то и пакет вылетает с произвольным портом.

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

Теперь обратно. Из Интернета прилетает пакет в маршрутизатор. Здесь есть два пути:
1) На маршрутизаторе в правилах файерволла прописан проброс портов. Мол если прилетел пакет UDP с портом назначения 44000, то отправляй его во внутреннюю сеть на адрес 192.168.0.2 порт 44000. Маршрутизатор так и делает собственно.
2) Такого правила нет. Тогда маршрутизатор смотрит табл. NAT, а нет ли активных сессий по порту назначения из прилетевшего пакета. Если он находит такую сессию (КСЛ отправлял пакеты с этого порта), то проверяется ряд дополнительных условий и только тогда пакет передается во внутреннюю сеть. В остальных случаях пакет отбрасывается.

Строго говоря пункт 2 - работает только для TCP. Очень редко для UDP, так как это была бы дыра в маршрутизаторе. В UDP нету сессий, в нем все несколько иначе.

Автор: lms-i 28.3.2013, 15:39

Цитата(Gaff @ 28.3.2013, 12:24) *

lms-i, наконец-то начался конструктивный разговор, а не просто крики с просьбами сделать что-нибудь)))

Да не говорите! Только мы просили технические проблемы решить, и тема ветки техническая. А Вы начали разглагольствовать о необходимости резерва, о тарифах, о трудностях при замене лифтов, долгах и т.д. На это Вам я вам конструктивно и ответил. Хотите поговорить о наболевшем - создавайте ветку в другом разделе.

Gaff, эта ветка началась с вопроса: "Подскажите, у кого-нибудь такая схема с одним маршрутизатором на УМ работает? На чем?" И мне кажется преследовалась цель узнать мнение людей кто уже пробовал. Ну а если у Вас:
Цитата(Gaff @ 28.3.2013, 12:24) *

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


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

И мы не кричали. Мы просили помощи, поделиться опытом.

Автор: Александр Смышляев 28.3.2013, 16:14

Цитата(pavel @ 28.3.2013, 16:21) *
Александр, Вы путаете...
Да нет, не путаю... То, что вы написали - верно и с этим никто не спорит. Я говорю немного о другом. Посмотрите внимательно (как я понимаю такую возможность вы имеете), от какого порта приходит пакет при пробросе портов и при его отсутствии.
При отсутствии проброса портов пакет придет от произвольного порта. Если прописать проброс портов, то пакет придет именно от порта, участвующего в пробросе.
Вот о чем я говорил...

Автор: Gaff 28.3.2013, 16:39

Поймите, пожалуйста, что мои "разглаголства" это лишь ответная реакция на Ваши же слова.

Цитата(lms-i @ 27.3.2013, 16:46) *

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

Я вот мужики одного не пойму, в каком сегменте отрасли вы работаете. Ведь хоть с DSL, хоть со Скайлинком, хоть с Мегафоном, хоть с оптикой, да хоть с чем могут быть проблемы.


А по поводу того, что это ветка техническая, я просто рассказал что не использую резервирование, объяснил по каким причинам. ДА согласен, что посты ни как не помогли решению вопроса, мне просто не было понятно из-за чего Вас так "достала" эта проблема, хотя заявили о ней недавно. Да и поймите, выглядело Ваши как слова маленького ребенка "дай, дай, дай!" (ни в коем случае не жалаю Вас обидеть")
Предлагаю просто прекратить этот разговор и не устраивать форумных баталий.
В скором времени я буду докупать TP-link MR3040, проведу эксперимент с ним и отпишусь. smile.gif

Автор: lms-i 28.3.2013, 16:49

Цитата(Gaff @ 28.3.2013, 17:39) *

В скором времени я буду докупать TP-link MR3040, проведу эксперимент с ним и отпишусь. smile.gif

Жму руку! Удачи в настройке! Будем ждать результатов.

Автор: котяра 28.3.2013, 22:47

Цитата(pavel @ 28.3.2013, 13:12) *

Коллеги, разработчики! Проблема решена! Всё оказалось очень просто. Жаль только, что пришлось потратить столько сил и времени. Доказывать наличие проблемы разработчикам и т.д.


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



как оказалось проблема в маршрутере и к разработчикам отношения не имела biggrin.gif


по вопросу... от 3 до 5 сек ставил...
не так всё безоблочно оказалось... на кратковременных тестах всё хорошо было... а в реальности... буду проверять ещё... но как, пока, оказалось через 5 переключений маршрутер "зависал". ( я не сетевик так что что именно там происходит незнаю). вродеб инфу маршрутер отдаёт что переключение произошло но вот связи нет.. попробую увеличить время до 10 и более сек... отпишусь...
а вот что тп-линк модемы "теряет" иногда факт... (правда модель 3240 старого типа была). так что УПП там не помешает явно... в случае чего он и "передёрнет" маршрутер...


так что можно сказать схема рабочая по факту...

единственное что интересует... проверить надо... если будет и проводной и 3G интернет с динамическими адресами.. будет ли происходить переключение?
в случае если проводной статика, а 3G динамика или оба со статикой, то переключение работает..


кстати мегамозг пока в отъезд smile.gif

Автор: revit 29.3.2013, 0:27

Цитата(котяра @ 28.3.2013, 20:47) *

как оказалось проблема в маршрутере и к разработчикам отношения не имела biggrin.gif

Да и не проблема..., и даже не фича...

Автор: lms-i 29.3.2013, 8:28

Цитата(котяра @ 28.3.2013, 23:47) *

как оказалось проблема в маршрутере и к разработчикам отношения не имела biggrin.gif

Да, конечно! При неработающем комплекте КСЛ-маршрутизатор надо было сразу разработчикам маршрутизатора звонить. Компании с мировым брендом, и сказать: "Чего-то ребята у Вас маршрутер с нашей Обью не работает!". Только в какую компанию? Не работала связка на трех разных маршрутерах 3-х разных производителей!

Это проблема была комплексной, никто и не говорил изначально что в ЛКДС недоработка. Необходимо было изучить проблему и решить. Для чего мы и обратились.

И после продолжительных тестов, за что спасибо команде ЛКДС и pavel, и недельных дебатов на форуме, истина была найдена. У нас заработало. Необходимо все проверить на практике с более длительным сроком.

Оказалась проблема и не в КСЛ, и не в маршрутизаторе. Необходио было учесть особенности работы алгоритмов NAT (как я понял) в связке КСЛ-маршрутер.!!! Сейчас вот только не надо пинать и мусолить про NAT! - это я к тем кто любит писать коменты "лишь бы написать не подумавши, чего-нибудь брякнуть".

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

Автор: pavel 29.3.2013, 9:14

Цитата(revit @ 29.3.2013, 1:27) *

Да и не проблема..., и даже не фича...

blink.gif
1) Проблема есть, думаю с этим никто не спорит;
2) Есть различные мнения по поводу того чья она и кто должен ее решать. Моё ИМХО:

На сайте ЛКДС в разделе каталог продукции есть еще один раздел, называется он "Сетевое оборудование". В нём мы видим КСЛ-Ethernet и Моноблок-Ethernet. В руководствах по данным устройствам, в других руководствах есть информация о настройке маршрутизатара с использованием технологии NAT для работы "сетевого оборудования ЛКДС" через Интернет (в том числе резерв через два маршрутизатора). Первая прошивка на КСЛ доступная на сайте датирована 2007 годом. Имеем:
а) КСЛы производились после массового внедрения технологии NAT (где-то 1999г.), ЛКДС в руководствах ссылается на ее использование вместе с КСЛ, ЛКДС признает свое оборудование "сетевым".

Транспортный протокол (TCP или UDP) из стека TCP/IP выбрали разработчики ЛКДС. Они выбрали UDP. У него есть свои плюсы, главный из которых простота.
б) Но у UDP есть и минусы (безопасность, проблема обозначенная в этой теме).

Итог: разработчик должен нести ответственность за свой выбор, понимать минусы выбраного решения и стремится их невелировать. Либо! Предупреждать клиентов о данных проблемах. О неполной совместимости с современными реализациями технологии NAT. Либо! Указывать список "совместимых маршрутизаторов", через которые всё работает, постоянно обновлять и пополнять его. (- бред на мой взгляд).

Маршрутизатор, собственно на то и маршрутизатор чтобы иметь несколько подключений к различным сетям (в том числе к Интернету) и корректно пересылать пакеты между этими сетями. Что они и делают. И ссылаться на то, что у нас в Оби UDP, у нас не какой-то "бытовой обмен" и поэтому давайте нам на каждого провайдера по маршрутизатору, как-то даже не салидно. Да и почему все считают схему с двумя маршрутизаторами правильной? Потому что ее предложили ЛКДС? Потому что они сделали, так чтобы с двумя работало, а с одним у них не получилось?

В случае ЛБпро резерва через два маршрутизатора нет, так как для ЛБпро нельзя задать два шлюза. Вчера тестировал резерв через один маршрутизатор в случае ЛБпро. Т.е. в удаленной МП стоят два ЛБпро и один маршрутизатор. В него приходит Инет по проводу. Хотели добавить 3G. Не работает.
Маршрутизатор - D-link 320NRU.

В ЛБпро заметил, что параметр "Ожидание подтверждения связи" нельзя выставить больше 10с. Подозреваю (не проверял еще), что и для КСЛ также. Таким образом, сейчас (без вмешательства разработчиков) можно гарантировать нормальный переход на резерв только в случае маршрутизатора, в котором можно задать (либо задан от производителя) UDP timeout менее 10с. В остальных случаях работать через один маршрутизатор резерв не будет.

Я сейчас вообще слабо представляю зачем защищать разработчиков ЛКДС? Мы хотели использовать один маршрутизатор для выполнения функций, с которыми и должен справляться один маршрутизатор, а не два. Мы этого добились. Объяснили как.
ЛКДС осталось всё проверить в случае с самым массовым D-Link, сделать так чтобы параметр "ожидание подтверждения связи" можно было бы задавать больше, чем 10с. Либо по-другому можно было задавать паузу в обмене. И всё! ЛКДС может писать в руководства схему резервирования с одним маршрутизатором, что для клиентов намного экономичнее. И сделать руководство по резервированию для ЛБпро!

Да, мы виноваты biggrin.gif вылезли тут со своей проблемой, людей озадачиваем. Все же работало. Вот и делайте как все, как у всех. Зачем Вам эти сетевые технологии. Плюньте вы на них.

Но вот только мы все уже на этом поле. И когда у кого-то из клиентов ЛКДС через инет 500 лифтов "уведут" - это чья проблема будет? Используя только ПО Оби.

Согласен с lms-i
Цитата

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

Автор: Александр Смышляев 29.3.2013, 9:41

Цитата(pavel @ 29.3.2013, 10:14) *
blink.gif
Как-то у вас, Павел, однобоко получается.
Вы считаете, что проблема есть. Пусть так. В связке 2 устройства: КСЛ и маршрутизатор. До маршрутизатора (разработкиков) вы "дотянуться" не можите, значит проблема в КСЛ!
Вам самому не кажется это смешным?
Ведь проблема в маршрутизаторе. Если он, при переключении с интерфейса WAN_1 на WAN_2, продолжает при NAT'е подставлять IP-адрес WAN_1, то тут безусловно виноват КСЛ... и его нужно допиливать...
Если вы не готовы с этим согласиться, то тут я вам мало чем могу помочь...

Автор: lms-i 29.3.2013, 10:19

Цитата(Александр Смышляев @ 29.3.2013, 10:41) *

Как-то у вас, Павел, однобоко получается.
Вы считаете, что проблема есть. Пусть так. В связке 2 устройства: КСЛ и маршрутизатор. До маршрутизатора (разработкиков) вы "дотянуться" не можите, значит проблема в КСЛ!
Вам самому не кажется это смешным?
Ведь проблема в маршрутизаторе. Если он, при переключении с интерфейса WAN_1 на WAN_2, продолжает при NAT'е подставлять IP-адрес WAN_1, то тут безусловно виноват КСЛ... и его нужно допиливать...
Если вы не готовы с этим согласиться, то тут я вам мало чем могу помочь...

Александр, я понимаю что Вы модератор, и Ваше мнение поддерждивает сам всевышний, но у Вас простите бельмо на глазу или пелена! Не надо так рьяно защищать ЛКДС, мы ни кого тут НЕ ОБВИНЯЕМ.

К какому, простите, разрабтчику маршрутизаторов обратиться, и с каким вопросом? У всех технология одна и та же...

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

Проблема при всем при том решена. Пользуйтесь двумя маршрутизаторами. Только в Европе специалисты животы надорвут почитав эту ветку. Мы на перспективу старались доработать свзку КСЛ-маршрутер, а опять оказались дураками. Да и ладно, пусть мы дураки. Зато Вы, Александр, бесспорно умнее нас. Алелуя!

Автор: revit 29.3.2013, 10:55

1. Массовое применение роутеров в нашей стране началось где-то в 2005-2006 годах в АДСЛ подключениях и никак не в 1999, хотя технология конечно старше.
КСЛ-ы появились в 2004-2005, т.е в одно время.
2. За прошедшее время роутеры сильно "выросли" функционально и применяемые в них NAT-ы (во множественном числе т.к. много различных видов) то же не стояли на месте. Соответственно возросло кол-во проблем связанных с протоколом UDP в механизмах NAT, которые не очевидны были ранее. И разработчики роутеров тоже их решают не всегда безпроблемно. Тем не менее UDP не отстой как вы думаете и у него есть преимуществом над TCP для голосовой связи через интернет каналы. И я считаю что это было правильным выбором ЛКДС, учитывая что ТСР еще требует и бОльших ресурсов процессора, а отсюда стоимость и пр.
3. Изначально на железных КСЛ-ах поддержка резервирования была сделана по шлюзам т.к это было востребовано заказчиками, а о резервирование роутером небыло и речи.
4. Когда перешли на ПКСЛ резервирование дешевыми роутерами еще не было широко распространено и эта функция в роутерах стоимостью до 3-4т.р появилась совсем недавно -с год назад . Ну а те кто использовал полноценные шлюзы, такими вопросами не озадачивались.
Что в итоге имеем:
Появились доступные резервируемые свистками роутеры -решаем возникшие вопросы.
Понятно, что за год можно было что-то предпринять в этом направлении разработчикам, но видимо пока есть другие первоочередные задачи связанные с разработкой абсолютно нового ПО и переходом на новое железо. И я думаю это можно понять.

Цитата(lms-i @ 29.3.2013, 8:19) *
К какому, простите, разрабтчику маршрутизаторов обратиться, и с каким вопросом? У всех технология одна и та же...
Технология одна, реализация разная. И там тоже люди...

Автор: pavel 29.3.2013, 11:03

Цитата(Александр Смышляев @ 29.3.2013, 10:41) *

Как-то у вас, Павел, однобоко получается.

КСЛ ни в чем не виноват - это факт.
А вот разработчики обмена Оби несколько причастны.
Вот если разработчики маршрутизаторов сделают эти таймауты в 1с, или вообще уберут. Мы, наверное, с Вами и форуме то побеседовать не сможем. Пока за белый IP не заплатим. А с учетом того, что у нас даже дома по 3-4 сетевых устройства, то надо приобретать подсеть из 4 IP. Это с учетом дефицита IPv4-адресов уже не так-то дешево. Так, что не вижу причины тянуться до разработчиков маршрутизаторов. Мы оставновились на использовании Микротиков где-то месяц назад. И то что он прекрасно справился с данной проблемой и без участия ЛКДС, лишь подтверждает правильность выбора.
И вот в схеме: "протокол обмена Оби через Интернет" - один маршрутизатор - NAT - два провайдера.
Что-то не работает. Что будем менять?
Провайдеров? Пробовали, оказалось они не причем.
NAT? Можно конечно. Но вроде технологии больше 10 лет и всё остальное через нее работает. Вряд ли все производители сетевого оборудования побежат ее переписывать в бесчисленном количестве устройств, только из-за того что "Обь" с ней не дружит.
Маршрутизатор? Так меняли, пробовали. ЛКДС так и не ответил, какой нам попробовать, что они считают эталоном.
Остается "протокол обмена Оби". Как самый молодой smile.gif он должен уважать старших. Именно он пришел на детскую площадку, на которой все остальные уже давно и замечательно играют и пытается установить свои правила.
В общем весь этот Интернет, все сетевые технологии - это большой набор стандартов, иногда допускающих отклонения в реализациях, иногда не строгих, иногда .... Но он есть и он такой. Если Вы решили что-то через него передавать, наверное, нужно принять все эти стандарты, технологии, а не пытаться всё изменить.

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


Цитата(revit @ 29.3.2013, 11:55) *

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


Согласен. Понять можно.
Вот только реакцию ЛКДС на проблему, не желание слышать и ничего менять. Пусть даже не сейчас, укажите срок просто. Вот это мы не понимаем.

Автор: Александр Смышляев 29.3.2013, 13:36

Цитата(lms-i @ 29.3.2013, 11:19) *
Александр, я понимаю что Вы модератор...
1. Дело не в том, что я модератор!
2. Скатывание на уровень личных оскорблений - признак отсутствия аргументов (как минимум).
3. Сдается мне, что lms-i/pavel - это один человек. А раздвоение личности нужно лечить. Вы уж там внутри себя решите, кем вы хотите быть - второй будет удален! (до конца сегодняшнего дня)
4. Отвечать на остальной "поток сознания" не вижу смысла...

Автор: pavel 29.3.2013, 13:50

Цитата(Александр Смышляев @ 29.3.2013, 14:36) *

3. Сдается мне, что lms-i/pavel - это один человек. А раздвоение личности нужно лечить.


Это не один человек. Но мы представляем одну компанию.

Предлагаю всем дождаться комментариев разработчиков. А именно Олега Владимировича, который сейчас в командировке.

Автор: Александр Смышляев 29.3.2013, 14:28

Цитата(pavel @ 29.3.2013, 14:50) *
Это не один человек. Но мы представляем одну компанию.
Что-то мне лично слабо верится в зазомбированность одного человека другим (в данном случае). Стиль подачи информации, агалтелость, с которой она подается и ряд других признаков наводят на мысь, высказанную ранее.

Цитата(pavel @ 29.3.2013, 14:50) *
Предлагаю всем дождаться комментариев разработчиков. А именно Олега Владимировича, который сейчас в командировке.
Рано или поздно Олег Владимирович прочитает данную ветку. И возможно что-то ответит, если сочтет нужным. Но боюсь, что и его слова вы не захотите услышать - вам ведь недостаточно Андрея Владимировича Ефименко и меня.
А пока вы можете почитать протоколы (о которых вы здесь так много говорили), и привести конкретные места из них, в которых Обь не соответствует данным протоколам (если сможите).

Автор: котяра 29.3.2013, 15:35

какаято лажа а не тема...

даж не знаю с чего начать... писатель из меня аховый...

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

я писал что тема достала... это не в том смысле что проблема горит, а втом что пара человек кричит а попробовать решить самим не очень то и хочется (сисадмины... что тут говорить). чуток попробовали и всё... вот и сел за стол. ну в течении дня проблему как то решил. неспорю что решение не совсем изящное но главное работоспособное. ну нехватает мне специальных знаний...

лкдс никто не защищает... вы б побывали там посмотрели... и со сроками... кто вам точно скажет когда решение будет? имеется приоритет в решении, задач. как и во всякой конторе...
лично я в незапамятные времена почти год ждал пока реализуют одну функцию в М-Мульте (а сейчас ею все пользуются). и не кричал на форумах КАРАУЛ!!! и сейчас есть мысли. ЛКДС знает и я знаю что в конце концов решение будет... а кричать... это глупо...

попробовал залить в 3420 прошивку двухгодичной давности... неработает! даж с компом, а не ксл виснет!

более менее стабильно работающие прошивки появились около года назад... срок небольшой... так что схема с двумя маршрутерами появилась и не от хорошей жизни...
второй вопрос цена...
ситуация. прихожу к заказчику и
говорю... есть решение за 7-10тысяч. но если крякнет то снова туж суму надо будет..
ответ: а подешевле?
1: есть за 3000. из трёх часте по 1000.
2: тоесть если чтото рухнет то в 1000 уложиться можно?
1: в принципе да...
интересно какой выбор сделает заказчик???

не спорю больше оборудования, больше настроек... но все настройки юзерские практически любой справится.. а это большой плюс...

сейчас как выясняется можно стоимость оборудования снизить до 2000р и обойтись двумя устройствами УПП и маршрутером... так что есть уже частное решение... можно и подождать немного... чего орать то???

интересно а кто тогда Александр?? rolleyes.gif


Автор: lms-i 1.4.2013, 19:00

Спасибо всем. Без вас мы бы не справились.
Fixer, отдельная благодарность за реальное решение по существу темы.

Автор: ginairat 2.4.2013, 0:00

Внесу свои пять копеек... Считаю, что lms-i и pavel правы. Проблема была, пусть в маршруте, но была. И решить ее должны были именно разработчики Оби. Ведь на остальные настройки маршрутизаторов инструкции были написаны (для 3Джи в том числе), так почему тут категорически отказывались? Нет времени? Так сказали бы, так мол и так в ближайшем будущем проблему рассмотрим и попытаемся решить... ИМХО.

Автор: котяра 2.4.2013, 8:08

Цитата(ginairat @ 2.4.2013, 1:00) *

Внесу свои пять копеек... Считаю, что lms-i и pavel правы. Проблема была, пусть в маршруте, но была. И решить ее должны были именно разработчики Оби. Ведь на остальные настройки маршрутизаторов инструкции были написаны (для 3Джи в том числе), так почему тут категорически отказывались? Нет времени? Так сказали бы, так мол и так в ближайшем будущем проблему рассмотрим и попытаемся решить... ИМХО.


попробую...
ну во первых. настройки в маршрутерах указаны СТАНДАРТНЫЕ. просто для удобства написаны...
во вторых. где вы видели явный отказ ЛКДС на эту тему? да есть свои нюансы (а как ещё на "крикунов" реагировать?) но отказа небыло.
ну а в третьих. самим что не попробывать то? время нет? а у них видимо море...

а по теме...
на дешовых маршрутерах (до 1500р) сделать на 100% надёжную схему врятли удасться.. всегда окажутся скелеты в шкафу... да и для реальных ипытаний каждого типа маршрутера нужен полигон и время не менее полугода... ( стенд это и есть стенд... реалии это нечто другое)
на дорогих (свыше 7000р) видимо возможно. но возникает вопрос в цене...
любой заказчик выберет вариант на "рассыпухе" так как он окажется гораздо дешевле (до 3000р максимум).

для ЛБ6.0 про... думаю, пока, лучше озадачить их введением резервирования по шлюзам (это им гораздо ближе)...

ну а в перспективе конечно неплохо бы...

ИМХО. это моё частное мнение...


из истории.
в своё время при использовании ПКСЛ. столкнулись с проблемой резервирования по нескольким шлюзам (тобиш сетевым картам). Андрей Ефименко писал об этом... причина была в програмном обеспечении винды. но так как с майкрософтом общение практичестки невозможно, была разработан отдельный програмный модуль для обхождения этой проблемы винды. "костыль" одним словом.
я не силён в "матиматике" но, как кажется, в маршрутерах похожая же проблема...
НО!! в отличии от компа туда сою програмулену не сделаешь. остаётся внешний "костыль"...
а УПП это и есть в данном случае "костыль"...

ну гдето так...

Автор: ginairat 2.4.2013, 11:54

Так то, если прочитать первый пост темы, то там ничего кричащего )). Вполне адекватная просьба помочь разобраться. И в дальнейшем тоже вполне аргументированные ответы lms-i и pavel.


Цитата
...После рестарта маршрутизатора таблицы протокола NAT очищаются и работоспособность восстанавливается.

Сорри, это пропустил. Если это решает проблему, то можно и УПП пользоваться )

Автор: lms-i 2.4.2013, 12:52

Цитата(котяра @ 2.4.2013, 9:08) *

во вторых. где вы видели явный отказ ЛКДС на эту тему?

здесь -
Цитата(Андрей Ефименко @ 21.3.2013, 15:13) *

Проблема в маршрутизаторе.

Но, это не отказ...нет. просто прекращение дальнейших действий...
Цитата

(а как ещё на "крикунов" реагировать?)

Что Вы имеете под словом "кричите"? blink.gif У вас с Александром самые эмоцианальные посты... wink.gif
Цитата
ну а в третьих. самим что не попробывать то? время нет?

Вы не внимательно читаете ветку, мы уже пробуем полгода.
Цитата
любой заказчик выберет вариант на "рассыпухе" так как он окажется гораздо дешевле (до 3000р максимум).

НЕ ЛЮБОЙ! У Вас скорее всего скудный опыт работы с заказчиками на этапе проектирования и согласования. При граммотной мотивации и хороших переговорных способностях можно добиться качественного подхода при перерасходе в 1000-3000 руб. Даже с бюджетниками, с ними бывает еще проще, т.к. деньги не их личные. И уйти от костылей типа УПП, которые далеко не всегда помогают. Более менее хороший маршрутизатор может стоить менее 5000 р. wink.gif

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

Зачем нам костыли? Мы же специалисты и должны профессионально подходить к решению проблем. Давайте вместе, никто никуда не торопит!

Автор: revit 2.4.2013, 17:22

Цитата(котяра @ 2.4.2013, 6:08) *
на дешовых маршрутерах (до 1500р) сделать на 100% надёжную схему врятли удасться..
на дорогих (свыше 7000р) видимо возможно.
Я даже больше скажу-что 1500 что за 7000 -разница в цене только из-за железа (мощнее проц, более скоростные интерфейсы и т.д) . Программные грабли могут быть одинаковые в обоих. Не раз попадал на такие. smile.gif
Цитата(котяра @ 2.4.2013, 6:08) *
в своё время при использовании ПКСЛ. столкнулись с проблемой резервирования по нескольким шлюзам (тобиш сетевым картам). Андрей Ефименко писал об этом... причина была в програмном обеспечении винды. но так как с майкрософтом общение практичестки невозможно, была разработан отдельный програмный модуль для обхождения этой проблемы винды. "костыль" одним словом.
Драйвер ЛКДС NDisprot это не костыли а специальная программа управления . Винда всегда работала с одним шлюзом а драйвер ее заставляет работать на несколько.

Автор: котяра 9.4.2013, 19:25

Резервирование одним маршрутизатором (тп-линк 3240) удаленного УМ.

Вообще м такая картина. После недельного эксперимента…

На удаленном ум: 2 IP-адреса. IP-адреса могут быть как и статические так и динамические. Как мне показалось, роли особой тут нет.
На пульту: использовались 2 статических IP-адреса. Один основной, другой резервный.

О роутер:
1. данный тип маршрутера имеет свойство «терять» 3g модем при простое. «Встроенные» в маршрутер алгоритмы зачастую не справляются с перезапуском модема. (Возникло, правда, подозрение что тут больше прошивка модема виновата)
2. исходя из вышесказанного применение УПП необходимо…
3. запуск маршрутера в режиме 3G с «0» занимает около 3минут (об этом чуть попозже).
4. переключение с режима WAN на 3G занимает от 30сек до 3мин… и то если модем не «завис».

О КСЛ/моноблоке:
1. необходимо установить время: ожидание после рестарта не менее 180сек. Это единственная доработка КСЛ которая реально требуется. Желательно вообще до 240 поднять. (это к разработчикам)
2. возможно надо сделать возможность «двойного» ожидания, по параметру «ожидание времени после рестарта»… То есть вначале происходит «перезапуск-ожидание» без передёргивания маршрутера (даётся врема на перестройку маршрутизации роутера), а если после этого, не произойдёт соединение то происходит повторный «рестарт» но уже с командой на отключение роутера. (это тож к разработчикам)
3. остальные настройки особого влияния не оказывают, при указанном выше времени… играться временем «ожидания ответа» тут не реально. Делать этот параметр равным 3минутам маразм, на мой взгляд.

О Пульте:
Использовался ПКСЛ.
Из настроек критические параметры который выявились.
1. Необходимо установить признак «работа по динамическим IP-адресам»
2. в исходящих связях указывать: 0000000.


кое какие мои наблюдения. (возможно и ошибочные).
Если использовать в ПКСЛ маршрутизацию по статическим адресам то, по моим наблюдениям, фактически всегда будет происходить перезапуск роутера КСЛ-ом (а то и не один раз). Хотя реально переключение на модем роутером производится… увеличение времени «время опроса УМ» в ПКСЛ немного меняет картину, но несильно…
В связи с этим использование на пульту аппаратного КСЛ, как мне представляется, неразумно. Также использование данного роутера (в режиме резервирования) на пульту тоже, на мой взгляд, неоправданно. Ненадёжно.

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

П.С. (последние наблюдения)
1. добавлю, что модем использовался «привязанный» к МТС Е1550.
2. при использовании «непривязанного» модема (Е1550) переключение происходит примерно за 2-3,5минуты а, с «привязанным» от 0,5 до 3 минут.
3. по моим наблюдениям, при использовании «непривязанного» модема, необходимость в УПП снижается на порядок…


Р.S. мож кому то и пригодится… пишу только то что сам наблюдал.

Прошу прошение за стиль изложения! «сисадмины» на смех не подымайте, пожалуйста. :o Пишу как понимаю. ;)

Автор: Tma_Jaguar 16.7.2013, 17:11

Я вот тоже занялся реализацией резервирования, и вот уже столкнулся с другой проблемой. Моноблок не возвращается на основной ип адрес при входящей связи. Сначала я вам на пальцах расскажу что такое ТСП и ЮДП протоколы (извините что всё пишу русскими буквами).

Так вот ТСП это как почта России, собирается посылка или бандероль, прикрепляется Адрес назначения и обратный адрес (точный обратный адрес) и выкидывается это в окно интернета, там принимается-распаковывается-упаковывается ответ-отправляется обратно точным адресом.

ЮДП сравним с телефоном. Устанавливается связь по номеру ип адреса и начинается каждые 2 секунды Алё - Алё - Лифт 4 где? - на 7 этаже - Алё - Алё. И можно молчать даже, а сессия будет висеть. Вся голосовая интернета в ЮДП. Потому что возможен двухсторонний обмен информации без задержек.

Теперь к ёжикам нашим. Дир-320 отстой. Пробую кенетик 4джи, сначала бодался с тех поддержкой по поводу добавления новой ревизии модели е171 модема в их прошивку, потом их пытался заставить допилить нормальное переключение с ВАН на модем, а то роутер виснет, теперь вот форумы читаю, думаю как дальше то жить)))

Автор: lms-i 17.7.2013, 7:48

Цитата(Tma_Jaguar @ 16.7.2013, 18:11) *

теперь вот форумы читаю, думаю как дальше то жить)))


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

На тему "других" проблем с моноблоком - можно целый семинар устроить. ) Я могу на вскидку добавить еще несколько:
1. При отказе основного канала Моноблок переходит на резервный канал. Когда основной канал восстанавливается - моноблок на него с резервного не возвращается!!! (может Вы это и имели в виду) Это самая серьезная проблема в плане организации резервирования. При чем ни где нет сигнализации о пропаже/возобновлении работы и основного канала и резервного. Мне кажется в МПульт должна быть такая сигнализация (кроме банального "Нет связи с ЛБ"), ведь это не сложно, но очень нужно! Приходиться допиливать средства мониторинга. Ведь надо понимать что переключение произошло, принимать действия по пропинке провайдеров, а когда восстановилось - вернуться, т.к. у нас допустим на резерве по мБ тариф - а это деньги...(
2. Нет возможности настроить PPPoE соединение.
3. Политика безопасности отсутствует.
и т.д.

Автор: revit 17.7.2013, 9:57

Цитата(Tma_Jaguar @ 16.7.2013, 15:11) *

ЯПробую кенетик 4джи, сначала бодался с тех поддержкой по поводу добавления новой ревизии модели е171 модема в их прошивку, потом их пытался заставить допилить нормальное переключение с ВАН на модем, а то роутер виснет, теперь вот форумы читаю, думаю как дальше то жить)))
Версия прошивки 1.х или 2.х?
Цитата(lms-i @ 17.7.2013, 5:48) *
1. При отказе основного канала Моноблок переходит на резервный канал. Когда основной канал восстанавливается - моноблок на него с резервного не возвращается!!!
Это громкое заявление, вы точно уверены? На какой прошивке? Не понимаю как мои 80 УМ-ов работают с резервом. Может объясните?
Цитата(lms-i @ 17.7.2013, 5:48) *

2. Нет возможности настроить PPPoE соединение.
Это да, в некоторых случаях нужно бывает.
Цитата(lms-i @ 17.7.2013, 5:48) *
3. Политика безопасности отсутствует.и т.д.
Какая политика -UDP и пинг... Что там обезопасивать?

Автор: котяра 17.7.2013, 10:01

ну дали .... опять пофлудить...

как это надо извратиться чтоб переключение интерфейсов неработало на ксл. это реально надо быть "крутым" сисадмином!!!
кстати в последнем дистрюбьютиве сигнализация есть...

по остальному без коментариев...

по схеме которую я выше описал у меня 2 узла работают... один без УПП. зависал пару раз за это время... но он близкий, проблем с "передёргиванием" нет... хотя скоро поставлю и туда УПП. зачем лишний раз ноги бить???
только не говорите что это косяк Оби, протоколы типа... это такие прошивки маршрутера и модема в купе...

кстати вы так и не привели пример в каких частях протокола нет соответствий..

Автор: Fixer 17.7.2013, 11:00

Коллеги, прекращайте уже всех собак на ксл вешать.
Во-первых, переключается там все нормально, у КСЛа есть таймаут, по которому он начинает пинать основную связь.
А во-вторых, для особо одаренных: АБСТРАКЦИЯ! АБСТРАКЦИЯ!
И ещё разок: АБСТРАКЦИЯ!
Дайте КСЛу хвост eth, а вопросами каналов и резервов пускай занимается маршрутизатор, он оттого и маршрутизатором называется.

Автор: lms-i 17.7.2013, 11:02

Цитата(revit @ 17.7.2013, 10:57) *

Это громкое заявление, вы точно уверены? На какой прошивке? Не понимаю как мои 80 УМ-ов работают с резервом. Может объясните?

Со слов наших ребят - уверен, обратно само не переключается пока резервный канал не отвалится. Уточню еще раз.
Цитата(revit @ 17.7.2013, 10:57) *

Какая политика -UDP и пинг... Что там обезопасивать?

Как я понял (в этом я не силен), дело в том, что если знать ip УМ, то с ним удаленно может работать левый человек знающий систему "Обь", никаких защит нет.

Автор: pavel 17.7.2013, 11:10

Цитата(revit @ 17.7.2013, 10:57) *

Это громкое заявление, вы точно уверены? На какой прошивке? Не понимаю как мои 80 УМ-ов работают с резервом. Может объясните?

Никто не говорит, что резерв не работает. Говорят о том, что если в удаленной УМ КСЛ с двумя рутерами перешел на запасной канал, он на нем и останется. Пока с запасным каналом какая-нибудь хрень не случится, которая вынудит КСЛ переключится обратно на основной. Например, ребут КСЛ или запасного маршрутизатора.
Т.е. восстановление (в схеме от ЛКДС с двумя рутерами) основного канала - не говорит о том, что КСЛ на него переключится через какое-то время. Ну восстановился и восстановился. Обь раюотает дальше на резерве.

Цитата(revit @ 17.7.2013, 10:57) *

Какая политика -UDP и пинг... Что там обезопасивать?

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

to котяра
у нас работают с резервом 5 точек. 2 по схеме ЛКДС, 3 по нашему методу описанному Выше как решение проблемы обозначенной в теме. Нигде нет УПП. Нигде он и не нужен. Дергать потому что ничего не надо. Кому, что как говорится...
Не соответствие протоколов:
Если Вы возьмете любой прикладной протокол, HTTP, SMTP или SNMP например, то заметите что у него есть правила запросов-ответов, приветствий. Любой из них в качестве транспортного использует TCP или UDP, в зависимости от необходимости подтверждения доставки. Сначала обычно идет приветсвие, после запрос, после ответ, потом паузы, новый обмен и т.д. Запросы бывают разные, ответы. Если что-то идет не так, происходит разрыв соединения. Которое может потом быть инициировано заново.
Разработчики ОБИ создали какие-то правила, по которым КСЛ/Моноблок/ПКСЛ/ЛБпро/ПКЛШ общаются между собой. Какие-то приветствия, запросы, ответы, уведомления и т.д. Эти правила я и называю "протоколом Оби".
Проблема поднятая в этой теме состоит в том, что "протокол ОБИ" не переваривает реализацию NAT в маршрутизаторах при переключении на разных провайдеров. Он не подстраивается и не настраивается под такое переключение. Хотя мог бы. Вариант для продвинутых маршрутизаторов был мной уже описан.

to Tma_Jaguar

У Вас очень сумбурный пост.
Проблема не ясна. Что используете, как настроили. Опишите схему.
Описание TCP и UDP не верное. Главное их отличие - гарантия доставки.
Т.е. TCP - заказное письмо (для обычной почты), когда Вы получаете от адресата уведомление с росписью в том, что он получил Вашу посылку. А UDP - обычное письмо. Дошло оно до адресата или нет, Вы от почты не узнаете и гарантий нет.

Автор: lms-i 17.7.2013, 11:22

Цитата(котяра @ 17.7.2013, 11:01) *

по схеме которую я выше описал у меня 2 узла работают...

вот когда будет 10 УМ по такой схеме, тогда и поговорим, CHIAO!

Автор: revit 17.7.2013, 11:29

Цитата(lms-i @ 17.7.2013, 9:02) *

Как я понял (в этом я не силен), дело в том, что если знать ip УМ, то с ним удаленно может работать левый человек знающий систему "Обь", никаких защит нет.
No comments... Это просто бред...


Цитата(pavel @ 17.7.2013, 9:10) *

Вас не взламывали? Не пытались?
Нас пока нет. Тьфу-тьфу.
были попытки и не раз... Комп закрыт файерволом а КСЛ/моно бесполезно ломать т.к нечего. Объясните о какой именно безопасности речь?


Автор: котяра 17.7.2013, 21:04

Цитата(lms-i @ 17.7.2013, 12:22) *

вот когда будет 10 УМ по такой схеме, тогда и поговорим, CHIAO!
P.S.: Дело совсем не в Барнауле.... wink.gif



когда нибудь и будет rolleyes.gif


Автор: kurilka 18.7.2013, 13:06

Цитата(pavel @ 17.7.2013, 12:10) *

Так вот, есть простой способ перехватить управление сетью Оби и всеми лифтами.

Да, действительно способ есть, но вовсе непростой.

Цитата(pavel @ 17.7.2013, 12:10) *

... если в удаленной УМ КСЛ с двумя рутерами перешел на запасной канал, он на нем и останется..

Через час ксл сделает попытку вернуться на основной канал. Если в этот момент он окажется не рабочим, ксл останется на резервном канале. И так до тех пор, пока звезды не сойдутся.

Прислушайтесь к словам Fixer-а. Не дело КСЛу маршрутизацией заниматься. Отдайте это на растерзание маршрутизатору.

Автор: pavel 6.8.2013, 0:53

1) Возврат КСЛ на основной канал.
"Если КСЛ начал использовать для связи либо альтернативный IP адрес связи либо альтернативный шлюз, то через 60 минут делается попытка вернутся на основные параметры. " - это из документации "Сеть передачи данных "ОБЬ" (LKDSDrv). Руководство по настройке".
Всё именно так и работает. Был не прав.
Был УМ с медленным (с потерями) резервным каналом, после восстановления основного канала диспетчера звонили и говорили, что всё по прежнему работает ооочень медленно, ГГС еле-еле. Когда начинал разбираться обнаруживал, что Обь всё еще работает по резервному. Перезагружал железку в УМ и всё начинало работать по основному и быстро. Было так несколько раз на двух УМ. Поэтому в голове остался пунктик. Экспериментально понял, что просто не дожидались отработки автоматики.

2) Проблема с безопасностью.
Дырка не дырка. Судите сами.
-- Текст убран автором в целях безопасности --- будет отправлен письмом разработчикам.
Статические IP везде - всё же выход.

3) По проблеме изначально обозначенной в этой теме.
Мы не просим от КСЛ маршрутизировать что-либо. Нам бы хватило даже одного поля шлюз в КСЛе. Мы просто хотим чтобы маршрутизировал между каналами именно МАРШРУТИЗАТОР.
Именно ЛКДС навязала схему с двумя маршрутизаторами, в которой по сути возлагает на КСЛ дополнительную нагрузку по работе с двумя шлюзами, т.е. заставляет КСЛ маршрутизировать.
Мы уже перешли на абстракцию - VPN.
Ладно давайте закончим диспут, объясню почему мы так упорствуем и чего добиваемся:

Я лично из мира сетевых технологий. В нем у меня сложилась четкое представление, что за маршрут посылки пакета отвечает маршрутизатор. За выбор канала между двумя провайдерами отвечает маршрутизатор. Поэтому когда я прочитал в документации Оби про схему с двумя маршрутизаторами я принял ее к сведению, но не посчитал ее единственно возможной.
Предложил компании, в которой работаю, перейти на чуть более продвинутые маршрутизаторы. Которые смогут больше в плане управления, статистики, безопасности и сами смогут обеспечить переключение на резерв (это нормально для маршрутизатора).
Но при первой установке с резервом вся это 4 месячная (для меня) свястопляка и началась.
Итогом ее стало: у разработчиков нет времени, это проблема реализации NAT в маршрутизаторах.
Разработчики верно натолкнули на причину. Довольно быстро у нас появилось две рабочие схемы - как сделать резерв с одной железкой:
1) Меняем таймеры NAT и КСЛ.
2) VPN (помогает и в случае ЛБпро в УМ).

Задела меня реакция разработчиков и завсегдатаев форума.
Ведь нами потрачена куча времени. Мы сами откопали проблему, сами нашли решение. Написали о нем.
У ЛКДС в документации нет строки "с одним маршрутизатором резерв не работает". Откуда нам было знать про все эти проблемы. Могут появиться новые клиенты, которые будут исходить из той же предпосылки: маршрутизировать должен маршрутизатор. Разработчики им потом в форум тыкать будут? Нет времени что-то менять - напишите пару строк в документации: "резервирование УМ с КСЛ и ЛБпро одним маршрутизатором не работает. Можете указать ваш взгляд из-за чего. Нужно пременять VPN-каналы, либо два маршрутизатора."

По основной работе была возможность посмотреть как работает NAT в такой ситауции на маршрутизаторах Cisco (лидер индустрии). Знаете так же как и на Микротиках. Те же таймеры по умолчанию, которые также можно изменить, также переключается - в общем реализация NAT на маршрутизаторах очень схожа. Даже таймауты удаления записей из таблиц NAT совпадают.
Я не знаю какие еще доводы нужны, чтобы объяснить: есть NAT, он такой, он такой во всем мире. Давайте это учитывать, когда пишем программы.
Остальное же работает через него, не зависает навечно. Таже SIP-телефония (UDP). Оборвется, присоединиться заново. Да различий много, всё несколько иначе. Но ведь и у SIP-телефонии вначале было много проблем. Но всё как-то решается движется вперед.
Нет времени - предупредите клиентов. Подправьте документацию.

Автор: kurilka 8.8.2013, 9:33

Цитата(pavel @ 6.8.2013, 1:53) *

Дырка не дырка. Судите сами.

Возможно, что есть легкий способ взлома, о котором я не знаю.
Цитата

Статические IP везде - всё же выход.

Я бы использовал статику для связи ПКСЛ->ПКСЛ. И еще убрал возможность выгружать и загружать nvram в ПКСЛ.
Цитата

Именно ЛКДС навязала схему

Право выбора использовать неиспользовать остается за вами.
Цитата

Мы уже перешли на абстракцию - VPN.

И правильно сделали.
Цитата

Но при первой установке с резервом вся это 4 месячная (для меня) свястопляка и началась.

У меня резервирование с одним маршрутизатором работает с 2007 г. Не всегда стабильно (модемы виснут), но работает. Если это еще актуально, то можно попробовать разобраться. Есть еще неделька.

Автор: pavel 8.8.2013, 11:53

Цитата(kurilka @ 8.8.2013, 10:33) *

Право выбора использовать неиспользовать остается за вами.


В том то и дело, что с одним маршрутизатором - не работает. Нужно либо изменять тайматы в КСЛ и роутере, либо VPN/туннели. Причем в документации про это ни слова.

Цитата(kurilka @ 8.8.2013, 10:33) *

У меня резервирование с одним маршрутизатором работает с 2007 г. Не всегда стабильно (модемы виснут), но работает. Если это еще актуально, то можно попробовать разобраться. Есть еще неделька.


В чем разобраться? Причины проблемы здесь уже раз десять были описаны под разными соусами. Диспут был о том, чья это проблема. ЛКДС или маршрутизаторов.

Если у Вас с 2007г. всё работает, можно в двух словах - как именно?

Автор: kurilka 8.8.2013, 13:00

В двух словах наверно будет непонятно.
Маршрутизатор в режиме "failover". При пропадании W1 устанавливается PPP соединение (W2) и разрывается при появлении W1. Собственно все.
У Вас по другому?

Автор: Sherp 17.9.2013, 16:18

Уважаемые участники дискуссии и, прежде всего, pavel! Хотел в диспетчерской организовать резервирование одним маршрутизатором Mikrotik (как собственно и описано в этой теме), но никак не могу сделать автоматическое переключение каналов именно на самом маршрутизаторе. Перерыл уже весь Интернет, попробовал кучу описанных способов и максимум, чего удалось добиться - канал переключается, Интернет 1-2 минуты работает, а потом отрубается. Если кто-то сталкивался с настройкой Mikrotik'ов, скиньте пожалуйста мануал, по которому вы сами настраивали маршрутизатор, а то уже совсем измучался. Заранее спасибо за ответы.

Автор: pavel 18.9.2013, 8:36

Цитата(Sherp @ 17.9.2013, 17:18) *

Уважаемые участники дискуссии и, прежде всего, pavel! ...


Практически все нужные мануалы по Микротику находятся здесь:
http://wiki.mikrotik.com/wiki/

Конкретно по резервированию подключения к Интернет с помощью двух провайдеров:
1. Скриптовый метод: http://wiki.mikrotik.com/wiki/Failover_Scripting
2. Безскриптовый метод: http://wiki.mikrotik.com/wiki/Advanced_Routing_Failover_without_Scripting
3. Еще один скриптовый метод: http://wiki.mikrotik.com/wiki/ECMP_Failover_Script
4. Первая и основная настройка для двух провайдеров (отрабатывает только в случае отсутствия пинга до шлюза провайдера): http://wiki.mikrotik.com/wiki/Two_gateways_failover

Сейчас используем доработанный под нас первый вариант. Собираюсь переходить на второй, после некоторой обкатки на тестовом стенде.


Автор: Sherp 20.9.2013, 11:00

pavel, огромное спасибо вам за ссылки, всё удалось настроить с помощью безскриптового метода, переключение происходит быстро и четко. Также настроен переход на резерв в самой "Оби". В связи с этим есть несколько вопросов.
1. Переход на резерв в MPult происходит с некоторой задержкой, которая сопровождается кратковременной потерей и последующим восстановлением связи с некоторыми УМ. Присутствует ли такое поведение MPult у вас?
2. Необходимо ли прописывать резервные адреса в настройках ЛБ 6.1. Pro? В некоторых ЛБ я прописывал резерные адреса, в некоторых нет, переключение происходит и в том, и в другом случае.

Заранее спасибо за ответы.

Автор: pavel 2.10.2013, 23:48

Цитата(Sherp @ 20.9.2013, 12:00) *

В связи с этим есть несколько вопросов...


1. Обычно нет. Но иногда возникает. Причина скорее всего в параметре ПКСЛ диспетчерской - интервал опроса КЛШ, у нас он 3 мин кажется.
2. Связь в сторону дичпетчерской на ЛБпро 6.1 нужно прописывать только, если IP ЛБпро - динамический. При статике на ЛБпро 6.1 параметры связи лучше указывать на ПКЛШ - так быстрее происходит установление связи Оби при переключении на резервного провайдера.

Автор: Tma_Jaguar 8.6.2015, 7:23

Какое оборудование нужно приобрести для резервирования одним роутером? Один микротик на ДП + один на моноблок? Какие модели подойдут? У нас на ДП оптика, поэтому необходимости в резервировании нет, а вот моноблок необходимо зарезервировать. Ну и в общем какая схема подключения двух микротиков?

Автор: revit 8.6.2015, 11:41

Цитата(Tma_Jaguar @ 8.6.2015, 4:23) *

нас на ДП оптика, поэтому необходимости в резервировании нет,
biggrin.gif Вот как раз ее то и нужно резервировать т.к она зависима от энергоснабжения, которое не резервируется источником бесперебойного питания находящимся в диспетчерской (если она у вас конечно она не прямая до серверной провайдера). И резервировать каналом сохраняющим работоспособность длительно работать от ИБП диспетчера (соnовый или ADSL)

А по поводу роутеров: модели имеющие два порта WAN или возможность назначения дополнительного порта WAN на одном из Ethernet. Зиксель-кинетик например.

Автор: Tma_Jaguar 8.6.2015, 12:00

Цитата(revit @ 8.6.2015, 12:41) *

biggrin.gif Вот как раз ее то и нужно резервировать т.к она зависима от энергоснабжения, которое не резервируется источником бесперебойного питания находящимся в диспетчерской (если она у вас конечно она не прямая до серверной провайдера). И резхервировать каналом сохраняющим работоспособность длительно работать от ИБП диспетчера (соnовый или ADSL)

А по поводу роутеров: модели имеющие два порта WAN или возможность назначения дополнительного порта WAN на одном из Ethernet


Оптика с узла провайдера, который зарезервирован на 7 часов + в случае долгой отключки 220 туда бегут ребята с генератором. Проблема будет только в случае обрыва магистральной оптики провайдера. Конвертор стоит у нас и зависит от нашего бесперебойного питания. Интересует резервирование выделенки меди каналом 3g через свисток. Какие микротики подойдут? любые с юсб или всё же какие то определенные модели? Какими конкретно вы пользуетесь?

Зюксель кенетик тестировал полтора года назад. Как то тяжко у него переход с WAN на 3G, и к тому же айпишник меняется + он переходит только в случае падения линка, А хочется функцию пинга (например ДП) и в случает обрыва - переход на резерв.

Как я себе представляю идеальную систему резервирования. Микротик на ДП имеет сервер ВПН (VPN) в котором существует внутренняя локальная сеть и подключаемые клиенты к ВПН попадают сразу во внутренюю сеть. На домах микротики подключаются к провайдору и конектятся к ВПН ДП, в случае обрыва - поднимается резер интернета 3Джи и конектится опять к ВПН ДП.

Автор: lms-i 8.6.2015, 13:47

Цитата(Tma_Jaguar @ 8.6.2015, 13:00) *

Оптика с узла провайдера

Любое оборудование провайдера ломается, линии, конвертор, плановые работы и т.д. Мы в любом случае ставим резерв. ИМХО.
Цитата

Интересует резервирование выделенки меди каналом 3g через свисток. Какие микротики подойдут?

На удаленные УМ сейчас ставим Mikrotik RB951Ui-2HnD. А какое оборудование у Вас в ДП? Если ПК, то там Микротик не нужен. хотя.. как посмотреть.)

По настройкам к pavel лучше обратиться. Его почту в личку скину.

Автор: котяра 8.6.2015, 18:39

Цитата(Tma_Jaguar @ 8.6.2015, 13:00) *

Зюксель кенетик тестировал полтора года назад. Как то тяжко у него переход с WAN на 3G, и к тому же айпишник меняется + он переходит только в случае падения линка, А хочется функцию пинга (например ДП) и в случает обрыва - переход на резерв.



последние прошивки зукселей поддерживают переход на резерв по пингу...

Автор: Tma_Jaguar 8.6.2015, 23:40

Цитата(котяра @ 8.6.2015, 19:39) *

последние прошивки зукселей поддерживают переход на резерв по пингу...

А пксл поддерживает динамические связи? Ну то есть он сменит айпишник связи если моноблок до него начнет стучаться с другого айпишника?

Или зюксель сможет подключаться к одному ВПН-серверу через выделенку и 3Джи

Автор: котяра 9.6.2015, 0:13

Цитата(Tma_Jaguar @ 9.6.2015, 0:40) *

А пксл поддерживает динамические связи? Ну то есть он сменит айпишник связи если моноблок до него начнет стучаться с другого айпишника?


без комментария...
это элементарно Ватсон... разумеется.

Автор: Tma_Jaguar 9.6.2015, 19:22

Цитата(котяра @ 9.6.2015, 1:13) *

без комментария...
это элементарно Ватсон... разумеется.

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

Автор: Евгений Пухальский 23.10.2015, 8:06

Все проблемы легко решаемы с помощью Mikrotik RB750, это такой маршрутизатор, стоит в районе 80уе. Там на уровне самой железяки все настраивается, все возможные резервированные каналы.
Прошу извинить общественность за уже 2-й раз упоминание этого, )) но за много лет намучился и нарадовался с разным популярным оборудованием, но как дорвался до микротика - мировоззрение перевеернулось! Там вплоть до того что время жизни динамического маршрута настраивается, и пара десятков других параметров НАТа... Т.е получаете ЦИСКу за 80уе.

К примеру красота - в машинку заводится Корбина, как на физ. лицо, и на диспетчерскую тем или иным образом она же, надо преодолеть бюрократию с физ-юр лицами. И автоматом получается 2 канала - через внешний инет, и через серую сеть Корбины, на знаю кстати как в РФ, но наша Казахстанская "Корбина" - Билайн интернет дома - еще и серые адреса практически статические держит... По крайней мере 3 мес. уже несколько модемов в сети, и серые адреса не поменялись.
И канал такой, что и видео по серой гнать можно.

Только одно гадство, нет-нет, да ненадолго и серая отваливается... Минута-другая-десяток в месяц...


Автор: Владислав Линкин 11.1.2016, 12:08

Увидел тему и как бывший интернетчик, придумал решение. Сообщения выше не читал, так что прошу прощения если повторюсь.
Для D-link'ов обольшинства моделей есть прошивка DD-WRT и OPEN-WRT
На этих прошивках можно шикарно реализовать резервироваие интернета и не только. rolleyes.gif
По резервированию есть полезная статья на хабре:
http://habrahabr.ru/post/170169/
wacko.gif Так же можно поднять простенький VPN сервер и подключаться с этих маршрутиризаторов (снимает вопрос, какой интернет проводной/3g и снимает проблему с IP). Реализовывал данный способ на макете и в принципе всё работало.
Если вдруг есть вопросы - пишите. помогу чем смогу biggrin.gif

Автор: Pro100A1ex 13.5.2016, 12:39

Всем доброго времени суток.
Почитал данную тему и решил поделится опытом реализации работы трех провайдеров на одном роутере MikroTik RB750.
Сразу оговорюсь, что описание буду выкладывать по наличию свободного времени, также я не сетевик smile.gif, и самое основное - на данный момент до конца роутер не сконфигурирован, так как хочется многого, но для реализации мало знаний sad.gif , а именно в том, что роутер работает в режиме балансировки между провайдерами и на данный момент не настроено резервирование, но если отказаться от балансировки, то данный вопрос решается элементарно указанием разных предпочтений для провайдеров "Distance 1 и 2" т.е. вся сеть работает через провайдера 1, а когда он падает - переходит на второго.
Хотелось уточнить насколько глубоко описывать настройки роутера ?
Продолжение следует ...

Автор: karellift 18.5.2016, 16:50

Цитата(Pro100A1ex @ 13.5.2016, 9:39) *

Всем доброго времени суток.
Почитал данную тему и решил поделится опытом реализации работы трех провайдеров на одном роутере MikroTik RB750.
Сразу оговорюсь, что описание буду выкладывать по наличию свободного времени, также я не сетевик smile.gif, и самое основное - на данный момент до конца роутер не сконфигурирован, так как хочется многого, но для реализации мало знаний sad.gif , а именно в том, что роутер работает в режиме балансировки между провайдерами и на данный момент не настроено резервирование, но если отказаться от балансировки, то данный вопрос решается элементарно указанием разных предпочтений для провайдеров "Distance 1 и 2" т.е. вся сеть работает через провайдера 1, а когда он падает - переходит на второго.
Хотелось уточнить насколько глубоко описывать настройки роутера ?
Продолжение следует ...

Злой микротик ...
Если бы его интерфейс был бы дружелюбен,как Zyxel,Asus,Netgear .
А так можно отдельную ветку открывать микротик, его настройка через Winbox и тд. слишком он узко спицилизирован.
Но вот если настроил,то забыл.

У нас на серверной, как раз микротик стоит. Я когда его с нуля настраивал без мануалов у меня ушло 3 дня. Потом день я вкуривал, как организовать пробросы портов на разные провайдеры и т.п. Хотя может быть Ваша железяка уже поближе к пользователю,но мне хватило терминала и команд в нем.

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

Для моноблоков, кслов использую zyxel, устанавливая доппакет приложений,втыкаю 3 g модем.
Настраиваю приоритет связи и пинг на диспетчерскую,нет пинга переключает на другой канал.
Моноблоку,кслу,блоку все равно ,что там за роутером у него ip не меняется, и связь остается прежней.

В пклш ставлю ip оборудования - 0.0.0.0

Автор: Tma_Jaguar 24.5.2016, 10:27

Цитата(karellift @ 18.5.2016, 17:50) *

В пклш ставлю ip оборудования - 0.0.0.0

C пклш всё понятно. А вот пксл что то не хочет подхватывать динамический ип. Может для этого необходимо использовать ключ (у меня он везде пустой)?

Русская версия Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)