Задать вопрос
@MarvinD
mikrotik

Как понять процесс работы failover на mikrotik с двумя WAN?

Есть пример: wiki.mikrotik.com/wiki/Advanced_Routing_Failover_w...

Я рассматриваю расширенный вариант с проверками 4 хостов (2 через ISP1, и еще 2 других хоста через ISP2). В общих чертах идея ясная, у меня все работает, но с доработками, но не в них вопрос, а в ясности процесса. На всякий случай, я видел статьи и на хабре и много где еще.

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

Привожу код (пронумерую строки, ясное дело, в скрипте нумерации нет):

1) /ip route
2) add dst-address=Host1A gateway=GW1 scope=10
3) add dst-address=Host1B gateway=GW1 scope=10
4) add dst-address=Host2A gateway=GW2 scope=10
5) add dst-address=Host2B gateway=GW2 scope=10

6) add dst-address=GW1 gateway=Host1A scope=10 target-scope=10 check-gateway=ping
7) add dst-address=GW1 gateway=Host1B scope=10 target-scope=10 check-gateway=ping
8) add dst-address=GW2 gateway=Host2A scope=10 target-scope=10 check-gateway=ping
9) add dst-address=GW2 gateway=Host2B scope=10 target-scope=10 check-gateway=ping


check-gateway=ping проверяет доступность хоста, указанного как шлюз (Host1A...Host2B, я использовал 8.8.8.8, 8.8.4.4 и еще два других IP). Если он не доступен, то шлюз помечается как недействующий (офиц. wiki: Periodically (every 10 seconds) check gateway by sending either ICMP echo request (ping) or ARP request (arp). If no response from gateway is received for 10 seconds, request times out. After two timeouts gateway is considered unreachable. After receiving reply from gateway it is considered reachable and timeout counter is reset.).

Какие при этом должны быть прописаны дефолтные маршруты?

Первое, что приходит в голову (default listing v.1):
add dst-address=0.0.0.0/0 gateway=GW1 distance=1
add dst-address=0.0.0.0/0 gateway=GW2 distance=2


не будут работать как failover, т.к. даже если ISP1 рухнет и Host1A и Host1B станут недоступными, это никак не отразится на маршрутах по-умолчанию (0.0.0.0/0).

Вот такой вариант (default listing v.2):
/ip route add dst-address=0.0.0.0/0 gateway=Host1A distance=1 check-gateway=ping
/ip route add dst-address=0.0.0.0/0 gateway=Host2A distance=2 check-gateway=ping


мне ясен, он работает. Но он:
  1. работает вовсе не завися от строк 6)-9), они просто не нужны при таком раскладе.
  2. не дает преимущества проверки доступности сразу двух хостов через ISP1 и других двух хостов через ISP2


Если "доработать" пример из wiki, снабдить дефолтные маршруты метками ISP1 и ISP2 соответственно, то с помощью Netwatch можно создать задания, которые при недоступности Host1A выполнят что-то вроде:
/ip route disable [find comment="ISP1"]
а при доступности:
/ip route enable [find comment="ISP1"]

Все здорово, и так тоже работает.
Вопрос: почему в wiki по ссылке в начале вообще ничего не сказано про дефолтные маршруты? Подразумевается, что читающий сам допрет, что надо как-то изворачиваться? Зачем даны строки 6)-9) - я так и не понял их реальное функционирование. Можете прояснить для меня цепочку?
  • Вопрос задан
  • 3183 просмотра
4 комментария
Подписаться 6 Оценить 4 комментария
Решения вопроса 1
@moneron89
Сертифицированный тренер Mikrotik
Прочитайте статью внимательно. в итоге мы приходим к двойной рекурсии. Кстати, интересное решение. Получается, что мы мониторим несколько хостов прямыми маршрутами в интернет, через каждый из них делаем маршрут для "виртуального" адреса, который, в свою очередь, является гейтвеем для рекурсивного маршрута по-умолчанию для клиентов. Получается, что маршруты черерез "виртуальные" адреса чекают любое кол-во внешних адресов. И если один из адресов не доступен, а остальные работают -- он будет в апе. Если все адреса сдохли -- значит, провайдер недоступен, деактивируем маршрут. Если Вы поймёте, как это работает, то не запутаетесь. Маршрутов нужно прописать много, да. Но решение интересное )

Полностью не соглашусь с утверждением l0ser140 о том, что фейловер на скриптах лучше. Ничего в нём хорошего нет. Чистая маршрутизация с этим справляется на 200% безо всяких костылей.
Ответ написан
7 комментариев
7 комментариев
Пригласить эксперта
Ответы на вопрос 2
@SmkvSre
Я тоже очень долго парился с настройкой резервирования, у меня получилась вот такая конструкция.

