Механізм резервування основного каналу, при наявності другого (наприклад, 3G або ADSL), на Mikrotik можна організувати по різному. Існує можливість зробити все без скриптів, але з деякими обмеженнями, так само можна зробити багаторівневу перевірку в скрипті і поставити це скрипт в планувальник (або використовувати Tools / Netwatch).
Варіанти збою основного каналу:
Перший варіант збою добре відпрацьовується Мікротіком самостійно, для цього досить включити контроль шлюзу провайдера в маршруті основного каналу:
При недоступності шлюзу основного каналу, Мікротік направить пакети через резервний.
При виникненні другого варіанту, мікротік буде "думати" що все добре (ping до шлюзу проходить) і буде слати все пакети через нього. Тому вирішувати проблему необхідно ширше, в чому допоможуть скрипти.
Якщо ви налаштовуєте маршрутизатор віддалено пам'ятайте: "Віддалена настройка Firewall - до виїзду". Тому не забувайте натиснути кнопку Safe Mode в Winbox. Цей механізм скасує всі зміни з моменту активації режиму Safe Mode, в разі якщо ваша сесія Winbox відвалиться.
У своєму рішенні я не змінюю метрики маршрутів а просто включаю / відключаю резервний маршрут, який має меншу метрику ніж основний канал.
Насамперед реєструємо маршрути (IP / Routes) для контрольних точок з метрикою (distance) = 1. Це необхідно щоб до зазначених контрольних точками трафік йшов тільки через основного провайдера.
аналогічно по другій контрольній точці.
У мене дві контрольні точки: 1. комутатор провайдера (10.0.0.1), які я пінг оперативно (кожну секунду), 2. зовнішній надійний сервер (77.88.8.1), за яким перевіряю що інфраструктура провайдера працює, але не працює канал провайдера ( раз в 30 секунд, тому що це значно рідше).
Далі змінюємо основні метрики каналів на 3 (distance = 3).
Далі додаємо відключений (disable) маршрут 0.0.0.0/0 з метрикою 2 з шлюзом резервного каналу. Саме цей маршрут ми будемо включати або відключати.
- Створено маршрути з пріоритетом 1 для контрольних точок, які доступні тільки для основного каналу;
- Створено маршрути з пріоритетом 2 для резервного каналу, включивши який ми пустимо весь трафік через резервний канал. Оскільки пріоритет маршрутів контрольних точок вище, ніж резервного каналу, доступ до них буде все одно здійснюватися тільки через основний канал;
- Маршрути 0.0.0.0/0 (обидва) переміщені на пріоритет 3, щоб при нормальному режимі (відключеним резервує маршрутом), трафік оброблявся з обох каналів.
Для перевірки доступності використовуємо Netwatch. Створюємо їх 2 штуки (Tools / Netwatch):
- Кожну секунду перевіряє доступність комутатора / шлюзу провайдера:
з UP скриптом:
Скрипти працюють за схожою логікою з першим Netwatch.
контрольні тести
Сценарій 1. Все нормально.
Netwatch 1 = OK -> Включаємо основний канал -> Включаємо Netwatch 2 -> Netwatch 2 = OK -> Резервний канал відключений.
Сценарій 2. Шлюз доступний, але інтернет не працює (збій вище провайдера).
Netwatch 1 = OK -> Включаємо Netwatch 2 -> Netwatch 2 = FAIL -> Резеврний канал включений.
Сценарій 3. Шлюз недоступний.
Netwatch 1 = FAIL -> Вимикаємо Netwatch 2 -> Резеврний канал включений.
На стану резервного каналу ми не дивимося, тому що якщо він теж відвалився то перемикання на нього нічого поганого не зробить - як не було Інтернету так і не буде.
Використання netwatch спрощує скрипти, тому що вони працюють не періодично (через Scheduler), а щодо подій "On down" / "On up".
Я вивчав цю статтю і відкинув її тому не захотів навантажувати таблицю маршрутизації такими милицями. Скрипти працюють очевидніше і інформативніше.
використовувати рекурсивний маршрут
/ Ip route
add check-gateway = ping distance = 10 gateway = 8.8.4.4 scope = 40 target-scope = 30 де target-scope це scope основного маршруту.