Настройка резервной интернет линии на роутере MikroTik RB2011UiAS-2HnD-IN

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

В данной инструкции мы рассмотрим пример настройки двух Интернет-каналов одновременно на роутере Mikrotik с целью отказоустойчивости — при разрыве соединения основной канал будет меняться на резервный. В нашем случае будет задействован один WAN Ethernet, второй — LTE. Итого, два провайдера и две сети.

Есть два способа настройки отказоустойчивости:

1. Настройка балансировки между шлюзами (разные приоритеты для интерфейсов). Данный метод можно использовать, если у нас оба провайдера предоставляют настройки со статическим адресом шлюза. Настройка выполняется без скриптов через конфигурирование нескольких шлюзов с разным весом.
2. Проверка доступности основного Интернет-канала и переключение на резервный при наличии проблем. Это универсальный метод настройки отказоустойчивости. Для настройки используется утилита Netwatch, которая выполняет скрипт проверки и, при необходимости, смены основного шлюза для доступа к сети Интернет.

Мы рассмотрим оба варианта. Настройки выполним в программе winbox. Настройка в веб-интерфейсе аналогична.

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

Маршруты с разным приоритетом

Раскрываем в меню IP:

. и переходим в Routes:

Добавляем 2 маршрута. Первый через одного Интернет провайдера со следующими настройками:

* мы указываем шлюз от нашего провайдера (в данном примере 1.1.1.1), задаем настройку проверки шлюза (Check Gateway) с помощью утилиты ping, задаем приоритет (Distance 10).

Для второго провайдера мы задаем, практически, аналогичные настройки:

* обратите внимание, что в отличие от первого маршрута, в данном указана большая дистанция и другой шлюз (для второго провайдера).

После удаляем старые маршруты. Должны остаться только те, что мы добавили.

Использование сценария, запускаемого в Netwatch

Данный метод поможет настроить резервирование канала, если один из провайдеров выдает динамические адреса в разных подсетях, например, подключение через 4G-модем.

1. Задаем описания

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

Раскрываем в меню IP:

. и переходим в Routes:

2. Настраиваем узел для проверки канала

Мы настроим узел, который будет пинговать провайдер 1. Если пинг пропадает, то необходимо переключать активный Интернет-канал на провайдера 2. Также мы должны заблокировать возможность пинговать проверочный узел с провайдера 2.

И так, переходим к настройке маршрутов:

Добавляем новый маршрут к проверочному узлу, например 77.88.8.2 (DNS Яндекса):

* в данной настройке мы задали маршрут к проверочному узлу через шлюз 1.1.1.1 (в нашем примере это шлюз от провайдера 1).

Переходим в IP — Firewall:

Создаем новое правило для запрета пинга проверочного узла через провайдера номер 2:

. в качестве действия выбираем drop:

3. Настройка задания в Netwatch

Переходим в Tools — Netwatch:

Создаем новое правило. На вкладке Host прописываем следующее:

* в данном примере мы будем проверять узел 77.88.8.2 раз в минуту.

На вкладке Up пропишем:

. а на вкладке Down следующее:

Проверка

Для проверки отказоустойчивости лучше всего отключить кабель основного провайдера (вытащить провод из WAN-разъема) — через небольшой промежуток времени Mikrotik должен начать раздавать Интернет второго провайдера. Проверить, что внешний канал изменился можно с помощью различных сайтов, например, 2ip.ru.

Читайте также

Данная информация также может быть полезной:

Mikrotik автоматическое переключение на резервный канал для динамического ip адреса (выдаваемого по DHCP)

Приветствую, Хабр! В связи с плохим качеством линии меня попросили настроить автоматическое переключение на резервный канал. Для этой цели предоставили роутер MikroTik RB 951Ui.

В этой ОС можно создавать маршрут двумя способами:

• вручную (через графический интерфейс или через терминал);
• автоматически DHCP-клиентом.

