Отродясь такого не бывало, и опять то же самое
Ⓒ Черномырдин
С момента написания предыдущей статьи количество коммутаторов Mikrotik не уменьшилось, а совсем даже наоборот, а значит пришла пора поделиться новыми особенностями эксплуатации данного оборудования. Стоит отдельно отметить, что в эксплуатируемой сети используются именно коммутаторы серии CRS3XX, соответственно особенности связаны именно с эксплуатацией оборудования Mikrotik в данной роли, опыта использования оборудования Mikrotiik качестве маршрутизаторов и межсетевых экранов нет. И почему-то не хочется его получать...
Особенность первая
В случае, если на одном из access портов коммутатора начинаются проблемы из-за плохого кабеля и/или "странного" оборудования, и на этом порту постоянно происходит flap линка:
oct/03 22:11:53 interface,info ether14 link up (speed 10M, full duplex)
oct/03 22:11:54 interface,info ether14 link down
oct/03 22:11:56 interface,info ether14 link up (speed 10M, full duplex)
oct/03 22:11:57 interface,info ether14 link down
oct/03 22:11:59 interface,info ether14 link up (speed 10M, full duplex)
oct/03 22:12:00 interface,info ether14 link down
oct/03 22:12:03 interface,info ether14 link up (speed 10M, full duplex)
oct/03 22:12:04 interface,info ether14 link down
oct/03 22:12:06 interface,info ether14 link up (speed 10M, full duplex)
oct/03 22:12:07 interface,info ether14 link down
oct/03 22:12:09 interface,info ether14 link up (speed 10M, full duplex)
oct/03 22:12:10 interface,info ether14 link down
oct/03 22:12:12 interface,info ether14 link up (speed 10M, full duplex)
oct/03 22:12:13 interface,info ether14 link down
oct/03 22:12:15 interface,info ether14 link up (speed 10M, full duplex)
oct/03 22:12:16 interface,info ether14 link down
oct/03 22:12:18 interface,info ether14 link up (speed 10M, full duplex)
oct/03 22:12:19 interface,info ether14 link down
oct/03 22:12:21 interface,info ether14 link up (speed 10M, full duplex)
oct/03 22:12:22 interface,info ether14 link down
oct/03 22:12:24 interface,info ether14 link up (speed 10M, full duplex)
oct/03 22:12:25 interface,info ether14 link down
oct/03 22:12:28 interface,info ether14 link up (speed 10M, full duplex)
oct/03 22:12:29 interface,info ether14 link down
То это приводит к тому, что начинает тормозить весь коммутатор и проблемы испытывают все пользователи, подключенные к данному коммутатору, так как он начинает терять до 75% кадров:
8 packets transmitted, 2 packets received, 75.0% packet loss
Понятно, что 8 ICMP echo request пакетов для статистики это маловато, но и жалобы пользователей, и периодические сообщения от системы мониторинга о недоступности коммутатора по SNMP, и тормоза при подключении к коммутатору по ssh также подтверждают наличие проблемы.
Если нет возможности разобраться с проблемой на интерфейсе на физическом уровне, то для её решения достаточно выключить проблемный интерфейс:
/interface ethernet
set [ find default-name=ether14 ] disabled=yes
После выполнения данного действия около 22:15 загруженность CPU падает с ~20% до обычных ~8%:

Но 20% загруженности CPU это вроде не много, и почему в итоге link flap на отдельно взятом порту приводит к такому поведению коммутатора для меня не очень понятно, но сталкиваюсь я с этим уже не первый раз, и именно очередное возникновение этой проблемы и побудило меня к написанию данной статьи.
Особенность вторая
С этой особенностью я столкнулся еще в 2021 году, и, возможно, проблему действительно уже исправили в новых прошивках, но, первая статья была написана раньше, чем я с ней столкнулся, а проблема сама по себе довольно интересная.
Топология сети в упрощённом виде выглядела так:

