Arista EOS reads the EEPROM data programmed into every transceiver at insertion. When EOS does not recognize the vendor ID string in byte 148 of the SFF-8472 or SFF-8636 memory map, it flags the module as unsupported — and depending on your EOS version and configuration, either logs a warning or disables the interface entirely.
This does not mean the module is defective or out of spec. It means the firmware identifier does not appear on Arista's approved vendor list. A module with correct TX power, RX sensitivity, and wavelength can still trigger this warning if the EEPROM vendor string goes unrecognized.
The fix is a single global configuration command. Choosing the right module is where the real work happens.
Before touching any configuration, confirm what EOS is actually seeing:
show interfaces transceiver
Look for notPresent, unsupported, or xcvrAbsent on the affected interface. Then run:
show logging | grep XCVR
This surfaces the exact %XCVR-6-UNSUPPORTED_TRANSCEIVER entries with timestamps and interface names.
unsupported-transceiver CommandIn global configuration mode:
switch(config)# service unsupported-transceiver
On EOS 4.20 and later, you may also need:
switch(config)# transceiver qsfp default-mode 4x10G
Or, to accept all third-party modules globally:
switch(config)# service unsupported-transceiver
Arista introduced a license-key requirement in certain EOS releases to formally acknowledge that you are accepting responsibility for third-party modules. If your version requires a key, the command without one will still suppress the warning in most deployments — but check your specific EOS release notes to confirm the exact behavior.
After applying the command:
switch(config)# write memory
switch# show interfaces status
The interface should come up. If it does not, pull the DOM data:
show interfaces transceiver detail
Verify TX power is within the expected range for your link type. For 100G SR4, that is between -7.3 dBm and +2.4 dBm. If TX power reads N/A or is significantly out of range, the module itself may be faulty rather than simply unrecognized.
To enable third-party modules on specific interfaces rather than globally:
switch(config)# interface Ethernet1
switch(config-if)# no switchport
switch(config-if)# transceiver media override
This is useful in mixed environments where some ports run Arista-branded modules and others use third-party alternatives.
It comes down to EEPROM programming. A module coded with a generic or incorrect vendor ID string will always trigger the warning. A module with firmware coded to present a recognized identifier — or with a vendor field that EOS accepts under the service unsupported-transceiver override — will come up without log noise.
This is why supplier selection matters as much as the EOS command itself. Running service unsupported-transceiver suppresses the warning, but it does not fix a module with incorrect DOM data, wrong wavelength coding, or a bad EEPROM checksum. Those problems surface as link instability or DOM read errors even after the port comes up.
Switch-verified modules — where the supplier has tested the specific module against the specific EOS version and platform — eliminate that second layer of risk.
The 100G QSFP28 is the most common third-party replacement target on Arista platforms. The four primary variants:
| Variant | Wavelength | Reach | Use Case |
|---|---|---|---|
| QSFP28 SR4 | 850nm (4x lanes) | 100m OM4 | Top-of-rack, intra-DC |
| QSFP28 LR4 | 1310nm (4x lanes) | 10KM SMF | Inter-building, campus |
| QSFP28 CWDM4 | 1270–1330nm | 2KM SMF | Data center interconnect |
| QSFP28 PSM4 | 1310nm (4x parallel) | 500m SMF | Parallel SMF runs |
For short-reach intra-rack and top-of-rack deployments on Arista 7050CX3 or 7060CX2, QSFP28 SR4 at 850nm is the standard choice. For inter-DC runs up to 10KM, QSFP28 LR4 at 1310nm is the correct spec.
400G deployments on Arista platforms typically use QSFP-DD DR4 (500m SMF, 1310nm) or QSFP-DD SR8 (100m OM4). Both are drop-in compatible with Arista 7170 and 7800 series switches when sourced from a supplier that programs the EEPROM correctly for EOS.
800G QSFP-DD DR8 — 800G, 1310nm, up to 500m on SMF — is the form factor driving AI and GPU cluster buildouts in 2026. Arista 7800R3 and the newer 7800R4 series support 800G QSFP-DD natively.
An 800G QSFP-DD DR8 Arista-compatible module is in stock at HYTOPTODEVICE, switch-verified and factory direct. At 60 to 90 percent below Arista OEM list pricing, the per-port cost difference across a 64-port 800G spine switch is large enough to justify a procurement review on its own.
| Arista Platform | Speed | Recommended Form Factor | Typical Reach |
|---|---|---|---|
| 7050CX3-32S | 100G | QSFP28 SR4 / LR4 | 100m / 10KM |
| 7060CX2-32S | 100G | QSFP28 SR4 / CWDM4 | 100m / 2KM |
| 7170-64C | 400G | QSFP-DD DR4 / SR8 | 500m / 100m |
| 7800R3 | 400G / 800G | QSFP-DD DR4 / DR8 | 500m |
| 7800R4 | 800G | QSFP-DD DR8 | 500m |
| 7280CR3 | 100G / 400G | QSFP28 LR4 / QSFP-DD DR4 | 10KM / 500m |
These pairings are based on standard MSA specs for each form factor and reach class. Always confirm your specific EOS version supports the chosen form factor before ordering at volume.
Three things separate a reliable supplier from one that ships modules that pass the EEPROM check but fail under load.
EEPROM coding accuracy. The supplier must program the correct vendor ID, part number, and serial number fields — and the DOM calibration data must reflect the actual optical performance of the module. Miscalibrated DOM data produces incorrect TX/RX power readings in show interfaces transceiver detail, which makes troubleshooting future link issues significantly harder.
Switch-level test verification. Bench testing on the actual Arista platform — not just generic MSA compliance — confirms the module comes up without warnings and passes DOM polling correctly. Compatibility test videos published by the supplier give you something concrete to reference before committing to a large order.
Factory-direct supply chain. Modules sourced directly from the factory carry no distributor markup and ship with consistent firmware. Reseller-stocked inventory can include modules from multiple firmware revisions, which creates inconsistency across a large deployment.
HYTOPTODEVICE supplies factory-direct Arista-compatible transceivers from 100G QSFP28 through 800G QSFP-DD, with compatibility test videos on site and 24/7 engineer support. Volume or single-unit orders ship worldwide.
Not saving the configuration. service unsupported-transceiver is a running-config change. Skip write memory and a reload reverts the setting — the warning comes right back.
Running an EOS version that requires a license key. On EOS 4.23 and later, some builds require the service unsupported-transceiver syntax. Without the key, the command may appear to accept but not fully suppress the error on all interface types.
Module with a bad EEPROM checksum. If the checksum does not validate, EOS will flag the module regardless of the service unsupported-transceiver setting. That is a supplier quality issue, not an EOS configuration issue.
Wrong form factor for the port type. Inserting a QSFP28 into a port configured for QSFP+ mode, or a QSFP-DD into a port not yet enabled for 800G, produces a different error that the unsupported-transceiver command does not address.
Q1:Does service unsupported-transceiver void my Arista support contract?
A:Arista's support terms state that issues directly caused by third-party transceivers may not be covered. The command itself does not void the contract for unrelated hardware or software issues. Most network teams accept this trade-off given the cost difference — particularly in high-density deployments where OEM transceiver spend is a material budget line.
Q2:Which EOS versions support the service unsupported-transceiver command?
A:The command has been available since EOS 4.14. On EOS 4.23 and later, some builds introduced an optional license-key parameter. The base command without a key still functions in most deployments, but check your specific EOS release notes for the exact syntax.
Q3:Can I use a 100G QSFP28 third-party module on an Arista 7050 without any EOS changes?
No. EOS will log the unsupported transceiver warning and may disable the interface. You need to run service unsupported-transceiver in global config and save the configuration before the port will come up.
Q4:What is the difference between QSFP28 SR4 and LR4 for Arista deployments?
A:QSFP28 SR4 operates at 850nm over multimode fiber, reaching 100m on OM4. QSFP28 LR4 operates at 1310nm over single-mode fiber, reaching 10KM. SR4 is the standard choice for intra-data-center links; LR4 is used for inter-building or campus connections.
Q5:Are 800G QSFP-DD modules compatible with Arista 7800 series switches?
A:Yes. The Arista 7800R3 and 7800R4 series support 800G QSFP-DD natively. The 800G QSFP-DD DR8 form factor at 1310nm covers up to 500m on SMF and is the standard choice for AI cluster spine-leaf interconnects in 2026.
Q6:How do I verify a third-party transceiver is working correctly after the warning is cleared?
A:Run show interfaces transceiver detail and confirm TX power, RX power, temperature, and voltage are all within expected ranges for the module type. Also check interface counters for CRC errors or input errors under show interfaces Ethernet.
Q7:What should I do if the port stays down after running service unsupported-transceiver?
A:Check the DOM data for out-of-range TX or RX power. Reseat the module and clean the fiber connector. If DOM data shows N/A across all fields, the EEPROM likely has a checksum error and the module should be replaced. If DOM data looks correct but the link is still down, verify the remote end is up and check for fiber polarity issues on MPO-based SR4 links.
service unsupported‑transceiver command only suppresses log alerts; it cannot fix inaccurate DOM calibration, wrong wavelength coding or corrupted EEPROM data. HYTOPTODEVICE Arista‑compatible transceivers undergo full optical and EEPROM calibration before shipment to prevent such post‑configuration link‑flapping issues.service unsupported‑transceiver enables third‑party optics for all ports. Per‑interface transceiver media override applies only to selected Ethernet interfaces, ideal for mixed OEM‑and‑third‑port environments. HYTOPTODEVICE technical documentation covers both deployment modes for network engineers configuring Arista switches.service unsupported‑transceiver is correctly configured. HYTOPTODEVICE runs EEPROM integrity verification for every Arista‑compatible transceiver during factory testing to avoid this common deployment pitfall.show interfaces transceiver detail to inspect TX/RX power, temperature and voltage readings, check interface counters for CRC errors. HYTOPTODEVICE Arista‑compatible transceivers output accurate DOM data, allowing you to perform standard Arista EOS health checks for long‑term link monitoring.The service unsupported-transceiver command takes 30 seconds to apply. Choosing a supplier whose modules do not require a second round of troubleshooting after that command is the part that takes more thought. Factory-direct, switch-verified modules with accurate EEPROM coding and published compatibility tests are the standard to hold any third-party supplier to. Browse the full Arista-compatible catalog — including 800G QSFP-DD DR8 in stock — at hytoptodevice.com.
