Sumas de comprobación: CC_BASE, CC_EXT, CC_DMI, páginas CMIS

Toda especificación de gestión protege su bloque de identidad con una o más sumas de comprobación — un único byte que permite al host detectar una EEPROM corrupta o escrita a medias antes de confiar en el contenido. Son triviales de calcular y fáciles de olvidar: una suma desactualizada tras una edición es la causa más común de que un módulo recién codificado se reporte como invalid.

El algoritmo

Todas usan la misma regla: sumar los bytes del rango cubierto como valores sin signo de 8 bits y conservar los 8 bits bajos de la suma (suma módulo 256). Sin CRC, sin polinomio.

sum = 0
para cada byte b en el rango:
    sum = (sum + b) & 0xFF
checksum = sum

Ejemplo — los primeros cinco bytes de un SFP 10GBASE-SR: 03 04 07 10 00 → 3 + 4 + 7 + 16 + 0 = 30 = 1Eh. Continúe hasta el byte 62 y el resultado es CC_BASE.

Dónde vive cada suma

No cubiertas por ninguna suma: las áreas específicas de fabricante (SFP A0h 96–127, QSFP 224–255, CMIS 223–255), la EEPROM de usuario, los monitores y banderas en vivo, los umbrales de la página 03h de QSFP y las páginas de carril de CMIS. Los fabricantes pueden añadir sus propios campos de integridad en el espacio de fabricante — esos no forman parte de la especificación.

Qué hacen los hosts con ellas

Un fallo de suma se reporta junto con la identidad, así que un módulo que además tiene un problema de política muestra un mensaje que oculta al otro — revise primero las sumas, es la corrección barata. Mapa de síntomas: Índice de síntomas.

Cuándo hay que recalcular

• Después de editar cualquier cosa en los rangos cubiertos — nombre de fabricante, número de parte, número de serie, código de fecha, códigos de conformidad, longitud de onda, longitudes, opciones, clase de potencia.
• Después de aplicar umbrales o constantes de calibración en SFP (CC_DMI).
• Después de restaurar una imagen parcial de otro módulo.
• No hace falta para cambios en el espacio de fabricante, la EEPROM de usuario o los bytes de control A2h.

Orden de las operaciones: editar → recalcular cada suma afectada → escribir → releer → verificar. Escribir el byte de suma antes que los datos que cubre deja una ventana en la que una pérdida de energía produce un módulo inválido.

Sumas de comprobación y bloqueos de fabricante

Las sumas correctas son necesarias, pero no suficientes. Una plataforma estricta también comprueba el bloque de fabricante y, en diseños bloqueados, una firma propietaria en el espacio de fabricante de la que las sumas de la especificación no saben nada. Superar el CC_BASE con una identidad rechazada parece un caso de bloqueo de fabricante, no un caso de suma — Bloqueo de fabricante, Campos de fabricante.

En CodingBox

CodingBox recalcula automáticamente CC_BASE, CC_EXT, CC_DMI y las sumas de página CMIS en cada escritura y resalta una discrepancia al leer un módulo — un campo de suma en rojo en Check transceiver o en el editor de EEPROM significa que el módulo se editó en otro sitio sin corregirla, o que la EEPROM está corrupta.

Dónde se sitúa cada suma entre sus vecinos: SFF-8472 A0h (63, 95), A2h (95), SFF-8636 superior (191, 223), páginas superiores de CMIS (222, 255), XFP (191, 223).