3 рекурсивных переключения маршрута при сбое

Пример резервирования с 3 рекурсивными маршрутами: у нас есть 3 адреса — 192.168.1.1, 192.168.2.1 и 192.168.3.1 (пожалуйста, настройте IP-адреса согласно вашей сети). Выберите любые 3 открытых DNS, например Google, OpenDNS или любой публичный DNS.

Пример выбора DNS:  
сеть 192.168.1.1 — выбран DNS 8.8.8.8  
сеть 192.168.2.1 — выбран DNS 8.8.4.4  
сеть 192.168.3.1 — выбран DNS 1.1.1.1

/ip route add dst-address=8.8.8.8 gateway=192.168.1.1 scope=10  
add gateway=8.8.8.8 distance=1 check-gateway=ping comment="Primary Route"  
add dst-address=8.8.4.4 gateway=192.168.2.1 scope=10  
add gateway=8.8.4.4 distance=2 check-gateway=ping comment="Secondary Route"  
add dst-address=1.1.1.1 gateway=192.168.3.1 scope=10  
add gateway=1.1.1.1 distance=3 check-gateway=ping comment="Third Route"

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

Что ты имеешь в виду под виртуальным хостом? Переключение между тремя WAN сделано таким же образом, как и для двух WAN, принцип остался прежним — в использовании всегда только один WAN одновременно (и да, для канала с самым низким приоритетом не нужно проверять доступность через рекурсивный поиск следующего хопа, если ты не распределяешь трафик между ними, а действительно строго выбираешь один в порядке приоритета для всего трафика).

Хорошо, ты имеешь в виду виртуальный хоп, а не виртуальный хост. Для переключения между несколькими WAN не нужен виртуальный хоп. Его основная задача — контролировать доступность конкретного канала через несколько хостов в интернете, чтобы, если хотя бы один из них отвечает на пинги, канал считался рабочим. Без этого, если единственный контролируемый хост выйдет из строя, канал сразу признаётся недоступным. Поэтому это никак не связано с количеством WAN-линий и с тем, как ты их используешь (только по приоритету, распределяя нагрузку или смешанным способом).

Предполагаю, что это ошибка копирования, и у вас для мониторинга WAN3 и WAN4 указан один и тот же адрес 1.1.1.1, хотя на самом деле они разные. Если это действительно ошибка копирования, то да, эти 4 маршрута по схеме 4×2 достаточно, чтобы мониторить все 4 WAN на предмет доступа к интернету. Но чтобы распределить (сбалансировать) нагрузку между WAN, надо использовать помеченные маршруты и назначать routing-mark: из 4 маршрутов с dst-address=0.0.0.0/0 и без routing-mark одновременно используется только один — тот, что имеет высший приоритет (самую низкую дистанцию) из доступных.

Когда и как вы сбрасываете свои подключения? Я использую netwatch на основном устройстве. Если этот netwatch срабатывает — появляется или пропадает пинг, — я сбрасываю подключения в фаерволе. Думаю, стоит использовать не один пинг, а несколько, или, может, два этапа проверки. А что у вас работает?

У меня настроен mangle и статический маршрут для резервного подключения. Это позволяет мне отслеживать и подключаться через резервное соединение, даже когда основное в порядке. Проблемы иногда возникают, когда система работает на вторичном соединении, а потом основное возвращается. Поскольку маршрут задан, переключение с резервного не происходит сразу. Приходится ждать, пока существующие подключения не завершатся — а это может занять часы. В итоге приходится делать flush, чтобы сбросить всё и переключиться обратно на основное. Изначально это было связано с очень медленным лимитированным резервным каналом, который хотелось использовать только при необходимости. Потому что как только превышаешь месячный лимит — скорость падает до 200К.

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

Довольно близко к тому, что я имел в виду.

Domotz берет на себя большую часть моего удалённого мониторинга.