Helldar Mar 18 2016 at 21:01

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

8 min

66K

System administration*Network technologies*

Tutorial

+23

Comments 34

icCE Mar 19 2016 at 01:01

Отлично!
Но на заметку, лучше пропинговать два ресурса. Иногда у ростелекома бывает проблема с доступом у google dns.

V0ldemar Mar 19 2016 at 01:32

А не пробовали еще оптимизировать скрипт стандартным микротиковским netwatch? :)

Helldar Mar 19 2016 at 09:18

Пробовал примерно 2,5 года назад. В начале статьи линки как раз на ту тему, где этот метод описывал.
С netwatch проблема в том, что нельзя принудительно выбрать интерфейс, через который пинговать ресурс. Поэтому нужно добавлять дополнительные правила в файервол, на блокировку пинга через резервный канал.
Это неудобно тем, что если мы захотим, например, изменить IP-адрес пинаемого ресурса, нужно не только в скриптах править, но и на вкладке файервола. А если забудем?..

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

fear86 Mar 19 2016 at 01:44

Отлично, вот все никак руки не доходили донастроить свой, что бы работал с dhcp. Хотелось сделать универсальный роутер все же, а не заточенный под конкретных провайдеров.

Helldar Mar 19 2016 at 20:05

Чуток не понял связь переключения каналов Инета с DHCP...

fear86 Mar 20 2016 at 01:04

Просто обычно все настройки завязаны на то, что ISP статический, и ip шлюза заранее известен. Это делает железку совершенно не переносимой.

Helldar Mar 20 2016 at 06:21

Не всегда. На крайнем месте моей работы, для которой я этот скрипт писал, есть 2 канала: Ростелеком и МТС. Первый использует PPPoE, второй MAC-адрес устройства в качестве "логина" и "пароля" (при первом входе переадресовывает на страницу МТС для ввода логина/пароля, после чего делает привязку по маку).
Так вот, у Ростелекома белый статический IP-адрес, а у МТС получаю через DHCP Client в Микротике.
При всем этом, ни в каких правилах у меня нет жесткой привязки к конкретному IP-адресу. Есть привязка лишь к именам интерфейсов, например, "pppoe-rostelecom", "eth2-MTS"...

Другими словами, совсем не обязательно жестко указывать IP-адреса, когда можно воспользоваться их текстовым эквивалентом (названия интерфейсов).

fear86 Mar 20 2016 at 13:46

У нас уже давненько все отказались от ppoe/l2tp. Сейчас у всех привязка по маку. Суть в том что большинство конфигов в инете обходятся без скриптов, просто проверкой доступности шлюза провайдера. Это конечно проверка так себе, но лучше чем ничего. И тут получается мы завязаны на инфраструктуру провайдеров. А должно все работать из коробки, настроил железку, отправил ее в другой город, там ее воткнули в сеть и она работает. И тут уже без скриптов не обойтись :)

icCE Mar 20 2016 at 14:30

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

Helldar Mar 20 2016 at 16:54

У нас в городе Ростелеком активно юзает PPPoE. Фишка в том, что при глюке сети их шлюз доступен, как и их внутренняя сеть (например, их сервер SIP-телефонии), НО внешний Инет недоступен пока не переподключишь соединение.

fear86 Mar 20 2016 at 17:48

Угу, я так и написал, что это не самое лучшее решение. Но зато самое простое.

mafet Mar 19 2016 at 05:58

А почему только 8.8.8.8. Были глюки в интернете, и 8.8.8.8 был не очень доступен. Как эта ситуация отработает?

Helldar Mar 19 2016 at 09:21

8.8.8.8 использовал в качестве примера. Согласитесь, если в примере указать, скажем, какой-нить 217.112.35.75, народ начнет спрашивать "что это за ресурс и почему пинаем именно его"? Хотя это обычный www.ru

icCE Mar 19 2016 at 12:24

Вопрос не почему 8.8.8.8 а

"А почему только 8.8.8.8"

Как я и писал выше< надо пинговать как минимум два ресурса.

Helldar Mar 19 2016 at 12:41

Исправил код скрипта, несколько его улучшив. Как раз добавил пинки для второго ресурса.

