Optical Transceiver EEPROM: How It Works, What Goes Wrong, and How to Read It (400G–1.6T)

Most fiber-optic problems get blamed on cables, dirty connectors, or switch firmware. A meaningful share of them are actually EEPROM problems wearing a cable's clothes. The transceiver tells the switch what it is. The switch trusts that declaration and configures itself accordingly. If the declaration is wrong, the link can come up, pass a quick test, and then fail under load — and nothing in your monitoring will point at the real cause.

This guide is for engineers running 400G, 800G, and 1.6T fiber optics in 2026. It covers transceivers and active cables (DAC, AEC, ACC, AOC), the specs governing how their EEPROM is laid out, what's stored where, what breaks when bytes are wrong, and how to read it across SONiC, Cumulus Linux, NX-OS, IOS-XR, EOS, and Junos.

1. EEPROM in Fiber Optics

EEPROM stands for Electrically Erasable Programmable Read-Only Memory. It's a small non-volatile memory chip that retains its contents without power and can be electrically rewritten in-circuit. In an optical transceiver or active cable, it sits on the module's PCB and is accessed by the host switch over a 2-wire (I²C-style) management bus.

The job is simple to describe: when a module is inserted, the switch reads its EEPROM to find out what was just plugged in. Vendor name. Part number. Serial number. Supported applications and speeds. Wavelength and reach. Per-lane monitoring thresholds. The switch uses that information to configure its SerDes, decide what FEC mode to negotiate, and bring the link up. That's the entire interoperability contract behind plug-and-play optics.

The reason EEPROM gets disproportionate operator attention in 2026 is that the cost of getting it wrong has gone up. At 25G NRZ per lane, hosts had enough margin to absorb a lot of imperfection. At 100G PAM4 — the lane rate behind today's 800G modules — and 200G PAM4 for 1.6T, that margin is mostly gone. Wrong byte → wrong host equalization → marginal eye → flapping link.

Figure 1 — Where EEPROM sits in a transceiver, and what the host reads. The two paths never touch: a module can pass traffic perfectly while its EEPROM reports wrong bytes.

Two practical things flow from that picture. First, the host has no way to independently verify what the module is — it relies entirely on what the EEPROM says. Second, the management path (the slow I²C bus) is completely separate from the high-speed data lanes. A module can pass full-rate traffic perfectly while reporting wrong values, and it can fail to bring up a link while reporting correct values.

2. The Specs That Govern It

Three families of specifications define what EEPROM looks like and how the host talks to it. Which one applies depends entirely on the form factor.

A few things worth knowing about how this evolved:

• CMIS replaced static memory maps with paged, advertised capabilities. Earlier specs had every byte at a fixed address. CMIS introduced a 256-byte window where the lower 128 bytes are always accessible and the upper 128 bytes are switched between numbered pages, allowing modules to expose a much richer set of features without running out of address space.
• CMIS started as the QSFP-DD MSA's specification. The OIF formally adopted it in January 2022, which is why CMIS revisions ≤ 5.2 carry a note that they were not originally produced by the OIF. CMIS 5.3 (4 September 2024) is the first revision fully under OIF.
• Errata matter. The CMIS 5.x Errata 1.0 (13 February 2025) documents a real interoperability bug in Application advertising that could cause unexpected configuration rejections. If you read CMIS 5.3, read the errata too.
• SFF-8024 is the lookup table for everything else. The Identifier byte that tells you whether a module is QSFP-DD (18h), OSFP (19h), QSFP28 (11h), or SFP+ (03h) is defined here. Rev 4.13 added codes for QSFP-DD800, OSFP-XD-RHS, and LPO-MSA optics.

3. What's Actually Inside

Whether the module follows SFF-8472, SFF-8636, or CMIS, the same four categories of information are present — they just live at different addresses. The CMIS layout below is the one that matters most for AI data center optics:

Figure 2 — CMIS memory map. Page 01h is the one that flaps links: wrong bytes here = wrong host SerDes config. SFF-8472/SFF-8636 modules use a similar shape with different addresses.

Identity fields (Page 00h)

Vendor name (16 ASCII bytes), Vendor OUI (3-byte IEEE company ID), Part Number, Revision, Serial Number, Date Code, plus an Identifier byte that names the form factor itself. There are also two checksum bytes — CC_BASE covering the base ID block and CC_EXT covering the extension block. If you re-code an EEPROM and forget to recalculate these, the module either won't be recognised or will be flagged as corrupted.

Capability fields (Page 01h — the AI-fabric-critical one)

