Failover Mikrotik без скриптов: рекурсивные маршруты.

  Подниму заезженную тему. Смотрел прямую трансляцию с MikroTik User Meeting (Moscow, Russia, September 30 - October 01, 2016) и там один докладчик рассказывал как он не любит писать скрипты и старается использовать функционал RouterOS без них. В докладе, кроме всего прочего, говорилось про рекурсивные маршруты для использования в качестве failover. Вспомнил теплое ламповое время когда я использовать такой вариант файловера и решил написать про это. Довольно интересное решение, которое было изобретено для Mikrotik в 2010 году.
  Допустим у нас есть несколько внешних провайдеров. При пропадании одного интернета-переключаемся на резервный, при возобновлении первого - переключаемся назад. Есть несколько вариантов решения.
  Первый - использование check-gateway=ping:

  Настройка существует прямо в вашем главном маршруте, она означает буквально следующее - "если основной шлюз недоступен - отключаем маршрут". Я думаю не нужно объяснять что эта штука работает только до основного шлюза нашего провайдера, но если проблемы после шлюза - ничего не переключится.
  Второй - использование скриптов. На нем останавливаться не буду - есть написанная статья.
  Третий, комбинированный - использование NetWatch и небольшого скрипта. В NetWatch прописываем какой-то хост, при пропадании пинга на него - выполняем скрипт. Это вариант я не использую, и вам не рекомендую. Лично я считаю, что NetWatch, в том состоянии, в котором он существует в Mikrotik, особо не работоспособен.
  Ну и наконец четвертый метод - использование рекурсивных маршрутов. Два внешних провайдера, на каждый из них нужно поставить по статическому маршруту который ведет на основной шлюз. Если вы получаете интернет, допустим, через PPPoE, то нужно снять галку Add Default Route и прописать маршрут вручную на шлюз подсмотренный в динамическом маршруте.

  Стоит сказать, что динамические маршруты имеют метрику 0, в то время - минимальная метрика для статических маршрутов - 1.
  Простой пример рекурсивного маршрута:

/ip route
add check-gateway=ping distance=1 gateway=8.8.8.8
add distance=1 dst-address=8.8.8.8/32 gateway=172.16.39.254 scope=10

  Где 8.8.8.8 -проверочный хост, который мы мониторим посредством пинга. 172.16.39.254 - основной шлюз нашей сети.

  Теперь непосредственно к файловеру. Допустим есть у нас два WAN. Трафик который идет от наших клиентов к провайдеру 1 промаркирован ISP1 (основной шлюз GW1), ко второму - ISP2 (основной шлюз GW2). Мы будем следить за HOST1 через GW1, за HOST2 через GW2. HOST1 и HOST2 -  могут быть любые ресурсы в интернет с отличной доступностью, именно на основе их работоспособности мы будет понимать работает наш интернет или нет.

  Добавим маршруты для наших проверочных хостов:

/ip route
add dst-address=Host1 gateway=GW1 scope=10
add dst-address=Host2 gateway=GW2 scope=10

  Теперь создадим рекурсивные маршруты для первого провайдера с разными дистанциями:

/ip route
add distance=1 gateway=Host1 routing-mark=ISP1 check-gateway=ping
add distance=2 gateway=Host2 routing-mark=ISP1 check-gateway=ping

  И для второго провайдера:

/ip route
add distance=1 gateway=Host2 routing-mark=ISP2 check-gateway=ping
add distance=2 gateway=Host1 routing-mark=ISP2 check-gateway=ping

  Эти маршруты будут разрешены рекурсивно, и активен будет тот маршрут, удаленный хост которого будет пинговаться. Если убрать с маршрутов routing-mark - маршрут станет основным для маршрутизатора.

  Как мы видим, в такой реализации проверяется только один внешний хост на каждый провайдер, что может быть не информативно. Желательно использовать несколько хостов. Далее будет реализация где мы будем контролировать два внешних хоста: Host1A и Host1B через GW1; Host2A и Host2B через GW2.

  Как и в предыдущей реализации вводим маршруты для наших хостов:

/ip route
add dst-address=Host1A gateway=GW1 scope=10
add dst-address=Host1B gateway=GW1 scope=10
add dst-address=Host2A gateway=GW2 scope=10
add dst-address=Host2B gateway=GW2 scope=10

  Нам нужно ввести дополнительные IP для промежуточных маршрутов. Для примера используем 10.1.1.1 и 10.2.2.2 (подсети IP-адресов не должны быть использованы в вашей сети):

/ip route
add dst-address=10.1.1.1 gateway=Host1A scope=10 target-scope=10 check-gateway=ping
add dst-address=10.1.1.1 gateway=Host1B scope=10 target-scope=10 check-gateway=ping
add dst-address=10.2.2.2 gateway=Host2A scope=10 target-scope=10 check-gateway=ping
add dst-address=10.2.2.2 gateway=Host2B scope=10 target-scope=10 check-gateway=ping

  Теперь добавляем маршруты по-умолчанию для наших клиентов:

/ip route
add distance=1 gateway=10.1.1.1 routing-mark=ISP1
add distance=2 gateway=10.2.2.2 routing-mark=ISP1
add distance=1 gateway=10.2.2.2 routing-mark=ISP2
add distance=2 gateway=10.1.1.1 routing-mark=ISP2

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

Источник

http://wiki.mikrotik.com/wiki/Advanced_Routing_Failover_without_Scripting

Подписаться на новые статьи.