null

Mikrotik - убийца

Так получилось, что по работе столкнулся с несколькими коммутаторами MikroTik серии CRS3XX, которые позиционируются как серьёзные ентерпрайзные железки, в отличие от более домашнего оборудования. И захотелось мне поделиться некоторыми личными впечатлениями от их эксплуатации.

Впечатление первое. Документация.

Согласно примерам, приведённым в документации, для access порта должен быть установлен pvid и этот порт должен быть добавлен в список untagged портов для соответствующего VLAN. Т.е. для выполнения стандартной операции по переводу access порта из одного VLAN в другой необходимо:

- изменить для него pvid:

/interface bridge port
set [ find interface=ether39 ] pvid=XXX

- найти порт в списке untagged портов старого VLAN в примерно таком выводе (вывод команды немного сокращён):

[admin@switch] > /interface bridge vlan export terse
/interface bridge vlan add bridge=bridge1 tagged=uplink untagged=ether1,ether3,ether5,ether7,ether9,ether11,ether13,ether15,ether17,ether19,ether21,ether23,ether25,ether27,ether29,ether31,ether33,ether35,ether37,ether39,ether41,ether43,ether45,ether46 vlan-ids=YYY
/interface bridge vlan add bridge=bridge1 tagged=uplink untagged=ether2,ether6,ether8,ether10,ether12,ether14,ether16,ether18,ether20,ether22,ether24,ether26,ether28,ether30,ether32,ether34,ether36,ether38,ether40,ether42,ether44 vlan-ids=XXX

- удалить его из этого списка:

/interface bridge vlan
set [ find vlan-ids=YYY ] untagged=ether1,ether3,ether5,ether7,ether9,ether11,ether13,ether15,ether17,ether19,ether21,ether23,ether25,ether27,ether29,ether31,ether33,ether35,ether37,ether41,ether43,ether45,ether46

- добавить порт в новый VLAN:

/interface bridge vlan
set [ find vlan-ids=XXX ] untagged=ether2,ether6,ether8,ether10,ether12,ether14,ether16,ether18,ether20,ether22,ether24,ether26,ether28,ether30,ether32,ether34,ether36,ether38,ether39,ether40,ether42,ether44 vlan-ids=XXX

Но, как подсказали в комментариях к этой статье, и как было проверено на реальном оборудовании, добавлять access порт в список untagged не нужно, достаточно установить для порта требуемый pvid, т.е. необходимо выполнить только первое из приведённых действий.

Впечатление второе. CLI.

Итак, access порты не нужно добавлять в список untagged, что существенно облегчает сопровождение коммутаторов уровня доступа. Но, если на коммутаторе много тэгированных портов с доступом в разные VLAN, то всё таки получаем описанную выше проблему с необходимостью редактирования больших списоков портов. Т.е. смотрим в примерно такой вывод:

[admin@switch] > /interface bridge vlan export terse
/interface bridge vlan add bridge=bridge1 tagged=swX61-1,swX61-2,swX75-1,swX75-2,swX81-1,swX81-2 vlan-ids=XXX
/interface bridge vlan add bridge=bridge1 tagged=swX61-1,swX61-2,swX70-1,swX74-1,swX74-2,swX75-1,swX75-2,swX81-1,swX81-2 vlan-ids=YYY

И, например, для переноса порта swX70-1 из VLAN YYY в VLAN XXX выполняем две команды:

/interface bridge vlan set [ find vlan-ids=YYY ] tagged=swX61-1,swX61-2,swX74-1,swX74-2,swX75-1,swX75-2,swX81-1,swX81-2 
/interface bridge vlan set [ find vlan-ids=XXX ] tagged=swX61-1,swX61-2,swX70-1,swX74-1,swX74-2,swX75-1,swX75-2,swX81-1,swX81-2

На сколько легко можно ошибиться при выполнении такой операции?

А что будет, если удалить какой либо, например, агрегированный интерфейс? Правильно. После этого он останется в списке портов коммутации с каким-то странным именем:

[admin@switch] > /interface bridge port export
add bridge=bridge1 interface=*2D

Эту запись надо удалить командой:

/interface bridge port remove [ find interface=*2D ]

И также необходимо исправить списки tagged портов для VLAN, так как в них появятся значения вида:

add bridge=bridge1 tagged=swX70-1,swX70-2-2,*2D vlan-ids=X
add bridge=bridge1 tagged=swX70-1,swX70-2-2,*2D vlan-ids=Y
add bridge=bridge1 tagged=swX70-1,*2D,swX74-1,swX74-2 vlan-ids=Z

Если порт был добавлен в большое количество VLAN, ручное его удаление из всех VLAN потребует и времени, и аккуратности.

Впечатление третье. CLI.

Допустил небольшую опечатку в команде, пропустив букву "e" перед знаком равенства:

/interface bridge port
set [ find interfac=ether39 ] bpdu-guard=yes edge=yes

для исправления ошибки мне потребовалось подключаться к консольному порту коммутатора, так как bpdu-guard был включен для всех портов, включая порт, подключенный к вышестоящему коммутатору, через который я и попадал на этот коммутатор. При этом старый дедовский метод попросить кого либо "выключить и включить", чтобы откатиться к предыдущему конфигу не работает, так как изменения сохраняются сразу при выполнении команды.

