null

Mikrotik - убийца Part II

Отродясь такого не бывало, и опять то же самое

Ⓒ‎ Черномырдин

С момента написания предыдущей статьи количество коммутаторов 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.

Таким образом, для завершения статьи, как нельзя лучше подходит другая цитата того же человека:

Хотели как лучше, а получилось как всегда

Ⓒ‎ Черномырдин

Вперед