Короткий ответ

Failover в RouterOS 7 держится на двух default с разным distance и механизме, который снимает плохой маршрут. check-gateway=ping пингует сам gateway (203.0.113.1). Если ISP не отвечает на ping на шлюзе, но интернет жив — будете ложно падать на резерв. Если шлюз пингуется с CPE, а uplink за ним мёртв — не переключитесь никогда. Тогда нужен recursive route на проверяемый адрес (например 1.1.1.1) с target-scope/scope, либо Netwatch+скрипт.

Одинаковый distance — это ECMP, не failover. Сначала выровняйте distance 1 и 2.

Симптомы и как отличить

Выдернули ether1 — клиенты висят, lte1/ether2 с адресом простаивает. Или наоборот: моргает каждую минуту.

КартинаНе failoverЧто это
Оба default AS с одним distancebackupECMP
Backup никогда не activecheck-gateway не падает primaryping шлюза «вечно жив»
Переключились, NAT не тотout-interfacemasquerade
Нет адреса на WAN2DHCP/PPPoEадрес от провайдера

Возможные причины

  1. Оба distance=1.
  2. check-gateway=ping на шлюз, который всегда отвечает с модема.
  3. Нет check-gateway вообще: primary «висит» unreachable только при no-link; PPPoE может врать.
  4. Recursive настроен, но scope/target-scope не дают использовать промежуточный маршрут.
  5. DHCP-клиент add-default-route=yes перетирает ваши статики другим distance.
  6. NAT только на ether1.
  7. Скрипт Netwatch выключает не тот интерфейс.

Диагностика

/ip address print
/ip route print detail
/ip dhcp-client print
/ip firewall nat print

Выдерните (в окно) primary или disable ether1 в тесте. Наблюдайте, станет ли backup A. Ping с роутера на 1.1.1.1.

Если primary ether1 no-link, а маршрут всё ещё A — default смотрит не на ether1 (PPPoE/VPN).

Лог route:

/log print where topics~"route"

Решение

Сценарий A. Простой distance + ping шлюза

Только если шлюз реально падает вместе с интернетом:

/ip route
add dst-address=0.0.0.0/0 gateway=203.0.113.1 distance=1 check-gateway=ping comment=isp1
add dst-address=0.0.0.0/0 gateway=198.51.100.1 distance=2 check-gateway=ping comment=isp2

check-gateway=arp — альтернатива, если ICMP запрещён, но ARP шлюза жив при мёртвом uplink — та же ловушка.

Сценарий B. Recursive (проверка «интернета», не модема)

Идея: ping 1.1.1.1 через ISP1. Если 1.1.1.1 недоступен этим путём — default ISP1 падает.

/ip route
add dst-address=1.1.1.1/32 gateway=203.0.113.1 scope=10 comment=probe-isp1
add dst-address=0.0.0.0/0 gateway=1.1.1.1 distance=1 check-gateway=ping target-scope=11 comment=default-isp1
add dst-address=0.0.0.0/0 gateway=198.51.100.1 distance=2 comment=default-isp2

Цифры scope/target-scope должны позволять использовать probe. Если default сразу inactive — scope не сходится; сверяйте с документацией ROS 7 по recursive, не копируйте ROS 6 вслепую при неудаче (логика близка, проверяйте print detail).

Не используйте 1.1.1.1 одновременно как единственный DNS и probe, если хотите резолвить при падении — это отдельный нюанс; для пробы можно взять другой anycast.

Сценарий C. DHCP default мешает

/ip dhcp-client set [find interface=ether1] add-default-route=no

Дальше только ваши статики. Иначе получите три default.

Сценарий D. NAT на оба WAN

/ip firewall nat
add chain=srcnat out-interface-list=WAN action=masquerade src-address=192.168.88.0/24

Оба WAN в list.

Как проверить, что проблема устранена

  1. Оба WAN с адресами, primary A, backup не A.
  2. Disable primary: в течение нескольких ping-interval backup становится A, клиенты выходят (новый conntrack).
  3. Enable primary: возврат на ISP1 (для check-gateway — когда probe снова жив).
  4. Старые TCP сессии могут умереть — это нормально при смене NAT IP.

Если не помогло

  • Нужен sticky per-host — policy routing, не два default.
  • Играет асимметрия — не держите два active default.
  • LTE «висит» без интернета с живым шлюзом — только recursive/Netwatch HTTP-check (тип icmp vs http-get в Netwatch ROS 7).
  • BGP с провайдером — другая лига, не distance 1/2.

Профилактика

  • Документ: кто primary, probe-адрес, distance.
  • Мониторинг обоих WAN ping и default flag.
  • Тестовое окно раз в квартал: физически выдернуть ISP1.
  • Не смешивать ECMP и failover на одних и тех же default.

DHCP default, detect-internet и ложные переключения

Пока /ip dhcp-client с add-default-route=yes рисует свой default, ваши статики с distance 1/2 живут в зоопарке. Отключите add-default-route и держите маршруты явно. Проверьте /interface detect-internet print: функция может помечать интерфейсы и путать ожидания, на проде её часто выключают после осознания.

check-gateway=ping до 203.0.113.1 бесполезен, если это LAN-сторона модема, которая отвечает всегда. Recursive на 1.1.1.1 (или другой probe) проверяет путь дальше модема. Не используйте один и тот же probe как единственный DNS, если при его падении хотите сохранить резолв — возьмите отдельный anycast.

Netwatch в ROS 7 умеет type=icmp и http-get. HTTP до «заглушки провайдера» может врать «всё ок» при мёртвом интернете. Интервал и порог down/up обязательны: один lost ping не должен /interface disable ether1. Скрипт, который disable WAN, обязан иметь безопасный возврат и не трогать LAN bridge.

После переключения conntrack со старым srcnat умрёт — это нормально. Новый трафик должен идти через masquerade на фактический WAN list, не только на ether1.

FAQ

Сколько ping check-gateway до объявления down?

Зависит от check-gateway реализации; это несколько неудачных проб, не мгновенно. Не ждите failover за 50 мс на SOHO.

check-gateway=bfd?

BFD нужен, чтобы пир его поддерживал. На DHCP WAN провайдера BFD обычно нет. Не включайте «потому что современнее».

Клиенты не переключаются, роутер пингует?

Conntrack/DNS кэш на клиенте, или браузер к старому IP. Новый ping с ПК обязателен. Иногда detect-internet путает — на проде его лучше не оставлять сюрпризом; смотрите /interface detect-internet.

Нужен ли OSPF между двумя MikroTik для failover WAN?

Нет для одного офисного роутера с двумя uplink.

Можно ли оба distance=1 и check-gateway?

Получите ECMP, пока оба up, и частично failover. Это гибрид со своими сюрпризами асимметрии. Для явного резерва — разный distance.