transceiver-db/blog-training-data/blog-058-arista-eos-optic-compatibility.md

title	slug	type	category	tags	seo_focus_keyword
Arista EOS Optical Compatibility: Reading the xcvr Errors and Understanding the Open Stance	arista-eos-optic-compatibility-xcvr-errors	deep-dive	Vendor Compatibility	Arista EOS QSFP28 SFP28 xcvr-missing DOM third-party optics	Arista EOS optic compatibility xcvr errors

Arista built its reputation partly on being the switch vendor that doesn't fight you about transceivers. For most of the company's history, that reputation was well-earned. EOS has historically been permissive about third-party optics by default—no service contract dependency, no hard blocks based on PID strings, no require-branded-optics enforcement. But "permissive by default" has always come with qualifications, and the error messages EOS generates around optics deserve a closer reading than they usually get.

The Two Error Strings That Matter

When an optic has issues on an Arista platform, you'll typically see one of two error conditions in show interfaces status or show interfaces ethernet 1/1 transceiver:

xcvr-missing: The port has no transceiver installed, or the installed transceiver isn't being detected at all. This sounds obvious but is sometimes misleading—it can also appear when a transceiver is physically present but failing the electrical handshake. If you're seeing xcvr-missing on an occupied port, the first check is whether the optic is fully seated. The second check is whether the optic is electrically compatible with the port type. Inserting an SFP+ into a QSFP28 port with an adapter, for example, will sometimes show xcvr-missing rather than a type-mismatch error.

xcvr-dom-not-supported: This is the more interesting one. It appears when EOS can detect the transceiver and bring the port up, but the DDMI (Digital Diagnostic Monitoring Interface) data isn't readable—either because the transceiver doesn't implement the A2 page of SFF-8472 (for SFP+) or the upper memory pages of SFF-8636 (for QSFP28), or because the A0 address byte 92 (the "diagnostic monitoring type" byte) doesn't correctly indicate that real-time monitoring data is available.

A port showing xcvr-dom-not-supported can still pass traffic normally. The error is cosmetic in terms of link operation, but it means you have no visibility into optical power levels, temperature, bias current, or voltage from that interface.

How Arista's Open Stance Works Mechanically

On EOS 4.20 and later, Arista's default behavior is to accept any transceiver that presents valid SFF-8472 or SFF-8636 EEPROM data and passes the MSA electrical interface tests. There is no PID whitelist enforcement in the default configuration. This is the architecture-level decision that distinguishes Arista from Cisco: the transceiver acceptance logic in EOS is capability-based rather than identity-based.

What EOS does check is the connector type byte, the transceiver type byte, and the compliance codes. If you plug a 10GBASE-SR SFP+ into a port configured for 25G, EOS will correctly refuse to bring the port up—not because of a compatibility blacklist, but because the speed negotiation doesn't match. This is correct behavior, not a third-party restriction.

On EOS versions prior to 4.15, there was a transitional period where some 40G QSFP+ ports would generate xcvr-dom-not-supported for any optic not in Arista's internal EEPROM vendor list, even if DOM data was actually present and readable. This was addressed in 4.15.2F, which rewrote the DDMI polling logic to query the A2 page directly rather than checking against a vendor list first.

EOS Versions That Changed the Strictness

The most significant loosening came in EOS 4.20.x, which introduced explicit support for the "unknown transceiver" state: the port operates normally, DOM data is displayed if available, and the only indication of an unrecognized transceiver is a low-severity log entry rather than an operational alarm. Before 4.20, some platforms (particularly the 7050CX series) would disable DOM polling entirely for unrecognized transceivers, leading to the xcvr-dom-not-supported condition even when the optic was perfectly functional.

EOS 4.26 introduced transceiver management, a configuration subsystem that lets you explicitly set per-interface transceiver expectations. This is mostly useful for enforcing that specific ports always have the correct optic type installed—a data center compliance use case—but it also introduced transceiver management permitted-xcvr-type which, if misconfigured, can make an otherwise permissive EOS installation selectively restrictive. If you've upgraded to 4.26 or later and suddenly have new compatibility issues that didn't exist on 4.22, check whether someone has enabled transceiver management policies.

DOM Display on Arista: What You Actually See

The show interfaces ethernet 1/1 transceiver command on EOS produces a clean output for supported optics:

Ethernet1/1 transceiver is present
  type is 100GBASE-SR4
  Manufacturer is Flexoptix
  SN is FX123456789
  Temperature is 32.07 Celsius
  Tx Power is 2.73 dBm
  Rx Power is -1.47 dBm
  Bias Current is 55.17 mA

For an optic generating xcvr-dom-not-supported, the same command produces the top block (type, manufacturer, serial) but the DOM fields are absent. This means the EEPROM A0 page is readable (so transceiver type detection works) but the A2 page or upper memory pages are not properly configured.

The check command for distinguishing a real DOM problem from an EEPROM programming issue is:

show interfaces ethernet 1/1 transceiver detail

The detail output includes the raw EEPROM compliance bytes and indicates whether the DOM capability flag is set. If DOM capability is not asserted in the EEPROM but physical monitoring data is present on the A2 page, EOS won't poll it—the capability flag is authoritative. Fixing this requires reprogramming the optic's EEPROM byte 92 to correctly assert A2 page monitoring capability.

Arista vs. Cisco: A Practical Comparison

The difference in the field is stark. A Cisco Catalyst 9500 with a third-party QSFP-28 that has the wrong Vendor PN in its EEPROM will refuse to bring the port up, full stop, unless you've upgraded to a JunOS version that added that PID to the compatibility table. An Arista 7050CX3 with the same optic will bring the port up, display whatever DOM data is available, and generate a log entry that says essentially "I don't recognize this specific optic but it looks electrically fine."

This matters operationally. With Arista, an improperly programmed EEPROM degrades your operational visibility but doesn't cause an outage. With Cisco, it can cause an outage until the programming is corrected or the software version is updated.

The practical lesson is that even on Arista platforms, optic EEPROM quality matters—just for different reasons. On Cisco, a bad EEPROM causes port failures. On Arista, it causes monitoring gaps. Neither outcome is acceptable in production.

The 400G Wrinkle

On Arista's 400G platforms (7060X4, 7080X4, and similar), the permissive EOS stance runs into a hardware constraint: OSFP and QSFP-DD modules use Arista's in-house thermal management system to maintain optic temperatures within safe operating bounds. The thermal management system needs to know the optic type to set fan curves correctly. For recognized optics, this happens automatically. For unrecognized QSFP-DD optics, EOS 4.28 and later will accept the optic but fall back to a conservative (higher fan speed) thermal profile.

This isn't a compatibility block—the port comes up—but in a dense deployment, the fan speed increase across a full chassis of unrecognized 400G optics generates enough acoustic noise to be a practical concern in some environments. If 400G deployment is in your near-term roadmap, verifying that your optic vendor's 400G QSFP-DD PIDs are recognized by Arista is worth more than a cursory check.