transceiver-db/blog-training-data/blog-011-transceiver-procurement-checklist.md

title	type	target_audience	score
The Transceiver Procurement Checklist Nobody Gave You	tutorial	customer	9/10

Buying transceivers at scale is one of those processes where the failure mode is invisible until it isn't. The batch that arrived dead. The optics that work fine in the lab but trip a syslog warning in production. The compatible modules that are "400G SR4" but weren't tested on your specific platform. The price that looked right until you factored in shipping, DOA replacement, and the hours spent in TAC calls. This is the checklist that prevents those problems.

Start before you talk to a vendor. Document your exact requirements in terms that a datasheet can answer. Form factor (QSFP-DD, QSFP28, SFP28, SFP+, OSFP). Speed (10G, 25G, 100G, 400G). Standard (SR4, LR4, DR4, CWDM4, etc.). Switch platform and software version. Required operating temperature range (commercial 0-70°C or extended/industrial). Target fiber type (OM3, OM4, OS2 single-mode). Required reach. Any DWDM requirements including channel plan and center frequencies. This list seems obvious. In practice, half the procurement errors happen because the requirements weren't written down and someone ordered LR4 instead of SR4 or got the wrong fiber type.

The switch platform and software version matter more than people realize. Compatibility isn't just "QSFP28 100G module in a QSFP28 port." It's "this specific module, in this specific software version, with or without the 'service unsupported-transceiver' configuration flag, on this specific ASIC-based platform." Some platforms check the EEPROM identifier and log warnings. Some block traffic until explicitly authorized. Some have firmware dependencies where a specific software release introduced or fixed a compatibility issue. The answer to "is this compatible?" should come with a tested software version, not just a yes/no. If a vendor can't tell you the specific platforms and software versions they've validated against, that's a red flag.

The DOA rate question is one you should ask every compatible vendor directly. The answer should be a number, not "very low" or "industry-leading." A credible answer looks like: "Our DOA rate for 100G QSFP28 SR4 over the past 12 months is 0.18%, tracked across batch shipments with our certified test report." If they can't give you a number, their quality control tracking is either nonexistent or they don't want you to know what it is. Good compatible vendors know their DOA rates by SKU because they track it to identify manufacturing batch issues. Expect 0.1-0.4% DOA for quality compatible optics. Anything below 0.1% should prompt the follow-up question of "how many units is that based on?"

Burn-in testing: ask whether the vendor does it and for how long. Burn-in testing runs modules at elevated temperature under load for 24-72 hours before shipping to catch early-life failures. OEM vendors do this. Tier-1 compatible vendors do this. Tier-2 and grey-market vendors often don't. Early-life failures (the ones that happen in the first 30-90 days) are the most expensive because they cause production incidents. A day of burn-in testing at the factory costs a fraction of an hour of unplanned downtime.

The EEPROM data question: for compatible optics targeting specific switch platforms (Cisco, Juniper, Arista), does the vendor program the correct vendor-specific EEPROM bytes? This is what enables the switch to recognize the optic without requiring manual configuration changes. A "Cisco-compatible" QSFP28 should have the Cisco vendor identifier and part number encoded in the EEPROM so IOS reads it as a recognized module. Ask for the EEPROM read output for the specific platform you're deploying on. Any credible vendor can provide this. The data looks like a table of register values — it's a standard diagnostic dump, not proprietary.

The test report question: before accepting any batch of more than 50 optics, request the batch test reports. These are the power output measurements, receive sensitivity measurements, and electrical eye diagram results from the production line. A batch test report shows that the optic meets the MSA specification for its type — that TX power is within range, that eye diagrams are open, that the center wavelengths (for CWDM/DWDM) are accurate. If the vendor provides test reports for every batch, they have a quality process. If they tell you the report isn't available or costs extra, they don't have the infrastructure to provide it consistently.

Incoming inspection at your site: for any batch over 100 units, plan for incoming inspection before deployment. This means taking a random sample (10% is reasonable) and doing power measurements with an optical power meter against a known-good source. Check that TX power is within spec for every module in the sample. Check that the EEPROM reads correctly. Check that DOM data shows normal values when the module is powered. This takes about two minutes per module with the right setup. For 100 modules at 10% sampling, it's 20 minutes and it will catch bad batches before they go into production.

Warranty terms vary more than people expect. "Lifetime warranty" is common in compatible optic marketing. Read the fine print: does "lifetime" mean the product lifetime or your network's lifetime? Is the warranty carry-in (you ship it to them) or advance replacement (they ship you a new one first)? What's the shipping cost arrangement? A compatible vendor with advance replacement for DOA modules within 24 hours of RMA approval is worth more than one with a lifetime warranty that requires three business days to process and requires you to ship first. Operational impact is measured in hours.

Spare parts pooling: decide before deployment how many hot spares you're carrying. For data center fabric, 1-2% of deployed optic count is a reasonable spare pool. For critical links (management plane, out-of-band, power management), carry one-for-one spares. For best-effort infrastructure, lower. Document which SKUs are in your spare pool and where they're stored — this sounds obvious but becomes non-obvious in a multi-site environment where someone is pulling spares from a different site's inventory to cover a production incident.

The DWDM case is worth calling out separately because the procurement tolerance requirements are more specific. For DWDM transceivers, you need to verify the channel wavelength to ITU G.694.1 grid specifications (typically 50 GHz spacing). The center wavelength should be accurate to within ±0.05nm for 100G coherent, within ±0.15nm for direct-detect CWDM4. Ask for the actual measured center wavelength for each DWDM module, not just the nominal channel. DWDM transceivers are tuned to specific ITU channels and a module that's off by 0.3nm on a tight DWDM system will cause BER problems that look like fiber issues.

Pre-deployment testing in your actual environment is the last step and the one most often skipped under time pressure. Plug one of each SKU into your actual switch, your actual software version, check for syslog warnings, verify DOM data reads correctly, run link training and BER tests if your platform supports it. This takes two hours and it is the only reliable way to catch compatibility issues before they affect production traffic. The lab validation your vendor did may not match your exact configuration. Test it yourself.

None of this is complicated. It's all checkboxes that require either asking the right questions or spending a small amount of time on incoming validation. The companies that run optics procurement well aren't doing anything exotic — they have the checklist, they follow it consistently, and they have enough operational data to know which vendors hit their commitments. Start building that data now.