AST2400, eno1 NO-CARRIER и, казалось бы, при чем здесь Google Chrome?

В этот раз у нас никаких гайдов, новостей, а только классические «сисадминские байки» про бубны, магию и вот это вот все. История будет немного поучительная, немного про собственную глупость, но кому-то может оказаться в дальнейшем полезной.

Я всегда считал, что баги прошивок случаются у кого-то другого, и меня это не касается. Но не в этот раз.

История одного бага, собственной глупости и «шаманства» ниже.

На производстве несколько лет исправно работало несколько серверов QuantaGrid-S1Q и поступила задача вывести их из одного проекта и переключить в другой проект, а также скоммутировать на другом оборудовании.

Минутка бесплатной рекламы: мне очень нравятся эти сервера. Инженеры разместили в 1U 12 HDD, 4 SSD на передней панели и 2 SSD сзади. Получается один такой блок, которым можно расширять тот же Ceph. Тут и HDD под хранение, и SSD под кэш\журнал, и небольшие SSD под ОС.

Примечательно, что извлекать\менять все диски можно без остановки сервера, что не характерно, например, для аналогичных серверов SuperMicro.

Вернемся к сути. Ранее оборудование было подключено с помощью SFP модулей Avago к коммутаторам Cisco Nexus, работало и не вызывало нареканий (а может должно было?). Сейчас же сервера были переключены на коммутаторы Arista с помощью родных twinax кабелей.

Каждый сервер оборудован двумя портами 10gbe, подключенными к разным коммутаторам. На сервере установлена CentOS 7.7 с последними обновлениями, собран LACP, все выглядит хорошо.

Начинаем проверять отказоустойчивость сети. Со стороны коммутатора отключается один порт – сеть работает. Включаем назад – работает. Отключаем второй порт – сеть на сервере полностью пропадает. Уже странно не так ли? Первый порт ведь включен обратно. Включаем второй порт, сеть не появляется.

Запускам интерфейс удаленного управления, подключаемся к консоли, смотрим. Оба интерфейса на сервере «лежат» с пометкой NOCARRIER и намекают, что у нас нет физики.

Смотрим логи, в логах много сообщений о том, что интерфейс поднимается на скорости 10gbe, затем сразу же падает.  Это может продолжаться бесконечно.

Конечно, сразу начинают появляться мысли о неподдерживаемых кабелях\коммутаторах, раньше ведь все работало.

В сервере установлен сетевой адаптер Intel с драйвером ixgbe:

# ethtool -i eno1
driver: ixgbe
version: 5.1.0-k-rh7.7

Включаю поддержку несовместимых модулей SFP:

vi /etc/modprobe.d/ixgbe.conf

Добавляем поддержку:

options ixgbe allow_unsupported_sfp=1

Перезагружаем драйвер:

rmmod ixgbe; modprobe ixgbe

Эффекта нет. Интерфейсы все так же в статусе NO-CARRIER. Перезагружаю сервер, сервер загружается, ничего нового. Сети нет, в логах интерфейсы все так же пытаются подняться, но не могут.

Пробуем обновить драйвер ixgbe до самой свежей версии на данный момент (5.6.3). Загружаем RPM-пакет, ставим. Толку, естественно, нет.

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

С системой сделал все что мог. Теперь настало время обновить прошивки. Штатно, через Web-интерфейс BMC предлагает обновить себя и BIOS. Начинаю, конечно же, с BMC.

BMC (Megarac SP), работает на чипе AST2400.
Версия BMC до обновления: 3.19;
Версия BMC доступная для загрузки: 3.33.

В поиске по патчноутам к прошивке находится несколько записей по ключевым словам LOM/NIC, но ничего, похожего именно на мою проблему я не встретил, либо читал невнимательно.

Процедура обновления следующая:

  1. BMC переходит в т.н. Update Mode;
  2. Указывается путь до Firmware;
  3. Выполняется проверка\установка.

Все, как и везде, думал я. Перехожу в Update Mode и наблюдаю следующую картину:

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

И вот «Чудо», «Магия» или как это еще назвать, появляется пинг до сервера. Этакий Workaround, нет сети на сервере? – запусти обновление прошивки, оно все равно не пройдет, но сеть восстановится.

Проверил еще раз, отключаем-подключаем порты, сеть не появляется. Запускаем «обновление» – сеть появляется. Смотрю логи:

Apr 14 22:13:03  kernel: ixgbe 0000:03:00.0 eno1: NIC Link is Up 10 Gbps, Flow Control: RX/TX
Apr 14 22:13:03  NetworkManager[1300]: <info>  [1586880783.0423] device (eno1): carrier: link connected
Apr 14 22:13:03  NetworkManager[1300]: <info>  [1586880783.1270] device (bond0): carrier: link connected
Apr 14 22:13:03  kernel: bond0: link status definitely up for interface eno1, 10000 Mbps full duplex
Apr 14 22:13:03  kernel: bond0: Warning: No 802.3ad response from the link partner for any adapters in the bond
Apr 14 22:13:03  kernel: bond0: first active interface up!

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

Опять отключаем-подключаем сеть, но теперь не выполняем обновление, а просто перезапускаем BMC.

Подключаемся к нему по SSH и короткой строкой:

reset SP

Сеть на сервере появляется. Виновник торжества определен, а значит нам нужно работать с ним.

Думаю, как же обновить BMC. Вариантов немного:

  1. Из-под ОС;
  2. Через Web.

Поскольку физического доступа к серверу нет (на улице карантин и вообще не хочется куда-то идти под ночь), а обновлять BMC через ОС, к которой подключен через BMC еще то занятие, первый вариант отпадает.

Пытаюсь думать, что же не так с интерфейсом обновления, который предоставляет Web и логикой понимаю, что прошивку где-то он должен запросить в любом случае.

И тут на помощь приходит народная мудрость – если где-то что-то не открывается, попробуй через Internet Explorer.

Подключаюсь к BMC через старый добрый IE11. Перехожу в Update Mode и вот оно:

Появилось заветное окно с предложением указать путь к свежему Firmware. Загружаю версию BMC 3.33, выполняется обновление, контроллер перезагружается, а сеть появляется.

Пробуем ради интереса отключить порты во всевозможных комбинациях, первый-второй-оба, сеть появляется, как и должна, интерфейсы в системе переходят в состояние UP, больше никаких NO-CARRIER.

Казалось бы – победа, но осадок остался, потому что в какой-то момент уже начал верить в магию и шаманов, да и много времени ушло прежде чем выполнить «банальное обновление прошивок».

Но есть и положительный момент – если бы я начал свой путь по запуску серверов сразу с конца этой статьи, то проблема решилась бы сама собой и этого бы даже никто не заметил. Но разве так интересно?

В качестве заключения:

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

Обновлять ли прошивки сразу при включении сервера? Скорее да, чем нет, но предварительно дважды убедиться в совместимости прошивки, которую вы загрузили с версией вашей ОС и используемой версией драйвера. У многих вендоров есть HCL (hardware compatibility list), который показывает соотношение всех версий прошивок, драйверов и ос, работа при которых гарантируется. При несоответствии вашей конфигурации и того, что заявлено в HCL вам могут даже отказать в технической поддержке.

И никогда не стесняйтесь открывать Internet Explorer и проверять работу BMC через него, если вам кажется, что что-то идет не так как должно в вашем любимом браузере.

Справедливости ради, при обновлении BMC до версии 3.33 в браузере Google Chrome теперь так же появляется заветное окно с предложением загрузить прошивку.

Leave a Reply

Your email address will not be published. Required fields are marked *