Скрипт микротик переключения каналов и переключение между каналами

Провайдер меняет шлюз в DHCP клиенте, не работает переключение или балансировка

DHCP клиент это один из самых распространённых типов настроек WAN интерфейса. Все настройки проходят в автоматическом режиме и не требуют ни каких дополнительных усилий. Однако в варианте с балансировкой двух провайдеров, используемая настройка требует явного определения шлюза(Gateway) в таблице маршрутизации. А если IP адрес серый(динамический), то правила с балансировкой перестанут работать при его изменении.

Для того, чтобы в правиле статической маршрутизации указывался текущий шлюз(Gateway) провайдера, в свойствах DHCP клиента следует укатать скрипт

Скрипт может быть дополнен добавлениями(и удалениями) маршрутов для Routing-mark и Netwatch.

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

Настройка двух провайдеров на MikroTik, балансировка и автопереключение

Инструкция по настройке 2-ух провайдеров на роутере MikroTik. В описании буду рассмотрены два распространённых типа работы двух провайдеров: резервирование и балансировка.

Резервирование(автопереключение) – при обрыве провайдера-1, весь интернет трафик переключается на провайдера-2;

Балансировка – тип настройки, когда две линии интернета работают одновременно. Распределение между провайдером-1 и провайдером-2 может быть в ручном или автоматическом режиме.

Организация локальной сети с одновременным подключением к двум интернет-провайдерам при помощи маршрутизатора MikroTik

Предположим, что у нас есть два интернет провайдера. Первый получает настройки по L2TP, для второго необходимо задать настройки статически, а нам требуется организовать безотказную работу интернет соединения. То есть, в случае отказа первого интернет провайдера маршрутизатор должен автоматически переключиться на второго (резервного) провайдера. А при восстановлении связи с первым провайдером маршрутизатор должен снова начать с ним работать.

Последовательность действий. Подключаем маршрутизатор к порту №3 и соответственно LAN интерфейсу ПК. Для конфигурации RouterOS будет использоваться утилита winbox. Заходим по MAC-адресу и авторизуемся. Видим интерфейс конфигурации маршрутизатора. (Рис. 1)

Рис. 1. Интерфейс конфигурации RouterOS

Первое, что мы делаем – настраиваем интерфейсы провайдера «1» и провайдера «2» Рис.2, а так же настраиваем LAN для портов 3, 4 и 5.

Рис. 2. Настройка провайдера «1» и провайдера «2»

В данном случае Интерфейс-1 принадлежит провайдеру «1» (ISP1 – имя для удобства) Интерфейс-2 принадлежит провайдеру «2» (ISP2). Для организации LAN переходим в пункт меню «Bridge» и добавляем интерфейс c именем LAN. (Рис.3).

Рис. 3. Организация LAN

Указывает порты, которые будут относиться к внутренней сети (Рис. 4)

Рис. 4. Добавление портов в LAN

Описание: Первое, что мы делаем, добавляем шлюз локальной сети (цифры 4, 5). Интерфейс указываем LAN. Второе – добавляем статический адрес второго провайдера (цифры 6, 7)

Рис. 5. Добавление адресов для интерфейсов

Так как организация подключения с первым провайдером осуществляется по L2TP необходимо добавить L2TP-клиента (Рис. 6)

Рис. 6. Добавление L2TP-клиента

После добавления клиента во вкладке status получим соединение. (Рис. 7)

Рис. 7. Статус L2TP-соединения

Теперь займемся организацией DHCP-сервера для раздачи адресов нашим клиентам внутренней сети. Первое что сделаем, создадим pool выдаваемых адресов (Рис. 8), а затем настроим сам DHCP-сервер. (Рис 9).

Рис. 8. Создание pool’а выдаваемых адресов

Рис. 9. Добавление и настройка DHCP-сервера

Описание DHCP-сервера: Добавляем сервер с именем (server1) к интерфейсу внутренней сети LAN c пулом адресов который создавали ранее. В network указываем, какие параметры передавать серверу клиентам.

Теперь нам необходимо добавить статические маршруты, так как всё взаимодействие между сетями осуществляется в соответствии с таблицей маршрутизации. Ее управление в RouterOS осуществляется в меню «Routes». Адресация с локальной сетью и с внутренними сетями провайдеров была добавлена динамически. Осталось добавить маршруты в интернет (на адрес 0.0.0.0/0) через шлюзы провайдеров. (Рис. 10).

Рис. 10. Добавление статических маршрутов

Рис. 11. Настройка переключения каналов

И в заключение, в закладке Up (цифра 5) необходимо прописать следующее правило:

Настройка правил для проходящего трафика

Используя встроенный файервол можно управлять абсолютно всем трафиком, нам необходимо запретить пинг на ISP2. Для это в окне терминала пропишем следующее:
#одобряем использование протокола icmp
ip firewall filter add chain=input comment=«Permit icmp»

#ограничиваем ping 8.8.4.4 через ISP2
ip firewall filter add action=drop chain=output comment=«Deny 8.8.4.4 to reserved internet-channel» dst-address=8.8.4.4 out-interface=«ether2 — internet II (reserve)» protocol=«icmp»

Материал является вводным и предназначен для знакомства с вопросом управления сетью с двумя провайдерами.

Mikrotik переключение между каналами.

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