При создании маршрута вручную не получится обновлять шлюз динамически. Для этого придется писать несколько достаточно больших скриптов и добавлять множество проверок. При их написании заметил, что в RouterОS проблематично заставить работать сложные скрипты. Очень тяжело отследить логику работы, хотя использовались логи и переменные для проверки. Скрипты были написаны, но работали нестабильно, несмотря на оптимизацию кода и добавления проверок. Когда количество проверок начало расти в геометрической прогрессии и многократная оптимизация логической схемы ненамного улучшила ситуацию — я решил отказаться от этого варианта и попробовать использовать в скрипте опцию автоматического создания маршрута DHCP- клиентом.

Для нужного интерфейса в настройках DHCP-клиента устанавливается опция автоматического создания маршрута по умолчанию.

Итак, скрипт будет работать по такому алгоритму:

Объяснение алгоритма

Для каждого интерфейса будет запущена копия скрипта. Каждая копия будет автономно создавать маршрут по умолчанию. Приоритет маршрута будет зависеть от distance. То есть, когда «упадет» соединение на маршруте с Distance 10 произойдет переключение на 11. Благодаря этому переключение получается бесшовным.

Для начала скрипт пингует выбранный хост в интернете по маршруту по умолчанию. Если пинг меньше чем ($PingCount-$Margin) (Margin — задается погрешность для контроля точности), тогда пингуем по тестовому маршруту для проверки «живое» ли соединение. В случае негативного результата проверяем маршрут и наличие проблем с настройками:

• перегружаем интерфейс каждые $TimeToWait раз (снижаем нагрузку на процессор);
• ждем загрузки интерфейса;
• проверяем есть ли настройки DHCP — клиента для данного интерфейса, в противном случае создаем;
• проверяем статус DHCP клиента (иногда RouterOS может «подсунуть свинью»);
• ждем получение DHCP lease;
• добавляем к значению $CurrentGateway нужный интерфейс;
• проверяем есть ли тестовый маршрут;
• проверяем правильный ли в тестовом маршруте шлюз.

Скорость реакции на состояние соединения можно индивидуально подстраивать с помощью следующих переменных:

• PingCount — количество посылаемых icmp запросов (также можно добавить еще одну переменную для определения количества посылаемых запросов по тестовому маршруту и на шлюз провайдера, то есть уменьшится количество запросов и соответственно увеличится скорость работы скрипта);
• Margin — коэффициент нужен для задания погрешности. Например, при $Margin=1 цикл проверки маршрутов запускается только тогда, когда пропадет больше одного пакета, что немаловажно в моей ситуации;
• TimeToWait при ожидании соединения интерфейс перегружается каждый $TimeToWait раз (это нужно для того, чтобы снять нагрузку на процессор)

Подготовительная настройка

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

Для работы скрипта не нужно создавать маршруты по умолчанию — он создаст их автоматически. Единственное, нужно подобрать подходящий distance для тестовых маршрутов (можно оба с $Distance = 1) и $DistanceDefault 10 и 11 для маршрутов по умолчанию (по одному для каждого провайдера). Также не нужно создавать dhcp клиентов.

При настройке роутера я использовал SSH и Winbox (специализированная программа для настройки устройств управляемых RouterOS, работает даже в *nix с помощью Wine).

В Interfaces меняем названия двух интерфейсов, чтобы совпадали со значением переменной $Iface в скрипте (у меня isp1, isp2):

Меняем DNS адреса на google-кие:

Повторяем предыдущий шаг для второго интерфейса, только заменяем значение переменной $Iface на «isp2», также меняем $DistanceDefault на вышеуказанные значения (у меня для isp1 — 10, а для isp2 — 11 ).

Также это можно сделать с помощью ssh или же из консоли, если возникают проблемы с кириллицей в дате:

Вот и все. Надеюсь, что эта статья окажется для кого-то полезной.

Как видите, несмотря на то, что маршрут указан верно — пинг не проходит.

Чтобы это исправить, добавил еще одну проверку (выше в коде скрипта она уже добавлена).

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, она и будет проверять, с заданной периодичностью, состояние канала.

