As a manufacturer of 3rd Party Certified Optical Transceivers, I’m often barraged with questions regarding the difference between Cisco approved SFPs and third party SFPs (Cisco Compatible). Inevitably the discussion starts going down the slippery slope of vendor lock in and high-profit racketeering. I’m going to try to explain the differences and ways to circumvent “lock in”.
Cisco uses OEMs (original equipment manufacturers) to produce all their SFPs, XFPs, SFP+, SFPs manufactured under the OEM model are packaged up in Cisco sealed bags and called “Cisco approved”.
Being Cisco approved means the SFPs have undergone rigorous testing with Cisco products and are guaranteed to have 100% compatibility and complete support. Third party SFPs (aka Cisco Compatible) are manufactured by companies not on the Cisco AVL (approved vendor list) and, therefore, are not deemed Cisco approved. These manufacturers will offer 100% compatibility guarantees but Cisco will not support them. Cisco may threaten breach of SmartNet and refuse support. Cisco reserves the right to refuse service and/or support if the problem is determined to be related to third party SFPs. From personal experience I’ve had plenty of customers using third party SFPs call in for other hardware problems and the SFPs go unnoticed. But if you are trying to bring up a fiber connection and it won’t come up and need help from Cisco you won’t get far with 3rd party transceivers.
The third party SFPs won’t work by default. Cisco-approved SFP modules have a serial EEPROM that contains the module serial number, the vendor name and ID, a unique security code, and cyclic redundancy check (CRC). When an SFP module is inserted in the switch, the switch software reads the EEPROM to verify the serial number, vendor name and vendor ID, and recomputes the security code and CRC. If the serial number, the vendor name or vendor ID, the security code, or CRC is invalid, the software generates this security error message and places the interface in an error-disabled state.
Here is a common log message indicating the hardware platform has detected an invalid SFP:
SYS-3-TRANSCEIVER_NOTAPPROVED:Transceiver on port Gx/x is not supported
These commands will differ from platform to platform. Fortunately, there are some undocumented (and unsupported) commands to circumvent this issue. From configuration mode enter the following commands. Note that since the first command is undocumented you can’t “tab” and “?” your way to the command. You can only type the full command in.
switch(config)# service unsupported-transceiver
switch(config)# no errdisable detect cause gbic-invalid
The first command will yield the following:
Switch(config)#service unsupported-transceiver
Warning: When Cisco determines that a fault or defect can be traced to the use of third-party transceivers installed by a customer or reseller, then, at Cisco’s discretion, Cisco may withhold support under warranty or a Cisco support program. In the course of providing support for a Cisco networking product Cisco may require that the end user install Cisco transceivers if Cisco determines that removing third-party parts will assist Cisco in diagnosing the cause of a support issue.
The above command should make it clear that you run the risk of losing support. I’ve used the above commands on Cisco 3750, 3560, and 2960 platforms.
Ultimately it’s the decision of the customer to make the call. Only they can ultimately decide risk versus reward. It’s our job as technology partners to explain the advantages and disadvantages of either approach.
Here are some reference links for additional information:
Third Party Policy:
http://www.cisco.com/en/US/prod/prod_warranty09186a00800b5594.html
SFP Invalid Error:
http://www.cisco.com/en/US/products/hw/modules/ps4999/products_tech_note09186a00807a30d6.shtml