К роутеру Mikrotik подключены два провайдера.
Первый провайдер к порту ether1-WAN1 со шлюзом 192.168.0.1, второй провайдер к порту ether2-WAN2 — шлюз 192.168.1.1.
Нужно настроить так, что бы основной канал WAN1 работал всегда, но при его падении срабатывало автоматическое переключение на второй провайдер WAN2.
После того, как первый провайдер восстанавливается, система автоматически должна перестроиться обратно на первого провайдера WAN1.
Как настроить подключение к провайдеру в этой статье рассказывать не будем, почитать об этом можно тут и тут.
В середине статьи можно будет посмотреть видео-обзор настройки на Mikrotik переключения каналов при падении одного из них.

1. Начнем с того, что нам нужно явно прописать маршруты для наших провайдеров, отдельно для каждого.
Переходим:

IP — ROUTE — «+»
Dst. Address: 0.0.0.0/0
Gateway: 192.168.0.1%ether1-WAN1
Distance:1
Scope:30
Target Scope:10
Comment: RWAN1

IP — ROUTE — «+»
Dst. Address: 0.0.0.0/0
Gateway: 192.168.1.1%ether2-WAN2
Distance:2
Scope:30
Target Scope:10
Comment: RWAN2

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

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

2. Теперь добавим маршрут к ресурсу интернете, который постоянно пингуется, конечно же это google dns, по нему мы будет определять доступность интернет-каналов провайдеров.

IP — ROUTE — «+»
Dst. Address: 8.8.8.8
Gateway: 192.168.0.1
Distance:1
Scope:30
Target Scope:10
Comment: GOOGLE ROUTE

3. Далее добавим правило в firewall на запрет пинга google dns 8.8.8.8 через WAN2, то есть пинг будет проходить только через WAN1 — первый провайдер. Это делается для того, что бы MIkrotik понял, находятся на втором канале, что первый канал поднялся при появлении ping 8.8.8.8.

IP — Firewall — Filter Rules — «+»:

Вкладка General.
Chain — Output;
Dst. Address — 8.8.8.8;
Out. Interface выберите ether2-WAN2;

На вкладке Action.
Action: drop.

4. Настраиваем саму логику переключения между провайдерами, при падении одного из них.
Переходим Tools — Netwatch — «+»:
Вкладка Host.
Host: 8.8.8.8
Interval: 00:00:05 (время, через которое проверяется данное правило)
Timeout: 1000 ms

Даем понять, что маршрут второго провайдера с комментарием RWAN2 отключается, если ping до host 8.8.8.8 начинают ходить.

Маршрут второго провайдера с комментарием RWAN2 включается, если ping до host 8.8.8.8 начинают ходить.

Подготовка настроек для работы с двумя провайдерами в MikroTik

Данный набор настроек будет считаться контрольной точкой для дальнейших режимов работы роутера MikroTik, а именно резервирования(автопереключения) и балансировки.

В исходной настройке роутера MikroTik произведена базовая настройка и как минимум один интернет провайдер уже работает.

Начать нужно с того, что требуется физическое подключение 2-ого провайдера. Для этого нужно подготовить свободный порт и исключить его из Bridge(LAN).

Освободить порт для 2-ого провайдера

На данном примере, был удалён ether2 со списка портов, принадлежащих к Bridge-LAN.

Настроить 2-ого провайдера

DHCP client

Add Default Route = no – статическая маршрутизация для 2-ого провайдера будет доставлена вручную.

Статический IP

PPPoE client

Add Default Route = no – статическая маршрутизация для 2-ого провайдера будет доставлена вручную.

Добавление 2-ого провайдера в список WAN

Отключить добавление DNS серверов для провайдера-1

Эти действия приведут к тому, что роутер MikroTik не будет использовать DNS сервера текущих интернет провайдеров. К примеру ситуация переключения на резервную линию может спровоцировать отсутствие DNS ответа, т.к. клиент или сам роутер осуществляет DNS запрос через основного провайдера. А он в то время уже перестал работать. Поэтому будут установлены общедоступные DNS сервера, который будут работать с двух провайдеров.

DHCP client

PPPoE client

Определить общедоступные DNS сервера

Отсутствие записей DNS серверов в разделе Dynamic Servers указывает на то, что роутер MikroTik не использует автоматические DNS сервера, которые назначаются в автоматическом режиме.

Отключить автоматическое добавление маршрутов

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

DHCP client

PPPoE client

Добавление маршрутов для двух провайдеров

Для переключение между провайдерами, будет использоваться скрипт, который будет находить маршрут с комментарием ISP-1 или ISP-2 и выключать или включать его в зависимости от статуса работы интернета. Ниже будет описан метод, как это можно сделать для типов подключения: статический IP, dhcp клиент, PPPoE подключение. Этим методом нужно воспользоваться для назначения комментария двух провайдеров.

Кроме обозначенных комментариев нужно определить distance = 2.

Статический IP или DHCP клиент

В случае с DHCP client значение Gateway можно взять с раздела Status самого DCHP клиента

PPPoE client

Mangle маркировка ответов для двух провайдеров

Правила маркировки маршрутов нужно определять только для белых(постоянных) IP адресов! Этот набор правил будет гарантировать то, что если пришёл input запрос на порт второго(или первого) провайдера, через этот же порт будет отправлен ответ. При отсутствии этих правил, доступ к роутеру по внешним IP может сопровождаться непредсказуемой работой.