Переходим в раздел Tools -> Netwatch и создаем там новый хост для проверки

Где:
Host: 8.8.8.8 — адрес по доступности которого мы будем проверять работоспособность основного канала
interval: 00:03:00 — в моем примере, проверка будет проводиться каждые 3 мин, интервал проверки вы можете задать по своему усмотрению, данная схема у меня работает уже несколько лет и 3 мин, для меня, вполне приемлемое время, чаще не вижу смысла запускать проверки.
Переходим во вкладку UP в ней будет выполняться команда которая будет выполняться в случае доступности IP адреса, мониторинг которого мы выполняем:

Переходим во вкладку 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

В данной инструкции мы рассмотрим пример настройки двух Интернет-каналов одновременно на роутере Mikrotik с целью отказоустойчивости — при разрыве соединения основной канал будет меняться на резервный. В нашем случае будет задействован один WAN Ethernet, второй — LTE. Итого, два провайдера и две сети.

Есть два способа настройки отказоустойчивости:

1. Настройка балансировки между шлюзами (разные приоритеты для интерфейсов). Данный метод можно использовать, если у нас оба провайдера предоставляют настройки со статическим адресом шлюза. Настройка выполняется без скриптов через конфигурирование нескольких шлюзов с разным весом.
2. Проверка доступности основного Интернет-канала и переключение на резервный при наличии проблем. Это универсальный метод настройки отказоустойчивости. Для настройки используется утилита Netwatch, которая выполняет скрипт проверки и, при необходимости, смены основного шлюза для доступа к сети Интернет.

Мы рассмотрим оба варианта. Настройки выполним в программе winbox. Настройка в веб-интерфейсе аналогична.

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

Маршруты с разным приоритетом

Раскрываем в меню IP:

. и переходим в Routes:

Добавляем 2 маршрута. Первый через одного Интернет провайдера со следующими настройками:

* мы указываем шлюз от нашего провайдера (в данном примере 1.1.1.1), задаем настройку проверки шлюза (Check Gateway) с помощью утилиты ping, задаем приоритет (Distance 10).

Для второго провайдера мы задаем, практически, аналогичные настройки:

* обратите внимание, что в отличие от первого маршрута, в данном указана большая дистанция и другой шлюз (для второго провайдера).

После удаляем старые маршруты. Должны остаться только те, что мы добавили.

Использование сценария, запускаемого в Netwatch

Данный метод поможет настроить резервирование канала, если один из провайдеров выдает динамические адреса в разных подсетях, например, подключение через 4G-модем.

1. Задаем описания

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

Раскрываем в меню IP:

. и переходим в Routes:

2. Настраиваем узел для проверки канала

Мы настроим узел, который будет пинговать провайдер 1. Если пинг пропадает, то необходимо переключать активный Интернет-канал на провайдера 2. Также мы должны заблокировать возможность пинговать проверочный узел с провайдера 2.

И так, переходим к настройке маршрутов:

Добавляем новый маршрут к проверочному узлу, например 77.88.8.2 (DNS Яндекса):

* в данной настройке мы задали маршрут к проверочному узлу через шлюз 1.1.1.1 (в нашем примере это шлюз от провайдера 1).

Переходим в IP — Firewall:

Создаем новое правило для запрета пинга проверочного узла через провайдера номер 2:

. в качестве действия выбираем drop:

3. Настройка задания в Netwatch

Переходим в Tools — Netwatch:

Создаем новое правило. На вкладке Host прописываем следующее:

* в данном примере мы будем проверять узел 77.88.8.2 раз в минуту.

На вкладке Up пропишем:

. а на вкладке Down следующее:

Проверка

Для проверки отказоустойчивости лучше всего отключить кабель основного провайдера (вытащить провод из WAN-разъема) — через небольшой промежуток времени Mikrotik должен начать раздавать Интернет второго провайдера. Проверить, что внешний канал изменился можно с помощью различных сайтов, например, 2ip.ru.

Читайте также

Данная информация также может быть полезной:

Mikrotik автоматическое переключение на резервный канал для динамического ip адреса (выдаваемого по DHCP)

