Адаптер QSA в кейдже QSFP28 на SONiC: оптика 10G линкуется, но не сообщает DDM
Мы повторно используем кучу оптики 10G на whitebox-коммутаторе под SONiC, поэтому в несколько кейджей QSFP28 установлены адаптеры формата QSA (10GTek QSA-100A) с обычными модулями 10G SFP+. Механически и электрически всё нормально. Проблема на стороне управления.
- коммутатор: 1U whitebox, SONiC, собранный под эту платформу
- адаптеры: 10GTek QSA-100A, кейдж QSFP28 в SFP+
- оптика: модули 10G SFP+, снятые с выведенного из эксплуатации коммутатора доступа
- та же оптика нормально читается в родном кейдже SFP+ на другой коробке
Что я вижу на адаптированных портах:
QSFP28 cage -> QSA-100A -> 10G SFP+
link: up, traffic passes
inventory: port still handled as a QSFP cage
DDM/DOM: nothing returned for the portЧто уже пробовал:
- поставил второй адаптер и вторую оптику - поведение идентичное;
- перенёс пару в другой кейдж QSFP28 - тот же результат;
- проверил, что оптика отдаёт полную диагностику в родном порту SFP+ на другой коробке.
Это отсутствующие данные диагностики что-то, что пассивный адаптер просто не может передать, или это сторона ПО коммутатора? И если ПО, то где должно быть исправление: на уровне платформы или в общем коде трансивера?
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 7
Прежде чем кто-то полезет в код платформы, один вопрос, который делит проблему пополам. Вставьте в тот же кейдж родной модуль QSFP28: получаете ли вы с него диагностику, или DDM на этом порту мёртв независимо от того, что подключено?
Если родной компонент читается нормально, кейдж и путь I2C в порядке, и всё сводится к тому, как драйвер порта интерпретирует то, что приходит через адаптер. Если родной компонент тоже возвращается пустым, дальше можно не читать эту тему - у вас другая неисправность, и адаптеры тут ни при чём.
Хорошо известное и довольно скучное различие в интерфейсе управления, и адаптер здесь ни при чём.
На стороне SFP задействованы два адреса I2C: данные идентификации живут по 0x50, карта диагностики - по 0x51. Компонент QSFP держит всё под 0x50 и добирается до остального переключением страниц. Так что драйвер, которому сказали, что кейдж это QSFP, ищет страницы по одному адресу и никогда не спрашивает ничего у 0x51. Идентификация возвращается достаточно правдоподобной, чтобы порт поднялся, а диагностика просто никогда не разрешается - именно такая картина, как вы описали.
Исправление должно быть на уровне платформы, а не в оптике и не в адаптере. Каждая платформа поставляет собственную реализацию SfpUtil; в вашей этот порт должен быть объявлен кейджем SFP, а не QSFP. Пока кто-то этого не сделает, DDM/DOM на адаптированных портах останется пустым. После этого модуль читается так же, как в родном кейдже SFP+.
Рабочий линк без ничего в диагностике - вот как выглядит неправильное ПО на этих портах. Это не похоже на маргинальную оптику.
Стоит назвать стандарты, тогда разделение очевидно. Сторона SFP - это SFF-8472, где диагностика живёт в собственной карте памяти, доступной по второму адресу. QSFP и QSFP28 следуют SFF-8636, а более новые компоненты - CMIS, где всё висит на одном адресе за выбором страницы.
Адаптер не может это перемостить. Это пассивный механический и электрический компонент, провода управления идут через него напрямую, и ничего по пути не транслируется. Так что хосту нужно сообщить, какая из двух моделей памяти применяется, прежде чем он прочитает хоть один байт, а адаптер не имеет способа ему это сказать.
Для контраста, та же категория проблемы на оборудовании Dell ONIE кусается сильнее. QSA 407-BBRO с 10GBASE-SR SFP+ 407-BBOU внутри (SFP-10GSR-85), в 40G-портах S4048-ON и в любом порту S6010-ON, оба под OpenSwitch OPX 3.1 dev2:
opx-ethtool корректно определяет носитель, отмечает трансивер как включённый и квалифицированный, admin state up, поддерживаемые скорости 1000, 10000 и 40000 Мбит/с, а порт всё равно никогда не поднимается, какую бы скорость, дуплекс или автосогласование ни настраивали, включая значения по умолчанию. Кто-то открыл это в репозитории platform-config OPX как запрос на улучшение - пожалуйста, заставьте здесь работать QSA - и никто так и не ответил. Он всё ещё открыт.
Это не привязка к вендору и не плохая оптика. Этот кейдж просто никогда не переводится сетевой ОС в режим адаптера, и никакая комбинация настроек интерфейса этого не сделает за вас.
Связано, но, пожалуйста, не смешивайте эти два случая. В исходном сообщении рабочий линк с отсутствующей диагностикой: тракт данных в порядке, неправильно только чтение управления, и патч платформенного SfpUtil это исправляет. Случай Dell - это порт, который вообще никогда не поднимается, потому что профиль порта для этого кейджа изначально не применяется. Это уровнем ниже и требует своего собственного исправления.
Кто-то, торопливо сопоставляя симптомы, может убить день на переписывание кода трансивера, пока их порт лежит по совершенно не связанной причине.
Ещё одна разновидность "адаптер - это программная функция", а не механическая. На Z9264F-ON под OS10 10.5.2.7 использование адаптеров QSA28 для носителя 10G SFP+ означает перевод порта в тот же профиль port-group, который использует breakout-кабель 4x10G:
Профили port-group на этой платформе действуют на пары портов QSFP28, так что применение профиля отключает парный порт в каждой паре. QSA28 - это одиночный интерфейс, но вы всё равно платите breakout-цену: 64 доступных порта становятся 32. Ни руководства пользователя OS10, ни спецификация оптики Dell не документируют однопортовый режим QSA.
Если на этой коробке вам нужно много родного 10G, планируйте потерю 2:1 заранее или ставьте отдельный коммутатор 10G в стойку.
Прежде чем кто-то закажет партию таких штук, я бы добавил две проверки в список. Заявляет ли сетевая ОС вообще поддержку QSA для этой конкретной платформы, и если да, во что обходится её включение: порты, диагностика, или профиль, который тянет вниз соседний кейдж. Механическая посадка никогда не проблема, каждый из этих адаптеров садится в кейдж без жалоб.
Случаи в этой теме различаются только тем, как далеко заходит ПО. На SONiC вы получаете то, что можете исправить сами: объявить порт как SFP, и диагностика вернётся. На платформах Dell выше вы ждёте чужого платформенного кода, и замена адаптеров или оптики никак это не сдвинет.