Статьи

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

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

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

Преамбула

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

Маршруты

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

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

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

/ip route add distance=1 dst-address=10.0.0.1/32 gateway=<primary_chanel>
/ip route add distance=1 dst-address=77.88.8.1/32 gateway=<primary_chanel>

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

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

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

/ip route add comment=Overrided disabled=yes distance=2 gateway=<reserve_gateway>

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

В итоге:

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

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

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

Каждую секунду проверяет доступность коммутатора/шлюза провайдера:

с UP скриптом:

:local rulestate
:set rulestate [/ip route get [find comment="Overrided"] disable];
:if (rulestate = false) do={
     /tool netwatch enable [find comment="Internet"]
     /ip route disable [find comment="Overrided"]
     /log info "Switch to primary connection"
}

с DOWN скриптом:

/log warning "Primary gateway fail... testing..."
:local checkip [/ping 10.0.0.1 count=4]
:if (checkip = 0) do={
      :local rulestate
      :set rulestate [/ip route get [find comment="Overrided"] disable];
      :if (rulestate = true) do={
            /tool netwatch disable [find comment="Internet"]
            /ip route enable [find comment="Overrided"]
            /log error "Switch to backup connection"
       }

}
:if (checkip > 0) do={
    /log warning "secondary test - OK"
            /tool netwatch enable [find comment="Internet"]
}

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

UP скрипт:

:local rulestate
:set rulestate [/ip route get [find comment="Overrided"] disable];
:if (rulestate = false) do={
     /ip route disable [find comment="Overrided"]
     /log error "Primary connection restored (Internet)"
}

Down скрипт:

/log warning "Internet test fail..."
:local checkip [/ping 77.88.8.1 count=3]
:if (checkip = 0) do={
      /log error "Internet fail (secondary test)"
      :local rulestate
      :set rulestate [/ip route get [find comment="Overrided"] disable];
      :if (rulestate = true) do={
            /ip route enable [find comment="Overrided"]
            /log error "Switch to backup connection (not Internet connection)"
       }
}
:if (checkip > 0) do={
    /log warning "secondary Internet test - OK"
}

Скрипты работают по схожей логике с первым 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”