КСЛ Резервирование одним маршрутизатором

[lms-i]

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

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

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

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

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

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

 

[pavel]

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

:blink:
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с. Либо по-другому можно было задавать паузу в обмене. И всё! ЛКДС может писать в руководства схему резервирования с одним маршрутизатором, что для клиентов намного экономичнее. И сделать руководство по резервированию для ЛБпро!

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

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

Согласен с lms-i

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

 

[alex_san]

:blink:

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

 

[lms-i]

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

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

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

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

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

 

[revit]

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

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

Технология одна, реализация разная. И там тоже люди...

 

[pavel]

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

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

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

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

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

 

[alex_san]

Александр, я понимаю что Вы модератор...

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

 

[pavel]

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

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

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

 

[alex_san]

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

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

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

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

 

[котяра]

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

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

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

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

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

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

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

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

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

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

 

[lms-i]

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

 

[ginairat]

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

 

[котяра]

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

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

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

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

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

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


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

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

 

[ginairat]

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

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

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

 

[lms-i]

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

здесь -

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

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

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

Что Вы имеете под словом "кричите"? :blink: У вас с Александром самые эмоцианальные посты...

ну а в третьих. самим что не попробывать то? время нет?

Вы не внимательно читаете ветку, мы уже пробуем полгода.

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

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

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

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

 

[revit]

на дешовых маршрутерах (до 1500р) сделать на 100% надёжную схему врятли удасться..
на дорогих (свыше 7000р) видимо возможно.

Я даже больше скажу-что 1500 что за 7000 -разница в цене только из-за железа (мощнее проц, более скоростные интерфейсы и т.д) . Программные грабли могут быть одинаковые в обоих. Не раз попадал на такие.

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

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

 

[котяра]

Резервирование одним маршрутизатором (тп-линк 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. мож кому то и пригодится… пишу только то что сам наблюдал.

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

 

[tjx919]

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

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

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

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

 

[lms-i]

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

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

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

 

[revit]

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

Версия прошивки 1.х или 2.х?

1. При отказе основного канала Моноблок переходит на резервный канал. Когда основной канал восстанавливается - моноблок на него с резервного не возвращается!!!

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

2. Нет возможности настроить PPPoE соединение.

Это да, в некоторых случаях нужно бывает.

3. Политика безопасности отсутствует.и т.д.

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