Маркировка будет состоять из двух каскадных правил: маркировки соединения и маркировки маршрута

Дисклеймер

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

• Автор не несет и не может нести какую либо ответственность за последствия использования материалов, размещенных в данной базе знаний. Все материалы предоставляются по принципу «как есть». Используйте их исключительно на свой страх и риск.

• Все высказывания, мысли или идеи автора, размещенные в материалах данной базе знаний, являются исключительно его личным субъективным мнением и могут не совпадать с мнением читателей!

• При размещении ссылок в данной базе знаний на интернет-страницы третьих лиц автор не несет ответственности за их техническую функциональность (особенно отсутствие вирусов) и содержание! При обнаружении таких ссылок, можно и желательно сообщить о них в комментариях к соответствующей статье.

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

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

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

Использование сценария, запускаемого в 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 следующее:

Одновременная работа 2-ух провайдеров в MikroTik, настройка режима балансировки

Существует два метода распределения нагрузки между 2-мя провайдерами в MikroTik:

Ручная балансировка. Все узлы делятся в ручном режиме на 2-ве условные группы и каждая из групп направляется к выделенному ей провайдеру;

Автоматическая балансировка. Узлы роутера MikroTik будут поделены на группы с помощью внутренних инструментов RouterOS.

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

Когда работают оба провайдеры, нагрузка распределяется согласно ручному распределению в Address list.

Проверка переключения интернета между двумя провайдерами

Проверим, как работает переключение между двумя провайдерами.

Настройка роутера MikroTik на два провайдера работает правильно. Теперь можно увеличить интервал пингования сервера Google.

1. Откройте меню Tools — Netwatch;
2. Сделайте двойной щелчок левой кнопкой мыши по 8.8.4.4;
3. На вкладке Host в поле Interval укажите интервал времени 00:00:30 — 30 секунд.
4. Нажмите кнопку OK.

На этом настройка маршрутизатора Микротик на два провайдера завершена.

Проверка

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

Интернет «появился», или как все вернуть назад

На этом-то этапе мы и заюзаем функцию `if else`:

/ip route {
    
    : ( [get  active] =  or  < ) ={
        
    } ={
        : info ( . "FIRST INTERNET CONNECTED");

        # Change distance
        : ( [get  distance] != 3 ) ={
              distance=3;
            : info ( . "Distance for " .  . );
            ;
        }
    }
    
}

Как и в первой части функции, выводим сообщение о доступности сети, после чего изменяем дистанцию резервного канала и чистим таблицу ARP.

Скрипт уведомления о падении канала связи в магазине

Скрипт о падении EMAIL-IT-FAIL
: sysname [/system identity get name];
: smtpserv [:resolve ];
: Eaccount ;
: pass ;
: date [/system clock get date];
: time [/system clock get time];
: mailto you@mail.yu
/tool e-mail send to=  from=you@mail. \ 
 user= password= server= port=587 start-tls=yes \
 subject=() \
 body=("ВНИМАНИЕ В МАГАЗИНЕ  ПРОПАЛА СВЯЗЬ С ОФИСОМ! Если письмо дошло до вас, значит магазин работает через VPN. Дата отправки письма  ")

Скрипт о восстановлении EMAIL-IT- RECOVER идентичен, за исключением текста.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ручная настройка балансировки 2 провайдеров в MikroTik

Как видно из названия, условную подсеть роутера MikroTik будет поделено на две группы: To-ISP-1 и To-ISP-2.

• pppoe-out1 – это провайдер-1;
• ether2 – это провайдер-2.

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

Mangle маркировка соединений для балансировки 2 провайдеров

Mangle маркировка маршрута для балансировки двух провайдеров

Аналогичные действия по маркировке соединений и маршрута нужно выполнить для Address List = To-ISP-2.

Общий вид раздела Mangle

Для каждой группы узлов To-ISP-1 и To-ISP-2 будет создано по два маршрута, чтобы обеспечить плавное переключение согласно первоначальным условиям по балансировке 2 провайдеров.

Общий вид таблицы маршрутизации при балансировке 2 провайдеров

Контроль ICMP запросов через нужный интерфейс

Эти правила обеспечат контроль статуса интернет соединения для каждого из провайдера. Диагностика статуса интернета будет осуществляться только через те интерфейсы, которые обозначены в таблице маршрутизации с комментариями Netwatch-1 и Netwatch-2.

Настройка Netwatch для переключения провайдеров

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

Настройка балансировки двух провайдеров Per Connection Classifier (PCC) раздела Mangle

Per Connection Classifier (PCC) позволят разделить трафик на равные потоки с возможностью держать пакеты с определенным набором параметров в одном потоке (определяется в наборе параметров из src-address, src-port, dst-address, dst-port)

Настройка 1-го WAN порта

Настраиваем 1-й порт на динамическое получение сетевых настроек от провайдера по DHCP.

1. Откройте меню IP — DHCP Client;
2. Нажмите кнопку Add (синий крестик);
3. В появившемся окне в списке Interface выберите интерфейс ether1;
4. Add Default Route выберите No;
5. Нажмите кнопку OK.

Теперь мы получили IP адрес от провайдера, который отображается в столбце IP Address.