In CMIS, Page 01h carries up to 15 Application Descriptors. Each one tells the host: "I support this combination of host electrical interface, media interface, host lane count, media lane count, and lane assignment." The host picks one — usually the first compatible application — and configures itself accordingly.

For an 800G OSFP DR8 module, you'll see Application Descriptors for native 1×800G plus breakout configurations like 2×400G, 4×200G, and 8×100G. The same physical module can therefore present itself differently depending on what the host requests.

Physical parameter fields

Wavelength (and tolerance, for tunable optics), reach in metres for SMF/OM3/OM4/copper, connector type code (LC, MPO-12, MPO-16, etc.), transmitter technology bits, and module power class. The power class matters operationally: a Class 8 module advertising up to 16.5 W has different cooling requirements than a Class 1 module at 1.5 W, and the host may refuse to power it up if cage thermals don't support it.

Monitoring fields (DDM)

Module temperature, supply voltage, per-lane TX bias, per-lane TX optical power, per-lane RX optical power. Each has alarm and warning thresholds also stored in EEPROM. There's a calibration model — internal calibration (the module has done the math, host reads scaled values directly) or external calibration (host reads raw A/D counts and applies the calibration constants stored at A2h bytes 56–91). Mixing those up is a classic source of "DDM readings that don't match reality."

What's specific to active cables

Passive DAC EEPROM is minimal — just the identity block, length, and a transmitter technology code marking it as copper. There's no DDM because there's nothing actively monitoring optical power. AEC, ACC, and AOC EEPROMs carry significantly more — they include retimer or redriver configuration, equalization settings the host can read or override, and the same DDM-style monitoring as transceivers. A wrong byte in an AEC EEPROM can look identical to "marginal cable" — the cable physically conducts the signal but the active components are configured to the wrong signal regime.

4. How EEPROM Gets There (and Why That Matters)

EEPROMs aren't programmed at the chip foundry. They're written during module assembly, from a per-SKU build template, and then validated on the production line before the module ships. This step is where most preventable EEPROM problems are introduced — and most of the cost of a bad EEPROM is borne by whoever deploys the module, not whoever built it.

This part of the supply chain is invisible to the buyer unless they ask. "We test every module at full optical performance" is a true statement that doesn't address EEPROM at all. The questions that matter are about template control, byte-level validation, and host-side regression — not optical power.

Figure 3 — Most EEPROM faults reveal themselves at one of these five stages. Stages 1-3 fail loud. Stage 4 fails silent — the link comes up, then flaps days later.

5. The Failures You'll Actually See

Most EEPROM-driven failures fit into a small number of recognisable patterns. The point of the catalogue below is pattern recognition — being able to look at a symptom and know which field to suspect first.

Two patterns deserve more attention because they are the most common misdiagnoses:

6. Reading EEPROM With What You Already Have

Every major NOS exposes EEPROM contents through CLI. You don't need bench equipment to read what's in a module — you just need the right command for the platform you're on.

The output is verbose but readable. Here's what an actual SONiC dump of an 800G OSFP DR8 module looks like — the same kind of output a leaf switch operator would see while diagnosing a flap, with every field labeled below:

Figure 4 — The three coloured blocks are everything you need. Identity (what it is) · Capabilities (what the host configures) · DDM (is it healthy right now).

Two SONiC-specific notes worth knowing. First, the daemon that drives all of this is xcvrd; per the SONiC source, it polls DDM on a 60-second cycle and caches static identity in STATE_DB until the module is removed or an error is detected. Second, when the I²C bus has a problem reading a module, you'll see specific error strings in the logs — "I2C bus stuck", "Bad eeprom", "Blocking error" — and xcvrd will stop updating that port's DOM info until it recovers.

7. EEPROM in AI Data Centers

This is where the load-bearing differences from earlier-generation fabrics show up. AI clusters concentrate the conditions that expose EEPROM problems — high lane rates, dense fabrics with thousands of optics, FEC-limited margins, and traffic patterns that create correlated stress across many links at once.

Why AI fabrics are EEPROM-sensitive

Three things compound. PAM4 reduces SNR margin by roughly 9.5 dB compared to NRZ at the same baud rate, which means the host's tolerance for misadvertised electrical interfaces is much smaller. FEC operates near threshold by design — a wrong host configuration that strips a few dB of margin is absorbed silently until thermal drift or a traffic burst pushes the link past its FEC-correctable BER. And scale means that even a small per-module probability of an EEPROM defect produces a non-trivial number of affected links across a 1,000+ module fleet. For more on PAM4 signal quality metrics, see our TDECQ guide.

