null

Mikrotik - убийца

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

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

Для выполнения стандартной операции по переводу access порта из одного VLAN в другой необходимо изменить для него pvid:

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

После чего найти этот порт в списке портов старого 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

 

Стоит ли говорить о вероятности совершения администратором ошибки при выполнении таких действий?

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

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

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

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

Впечатление третье. 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 для выполнения рутинной работы по переключению access порта между VLAN. Уложился в 63 строки, правда мог забыть выполнить какие-то проверки. Да и работает он не быстро - несколько секунд на каждый порт...

Вперед