[delphi_night]

Здравствуйте. Есть задача особого назначение. Нестандартная ситуация. Для решения задачи резервирования клиентского соединения по каналу 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

 

Будут еще задачи по микротику.

[Constantin]

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

в противном случае нуна писать скрипты на проверку доступности ресурса через каждый шлюз......

на МТ это делается, примеры нужно в сети искать их есть и не мало

[delphi_night]

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

в противном случае нуна писать скрипты на проверку доступности ресурса через каждый шлюз......

на МТ это делается, примеры нужно в сети искать их есть и не мало

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

[ChargeSet]

вот есть очень хороший мануал

[Constantin]

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

/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 это и есть метрика

[Saab95]

Кроме метрики можно завернуть весь интернет по OSPF на адрес шлюза, исключив из него адрес маршрутизатора, на который удаленное устройство через интернет подключается. Не фильтром с маршрутом 0.0.0.0/0, а именно проанонсив сети, умело играя с масками, можно все провернуть 20-30 записями.

[delphi_night]

Можно ли здесь на кого-то рассчитывать в плане платы за полноценный скрипт, сделанный по моему ТЗ. Я проверил варианты и чувствую, что скрипт более полноценно решает, потому что кроме проверки активности шлюза, часто нужно перезапускать DHCP, потому что маршрутизатор может сбросить клиента, а микротики не всегда это понимают. Есть и некоторые другие ньюансы. Работа удаленная.

[Constantin]

а при чем тут DHCP ????

[delphi_night]

а при чем тут DHCP ????

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

[Constantin]

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

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

 

или я чего то не понимаю