V0ldemar Mar 20 2016 at 07:32

GGC разве не предусматривает недоступность ресурса?

iwram Mar 19 2016 at 06:20

Хорошая статья. Но я в подобном случае поступил по другому, без сложных скриптов. Также ситуация, один провайдер основной, представим что это шлюз 172.16.1.1 и провайдер который считает трафик помегабайтно или низкая скорость, шлюз будет 192.168.1.1. Создаем 2 скрипта, один назовем change-to-main с следующим содержимым:
/ip route set gateway=172.16.1.1 [find dst-address=0.0.0.0/0];
/tool e-mail send server="Адрес почтового сервера" port=25 user="Учетка почты" password="Пароль" to="кому отправить" from="От кого отправлено письмо" \
subject="MikroTik: $[/system clock get date], $[/system clock get time]" \
body="Переключение на основной канал\nДата: $[/system clock get date]\nВремя: $[/system clock get time]\nМеня зовут: $[/system identity get name]:";

Как видно скрипт будет уведомлять администратора о переключении на резервный канал. И второй скрипт подобный только с другим именем и другим шлюзом, дав ему имя change-to-reserv и поменять "Переключение на резервный канал". Можно написать по английски, кому как нравится.
далее идем в Tool> netwatch
добавляем следующее:
add down-script=change-to-reserv host=8.8.8.8 up-script=change-to-main
add disabled=yes down-script=change-to-reserv host=172.16.1.1 \
up-script=change-to-main

Самое важное здесь, создать правило в файрволе, чтобы резервный провайдер не смог пинговать адрес который мы укажем в netwatch (гугловский днс я бы не рекомендовал ставить в данном случае, для этого есть много других ресурсов в пиринге города), если правило не укажем, то netwatch правильно работать не будет. Например, если резервный провайдер будет на ether2, то правило будет выглядеть вот так.
/ip firewall filter
add action=drop chain=output dst-address=8.8.8.8 out-interface=\
ether2

Helldar Mar 19 2016 at 09:22

Судя по названиям скриптов у Вас настроено согласно моей прошлой статье)
Да, метод работает, НО это неудобно тем, что если мы захотим, например, изменить IP-адрес пинаемого ресурса, нужно не только в скриптах править, но и на вкладке файервола. А если забудем?..

iwram Mar 19 2016 at 15:08

Точно, давно настраивал и поэтому написал. Извините за плагиат :).

Helldar Mar 19 2016 at 15:09

Все норм) Прост увидел знакомые названия скриптов.

В одном из предыдущих мест работы этот скрипт все-то работает. Кстати, именно для той работы я его и писал, и с него же выложил статью на Хабре)

А не меняю его по одной причине — я там не работаю)))

esudnik Mar 19 2016 at 09:24

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

Как дальнейшее улучшение можно сделать более сложный скрипт проверки на доступность интернета. Где не только в ответе будет да или нет, а будет определятся фактор качества интернет соединения. Например, 0 = интернет не работает, 100 = интернет работает очень хорошо, 70 = интернет работает нормально, но могло бы быть лучше. Соответственно в алгоритме проверять не только пинг но и различные другие параметры. Потом переключать на резервный интернет если оба значения сильно отличаются.

Helldar Mar 19 2016 at 09:28

Согласен, задумка отличная. В моем случае разница такова, что скрипт настраивал для двух контор: в одной 42 ПК, в другой 96. Вдобавок, по практике, Инет в них либо есть, либо его нет совсем. У обоих Ростелеком по оптике в качестве основной линии.
Поэтому и не приходилось задумываться над доработкой скрипта в плане оценки качества линии.

Helldar Mar 19 2016 at 14:35

Не мог устоять идее и реализовал ее в скрипте. Текст статьи обновил)

Iv8 Mar 19 2016 at 16:39

Настроил так больше года назад: https://habrahabr.ru/post/244385/
по разделу "Обеспечение failover с более глубоким анализом канала"

Исправно работает, вообще без скриптов.

Helldar Mar 19 2016 at 17:00

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

