Резервирование одним маршрутизатором |
Здравствуйте, гость ( Вход | Регистрация )
Резервирование одним маршрутизатором |
pavel |
21.2.2013, 19:37
Сообщение
#1
|
Участник Группа: Пользователи Сообщений: 34 Регистрация: 31.10.2011 Пользователь №: 6 565 |
Приветствую.
Резервирование УМ с использованием двух маршрутизаторов прекрасно описана ЛКДС и прекрасно работает. Но, хотим сделать резервирование не плодя на каждой УМ по 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, то канал интернета на маршрутизаторе переключается, а связь КСЛ (Моноблока) с Диспетчерской - НЕТ. Смотрел соединения на маршрутизаторе: КСЛ постоянно пробовал соединиться с резервным адресом диспетчерской... и только после перезагрузки (иногда ни одной) маршрутизатора и/или КСЛ связь восстанавливалась. Причем это наблюдалось в обе стороны: при переключении на резерв и с резерва на основной канал. Подскажите, у кого-нибудь такая схема с одним маршрутизатором на УМ работает? На чем? |
котяра |
27.3.2013, 16:02
Сообщение
#2
|
Активист Группа: Пользователи Сообщений: 1 191 Регистрация: 21.2.2008 Пользователь №: 2 780 |
вот достала тема. весь день на неё угробил, только для чего сам не пойму... а время не резиновое..
собрал на столе конструкцию... 1. моноблок с 3 подключёными блоками 2. маршрутер с поддержкой WAN и 3G 3. проводной и "свисток" имели статические IP-адреса. 4. на ноуте создал ПКСЛ через 3g-модем (статика). прописал как положено всё... 5. настроек минимум указал (я ж не "сетевик" мне чем попроще тем лучше) одним словом. с TP-Link 3420 заработало... на столе... буду юзать дальше... |
lms-i |
27.3.2013, 17:46
Сообщение
#3
|
Участник Группа: Пользователи Сообщений: 50 Регистрация: 13.5.2008 Пользователь №: 2 992 |
вот достала тема. Конечно достала, зачем ее и открыли. Я вот мужики одного не пойму, в каком сегменте отрасли вы работаете. Ведь хоть с DSL, хоть со Скайлинком, хоть с Мегафоном, хоть с оптикой, да хоть с чем могут быть проблемы. Я повторюсь: отключения питания, аварии на оборудовании провайдера (у всех были), плановые технические отключения - это все присутствует в нашей жизни, этого не избежать. Так вот про сегмент. Мне не понятно, почему то вас особо не беспокоит отсутствие связи с удаленным УМ. То ли вы не сталкиваетесь с этим непосредственно; то ли не отвечаете за это напрямую; то ли у вас служба налажена с таким давлением на Заказчика, что мол мы крутые, нет связи - "ну такие дела" мы не причем и все, ждем пока наладится; то ли конкуренции нет; то ли идеальные услуги провайдер предоставляет и ни одного перебоя нет; то ли начальству по барабану кто там застрянет - сам вылезет. Честно, ей богу, мне не понятно... Мы пытаемся найти понимание на форуме, а получается "требуем фигню", нас еще и дураками пытаются обозвать. Ну мы же не из пальца высосали эту проблему. Если у вас нет такой ситуации, то это не значит что в других городах так же. По каким то причинам народ не беспокоится. Но поверьте, рано или поздно поднимется вопрос о повышении надежности и качества. Кто то поддерживает идею, а кто то и стесняется согласиться, а кто то подводные камни ищет. Мы за здоровый диалог и надо подумать хорошо прежде чем критиковать. Разработчики конечно смотрят на это отчасти с непониманием - "вот пристали"...Но им не ходить в прокуратуру, почему бабуля прибралась и т.д. А кто хоть раз там был (в прокуратуре) тот поймет, и каждый раз при отсутствии связи будет нервничать. Все эти нервы увеличиваются с количеством УМ. Начинают припарки предлагать. Поставьте две железки, поставьте УПП. Зачем городульки городить. Пытаемся оптимизировать и упростить схему. Обратите внимание на проблему, мы не просим завтра ее решить. Пытаемся уровень приподнять. Ведь вы поставляете продукцию и на запад. Мне кажется европейские специалисты усмехнуться и спросят зачем две железки, почему нельзя реализовать одну? УПП не плохая вещь, на не в этом случае. Что касается сохранности и диагностики УМ - все это фигня, если захотеть можно все организовать. Персонал который заходит в МП можно четко отследить, опять же при желании. Также этот персонал можно обязать проверять и наличие свистка, и проверить резерв (выдернув шнурок). Ведь кто-то ходит по МП с определенной периодичностью. Тут дело организации - это не есть проблема. Платить дополнительно 150 руб в месяц за точку и быть спокойным - мы согласны, нервы дороже и бензин и труд (если придется туда ехать). Порой и Заказчик даже это понимает, он согласен платить за второго провайдера, лишь бы надежнее было. Я просто две ветки почитал и расстроился если честно. Мне на семинаре в июле 2012 в Бердске всё казалось таким светлым и дружным. А оказывается не так все и светло. С пониманием туго. Но энтузиасты пока есть!!! ))) Котяра, я надеюсь проверял преключение на 3G при отключении WAN? И что значит заработало, на ЦД выводил? Очень интересно чем эксперимент закончится. revit, в нескольких диспетчерских стоят свистки, роутер там ставить не резонно. |
revit |
28.3.2013, 10:38
Сообщение
#4
|
Активист Группа: Пользователи Сообщений: 6 658 Регистрация: 7.2.2006 Из: г. Ростов-на-Дону Пользователь №: 3 |
revit, в нескольких диспетчерских стоят свистки, роутер там ставить не резонно. -------------------- Я не понял Вашего вопроса, но я Вам на него отвечу.....
Лень-психоматический признак исправности выработанного за годы эволюции механизма интуитивного распознавания безсмысленности выполняемой задачи. |
lms-i |
28.3.2013, 10:50
Сообщение
#5
|
Участник Группа: Пользователи Сообщений: 50 Регистрация: 13.5.2008 Пользователь №: 2 992 |
|
Gaff |
28.3.2013, 11:24
Сообщение
#6
|
Активный участник Группа: Пользователи Сообщений: 252 Регистрация: 30.1.2011 Из: Тюмень Пользователь №: 5 789 |
lms-i, наконец-то начался конструктивный разговор, а не просто крики с просьбами сделать что-нибудь)))
По мегафону, да у нас в регионе (именно у нас) лидер и работает стабильно, у Вас может быть все абсолютно наоборот, поэтому однозначно говорить что обязательно используйте не буду. А по поводу резервов именно на Очень удаленных объектах, это разумеется необходимо, особенно если нет людей способных перезапустить оборудование (не хорошо это, но сбои бывают во всем), ведь если частые сбои, то действительно не наездишься. УПП пока еще вообще ни разу не использовал, мысли были, но смог и так все отладить. А вот такие очень удаленные объекты это уже частный случай, там действительно возможны варианты приобретения оборудования и оплаты интернет заказчиком, но у нас пока, но отмечу что ПОКА, такого не было. Удаленные объекты у нас имеют как правило свой штат лифтеров, и это административные здания, где к лифтам относятся бережно. Я уверен, что со временем и у нас может возникнуть необходимость в резерве, а сейчас я не готов ответить на Ваш опрос ни да ни нет, т.к. во первых нет острой необходимости, во вторых, не понятно как на нашей компании отразятся изменения и в третьих, разработчики не сказали свое слово, может быть на их взгляд действительно проблемы есть, но заключается в чем то другом, а может измения как то повлияют на безопасность протокола, ну или еще что-то в этом роде. Вообщем, предлагаю просто дождаться что скажут разработчики и совместно решить эту проблему, если таковая имеется. |
pavel |
28.3.2013, 12:12
Сообщение
#7
|
Участник Группа: Пользователи Сообщений: 34 Регистрация: 31.10.2011 Пользователь №: 6 565 |
Коллеги, разработчики! Проблема решена! Всё оказалось очень просто. Жаль только, что пришлось потратить столько сил и времени. Доказывать наличие проблемы разработчикам и т.д.
В общем проблема действительно записями в таблице 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
Сообщение
#8
|
Модератор Группа: Главные администраторы Сообщений: 10 691 Регистрация: 7.2.2006 Из: Новосибирск Пользователь №: 2 |
Главное, чтобы параметр "Ожидание подтверждения связи" КСЛ/Моноблока был больше, чем таймаут UDP соединений в маршрутизаторе. Чтобы запись в таблице NAT успела сброситься. Если бы все было так безоблачно... Я же вам в прошлом своем посте писал...Попробую разжевать. Выставили вы 1 с в роутере. В КСЛ'е 2 с. И, в придачу к этому, имеете прохождение запрос/ответ более 1 с. Что в этом случае произойдет? Догадались? Или дальше объяснять? Вы, попросту, не получите соединения вообще. КСЛ пошлет пакет - будет установлено соответствие источник-получатель-параметры_маршрута. Через 1 с это соответствие сбросится, а ответный пакет придет на 0,5 с позднее. КСЛ бы его принял (таймаут стоит 2 с), ба вот роутер уже не будет знать, что с этим пакетом делать... и попросту сбросит его. Связи не будет. |
pavel |
28.3.2013, 13:12
Сообщение
#9
|
Участник Группа: Пользователи Сообщений: 34 Регистрация: 31.10.2011 Пользователь №: 6 565 |
Если бы все было так безоблачно... Александр, я же учел Вашу критику: Цитата на 5 секунд. Оба, потому что не разбирался пока в какой попадет обмен Оби. Далее заходим в КСЛ/Моноблок и ставим в окне Адреса связи параметр "Время ожидания подтверждения связи" в 10 секунд. Да и потом. На обратное прохождение пакета это никак не повлияет, т.к. на маршрутизаторе проброшены порты 44000 и 44001 на КСЛ. Так что, когда прилетает пакет снаружи, маршрутизатор не смотрит таблицу NAT. Вот если их не пробросить... Мой предыдущий пост - это не гипотеза. Я проверил всё именно на том УМ, на котором ранее неработала связь с КСЛ с использованием трех маршрутизаторов. И туда и обратно замечательно переключается всё и работает. С Микротиком |
Александр Смышляев |
28.3.2013, 15:03
Сообщение
#10
|
Модератор Группа: Главные администраторы Сообщений: 10 691 Регистрация: 7.2.2006 Из: Новосибирск Пользователь №: 2 |
Александр, я же учел Вашу критику: Простите, как-то между глаз попало 5 сек...Да и потом. На обратное прохождение пакета это никак не повлияет, т.к. на маршрутизаторе проброшены порты 44000 и 44001 на КСЛ. Так что, когда прилетает пакет снаружи, маршрутизатор не смотрит таблицу NAT. Так ведь таблица NAT строится с учетом этого правила. Если правило(а) прописаны, то пакет выходит из роутера в WAN не абы от какого порта, а от того, который соответствует правилам. Если нет проброса портов, то и пакет вылетает с произвольным портом. Исходя из этого таблица NAT вообще, вроде, ни при чем... если только в ней не фигурирует еще и WAN интерфейс (достоверно судить не могу - как предположение). |
Текстовая версия | Сейчас: 29.3.2024, 6:28 |