Проблема
Существует способ настроить балансировку нагрузки с резервированием без скриптов, описанный здесь: . Всё работает отлично. Мы можем использовать «виртуальные» хопы и полагаться на рекурсивный поиск следующего хопа. Однако, чтобы это работало, нужно определить хотя бы один маршрут, который указывает на реальный шлюз. Вот пример из упомянутой статьи:
/ip route
add dst-address=Host1 gateway=GW1 scope=10
add dst-address=Host2 gateway=GW2 scope=10
GW1 и GW2 должны быть IP-адресами. Если здесь использовать имена интерфейсов, рекурсивный поиск следующего хопа не сработает.
Но что делать, если адрес шлюза может изменяться? Если переподключиться к провайдеру и получить новый адрес шлюза, все наши статические маршруты, связанные с этим провайдером, перестанут работать, потому что они всё ещё используют старый адрес шлюза.
Есть обходной путь, если мы подключаемся через ppp (pppoe, pptp, l2tp и т.д.). Можно указать статический удалённый IP-адрес для конкретного соединения в профиле ppp.
А что делать, если адрес шлюза выдается динамически через DHCP? Здесь можно использовать скрипты и менять все соответствующие маршруты под новый адрес шлюза.
Но я считаю, что операционная система, специально созданная для маршрутизации, должна позволять делать такие вещи без скриптов, не так ли?
Решение
Я бы предложил добавить следующую новую опцию в dhcp-client, pppoe-client, l2tp-client и все остальные клиенты: gateway-alias (IP; по умолчанию: «»)
Если эта опция указана, Router OS автоматически добавит следующий динамический маршрут в таблицу маршрутизации при поднятии соединения (будет добавлен connected-маршрут):
/ip route add dst-address=/32 gateway= distance=1 scope=10 target-scope=10
Этот маршрут будет автоматически удалён при падении соединения (connected-маршрут удаляется).
Так мы сможем использовать как шлюз в наших статических маршрутах, и больше не нужно менять маршруты, даже если реальный шлюз динамический.
Более того, используя такой подход, можно менять провайдера без изменения каких-либо статических маршрутов.
Существует способ настроить балансировку нагрузки с резервированием без скриптов, описанный здесь: . Всё работает отлично. Мы можем использовать «виртуальные» хопы и полагаться на рекурсивный поиск следующего хопа. Однако, чтобы это работало, нужно определить хотя бы один маршрут, который указывает на реальный шлюз. Вот пример из упомянутой статьи:
/ip route
add dst-address=Host1 gateway=GW1 scope=10
add dst-address=Host2 gateway=GW2 scope=10
GW1 и GW2 должны быть IP-адресами. Если здесь использовать имена интерфейсов, рекурсивный поиск следующего хопа не сработает.
Но что делать, если адрес шлюза может изменяться? Если переподключиться к провайдеру и получить новый адрес шлюза, все наши статические маршруты, связанные с этим провайдером, перестанут работать, потому что они всё ещё используют старый адрес шлюза.
Есть обходной путь, если мы подключаемся через ppp (pppoe, pptp, l2tp и т.д.). Можно указать статический удалённый IP-адрес для конкретного соединения в профиле ppp.
А что делать, если адрес шлюза выдается динамически через DHCP? Здесь можно использовать скрипты и менять все соответствующие маршруты под новый адрес шлюза.
Но я считаю, что операционная система, специально созданная для маршрутизации, должна позволять делать такие вещи без скриптов, не так ли?
Решение
Я бы предложил добавить следующую новую опцию в dhcp-client, pppoe-client, l2tp-client и все остальные клиенты: gateway-alias (IP; по умолчанию: «»)
Если эта опция указана, Router OS автоматически добавит следующий динамический маршрут в таблицу маршрутизации при поднятии соединения (будет добавлен connected-маршрут):
/ip route add dst-address=/32 gateway= distance=1 scope=10 target-scope=10
Этот маршрут будет автоматически удалён при падении соединения (connected-маршрут удаляется).
Так мы сможем использовать как шлюз в наших статических маршрутах, и больше не нужно менять маршруты, даже если реальный шлюз динамический.
Более того, используя такой подход, можно менять провайдера без изменения каких-либо статических маршрутов.

). Что посоветуешь? Заранее спасибо.