Контрольные суммы: CC_BASE, CC_EXT, CC_DMI, страницы CMIS

Каждая спецификация управления защищает блок идентификации одной или несколькими контрольными суммами — одним байтом, по которому хост распознаёт испорченную или недописанную EEPROM, прежде чем поверить содержимому. Их тривиально вычислить и легко забыть: устаревшая сумма после правки — самая частая причина, по которой свежезакодированный модуль объявляется invalid.

Алгоритм

Все используют одно правило: сложить байты покрываемого диапазона как беззнаковые 8-битные значения и оставить младшие 8 бит суммы (сумма по модулю 256). Никакого CRC, никакого полинома.

sum = 0
для каждого байта b в диапазоне:
    sum = (sum + b) & 0xFF
checksum = sum

Пример — первые пять байтов SFP 10GBASE-SR: 03 04 07 10 00 → 3 + 4 + 7 + 16 + 0 = 30 = 1Eh. Продолжите до байта 62 — получится CC_BASE.

Где живёт каждая сумма

Спецификация	Сумма	Расположение	Покрывает
SFF-8472 (SFP)	CC_BASE	A0h байт 63	A0h байты 0–62
SFF-8472	CC_EXT	A0h байт 95	A0h байты 64–94
SFF-8472	CC_DMI	A2h байт 95	A2h байты 0–94 (пороги и константы калибровки)
SFF-8636 (QSFP)	CC_BASE	байт 191	верхняя страница 00h байты 128–190
SFF-8636	CC_EXT	байт 223	байты 192–222
INF-8077i (XFP)	CC_BASE	байт 191	байты 128–190
INF-8077i	CC_EXT	байт 223	байты 192–222
CMIS	сумма страницы	страница 00h байт 222	страница 00h байты 128–221
CMIS	сумма страницы	страница 01h байт 255	страница 01h байты 130–254 (128–129 хранят версию неактивной прошивки и исключены)
CMIS	сумма страницы	страница 02h байт 255	страница 02h байты 128–254
CMIS	сумма страницы	страница 04h байт 255	страница 04h байты 128–254

Не покрыты никакой суммой: вендорские области (SFP A0h 96–127, QSFP 224–255, CMIS 223–255), пользовательская EEPROM, живые мониторы и флаги, пороги страницы 03h QSFP и канальные страницы CMIS. Вендоры могут добавлять свои поля целостности в вендорском пространстве — к спецификации они не относятся.

Что делают с ними хосты

Поведение	Результат плохой суммы
Проверяют CC_BASE (большинство коммутаторов и маршрутизаторов)	модуль показан как invalid, unsupported или EEPROM checksum error; порт может уйти в errdisable; лазер часто остаётся выключенным
Проверяют и CC_EXT	то же или только запись в лог, в зависимости от платформы
Проверяют CC_DMI	DDM показан как not supported или значения игнорируются; сам линк не затронут
Игнорируют суммы (многие NIC, часть открытых коммутаторов)	модуль работает; ошибка всплывает только в утилитах

Отказ по сумме сообщается вместе с идентификацией, поэтому у модуля, у которого есть и проблема политики, одно сообщение скрывает другое — проверяйте суммы первыми, это дешёвое лечение. Карта симптомов: Индекс по симптомам.

Когда нужно пересчитывать

После правки чего угодно в покрываемых диапазонах — имени вендора, партномера, серийника, кода даты, кодов соответствия, длины волны, длин, опций, класса мощности.
После применения порогов или констант калибровки у SFP (CC_DMI).
После восстановления частичного образа с другого модуля.
Не нужно при изменениях в вендорском пространстве, пользовательской EEPROM или байтах управления A2h.

Порядок операций: правка → пересчёт всех затронутых сумм → запись → обратное чтение → проверка. Запись байта суммы до данных, которые он покрывает, оставляет окно, в котором пропадание питания даёт невалидный модуль.

Контрольные суммы и вендор-локи

Верные суммы необходимы, но недостаточны. Строгая платформа проверяет ещё блок вендора, а у залоченных конструкций — проприетарную сигнатуру в вендорском пространстве, о которой суммы спецификации ничего не знают. Пройденный CC_BASE при отвергнутой идентификации — случай вендор-лока, а не сумм — Вендор-лок, Поля вендора.

В CodingBox

CodingBox автоматически пересчитывает CC_BASE, CC_EXT, CC_DMI и суммы страниц CMIS при каждой записи и подсвечивает несовпадение при чтении модуля — красное поле суммы на Check transceiver или в редакторе EEPROM означает, что модуль правили в другом месте без исправления суммы, либо EEPROM повреждена.