Проверим, что есть подключение к интернет. Откройте меню New Terminal и введите команду ping ya.ru. Как видите, пинг есть.

Резервирование внутренних и внешних каналов связи, статическая маршрутизация, корпоративная сеть на MikroTik

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

Считаю, что динамическая маршрутизация именно в данной задаче работала бы не так быстро и вероятно надежно, как того требует проект. Ничего не имею против динамической маршрутизации, но негативные отзывы о работе ее на оборудовании MikroTik и некоторая специфика сети (об этом ниже), повлияли на выбор в сторону статики и скриптов.

Часть 0. Что дано

Ко мне обратились клиенты – местная торговая сеть. Которой мы предоставляем услуги по организации локальной сети для связи между распределенными по городу магазинами.

С технической точки зрения – провайдер выделяет им отдельный VLAN в своей сети. Все магазины (их 12) подключены к ISP через оптику используя две технологии: FTTH и PON.

Схема сети предприятия до модернизации изображена на картинке.

В двух магазинах и центральном офисе подключение по технологии Ethernet (FTTH). В остальных 9-ти магазинах подключение происходит через технологию PON (Passive Optical Network). При подключении через PON используется Huawei терминалы, модель HG810 – они же ONU (Optical Network Unit). О технологии PON можно прочесть тут.

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

Давайте рассмотрим их подробнее:

1. В сети PON построенной на оборудовании компании Huawei, по умолчанию запрещен обмен трафиком, между ONU работающих от одной базовой станции (OLT – Optical Line Terminal). Эту проблему нам удалось решить, используя специальные профили для корпоративных VLAN.
2. ONU не пропускает DHCP пакеты со стороны абонента по направлению в сеть провайдера. Из сети провайдера в сторону абонента – все ходит. Если подключить главный офис с DHCP сервером к распределенной корпоративной сети через ONU, то сервер находящийся в офисе не сможет раздать адреса узлам, которые находятся за пределами офиса.
3. Аналогичная проблема с проходимостью Multicast – пакетов. Все Multicast пакеты, не проходят через ONU и не видятся в других участках сети.

С остальным трафиком проблем нет, никаких фильтраций и ограничений.

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

На момент обращения ко мне, сеть магазинов представляла из себя плоскую, неуправляемую сеть, с одним маршрутизатором под управлением Kerio Control Server.

В сети все IP устройства из всех магазинов были видны друг другу. Таблица FDB на коммутаторах провайдера насчитывала более 350 устройств в их VLAN. Все эти устройства были в одном большом broadcast-домене.

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

Иногда случались аварии у провайдера из-за которых терялась связь между офисом и отдельным магазинов.

Хуже, когда случается потеря связи между центральным офисом и сетью провайдера. Именно в таком случае все 12 распределенных по городу магазинов, остаются без связи с серверами расположенными в офисе и без доступа к сети интернет. В этот период работа магазинов существенно ограничивается, пропадают возможности:

1. Принимать оплату безналичными платежами.
2. Проводить прием и ревизию товаров.
3. Выполнять синхронизацию цен и остатков.

Центральный офис был подключен через Ethernet. Так как им требовалось раздавать DHCP для устройств во всех магазинах. Оптика из офиса идет в ближайший многоквартирный дом, где размещается узел связи провайдера. Когда в этом доме или домах подключённых далее пропадает электропитание – все 12 магазинов остаются без связи с офисом.

Чтобы работать в случае аварии по питанию, в главный офис заведена линия PON. Использовалась она лишь как резерв на случай падения Ethernet, т.к. через нее не проходили DHCP пакеты. Переключение между каналами связи Ethernet и PON осуществлялось вручную.

Мне были поставлены задачи:

1. Сегментировать сеть и разбить ее на множество мелких broadcast-доменов, чтобы исключить негативное влияние в одном из них на общую сеть.
2. Внедрить способ автоматического переключения внутренних каналов связи на случай если между главным офисом и провайдером пропадет связь через Ethernet или PON.
3. Внедрить способ автоматического переключения связи с офисом, на случай если в каком-то конкретном магазине пропадает связь с ISP – а значит локальная связь с офисом и выход в интернет.
4. Внедрить возможность автоматического уведомления системных администраторов предприятия об аварии на том или ином участке сети (пропала связь с офисом или пропал резервный интернет).

Часть 1. Решение поставленных задач

Для выполнения данных задач куплено оборудование фирмы MikroTik. В центральный офис куплена модель RB1100AHx2, а в каждый из 12-ти магазинов MikroTik hEx (RB750Gr2).

В центральном офисе и во всех магазинах подключается второй провайдер – Ростелеком. У которого компания покупает только доступ в интернет. В центральном офисе подключение выполняется кабелем (FTTH), в магазинах через ADSL. Модемы арендуются у провайдера и работают исключительно в режиме моста.

В сети предприятия введена распределенная схема адресации:

• 192.168.1.0/24 – сеть центрального офиса.
• 192.168.2.0/24 – 192.168.13.0/24 локальные сети каждого из 12 магазинов.

Для работы маршрутизации между офисами введены две вспомогательные сети в которых организована связь между маршрутизаторами MikroTik:

• 10.10.10.0/24 – сеть, приходящая в главный офис через основной Ethernet канал
• 10.10.20.0/24 – сеть, приходящая в главный офис через резервный канал (PON)

