Russian Users MikroTik | Форум пользователей MikroTik

Сделайте второй маршрут без маркировки с большей метрикой и проверку на доступность первого. Тогда в случае отвала тик днс будет резолвить через второй.
В идеале проверку делать рекурсивными маршрутами, ну или можете использовать нетвотч.
Если во второй никогда нельзя пускать основную массу, то можете просто явно указать это в маскарадинге. Ну и в фаерволе можно порезать подсеть или наоборот сделать исключение.

например так:
/ip route
add check-gateway=ping comment=yota distance=1 gateway=77.88.8.1
add check-gateway=ping comment=lte2_check distance=2 gateway=8.8.4.4
add comment=yota-check distance=1 dst-address=77.88.8.1/32 gateway=109.XXX.XX.XX scope=10
add comment=megafon-check distance=2 dst-address=8.8.4.4/32 gateway=10.X.XXX.X scope=10

/ip firewall filter
add action=drop chain=output dst-address=8.8.4.4 out-interface=vlan_yota
add action=drop chain=output dst-address=77.88.8.1 out-interface=vlan-megafon

Только важно эти адреса как днсы не использовать конечно же.

Мне не понятно желание не давать второй канал самому тику полностью.

mrrc писал(а): ↑30 сен 2020, 21:39 Что-то я пока не очень врубаюсь, если честно.
Во второй канал принудительно направляются либо подсети целиком, либо избирательно отдельные локальные адреса пользователей по мере необходимости, список корректируемый и управляется через адрес лист, чтобы весьма удобно позволяет управлять выпуском нужного рабочего места через обособленный канал второго провайдера.

yarvelov писал(а): ↑30 сен 2020, 21:01 Мне не понятно желание не давать второй канал самому тику полностью.

Так быть может это было бы более простым и надежным решением? Никаких возражений нет, чтобы именно сам тик (его сервисы) могли использовать оба канала от обоих провайдеров.
В IP -> DNS занесены по два адреса DNS от каждого провайдера. Но наверняка доступ из сети одного провайдера к адресам DNS второго запрещен и наоборот соответственно.

Ну так используйте публичные днс.
И маршруты дефолтные оба с разными метриками и проверкой.
А принудительное направление так и останется с маркировками и метками.

mrrc писал(а): ↑30 сен 2020, 22:16

yarvelov писал(а): ↑30 сен 2020, 21:49 Ну так используйте публичные днс.
И маршруты дефолтные оба с разными метриками и проверкой.

Наверное так.
Только насколько публичные будут быcтры по отклику.

Код: Выделить всё

/ip route
add comment="Route to ether3_WAN_200M" distance=1 gateway=IP_GW_ISP2 routing-mark=\
    ether3_WAN_200M
add check-gateway=ping comment="Main WAN route" distance=1 gateway=IP_GW_ISP1
add distance=2 gateway=IP_GW_ISP2

Только как выше упоминал, когда падает канал первого провайдера, зачастую шлюз его остается доступным, в вот дальше и адреса DNS уже нет.

ну что мешает проверить их пингом, например эти https://dns.yandex.ru/

вот из-за того что проверка доступности шлюза провайдера не дает гарантий проверки и делают рекурсивные маршруты пример которых я дал выше.
Иногда вовсе не отвечает гейтвей на icmp в тех же лте сетях.
Можно еще проверять некий адрес в инете вроде 8.8.8.8 и опускать маршрут используя netwatch. В прочем рекурсивные маршруты именно внешний адрес и проверяют, на мой взгляд механизм намного лучше, чем c применением netwatch.
Конечно же это все требует блокировки проверяемых внешних адресов в фаерволе, пример так же выше.