Subscribe to this list via RSS Blog posts tagged in Optical Transceiver
5676

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

Last modified on Continue reading
0

Blog Menu

News 

  • Cascadia FiberNet plans fiber-optic network link between Vancouver, BC, and Seattle

    Cascadia FiberNet Inc., part of the Cascadia Gateway Initiative, has announced plans for an 864-strand fiber-optic network between Vancouver, British Columbia’s Harbour Centre and Seattle’s Westin Building Exchange. Work on the carrier-neutral fiber network should begin by this March with a goal of begin ready for service by the end of the first quarter of 2020.

  • OFS offers R-Pack Rollable Ribbon Backbone Cable

    OFS has expanded its line of rollable ribbon cables with the R-Pack Rollable Ribbon (RR) Backbone Cable. Available with 24, 48 and 72 fiber counts, the R-Pack RR Backbone Cable targets horizontal backbone applications and NFPA 202 requirements. OFS sees the fiber-optic cable as applicable to data center, central office, and fiber-to-the-business (FTTB) fiber networks.