/ip address
add address=<ISP1_IP_ADDRESS> interface=ether1_WAN_MAIN
add address=<ISP2_IP_ADDRESS> interface=ether2_WAN_RESERVE

/interface list
add name=WAN

/interface list member
add interface=ether2_WAN_RESERVE list=WAN
add interface=ether1_WAN_MAIN list=WAN

/ip firewall nat
add action=masquerade chain=srcnat out-interface-list=WAN

/ip firewall mangle
add action=mark-connection chain=input in-interface=ether1_WAN_MAIN new-connection-mark=Input/ISP1
add action=mark-routing chain=output connection-mark=Input/ISP1 new-routing-mark=ISP1 passthrough=no
add action=mark-connection chain=input in-interface=ether2_WAN_RESERVE new-connection-mark=Input/ISP2
add action=mark-routing chain=output connection-mark=Input/ISP2 new-routing-mark=ISP2 passthrough=no
add action=mark-connection chain=prerouting in-interface=ether1_WAN_MAIN new-connection-mark=Forward/ISP1
add action=mark-routing chain=prerouting connection-mark=Forward/ISP1 in-interface=!ether1_WAN_MAIN new-routing-mark=ISP1 passthrough=no
add action=mark-connection chain=prerouting in-interface=ether2_WAN_RESERVE new-connection-mark=Forward/ISP2
add action=mark-routing chain=prerouting connection-mark=Forward/ISP2 in-interface=!ether2_WAN_RESERVE new-routing-mark=ISP2 passthrough=no

/ip route
add distance=1 gateway=<ISP1_GATEWAY> routing-mark=ISP1
add distance=1 gateway=<ISP2_GATEWAY> routing-mark=ISP2
add distance=1 dst-address=8.8.4.4/32 gateway=<ISP2_GATEWAY>
add distance=1 dst-address=8.8.8.8/32 gateway=<ISP1_GATEWAY>
add distance=1 dst-address=77.8.8.1/32 gateway=<ISP2_GATEWAY>
add distance=1 dst-address=77.8.8.8/32 gateway=<ISP1_GATEWAY>
add check-gateway=ping distance=10 gateway=8.8.8.8 target-scope=30
add check-gateway=ping distance=20 gateway=8.8.4.4 target-scope=30
add check-gateway=ping distance=10 gateway=77.8.8.8 target-scope=30
add check-gateway=ping distance=20 gateway=77.8.8.1 target-scope=30

/ip route rule
add action=lookup-only-in-table routing-mark=ISP1 table=ISP1
add action=lookup-only-in-table routing-mark=ISP2 table=ISP2


Проверка по двум хостам на обоих интерфейсах (гугловские и яндексовские DNS).

Но для меня это пол беды, подключение к другому филиалу организовано по L2TP/IPSec, конкретно этот маршрутизатор является клиентом и L2TP/IPSec сессия, которая успешно переключается с ISP1 на ISP2, т.к. сессия рвётся и переподключается по новому маршруту, но когда появляется интернет на ISP1, она не спешит на нём переподняться, т.к. ей и на ISP2 не плохо.
Ответ написан
Комментировать
Комментировать
l0ser140
@l0ser140
По-моему это костыли какие-то.
Единственный плюс в них - нет скрипта, зато в остальном сплошные минусы.
Советую реализовывать при помощи скрипта, можно нагуглить примеры. Будете проверять одни и те же хосты через оба соединения, запускать с желаемой периодичностью, писать в логи о недоступности интернета, не будет этого треша в роутинге и прочие плюшки.
Ответ написан
3 комментария
3 комментария
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы
Вакансии с Хабр Карьеры
Сетевой инженер
Cloud4Y • Ярославль
от 150 000 до 250 000 ₽
Сетевой инженер
Cloud4Y • Москва
от 250 000 до 350 000 ₽
Ведущий системный администратор
ФИНФОРТ • Краснодар
от 200 000 ₽
Ещё вакансии
Заказы с Хабр Фриланса
Аналитика разработки мобильного приложения
20 нояб. 2024, в 16:19
1000 руб./в час
Починить смену почты в обработке входящих аккаунтов - C# .Net
20 нояб. 2024, в 16:02
25000 руб./за проект
Требуется сверстать на Wordpress несколько страниц
20 нояб. 2024, в 15:48
1000 руб./в час
Ещё заказы