transceiver-db/blog-training-data/blog-071-sff-8024-transceiver-id-codes.md

title	slug	type	category	tags	seo_focus_keyword
SFF-8024 Transceiver Identifier Codes Decoded	sff-8024-transceiver-id-codes	deep-dive	Standards & Compatibility	SFF-8024 EEPROM transceiver-identification NOS-compatibility IDPROM compatible-optics	SFF-8024 transceiver identifier codes

Every transceiver carries a small autobiography in its EEPROM. The first few bytes tell the host system what kind of device it's talking to — and network operating systems use this information to decide whether to bring up the port at all. SFF-8024, the SFF Committee's identifier mapping document, is the Rosetta Stone for this. It's also where most "why won't my optic come up?" investigations eventually land.

The Three Bytes That Matter Most

Address 0x00 is the identifier byte. This is the top-level declaration: what form factor am I? The values are standardized across SFF-8024 Table 4-1. A value of 0x03 means SFP/SFP+/SFP28. 0x0D is QSFP+. 0x11 is QSFP28. 0x18 is QSFP-DD. 0x1E is OSFP. If you're staring at a hex dump from ethtool -m or show interface transceiver and the first byte reads 0xFF or 0x00, the module either failed to respond during power-up or the interface isn't initialized. That's not a compatibility problem — that's a hardware problem.

Address 0x01 is the extended identifier. In QSFP28 (SFF-8636) modules, this byte encodes power class and CDR (Clock Data Recovery) capability. Bits 7:6 define the power class from 1 (1.5W max) through 8 (20W max). Bit 2 indicates whether a CDR is present in the TX path, bit 1 for RX. This matters because a host system configured for a low-power module will assert a power-override signal differently than for a high-power module. Mismatches here cause brown-outs that look exactly like a failing laser.

Address 0x07 is the connector type. The SFF-8024 Table 4-3 list is long — LC (0x07), MPO 1x12 (0x0C), MPO 2x16 (0x0E), CS (0x11), SN (0x13), and so on. This byte exists partly for inventory systems and partly so that NOS platforms can sanity-check whether the physical connection makes sense for the interface type. In practice, most platforms don't gate port bring-up on this byte, but some do log warnings, and a few vendor-specific implementations do use it in their validation logic.

What "Compatible" Vendors Actually Write

Third-party transceiver vendors face a choice when programming EEPROM: fill the identifier fields exactly per specification, or copy the OEM bytes verbatim. The answer varies by vendor and matters enormously.

A well-programmed compatible module populates 0x00, 0x01, and 0x07 per SFF-8024 exactly. The vendor OUI at bytes 0x41–0x43 (in SFF-8636) will be the compatible vendor's own OUI, not Cisco's or Juniper's. The vendor name field at bytes 0x50–0x5F will say something like "FLEXOPTIX" or "FINISAR" or whatever the actual manufacturer is. This is the honest approach and works reliably on well-implemented platforms.

A "reprogrammed" module is a different animal. These are typically genuine OEM optics — often pulled from decommissioned equipment — where the EEPROM has been overwritten to match a specific OEM's signature: vendor name, part number, serial number suffix, and sometimes even the OUI. The identifier bytes at 0x00–0x07 stay correct (they're structural, not branding), but the upper vendor fields now claim to be something they're not. The practical implication is that the module will pass vendor authentication checks that read those fields, including Cisco's IDPROM authentication on some Nexus platforms.

This raises an obvious question about authenticity and one less obvious question about safety. The authenticity question is a policy issue for your organization. The safety question is more interesting: if the EEPROM claims capabilities the hardware doesn't actually have, you can get unexpected behavior under marginal conditions — particularly around power classes and TX disable behavior.

How NOS Platforms Use These Bytes for Gating

Cisco IOS-XE on Catalyst platforms performs what Cisco calls "transceiver validation." The platform reads the identifier bytes, checks the vendor OUI against an internal allow-list, and makes a port enable decision. If the vendor OUI isn't recognized, the port typically comes up anyway but with a log message: %TRANSCEIVER-3-NOT_QUALIFIED: Transceiver is not qualified. The port still passes traffic. This is the "warning but allow" model.

NX-OS on Nexus 9000 series is more aggressive. With service unsupported-transceiver not configured, the platform will refuse to bring up a port with an unrecognized vendor OUI, writing %SFF8472-5-THRESHOLD_VIOLATION events and keeping the interface admin-down effectively. Enabling unsupported transceiver support is a global command that many operators apply during initial deployment and then forget about — until they migrate to a new chassis where it hasn't been set.

Junos on MX and PTX platforms reads identifier bytes during PIC initialization. The behavior differs between Junos versions prior to 19.1 and after, where Juniper tightened vendor validation for 400G optics specifically. On QFX switches, the behavior is closer to the Catalyst model — warn and allow. On PTX, particularly for coherent pluggables, validation is stricter.

Arista EOS is by far the most permissive of the major platforms. It reads the identifier bytes for informational purposes, logs the vendor string, and brings up the port. This is partly why Arista gear is often used for initial compatibility testing of new optics — the platform itself won't be the obstacle.

The "Reprogrammed" Question in Plain Terms

When someone offers you "reprogrammed Cisco optics" at a significant discount, what they're selling is a module that has had its EEPROM overwritten to impersonate a Cisco-branded part. The identifier bytes (0x00, 0x01, 0x07) will be correct per SFF-8024 because they describe the actual hardware. The vendor branding fields will claim Cisco, often including a plausible-looking serial number.

On platforms that gate port enable on vendor OUI validation, this module will pass the check. On platforms that do EEPROM cryptographic signing (Cisco's later implementations on high-end platforms do perform a signed validation for certain optics), it will fail, because you can copy bytes but you can't forge the signature without the private key.

The risk profile of reprogrammed optics is not primarily about signal quality. The optical hardware is typically genuine. The risks are: loss of traceable provenance for compliance purposes, behavior under firmware updates that tighten validation (the port you were relying on stops coming up after a scheduled maintenance window), and inability to get vendor TAC support even for problems unrelated to the optic.

Reading the EEPROM Yourself

On Linux, ethtool -m ethX gives you a decoded view. For raw hex, ethtool --dump-module-eeprom ethX hex on is more useful when you want to check specific bytes against SFF-8024. On Cisco NX-OS, show interface ethernet X/Y transceiver detail parses the EEPROM and presents the vendor fields. On Junos, show chassis pic fpc-slot pic-slot and show interfaces diagnostics optics give you the decoded view.

If you're doing systematic inventory of a large install base, writing a small script that checks byte 0x00 against expected values and flags mismatches is a ten-minute investment that pays off every time you inherit someone else's network. The alternative is discovering that your "100G LR4" port is actually running a 25G SR optic that someone labeled wrong after the last migration, while you're standing in a data center at 2 AM.

Understanding SFF-8024 is not about memorizing lookup tables. It's about knowing which three bytes define what the hardware claims to be, which fields define what the vendor claims to have built, and what your NOS does with the difference between those claims and what it expects to see. Most compatibility issues reduce to exactly that gap.