Successful fiber projects depend on coding that's certified OEM compatible.
Quality is top of mind when sourcing for any project, but with fiber optics, its importance is scaled tenfold. A component must be of the correct specifications for the network it is intended to support--specifications that, for transceivers, run the gamut from speed and supported wavelengths to connectors and form factors. While matching all of these to the rest of your hardware are important, one of the most critical elements for deployment success is a transceiver's coding.
Even if all of the other specifications are met, if a transceiver's EEPROM is not coded and safeguarded correctly for the environment it is to be deployed in, it is all for naught. A transceiver is no more than a metal brick if it cannot communicate with other devices within your network environment.
Working with a provider like AddOn that has the experience and confidence to certify their transceivers as fully interoperable with the OEM switches you're using is paramount to guaranteeing success. Otherwise, you may end up dealing with the results of other providers' coding inexperience--the headaches of technical support, returns/exchanges, and project delays.
What are the most frequently reported issues when sourcing from less experienced third-party suppliers?
The most often reported issues stem from poor reliability or a lack of compatibility. Reliability issues are most commonly related to the quality of the transceiver's hardware (more on hardware reliability issues here), while compatibility ones are directly associated with poor quality (or even blatantly incorrect) coding.
Poorly or incorrectly coded optics can cause a transceiver to throw a myriad of errors, ranging in the severity from "working but with non-functioning feature(s)" to "reporting as the wrong part" or even receiving the dreaded “unsupported data” or "no PID" errors, leading to a disabled port.
These errors, regardless of severity, cause network delays and system reboots, eating up critical project time and possibly requiring a system engineer to repair in the most catastrophic situations.
What are some of the errors thrown by transceivers coded by those without the experience to do so properly?
Tested products included a diverse sampling of hardware types from various suppliers, such as SFP LX, QSFP LR4, SFP+ DWDM, and a variety of DACs and AOCs.
When these test products were installed in Cisco and other OEM systems, those that failed fed back the below:
Transceivers:
- Error: Incorrect part number displaying in the EEPROM.
- Consequence: Certain features may not be supported and additional configuration may be required.
- Error: No “PID” displays
- Consequence: The switch may not recognize the part, thus disabling the port. Or, it may work for now, but future OEM updates may cause issues or failures.
- Error: Displays "Non-Cisco" (or other OEM).
- Consequence: The switch may render the port unusable until it the optic is recoded or replaced.
- Error: Receive "UNSUPPORTED" message upon inserting in any switch ports.
- Consequence: If read as non-compatible, it may not be usable depending on the severity of the mismatch. Recoding or a replacing is again required.
- Error: No “PID” displays.
- Consequence: The switch may render the port unusable until it the optic is recoded or replaced.
- Error: No DOM reporting available on AOCs in multiple platforms.
- Consequence: The lack of reporting may limit troubleshooting and monitoring capabilities, hampering visibility of operators in resolving faults or failures.
- Error: Module SPROM display 0 meters.
- Consequence: The lack of detailed information provided to the switch may cause issues with troubleshooting and monitoring capabilities.
DACs & AOCs:
- Error: Wrong part number shown in the EEPROM.
- Consequence: Certain features may not be supported or additional configuration may be required.
What happens if an optic is not coded correctly?
Incorrectly coding a transceiver can have many unexpected adverse effects. Sometimes the effects are minor, such as a nice-to-have feature not being supported. Other times, the OEM switch won’t even recognize the part, let alone recognizing it as compatible. This makes the port unusable until the transceiver is swapped out or coded appropriately.
One specific but disastrous example is that the EEPROM on the transceiver can be coded without write protections (such as a password). If an EEPROM does not have a write protection, an OEM switch may "accidentally" overwrite some or all of the pre-installed coding. This "bricks" the transceiver, making it (and the port its in) useless until recoded or replaced. Since power surges or outages often force hardware to reboot (and these OEM devices typically attempt to write to optics on a reboot), it becomes highly probable that amateurishly coded transceivers will end up disabling or crippling your network.
Understanding an end user's needs and properly coding an optic to meet them avoids these issues, which is why working with a provider with experience in coding transceivers is so crucial.
What happens to the optic when there are revisions or updates to the OEM software?
OEMs are constantly updating their hardware's firmware to support new features and security updates as demanded by their end users (and rightfully so). An unintended but critical side effect of firmware updates are that they can throw a proverbial wrench into the works for those using third-party optics. Frequently updating their firmware combats third-party optics that are often priced at a fraction of their equivalent as providers then scramble to update their coding. Because of this practice, other suppliers’ optics may be functional upon delivery and installation, but unless they stay on top of these revisions and changes to software, their parts to can (and often do) later fail.
While no provider has a crystal ball to divine exactly what new compatibility challenges OEMs revisions will bring before they do so, the AddOn team is dedicated to constantly researching these firmware upgrades and implementing them to our optics, maintaining an up-to-date coding database. This helps keep our optics working far beyond just initial deployment, unlike many of our competitors. When choosing AddOn as your optics provider, you aren't sourcing for just a short term solution, but for the long haul.
How do I avoid these headaches when working with third-party optics providers?
Quite simply, partner with AddOn! We understand the importance of quality, which is why we've taken measured steps in our manufacturing and testing processes. When you've worked with those who depend on your products daily, you're easily able to provide solutions that directly address their infrastructure's needs at a foundational level.
Our in-house coding facility programs and certifies all parts to standard OEM specs while also having the flexibility to create one-of-a-kind coding solutions for customized networks. AddOn transceivers come packaged with over 20 years of experience using our database of compatible programming, resulting in a final product with unrivaled reliability. These decades of experience ensure that we provide our valued partners mission critical optics that work the first time and every subsequent time.
Every optic we ship is first coded in-house at our U.S. and U.K. facilities, then tested in the exact environment that the client intends to deploy their transceiver. Our advanced test bed guarantees that they perform identical to an OEM version. This expert-driven coding process results in optics with a 99.98% reliability rate with certified compatibility.
Lastly, our proprietary Data Traveler System™ tracks and serializes every part to ensure it has gone through proper coding and testing. From keeping our testing and coding lab up to date with the latest hardware to pre-code hardware inspections, we create certified solutions that are guaranteed for long lasting compatibility and performance.