В данной топологии sw370-1 это коммутатор производства Huawei, остальные коммутаторы - Mikrotik.
В один прекрасный субботний день электрики на несколько часов обесточивают серверную, из-за чего оказываются выключены коммутаторы sw370-1 и sw370-2-1. По окончании работ я успешно подключаюсь к части сети, подключенной через sw370-1, но вся остальная сеть оказывается недоступна. Берём руки в ноги и едем в ВУЗ, где подключаемся в консольный порт коммутатора sw370-2-1 и начинаем диагностику.
Так как только у коммутатора sw370-1 приоритет установлен в 0, то он должен быть выбран к качестве корневого моста, но, проверка роли соответствующего порта на sw370-2-1 показывает, что у него выбрана роль alternate:
interface: sw370-1
status: in-bridge
port-number: 13
role: alternate-port
edge-port: no
edge-port-discovery: yes
point-to-point-port: no
external-fdb: no
sending-rstp: yes
learning: no
forwarding: no
root-path-cost: 10
designated-bridge: 0.DC:21:E2:E8:09:91
designated-cost: 0
designated-port-number: 1
hw-offload-group: switch1
А в качестве корневого выбран порт в сторону другого Mikrotik:
interface: sw375-2
status: in-bridge
port-number: 5
role: root-port
edge-port: no
edge-port-discovery: yes
point-to-point-port: yes
external-fdb: no
sending-rstp: yes
learning: yes
forwarding: yes
internal-root-path-cost: 660
designated-bridge: 0x8000.C4:AD:34:DB:EB:0D
designated-internal-cost: 650
designated-port-number: 2
hw-offload-group: switch1
Что объясняет недоступность остальной части сети с коммутатора sw370-1, так как пользовательский трафик на alternate порту блокируется.
"Немного" удивившись увиденному, я отключаю порт в сторону sw375-2, и... корневым становится порт sw375-1. Проверяю вывод команды
/interface bridge monitor bridge1 once
и вижу там странное:
state: enabled
current-mac-address: 48:8F:5A:3A:0D:2E
root-bridge: no
root-bridge-id: 0.DC:21:E2:E8:09:91
regional-root-bridge-id: 0x8000.48:8F:5A:3A:0D:10
root-path-cost: 10
root-port: sw375-1
port-count: 15
designated-port-count: 12
mst-config-digest: ac36177f50283cd4b83821d8ab26de62
fast-forward: no
Т.е. коммутатор "видит" правильный root bridge id, но в качестве корневого порта выбирает другое устройство, с более низким приоритетом, при этом посчитав какую-то странную стоимость достижения корневого порта.
В моменте проблему удалось решить выключив все порты, после чего сначала включить порт в сторону правильного корневого коммутатора, и после этого даже была заведена заявка у вендора, который в итоге ответил:
A similar issue where incorrect internal-root-path was calculated was repeated in our labs, we will try to fix this in future RouterOS releases, but I cannot provide an ETA yet.
Также немного самостоятельно поковырявшись в проблеме я обнаружил интересную особенность - оказалось, что, например, коммутаторы Huawei по умолчанию в качестве region-name используют свой MAC, а даже в официальной документации в команде включения MSTP нет указания region-name:
/interface bridge
set bridge protocol-mode=mstp vlan-filtering=yes
И в таком случае Mikrotik в качестве region-name использует пустое значение, что, теоретически, могло быть одним из триггеров описываемой ситуации, так как у всех коммутаторов Mikrotik в данной топологии использовался region-name="", а на коммутаторе Huawei, на котором MSTP включён по умолчанию, region-name был равен его MAC адресу. Как один из шагов по предотвращению повторения ситуации на всех коммутаторах был настроен одинаковый region-name:
/interface bridge
add dhcp-snooping=yes name=bridge protocol-mode=mstp region-name=CS vlan-filtering=yes
Также, в такой топологии имеет смысл повысить приоритет коммутатора sw370-2-1, чтобы он не пытался считать корневым коммутатором один из access коммутаторов сети, и его конфигурация была приведена к виду:
/interface bridge
add dhcp-snooping=yes mtu=9000 name=bridge priority=0x4000 protocol-mode=mstp region-name=CS vlan-filtering=yes
И, наконец, чтобы окончательно защитить sw370-2-1 от потенциального появления в сети fake root bridge ограничиваем роль не root портов включив root guard:
/interface bridge port
add bridge=bridge interface=sw431-1 restricted-role=yes
add bridge=bridge interface=sw431-2 restricted-role=yes
add bridge=bridge interface=sw375-1 restricted-role=yes
add bridge=bridge interface=sw375-2 restricted-role=yes
К слову говоря, согласно документации на момент написания статьи на LTS версии прошивок restricted-role можно использовать только при использовании MSTP.
Особенность третья
В настройках bridge мной тихо было упомянуто использование dhcp snooping. И, например, на оборудовании Huawei это довольно мощный инструмент, позволяющий отслеживать какой IP адрес был назначен которому пользователю и блокировать трафик с чужим IP, о чём я писал в другой статье.
А что же у Mikrotik? А у Mikrotik, к сожалению, dhcp snooping ограничивается только защитой от fake dhcp server. Ни о сохранении информации о назначенных IP нет, ни, тем более, о блокировании использования чужого IP тут, к сожалению, речи не идёт.
Особенность четвёртая
В различных материалах уважаемого мной Huawei долго рассуждают на тему использования Native AC - функционала контроллера WiFi сети на коммутаторе, который позволяет избежать узкого места в виде "тонкого" канала до выделенного контроллера. RouterOS, в соответствии с своей тенденцией предоставлять максимум возможностей на любом оборудовании, также позволяет использовать в качестве контроллера WiFi сети коммутаторы серии CRS3XX.
Так как из изначальной парочки hAP ac² в качестве временного решения WiFi сеть выросла до чуть более десятка таких устройств, мной была предпринята попытка перенести функционал контроллера WiFi сети с одного из WiFi маршрутизаторов на коммутатор CRS326-24S+2Q+ - тот самый sw370-2-1 из топологии выше. Сказано - сделано. И это даже как-то какое-то время работало. Но иногда стали наблюдаться странные потери кадров в сети. А после того как я одновременно перезагрузил десяток "точек доступа", этот самый коммутатор на какое-то время вообще выпал из сети , полностью положив всю сеть.
Судя по графикам загруженности CPU, которые, к сожалению, не сохранились, старенький одноядерный MIPS 24Kc, который установлен в этом 24 x 10Gb + 2 x 40Gb коммутаторе, банально не справился с задачами WiFi контроллера. Пришлось вернуть контроллер обратно на hAP ac², в котором установлен более шустрый четырёхядерный ARMv7.
Таким образом, для завершения статьи, как нельзя лучше подходит другая цитата того же человека:
Хотели как лучше, а получилось как всегда
Ⓒ Черномырдин