Why the EEPROM matters
Every pluggable optical transceiver (SFP, SFP+, QSFP, QSFP28, etc.) ships with a small EEPROM that stores two kinds of information: a fixed Serial-ID block (vendor, part number, serial number, capabilities) and—when provided—a diagnostics area (real-time temperature, voltage, TX/RX power, etc.). Reading that EEPROM is the most reliable way to verify compatibility, identify mismatched optics, and diagnose link problems before you start swapping cables or reconfiguring ports. The SFP memory map and the diagnostics interface (Digital Diagnostic Monitoring or DDM/DOM) are standardized by the SFF/MSA families so you can decode fields predictably.
Standards & addresses you need to know
Two addresses on the transceiver’s I²C bus are essential:
-
A0h (0xA0) — the serial ID / base EEPROM (96–128 bytes depending on form factor). You’ll find identifier, connector type, vendor name (bytes 20–35), vendor OUI, part number and revision here.
-
A2h (0xA2) — the Digital Diagnostic Monitoring (DDM) page: real-time sensors, alarm/warning thresholds, and calibration constants (if present). Not every module implements all DDM fields, but when it does the host can read live temperature, supply voltage, laser bias, TX power and RX power here.
For QSFP family modules (4-lane / higher data rates), the memory map and management interface follow the SFF-8636/related QSFP MSAs (multi-page structure, expanded fields for lane mapping and higher-speed telemetry). If you work with QSFP or QSFP28, treat the QSFP memory map as a superset of the SFP ideas — same I²C concept, different offsets/pages.
Comparison: SFP vs QSFP Memory Structure
Tools & methods to read the EEPROM (real commands)
Choose the approach that matches the host hardware you control.
1) Use OS/network tools (recommended on servers and switches)
ethtool -m <ifname> — read and decode module information (hardware dependent). On many Linux drivers this prints type, vendor, wavelength, and DOM values.
Example: sudo ethtool -m eth0 (or -m --dump-module-eeprom to dump raw bytes). ethtool -e can dump raw EEPROM contents too.
2) Use platform utilities designed for pluggables
sfputil (SONiC / switch utilities): sfputil show eeprom or sfputil show eeprom --dom prints decoded fields and DOM readings. These tools know vendor conventions and are safer than raw I²C in many platforms.
3) Read raw I²C (when you have low-level access)
On a host with access to the module I²C bus you can use i2cdump/i2cget from i2c-tools. Example pattern (varies by hardware):
i2cdump -y <bus> 0x50 — dump A0 page (note: 0x50 is the 7-bit device address corresponding to 0xA0).
i2cdump -y <bus> 0x51 or i2cget -y <bus> 0x51 <offset> — depending on your platform mapping for A2 (some maps differ; check vendor docs).
Warning: raw writes can corrupt the EEPROM; use read-only operations unless you know exactly what you’re doing.
Practical note: many switch ASICs do not expose the raw I²C bus to the host OS; instead they provide decoded fields via the switch OS. Use
ethtool/sfputilfirst and fall back to I²C only when necessary.
Interpreting the fields
-
Identifier (byte 0): tells you form factor (03h = SFP/SFP+).
-
Vendor name (bytes 20–35 at A0): ASCII left-aligned — quick check for manufacturer.
-
Vendor PN / Rev / Serial (bytes 40–59/56–59 / 68–83 etc.): cross-check these against inventory and warranty records.
-
Wavelength / compliance codes: Transceiver capability bits show supported standards (1000BASE-LX, 10GBASE-SR, Fibre Channel rates). You’ll find compliance bits defined in the SFF tables; those bits tell the host which PHY modes the module fits.
-
DDM real-time values (A2): temperature is typically a signed 16-bit value (units: 1/256 °C), voltages and powers often use calibration constants stored elsewhere in the DDM area — so if a value looks like an ADC count, consult the calibration bytes to convert to mW or volts. The specification explains conversion and internal vs. external calibration flags.
Quick workflow
-
Identify the interface and running OS.
-
Run
sudo ethtool -m <if>— if the driver supports decoding you’ll get vendor and DOM values. -
If you need raw bytes,
sudo ethtool -e <if>orsfputil show eeprom; save output for auditing. -
If deeper analysis required and you have I²C access, use
i2cdump -y <bus> 0x50(A0) and the appropriate address for A2. Convert ADC counts using calibration bytes (see the SFF-8472/AN documents).
Troubleshooting & gotchas
-
No response / unreadable EEPROM: check physical seating, port cleanliness, and that the switch does not vendor-lock third-party optics (some vendors will reject or mark third-party SFPs). Vendor logs or CLI often output “unsupported transceiver” messages — consult platform docs for commands such as service unsupported-transceiver (Cisco) or equivalent platform hints.
-
Driver/firmware limitations: older NIC/switch drivers may not support DDM or may show raw counts only; update platform firmware cautiously.
-
Interpreting values: remember that RX/TX power interpretation depends on whether the module reports raw ADC counts or scaled values — check the calibration bytes before drawing conclusions.
Security & safety
Never write to EEPROM unless you have a clear, vendor-supported reason — changing serial IDs or calibration data can break inventory and violate vendor warranty or service terms. If you must program a module (for repair or lab use), use a hardware programmer and keep a verified backup of original contents.
The Wolontek Assurance
WOLON produces a full range of SFP, SFP+, QSFP, and QSFP28 optical transceivers engineered for data-center reliability.
Unlike generic “coded” optics that often hide data, every WOLON module ships with:
1.Standard-Compliant Memory Maps: Fully readable by ethtool and switch CLIs.
2.Factory-Calibrated DDM: Accurate real-time diagnostics without complex host-side math.
3.Clear Vendor Data: Making inventory management easy.
<Stop Debugging. Start Deploying. />
Don’t let non-standard EEPROM mapping crash your switch.
Wolon transceivers follow SFF-8472 & SFF-8636 strictly. We offer Custom EEPROM Coding to emulate Cisco, Arista, Juniper, or Generic firmware.
// Guaranteed DDM Accuracy within ±3dB.
FAQ: Common SFP EEPROM Questions
Q1: Why does ethtool -m fail with “Connection timed out”?
A: This usually indicates an I²C bus hang on the switch or NIC. Try re-seating the SFP module (pull it out and plug it back in) to reset the microcontroller inside the module.
Q2: What is the difference between “Internal” and “External” calibration?
A: This determines who does the math.
Internal Calibration: The SFP module converts the raw analog data into real units (e.g., Celsius, dBm) before sending it to the host. (Wolontek modules use this method for easier compatibility).
External Calibration: The SFP sends raw data, and the host (switch) must read the calibration constants from the EEPROM and calculate the real values itself.
Q3: Can I re-program an SFP EEPROM to work with a different switch brand?
A: Technically yes, but standard tools like ethtool cannot do this because the EEPROM is usually write-protected. You need a dedicated SFP Coding Box to unlock the chip and change the Vendor ID to match the target switch (e.g., changing “WOLON” to “CISCO”).
Q4: Does reading the EEPROM interrupt network traffic?
A: No. The I²C management interface is physically separate from the high-speed data lanes. You can poll the EEPROM for temperature or light levels continuously without causing packet loss.