How transceiver coding works: EEPROM, MSA and host support

01Two kinds of compatibility

A transceiver has to satisfy two separate requirements, and confusing them causes most of the trouble in optical procurement. The first is optical and electrical compatibility: the module must implement the correct standard, at the correct rate, on the correct wavelength plan, with an electrical interface the host port expects. That is what IEEE standards and multi-source agreements define, and it is what allows a module from one manufacturer to link to a module from another.

The second is host acceptance: the switch, router or network adapter must be willing to enable the port when the module is inserted. That decision is made in software, based on information the host reads out of a small memory inside the module. A module can be entirely standards-conformant and still leave a port administratively down because the host did not recognise what it read.

02What the MSA actually specifies

A multi-source agreement is a document produced by a group of manufacturers that fixes the things a module must share for the market to function: mechanical dimensions and latching, the electrical connector and pin assignment, power classes, thermal limits, and the layout of the management memory. SFP, SFP+ and SFP28 modules follow the SFP MSA family; QSFP+ and QSFP28 follow the QSFP family.

The management interface is described in the SFF documents. SFF-8472 defines the memory map used by SFP, SFP+ and SFP28 modules, with a base identification page and a second page carrying digital diagnostics. SFF-8636 defines the equivalent map for QSFP+ and QSFP28. Newer high-speed form factors use the Common Management Interface Specification. Compliance with these documents is what makes a module readable by any standards-based host.

03Inside the EEPROM

The identification memory is small and highly structured. It records the identifier and form factor, the connector type, the transceiver codes that say which standards the module supports, the nominal bit rate, the supported link lengths for each fiber type, the wavelength, vendor name, vendor IEEE organisationally unique identifier, vendor part number, revision, serial number and date code, along with checksum bytes over defined ranges.

A second area carries digital diagnostics: real-time temperature, supply voltage, laser bias current, transmitted optical power and received optical power, together with the calibration constants and warning and alarm thresholds the host uses to interpret them. This is what a switch displays when you ask it for transceiver detail, and it is the same information that later supports link troubleshooting. Every listed module quoting DDM or DOM support, such as the 25G SFP28 LR 1310 nm 10 km transceiver, implements this area.

04Why hosts check the identification fields

Network equipment vendors read the vendor name, OUI and part number fields and compare them against an internal list of modules their software knows. The stated reasons are support and quality: the vendor can characterise behaviour, set sensible diagnostic thresholds, and know what is in the port when a customer opens a case. The commercial effect is that optics purchased elsewhere may be rejected, or accepted with a warning, depending on the platform and the software release.

Behaviour varies widely. Some platforms enable the port and log an informational message. Some hold the port down until an explicit configuration command permits unrecognised optics. Some accept the module but suppress diagnostics. The variation is by vendor, by platform family, by line card and by software version, which is why compatibility can only be confirmed against a specific combination rather than assumed from a vendor name.

05What coding means in practice

Coding is the process of writing the identification fields in a module's EEPROM so that a particular host reads values it recognises and enables the port normally. The optical and electrical design of the module does not change; what changes is the information the host reads over the management interface, together with the checksums that must remain consistent.

Several catalogue entries list OEM and ODM coding for major switch platforms as a standard customisation option, alongside temperature grades and alternative reach options. The important framing for procurement is that coding is a manufacturing configuration requested by the buyer for use in their own equipment. It is not an approval, a certification, an authorisation or an endorsement by the host vendor, and no supplier can grant one. Any claim to the contrary should be treated as a reason for caution rather than confidence.

06Information a supplier needs from you

Correct coding depends on precise host information, and vague enquiries produce modules that arrive and do not work. Provide the host manufacturer and exact model, not the product family. Provide the line card, module or port group designation where the equipment is modular, because different cards in one chassis can behave differently. Provide the operating system and software version in use, since acceptance behaviour changes between releases.

Provide the optical requirement independently of the coding: rate, standard, wavelength plan, connector, fiber type, reach, temperature grade and whether diagnostics are required. If you already use a particular part number from another source and want the module to present as that part, say so explicitly. Finally, say how many ports of each type you intend to fill, because port density affects power and thermal considerations that no amount of coding will fix.

