delphi_night Posted February 28, 2014 Posted February 28, 2014 Здравствуйте. Есть задача особого назначение. Нестандартная ситуация. Для решения задачи резервирования клиентского соединения по каналу wifi (routerboard используется как клиент к беспроводным сетям) была выбрана плата 411UAHR Mikrotik. Задача состоит следующая: необходимо обеспечить взаиморезервирование желательно с выбором наилучшего канала связи среди 2-3 интерфейсов (1 wlan - основной, 2 - wlan - резервный для wifi, 3 - lte - крайнее резервирование на случай отказа местной wifi сети). Планировалось использовать бондинг, но: 1. Не добавляется LTE 2. Ломаются DHCP клиенты на wlan 1,2. Не выдается адрес либо только на одном, либо сразу на обоих. Если отключить бондинг, то все начинает работать. 3. Оказалось, что бондинг микротика это не совсем бондинг и на той стороне должен быть тоже бондинг, но у нас обратная сторона - это wi-fi сеть провайдера с произвольным оборудованием. Все адреса в сети должны быть получены с помощью DHCP на всех интерфейсах. Использование статических адресов не допускается. Адреса шлюзов по умолчанию тоже неизвестны. Вся информация о сети получается из DHCP. Допускается использовать public DNS. Всю первичную настройку провел (NAT, client and server DHCP, security profiles, wireless connections). Работает, маршруты верные, Интернет есть, Клиент подключается к плате через Ethernet. Необходимо предложить решение такой задачи. В наличии есть свои серверы, публичные адреса. Время смены маршрута - не более 8 секунд Кто готов сделать под ключ с консультацией, оформлением в виде консольных команд списком с комментариями и объяснением возможных способов с демонстрацией - платно с моей стороны. Работа через тимвьювер, можно подъехать в офис. Москва, М. Измайловская. Пока актуально до Воскресения. Предложения можно сюда или на телефон 89629110374. Почта delphi_night@rambler.ru Будут еще задачи по микротику. Вставить ник Quote
Constantin Posted February 28, 2014 Posted February 28, 2014 это все делается метрикой в машруте по умолчанию, если конечно инет не будет падать где то дальше шлюза в противном случае нуна писать скрипты на проверку доступности ресурса через каждый шлюз...... на МТ это делается, примеры нужно в сети искать их есть и не мало Вставить ник Quote
delphi_night Posted February 28, 2014 Author Posted February 28, 2014 это все делается метрикой в машруте по умолчанию, если конечно инет не будет падать где то дальше шлюза в противном случае нуна писать скрипты на проверку доступности ресурса через каждый шлюз...... на МТ это делается, примеры нужно в сети искать их есть и не мало Спасибо. Не могли бы вы более подробно рассказать про метрику. Раньше в таких случаях у нас работал скрипт, он пинговал интерфейсы и определял признак неактивности, затем брал адрес на другом и менял параметры подключения (маршруты). Вставить ник Quote
ChargeSet Posted February 28, 2014 Posted February 28, 2014 вот есть очень хороший мануал Вставить ник Quote
Constantin Posted March 1, 2014 Posted March 1, 2014 Спасибо. Не могли бы вы более подробно рассказать про метрику. Раньше в таких случаях у нас работал скрипт, он пинговал интерфейсы и определял признак неактивности, затем брал адрес на другом и менял параметры подключения (маршруты). /ip route add check-gateway=ping distance=1 dst-address=0.0.0.0/0 gateway=pppoe-out1 add check-gateway=ping distance=2 dst-address=0.0.0.0/0 gateway=pppoe-out2 осмыслите...... где distance это и есть метрика Вставить ник Quote
Saab95 Posted March 1, 2014 Posted March 1, 2014 Кроме метрики можно завернуть весь интернет по OSPF на адрес шлюза, исключив из него адрес маршрутизатора, на который удаленное устройство через интернет подключается. Не фильтром с маршрутом 0.0.0.0/0, а именно проанонсив сети, умело играя с масками, можно все провернуть 20-30 записями. Вставить ник Quote
delphi_night Posted March 1, 2014 Author Posted March 1, 2014 Можно ли здесь на кого-то рассчитывать в плане платы за полноценный скрипт, сделанный по моему ТЗ. Я проверил варианты и чувствую, что скрипт более полноценно решает, потому что кроме проверки активности шлюза, часто нужно перезапускать DHCP, потому что маршрутизатор может сбросить клиента, а микротики не всегда это понимают. Есть и некоторые другие ньюансы. Работа удаленная. Вставить ник Quote
delphi_night Posted March 2, 2014 Author Posted March 2, 2014 а при чем тут DHCP ???? Дело в том, что когда шлюз становится неактивным, то это не всегда проблема выше. По нашему опыту часто на маршрутизаторах стоит маленькое время релиза адреса DHCP и маршрутизатор "забывает" этот узел в сети. Помогает повторное DHCP, которое сам микротик делает не всегда, точнее не со всеми роутерами. Эта проблема проявляется, когда беспроводное соединение активно сутками на пролет. Вставить ник Quote
Constantin Posted March 2, 2014 Posted March 2, 2014 По нашему опыту часто на маршрутизаторах стоит маленькое время релиза адреса DHCP и маршрутизатор "забывает" этот узел в сети. Помогает повторное DHCP, что то вы путаете, шлюз то не меняется....ну можно поставить в планировщик раз сутки дергать dhcp клиента.... или я чего то не понимаю Вставить ник Quote
.png.5d2afa2996cc6a85d0f2c09b92dd0a28.png)
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.