MikroTik Chateau 5G R17 AX — отладка зависшего failover: ловушка не того порта

Короткая история траблшутинга из моего собственного Chateau-сетапа. Интернет «работал», игры начали лагать, задержка до локальных серверов скакнула до ~30 мс вместо привычных 8–12. На поиск ушло около 30 минут — целиком потому, что я смотрел в конфиг, а баг был в кабеле. Записываю, чтобы не потерять ещё один вечер.

Напоминание о сетапе

Chateau 5G R17 AX, RouterOS 7.19.5. Та же конфигурация, что в посте про базовую настройку:

Параметр	Значение
WAN primary	`ether1` — DHCP от cable ISP modem (HFC / DOCSIS)
WAN backup	`lte1` — LTE plan eSIM, distance 2
LAN bridge	`bridge` с `ether2–ether5` + `wifi1` + `wifi2`
LAN subnet	`192.168.50.0/24`
ISP-роутер	ISP modem (cable ISP), HFC-кабель, IPv6 RA

Симптом

Браузер работал. В играх пинг скакал — 30–60 мс там, где я ждал 10. ipinfo.io с ноута:

"ip": "<your-lte-public-ip>",
"city": "<city>",
"org": "AS<lte-asn> <LTE ISP>"

Это LTE eSIM, а не cable ISP. Я всё это время сидел на бэкапе и не замечал. Почему было неочевидно: IPv6 работал нормально, потому что ISP modem сидит на том же L2, что и bridge Chateau, и шлёт IPv6 RA напрямую клиентам. ping6 куда угодно — идеален; на LTE был только IPv4.

Лестница диагностики

Порядок, в котором надо было идти (и пойду в следующий раз).

1. Публичный IP и ASN — всегда первое

curl -s ipinfo.io/json | grep -E '"ip"|"org"'
curl -s -6 ipinfo.io/json | grep -E '"ip"|"org"'

Если IPv4 показывает AS<lte-asn> <LTE ISP>, а IPv6 — AS<cable-asn> <cable ISP>, ты на бэкапе только по v4. Дымящееся дуло.

2. Второй хоп IPv4-трейсроута

traceroute -n -m 4 8.8.8.8

Hop 2	Что значит
`192.168.0.1` (или другой private)	Кабельный WAN → LAN-сторона ISP modem → primary жив
`172.18.x.x` / `100.64.x.x`	LTE CGNAT → ты на бэкапе

Если второй хоп в 172.16.0.0/12 или 100.64.0.0/10 — ты под CGNAT через LTE.

3. Default-маршруты на MikroTik

/ip route print where active dst-address=0.0.0.0/0

Что я ожидал (кабель up)	Что увидел на самом деле (кабель не bound)
`DAd 0.0.0.0/0 192.168.0.1 d=1`	(ничего через ether1)
`DAm 0.0.0.0/0 lte1 d=2`	`As+ 0.0.0.0/0 lte1 d=2`
	`DAm+ 0.0.0.0/0 10.x.x.x d=2`

Два равноценных дефолта через lte1 и ни одного DHCP-маршрута через ether1 → DHCP-клиент так и не забиндился на WAN-порту.

4. Статус DHCP-клиента

/ip dhcp-client print detail

status=searching... дольше ~10 секунд при link-ok на интерфейсе = что-то между модемом и DHCP-клиентом сломано. Всегда одно из:

Не тот физический порт (этот пост)
Не тот интерфейс в конфиге DHCP-клиента
LAN-DHCP на ISP modem ещё не поднялся (только ребут, дай 60 секунд)
На ISP modem висит старый lease, привязанный к другому MAC
Битый кабель / линк автонеготнулся в 10 Mbps

5. Состояние линка на WAN-порту

/interface ethernet monitor ether1 once

Здоровый:

status: link-ok
rate: 1Gbps
full-duplex: yes

Если rate: 10Mbps — у кабеля электрически мертвы 2 пары из 4. Замени кабель до того, как дальше что-то отлаживать: на 10 Mbps half-duplex даже DHCP может не справиться с пачкой offer-ов, и в любом случае ты только что закапил весь дом до 10 Mbps.

6. Состав bridge-портов и группировка свитча

/interface bridge port print
/interface ethernet switch port print

Вот это меня и ударило. Подробнее ниже.

Сам баг

Я переткнул Ethernet-кабель ISP modem в другой порт Chateau (не подумав — отключал что-то и подключил обратно не туда). Конкретно:

ether1 (WAN, вне bridge): туда воткнут десктоп
ether5 (LAN, внутри bridge): туда воткнут кабель от ISP modem

Как это выглядит на роутере:

