Как каждая NOS проверяет модуль

Между «модуль обнаружен» и «порт поднят» каждая сетевая ОС проверяет идентификацию модуля. Что она сравнивает, что делает при несовпадении и может ли администратор это обойти — различается по вендору, платформе и релизу, и в этой разнице вся тема совместимости трансиверов. Здесь поведения выложены бок о бок, как их документируют вендоры и как они наблюдаются в поле, чтобы модуль, прочитанный на столе, можно было оценить относительно коробки, для которой он предназначен.

Что может проверяться

Поведение по вендорам

Публичные команды и поведение по свежим релизам; детали зависят от платформы и версии.

Где обход у вендора существует, он обычно предлагается как есть: модуль работает, но вендор не обязуется поддерживать сочетание. Решения по парку — за владельцем сети (Сторонние модули).

Чему должен удовлетворять «закодированный под вендора X»

Как это выглядит со стороны стола: Вендор-лок и кодирование, Перекодировка EEPROM.

Чтение отказа

Команды по NOS, чтобы увидеть эти состояния: Проверка оптики на коммутаторе.

Изменения с обновлениями софта

Вендоры ужесточают или ослабляют проверки между релизами: новая валидация сигнатур, новые списки поддерживаемой оптики, убранные скрытые команды, изменённая обработка DDM. Парк сторонней или закодированной оптики, работавший вчера, после обновления может уйти в errdisable (Матрицы совместимости и прошивки).

В CodingBox

CodingBox показывает точные байты, которые читает каждая проверка выше — имя вендора, PN, суммы, коды соответствия, класс мощности, — а база кодов хранит идентификации, которые принимает тот или иной класс платформ. После кодирования проверяйте на тестовом порту; последнее слово за коммутатором, а не за столом (Check transceiver).

Серверный аналог — белые списки драйверов по вендорам NIC, обходы Intel, поведение Windows и ESXi: Совместимость трансиверов на NIC.