микротик скрипт переключения каналов

Mikrotik: автоматическое переключение канала на резервный и обратно

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

Что я хотел сделать, если отключается основной канал Интернета:
1. Переключиться на резервный канал (после «появления», разумеется, вернуться на основной);
2. Отправить уведомление по email о факте изменения состояния.

Кому интересно, прошу под кат.

Нам дано:
— Mikrotik RB450G с прошивкой 5.19 версии;
— 2 порта с Интернетом, один из которых для подключения использует PPPoE соединение.

Сперва добавим 2 скрипта, один из которых будет переключать на резервный канал, а второй вернет подключение к первому.

Составим первый скрипт, который будет активировать резервный канал и назовем его «change-to-reserv» и содержать в себе код:

Следующей строкой в этом же скрипте укажем:

Переключение линии на резервный канал
Дата: jul/30/2014
Время: 10:52:13

В итоге, наш скрипт будет иметь вид (RouterOS 5.19):

И для RouterOS 6.17:

Как уже писал выше, сохраним его под именем «change-to-reserv» и приступим к написанию второго скрипта:

В отличие от первого скрипта, в теле отправляемого email-сообщения мы укажем «Переключение на основной канал» и включим раннее отключенный маршрут.
Сохраним наш скрипт под именем «change-to-main«.

Так как память у Mikrotik не резиновая, мы оптимизируем наш скрипт для выполнения поставленной задачи.
Для этого нам необходимо использование утилиты Netwatch, которая работает как тригер. То есть, если состояние подключение изменится, то сменится и статус с выполнением нужных нам скриптов.

В Netwatch мы добавим новое правило, где укажем хост 8.8.8.8 и имена скриптов во вкладках «Up» — «change-to-main» и «change-to-reserv» во вкладке «Down» соответственно.
Также следует указать период проверки состояния. У нас указана 1 минута.

Дальше следует завершающий шаг — проброс маршрута. Если этого не сделать, то скрипт сработает на переключение к резервному каналу и останется в данном положении. Обратный переход будет возможен если резервный канал «упадет».

В общем, добавляем маршрут с указанием следующих данных:
Dst. Address = 8.8.8.8 // Указываем, что будем пинговать DNS-сервер Гугла (для меня не критично, указываю его);
Gateway = pppoe-main // То самое PPPoE-соединение на основной канал
Distance = 1
Остальные параметры оставляем как есть.

Отныне принцип работы следующий:
Netwatch через основной канал будет проверять пинг до DNS-сервера Google. Как только пинг пропадет, выполнится скрипт «change-to-reserv«, указанный на вкладке «Down«. Данный скрипт отключит основной маршрут (PPPoE) и все пакеты будут идти по резервному каналу. Как только пинг по основному каналу возобновится, скрипт вновь активирует маршрут основного канала (параметр Distance которого, разумеется, «1«, а резервного — «2«). Вместе с этим будут приходить уведомления на email-адрес о фактах изменения состояния.

ВНИМАНИЕ. Для работы скриптов под управлением RouterOS 6.17 необходимо внести изменения в скрипт отправки email-адреса, а именно убрать параметр «tls=«.
То есть, наш код (например, для переключения на резервный канал) будет иметь вид:

Источник

Универсальный скрипт переключения 2-х каналов интернета Mikrotik

Около 2,5 лет назад писал статью на тему автоматического переключения канала Интернет на резервный. Скрипт, конечно, и по сей день работает «на отлично», но его внешний вид и некоторые нюансы…

Итак, встала задача улучшить скрипт, максимально устранив побочные эффекты. Что ж, приступим.

В нашем распоряжении Mikrotik RB850Gx2, для которого мы будем писать скрипт (его работоспособность также проверена на моделях RB450G и RB951G-2HnD).

Присвойте скрипту имя, например, script-check-inet

Что же будем в нем использовать?

Итак, для начала определим необходимые переменные:

