Ререзвирование канала на Mikrotik

Механизм резервирования основного канала, при наличии второго (например, 3G или ADSL), на Mikrotik можно организовать по разному. Существует возможность сделать все без скриптов, но с некоторыми ограничениями, так же можно сделать многоуровневую проверку в скрипте и поставить это скрипт в планировщик (или использовать Tools / Netwatch).

Исходные данные.

net_scheme

Варианты сбоя основного канала:

net_fail

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

QIP Shot - Screen 132

 

При недоступности шлюза основного канала, Микротик направит пакеты через резервный.

При возникновении второго варианта, микротик будет “думать” что все хорошо (ping до шлюза проходит) и будет слать все пакеты через него. Поэтому решать проблему необходимо шире, в чем помогут скрипты.

Преамбула

Если вы настраиваете маршрутизатор удаленно помните: “Удаленная настройка Firewall – к выезду”. Поэтому не забывайте нажать кнопку Safe Mode в Winbox. Этот механизм отменит все изменения с момента активации режима Safe Mode, в случае если ваша сессия Winbox отвалится.

Маршруты

В своем решении я не меняю метрики маршрутов а просто включаю/отключаю резервный маршрут, который имеет меньшую метрику чем основной канал.

Первым делом регистрируем маршруты (IP / Routes) для контрольных точек с метрикой (distance) = 1. Это необходимо чтобы к указанным контрольным точками трафик шел только через основного провайдера.

QIP Shot - Screen 128

аналогично по второй контрольной точке.

У меня две контрольные точки: 1. коммутатор провайдера (10.0.0.1), которые я пингую оперативно (каждую секунду), 2.  внешний надежный сервер (77.88.8.1), по которому проверяю что инфраструктура провайдера работает, но не работает канал провайдера (раз в 30 секунд, т.к. это значительно реже).

Далее меняем основные метрики каналов на 3 (distance = 3).

QIP Shot - Screen 129

Далее добавляем отключенный (disable) маршрут 0.0.0.0/0 с метрикой 2 с шлюзом резервного канала. Именно этот маршрут мы будем включать или отключать.

Комментарий “Overrided” понадобится нам для того чтобы идентифицировать маршрут.

В итоге::

  1. Созданы маршруты с приоритетом 1 для контрольных точек, которые доступны только для основного канала;
  2. Созданы маршруты с приоритетом 2 для резервного канала, включив который мы пустим весь трафик через резервный канал. Т.к. приоритет маршрутов контрольных точек выше, чем резервного канала, доступ к ним будет все равно осуществляться только через основной канал;
  3. Маршруты 0.0.0.0/0 (оба) перемещены на приоритет 3, чтобы при нормальном режиме (отключенным резервирующим маршрутом), трафик обрабатывался с обоих каналов.

Контроль доступности контрольных точек

Для проверки доступности используем Netwatch. Создаем их 2 штуки (Tools / Netwatch):

  1. Каждую секунду проверяет доступность коммутатора/шлюза провайдера:
    QIP Shot - Screen 130
    с UP скриптом:

    с DOWN скриптом:

    Down скрипт первым делом проверят ping до коммутатора еще раз (4-мя пакетами), в случае если дополнительная проверка маршрута до провайдера подтвердила пропажу сигнала (checkip = 0), то скрипт ищет маршруты с комментарием “Overrided” и включает их. Т.к. при отсутсвии доступа к коммутатору провайдера смысла проверять доступ к Интернет (77.88.8.1) смысла не имеет, отключаем Netwatch 2.
  2. Доступность IP в интернет.
    QIP Shot - Screen 131
    UP скрипт:

    Down скрипт:

    Скрипты работают по схожей логике с первым Netwatch.

Контрольные тесты

Сценарий 1. Все нормально.

Netwatch 1 =  OK -> Включаем основной канал ->  Включаем Netwatch 2 -> Netwatch 2 = OK -> Резервный канал отключен.

Сценарий 2. Шлюз доступен, но интернет не работает (сбой выше провайдера).

Netwatch 1 =  OK ->  Включаем Netwatch 2 -> Netwatch 2 = FAIL -> Резеврный канал включен.

Сценарий 3. Шлюз не доступен.

Netwatch 1 =  FAIL ->  Выключаем Netwatch 2 -> Резеврный канал включен.

Заключение

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

Использование netwatch упрощает скрипты, т.к. они работают не периодически (через Scheduler), а по событиям “On down”/ “On up”.

5 мыслей о “Ререзвирование канала на Mikrotik”

    1. Я изучал данную статью и отбросил ее т.к. не захотел нагружать таблицу маршрутизации такими костылями. Скрипты работают очевиднее и информативнее.

  1. использовать рекурсивный маршрут
    /ip route
    add check-gateway=ping distance=10 gateway=8.8.4.4 scope=40 target-scope=30 где target-scope это scope основного маршрута.

  2. В скрипте указана ссылка на комент [find comment=”Internet”]. К чему относится комментарий “Internet”?

    1. К тому что левее – /tool netwatch, – это netwatch который следит за коннектом к Интернет.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.