Для того, чтобы избежать такой ситуации, перед выполнением любой операции, даже если Вам она кажется совершенно безопасной, на коммутаторе лучше включать safe mode.

Впечатление четвёртое. LACP.

Сразу после установки нового коммутатора была настроена агрегация с использованием протокола LACP. После подключения оборудования к портам внезапно выяснилось, что агрегированный интерфейс не поднимается. Обновление прошивки до последней стабильной проблему не решило. После чего была заведена заявка на сайте MikroTik, на которую был получен ответ...

Впечатление пятое. Поддержка.

Ответ поддержки звучал так:

Similar issues have been reproduced in our labs running 6.47.4 version, but they are fixed with the latest RouterOS testing version 6.48beta40.

То есть:

  1. Поддержка рекомендует установить testing прошивку для продуктивного использования.
  2. При выпуске стабильных прошивок не проводится тестирования в достаточном объёме, чтобы заметить такие серьёзные проблемы, как неработающая агрегация каналов.

Впечатление шестое. Необъяснимое.

После некоторого количества месяцев работы коммутатора пользователи начали жаловаться на тормоза в работе сети. После длительных поисков виновника подозрения пали на коммутатор MikroTik, и был запущен ping между несколькими парами узлов, включенных в этот коммутатор. Результат меня, скажем, удивил:

3600 packets transmitted, 3474 received, 3% packet loss, time 921343ms

Я даже не мог предположить, что на цепочке сервер - коммутатор - сервер можно получить 3% потерь. При этом и сервера, и коммутатор имеют 10G интерфейсы, а всплески трафика с трудом дотягивали до 400Mbit/s. Также была замечена ненормальная нагрузка на процессор коммутатора. Для решения проблемы потребовалось... перезагрузить коммутатор.

Впечатление седьмое. Стекирование.

В продолжение предыдущего посыла - да, у MikroTik нет ни стекирования, ни поддержки модного сейчас MC-LAG. Любая перезагрузка коммутатора - downtime.

Впечатление восьмое. MTU.

В связи с особенностями сети на оборудовании используются jumbo фреймы и, соответственно MTU на интерфейсах поднят до 9000. Для начала меня смутило то, что разрешение на передачу jumbo фреймов на современном коммутаторе не сделано по умолчанию. Но это ерунда на фоне того, что некоторых случаях после кратковременного падения линка на обоих портах агрегированного интерфейса иногда​​​​​​​ на коммутаторе перестают передаваться jumbo фреймы для этого интерфейса. А для быстрого решения этой проблемы достаточно... перезагрузить коммутатор.

Впечатление девятое. Опять необъяснимое.

После выполнения команды по добавлению нового агрегированного интерфейса для нового узла:

/interface bridge port
add bridge=bridge1 interface=newnode

я потерял доступ ко всем старым узлам. После отката этой команды доступ вернулся, а после перезагрузки коммутатора и повторного добавления проблема не повторилась.

Впечатление десятое. Продуманность web интерфейса.

Если зайти браузером и попытаться выбрать временную зону, то у Вас ничего не получится. Потому для выбора нужной временной зоны нужно её найти в списке из всех известных в linux временных зон, список которых занимает много страниц, возможности поиска в интерфейсе не предусмотрено, а javascript раз в секунду обновляет текущее время, каждый раз сбрасывая Вас на первый пункт в этом списке.

Впечатление одиннадцатое. Надёжность.

В один прекрасный день от zabbix приходит уведомление, что один из коммутаторов недоступен, а один из сотрудников сообщает, что на этом коммутаторе зажёгся индикатор Fault. Пытаемся понять причину включения индикатора:

[admin@switch] /system health> print

action timed out - try again, if error continues contact MikroTik support and send a supout file (13)

Хорошо, давайте выполним ставшую уже привычной операцию, т.е. перезагрузим коммутатор:

[admin@switch] > /system reboot
Reboot, yes? [y/N]:
y
system will reboot shortly
action timed out - try again, if error continues contact MikroTik support and send a supout file (13)

Зато через какое-то время zabbix отчитывается, что данный коммутатор перезагрузился. А потом ещё раз, и ещё. А ведь я успел развернуть только несколько коммутаторов, из закупленных нескольких десятков...

Впечатление двенадцатое. А что с более домашним оборудованием?

Попросили меня настроить на базе hAP ac² временную точку доступа. Включаем, заходим на web интерфейс, сразу получаем wizard, который предлагает переключиться в режим "просто точка доступа", который то мне и нужен. Соглашаемся, переключаемся. После чего полностью теряем управление железкой. После нескольких сбросов в настройки по умолчанию опытным путём устанавливаем, что перед переводом устройства в режим точки доступа надо было выпилить все правила фильтрации трафика.

Итого

Учитывая количество закупленных коммутаторов, выбора как бы нет. Поэтому возможно продолжение этой статьи. Также по ходу работы с оборудованием потихоньку пишется скрипт на python для "очеловечивания" части рутинной работы, в первую очередь по назначению VLAN для тэгированных и нетэгированных портов.

Вперед