Приветствую, Хабр! В связи с плохим качеством линии меня попросили настроить автоматическое переключение на резервный канал. Для этой цели предоставили роутер MikroTik RB 951Ui.

В этой ОС можно создавать маршрут двумя способами:

• вручную (через графический интерфейс или через терминал);
• автоматически DHCP-клиентом.

При создании маршрута вручную не получится обновлять шлюз динамически. Для этого придется писать несколько достаточно больших скриптов и добавлять множество проверок. При их написании заметил, что в RouterОS проблематично заставить работать сложные скрипты. Очень тяжело отследить логику работы, хотя использовались логи и переменные для проверки. Скрипты были написаны, но работали нестабильно, несмотря на оптимизацию кода и добавления проверок. Когда количество проверок начало расти в геометрической прогрессии и многократная оптимизация логической схемы ненамного улучшила ситуацию — я решил отказаться от этого варианта и попробовать использовать в скрипте опцию автоматического создания маршрута DHCP- клиентом.

Для нужного интерфейса в настройках DHCP-клиента устанавливается опция автоматического создания маршрута по умолчанию.

Итак, скрипт будет работать по такому алгоритму:

Объяснение алгоритма

Для каждого интерфейса будет запущена копия скрипта. Каждая копия будет автономно создавать маршрут по умолчанию. Приоритет маршрута будет зависеть от distance. То есть, когда «упадет» соединение на маршруте с Distance 10 произойдет переключение на 11. Благодаря этому переключение получается бесшовным.

Для начала скрипт пингует выбранный хост в интернете по маршруту по умолчанию. Если пинг меньше чем ($PingCount-$Margin) (Margin — задается погрешность для контроля точности), тогда пингуем по тестовому маршруту для проверки «живое» ли соединение. В случае негативного результата проверяем маршрут и наличие проблем с настройками:

• перегружаем интерфейс каждые $TimeToWait раз (снижаем нагрузку на процессор);
• ждем загрузки интерфейса;
• проверяем есть ли настройки DHCP — клиента для данного интерфейса, в противном случае создаем;
• проверяем статус DHCP клиента (иногда RouterOS может «подсунуть свинью»);
• ждем получение DHCP lease;
• добавляем к значению $CurrentGateway нужный интерфейс;
• проверяем есть ли тестовый маршрут;
• проверяем правильный ли в тестовом маршруте шлюз.

Скорость реакции на состояние соединения можно индивидуально подстраивать с помощью следующих переменных:

• PingCount — количество посылаемых icmp запросов (также можно добавить еще одну переменную для определения количества посылаемых запросов по тестовому маршруту и на шлюз провайдера, то есть уменьшится количество запросов и соответственно увеличится скорость работы скрипта);
• Margin — коэффициент нужен для задания погрешности. Например, при $Margin=1 цикл проверки маршрутов запускается только тогда, когда пропадет больше одного пакета, что немаловажно в моей ситуации;
• TimeToWait при ожидании соединения интерфейс перегружается каждый $TimeToWait раз (это нужно для того, чтобы снять нагрузку на процессор)

Подготовительная настройка

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

Для работы скрипта не нужно создавать маршруты по умолчанию — он создаст их автоматически. Единственное, нужно подобрать подходящий distance для тестовых маршрутов (можно оба с $Distance = 1) и $DistanceDefault 10 и 11 для маршрутов по умолчанию (по одному для каждого провайдера). Также не нужно создавать dhcp клиентов.

При настройке роутера я использовал SSH и Winbox (специализированная программа для настройки устройств управляемых RouterOS, работает даже в *nix с помощью Wine).

В Interfaces меняем названия двух интерфейсов, чтобы совпадали со значением переменной $Iface в скрипте (у меня isp1, isp2):

Меняем DNS адреса на google-кие:

Повторяем предыдущий шаг для второго интерфейса, только заменяем значение переменной $Iface на «isp2», также меняем $DistanceDefault на вышеуказанные значения (у меня для isp1 — 10, а для isp2 — 11 ).