The form factors that dominate AI DC

The IHS-vs-RHS distinction is the single most expensive EEPROM-related mistake in 2026 AI procurements, and it isn't really an EEPROM problem at all — it's a physical cage compatibility problem that the EEPROM identifier byte doesn't disambiguate. Both flat-top and finned-top OSFP modules report identifier 19h; the cage type that's required is determined by the host platform.

NVIDIA platforms: what's publicly documented

Spectrum-X SN5600 — Spectrum-4 ASIC, 51.2 Tb/s, 64×800G OSFP cages. Supports both Pure SONiC and Cumulus Linux. The platform has built-in root-of-trust authentication that automatically blocks altered or unsigned components at the BIOS-through-NOS layer — that's a firmware-level check, not an EEPROM cryptographic lock. At the optics layer, compatibility is largely physical (cage type) plus standard CMIS application advertising.

Quantum-X800 Q3400-RA — InfiniBand XDR, 4× Quantum-3 ASICs, 144×800G across 72 OSFP twin-port IHS cages, 115.2 Tb/s aggregate. The Q3200-RA is the smaller variant with NDR backward compatibility. For a full compatibility matrix, see our NVIDIA 800G transceiver compatibility guide.

ConnectX-8 SuperNIC — 800G XDR-class NIC for GPU servers, OSFP-RHS cages. Pairs with the spine through DAC (≤ 2 m), ACC (3–5 m), AEC (3–9 m), AOC (30–100 m), or transceivers (SR8 to 100 m, DR4 to 500 m). Full interconnect type guide: 800G DCI selection guide.

Spectrum-X Photonics / Quantum-X Photonics — co-packaged-optics switches announced at GTC March 2025. CPO replaces per-port pluggable transceivers with optics integrated at the switch package — which changes the EEPROM model entirely. As of mid-2026, public NVIDIA documentation does not describe a CMIS-equivalent management model for the integrated optical engines.

Active cables in AI clusters

At 800G, passive DAC effectively runs out of reach at about 2 m because copper losses double versus 400G. AOC works at any reach but draws 1–2 W per end. AEC and ACC have become the practical answer for the 3–9 m zone — Marvell and Infraeo demonstrated a 9 m 800G AEC at OCP Global Summit 2025, and 1.6T AECs are now appearing in trial deployments.

From an EEPROM perspective, AECs and ACCs carry significantly more configuration than a passive DAC. The retimer DSP (in AECs) or linear equalizer (in ACCs) needs configuration that's stored in EEPROM and read by the host. A wrong byte in that section produces symptoms that look exactly like marginal cable performance: BER just inside the FEC margin, occasional flaps under thermal swing, or per-lane errors that shift between lanes between reboots.

LPO: why EEPROM accuracy matters more, not less

Linear Pluggable Optics (LPO) remove the DSP from the module and shift signal conditioning to the host switch's SerDes. That cuts module power by roughly half, which is a significant win at AI fabric scale. But it also makes EEPROM advertising far more important — the host now needs accurate information about what the module's analog front-end can and can't do, so it can configure its own equalization correctly.

The standards work supporting this is CMIS-VCS (Versatile Control Set, July 2025). LPO modules must be qualified against specific switch silicon (Broadcom Tomahawk 5/6, NVIDIA Spectrum-4) — qualification is now host-platform-specific in a way it wasn't for DSP-based modules.

8. Coding Tools and Field Rewriting

EEPROM is field-rewritable by design. There's a small ecosystem of programming boxes and software that let you read and rewrite module EEPROMs after they've shipped. The category is real, the tools are openly advertised, and any honest discussion of EEPROM in 2026 has to acknowledge what they're for and what they aren't.

SFF-8472 supports password protection on writable EEPROM specifically because some of these uses are problematic — vendors ship with a 4-byte password that locks identity and calibration regions, and reputable coding boxes respect that.

9. Glossary & References

Terms used in this guide

Primary sources

• OIF CMIS — oiforum.com/technical-work/implementation-agreements-ias (CMIS 5.3, CMIS-VCS, Errata)
• SNIA SFF — SFF-8472 Rev 12.5a, SFF-8636 Rev 2.11, SFF-8024 Rev 4.13 at members.snia.org
• SONiC xcvrd — github.com/sonic-net/sonic-platform-daemons
• NVIDIA networking — docs.nvidia.com/networking
• Cisco IOS-XR optics — cisco.com/c/en/us/td/docs/iosxr
• Arista EOS — arista.com/en/um-eos/eos-transceiver-performance-monitoring