Главный офис имеет доступ в сеть интернет через 3 канала:

• ISP1-A – через Ethernet канал, с префиксом /30 IP – 1.1.1.1
• ISP1-B – через PON канал, с префиксом /30 IP – 2.2.2.2
• ISP-2 (Ростелеком) — через PPPoE, IP — 3.3.3.3

Ниже пример конфигурации:

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

Для организации работы удаленных магазинов в случае пропажи связи между магазином и ISP-1, на главном роутере в офисе созданы по 2 пользователя VPN для каждого магазина. Это сделано чтобы каждый из магазинов имел одновременно два активных подключения через внешнюю сеть интернет на два внешних IP адреса в офисе от обоих провайдеров.

Вводим еще 2 вспомогательные сети для обмена трафиком между офисом и магазинами уже через VPN.

• 10.20.30.0/24 – сеть внутри VPN, для магазинов, цепляющихся через внешнюю сеть на IP от ISP-1
• 10.30.40.0/24 сеть внутри VPN, для магазинов, цепляющихся через внешнюю сеть на IP от ISP-2

Включаем L2TP Server на роутере и создаем профили пользователей (здесь привожу пример для одного магазина):

Командой /interface l2tp-server добавляю жесткую привязку в разделе PPP для каждого магазина. Это делается для удобного определения какие магазины подключены. И через что идет трафик.

У нас получаются четыре сети для обмена трафиком.

Для удобства я спланировал адресацию таким образом, что сеть 192.168.15.0/24, будет доступна через 10.10.10.15, 10.10.20.15, 10.20.30.15 и 10.30.40.15, другие подсети будут иметь другие адреса соответственно.

Теперь создадим маршруты.

Я использую для разных маршрутов разные значения административного расстояния. В штатном режиме данные в магазин пойдут через сеть 10.10.10.15, т.к. у нее самый низкое значение административного расстояния – 10. Сеть 10.10.10.0/24 доступна через eth-1, а значит основной канал Ethernet от ISP-1.

В случае выхода из строя канала связи eth-1 данные будут идти по сети eth-2 через PON, если и там беда тогда уже в помощь VPN через PPPoE от ISP-2.

Пример подключения сети в офисе изображен на картинке ниже.

Выполним аналогичные настройки в удаленном магазине. Назначаем адреса:

Создаем l2tp VPN подключение

Предлагаю взглянуть на схему подключения магазина:

В случае выхода канала из строя eth-1 в удаленном магазине, он автоматически теряет связь с офисом через оба локальных маршрута, идущих через ISP-1. Тут нам на помощь приходит VPN сети 10.20.30.1 и 10.30.40.1 которые всегда подняты, причем подняты они всегда через резервный интернет канал для магазина!

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

Создаем таблицу маршрутизации для ISP-2 в магазине:

И создаем правила маршрутизации, согласно которым трафик до обоих IP VPN сервера в офисе будет ходить только через резервный интернет.

Теперь у нас всегда доступен и поднят VPN вне зависимости от того, через какой из каналов берет интернет магазин и сам роутер. Сеть VPN будет работать всегда только через резервный канал и всегда готова принять на себя миссию по связи с офисом.

Сам интернет по умолчанию работает через ISP-1 от офиса, поэтому созданы также 2 отдельные таблицы маршрутизации для доступа в интернет через офис.

Нам нужно убедится, что трафик до 10.10.10.1 и 10.10.20.1 не пойдет через дефолтный роут, откуда с некой вероятностью может прилететь ответ. Для этого я создаю жесткую привязку где искать адреса 10.10.10.1 и 10.10.20.1.

Последнее для магазина — создаем маршруты к офису.

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

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

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

Но, во-первых, большинство магазинов подключены через PON, который не пропускает multicast. И OSPF, и RIP просто не взлетели бы через локалку.

Во-вторых, у меня мало опыта работы с OSPF. И я не уверен в том, как именно она поведет себя, в случае, если канал через ISP-1 локально будет доступен, но в нем будут потери 20-25% и выше. Трафик ходить будет и пакеты с Router Hello будут видны, а вот с живым трафиком будут трудности.

Третье – это скорость реакции и переключения, по умолчанию в настройках OSPF значение Router Dead Interval равно 40 сек. Что для магазина достаточно долго (ну вот такие заказчики). Конечно, его можно подкрутить и уменьшить, но насколько стабильно тогда будет работать OSPF?

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

Честно ничего против OSPF не имею. Но в данном случае, решил перестраховаться и сделать переключение через скрипт.

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

За основу скрипта проверки доступности локальных каналов связи был взят скрипт хабраюзера magnitudo.

Принцип работы скрипта прост. Мы пингуем по 7 раз каждый из интерфейсов на главном роутере большими пакетами по 1500 байт. Удовлетворительным результат считается если вернулось не менее 5 пакетов. Такой метод очень чуток к вероятным проблемам со связью в канале. Если проблемы есть – канал считается не доступным.

В зависимости от результата, устанавливаем значение административного расстояния. Увеличиваем его на 100 если канал не доступен.
Если пропадают оба канала подключенных локально, то скрипт инициирует запуск другого скрипта, отсылающего письмо о падении, либо о восстановлении.