07Reach and rate coding are not the same thing

It is worth separating two ideas that often arrive in the same sentence. The transceiver codes and length fields in the EEPROM describe what the module is: a 10 km single-mode variant, a 100 m multimode variant, a copper variant. The vendor identification fields describe who the host believes made it. Coding normally means adjusting the second set while leaving the first accurate.

Misrepresenting the first set causes real problems. If a 10 km module is coded to report itself as a 40 km module, the host will accept it and the operator will plan links against a reach the hardware cannot deliver, and the failure appears months later as an unexplained error rate. Insist that the technical fields describe the actual optical performance of the module and that the datasheet matches those fields. Honest identification is part of the specification, not a detail.

08Multi-rate, multi-vendor and mixed estates

Many networks run equipment from several vendors, and some ports must work in more than one place over their life. Two practical approaches exist. The first is to code each batch for the platform it will occupy and to label the packaging clearly with the target platform, which keeps the stockroom unambiguous but creates several part numbers for one optical variant. The second is to hold a small generic stock for lab, test and vendor-neutral equipment, and coded stock only for platforms that require it.

Whichever approach you choose, maintain a table mapping your internal part number to the optical variant, the coded platform and the software versions it has been confirmed against. Modules are physically identical and visually indistinguishable once the label is removed, so a mixed drawer of coded optics is a source of long and avoidable outages.

09Third-party optics and warranty questions

Purchasing optics separately from the host equipment is a normal commercial practice, and equipment vendors generally support their own hardware while declining to support problems traced to another manufacturer's module. In practice that means the operator carries the responsibility of eliminating the module as a cause when raising a case, usually by substituting a known-good unit.

Two habits reduce friction. Keep a small quantity of the host vendor's own optics for the platforms that matter most, so that substitution testing is possible during an incident. And keep the diagnostic evidence: the DDM readings at turn-up and at the time of the fault, the interface error counters, and the measured route loss. A link that shows correct received power and clean error counters points away from the module, and that evidence is more useful in a support conversation than a debate about supply chains.

10Testing before volume

Confirming coding on the actual host is the only reliable verification. A sample test should be small, quick and documented. Insert the module in the intended port type on the intended software version. Confirm that the interface comes up without configuration workarounds, and note any log message the platform produces. Read the transceiver detail output and check that vendor fields, part number, wavelength and length fields display sensibly and that diagnostics are populated rather than blank or obviously wrong.

Then exercise the link: run traffic long enough to see whether error counters increment, and check received optical power against the calculated budget. Repeat after a reboot of the host, because some platforms perform different checks at cold start than on hot insertion. Record the software version tested, because a future upgrade can change acceptance behaviour and the record tells you what changed.

11When a coded module still does not come up

Work through the causes in order, because they are rarely the ones assumed first. Check that the port is not administratively disabled or held by a configuration that forces a speed the module cannot provide. Check that the module variant matches the port: a 25G SFP28 module in a port configured for 10G may need explicit speed configuration, and a breakout port may need its group reconfigured. Check the software version against the one the coding was confirmed on.

Then check the physical layer: cleanliness of the connectors, correct fiber type, correct polarity on parallel links, and received power inside the operating window rather than above or below it. Only after those steps is the coding itself a likely cause. When it is, give the supplier the exact log message, the transceiver detail output and the software version, since those three items usually identify the problem.

12Putting it in the purchase order

A well-formed line item names both halves of compatibility. It states the optical variant precisely, for example 25G SFP28 LR, 1310 nm, duplex LC, single-mode, 10 km, DDM, commercial temperature grade. It then states the coding target: the host manufacturer, model, line card and software version the module should be coded for. It states the quantity, the packaging requirement and whether samples are required before the balance ships.

It should not state, and no supplier should offer, any claim that the module is approved, certified or authorised by the host equipment vendor. Modules can be built to the relevant MSA and coded for use in a given platform, and that is the accurate description. Precise wording gives the technical team a document they can verify when the shipment arrives.

13Frequently asked questions