Checksums: CC_BASE, CC_EXT, CC_DMI, CMIS pages

Every management specification protects its identity block with one or more checksums — a single byte that lets the host detect a corrupted or half-written EEPROM before it trusts the contents. They are trivial to compute and easy to forget: a stale checksum after editing is the most common reason a freshly coded module is reported as invalid.

The algorithm

All of them use the same rule: add the bytes of the covered range as unsigned 8-bit values and keep the low 8 bits of the sum (sum modulo 256). No CRC, no polynomial.

sum = 0
for each byte b in range:
    sum = (sum + b) & 0xFF
checksum = sum

Example — the first five bytes of a 10GBASE-SR SFP: 03 04 07 10 00 → 3 + 4 + 7 + 16

0 = 30 = 1Eh. Continue through byte 62 and the result is CC_BASE.

Where each checksum lives

Specification	Checksum	Location	Covers
SFF-8472 (SFP)	CC_BASE	A0h byte 63	A0h bytes 0–62
SFF-8472	CC_EXT	A0h byte 95	A0h bytes 64–94
SFF-8472	CC_DMI	A2h byte 95	A2h bytes 0–94 (thresholds and calibration constants)
SFF-8636 (QSFP)	CC_BASE	byte 191	upper page 00h bytes 128–190
SFF-8636	CC_EXT	byte 223	bytes 192–222
INF-8077i (XFP)	CC_BASE	byte 191	bytes 128–190
INF-8077i	CC_EXT	byte 223	bytes 192–222
CMIS	page checksum	page 00h byte 222	page 00h bytes 128–221
CMIS	page checksum	page 01h byte 255	page 01h bytes 130–254 (128–129 hold the inactive firmware version and are excluded)
CMIS	page checksum	page 02h byte 255	page 02h bytes 128–254
CMIS	page checksum	page 04h byte 255	page 04h bytes 128–254

Not covered by any checksum: the vendor-specific areas (SFP A0h 96–127, QSFP 224–255, CMIS 223–255), user EEPROM, the live monitors and flags, QSFP page 03h thresholds, and CMIS lane pages. Vendors may add their own integrity fields in vendor space — those are not part of the specification.

What hosts do with them

Behaviour	Result of a bad checksum
Validate CC_BASE (most switches and routers)	module shown as invalid, unsupported or EEPROM checksum error; port may errdisable; laser often kept off
Validate CC_EXT as well	same, or only a log entry, depending on platform
Validate CC_DMI	DDM shown as not supported or values ignored; the link itself is unaffected
Ignore checksums (many NICs, some open switches)	module works; the error surfaces only in tools

A checksum failure is reported together with identity, so a module that also has a policy problem shows one message hiding the other — check the checksums first, they are the cheap fix. Symptom map: Symptom index.

When you must recompute

After editing anything in the covered ranges — vendor name, part number, serial, date code, compliance codes, wavelength, lengths, options, power class.
After applying thresholds or calibration constants on SFP (CC_DMI).
After restoring a partial image from another module.
Not needed for changes in vendor space, user EEPROM or A2h control bytes.

Order of operations: edit → recompute every affected checksum → write → read back → verify. Writing the checksum byte before the data it covers leaves a window where a power loss produces an invalid module.

Checksums and vendor locks

Correct checksums are necessary, not sufficient. A strict platform also checks the vendor block and, on locked designs, a proprietary signature in vendor space that the specification checksums know nothing about. Passing CC_BASE with a rejected identity looks like a vendor lock case, not a checksum case — Vendor lock, Vendor fields.

In CodingBox

CodingBox recalculates CC_BASE, CC_EXT, CC_DMI and the CMIS page checksums automatically on every write and highlights a mismatch when reading a module — a red checksum field on Check transceiver or in the EEPROM editor means the module was edited elsewhere without fixing it, or the EEPROM is corrupted.