Также это можно сделать с помощью ssh или же из консоли, если возникают проблемы с кириллицей в дате:

Вот и все. Надеюсь, что эта статья окажется для кого-то полезной.

Как видите, несмотря на то, что маршрут указан верно — пинг не проходит.

Чтобы это исправить, добавил еще одну проверку (выше в коде скрипта она уже добавлена).

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

• Главная
• Резервирование каналов в Mikrotik при помощи рекурсивной маршрутизации

Резервирование каналов в Mikrotik при помощи рекурсивной маршрутизации

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

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Теория

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

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

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

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

• Непосредственно присоединенные сети — в данном случае они имеют флаг С — connect — это сети к которым физически подключен маршрутизатор, они добавляются при подключении интерфейса и удаляются при его отключении.
• Статические маршруты — добавляются системным администратором, либо динамически, при подключении коммутируемого соединения или получения сетевых параметров по DHCP. В этом случае к флагу S -static, добавляется флаг D — dynamic.
• Динамические маршруты — маршруты добавляемые при помощи протоколов динамической маршрутизации, таких как OSPF, RIP и т.д. Не следует путать их с динамически добавляемыми статическими маршрутами и маршрутами непосредственно присоединенных сетей. Флаг D — dynamic в Mikroitk обозначает только то, что маршрут добавлен автоматически, без участия пользователя. А динамические маршруты обозначаются флагами r — rip, b — bgp, o — ospf, m — mme, однако их рассмотрение выходит за рамки данной статьи.

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

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

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

Хорошо, адрес шлюза мы определили, но это не решило основной задачи — куда отправить данные. Почему? Вернемся к нашей аналогии, вы решили поехать из Белгорода в Москву, карта показывает, что сначала вам нужно приехать в Курск. Отлично, но как именно в него попасть? Навигатор услужливо подскажет нам, что требуется ехать на север по федеральной трассе М2 «Крым».

В нашем случае основной задачей маршрутизатора будет определить интерфейс выхода, т.е. куда именно физически нужно направить данные, чтобы они добрались до требуемого места назначения. Поэтому роутер снова начинает поиск в таблице маршрутизации чтобы определить каким образом следует добраться до искомого адреса шлюза 192.168.3.1, согласно таблице, будет найден маршрут к сети 192.168.3.0/24 через интерфейс ether5. Так как интерфейс выхода определен, то поиск прекращается и роутер формирует необходимый тип данных для передачи на канальном уровне.

Здесь тоже следует дать краткие пояснения, если интерфейс выхода является сетью Ethernet, то роутер выполнит ARP-запрос для адреса шлюза и сформирует Ethernet-кадр, а если это туннельный интерфейс точка-точка (VPN, PPPoE), то выполнит инкапсуляцию IP-пакета и отправит его на другую сторону туннеля.

И здесь мы приходим к следующим соображениям: таблица маршрутизации может быть большая и поиск по ней может быть затратным, в тоже время шлюз будет располагаться в одной из непосредственно присоединенных сетей, возможно следует ограничить поиск только по ним?

Для решения этой проблемы в Linux, а следовательно, и в RouterOS, введены понятия области маршрута — Scope, и области поиска — Target-scope. Теперь вернемся к нашей таблице маршрутизации, «нулевой» маршрут имеет область — 30 и область поиска — 10. Следовательно дальнейший поиск будет вестись только среди маршрутов с областью 10.

По умолчанию данные опции имеют следующее значение:

• Непосредственно присоединенные сети: Scope — 10, Target Scope не имеет смысла, так как данный маршрут указывает на интерфейс выхода
• Динамические маршруты — OSPF, RIP, MME: Scope — 20, Target Scope — 10
• Статические маршруты: Scope — 30, Target Scope — 10

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

Давайте рассмотрим следующую таблицу маршрутизации:

