Edgecore AS9716-32D: sfputil расшифровывает модуль 400G QSFP-DD как QSFP28 под PDDF
Поднимаем пару AS9716-32D в качестве 400G spine в лаборатории, на community-сборке SONiC со слоем PDDF. Проблема не в оптике, линк с соседом поднимается нормально, но всё, что коммутатор о ней сообщает, - неправда.
- Edgecore AS9716-32D (x86_64-accton_as9716_32d-r0)
- community-сборка SONiC с PDDF для этой платформы
- модуль 400G QSFP-DD (производства NeoPhotonics) в первом порту
Само чтение проходит успешно, модуль отображается в списке, а порт определяется как QSFP28:
admin@sonic:~$ sfputil show eeprom
Ethernet0: SFP EEPROM detected
Identifier: QSFP28 or later
Vendor Name: NeoPhotonicsИменно на этой строке идентификатора всё и ломается. Это модуль QSFP-DD, поэтому байты ниже расшифровываются по набору полей SFF-8636, а не CMIS, и все последующие поля выглядят как шум.
Что уже проверено:
- сам модуль исправен, тот же экземпляр корректно читается на другой платформе, и на дальнем конце видят свет;
- переустановка модуля и перенос в другой порт ничего не меняют, все порты 400G ведут себя одинаково;
- в описании устройства PDDF эти порты объявлены как QSFP28 и привязаны к optoe1.
Это последнее и есть весь ответ - портам QSFP-DD просто нужно другое устройство optoe, и правка описания платформы это принятый способ исправить проблему, или что-то выше по стеку тоже должно узнать о типе порта?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 4
Ваш симптом в точности совпадает с проблемой привязки, так что дальше копать оптику не нужно.
Описание устройства PDDF для AS9716-32D объявляет порты 400G как QSFP28 и привязывает их к optoe1. optoe1 отдаёт раскладку EEPROM по SFF-8636, которую используют QSFP+ и QSFP28, поэтому модуль CMIS читается по неправильной карте, и всё, что идёт после идентификатора, выглядит как шум. Тип порта, который вы видите, вообще не определяется - это просто то, что написано в описании.
QSFP-DD следует стандарту CMIS, а CMIS обслуживается через optoe3. Исправление - поменять оба поля в описании устройства PDDF для этих портов: тип с QSFP28 на QSFP-DD, и драйвер с optoe1 на optoe3. Я проверил это на том же устройстве с модулем 400G NeoPhotonics, и после изменения
sfputil show eepromвозвращает корректно расшифрованный модуль.Два предостережения. Это платформенные данные, так что обновление образа с радостью вернёт старое описание обратно, если изменение не встроено в сам собираемый вами образ. И в апстриме именно это изменение было одобрено, но pull request закрыли без слияния - работу включили в более позднее изменение, так что не считайте, что ваш образ уже это несёт. Сначала прочитайте описание устройства для своей платформы, и через минуту станет ясно, есть ли вообще что искать.
Прежде чем трогать какие-либо файлы платформы, выложите сырой дамп:
sudo sfputil show eeprom -dна этом порту. Если все байты на месте и хромает только интерпретация, это проблема привязки, а не модуля, и на это стоит потратить десять минут, прежде чем кто-то заговорит об RMA.Вторую половину вы уже сами и ответили. optoe1 - это вариант для SFF-8636, используемый QSFP+ и QSFP28, поэтому модуль CMIS, прочитанный через него, выходит искажённым начиная с идентификатора - это ровно тот вывод, который вы вставили. Раз в описании для порта QSFP-DD указан optoe1, со стороны модуля подозревать больше нечего.
Так что выложите ещё и соответствующие строки описания устройства PDDF для одного из этих портов. Это покажет, ошибка только в поле драйвера или ещё и в заявленном типе порта.
Так и было. Тип порта на QSFP-DD, драйвер на optoe3, перезагрузка - и модуль теперь расшифровывается корректно,
sfputil show eepromбольше не называет порт QSFP28. Я внёс изменение в собираемый нами образ, а не патчил работающий коммутатор, как раз из-за упомянутого выше момента с обновлениями.Честное замечание для тех, кто найдёт это позже: это исправляет только чтение EEPROM, и ничего больше. Остальная обвязка для трансиверов на этой платформе всё ещё имеет свои особенности, и я бы не назвал устройство полностью доведённым до ума.
Раз уж вы упомянули оставшиеся особенности - вот ещё одна, которая вас ждёт на той же платформе. На нашем AS9716-32D (x86_64-accton_as9716_32d-r0) с master-сборкой SONiC команда
sudo sfputil show presenceпоказывает установленные модули как Present и нормально читает их EEPROM, аshow interfaces transceiver presenceсообщает по всем портам Not present. В syslog повторяется:а чтение EEPROM через CLI падает с RuntimeError('PddfEeprom is not Programmed'). Появляется случайным образом после перезагрузки, и первопричину так никто и не выложил, так что единственная проверка присутствия, которой я там доверяю - это sfputil.
Не связано, но из той же области: эти две команды также, как известно, расходятся в названиях ключей в ветке 202012, что было исправлено в 202205. Если ваши выводы отличаются формулировками, а не содержанием, то дело, скорее всего, именно в этом.