Кто-то заметил, что у меня четыре маршрута, а скрипт проверяет только три. Это делается с целью экономии времени, т.к. все три интерфейсах (два – локально, один через инет) завязаны на основного провайдера. И если у него будет провал на всех 3х интерфейсах, тогда уже остается только последний резервный внешний VPN через ISP-2. Который всегда имеет AD = 40.

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

Кто-то подумает это же сколько скриптов постоянно будут крутится? И вообще, сколько времени нужно чтобы скрипт отработал? С каким интервалом его запускать?

Для меня критично время реакции по доступности маршрута. При проверке скрипта я пробовал засекать время отработки. В случае, когда все штатно это где-то 7 секунд.

Если какой-то из каналов не доступен и скрипт ждет ответа по тайм-ауту, то время увеличивается примерно до 15 секунд.
Что значительно быстрее чем OSPF ждущая по дефолту 40 секунд.

С каким интервалом запускать скрипт? А ни с каким! Я не делал для этого скрипта scheduler!

Этим еще быстрее сократил время реакции. Мне удалось добиться практически моментального времени реакции (на практике около 5 секунд) благодаря подключению к делу NetWatch!

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

Создаем Netwatch для всех 3х адресов:

Поясню – NetWatch пингует хост 10.10.10.1 каждые 10 секунд, с тайм-ауте в 2 секунды. В случае падения, мы сразу превентивно устанавливаем административное расстояние +100 — делаем маршрут не активным.

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

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

Такие NetWatch созданы для всех трех внутренних адресов в сети ISP-1. Которые регулярно пингуют друг друга с двух сторон и в случае проблем, моментально меняют AD и запускают более детальную проверку скриптом.

Ниже привожу листинг скрипта, уведомляющего о падении и восстановлении связи с офисом. За основу скриптов для уведомления использовал статью seventh.

Скрипт о восстановлении EMAIL-IT- RECOVER идентичен, за исключением текста.

Конец

Вот собственно и все. Хотя я не рассказал обо всем, что хотел. За скобками осталась реализация резервирования самого интернета в офисе и в филиалах, уведомление об аварии связанных с интернетом и их восстановлением. Счетчиками количества времени – сколько лежит канал в интернет. Как я ловил Wi-Fi принтер, гуляющий по магазинам через OSPF.

Спасибо всем, кто дочитал до конца. Жду вашей критики, советов, предложений. Будут вопросы, с удовольствием на них отвечу.
Если будет интересно, напишу еще по пару статей по этому проекту, с описанием некоторых костылей в работе сети, которые приходилось решать нетривиальными способами.

Последнее — общая схема подключения офиса и одного из 12 магазинов.

Комментарии к коду

Инициализация функций, используемых в скрипте. Эти функции вводятся скриптом «variable-initialization»!

:global sendEvent;
:global pingSession;
:global ispLogging;

Эти переменные также вводятся скриптом «variables-initialization».

:global eventEmail;
:global pingCount;
:global stableConnectFrom;
:global setFailCounter;
:global ether1Name;
:global ether2Name;

Объявление локальных переменных.

• failoverScriptName должен совпадать с названием этого скрипта;

• startModeEvent — это метка для логов по умолчанию;

• failoverRunTime — максимальное время работы этого скрипта в секундах, вычисляется эмпирически;

:local failoverScriptName "failover";
:local startModeEvent "failover-scheduler";
:local failoverRunTime 30;

Объявление глобальных переменных, которые используются только этим скриптом, а также инициализация переменной pingFailCount, если она имеет не правильный тип.

:global pastCheckStatus;
:global failoverRun;
:global pingFailCount;
:if ( [ :typeof $pingFailCount ] = "nil" || [ :typeof $pingFailCount ] = "nothing" ) do={ :set pingFailCount $setFailCounter; }

Объявление прочих локальных переменных.

:local ether1Route;
:local ether2Route;
:local pingCountTotal ($pingCount * 2);
:local stableConnect $stableConnectFrom;
:local gateway1ip;
:local gateway2ip;
:local pingStatus;

Проверка двойного запуска

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

:if ( $failoverRun != true ) do={ :set failoverRun true; } else={
  :local alreadyRun "Script is already running, after $failoverRunTime seconds we will try again, do not worry.";
  :local scrComplete "Execution of the previous script is completed, continue execution of the current script.";
  :log warning ("$alreadyRun");
  $sendEvent msg=$alreadyRun;
  :delay $failoverRunTime;
  :if ( $failoverRun = true ) do={
    :local didtComplete "Script did not complete in $failoverRunTime seconds, execution of the current script and schedule stopped!";
    /system scheduler set [find on-event="$failoverScriptName"] disable=yes comment="$didtComplete";
    :log error ("$didtComplete");
    $sendEvent msg=$didtComplete;
    :set failoverRun false;
    :error "$didtComplete";
    } else={
      :log info ("$scrComplete");
      :set failoverRun true; }
}

SMS команды

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

Резервный канал

SMS команда для переключения на резервный канал.

Значение переменной stableConnect устанавливается заведомо большим, чтобы при любом исходе тестирования основной канал казался скрипту неработоспособным и он переключил нас на резервный. А для того, чтобы скрипт изменил маршруты сразу, сбрасывается значение переменной pastCheckStatus в false. Ну и изменяется метка для логов startModeEvent, чтобы было понятно. Последним отключается расписание.

