Loop за MikroTik: остановить шторм, затем корректный STP/RSTP

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

Петля L2 за MikroTik превращает bridge в генератор broadcast/multicast: CPU 100%, DHCP умирает, Wi‑Fi отваливается. Сначала разорвите петлю: выдерните лишний патчкорд или disable подозрительный /interface bridge port. Потом включите protocol-mode=rstp (или rstp с приоритетами под ваш корень) и loop-protect на access-портах. Не начинайте с reset-configuration и не оставляйте protocol-mode=none на мосте с двумя линками в один коммутатор.

Storm-control/rate limit — подушка, не замена STP. VLAN filtering петлю сам не лечит, если два порта в одном VLAN замкнуты.

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

Все линки «как дискотека», даже простаивающие ПК. /tool profile → bridging. Ping к 192.168.88.1 с джиттером. Похоже на высокий CPU, но RX на LAN-портах лавина, WAN тихий.

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

1. Два кабеля коммутатор↔MikroTik без RSTP.
2. Пользовательский мини-свитч замкнул два офисных порта.
3. protocol-mode=none «для скорости».
4. RSTP включён, но edge=yes на uplink / неправильный path cost, блок не там.
5. VLAN: петля в одном vlan-ids при filtering.
6. Bonding без корректного партнёра (два линка как отдельные access).
7. Wi‑Fi WDS/мост в тот же L2, что ethernet.

Диагностика

Если WinBox уже не дышит — консоль или MAC, или выдернуть кабели с листьев сети.

/system resource print
/interface print stats
/interface bridge print
/interface bridge port print
/interface bridge monitor bridge

Ищите порт с аномальным RX. Disable по одному:

/interface bridge port
set [find interface=ether4] disabled=yes

Если CPU упал — петля через ether4 (или вниз по дереву).

/interface ethernet print

loop-protect-status если функция включена.

Не запускайте torch на пике шторма надолго.

Решение

Сценарий A. Сейчас шторм

1. Отключите недавно добавленный кабель/порт.
2. Дождитесь падения CPU.
3. Не включайте порт обратно, пока нет RSTP.

Сценарий B. Включить RSTP

/interface bridge
set bridge protocol-mode=rstp
/interface bridge port print

Корень STP: офисный ядро-коммутатор обычно priority лучше, чем случайный hEX. На MikroTik:

/interface bridge set bridge priority=0x8000

Значение под вашу схему (меньше = предпочтительнее как root, не ставьте все нули без нужды). Порты к пользователям:

/interface bridge port
set [find interface=ether2] edge=yes

Uplink edge=no. Не помечайте все порты edge.

Сценарий C. loop-protect

/interface ethernet
set ether2,ether3,ether4 loop-protect=on

Не вешайте blindly на WAN ether1, если это не ethernet-bridge WAN.

Сценарий D. После VLAN

Петля может быть внутри VLAN 20 при чистом VLAN 88. Смотрите те же порты в vlan table.

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

CPU в норме, RX портов соответствует трафику, не гигабит broadcast. DHCP renew стабилен. Повторно воткнуть второй кабель в тесте: RSTP блокирует порт (role=backup/discarding в monitor), шторма нет. Логи loop-protect при намеренной петле.

/interface bridge port print
/interface bridge monitor bridge

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

• Петля ниже, на неуправляемых свитчах — RSTP MikroTik не увидит чужой неуправляемый loop за одним портом. Тогда storm на этом порту: disable, искать кабель у пользователя.
• MRP/STP чужого вендора конфликт — унифицируйте или разведите L2.
• Broadcast от infotainment/IP-камеры — не классическая петля, но похож; фильтры/изолированные порты.

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

• RSTP сразу на любом bridge с >1 порта в LAN.
• loop-protect на access.
• Запрет двух линков «для надёжности» без LAG/STP.
• Мониторинг CPU bridging.
• Порт isolation / horizon на гостевых, если нужно.

Как найти кабель петли, когда неуправляемый свитч молчит

RSTP на MikroTik блокирует свои порты. Петля за одним access-портом на дешёвом свитче MikroTik не разведёт: шторм приходит уже с одного etherX. Тогда disable этот порт — CPU падает — ищите второй кабель у пользователя. loop-protect на ethernet часто успевает погасить такой порт сам: смотрите loop-protect-status и лог.

/interface ethernet print
/log print where message~"loop"

Не ставьте protocol-mode=none «чтобы не было STP delay»: секунды сходимости RSTP дешевле часа шторма. edge=yes только на портах к ПК/телефонам, не на uplink к ядру. Если ядро должно быть root, приоритет моста hEX не должен быть ниже ядра без схемы.

Bonding без настройки партнёра превращается в две параллельные L2-линка — мгновенная петля. WDS/мост Wi‑Fi в тот же VLAN, что ethernet, даёт ту же картину. После гашения шторма проверьте DHCP и Wi‑Fi: они «сами» оживают, если это был loop, а не отдельная поломка пула.

FAQ

protocol-mode=stp vs rstp vs mstp?

Для большинства офисов ROS 7: rstp. mstp — если сознательно мапите MSTI на VLAN. stp старый, медленнее сходимости.

horizon=1 на портах?

Горизонт ломает прямую L2 между портами с одним horizon (как split horizon). Полезно для «клиенты не видят друг друга», не полная замена STP на uplink-петлях.

Отключить IGMP snooping поможет?

Не от петли unicast/broadcast storm. Может чуть снизить multicast. Не первый шаг.

Почему WAN не штормит?

Петля в LAN-bridge. WAN вне моста. Если ether1 в bridge — можете заштормить и uplink, это хуже.

BPDU guard есть?

На ROS смотрите актуальные свойства порта (edge, restricted role, bpdu) в вашей 7.12/7.16. Не выдумывайте cisco-команды. edge=yes + loop-protect — практичный SOHO набор.

Можно ли вместо RSTP включить только storm-rate на портах?

Как подушка — да, как замена STP — нет. Storm-control режет уже случившийся шторм, RSTP не даёт петле стать штормом при втором кабеле между управляемыми мостами. На неуправляемом свитче за одним портом RSTP всё равно не спасёт — нужен loop-protect и дисциплина кабелей. Держите оба: rstp на bridge и loop-protect на access. protocol-mode=none ради «меньше delay» возвращает вас к дискотеке линков.