Наш сайт использует файлы cookies, чтобы улучшить работу и повысить эффективность сайта. Продолжая работу с сайтом, вы соглашаетесь с использованием нами cookies и политикой конфиденциальности.

Статьи

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

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

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

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

net_scheme.png


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

net_fail.png

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

QIP-Shot-Screen-132.png

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

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

Преамбула

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

Маршруты

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

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

QIP-Shot-Screen-128.png

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

/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).

QIP-Shot-Screen-129.png

Далее добавляем отключенный (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):

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

QIP-Shot-Screen-130.png

с 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 в интернет.

QIP-Shot-Screen-131.png

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”



Возврат к списку