Теперь разберемся как это работает. Когда мы хотим связаться с каким-либо узлом в сети интернет маршрутизатор выполнит поиск по таблице маршрутизации и, если не указано иных маршрутов, выберет «нулевой» в котором указан шлюзом 1.1.1.1, так как найден адрес, то поиск будет продолжен, чтобы определить интерфейс выхода. Так как указанный нами шлюз не находится ни в одной из непосредственно присоединенных сетей, то сделать это не удастся и такой маршрут работать не будет.

Поэтому мы «подскажем» маршрутизатору как достичь указанного нами узла и добавим маршрут к 1.1.1.1 через сеть провайдера, а чтобы он участвовал в поиске его область должна быть меньше или равна области поиска «нулевого» маршрута, т.е. 10. Это очень важный момент, если вы неправильно укажете область второго маршрута — рекурсивная маршрутизация работать не будет.

Итак, роутер находит адрес первого шлюза — 1.1.1.1 и начинает искать маршрут к нему с среди маршрутов с областью 10, там он находит второй маршрут и получает из него новое значение шлюза — 192.168.3.1 — который является шлюзом нашего провайдера, затем еще раз выполняет поиск и находит связанный с ним интерфейс выхода — ether5. После чего пакет отправляется провайдеру, а удаленный узел 1.1.1.1 используется нами только как способ проверки наличия интернета через данный канал. Это и есть рекурсивная маршрутизация.

Практика

Будем считать что на вашем роутере уже настроен доступ к двум провайдерам и мы не будем останавливаться на этапе базовой настройки, если вы испытываете затруднения с этим, то обратитесь к нашей статье: Базовая настройка роутера MikroTik.

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

У нас есть два нулевых маршрута с разными административными дистанциями (1 для основного провайдера, 2 для резервного) и три маршрута для непосредственно присоединенных сетей, где 192.168.3.0/24 — сеть основного провайдера, а 192.168.16.0/24 — резервного.

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

Внимание! Дальнейшие действия следует производить имея физический доступ к устройству!

Прежде всего отключим автоматическое создание нулевых маршрутов для сетей провайдеров, для этого следует снять флаг Add Default Route в свойствах подключения, либо установить одноименную опцию в значение — no.

После этого доступ в интернет по обоим каналам пропадет. Имейте это ввиду при планировании работ.

В первую очередь создадим маршруты к этим узлам. Для этого снова перейдем в IP — Routes и создадим новый маршрут:

Где Dst. Address — 1.1.1.1 — узел для проверки первого провайдера, Gateway — 192.168.3.1 — шлюз первого провайдера, Distance — 1, Scope — 10. Обратите внимание на значение области (Scope), если вы оставите там значение по умолчанию — 30, то рекурсивная маршрутизация работать не будет! Затем добавим второй аналогичный маршрут, но уже к узлу 9.9.9.9 через шлюз второго провайдера.

Эти же действия через терминал:

Затем добавим два рекурсивных «нулевых» маршрута. Для первого провайдера:

Dst. Address оставляем по умолчанию — 0.0.0.0/0, Gateway — 1.1.1.1 — высокодоступный узел для первого провайдера, Check Gateway — ping — указываем проверку доступности шлюза, Distance — 1.

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

Dst. Address — 0.0.0.0/0, Gateway — 9.9.9.9, Check Gateway — ping , Distance — 2. Обратите внимание на значение административной дистанции второго маршрута, она должна быть больше, чем у основного провайдера, в нашем случае — 2.

То же самое быстро в терминале:

Теперь таблица маршрутизации будет выглядеть следующим образом:

Наши маршруты добавились как рекурсивные и активным является маршрут через основного провайдера. Теперь имитируем аварию у первого провайдера, буквально через 10-20 секунд таблица маршрутизации изменится и рабочим станет маршрут через резервный канал:

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

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

Рекурсивная маршрутизация и PPPoE

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

Для этого перейдем в PPP — Profiles и создадим новый профиль, укажем для него понятное имя и зададим параметр — Remote Address, адрес можно указать любой, единственное условие — он не должен пересекаться с вашими внутренними сетями, в нашем случае это 10.253.252.251. Также установите переключатель Change TCP MSS в положение yes.