… бухгалтеры ругались, что тот же "Сбербанк Бизнес Онлайн" каждый раз требует пароль — оказалось, что пакеты принимались с одного канала, а уходили на другой.
Значит, криво настроил. Ну да ладно)

Статью прочел, расписано хорошо и понятно. Принял к сведению) Спасибо!

icCE Mar 19 2016 at 18:31

Возник тут еще один вопрос. Можно как то сделать учет трафика?
Например, второй канал может быть лимитирован.
Вроде я видел у routeros подобие БД, может кто уже успел реализовать ?

semifunctional Mar 20 2016 at 01:11

А как же официальная фича из коробки?

icCE Mar 20 2016 at 14:32

шлюз может спокойно работать, но интернета не будет.

semifunctional Mar 20 2016 at 15:53

Там тот же способ проверки что и здесь — пингуют указанный хост.

duzorg Mar 20 2016 at 21:00

У меня вот другая интересная "фича" была. Провайдер ТТК, при отключении не поднимал связь, пока не передернут кабель или не ребутнут роутер. Пришлось дописывать в существующий скрипт рестарт интерфейса...

Helldar Mar 21 2016 at 12:46

Аналогичная ситуация и у Ростелекома — их внутренняя сеть доступна, а внешняя нет.
Поэтому и выкрутился таким кодом:

# Function to reconnect PPPoE connection
:local reconnectPPPoE do={
    /interface pppoe-client set $nameInterface disable=yes;
    :delay 1s;
    /interface pppoe-client set $nameInterface disable=no;
}

satoo Oct 18 2016 at 21:58

Недавно смотрел готовые решения по переключению каналов микротика и наткнулся на этот скрипт. Спасибо, особенно за «оценку качества» с пингом на два адреса.

Хотелось бы отметить следующее: при каждом запуске скрипта мы переключаемся на шлюз основного канала. Т.е. если у нас через основной канал теряются пакеты (т.е. он работает, но кое-как), то при тестировании мы всех переключаем на этот глючный основной канал. При этом сеть начинает «лагать». Особенно радуются sip-пользователи.

Лучший и правильный вариант в этом случае — пинговать через конкретную таблицу маршрутизации с минимальным размером пакета, например:

/ping $pingTo1 interface=$firstInterfaceName size=28 count=$pingCount routing-table=$firstInterfaceName

Кроме того, лучше переделать инициализацию интерфейсов из-за вышеперечисленного и того, что не всегда можно указать интерфейс как шлюз (т.е. если на стороне провайдера не включен proxy-arp):

 :set firstInterface [find dst-address="0.0.0.0/0" gateway=$firstInterfaceName];

 :set secondInterface [find dst-address="0.0.0.0/0" gateway=$secondInterfaceName];



 :set firstInterface [find dst-address="0.0.0.0/0" comment=$firstInterfaceName !routing-mark];

 :set secondInterface [find dst-address="0.0.0.0/0" comment=$secondInterfaceName];

Соответственно, в таблице маршрутизации мы должны добавить маршрут до тестируемого адреса (или до 0.0.0.0/0) с именем таблицы равной названию основного интерфейса.

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

ЗЫЖ данная ситуация не будет наблюдаться когда основной канал в дауне, т.к. основной шлюз не будет активным и дистанция до резервного канала не имеет значения и описываемые «залипания» не видны

karakum22 Oct 18 2022 at 20:39

@Helldar В скрипте всё еще есть ошибка подсчета процента полученных пингов. Если итог не ровно 100, то всегда будет 0.

[andrey@GW] > :put ( 30+50 )
80
[andrey@GW] > :put ( (30+50)/100 )
0
[andrey@GW] > :put ( ((30+50)/100)*100 )
0
[andrey@GW] > :put ( ((30+50)*100/(50+50)) )        
100
[andrey@GW] > :put ( (((30+50)*100)/(50+50)) )
80

такая вот арифметика..

Helldar Oct 19 2022 at 00:58

Какую древность Вы откопали :)

Я последний раз с микротиком сталкивался примерно в 2018-м году, а данный скрипт как в 2016-м написал, так и запустил на железке. Жалоб не было ¯\_(ツ)_/¯

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

Show the best of all time