Запрос на функцию: Связать "check-gateway" в маршрутах с элементом(ами) netwatch

Да, я сам немного равнодушен к разным подходам. Но я даже не знаю, с чего начать писать твою «Как настроить MultiWAN», потому что простой схемы тут нет. Думаю, у них есть настройка «check-gateway=ping», так что, вместо того чтобы самому отправлять пинг, можно просто смотреть текущее состояние /tool/netwatch. Например, состояние конкретного netwatch (вверх/вниз) в момент опроса маршрута (/ip/route) и уже на основе этого определять состояние маршрута. И Netwatch позволяет делать такие вещи, как срабатывание по задержке или джиттеру — а в «мульти WAN» окружении это может быть важнее, чем просто «доступность пинга».

Моя проблема с рекурсивной маршрутизацией в том, что «мониторимый хост» не обязательно является тем, что ты реально хочешь контролировать — ведь он скорее индикатор живости конкретного маршрута. То есть нужна какая-то разгрузка между «тем, что тебе важно чтобы работало» (/tool/netwatch) и «тем маршрутом, который они используют» (/ip/route), но без скриптов это не реализовать.

И хотя скрипты по событию «вверх» или «вниз» могут находить нужный маршрут для включения или выключения, тебе всё равно надо постоянно синхронизировать route-id. А скрипты бывают хрупкими: обычно полезны, но нет гарантии, что скрипт, который работает сегодня, останется рабочим после обновления.

Если резервное подключение не сработает и письмо об этом не придёт — это неприятно. Но если что-то критичное, например, переключение маршрутов на удалённом узле далеко от тебя, сломанный после обновления «скрипт переключения» — это катастрофа. И в любом случае, тебе всё равно придётся объяснять: «когда меняешь маршрут, не забудь поменять route-id в скриптах netwatch…»

Проблема в том, что я не хочу получать уведомления о том, что что-то «упало», я хочу, чтобы этого «падения» изначально не было. Сложность — враг надёжности.

Ну, я использую VRRP в некоторых конфигурациях с рекурсивной маршрутизацией. Например, если у вас есть два LTE-устройства Mikrotik на разных операторах, VRRP — довольно полезный метод. Эта функция позволила бы сделать LTE-решения более продвинутыми, так как netwatch jitter помогает выбирать маршрут при наличии нескольких LTE-сетей — то есть, если не пришлось бы так сильно переживать из-за проверки доступности. Уверяю вас, часть с VRRP — это не самое сложное. На самом деле, VRRP я бы поставил в список «недооценённых возможностей». Но с рекурсивными маршрутами и VRRP таблица маршрутизации превращается в настоящий хаос — ведь количество интерфейсов для управления удваивается. Все методы, которые работают по каждому пакету или по каждому соединению в Multi-WAN, не имеют значения, если пакет отправляется на интерфейс без интернета. Поэтому я и уделяю особое внимание «check-gateway» в обсуждениях Multi-WAN. По сути, LTE отключается чаще, чем выходит из строя любое оборудование Mikrotik.

Да, у нас такой же опыт. Кстати, немного по теме операторов MNO и HA. В сельской местности не редкость, что некоторые операторы используют одни и те же площадки. Если повреждается магистральная линия или случается долгий отключение электричества, то, к сожалению, никакого преимущества в одновременном использовании разных операторов нет — все перестанут работать. Поэтому, если возможно, для максимальной отказоустойчивости стоит использовать разные базовые станции, но в деревне это, к сожалению, нереально. Большинство проблем с MNO, с которыми мы сталкивались, как обычно, связаны с неудачными обновлениями ПО на базовой станции и проблемами с магистралью. Однако абсолютное большинство проблем, с которыми мы сталкиваемся ежедневно, связано с клиентским оборудованием (CPE).

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