В терминале это можно сделать так:

После чего назначим этот профиль вашему PPPoE соединению:

И после его перезапуска убедимся, что удаленный адрес соединения теперь соответствует назначенному нами:

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

Рекурсивная маршрутизация и DHCP

Затем перейдем в настройки DHCP-клиента — IP — DHCP Client — и на закладке Advanced внесем в соответствующее поле короткий скрипт:

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

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

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Дополнительные материалы:

Mikrotik

The Dude

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

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

1. Канал Ehernet от NLink втыкается в первый порт роутера, получает IP по DHCP и поднимает pptp соединение, названное nlink. Это будет основное соединение.
2. Канал ADSL от провайдера Домолинк проходит через DLink-2500 в режиме моста и втыкается во второй порт роутера, поверх поднимается pppoe соединение, названное domolink. Это будет резервное соединение.
3. Порты 3-5 роутера используются для подключения устройств локальное сети.

Настройка подключений и маскарадинга для компьютеров локальное сети является тривиальной и детально описана в официальной вики.

При настройке ppp подключений нужно отключить добавление маршрутов по умолчанию, а затем создать статические маршруты разными метриками и подходящими комментариями:
/ip route
add comment=MainGW disabled=no distance=1 dst-address=0.0.0.0/0 gateway=nlink scope=30 target-scope=10
add comment=RsrvGW disabled=no distance=2 dst-address=0.0.0.0/0 gateway=domolink scope=30 target-scope=10

Теперь чтобы переключать каналы достаточно изменять параметр distance. Трафик пойдёт через канал с меньшим значением этого параметра.

Определение IP-адресов интерфейсов

Определение IP-адреса основного интерфейса

Определение IP-адреса резервного интерфейса

Переключение каналов

Скрипт называется connection_check
:global MainIf
:global RsrvIf
:global MainIfAddress
:global RsrvIfAddress

:local PingCount 3

#www.ru
:local PingTarget1 194.87.0.50

#ya.ru
:local PingTarget2 87.250.250.203

#google dns
:local PingTarget3 8.8.8.8

#Check main internet connection
:local MainIfInetOk false;

if ($MainIfAddress=»») do=

:set MainIfInetOk (($PingResult1 + $PingResult2 + $PingResult3) >= (2 * $PingCount))
>

#Check reserved internet connection
:local RsrvIfInetOk false;

if ($RsrvIfAddress=»») do=

:set RsrvIfInetOk (($PingResult1 + $PingResult2 + $PingResult3) >= (2 * $PingCount))
>

:put «MainIfInetOk=$MainIfInetOk»
:put «RsrvIfInetOk=$RsrvIfInetOk»

if (!$MainIfInetOk) do= <
/log error «Main internet connection error»
>

if (!$RsrvIfInetOk) do= <
/log error «Reserve internet connection error»
>

if (!$MainIfInetOk && $RsrvIfInetOk && ($MainGWDistance

Обратите внимание на пинг через конкретный интерфейс, а так же на критерий признания канала неисправным. Я пингую три разных узла и считаю, что интернет на данном интерфейсе не работает, если приходит меньше 2/3 ответов.

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, она и будет проверять, с заданной периодичностью, состояние канала.

Переходим в раздел Tools -> Netwatch и создаем там новый хост для проверки

Где:
Host: 8.8.8.8 — адрес по доступности которого мы будем проверять работоспособность основного канала
interval: 00:03:00 — в моем примере, проверка будет проводиться каждые 3 мин, интервал проверки вы можете задать по своему усмотрению, данная схема у меня работает уже несколько лет и 3 мин, для меня, вполне приемлемое время, чаще не вижу смысла запускать проверки.
Переходим во вкладку UP в ней будет выполняться команда которая будет выполняться в случае доступности IP адреса, мониторинг которого мы выполняем:

Переходим во вкладку 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

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

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

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

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

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

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

В поле `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«. Решение проблемы было простым — обрамить вычисляемые значения в дополнительные скобки, получив