где:
$firstInterface — имя нашего PPPoE-соединения основной линии связи.
$secondInterface — имя нашего Ethernet-соединения резервной линии.
$pingTo1 и $pingTo2 — IP-адреса ресурсов, которые будем «пинать».
$pingCount — количество пингов на каждый IP-адрес
$stableConnectFrom — процентное соотношение для определения «стабильности» Интернет-канала. Например, в нашем случае при потере свыше 30% пакетов пинга (`$pingStatus Создадим запись в шедулере

В поле `Name` введите имя записи, чтобы не запутаться.
Поле `Start Time` я выставил `00:00:00` для запуска ровно в полночь.
Интервал — 30 секунд
В поле `On Event` вписываем имя нашего скрипта — `script-check-inet`
И жмем «ОК».

Вот, собственно, и все!

Ниже под спойлером приведен полный код скрипта.

Так как мы ввели дополнительную переменную `$firstInterfaceName`, то удалось изменить эту конструкцию и добились работоспособности скрипта на всех перечисленных устройствах.

UPD 2

Код скрипта в очередной раз был обновлен. esudnik обратил внимание на проблему большого количества потерянных пакетов при активном подключении к сети. Таким образом, мы ввели дополнительную переменную (`stableConnectFrom`), используемую для определения процентного соотношения «качества» линии.

В примере указано значение переменной равное «70». Это значит, если процент успешно отправленных пакетов будет ниже 70%, скрипт активирует резервный канал.

UPD 3

Как заметил icCE, при использовании скрипта на прошивке 6.36rc10, выходит ошибка:

Прошивке не нравится «* 100«. Решение проблемы было простым — обрамить вычисляемые значения в дополнительные скобки, получив

Источник

MikroTik → MikroTik 2 провайдера с автоматическим переключением на резервный канал( MikroTik Failover 2 ISP )

Всех приветствую, решил написать статью, описывающую способ реализации отказоустойчивости на оборудовании Mikrotik.
В одной маленькой конторе, где я подрабатываю, из-за регулярных проблем у провайдера, задумались о подключении второго интернет канала, основного провайдера (не стабильного в последнее время) отключать не хотят, за много лет его использования тариф для фирмы не изменимся, да и скорость отличная, за те деньги + есть внешний IP и сотрудники офиса могут подключаться по VPN к офису, руководство о смене провайдера ничего слышать не хочет, это почти самый центр Москвы и с провайдерами там не очень весело.

Идея была в том что офис будет протянут новый канал и необходимо было реализовать следующую схему,
первый провайдер назовем его ISP1 (Глючный) и ISP2 (не имеет внешнего адреса только серый 10.57.ХХ.ХХ), опишу схему подробнее
ISP1 предоставляет сеть с белым IP который прилетает по DHCP, скорость 100 Мбит/с
ISP2 предоставляет сеть с серым IP адресом находящимся за NAT скорость 30 Мбит/с
Провайдер ISP2 нужен чтобы пересидеть, время недоступности основного канала, а офис мог функционировать с небольшими ограничениями.
Я пробежался по готовым статьям и не нашел того решения что меня устраивало на 100%, вот я и решил поделиться
своей наработкой с общественностью.
Я опишу свой способ, который без проблем работает как у 2х провайдеров которые выдают IP адреса по DHCP, так и у 2х провайдеров которые раздают статические адреса, как вы просчитали выше, у меня 2 сети- одна сеть конфигурируируется по DHCP, а вторая — статические адреса.
Данная схема, отработала уже более 2х лет, статистика сипользования
переключений в неделю — в среднем 3
среднее время использование резервного канала 12 мин

В качестве примера, для обозначения шлюзов я буду использовать эти, выдуманные мной адреса, вам их необходимо заменить на свои.
ISP1 шлюз 777.777.777.777
ISP2 шлюз 888.888.888.888

В качестве подготовки

Я не буду останавливаться на настройке маршрутизатора, пример настройки можно посмотреть в статье: Настройка MikroTik RouterBoard RB951G-2HnD, а перейдем сразу к делу.

Для начала переходим в меню настройки сетевых интерфейсов, интерфейс ether1 подключенный к провайдеру ISP1, мы переименуем в ether1-ISP1, чтобы было понятно за что он отвечает

Сетевой интерфейс ether2 подключен у нас к провайдеру ISP2, назовем его ether2-ISP2
Поступим с ним аналогичным образом.

Кратко опишу процесс работы по проверке работы канала и алгоритма переключения на резервный канал и обратно.
Выбираем IP адрес в интернете, с высокой степенью доступности, в качестве примера, буду использовать IP 8.8.8.8
Создаем правило фаерволла, которое разрешает прохождение пакетов только через основной канал с интерфейсом подключенным в ISP 1, в случае переключения на резервный канал, пакеты будут пытаться отправляться через новый маршрут по умолчанию, вот тут вступает правило фаерволла, которое прямо запрещает прохождение пакетов от маршрутизатора через интерфейс подключенный к ISP 2.

1 Настраиваем Firewall

Переходим в IP->Firewall и создаем правило, запрещающее отправку пакетов через ISP2

Где
Chain: output — указываем правило, которое применяется для исходящих пакетов от маршрутизатора.
Dest address: 8.8.8.8 — IP адрес, пакеты адресованные которому, будут подпадать под это правило.
ether2-ISP2 — Интерфейс, для которого применяется это правило.

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

Жмем OK и сохраняем изменения.

2 Настраиваем маршрутизацию

Переходим в IP-> Routers и видим примерно такую таблицу маршрутизации, IP основного канала ISP1 я закрасил, серыйе адреса второго провайдера я оставил.

Из скриншота мы видим что маршрутом по умолчанию 0.0.0.0/0 у нас является интерфейс подключенный к провайдеру ISP1, вот этим параметром мы и будем управлять, перенося его с одного интерфейса на другой.
Нам необходимо создать маршрут к IP 8.8.8.8 пакеты к которому, от маршрутизатора, будут идти только через ISP1

Жмем + и добавляем новый маршрут как на скришшоте

Для чего это все нужно?
Система будет проверять доступность этого IP адреса, через провайдера ISP1, если этот адрес не доступен, выполняется переключение на резервный канал, при этом система будут продолжать, с определенной периодичностью, пытаться достучаться до адреса 8.8.8.8, через провайдера ISP1. Тут возникает закономерный вопрос, а почему не проверять доступность шлюза провайдера?!
Бывают ситуации, что сеть провайдера работает нормально, а вот дальше, пакеты уже не летят, тогда не произойдет переключения на резервный канал и все будут сидеть без интернета, по этой причине необходимо проверять доступность адресов именно в глобальной сети!

3 Настраиваем Netwatch

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

Переходим во вкладку DOWN
Эта команда будет выполнена в случае недоступности IP адреса

Жмем OK, в списке у нас появится правило:

Где будет указывать интервал проверки, который мы задали, 3 мин, таймаут проверки 1000 мс или 1 сек и состояние UP, также дата и время последнего изменения состояния.

4 Тестирование

Это важный этап проверки работоспособности данной схемы!
Нам необходимо проверить работу системы переключения на резервный канал и возвращение на основной.
Нужно зайти в настройки сетевых интерфейсов Interfaces и выключить сетевой интерфейс ether1-ISP1 подключенный к ISP1
Открыв окно, netwatch, где можно наблюдать, как система запустит проверку и обнаружит что канал провайдера ISP1 не доступен, статус изменится на down и шлюзом по умолчанию, станет шлюз провайдера ISP2 888.888.888.888
На перестройку таблицы маршрутизации уходит примерно 30 сек, после этого интернет опять начинает работать. Можно зайти например на сайт 2ip.ru и увидеть что у вас IP адрес резервного провайдера.
Чтобы все вернуть обратно, просто включаем интерфейс ether1-ISP1, через 3 мин система обнаружит что доступ к IP 8.8.8.8 восстановлен и можно переключать на основной канал, сделав шлюзом, по умолчанию, шлюз провайдера ISP1 777.777.777.777
Снова заходим на 2ip.ru и видим что теперь у нас IP выданный провайдером ISP1

В общем решение получилось очень простым и за время использования, показало свою пригодность для использования.
Думаю, статью на этом можно завершить, на благодарю тех кто смог дочитать ее до конца…

Источник

Mikrotik: скрипт переключения на резервный канал интернета

Хочу поделиться своим скриптом для перехода на резервный интернет, когда основной пропадает, и возврату на основной, как только он вновь заработает. Сразу скажу, каналы доступны по-одному, никакого load-balance тут не будет. Оба канала — PPP соединения (в моем случае один проводной, второй — 3G свисток). Скрипт сделан специально как наиболее гибкое средство мониторинга, так как другие варианты, в частности check-gateway, не совсем корректны для меня.

Основной принцип прост: поднятый VPN канал не означает, что интернет через него работает. Я проверяю, пингуя несколько внешних адресов. Можно придумать, когда и пинги не являются показателем работы, но эти случаи я опускаю, в скрипте можно указать любой другой способ проверки, под ситуацию. Другие особенности: резервный канал — мобильная сеть, и он подключается только при отсутствии основного канала, в остальное время интерфейс выключен. При возврате обратно на основной канал корректно проверяется его работоспособность. Методика, отличная от пинга с указанием интерфейса. Ну и route-distance у интерфейсов меняются динамически и всегда не равны, что дает возможность одновременной работы каналов, но трафик направляется только на один из них.

При понимании можно легко переделать скрипт, если провайдеры или один из них, дает статику.

Итак, я последовательно опишу, какая настройка нужна для работы скрипта, а затем по кусочкам опишу основные моменты работы. В конце будет скрипт целиком.

Допустим, есть 2 PPP соединения ISP1 — основной, и ISP2 — резервный, оба настроены и работают по-отдельности. Выставляем на них dial-on-demand=no и add-default-route=yes, затем устанавливаем у ISP2 параметр default-route-distance на единицу больше, чем у ISP1. Настраиваем стандартные вещи, как NAT, маркировка пакетов и соединений для ответов по тому же интерфейсу, откуда пришел запрос, маршрутов для помеченных пакетов:

Также предположим, что локальный адрес роутера 192.168.xx.yy, а подсеть 192.168.xx.0/24. Эти данные, как и имена интерфейсов, нужно изменить на свои. Это не вся настройка, но обо всем по-порядку.

Определяем переменные: пишем названия интерфейсов в ifMain и ifRes, локальный адрес роутера в pingSrcAddr (далее будет понятно, зачем он нужен), и 3 внешних адреса, которые будут пинговаться для проверки канала в массив ip.

Разрешим запускаться только одной копии скрипта. Delay на случай запуска при старте RouterOS, даем время подняться соединениям.

Пропустим немного, и перейдем к основной части. Скрипт работает бесконечно, вернее, пока его не остановят или не случится ошибка. В бесконечном цикле он анализирует текущее состояние по переменной state и выполняет необходимые действия. Рассмотрим их.

Состояние 0 — когда работает основной канал. Раз в 15 секунд проверяем последовательно один из трех указанных адресов, если ответа нет — проверяем все 3 адреса. Глухо — инициируем переход на резервный канал. Тут жестко указано, что адресов в массиве — 3. Если это не так, придется подправить.

Состояние 1 — переключение каналов. Здесь важно, какие именно PPP соединения используются. В примере — ISP1 это l2tp-client, а ISP2 — ppp-client. Если другие, нужно их подправить в строках с default-route-distance.

После включения резервного канала ждем 7 секунд. Это достаточное время для меня, за которое 3G соединение поднимается. За это время текущие соединения и новые висят в таймаутах, пока основной VPN еще не разорвался, и минимизируются ответы роутера типа dest unreachable.

Звуковая индикация на любителя, может и ночью сработать. Если не нужно — убираем.

Далее основной канал отключается, его default-route-distance устанавливается на 1 больше, чем у резервного, и он включается обратно. За счет этого имеем возможность ждать возврата основного канала без помех для работы интернета через резерв.

Забегая вперед, при переходе обратно на основной канал и отключении резерва его default-route-distance снова увеличится на 1. С каждым переключением route distance у PPP соединений последовательно увеличивается. Для того, чтобы они не уходили слишком далеко, здесь проверяется текущее значение и происходит сброс на 1 при превышении 10 (цифра не имеет значения, взято для примера, теоретически максимум около 250).

Состояние 2 — ожидание восстановления основного канала. Стоит отметить, что состояние резерва не интересно. Если он не подключился, ничего не поделать, все условия для него созданы, и фактически нас интересует только основной канал.

Здесь ожидается поднятие VPN основного канала, и после этого через него при активном резерве происходят попытки пинга внешних адресов. Сделано это сложновато, но правильно. Если писать ping xx.xx.xx.xx interface=$ifMain, то по словам разработчиков, это может как работать, так и нет. Тут используется пинг с локального адреса роутера. Допускается, что он всегда есть, иначе зачем роутер нужен. Я не использовал внешний адрес основного канала, потому что провайдер его дает динамическим. Разбираемся, как же сказать роутеру посылать такие пинги через основной канал, даже когда его маршрут неактивен (route distance больше, чем у резервного):

Трафик пингов, используемый тут, является нестандартным. Это output трафик, исходящий от самого роутера на внешний адрес. Обычно, в таких случаях за src-address роутер берет адрес интерфейса, по которому уйдет пакет. Указывая локальный адрес роутера как src-address, мы как бы выносим его за тот же NAT, за которым сидит локалка. Далее, такой трафик метится с routing-mark основного канала, и пакеты идут по основному каналу за счет маршрута с меткой.

Второе правило также необходимо. Без него, если вдруг основной канал снова упадет, то пинги, даже помеченные to_ISP1, пойдут по маршруту без метки резервного канала, что приведет к некорректному возврату на основной канал. Так работает RouterOS, если канал не подключен, то маршруты, даже помеченные, отключаются. Чтобы было немного яснее, представим, что state=2, основной канал поднят, но трафик через него не идет. На пинги в таком случае уйдет 6 секунд. Так вот если в это время основной канал отключится, то пинги начнут проходить по резерву. Второе правило это исключает.

Отмечаем, что пинги в локалку с роутера не метятся и работают как обычно.

Состояние 3 — переход на основной канал. После того, как пинги по основному каналу начали проходить, достаточно выключить резервный VPN, и будет использоваться основной. Далее, меняем default-route-distance у резервного на 1 больше, чем у основного, и подаем звуковой сигнал. Обращаем внимание на тип PPP соединений, и меняем по-необходимости.

На этом цикл замыкается и происходит возврат в состояние 0.

Теперь о том, как при запуске скрипта он узнает текущее состояние:

Здесь логика также сложновата на первый взгляд. Анализируются 3 параметра: запущен ли ISP1, запущен ли ISP2, и соотношение default route distance у них. Начальные состояния 1 и 3 являются нестандартными, и говорят о неправильной настройке, но скрипт в таком случае сам все восстанавливает, пусть иногда и путем ненужных переключений.

У меня есть еще одно состояние, которое я исключил, т.к. скорее всего оно вряд ли нужно большинству. Мой ISP1 подключает VPN по имени, не по IP, для разрешения этого имени нужно использовать DNS этого же провайдера, т.к. оно разрешает в локальный адрес. И если не помочь скрипту с разрешением, указывая конкретный DNS, то даже после доступности сети ISP1 он никогда не подключится, т.к. не разрешит доменное имя, а будет продолжать использовать DNS резерва. Вот это доп. состояние:

Вместо DNSip1, DNSip2 и VPNaddress подставляем нужные данные. Все состояния ниже соответственно смещаются на +1.

Вот в принципе и все, разработано и отлажено на 6.26 и RB951G-2HnD. На других версиях — не обещаю, и простите за отсутствие ‘:’ перед командами.

В моей конфигурации в связке с этим скриптом работает еще один, который запускается по-расписанию раз в минуту. Он проверяет, запущен ли этот скрипт, ну и дополнительно отсылает мне по почте IP адрес, когда тот меняется. Вот небольшой пример, но только первой части:

Глобальной переменной можно отключить запуск скрипта Failover. Также, за счет расписания, при непредвиденных перезагрузках роутера скрипт будет автоматически запущен снова.

Источник

Mikrotik Advanced Failover: автоматическое переключение между основным каналом и 3G. Проверка основного интернет-канала и отправка SMS-уведомлений из Mikrotik

В рамках вводной публикации, опубликованной ранее, были изложены основные моменты подключения 3G-модема к маршрутизатору Mikrotik, на примере Huawei E173 и RB952Ui-2nD (hAP). Также мы рассмотрели базовые настройки для резервирования Интернет-канала. В рамках этой публикации описаны важные аспекты, касающиеся 3G модема и тарифного плана, а также процесс настройки автоматического переключения интернет-канала при отсутствии доступа к интернет-ресурсам.

Если вы еще не выбрали маршрутизатор, чтобы не растеряться во всем разнообразии Mikrotik, советуем обратить свое внимание на следующие модели: RB951Ui-2nD (hAP), 952UI-5ac2nD (hAP ac lite), RB951Ui-2HnD, RB951G-2HnD, RB962UiGS-5HacT2HnT (hAP ac). Все эти модели оснащены портом USB и позволяют подключать модемы 3G/4G. Обратите внимание, в hEX отсутствует модуль Wi-Fi. Для более требовательных подойдет RB2011 и RB3011. Эти и многие другие модели вы можете найти в интернет-магазине ASP24.

Выбор тарифа, система «My Lifecell»

Выбирая тарифный план для 3G-модема, обращайте внимание на стоимость, объем траффика и дополнительные услуги. Основное предназначение модема – доступ к Интернет, поэтому дополнительные услуги (бесплатные минуты в сети) нам попросту не нужны.

У оператора Lifecell есть специальные тарифные планы для планшетов и 3G-роутера, которые отличаются более высоким объемом включенного траффика.

Лично я выбрал тариф «3G+ Гаджет». Данный тарифный план доступен в трех вариантах, с абонплатой 49, 89 и 149 грн. в месяць. В зависимости от размера абонплаты, объем месячного траффика составляет 2, 6 или 14 Гб.

При использовании с модемом Huawei E173, этот тариф будет намного более выгодным, нежели «3G+ Смартфон». Самым выгодным тарифом является «3G+ Роутер», для которого доступно 20 Гб за 129 грн. При желании, Wi-Fi роутер также можно подключить к Mikrotik. Точнее наоборот, подключить Mikrotik к беспроводной сети роутера (CPE).

Лично мне вариант с модемом показался более интересным за счёт возможности отправки SMS прямо с Mikrotik, о чем мы поговорим чуть ниже. Первым делом нам нужно получить пароль для доступа в систему «My lifecell». Для этого, используя SIM-карту модема, необходимо отправить SMS с текстом «PAROL» на номер 123. Лично я отправлял SMS используя оригинальное приложения модема для Windows, предварительно подключив модем к ПК.

В ответном сообщении вы получите новый пароль для входа в систему. Личный кабинет My Lifecell позволяет следить за балансом и управлять дополнительными услугами.

У тарифа «3G+ Гаджет» есть небольшой минус. Все дело в том, что данный тариф предназначен в первую очередь для доступа к Интернет, поэтому стоимость 1 SMS, по-умолчанию, составляет 1 грн. Поскольку я предполагаю использование SMS-оповещений, то мне требуется дополнительный пакет SMS – не платить же по 1 гривне за каждое сообщение?

В разделе «Тарифные планы и услуги – Услуги» во вкладке «Обмен сообщениями» для тарифного плана «3G+ Гаджет» можно заказать один из трех пакетов.

Я остановился на пакете 50 SMS на неделю за 6 грн, чего должно быть более, чем достаточно для уведомлений об отключенном интернете. Если вы предполагаете отправлять больше сообщений, можно заказать 350 или 1000 сообщений на месяц с соответствующей доплатой.

«Huawei Terminal» прямо на Mikrotik?

С тарифным планом и SMS разобрались. Теперь вернемся к нашему модему Huawei E173. Для 3G-модемов доступно конфигурирование устройства через терминал с помощью AT-команд.

Вы можете скачать «Huawei Terminal» в интернете и использовать его на ПК под управлением Windows. Это бывает полезно в тех случаях, когда на модеме установлен неправильный (неподходящий) режим работы и Mikrotik его не видит. Перечень AT команд необходимо искать под определенную модель!

Если же Mikrotik видит модем, вы можете воспользоваться встроенным средством самой RouterOS. Откройте «New Terminal» и выполните команду

Обратите внимание на название порта, он должен соответствовать тому, на котором смонтировался модем в Mikrotik. Если с первой попытки подключиться не удалось, попробуйте изменить Channel в пределах 0-3. Для того, чтобы проверить, отвечает ли нам модем, можно воспользоваться командой «AT».

Ниже приведу список проверенных для Huawei E173 команд:

С помощью разных параметров можно отключать CD-ROM, карту памяти, режим сетевой карты, устанавливать приоритеты в выборе типа сети и так далее. Некоторые ресурсы советуют принудительно устанавливать режим «Только модем», якобы в этом режиме модем работает быстрее и стабильнее. Делается это командой:

Подробно останавливаться на AT-командах я не буду, в интернете вы сможете найти всю информацию самостоятельно.

Advanced Failover: настройка автоматического переключения между основным провайдером и 3G-модемом

Итак, у вас уже есть достаточно знаний для подключения модема. Пришло время настроить продвинутое автоматическое переключение. За основу взят «Универсальный скрипт переключения 2-х каналов интернета Mikrotik». Скрипт был немного усовершенствован и переработан для работы в типичной для 3G конфигурации:

Скрипт без отправки SMS и управления гостевой сетью

Скрипт с отправкой SMS и включением-отключением гостевой сети

Различия между скриптами, основные параметры

Теперь о различиях. Первый код – обычная версия скрипта, которая реализует переключение на резервный канал при отсутствии доступа к Интернет.

Вторая версия скрипта поддерживает отправку SMS-оповещений при отключении и повторном включении основного канала. Также реализовано отключение гостевой сети (Free Wi-Fi, wlan2), чтобы «гости» не расходовали ваш трафик 3G. При желании, можно wlan2 переименовать в wlan1 (основной беспроводной интерфейс), в этом случае будет отключаться основной интерфейс (например, если беспроводной сетью ваши сотрудники пользуются на смартфонах в личных целях).

Пройдемся по параметрам:

Чем больше пингов – тем более точно можно произвести настройку переключения. В данном примере всего 6 пингов, по 3 пинга на каждый адрес. Если 4 пинга из 6 пройдут – интернет считается стабильным. Сильно увеличивая количество пингов, не забудьте увеличить интервал между запусками скрипта, иначе скрипт будет перезапущен еще до завершения всех команд.

Как работает переключение между каналами

Шаг 1: скрипт производит проверку обеих каналов, если интерфейс отключен – система дает команду на его включение. Для обычного интерфейса ethernet используется задержка 2 сек, чего достаточно для получения параметров сети по DHCP. Для интерфейса модема (ppp-client) установлена задержка 8 сек, т.к. получение параметров и установка соединения занимают больше времени.

Шаг 2: скрипт ищет маршруты в интернет (0.0.0.0/0) с заданным названием интерфейса для каждого канала.

Шаг 3: скрипт проверяет Distance для маршрута основного канала. Distance основного канала статичен и всегда равен 2. Если параметр указан неверно, система назначит ему 2 автоматически.

Шаг 4: скрипт проверяет Distance для роута резервного канала. Distance может принимать значение 1 либо 3. Если параметр указан неверно, система переназначит 3 автоматически.

Шаг 5: скрипт последовательно производит пинг обеих адресов, используя основной канала. Производится расчет успешного прохождения пакетов в процентном соотношении.

Шаг 6-A: если процент успешных пакетов меньше заданного параметра, основной канал признается нерабочим, в лог Mikrotik пишется запись о «падении» основного канала. После чего выполняется проверка Distance для резервного канала, если он равен 1 – значит Mikrotik уже использует 3G и дальнейшие действия не требуются. Скрипт завершает свою работу. В противном случае, запускается цепочка:

Шаг 6-B: если процент успешных пакетов в пределах заданного лимита, система пишет в лог запись о том, что основной канал работает. После этого производится проверка Distance для резервного канала, если он не равен 3, система запускает цепочку:

Вот собственно и всё. Скрипт выбирайте тот, который больше вам подходит.

Если у вас нет гостевой сети

Если включать и отключать гостевую сеть нет необходимости, удалите из скрипта 3 следующие фрагмента:

Настройка отправки SMS

Отправка SMS осуществляется через 3G-модем стандартными средствами Mikrotik

Если SMS не отправляется, проверьте наличие денег на счету. Если деньги есть, но SMS не отправляется – попробуйте изменить channel=2 в диапазоне 0-3 (актуально для других модемов). Вместо +380931234567 не забудьте указать ваш номер в международном формате. Текст сообщений правится в message=»».

Обратите внимание! Кириллица не поддерживается!

Как добавить скрипт в Mikrotik?

Для того, чтобы добавить скрипт, необходимо вызвать System – Scripts. В появившемся окне нажимаем синий плюс. Появится новое окошко «New Script». В «Name» указываем желаемое название скрипта, например «Failover» (англ. обработка при отказе); в «Source» вставляем код скрипта. Нажимаем ОК.

Далее необходимо запустить планировщик и задать интервал запуска скрипта. Вызываем System – Scheduler, создаем новое задание (New Schedule). Название можно указать любое, в «Start Time» выбираем «startup» (при запуске), после чего указываем интервал, например 30 сек.

Анализируем логи Mikrotik

Для того, чтобы проверить корректность работы скрипта, откройте «Log». В штатном режиме, когда основной канал работает, вы увидите в логах соответствующие периодические записи. Для удобства они имеют статус «warning» (предупреждение), из-за чего выделяются синим цветом.

При отказе основного канала, вы увидите в логах запись, выделенную красным (статус error), а также все последующие действия скрипта.

После каждого цикла скрипта, в логах должна присутствовать запись «End ping», если этой записи нет – скрипт выполнился не до конца.

В заключение

Скрипт не анализирует резервный канал на предмет доступа в Интернет, т.к. особой пользы от этого лично я не вижу. Если вам требуется обработка – вы можете дописать её самостоятельно, например, добавив в неё принудительную перезагрузку модема. Если Интернет на модеме не работает, всё же есть вероятность того, что SMS работает и у вас получится еще отправить SMS-уведомление об отказе.

Видеокурс «Настройка оборудования MikroTik» (аналог MTCNA)

Учитесь работать с MikroTik? Рекомендую видеокурс «Настройка оборудования MikroTik». В курсе разобраны все темы из официальной учебной программы MTCNA и много дополнительного материала. Курс сочетает теоретическую часть и практику – настройку маршрутизатора по техническому заданию. Консультации по заданиям курса ведет его автор Дмитрий Скоромнов. Подойдет и для первого знакомства с оборудованием MikroTik, и для систематизации знаний опытным специалистам.

Источник