:if ( $channel = "backup") do={
  :set stableConnect 60;
  :set pastCheckStatus false;
  :set startModeEvent "failover-man-back";
  :local ChannelSw "Channel switched to the $ether2Name manually via SMS, schedule stopped!";
  /system scheduler set [find on-event="$failoverScriptName"] disable=yes comment="$ChannelSw";
  :log warning ("$ChannelSw");
  $sendEvent msg=$ChannelSw;
}

Основной канал

SMS команда для переключения на основной канал.

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

:if ( $channel = "primary") do={
  :set stableConnect -60;
  :set startModeEvent "failover-man-prim";
  :local ChannelSw "Channel switched to the $ether1Name manually via SMS, schedule stopped!";
  /system scheduler set [find on-event="$failoverScriptName"] disable=yes comment="$ChannelSw";
  :log warning ("$ChannelSw");
  $sendEvent msg=$ChannelSw;
}

Автоматический выбор

Команда возвращает работу скрипта в нормальный режим и сразу же завершает работу.

:if ( $channel = "auto") do={
  :local ChannelSw "Automatic channel selection enabled via SMS, schedule running.";
  /system scheduler set [find on-event="$failoverScriptName"] disable=no comment="";
  :log warning ("$ChannelSw");
  $sendEvent msg=$ChannelSw;
  :set failoverRun false; 
  :error "The script completed its task and stopped!";
}

Проверка состояния каналов

Команда просто проверяет оба канала, отчитывается в ответной SMS и завершает работу.

:if ( $channel = "test") do={
  :local ether1Status [ $pingSession pingFrom=$ether1Name myPingCount=8; ];
  $ispLogging outInt=$ether1Name receivedPing=$ether1Status totalPing=16 startMode="failover-sms" newFileAt=month;
  :local ether2Status [ $pingSession pingFrom=$ether2Name myPingCount=8; ];
  $ispLogging outInt=$ether2Name receivedPing=$ether2Status totalPing=16 startMode="failover-sms" newFileAt=month;
  :local channelStatus "Received ping's:\r\n$ether1Name - $ether1Status/16;\r\n$ether2Name - $ether2Status/16";
  $sendEvent msg=$channelStatus;
  :set failoverRun false; 
  :error "The script completed its task and stopped!";
}

Получение IP шлюзов

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

/ip route { :do {
  :set gateway1ip [get [find dst-address="0.0.0.0/0" gateway-status~"$ether1Name"] gateway];
  :set gateway2ip [get [find dst-address="0.0.0.0/0" gateway-status~"$ether2Name"] gateway];
  } on-error={
    :local noRoute "No default route found for channel $ether1Name or $ether2Name, schedule stopped!";
    /system scheduler set [find on-event="$failoverScriptName"] disable=yes comment="$noRoute";
    :log error ("$noRoute");
    $sendEvent msg=$noRoute;
    :set failoverRun false;
    :error "$noRoute"; }
}

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

:local clearArp do={
  :global ether1Name;
  :global ether2Name;
    /ip arp remove [find interface="$ether1Name" || interface="$ether2Name"];
    :log warning ("ARP for $ether1Name and $ether2Name removed!");
}

Функция для CAPsMAN

Функция для переключения Wi-Fi сетей. Для выключения гостевой сети ждет переменную hotSpotOff с параметром yes, для включения нужно вызвать без переменных. Для использования нужна соответствующая настройка.

:local swWireless do={
  /caps-man provisioning {
    :if ( $hotSpotOff = "yes" ) do={
      set [find name-prefix~"Wi.Ghs"] disable=yes;
      set [find name-prefix~"Wi.Gln"] disable=no;
      :log warning ("CAPsMAN settings has changed: mobile Wi-Fi disabled!");
      } else={
        set [find name-prefix~"Wi.Ghs"] disable=no;
        set [find name-prefix~"Wi.Gln"] disable=yes;
        :log info ("CAPsMAN settings has changed: mobile Wi-Fi enabled!"); }
      }
  /caps-man radio provision [find remote-cap-identity~"cs-ap"];
}

Проверка интерфейсов

Проверяем, чтобы оба интерфейса были включены. Если это не так, ключаем.

/interface ethernet {
  :if ( [get $ether1Name disable] = true ) do={
    set $ether1Name disable=no;
    :delay 2s;
  }
  :if ( [get $ether2Name disable] = true ) do={
    set $ether2Name disable=no;
    :delay 2s;
  }
}

Проверка резервного канала

Вызываем функцию для проверки резервного канала.

:set pingStatus [ $pingSession pingFrom=$ether2Name; ];

 :if ( $pingStatus < $stableConnectFrom ) do={
  :if ( $pingFailCount = $setFailCounter ) do={
    $ispLogging outInt=$ether2Name receivedPing=$pingStatus totalPing=$pingCountTotal startMode=$startModeEvent newFileAt=month;
    :local noInet "$ether2Name failure (received $pingStatus/$pingCountTotal)!";
    :log error ("$noInet");
    $sendEvent msg=$noInet;
    :set pingFailCount 0; } else={ :set pingFailCount ( $pingFailCount + 1 ); }
    } else={
      :if ( $pingFailCount != $setFailCounter ) do={
        $ispLogging outInt=$ether2Name receivedPing=$pingStatus totalPing=$pingCountTotal startMode=$startModeEvent newFileAt=month;
        :set pingFailCount $setFailCounter;
        :local worksFine "$ether2Name works fine (received $pingStatus/$pingCountTotal).";
        $sendEvent msg=$worksFine;
        :log info ("$worksFine"); }
}