/interface bridge port print
;;; defconf
0 X ether1     bridge       ...  (ОТКЛЮЧЁН в bridge — defconf помечает как WAN)
1   ether2     bridge  yes  ...
4   ether5     bridge  yes  ...   ← сюда воткнут кабель провайдера
...

ether1 намеренно отключён в bridge в defconf. Именно это делает его WAN-портом. DHCP-клиент привязан к ether1 по той же причине. Поэтому:

Кабель от ISP modem оказался на LAN-стороне: сидел в одном bridge со всеми LAN-устройствами и WiFi-клиентами. DHCP-сервер ISP modem гонял с DHCP-сервером Chateau на 192.168.50.0/24.
ether1 ждал DHCP от десктопа, который, очевидно, DHCP-сервером не работает.
Failover корректно увидел, что у ether1 нет дефолта, и держал всё на lte1.

Тот факт, что IPv6 продолжал отлично работать через ISP modem, заставлял ситуацию ощущаться как «интернет сегодня просто медленный», а не как явный отвал.

Починка

Когда заметил:

Кабель ISP modem → ether1.
Десктоп → любой из ether2–ether5.
На Chateau:
```
/ip dhcp-client set [find interface=ether1] add-default-route=yes default-route-distance=1
/ip dhcp-client renew ether1
```
У меня было add-default-route=no из failover-сетапа (потому что я добавляю рекурсивный маршрут руками — см. базовую настройку, шаг 6). Для быстрой проверки переключил на yes с distance=1. Если хочешь сохранить рекурсивную пробу через 1.1.1.1, оставляй add-default-route=no и доверяй уже существующим статическим маршрутам — они активируются обратно, как только DHCP-lease забиндится.

Проверка:

/ip dhcp-client print
# status=bound, address=192.168.0.<lease>/24
/ip route print where active dst-address=0.0.0.0/0
# DAd 0.0.0.0/0  192.168.0.1  d=1   ← кабель, primary
# As+ 0.0.0.0/0  lte1         d=2   ← LTE, backup

С ноутбука:

curl -s ipinfo.io/json | grep -E '"ip"|"org"'
# "org": "AS<cable-asn> <cable ISP>"   ← cable, not LTE

Уроки (грабли в коллекцию)

Маркируй WAN-порт физически. Кусок скотча на задней панели роутера с надписью WAN ← ISP сэкономил бы весь этот вечер. В следующий раз, когда залезу в железо, — приклею.
ipinfo.io — первая команда, а не десятая. Когда что-то ощущается «не так», публичный IP + ASN мгновенно говорит, какой аплинк активен. Я полез ковырять маршруты до того, как запустил его — потерял пятнадцать минут.
IPv6 врёт тебе — это реальный failure mode на dual-stack с проходным модемом. Если ISP-модем на том же L2, что и LAN, он может отправлять IPv6 RA напрямую клиентам, пока IPv4-путь сломан. Ощущение «интернет работает» обманчивое — при отладке всегда проверяй оба стека отдельно.
link-ok порт всё ещё может быть «не тем». На ether5 линк автонеготнулся в 1 Gbps full-duplex и выглядел здоровым — потому что был здоровым гигабитным линком, просто к другому устройству. State линка говорит про кабель, а не про топологию.
bridge port print — источник истины про роль WAN/LAN, а не номер порта. Если что-то перетыкаешь — запускай эту команду до того, как что-то втыкать.
Только что перезагруженному ISP modem нужна минута. Аптайм меньше ~2 минут может означать, что LAN-сторона DHCP ещё не поднялась. Подожди, потом renew. Не начинай ломать конфиг.
bound ≠ default route. Статус DHCP-клиента bound означает только, что lease выдан. add-default-route и реальную таблицу маршрутов проверяй отдельно. Они могут расходиться.

Бандл быстрых проверок

Для 30-секундного «всё ли в порядке» — паста на Chateau:

:put "--- DHCP ---"
/ip dhcp-client print detail
:put "--- Routes ---"
/ip route print where active dst-address=0.0.0.0/0
:put "--- WAN link ---"
/interface ethernet monitor ether1 once
:put "--- LTE ---"
/interface lte monitor lte1 once
:put "--- Bridge ports ---"
/interface bridge port print

И на клиенте:

curl -s ipinfo.io/json | grep -E '"ip"|"org"'
curl -s -6 ipinfo.io/json | grep -E '"ip"|"org"'
traceroute -n -m 4 8.8.8.8

Если все они согласны на «кабель, primary, distance 1, второй хоп — LAN-сторона ISP modem» — всё ок. Если кто-то расходится — начинай с шага 1 лестницы выше.

Связанные посты: обзор · базовая настройка · VPN до дома · хардненинг