EEPROM Coding

What EEPROM Coding Is

Inside every pluggable is a small non-volatile memory holding the module's description of itself: vendor name, part number, serial number, date code, supported wavelengths and reaches, power class, and the thresholds behind DDM. The switch reads it the instant the module seats, before any light matters. Which document defines the layout depends on the form factor — SFF-8472 for SFP through SFP28, SFF-8636 for QSFP+ and QSFP28, CMIS above that.

Coding is programming that memory during manufacture. It is ordinary and expected — an uncoded module is an unfinished one. What varies is which identity is written, because platforms differ in what they accept.

Why a Switch Rejects an Uncoded Module

The identity fields are not decoration. A host uses the reach and wavelength codes to pick a FEC mode, the power class to set fan speed and cage budget, and the compliance codes to decide which interfaces the port may run. Blank, inconsistent or checksum-failing fields give it nothing to work with, so it refuses the port rather than guess.

Many platforms also compare the vendor string against a list their software recognises. Some accept anything. Some pass traffic and log a warning on every reload. Some hold the interface down. None of this is an optical judgement — the module may be flawless — it is a software policy decision taken from an ASCII string.

Getting It Right at Order Time

The fix is procurement, not fieldwork. Tell your supplier the switch make, model and software version before the module is built and the coding is written correctly the first time. A properly coded module and an original present the same identity to the same switch, which is why coding is standard industry practice rather than a workaround.

Support policy is separate from warranty terms, and both vary by vendor and jurisdiction — the US Magnuson-Moss Warranty Act is often cited here, but it governs consumer products rather than commercial data-centre equipment, so do not rely on it. What a vendor may in practice decline is help debugging a link that contains a third-party part. Buy from a supplier who will provide that help.

Coding to the wrong platform is the failure mode that costs time: a module coded for one vendor's switch and installed in another's is rejected exactly as though it were uncoded. Record coding against part numbers in your spares list.

Beyond the Vendor String

Good coding describes the module honestly in every field, not just the name. A module claiming a 10 km reach it does not have, or a power class below what it draws, produces faults far harder to diagnose than a clean rejection: thermal throttling, and links that pass at 20 °C and fail at 45 °C.

That is a real quality difference between suppliers and it is invisible on a datasheet. Ask whether modules are traffic-tested on the target platform after coding, not merely programmed and shipped. See OEM vs third-party transceivers for the wider trade-off.

Where You Meet It

Every time a port logs an unrecognised or unsupported transceiver — the unsupported transceiver guide covers what that message means. Everything in our transceiver range is coded to the platform named on the order and traffic-tested before it ships.

Related Terms

CMIS, MSA, DDM, FEC, loopback modules.