Основная часть скрипта

Собственно, отсюда она только начинается. До этого были цветочки.

/ip route {
  :set ether1Route [find dst-address="0.0.0.0/0" gateway=$gateway1ip];
  :set ether2Route [find dst-address="0.0.0.0/0" gateway=$gateway2ip];

Тексты писем

Тут вводится текст для сотрудников, который сообщает им в каком состоянии находится Интернет.

Для удобства он разбит на 4 фрагмента — заголовок, текст при переходе на резервный канал, текст при переходе на основной канал и подпись.

Для переноса строк можно использовать \r\n. Кириллица тоже поддерживается, но вводить текст нужно непосредственно в редакторе скриптов WinBox, т.к. у MikroTik’а с этим есть определенные сложности.

  :local eventHeader "Header,";
  :local eventTextBackup "Text\r\n\r\nBackup";
  :local eventTextPrimary "Text\r\nPrimary";
  :local eventSign "Sign";

А тут формируется итоговое письмо и тема, которая будет состоять из пояснительного текста и временной метки. Опять же, текст темы можно писать на русском.

  :local dateTime ([/system clock get date]."@".[/system clock get time]);
  :local userSubjBackup "Subj Backup $dateTime";
  :local userSubjPrimary "Subj Primary $dateTime";
  :local eventPrimary "$eventHeader\r\n\r\n$eventTextPrimary\r\n\r\n$eventSign";
  :local eventBackup "$eventHeader\r\n\r\n$eventTextBackup\r\n\r\n$eventSign";

Пример письма

Подготовка маршрутов

Проверка и, при необходимости, корректировка обоих маршрутов. Для удобства, основной канал имеет дистанцию 2, а резервный 3. При переходе на резервный канал меняется только дистанция у маршрута этого канала — с 3 на 1.

  :if ( [get $ether1Route distance] != 2 ) do={
    set $ether1Route distance=2;
    :log warning ("Distance for " . $ether1Name . " corrected!");
  }

  :if ( [get $ether2Route distance] != 1 && [get $ether2Route distance] != 3 ) do={
    set $ether2Route distance=3;
    :log warning ("Distance for " . $ether2Name . " corrected!");
  }

Проверка основного канала

Вызываем функцию для проверки основного канала.

:local pingStatus [ $pingSession pingFrom=$ether1Name; ];

Вот наконец и самая суть скрипта. Если pingStatus меньше stableConnect проверяем, первый ли это раз. Если первый, то просто предупреждаем администратора и выставляем метку pastCheckStatus в значение false. Если не первый, т.е. pastCheckStatus уже равно false, то переключаем канал на резервный, пишем в лог, уведомляем сотрудников и отключаем гостевую Wi-Fi сеть.

Если pingStatus не меньше stableConnect, значит основной канал работает нормально и можно переключиться обратно на него. В этом случае переключаем канал, меняя дистанцию резервного канала на 3, пишем в лог и всех уведомляем. Все!

  :if ( $pingStatus < $stableConnect ) do={
    :if ( [get $ether2Route distance] != 1 ) do={
      $ispLogging outInt=$ether1Name receivedPing=$pingStatus totalPing=$pingCountTotal startMode=$startModeEvent newFileAt=month;
      :local noPriInet "$ether1Name failure (received $pingStatus/$pingCountTotal), $ether2Name enabled!";
      :if ( $pastCheckStatus = false ) do={
        set $ether2Route distance=1;
        :log warning ("Distance for " . $ether2Name . " changed!");
#        $clearArp;
        $swWireless hotSpotOff=yes;
        :log error ("$noPriInet");
        $sendEvent msg=$noPriInet;
        $sendEvent mode=mail to=$eventEmail subj=$userSubjBackup msg=$eventBackup;
        } else={
          :local badPriInet "$ether1Name is bad (received $pingStatus/$pingCountTotal)!";
          :log warning ("$badPriInet");
          $sendEvent msg=$badPriInet;
          :set pastCheckStatus false; }
      }
      } else={
        :if ( [get $ether2Route distance] != 3 ) do={
          $ispLogging outInt=$ether1Name receivedPing=$pingStatus totalPing=$pingCountTotal startMode=$startModeEvent newFileAt=month;
          :local PriInetGood "$ether1Name connected (received $pingStatus/$pingCountTotal), $ether2Name disabled.";
          :log warning ("$PriInetGood");
          set $ether2Route distance=3;
          :log warning ("Distance for " . $ether2Name . " changed!");
#          $clearArp;
          $swWireless;
          $sendEvent msg=$PriInetGood;
          $sendEvent mode=mail to=$eventEmail subj=$userSubjPrimary msg=$eventPrimary;
        }
        :set pastCheckStatus true;
      }
}

И напоследок меняем значение переменной failoverRun на false, уведомляя другие копии этого скрипта о том, что текущий скрипт завершился и можно занимать его место.

:set failoverRun false;

UPD

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